3 ms·

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 i

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 https://github.com/google/playground-elements

rafram 1y ago
> 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.
- spankalee 1y ago
  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.
  - rafram 1y ago
    > 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.
    - spankalee 1y ago
      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.
      - rafram 1y ago
        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.
- Zardoz84 1y ago
  Read the last paragraph
WorldMaker 1y ago
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.
- spankalee 1y ago
  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.
stagas 1y ago
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 https://github.com/stagas/tssw

rafram 1y ago

> 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.

spankalee 1y ago
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.
- rafram 1y ago
  > 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.
  - spankalee 1y ago
    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.
    - rafram 1y ago
      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.
Zardoz84 1y ago
Read the last paragraph

WorldMaker 1y ago

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.

spankalee 1y ago
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.

stagas 1y ago

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 https://github.com/stagas/tssw