Live data from Hacker News

HyperTerm – JS/HTML/CSS Terminal

hyperterm.org

101–110 of 267 posts

Re: HyperTerm – JS/HTML/CSS Terminal

#101

Earlier quoted context omitted.

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 ef…

>Instead I can make a terminal that's significantly more efficient and responsive ...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.

I don't know what imaginary language you are imagining that only runs on 1 os and doesn't have libraries in it's ecosystem.

Re: HyperTerm – JS/HTML/CSS Terminal

#102

This looks very well executed and really cool, but I'm honestly really tired of all the node/electron terminals. In its favor, this project looks a lot more clean and less opinionated than that 'Black Screen' monstrocity.

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)

Well for instance, Atom and VSCode have ~50ms (or ~49x) more input latency than editors written in C (source: https://pavelfatin.com/typing-with-pleasure/ )

But maybe we are willing to accept 50x worse performance and higher memory requirements and slower startup time because the language is nice and guarantees correctness....Well no, it is javascript, not Haskell or Lisp. So, what is the win here? Why have we collectively decided javascript is a good tool for making applications for the desktop?

Re: HyperTerm – JS/HTML/CSS Terminal

#103

Earlier quoted context omitted.

How about the fact that your computer now has three enormous copies of chromium on it for no good reason?

On my system, a long running Slack process uses about as much memory as a Finder window.

But what about power usage? Battery life is important.

Re: HyperTerm – JS/HTML/CSS Terminal

#104
Initial commit 15 days ago?? I think I'll hold off on any sudo commands or special permissions requested by the OS.

Looks super cool though. Seems like a no-brainer with Electron.

Edit: I take that back, since it largely leverages hterm by the Chromium team, looks like the real first commit was in 2011 or so.

Re: HyperTerm – JS/HTML/CSS Terminal

#105

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)

Well for instance, Atom and VSCode have ~50ms (or ~49x) more input latency than editors written in C (source: https://pavelfatin.com/typing-with-pleasure/ ) But maybe we are willing to accept 50x worse performance and higher memory requirements and slower startup time because the language is nice and guarantees correctness....Well no, it is javascript, not Haskell or Lisp. So, what is the win here? Why have we collec…

Well now when someone removes left pad from npm your whole terminal can break.

Re: HyperTerm – JS/HTML/CSS Terminal

#106
There was another project that's extremely similar to this posted a week or so ago, and it got a lot of flak for existing; I don't think very many commenters agreed with its existence (except, perhaps, as an educational exercise for the programmer).

That project was posted here: http://rungoterminal.com/

This, however, is executed and presented much better than that other project, and catered towards the correct crowd (web developers using Mac OS X). Although I would never use either, I think that it just goes to show that presentation is extremely important: these two terminal emulators could very well be the exact same implementation (or at least very similar), and far less people would use it because they've chosen the wrong demographic.

Also because of the clean presentation, it creates a perception that HyperTerm is executed more cleanly than Rungo Terminal, even if there are no facts to back that belief.

Re: HyperTerm – JS/HTML/CSS Terminal

#107
post #20

Earlier quoted context omitted.

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.

But if we are going to accept the computational inefficiency, what do we gain for it?

If our only answer, collectively, as developers, is the richness of the ecosystem, then perhaps we should be moving our time and energies to make a rich ecosystem in either a language/runtime environment that performs better (C/Rust/OCaml/Whatever) or one that encourages correctness and/or speed of development.

I know some people think javascript is the latter, and I can't prove them wrong, but I suspect that is not true.

Re: HyperTerm – JS/HTML/CSS Terminal

#108

Earlier quoted context omitted.

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 ef…

>Instead I can make a terminal that's significantly more efficient and responsive ...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.

Ooh, 250,000+ modules with an average of less than one active user, little to no documentation or tests, and which may or may not be trivial one-liners. Above all, any given module has at least one other module that provides that same functionality.

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.

Re: HyperTerm – JS/HTML/CSS Terminal

#110
post #100
post #85

Earlier quoted context omitted.

Thanks...followed the Wikipedia link to the Rob Cox demo video. Mind blowing to have an editor as an OS filesystem that can intercept OS events. If I hadn't spent the last 20 years learning vi I would grab a copy and give it a try.

Yeah, plan 9 did a lot of cool things and fixed many of Unix fundamental warts. Taking the "everything is a file" much further, and namespaces as a fundamental primitive rather than something bolted on afterwards, for starters. Alas, too little too late, it seems.

Inferno and Limbo improved upon it.
Post reply on HN