HyperTerm – JS/HTML/CSS Terminal

  git clone git://git.suckless.org/st
  cloc --quiet st
  http://cloc.sourceforge.net v 1.60
  T=0.09s
  (45.8 files/s, 56588.2 lines/s)
  ------------------------------------
  Language   files blank comment code
  ------------------------------------
  C            1      497  253    3654
  C/C++ Header 2       40  124     313
  make         1       13    2      45
  ------------------------------------
  SUM:         4      550  379    4012
  ------------------------------------

[ed: Actually, this get even more extreme for the terminal I actually use everyday, sakura[1]:

  apt-get source sakura
  (cloc sakura)

Gives a total of 2490 lines of code, of which 2380 are C, the rest is CMake, make and Bourne Shell... that is cheating of course, as sakura uses libvte: which clocks in at ~45K lines of C - and a total of ~103K loc all together. Still a far cry from millions of lines of code...

[1] https://bugs.launchpad.net/sakura ]

>Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator.

So you prefer one written in ... C? Because C is secure by design?

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.

I was talking more about how it affects end users. Understandability of the code and dependencies are irrelevant in this case. Load time is important, but LOC is only a proxy for that metric. It's not totally unreasonable to imagine a well-written app with twice the code start faster than a poorly written one.

>Above all, any given module has at least one other module that provides that same functionality.

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.

> So you prefer one written in ... C? Because C is secure by design?

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