Live data from Hacker News

Why Meteor will kill Ruby on Rails

differential.io

131–140 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#131

Derby ( http://derbyjs.com/ ) ostensibly does everything that Meteor does, but seems to be flying a bit under the radar. I'd be interested to hear comments from anyone that has had experience building apps in both Derby and Meteor.

The documentation for DerbyJS is unfortunately somewhat thin on the ground at the moment, which is a shame.

They do have this YouTube tutorial though, where they run through how they made the multiplayer story game:

http://www.youtube.com/watch?v=V0DOGXmaT3g

Code is on Github here:

https://github.com/codeparty/multiplayernotepad

Demo (currently unavailable):

https://stories.derbyjs.com

Re: Why Meteor will kill Ruby on Rails

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

(MDG-er here) A few meteorites actually did write an equivalent of phpMyAdmin for the Meteor Summer Hackathon, in case it's of interest to you: http://www.youtube.com/watch?v=ixJyB8Z-tU8 :-)

Re: Why Meteor will kill Ruby on Rails

#133
post #97

Earlier quoted context omitted.

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?

I have more faith in open-source community to fix warts vs. closed-source Microsoft. I did ASP.NET back when it launched, and Microsoft wasn't setup to really listen to developers like the Meteor team is.

Re: Why Meteor will kill Ruby on Rails

#134
post #74

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…

Similarly on the Java side you've got JSF which is basically ASP.Net ported to Java. It was a dumb idea when ASP.Net did it, and it was still a dumb idea when it was ported to Java. Now we have the same dumb idea ported to Javascript. Also as you point out, Javascript. Thanks but no thanks, give me a proper REST API on my server, and a good JS framework on my client, and I could really care less what language the ser…

I had the great privilege of working and maintaining a few JSF applications for a year or so when I first got into my job. -_-. I even had a greenfield project with it. It's probably the worse thing you can use, and after some asking, pleading, and convincing the boss we moved to Play 1.x. That turned to be a wank fest with the whole Scala and Play 2 thing coming in a year or so later. We ended up just going to the source of all good MVC frameworks and landed on Rails, with a move into Node for a few months before Rails.

I tried Meteor a few times and the whole thing just reeks of JSF. I wont touch it with a ten foot pole.

On the other hand Rails and Ember really flow good together. I was more of an Angular fan, but the whole Ember integration is great. Rails makes it really easy to do nice API's without a whole lot of boilerplate. Database handling is awesome. Migrations are nice. Lots of gems. I feel like someone is holding my hand, while with Node I felt like I was holding my breath the whole time. If that makes sense. It was like a sigh of relief when we moved to Rails.

The whole context switching thing is overrated IMO.

Re: Why Meteor will kill Ruby on Rails

#135
I'm tempted to say: "unless mongoDB gets a lot better, this is not going to be true." However, a minute fraction of the rails community is large sites, so it doesn't matter.

I also think a lot of people like rails because they find ruby extraordinarily beautiful. As much as I like JS, beautiful syntax is not its strong suit.

Re: Why Meteor will kill Ruby on Rails

#137
post #97

Earlier quoted context omitted.

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?

it means if you have to explore some "invisible" process, you can see exactly what it does and inject your own code if you want to change it.

Re: Why Meteor will kill Ruby on Rails

#138
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 very easy to do in Meteor. You just tell Meteor to only publish the information you need, just as you would in any other web application.

I am currently running an enterprise software project on meteor with thousands of pieces of data in the database. If I published all of the data at once, it would crash the browser. I know because I actually did it when developing. Once you write the correct publish functions, it runs extremely quickly and only has the information you need in memory. All of this data is reactive too. And yes, you can paginate the information.

Re: Why Meteor will kill Ruby on Rails

#139
post #63
post #27

While I was reading this post, the page automatically reloaded to something that said "oops, this page can't be found", and then a few seconds later loaded back to the original. This is while I was simply reading the text, not interacting with the page at all. Somehow, through the magic of JavaScript and Websockets, they managed break passively reading static content.

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.

Post reply on HN