4 ms·

If you use vanilla JS modules you can get away with no bundlers at all which greatly simplifies web projects. import statements "just work" in browsers, and cac

by umvi 2y ago

If you use vanilla JS modules you can get away with no bundlers at all which greatly simplifies web projects. import statements "just work" in browsers, and caching of shared modules means you don't need fancy things like chunking. Also no need for map files and such, just debug directly in browser. Vanilla TS also works well if you use a server side translator like esbuild to strip out the types before serving the files in a middleware (especially if you are using a golang backend, esbuild is trivial to integrate as a middleware)

nosefurhairdo 2y ago
> Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching). Source is Vite docs: https://vite.dev/guide/why.html#why-bundle-for-production https://vite.dev/guide/why.html#why-bundle-for-production For me, Vite has largely solved my js tooling needs. It's definitely cool how far we can go with the platform alone, but for larger applications or publishing libraries, tooling like Vite is a blessing.
- umvi 2y ago
  That hasn't been my experience. Depends on the caching mechanism used I guess, but if you bake cache busting directly into the URI like I do (i.e. there's a hash digest in the path), the browser doesn't need to make any additional network round trips for any nested imports that have already been fetched - they are all 0ms cache hits. And even if you use a cache mechanism that requires reaching out to the server every time, it's still very lightweight (you'll just get a 304 not modified for any nested imports) Even if vanilla modules is slightly less optimal than a bundler performance wise, I would still argue the additional complexity (for learning, maintaining, deploying, debugging) introduced by said bundler is not worth the extra cost for most websites.
MyOutfitIsVague 2y ago
Due to that caching, you still need some sort of preprocessor to digest the files and generate an import map. Third party modules also add some extra friction. I found that when I ended up pruning out all the edge cases, just bundling it ends up being less work anyway.
- umvi 2y ago
  > Due to that caching, you still need some sort of preprocessor to digest the files and generate an import map. Why? I haven't needed import maps at all. > Third party modules also add some extra friction This is true, sometimes 3rd party JS requires you write a small ESM wrapper, etc, but I haven't found it to be too onerous
  - MyOutfitIsVague 2y ago
    If you import a module by its path or URL, it is cached by that path. So if you update a file, browsers that have already pulled that module will get the old version. Getting around this needs some sort of digest. To import that file, you need to either use an import map to get the proper digested file or a preprocessor step to substitute the digested name into the importing module.

by umvi 2y ago

nosefurhairdo 2y ago

> Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching). Source is Vite docs: https://vite.dev/guide/why.html#why-bundle-for-production https://vite.dev/guide/why.html#why-bundle-for-production For me, Vite has largely solved my js tooling needs. It's definitely cool how far we can go with the platform alone, but for larger applications or publishing libraries, tooling like Vite is a blessing.

umvi 2y ago
That hasn't been my experience. Depends on the caching mechanism used I guess, but if you bake cache busting directly into the URI like I do (i.e. there's a hash digest in the path), the browser doesn't need to make any additional network round trips for any nested imports that have already been fetched - they are all 0ms cache hits. And even if you use a cache mechanism that requires reaching out to the server every time, it's still very lightweight (you'll just get a 304 not modified for any nested imports) Even if vanilla modules is slightly less optimal than a bundler performance wise, I would still argue the additional complexity (for learning, maintaining, deploying, debugging) introduced by said bundler is not worth the extra cost for most websites.

MyOutfitIsVague 2y ago

Due to that caching, you still need some sort of preprocessor to digest the files and generate an import map. Third party modules also add some extra friction. I found that when I ended up pruning out all the edge cases, just bundling it ends up being less work anyway.

umvi 2y ago
> Due to that caching, you still need some sort of preprocessor to digest the files and generate an import map. Why? I haven't needed import maps at all. > Third party modules also add some extra friction This is true, sometimes 3rd party JS requires you write a small ESM wrapper, etc, but I haven't found it to be too onerous
- MyOutfitIsVague 2y ago
  If you import a module by its path or URL, it is cached by that path. So if you update a file, browsers that have already pulled that module will get the old version. Getting around this needs some sort of digest. To import that file, you need to either use an import map to get the proper digested file or a preprocessor step to substitute the digested name into the importing module.