[progx]

I did not see the difference, only that Sails has a smaller scope. With Meteor you can change all frontend-data of connected clients "in realtime", but Sails did not have this key feature. So iam not sure why i should use Sails, when i can have more with meteor?

[KaoruAoiShiho]

Because Meteor front-end bindings suck terribly. With sails you can use any of the tried and true front end frameworks like angularjs or emberjs etc instead of meteor's crap.

Disclaimer I haven't used Sails so this is not an endorsement for sails, just a reflection of my experience with meteor.

[brodo]

Warning, this is a rant.

I've started a Meteor.js Project 3 Weeks ago and I'm regretting it. It's an architectural nightmare. It uses global variables for everything. One would think the news, that this is a bad idea, would have spread since the 70's. Unit tests are not possible in this style. You can do integration tests with the Laika Framwork though.

The next problem is a severe case of "note invented here" syndrome. Packaging, data access, Templating - Meteor.js has it's own. For example, they have their own version of Handlebars which I did not realize until yesterday. It has some documented and some undocumented differences to the original one. I had lots of fun with some custom Handlebar helpers that I wrote. I tested them against the original Handlebars and they passed all my unit tests. In the project however they did not work at all.

As KaoruAoiShiho said the bindings suck terribly. Well, they don't exist really, you just use jQuery. (Thank god, they don't roll their own version of that.)

The elephant in the room is data access. If you're a MongoDB fan like I am they will lure you in with the fact that you can use MongoDB directly form the client. Don't fall for that, it's a terrible idea. It's such a terrible idea, that they introduced 'server methods' to kind of fix all the problems with it. Server methods are not REST. Server methods are RPC style web APIs. Welcome to 10 years ago. They dislike REST because it's stateless. (at least that's what i've taken form this talk: http://www.youtube.com/watch?v=NnMqMAYmTuo) As you might have realized by now these guys just LOVE state. State and global variables.

If you're a Haskell programmer and you are not jet curled together into a ball and crying, id's suggest to quickly read a monad tutorial before continuing.

Dependency management is also a big problem. You can't just use nodes good old `require` and `module`. The order in which files are loaded is determined by their name and position in the directory structure. I shit you not.

They have also their own build tool. (who would have thought...) It watches your files and compiles them. Which works great most of the time. You can't have includes in your SASS/LESS/Stylus files tough. I guess the notion of having a proper module system scares it a little. I found this thing to be the best aspect of my whole Meteor experience. Not as good as Grunt though.

Per default, there is no routing. There is an unofficial routing package which works good, but is by far not as feature rich as the Express one. It also introduces some more global variables in true Meteor.js spirit.

In my opinion Meteor is good for prototyping. You can get a small app up in no time. Just don't build anything real with it.

[progx]

Thx for that huge info! I only read about meteor and their informations on the webpage, i want to use it in some weeks for a smaller project, but now i will look closer at meteor before i use it.