> Typescript recently announced a rewrite in Go for an expected 10x performance gain

Really?

Why use Typescript at all, in that case?

I really do not know

The Typescript compiler, currently JavaScript, is being rewritten in Go. The 10x performance gain is in build time, which is still a major speedup and will shrink the development loop.

The improvement is in `tsc`, the type checker. The improvement is reduced build times and thus faster developer or agent cycle times.

Couple things:

First, perf you mention is from fundamentally CPU intensive workloads, not a sparse async environment like a typical server.

Second (far more important) the reason we do this is type safety. We don't want types to break at the handover or to maintain them twice. We eliminate a huge category of issues and mental overhead.

This maintainability and simplicity is worth more (to me at least) than perf.

As a bonus there's also directly shared utils, classes etc. which again can be reused across client/server but more importantly stay in sync.

I am curious, how do you handle version skew between frontend / backend when you're reusing code + types?

I design solutions so that there is a distinct frontend and backend. Instead of reuse, common code gets shared. Yes, it does take a bit of fiddling to get the architecture to support that. But once you get it bedded down, it becomes just a matter of conventions.

More depressing is those of us that would rather use Java, C#, basically any JVM or .NET language, or even if it must really be, Go, but have to bother dealing with nodejs instead, because reasons.