Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails is just an API

blog.alexmaccaw.com

Post reply on HN
Print view View original

101–110 of 114 posts

Re: Rails is just an API

#101

Post by [deleted] »

moe wrote: post #100
n8agrin wrote: post #81

Earlier quoted context omitted.

I don't fully understand your point. My quote you're using is meant to be rhetorical. So you're not Twitter... are you implying that you could build an all JS application and avoid all of the problems that Twitter ran into at Twitter's scale? If so, I'd love to see you execute your ideas successfully and explain them so we could all learn from you.

Yes, I'm implying that. I have personally done it for smaller apps. Google and others are demonstrating it with gmail et al, at a significantly higher complexity than twitter. It's nonsensical to conclude "Twitter can't do it so it isn't possible". I maintain twitter.com is slow because twitter is incompetent or doesn't care about their product. When you look at what the page actually does then there's no reason why…

[deleted]

Re: Rails is just an API

#102

Post by kalleboo »

moe wrote: post #100
n8agrin wrote: post #81

Earlier quoted context omitted.

I don't fully understand your point. My quote you're using is meant to be rhetorical. So you're not Twitter... are you implying that you could build an all JS application and avoid all of the problems that Twitter ran into at Twitter's scale? If so, I'd love to see you execute your ideas successfully and explain them so we could all learn from you.

Yes, I'm implying that. I have personally done it for smaller apps. Google and others are demonstrating it with gmail et al, at a significantly higher complexity than twitter. It's nonsensical to conclude "Twitter can't do it so it isn't possible". I maintain twitter.com is slow because twitter is incompetent or doesn't care about their product. When you look at what the page actually does then there's no reason why…

Isn't "they could serve direct links as static HTML" the whole point of this discussion? That writing the whole app as JavaScript only is too slow?

In any case, Gmail is not a good example to support your case since it loads just as slowly as Twitter does, with a progress bar and everything.

Re: Rails is just an API

#103

Post by regularjack »

rimantas wrote: post #98
regularjack wrote: post #97

What about graceful degradation? Making JavaScript a requirement instead of an addition is plain wrong and goes against the essence of the Web.

Only if "Web" for you consist of mostly static content. For others there is an interesting thing called Web Applications. How do you gracefully degrade a game done with all cool stuff HTML5 and friends offer?

No, I'm not talking about static content, I am talking about dynamic content, which is exactly what Rails is there for. If you only have static content you don't even need Rails, just have the web server deliver it.

I was not talking about "Web Applications" either, which, FYI, are not the same thing as dynamic content. I realize that he mentions in the post that he's mostly talking about Web Applications, but then he's just stating the obvious and the post title should be "For Web Applications, Rails is just an API".

Re: Rails is just an API

#104

Post by kalleboo »

virtualeyes wrote: post #53
jshen wrote: post #43

Earlier quoted context omitted.

"Every big website on the web right now" Can you define big? I've worked on some big sites that used MRI ruby for APIs and we served a ton of traffic with strict SLAs for a max of 250ms at the 99th percentile and things like that.

oh, Twitter (Scala/Java), American Airlines (Java), Facebook (on HipHop in C++), Stackoverflow (C#), ESPN (Java) I think by big that's a code word for enterprise. The big sites you have worked on are comparatively small if Ruby is backing the show. That's not to take away from the ton of traffic that you guys were able to serve; it's just that there are few enterprise level Ruby backed sites running these days. Githu…

If you haven't seen Twitter errors recently that just means you haven't been working with the Twitter API enough.

Re: Rails is just an API

#105

Post by virtualeyes »

getsat wrote: post #68
virtualeyes wrote: post #54

Earlier quoted context omitted.

Yes, you're correct, it was not an either-or proposition, I'm sorry, they dropped them both. Seriously, I'm curious, what public facing, or any facing, components does Twitter use that is written in Ruby and/or Rails? A Google search for "twitter rails" brings up the usual got dumped threads. A similar search, but this time, "twitter scala" brings up, as a first result "Scala School" for Twitter engineers, followed b…

I have multiple friends working at Twitter. The frontend is still all Rails.

Bizarre, can find nothing on the net that backs that claim, would love to see concrete evidence here in 2012, was under the impression that Twitter was fully ditching Rails.

Re: Rails is just an API

#106

Post by jamesgeck0 »

jiggy2011 wrote: post #71
hcarvalhoalves wrote: post #41

Earlier quoted context omitted.

Agree, althought I'm not fully convinced the web is fit for "web apps", or that even "web apps" make sense. At least not with current technology. Developing apps to run on the browser still implies a lot of redundancy: you are forced to work with solutions that weren't created for interactive applications in the first place (HTTP, DOM), limited to one language designed by comitee (Javascript) and code reuse is minima…

I think there are 4 reasons we are here. 1) Developers are worried that a user won't try their app if they have to install something on their computer. 2) Compatibility , support anything that can render HTML , although this may no longer be the case with the amount of chrome only apps I see. 3) Firewalls, you can get out on port 80 pretty much anywhere, that random port number you decided to use for your app not so…

Java applets and Flash aren't hated because they're powerful. It's because they're perceived as slow. Java applets used to make my entire browser freeze up for a few seconds when they loaded. Before installing AdBlock, I would regularly see Flash ads chugging along at 100% on one of my CPU cores.

Re: Rails is just an API

#107

Post by moe »

kalleboo wrote: post #102
moe wrote: post #100

Earlier quoted context omitted.

Yes, I'm implying that. I have personally done it for smaller apps. Google and others are demonstrating it with gmail et al, at a significantly higher complexity than twitter. It's nonsensical to conclude "Twitter can't do it so it isn't possible". I maintain twitter.com is slow because twitter is incompetent or doesn't care about their product. When you look at what the page actually does then there's no reason why…

