For being such a flawed language, it does get one thing right. That one thing made Ryan Dahl pick javascript and it is the relative absence of blocking IO calls. Instead you use events and callbacks.

> "relative absence of blocking IO calls."

Do not confuse "language" with "standard library".

The whole event loop idea, which is core to javascript, allows for the single-threaded non-blocking I/O in a way that no other popular language does. Because of this, javascript has features that make this type of programming easy - first-class functions, anonymous functions, etc.

So, yes. Non-blocking I/O is a standard library feature, but it works because of language features.

> "The whole event loop idea, which is core to javascript, allows for the single-threaded non-blocking I/O (...)"

Event loops are not a property of JavaScript of any other programming language: Every single GUI Win32 application ever written in C directly calling the WinAPI contains an explicit event loop.

> "(...) in a way that no other popular language does. Because of this, javascript has features that make this type of programming easy - first-class functions, anonymous functions, etc."

JavaScript is hardly the only language, or even the only popular language, to ever have first-class procedures or anonymous procedures. You know what (at some point in time) widely taught language has a procedure data type[1]? Pascal. So why not Node.pas instead?

> "So, yes. Non-blocking I/O is a standard library feature, but it works because of language features."

That countless other languages have. Most of them a lot better designer than JavaScript.

===

[1] Edit: I originally suggested Pascal has anonymous procedures, which it does not.

> allows for the single-threaded non-blocking I/O in a way that no other popular language does.

C# Async and Await - http://msdn.microsoft.com/en-us/library/vstudio/hh191443.asp...

Twisted (Python) and EventMachine (Ruby) don't all of these do the same thing?

Yes. But they are tacked on to the language after the fact rather than built in from the beginning. My experience is that both language and libraries support that kind of pattern better in node than in Python (no Ruby experience with async).

I believe twisted was an inspiration for node.

were those in the language before or after node came out?

async/await are just sugar over the much older asynchronous delegate pattern that has been in the language since day one. So yes, they were.

are they widely used in APIs to e.g. send a query to the sql database or open a file?

Yes.

In .Net 4.5 there are Async versions of the web, file, stream, image and SQL category of functions.

It's also making its way into ASP.Net layer.

Well, the browser implementation I guess. The point being the correct mindset.

"Mindset" is not a property of programming languages. "Semantics" is. And JavaScript's semantics is, by any reasonable assessment, a huge pile of crap.

Meh, whatever. I can’t believe people still have flamewars about programming languages on the Internet like it was still 1996.

I was not trying to ignite a flamewar. I was just correcting the mistaken idea that JavaScript's "relative absence of blocking IO calls" is somehow a property of the language itself.

In any case, the real issue at stake is whether there is anything about Node.js that makes it particularly good for writing server-side applications. As far as I can tell, the only thing Node.js brings to the table is an event loop. Event loops are not a particularly earth-shattering concept: Anyone who has written a graphical Win32 application by directly using the WinAPI has written an event loop (message loop in Win32 parlance). I do appreciate not having to write the loop myself, but:

1. An event loop can only handle concurrent I/O. Furthermore, because the event loop is hardcoded into every single Node.js instance, there are two legitimate choices that are nevertheless unavailable to a Node.js programmer: a) disabling the loop, if he does not need it, b) spawning multiple event loops as separate threads within a single Node.js instance.

2. Node.js offers no support whatsoever for concurrent computation. I know, I know, all your Web application does is move data between a database and a client. But, if the only use case of Node.js is going to be making Web applications, would it not have been better to make a Web application framework, and provide it as a library?

Languages that actually provide concurrency support (Erlang, Haskell and Rust, to name a few) make writing event loops as easy as it used to be in the 1990s. On top of that, they can be used to write server-side applications that scale.

Node was created to make scripting fast servers easy. Nothing more, nothing less. Because JS (as implemented in the browser and known by many programmers) didn't carry the baggage of blocking IO calls, Ryan thought it would be a good language for an event-loop based server.

History of Node.js: http://www.youtube.com/watch?v=SAc0vQCC6UQ

