Live data from Hacker News

Why Meteor will kill Ruby on Rails

differential.io

91–100 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#91

Earlier quoted context omitted.

Then you probably don't eat spaghetti.

You must not be familiar with this utensil. It is a spoon with a fork like end. Many a plate of school lunch spaghettis has been eaten with a spork.

It's still much easier and more efficient to eat spaghetti with chopsticks.

Re: Why Meteor will kill Ruby on Rails

#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 and for highscore lists consisting of 10-20 items. Not so great when there are 500k items ordered by score and someone wants to paginate through all of them.

It's trivial in a sql-database backed application, but more or less impossible with Meteor because you can't listen to arbitrary queries without having the whole collection in the clients memory.

Btw, I'd love to be proven wrong though. I tried to write an equivalent of phpMyAdmin for the Meteor+MongoDB combination, but I couldn't figure out how to how to provide clients with an always updated view of mongo collections without running them out of memory.

Re: Why Meteor will kill Ruby on Rails

#93

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…

Thanks for identifying those issues — bugs we'll fix.

Re: Why Meteor will kill Ruby on Rails

#95
Josh, it's an increasing article.

I don't know what types of apps your company builds but it would be nice to state that. I certainly don't think you believe that Meteor is a good fit for all kinds of web apps. It does seem like its a really good fit for the apps that your company builds.

I would get more out of your article if you provide some context around the types of apps your company is focused on.

Re: Why Meteor will kill Ruby on Rails

#96
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…

Your claim that the client has a full copy of the server's data is incorrect. By default that is the case, but removing such functionality takes only a few lines of javascript and removing the "autopublish" package (one command).

Seriously, Meteor has grown up a lot recently. This stuff moves quick. I encourage you to take a look at it again, because I imagine many of your initial problems with the platform have been settled - there are still people out there who feel any user can clear out the whole DB from the client .

Re: Why Meteor will kill Ruby on Rails

#97

It concerns me that the selling points of Meteor are the same as the old selling points of ASP.Net. - Both seek to make the divide between server and client "seamless", marshaling data back and forth so that you can "call" server code from the client and vice-versa. - Both tout the ability to do all your development in a single language - Both claim impressive gains for RAD ASP.Net had some impressive demos for its t…

Of course ASP.NET was closed source, and from Microsoft — Meteor is open-source, and is being driven by a small team.

What does that have to do with any of the points raised?

Re: Why Meteor will kill Ruby on Rails

#98
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…

Meteor has publication/subscription system that ships only data you specify w/ very fast communication w/ server.

Re: Why Meteor will kill Ruby on Rails

#99

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…

Your feelings towards JavaScript essentially mirror mine, though I've found writing code in TypeScript for Meteor has been a much more pleasant experience and gives me more confidence in the code I write.

https://github.com/orefalo/meteor-typescript-compiler

http://www.typescriptlang.org/

Re: Why Meteor will kill Ruby on Rails

#100

It concerns me that the selling points of Meteor are the same as the old selling points of ASP.Net. - Both seek to make the divide between server and client "seamless", marshaling data back and forth so that you can "call" server code from the client and vice-versa. - Both tout the ability to do all your development in a single language - Both claim impressive gains for RAD ASP.Net had some impressive demos for its t…

ASP.NET enabled a lot of certain types of developers to quickly drag-n-drop web apps just like they did with VB Windows GUIs. The amount of code needed was pretty cool. Sure, it resulted in a less-than-ideal webpage, but it worked. VB.NET wasn't really a foundation; it had major changes from VB6 and had feature parity with C# (and more in some cases). Javascript is by far a much worse language. What should we expect…

>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, this particular issue can easily be detected prior to deploying to production.

Post reply on HN