I've never written anything on node.js, but that's the only argument that's ever given me pause.
To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.
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.
Should we collectively eschew what's possible due to individual language gripes?
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.
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?
Exactly what I asked.
> 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.
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.
History repeats itself.
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...
https://news.ycombinator.com/item?id=15090278
TL;DR: Writing JavaScript for the browser won't really help you write good JavaScript for the server.
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.
What do you mean? The fs module shipped with node is pretty much just a wrapper for libc. Hell, it even links to the open(2) manpage in the docs for usage information.
What's finally got me writing way more Javascript than I'd like to is React Native. It's by far the easiest way I know of to share code between iOS and Android, it papers over a lot of Android's irritating/broken UI bits (introducing others, but overall improving the situation), and you actually can share much of your code (practically everything but the UI layer) with a web client—and even... spits... Electron. RN's performance isn't even terrible, especially compared to cross-platform mobile frameworks that have come before it (and to Electron spits)
Hopefully Webassembly will save us in another couple years, and we'll be able to do the same thing in any of several much better languages.
[EDIT] though definitely keep your sanity and use Typescript. I'd have probably jumped off a bridge by now if I were having to do all this in actual JS, of any flavor.
Also, it 'helps' if both server and client are single-threaded, because then, you can use similar solutions on both server and client (even if they sometimes aren't the most pleasant approach for solving your domain)
I hope that Web Assembly will take of and get a decent interface to the DOM, allowing developers to pick other languages in the role that JavaScript now has.
Today, I do front-end React stuff as well as back-end servers with Node JS. I have been happy with it so far.
With some type-system like Flow or TypeScript, you can manage huge projects in Node JS.
I happen to like the community, CLI tools written in Node, and the plethora of open source libraries built on top of Node.
This also has a downside. Your libraries can get outdated quite fast, you would have to keep up with new language syntaxes etc., and remember which syntax is supported by which version of Node etc.
But so far, I think Node is headed in the right direction.