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.
HyperTerm – JS/HTML/CSS Terminal
101–110 of 267 posts
Re: HyperTerm – JS/HTML/CSS Terminal
#102This 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)
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
#103Re: HyperTerm – JS/HTML/CSS Terminal
#104Looks 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
#105Earlier 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…
Re: HyperTerm – JS/HTML/CSS Terminal
#106That 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
#107Earlier 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.
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
#108Earlier 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.
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
#109Re: HyperTerm – JS/HTML/CSS Terminal
#110Earlier 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.