4 ms·

With some other languages, you have big projects that basically are your secondary stdlib. Boost in C++, Apache Commons in Java, etc. These can reduce a lot of

With some other languages, you have big projects that basically are your secondary stdlib. Boost in C++, Apache Commons in Java, etc. These can reduce a lot of your dependencies down to a single umbrella project who stewards everything. The number of developers who work as maintainers on the packages within these projects is probably comparable to the number of developers working on the same sorts of packages in Node, but they're all working under a single banner, effectively. It's about having dependencies within projects as organizations vs the NPM approach where basically every dependency is it's own project and organization.

noahtallen 3y ago
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.
skydhash 3y ago
They don't even need to be big. They just need to cover a subject, but most of it needs to be the library code instead of a thin wrapper around multiple libraries. Take Carbon, the PHP library. It is centered around date time manipulation and provides a cleaner alternative to the standard library. It only has 6 dependencies, and I figure it wouldn't take long to vet it. The Laravel Framework also has few dependencies, and it was a delight to browse. I created a small Node+Express project, added a few dependencies to handle things like CORS, API Authentication, ORM, and data validation, and my node_modules folder has 300 packages already. Frontend wise, it's worse. I only used a few libraries when I was doing Android, most of them utilities and vendor SDKs. And the contrast is even higher in another project I'm working on. The Java Code takes less than 10 minutes to build, while the frontend code turns the laptop into a jet.
- com2kid 3y ago
  > I created a small Node+Express project, added a few dependencies to handle things like CORS, API Authentication, ORM, and data validation, and my node_modules folder has 300 packages already. Frontend wise, it's worse. The vast majority of node dependencies are for testing frameworks and other tools that are never shipped to the customer. For example, if you install any tool that does pretty command line output, odds are it installs some console UI libraries as a dependency, and odds are they also install a lower level curses like library as a dependency. (Also I've yet to meet a simple ORM system!) Jest is another common offender, much like every other popular testing framework, it is large and complex, and due to the nature of Javascript, it is also more powerful than a lot of the other testing frameworks I have seen (e.g. Jest can do stuff at runtime that Java frameworks need to do at compile time). Those Java frameworks that go in and mock classes are complicated, but they are all hidden behind a "single" dependency. Regarding front end build times, if a frontend website is taking any amount of time to build, something else is wrong (e.g. TypeScript is rebuilding everything one very build). Typical frontend website dev stacks have hot reloading enabled that allows for the site to be refreshed and updated the instant a file is saved. Nicer setups live change the DOM and try to avoid reloading the page unless something touching state management has been altered. (My experience is with React and Svelte alongside TS, Angular may be a different story, not sure!)
Xeoncross 3y ago
...or you can have a solid stdlib like Go where you don't need any dependencies to do everything from encryption to regex to json encoding, image creation and MIME parsing. I wish more languages would invest in their stdlib.
- quickthrower2 3y ago
  JS is burdened by being a browser standard though. But this could be worked on I agree. But then who leads that? With Go there is an owner at least.
- arvinsim 3y ago
  I am pretty sure that Javascript programmers would love to have a better stdlib. But who is going to do it?
circuit10 3y ago
That might be bit better from a security perspective but modularity and code reuse are good things and npm makes them easy I guess it’s a tradeoff

noahtallen 3y ago

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.

skydhash 3y ago

They don't even need to be big. They just need to cover a subject, but most of it needs to be the library code instead of a thin wrapper around multiple libraries. Take Carbon, the PHP library. It is centered around date time manipulation and provides a cleaner alternative to the standard library. It only has 6 dependencies, and I figure it wouldn't take long to vet it. The Laravel Framework also has few dependencies, and it was a delight to browse. I created a small Node+Express project, added a few dependencies to handle things like CORS, API Authentication, ORM, and data validation, and my node_modules folder has 300 packages already. Frontend wise, it's worse. I only used a few libraries when I was doing Android, most of them utilities and vendor SDKs. And the contrast is even higher in another project I'm working on. The Java Code takes less than 10 minutes to build, while the frontend code turns the laptop into a jet.

com2kid 3y ago
> I created a small Node+Express project, added a few dependencies to handle things like CORS, API Authentication, ORM, and data validation, and my node_modules folder has 300 packages already. Frontend wise, it's worse. The vast majority of node dependencies are for testing frameworks and other tools that are never shipped to the customer. For example, if you install any tool that does pretty command line output, odds are it installs some console UI libraries as a dependency, and odds are they also install a lower level curses like library as a dependency. (Also I've yet to meet a simple ORM system!) Jest is another common offender, much like every other popular testing framework, it is large and complex, and due to the nature of Javascript, it is also more powerful than a lot of the other testing frameworks I have seen (e.g. Jest can do stuff at runtime that Java frameworks need to do at compile time). Those Java frameworks that go in and mock classes are complicated, but they are all hidden behind a "single" dependency. Regarding front end build times, if a frontend website is taking any amount of time to build, something else is wrong (e.g. TypeScript is rebuilding everything one very build). Typical frontend website dev stacks have hot reloading enabled that allows for the site to be refreshed and updated the instant a file is saved. Nicer setups live change the DOM and try to avoid reloading the page unless something touching state management has been altered. (My experience is with React and Svelte alongside TS, Angular may be a different story, not sure!)

Xeoncross 3y ago

...or you can have a solid stdlib like Go where you don't need any dependencies to do everything from encryption to regex to json encoding, image creation and MIME parsing. I wish more languages would invest in their stdlib.

quickthrower2 3y ago
JS is burdened by being a browser standard though. But this could be worked on I agree. But then who leads that? With Go there is an owner at least.
arvinsim 3y ago
I am pretty sure that Javascript programmers would love to have a better stdlib. But who is going to do it?

circuit10 3y ago

That might be bit better from a security perspective but modularity and code reuse are good things and npm makes them easy I guess it’s a tradeoff