
Twitter Rolls Twitter.com Back to a Server-Side Architecture - apievangelist
http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html
======
parasubvert
This isn't a rollback of the API-oriented architecture, it's a rescue of a
bunch of wrong-headed design mistakes, like forcing the rendering of
individual status pages through a JavaScript function, using a hash-bang URI.

One of the major drivers behind the constraints in a RESTful architecture is
user-perceived response time. Routing all content through "code on demand",
which is effectively what you're doing when you force a JavaScript function to
do all the rendering, instead of the browser itself, is not taking advantage
of the fast, incremental rendering nature of plain old HTML generated by the
server.

One can still design good API-oriented URIs with a server-side approach,
you're just providing different serializations of the same resource (a nice
HTML one and a JSON one for API access).... so there's nothing fundamental
that Twitter has lost or abandoned here. They're just using the web better.

~~~
stdbrouw
HTML is HTML. Why would it be any easier for the browser to render server-
generated HTML incrementally, versus client-generated HTML?

~~~
parasubvert
Not easier... just faster.

Server-generated HTML: the browser GETs it and renders it as it streams
through.

Client-generated HTML: the server GETs an HTML page with a JavaScript link,
then GETs a JavaScript .js, then executes it, the jS GETs the JSON, then
translates that into HTML at the DOM level.

The latter is arguably something that will lead to a better user experience
once the page is in a "steady state", i.e. all dependent representations are
loaded into the browser and rendered. But relying on it for "first render"
makes for a slow experience when (e.g.) clicking on a link to an individual
Twitter status.

~~~
stdbrouw
Getting that JavaScript is a one-time operation, and a 304 from then on. Also,
the HTML can include bootstrapped data, saving the roundtrip for JSON.

Also, with client-side rendering you execute more code on the client but less
on the server, so in an environment like Twitter where it's not possible to do
any sort of heavy caching (everybody sees something else), you're simply
trading time on the server for time on the client. Not faster, not slower.

Server-side HTML generation is not a magical 0ms process.

~~~
callmevlad
Don't forget that JavaScript has to be interpreted every time the page loads,
even if you have a cached copy of it. If it's a large chunk of code, the time
to do that is not trivial.

I'm not quite sure that it's as much of a zero-sum game as you present it. I
can easily think of scenarios where rendering on the server is much faster
(e.g. using a compiled language vs JS, taking advantage of powerful hardware,
granular caching, etc) and much more constant.

Edit: spelling.

------
ComputerGuru
I am so proud of twitter right now, that I feel words will fail me, so I shall
keep this short and to the point:

It takes serious balls to admit you were wrong after you kicked off an entire
avalanche that has been breaking the web ever since. Yes, a lot of us knew
then it was a ridiculously bad idea and we all said so; but for them to
actually take this advice after going so out of their way to go completely
client-side is just fantastic. Kudos, twitter folk!

~~~
marknutter
For some web apps, namely ones that don't get linked to often like Twitter or
ones that are truly trying to behave like desktop applications, hash-bang urls
are really the only option for maintaining state in browsers that don't
support HTML5 push states yet. I think the backlash against Twitter's and
Gawker's use of them is warranted, but not the hyperbole that hash-bangs, no
matter the context, "break the web."

------
demetris
Here is the original post, by the Twitter engineers:

[http://engineering.twitter.com/2012/05/improving-
performance...](http://engineering.twitter.com/2012/05/improving-performance-
on-twittercom.html)

~~~
staunch
Maybe a mod will swap it for the blogspam. _nod_

~~~
n8agrin
I posted it immediately after it was announced. It got ~20 quick up votes but
never landed on the home page: <http://news.ycombinator.com/item?id=4040049>

------
akkartik
To mark this momentous occasion I'm going to go back and reread Steve Yegge on
Amazon's SOA.