Isn't "they could serve direct links as static HTML" the whole point of this discussion? That writing the whole app as JavaScript only is too slow? In any case, Gmail is not a good example to support your case since it loads just as slowly as Twitter does, with a progress bar and everything.

Isn't "they could serve direct links as static HTML" the whole point of this discussion?

For me the point of the discussion was the claim that the first-load performance of a fat-client app is inherently terrible.

This is false.

It is a straightforward optimization problem. Twitter didn't care to optimize.

I don't think it is under debate that the overall responsiveness (after first-load) in a client-side app is heads and shoulders above anything you can achieve in the request/response paradigm. Network latency is real, AJAX can mitigate it but instant response is only possible when you don't hit the server.

So all we're talking about here is the specific (important) case of the initial page-load. As said above, that case has tons of optimization potential, up to the point where it's near indistinguishable from a regular HTML page-load.

Gmail is not a good example to support your case

This may be subjective. Yes, GMail is slow. But it loads faster than twitter for me, despite being significantly more complex. I also imagine google has less incentive to optimize the first-load because unlike twitter users rarely follow deep-links to gmail.

Now imagine twitter applied only the little optimization that google has to their much smaller app - the latency problem would probably not exist. And if that's not enough, I can only repeat: It's a valid approach to serve static HTML for direct tweet links (or just for everything) and upgrade it asynchronously.

My point is that it's very possible to optimize this problem away where it matters (deep links to tweets). I've done it myself a couple times. It's nasty gruntwork, involving endless Firebug sessions. Crying Foul and "this is not possible" is a lazy cop-out.

Re: Rails is just an API

#108

Post by virtualeyes »

regularjack wrote: post #103
rimantas wrote: post #98

Earlier quoted context omitted.

Only if "Web" for you consist of mostly static content. For others there is an interesting thing called Web Applications. How do you gracefully degrade a game done with all cool stuff HTML5 and friends offer?

No, I'm not talking about static content, I am talking about dynamic content, which is exactly what Rails is there for. If you only have static content you don't even need Rails, just have the web server deliver it. I was not talking about "Web Applications" either, which, FYI, are not the same thing as dynamic content. I realize that he mentions in the post that he's mostly talking about Web Applications, but then h…

Rails is there to generate static content as the alternative, hitting the Rails stack for live data, is asking for trouble -- just ask Twitter ;-)

Of course by saying such a thing on a Rails thread, I am clearly asking to accrue yet more karma. I can take it, the truth hurts, I'm a compile time Boddhisatva brought here to enlighten the heathens, willing to descend into runtime hell to save all beings and bring them to the other shore of static compilation.

May all beings be snappy (and never sluggish)

Re: Rails is just an API

#109

Post by hcarvalhoalves »

jiggy2011 wrote: post #71
hcarvalhoalves wrote: post #41

Earlier quoted context omitted.

Agree, althought I'm not fully convinced the web is fit for "web apps", or that even "web apps" make sense. At least not with current technology. Developing apps to run on the browser still implies a lot of redundancy: you are forced to work with solutions that weren't created for interactive applications in the first place (HTTP, DOM), limited to one language designed by comitee (Javascript) and code reuse is minima…

I think there are 4 reasons we are here. 1) Developers are worried that a user won't try their app if they have to install something on their computer. 2) Compatibility , support anything that can render HTML , although this may no longer be the case with the amount of chrome only apps I see. 3) Firewalls, you can get out on port 80 pretty much anywhere, that random port number you decided to use for your app not so…

The problem with Java applets and Flash is that they are a broken model inside another broken model - they shoe-horn their own VMs to run applications inside a browser. It's the ultimate hack.

The web, as it was originally envisioned, makes perfect sense: HTTP, URIs and hypertext to provide navigable content, period. On the other hand, building interactive applications by manipulating the DOM while reinveinting UI patterns and widgets over and over again seems like a hack that grew to enormous proportions.

I feel the reason why "web apps" are so popular is because it allows small startups to develop more-or-less cross-compatible products faster and with fewer resources than developing a webservice and then hiring 4 engineers: one for a Windows client, one for a Mac client, one for a iOS client and one for an Android client. The fact browsers all follow more-or-less the same standards and they all run Javascript turned them on the "write once, run everywhere" platform that Java failed to deliver, but in my opinion it's still (very) far away from ideal.

Re: Rails is just an API

#110

Post by n8agrin »

moe wrote: post #107
kalleboo wrote: post #102

Earlier quoted context omitted.

Isn't "they could serve direct links as static HTML" the whole point of this discussion? That writing the whole app as JavaScript only is too slow? In any case, Gmail is not a good example to support your case since it loads just as slowly as Twitter does, with a progress bar and everything.

Isn't "they could serve direct links as static HTML" the whole point of this discussion? For me the point of the discussion was the claim that the first-load performance of a fat-client app is inherently terrible. This is false. It is a straightforward optimization problem. Twitter didn't care to optimize. I don't think it is under debate that the overall responsiveness (after first-load) in a client-side app is head…

You're making a lot of assumptions that are unfounded.

What you're suggesting is usually called progressive enhancement. Yeah it's great, but sadly when you are using a system like Spine, Backbone or Ember, it's not just a matter of "endless Firebug sessions" to resolve the initial bootstrap problem.

No one claims that this is not possible, nor is anyone "crying foul". On the contrary I know first hand how much of this work was done at Twitter and how difficult it is. But as you stand by your petulant claim that "twitter.com is slow because twitter is incompetent or doesn't care about their product." I stand by mine, that there are tradeoffs when embracing one style of development over another.

Feel free to disagree with me but back it up with experience, not false assumptions, blanket statements and the denigration of many good people.

Post reply on HN