"I already know it, there are working libraries for my particular problem and the performance is acceptable, I can reuse code in my web client, it doesn't require compilation, it's popular, etc etc."

There are plenty of good reasons.

This post is what we used to call flamebait.

<NodeJS> considered harmful.

By some guy who favours low level languages.

There's no good reason to read this article.

While I'm not convinced that Node is great. It is fine.

The article is hilarious in comparing it to 3 AOT-compiled lower level languages. I would compare it to Ruby, Python and PHP.

Also, I'm unclear on if the benchmark did any IO-bound work that actually makes async servers make sense. The whole "we can serve other clients while waiting for IO" is the reason it is any good.

Not a huge fan of Node. But this post was just a headscratcher.

Good reason to use Nodejs: The community.

The amount of innovation, available toolset and the pace that everything moves forward (while keeping backward compatibility) is incredible.

And now async/await is available and there are proposals for static typing in next version.

That's the good thing about this community that I love. The community identifies a problem and within a couple of years its fixed.

callbacks suck? Promises, Generators and now Async/Await are there which essentially solve the issue. (And the community has embraced them all already)

There are proposals for optional static typing for next version. I think once the static typing is there, there arent many reasons not to use nodejs.

- Innovation: subjective. People can't even agree on an universally agreed upon definition. Still, care to give an example?

- Available toolset: oh, you mean the dozens of builders, packers, or task runners, being only three examples? Or the `leftpad` fiasco, maybe?

- async/await are syntactic sugar. They solve programmer happiness. Granted that's a big win (no sarcasm), but let's be clear on the semantics. That's not optimizing anything in a technical sense, it makes it more pleasant and quicker to write the code.

- "Within a couple years the problem is fixed". You should communicate with more business people. If I had to pick a technology today, based on what is available today, Node.JS wouldn't even make the top 10. By your logic, being optimistic for the future is a decision maker. That's actually not far off and sadly all of us devs make decisions based on such emotions, but IMO Node.JS shouldn't be judged on that basis.

- "Proposals for OPTIONAL static typing". Great, one more thing to track backwards compatibility on. Can't you see how the JS community is just happy to pile a hack on top of a hack, to infinity and beyond? It's surprising and saddening to me that this isn't obvious to so many JS devs.

--- Apologies, sir/madam, but you lack the bigger picture perspective. You like the stack? Nobody should criticize you over that, we all have fandoms. But you need to be more objective and identify the lingering problems. Shiny new proposals don't necessarily fix anything.

None of the things you mentioned were invented by the nodejs community. Reimplementing existing ideas is hardly innovation.

The point being made is that the problems are solved

Old/new ideas reimplemented in a way that provides more value are, indeed, innovation. You're confusing with "invention". You might think: "oh well, vocabulary". But that's precisely this difference that matters.

techempower web framework benchmark:

https://www.techempower.com/benchmarks/#section=data-r14&hw=...

I can see comparing node.js to go maybe, but it's just not in the same space as C++ and Rust. A comparison with Python and PHP or Ruby would be a lot more interesting. I just can't imagine scoping out a project and shortlisting C++ and node.js for the final two choices for implementation.

there is no good reason to use c++. it is verbose, needs two files for one class, it can cause memory leaks and security holes like no other and last but not least you need to be on the mensa list to be effective in it.

really we can make this argument about anything. c++ has its uses. so does node. so does php. as for myself the only language i have difficulty understanding the purpose of has to be ruby. its more difficult than php, not as readable as python, does not run on the client like javascript and does not offer real functional programming like haskell, it is not as syntactically simple as lisp and it is outperformed by almost everything else. but then i have not used it. maybe somebody could enlighten me?

Simple: because of Ruby on Rails.

Business loves easy-to-build websites. That's how Rails got traction. It promises a quick way to market -- and that's not a lie -- but the maintenance cost over time grows way too much for it to be worth it. Rails is awesome for MVPs, prototypes and small projects. An argument can be made for mid-sized projects; depends on the other dependencies, but IMO it shouldn't be used in the mid-sized area.

