Black Screen – Both a terminal emulator and an interactive shell | Hacker News Reader

Black Screen – Both a terminal emulator and an interactive shell

github.com

163 pointsyankcrime163 comments

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.

From the README.md:

> 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?

But what extra features does this actually provide? According to screenshots, it has:

* a popup menu * colored background lines * another popup menu

well that's not exactly innovative (a popup menu for argument completion is available in fish today without eating RAM like Chrome)

It probably poses some benefits for terminal beginners, such as helping designers use git for instance in a UI more welcoming than the standard term.

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

Emacs has had both shell completion popups (via Helm) and a better git UI (magit) for a number of years now.

"I can't work with this, because it's too slow" isn't resource cyncism. It has some neat ideas, but I can't use it as a terminal emulator.

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)

So many people miss this. This project (and many others like it) wouldn't be faster without Electron. They flat out wouldn't exist.

If people don't want to use Electron apps then don't, but don't fill every single discussion of an Electron app with the same old whining.

>I'm not suggesting that at all.

My mistake, then.

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.

So the only feedback that is permissible is adulation?

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.

I would agree with you if the link's README wasn't so cocky

On HN 2 years ago: https://news.ycombinator.com/item?id=10176289

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]

Plus it's kinda slow. Terminals are hard.

[0] https://github.com/vshatskyi/black-screen/issues/260

[1] https://github.com/vshatskyi/black-screen/issues/94

[2] `npm install fs-vacuum init-package-json npm-install-checks npm-registry-client read-installed`

[3] https://github.com/vshatskyi/black-screen/issues/600

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?

- collapse previous outputs (stderr / stdout / both)

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.

    >- jump to previous commands.
    >You just ran a command that printed a few pages, you want to scan from the first line.

I think tmux might get you there. You bind a key to enter copy-mode and backward search for your particular prompt.

    >- collapse previous outputs (stderr / stdout / both)
    > Let me toggle stdout / stderr after the command has been run.

That sounds like a good one.

    >- connect a pipe to a previously run command
    >... But why can't you re-use the output that is there in the terminals scrollback buffer?

Once again tmux could "save-buffer" to a file for you if you did that backwards search then copy to a paste buffer. Just bind another key.

Emacs shell-mode does the first one. The other two should be trivial for someone moderately proficient in elisp.

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)

Alacritty is so fast. It's amazing.

It has a few problems though, like I keep selecting text by mistake. Also, no tab support?

At the end of the day, I think iTerm2 is a good balance between speed and functionality.

Alacrity is intended to be used with a multiplexer like tmux, at least for now. I doubt you'll see tab support any time soon, if ever.

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.

Where will the bottleneck be?

I ain't too sure, but

https://www.reddit.com/r/programming/comments/5mflek/alacrit... The Terminology (another light-weight term, with memory goals, that has scrollback) developer's comments are here

I wonder if Chrome providing a headless mode could somehow improve things.

Doesn't headless mode just mean rendering to a bitmap instead of a window?

No, but it's usually used to take screenshots and stuff like that.

It means rendering without the UI from what I understand.

It's designed to be used urxvt-style, where the core has just enough features to allow other programs to build that kind of stuff on top of it.

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"

This sounds cool. Could you elaborate ? Like what is going to render whatever it wants ?

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.

Terminology can render pictures and video in the terminal and uses OpenGL:

https://www.enlightenment.org/about-terminology

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.

Sounds a lot like Mozilla's xmlterm :-)

Using Electron to make a terminal emulator is one of the most webshit things I've ever seen. Congrats

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.

>electron based text editor, music player, terminal, 2 - 3 chat apps, git browser

So... Atom, Spotify, Black Screen, Slack & Discord, GitKraken. "Soon" is now.

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.

Well, a chain is only as strong as its weakest link. And Spotify is a bloated monster and a disgrace just because of "only the view".

+1 You beat me to it.

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.

They cannot be upgraded because ordinary users didn't actually ever upgrade them when it was even possible.

Why do you think the reason matters? It doesn't change anything.

> 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).

> finally delivering what Java promised

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.

On a side note, anyone looking for a slightly more useful shell that is still very lightweight: check out fish: https://github.com/fish-shell/fish-shell

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.

Then someone will come up with ElectronOS.

And then someone will write a web browser for Electron, and then someone will make that browser headless. Electrons all the way down!

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.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

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.

> 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.

Wouldn't shared resources lead to security vunerabilities between electron apps(genuine question, not something I've really looked into at all)

Depends on the implementation, but I'm sure it's possible to do it safely. Chrome already has most of the necessary tools https://www.chromium.org/developers/design-documents/multi-p....

Question is how much memory would actually be saved.

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.

I also like the zoo.

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?

You can't buy more RAM in most small laptops anyway, and even big ones have limits.

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?

> considerably slower than iTerm2

Why is a terminal emulator slow at all? Why aren't they subject to the same "give me 60hz or die" prejudice as games?

I wonder if someone should setup benchmarks against an actual Wyse green-screen terminal.

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).

The thing I like the most is the path bar. I also like the design of the space where you enter commands.

