HTML + JavaScript + Electron
Just download that archive, extract its content, and you will find the "goterminal" script that is basically an ASAR archive [1] with a copy of CEF [2] as the webview for the web application that they (for some unknown reason) decided to create.
That's unpleasant. This is a forum for programmers. Care to explain why you are criticizing a participant for programming?
What an absurd, and disgusting, point of view. The author is free to create whatever the fuck he/she wants, for fun. It's not wasting anyone's time -- no one else is obliged to spend any time interacting with it in any way.
You should really reconsider your position. One point is that, while you may have the skills and experience to only work on projects that improve the status quo, many of us do not; and even those who do, as beginners had to pass through the stage where they did not.
flips over table
I am desperate for someone to come along and realize that the current terminal interface is a perpetual train wreck, and that if we can break compatibility but end up with something better we should.
Consider for a moment what a monumental task it is to make a simple ncurses menu and status bar in bash script. Consider for a second how trivial that could be made if each command line entry were a small flexible webview.
Imagine if you typed netstat and it showed the results, but there was also a field where you could key in text narrowing queries as part of the standard presentation for all very long input. No more appealing to grep or more and losing context or blasting your scrollback buffer.
Consider for a moment if we could move away from trivial line interfaces for SSH and towards a protocol that actually handles sessions and works over SSL in every conceivable network environment. Hell, most people I know have migrated to mosh and only type ssh when they're provisioning fresh cloud instances (usually to get mosh on there as fast as humanly possible).
The entire idea that "text is a superior interface" is correct as an input mechanism, but not necessarily as a data presentation mechanism. HTML and some basic es2015/typescript/whatever isn't just flat out better than bash for this sort of thing, but it flows from a long history of tools like tcl/tk trying to make the shell a more efficient and effective place to visualize trivial data.
I've been using terminals since 80 characters was a luxury and amber was the fancy new color, and for at least 20 of those years I've been hoping we'll see something that keeps the composability of shell scripting but introduces a non-line oriented protocol that could also offer presentation logic when appropriate.
We could preserve all of that if we just pretend all existing shell commands return a (forgive the templating syntax, it'll be understandable by a wide audience) Map<Stream<Text>> where {'stdout': <stdout>} and additional data can be offered around that with trivial API additions.
Please, let's not pretend we'd not benefit massively from richer tooling here.
Absolutely nothing about this project or the way they went about building it shows any tendency towards richer tooling. A web interface also does not inherently enable richer tooling. You could implement this non-line oriented protocol entirely without 500+ MB of JS and the interpretation of that data could obviously be done without it too.
Edit:
While I understand your rants all over these threads (it doesn't inherently have to be inefficient and bloated), you've picked a strange submission to take these fights in. The software in question is in fact bloated, not compliant and is really only an interface to aliases.
Also, I would add: The proof is in the pudding. You seem to have made this a personal crusade, so I would urge you to make a decent PoC with these ideas to show the world.
It really isn't, see e.g. whiptail.
And using ncurses for anything today is not a good idea. Surviving terminals are overwhelmingly ANSI, and can be supported by a single codebase that uses escape sequences directly, wihtout the horrors of ncurses.
Historically most terminal implementations have been fraught with performance issues. We'd moved off xterm to aterm and then back. We'd been hesitant to adopt gnome-terminal because of the GTK+ chrome then saw its font kit actually rendered faster.
What most people don't get is how absurdly well-optimized the text rendering and reflowing is for web browsers. With care, people can get modern cellphone browsers to hit 60fps animations and reflows while pushing huge volumes of text through them.
Take any 3 GUI toolkits you can name and ask yourself, "Do all three of these combined have a maintenance budget that equals that of even Firefox by itself, let alone any TWO modern web browsers?" Hell, some of the most cutting edge research into interpreters and garbage collectors is coming out of Google making V8 fast.
Quite frankly, I'd bet that with care and foresight this could be faster than iTerm.
There is also the matter that no matter how much optimization you put into something you can't recoup the cost of the fundamental design choices you went with. Choosing something with less power can solve a lot of headaches.
This was my creeping suspicion the moment I saw the screenshots. Utter garbage.
