5 ms·

Note that since ES6 imports are statically defined, the browser can find and begin to download dependent files before even parsing the actual JS. They could eve

Note that since ES6 imports are statically defined, the browser can find and begin to download dependent files before even parsing the actual JS. They could even start downloading dependent files in parallel before the first file is fully downloaded. But bundling will still probably be faster and will probably continue to be a mainstay of production web apps, just like minification already is.

Arnavion 10y ago
>Note that since ES6 imports are statically defined, the browser can find and begin to download dependent files before even parsing the actual JS. I think you meant executing the actual JS. Finding the imports requires parsing the file, and imports can be anywhere in the file as long as they're at the top level.
- domenicd 10y ago
  It depends. For HTML all browsers do a form of "preparsing" where they do simplistic string searches for things that look like URLs and start speculatively fetching based on that. You could imagine a similar pass for JS modules.
  - Arnavion 10y ago
    Ah, that's cool.
  - bzbarsky 10y ago
    Firefox doesn't do simplistic string searches, for what it's worth. It actually tokenizes the HTML and kicks off loads from tokenization. If someone then misuses document.write the token stream has to be thrown out and things have to be retokenized, but that's rare in practice. The tradeoff is better accuracy of the preloader and not having to go through the text twice unless someone is misusing document.write.
MatthewPhillips 10y ago
You still have to fetch a module before you know it's dependencies. So if A depends on B which depends on C, you must fetch those sequentially. With a deep dependency graph this will be a problem.
WorldMaker 10y ago
Bundling may not necessarily be faster with HTTP/2 and proper cache controls.
- mevile 10y ago
  Right, with HTTP2 and caching, you'd actually save on bandwidth if you didn't have to deploy a new build whenever an individual file changed.
- MatthewPhillips 10y ago
  I don't see a practical difference between bundling and server push to the developer. You are still using tooling that traces your dependency graph and produces... something. In the case of a bundler it produces a concatenated script and in the case of http push it produces a list of files that should be sent with a particular route. To the developer, why should the latter be preferred over the former?
  - WorldMaker 10y ago
    From a developer side, at least, HTTP/2+caching (with or without server push) is preferential in that the browser handles everything (and knows what it needs) versus bundling which is a build process of some sort. From a developer perspective, producing the only the dependency graph is still going to be faster and need less overall IO than building a bundle. You can get a sense of it today with jspm dep-cache versus jspm bundle times.
  - rajivm 10y ago
    Three reasons off the top of my head: - Smaller cacheable objects -- every change you make doesn't invalidate the whole "bundle". - If there are many permutations of the optimal bundles: different browsers, different pages use different scripts, etc. - The browser does not need to wait for the "full bundle" to download to execute your app/site -- it can start once the first necessary assets are loaded. In one project I worked on, we had 3 bundles: - early load (inside the head tag) - deferred load secondary (after body tag, for the other site pages) - deferred load primary (after the body tag, for the 'hot' pages of the site) With a optimal http/2.0 setup, we wouldn't need to make these never fully optimal bundles.

Arnavion 10y ago

>Note that since ES6 imports are statically defined, the browser can find and begin to download dependent files before even parsing the actual JS. I think you meant executing the actual JS. Finding the imports requires parsing the file, and imports can be anywhere in the file as long as they're at the top level.

domenicd 10y ago
It depends. For HTML all browsers do a form of "preparsing" where they do simplistic string searches for things that look like URLs and start speculatively fetching based on that. You could imagine a similar pass for JS modules.
- Arnavion 10y ago
  Ah, that's cool.
- bzbarsky 10y ago
  Firefox doesn't do simplistic string searches, for what it's worth. It actually tokenizes the HTML and kicks off loads from tokenization. If someone then misuses document.write the token stream has to be thrown out and things have to be retokenized, but that's rare in practice. The tradeoff is better accuracy of the preloader and not having to go through the text twice unless someone is misusing document.write.

MatthewPhillips 10y ago

You still have to fetch a module before you know it's dependencies. So if A depends on B which depends on C, you must fetch those sequentially. With a deep dependency graph this will be a problem.

WorldMaker 10y ago

Bundling may not necessarily be faster with HTTP/2 and proper cache controls.

mevile 10y ago
Right, with HTTP2 and caching, you'd actually save on bandwidth if you didn't have to deploy a new build whenever an individual file changed.
MatthewPhillips 10y ago
I don't see a practical difference between bundling and server push to the developer. You are still using tooling that traces your dependency graph and produces... something. In the case of a bundler it produces a concatenated script and in the case of http push it produces a list of files that should be sent with a particular route. To the developer, why should the latter be preferred over the former?
- WorldMaker 10y ago
  From a developer side, at least, HTTP/2+caching (with or without server push) is preferential in that the browser handles everything (and knows what it needs) versus bundling which is a build process of some sort. From a developer perspective, producing the only the dependency graph is still going to be faster and need less overall IO than building a bundle. You can get a sense of it today with jspm dep-cache versus jspm bundle times.
- rajivm 10y ago
  Three reasons off the top of my head: - Smaller cacheable objects -- every change you make doesn't invalidate the whole "bundle". - If there are many permutations of the optimal bundles: different browsers, different pages use different scripts, etc. - The browser does not need to wait for the "full bundle" to download to execute your app/site -- it can start once the first necessary assets are loaded. In one project I worked on, we had 3 bundles: - early load (inside the head tag) - deferred load secondary (after body tag, for the other site pages) - deferred load primary (after the body tag, for the 'hot' pages of the site) With a optimal http/2.0 setup, we wouldn't need to make these never fully optimal bundles.