Thank you for writing this. Keeping the target audience in mind, one thing you may want to consider is telling people how to stop the node server once its started (CTRL-C).
After teaching university, and now having spent the past few years teaching teens it's best not to take for granted what a student might know. Though I discovered that on all levels (not just by teaching the teenagers). When you say "absolute beginner", you've got to be careful not to make too many leaps.
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'd love to chat about the platform. I'm not sure if this is the correct forum for pimping it. I just don's to turn this comment area into a discussion of the platform. Hit us up on twitter @OnModulus or send an email to feedback@modulus.io.
Well Modulus, http://modulus.io, has a number of things that set us apart. One is that we're not really into to tiers. Custom SSL, domains, etc... are part of the normal package. We support WebSockets, there are a couple others that do but most don't. The really interesting piece is that we provide our customers with a great set of statistics about your running application (number of requests, response times, cpu, memory and more). We also have MongoDB hosting in house which lets you spin up a database for your application quickly.
I like this article. I've been learning Node on the side (I'm a Java developer so Node is pretty foreign to me) and really enjoying it, but as it's very different from what I'm used to these kinds of guides are a big help.
Interesting article. You guys should maybe split this "cookbook" into multiple articles where you will briefly cover socket.io, Mongoose, and unit testing.
So basically if you have an infinite loop in your app's one and only thread, none of the callbacks will happen because they have to run on that one thread?
Yep. Similar to how an infinite loop in the browser will freeze up the page - the browser only gets to control to draw by putting a draw function in the event loop, so if you hog the thread, the page can't update.
No, Javascript has no notion of threads. Rather than true concurrency and a synchronization mechanism, it has callbacks (upon callbacks upon callbacks).
Technically speaking, HTML 5 introduced web-workers which allows javascript to have multiple threads (see 1). However, it's still useful to think about them as being single threaded since workers are sandboxed, meaning they don't have access to the global namespace. This avoids issues commonly found in concurrent programming. E.g., separate threads cannot read and write to the same variable since they don't have access to each other's namespaces.
People coming from multi-threaded server environments should be aware that multi-threading does in fact exist in Node (scope of parent comment), but it's rather different from other more common concurrent event handling schemes. I.e., you cannot have shared mutable variables across threads (scope of article and ongoing async discussion). For examples, see https://npmjs.org/package/webworker-threads and https://github.com/cramforce/node-worker.
Not trying to be flamy, but, once again... why people insist on pushing on projects based on a... renownedly flawed programming language?
..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..
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.
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.
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).
"Mindset" is not a property of programming languages. "Semantics" is. And JavaScript's semantics is, by any reasonable assessment, a huge pile of crap.
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.
[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).
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.
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.
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.
