jquery.terminal VS esprima

Few of my Open Source projects: * jQuery terminal * LIPS Scheme * Gaiman * Sysend * Wayne

But then I realized that I should probably will need to use jsDOM. This is the library that can be used in nodejs to mock the DOM. This is what jest testing framework is using and this is what I was using to test jQuery Terminal library in Jasmine before jest was created.

Creating such a styled console website or fake terminal website is easier if you have a library that will give you the look and feel of the real terminal emulator, with a nice API to create commands, so you don’t need to create it from scratch. We will use the JavaScript Terminal library: jQuery Terminal, which gives a simple, but powerful API to create interactive terminals on any website. The library doesn’t use any HTML5 features and uses ES5 so it will work on any Browser even in IE11.

There is way more than in the Wikipedia article. I was implementing an interpreter for ANSI Art some time ago, maybe you will find it helpful. After a lot of struggle with my own parser using regular expressions, someone suggested that I should use a real parser which I use now. My project is in JavaScript and I used Node Ansi parser. It handles all ANSI escape code including cursor movements. There are no good documentation, I got help from one of the contributors that were also a contributor to the XTerm.js library. You can see my code that uses the library here: unix_formatting.js the file includes NodeAnsiParser.

I've wanted to have my own programming language, that will make it easier to create text-based adventure games for my Open Source project jQuery Terminal. The idea for the language came after I've created a paid gig for one person, let's call him Ken, that needed this type of game, where the user interacted with the terminal and was asked a bunch of questions and it was like an adventure game, related to Crypo. The code I've written, that Ken needed, was data-driven by a JSON file. It was working nicely, Ken could easily change the JSON and have the game changed however he wanted. I've asked if I could share the code since it was a very cool project and Ken agreed that I can do that two months after he publish the game. But after a while, I've realized that I can have something much better. My own DSL language, that will make it simpler to create text-based adventure games. A person with a bit of programming knowledge like Ken, could easily edit the game, because the language will be much simpler than complex JavaScript code that is needed for something like this. And even if I would be asked to create a game like the one for Ken, it would be much easier and faster for me. This is how Gaiman programming language has started.

My jQuery Termial: https://terminal.jcubic.pl/ library. It started more the 10 years ago. It's written in ES5, I didn't wanted to do that, but I'm thinking about creating version 3.0 that would be a rewrite in latest JavaScript or TypeScript.

I'm working on a language called Gaiman similar to ruby that compiles to JavaScript. The purpose of the language is to simplify creating interactive text games, first for the Web later maybe for the normal terminal. The web part is based on my jQuery Terminal library.

If you don't mind using jQuery Based Terminal library. You can do almost everything (except I don't know how to create floating domain animation) with https://terminal.jcubic.pl/. You can think about jQuery Termial as a framework. You don't need ReactJS or Angular for this.

The library supports typing animation and changing colors. You can easily create the same interactive console.

If you're interested I can create a demo for this.

Focusing again on ESLint, the parser used by the linter is called Espree. This is an in-house parser built by the ESLint folks to fully support ECMAScript 6 and JSX on top of the already existing Esprima. The Espree module provide APIs for both tokenization and parsing that you can easily test out.

For TypeScript we have used AST transforms from their compiler API, and for plain JavaScript we did a similar thing using ESPrima. This helped us implement some simple optimizations like stream fusion (combining .filter and .map into a single operation) or avoiding extra object allocations in vector math, which led to nice performance improvements in code that does heavy computation (we process large amounts of data on the server and store results of physics simulations).

I used ESPrima, but any parser would do in this case. I then wrote a simple function to extract all "atomic" non-boolean expressions from it.

AST is an acronym for Abstract Syntax Tree. It's the way to represent code in a format that tools can understand. Usually in form of tree data structure. We will use AST in the format of an Esprima, which is a JavaScript parser that outputs AST.

esprima

Create an AST: Esprima

The thread was originally about CRA vs Vite size on disk (or implicitly, if we're applying it to real world applications, network cost in CI job startup times). And like I said, surrogate pairs don't apply to ASCII.

See this[0] for reference. Note how the first byte must fall within a certain range in order to signal being a surrogate pair. This fact is taken advantage of by JS parsers to make parsing of ASCII code faster by special casing that range, since checking for a valid character in the entire unicode range is quite a bit more expensive[1].

[0] https://github.com/jquery/esprima/blob/0911ad869928fd218371b...

[1] https://github.com/jquery/esprima/blob/0911ad869928fd218371b...

If you want to learn more about parsing, reading the code of an actual recursive parser might be a better idea. Esprima is a decent place to start if you're interested in JS grammar. Then you can look at the babel handbook to learn more about AST transformations. From there, the literature gets quite a bit more heavy. If you get this far and are willing to push further, you'll probably want to grab yourself a copy of the dragon book at a minimum.