Hacker News Reader

Comment by spankalee | Hacker News Reader

Synchronous XHR is a really bad way to do this. The performance will be terrible for anything but the smallest module graphs.

But the TypeScript compiler API is synchronous, so there's a problem.

What you want to do is asynchronously walk the import graph, resolving import specifiers along the way with something like es-module-lexer or TypeScript's light parser, then when all the input files are collected, pass them through a compiler host to the compiler.

This is what the Lit team's Playground Elements do, which compile files on a worker for embeddable interactive code samples: https://github.com/google/playground-elements

View on HN

> But the TypeScript compiler API is synchronous, so there's a problem.

But it doesn't use DOM APIs, so you can run it in a worker without any issue. Monaco (the embeddable distribution of VSCode) does that.

The even bigger issue is that the TypeScript compiler is gigantic — like 10 MB, which is just a nonstarter for something you'd need to embed in every page of your site.

The compiler is about 730k compressed, not 10 MB. You can also lazy load it so that you show code before being able to run it.

Being in a worker only causes the synchronous fetches to not block the main thread. It's still terrible for performance as you lose all ability to load files in parallel.

It's really not that difficult to pre-traverse the import graph and fire off as many parallel fetches as the browser will allow.

> The compiler is about 730k compressed

Thanks, you're right, I was looking at the unminified version. Minified is 3.4 MB uncompressed, 730 KB compressed. That's still crazy considering that you could avoid it by compiling your code on the server (which can be extremely fast if you disable type-checking) rather than shoving that responsibility onto your user's browser. Might be reasonable for a big web application with megabytes of other scripts, but not for a normal website.

Oh, I wouldn't use something like this for the main code of a page. You should absolutely just compile and bundle the TS once, rather than on every page load.

But there are cases where you want to be able to run arbitrary TypeScript in the browser - in our case it was inline editable code samples - and for that running the TS compiler efficiently in a worker is great, and 730k isn't that bad. You probably also have 500kB - 1MB for a decent code editor too.

That's totally fair. The OP seems to be intended for your main page logic:

> TypeScript is still second-class citizen with regards to browser adoption, there is a proposal to fix that, but until then we have to use tooling, bundlers, build steps that are an impediment for when you want to quickly create a short demo or PoC.

(Of course, just for "a short demo or PoC," but will anyone be motivated to rip it out before that's no longer feasible?)

So I assumed you were talking about something similar. But using this approach to compile user code makes a lot of sense.

Read the last paragraph

As per another commenter's suggestion, I gave it a shot using a Service Worker and it looks like it works as well[1].

[1]: https://github.com/stagas/tssw

Sychronous XHR also seems a symptom here of compiling Typescript to CommonJS which as a very synchronous module system is also the wrong module system to choose for a browser application. All the modern browsers support ESM great and asynchronously load them just fine.

The compiler API has nothing to do with the module format for the compiler itself.

The issue is that the CompilerHost and LanguageServiceHost interfaces expect a synchronous filesystem API, and downstream from that the compiler internals all expect synchronous access to files.

There's a very long standing issue open to make the API async, but I'm pretty sure it's obsolete now in the face of the tsgo work.

Reply on news.ycombinator.com