lefnire/gist:4457396

## gistfile1.txt
Response to the rant (with formatting): https://gist.github.com/64f15ecc13fa1af83f82

I've tested out Derby and Meteor and I can't agree with lefnire.

Firstly, I'm the developer of one of the only in production (?) Meteor site that I know of (I've asked around for others but didn't get much of an answer). http://anonkun.com

Time from idea to launch was 10 days.

Before deciding which framework I'm going to go with, both Derby and Meteor were investigated along with a host of other frameworks. Derby isn't bad, but...

Its primary problems of bad PR, bad docs, small community, etc are probably enough to discourage most people. lefnire also makes some unfair comparisons with Meteor.

Derbyjs supports rest while Meteor doesn't. That's silly, because REST is missing the point. Meteor/Derby is supposed to be realtime frameworks. Is your mobile app going to do polling not real time? Meteor has a new protocal with various clients in development that will enable real time streaming to all your devices. Don't need rest. And secondly of course you can do REST just that nobody has bothered to.

NPM is a big problem. Metor has some walled-garden syndrome that I think everyone who has encountered hates. It uses fibers, an NPM module that simplifies the callback soup that node.js is used to but breaks compatibility with most NPM modules. That could actually be a business decision rather than a technical one (to promote lock-in), and if true would be atrocious. Despite what I said before, because of this and other reasons I can't promote Meteor. My next project will not be using it.

I don't think Derby is better though.

Derby, in examination, actually does less useful things than the in-house framework I built for my backbone.js site (more on this later). Using socket.io and pulling together a bunch of common node.js modules you can hook up your own real time system without TOO much effort.

The hard part is in the client side syncing and templating and both Derby and Meteor suck at this. They have built (imo bad) custom client side stacks. I've more experience with Meteor so I can say that their client side stack is slow and leaky. Meteor's events system used to integrate with jQuery... but now it doesn't anymore, and their custom events system has so many missing features and bugs.

Meteor also forces you to use their templating system instead of using better and more popular ones like Jade and have crappy support for basic things like bootstrap and stylus. As a real time framework Meteor does its job but its value add in terms of bundling, helping you create structure, and so on is seriously half baked and a waste of time to deal with (I replaced ~7 core framework packages with my own forked versions). You can do better by yourself by pulling together NPM modules or looking on github for node.js bootstrap examples.

So what is the answer?

Right now I'm investigating Firebase + Angularjs. Theoretically this should provide the best possible setup.

Angularjs is a fantastic, popular, well supported and well documented client side framework that should be taking the javascript world by storm in 2013. This is opposed to the undocumented and buggy Spark module that passes for client side framework in Meteor. It seems unlikely that the Meteor team, with their attention diverted to all parts of the stack, including server administration and hosting, could do a better job than the googlers that are working on Angular.

Firebase takes care of all the real time syncing you can need. It's authentication system is pretty sweet too.

I can't recommend this setup too heavily because of lack of production experience with it but this is what I'm thinking about.

Final note on backbone:

I've used backbone extensively for over a year, including backbone+ frameworks like Marionette, and I agree with lefnire that its heyday is over. I would not be using it or any of its derivatives on another project. There are more and better alternatives. I consider this fairly obvious and indisputable, and if you disagree then you need to educate yourself on the scene and not just pick the most popular one (because it's the oldest).

Angular will probably be the one taking the crown for 2013 as the javascript framework of choice (and people will realize that the sanctity of HTML is not worth fighting for) but this should be a nice battle.
	Response to the rant (with formatting): https://gist.github.com/64f15ecc13fa1af83f82

	I've tested out Derby and Meteor and I can't agree with lefnire.

	Firstly, I'm the developer of one of the only in production (?) Meteor site that I know of (I've asked around for others but didn't get much of an answer). http://anonkun.com

	Time from idea to launch was 10 days.

	Before deciding which framework I'm going to go with, both Derby and Meteor were investigated along with a host of other frameworks. Derby isn't bad, but...

	Its primary problems of bad PR, bad docs, small community, etc are probably enough to discourage most people. lefnire also makes some unfair comparisons with Meteor.

	Derbyjs supports rest while Meteor doesn't. That's silly, because REST is missing the point. Meteor/Derby is supposed to be realtime frameworks. Is your mobile app going to do polling not real time? Meteor has a new protocal with various clients in development that will enable real time streaming to all your devices. Don't need rest. And secondly of course you can do REST just that nobody has bothered to.

	NPM is a big problem. Metor has some walled-garden syndrome that I think everyone who has encountered hates. It uses fibers, an NPM module that simplifies the callback soup that node.js is used to but breaks compatibility with most NPM modules. That could actually be a business decision rather than a technical one (to promote lock-in), and if true would be atrocious. Despite what I said before, because of this and other reasons I can't promote Meteor. My next project will not be using it.

	I don't think Derby is better though.

	Derby, in examination, actually does less useful things than the in-house framework I built for my backbone.js site (more on this later). Using socket.io and pulling together a bunch of common node.js modules you can hook up your own real time system without TOO much effort.

	The hard part is in the client side syncing and templating and both Derby and Meteor suck at this. They have built (imo bad) custom client side stacks. I've more experience with Meteor so I can say that their client side stack is slow and leaky. Meteor's events system used to integrate with jQuery... but now it doesn't anymore, and their custom events system has so many missing features and bugs.

	Meteor also forces you to use their templating system instead of using better and more popular ones like Jade and have crappy support for basic things like bootstrap and stylus. As a real time framework Meteor does its job but its value add in terms of bundling, helping you create structure, and so on is seriously half baked and a waste of time to deal with (I replaced ~7 core framework packages with my own forked versions). You can do better by yourself by pulling together NPM modules or looking on github for node.js bootstrap examples.

	So what is the answer?

	Right now I'm investigating Firebase + Angularjs. Theoretically this should provide the best possible setup.

	Angularjs is a fantastic, popular, well supported and well documented client side framework that should be taking the javascript world by storm in 2013. This is opposed to the undocumented and buggy Spark module that passes for client side framework in Meteor. It seems unlikely that the Meteor team, with their attention diverted to all parts of the stack, including server administration and hosting, could do a better job than the googlers that are working on Angular.

	Firebase takes care of all the real time syncing you can need. It's authentication system is pretty sweet too.

	I can't recommend this setup too heavily because of lack of production experience with it but this is what I'm thinking about.

	Final note on backbone:

	I've used backbone extensively for over a year, including backbone+ frameworks like Marionette, and I agree with lefnire that its heyday is over. I would not be using it or any of its derivatives on another project. There are more and better alternatives. I consider this fairly obvious and indisputable, and if you disagree then you need to educate yourself on the scene and not just pick the most popular one (because it's the oldest).

	Angular will probably be the one taking the crown for 2013 as the javascript framework of choice (and people will realize that the sanctity of HTML is not worth fighting for) but this should be a nice battle.