HyperTerm – JS/HTML/CSS Terminal | Hacker News Reader

CSS Terminal

hyperterm.org

630 pointspandemicsyn255 comments

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.

That's "HyperTerminal" not "HyperTerm".

A very similar name for a product sitting in the same space (terminal emulator). That's generally an unwise decision as it can create confusion for both projects, and the one with the trademark (especially since this new one's name is a substring of the older project) is in a position to make a valid claim against the new project.

If someone created a new project called Steem to deliver video games to end users[, would you] be surprised if Valve took issue with their choice of name?

EDIT: Left out part of a sentence.

> if Valve took issue

isn't it true that companies have to take issue, otherwise they lose their trademark? I used to be angry when large corporations would sue a little guy or nonprofit over name squabbles, but then I heard that the big company can lose their trademark if they dont.

That's my understanding as well, yes.

For an example of this happening, "Aspirin" was originally a Bayer trademark registered in 1897.

I probably heard the same thing as you. With the whole Scrolls fiasco, I think. Someone explained Bethesda had to go after Mojang.

HyperTerminal was commonly referred to as "HyperTerm" in the BBS community, probably because the executable was hypertrm.exe. Also possibly because most other dial-up terminal emulators had names ending in "Term".

The free version was bundled with Windows for 10+ years, and although it wasn't a particularly great terminal, its ubiquity came in handy when trying to bring new people into the bulletin board system world.

Anyone remember this?

> On February 20, 2004, the developers of wxWindows announced that the project was changing its name to wxWidgets, as a result of Microsoft requesting Julian Smart to respect Microsoft's United Kingdom trademark of the term Windows. [1]

That being said, I think if MS doesn't ask them to change it, there isn't much to worry about. "wxWindows" was originally started in 1992.

[1]: https://en.wikipedia.org/wiki/WxWidgets

IIRC, Microsoft licensed Hyperterminal from a company called Hilgraeve (sp?). It was never an official part of Windows, although IMHO it should have been.

Regardless of who owns/owned the trademarks in whatever countries, it's not appropriate to reuse the name. It will lead to unnecessary confusion. Bad call, even if no lawyers get involved.

