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.
