"As long as the block of code inside the if fits in one line, you can also use this shorthand syntax (note the lack of curly brackets):"

My definition of "one line" invalidates this statement. However, I believe "one line" is pretty objective. Javascript will execute anything until it reaches a semi-colon. The following is valid Javascript.

    if (foo)
        for (i = 0; i < a.length; ++i)
            if (i === 5)
                console.log (a[i]);

Other than the obvious nitpicking, great article! It clears up a couple of confusing aspects of Javascript.

The thing you end with the semicolon is a expression.

    if (1) console.log(1), console.log(2), console.log(3);

The comma breaks and returns the next value.

    var foo = 1, 2, 3;
    foo => 3

So correctly: Use this shorthand syntax to pick up only the next expression. :)

This is a basic JavaScript tutorial. How did this reach the home page?

Meteor primer (If you have any dependencies):

- Forget about async

- learn to love Meteor._wrapAsync

- learn to hate npm packages that don't follow the function(err, result) convention.

- `mrt install npm` should be the first thing you do

Meteor._wrapAsync is one of the coolest things about Meteor. I didn't really understand its power until I watched EventedMind's video on it, though - https://www.eventedmind.com/feed/meteor-meteor-wrapasync.

I keep using it to keep my code clean and avoid callbackhell(.com).

It's just just inline non-blocking right? When people say "not async" I think blocking, but it's actually async in that you can have other operations happen in between execution of lines of code. Like if something that would traditionally be async in node executes, you don't have to wrap a callback in a function, yet it's still async, kind of like yield statements in python Twisted. If you think it isn't async and it is you're going to be in a world of hurt some day.

In meteor it is synchronous.

If something in node is async, you have to wrap it up with _wrapAsync, else meteor explodes. Once it is wrapped, it is no longer async, your code will block until the (internal) callback is called, then it will continue.

It is exactly, not like a 'yield' in Twisted, that is the same in node, but in Meteor (server side) nearly everything is synchronous.

I believe you're wrong, it's not blocking otherwise it would be terrible. I remember testing this before. Fibers is inline non-blocking.

The readme explicitly even mentions that it yields:

https://github.com/laverdet/node-fibers/blob/master/README.m...

"Again, the node event loop is never blocked while this script is running."

This SO answer agrees:

http://stackoverflow.com/questions/10282828/node-js-modules-...

I don't remember what my test was, but I tried it, it doesn't block. Try to create something that you think doesn't block to freeze node while using fiber, it won't block, that's what makes fiber awesome. Fiber doesn't block. If you think it's blocking when it isn't it can kick your ass because you will assume incorrect order of events. It's just inline non-blocking.

If I'm wrong I would be happy to be corrected about this.

EDIT:

A perfect way to test this would be to loop through a bunch of HTTP requests that can take varying lengths of time to return and print when they finish, you're going to see they finish out of order. You'd have to write the loop such that each http request fires indepently of each other, which is tough in fiber, but a settimeout could do it (Checkout the sleep example in the fiber readme). If those http requests blocked other ones you'd have a pretty shitty situation, but they don't. And so if you assumed those HTTP requests completed in the same order you made them you would be in trouble.

I'm near 100% certain you are incorrect.

They don't block the event loop, no.

But they do remove callbacks and thus asynchronity from libraries.

i.e aws-sdk

    S3.putObject(..., function callback(result){})

would become (with _wrapAsync):

    result = S3.putObjectSync(...)

In the below example:

    var x = 5;
    x = S3.putObjectSync(...);
    console.log(x);

The console will never log "5". That is what I mean... maybe I'm confusing the terminology though :\

I believe you are right.

Additionally

=You can have it blocking per client too

This is useful since it ensures that requests from the client run in the order you intend (in case a method takes a while to respond)

You can get passed this by calling this.unblock() for that particular client only.

To clarify: This means it wont block other clients at all, unless the commands are blocking on a lower level (Filesystem IO for example)

I didn't know what Meteor is and the link didn't explain.

FROM: https://www.meteor.com/ Meteor is an open-source platform for building top-quality web apps in a fraction of the time, whether you're an expert developer or just getting started.

To be fair, this link is on a site called "Discover Meteor", whose entire purpose is to elucidate the Meteor framework. It's not unreasonable for the site to assume that you got there from somewhere that already explained what Meteor was, such as the front page, rather than a random HN direct link.

It's worth noting that Meteor is a unique framework, because of the live templating engine and data binding, that allow you to design and prototype real-time applications very quickly.

You're right, I'll add a link to their site.

Sacha, this is a really good overview of some common JS syntax I've been struggling with as I've been learning Meteor. Thanks for posting!

A bit of a side track i guees, but how is any of the tings mentioned in the text paradoxes.

You're right, "contradictions" would be better!