SlideShare a Scribd company logo
1 of 42
Download to read offline
Front-end Abstractions


Tom Occhino
June
Agenda

   Intro

   Resources

   Interaction

   Rendering

   Conclusion
Intro and some info
Intro
Vocabulary
▪   amped   excited, psyched
▪   clowny comical, silly
▪   j0nx	   stuff, things
▪   lolzy   crazy, laugh inducing
Intro
Overview
▪        Front-end systems
▪   Server side (PHP) + Client side (JS) integration
▪   High level overview
    ▪   What is it?
    ▪   How does it work?
    ▪   Why did we build it?
Resource management
Resources

    Haste
    Bootloader
    Primer
Resources
Haste
▪   What is it?
    ▪   package and dependency management for CSS & JS
Resources
Haste
▪   How does it work?
    ▪   declarative file annotation
        ▪   @provides single unique identifier
        ▪   @requires multiple resources
        ▪   other features
    ▪   integration
        ▪   require_static function
        ▪   analyze_resources script
Resources
Haste
▪   Why did we build it?
    ▪   agility
    ▪   simplicity
    ▪   performance
        ▪   intelligently constructed packages
            ▪
                crazy ass algorithms
            ▪
                no, seriously
Resources
Bootloader
▪   What is it?
    ▪   on demand loading and unloading of static resources
        ▪   includes all required resources
Resources
Bootloader
▪   How does it work?
    ▪   loads resources through dynamic script injection
    ▪   executes callback after all resources are loaded
    ▪   built to work with Haste
        ▪   @suggest
        ▪   bootloadEnable
Resources
Bootloader
▪   Why did we build it?
    ▪   performance
    ▪   reduce waste
Resources
Primer
▪   What is it?
    ▪   That’s the whole file >
Resources
Primer
▪   What is it?
    ▪   most interactions are simple
        ▪   GET (click link)
        ▪   POST (submit form)
    ▪   aims to be the         /   solution
    ▪   delete tons of boilerplate JavaScript
        ▪   at one point about MB of JS on the homepage
Resources
Primer




         we had about   MB of JS on the homepage
Resources
Primer




            wtf!?
Resources
Primer
▪   How does it work?
    ▪   small JS file in the <head>
    ▪   global event listener
        ▪   looks for attributes like ajaxify
        ▪   bootload necessary components
        ▪   perform action when ready
Resources
Primer
▪   Why did we build it?
    ▪   move JS to bottom of the page (roadrunner)
    ▪   sick of doing the same crap over and over
    ▪   we had like, a meg of JS blocking rendering
Interaction systems
Interaction

    LinkController
    PageTransitions
    Quickling
    PageCache
Interaction
LinkController
▪   What is it?
    ▪   similar to Primer listens for click events
▪   How does it work?
    ▪   global mousedown / keydown event
    ▪   filter out certain clicks
    ▪   invoke ‘handlers’ for relevant clicks
Interaction
PageTransitions
▪   What is it?
    ▪   prevent a full page load if we can do something better
▪   How does it work?
    ▪   register handlers for your component
        ▪   uri is passed into the handler
        ▪   look for patterns and handle when possible
    ▪   kill the default event if handled
Interaction
Quickling
▪   What is it?
    ▪   a special ‘default’ PageTransition
Interaction
Quickling
▪   How does it work?
    ▪   fallback PageTransition handler
    ▪   simulate browser events Arbiter
    ▪   store history HistoryManager
    ▪   appear busy BusyUIManager (!?)
        ▪   iframe transport
        ▪   wait cursors
Interaction
Quickling
▪   Drawbacks
    ▪   css rules over time
    ▪   memory consumption
    ▪   complexity
▪   Current Status
    ▪   IE, FF, Chrome (>     )
    ▪   ~     of page loads are through Quickling
    ▪   up to ~      reduction in render time
Interaction
PageCache
▪   What is it?
    ▪   local cache for visited pages
Interaction
PageCache
▪   How does it work?
    ▪   black magic
    ▪   built on top of Quickling
    ▪   cache server responses
        ▪   pull from cache when there’s a match
        ▪   replay all new actions
Interaction
PageCache
▪   Drawbacks
    ▪   complexity
▪   Current Status
    ▪   enabled for homepage
    ▪   ~    savings on page hits to home
    ▪   up to - x speedup over Quickling alone
Interaction
All Systems
▪   Why did we build them?
    ▪   performance
        ▪   full page loads are more expensive than partial
    ▪   better user experience
        ▪   especially for things like chat
Interaction                                                          Normal   Quicklng   PageCache
Worldwide TTI
,
                  ,
,


,                              ,


                                             ,   ,
,
                                                     ,

                                                         ,   ,
,                                                                ,




                               p                     p           p                  p

    Footnote: Facebook Internal Data, June
Rendering abstractions
Rendering

    Pagelets
    Early Flush
    BigPipe
Rendering
Pagelets
▪   What are they?
    ▪   technique for structuring pages
