How your JavaScript becomes C
At deploy time, every Worker in your repository is translated into C and linked into the server that runs it. The translation is done by AI models working from a curriculum of worked examples, and every build is checked against how the JavaScript actually behaves. Nothing interprets your code at runtime.
Taught, not specified.
In 1725 Johann Fux taught counterpoint by species — one new constraint at a time, worked out on the page rather than stated as law. Bach, Haydn, Mozart and Beethoven all learned from it.
We build our compiler the same way. Every build carries a curriculum: JavaScript beside the exact C it becomes, graded from the simplest shape up through the hard ones. Idiomatic C is a craft rather than a specification — you can write rules for it indefinitely and still not pin it down; show the work and it transfers. That is what produces mappings like these, and why nothing interprets your code at runtime:
JavaScript Source
Compiled C Target
→ Hover over any JavaScript or C node above to inspect compiled symbols.
Verified, not asserted. Three reference workers — static routing, environment-bound handlers, and JWT auth — replay identical requests against the real hono 4.12.27 and against our compiled C. We diff the responses. They agree, down to the WWW-Authenticate header on a rejected token.
Watch your code become C
The compiler isn’t a black box. Each build is something you can open, read and compare with the last one.
- Your JavaScript beside its C. Every build of every Worker is in the console: the JavaScript you pushed and the C it became, side by side.
- Builds follow your changes. Change a Worker and the next build edits its existing C from your change instead of starting over, so the code you didn’t touch stays as it was. You see both diffs: what changed in your JavaScript, and what that changed in the C.
- Unchanged Workers aren’t rebuilt. A push reuses the C already adopted for that exact source, so a deploy only translates what you changed.
- Every build shows its evidence. The compiler’s output and the results of your own tests run against the built service. A build that compiles but hasn’t passed its tests is shown as compiled, never as proven.
- A failed build stops the deploy, and tells you why. The deploy links to the build, where you can read what failed and approve a fix or another attempt.
- You never maintain the C. It isn’t committed to your repository, which stays JavaScript. The C is there to read, so you can check the translation for yourself.
The best AI spend is the kind you never see.
Most AI spend shows up as a new line item — a cost you track, justify, and hope pays off. That is the wrong shape. The entire point of investing in AI is to turn expensive, expert, repetitive work into something cheap and automatic. When it actually works, the spend does not appear next to your costs. It disappears into them.
DataVec applies that to the cost of running your software. We use AI to compile your JavaScript and TypeScript into native C — the systems-level work that used to take a compiler team and a rewrite. There is no “AI” line on your bill to defend. There is a smaller infrastructure bill: the same code you already write, running at machine speed, isolated per end user, billed as plain VM-time, with the serverless premium gone.
You never see the AI spend. It cuts operational cost so far that it shows up as one thing only — a lower operational cost. That is what AI spend should really look like.
That is what we are building.