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

311–320 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#311

Post by dham »

jaegerpicker wrote: post #298
dham wrote: post #269

Earlier quoted context omitted.

First you say > . You just have to do so much glueing In your previous post. Then you list out MEAN(Mongo, Express, Angular, Node), which is all glueing. I have used this stack extensively, and I must say its not even close to Rails. In fact it's not even on the same planet. After all you guys finish your piddly todo lists, start trying to write some real business logic in Node, and see how far it gets you. There is…

Yes because no one has built real business logic in node.js. and clearly node.js is only good for piddly todo lists. I've worked with python/Django, rails, and node.js on real complex apps with huge amounts of business logic built in them. Each one had advantages and disadvantages. I will say that MEAN certainly compared very well to both type of apps once in production. I was more productive in the other two but per…

I Never said no one has built business logic in Node.js.

I'm also not sure where you implied that I've dismissed Node, because I most certainly haven't. In fact I have several Node applications in production at my company. I'm just stating facts, and to be honest I'm extremely open minded when it comes to new frameworks.

But Meteor, I've been there done that. It's called JSF in the Java community.

Thanks.

Re: Why Meteor will kill Ruby on Rails

#312

Post by bennyg »

mbesto wrote: post #299
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…

I'll just leave this here: Let’s say you decide one day you want to build a table. This table is going to be made using wood, nails and a hammer. All things being equal, let’s say you build this table with hammer A that has a utility of 10. You build a second table with hammer B and it has a utility of 15. You, the carpenter, have now created two tables, table A and table B, respective to their hammers. The tables ar…

What is utility measure of? This analogy is way too simplified to be of real importance. There are more tools that go into building a scalable, maintainable table.

Re: Why Meteor will kill Ruby on Rails

#313

Post by rglover »

dham wrote: post #279
rglover wrote: post #274

Earlier quoted context omitted.

Simple: I'm a front-end developer by trade and Meteor gave me something I understood (JavaScript) on both the client and server. To build this in Rails would have meant learning both Rails and Ruby. My app doesn't need to be realtime, and that's a narrow way to look at Meteor. Real time is just a nice bonus that the framework enables.

But why? Meteor is a paradigm shift from the front end. Front end Javascript is asynchronous and event based. Meteor is synchronous. You're going to take a hit learning any framework, no matter the language. I picked up Rails just as fast as I did Play framework, and I had never looked at Ruby before. The whole NodeJS appeals to front end programmers thing kind of reeks to me. I think it's an irrelevant argument. I m…

I think it's an irrelevant argument.

I could say exactly the same thing. For example, say a new Ruby framework was released that you really enjoyed and you "got it" because it was similar to Rails or aligned well with Ruby. The same principle applies: if something is familiar, it stands to reason that you'll have an easier time comprehending it.

Regardless, does what framework I use really matter? As long as I'm able to solve problems in a way that makes sense to me, I don't really see the point in wasting time debating what to use.

If the pajamas are comfortable, they're comfortable. Who cares if they're blue or green?

Re: Why Meteor will kill Ruby on Rails

#314

Post by dfischer »

petercooper wrote: post #103
al2o3cr wrote: post #7

"Let's be real, Javascript is the #1 language on Github and for good reason - it runs everywhere." Similarly, anal sex is the best kind because it works on all genital configurations. /snark

I suspect there's a significant number of people who would actually agree with that though.

Touché Peter, touché.

Re: Why Meteor will kill Ruby on Rails

#315

Post by nostrademons »

optymizer wrote: post #282
nostrademons wrote: post #207

Earlier quoted context omitted.

That's all true, but I'm also beginning to wonder how much you actually need those frameworks to build MVPs quickly. I used to do the bulk of my prototyping with Python + Django + JQuery + Postgres or AppEngine Datastore. Of late, I've switched a lot of it to just straight HTML + Javascript + a JSON feed from backends. If I need server-side computation, I'll build a quick Go or webapp2 app on AppEngine. I work just a…

> .ajax = iframes I was pretty much in the same boat as you regarding all the other choices, but when i saw this I thought: "Seriously?" I remember when AJAX came out: I was finishing my iframe-based custom-rolled 'AJAX'. It was such a hack, I can't even believe someone would consider it in 2013. Why not XMLHttpRequest?

Iframes have a couple advantages over XHR:

1. You can do progressive rendering with an iframe. With an XHR you don't get the 'loaded' callback until the entire response has arrived, and so you can't start working with and manipulating the data until it's all there. With an iframe you can put successive chunks in tags and they will start executing as soon as the closing tag for the script is found. Or if you want to transport the data as HTML, you can put a 0-length animation on each element that forms a response chunk, and listen for the animationend event to get notified as soon as it's ready in the DOM.

