I tried to use this but got stuck when i opened up vim with NERDTree, it wouldn't expand folders...
HyperTerm – JS/HTML/CSS Terminal
91–100 of 267 posts
Re: HyperTerm – JS/HTML/CSS Terminal
#92It definitely looks cool, but may I ask what's the problem that is being solved here? Does it support tmux or at least window splits?
Which problems does this solve that the regular Terminal didn't solve? I'm kind of lost here, "I need some fireworks while I type in my terminal" is not a problem that I have often to be honest.
Re: HyperTerm – JS/HTML/CSS Terminal
#93Earlier quoted context omitted.
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 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.
Re: HyperTerm – JS/HTML/CSS Terminal
#94Hopefully this inspires someone to make a Lua/Python scriptable terminal. I'm not a big fan of the web stack. This is a pretty cool concept though.
ES6 fixes most of my biggest problems with JavaScript as a language, and adds a few things I didn't think of, but are nice. Generators, destructuring assignment, nicer class syntax, etc. I found this series of blog posts helpful: https://hacks.mozilla.org/category/es6-in-depth/
Sure, there's still a lot of old code out there to read, but I would guess this project is using mostly modern patterns. Most Node projects do.
Re: HyperTerm – JS/HTML/CSS Terminal
#95Earlier 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.
I think he meant inefficient in terms of battery power.
Re: HyperTerm – JS/HTML/CSS Terminal
#96Earlier 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 have any skin in this but I don't understand what it means for a terminal to "support the 250k+ Node modules," or any of the features you listed, honestly
Re: HyperTerm – JS/HTML/CSS Terminal
#97Earlier quoted context omitted.
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.
> I'm just saying that LOC is a fairly useless metric for evaluating software.
That's just not true.
Most open-source people want to be able to read, audit, fix, and (if it comes to it) maintain other people's code. 14+ million lines of code make this virtually impossible. (To be fair: Electron-based apps aren't the best example for the point I'm trying to make.)
Rate of change is another very useful metric.
Re: HyperTerm – JS/HTML/CSS Terminal
#98It definitely looks cool, but may I ask what's the problem that is being solved here? Does it support tmux or at least window splits? Which problems does this solve that the regular Terminal didn't solve? I'm kind of lost here, "I need some fireworks while I type in my terminal" is not a problem that I have often to be honest.
my guess is "a terminal that a person who is more comfortable with html, js and css than bash will like"
I must say, using basically a css stylesheet to control how your terminal looks and behaves does feel a lot more user friendly than a PS variable.
Re: HyperTerm – JS/HTML/CSS Terminal
#99The 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.
Oh wow that's a blast from the past. I don't think I've used that in 15 years.
But yeah, like yourself, the first thing I thought of when I saw this title was that old Windows terminal.
Re: HyperTerm – JS/HTML/CSS Terminal
#100Earlier quoted context omitted.
It was an editor for Plan9. Here you go: https://en.wikipedia.org/wiki/Acme_(text_editor)
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.