洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

That JavaScript/TypeScript runtime idea I mentioned has mutated a bit.

Once I actually thought about it, writing another Node.js/Deno/Bun-shaped runtime didn't seem especially useful; there are enough of those already. What I actually want to try is an ahead-of-time JavaScript/TypeScript compiler in roughly the SBCL/Chez Scheme tradition: native code, with a generic implementation always available and specialized versions picked by cheap runtime guards. A failed guard just falls through to code that's already compiled, rather than needing an interpreter or a deopt path. There are probably adjacent projects doing pieces of this, so I won't claim the territory is empty, but I haven't seen this exact shape applied to JavaScript/TypeScript. I've codenamed it Oseo (鼯鼠; flying squirrel in Sino-Korean).

It's still just a compiler experiment, not something I'd call presentable yet, so the repo stays closed for now. Once it works well enough, the first thing I want to try is switching the Fedify CLI, currently built with deno compile, over to Oseo and seeing what breaks. Fedify is the ActivityPub server framework I also maintain, so it should make a reasonably unforgiving first customer. I'll keep picking at Oseo for the next few months and post again when something interesting starts working.

2 replies

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

Some amusing timing: Vercel Labs just published scriptc, with a strikingly similar surface goal: compile JavaScript/TypeScript ahead of time to a small native executable, with no Node.js or V8 embedded. Apparently someone else wandered into roughly the same problem at roughly the same time. The design underneath is almost the opposite bet, though.

scriptc runs the real TypeScript 7 checker and treats its results as facts, lowering them into a typed IR with monomorphic arrays, exact records, tagged unions, and so on, then through LLVM or a C fallback. Anything outside that model, including any and plain JavaScript packages, needs --dynamic, which links QuickJS-ng as a separate island with its own heap and microtask queue. Values are copied and checked at the boundary. Its correctness evidence is 800+ differential tests against Node.js, rather than a spec-conformance claim.

Oseo trusts none of that. A value annotated number may still be a string at runtime, and the compiled generic path has to handle it without an escape-hatch VM. Typed and untyped code use the same native generic-plus-guarded model, and the target is versioned ECMA-262/test262 conformance rather than matching Node.js behavior. scriptc trusts the checker and isolates what it doesn't trust in another engine; Oseo trusts nothing, but has no second engine to isolate it into. scriptc is already a much broader, more mature Vercel Labs project. I just find the near-convergence from opposite directions rather pleasing.

Filip Jerzy Pizło, Fil-C's author and someone who makes dynamic languages fast for a living, left a fairly harsh critique of scriptc on Hacker News, worth reading in full. His core complaints, QuickJS-ng as the any fallback and floats-only numbers without integer inference, land on exactly the two bets Oseo refuses to make: a guard failure here falls through to already-compiled generic code, not an interpreter, and there's no static gamble on numeric representation to begin with.