4 ms·

I'm not sure why this would be desirable. Sure, bundlers are slow, but that's what projects like pax [1] are for. Bundlers create one single file instead of the

by est31 8y ago

I'm not sure why this would be desirable. Sure, bundlers are slow, but that's what projects like pax [1] are for. Bundlers create one single file instead of the browser having to download your entire possibly huge dependency tree. Sure, with HTTP/2.0 and the upcoming QUIC or HTTP/3.0 overhead of this is minimized, but it's still not zero. There is also a cognitive overhead of having to configure the server to push all the deps to clients otherwise you have constant back & forth where the client is fetching a file, then the server is answering, then the client is finding out it needs those other files, etc etc. Unless you are using global CDNs, expect latencies to be > 50ms for each such step, if not hundreds of ms, and this times the depth of your dependency graph. Bundlers also do dead code analysis. There are really two solutions to this: either avoid using js dependencies, at which point you won't need npm or pika or whatever, or use bundlers. [1]: https://github.com/nathan/pax https://github.com/nathan/pax

treve 8y ago
One major benefit is that for any given page in your application, you probably don't need the entire bundle. This is not really true for SPA's, but I hope that's a trend that will eventually sizzle out again except for specialized cases. Just grabbing what you need can have significant benefits. I agree with the latency problem though, it would be nice to have a HTTP/2 or HTTP/3 server that has a basic understanding of the JS dependency tree and preemptively push the entire tree.
- plausibilities 8y ago
  Here's the problem I'm struggling with: 1. Typically, you only ever care about minimizing bundle size in cases where latency is consistently questionable 2. In those cases, whatever UI you're supporting is likely then not meant for latency-sensitive operations, and thus the overall workflow tends to have low state complexity 3. Just how much actual value is added in those scenarios by having the ESM workflow specifically in conjunction with importable NPM modules? I'm sure you can think up some contrived use cases but I'm just not seeing any particularly compelling ones.
  - s_y_n_t_a_x 8y ago
    No it's not just latency. In fact, that's not even the most important factor. On mobile devices if the script is too large, it will freeze while parsing.
- infinite8s 8y ago
  > This is not really true for SPA's, but I hope that's a trend that will eventually sizzle out again except for specialized cases. I suspect we'll see the opposite, with people building desktop type applications and deploying through the browser (especially with the growth of wasm)
- Can_Not 8y ago
  nuxtjs and webpack4 are actually automatically bundling dependencies so that libraries are automatically included only on pages that use them.
derefr 8y ago
You probably won't end up with a dependency tree. Remember development in 2007? Remember this? <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script> Under ESM, each of your dependencies could go back to being a (CDN or /vendor-directory) hosted "release." The release would have been packed together into a single JS file + a single CSS file by its developer, when it was published. There would be no reason to further run a bundler just to turn ~5 such pairs of files into one pair. Over HTTP2/3 that difference is negligible. It's non-negligible for "thousands of dependencies", of course, but nobody would be doing that. "Thousands of dependencies" is for library development, not for library release packaging. NPM (or Pika) is still useful under such a paradigm, for the same reason Cargo or Bundler or Pip or Mix or whatever other tools are useful: these tools let you specify your direct dependencies using symbolic version constraints, and then retrieve+update+lock those dependencies. This is helpful whether your direct dependencies are "baked-down" release packages or raw deep-dep-tree source.
- s_y_n_t_a_x 8y ago
  That's worse because you lose the ability to "tree-shake". It would go back to importing all of Underscore on a CDN versus bundling the few functions you need into the main bundle.
  - GordonS 8y ago
    OTOH, if you use a "standard" library from a CDN, it's quite possible that the end user already has it cached.
    - s_y_n_t_a_x 8y ago
      That never really works out in practice when there's so many versions and then you're at the disposal of a public CDN, which can be the bottleneck, especially when it's critical code. Sure you can fallback to local copies, but that just means your app hung there for X amount of time, and the added complexity of adding fallback logic. Plus if you look at the size of these libraries, especially utility libraries (date-fns, underscore, etc) they are huge, and you usually only need a few functions. Relying on cache will never be a bigger benefit than tree-shaking. Sure you could manually try to extract those functions, but that's a much much worse developer experience.
simplify 8y ago
How does pax compare to fastpack? https://github.com/fastpack/fastpack https://github.com/fastpack/fastpack

by est31 8y ago

treve 8y ago

One major benefit is that for any given page in your application, you probably don't need the entire bundle. This is not really true for SPA's, but I hope that's a trend that will eventually sizzle out again except for specialized cases. Just grabbing what you need can have significant benefits. I agree with the latency problem though, it would be nice to have a HTTP/2 or HTTP/3 server that has a basic understanding of the JS dependency tree and preemptively push the entire tree.

plausibilities 8y ago
Here's the problem I'm struggling with: 1. Typically, you only ever care about minimizing bundle size in cases where latency is consistently questionable 2. In those cases, whatever UI you're supporting is likely then not meant for latency-sensitive operations, and thus the overall workflow tends to have low state complexity 3. Just how much actual value is added in those scenarios by having the ESM workflow specifically in conjunction with importable NPM modules? I'm sure you can think up some contrived use cases but I'm just not seeing any particularly compelling ones.
- s_y_n_t_a_x 8y ago
  No it's not just latency. In fact, that's not even the most important factor. On mobile devices if the script is too large, it will freeze while parsing.
infinite8s 8y ago
> This is not really true for SPA's, but I hope that's a trend that will eventually sizzle out again except for specialized cases. I suspect we'll see the opposite, with people building desktop type applications and deploying through the browser (especially with the growth of wasm)
Can_Not 8y ago
nuxtjs and webpack4 are actually automatically bundling dependencies so that libraries are automatically included only on pages that use them.

derefr 8y ago

You probably won't end up with a dependency tree. Remember development in 2007? Remember this? <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script> Under ESM, each of your dependencies could go back to being a (CDN or /vendor-directory) hosted "release." The release would have been packed together into a single JS file + a single CSS file by its developer, when it was published. There would be no reason to further run a bundler just to turn ~5 such pairs of files into one pair. Over HTTP2/3 that difference is negligible. It's non-negligible for "thousands of dependencies", of course, but nobody would be doing that. "Thousands of dependencies" is for library development, not for library release packaging. NPM (or Pika) is still useful under such a paradigm, for the same reason Cargo or Bundler or Pip or Mix or whatever other tools are useful: these tools let you specify your direct dependencies using symbolic version constraints, and then retrieve+update+lock those dependencies. This is helpful whether your direct dependencies are "baked-down" release packages or raw deep-dep-tree source.

s_y_n_t_a_x 8y ago
That's worse because you lose the ability to "tree-shake". It would go back to importing all of Underscore on a CDN versus bundling the few functions you need into the main bundle.
- GordonS 8y ago
  OTOH, if you use a "standard" library from a CDN, it's quite possible that the end user already has it cached.
  - s_y_n_t_a_x 8y ago
    That never really works out in practice when there's so many versions and then you're at the disposal of a public CDN, which can be the bottleneck, especially when it's critical code. Sure you can fallback to local copies, but that just means your app hung there for X amount of time, and the added complexity of adding fallback logic. Plus if you look at the size of these libraries, especially utility libraries (date-fns, underscore, etc) they are huge, and you usually only need a few functions. Relying on cache will never be a bigger benefit than tree-shaking. Sure you could manually try to extract those functions, but that's a much much worse developer experience.

simplify 8y ago

How does pax compare to fastpack? https://github.com/fastpack/fastpack https://github.com/fastpack/fastpack