Putting The Web Back In Web Applications

Slide 1

Slide 1 text

Putting the web back into web applications @danwrong Thursday, June 14, 12

Slide 2

Slide 2 text

“The web sucks”- Zed A. Shaw http://vimeo.com/43380467 Thursday, June 14, 12

Slide 3

Slide 3 text

• W3C has many failed specs • CAN I CENTER SOME SHIT?? • Media is complicated • JavaScript WTF?!? Thursday, June 14, 12

Slide 4

Slide 4 text

He’s partially right Thursday, June 14, 12

Slide 5

Slide 5 text

Thursday, June 14, 12

Slide 6

Slide 6 text

HTML 5 > Flash 5? Thursday, June 14, 12

Slide 7

Slide 7 text

...except we need to cope with more runtimes Thursday, June 14, 12

Slide 8

Slide 8 text

If you want to build apps then HTML5 is not the best tool for the job Thursday, June 14, 12

Slide 9

Slide 9 text

So why do we bother writing web apps? Thursday, June 14, 12

Slide 10

Slide 10 text

The web is... Thursday, June 14, 12

Slide 11

Slide 11 text

shareable Thursday, June 14, 12

Slide 12

Slide 12 text

indexable Thursday, June 14, 12

Slide 13

Slide 13 text

interlinked Thursday, June 14, 12

Slide 14

Slide 14 text

accessible Thursday, June 14, 12

Slide 15

Slide 15 text

The web is amazing Thursday, June 14, 12

Slide 16

Slide 16 text

Web applications are a series of trade-offs Shit Crap Thursday, June 14, 12

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

“Everything that can be done on the client is done on the client” - Lea Verou Thursday, June 14, 12

Slide 19

Slide 19 text

http://www.youtube.com/watch?v=0T57Ivn5-Pw Thursday, June 14, 12

Slide 20

Slide 20 text

• Infinite scalability • Lower costs • More responsive Thursday, June 14, 12

Slide 21

Slide 21 text

She made all the right trade-offs Thursday, June 14, 12

Slide 22

Slide 22 text

I work at Thursday, June 14, 12

Slide 23

Slide 23 text

We’ve been rebuilding .com’s front end Thursday, June 14, 12

Slide 24

Slide 24 text

http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html Thursday, June 14, 12

Slide 25

Slide 25 text

• 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

Slide 26

Slide 26 text

Sound familiar? Thursday, June 14, 12

Slide 27

Slide 27 text

Why the hell did we move back to the server? Thursday, June 14, 12

Slide 28

Slide 28 text

“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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Performance, stability and maintainability Thursday, June 14, 12

Slide 31

Slide 31 text

But what does “fast” even mean? Thursday, June 14, 12

Slide 32

Slide 32 text

Performance is highly contextual Thursday, June 14, 12

Slide 33

Slide 33 text

We care about “Time To First Tweet” Thursday, June 14, 12

Slide 34

Slide 34 text

Time To First Tweet From navigation to the user seeing the timeline Thursday, June 14, 12

Slide 35

Slide 35 text

We measure this (with the Navigation Timing API) Thursday, June 14, 12

Slide 36

Slide 36 text

• 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

Slide 37

Slide 37 text

1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the client Thursday, June 14, 12

Slide 38

Slide 38 text

1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the client Thursday, June 14, 12

Slide 39

Slide 39 text

1. Get initial page 2.Get CSS 3.Get JavaScript 4.Get data 5. Render template Rendering on the server Thursday, June 14, 12

Slide 40

Slide 40 text

What else do we get? Thursday, June 14, 12

Slide 41

Slide 41 text

We get the power of the web for free Thursday, June 14, 12

Slide 42

Slide 42 text

Search indexable without extra code Thursday, June 14, 12

Slide 43

Slide 43 text

Browser history without extra code Thursday, June 14, 12

Slide 44

Slide 44 text

URL routing without extra code Thursday, June 14, 12

Slide 45

Slide 45 text

Shareable links without extra code Thursday, June 14, 12

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

• 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

Slide 48

Slide 48 text

• 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

Slide 49

Slide 49 text

Did we win? Thursday, June 14, 12

Slide 50

Slide 50 text

Chrome, San Francisco Before After Thursday, June 14, 12

Slide 51

Slide 51 text

Chrome, San Francisco Before After Thursday, June 14, 12

Slide 52

Slide 52 text

IE 8, San Francisco Before After Thursday, June 14, 12

Slide 53

Slide 53 text

Cut the 95th percentile in SF by 75% Thursday, June 14, 12

Slide 54

Slide 54 text

This is just one of the trade-offs we made Thursday, June 14, 12

Slide 55

Slide 55 text

Make your own trade-offs Thursday, June 14, 12

Slide 56

Slide 56 text

Client-side is not the future Thursday, June 14, 12

Slide 57

Slide 57 text

Server-side is not the future Thursday, June 14, 12

Slide 58

Slide 58 text

Making appropriate use of all the tools you have is the future Thursday, June 14, 12

Slide 59

Slide 59 text

• HTTP Caching • History API • In Memory Caching • Streaming response bodies • Concurrent data fetches • Lazy loading • and so much more... Thursday, June 14, 12