Still, businessmen prefer short-term gains over saving costs in the long-term. And that's how Rails gained popularity. And that's why many devs, me included, are having a very hard time moving away from it -- in my case to Go and Elixir.

I like the article from the POV of a purist, but this perspective is what's garbage. Most development projects suffer from labour constraints long before hardware constraints come into play. Cross that bridge when you come to it. Otherwise, chalk up a win, and move onto your next project.

Don't want to undermine the fact that there is value here, but only if the case demands it. For my $ though, I'd rather invest in a security specialist first.

This post is so needlessly and so disproportionately aggressive, blunt and certain to rub people up the wrong way, I can only assume it's deliberately tongue-in-cheek trolling. Well done, sir.

I agree with several other commenters pointing out that the comparison is badly made -- throwing Ruby, PHP, Perl and Erlang/Elixir in the mix would make for much more interesting and useful article.

Probably the author needed to let off some steam. We all do it and I think HN is being pretty harsh on people being people. I am convinced every single person criticizing has been flaming in the last one month, in one platform or another.

Polyfills there you have a reason.

Don't know why I even bother answering this article is useless anyway.

PS I hate javascript and try to not use it when possible. Gives me the best response times

What if you only know how to write Javascript?

Not a good reason. Learning Rust/Go/Java really isn't hard.

Learn more languages?

Programming languages are largely very similar, if you know one language it should not be a problem to pick up another language and write hello world code fairly quickly.

Writing a webserver in a language that offers libraries for it should also not be a problem and doable within a weekend.

If all you've got is a hammer, everything looks like a nail. If all you've got is a rock, you're going to be working even harder on pounding those nails, and god help you when you run into screws or bolts.

So why twitter migrate they mobile traffic to backend Node.js with Express? Isn't that company with enough resources for use a better backend language?

Wasn't this already posted a couple days ago? It got flagged then, too.

I dislike NodeJS as much as any other person, but comparing it to three AOT-compiled strongly-typed languages is a ridiculous criticism.

Of the three languages presented for comparison, Go is maybe a good call for the sort of web development in which NodeJS is used. Rust is marginal. C++ is absurd.

A better comparison would've been with other languages actually common in web backends (at least those that aren't maintained by masochists). Go could stay. Throw in Ruby and PHP and Perl and Erlang. See how things really do compare.

What if I want to use the same language on both client and server?

Kotlin! :) Which incidentally added coroutines and async/await in the recently released version 1.1.

Server-side (running on the JVM): http://kotlinlang.org/docs/reference/server-overview.html

Compiling to JavaScript for the client side: http://kotlinlang.org/docs/reference/js-overview.html

...and for the Android client, compiling to Java bytecode, using the regular Java-based Android APIs and SDK: http://kotlinlang.org/docs/reference/android-overview.html

For iOS and other targets where you don't want the Java or JS runtimes, native compilation via LLVM is in the works: https://github.com/JetBrains/kotlin-native/

Might be a good idea to start using PHP as a browser scripting language then

Rust has a WebAssembly backend :-)

All we need a web framework written in Rust which includes the generation of client-side code.

Paired with incremental compiles (yet to land in stable AFAIK) that should be pretty awesome.

Edit: nose

A very long time ago (1994) I did hack Mosaic about to use Perl as a a client side scripting language... :-)

Dart should take care of that:

https://www.dartlang.org

Note - Haven't tried it yet, but it's on my ToDo list. ;)

Various languages can generate server-side code and javascript. Since you asked, Nim generates C, JS and more: https://nim-lang.org/

You could also use Purescript, even sharing the same modules between the frontend and backend.

What a garbage blog post.

Who codes a Web facing service in C, C++ (or Rust) nowadays. It takes way to much development time, and Rust network code and frameworks are still underdeveloped and still a weak spot.

If you need high performance than Go or Java are the best, than PHP and Nodejs. The later one handle millions of concurrent request very well with latest version and in case of Nodejs if you launch one per CPU core. The advantage of PHP and Nodejs is the development speed, as they are nit statically typed.

There are far better far grander benchmarks out there like https://www.techempower.com/benchmarks/