[1] can give you some insight on the dark side of JS. Also, avoiding JS in some way or another is not that hard, esp. since there're a lot of languages which compile to JS, most notably CoffeeScript and ClojureScript.
As much as I love CoffeeScript, it's not a substitution for learning JavaScript. CoffeeScript is basically just JavaScript with a prettier syntax and if you don't understand JavaScript you won't understand CoffeeScript.
That is completely true, you can't treat CoffeeScript as a replacement for learning Javascript in fact I'd say you need to have a pretty strong understanding of JavaScript to really use CoffeeScript well. That said CoffeeScript does some nice things to prevent typical small js errors for newer devs.
Very true. I love CoffeeScript very, very much. It's my favorite language - I like it even better than ruby, if you believe me! I like using indentation instead of stupid 'end's that only God knows are ending a loop or a def or something else, I like the use of ... instead of * (for splats), and a few other things.
But, as much as I like CS and hate (really hate) JS, I have to agree with you wholeheartedly. You must know JavaScript well. Variable/function hoisting won't bite you in CS, but other JS idiocies will.
Read Douglas Crockford's "JavaScript: The Good Parts" at least twice (and take a lot of notes). It's the best no-bullshit book on JavaScript (the language, not "how to use JavaScript in Node/front-end web design") around.
I guess FM index is just not the right thing to use when you need a key-value data store. It's a full text index -- a data structure, which allows fast substring queries over a fixed text corpus.
- unicode characters (for instance you can't type in russian) -- try there http://demos.anyterm.org/shellinabox_nano
- speed could've been better, there's a noticeable delay when running something like `mc`
I haven't tried Gate One yet, but I did look very closely at your project at some point. Great work, btw :)
I chose to write my own terminal emulator from scratch because after trying various existing open source implementations (including the one in Ajaxterm) I decided they were too slow, buggy, or incomplete. I have old versions of Gate One that used a modified version of Ajaxterm's emulation, Termemulator, and one other that I can't remember right now.
The biggest reason of all was the speed. Gate One needed to support multiple users running multiple terminals. Every terminal--when the screen is updated--needs to be converted into HTML and sent to the client. I wrote terminal.py to be as fast as possible with this purpose in mind.
For reference, I hadn't heard of pyte until I saw your link just now. I'll definitely be checking it out.
Having said all that, now that I've already written my own terminal emulator for Gate One, it includes some additional features that only Gate One is suited to take advantage of (special escape handlers that only terminal.py would know how to handle--for plugin authors to use). I don't think it would be practical to use something else at this point.
I understand your point, there's two problems with most of the terminal emulators I've seen:
- they are either poorly or completely unsupported
- the code is a nightmare, badly written, undocumented
Both make extending a VTE an almost impossible task. Actually, that's why we (at Selectel) wrote `pyte` [http://github.com/selectel/pyte], which soon became open-source.
As for speed issues, have you considered implementing incremental updates (like in AnyTerm, for example)? This approach works perfectly in our setup (multiple clients, multiple terminals).
P. S. Looking through the code, I can tell that you had some tough nights throughout those 9 months :) Good job!
Open source projects need a RELATED_WORK.txt like the section at the end of academic papers. Each project would get a summarised one paragraph comparison.
Actually, some of them do have it -- `xterm`, for instance has a lists of flaws in other terminals. `pyte` on the other hand only mentions similar projects.
