Will this run in the browser (WASM)?

[louwers]

Since the announcement does not mention WASM, will running typescript-go in the browser will be officially supported?

I guess this will be a requirement for TypeScript Playground and other users of @typescript/vfs.

[ahejlsberg]

Since the announcement does not mention WASM, will running typescript-go in the browser will be officially supported?

Yes!

[jakebailey]

I'm not sure where the 2MB is coming from, but the current binary we have for our single entrypoint is more like 18MB, which is actually about how big esbuild is.

[pulsejet]

@ahejlsberg @jakebailey I just want to put a word of caution here - go currently emits very inefficient wasm due to some fundamental conflicts with the stack model (see golang/go#65440). There's a good chance this will be fixed with stack switching or JSPI, but that's at least a few years in the future. But as of today, performance and size of the output wasm is very bad.

Meanwhile, tinygo emits very efficient wasm by using binaryen's relooper implementation (asyncify) rather than gc's naive stack unwind-rewind. However the garbage collector in tinygo is quite naive and basically unusable in nontrivial apps (gc pauses end up being over one second for us). But it's likely that this problem is much easier to fix by using another existing implementation (see tinygo-org/tinygo#4385)

[jakebailey]

We aren't against tinygo at all, it's just that it crashes for our repo in the two most recent tinygo releases, so we can't really test.

[pulsejet]

Right, I didn't mean to imply that (if I did).

All I was pointing out is the wasm go produces (regardless of compiler) may currently have (major) performance issues - just something to keep in mind.

[justinfagnani]

I suspect that most users of tsc that use it in the browser will appreciate the speed up and won't notice 2MB Go runtime added to the wasm code. While that's an obscene size in philosophical terms, I think it's fair to say that it's hard to think of a place it would pose a problem.

We run TypeScript in a web worker for a playground component that's embedded all over our documentation site (https://github.com/google/playground-elements). We want this playground to load as fast as possible because cold page loads are quite common, and users want to see interactive examples as fast as possible. The typescript bundle is about 3MB uncompressed currently. I think we would notice an additional few MBs quite a lot.

[yeshan333]

It would be nice to see more details on the work~

[lukescott]

If WASM is yes, I just want to clarify: This allows us to compile TypeScript into Go source? This isn't just for optimizing the compiler/vscode, right?

If so, are there any plans to allow Go packages to be imported into TypeScript? Perhaps by generating .d.ts files and allow those to be referenced via ESM? That would be huge if we got to that stage.

At our company we use both TypeScript and Go. We mostly use Go on the backend, but we have team members who are more comfortable with TypeScript.

[jakebailey]

No, this is not about converting anyone's TypeScript into Go. It's just about us porting the TypeScript compiler itself to Go.

[lukescott]

Gotcha thank you for the clarification 👍

[Snowflyt]

I’m concerned about tree-shaking. Many projects, like ts-blank-space, use only part of the TypeScript compiler API, and with tree-shaking, the bundle size can be significantly reduced compared to including the full TypeScript bundle.

I have developed an online TypeScript REPL that utilizes the TypeScript compiler API in the browser (repository here). After tree-shaking, it adds approximately 3MB to the bundle, which is acceptable in terms of load time since I use dynamic import along with a progress bar. I wonder if the Go port can maintain this size—if the bundle grows to around 15MB, it would be a bit large for such a simple use case.

[RyanCavanaugh]

Syntactic tools like ts-blank-space only need a parse tree, and can use one of the many TS-compatible JS-based parsers available.

It's certainly possible that browser-based semantic operations are going to incur a bigger bundle size. We haven't even tried shrinking this number yet so it could go down, but I don't expect that we'll be able to do this without having a larger overall payload at the end of the day.

[Snowflyt]

Syntactic tools like ts-blank-space only need a parse tree, and can use one of the many TS-compatible JS-based parsers available.

It's certainly possible that browser-based semantic operations are going to incur a bigger bundle size. We haven't even tried shrinking this number yet so it could go down, but I don't expect that we'll be able to do this without having a larger overall payload at the end of the day.

Fair explanation, thanks! However, it seems likely that many tools relying on the TypeScript compiler API will need to switch to alternative libraries if they want to further reduce bundle size. While this isn’t ideal, it may be an unavoidable step toward a faster TypeScript.