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

111–120 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#111

Post by awj »

programminggeek wrote: post #72
orclev wrote: post #49

Earlier quoted context omitted.

Ruby and Java don't really compete in the same space, it would probably be better to compare Ruby and PHP as those two are the primary competitor with each other. If you wanted to point to a competitor to Java, .Net would probably be the closest match.

I agree, but when Rails came out, there was a whole lot of Ruby on Rails is going to kill Java type posts. I guess this means Meteor is reaching some mindshare.

Yeah, and we saw how well that worked. Java projects sprung up to incorporate the good ideas from Rails, Rails itself picked up a load of developers and evolved into something decent, and the world moved on. Nothing was killed, but all the boats rose.

I'm thinking maybe the drama wasn't a requirement for this to happen. Perhaps Meteor devs could experiment with that idea.

Re: Why Meteor will kill Ruby on Rails

#112

Post by vetrom »

I think there is some degree of conflation here. You can have different views/communication for session state and separate that from database state.

Websocket apps are almost invariably in the family of apps that act on some sort of session synchronization, and if you are depending on a synchronized full-view between serverclient, then yes, you will have a bad time if your working set grows without bounds.

If you are more concerned with just prediction/event/streaming and have a decent invalidation/resync mechanism, then meteor becomes a natural choice for interactivity.

Oh, wait, there's the first two problems in CS again — caching and naming things.

Re: Why Meteor will kill Ruby on Rails

#113

Post by joshowens »

jaredsohn wrote: post #100
MichaelGG wrote: post #85

Earlier quoted context omitted.

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…

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.

Re: Why Meteor will kill Ruby on Rails

#114

Post by bjourne »

prezjordan wrote: post #96
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…

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…

No stopping autopublish doesn't solve anything in this case. In my leaderboard example, the clients view of the highscore is dependent on all data in the collection which has to be published and the client has to subscribe to it.

Even if you only want to show the best 10 scores of your 500k population, Meteor doesn't allow you to subscribe to the Mongo equivalent of "select player, score from results order by score desc limit 10" (last I checked anyway) And even if it did, well what if you want to see result 11-20 or the 10 best scores among your friends?

You or someone else is very welcome to prove me wrong here and I'll admit I'm an idiot. All that is needed is 1 grid, 500k items, allow me to sort up and down on the headers and let me paginate through it as I please and support 5 simultaneous users. Trivial to write using Rails or Django. I claim impossible to write in Meteor.

Re: Why Meteor will kill Ruby on Rails

#115

Post by joshowens »

orclev wrote: post #74
curveship wrote: post #68

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…

So it is ok to go build a node.js REST api and slap Angular.js on it and somehow that is better?

You really should care what language/framework the server side is built in because someone has to work on it...

Re: Why Meteor will kill Ruby on Rails

#116

Post by lambda »

rywalker wrote: post #87
lambda wrote: 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.

sorry that was a deploy to fix the "oops, this page can't be found" that was flashing before the page loads. When we deploy Meteor, it hot fixes the client (i.e. restarts the app in your browser)

My skepticism here is due to the use of an "app in my browser" to display a static blog post.

A blog post is fairly simple static content. My browser is an app that does fine at displaying it. By making the page an app that dynamically updates upon server changes, you actually substantially damaged my experience, as I was interrupted in the middle of reading the page.

I'm not opposed to apps which dynamically update data in real time from the server, when that's appropriate. A static blog post does not appear to be such a case.

The irony here is that this was on an article titled "Why Meteor will kill Ruby on Rails", an overstated claim describing how a framework build around updates from the ground up is so much stronger than one based on delivering static content. The actual behavior of the page seemed to speak more loudly than the content.

Re: Why Meteor will kill Ruby on Rails

#117

Post by rco8786 »

_7fvc wrote: post #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 Rai…

> I can say meteor will kill nodejs

meteor runs on nodejs...

Re: Why Meteor will kill Ruby on Rails

#118

Post by morgante »

bjourne wrote: post #114
prezjordan wrote: post #96

Earlier quoted context omitted.

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…

No stopping autopublish doesn't solve anything in this case. In my leaderboard example, the clients view of the highscore is dependent on all data in the collection which has to be published and the client has to subscribe to it. Even if you only want to show the best 10 scores of your 500k population, Meteor doesn't allow you to subscribe to the Mongo equivalent of "select player, score from results order by score d…

> Meteor doesn't allow you to subscribe to the Mongo equivalent of "select player, score from results order by score desc limit 10" (last I checked anyway) And even if it did, well what if you want to see result 11-20 or the 10 best scores among your friends?

That's actually all possible. Just write a good publisher which takes the number of results as an argument. All the sorting can happen on the backend and then you push down the x results.

Sure, not as effortless as autopublish, but also no harder than in traditional apps.

Re: Why Meteor will kill Ruby on Rails

#119

Post by jarsbe »

joshowens wrote: post #54
bowlofpetunias wrote: post #43

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…

This isn't just fashion. We launch client apps in 6 weeks, time isn't negligible for us.

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

Re: Why Meteor will kill Ruby on Rails

#120

Post by morgante »

_7fvc wrote: post #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 Rai…

> I can say meteor will kill nodejs, but not Rails.

It won't kill Node any more than Rails killed Ruby.

Post reply on HN