Why is meteor.js synchronous?

Question

Doesn't code take an efficiency hit by being synchronous? Why is coding synchronously a win? I found these two links in doing some research: http://bjouhier.wordpress.com/2012/03/11/fibers-and-threads-in-node-js-what-for/, https://github.com/Sage/streamlinejs/

If the goal is to prevent spaghetti code, then clearly you can have asynchronous code, with streamline.js for example, that isn't a callback pyramid, right?

Answer 1

You have to distinguish two things here:

• Synchronous functions like node's fs.readFileSync, fs.statSync, etc. All these functions have a Sync in their names (*). These functions are truly synchronous and blocking. If you call them, you block the event loop and you kill node's performance. You should only use these functions in your server's initialization script (or in command-line scripts).
• Libraries and tools like fibers or streamline.js. These solutions allow you to write your code in sync-style but the code that you write with them will still execute asynchronously. They do not block the event loop.

(*) require is also blocking.

Meteor uses fibers. Its code is written in sync-style but it is non-blocking.

The win is not on the performance side (these solutions have their own overhead so they may be marginally slower but they can also do better than raw callbacks on specific code patterns like caching). The win, and the reason why these solutions have been developed, is on the usability side: they let you write your code in sync-style, even if you are calling asynchronous functions.

Jan 25 2017 edit: I created 3 gists to illustrate non-blocking fibers: fibers-does-not-block.js, fibers-sleep-sequential.js, fibers-sleep-parallel.js

Answer 2

The code is not "synchronous" when using something like streamlinejs. The actual code will still run asynchronously. It's not very pretty to write lots of anonymous callback functions, thats where these things helps.