I think there is a stunning amount of "resource cynicism" in this thread. Yes, this application uses much more RAM and CPU than a "normal" terminal emulator. The project author is clearly trying to explore other ways that terminal interaction could work, and is using a well known framework to accelerate this process. If you use this project, you're using it to experiment with a new way of working with the terminal, not to get screaming fast GPU accelerated screen rendering. Potentially discovering new, valuable ways of working with computers is worth doing, and should be encouraged.
I encourage experimentation like this, and I've been spending some time thinking of how a terminal emulator could be re-invented. Some of the best ideas I already see implemented so I'm very excited to try it.
Unfortunately, in practice it falls short. RAM is one thing, but CPU usage is absolutely through the roof. The app freezes when trying to type "cd jobs", then consumes all CPU cores fully and stalls my computer. Fans spin up and doing a simple "ls -al" takes several seconds for it to complete. During this time it will not buffer keypresses properly and I experienced old keypresses being mixed with new ones, to create a command I did not type.
The project doesn't sell itself as experimentation. Even if it did I'd advice against testing it, simply because of the severity of the issues I encountered using it for 5 minutes.
This project shows what can be done. It's a step forward. Now it's up to other terminal emulators to see how far they can go towards this.
It's a hog because it uses electron (in other words chromium browser), on the one hand this makes a lot of sense for text, CSS and HTML are useful tools for this kind of experimentation, on the other hand electron is a behemoth and this makes xterm look like a twig... I think everyone is in agreement that terminal emulators should be lightweight.
> Also, unlike most of the emulators you can meet nowadays it uses HTML and CSS for its UI (exactly as Atom does), which means we can stop misusing unicode characters and make a better looking terminal with appropriate tools.
I added emphasis.
When they say it's the right tool for the job, and in reality it's not... well, you get reactions like these. And justifiably I think.
The author meant it as "no more ASCII art for window decorations in the terminal console", and you just twisted it into "use a Web browser, because that's the right way", am I right?
I see this attitude all the time, namely the idea that difficulty is somehow proof of quality, or "professionalism" of a tool. It's obviously rooted in some instances where it is/was correct, such as the superior typesetting of LaTeX vs Word for academic work. But it's not an ironclad rule, and it shouldn't be trotted out as an argument anytime someone tries to improve existing tools. In this case:
- I'd say I need to look up any option flags or commands I use less than 15x/week
- Even the most professional 10x developer will spend a significant amount of his time with such commands, making this feedback useful
- The shell is essentially a REPL, but most people forgo most of its potential because the language isn't core to our work, and somewhat hideous. Anything that helps discoverability could be useful.
And, for what it's worth, designers that work with code usually don't have problems with git. Designers that work with photoshop would rarely need git, which is kinda out of its element with binary data
You appear to be suggesting we forgive the project for its poor memory footprint because Electron was used as a sort of rapid prototyping tool to get v1.0 out the door.
I think you know just as well as everyone else that this project's use of Electron is unlikely to be an interim measure. It will (probably) always be a resource hog, just like Chrome will (probably) always be a resource hog. That's a conscious choice that is here for the duration.
Using Electron may have accelerated the process but let's not pretend that the author is going to rewrite it in something more performant once a little traction is gained.
I'm not suggesting that at all. I'm saying this project would likely not exist in any form without Electron. If the ideas expressed within are successful enough, realistically speaking people would either:
1. continue using it despite the footprint
2. merge similar ideas into other emulators
3. fork and rewrite in whatever the next paradigm for expressive UI apps is (with hopefully a smaller footprint)
If there is shown to be a demand for this kind of terminal UX, someone may well write a native version of it. Possibly it will push some of the existing terminal emulator projects to add new features, or someone will fork one of them.
Either way, it's nice to have options, and it's nice to see innovation, and if Electron makes it easier to innovate we should be glad of that.
Technically, adding a 5th prong to a middle of fork that bends backward is "innovative". But is it useful?
Okay that was a bit snarky, but.. aside from the primitive monkey part of my brain that cringes at any electron app's resource (ab)use, there's the fact that these apps are proliferating like crazy, and the resource usage adds up after a while.
If all you're running is Atom, you probably don't care. But when you're using Atom, Simplenote, Discord, Slack, Nylas, and Brave all on the same box at the same time (hi!), it's enough to bring even a modern desktop processor to its knees when any of them misbehave. With Moore's law on its way to being broken, I'd like to see tighter development, rather than this sprawl of easy-but-wasteful tools.
Electron is to app development as Keurig machines are to coffee. Easy, convenient, horribly wasteful and inefficient.
>Using Electron may have accelerated the process but let's not pretend that the author is going to rewrite it in something more performant once a little traction is gained.
If we also dont pretend that the sort of people complaining are anything but a distraction.
Because nothing is stopping them from writing something they like better, except off course skill, attitude and discipline. Thankfully they are able to contribute something much more valuable: opinions.
So, yeah. Maybe its a resource hog. Its still interesting and far superior to resource friendly version with the same feature set due to it having the awesome feature of actually existing.
> Because nothing is stopping them from writing something they like better, except off course skill, attitude and discipline. Thankfully they are able to contribute something much more valuable: opinions.
If people don't want feedback, then they shouldn't post on HN. HN is a place where plenty of people provide opinions whether others like it or not. If that's not something people want, then they shouldn't be here.
As for making something better. Better solutions already exist. Terminal emulators are an already solved problem. What terminal emulator problem will be solved that hasn't already been solved by urxvt, KiTTY, Serial, or any of the other Electron based terminals like Magnesium or Hyper?
That's not to say people shouldn't try as there are many reasons to do so. To suggest that opinions are somehow less valuable than yet another implementation of a terminal emulator written in a bloated framework based on a language that was designed in 11 days just to animate web page elements - and that people should reinvent the wheel or shut up... well that's just like, your opinion, man.
>What terminal emulator problem will be solved that hasn't already been solved by urxvt, KiTTY, Serial, or any of the other Electron based terminals like Magnesium or Hyper?
Well if you clicked the link, you would see a number of original features, including html output support. And i don't think it's fair to say that modern javascript is the same language as the one Brandon Eich designed in 11 days.
But if you think that constitutes 'feedback' -- that wouldn't be my definition.
>If people don't want feedback, then they shouldn't post on HN.
Which is what i generally suggest people do -- not because they don't want feedback, but because most people would simply lose motivation when the majority of people react to the glimmer of the word 'electron' and don't bother to click the link or check out the features.
And you can replace 'electron' with anything really. If somebody writes something in Java, there is a good chance some people will react saying that the JVM is evil or how Java is a horrible enterprise language. If somebody writes something in PHP, they'll get the PHP is a horrible language. If somebody writes something in C, they'll get a 'C is too insecure'. If somebody writes an OS-X app or a Windows app, they'll get feedback about how they picked the wrong OS.
It's feedback in the same way that fat shaming a classical pianist would be feedback. If the same 'feedback' can apply to millions of projects without alteration or requiring any effort to establish whether it's applicable -- that is not feedback, that is just taking the piss on something.
I'm sorry. I don't think i phrased it well enough. I thought this project was quite interesting, because it has interesting new features -- things radically different from the alternatives. Whether those are good or bad ideas could be an interesting discussion.
Instead, it's a thread full of people who didn't actually check it out, but abuse the opportunity to repeat a knee-jerk reaction to electron. It's just feels like going to a concert and instead of people talking about whether they liked the music or not, they just default into fat shaming the singer or something to make themselves feel better about themselves.
>So the only feedback that is permissible is adulation?
I guess we differ on what constitutes 'feedback' -- i didn't see much in this thread that would qualify as such.
> If you use this project, you're using it to experiment with a new way of working with the terminal, not to get screaming fast GPU accelerated screen rendering.
Screaming fast GPU accelerated screen rendering _is_ a new way of working with the terminal IMO. All hail alacritty. That's the kind of innovation I support. Trying to max out RAM and CPU for a slightly better looking UI is not something I am even going to consider trying out.
But why does this come up every time? When one puts a thing online for others to use, there will be responses, some positive, some negative. Nothing to be scandalised about.
Also, speed and resource useage is a valid concern. Some comments say that it's practically unusable on modern hardware, and on my laptop which is 7-8 years old, I can't touch this when it comes for linux (non that I would, but) because Electron is just too heavy for my computer, and I'd rather not use it than replace my device.
I agree with this. Also, I think that if this (Electron-based apps) keeps getting the type of attention it has been getting (people who are used to web technologies using it for native apps), it will push on Google and hardware manufacturers to start optimizing this stuff more and more. If eventually Electron apps run blazing fast and take miniscule amounts of CPU (not to mention CPUs will continue to get better and faster and more efficient), wouldn't it be better for everyone? I think this kind of stuff is innovative and keeps pushing the boundaries, so I'm all for it.
Tried it again today, replacing urxvt+zsh for an hour or so. Most of these problems are probably due to the fact they use a custom shell:
- ctrl-r (history search) just reloads the electron window and clears everything [0]
- does not work with virtualenv (bin/activate just messes up the shell to the point where even `ls` stops working – `Black Screen: command "ls" not found.`) [1]
- weird tab completion
- none of the "advanced" shell features work over ssh (well, that's expected, since ssh starts a standard bash/zsh/whatever shell on the server)
- had to install bunch of additional npm deps [2] to make it start on Linux
- `tmux` is less broken that it used to be when i first tried it, but still not without any problems, same for `htop` and `vim`
- it reports that some built-in commands are present, but they don't work at all (eg. print, source) [3]
Yeah, implementing a new terminal emulator (and a custom shell!) is pretty rough going. I've heard the idea expressed that it's hard to get programmers to use a new code editor, even if you have a killer feature, because they need to see every feature that's ever been implemented in every old editor before they'll switch. Reminiscent of Light Table.
Those are basic features, not "every feature". Black Screen needs to have basic features before it can be considered usable. Besides, it's macOS only, so I won't use it any time soon.
Here is my quick wish list of features I think I would use at least weekly if my terminal included them.
- jump to previous commands.
You just ran a command that printed a few pages, you want to scan from the first line. You have to scroll up and find the last prompt, where you typed the command. Why isn't there a shortcut for this?
Hmmm, were there any warnings in the build I just ran? Anything on stderr? Let me toggle stdout / stderr after the command has been run.
- connect a pipe to a previously run command
You run a computation that takes a minute and produces a few pages of output. You realize you want the output sorted. So you run it again. You could pipe to sort, or if you piped to a file you could cat the file next time you needed the output. But why can't you re-use the output that is there in the terminals scrollback buffer?
> You just ran a command that printed a few pages, you want to scan from the first line. You have to scroll up and find the last prompt, where you typed the command. Why isn't there a shortcut for this?
macOS's Terminal.app has this. Key shortcuts can jump between prompts (or between marked lines if you want to press a key combo to mark arbitrary lines), and can also select all text to the previous/next prompt (so you can trivially copy the output of a command).
> Hmmm, were there any warnings in the build I just ran? Anything on stderr? Let me toggle stdout / stderr after the command has been run.
Potentially interesting, but I'm not sure if it can actually be done. Both stdout and stderr are connected to the pty; can the pty meaningfully distinguish which connection is stdout and which is stderr? Also, what happens if stdout and stderr get mixed in the same line? You can't really collapse that.
I thought hyper was supposed to be the terminal for the 21st century, It looks like another one of
"why not make a terminal that takes up hundreds of MB of ram because we have plenty."
I will wait for Alacritty, and will ditch iTerm2 for it. I just need super minimal and fast terminal with true colors, that's all (although I hope Alacritty won't go super minimal as they intended to in beginning)
And I am all for that, since i have configured and used tmux for a more than 5 years now. But what bummed me a bit is copy/paste handling (they think it should be handled by tmux, which is one of the tmux' weaknesses imho)
I'm totally with you. I haven't managed to get tmux copy paste to behave like I'd like it to, so I have a bind to toggle the mouse on or off, then use the alacritty functionality to copy. It's clunky to say the least. I hope alacritty eventually implements something like holding shift and dragging enables mouse selection (like gnome shell).
Shouldn't be any other way. Modularity is such a nice idea. Much nicer than spinning up something that takes 600 MB of RAM in components not necessary to completing the task at hand.
Maybe if electron's dependencies could be compiled down to the minimum functionality needed by a given application this could work.
As far as Alacritty is concerned, modularity can easily come with a cost.
once you add in e.g. tmux for multiplexing and scrollback, then you are bottlenecked at tmux's speeds, as opposed to the terminal emulator's speeds (not like it really matters, but its an interesting effect)
That will be interesting for the tmux (or do we go all the way to nurses??) developers, because tmux has probably always been way faster than any terminal emulator it has been running in.
URxvt has tabs, via some sort of plugins. There are (at least) two "Perl extensions" for it.
urxvt -pe tabbed
# or
urxvt -pe tabbedex
Tabbedex needs to be installed, it has more features than `tabbed` (which is bundled with rxvt iirc), eg. tab renaming and moving. Looks like this: https://vgy.me/S1j8Re.png
That feels like such a cop-out. The tab paradigm is widely adopted and it seems strange for a terminal developed in 2017 to aim for xterm's feature set :)
At least the core developers should provide the default tabbed wrapper on top of it.
But who knows, maybe it will be successful even without tabs.
IMHO a modern terminal should render things on OpenGL surface. If done well this should be quite lightweight but at the same time could allow some amazing rich terminal apps. Something like "give me this 30x10 region and I'm going to render whatever I want in it"
I could type "df --HISTORY 7 /filesystem" and it renders a graph showing the last 7 days utilization. Yeah, df would need to change.
Or we could write "thumbnail babes.jpg" and it renders it directly in the terminal instead of popping up another window.
Or if I'm wanting to do some scripted image editing it'd be pleasant to be able to render images directly into my terminal as I work out the specifics of my task. As opposed to writing to temp files and then viewing them with a separate viewer.
Personally though what I want from a terminal emulator is something integrating into SSH which creates an out of band channel from the remote end of my ssh session to the terminal emulator. This way I don't have to play stupid games with shell prompts and the like, programs could literally know that a data path to my screen is available and do things like change background colors if I've changed users. Messing around with prompts and shoehorning too much stuff into escape sequences is awkward.
The command line interface is nice for advanced users as it's like programming. But for normal computer users that just want to get shit done, a GUI is much better. For GUI I recommend using a window manager and a large dedicated desktop monitor. You can have your image in one GUI window app, that auto reload the image when the file is updated. And have the code editor in another window app.
Here's what's been bugging me lately about electron apps. They often take disproportional amounts of ram compared to what they do/have to offer. Common response is that it's not an issue because ram is plentiful and even if my terminal takes 500 mb of ram that's not an issue because I have 8 gb or 16 or whatever. Yes, but if this trend continues soon we'll end up with electron based text editor, music player, terminal, 2 - 3 chat apps, git browser, etc. etc. That starts to quickly add up and I don't feel like buying more ram just because it's cheap. RAM is cheap but so is a trip to the zoo and given the choice I'd rather go to zoo than buy more ram.
Spotify is close but not actually an Electron app, although it does use the Chromium Embedded Framework on-top of a C++ core and modules. Basically, only the view is web-based.
I'm 100% with you on this, but the real problem is that, while maybe RAM is relatively cheap, the most common computers today, laptops, cannot be arbitrarily upgraded!, and any developer who ignores that is just not doing you a favor.
> if this trend continues soon we'll end up with electron based text editor, music player, terminal, 2 - 3 chat apps, git browser, etc. etc.
I can imagine at some point the runtime, being so popular, getting heavily optimized by some stakeholder. I already heard that there are some significant contributions from Microsoft. They had also did the same for node.js.
> and given the choice I'd rather go to zoo than buy more ram
While I generally agree with your comment, I personally like shopping for hardware much more than pitying caged animals.
That 500-700MB for an ordinary single application is already using heavily optimized electron. I do not think electron is some sloppily written piece of software. That monstrous ram consumption is just the effect of using browser framework for non-browser application. Nothing will change until people simply stop using electron.
You may be right, I don't know the internals of the Webkit. Then I suppose an alternative with an easy migration path would pop-up... or the supply of developers with good native experience would need to magically increase, which is very less likely to happen.
> or the supply of developers with good native experience would need to magically increase
Well one of the thing I notice despite all the new apps made with electron, none of them opened a category of new type of software which wasn't there before. It is just quickly made chat app, notes app, text editor and so on. So it is not that we need dramatically more native developers but to ask do we need 100 more apps of same type.
The only real benefit I see to Electron is it's finally delivering what Java promised, which is apps that run on all platforms from a single code base. Although, just like Java, they end up having non-platform-native UIs, and I imagine there's still some amount of platform-specific work you need to do (e.g. providing appropriate keyboard shortcuts on each platform).
Isn't this mostly true for Java already? I certainly recall downloading various applications bundled in .jar's and having them work fine on whatever platform I happened to be using.
I think people moved away from writing end-user apps in Java because they were bloated and slow and had ugly UIs, not because cross-platform development was super hard.
Can anyone comment on the relationship between memory usage and the number of windowed instances of Black Screen?
Right now I have 8 terminals open, some tabbed, some not, Sometimes I can have over twice as many. Many of them sit untouched on an Awesome workspace for days ready for me to come back to whenever I need them. This isn't a issue since their memory footprint is almost non-existent on pretty much any machine. Could I get away with this if I had to run an instance of Node + Chromium per terminal window? Is Black Screen one step ahead of me and it'll reuse an already running instance and open up another window? Do I want all my terminal instances to be managed by a single node process? Despite my reservations, still going to give this a go.
Eventually we may end up with shared system-wide electron instances, that are shared between all applications that claim they're compatible with said version. Kind of like Chrome tabs all share the same Chrome browser.
It's going to start with a browser based desktop ('not OS') and trickle down from there inception style. That way when we build a mirror out of raspberry pi we can CSS/js the calendar into the desktop background.
Unfortunately some people seem to have missed that this talk was labeled "comedy" and "absurdist", are actually trying to implement a JavaScript kernel. The talk just got the name wrong - it was "Electron", not "Metal".
I know it's an experimental project, but that's exactly the time to learn Ruby+Tk, or {anything}+Qt, or any of the other cross-platform toolkits. If you have to bundle an entire GUI server ("the browser") with your app to shoehorn HTML into use cases it wasn't designed for, you're doing it wrong.
"wrong" is subjective here. You could also argue that Ruby+Tk is "wrong" because Ruby is not as efficient as coding in C++, or C, or Assembly.
What we're talking about here, (and every time this comes up, again, and again, and again, over and over) is what shortcuts you're willing to take to get to MVP. There are a lot of Electron success stories out there, and when you're a solo dev starting out, and want to make a cross platform app, Electron is approachable and proven.
As far as I understand, there's nothing impossible in optimizing the internals of Electron while keeping more or less the same application-facing API. And if it's possible, it will get done, sooner or later - after all, Java had a reputation for being slow too.
It's definitely a band-aid, but has anyone tried ksm on linux with a web/electron-heavy desktop to see how much ram is duplicated across multiple instances?
Very nice. It's the best-looking terminal I've used, and I do like to use software that works but also looks good.
However, is considerably slower than iTerm2, which may or may not be a problem, and might be solved in future versions.
The deal breaker for me to use this version is that tab reordering doesn't work (doesn't work in Hyper, either).
It would be nice to be able to change the font size.
The real question I have is: why must we use Electron to create good-looking software? Can't iTerm2's UI be improved and be made to look like Back Screen or Hyper?
What do you mean by good looking though? If it's the color scheme or text font/size/color those can be customised in practically any terminal emulator(even Terminal.app).
People are bemoaning the use of Electron on this thread quite a lot, for a lot of different reasons. Rather than just complaining that "Electron == Bad" does anyone have any thoughts on why Electron is so popular, and how to use that information to come to a compromise that keeps those benefits without the inherent negatives of memory usage & speeds issue?
My two pence; A consolidated push of a React Native for Desktop seems like it could really help here. You get a lot of the benefits of working in a web-like environment (the developer experience, the development speed, the ability to share code across runtimes) but you end up with Native Code (Swift, C#, Cpp, etc.) for each supported OS. RN for Mobile OSs has done wonders in my opinion. I think a real push for RN in the Desktop could be the next big thing for desktop apps.
Perhaps if Javascript were used more like a traditional programming language? I.e. to build a terminal emulator, you find the JS library that binds to OpenGL or SDL or X or Cocoa or whatever, and you write JS code against that library, then compile it into a bytecode/binary.
> and how to use that information to come to a compromise
Electron is popular because it uses regular web tech to build apps. Electron is slow because it uses regular web tech to build apps.
Where is the compromise?
Another question is "popular with who"..
> the developer experience, the development speed, the ability to share code across runtimes
I don't know what you mean by "the developer experience", but surely any high-level language gets you speedy development, and architectural agnosticism?
A compromise would be to use Electron/Chromium as shared libraries so the bulk of those apps would be using the same 500 MB - nearly free lunch for users who would have Chromium running all day either way.
RN for windows is for UWP / store apps only. If you don't want to use the store, or want RN on windows 7 you're out of luck. I think even windows 8 might be off the table
I tried using this in my day to day for a short period of time. If you like GUI and native apps, it's a dream. If you prefer using things like Sublime or Kaleidoscope, over vim or the native difftool, Black Screen is what your workflow has been waiting for. It has native OSX text selection/manipulation, great (if a little wonky) autocomplete, easier directory browsing, the ability able to click to add files to git commits, notifications when long processes finish and several other nice touches.
The typical hacker news user probably isn't going to love this. It's certainly not as performant, and probably a slower workflow if you're someone that prefers to never let your hands leave the keyboard.
That being said, it's definitely not ready for full time. I ended up switching back to terminal for now, but I keep watching this closely.
Its unideal. Black Screen is certainly rough in the way that Atom was when it first launched. That being said, it feels more at home next to other OSX app then terminal which feels more like a window to the 80s
I don't care about whether it uses Electron or hundreds of MB or not. I'm just missing a real motivation for why I would want to use this, rather than the terminal I'm already using.
Main stated motivations appear to be "better looking" and autocompletion, which doesn't really sell it to me.
Yeah, those completions that show the documentation is something that shells like Fish already do out of the box. The terminal is not the right place to do this to begin with.
> We aim to be compatible at least with VT100. All the programs (emacs, ssh, vim) should work as expected.
At work, I use a VT100 cartridge for my Atari ST. It's not entirely VT100-compatible but I know for a fact that the vast majority of ncurses applications (not even to mention tmux) don't work and cause the terminal to be so corrupted as to be unusable.
Many applications rely on specific behaviours of newer terminals, so a better target would be xterm (or similar) compatibility. No one is targeting VT100 anymore.
vim-airline requires you to use a patched font that replaces certain little-used unicode characters with shapes that airline uses to draw its UI. Specifically, those < and > looking dividers in the airline statusline. Although it's totally possible to use airline without this and it will look only slightly less fancy.
They're not little-used unicode characters. They're code points in the Private Use Area, which is an area of Unicode that's explicitly set aside and will never be assigned to "real" characters, specifically so they can be used for custom things. vim-airline's use of the PUA for its custom glyphs is quite appropriate, it's just annoying that it requires a patched font.
Incidentally, the Apple glyph (, or ⌥⇧K on macOS), is actually in the PUA as well (in fact, it's the very last PUA codepoint, U+F8FF). Which is why it may not render correctly in fonts that don't ship on macOS. Anyone reading this on Windows, Linux, or Android probably won't actually see the apple character.
The author seems to be under the impression that that set of glyphs not in the ASCII set is somehow special. That is not he case for any reasonable modern OS. Your font rendering engine does not care whether its painting a or a F or a . As long as it knows how to draw the glyph it will, and if it doesn't it will make one up.
If your browser could not draw the tub and pantheon above chances are neither would black-screen. The author seems to be an accomplished coder, but I can't see how the magic of JavaScript will make teaching your font engine how to paint a glyph go away.
It's not the font-rendering he's taking exception to. His argument seems to be that UI elements like the chevrons and icons in vim-powerline shouldn't be rendered using fonts at all. They currently are because traditionally terminals only have text-rendering to work with, but it's clear he'd rather have that UI be HTML instead.
I suspect that the author means you should just use graphically drawn elements rather that special characters that sort of look like what you want. Since electron is based on a browser, you could inline images and other graphics along with the text.
As terminals are basically text-only, to display symbols that powerline uses you have to create a font containing those symbols overriding some of the characters in it.
The major issue with terminal emulators like hyper, is that they don't take care of all the bazillion tiny edge cases that traditional terminals have had to deal with over the past.. don't know, 30 years? How do I know that this thing is stable enough to be a daily driver?
No, alright, but I've seen several complaints from people trying out hyper, and getting exceptions/errors on a daily basis. I can't imagine black screen being any different, especially because it is newer.
I have hyper installed. I think it's fantastic. The only reason I don't use it is I usually open a terminal through VS Code but hyper doesn't open in the correct directory.
Looks very nice, however I tried running find that prints a very long list of files, and the terminal just got stuck after a while. Printing a huge number of lines without freezing or slowing down is a must for me in a terminal. Otherwise looks like something I'd use!
You closed the page immediately after learning that it has been built with Electron? Thanks for letting us know. The ideas are nice indeed, but stating that doesn't make your comment add anything to the (potential) discussion.
Electron is a memory-hog and I see how the trade-offs it does wouldn't suit an application which is likely to keep running in the background with multiple instances, and stating that would be much more constructive IMHO.
Let's hope author/poster doesn't close the HN tab immediately after seeing your comment :)
I don't understand your concern. Does anyone read my comment and think that I think that I represent the HN readers? I doubt it, but, I'm sorry if that's the case. Do you want me to admit it that single sentence was sarcastic? Well, yes it is but I explained myself in detail afterwards. It's neither a dismissal nor lacks content. Your objection to sarcasm in this instance would be unwarranted. Also then, this means your first reply is snark itself.
>You closed the page immediately after learning that it has been built with Electron? Thanks for letting us know. The ideas are nice indeed, but stating that doesn't make your comment add anything to the (potential) discussion
Well, what I implied was: I don't think this will go anywhere as long as its tied to Electron.
It might be OK for exploration of the UX space, but not for any kind of practical everyday terminal replacement (and I've used the one in VS Code).
Its perfectly reasonable to stick with a conclusion once you reached it. You don't stick your penis in the blender every time you walk through the kitchen to check whether or not its still as unpleasant as before. At some time you may actually commit to accepting the evidence. Having a open mind should not stop you from learning.
"I left the restaurant because they used blenders" vs "Blender is unsuitable for preparing {insert dish name} for {reasons here} therefore I don't order it in that restaurant which uses blenders while preparing it". I expect the second from a HN comment.
Also, if it's that obvious, why are there many people up-voting this and even then, why would you keep stating the "obvious"? Do you think the scenario you described, written as a "how to blend..." article, would attract attention here?
Electron is more like the cheapest professional blender that is very fast and gets the job mostly done but leaves some pieces intact. It's a very bad idea to use it in a five-star kitchen where your customers would complain about even the plate arrangement. It's totally fine to use it in a Kebab shop to prepare garlic sauce.
Electron is to semi-technical+ users as Beats headphones are to audiophiles.
> Electron is more like the cheapest professional blender that is very fast
I think it is a blender that does same thing what most other blenders do but consumes 10 times more power. However it comes in 100s of colors so cool people like this innovative product.
It's electron. You're running a fully fledged Chrome instance(which at this point might as well be another full OS) in order to run a terminal emulator. This also means that it probably comes bogged down with all the shit which infests modern web development [1].
It also appears to take over lots of the autocomplete/history functions from BASH, which also means it will either not play nice with ZSH or carry over that functionality when used with ZSH.
Going over the screenshots there also appear to be a bunch of hand populated options/descriptions(unless it's auto filling based on man) which would take away a lot of the modularity.
Also, it appears to be coded in Node and the Read Me mentions Visual Studio, and REE M$ and all that comes in.
No web developers are developers as much as people doing development on other platforms. That's not the case. Running a browser for terminal access is just not acceptable.
While I don't like seeing people flame op for making a choice of technology, electron boils down to a trade-off between the developer's convenience and the end user's computing power. I think it's pretty reasonable for the users to not like that prospect.
