front end abstractions at facebook
TRANSCRIPT
Front-end Abstractions
Tom OcchinoJune !"#"
! Intro
" Resources
# Interaction
$ Rendering
% Conclusion
Agenda
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
ResourcesHaste
▪ What is it?
▪ package and dependency management for CSS & JS
ResourcesHaste
▪ How does it work?
▪ declarative file annotation
▪ @provides single unique identifier
▪ @requires multiple resources
▪ other features
▪ integration
▪ require_static function
▪ analyze_resources script
ResourcesHaste
▪ Why did we build it?
▪ agility
▪ simplicity
▪ performance
▪ intelligently constructed packages
▪ crazy ass algorithms
▪ no, seriously
ResourcesBootloader
▪ What is it?
▪ on demand loading and unloading of static resources
▪ includes all required resources
ResourcesBootloader
▪ How does it work?
▪ loads resources through dynamic script injection
▪ executes callback after all resources are loaded
▪ built to work with Haste
▪ @suggest▪ bootloadEnable
ResourcesBootloader
▪ Why did we build it?
▪ performance
▪ reduce waste
ResourcesPrimer
▪ What is it?
▪ That’s the whole file >
ResourcesPrimer
▪ 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
ResourcesPrimer
we had about #MB of JS on the homepage
ResourcesPrimer
wtf!?
ResourcesPrimer
▪ 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
ResourcesPrimer
▪ 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
InteractionWorldwide TTI
"
#,"""
!,"""
),"""
*,"""
(,"""
p%" p+( p(" p!(
('%&(!
!,$()
",##*
'"$
!,"*#
!,&'(
#,"!*
'$%
!,#$!
",##$
$,(&#
Normal Quicklng PageCache
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