
Node.js Guide - gulbrandr
http://nodeguide.com/
======
jacoblyles
In the "Beginner Guide" section - I would recommend using console.error()
instead of console.log() for debugging output because console.error() is
blocking while console.log() is not. Nothing is more annoying than your
program crashing before it finishes printing debugging output when you are
trying to debug a crash!

~~~
felixge
Good idea, I'll do that.

------
davej
I was afraid to read the style guide for fear of seeing the preceding comma
pattern (I think it's popular in Node because ryah uses it). Thankfully it
recommends the trailing comma :)

    
    
        var variable, // trailing comma
            anotherVariable,
            thirdVariable;
    
        var variable 
          , anotherVariable // preceding comma
          , thirdVariable;

~~~
DTrejo
Here's an article about why preceding comma is very convenient:

[http://ajaxian.com/archives/is-there-something-to-the-
crazy-...](http://ajaxian.com/archives/is-there-something-to-the-crazy-comma-
first-
style?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ajaxian+%28Ajaxian+Blog%29)

More specifically, in which is it easier for you to find the error?

    
    
      // error in standard style
      var a = "ape",
        b = "bat",
        c = "cat",
        d = "dog"
        e = "elf",
        f = "fly",
        g = "gnu",
        h = "hat",
        i = "ibu";
    
      // error in comma-first style
      var a = "ape"
        , b = "bat"
        , c = "cat"
        , d = "dog"
        e = "elf"
        , f = "fly"
        , g = "gnu"
        , h = "hat"
        , i = "ibu"
        ;

~~~
joelhaasnoot
If that's so, why do we not see this in other mainstream languages? While I
see the slight advantage of seeing errors, that is the first thing node sees.
I use either nodemon or cluster, which both monitor your program on saving
your code. When you think you're ready to go, save and see if it has no
compile errors.

~~~
jberryman
I don't know if haskell counts as a mainstream language, but it's pretty
common to see this pattern in a module's export list. I go back and forth.

~~~
jerf
Haskell's an odd case; experienced Haskell users are likely to be thinking of
the comma as less of a "separator" than a "combinator" constructing a tuple,
and preceding-combinator-on-newline is an idiomatic style. Which doesn't
disprove your point, I'm just saying it's an edge case. This is after all the
language community that interprets a semicolon (as used in most languages) as
a combinator too.

------
FixedPoint
I am sorry, but event-based programming is the wrong way to tackle the problem
of scaling up blocking I/O code. Event-based programming more or less forces
one to write in CPS style, which soon becomes a nightmare to reason about. I
speak from the experience of having written several thousand lines of such
code.

A better solution is to pick a language that has light-weight threads
(Haskell, Erlang, ...), and let the language handle the events (and call-
stacks!) under the hood. Cf the caffeine/percolator paper (even though they do
end up using heavy-weight Java threads).

------
gumbo
Something good to know about usecases where node.js is not a good fit:

    
    
      The truth is that while we are starting to see good frameworks for node.js, there is nothing as powerful as Rails, CakePHP or Django on the scene yet. If most of your app is simply rendering HTML based on some database, using node.js will not provide many tangible business benefits yet.

------
mononcqc
Here's some criticism.

Taken from 'convincing the boss':

''' Another great aspect of node.js is the ease at which you can develop soft
real time systems. By that I mean stuff like twitter, chat software, sport
bets or interfaces to instant messaging networks. '''

Those are not all 'soft real time' applications, especially not twitter. Soft
real time here might mean that the usefulness of a result degrades if it
misses its deadline. This might be the case of some chat software, but in the
case of twitter, I receive very little degradation of service if I just go
tomorrow.

The key point here is that you have to be able to have a metric of a deadline
and what to do when you fail it. "If we do not get an acknowledgement by 30
ms, we assume the current node is too busy for our needs and retry on a
different one" could be an example of this.

''' So don't try to build hard realtime systems in node, that require
consistent response times. Erlang is probably a better choice for these kinds
of applications. '''

Erlang is made specifically for soft real time applications, not hard real
time. You do _not_ want to use Erlang to build things like life or death
systems when you need to be precise to the microsecond. It is pretty good when
you can miss a deadline, handle that, work your way around it, but it can not
offer any guarantee about never missing a deadline. Not only does this section
give bad advice about node.js, it also gives bad advice on other languages.

It just feels as if the author meant to say "It is good for interfaces with
live updates, which could be slow or lack constancy of response times", not
much more.

Later in the same section:

''' Combining this with node's radical model of non-blocking I/O, you have to
try very hard to create a sluggish application. '''

My understanding was that you actually have to be careful not to write code
that runs for too long, in order to avoid messing up your request times by
ruining the cooperative scheduling scheme used in the language.

===

In general, the previous guides seem to be nicer, although I have to question
the reason behind advice like 'do not extend the prototypes'. I figure it has
to do with the difficulty of keeping things compatible, but if you're giving
me advice, tell me _why_. Do not expect me to blindly follow your standards
just because you said so.

In the deployment part, it is shown how to use screen to start and detach the
server. Is there any reason why nohup or disown won't do it? it is advised not
to use the shown setup for a production system -- it would be nice to know
where to look for that.