2. You can measure and manipulate elements while they're still in the iframe. For example, if you're animating the rest of your layout, you can measure the size of the elements that you just loaded inside a hidden iframe, adjust transitions on the main page to make space for them, and then pop the elements from the iframe into their proper places in the final layout. With an XHR, the only way to measure the element is to place it into the DOM and force a layout, which is much slower, particularly on mobile devices.

3. Iframes form a layout boundary, so when the browser lays out elements in them it stops the layout process at the iframe. This eliminates the need to do a CPU-intensive layout of the whole page when you pop in your XHR content.

Re: Why Meteor will kill Ruby on Rails

#316

Post by nostrademons »

hnriot wrote: post #301
nostrademons wrote: post #207

Earlier quoted context omitted.

That's all true, but I'm also beginning to wonder how much you actually need those frameworks to build MVPs quickly. I used to do the bulk of my prototyping with Python + Django + JQuery + Postgres or AppEngine Datastore. Of late, I've switched a lot of it to just straight HTML + Javascript + a JSON feed from backends. If I need server-side computation, I'll build a quick Go or webapp2 app on AppEngine. I work just a…

that's all correct, but then you ruined it with the .ajax= iframes nonsense and the total waste of time removing jquery. optimizing for the right things is important, but doing the wrong ones is just wasting your time.

See my other response on iframes:

https://news.ycombinator.com/item?id=6649195

One of my big surprises moving to Google was how much iframes are still used, but even beyond that is the very pragmatic approach of looking for exactly what a technology gives you and what it costs you in return. There's basically a 1:1 correspondence between the API of an iframe and the API of an XHR:

xhr.open = iframe.src

xhr.onreadystatechange = iframe.onload

xhr.response = iframe.contentDocument

Many devs don't like working with iframes because it doesn't fit their mental model of how a request should work (possibly because iframes were initially introduced with a visual extent), but that's a problem with their mental models, not with iframes. You can always wrap the API if you don't like it, anyway - pretty much all the major frameworks do, since raw XHRs are a bit clumsy to use.

Re: Why Meteor will kill Ruby on Rails

#317

Post by aaronem »

al2o3cr wrote: post #7

"Let's be real, Javascript is the #1 language on Github and for good reason - it runs everywhere." Similarly, anal sex is the best kind because it works on all genital configurations. /snark

No it doesn't; you need at least one penis involved. /taking-snark-seriously

Re: Why Meteor will kill Ruby on Rails

#318

Post by bjourne »

dboat wrote: post #143
bjourne wrote: post #114

Earlier quoted context omitted.

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…

You could have asked for help, but that wouldn't work very well here, it's not what this site is for after all. Far more effective to announce something incorrect and let the forces of truth and justice solve your problem for you. Well played.

Yep, if only the "forces of thruth" actually knew what they were talking about it would have worked great. :) Btw, I've asked for help in other places (which I won't link to as I like to keep my internet identities somewhat separated) but no one has an efficient way to deal with large collections.

Re: Why Meteor will kill Ruby on Rails

#319

Post by derefr »

nostrademons wrote: post #315
optymizer wrote: post #282

Earlier quoted context omitted.

> .ajax = iframes I was pretty much in the same boat as you regarding all the other choices, but when i saw this I thought: "Seriously?" I remember when AJAX came out: I was finishing my iframe-based custom-rolled 'AJAX'. It was such a hack, I can't even believe someone would consider it in 2013. Why not XMLHttpRequest?

Iframes have a couple advantages over XHR: 1. You can do progressive rendering with an iframe. With an XHR you don't get the 'loaded' callback until the entire response has arrived, and so you can't start working with and manipulating the data until it's all there. With an iframe you can put successive chunks in tags and they will start executing as soon as the closing tag for the script is found. Or if you want to t…

Regarding the first objection, you could just send your responses as a series of websocket messages, rather than repeated AJAX request/response pairs.

The other two objections I'm not so clear on--maybe because I don't often dynamically construct views by retrieving "presentation" from the server. In what I've seen as "idiomatic HTML5 client-side development", all the views are shipped as templates with the initial code-blob that starts up the client; from then on, the client just speaks pure data-related JSON to the backend's plain HTML-unaware API. Does this practice not scale to Google levels? :)

Re: Why Meteor will kill Ruby on Rails

#320

Post by bjourne »

benaiah wrote: post #121
bjourne wrote: post #114

Earlier quoted context omitted.

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…

It's quite easy, and you still get reactivity. You publish the collection as before, but you write a server-side filter (a well-documented core feature) that only sends a small piece of that to the client. Even though the client only sends a small piece, the changes to those items are still reflected back to the server and other clients live. It's supported this from the day it was released - I remember hooking up so…

In addition to that to make robust pagination you need aggregation. Printing the message "you are looking at page X of Y pages" requires you to know the count of the collection or else you can't say how many pages there are. I.e You need to reactively monitor MongoDB's equivalent of "select count(*) from blaha". Doing that (without cheating and caching the count) is very expensive in Meteor.
Post reply on HN