The moral of the story is that I hated having a terminal in JavaScript for a remote server, so I have no idea why I would want one for my local computer.
It was just the lack of full terminal support, and how if I wanted to add even the most basic of features, it would take thousands of lines of code (this was before things really took off and there were libraries for everything, not that it makes it too much better).
Instead I can make a terminal that's significantly more efficient and responsive, with a fraction of the amount of code, and without having to write any JavaScript, which is its own achievement.
...and that runs on exactly one OS, and doesn't support the 250k+ Node modules, and that doesn't support standardized plugins, and that can't open web pages locally...
JavaScript hate is so 2010.
Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. The hard part isn't drawing characters to the screen (which is what HTML and CSS would help with), it's the VT100 parsing and logic, which can be written in...well, anything, really.
I would first like to point out that the HyperTerm OSX zip is 43mb, and the unzipped HyperTerm.app is 123mb.
Supporting exactly one OS: again, the OS specific bits aren't the hard part. Blitting characters to the screen is easy, and platform independence certainly isn't worth 123mb of overhead.
250k+ Node modules: The number of packages in a package repository is a poor metric for determining anything except the number of packages in the package repository. npm has tons of redundant or ill-maintained packages, and that's even before we discuss whether having a bunch of available packages makes a terminal better at all. In my opinion, it doesn't, and this circles back around to the fact that a terminal needs to be secure. I sure as hell don't want random unaudited code running in the same application that I use to administer systems.
Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here.
Can't open web pages locally: Why should a terminal do that? As a party trick? I don't want to stand in the way of improvement, here, but I also have no problem opening a separate web browser to browse the web.
Javascript hate: It's not hate when people bring up salient points. Just because the web platform is open and everybody is using it right now doesn't mean that it's perfect or above criticism.
So you prefer one written in ... C? Because C is secure by design? <rim shot>
Coding a terminal in Rust or even Go would be awesome, I admit...
>Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here.
See the demo animation for a (silly yet awesome) example.
>250k+ Node modules
Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
>It's not hate when people bring up salient points.
>>>without having to write any JavaScript, which is its own achievement.
The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. His other points were that, in the past, he had written a JavaScript terminal as a school project that he ended up hating, it took him thousands of lines of code, and he'd done it before Node existed to provide the batteries. What salient points do you actually refer to?
I'm not really disagreeing with you about the terminal: Honestly I will keep my lighter terminal with tabs and good UI for most real uses. But I love to see people innovating; providing extendable architecture is the way we get great new features.
Maybe there's no killer feature in this one to justify the extra weight, but neither do I see the need to pile hate on it because JavaScript; even less because they had a bad experience in school writing a JavaScript project that was similar.
You missed the point. A program that is 2,500,000 lines of code of interpreted JavaScript, and was written by some guy in a few weeks who pulled in hundreds of unaudited third party libraries, is definitely less secure than a 100,500 line C application that has been slowly developed, improved, and audited for some 25 years or more.
>See the demo animation for a (silly yet awesome) example.
A plugin is inherently not "standard" if it does not work on terminals other than the one it's designed for. Zsh has many plugins, albeit not "standard", and almost definitely fulfills all of the functionality you could want out of this project.
>Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
As said before, I don't want to do really cool things with CSS and HTML _in my terminal_. That's what I use a proper browser, IDE, or other functional-specific application for. And even if I did want a program that did absolutely everything, I'd rather use Emacs than some random NodeJS terminal emulator somebody wrote.
> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate.
JavaScript is objectively a bad language, and to simply say "JavaScript hate is so 2010" is a cheap redirect of actual criticisms of the language. (And no, I don't think ES6 makes it that much better, although at the very least it becomes bearable that way.)
JavaScript is not objectively bad. I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up.
It's objectively not perfect, but then most languages have problems. There are a few regretful mistakes in the design, but they can be worked around by using programming style decisions enforced by a linter.
JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.
Most of what sucks about using JavaScript is dealing with the DOM and browser differences in DOM implementations, but that's not JavaScript, that's just dealing with multiple browser platforms. Which you don't have to do in Node or Electron.
>"JavaScript hate is so 2010" is a cheap redirect of actual criticisms
No, it was a cheap comeback at substance-free hate directed at the language. If you want to argue details, read JavaScript, The Good Parts (or watch the YouTube video of the same name), and get back to me with what parts of JavaScript are actually, objectively bad. And in order to meet the "objectively" threshold, be sure to cite studies, because otherwise it's just your opinion.
Let me be clear here: JS is not really any better or any worse than any other interpreted languages. Yeah, I can name a few language-level problems (whoever decided that Promises should silently eat exceptions was wrong), but the big problems are not unique. Things like awful numeric performance (I've done crypto in JS), horrible multithreading support (Python and Ruby have GILs so it's roughly the same thing), etc etc.
The difference is that JS/web programmers seem to be the only ones saying that things written in their language and platform of choice (JS/HTML/CSS webapps, inside or outside of Electron) are the future everybody wants. Like the ego-stroking whenever somebody posts a new Node or Electron tool that had no reason to be written in JS except that the developer just didn't want to use another language isn't weird. Like 123mb for a terminal emulator isn't ridiculous.
Javascript brings nothing to the table except that it's the only language you can use for web programming. Nothing.
The execution model is awful as well, since apparently in order to get any sort of decent performance in a webapp these days you need to maintain a shadow copy of the DOM just so you can hack around the browser's layout engine.
> JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.
30 years programming experience and you want to compare an interpreted language to a naïve C implementation? Come on. Did you see the Python libuv asyncio implementation that is 2x faster than the equivalent code running in Node [0]? Python, using Node's own supporting libraries (http-parser also) is better than Node at Node's own game.
[0]: http://magic.io/blog/uvloop-blazing-fast-python-networking/
> I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up.
Although please come back when this becomes a true statement.
That sir is uncalled for.
So, if Javascript hate is "so 2010," is C hate all the fashion now? If you're going to get on somebody's case for trashing a programming language than you might as well practice what you preach.
C certainly isn't secure by design, but there are plenty of demonstrably secure projects developed in C and C++ (and it's not like Node is self-bootstrapped, either). To answer your question, yes, I would prefer one written in C. Any day of the week.
> Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
Dragging along such a massive runtime environment is such a heavy cost for that, though. And, again...in a terminal? I'm not judging every since Electron app, right now, I'm just judging HyperTerm.
> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. His other points were that, in the past, he had written a JavaScript terminal as a school project that he ended up hating, it took him thousands of lines of code, and he'd done it before Node existed to provide the batteries. What salient points do you actually refer to?
Honestly? Parent didn't make any. I'm just tired of people defending programming languages like they're more than just tools. It's fine to hate tools. Obviously this person's JS hate is coming from an informed place, because they've written a fair chunk of it.
How do you feel about the 'eshell' mode in emacs? I think it's neat because it's basically a normal shell plus an elisp REPL.
I imagine a terminal emulator with access to a large library of functions (such as a trusted subset of npm modules) could be useful.
Meanwhile, plenty of other languages run on many operating systems, have standardized library behaviour, and can trivially ask the operating system to open a file:// uri.
In practice this means that you can often find a module that does exactly what you want.
I find that most modules have great test coverage, and I've found it easy to contribute to several high profile projects in the Node ecosystem. The concept of trying to contribute to, say, Boost, makes me cringe. I would just assume that anything I suggested would be killed or mangled in committee discussion, and this despite the fact that I have a friend on the committee. [1]
95% of the modules I'm using are either relatively high profile build tools or they have TypeScript definitions in DefinitelyTyped, which has a much more modest ~1800 modules. Still I've occasionally needed obscure functionality and have been able to find appropriate libraries for it.
[1] Actually, don't know if he still is, but when I was in closer touch with him it seemed like an unapproachable task.
At some point you reach a maximum load and the structure becomes too brittle; the materials and process chosen dictate what that maximum load is. Corollary, they dictate how difficult it is to quickly throw together a simple walk path.
52,477 downloads in the last day
335,554 downloads in the last week
1,448,740 downloads in the last month