Putting The Web Back In Web Applications

As delivered at TXJS 2012

Transcript

1. Putting the web back into web applications @danwrong Thursday, June 14, 12
2. “The web sucks”- Zed A. Shaw http://vimeo.com/43380467 Thursday, June 14, 12
3. • W3C has many failed specs • CAN I CENTER SOME SHIT?? • Media is complicated • JavaScript WTF?!? Thursday, June 14, 12
4. He’s partially right Thursday, June 14, 12
5. Thursday, June 14, 12
6. HTML 5 > Flash 5? Thursday, June 14, 12
7. ...except we need to cope with more runtimes Thursday, June 14, 12
8. If you want to build apps then HTML5 is not the best tool for the job Thursday, June 14, 12
9. So why do we bother writing web apps? Thursday, June 14, 12
10. The web is... Thursday, June 14, 12
11. shareable Thursday, June 14, 12
12. indexable Thursday, June 14, 12
13. interlinked Thursday, June 14, 12
14. accessible Thursday, June 14, 12
15. The web is amazing Thursday, June 14, 12
16. Web applications are a series of trade-offs Shit Crap Thursday, June 14, 12
17. Web applications are a series of trade-offs Shit Crap Passable We need to know the web and make trade-offs Thursday, June 14, 12
18. “Everything that can be done on the client is done on the client” - Lea Verou Thursday, June 14, 12
19. http://www.youtube.com/watch?v=0T57Ivn5-Pw Thursday, June 14, 12
20. • Infinite scalability • Lower costs • More responsive Thursday, June 14, 12
21. She made all the right trade-offs Thursday, June 14, 12
22. I work at Thursday, June 14, 12
23. We’ve been rebuilding .com’s front end Thursday, June 14, 12
24. http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html Thursday, June 14, 12
25. • Removed JavaScript (Hashbang) routing • Render all content on the server • Endpoints deliver rendered HTML • Defer loading of JavaScript What we’ve done Thursday, June 14, 12
26. Sound familiar? Thursday, June 14, 12
27. Why the hell did we move back to the server? Thursday, June 14, 12
28. “I'm not happy with the new path of twitter, is a retro-revolution managed by an anti-SPI engineer” “Next, twitter will optimise by rendering HTML from PostgreSQL prepared statements.” “Client-side apps, templating engines and CPUs get faster. The only way to reduce latency to the server is to increase the speed of light.” Why can't u make it so the tweets can be longer? “Sanity prevails! @Twitter are ditching the "#!" and reducing JavaScript! #win #DoingItRight” Thursday, June 14, 12
29. “I'm not happy with the new path of twitter, is a retro-revolution managed by an anti-SPI engineer” “Next, twitter will optimise by rendering HTML from PostgreSQL prepared statements.” “Client-side apps, templating engines and CPUs get faster. The only way to reduce latency to the server is to increase the speed of light.” Why can't u make it so the tweets can be longer? “Sanity prevails! @Twitter are ditching the "#!" and reducing JavaScript! #win #DoingItRight” Thursday, June 14, 12
30. Performance, stability and maintainability Thursday, June 14, 12
31. But what does “fast” even mean? Thursday, June 14, 12
32. Performance is highly contextual Thursday, June 14, 12
33. We care about “Time To First Tweet” Thursday, June 14, 12
34. Time To First Tweet From navigation to the user seeing the timeline Thursday, June 14, 12
35. We measure this (with the Navigation Timing API) Thursday, June 14, 12
36. • Could be improved across the board • Giant outliers from old machines and browsers • Big differences between countries Time To First Tweet needed work Thursday, June 14, 12
37. 1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the client Thursday, June 14, 12
38. 1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the client Thursday, June 14, 12
39. 1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the server Thursday, June 14, 12
40. What else do we get? Thursday, June 14, 12
41. We get the power of the web for free Thursday, June 14, 12
42. Search indexable without extra code Thursday, June 14, 12
43. Browser history without extra code Thursday, June 14, 12
44. URL routing without extra code Thursday, June 14, 12
45. Shareable links without extra code Thursday, June 14, 12
46. 1. Less to send over the wire 2.Less variance across browsers/devices 3.Less tests to run across multiple browsers 4.Less hard to track down errors Less code running on the browser Thursday, June 14, 12
47. • Consume the REST API • Less hardware required • Less data over the wire • Faster navigation once app has loaded But if we render on the client-side... Thursday, June 14, 12
48. • Consume the REST API • Less hardware required • Less data over the wire • Faster navigation once app has loaded But if we render on the client-side PJAX and caching Thursday, June 14, 12
49. Did we win? Thursday, June 14, 12
50. Chrome, San Francisco Before After Thursday, June 14, 12
51. Chrome, San Francisco Before After Thursday, June 14, 12
52. IE 8, San Francisco Before After Thursday, June 14, 12
53. Cut the 95th percentile in SF by 75% Thursday, June 14, 12
54. This is just one of the trade-offs we made Thursday, June 14, 12
55. Make your own trade-offs Thursday, June 14, 12
56. Client-side is not the future Thursday, June 14, 12
57. Server-side is not the future Thursday, June 14, 12
58. Making appropriate use of all the tools you have is the future Thursday, June 14, 12
59. • HTTP Caching • History API • In Memory Caching • Streaming response bodies • Concurrent data fetches • Lazy loading • and so much more... Thursday, June 14, 12
60. One size fits all is overrated Thursday, June 14, 12
61. Questions? twitter.com/jobs @danwrong spkr8.com/t/11251 Thursday, June 14, 12