Fast Web servers. There is absolutely nothing there that I could use to make, say, a fast database server.

yes, fast web servers.

JavaScript is the most widespread language that doesn't lock you down into any particular vendor's platform.

The last thing we need is for everyone to be writing iOS and Android apps and calling it a day.

Come up with a better language that runs anywhere, instantly, so I don't have to give Apple a cent or Google an iota of data on me, and we'll talk!

Try Typekit, it makes JS much, much better and it more or less is what JS will become in the future (it follows latest ECMAScript proposals)

Did you mean Typescript?

In what way is it flawed?

[edit spelling] I think that the reason you find so much negativity regarding javascript is that many people come to javascript from some other language which offers features which javascript doesn't yet offer.

Having cut their teeth on a language tends to leave the programmer with a worldview where any language which doesn't have the same features which are present in their beloved language is an inferior language.

I believe Paul Graham refers to this as 'The Blub Paradox'[0].

Most of the complaints surrounding javascript stem from the fact that it was initially designed to be a lightweight scripting language.

At the time that javascript was created I think that very few people envisioned the web growing into what it has become. Javascript wasn't created with 100,000 line programs in mind.

Therefore it is currently missing some abstractions which people creating and maintaining programs in the large have come to rely on such as classes, interfaces and modules.

Also javascript has a very simple standard library which leads to people feeling that they need to reinvent the wheel in most cases.

Finally Javascript has prototypal inheritance as opposed to the more traditional class based inheritance which so many programmers are used to.

Of course many of the things mentioned above have already been solved or are currently being solved.

The ECMAScript standards body is in the process of adding classes and modules. Libraries such as underscore.js are fleshing out the standard library. And tools such as Coffeescript are providing a more class based inheritance model (if that is your thing).

[0] http://www.paulgraham.com/avg.html

Yes, I am so trapped in my Haskell blub that I cannot possibly understand why JavaScript is so amazing.

Have you tried livescript(http://livescript.net/) or clojurescript(https://github.com/emezeske/clojurescript)? I know that they don't have all of Haskell's features but they do bring Javascript a little bit closer to languages like Haskell.

This is a good example of the ways clojurescript improves on javascript: http://himera.herokuapp.com/synonym.html

I do not particularly care about having a pretty syntax, what I want is the high assurance that the program will not be wrong.

Have you tried using haste or fay? (I haven't, just curious)

Who said it was amazing?

Typescript[1] remedies a lot of things people dislike about Javascript, including the lack of strict typing. I've been using it with Node lately and it has made me do a 180 towards my interest in making Javascript a sever side language for projects.

[1] http://www.typescriptlang.org/

Thanks for taking the time to make these interesting points.

Nonetheless reading them it just made javascript even more repellent to me.

It looks like a cup of bad tea to which you need to add some corrections and addons in the first place to taste at least as decent as the other teas. But still it's generally preferred to much better alternatives because it comes with this kind of unique (not true anymore) feature of non-blocking IO.

What some programmers don't realize in this, is that this inducted preference is just the result larger and larger scale profits needs, influencing the programming world.

If a competitor enterprise which operates in the same market as yours can answer to 10000 more concurrent visits than you do, then you are out of the market. Or: Internet marketing rules will tell you that if your visitors are not engaged in your website in about 5 seconds they'll leave.

This is why we are now forced to learn javascript.

And... programmatically speaking, it's really sad.

Nice answer. I've gone from Java->Haskell->Clojure->CoffeeScript. I was never fluent in Haskell->Clojure but I could get around.

But being completely familiar with Java, CoffeeScript/JavaScript feels nice. I really like underscore.js. When googling for why people don't like JavaScript, it seems that CoffeeScript has already fixed all those problems.

So people only care about syntax? No wonder there is so much buggy software out there.

I can only guess you're reacting to me saying, "I like JavaScript because it lets me type less". Unfortunately, I didn't say that.

To add to your list of common grievances about JS, there is no integer nor bigint datatype, only doubles, so floating-point rounding errors are common and numbers have an upper limit (2^53). Also, the way variable scoping works in the language, is completely insane.