>The sad thing about Rails is it largely stagnated for some time >You just have to do so much glueing >These are solved problems on node
And to be clear, Node is not a 100% perfect platform either.
>I think the author is attempting to elude to the cargo-cult that hit Rails will migrate to Meteor.
Of all the options available, why Meteor? Like someone on this thread said, it has a lot more evolving to do, to even become on par with rails in the current situation.
We're talking about the basic reason why people choose rails:
Productivity (Getting stuff done) and getting your product out to the market. I think in this perspective nothing beats rails:
rails new blog
rails generate scaffold Post title:string text:text
rails s
Absolutely. But as a software piece, I think it can apply itself to the web more easily than Ruby currently can.
> Of all the options available, why Meteor?
Right, there are plenty of options, MEAN is getting nicely popularized. You also have Derby.
> Like someone on this thread said, it has a lot more evolving to do, to even become on par with rails in the current situation.
Yea, there's a problem with how much you get for free with Rails (rubygems), and how much utility a framework provides you (AR, generators, etc). Right now those are areas that need improvement, but the community & time will improve those.
Re the awesomeness of generators: Yea, meteor doesn't have any, and in all fairness we're talking about something that isn't 1.0, but from a practical point of view: this is an easy task in Meteor and would only take 5-10 lines of code.
On something that rails doesn't have is dependency reloading. So imagine a world without `bundle install`. Meteor wants to streamline, it just hasn't gotten all the corner cases yet. It's still early, but it's still got a lot of bang for it's buck.
Perhaps some are jumping ship early or just want to get acclimated with new software in it's infancy. I just like both.
> . You just have to do so much glueing
In your previous post. Then you list out MEAN(Mongo, Express, Angular, Node), which is all glueing. I have used this stack extensively, and I must say its not even close to Rails. In fact it's not even on the same planet.
After all you guys finish your piddly todo lists, start trying to write some real business logic in Node, and see how far it gets you. There is a reason the Meteor team chose fibers. You can async.waterfall all you want but structuring your code in a synchronous manner, lets you get stuff done.
People tout Node and Meteor for real time stuff. I could do similar things with SSE and Rails/Ember or Angular. The users of your applications don't care if you use Websockets and really most of the time you don't even need Websockets, you just need SSE or long polling.
First of all, I only claimed you have plenty of glueing in Rails (although you glue when working with anything, it's the degree at which I think is important).
Secondly, I was agreeing with about there being options, I didn't really reply to the "why Meteor", I think I went over that enough.
> I have used this stack extensively, and I must say its not even close to Rails. In fact it's not even on the same planet.
They are both used to build web applications, I think they have many similarities. But yes, they do have a wide range of strength and weaknesses.
> After all you guys finish your piddly todo lists, start trying to write some real business logic in Node, and see how far it gets you. There is a reason the Meteor team chose fibers. You can async.waterfall all you want but structuring your code in a synchronous manner, lets you get stuff done.
I don't find it exceedingly difficult to be productive in Rails, Meteor, or MEAN. Again, each has their strength and weaknesses.
And in terms of structuring code: async or not, you have plenty of options to properly organize it (eg: Deps.autorun, promises, npm's async).
> People tout Node and Meteor for real time stuff.
I think because it tools itself well there.
> I could do similar things with SSE and Rails/Ember or Angular.
Right, no one is taking Rails away from you.
> The users of your applications don't care if you use Websockets
True, most users won't care about the specific technologies used to load a page. But it could play a role in the experience, which is something they will care about.
> and really most of the time you don't even need Websockets, you just need SSE or long polling.
See, here's the thing "most of the time", but not all of the time. So there are cases for each.
Long polling has plenty of cons, and SSEs don't provide you with a bidirectional channel. That's important for some applications.
I'm also not sure where you implied that I've dismissed Node, because I most certainly haven't. In fact I have several Node applications in production at my company. I'm just stating facts, and to be honest I'm extremely open minded when it comes to new frameworks.
But Meteor, I've been there done that. It's called JSF in the Java community.
Thanks.
[1] http://blog.mongodb.org/post/49262866911/the-mean-stack-mong...
No one is taking Rails away from you. I don't think it's bullshit. There are use cases for each. I think Meteor offers up a good debate about "how we do development these days", and attempts to answer them, albeit early. Meteor is still new, and it's path is currently bumpy. But it tries, and innovation is a wonderful thing, that's what Rails gave us early on. The sad thing about Rails is it largely stagnated for some time while JS M.V.-whatevers sprouted. It couldn't solve realtime application building problems and provided no means for a client side implementation. And for the most part still does (although 4 supports SSEs). You just have to do so much glueing. One more: what about the inherently non-threadsafe nature of rubygems? How will Rails overcome being a threadsafe framework when it's dependancy mechanism has no safety check? I digress. These are solved problems on node, and it's something Rails still stagnates with. My point here is: Rails has issues too, big ones.
I can see Meteor either evolving nicely, or fading away. Keep in mind that it already has a growing community and development is backed with solid dollars & a passionate team.
I think the author is attempting to elude to the cargo-cult that hit Rails will migrate to Meteor. In time I believe many will. I think both communities will stay strong, and after enough time will begin to look like each other. Rails could learn a thing or two from Meteor. And conversely Meteor the same.