

A JavaScript Primer For Meteor - sgdesign
https://www.discovermeteor.com/blog/javascript-for-meteor

======
1stop
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

~~~
yukichan
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.

~~~
1stop
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.

~~~
yukichan
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...](https://github.com/laverdet/node-
fibers/blob/master/README.md)

"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-...](http://stackoverflow.com/questions/10282828/node-js-modules-
async-vs-fibers-promise-vs-q-oper8)

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.

~~~
Tarang
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)

------
michaelmcmillan
"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.

~~~
igl
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.
:)

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

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

FROM: [https://www.meteor.com/](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._

~~~
benaiah
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.

------
bsbechtel
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!

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

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

------
grigio
Go go Meteor. Here's a map of MeteorJS users
[http://weuse.meteor.com](http://weuse.meteor.com)

