Live data from Hacker News

HyperTerm – JS/HTML/CSS Terminal

hyperterm.org

111–120 of 267 posts

Re: HyperTerm – JS/HTML/CSS Terminal

#111
imgcat[1] is one of my favorite terminal innovations as of late. I thought I'd take a long shot and see if it worked since that functionality seems like it would be simple for a browser-engine-based terminal to handle, but sadly no-go. I smell pull request.

[1]https://www.iterm2.com/documentation-images.html

Re: HyperTerm – JS/HTML/CSS Terminal

#112
post #88

"Builds for Windows and Linux are coming very soon" I can't wait. Anyone knows how I could build this on windows?

Follow the instructions from the GitHub page [1] the ones under the "Contribute" title, that will be enough for you. If you don't know how to work with a Node.JS project then wait for their official Windows release.

[1] https://github.com/zeit/hyperterm#contribute

Re: HyperTerm – JS/HTML/CSS Terminal

#113

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…

I can't agree more, There is no reason that editing text files would need a full web browser which is buggy and slow. Many of these javascript apps which are replacing native apps use 500mb of ram, at some point you will have 5-10 of these things churning memory and consuming battery life and cpu cycles. (Note Atom, HyperTerm, Chrome, Slack, and Kitematic is already 5 browser apps)

Re: HyperTerm – JS/HTML/CSS Terminal

#114

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.

Hey, I have a few issues with your attitude.

Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. The hard part isn't drawing characters to the screen (which is what HTML and CSS would help with), it's the VT100 parsing and logic, which can be written in...well, anything, really.

I would first like to point out that the HyperTerm OSX zip is 43mb, and the unzipped HyperTerm.app is 123mb.

Supporting exactly one OS: again, the OS specific bits aren't the hard part. Blitting characters to the screen is easy, and platform independence certainly isn't worth 123mb of overhead.

250k+ Node modules: The number of packages in a package repository is a poor metric for determining anything except the number of packages in the package repository. npm has tons of redundant or ill-maintained packages, and that's even before we discuss whether having a bunch of available packages makes a terminal better at all. In my opinion, it doesn't, and this circles back around to the fact that a terminal needs to be secure. I sure as hell don't want random unaudited code running in the same application that I use to administer systems.

Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here.

Can't open web pages locally: Why should a terminal do that? As a party trick? I don't want to stand in the way of improvement, here, but I also have no problem opening a separate web browser to browse the web.

Javascript hate: It's not hate when people bring up salient points. Just because the web platform is open and everybody is using it right now doesn't mean that it's perfect or above criticism.

Re: HyperTerm – JS/HTML/CSS Terminal

#115
post #43

Earlier quoted context omitted.

What did you lose enthusiasm for? commando or HyperTerm? I've been toying with the idea of a "teaching terminal" for learning the command line as well, and building off of HyperTerm seems like a good approach.

A teaching shell might be more important. Something like what Reason does for OCaml, but done for the the unix command line. Use the model of something like is common with a lot of MUD clients, all text input occurs in a field at the bottom (look at tinyfugue). Below that have a set of autocomplete hints. This would be filled in based off of common usage, and knowledge of binaries avialable in the path, knowledge of…

you're right this is probably better inside the shell. That'd make it more cross platform too.

I was thinking a different approach on how it'd work. Since the goal is teaching, I'd prepopulate it with support for really basic stuff like cat, ls, echo etc. And the bottom portion would be focused on teaching how these commands work and guiding through most common use cases. Then as the user advances, they could install new modules. Maybe they now want to start text processing so could recommend they install the grep, awk or sed modules and then begin taking those tools on.

Re: HyperTerm – JS/HTML/CSS Terminal

#116
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.

I can honestly say that I have never been inconvenienced even slightly by an application that takes up between 0 and 500mb on disk.

If it starts to get into the multi-GB range it can hurt to download, but below that it's all identical to me. If it means that i don't need to run a specific version of a library installed globally on my machine, and i don't need to manage a big chain of dependencies myself, and it runs on multiple platforms, i don't care if it's 1mb or 500mb, and i don't care how many copies of it I'm running.

My ssd has 60gb remaining on it after a few years of daily use and i haven't needed to worry about program space yet.

Re: HyperTerm – JS/HTML/CSS Terminal

#117
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.

This is definitely a trademark violation: http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4803:prh...

A rename is in order.

Re: HyperTerm – JS/HTML/CSS Terminal

#119

You guys just can't stop making cool stuff can you? now.sh, now-serve, micro.. I'm not the biggest Node fan, but these are really well done. Execution on these ideas has always been 10/10.

Guillermo is also behind Socket.IO, Cloudup, and organizes JSConf Argentina

Re: HyperTerm – JS/HTML/CSS Terminal

#120
As a long Konsole user, I wonder if it supports unlimited logging, how it will react to 500M of console backlog, what's up with scrolling/overflow at all?

In my experience, terminal is one of the trickest to get right under extreme conditions.

What's with tabs also? :)

Post reply on HN