Live data from Hacker News

Why Meteor will kill Ruby on Rails

differential.io

101–110 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#101
Before we get carried away, let's remember that the web has tremendous utility outside of applications. Progressive enhancement is still the best way to do a great many types of websites. Rails succeeded because it tied together the fundamentals of the web in a nice package. Meteor is another step-change for a certain kind of real time application, but that is by definition a much narrower use-case.

Re: Why Meteor will kill Ruby on Rails

#102
post #92

I'll make an even bolder claim: Meteor doesn't work at all for anything except small toy apps. Meteor is built on the idea of reactiveness between server and clients. That is if the servers view of the data changes, then the clients views' must also change at the same time. It accomplishes that using websockets and letting each client have a full copy of all the servers data in memory. Works great for simple chats an…

You should really read up on autopublish and turn it off for your app.

Don't make bold claims unless you try a little harder!

Re: Why Meteor will kill Ruby on Rails

#103
post #7

"Let's be real, Javascript is the #1 language on Github and for good reason - it runs everywhere." Similarly, anal sex is the best kind because it works on all genital configurations. /snark

I suspect there's a significant number of people who would actually agree with that though.

Re: Why Meteor will kill Ruby on Rails

#104
That's a bold claim to make when your blog can't function without cookies.

Also, after it loaded, the only point that seemed to be directly related to Rails had to do with teaching designers to use templates and the asset pipeline. If that's your only Rails-specific issue then you're really claiming that Meteor will kill all other kinds of web development.

Re: Why Meteor will kill Ruby on Rails

#106
post #89

Why do people put so much effort in comparing tool A to tool B when either of those tools only cover 5% of all the work that goes into any serious application, and the time saved by any advantage tool A has over tool B is pretty much negligible? I mean cool, so Meteor is maybe better for prototyping. Because that's all we're talking about here, prototypes and ultra-simple websites. It's always the same story, a shiny…

Making repeated prototypes (in est, experiments ), quickly, is how you approach entrepreneurialism in any sort of scientific manner. Nothing needs to scale, or work at the edge-cases, until it has product-market fit; and you might need to write twelve or twenty or two-hundred different apps until you find one that works out that way. That's what makes these frameworks popular with HN: startup founders are not in the…

I am sitting at a Meteor unconf today and we are talking about scalability of Meteor... There are some very interesting pieces coming out in the next month to really push the envelope on handling a lot of users at once.

I would agree, we are in the business of building MVPs every day so it is much more interesting to us, I bet.

Re: Why Meteor will kill Ruby on Rails

#107
Catchy title but misleading. I can't access the blog. Josh, do you run your blog on meteor.com? You should migrate to a production-like environment. We ran into this issue before :)

My team builds http://vida.io with meteor. We've got 100-200 visits a day, few thousands at our peak.

I'm an experienced Rails developer and dabbled a little with nodejs. I can say meteor will change nodejs framework dev, but not kill Rails.

Some of the serious problems I found developing with meteor:

- Reactive template is nice but can lead to very hard to debug issues. Small portion of applications (in general) need real-time. I often spend time disabling reactive update. There's no really good way to debug reactive update trigger.

- Organizing, switching views/templates can get confusing for site navigation.

- Package system is still infancy, has a VERY long way to catch up with Rails ecosystem.

- Pub/sub model introduces a lot of performance issues. We have to limit the amount of data we send back.

- Security: this is related to pub/sub model in previous point. It's very easy to publish unauthorized data to client side.

- No best practices with the exception of authentication. So everything else takes LONGER to do than Rails. Developing in Rails is still way faster in most scenarios.

Despite of these problems, I think meteor is a promising framework. I like how it unifies client and server. And hopefully, meteor dev team will address the above problems.

Post reply on HN