51–60 of 82 posts
Even though Twitter has decided it's either "pushstate or bust" what sort of fallback for pushstate exists for those of us who care about all our users, not just the ones with good browsers?
Earlier quoted context omitted.
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…
This is what they do.
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.
I thought this was about twitter moving away from hashtags. For some reason I got a bit excited, may be because I find vast majority of hashtags to be annoying noise. That said, I know they serve a purpose in specific use cases and donno a better alternative.
Us nerds, we won't care one way or the other anyway.
Even though Twitter has decided it's either "pushstate or bust" what sort of fallback for pushstate exists for those of us who care about all our users, not just the ones with good browsers?
The fallback is a normal web request and page refresh. This seems far more caring for all of their users than the high load that the hash-bang design placed on client computers.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
That would make sense to me. I always thought it was odd that you weren't allowed to attach a link as metadata, causing the rise of all the various URL shorteners.
The tweet still needs to fit into 140 characters, including any metadata you want visible to the recipient. Think SMS. Hence, might as well make it a user-manageable item in the tweet itself.
Earlier quoted context omitted.
~6 months ago IIRC they constantly had problems with their redesign and the last update involved removing the hashbangs
This sounds about right, if not a little earlier. Experimental work for this was done by me here: https://github.com/ianvanness/html5history I believe there were further tweaks for additional pages that needed to be supported (whereas I had only solved, and most likely not very elegantly, the rudimentary issue) that took additional time before the hash bang removal was actually launched.
I check the site every couple of weeks because I was interested in how the redesign would work out. It seems they eventually got it right, I like it. A lot of the other blogs have home and article pages that are just too heavy and slow.
Earlier quoted context omitted.
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.
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.
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
This is a good move by Twitter. I wholeheartedly endorse it.