[http://plus.google.com/112678702228711889851/posts/eVeouesva...](http://plus.google.com/112678702228711889851/posts/eVeouesvaVX)

------
bceagle
It is always a little misleading reading articles like this because they don't
get into many of the details. At the end of the day, you need to build to meet
the requirements of your target audience. It doesn't really make sense to
think that just because Twitter does something, then you should do it. The
optimizations they are talking about may be so specific that they don't even
apply to the common mid-sized web app. I think that the overall client-side
architecture has broken new ground and does provide benefits that make sense
for a lot of sites. I wouldn't think twice about not using the client side
architecture just because of Twitter making a change.

Also, as some people already noted, Twitter didn't abandon client side
rendering. If you go on the site now, you will still get redirected to the #!
page.

~~~
jsprinkles
This entry doesn't get into details because it's blog spam, submitted by the
blogger himself.

You want this: [http://engineering.twitter.com/2012/05/improving-
performance...](http://engineering.twitter.com/2012/05/improving-performance-
on-twittercom.html)

~~~
apievangelist
You guys are the blog detail. Your comments are the reason for short post.

~~~
jsprinkles
I'm not sure how you expect the discussion to be accurate or informative
without details that the article you summarized happily goes into. We already
see confusion about where it's rolled out because we're reading you, not
Twitter Engineering.

What does your post add to theirs? Honestly?

~~~
apievangelist
I'm not looking to add anything to theirs. Thats why I link to them. I'm
looking to get discussion here and on Twitter...while I formulate my own
thoughts...and more analysis. That's why I said...your the detail of this
post.

~~~
SkyMarshal
_> I'm not looking to add anything to theirs. Thats why I link to them._

Then link to them here as well. Save your own blog post for when you've got
some original insight to add, then submit it to HN. Not before.

 _> I'm looking to get discussion here and on Twitter...while I formulate my
own thoughts...and more analysis. That's why I said...your the detail of this
post._

That's lazy as shit.

------
callumjones
I wouldn't call it a rollback completely, but an improvement on the first time
load. The whole Twitter page is rendered initially server side but then any
subsequent request is made by JSON calls and rendered client side -- probably
the best approach given the time it took for Twitter.com to load.

------
DanI-S
Twitter is used in a lot of developing countries, through a lot of outdated
browsers, on a lot of slow computers. I'd imagine that this plays into their
choices somewhat.

------
tnash
I think this is great. The browser isn't an OS, it's a portal. It's already
running on an OS. It didn't work for mobile (remember Apple was all about the
web apps back in the day), it shouldn't work for desktop.

------
SCdF
Thank the creator. It was a blindingly unnecessary fashion statement that
caused more problems than it solves, and I wish it safe passage on its way to
the closet of failed experiments.

