Comment by simonw | Hacker News Reader

Comment by simonw | Hacker News Reader

Parent Full thread

This is fantastic news.

From the recent tweets by https://twitter.com/danwrong it looks like Twitter are moving entirely to HTML5 pushState, and leaving IE users with full page refreshes rather than continuing to serve them #! - Dan says "I'm not sure why everyone is so adverse to page refreshes these days. You can make them fast too."

Of course, Twitter are going to have to include a piece of JavaScript on the http://twitter.com/ homepage which checks for a #! and redirects the user to the corresponding page - and they'll have to keep that JavaScript there forever, since they have nearly two years worth of links that they need to avoid breaking. One of the many reasons #! is such a nasty hack.

In terms of performance, this is going to make Twitter a lot /faster/ for me - I often open Twitter profile pages in new windows (due to working on Lanyrd) and each new window has to pull in and execute a HUGE chunk of JavaScript before it will display the page. Being able to just load a regular HTML page will be much faster for me.

It doesn't sound like they're switching to rendering on the backend, though. So you're most likely still going to have to execute a huge chunk of javascript before displaying the page, though hopefully it will get faster.

I'm hoping that they plan to serve up the HTML and CSS for the basic page as quickly as possible, then load the JS that adds the pushState / interactive stuff asynchronously.

A page with a single tweet on really shouldn't need to pull down much code. The JS can all be cached by the browser (far future expires headers etc) and there are some neat tricks you can do with app cache and localStorage to make that work even better.

IIRC, Twitter brought in Steve Souders as a consultant for improving the performance of the Twitter web interface and the main recommendation he offered was to have the tweet content in the HTML page instead of loading them dynamically.

Indeed, one always hopes they do the right thing :P

This is what they do.

Nope.

At the moment if you go to https://twitter.com/#!/twitter then it loads up the HTML for https://twitter.com/, if you're logged in it will be the tweets of those you follow. Then the javascript magic loads in @twitter's profile dynamically.

PushState will allow twitter to load in the static HTML for @twitter's profile at https://twitter.com/twitter/ and then progressively enhance it with javascript. The net gain will be that the page will be available much faster on initial page load.

Well, you're right and you're wrong. I'll be specific, since you are:

Twitter is sending down the home timeline as HTML. In fact, what most people are looking for when they go to twitter.com is their home timeline so I'm correct, this is what they are doing (at least in new-new-twitter which I think almost everyone now has). You're also correct, when you go to twitter.com/#!/n8agrin you get your timeline in the background which is then replaced with my tweets. However it wasn't always this way. At one point in time, going to twitter.com just downloaded a bunch of javascript and an HTML bootstrap. The whole site was generated by javascript. I know this because I worked on it.

Technically pushState doesn't really have anything to do with the practice of progressive enhancement or making anything "much faster". You can make pure javascript sites very fast, you can make serving straight up HTML very fast, you can progressively enhance HTML without pushState. pushState is really just a way to manipulate the history of a browser, while optionally changing the browser's current url, without a page refresh (read more here: https://developer.mozilla.org/en/DOM/Manipulating_the_browse...). You can use it to do a lot of things, one of which is to have it serve as one part of a solution for sites that behave like single-page apps without having to resort to the fragment identifier (http://en.wikipedia.org/wiki/Fragment_identifier), forever vilified as the hashbang.

IME I get my timeline flashing up in the foreground (not background!) before the actual content I want appears. Wastes a second or two.

Woop, sorry I downvoted you.

this will certainly happen, at least in the places it will be most useful.

Dan doesn't say anything about where the rendering will happen.

Most sites these day (including Facebook, Gmail, etc) have to execute "a huge chuck of js" before displaying the page.

I have been told by some people in the know that they have come up with a system similar to pjax for certain page components, though that may have changed.

True for Gmail, though Google+ renders most of the initial page view in static HTML/CSS, then progressively enhances subsequent pages using JS and a variety of techniques, including embedded frames and pushState. There's a lot that goes into making G+ so fast, and pre-rendering a big is part of it.

By way of comparison, view the following two links in a javascript-less browser (or just view source):

  $ w3m http://twitter.com/#!/danwrong/status/171680703824662528

  $ w3m https://plus.google.com/117377434815709898403/posts/f35f8QvHab7

The first link contains nothing but boilerplate and the JS that lazily loads the real content, whereas the second contains the actual content ready for the client to render immediately (and index, if you're a crawler).

This is a good move by Twitter. I wholeheartedly endorse it.

Wouldn't they have to, to support browsers without pushState? And even if they used terrible JavaScript hackery to get around that (serve same content for every URL, have clients AJAX in content based on location.href) how would they support web crawlers? I thought the whole point of the hashbang was that you would get the original content (or an equivalent representation) by removing it from the URL, so I'd think they still support backend rendering at some level.

They could use the exact same setup they have right now.

They'd just serve the exact same (static) html for every twitter.com/username URL. I don't think it's exactly terrible Javascript hackery to look at the location.href and do an ajax call.

They'd probably support web crawlers with the same system they use now. And many web crawlers these days execute javascript anyway.

The system they have now is the #! hack, the crawlers know how to request static versions of the pages. There isn't a similar mechanism for pushState based designs, you just serve up the content pre-rendered for the initial page. So that's probably what they will do to stay indexable. It will also make the first page load snappier (probably)

Dan says he is on the job.

https://twitter.com/#!/danwrong/status/171730032807518210

can't they just do a one-line .htaccess regex replace? or is it more complicated than that?

Nope, because anything after the # isn't included in the HTTP GET request made to the server - so a .htaccess-level redirection won't see it. You have to execute actual JavaScript on the client to read and redirect the #! bit.

That is the fundamental problem with hashbangs: the server receives "GET / HTTP/1.1" and the client uses javascript to render the hashbang. The server has no idea a hashbang is present until after it sends javascript to run client-side.

The redirection has to be done on the client-side, because the server never receives the fragment identifier as part of the URL.

To be honest, I'd prefer maintaining a single JS redirect on the main page, rather than many server-side regular expressions trying to redirect to appropriate pages.

Reply on news.ycombinator.com