loading...

re: The Future of "View Page Source" VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Well, yes. It does. But once it parses an import statement, then it has to fetch the next level of dependencies... and then the next... and then th...

However, for common dependencies like lodash, if you use a CDN like pika or jspm, you won't load them, they'll be cached. With bundles, that is simply impossible. Also I as a dev vastly prefer not needing a build step, so I use es modules.

Yes, it would be great if everyone used smart CDNs like Pika, but the reality is otherwise. I do hope for the best, though! 🤞

But I believe you misunderstood me about the network disadvantages of ES modules. ES modules can be represented as a big graph of dependencies.

NOTE: By "dependencies", I mean both external libraries, internal application code, userland modules, and other related components. It is not limited to only NPM modules.

However, the problem with this dependency graph is traversal. When the browser fetches for import statements, it is basically traversing only one level of that big dependency graph. This must be repeated until the whole graph has been traversed, where each node (dependency/script/module) would require a network round trip (assuming the absence of HTTP/2's server push feature).

Even with HTTP caching enabled, this is still the main problem with ES modules. Yes, the network trip has been mitigated, but it would have been more efficient (in terms of CPU cycles) if the browser had just parsed a single bundle instead of recursively traversing an entire dependency graph all over again.

For small sites (with equally small dependency graphs), this would not matter at all. But I would imagine that heavy web apps such as those of Facebook and Spotify would slow down to a crawl if they used ES modules over bundles instead, even with caching enabled.

Caching only goes as far as mitigating network round trips. For large dependency graphs, traversing while parsing syntax can prove to be quite taxing on the CPU. Even more so for mobile devices.

This is why code bundling has become a necessary build step for large applications. Again, smart CDNs can only go as far as mitigating network round trips. It is still more efficient (and battery-friendly) to load a big bundle rather than a deep dependency graph.

Or, use preload links to preload all your JS, and use the await import function as needed, so the browser preloads and caches all your JS, but loads only the minimum first.

I suppose that could work. I can see the appeal behind your method. It's definitely a much better developer experience without the build steps.

Personally, I still wouldn't rely on this behavior if I were to write a large application. Browser support for dynamic imports aside, there just seems to be more runtime overhead with ES modules than if I had just moved the import overhead at compile-time as a build step.

But then again, this is an unfortunate side effect of the "modern Web", where bundling code is just more network- and CPU-efficient than the more elegant ES modules. 😕

Don't get me wrong, I'd love to see a future where the Web is beautifully intuitive and semantic everywhere, but the reality of the situation just deems it otherwise.

ES modules are great, but the current climate of the modern Web forces me to add a tedious build step because it's a "best practice" for network and parser performance.

So yeah... As much as I want to keep my codebases simple like you do, large applications call for such complexities. ES modules are not exactly the most "sCaLaBLe" solution. I'd love to see the day when I'd be proven wrong, though.

Code of Conduct Report abuse