Change to xterm.js

[mofux]

Hi, after evaluating several JS libs for terminal emulation to improve the performance of hyper, I found that https://github.com/sourcelair/xterm.js would probably better suite this project.

• 👍 It is actively maintained.
• 👍 Used by Visual Studio Code and maintained by @Tyriar , who would probably welcome some combined efforts on fixing bugs and improving xterm.js
• 👍 It doesn't require to sign an NDA to contribute
• 👍 It doesn't isolate the terminal DOM inside an iframe, which makes it much easier to hack and style
• 👍 It has solved some of the problems we are having with hterm currently, e.g. IME and CJK character support
• 👎 It is currently being migrated to typescript, which might not be everyone's favourite flavour
• 👎 It feels slightly less responsive at the moment, I think this is caused by the queue mechanism that tries to schedule big ui updates and introduces some ms lag - but it can be optimized

I did some quick tests replacing hterm with xterm.js and the performance seems level. I was also able to quick and dirty put in some of the features we get from hterm, e.g. changing the cursor color on bell.

If you like I can start working on pull request that replaces the current implementation with xterm.js, but I'd like to see some thumbs up for that first

[rauchg]

When I first tested it it had some serious problems in terms of support of terminal features and slower performance. Would be useful to revisit this now, though

[mofux]

Agree, would actually be good to have some reproducible test cases to compare both against each other. Like the vtop or emoji test for non standard-width characters (which is broken in xterm and hterm) and locale specific tests, as well as tests for unicode, performance (seq 1000000) etc... I will try to create a couple of test files and run them to compare the output.

[tbodt]

It also may fix #270.

[tbodt]

Actually it won't, it has no support for cursor shapes at all. It would be a lot easier to fix #270 though.

[KarlAmort]

@mofux I recently generated the stats at #687 (comment). It's a really somewhat terrible ruby script but I could put it in a gist if you're interested.

It's actually a bit involved to measure output lag (from the outside) because the actual commands finish long before the output arrives.

[tbodt]

#1286 (comment)

There are a number of other styling things I'd like to fix, such as underline/i-beam cursors not blinking, but the root cause is hterm. SO CAN WE PLEASE FOR THE LOVE OF GOD USE A JAVASCRIPT TERMINAL LIBRARY THAT DOES NOT REQUIRE SIGNING AN NDA TO CONTRIBUTE TO!!!!!!11!!1 #1275

[Tyriar]

FYI, the main issues on xterm.js to watch regarding perf are:

• scrollback doesn't work as expected xtermjs/xterm.js#361 scrollback doesn't work as expected - I currently have a WIP branch that should help when culling rows from the buffer, this blocks the below issue and should make it process output faster
• Refresh limit system makes performance bad on Windows xtermjs/xterm.js#280 Refresh limit system makes performance bad on Windows - This is the root cause for the laggy input issue which I believe is the main regression from hterm

It might be worth holding out on migrating until these 2 are tackled if the laggy input is too much of a regression (likely some time in January of February).

[SirTimmyTimbit]

I say we wait then. We finally have a good looking terminal on Windows, I'd be sad if it turns laggy :(

[mofux]

I agree. Thanks @Tyriar for giving us a rough roadmap. I'll follow the issues closely and catch up again once they have been resolved.

[dionisokan]

+1 for switching to xterm.js. As an Asian user, I would be very happy to see correctly rendered CJK characters and support for IME, as for now they mess up any other output in hyper.

[rauchg]

@dionisokan can you describe the issues you have with the IME support in 1.0? cc @matheuss