I tried to revive this as an alternative to #492, but ran into problems with code splitting.

Here's the waterfall for loading the chunks created for parcel:

And here's the waterfall for loading chunks created by esbuild:

Ignore the sizes -- this is esbuild in development v.s. parcel in production. The parcel version is minified & gzipped.

The part that's a dealbreaker for me is that esbuild generates 6 chunks instead of the desired 4, and requires 2 round trips before the main chunk executes (speedscope.js has to wait for the two chunk-***.js files to download and execute). This happens because these files share common dependencies with the intentionally code-split chunks.

An example of where this happens is lib/profile.ts. This file is used both by the main speedscope.js chunk and the import-***.js chunk. In esbuild's implementation, this means that the contents of lib/profile.ts are split out into a separate chunk which gets asynchronously loaded after the main chunk is downloaded and parsed. (See esbuild's documentation on code splitting)

In parcel's implementation, this code is contained in the main chunk and then somehow referenced from inside of the import-***.js chunk without any additional network overhead.

This is a bummer! I could work around the network waterfall by embedding those initial chunk dependencies directly into the page, but I'd still lose out on compression benefits of having all of the main chunk's contents in a single network payload.

It's possible, however, that the benefits of using the esbuild esm target w/ minification outweighs the loss caused by shared compression.

cat speedscope.js | gzip | wc -c
   47065
cat chunk-EK7ODJWE.js | gzip | wc -c
     337
cat chunk-UCDBZYH3.js | gzip | wc -c
    5620

Those add up to less than the size of just compressing the version output by parcel v1. So if I can get the initial chunks to all load as part of the initial load by embedding multiple script tags, then maybe this is still a performance improvement.