not the same name, but close. (I can't find the text "HyperTerm" on that page)

You sure? Because I can. http://i.imgur.com/3WnYw4H.png

Perhaps a rename to "HyperTermiML" is in order.

that probably wouldn't be different enough to satisfy a trademark infringement. you could easily make a case that those are confusable, and obviously similar types of products (both terminal emulators).

I know.

I also thought of hyperterminal.

HyperTerm is what I called it (because I'm old).

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.

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

A rename is in order.

This doesn't appear to be a commercial product, so there could be no trademark violation.

That's not how trademarks work.

15 U.S. Code § 1125 [0]:

    ...
    (3) Exclusions The following shall not be actionable as dilution by blurring or dilution by tarnishment under this subsection:
    
      (A) Any fair use, including a nominative or descriptive fair use, or facilitation of such fair use, of a famous mark by another person other than as a designation of source for the person’s own goods or services, including use in connection with    —

        (i) advertising or promotion that permits consumers to compare goods or services; or
        
        (ii) identifying and parodying, criticizing, or commenting upon the famous mark owner or the goods or services of the famous mark owner.

      (B) All forms of news reporting and news commentary.

     *(C) Any noncommercial use of a mark.*
    ...

Do you know of another section, subsection, or other that would validate your claim?

[0] https://www.law.cornell.edu/uscode/text/15/1127

That's exactly how it ought to work. I hope this gets noticed despite you being so heavily down-voted (and flagged... wtf?). I'd like to see it get properly refuted if it's not true.

This only covers trademark dilution which is one cause of action for trademark infringement, but not the only possible cause of action. Usually trademark dilution is argued when the products are dissimilar. In this case, they are not dissimilar. And as such, this is the regular definition of infringement and is not covered by 15 U.S.C. § 1125(c)(3). It falls distinctly under § 1125(a).

PS - You linked to 15 U.S.C. § 1127, but quoted 1125.

PPS - An overview of the difference between dilution and infringement: http://www.nolo.com/legal-encyclopedia/what-trademark-diluti...

Unfortunately HN didn't allow me to edit the comment. 1127 however contains the definition of many terms and I believe the same conclusion can be drawn from them (Trademark does not apply to noncommercial use).

Here is 1125(a):

    (1) Any person who, on or in connection with any goods or services, or any container for goods, *uses in commerce any word*, ...

As such, it does not apply in this situation.

Further, 1125(c)(3)(C) is an exclusion across the entire 1125 subsection (and yes, for dilution, which is what has been argued here).

https://www.law.cornell.edu/uscode/text/15/1125

RE: PPS

Your link says that infringement is a type of dilution. Therefore, no dilution means no infringement.

Also note my other response to this comment: 1125(a) explicitly only includes commercial use.

Again, the US government has only the authority to regulate interstate commerce (ie. trade [hence, trademark]).

Before UNIX was ported to the PC, I used a DOS program called Crosstalk Communicator.

Today it's so easy to run a small UNIX kernel on a PC.

Why would "industrial control areas" still be using Windows, if what they need is terminal emulation? Tradition? Windows-only software?

Windows on a networked computer sounds like a potential security hazard in such places.

Maybe they can get the domain name through UDRP.

32 bit windows XP was an RTOS. This is one of the reasons so many people where reluctant to leave it.

Windows CE can be a RTOS. XP is not.

https://msdn.microsoft.com/en-us/library/ms838350(v=winembed...

"Is Windows XP Embedded a real-time OS? Windows XP Embedded satisfies the vast majority of performance requirements. However, if you require a more powerful real-time support for your Windows XP Embedded OS, you can utilize one of the real-time extensions that are available through third-party vendors."

There are apparently third-party real-time extensions available, but if that counts then the existence of CONFIG_PREEMPT_RT makes Linux a RTOS and I think that'd be a pretty silly claim too.

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.

> "it got a lot of flak for existing"

Oh wow, you weren't kidding: https://news.ycombinator.com/item?id=12046778

These comments really make me ashamed of the HN community.

Anything related to javascript or web technologies brings out that kind of response in some way, but sometimes the HN crowd takes it overboard.

I appreciate that the HN community doesn't feel the need to sugar coat something that is obviously bullshit. If you don't want people to critique your work, don't post it on discussion forums.

Yet there is such a thing as a middle ground in criticism. I'm glad HN is not product hunt (a mix of "hey check my alternative product" and "hey that's amazing, best product ever, wow"), but the comments on that thread were harsh cheap shots taken at the author. Only a single commenter was able to provide constructive feedback, which is a shame.

Just because you specifically are okay with receiving harsh criticism doesn't mean that everyone is, or should be.

I didn't see the previous Go Terminal post but after trying it now, my immediate reaction is that HyperTerm is much more usable. For some reason, Go Terminal ignored some of my zsh configuration. It also took longer to start and seemed more sluggish overall.

Yep, the videos are hugely important. The first half of Go Terminal's is just creating aliases (which is easier to do without the fancy UI), and that's where I got bored and closed the page. This project actually showed some interesting things.

Still seems like a fundamental misunderstanding of what a terminal is for. I SSH into any number of boxes every day, be it on my RaspberryPi, client machines in AWS, crappy hosting providers, etc. The standard bash terminal is there on all of them, which can not be said of any project like this.

This is a 'terminal emulator' (client). So what you ssh into is irrelevant and Bash etc. are also irrelevant. This is a client you could ssh from (and use whatever shell you like, locally and remotely).

Your comment is a fundamental misunderstanding of what a terminal is for. Bash is not a terminal, it is a shell.

You interact with the shell through the terminal.

Old-school terminals were physical devices that had their own keyboard and CRT display, and were connected to the computer via a serial port. Modern "terminals" are actually terminal emulators (software that emulates the older hardware) that display the emulated terminal display on your screen. That might be your kernel's /dev/tty1 which displays the text by directly writing to the graphics card. Or, it might be a user-space application that displays it as a window in a graphics system; such as PuTTY[1], Terminal.app, iTerm, XTerm, gnome-terminal, or one of these projects.

[1] PuTTY is not just a terminal emulator, it is also an SSH client, among other things.

Anybody remember TermKit[0]? This was my first thought when I saw "JS/HTML/CSS Terminal". It was built on WebKit (five years ago, before the everything-in-JS craze really began) and had a lot of really promising features like smart MIME-type support... and then development sort of stopped.

I'd love to see the concept revisited with present-day technologies and platforms.

[0]: https://acko.net/blog/on-termkit/

Heh yes.

There was also a mozilla XUL based terminal many years ago - can't remember the name though.

XMLterm

The only article about is that I've ever found or read is this one:

http://www.xml.com/pub/a/2000/06/07/xmlterm/

XMLterm. DomTerm http://domterm.org was very much inspired by XMLterm. Please check it out.

Everything-in-JS started more than five years ago. Nine years ago (almost to the day) Atwood formulated his law [0].

[0] https://blog.codinghorror.com/the-principle-of-least-power/

He did a follow-up on Reddit explaining what happened:

https://www.reddit.com/r/programming/comments/137kd9/18_mont...

There are several projects working on this!

The biggest is Black Screen, but I've also got one and seen some others.

- https://github.com/shockone/black-screen - https://github.com/CGamesPlay/hterminal - https://github.com/sedwards2009/extraterm

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.

I'm a big fan of their markdown semi-renderer. Is that open source?

Yeah, I like that too. Just emailed them about it.

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

Just an idea: The only windowed applications I use are a terminal (st), my text editor (Atom), and a browser (Firefox). Suppose I switched to HyperTerm, Atom, and Chromium. I would have three copies of the Chromium renderer and V8 interpreter loaded in memory. Is there a project that merges these things into a single daemon, to improve individual app startup time, save memory, and reduce the binary size from 42 MB (for HyperTerm) to the size of only its own components?

All you have to do is enter a url and it will render web pages. It uses redux and lets extension developers modify any action basically letting them modify anything, so an extension that makes a nice browser is definitely possible. Also I'm sure you could embed Atom into it too. Basically my holy grail , an entire web dev environment in one app/window with tabs..

But you can already have this pretty trivially in emacs: http://puu.sh/q3hpW/2933a20e84.png

But then you are using emacs...

At least it's not written in Javascript.

You can also render full webpages using webkit: https://www.reddit.com/r/emacs/comments/4srze9/watching_yout...

Cool, I don't know if I really have a use for that though, I kinda like having the documentation I pull up match the color scheme of my code.

The moment when I saw Google render inside the terminal is when I went from "whatever" to "wow". My typical dev setup involves a fullscreen terminal (with Vim) and a Chrome window with various tabs. Furthermore, I usually place these in separate workspaces. But if I could effectively house my Chrome tabs within my terminal, that would be such a pleasure to use. Especially since switching workspaces on MacOS comes with an unconfigurable animation/delay.

My OS X Terminal is already slow enough with my 20 windows open... There's no way I'd switch to an even slower, bulkier implementation with the overhead of Chromium. WTF

Well, sure. That's what I was trying to fix with my suggestion. In that case, the overhead of HyperTerm could be the overhead of a Chromium tab, not an entire Electron application.

This is something I wish more effort was being put into. As more and more apps become V8-based, with each shipping completely separated, I wish there was some way to have them share resources. I know there are a lot of issues with this (different Node versions, possibly security, and figuring out inter-app resource sharing), but it would be magnificent for my computer's battery life. Does anyone know of any work being done on this front or a possible implementation?

A daemon? Pff, we need Chromium running in the kernel where it truly belongs.

They are all based on electron. It seems like a thing electron should do. I.e spit out binaries that use chrome and node in the system.

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 haven't even looked at "Black Screen", but what makes it a monstrosity? It is just a piece of open source software, after all.

In my experience, it's very slow and clunky, but the real problem is that it attempts to impose a lot of styling and decoration _on top_ of the terminal.

For example, the command prompt isn't just a command prompt, it has this silly chevron decoration with autocomplete functionality. It can probably be turned off in the settings, but I find it to be a really annoying default. It just assumes I don't have my own prompt how I want it or my own autocorrect system.

I have to explicitly disable half the 'features' before I get anything actually useful to work with.

I'm tired of node/electron anything.

I use two tools daily that are built on Electron and they are great. Not only that, but it's never obvious they run on Electron. I'm curious, what do you hate so much about it?

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

If you have the RAM for it and the software works well, who cares? Plus, it seems potential improvements are coming in this area.

https://github.com/electron/electron/issues/673

On the one hand side people complain that Turbo Pascal and WordPerfect (or even UNIX for that matter) worked extremely fast on an 386SX with 4MB RAM and that modern software eats hundreds of megabytes of memory and seems slower, without providing much new functionality.

This attitude (replacing a lean and fast terminal, by one rendered using a web browser engine) is exactly why modern machines that are 1000x faster and with 1000x the memory still seem to be slow for basic tasks.

Of course, it's a free choice. You can waste resources by replacing small programs by browsers ;). But it's reasonable that many people find it a waste.

> no good reason.

Well thats subjective. I might not be as cool as you but I get my work done using these tools.

I think he's saying you only need one version of Chromium on your machine to run all these tools.

How many copies of unix (partitions, vms, containers) do you have on your computer?

One?

TinyCore Linux is 12 MB. A fully functional Unix(-like) system, including an X server.

So, for one Javascript-written terminal app, you can install a full Linux system with X and a window manager 10 times (Hyperterm.app is 122 MB).

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.

My iTerm process is using about 170mb of memory, though that's admittedly less than half of what Slack is using. Big picture, with 8gb of ram, this is not a problem.

I have 6 terminals open right now and that's my baseline. I often go up to 12-15 terms.

Presumably, multiple tabs in this browser based terminal would only use one chrome process

Talking about seperate windows here.

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.

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.

I can't say I've measured it quantitatively, but it doesn't appear to have a huge effect, but I also don't need to be untethered all day long.

When I check the battery status on my Mac, only Chrome is listed in the "Apps that use significant energy" list.

On mac, slack uses macgap, not electron.

Was this a recent change? Because electron's homepage[0] still shows that Slack was built on it.

[0]: http://electron.atom.io/

On windows (and I guess on linux) they use electron.

Same as java maybe ? Lot of bad apps that make you feel the engine underneath

you can always ignore those projects if they make you so tired.

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)

There are more and more applications based on it -- negativity increases along with popularity.

Trivial apps depending on 14+ million lines of code is not a good thing.

Edit: @michaelmior I think you know what I mean.

I think a good terminal emulator is far from trivial.

Edit: I'm not sure I do know what you mean. I agree that building trivial apps in Electron probably doesn't make sense. But my terminal emulator is something I spend most of my day using. If building that on top of 14 million lines of C++ gives me a better piece of software, I'm all for it.

https://www.openhub.net/p/putty

Perhaps not as feature comlpete, and not my daily use terminal emulator, but it's only 110k lines of code. And it's not just a terminal emulator, that's just one thing it does in that 110k lines of code.

EDIT: I was going to look up others but I'm distracted by other obligations. My point being: Terminal Emulators aren't actually that complex.

I wrote a terminal emulator <https://github.com/adamdruppe/terminal-emulator> and use it daily so it is good enough for me at least... clocks in at ~15k lines (including the gui helper lib).

The biggest complexity is dealing with legacy terminals... and you can really just target the handful of xterm features programs actually use and get something working without a huge amount of code.

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 agree with you, with regards to the end user caring or not, but there aren't many tech-unsavvy people using terminal emulators on the regular. So when Putty and iTerm2 both weigh in between 100-200k LOC and this is in the 14m LOC space, it's difficult to not make the presumption that that's a lot for a terminal emulator.

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

How so? It affects load time, understandability, binary size, dependency payload...

I personally hate the load times. Node apps always seem to need to think for a second or too. Sublime Text v VSCode is pretty bad. Sublime Text v Atom is even worse.

When you're moving fast and in your flow, it gets to be really annoying.

I was talking more about how it affects end users. Understandability of the code and dependencies are irrelevant in this case. Load time is important, but LOC is only a proxy for that metric. It's not totally unreasonable to imagine a well-written app with twice the code start faster than a poorly written one.

  git clone git://git.suckless.org/st
  cloc --quiet st
  http://cloc.sourceforge.net v 1.60
  T=0.09s
  (45.8 files/s, 56588.2 lines/s)
  ------------------------------------
  Language   files blank comment code
  ------------------------------------
  C            1      497  253    3654
  C/C++ Header 2       40  124     313
  make         1       13    2      45
  ------------------------------------
  SUM:         4      550  379    4012
  ------------------------------------

[ed: Actually, this get even more extreme for the terminal I actually use everyday, sakura[1]:

  apt-get source sakura
  (cloc sakura)

Gives a total of 2490 lines of code, of which 2380 are C, the rest is CMake, make and Bourne Shell... that is cheating of course, as sakura uses libvte: which clocks in at ~45K lines of C - and a total of ~103K loc all together. Still a far cry from millions of lines of code...

[1] https://bugs.launchpad.net/sakura ]

Sure. I wasn't arguing that millions of lines of code are necessary for a terminal. Thanks for the pointer to Sakura though! I quite like it and I might have to give it a try :)

How many lines is the JDK? or .NET, or libcpp?

LLVM: 1.5 million (I assume libc++ is less than 500k)

OpenJDK: 6.8 million

.NET: 10.5 million

Source: https://www.openhub.net/

I agree, but I'd take it a step further - the 15+ million Lo(memory-unsafe!)C for the unix kernel other (all?) trivial apps sits on is also not a good thing.

I agree with your larger point (I think) but for what it's worth: Most of those 15+ million lines are drivers you don't use.

I believe it has to do with the amount of performance lost in the overhead with the electron stack versus a native implementation.

Please correct me if I'm wrong.

For the majority of applications, I'd imagine there's a negligible performance difference. Besides, any app built on Electron will run infinitely faster than one which wasn't built at all since the developer didn't want to learn another language. I'm not saying Electron is suitable for everything, but I think it has its place.

I still question Electron for "commercial quality" apps. The Electron runtime by itself is about 100mb. I've built an internal Electron app for work and for that it's absolutely fantastic.

> negligible performance difference

Using Atom or VS Code instead of Emacs cuts my battery life by a few hours. The Spotify desktop app that uses a ton of JavaScript is also horribly inefficient and has a big impact on battery life.

None of this is negligible.

On top of this, chrome/chromium versus safari is another 1-2 hours of battery. I think people vastly underestimate the energy requirements of web technologies.

On which OS?

On the other hand, my Emacs starts up in more than thirty seconds. To fully start up it needs to read some 2k loc of my own ELisp code and hundreds of thousands loc of required libraries.

I use Emacs as a Jabber client, Python and Clojure development environments, file manager, image and pdf viewer, HTTP server, spreadsheet and note-taking app and (polyglot) Literate Programming environment. And that's just the beginning of what it can be used for.

In other words, giving Emacs as an example of small and fast, natively written application is a bit unfortunate. Not to mention most of Emacs is written in ELisp, so the "natively" part is not even factually correct.

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.

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.

Electron means your app runs on Mac + Win + Linux without much effort. It could also potentially run on the web browser.

That is a huge sell.

I have tried to edit a file with a little bit of long JSON that came from a server (less than 50K) and atom completely froze trying to display it. This was two weeks ago. I've ditched Atom entirely.

> I'm curious why there's so much node/electron negativity circulating.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses".

--Bjarne Stroustrup

I'm pretty sure that applies to language runtimes as well.

> Although I guess asking for positivity when it comes to electron is a bit of a stretch

I like to stay current, and in this charged environment, I'd be shocked if anode runtime wasn't at the nucleus of every accelerator.

I'm sure Dijkstra is half-spinning in his grave.

Your puns are glorious!

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?

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

No it can't. After that whole fiasco npm has made it so packages once published cannot be removed after a 24 hour window without npm manually doing it on your behalf, that is to make sure this instance never does happen again.

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)

* We've decided to use JavaScript because the community is there. Go ahead and write an IDE in Haskell - have fun rewriting all the libraries that already exist in JavaScript and soliciting for open source contributions when a tiny fraction of all programmers can understand it.

I love Haskell and lisp, but you have to face the facts.

* TypeScript is actually a good language, and gives pretty darn good correctness guarantees.

* Your benchmark does not test against VSCode, which is much faster than Atom.

> * TypeScript is actually a good language, and gives pretty darn good correctness guarantees.

TypeScript's main focus is IDE tooling, not correctness. Here is an example on how generics are unsound in TypeScript: http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.htm...

If you want to write JavaScript with a type system focused on soundness, you should give [flow](https://flowtype.org/) a try.

I don't think that anyone argued TypeScript is 100% sound, nor is that a meaningful goal to hit. I find TS to be a solid language that gives me reasonable confidence in my code. (The tooling is also great!)

This makes me want to re-implemented "commando" from AUX/MPW (I've never understood why this idea didn't take off).

If you don't know, when you typed an ellipsis after a command in AUX or MPW a dialog box would be displayed showing the most popular toggles and options for the command (and allowing graphical file-picking). When you clicked "ok" it would type the command for you, so it made the command line both easier to use and easier to learn.

(I just downloaded and tried it out and lost my enthusiasm. There's no attempt to provide a proper GUI.)

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 the command line arguments of common tools (git-prompt.sh is really nice for getting my new-to-git coworkers started, for instance).

This could be wrapped up in the terminal, but needs to be aware of the environment in which it's being executed which moves beyond the purview of most terminal emulators and into the area of the shell itself.

EDIT: Rough ascii art illustration:

  +----------------------------------------------------+
  | > cat foo.txt                                      |
  | Hello, world!                                      |
  |                                                    |
   ////////////////////////////////////////////////////
  |                                                    |
  +----------------------------------------------------+
  | > ca                                               |
  +----------------------------------------------------+
  |cat | cac... | cal...| can...  | can... | cap...    |
  +----------------------------------------------------+

`cat` first because of frequency of use (in general) and recent use. Others are showing other matches of the currently typed value + one letter, ... indicating more than one option.

You'd want usage statistics on common commands, and you'd need to assemble a database of command line options. Might be able to grab these from man/info pages, but formatting is likely inconsistent. Could at least get started that way. And you'd want to collect the users history to customize it. This'd be equivalent to the hints on many mobile OS keyboards.

I could see this being pulled into the terminal, rather than the shell itself. But it'd still need information about the underlying environment (easy if local, hard if remote).

How do terminal emulators on tablets handle keyboard input? Do any of them offer guided hints?

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.

`fish` shell works a little like this.

You mention OCaml, so you probably are aware, but others may not be: there is an `utop` project, which does exactly this for OCaml REPL. It looks like this:

    ─( 16:36:52 )─< command 0 >───────────────────────{ counter: 0 }─
    utop #
    ┌───┬────────────┬─────┬───────────┬──────────────┬───────┬─────┐
    │Arg│Arith_status│Array│ArrayLabels│Assert_failure│Big_int│Bigar│
    └───┴────────────┴─────┴───────────┴──────────────┴───────┴─────┘

and supports syntax highlighting and autocompletion, among other features. Similar to bpython in Python-land.

Link: https://opam.ocaml.org/blog/about-utop/

> I just downloaded and tried it out and lost my enthusiasm. There's no attempt to provide a proper GUI.

That was always my take on Commando. In theory, there's an idea there. In practice, it's not clear who it was supposed to appeal to. If one has to mouse around, just provide a proper GUI wrapper for the tool.

I lost enthusiasm for hyperterm. Commando was awesome.

Can anyone comment on how this compares to Black Screen ? https://github.com/shockone/black-screen

Black Screen is a shell as well as a terminal. This is just a terminal.

How well does it deal with copious amounts of text scrolling across the screen. It's been a while since I've used it, but IIRC Gnome Terminal had big issues with this for a long time (due to the underlying library that they were using).

It's really bad. Not as bad as gnome-terminal back in the day (it's been fixed for a while), but it definitely can't keep up with a 'find /usr'.

(I'm running it on linux, ymmv).

This is bad ass job, congratulations. Like someone else mention in the comments, execution and idea you get 100/100 points.

A while ago I wrote something similar to this as a school project, but instead of being a local terminal, it was for a remote server. There was a sort of virtual file system the user interacted with, with metadata stored in MySQL, as one does for school projects.

The moral of the story is that I hated having a terminal in JavaScript for a remote server, so I have no idea why I would want one for my local computer.

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 efficient and responsive, with a fraction of the amount of code, and without having to write any JavaScript, which is its own achievement.

>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

The modules are there so you can add features and you have the entire Node toolbox at your disposal.

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.

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.

https://www.npmjs.com/package/open

https://www.npmjs.com/package/opn

    52,477 downloads in the last day
    335,554 downloads in the last week
    1,448,740 downloads in the last month

Not bad.

>Above all, any given module has at least one other module that provides that same functionality.

In practice this means that you can often find a module that does exactly what you want.

I find that most modules have great test coverage, and I've found it easy to contribute to several high profile projects in the Node ecosystem. The concept of trying to contribute to, say, Boost, makes me cringe. I would just assume that anything I suggested would be killed or mangled in committee discussion, and this despite the fact that I have a friend on the committee. [1]

95% of the modules I'm using are either relatively high profile build tools or they have TypeScript definitions in DefinitelyTyped, which has a much more modest ~1800 modules. Still I've occasionally needed obscure functionality and have been able to find appropriate libraries for it.

[1] Actually, don't know if he still is, but when I was in closer touch with him it seemed like an unapproachable task.

It reads like Javascript development is largely a process of cementing together small rocks; in contrast to development elsewhere, which is largely a process of mortaring together large bricks and/or building new framework.

At some point you reach a maximum load and the structure becomes too brittle; the materials and process chosen dictate what that maximum load is. Corollary, they dictate how difficult it is to quickly throw together a simple walk path.

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.

I tend to agree with all of your points.

How do you feel about the 'eshell' mode in emacs? I think it's neat because it's basically a normal shell plus an elisp REPL.

I imagine a terminal emulator with access to a large library of functions (such as a trusted subset of npm modules) could be useful.

>Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator.

So you prefer one written in ... C? Because C is secure by design? <rim shot>

Coding a terminal in Rust or even Go would be awesome, I admit...

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

See the demo animation for a (silly yet awesome) example.

>250k+ Node modules

Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.

>It's not hate when people bring up salient points.

>>>without having to write any JavaScript, which is its own achievement.

The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. His other points were that, in the past, he had written a JavaScript terminal as a school project that he ended up hating, it took him thousands of lines of code, and he'd done it before Node existed to provide the batteries. What salient points do you actually refer to?

I'm not really disagreeing with you about the terminal: Honestly I will keep my lighter terminal with tabs and good UI for most real uses. But I love to see people innovating; providing extendable architecture is the way we get great new features.

Maybe there's no killer feature in this one to justify the extra weight, but neither do I see the need to pile hate on it because JavaScript; even less because they had a bad experience in school writing a JavaScript project that was similar.

> So you prefer one written in ... C? Because C is secure by design? <rim shot>

You missed the point. A program that is 2,500,000 lines of code of interpreted JavaScript, and was written by some guy in a few weeks who pulled in hundreds of unaudited third party libraries, is definitely less secure than a 100,500 line C application that has been slowly developed, improved, and audited for some 25 years or more.

>See the demo animation for a (silly yet awesome) example.

A plugin is inherently not "standard" if it does not work on terminals other than the one it's designed for. Zsh has many plugins, albeit not "standard", and almost definitely fulfills all of the functionality you could want out of this project.

>Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.

As said before, I don't want to do really cool things with CSS and HTML _in my terminal_. That's what I use a proper browser, IDE, or other functional-specific application for. And even if I did want a program that did absolutely everything, I'd rather use Emacs than some random NodeJS terminal emulator somebody wrote.

> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate.

JavaScript is objectively a bad language, and to simply say "JavaScript hate is so 2010" is a cheap redirect of actual criticisms of the language. (And no, I don't think ES6 makes it that much better, although at the very least it becomes bearable that way.)

>JavaScript is objectively a bad language

JavaScript is not objectively bad. I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up.

It's objectively not perfect, but then most languages have problems. There are a few regretful mistakes in the design, but they can be worked around by using programming style decisions enforced by a linter.

JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.

Most of what sucks about using JavaScript is dealing with the DOM and browser differences in DOM implementations, but that's not JavaScript, that's just dealing with multiple browser platforms. Which you don't have to do in Node or Electron.

>"JavaScript hate is so 2010" is a cheap redirect of actual criticisms

No, it was a cheap comeback at substance-free hate directed at the language. If you want to argue details, read JavaScript, The Good Parts (or watch the YouTube video of the same name), and get back to me with what parts of JavaScript are actually, objectively bad. And in order to meet the "objectively" threshold, be sure to cite studies, because otherwise it's just your opinion.

I really don't feel like carrying on another JavaScript argument, so we'll just have to agree to disagree.

> I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up.

Although please come back when this becomes a true statement.

>Although please come back when this becomes a true statement.

That sir is uncalled for.

> It's objectively not perfect, but then most languages have problems.

Let me be clear here: JS is not really any better or any worse than any other interpreted languages. Yeah, I can name a few language-level problems (whoever decided that Promises should silently eat exceptions was wrong), but the big problems are not unique. Things like awful numeric performance (I've done crypto in JS), horrible multithreading support (Python and Ruby have GILs so it's roughly the same thing), etc etc.

The difference is that JS/web programmers seem to be the only ones saying that things written in their language and platform of choice (JS/HTML/CSS webapps, inside or outside of Electron) are the future everybody wants. Like the ego-stroking whenever somebody posts a new Node or Electron tool that had no reason to be written in JS except that the developer just didn't want to use another language isn't weird. Like 123mb for a terminal emulator isn't ridiculous.

Javascript brings nothing to the table except that it's the only language you can use for web programming. Nothing.

The execution model is awful as well, since apparently in order to get any sort of decent performance in a webapp these days you need to maintain a shadow copy of the DOM just so you can hack around the browser's layout engine.

> JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.

30 years programming experience and you want to compare an interpreted language to a naïve C implementation? Come on. Did you see the Python libuv asyncio implementation that is 2x faster than the equivalent code running in Node [0]? Python, using Node's own supporting libraries (http-parser also) is better than Node at Node's own game.

[0]: http://magic.io/blog/uvloop-blazing-fast-python-networking/

> So you prefer one written in ... C? Because C is secure by design? <rim shot> > Coding a terminal in Rust or even Go would be awesome, I admit...

So, if Javascript hate is "so 2010," is C hate all the fashion now? If you're going to get on somebody's case for trashing a programming language than you might as well practice what you preach.

C certainly isn't secure by design, but there are plenty of demonstrably secure projects developed in C and C++ (and it's not like Node is self-bootstrapped, either). To answer your question, yes, I would prefer one written in C. Any day of the week.

> Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.

Dragging along such a massive runtime environment is such a heavy cost for that, though. And, again...in a terminal? I'm not judging every since Electron app, right now, I'm just judging HyperTerm.

> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. His other points were that, in the past, he had written a JavaScript terminal as a school project that he ended up hating, it took him thousands of lines of code, and he'd done it before Node existed to provide the batteries. What salient points do you actually refer to?

Honestly? Parent didn't make any. I'm just tired of people defending programming languages like they're more than just tools. It's fine to hate tools. Obviously this person's JS hate is coming from an informed place, because they've written a fair chunk of it.

As an Acme user, I find the extensibility feature very interesting: Once you are used to Acme's contextual (and programmable) handling of text, it's hard to go back to a normal terminal.

Never heard of Acme -- can you elaborate?

It was an editor for Plan9.

Here you go: https://en.wikipedia.org/wiki/Acme_(text_editor)

It still is.

It also runs on Macos, Linux, Windows, and BSD.

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.

Russ Cox, not Rob Cox. You may be intermingling Rob Pike and Russ Cox, who are both involved in Acme.

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.

I tried to use this but got stuck when i opened up vim with NERDTree, it wouldn't expand folders...

I think it would be great if we could go beyond text in terminal applications. Think Jupyter notebooks but inside terminal. It would be great if terminal window was just an OpenGL surface that one could draw on, with good API for doing just text. Something as simple as "put this interactive plot in this 20x20 area there" would make a big difference for a lot of programs and scripts I'm writing. At the moment if I want something like that I pipe the data through websocket to the browser and that's OK but I'd rather stay in the terminal.

That is the goal of the DomTerm http://domterm.org project. I see little point in a JS-based terminal emulator unless you can "print out" graphics, images, or general HTML. DomTerm's goal is "full" xterm compatibility and embeddable graphics, rich(er) text, etc.

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

Gate One (web-based terminal) has had this functionality for years:

https://github.com/liftoff/GateOne/

Just 'cat someimage.jpeg' or 'cat someimage.png' and it'll display it right there in the terminal. Works great if I do say so myself (I wrote it =).

I think I've come across this before. So it's a browser/web server solution, right? Seems like there could be some performance/security issues. Seems pretty full featured, though. Nice work!

Hundreds of thousands of users for three years now and there's yet to be any reports of a security issue. The closest thing was a very mild information disclosure issue with the bundled ssh_connect.py script... Because it imported readline you could hit ESC twice and see a listing of the files in the same directory as the script (one other file). Couldn't do anything with that info though, haha. Regardless, I fixed that years ago and there's been nothing since.

I couldn't get this to work reliably. The tty messed with cr and lf characters unpredictably. I'm curious if you found a way around this issue.

It should work reliably but only with "modern" jpeg files. Older files have a slightly different (shorter; no exif stuff) header that makes them more ambiguous. So some of those might not get detected properly but it should work for anything taken by a modern camera/phone.

PNGs should always work as that format is very easy to detect.

DomTerm has its own version of imgcat - see: http://domterm.org/Applications.html

It 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.

I just tried it, and yes, tmux works.

Also, it seems really fast. Liking it so far. Especially after iTerm versioning jumped the shark.

If they continue to improve on it and release it on Windows, it will solve the "no good terminals on Windows" problem.

Would you recommend this to a beginner? Hilariously I'm actually asking for a friend, I don't have a Mac.

OS X comes with a built-in terminal (that's actually pretty good). There's no reason for a beginner to reach for any third-party terminal software.

Yes beginner should start with plain old bash IMO.

A terminal emulator is not a shell. Using bash has nothing to do with the decision whether you use the OS X Terminal or some third party terminal emulator.

Besides iTerm2 maybe. Default config is very similar to the built-in OS X terminal.

I would not recommend iTerm2 to a beginner. The iTerm developers believe in the kitchen sink approach to preferences, which is not very beginner-friendly. And there's not much reason to use iTerm2 in general anyway now that Terminal.app has mouse support, I'm only aware of a few relatively esoteric features that iTerm2 has that Terminal doesn't (support for colors outside of the 256-color palette, and built-in support for showing tmux panes as iTerm window splits).

That's why I said that the default config is fine for beginners. Don't even need to open the preferences window.

pretty sure that iTerm2 for a beginner is pretty much identical to Terminal. At that stage don't know enough to leverage it's fancy capabilities so they don't get in the way and confuse you. When you're ready for them, they're there for you. In Terminal you have something that looks and works almost identical but when you want more you can't have it.

Personally, on OSX I'd go with iTerm2 any time of the day.

Over the built-in Terminal.app? Why?

"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

Their installation notes involve executing a bash script.

Also, the node package `child_pty` is part of the dependency tree - which doesn't support Windows. This is all totally fine but now I'm genuinely curious about how this builds on Windows.

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.

My first reaction is: "This could be the VS Code of terminals". For those stuck on Windows, where the choice in terminals is pretty bad AND more and more Windows dev is done from the command line (hello 'dotnet'), this could be very welcome.

Microsoft announced support for Linux/Unix tools in Windows 10 awhile back. You can get bash if you want.

https://msdn.microsoft.com/en-us/commandline/wsl/about

bash might be there, but the terminal emulation is still pretty bad. (I'm a week or two behind on preview builds, but I still couldn't run a bunch of ncurses/tmux/mosh type apps).

conhost.exe is a shame and it's kind of indicative how much joy it was just to get some basics (like QuickEdit by default, etc).

For windows, conemu ( http://conemu.github.io ) is a bit more annoying to configure than terminal.app, but works just as well, and even has the more powerful built in features like tmux. Of course you have to run something like msys2 (or maybe the bash for windows, but I haven't tried it yet) to get the "unix" environment.

Awesome. However there is just no way someone developing a terminal, hasn't heard of HyperTerminal. It was bundled with every Windows OS. Good luck with that naming cease and desist :/

http://www.trademarkia.com/trademarks-search.aspx?tn=hyperte...

hyperterm Search Apply Now! This name is not found in our database of U.S. trademarks, so Apply for it Now. Check off countries you wish to trademark your name/slogan in.

Another JS terminal emulator, https://chromium.googlesource.com/apps/libapps/+/master/hter...

HyperTerm uses hterm underneath.

Rendering a webpage in the shell is neat. The concept of a terminal wrapped in a browser has a lot of potential.

It also seems like iTerm is moving in the direction of richer media integration with recent features like inline image rendering.

I'm trying it and it feels great. The ability to easily extend it is huge!

Looks really cool, but honestly the input lag is noticeable when compared to something like iTerm. Not sure that's something I could get used to. Is that just a limitation of Electron?

I'm excited to see if a community arises to build and share themes for HyperTerm. I switched from iTerm, and will reply back to this comment if I switch back.

tiny nitpick for a really cool thing: it's not based on JS/HTML/CSS, it's written in or build on JS/HTML/CSS.

If that has the iTerm speed it will be my new terminal app. It looks awesome! Can't wait to see the ecosystem around it.

CodePicnic https://codepicnic.com/

I think HyperTerm is free. And open-source.

Ctrl-a seems to be selecting all, how am I suppose to get out of a screen if I can't Ctrl-a d?

This seems like a oversight.

For anybody with Firefox/Autoplay disabled, you need to right click and select play to see the demo...

Is there any way to use HyperTerm as an embeddable terminal emulator in your own web apps?

That's gonna be one staggeringly heavyweight web app.

oh wow. This is awesome! Now I desperately need a Clojurescript plugin for this.

Finally, I've always wanted a terminal with particle effects!

It assumes I have npm installed. Probably shouldn't:

https://github.com/zeit/hyperterm/issues/134

Would be interesting to see a Hypermedia API explorer.

Personally, I dislike the march of the web technologies towards the desktop. I think, we forgot what they're intended to be used for.

This would work so well with Atom

Why not just call it JSTerminal?

How is this different from crosh / hterm?

Yet another "thin" client...

Cool

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? :)

Bored at first, then was forced to smile with glee. Now I must download it, even though I was originally poo-pooing "another terminal" in my head. Well done, well done.

Hopefully 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.

Yeah I'm sure JS is better than before but I just don't like the web stack in general. I don't like using CSS/HTML/DOM.

-_- another node.js term

you're my hero

the video is a bit silly in the end

It is outrageously silly but maybe that's the point - it carries a message that you can do whatever you want with it (and implies - without much effort, if you can do silly things like this).

There is unexplored area sitting just right there.

Imagine having easy access to ncurses replacement, jupyter kernels like output from any of your "console" tools - that would be awesome.

> It is outrageously silly but maybe that's the point

exactly, I don't understand the downvotes. The parts I saw however, didn't show what you wish for.

The video doesn't seem to have a slider, but click to skip or some. A visual indicator would be nice.

Reply on news.ycombinator.com