▪   How do they work?
    ▪   parallel generation
    ▪   can be refreshed independently
▪   Why did we build it?
    ▪   flexibility
    ▪   good design
Rendering
Early Flush
▪   What is it?
    ▪   flush the html response in two parts
▪   How does it work?
    ▪   send the <head> to the browser asap
        ▪   browser starts downloading resources
        ▪   server is still generating the page
▪   Why did we build it?
    ▪   overlap gen+render time
Rendering
BigPipe
Rendering
BigPipe
▪   What is it?
    ▪   progressive rendering of pages
▪   How does it work?
    ▪   send down page skeleton
    ▪   page content in scripts as completed
▪   Why did we build it
    ▪   LittlePipe was too slow
    ▪   performance ( . -> . )
Summary and thoughts
http://www.facebook.com/Engineering

  http://www.facebook.com/careers

More Related Content

Viewers also liked

Real Time Web with Node
Real Time Web with NodeReal Time Web with Node
Real Time Web with Node
Tim Caswell
 
Souders WPO Web 2.0 Expo
Souders WPO Web 2.0 ExpoSouders WPO Web 2.0 Expo
Souders WPO Web 2.0 Expo
Steve Souders
 
Solving Problems with YUI3: AutoComplete
Solving Problems with YUI3: AutoCompleteSolving Problems with YUI3: AutoComplete
Solving Problems with YUI3: AutoComplete
IsaacSchlueter
 
Os Peytonjones
Os PeytonjonesOs Peytonjones
Os Peytonjones
oscon2007
 

Viewers also liked (17)

Performance beyond page load (jQuery Conference)
Performance beyond page load (jQuery Conference)Performance beyond page load (jQuery Conference)
Performance beyond page load (jQuery Conference)
 
Real Time Web with Node
Real Time Web with NodeReal Time Web with Node
Real Time Web with Node
 
Introduction of AMD Virtual Interrupt Controller
Introduction of AMD Virtual Interrupt ControllerIntroduction of AMD Virtual Interrupt Controller
Introduction of AMD Virtual Interrupt Controller
 
Using YQL Sensibly - YUIConf 2010
Using YQL Sensibly - YUIConf 2010Using YQL Sensibly - YUIConf 2010
Using YQL Sensibly - YUIConf 2010
 
The next step, part 2
The next step, part 2The next step, part 2
The next step, part 2
 
Souders WPO Web 2.0 Expo
Souders WPO Web 2.0 ExpoSouders WPO Web 2.0 Expo
Souders WPO Web 2.0 Expo
 
YQL and YUI - Bausteine fuers web
YQL and YUI - Bausteine fuers webYQL and YUI - Bausteine fuers web
YQL and YUI - Bausteine fuers web
 
Solving Problems with YUI3: AutoComplete
Solving Problems with YUI3: AutoCompleteSolving Problems with YUI3: AutoComplete
Solving Problems with YUI3: AutoComplete
 
Velocity NY - How to Measure Revenue in Milliseconds
Velocity NY - How to Measure Revenue in MillisecondsVelocity NY - How to Measure Revenue in Milliseconds
Velocity NY - How to Measure Revenue in Milliseconds
 
USENIX LISA15: How TubeMogul Handles over One Trillion HTTP Requests a Month
USENIX LISA15: How TubeMogul Handles over One Trillion HTTP Requests a MonthUSENIX LISA15: How TubeMogul Handles over One Trillion HTTP Requests a Month
USENIX LISA15: How TubeMogul Handles over One Trillion HTTP Requests a Month
 
virtualization tutorial at ACM bangalore Compute 2009
virtualization tutorial at ACM bangalore Compute 2009virtualization tutorial at ACM bangalore Compute 2009
virtualization tutorial at ACM bangalore Compute 2009
 
Examples of D3 Visualizations
Examples of D3 VisualizationsExamples of D3 Visualizations
Examples of D3 Visualizations
 
Os Peytonjones
Os PeytonjonesOs Peytonjones
Os Peytonjones
 
Breaking The Cross Domain Barrier
Breaking The Cross Domain BarrierBreaking The Cross Domain Barrier
Breaking The Cross Domain Barrier
 
Test Driving a jQuery Plugin
Test Driving a jQuery PluginTest Driving a jQuery Plugin
Test Driving a jQuery Plugin
 
Build HTML5 Sites/Apps with Kendo UI Core
Build HTML5 Sites/Apps with Kendo UI CoreBuild HTML5 Sites/Apps with Kendo UI Core
Build HTML5 Sites/Apps with Kendo UI Core
 
Beyond DOM Manipulations: Building Stateful Modules with Events and Promises
Beyond DOM Manipulations: Building Stateful Modules with Events and PromisesBeyond DOM Manipulations: Building Stateful Modules with Events and Promises
Beyond DOM Manipulations: Building Stateful Modules with Events and Promises
 

