3 ms·
> 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 rou
by 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 agoThat 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.