That JavaScript was not designed to work as a *nix (or Windows for that matter) server language. And that any attempts to make it work as a server language are going to include some major workarounds to fit that round peg into a square hole.
You can still make it work; but you can script a web page's interactions in C as well. That doesn't make it the right thing to do.
I'm not a particular fan of JavaScript on the server these days, but when you have a large number of developers who know JavaScript from the front-end world and a language ecosystem that's quite large and relatively robust, I would argue that doing those "major workarounds" (which aren't so major, really) to make server-side JavaScript an accessible option at least very closely resembles the "right thing to do".
Should we collectively eschew what's possible due to individual language gripes?
While I think we agree on points, I also feel like your argument is kind of an overgeneralization. There are knowledge points specific to Node, but developing good code for the browser has similar land mines (referring mainly to asynchrony here) as developing for the server. The problems that exist at the language level, and best practices, are generally applicable to both the server and the browser.
As far as libraries are concerned, it was never my experience that the landscape changed drastically from one to the other. Most of the libraries I look at/use for the front-end today advertise themselves as both for Node and for the browser.
No. We should collectively evaluate competency and correctness of a developer and language for it's best purpose as in any adequately run job interview.
> collectively evaluate competency and correctness of a developer
I'm sorry, is this a dig at Ryan Dahl, or of JavaScript/Node developers in general? I'm having trouble understanding what point you're addressing with this comment.
As for evaluating languages for their "best purpose", I think that's a very complex discussion that doesn't necessarily yield a best (or cost effective/productive) result. And certainly, as we've seen routinely evidenced, using a different language on the server is no panacea.
I'm sorry, what don't you understand?
Complexity is best discussed by those who introduce it.
To be clear: I said js is misplaced on the 'server' side
and is a wart in general when applied in that context.
Any educated comment on these sentiments?
Without clarity on the sentiments themselves there's not a lot to elaborate on without simply fumbling in the dark. If the concern, though, is that, in Node, you live and die by an asynchronous event loop, I'd say that's not a small footgun. I don't think that's in dispute. I'd also say that the presence of footguns doesn't, by itself, disqualify a language from being used in any particular context.
As for JavaScript being a wart, I don't really agree with that sentiment. I think that's attributable to some pretty strong and level-headed language evolution making what was once a very blunt scripting instrument into something somewhat reasonably suited to larger-scale applications.
JavaScript is objectively, demonstrably a badly-designed, error-generating language for which countless libraries, generators, and higher-level languages and frameworks such as Elm and TypeScript have been created to compensate for its shortcomings - and it most especially does not belong on the server side.
It is the poster child for the "If the only tool you have is a hammer..." maxim.
Its appeal derives almost completely from its presence in probably every major browser, where it was placed for DOM manipulation and was stressed way past its design envelope over time, leading to the increasingly dystopian web development landscape we progressively inhabit.
If it is ultimately victorious, it will be in spite of its design, not because of it. Those of us who are old enough to remember will cringe at the pain we endured over the years because of the widely used Intel 808x architecture as it evolved (small/medium/large/huge memory models, and segment registers, anyone?), not because it had the greatest merit, but because of its market penetration.
I really don't disagree on any particular point. I only take issue with the suggestion that it simply shouldn't be an option. In the past I probably would've said the same about PHP, which sits pretty squarely in the same camp as JavaScript for its "victory despite design".
All things considered, a craftsman simply uses a tool to do a job. Often it doesn't involve much fanfare. I wouldn't say that modern JavaScript is quite as blunt an instrument as a hammer, but hey, if you're good with a hammer...
