4 ms·

Ask HN: Are JS bundlers filling a design flaw?

I don’t have a lot of experience in Node development. From a glance, my idea of a bundler is a utility that takes code from software packages and assembles it with autogenerated boilerplates to produce front end applications that can run without any backend dependence. From looking at a few, my concern is they are inherently bloated and fill a gap that really shouldn’t exist. Shouldn’t JS client code be assembled with packages as a standard, something that compiles together without all this filler nonsense? These things typically produce tens of thousands of lines just to add simple libraries.

al2o3cr 4y ago
I don’t have a lot of experience in Node development From looking at a few, my concern is they are inherently bloated Ah yes, a decision reached based on your deep understanding of... oh wait, no. JS bundlers are kind of a hot mess, but try learning a little bit more about things before you decide you're smarter than everyone else working in the space.
- pipeline_peak 4y ago
  Looks like I struck a nerve
  - rantallion 4y ago
    No, they're right. It sounds like you're inexperienced with the tooling and should spend some more time with it. That's not even a criticism, just a truth. Take this: > These things typically produce tens of thousands of lines just to add simple libraries. If you're ending up with a bundle that's thousands of lines long, you've done something wrong. My team use esbuild to bundle code for AWS Lambdas and usually end up with minified code under a couple of kilobytes (though admittedly the bulkier stuff sits in a Lambda layer - since, you know, bundling everything under the sun would be stupid).
    - pipeline_peak 4y ago
      To say it requires a deep understanding is an opinion, not the truth. That was tacked on with a lot of unnecessary snark. All I’m trying to say is bundling is something that shouldn’t really exist. It doesn’t take a veteran to know that.
rektide 4y ago
> my concern is they are inherently bloated This is a non-issue. The overhead is tiny. You can take the time to find out... but development life is really really hard when we let nebulous fear guide us. This fear of bloat is abstract; while perhaps having some small shade of absolute truth in practice the impact is invisible, & more than made up for a dozen times over by the benefits. > and fill a gap that really shouldn’t exist. Here you are onto something. Bundling exists because of necessity more or less, that modules were slow to evolve in JS and started on the server side. Borwsers now structurally can load modules, the language defines what modules are (EcmaScript Modules, ESM), and a decent % of packages ship as ESM. There's some hangups around how to use them- a spec called import-maps[1] is pretty much required, short of painful rewriting of the distributed modules with rewritten hardcoded paths, but the big challenge we're still facing is transport. We're still trying to get fast at sending a lot of small files. Works like early-hints are starting to emerge but for now, bundling our assets into a couple bigger files is still a huge performance win. [1] https://caniuse.com/import-maps https://caniuse.com/import-maps

al2o3cr 4y ago

I don’t have a lot of experience in Node development From looking at a few, my concern is they are inherently bloated Ah yes, a decision reached based on your deep understanding of... oh wait, no. JS bundlers are kind of a hot mess, but try learning a little bit more about things before you decide you're smarter than everyone else working in the space.

pipeline_peak 4y ago
Looks like I struck a nerve
- rantallion 4y ago
  No, they're right. It sounds like you're inexperienced with the tooling and should spend some more time with it. That's not even a criticism, just a truth. Take this: > These things typically produce tens of thousands of lines just to add simple libraries. If you're ending up with a bundle that's thousands of lines long, you've done something wrong. My team use esbuild to bundle code for AWS Lambdas and usually end up with minified code under a couple of kilobytes (though admittedly the bulkier stuff sits in a Lambda layer - since, you know, bundling everything under the sun would be stupid).
  - pipeline_peak 4y ago
    To say it requires a deep understanding is an opinion, not the truth. That was tacked on with a lot of unnecessary snark. All I’m trying to say is bundling is something that shouldn’t really exist. It doesn’t take a veteran to know that.

rektide 4y ago

> my concern is they are inherently bloated This is a non-issue. The overhead is tiny. You can take the time to find out... but development life is really really hard when we let nebulous fear guide us. This fear of bloat is abstract; while perhaps having some small shade of absolute truth in practice the impact is invisible, & more than made up for a dozen times over by the benefits. > and fill a gap that really shouldn’t exist. Here you are onto something. Bundling exists because of necessity more or less, that modules were slow to evolve in JS and started on the server side. Borwsers now structurally can load modules, the language defines what modules are (EcmaScript Modules, ESM), and a decent % of packages ship as ESM. There's some hangups around how to use them- a spec called import-maps[1] is pretty much required, short of painful rewriting of the distributed modules with rewritten hardcoded paths, but the big challenge we're still facing is transport. We're still trying to get fast at sending a lot of small files. Works like early-hints are starting to emerge but for now, bundling our assets into a couple bigger files is still a huge performance win. [1] https://caniuse.com/import-maps https://caniuse.com/import-maps