3 ms·

> The vast majority of node dependencies are for testing frameworks and other tools that are never shipped to the customer. So just to test I installed Django

> The vast majority of node dependencies are for testing frameworks and other tools that are never shipped to the customer. So just to test I installed Django in a new virtualenv. I get a testing framework, and ORM, CORS, authentication, data validation, hot reloading and much more. It's three dependencies: django, asgiref and sqlparse. Part of it is that Django just builds a ton of stuff on their own, but they also have the Python stdlib to build on. As others mentioned you have things like Boost, the Go standard library, or even libc (of which there are multiple implementations). There's no reason why you couldn't have a JavaScript standard library, or multiple. They don't have to be shipped with the browsers, in fact I think that would be a bad idea. So when you start a new JavaScript project, you pull in your favorite standard library and when you ship your code, the bundler or whatever it's called could analyze your code pull out the relevant bits of the standard library and only include the bits you need.

com2kid 3y ago
> As others mentioned you have things like Boost, the Go standard library, or even libc (of which there are multiple implementations). There's no reason why you couldn't have a JavaScript standard library, or multiple. They don't have to be shipped with the browsers, in fact I think that would be a bad idea. So when you start a new JavaScript project, you pull in your favorite standard library and when you ship your code, the bundler or whatever it's called could analyze your code pull out the relevant bits of the standard library and only include the bits you need. That is kinda-sorta how things work, except JS devs like to split code up into smaller modules. https://www.npmjs.com/package/jest?activeTab=dependencies https://www.npmjs.com/package/jest?activeTab=dependencies has 4 dependencies, if you look at @jest/core a lot of its dependencies are in fact other parts of the same project. The lack of batteries included means there is a lot more room for diversity, if someone wants to write a new server to compete with express (and plenty of people have) they can follow the same middleware API standard and you can swap our your existing web server for another one but your ORM will still work! Also a minimum viable JS Rest endpoint is literally 4 or 5 lines of code. Getting cors working is 2 or 3 lines more (based on if you count the import statement as a LoC). Adding schema validation to an endpoint is another 2 LoC. The number of concepts needed to be understood to setup an endpoint in Node land is minimal, and you can then build out whatever tools you want on top. If you want a batteries included framework, there are also plenty of those, from fullstack systems Sveltekit and Next.js to multiple starter templates for backend services that give you whatever tools you wanted. People go "Python has Django" and there are huge advantages to having a single golden path, but Node has a richness in the ecosystem that lets people start off small with and choose what tooling is best as their projects grow. And at the end of the day, an ORM is going to require N lines of code, it doesn't matter if it is bundled with a framework of it is an external dependency.

com2kid 3y ago

> As others mentioned you have things like Boost, the Go standard library, or even libc (of which there are multiple implementations). There's no reason why you couldn't have a JavaScript standard library, or multiple. They don't have to be shipped with the browsers, in fact I think that would be a bad idea. So when you start a new JavaScript project, you pull in your favorite standard library and when you ship your code, the bundler or whatever it's called could analyze your code pull out the relevant bits of the standard library and only include the bits you need. That is kinda-sorta how things work, except JS devs like to split code up into smaller modules. https://www.npmjs.com/package/jest?activeTab=dependencies https://www.npmjs.com/package/jest?activeTab=dependencies has 4 dependencies, if you look at @jest/core a lot of its dependencies are in fact other parts of the same project. The lack of batteries included means there is a lot more room for diversity, if someone wants to write a new server to compete with express (and plenty of people have) they can follow the same middleware API standard and you can swap our your existing web server for another one but your ORM will still work! Also a minimum viable JS Rest endpoint is literally 4 or 5 lines of code. Getting cors working is 2 or 3 lines more (based on if you count the import statement as a LoC). Adding schema validation to an endpoint is another 2 LoC. The number of concepts needed to be understood to setup an endpoint in Node land is minimal, and you can then build out whatever tools you want on top. If you want a batteries included framework, there are also plenty of those, from fullstack systems Sveltekit and Next.js to multiple starter templates for backend services that give you whatever tools you wanted. People go "Python has Django" and there are huge advantages to having a single golden path, but Node has a richness in the ecosystem that lets people start off small with and choose what tooling is best as their projects grow. And at the end of the day, an ORM is going to require N lines of code, it doesn't matter if it is bundled with a framework of it is an external dependency.