The advice above regarding CTRL-C is good. An absolute beginner might not know this.

Also I noticed a leap in the "static file server" lesson. A beginner may not realize they have to create a public directory and will just get a very unfriendly "Cannot GET" error. This might be especially true as following the `npm install express` command, directories were generated automatically. This sets up an expectation that isn't fulfilled.

A little more handholding might keep you from answering as many questions and allow the beginner a really smooth entry.

I'll use node for Unix scripting when you pry every other alternative from my cold dead hands:

  awk '{a[$2] += $3};END{for(x in a){print x, a[x]}}' sample.txt 
  A 2
  B 14
  C 6

Do you mean multi-threaded?

Once one of those activities completes the event loop will give a signal to the main thread of the Node app and the callback will be executed.

Not sure if that helped or just confused everyone.

[1] https://developer.mozilla.org/en-US/docs/Web/Guide/Performan...

..Yea JS.

Today it's clear that the "only" reason for it being used is its widespread availability in browser, but that started in a time when you needed a way to change the mouse pointer from default to a rainbow colored one.

But still js it's the programming language we build frameworks for today, and the kind of industry standard we are proud of.. today.

We are we still stuck at this point? [rhetorical question]

I am not even close to being capable of fixing this by myself so obviously the reason for this comment is just to create my own little tiny wave of resonance, hoping that it could hurt the next bigger wave, hoping this could go on forever.. till the point that js is replaced by something better and wiped forever from planet earth..

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

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

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.

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

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.

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.

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

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!

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

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.

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

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.