I'd also generally be interested in knowing how you'd avoid spaghetti callback
hell from the approach used in node.js, but that doesn't seem to be part of
the guide. This is a work in progress, and I am not holding this against the
author.

~~~
felixge
Hi, I'm the author of the guide.

Thanks for your feedback. You made some great points about real time systems,
I'll try to rework that section.

> Do not expect me to blindly follow your standards just because you said so.

This reminds me of school : ). The difference here however is that I don't
expect anybody to do anything, and participation is entirely voluntary.

In this case I didn't explain my choice of style because most people in the JS
community would consent with it, and there has been lots of discussion about
this in the past.

> In the deployment part

That's still a work in progress. I didn't choose nohup because I feel screen
is conceptually slightly simpler. However, a real deployment section is coming
in the future.

> I'd also generally be interested in knowing how you'd avoid spaghetti
> callback hell from the approach used in node.js, but that doesn't seem to be
> part of the guide. This is a work in progress, and I am not holding this
> against the author.

That will be the subject of a guide by itself as well.

~~~
alnayyir
Why are you writing about "soft real time" when you don't seem to have done
any work in RTOS/embedded?

Your listed project is transloadit, which is a file uploader that does some
sort of magic I don't care about. (I'm provincial.)

You also appear to be available as a node.js consultant. That's a first for
me. I figured the only "node.js consultants" were ryah and anybody you could
catch awake on Freenode.

A burgeoning ecosystem is good. It's not good when virtually every proponent
of Node.js I run into makes wild claims.

Checked your submissions, I see in this order from chronological proceeding
towards the final entropic state of the universe:

1\. jQuery >? *

2\. Git

3\. Node.js

4\. Node.js

5\. Node.js

6\. Transloadit file jobber thingie (written in JS, on Node.js)

7\. Javascript (This is what Node.js is written in, FYI)

8\. TDD @ Transloadit (written in JS, on Node.js, Church of the GoF)

9\. Realtime encoding - over 150x faster

As easily as I could outright crucify you for butchering the word "realtime"
here, I'll simply spare you the trouble and do a text-replace that'll fix your
solipsism simulator article (blog)

s/realtime/buffered/g

'Fraid that won't work for your video though. You'll have to fix that
yourself. Also, please provide full transcripts (linked, in-line, doesn't
matter) in future. Not all of us are hearing.

And to cap it:

[http://debuggable.com/posts/hacking-a-commercial-airport-
wla...](http://debuggable.com/posts/hacking-a-commercial-airport-
wlan:480f4dd5-50a0-40c6-aa60-4afccbdd56cb)

Illustrious real-time hacking, that.

This is why we programmers don't deserve to be called engineers, not yet.

Code is art, wondrously so, but we're lacking a rigor and consistency of
competence that _could_ be there.

~~~
felixge
Why are you trying to discredit everything I have done in the last ~5 years?

~~~
thomasdavis
haters gonna hate

keep it up!

------
glesperance
Am I the only one to wonder why there are no mention of coffee-script at all ?

It seems to me like a very effective and easy way to make programming more
efficient and improve code readability.

Moreover,coffee-script handles all OOP concepts that could be needed to use
node.

------
swannodette
Ugh, don't agree at all with the dismissal of Object.freeze. This introduces
immutable values to JS which is great for many kinds of data as well probably
opening the door for more optimizations by V8.

~~~
mraleph
Currently doing Object.freeze closes the door for optimizations: object goes
into so called slow mode.

See <http://jsperf.com/object-freeze> results.

~~~
swannodette
<http://jsperf.com/object-freeze/3>

<http://jsperf.com/object-freeze/5>

<http://jsperf.com/object-freeze/6>

A reminder on how immutable objects are meant to be used. When used properly
even under attempts to mutate, they run circles around trying to use mutable
objects in an immutable manner.

~~~
mraleph
Yeah, I did something stupid in my own test. Probably I was thinking about
Object.seal(). Nevertheless your own test revision #3 shows that accesses to
frozen properties are roughly 14 times slower.

Revisions #5 and #6 do an allocation in the "hot" testcase so the real cost of
property lookup just becomes hidden behind cost of memory management.

------
joelhaasnoot
Very handy. Working on a project with node.js and need to take more of these
suggestions to heart. Callbacks take some getting used to, especially
returning data is tricky, but it does make things slicker. Node.js is awesome
but oh so fragmented: I use Mongoose and Express, both of which have APIs that
have changed, and stuff breaks, with lots of old examples floating around.
There are also lots of plugins and libraries which seem to do the same thing
(cluster, spark, spark2, etc, etc)

------
beck5
Just what I am looking for, installed node a few hours ago. Does anyone have
any express.js resource recommendations?

~~~
Apocryphon
I would like to echo my gratitude for this guide. I am also in need of a crash
course in Node.js, this is really helpful!

------
efnx
(If you're reading Felix) The 'Right' section of Nesting Closures violates the
'Right' section of Named Closures. The outer closure is not named...

------
krmmalik
Fantastic. Just what i wanted. Thank you so much.

------
reledi
Thank you very much for this guide. I was going to learn Node.js later this
month and this will make it much easier.

------
lxd
amazing guide, thank you!

