quickjs

Not OP but I was considering using it as well. I could see it going either way. If Fabrice stays interested in the project and keeps improving it, it could be a great win. If he moves on to other things, perhaps not. I've been looking at quickjs issues and forks and see a lot of random fixes from various people and most of them don't seem to be accepted or responded to: * https://github.com/bellard/quickjs/issues/131 * https://github.com/bellard/quickjs/issues/130 * https://github.com/bellard/quickjs/issues/129 * https://github.com/bellard/quickjs/issues/123 * https://github.com/bellard/quickjs/issues/111 * https://github.com/bellard/quickjs/issues/103 * https://github.com/bellard/quickjs/issues/96 The mailing list doesn't seem to have a lot of responses either. So, it's actually hard to say. The first instinct is it's great to base a pro

You can also refer to the Unicode routines of other small JS engines[1,2], those don’t use ICU either, although the implementations are mercilessly size-optimized (to put it politely) and restricted to what the target JS version requires (e.g. Duktape does casemapping but no normalization). Still, Bellard’s in particular look like he had a small Unicode processing library lying around and just copied it into the tree, not like he was forced to write the absolute minimum to do a JS inteprerer, so they can even be compared with dedicated libraries like libgrapheme, libutf8proc or libutf. [1] https://github.com/bellard/quickjs/blob/master/libunicode.c [2] https://github.com/svaarala/duktape/blob/master/src-input/du...

A few that come to mind.. Hand-written compiler for WebAssembly Text format to binary - https://raw.githubusercontent.com/stagas/wat-compiler/main/s... Gameboy emulator implemented in C, that also runs in the browser - https://github.com/binji/binjgb QuickJS Javascript Engine - https://github.com/bellard/quickjs The TypeScript language and compiler - https://github.com/microsoft/TypeScript

I haven't looked too closely at LiveView yet. I did flip back and forth between going with the Hotwire approach (I guess inspired by LiveView?). It was a tough call, but I ultimately decided to server-render JS. This thought-experiment helped: • If Ruby could natively render Javascript, would they still choose the Hotwire approach? I concluded no. I don't see the reason to have multiple approaches (HTML over wire, Stimulus), when one solution would suffice. The one solution also happens to be way more familiar to today's frontend developers. I definitely didn't want to make another templating language. Bud will eventually ship with it's own JS evaluator. Either through https://github.com/dop251/goja or through porting https://github.com/bellard/quickjs to Go (~25kloc of C)

Im am always fascinated by how a single person can build a language runtime. That too for language like JavaScript where large number of features are introduces on regular basis. https://github.com/bellard/quickjs/graphs/contributors

> runtime for TypeScript written in Go This makes it sound like the TypeScript runtime (interpreter or JIT) is written in Go, but the project uses the quickjs JavaScript runtime, which is written in C: https://github.com/bellard/quickjs

Ancient FORTRAN, as opposed to complicated modern Fortran/C++/Rust, has a huge advantage if you ever crash your spaceship on a resource rich alien world and have to build a programmable computer from scratch from first principles using only knowledge that a single human could memorize. Modern languages require nontrivial compiler theory to parse a sequence of language symbols into an Abstract Syntax Tree (AST), etc. But Ancient FORTRAN is essentially designed to be read in and translated just a few 80 column punch card lines at a time, much like assembly languages. Compilers were written that could fit inside computers with only a few thousand words of 16 or 18 bit memory. Magnetic Core memory from that era was often made by hand, by little old ladies weaving it in factories I've been told, and was used for the Apollo moon spacecraft and