36 ms·

Black Screen – Both a terminal emulator and an interactive shell

163 points by yankcrime 9y ago

coldtea 9y ago
>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.
- deleted 9y ago
  [deleted]
- nkkollaw 9y ago
  Why, though. I don't get it.
  - KevanM 9y ago
    Electron is the new devil?
    - huhtenberg 9y ago
      It's the new "let's store everything in XML" from the late 90s.
    - rs86 9y ago
      Electron and dynamic languages
  - H4CK3RM4N 9y ago
    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 http://idlewords.com/talks/website_obesity.htm
    - nkkollaw 9y ago
      Got it. So the problem is with "based on Electron", I though it was the beginning of the sentence.
      - H4CK3RM4N 9y ago
        It's basically a terminal for use with the modern web, which is bad.
  - lnx01 9y ago
    Perhaps OP doesn't like the idea of keeping an entire running Blink engine in memory just to have nice terminal features.
  - ionised 9y ago
    Electron is a hammer in search of nails
- egeozcan 9y ago
  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 :)
  - ageofwant 9y ago
    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.
    - egeozcan 9y ago
      "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?
      - coldtea 9y ago
        >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.
        egeozcan 9y ago
infogeek 9y ago
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."
nkkollaw 9y ago
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?
- H4CK3RM4N 9y ago
  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).
  - nkkollaw 9y ago
    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.
    - BugsJustFindMe 9y ago
      The path bar looks like powerline, which you can get without this.
    - Trd 9y ago
      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.
      - nkkollaw 9y ago
        Yes, I've used it in the past. I don't use it because '&&' is not available. I use it pretty often.
WatchDog 9y ago
Seems like the polar opposite of the other recent terminal emulator project to gain my attention Alacritty
umurgdk 9y ago
Dear hipsters, ITS DAMN KISS*NG TERMINAL. WHY THE HELL IT NEEDS DAMN HUNDREDS OF MBs OF RAM AND RENDERER PROCESSES AND WHATEVER CHROMIUM TAKES! WHAT IS THE POINT OF RUNNING A BROWSER TO ACCESS A TERMINAL! Thank you for listening my hatred. Yeah I'm just an another hater ^_^
- rs86 9y ago
  Because web developers are not real developers.
  - umurgdk 9y ago
    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.
- sctb 9y ago
  Please don't post like this here, it breaks the guidelines. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
Philipp__ 9y ago
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)
- nkkollaw 9y ago
  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.
  - bmon 9y ago
    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.
    - rs86 9y ago
      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.
      - nkkollaw 9y ago
        I wonder if Chrome providing a headless mode could somehow improve things.
        marcoms 9y ago
        Doesn't headless mode just mean rendering to a bitmap instead of a window?
        nkkollaw 9y ago
jaimehrubiks 9y ago
And there it comes the anti-electron army, prepare your shield.
- bmon 9y ago
  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.
  - matt4077 9y ago
    The developer's convenience is directly reflected in pace of development and accessibility for plugin developers, both of which users care about.
    - Chris2048 9y ago
      but it's short-term convenience, for a developer mostly familiar with web-tech.
dkns 9y ago
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.
- BugsJustFindMe 9y ago
  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.
  - golergka 9y ago
    They cannot be upgraded because ordinary users didn't actually ever upgrade them when it was even possible.
    - BugsJustFindMe 9y ago
      Why do you think the reason matters? It doesn't change anything.
- egeozcan 9y ago
  > 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.
akanet 9y ago
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.
- na85 9y ago
  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.
  - jsnathan 9y ago
    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.
    - Karunamon 9y ago
      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.
alfa07 9y ago
It's slow and doesn't scale for my use case (scroll back with 1m lines)
ryzawy 9y ago
The author claims that plugins like vim-airline are "misusing unicode characters", without an explanation. Can somebody here chime in?
- colordrops 9y ago
  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.
  - palunon 9y ago
    Which is basically what emacs powerline does. Without using all your RAM.
- iaml 9y ago
  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.
- Nyubis 9y ago
  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.
  - kevin_thibedeau 9y ago
    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.
  - eridius 9y ago
    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.
FloatingGhost 9y ago
but... why? Is a simple terminal not good enough? >An IDE for terminals but why!?
Grangar 9y ago
Looks interesting! I'll be watching this until Windows release.
ihaveahadron 9y ago
Why even us windows 95, it takes more resources than dos.
HalfwayToDice 9y ago
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?
deleted 9y ago
[deleted]
azeirah 9y ago
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?
- jazoom 9y ago
  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.
  - azeirah 9y ago
    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.
    - jazoom 9y ago
      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.
