[eknkc]

I feel like you'll need to provide a wasm binary for browser environments and maybe as a fallback in node itself. Last time I checked, Go really struggles to perform when targeting wasm. This might be the only reason I'd like to see it in Rust but I'm still glad you went with Go.

Are there any insights on the platform decision?

[jchw]

Honestly, the choice seems fine to me: the vast majority of users are not compiling huge TypeScript projects in the browser. If you're using Vite/ESBuild, you're already using a Go-based JS toolchain, and last I checked Vite was pretty darn popular. I don't suspect there will be a huge burden for things like playground; given the general performance uplift that the Go tsc implementation already gets, it may in fact be faster even after paying the Wasm tax. (And even if it isn't, it should be more than fine for playground anyways.)

[merb]

I‘m pretty sure that a lot of vite users with hot reload will run tsc inside the browser (tanstack, react-router)

[jchw]

I am not a Vite expert, however, when running Vite in dev mode, I can see two things:

- There is an esbuild process running in the background.

- If I look at the JavaScript returned to the browser, it is transpiled without any types present.

So even though the URLs in Vite dev mode look like they're pointing to "raw" TypeScript files, they're actually transpiled JavaScript, just not bundled.

I could be incorrect, of course, but it sure seems to me like Vite is using ESBuild on the Node.JS side and not tsc on the web browser side.