I wish something would, but nothing at the moment, is even close to the scale at which EJB gets things done. I truly mean it. And something built out of Ruby replacing a Java-based full-bleed framework? I think you must be fucking kidding me. What the author describes is a very specific use-case and maybe, just maybe Rails might replace a portion of that use case. In fact, if I were to do something like what the author suggests, I would still choose EJB and jBoss (or Orion if you know it better).
etc, etc.
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.
>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
How many lines of actual code I have written so far to actually get my basic blog idea up and running? None.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...
Have we really come to a stage, where what Facebook has done after billions of worth investment and thousands of people working, can be cloned with a open source technology in hours?
>>I can make a clone of any complex app out there in the web in a matter of minutes/hours.
Again how is this possible. Or let me word it this way, if some thing can be copied in minutes how can it be called complex?
I meant that you can get out an MVP of a complex web application like Facebook in a matter of hours/days (depending on the complexity of course) instead of having to wait for weeks/months when you're on with another framework.
>if some thing can be copied in minutes how can it be called complex?
Just because your life is made easier by a tool, doesn't necessarily mean the original process is any less complex. And that's why the market for for such tools even exist :)
Translation: Just because a bottle of Coca Cola costs $0.99 and a bottle of water costs $2, doesn't mean that the process of creating Coca cola is by any means less complex.
Cheers.
Whether it can support a billion users is a different story. (It won't)
In its core, the app is just users who can friend each other.
Add AJAX to that... and tada, something that resembles facebook.
Scaling the app to be very reactive, available to millions accessing it at the same time, and with near 100% up time is where the hundreds millions of dollars go. (and all that data mining)
If you mean "mimicking on or two of the features" I'm with you :)
A basic social network clone? Sure, maybe a day. But to emulate all the features Facebook has would probably take well over a month if done alone, even if the dev was very experienced with Rails.
This is probably a more important metric than language popularity on github: http://www.statisticbrain.com/computer-programming-language-... And I'm sure javascript has grown quite a bit in popularity in 2013.
Javascript is getting things done, and with node and mongo and now meteor, it's only getting easier.
It's a fact that many don't want to face, but you may need to practice your JavaScript skills to find your next job.
I'd be willing to go toe-to-toe with you guys on no framework at all - just HTML/CSS/JS and perhaps a little JSON feed to an AppEngine datastore if data needs to be persisted and shared among multiple users.
I wish something would, but nothing at the moment, is even close to the scale at which rails gets things done. I truly mean it. And something built out of Javascript replacing a Ruby-based full-bleed framework? I think you must be fucking kidding me. What the author describes is a very specific use-case and maybe, just maybe Meteor JS might replace a portion of that use case. In fact, if I were to do something like what the author suggests, I would still choose rails and Knockout JS (or Angular JS if you know it better).
Do you know how long it takes to build a Facebook backend clone in rails? Maybe a day? And the frontend (all the Ajaxy stuff) should probably add a week or two (worse-case scenario). That's just it. That's the power of rails.
If you were to build the backend in Javascript without the power that Rails provides I'm sure you will need more than just a day, let alone a week.
The point is, nothing is close to what rails is right now. I badly wanted something to replace rails for my work, but I haven't found a single solution that fits my needs. I've tried everything - Play, Sails, Revel, Gorilla, etc etc. But nothing there is that can replace rails. And all the frameworks that claim to be more like Rails, they're simply not true. Have you tried using play (Scala) and PostgreSQL together? The experience is nothing like Rails.
I can make a clone of any complex app out there in the web in a matter of minutes/hours. That's the power that rails gives me and no other framework/combination can't.
I understand that Rails is slow. But this is not the right way to critique it - Claiming something is going to replace it when it actually isn't true.
We develop all our v0.1s in Rails in house and port them to Go (only if necessary and if the project owner is particular about it.) and that seems to work well for us.