Live data from Hacker News

HyperTerm – JS/HTML/CSS Terminal

hyperterm.org

61–70 of 267 posts

Re: HyperTerm – JS/HTML/CSS Terminal

#61
post #19

The folks who make HyperTerm might have something to say about your product naming... http://www.hilgraeve.com/hyperterminal/ Edit: I'm surprised more people in the HN crowd aren't familiar with HyperTerm (Yes that is the name and what everyone called it for many many years) It was bundled with Windows up to 7, and is still used heavily in industrial control areas.

I also thought of hyperterminal.

HyperTerm is what I called it (because I'm old).

Re: HyperTerm – JS/HTML/CSS Terminal

#62
post #20

Earlier quoted context omitted.

I'm curious why there's so much node/electron negativity circulating. (Although I guess asking for positivity when it comes to electron is a bit of a stretch :P)

They're slow, big, and outrageously inefficient. Most electron apps also come with this weird web influenced "I'm kinda native y'all trust me" UI design which makes it even worse. My battery and eyes simply can't stand the things.

Interesting. I haven't experienced the slowness of Electron apps. And outrageously inefficient doesn't really matter to me if it's efficient enough for me not to notice any slowdown.

Re: HyperTerm – JS/HTML/CSS Terminal

#63
post #31

A while ago I wrote something similar to this as a school project, but instead of being a local terminal, it was for a remote server. There was a sort of virtual file system the user interacted with, with metadata stored in MySQL, as one does for school projects. 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.

I'm curious why you hated the fact that it was in JavaScript? Was it because it ran in the browser? Because this one probably can, but it runs natively by default as far as I can tell.

It wasn't really the browser. In fact the fact that it even ran in a browser was pretty cool.

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.

Re: HyperTerm – JS/HTML/CSS Terminal

#64
post #54
post #40

Earlier quoted context omitted.

My Visual Studio Code app is 138MB. On the grand scale of things, I'm not that worried about multiple copies of Chromium.

Electron by itself weighs in around 100mb. iTerm2 is a packed to the gills with features terminal that is 13mb.

My iTerm process is using about 170mb of memory, though that's admittedly less than half of what Slack is using. Big picture, with 8gb of ram, this is not a problem.

Re: HyperTerm – JS/HTML/CSS Terminal

#65
post #16

Earlier quoted context omitted.

I believe it has to do with the amount of performance lost in the overhead with the electron stack versus a native implementation. Please correct me if I'm wrong.

For the majority of applications, I'd imagine there's a negligible performance difference. Besides, any app built on Electron will run infinitely faster than one which wasn't built at all since the developer didn't want to learn another language. I'm not saying Electron is suitable for everything, but I think it has its place.

> negligible performance difference

Using Atom or VS Code instead of Emacs cuts my battery life by a few hours. The Spotify desktop app that uses a ton of JavaScript is also horribly inefficient and has a big impact on battery life.

None of this is negligible.

Re: HyperTerm – JS/HTML/CSS Terminal

#66

Earlier quoted context omitted.

I think a good terminal emulator is far from trivial. Edit: I'm not sure I do know what you mean. I agree that building trivial apps in Electron probably doesn't make sense. But my terminal emulator is something I spend most of my day using. If building that on top of 14 million lines of C++ gives me a better piece of software, I'm all for it.

Does it though? iTerm2 is the most feature-rich terminal I've ever used, and even then it's several orders of magnitude smaller then Electron (cloc says it's around 111K lines of Objective-C, with around 38K more lines split across Python and C++).

Maybe it's not better. That wasn't really my point though. I'm just saying that LOC is a fairly useless metric for evaluating software. Especially from an end user perspective.

Re: HyperTerm – JS/HTML/CSS Terminal

#68
Anybody remember TermKit[0]? This was my first thought when I saw "JS/HTML/CSS Terminal". It was built on WebKit (five years ago, before the everything-in-JS craze really began) and had a lot of really promising features like smart MIME-type support... and then development sort of stopped.

I'd love to see the concept revisited with present-day technologies and platforms.

[0]: https://acko.net/blog/on-termkit/

Re: HyperTerm – JS/HTML/CSS Terminal

#69
post #12

Earlier quoted context omitted.

OS X comes with a built-in terminal (that's actually pretty good). There's no reason for a beginner to reach for any third-party terminal software.

Besides iTerm2 maybe. Default config is very similar to the built-in OS X terminal.

I would not recommend iTerm2 to a beginner. The iTerm developers believe in the kitchen sink approach to preferences, which is not very beginner-friendly. And there's not much reason to use iTerm2 in general anyway now that Terminal.app has mouse support, I'm only aware of a few relatively esoteric features that iTerm2 has that Terminal doesn't (support for colors outside of the 256-color palette, and built-in support for showing tmux panes as iTerm window splits).
Post reply on HN