em500 9y ago
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.
coffeedoughnuts 9y ago
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.
- automathematics 9y ago
  Yes! Microsoft supports RN for Windows and Ubuntu made a Lib too. Apple hasn't spoken up but some fans are working on one...
  - roryisok 9y ago
    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
- Chris2048 9y ago
  > 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?
  - mcbits 9y ago
    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.
dvirsky 9y ago
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!
helb 9y ago
On HN 2 years ago: https://news.ycombinator.com/item?id=10176289 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 https://github.com/vshatskyi/black-screen/issues/260 [1] https://github.com/vshatskyi/black-screen/issues/94 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 https://github.com/vshatskyi/black-screen/issues/600
- akanet 9y ago
  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.
  - alexeiz 9y ago
    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.
ageofwant 9y ago
Also reminds me of this cool thing https://github.com/paradoxxxzero/butterfly https://github.com/paradoxxxzero/butterfly. Which, I personally have used to amaze and confound.
drinchev 9y ago
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 https://github.com/zeit/hyper
vorotato 9y ago
Call me when it does something a normal terminal doesn't. In the examples I don't see ANYTHING new.
- Trd 9y ago
  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.
- geodel 9y ago
  I think doing same thing but consuming 10 times more resources is kinda new. Though it is not the new I personally like.
GreaterFool 9y ago
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"
- z3t4 9y ago
  This sounds cool. Could you elaborate ? Like what is going to render whatever it wants ?
  - wang_li 9y ago
    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.
    - ymse 9y ago
      Terminology can render pictures and video in the terminal and uses OpenGL: https://www.enlightenment.org/about-terminology https://www.enlightenment.org/about-terminology
    - rkeene2 9y ago
      Sounds a lot like Mozilla's xmlterm :-)
    - 9y ago
rrggrr 9y ago
This is AWESOME. The type ahead support is terrific.
harrygeez 9y ago
This is actually pretty close to how I envisioned the terminal emulators of the future will be like. Shame it's based on Electron.
julianozen 9y ago
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.
- tjoff 9y ago
  "If you like GUI and native apps, it's a dream." Um? If you like native apps you probably despise anything Electron.
  - julianozen 9y ago
    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
KernlPanik 9y ago
Using Electron to make a terminal emulator is one of the most webshit things I've ever seen. Congrats
oblio 9y ago
A somewhat related question: is Electron modular? Could you build it without sound support, for example?
seniorsassycat 9y ago
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?
- sigjuice 9y ago
  Emacs shell-mode does the first one. The other two should be trivial for someone moderately proficient in elisp.
- gluggymug 9y ago
  >- 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.
- eridius 9y ago
  > 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.
irl_ 9y ago
> 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.

163 points by yankcrime 9y ago

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

deleted 9y ago
[deleted]
nkkollaw 9y ago
Why, though. I don't get it.
- KevanM 9y ago
  Electron is the new devil?
  - huhtenberg 9y ago
    It's the new "let's store everything in XML" from the late 90s.
  - rs86 9y ago
    Electron and dynamic languages
- H4CK3RM4N 9y ago
  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 http://idlewords.com/talks/website_obesity.htm
  - nkkollaw 9y ago
    Got it. So the problem is with "based on Electron", I though it was the beginning of the sentence.
    - H4CK3RM4N 9y ago
      It's basically a terminal for use with the modern web, which is bad.
- lnx01 9y ago
  Perhaps OP doesn't like the idea of keeping an entire running Blink engine in memory just to have nice terminal features.
- ionised 9y ago
  Electron is a hammer in search of nails
egeozcan 9y ago
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 :)
- ageofwant 9y ago
  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.
  - egeozcan 9y ago
    "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?
    - coldtea 9y ago
      >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.
      - egeozcan 9y ago

infogeek 9y ago

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

nkkollaw 9y ago

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?

H4CK3RM4N 9y ago
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).
- nkkollaw 9y ago
  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.
  - BugsJustFindMe 9y ago
    The path bar looks like powerline, which you can get without this.
  - Trd 9y ago
    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.
    - nkkollaw 9y ago
      Yes, I've used it in the past. I don't use it because '&&' is not available. I use it pretty often.

WatchDog 9y ago

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

umurgdk 9y ago

