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.
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.
I don’t have a lot of experience in Node development
From looking at a few, my concern is they are inherently bloated
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.