Front End Abstractions at Facebook

  • 1.
  • 3. Agenda Intro Resources Interaction Rendering Conclusion
  • 5. Intro Vocabulary ▪ amped excited, psyched ▪ clowny comical, silly ▪ j0nx stuff, things ▪ lolzy crazy, laugh inducing
  • 6. Intro Overview ▪ Front-end systems ▪ Server side (PHP) + Client side (JS) integration ▪ High level overview ▪ What is it? ▪ How does it work? ▪ Why did we build it?
  • 8. Resources Haste Bootloader Primer
  • 9. Resources Haste ▪ What is it? ▪ package and dependency management for CSS & JS
  • 10. Resources Haste ▪ How does it work? ▪ declarative file annotation ▪ @provides single unique identifier ▪ @requires multiple resources ▪ other features ▪ integration ▪ require_static function ▪ analyze_resources script
  • 11. Resources Haste ▪ Why did we build it? ▪ agility ▪ simplicity ▪ performance ▪ intelligently constructed packages ▪ crazy ass algorithms ▪ no, seriously
  • 12. Resources Bootloader ▪ What is it? ▪ on demand loading and unloading of static resources ▪ includes all required resources
  • 13. Resources Bootloader ▪ How does it work? ▪ loads resources through dynamic script injection ▪ executes callback after all resources are loaded ▪ built to work with Haste ▪ @suggest ▪ bootloadEnable
  • 14. Resources Bootloader ▪ Why did we build it? ▪ performance ▪ reduce waste
  • 15. Resources Primer ▪ What is it? ▪ That’s the whole file >
  • 16. Resources Primer ▪ What is it? ▪ most interactions are simple ▪ GET (click link) ▪ POST (submit form) ▪ aims to be the / solution ▪ delete tons of boilerplate JavaScript ▪ at one point about MB of JS on the homepage
  • 17. Resources Primer we had about MB of JS on the homepage
  • 19. Resources Primer ▪ How does it work? ▪ small JS file in the <head> ▪ global event listener ▪ looks for attributes like ajaxify ▪ bootload necessary components ▪ perform action when ready
  • 20. Resources Primer ▪ Why did we build it? ▪ move JS to bottom of the page (roadrunner) ▪ sick of doing the same crap over and over ▪ we had like, a meg of JS blocking rendering
  • 22. Interaction LinkController PageTransitions Quickling PageCache
  • 23. Interaction LinkController ▪ What is it? ▪ similar to Primer listens for click events ▪ How does it work? ▪ global mousedown / keydown event ▪ filter out certain clicks ▪ invoke ‘handlers’ for relevant clicks
  • 24. Interaction PageTransitions ▪ What is it? ▪ prevent a full page load if we can do something better ▪ How does it work? ▪ register handlers for your component ▪ uri is passed into the handler ▪ look for patterns and handle when possible ▪ kill the default event if handled
  • 25. Interaction Quickling ▪ What is it? ▪ a special ‘default’ PageTransition
  • 26.
  • 27. Interaction Quickling ▪ How does it work? ▪ fallback PageTransition handler ▪ simulate browser events Arbiter ▪ store history HistoryManager ▪ appear busy BusyUIManager (!?) ▪ iframe transport ▪ wait cursors
  • 28. Interaction Quickling ▪ Drawbacks ▪ css rules over time ▪ memory consumption ▪ complexity ▪ Current Status ▪ IE, FF, Chrome (> ) ▪ ~ of page loads are through Quickling ▪ up to ~ reduction in render time
  • 29. Interaction PageCache ▪ What is it? ▪ local cache for visited pages
  • 30. Interaction PageCache ▪ How does it work? ▪ black magic ▪ built on top of Quickling ▪ cache server responses ▪ pull from cache when there’s a match ▪ replay all new actions
  • 31. Interaction PageCache ▪ Drawbacks ▪ complexity ▪ Current Status ▪ enabled for homepage ▪ ~ savings on page hits to home ▪ up to - x speedup over Quickling alone
  • 32. Interaction All Systems ▪ Why did we build them? ▪ performance ▪ full page loads are more expensive than partial ▪ better user experience ▪ especially for things like chat
  • 33. Interaction Normal Quicklng PageCache Worldwide TTI , , , , , , , , , , , , , p p p p Footnote: Facebook Internal Data, June
  • 35. Rendering Pagelets Early Flush BigPipe
  • 36. Rendering Pagelets ▪ What are they? ▪ technique for structuring pages ▪ How do they work? ▪ parallel generation ▪ can be refreshed independently ▪ Why did we build it? ▪ flexibility ▪ good design
  • 37.
  • 38. Rendering Early Flush ▪ What is it? ▪ flush the html response in two parts ▪ How does it work? ▪ send the <head> to the browser asap ▪ browser starts downloading resources ▪ server is still generating the page ▪ Why did we build it? ▪ overlap gen+render time
  • 40. Rendering BigPipe ▪ What is it? ▪ progressive rendering of pages ▪ How does it work? ▪ send down page skeleton ▪ page content in scripts as completed ▪ Why did we build it ▪ LittlePipe was too slow ▪ performance ( . -> . )