Dear hipsters, ITS DAMN KISS*NG TERMINAL. WHY THE HELL IT NEEDS DAMN HUNDREDS OF MBs OF RAM AND RENDERER PROCESSES AND WHATEVER CHROMIUM TAKES! WHAT IS THE POINT OF RUNNING A BROWSER TO ACCESS A TERMINAL! Thank you for listening my hatred. Yeah I'm just an another hater ^_^

rs86 9y ago
Because web developers are not real developers.
- umurgdk 9y ago
  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.
sctb 9y ago
Please don't post like this here, it breaks the guidelines. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

Philipp__ 9y ago

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)

nkkollaw 9y ago
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.
- bmon 9y ago
  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.
  - rs86 9y ago
    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.
    - nkkollaw 9y ago
      I wonder if Chrome providing a headless mode could somehow improve things.
      - marcoms 9y ago
        Doesn't headless mode just mean rendering to a bitmap instead of a window?
        nkkollaw 9y ago

jaimehrubiks 9y ago

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

bmon 9y ago
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.
- matt4077 9y ago
  The developer's convenience is directly reflected in pace of development and accessibility for plugin developers, both of which users care about.
  - Chris2048 9y ago
    but it's short-term convenience, for a developer mostly familiar with web-tech.

dkns 9y ago

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.

BugsJustFindMe 9y ago
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.
- golergka 9y ago
  They cannot be upgraded because ordinary users didn't actually ever upgrade them when it was even possible.
  - BugsJustFindMe 9y ago
    Why do you think the reason matters? It doesn't change anything.
egeozcan 9y ago
> 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.

akanet 9y ago

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.

na85 9y ago
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.
- jsnathan 9y ago
  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.
  - Karunamon 9y ago
    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.

alfa07 9y ago

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

ryzawy 9y ago

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

colordrops 9y ago
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.
- palunon 9y ago
  Which is basically what emacs powerline does. Without using all your RAM.
iaml 9y ago
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.
Nyubis 9y ago
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.
- kevin_thibedeau 9y ago
  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.
- eridius 9y ago
  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.

FloatingGhost 9y ago

but... why? Is a simple terminal not good enough? >An IDE for terminals but why!?

Grangar 9y ago

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

ihaveahadron 9y ago

Why even us windows 95, it takes more resources than dos.

HalfwayToDice 9y ago

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?

deleted 9y ago

[deleted]

azeirah 9y ago

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?

jazoom 9y ago
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.
- azeirah 9y ago
  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.
  - jazoom 9y ago
    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.

em500 9y ago

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.

coffeedoughnuts 9y ago

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.

automathematics 9y ago
Yes! Microsoft supports RN for Windows and Ubuntu made a Lib too. Apple hasn't spoken up but some fans are working on one...
- roryisok 9y ago
  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
Chris2048 9y ago
> 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?
- mcbits 9y ago
  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.

dvirsky 9y ago

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!

helb 9y ago

On HN 2 years ago: https://news.ycombinator.com/item?id=10176289 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 https://github.com/vshatskyi/black-screen/issues/260 [1] https://github.com/vshatskyi/black-screen/issues/94 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 https://github.com/vshatskyi/black-screen/issues/600

akanet 9y ago
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.
- alexeiz 9y ago
  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.

ageofwant 9y ago

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

drinchev 9y ago

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 https://github.com/zeit/hyper

vorotato 9y ago

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

Trd 9y ago
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.
geodel 9y ago
I think doing same thing but consuming 10 times more resources is kinda new. Though it is not the new I personally like.

GreaterFool 9y ago

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"

z3t4 9y ago
This sounds cool. Could you elaborate ? Like what is going to render whatever it wants ?
- wang_li 9y ago
  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.
  - ymse 9y ago
    Terminology can render pictures and video in the terminal and uses OpenGL: https://www.enlightenment.org/about-terminology https://www.enlightenment.org/about-terminology
  - rkeene2 9y ago
    Sounds a lot like Mozilla's xmlterm :-)
  - 9y ago

rrggrr 9y ago

This is AWESOME. The type ahead support is terrific.

harrygeez 9y ago

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

julianozen 9y ago

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.

tjoff 9y ago
"If you like GUI and native apps, it's a dream." Um? If you like native apps you probably despise anything Electron.
- julianozen 9y ago
  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

KernlPanik 9y ago

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

oblio 9y ago

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

seniorsassycat 9y ago

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?

sigjuice 9y ago
Emacs shell-mode does the first one. The other two should be trivial for someone moderately proficient in elisp.
gluggymug 9y ago
>- 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.
eridius 9y ago
> 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.

irl_ 9y ago

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