What is this for?

[mindplay-dk]

Just wondering, what did you build this for?

I went looking for a tiny TS compiler that would be small and fast enough to run in the browser - perhaps in a service worker.

Is that what you're after as well?

I wonder, esbuild being the fastest thing out there, would it be possible to pull just the parser and transformer from it's libraries, build a WASM module using tinygo, and get something very fast and small?

With those compile times, and if it runs on a separate thread from the UI thread (in a service worker) it might not actually impact load times substantially.

You might not need to write an entirely new parser. Seems like a lot of work. So much hard work went into esbuild already, and expect it might be both small and fast if built with tinygo, as the parser itself is hand written and small.

What do you think?

[mizchi]

mints is most important for memory footprint and time to first compile for running on a browser.

I built this for a couple of uses.

• Avoid blocking: blocking the browser for the time it takes to load the code into memory. I figured this could be worked around by making it a small footprint. (As you pointed out, service workers can work around this problem.
• Embedded: We wanted to provide a TS runtime environment within the playground for beginners to write TypeScript. Mints avoids this problem.
• CDN Edge: We wanted to create a tool to dynamically build and cache rollup + ts on a CDN Edge, such as a cloudflare worker. In this case, compilers other than mints will have problems with Cloudflare Worker's 1MB limit.

This is an extreme case, but even if compiling with raw ts + mints and running in a production environment, if the tool is running on mints, it will work to some extent without problems. (Although there is the problem of using user CPU resources unnecessarily.)

In terms of footprint, esbuild has some problems.

• Since esbuild is mainly accelerated by parallelization, it will not perform as well as it should in the browser unless webassembly multithreading is enabled. Also, this concept prevents tinygo, which omits channel, from being selected as a backend. This is more of a problem with Go itself than with esbuild.
• Build size: esbuild, or rather Go's Wasm Backend, builds the entire Runtime and user code for GC and channel. swc has the same problem and does not focus on build size, which is 28MB.

mints also has problems.

• It does not support ASI to make the parser lightweight.
• Even assuming no ASI, it is difficult to classify tokens enclosed with / such as regular expressions /abc/g and a / b / c at tokenize time due to the language specification of JS, so it is heuristically handled.
• I'm making this as a hobby when I feel like it, so there is a quality problem. I don't have much time these days.

see evanw/esbuild#836

[mindplay-dk]

Wow, thanks for the in-depth answer.

fwiw, I think the tradeoffs you've had to make, like no ASI, are completely reasonable - these are things you could easily lint against with a standard linter anyhow.

(This is a really good answer - you might consider including this in the README. 🙂)