4 ms·

This is a very old post and I thought we were past this. It guess it may seem relevant due to the recent change in Twitter's client side architecture (Dan works

by camwest 14y ago

This is a very old post and I thought we were past this. It guess it may seem relevant due to the recent change in Twitter's client side architecture (Dan works there). As far as I know Dan is implementing real urls without hash bangs but will use pushState on supported browsers. The end result will basically be the same but with an optimized initial page load since the whole URL is delivered to the server.

swah 14y ago
Sorry I didn't realized this was 2011, someone referred to it on G+ and I posted as new...
timhaines 14y ago
I think the post is relavant (today) considering Dan (the author) was instrumental in removing the hashbangs. Twitter's Engineering Blog Post from today: http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html http://engineering.twitter.com/2012/05/improving-performance...
- mattmanser 14y ago
  Weird thing they seem to have completely misidentified the reason why their architecture was slow: The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our user’s machines rather than our own. From a brief look I had at it a few months ago they were sending a 1.5Mb javascript file which contained a template for every single action you could ever perform on twitter. Because it was squished I assume it got invalidated a lot as they made any tweak to their UI. That seemed to be the greater problem rather than these mysterious execution times. Seriously, who has ever had a performance problem transforming a bit of JSON with something like jQuery.tmpl or mustache? They ultimately seem to have thrown the baby out with the bath water. Then again we had this discussion about client v server rendering when 37signals posted their new architecture, I understand there are advantage of doing the template transforms serverside.
  - simonw 14y ago
    "Seriously, who has ever had a performance problem transforming a bit of JSON with something like jQuery.tmpl or mustache?" Mobile devices. Just parsing and executing a big chunk of JavaScript (like the jQuery library itself) can take the best part of a second on many mobile phones.
  - acdha 14y ago
    Searching through ShowSlow.com provides more visibility: http://www.showslow.com/details/92778/http://twitter.com/#!/yellowblog http://www.showslow.com/details/92778/http://twitter.com/#!/... That's 1,887 ms to render anything and almost a full second of JavaScript execution time. Waterfall graphs show a similar story: they pushed everything past the document load event so the monitoring tools are a bit off: http://www.webpagetest.org/result/120414_9W_3Z15P/ http://www.webpagetest.org/result/120414_9W_3Z15P/ shows an acceptable 1.4 second start of render, which isn't great but acceptable, but looking at the actual video shows that's merely how long it took to render a tiny part of the page - displaying the content which the user actually wanted about took over 8 seconds! http://www.webpagetest.org/video/view.php?id=120414_2a4075f2852e67c72bfc9ffa1733406476e11845 http://www.webpagetest.org/video/view.php?id=120414_2a4075f2...

by camwest 14y ago

swah 14y ago

Sorry I didn't realized this was 2011, someone referred to it on G+ and I posted as new...

timhaines 14y ago

I think the post is relavant (today) considering Dan (the author) was instrumental in removing the hashbangs. Twitter's Engineering Blog Post from today: http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html http://engineering.twitter.com/2012/05/improving-performance...

mattmanser 14y ago
Weird thing they seem to have completely misidentified the reason why their architecture was slow: The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our user’s machines rather than our own. From a brief look I had at it a few months ago they were sending a 1.5Mb javascript file which contained a template for every single action you could ever perform on twitter. Because it was squished I assume it got invalidated a lot as they made any tweak to their UI. That seemed to be the greater problem rather than these mysterious execution times. Seriously, who has ever had a performance problem transforming a bit of JSON with something like jQuery.tmpl or mustache? They ultimately seem to have thrown the baby out with the bath water. Then again we had this discussion about client v server rendering when 37signals posted their new architecture, I understand there are advantage of doing the template transforms serverside.
- simonw 14y ago
  "Seriously, who has ever had a performance problem transforming a bit of JSON with something like jQuery.tmpl or mustache?" Mobile devices. Just parsing and executing a big chunk of JavaScript (like the jQuery library itself) can take the best part of a second on many mobile phones.
- acdha 14y ago
  Searching through ShowSlow.com provides more visibility: http://www.showslow.com/details/92778/http://twitter.com/#!/yellowblog http://www.showslow.com/details/92778/http://twitter.com/#!/... That's 1,887 ms to render anything and almost a full second of JavaScript execution time. Waterfall graphs show a similar story: they pushed everything past the document load event so the monitoring tools are a bit off: http://www.webpagetest.org/result/120414_9W_3Z15P/ http://www.webpagetest.org/result/120414_9W_3Z15P/ shows an acceptable 1.4 second start of render, which isn't great but acceptable, but looking at the actual video shows that's merely how long it took to render a tiny part of the page - displaying the content which the user actually wanted about took over 8 seconds! http://www.webpagetest.org/video/view.php?id=120414_2a4075f2852e67c72bfc9ffa1733406476e11845 http://www.webpagetest.org/video/view.php?id=120414_2a4075f2...