Autocomplete by default is also very nice.

Look & feel is not just colors, but a lot of small details that make the UI look good and polished.

The path bar looks like powerline, which you can get without this.

apt install fish

chsh

Now you have those completions, documented and all, in all your terminals, whether it's Konsole, Gnome-Terminal, St, Terminator or the linux tty.

Yes, I've used it in the past.

I don't use it because '&&' is not available. I use it pretty often.

Instead use:

    command1; and command2

More info: https://fishshell.com/docs/current/tutorial.html#tut_combine...

It's not the same thing.

; executes the following command even if the first one fails. && only if the previous command returns 0.

Not when used with and. And and or verify if the previous command executed. It says as much in the documentation linked by OP.

So you can do things like: runthiscommand; and echo "Success"; or echo "Failed"

> It's not the same thing.

Oh but it is! Read the link!

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.

That basically already exists.[0] The only major issue is that they're limited to the permissions of normal webpages in the browser.

[0]https://chrome.google.com/webstore/category/apps

Chrome apps are being discontinued on most OSes, so they recommend migrating to Electron or NW.js if a normal web app or extension won't work. https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...

Yes! Microsoft supports RN for Windows and Ubuntu made a Lib too. Apple hasn't spoken up but some fans are working on one...

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

Seems like the polar opposite of the other recent terminal emulator project to gain my attention Alacritty

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.

"If you like GUI and native apps, it's a dream."

Um? If you like native apps you probably despise anything Electron.

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.

Call me when it does something a normal terminal doesn't. In the examples I don't see ANYTHING new.

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.

I think doing same thing but consuming 10 times more resources is kinda new. Though it is not the new I personally like.

Although I'm not a huge fan of electron as well. I really like the creativity behind this project.

Btw, there is another electron-based popular emulator called hyper[1].

1: https://github.com/zeit/hyper

> 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.

The author claims that plugins like vim-airline are "misusing unicode characters", without an explanation. Can somebody here chime in?

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.

My understanding is that the *lines are using custom glyphs for box drawing characters along with icons in the PUA. All legit use of Unicode.

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.

Which is basically what emacs powerline does. Without using all your RAM.

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.

This is actually pretty close to how I envisioned the terminal emulators of the future will be like. Shame it's based on Electron.

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?

30 years later and many terminals still don't protect against sneaky code execution, just to give one example. It seems time doesn't fix everything.

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!

Also reminds me of this cool thing https://github.com/paradoxxxzero/butterfly. Which, I personally have used to amaze and confound.

It's slow and doesn't scale for my use case (scroll back with 1m lines)

Looks interesting! I'll be watching this until Windows release.

>Black Screen is an IDE in the world of terminals. Strictly speaking, it's both a terminal emulator and an interactive shell based on Electron.

And that's where I closed the page. Though the ideas are nice.

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 :)

> Thanks for letting us know.

Who these "us" you are referring to?

As the old saying went back in Fido/BBS times - "unlearn to speak for everyone".

> Who these "us" you are referring to?

"Us", here, refers to the HN readers.

> As the old saying went back in Fido/BBS times - "unlearn to speak for everyone".

I didn't say that we all thank the author. In that sentence, the person who is thanking is me, let alone the whole thing being a figure of speech.

That sentence is a snark gratuitously attributed to more than yourself.

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.

I'm with you. It's an obnoxious habit that people have picked up on news aggregators, to publicly make an announcement that they closed a page.

Heh, I'm with you (though I've made the announcement).

But I really don't see much potential in Electron for any kind of heavy app. And even if it was acceptable, I'd still prefer it to be native.

>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?

>Also, if it's that obvious, why are there many people up-voting this and even then, why would you keep stating the "obvious"?

Just because something is obvious, doesn't mean people also consider it obvious.

So, one reason to "keep stating the obvious" is to inform those people.

Well then you are expected to explain why it is obvious, which is what I'm suggesting in the first place.

But isn't resource-bloat something that poisons any application?

A blender that emitted harmful radiation would be unsuitable for anything too.

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.

Why, though. I don't get it.

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.

[1] http://idlewords.com/talks/website_obesity.htm

Got it. So the problem is with "based on Electron", I though it was the beginning of the sentence.

It's basically a terminal for use with the modern web, which is bad.

Perhaps OP doesn't like the idea of keeping an entire running Blink engine in memory just to have nice terminal features.

Electron is a hammer in search of nails

Electron is the new devil?

It's the new "let's store everything in XML" from the late 90s.

Electron and dynamic languages

A somewhat related question: is Electron modular? Could you build it without sound support, for example?

Enough about RAM and CPU. Let's talk about BATTERY LIFE.

Why would I run a terminal app which drains my Macbook battery three times as fast as the default app?

This is AWESOME. The type ahead support is terrific.

And there it comes the anti-electron army, prepare your shield.

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.

The developer's convenience is directly reflected in pace of development and accessibility for plugin developers, both of which users care about.

but it's short-term convenience, for a developer mostly familiar with web-tech.

Reply on news.ycombinator.com