Meet Hyper.is – the terminal written in HTML, JS and CSS Zeit, a San Francisco-based software startup, has released the 1.0 version of Hyper, a terminal emulator written in JavaScript, HTML, and CSS. Why? Well, why not? Hyper is based on Electron, an open source framework for creating cross-platform desktop applications using HTML and JS. Developed by GitHub for its Atom text …
May have been an interesting exercise for the author, but for practical use I don't see any point at all. Terminal windows are one application where the performance must be good (sluggishness eats into you productivity in a very concrete way), and no bloat because a power user often keeps dozens of them open at any given time. And it is anyway a solved problem. Until last year, I used xterm for these reasons exclusively, but then reluctantly moved to Xfce4-terminal because xterm does not handle clipboard interactions with Windows when running in VM very well. Xfce-terminal solves this and is almost fast enough. (And can also open web links from selected text, if you want that kind of thing...)
Thanks for this link. I stopped using Atom within a few weeks of its release because of it being slow as balls, but it is wonderful to see the many stages of developer-data-theft-denial.
"Oh it's totally minor, why do you care?"
"You're getting a free product, stop complaining!"
"Microsoft and google already know who you are! They get to do it, why shouldn't we?"
"Look, we've got a legal team and we're sure a company like ours wouldn't do anything illegal"
"We spoke to the lawyers. It'll be removed tomorrow."
Atom and Visual Studio Code already have terminal plugins. They do what they say on the tin.
A standalone terminal app might require some menus of its own to manage tabs and provide the functionality someone might get from ConEmu, gnome-term or whatever but the main work is already done.
That said, a GOOD terminal can be a godsend. I use ConEmu all the time because it offers ANSI highlighting, cut / copy / paste, tabs, search and a bunch of other stuff that I wouldn't get from cmd.exe. I could see how a developer's terminal application which also happened to be cross platform could become popular.
If I take a look at a project and see that the only use case they imagined for a tech demo is a cursor particle spray, I'm not very impressed with the project.
Oh, they can also open URLs you say ? Wow, Lynx has been able to do that since 1997.
Nope, still not impressed.
Based on HTML and JavaScript ? Now that's impressive. You've created a platform that replicates every other browser in existence. Here, have a lollipop.
It's a application framework that happens to be built on NodeJS and other web technologies. It's not a browser per se although it uses an embedded browser engine to drive its UI. The benefit is somebody writing a plugin or function for the app only has to do it once and providing it has no platform dependencies it will install and run anywhere.
It's not a radical new concept. Mozilla was doing this a decade ago. Firefox, Thunderbird, Seamonkey, all of the plugins plus a bunch of external projects such as xpcshell used JS, CSS, XML to develop apps in.
Congratulations, web people! You can now do with JavaScript and CSS on your Web Browser what we could do on our PCs in the 1990s with native applications. This is surely progress!
You can now read e-mail, open menus, play solitaire, watch movies, and even chat on a Web Browser! Soon you may even be able to do some serious work on it, just like we did on PCs at the turn of the Millenium. Innovation!
dZ
... particulary since it allows you to make simple web applications much simpler and therefore much more secure, adding the bloat of multiple libraries and frameworks kinda eliminates the effort.
What would make sense would be a "DOM-Terminal" standard. A simple protocoll which turns the browser into a terminal you can send commands to, to modify your document tree.
It's now 11 years since I wrote Anyterm, the first terminal-on-a-web-page:
http://anyterm.org/
There are some demos there, but you'll probably crash it if you all try at once.
It's open-source (GPL) and still maintained - I just added IPv6 support a few days ago.
For those of you asking "why", the main answer is so that people who find themselves behind an http-only firewall can still do command-line stuff on external machines.
My implementation was largely constrained by the technology available at the time (and the code still has lots of work-arounds for hopefully long-since-fixed browser bugs). It should be much easier to do today if you start from scratch.
Clicking the live demo link gives me a 503 error.
> For those of you asking "why", the main answer is so that people who find themselves behind an http-only firewall can still do command-line stuff on external machines.
I think this could be practical if I needed to log in from a public computer but then how is key-based auth going to work? What if the network uses SSL Inspection to subvert your HTTPS? I would not want to do any server administration from public computers, but on my own devices it seems simpler to use standard SSH encapsulated in HTTP by way of corkscrew and the terminal environment of my choice.
I *would* consider using Anyterm if it were pitched as more of a web-based Mosh substitute, i.e. the web app maintains the connection to SSHd and secures it with cookie-based authentication so if the user is mobile and dealing with frequent disconnections it won't interrupt the SSH session. Just a thought, interesting project nonetheless.
Right now the bastet and adventure demos are working for me but nano is down.
They have deliberately low max-session limits...
I did consider doing persistent sessions, but on reflection I decided that it's better to do that at the next layer down i.e. using screen. Then configure Anyterm to invoke screen, rather than "ssh localhost". I should probably mention that in the docs.
There is no sensible way to do key-based auth. One-time passwords of some sort might be the best alternative. TBH it's fundamentally not well suited to situations needing more than modest security.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
