Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Meteor will kill Ruby on Rails

differential.io

Post reply on HN
Print view View original

181–190 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#181

Post by 1qaz2wsx3edc »

neya wrote: post #166

This is bullshit. In my whole experience as a full stack developer, after having tried various technologies and languages and frameworks - including ones built with PHP, Ruby, Scala, Javascript and Golang, I can this say with full confidence and can afford to put my name and credibility to stake - Nothing is going to replace Ruby on rails anytime soon. I wish something would, but nothing at the moment, is even close…

Sure.

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.

Re: Why Meteor will kill Ruby on Rails

#182

Post by bhauer »

subsection1h wrote: post #73
subsection1h wrote: post #66

Is your blog powered by Meteor? I ask because your blog has some major issues: First, when I load http://differential.io/blog and click a link for an old article, the content of the "Why Meteor will kill Ruby on Rails" article is displayed instead of the content of the article I wanted to read. This happens for every article. Second, when I load http://differential.io/blog , scroll down to an old article, click the a…

I visited Meteor's blog just now at http://www.meteor.com/blog to see if it would break my Back button the way that your blog did. Indeed, it did. Clicking my Back button at a Meteor-powered site seems to always direct me to the top of the previous page, not to the location on the previous page where I left off. As I wrote in the parent comment, this issue is very annoying. Is this a problem that the Meteor developer…

I don't use Meteor, but If I recall correctly, when we added client-side composition to our blog [1], I had to capture the scroll position when I pushed a new entry into the history stack. When that entry is popped back off, I manually move the scroll position since the browser doesn't know to do that itself.

I think it more or less works. If you scroll down and click one of the older entries and then press back, it should remember where you were in the bigger page.

Kind of a pain in the rear, frankly. It was sort of fun doing the client-side composition, and I like the immediacy of it, but I'm left a little apprehensive.

[1] http://www.techempower.com/blog/

Re: Why Meteor will kill Ruby on Rails

#183

Post by misuba »

bjourne wrote: 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…

The most hilarious thing about this is how uncannily your claims mirror those that Rails had to deal with when it was new - people saw the easy-to-get-rolling-with scaffolds and assumed Rails couldn't make your app look like anything else.

It took the better part of two years for people to stop saying so. The "smart, sensible people" condescendingly repeating "you need more than a _scaffold._" It was just as amazing then.

Re: Why Meteor will kill Ruby on Rails

#184

Post by rurounijones »

joshowens wrote: post #60
scotth wrote: post #48

Earlier quoted context omitted.

I can think of one reason, although it's not necessarily a good one, or the only way to do it. Once the connection is established, the server could push down all required resources for the page, rather than wait for the browser to request them one by one.

It is built in Meteor, we just switch our whole site to use it. We switch from rails because we have much more Meteor knowledge on our team.

"Right tools for the job"

Meteor is not (and rails probably isn't either) the right tool for a simple blog like that. jekyll or something like that is.

The fact that you used an inappropriate tool for a blog and then say on the blog how you use that tool for all your clients casts a shadow on your professionalism I feel.

Re: Why Meteor will kill Ruby on Rails

#185

Post by hippee-lee »

joshowens wrote: post #142
jarsbe wrote: post #119

Earlier quoted context omitted.

I'd love to see some examples of these apps, are you able to please share?

Sure: http://www.shinglecentral.com/ http://assistant.io/ http://lister.io/ Are just a few from the last 1.5 months.

Can you point to some example that are a bit more complex in nature? My issue (that I identified with the backbone tutorials and re affirmed with the Angular tutorials) is that simple apps are easy to do with x, y or z. But if the new one or that one is going to replace the old one there should be 37 signals level complexity type apps out there. While I can't speak for Meteor, I don't see anything running on angular that's at that level.

Caveats: I glossed over the fact that angular is not a full stack, I have seen a few angular videos where teams have demoed and presented on complex angular apps.

Re: Why Meteor will kill Ruby on Rails

#187

Post by ben_mcmahen »

Having made some fairly substantial web-apps using Meteor such as http://subtitles.fiddlware.com, I can say that Meteor does make it incredibly easy, at least at the outset, to create a certain kind of application. It's great for something that is fairly self-contained; i.e., the task of the app is fairly narrow, and only consists of 1 - 2 pages... which may still make up multiple views. It's incredibly easy to implement a login system. And if you're at all dealing with something that is real-time, Meteor basically gives you socket.io style functionality for free. It was a good fit for the subtitles application.

But there are definitely some weaknesses. It doesn't scale particularly well -- and I don't mean, necessarily, in terms of performance, I mean in terms of creating a large application... or a page with many sub-applications. And while the reactivity is awesome... and the auto-real-time can be awesome... sometimes you can feel "locked in" to the Meteor-way, when another (declarative) approach may be more suitable. In a weird way, you end up "working around" the features of Meteor.

I'm increasingly convinced that a more modular approach is ultimately the best route... which is what something that express, sockjs, and component.js provide. I like using reactivity when I want to. And I like being able to swap different parts of the stack when desirable. It's typically more work at the beginning, but the flexibility can ultimately be liberating...

Re: Why Meteor will kill Ruby on Rails

#188

Post by aioprisan »

bjourne wrote: 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…

this is so wrong, you should really read the documentation first.. turn off autopublish and add server-side filters, should take about 2 minutes

Re: Why Meteor will kill Ruby on Rails

#189

Post by bzalasky »

dustingetz wrote: post #180
neya wrote: post #166

This is bullshit. In my whole experience as a full stack developer, after having tried various technologies and languages and frameworks - including ones built with PHP, Ruby, Scala, Javascript and Golang, I can this say with full confidence and can afford to put my name and credibility to stake - Nothing is going to replace Ruby on rails anytime soon. I wish something would, but nothing at the moment, is even close…

You have no idea what you're talking about. Like, your whole post is false

Seconded.

Re: Why Meteor will kill Ruby on Rails

#190

Post by rafekett »

qiqing wrote: post #130
bjourne wrote: 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…

Z-mongo-admin, the Meteor equivalent of phpMyAdmin, was a project that won a prize at the Meteor hackathon earlier this year. [1] Here's one of its authors, Geoffrey Vedernikoff, speaking at HackMIT. [2] Perhaps you could compare notes with the team to see what's going wrong in your version. [1] http://www.meteor.com/blog/2013/07/09/congratulations-to-the... [2] http://www.meteor.com/blog/2013/10/11/meteor-at-hackmit…

I'm sure his project worked, too, it just didn't scale.
Post reply on HN