There is also the one from Microsoft themselves, although it supports only a subset.

https://www.microsoft.com/en-us/research/publication/static-...

Used in Make Code,

https://www.microsoft.com/en-us/research/project/microsoft-m...

Bookmarked, thanks

Ah, amazing project! Congratulations. I was just writing under another thread that we support any and unknowns in two different ways. First, most any and unknowns are lazy programming—if you trace the call graph you can prove they have concrete types, or used only in one shape. If we can't prove a type narrows properly, we lower it to a boxed dynamic value carrier so it doesn't block compilation. Like JSON.parse—for this we have a special syntax, you can do JSON.parse(x) as T, to define the type, and if you don't it becomes a dynamic value whose price you pay only for that site / variable.

We also have limited support for `new Function("...")` via a small evaluator written in C++ that parses and runs the generated body. We mainly built this for Fastify's generated routing functions so it doesn't support classes, asynchronous, destructuring, etc, but conditionals, loops, variable declarations etc work.

There is no "eval" yet, but the same support shape could be added for it too, as the mechanism is already there.

The approaches and the limitations are documented here:

https://github.com/geastack/compiler/blob/main/docs/EVAL.md https://github.com/geastack/compiler/blob/main/docs/DYNAMIC-...

Amazing questions, thank you for the careful read!

We should ship a compatibility matrix... at some point we were hoping to report test262 coverage for ECMAScript compliance, but we had to prioritize the release. Of course any of the typical web APIs work, including localStorage, and even so far as the Web Audio API (and we're working on WebRTC to make it cross platform. It's especially interesting to be able to build real-time communication apps, say, on an ESP32-S3, with just the web semantics).

In short, most app code stays inside the portable model. You need to know the target when you use host APIs that are constrained on small devices: blocking I/O, memory limits, file sizes, and of course you can combine it with native code for the target. I'm building a guitar effects processor, for example, where the UI is powered by Gea Stack but all the audio processing happens natively (https://github.com/dashersw/coyopedal).

On AI: yes, it's mostly me plus agents for the compiler. We have a team at Coyotiv that helps with everything else. I use Claude Code with Claude Opus as the main model and Sonnet subagents for parallel work, with a fair bit of Fable. I also combine this with whatever GPT model is available over Codex. During the past 6 months I've started working on the compiler, I've changed several model versions :)

What makes AI perform on a compiler:

Hard gates the agents can't argue with, like a diff gate that names every program whose output changed, plus conformance sweeps, a diary that captures past failures so they don't repeat, and treating a passing exit code as insufficient and the outputs get checked against Node.js behavior and unit tests.

The biggest differentiator for me is, even though I'm a pretty relaxed manager for humans, I'm a heavy micro-manager for AI. I read its thinking tokens and its code live and as soon as I spot something I don't like, I intervene and guide the model to the output I want to see.

It wasn't easy, Gea Stack in total I think burnt more than a million dollars in AI credits, and I've been working on it literally non-stop for 6 months.

Ah damn, this is a leftover from literally the first day of our Android target build. Of course it's native for Android, too. Will fix it ASAP, thank you!