Live data from Hacker News

Why Meteor will kill Ruby on Rails

differential.io

151–160 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#152

How exactly did the author come to this Meteor and Rails dichotomy? What do they have alike besides being web application frameworks, of which there are endless? This makes about as much sense to me as "Why Flask will kill Zend".

I came from Rails after using it for 8 years, so it is my easiest comparison point.

Give this whole Meteor thing some more time to sink in.

Your still in the honeymoon phase. I know this because you list context switching. Anyone that moves to Node(or meteor) and lists context switching as a reason, is not long for this world... of switching to node.

I'm not going to convince you here, but just proceed with caution. It would be like me convincing my friend after he's dated a girl for a year that she's a total ass. Not going to happen.

Re: Why Meteor will kill Ruby on Rails

#153
post #63

Earlier quoted context omitted.

It's not static and it's not readable HTML when accessed without JavaScript. If I understand, that's the feature of the framework that is being praised.

I don't think that's completely fair. Meteor to me, is more cased for building realtime applications. Should a blog be a realtime application? Probably not, can it? Sure. Not only that but, but the page compensated. It's also kind of neat, that the author has indeed written a realtime blog. For fun: they could magically fix typos while you're reading.

Or users could legitmataly highlight typos and they could get fixed in real time.

Re: Why Meteor will kill Ruby on Rails

#154
post #149
post #148

Earlier quoted context omitted.

100% agree here. Way to many Rails developers around for it to die. Also as cool as Meteor is, and it's pretty cool. There is a huge continent of developers that will resist javascript for as long as possible, because even though it is ubiquitous, let's be honesty, it does suck in a number of ways. Ruby / Python / Go / etc.. are all so much nicer languages from a developer happiness perspective. Ultimately javascript…

if only all the browsers would run python... now that would be developer happiness. ;)

unless you happen to be one of those sickos who thinks significant whitespace is a terrible idea....

Re: Why Meteor will kill Ruby on Rails

#155

It depends on your definition of kill. If you mean for new project starts, it might severely diminish it, but I don't think it will flat out end its popularity any more than Rails killed Java. Also, it depends on what type of project you are talking about. For something at large scale, my guess is meteor won't be any more successful than Rails has been at huge scale (like Twitter). I do agree that using one language…

I can go into large detail why calling it incredibly painful and unpleasant is nothing but hyperbole though. Have you tried building a to-do MVC app, at least?

GP is expressing a personal language preference. I also find JS horrific to work with (and I've worked with it a lot). But that doesn't mean you can't or shouldn't enjoy it.

Re: Why Meteor will kill Ruby on Rails

#156

Earlier quoted context omitted.

>I wonder if Meteor will end up introducing security holes like ASP.NET, as developers forget there's an abstraction and clients can't be trusted? (In ASP.NET, things like being able to screw with viewstate or fire events for disabled controls.) This is a thing for Meteor already. For example, if you have the insecure package enabled, you can can make changes directly to the database from the browser console. However…

Insecure is there to help speed development when you are getting started. All frameworks can do their best to compensate for security holes, but ultimately people need to pay attention to it. That being said, Meteor offers a call method and code runs on the server - if security is a concern then you should pay attention to what happens on the server.

I've not used Meteor. How exactly does "insecure" help speed development? Certainly any code you write with it is worthless, right? I mean, before production you need to remove it and rewrite it using another method, so what's the point? Or do you mean it's useful on the sysadmin side, as a REPL-like data access console?

Re: Why Meteor will kill Ruby on Rails

#157
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.

http://assistant.io/ :

> Uncaught Error: Must set options.password > 62afa287c8fae43c43f745c9f43dbcd4b875e531.js:14

> Uncaught TypeError: # is not a function

When trying to add attendees,nice UI though.

Re: Why Meteor will kill Ruby on Rails

#158
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.

Neat - earlier today, I was just experiencing the pain that assistant.io apparently alleviates.

Re: Why Meteor will kill Ruby on Rails

#159

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…

Hah, I went to the website and it just sat there refreshing itself. After me manually refreshing it a few times it eventually loaded. Can't say I would bother touching Meteor.
Post reply on HN