4 ms·

The assumption of many npm packages is that you have a bundler and I think rightly so because that leaves all options open regarding polyfilling, minification a

The assumption of many npm packages is that you have a bundler and I think rightly so because that leaves all options open regarding polyfilling, minification and actual bundling.

jacobsenscott 2y ago
polyfilling and minification both belong on the ash heap of js development technologies.
- benregenspan 2y ago
  I would agree with you if minification delivered marginal gains, but it will generally roughly halve the size of a large bundle or major JS library (compared to just gzip'ing it alone), and this is leaving aside further benefits you can get from advanced minification with dead code removal and tree-shaking. That means less network transfer time and less parse time. At least for my use-cases, this will always justify the extra build step.
  - out-of-ideas 2y ago
    I really miss the days of minimal/no use of JS in websites (not that I want java-applets and Flash LOL). Kind of depressing that so much of the current webdesign is walled behind javascript.
    - brianwawok 2y ago
      I don’t. Always Craigslist and hacker news to give that 2004 UX.
  - sandwitches 2y ago
    Cool, I can download 20 MB of JavaScript instead of 40. Everyone uses minification, and "web apps" still spin up my laptop fans. Maybe we've lost the plot.
    - deleted 2y ago
      [deleted]
- girvo 2y ago
  I wish. When our bundles are being deployed globally and regularly opened on out of date phones and desktops, it can't be avoided yet.
  - lostmsu 2y ago
    There might be a negative incentive in play: you may be compressing packages, but having your dependencies available at the tip of *pm install bloats overall size and complexity beyond what lack of bundling would give you.
spankalee 2y ago
The assumption shouldn't be that you have a bundler, but that your tools and runtimes support standard semantics, so you can bundle if you want to, or not bundle if you don't want to.

The assumption of many npm packages is that you have a bundler and I think rightly so because that leaves all options open regarding polyfilling, minification and actual bundling.

jacobsenscott 2y ago

polyfilling and minification both belong on the ash heap of js development technologies.

benregenspan 2y ago
I would agree with you if minification delivered marginal gains, but it will generally roughly halve the size of a large bundle or major JS library (compared to just gzip'ing it alone), and this is leaving aside further benefits you can get from advanced minification with dead code removal and tree-shaking. That means less network transfer time and less parse time. At least for my use-cases, this will always justify the extra build step.
- out-of-ideas 2y ago
  I really miss the days of minimal/no use of JS in websites (not that I want java-applets and Flash LOL). Kind of depressing that so much of the current webdesign is walled behind javascript.
  - brianwawok 2y ago
    I don’t. Always Craigslist and hacker news to give that 2004 UX.
- sandwitches 2y ago
  Cool, I can download 20 MB of JavaScript instead of 40. Everyone uses minification, and "web apps" still spin up my laptop fans. Maybe we've lost the plot.
  - deleted 2y ago
    [deleted]
girvo 2y ago
I wish. When our bundles are being deployed globally and regularly opened on out of date phones and desktops, it can't be avoided yet.
- lostmsu 2y ago
  There might be a negative incentive in play: you may be compressing packages, but having your dependencies available at the tip of *pm install bloats overall size and complexity beyond what lack of bundling would give you.

spankalee 2y ago

The assumption shouldn't be that you have a bundler, but that your tools and runtimes support standard semantics, so you can bundle if you want to, or not bundle if you don't want to.