You made two attacks.
For the first, you say use the right tool for the job, in counter to the idea that maybe using JS front and backend has some synergistic phenomena. But you don’t express much about what makes any other tools more appropriate. It seems like there’s more parity, more equivalence about what we can do with any given language than there has ever been, in spite of their being more languages out there: Swift, Go, Clojure- you’re going to see what looks like fairly common Router library atop a pretty unremarkable HTTP server library wherever you go. Languages are so indistinct, so irrelevant that we have multi-libraries like Unirest.io emerging, literally the same library in 8 different languages. So I don’t get what makes your argument worthwhile- what is it that makes JS inappropriate on the backend, or unsuited, or why are others better? “Node by itself is not a sufficiently good reason,” is not a sufficiently good reason.
Your second attack point, on code sharing, goes a little more into depth on what might make Node inappropriate. It however largely ignores the point, that some people are doing amazingly creative code sharing front end and back. I’d happily volunteer that we have a long long way to go if this is to become a real, valuable thing but with Service Workers on the rise that confluence is going to be able to start getting a whole lot stronger and more obviously compelling if not flat out necessary. In a more simple scale, already hugely practiced, simply pre-rendering pages with the code they’ll ultimately be running- as is popular in React land- is an obvious and titanic win that’s super easy to achieve because of code sharing. Incremental enhancement is, with complex front ends, possible because of code sharing.
But instead of talking about code sharing, this article continues with ill directed beating around the bush. You handily link out rather than say why debugging is hard, and for those who want to read the full article on what that link had to say on debugging, it’s this: “This is mostly a personal opinion, but I found Node.js hard to debug than other languages I have used. It is really easy to get lost in the code and even debugging simple things take long time.” That doesn’t really say much to me. I personally don’t agree. I dunno, Chrome and Firefox Dev Tools and are some of the most amazing, heavily invested most coherent systems I’ve ever been fortunate to see, and at least Chrome is so having Node Inspector available makes all the difference. For “serious production” environments Node’s long been able to do what precious few languages can: bundle a repl, & expose state within the production app, such that you can query and perhaps correct systems at runtime in production: this is a huge focus of Jesper Louis Andersen’s excellent Systems in Production (link below), and is something very few besides Erlang have any game at whatosever.. I think back to history, to Venkman’s Debugger and am in awe, and Venkman was doing just fine for it’s point in time versus VS and Borland’s Turbo C++. As we advance in time and systems, & with the (re-)advent of microservices, debugging becomes less about these debuggers and more about tracing, and thankfully Node has good Zipkin libraries &c to help, so we can deeply observe systems. And that’s up to us, the engineers, to make happen, the showing off of our running time, not our runtimes: we have to expose the compute of business exteriorly.
I dunno mate. This seems like lazy complaining. There’s no meat here. It’s ra-ra jingoistic chest thumping: we have real problems! We need real tools! Ra-ra-ra! It’s hot air. Trying to fake a story that some specific languages are good or not good for specific problems is 99% of the time fakery, quackery. Go has channels, Node has streams: how much difference is that going to make in your world? Well, yeah, some, but most libraries are going to look and behave somewhat similarly anyways. You have to be super on the edge for your tech to start biting you.
“Very large, very sophisticated, and requiring high reliability” is just drawing up boogeymen to scare the kids with, in 99% of cases. There’s no backing, it’s just a pure emotional appeal to elitism, to get people to self-select as having problems somehow vaguely better than what they’ve been told Node can do. For 99% of people Node would be way more than enough. This entire kind of article is a threat to good engineering, to rational and scientific discourse. It rides and feeds a pop-culture mania, is built to build hype. This same practice of applied heresay filled the catcherisms that the Sad State of Web Development practiced (which I have written up, linked), and is not even up to Jenn Schiffer’s level of a technology writeup, In with the New Web Technologies and Out With The Old. Links below; may we ever be moving forwards,
My writeup on Sad State: https://www.reddit.com/r/programming/comments/40jcx5/the_sad_state_of_web_development/cyurh8p