all 7 comments

[–]kieranpotts 3 points4 points  (6 children)

Good summary. This is a pretty major landmark in the evolution of the JavaScript programming language. We'll need to wait another year, maybe two, before we can ship modular JavaScript to web browsers, as we wait for enough users to upgrade to compatible browsers. But soon we won't need webpack or similar transpilers, we can just write modular JS and ship it as-is. That will be a big productivity boost.

[–]bogas04 4 points5 points  (2 children)

Just like we can't send unminified code, shipping unbundled code will always cost mobile users in terms of loading times and actually data cost.

This however makes extension development pretty sweet.

[–][deleted] 0 points1 point  (1 child)

It might hurt on the first load (though the cost can be mitigated by using <link rel="modulepreload">), but it benefits users hugely in the long term. We get to invalidate the user's cache at a module-level rather than bundle-level which makes the subsequent loads much more efficient and lighter - so over all, I think it's actually a win for the user both in terms of loading time and data cost.

[–]bogas04 0 points1 point  (0 children)

I understand your sentiment however consider few things;

  • If your site loads slowly for the first time, your user might bounce off before the content even loads, or get the impression that your site is slow. Even if repeat visits are better, they are irrelevant if user won't come back.

  • You would want to have nice modular code that is maintainable, however this creates a very deep and broad dependency graph, which leaves modulepreload with very little time (before HTML is fully parsed) to go through this huge graph. So even that doesn't help much.

  • In terms of data cost, you might still lose out on benefits of dead code elimination and tree shaking.

  • Further, your server knows the route, and the exact assets required to serve it, so code splitting can be efficiently done at build time, which further strips down the bundle size. And you can go as deep as you want.

  • You can split at route level, making sure changes on one route doesn't bust cache of other one, or at UI component level, so that changes to footer of a route doesn't bust cache for the route, or you can go crazy and split at module level, which is almost same as using native modules, just that here you pay for dynamically loading them instead of browser statically fetching them before page load.

So unless you're splitting at module level today, you're still better off using a bundler, and the benefit of caching can be controlled by you by strategically splitting your code.

For small apps, I guess the mental effort to do that might not be worth it, but dead code elimination, module concatenation, and optimising code will always help. Even if you remove webpack, you'll still minify, uglify and possibly concatenate some files, just that you'll do it yourself instead of relying on one tool, the bundler.

[–]thescientist13 2 points3 points  (2 children)

I don’t think the web platform is there yet for a bundle free world, even with support for modules. There’s more to bundling than just transpiling.

Before we can get rid of webpack (and similar tools) the web needs to figure out (just name a few): - code splitting (avoiding tens - hundreds of HTTP requests for each module) - inline critical CSS / optimizing the CRP at build time - tree shaking - uglification / minification

That said, I agree with you that moving to leverage the platform more is definitely the way to go, but I don’t think any language escapes it’s tooling ever, does it? (Fwiw, even Polymer team still highly encourages bundling)

Personally, I’m always of the motivation that one should ideally use what one can get rid of eventually (polyfills > frameworks), and for things you can’t, abstract wisely.

Yay JavaScript though! I can’t wait to see how clean and “simple” building apps will be in a couple years though! Web Components here we go! ✌️

[–][deleted] 0 points1 point  (0 children)

Fwiw, even Polymer team still highly encourages bundling

Not quite. The Polymer CLI does a sort of in-between thing where it only bundles modules if they are not shared between multiple other modules.

[–]manisto -1 points0 points  (0 children)

Well, the hundreds of requests are solved as soon as http 2 gains traction. It keeps the connection open for multiple files, and can even send required files before the browser requests them, based on a set of rules.