Node succeeded by “simply” being plain JS on V8 with a really small standard library. Easy! No nonsense! Everyone knows this already!
Unfortunately that left everything else up to the community to solve: establishing a “good” standard library, building, debugging, packaging, bundling, dealing with the Node/Browser duality in a meaningful way, creating usable network frameworks, UI frameworks and surely much more.
And they’ve all ended up reinventing that 100 times (like the curse of lisp) in 200 different ways, all recursively based on Node, while standing on the shoulder of non-giants trying to solve one of the other problems mentioned above, possibly standing on the shoulder of someone else who has already tried to solve what you are trying to solve now.
Calling it a clusterfuck probably isn’t sufficient, yet at the same time it seems to work, so it’s simultaneously a sort of modern day miracle.
Disclaimer: have set up quite a few node build-pipelines.
Of npm (the online database of packages) I hate the fact they never forced a clear distinction between package meant to be used only in the backend with node, package meant to be used only on the fe inside a browser, and package which can be used in both. I mean just having a flag for that would be useful, simple and solve a lot of headaches
In what case would an npm package for talking to an external database be actually useful for a frontend project?
I mean, yes, if you're only ever running the tool inside a LAN where that access exists, I suppose it's conceivable...
And plenty of frontend packages that rely on storing state in the browser's window object (Redux etc.) would presumably be a bad idea to use for most backend projects, but no doubt somebody's found a way to make it work. I suppose I'm not disagreeing with you, but the GP kinda has a point too.
A couchDB package perhaps, for which the db supports access via http. Or look at any of over 1000 of sindresorhus' packages - a majority of which are meant to be used in both environments. I've seen plenty of backend services using state trees and mobX style packages.
Unfortunately that left everything else up to the community to solve: establishing a “good” standard library, building, debugging, packaging, bundling, dealing with the Node/Browser duality in a meaningful way, creating usable network frameworks, UI frameworks and surely much more.
And they’ve all ended up reinventing that 100 times (like the curse of lisp) in 200 different ways, all recursively based on Node, while standing on the shoulder of non-giants trying to solve one of the other problems mentioned above, possibly standing on the shoulder of someone else who has already tried to solve what you are trying to solve now.
Calling it a clusterfuck probably isn’t sufficient, yet at the same time it seems to work, so it’s simultaneously a sort of modern day miracle.
Disclaimer: have set up quite a few node build-pipelines.