[ranguna]

I personally like to have a few dependencies in my projects and a simple runtime vs having a monster of a language with a huge amount a unrelated and specialised APIs (java) and still need to install some additional dependencies.

I think the barebone nature of nodejs and javascript is what makes it great. If you don't like it, don't use it, there are other languages and runtimes out there and node is a really good fit for a lot of people.

[1_player]

I don't. I'd rather trust the tens of thousands of developers working on the core language and core stdlib, than on a dependency some random guy in Albania maintains on his spare time.

Or in the case of the JS ecosystem, you might only use established dependencies, which in turn use dozens more which in turn use dozens more, and the probability that there's a dependency some random guy in Albania maintains very quickly approaches 100%.

Have we already forgotten left-pad?

[runarberg]

If you have a problem with library written and maintained by a random guy in Albania you have the option of not using it. If a functionality is so niche that you can only find one fit in the entire npm ecosystem, I doubt this functionality will ever make it to the standard lib of a non-node runtimes.

Personally I like dependencies written and maintained by a random guy in Albania on their spare times. And I would use it when making fun stuff at home. I might even open an issue or a pull request. Dealing with a random guy in Albania sounds way more fun then dealing with a language committee in Silicon Valley.

[Octoth0rpe]

How many people audit their dependency authors more than 1 level deep? That's the problem: I know who wrote all of my first level dependencies (react, react-router, redux, reacstrap, etc). I don't know who wrote _their_ dependencies, and the 3rd level, 4th level. And I don't think anyone has the time to adequately evaluate that every time a dependency's version gets bumped given how deep the graph goes.

[WA]

I'm like you. I want as few dependencies as possible. I liked this about PHP: You could get very far without any dependencies at all.

For a toy project, pull in some dependencies. For a more serious project that requires to do due diligence on every dependency you pull in, it gets annoying very quickly.

Also, I kinda dread all the fast-changing version numbers in the JS ecosystem.

[irrational]

There is nothing stopping you from looking at their code and, after vetting it, copying the code and pasting it into your own local JS files. Now you don’t have to worry about anyone tampering with it after you have vetted it.

[1_player]

Sure, I'll do that next time I'm at work, I'll tell the frontend dev running `npm install next` to spend the next 6 months doing a code review of the 258 dependencies in the tree. Boss will have to wait.

https://npm.anvaka.com/#/view/2d/next

There's dependencies like webpack, and "dependencies" like lodash-sortby, is-number, isarray, diffie-hellman, encoding, is-negative-zero or assert. Who in good faith can argue that those are better served as standalone dependencies maintained by who-knows-who instead of being in a standard library?

I so wish someone had the balls (and good enough OpSec) to inject malware into one of those 5 lines long dependencies, causing hundreds of billions of dollars in damages, and then we'll perhaps do something about it.

[HelloNurse]

In practice, you rely on libraries that are popular and/or written by someone trustworthy. "Vetting" libraries amounts to thorough tests of the complete application.

[BatteryMountain]

Java is not really a good benchmark for having lean build artifacts. It is a monster but it has other desirable qualities.

In .Net land, the dotnet core runtime weighs in at about 30mb (what you'd need to run a production server), the sdk is about 140mb (for development machines and build servers)(once off setup). If you compile a project that depends on 5 other packages, it will only include those 5 packages and a package for your actual project (assuming 1 project per solution, else n packages for n projects per solution). It boils down to having build artifacts that are super lean, provided you are using the installed runtime on the target machine. You also have the option to package the framework along with your own package, then you don't have to install the runtime on the target machine, and these typically compile down to less than 100mb. It is probably less by now, but I don't use it. You also have the option to bake everything into a single file, much like how Rust does it.

So yeah, I wish more people would play with .Net Core and it's tooling a bit, it's bloody great at moment. Java and it's tooling feels like a behemoth once you get used to the new dotnet tooling.

Take it from somebody that builds build servers and custom tooling (cloning git repo's, building prod binanies, packing them if needed and then move them around (deployment, nuget server etc), all on linux, with C# code) - it is a dream. Calling the the dotnet build tools from my own console apps is a no brainer. My build tools can then be called by other processes in linux like any other cli app, or if I build them as asp.net projects, a simple middleware to intercept calls from nginx to trigger workflows remotely... easy peasy. All while the build tools can talk to Digital Ocean, Azure, Aws via their api's...

[enumjorge]

Simple, and lightweight sound great in theory but some problems are complex enough they they require a lot logic, and that complexity needs to live somewhere, whether it’s your code base or a dependency. Node.JS could provide its libraries in a modular way so that you only install what you need. Essentially, that’s how npm works now except that the packages are provided by random people, and often times the work of getting them to work together to form a complete solution to a problem is left as an exercise to the reader.

When everything is broken down to very simple packages, you often end up in a situation where your dependency tree is very deep and now keeping track of which packages you use and vetting them becomes a complex task. Many devs are too trusting of the packages they take a dependency on. Remember that npm package that everyone used but was buried like 3 levels deep in people’s dependency trees, and then maintainer got tired of working on it so he handed it over to someone else who then purposefully injected a vulnerability into it which affected a lot of projects?

> If you don’t like it, don’t use it

Again, simpler said than done. My guess is most of us are working on projects where we don’t/didn’t get to choose the tech stack.