------
swah
But Twitter.com is slow (like a couple seconds to load twitter.com/#!/someone)
even if you're using the latest Chrome browser - it can't be just fault of the
client side architecture...

If the initial JSON was coming bundled with the page, the only reason for the
slowdown is parsing JS? I thought that was what browsers were good at those
days...

~~~
InclinedPlane
On a cold load you'd have to transfer 2 megs of mostly JS over the wire, and
only after all that was done could JS start rendering. Even with a fast 10
megabits/s line that will still take upwards of 2 seconds just to get to
square 1.

------
sunwooz
Sorry, but what's the difference between using a web application architecture
and using a server side architecture? I'm curious!

~~~
anextio
Are you familiar with Model-View-Controller?

In this case it would be moving some of the controller logic (the parts
responsible for rendering views and dispatching events from the UI) to the
browser, and using an API to communicate with the model (and the rest of the
controller).

So, if I'm going to display a page of 10 tweets, in the classic server side
architecture, I load the tweets, render a view template based on a context
containing those tweets, and then send the HTML to the browser.

In an API-based web application architecture like this, I _always_ send the
same HTML, which is cached in memory and is almost a no-op to send to the
browser, then the client side scripting looks at the URL of the page and makes
a call to a JSON or XML API that will result in those 10 tweets. These tweets
are then rendered on the client side by the browser.

This is beneficial in a few ways:

* You can re-use the exact same API and expose it to third parties, who can then write apps with all the functionality of your webapp, and you've one less thing to test.

* Rendering a template can be a (relatively) time-consuming operation that may require some I/O. On a single-threaded platform like Node.js, where you simply want to dispatch an event (request) as fast as possible and move on, rendering a template takes a lot of time.

* If the time is going to be spent rendering that template anyway, you may as well crowdsource it and let the browser handle it. The browser is probably only processing one page load at a time, whereas your servers could be processing thousands or millions.

The cons of using this system are related to the benefits:

* The API you use is likely to suffer from Abstraction Inversion[1], or if that's intentionally avoided, a Leaky Abstraction[2]. The reason for this is that there may be some pages to be rendered that require more complex, or less abstract, queries on the data. On the server you could easily issue a JOIN query, but it may not make sense to expose such a thing directly via a RESTful interface. Therefore your application may end up firing numerous API requests and joining the results manually in order to complete a request. If you DO expose this functionality, it will probably end up looking very out of place and very specific.

* The extra time spent by the browser may not be suitable in all cases. It poses a number of accessibility and performance problems on certain devices. I may not be able to use a certain website with a screen reader because of this, or I may not be able to view it on an ancient version of Opera running on a shitty old phone over 3G. Even on a modern smartphone, the time taken from seeing a Twitter page's header and background with the loading indicator to actually seing the content was a pain in the ass.

* Depending on your application and architecture, you may be able to deliver even better performance by caching rendered templates than by offloading it to the browser. For example, I believe Reddit pretty much prerenders and caches every single page on the site, which is why most stuff loads instantly, but at peak times it takes a while to load the message inbox, or the 80th page of posts. This might be made even worse by extra API calls and client side rendering.

[1] <http://en.wikipedia.org/wiki/Abstraction_inversion> [2]
<http://en.wikipedia.org/wiki/Leaky_abstraction>

~~~
dansingerman
A lot of that could be described as "lessons I have learned on recent
projects". I wish I had read (and grokked) this post 18 months ago.

~~~
anextio
Well, there's no One True Way for Software Engineering, and certainly this
service-based approach can and does work for many, many projects. Obviously it
wasn't a complete disaster in Twitter's case.

If I may, I'll employ another Anti-Pattern, Cargo Cult Programming[1]. This
means that a team sees some method or 'One True Way' and starts implementing
it without understanding why.

It's almost guaranteed to go wrong, and it tends to apply a lot to things that
are hip, like this architecture and things like NoSQL.

[1] <http://en.wikipedia.org/wiki/Cargo_cult_programming>

------
j45
Seeing as the web is more service oriented than object oriented..

Are we surprised to see a step towards SOA (presumably from OO that was also
at the service layer)?

For me Web / mobile apps that are architected from a primarily OO perspective
can turn out very differently (often with unique OO bottlenecks) than apps
architected from a service-first perspective, using OO to fulfill services.

------
kijin
There's still a shebang in the URL. If I enter a URL without a shebang, it
redirects to one that contains a shebang. Since the browser won't include the
fragment in the request, how does the server know which page to send back
without using JavaScript to make another request? So it's not really "server
side", not even the initial page load.

~~~
ryannielsen
If you read Twitter's actual announcement
([http://engineering.twitter.com/2012/05/improving-
performance...](http://engineering.twitter.com/2012/05/improving-performance-
on-twittercom.html)), they've only rolled out the described changes to the
tweet permalink page. Other pages will see these changes over the coming
weeks.

------
halayli
I feel they were doing it wrong. If they preloaded the page with bootstrapped
data + templates then it should be as fast.

------
chintan
2011-02-11: "We've made a tradeoff, however, in making twitter.com into an
application using the hash, which is that it now cannot be both an app and a
site at the same time."

[http://www.adequatelygood.com/2011/2/Thoughts-on-the-
Hashban...](http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashbang)

------
kamweti
I welcome this but sticking with the fastest twitter client yet - their mobile
site. i use it even on desktop plus they recently made improvements on it

<http://news.ycombinator.com/item?id=2977580>

------
grampajoe
The client-side approach would work great if they didn't try to cram in so
many features.

------
AdrianRossouw
from what i can tell, they are just rendering the initial page load on the
server now.

~~~
wahnfrieden
Not at all surprising then except that it shows they're confident enough in
their choice of clientside rendering to invest more deeply in it (by
optimizing the initial load now.) What a misleading title.

------
joshfraser
I'm glad to see this. While it was an interesting experiment for Twitter to
undergo, their front end performance really took a hit. I expect they'll see
their usage numbers on twitter.com start going up again as they fix things.

------
jemeshsu
Twitter is doing the best approach which is a mix of both client-side and
server-side. It is not an either or situation.

