Hello. I'm the author of Black Screen, and I'm upset this post has appeared on Hacker News. The terminal is at a very early stage; I don't even use it by myself. Although, it's nice to see that people show some interest.
Pretty cool looking project though, I have been thinking about something like this for a while now. The two biggest problems seem to be performance(I spawn throwaway shells all the time, so my terminal emulator need to open pretty much instantly), and fully compatibility(I use vim in the terminal as my main editor).
I'll be watching to see how it turns out.
By biggest concern is how to cat a 50MB file. If you try it now, everything gets stuck.
A new terminal/shell is a very hard sell, as I know from my own experience. Six years ago I wrote my own terminal/shell combination ( http://wiki.tcl.tk/23446 ). It works well enough that I've been using it myself full-time at work ever since, but although a few other people have tried it, no-one else ever adopted it. My own attempt is implemented in Tcl/Tk, an older but much lighter-weight framework (it has no problem with cat-ing a 50MB file).
I combined the functions of shell and terminal because I found the shell/terminal split made some of the functionality I wanted difficult or impossible. One example is that I colour text written to stderr in red - standard shells mix stderr and stdout together before the terminal even sees them.
I decided early on that I would not support terminal escape sequences. I set the TERM environment variable to "dumb" which tells well-behaved programs not to use escape sequences. So you can't run vi/vim in one of my windows, but I always use gvim so I don't find this a problem.
Similarly after some experimentation I decided not to use ptys as they created as many problems as they solved. So programs which change behaviour based on whether they are connected to a terminal behave as if running from a script. Eg. running "man command" lists the whole man page rather than trying to page it - but this is what I want since one can page up/down in the shell anyway.
However it seems that people who use a terminal get very attached to its idiosyncracies and will reject anything even slightly different. Since it's very difficult to make any real improvements without introducing incompatibilies, attempts at improving the terminal/shell user experience rarely catch on. In contrast, a few other tools I have implemented using the same technology have been adopted by a worthwhile user community at work. I think the difference is that they are used for more specialised tasks and don't require the user to change their everyday workflow.
Anyway, good luck with your endeavour!
. npm install black-screen
is far better t'han "install-all" for many reasons: better npm search, no namespace pollution, more semantic than such a generic name.
Please consider to change it.