5 ms·

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 be

by mnutt 15y ago

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.

n8agrin 15y ago
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.
- dewitt 15y ago
  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.
pak 15y ago
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.
- mnutt 15y ago
  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.
  - almost 15y ago
    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)
simonw 15y ago
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.
- mvzink 15y ago
  Indeed, one always hopes they do the right thing :P
- n8agrin 15y ago
  This is what they do.
  - nfriedly 15y ago
    Woop, sorry I downvoted you.
  - davej 15y ago
    Nope. At the moment if you go to https://twitter.com/#!/twitter https://twitter.com/#!/twitter then it loads up the HTML for https://twitter.com/ 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/ 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.
    - deleted 15y ago
      [deleted]
    - n8agrin 15y ago
      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_browser_history 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 http://en.wikipedia.org/wiki/Fragment_identifier), forever vilified as the hashbang.
sjs 15y ago
Dan says he is on the job. https://twitter.com/#!/danwrong/status/171730032807518210 https://twitter.com/#!/danwrong/status/171730032807518210

by mnutt 15y ago

n8agrin 15y ago

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.

dewitt 15y ago
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.

pak 15y ago

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.

mnutt 15y ago
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.
- almost 15y ago
  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)

simonw 15y ago

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.

mvzink 15y ago
Indeed, one always hopes they do the right thing :P
n8agrin 15y ago
This is what they do.
- nfriedly 15y ago
  Woop, sorry I downvoted you.
- davej 15y ago
  Nope. At the moment if you go to https://twitter.com/#!/twitter https://twitter.com/#!/twitter then it loads up the HTML for https://twitter.com/ 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/ 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.
  - deleted 15y ago
    [deleted]
  - n8agrin 15y ago
    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_browser_history 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 http://en.wikipedia.org/wiki/Fragment_identifier), forever vilified as the hashbang.

sjs 15y ago

Dan says he is on the job. https://twitter.com/#!/danwrong/status/171730032807518210 https://twitter.com/#!/danwrong/status/171730032807518210