Reading up on all these Node.JS posts I'm surprised at just how many gotchas the platform has and how there's no single standardized way to solve them.
It's not encouraging stuff. On paper the platform looks decent but aside from a few use cases it seems that there's more hype than it merits.
I have personally hit both while trying to build (not even write!) Node software.
The former bug is an example of "broken by design", and it's interesting that it remains open (therefore admitting that it is a problem?), but no solution came yet. Although I believe Yarn doesn't have it - but then why doesn't the entire Node community move to Yarn?
The latter bug is, to me, just insane. Several dozen bug reports (and even more if you google for the error message); and when it shows up, it can be an outright blocker. It was for me - I plainly couldn't build the software that I wanted, and no workarounds helped. And no fix, 1.5 years later and counting.
That's why I said "Node ecosystem". NPM is definitely a part of said ecosystem, and it still the de facto standard package manager (which, also - why, when there's Yarn?).
It's been the single least productive coding environment of my life. When you're taking care of large systems of backend servers, Javascript is pretty far down on the list of languages I'd pick to use. Add to that Node's explicit handling of asynchronous operations instead of just blocking and waiting.
Also, it seems to get worse the more code you have. I'm sure it's possible to write really good readable javascript in large codebases, and the same for Node, I just haven't seen it done.
Another subject the author brings up is "the ecosystem". Javascript has so many libraries that keeping up with them, their updates, and using them in a canonical way throughout a large codebase is a full-time job for at least one engineer.
> Another subject the author brings up is "the ecosystem". Javascript has so many libraries that keeping up with them, their updates, and using them in a canonical way throughout a large codebase is a full-time job for at least one engineer.
Same, and same. It's very research-y. It is an incredible place to work if you treat your development process like research anyway, but if you just want to jam through production cycles I would pick Python or something stable.
I would say research-y development: building with the understanding that some percentage of the time you will be building only to learn.
Also, there is a lot of research in design, and I do design and development interleaved. I could carve out slices of that work to call "pure development" or "pure research", but for me, design, engineering, and research are all part of one tightly coupled process. I call that process development for shorthand. Is there a better word?
It's not encouraging stuff. On paper the platform looks decent but aside from a few use cases it seems that there's more hype than it merits.