Rails will Ruby-kill Meteor — on why
weblaws.org
weblaws.org
The whole premise of Rails is convention over configuration. Build a set of tools optimized for the average application following "best practices". And guess what? Rails is still the best framework for producing the average Web application using 2006 best practices.
Now it's 2013. The average application server starts with Rails, then throws away ERB, routing, form_for, and the entire MVC lifecycle and slaps Ember on top of it. Technology has changed a lot in seven years (mobile, javascript, blah blah blah), and more importantly, it's only getting more client side
While I like what Meteor is attempting to do by merging the client and server into one framework, I feel their approach is somewhat haphazard. Using it left a bad taste in my mouth, though t be fair I haven't done much beyond building a basic app for evaluation purposes. I'm currently evaluating Derby.js, and so far I'm liking it much more.
That said, convention has yet to be established for clientside apps, so either framework could fail. I do think that there is a niche for a framework that provides both the server and the client, however.
"Meteor looks very interesting, but until it supports more of the above, we’re talking apples and oranges."
If only one could somehow contribute to open source projects. Oh wait... But I guess complaining and comparing a 1 year old platform with a platform that's almost 10 years old is easier.
When you consider how incredibly fast meteor is growing compared to how RoR has grown it becomes apparent that meteor will grow past it very quickly.
Please next time do your investigation homework before comparing two totally different software ecosystems.
If Ruby on Rails had that much money from the beginning now you would be running the fastest, most beautifully coded/structured super-scalable real-time app in the world :)
[1] http://www.meteor.com/blog/2012/07/25/meteors-new-112-millio...
A.
B.
C.
D.