News for hackers. Stuff that matters.
Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by vdaniuk on Friday June 12, 2015 @10:38AM (#9706137)
> Browser: interacting against DOM objects and events (clicks, etc)

> Server: you are wedged into the function(options,callback) pattern and many promise libraries. you are often using functions as "middleware" or wrapping them in promises.

How much time did you actually spend evaluating Meteor? Meteor is using fibers on the server and thus the code is written in the synchronous style.

Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by anon3_ on Friday June 12, 2015 @11:22AM (#9706418)
The above comparison was about the difference between JS in browser and server-side.

> How much time did you actually spend evaluating Meteor?

A week? I saw the fibers dependency.

> Meteor is using fibers on the server and thus the code is written in the synchronous style.

There is no library (promises, fibers) that alleviates the simplicity of being able to do:

  users = User.objects.all()
And not having to wrap it in a promise.

I should add, we went from Meteor -> Express -> Django. It was such a relief to invest time in our features, and not having to have the downsides of every minute DB / API being asynchronous. I could elaborate.

Re:Meteor Raises $20M to Build the One JavaScript Stack to R... by vdaniuk on Friday June 12, 2015 @11:54AM (#9706652)
> There is no library (promises, fibers) that alleviates the simplicity of being able to do: users = User.objects.all()

As an counter-example, Sequelize offers both callbacks/promises so you don't have to wrap the query function manually. In fact many libraries provide promise interface or can be promisified with bluebird.

Using ES7 async/await and babel you just write:

let users = await Users.findAll()

Async/await syntax was the feature that made JS development pleasant for me. Brackets and parentheses soup that tends to be produced by callbacks/promises made my pattern recognition sick.