Will this run in the browser (WASM)? #458
-
|
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 |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 15 replies
-
Yes! |
Beta Was this translation helpful? Give feedback.
-
|
@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) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
I'm really HYPED. Now I can just ship the compiler as wasm, write my code in typescript, and no need for offline webpacking, I can just include it like normal js file. |
Beta Was this translation helpful? Give feedback.
-
|
It would be nice to see more details on the work~ |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
-
|
No, this is not about converting anyone's TypeScript into Go. It's just about us porting the TypeScript compiler itself to Go. |
Beta Was this translation helpful? Give feedback.
-
|
Gotcha thank you for the clarification 👍 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Syntactic tools like 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
Yes!