4 ms·

The JS ecosystem has moved away from massive monolithic packages due to bundle size constraints. Unfortunately, JS code has a lot of extra constraints placed on

The JS ecosystem has moved away from massive monolithic packages due to bundle size constraints. Unfortunately, JS code has a lot of extra constraints placed on it since it has to be instantly performant over the wire. Something desktop apps don't have to deal with! jQuery and Lodash could be considered "secondary stdlib" packages. Lodash for various data functions, and jQuery for dom manipulation functions. Now that other frameworks are more common and the basic stdlib is larger, many projects have migrated away from them to improve bundle size. (As an example, pulling in one lodash function tends to pull in lots of other functions from within lodash, unnecessarily inflating the amount of code sent to the browser.)

com2kid 3y ago
Another advantage of this, at last for the backend, is that Node itself has a small footprint. Compared to the JVM, Node is tiny. It does some IO stuff and some eventing stuff and not much else. For the front end, ideally tree shaking is used, and even fancier build systems create code that doesn't pull down dependencies until they are actually needed at runtime.
bathtub365 3y ago
Why not just strip out unused code? This has existed in other toolchains for years.
- thephyber 3y ago
  Tree shaking exists in build tools, but (1) libraries like Lodash have functions that use many other functions in the same library (for DRY reasons) and (2) the issue with NPM libraries is that they generally pull in all dependencies and Dev dependencies, not just an efficient dist / build minimal code set.
  - 8n4vidtmkvmk 3y ago
    Fwiw I strip out my dev deps before publishing. I've started bundling in the prod deps and stripping them too. That way if I need like 5 random functions from 5 random packages the end result just includes the 5 funcs and has 0 deps. It avoids version issues too. And I don't minify anymore so it's very readable.

com2kid 3y ago

Another advantage of this, at last for the backend, is that Node itself has a small footprint. Compared to the JVM, Node is tiny. It does some IO stuff and some eventing stuff and not much else. For the front end, ideally tree shaking is used, and even fancier build systems create code that doesn't pull down dependencies until they are actually needed at runtime.

bathtub365 3y ago

Why not just strip out unused code? This has existed in other toolchains for years.

thephyber 3y ago
Tree shaking exists in build tools, but (1) libraries like Lodash have functions that use many other functions in the same library (for DRY reasons) and (2) the issue with NPM libraries is that they generally pull in all dependencies and Dev dependencies, not just an efficient dist / build minimal code set.
- 8n4vidtmkvmk 3y ago
  Fwiw I strip out my dev deps before publishing. I've started bundling in the prod deps and stripping them too. That way if I need like 5 random functions from 5 random packages the end result just includes the 5 funcs and has 0 deps. It avoids version issues too. And I don't minify anymore so it's very readable.