The problem is this approach that somehow finds a monolith with 694 dependencies acceptable, yet turns around and praises node.js modules for being so "bite-sized".
>What did bite me was the apparent "infinity" of possibilities at each step of the development process. Whenever I need a feature - there's 20 different libs there to help you. Which one should I pick ?
This kind of choice paralysis used to bite me too. What totally fixed it for me was really weighing the consequences of adding a dependency every time I'd consider one. Most of my production services are a couple hundred lines and have fewer than 5 dependencies (of which, half are boilerplate that every other service has).
Rails is great at big CRUD MVC applications. If you want a Rails-like app in Node.js, you should start with an opinion "skeleton" MEAN/MVC framework rather than re-implementing rails and all its dependencies with every application.
I loved node when it came out. I did a lot of experimental projects with it. I also liked npm and the ability to use modules...
But at some point, this all turned into dependency insanity.
It didn't bite me as much, because i've never used node for production apps, but I imagine it has the potential to be a serious issue, when your bread-and-butter app depends on 694 other libraries.. who knows what lurks in them...
What did bite me was the apparent "infinity" of possibilities at each step of the development process. Whenever I need a feature - there's 20 different libs there to help you. Which one should I pick ?