Transpose: our C# to JavaScript compiler just got 7x faster

Rafael

• 2026-08-03

Curiosity's front end is written in C# and compiled down to JavaScript to run in the browser. We've built it that way for years, through a compiler called h5, and it's worked: one language across the whole stack, one team, no separate JavaScript codebase drifting out of sync with the backend. That approach hasn't changed. What we just rewrote is the compiler that makes it possible.

Why compile C# to JavaScript at all

The browser only runs JavaScript, but that doesn't mean the code has to be written in it. Writing the front end in the same language as the backend means the two sides can share real things, not just a REST contract: the same model classes, the same validation logic, the same helper methods, defined once and used on both ends. A field renamed on the backend is a compile error on the front end, immediately, not a bug found in production three weeks later. Type safety runs the whole way from the database to the browser, not just up to the API boundary.

That's what the compiler has always bought us. h5 delivered on it reliably for a long time. But it carried an aging translation pipeline underneath, and every new year of C# syntax it had to support piled more special cases onto it. The cost showed up in the one place every developer feels it several times a day: how long a build takes.

What changed

We rewrote the compiler from the ground up and called it Transpose. It's built directly on Roslyn, the compiler platform .NET itself uses to parse and understand C#, so Transpose reads your code the same way the C# compiler does instead of maintaining its own aging understanding of the language. Fewer moving parts between your code and the JavaScript that ships to the browser. It's open source under the Apache 2.0 license.

The difference is in the numbers, and they're not close:

• Compiling our own Tesserae UI framework: 7.7x faster — down from 2 minutes 41 seconds to 21 seconds.
• A full CI run, install to publish: 2x faster — down from 5 minutes 24 seconds to 2 minutes 42 seconds.
• Rebuilding with no source changes: 19x faster — Transpose checks whether anything actually changed and skips the work entirely when it hasn't.
• A change to a single method body: about 2x faster — everything else in the project stays cached.

None of these came from a synthetic benchmark built to look good. The first two are two ordinary CI runs of the same repository, a few weeks apart, same machine, same test suite, nothing tuned for the comparison.

What it means for the people building with it

A build that takes 21 seconds instead of nearly 3 minutes changes how you work, not just how long you wait. Under 30 seconds, you stay on the change: you rebuild, look, adjust, rebuild again, and the loop stays tight enough that you don't lose your train of thought. Past a couple of minutes, that loop breaks. You switch tabs, check messages, come back and have to reload what you were doing in your head. Multiply either version of that by however many builds a developer runs in a day, and the gap compounds into real hours, not just saved minutes on a CI dashboard.

One of our partner developers, after moving a project over, put it about as plainly as it can be put:

It's nice. It's really, really nice.

Getting it

Transpose is on NuGet (Transpose.Compiler, Transpose.BCL, Transpose.Core, and a handful of bindings) and the source is on GitHub, Apache 2.0. If you're already on h5, the README covers what moves over directly and what changed in the rename.

You can check the developer docs for more news. Or get in touch.