7 ms·
Just what I want in a framework. Thousands of libraries with functional overlap, each tested in a small number of real use cases and having a large number of un
by aneth4 13y ago
Just what I want in a framework. Thousands of libraries with functional overlap, each tested in a small number of real use cases and having a large number of undiscovered bugs, none of which is flexible enough to solve my problem or has a large community to maintain it.
In time, node users will realize the pain of abandoned library dependencies and the overhead of researching alternatives and grinding through bugs and functional gaps in poorly planned libraries.
I like node, but the library situation is a disaster. I'll take monolithic, well designed, tested, and popular over a huge choice of one off libraries any day.
- karterk 13y agoI'll take monolithic, well designed, tested, and popular over a huge choice of one off libraries any day. Been there, done that. And, it's terrible. Monolithic things try to do too many things. It's fine if you grow along with it but a few years down the line - a beginner will find it very difficult to get started and manoeuvre around. Small, composable things are better. If something is popular, it will be forked and maintained. Also, monolithic things tend to slow down over time (in terms of keeping up) as they start accruing so much baggage.
- aneth4 13y agoSmall and composable things that are popular and well tested is great. That is not what you get from something like the wild-west of node. Perhaps your ideal is Linux, with small composable commands. How many of those commands copy or move a file? Pretty much one - that's because lots of unexpected things go wrong, and we need one good implementation instead of 500 shitty ones. Rails is actually moving towards being a pre-installed collection of small composable things, much like a *nix distribution. Small and composable is great. Everyone implementing cp is not.