Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Client_Side_Rendering_Is_Not_So_Easy.pdf
nuria_ruiz
July 08, 2012
Technology
3
650
Client_Side_Rendering_Is_Not_So_Easy.pdf
nuria_ruiz
July 08, 2012
Tweet
Share
More Decks by nuria_ruiz
See All by nuria_ruiz
Wikipedia's Lean Data Diet and Lessons Learned
nuria_ruiz
0
54
Wikipedia and The Lean Data Diet
nuria_ruiz
1
39
Other Decks in Technology
See All in Technology
eBPF for Security Observability
lizrice
0
220
Custom AppをIP制限ありのままで審査に通す方法
yusuga
0
690
OPENLOGI Company Profile
hr01
0
610
データ分析基盤のはじめかた
chanyou0311
0
120
【Pythonデータ分析勉強会#33】「DearPyGuiに入門しました」の続き~Image-Processing-Node-Editor~
kazuhitotakahashi
0
170
俺の Laravel がこんなに速いわけがない! / My Laravel Too Fast
hanhan1978
0
100
セキュリティ 開運研修2022 / security 2022
cybozuinsideout
PRO
3
3.9k
Autonomous Database Cloud 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
10
18k
Rethinking how distributed applications are built
tillrohrmann
0
110
【SAP知らない人向け】SAP on AWS 個人学習メモ/sap-on-aws-study
emiki
3
2.3k
Implementing Kubernetes operators in Java with Micronaut - TechWeek Java Summit 2022
alvarosanchez
0
120
Design for Humans: How to make better modernization decisions
indualagarsamy
2
130
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
253
12k
Teambox: Starting and Learning
jrom
123
7.7k
Making the Leap to Tech Lead
cromwellryan
113
7.4k
GraphQLの誤解/rethinking-graphql
sonatard
28
6.6k
Building Adaptive Systems
keathley
25
1.1k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
10
3.4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
226
15k
Producing Creativity
orderedlist
PRO
334
37k
Practical Orchestrator
shlominoach
178
8.6k
Embracing the Ebb and Flow
colly
73
3.4k
We Have a Design System, Now What?
morganepeng
35
3k
StorybookのUI Testing Handbookを読んだ
zakiyama
5
2.3k
Transcript
from 2010 to now... Client Side Rendering is Not So
Easy
Nuria Ruiz @pantojacoder
What is client side rendering? A fine idea...
None
<div class="entry"> <h1>{{title}}</h1> <div class="body"> {{{value}}} </div> </div> { "title":
"Pretty title", "value": 10000, }
To move rendering to the client you need two things:
1. Template Engine 2. Templates Loads of Javascript in the client.
None
Couple of things about About 1 billion page requests every
day. 10% on IE7, 0.5% on IE6.
We have a loading bar.
We have a thick Javascript client.
We offer several languages: Spanish, English, Catalan...
Back to loads of Javascript in the client... Remember that
loading bar? 500 K compressed, 23 requests ~ 3300 K of Javascript !!!!
Performance Problem #1 Eager loading of Javascript. Async !=Lazy
<div class="footer"> <div> <a class="hide" href="%sectionLink%"> <fw:translate id="Video.video_view_more_link"> %(video_view_more_link)View more...
</fw:translate> </a> </div> Performance Problem #2 and #3 Templates were plain HTML documents.
We needed to do ajax to retrieve templates, which are
HTML docs (cannot use <script>). AND Loads of walking the DOM to insert data.
None
Faster on IE7 than Chrome. We tried a "new" templating
technology to solve the DOM issue.
XSLT
XSLT was faster but had many problems. Browser Implementation is
1.0. It does not support dynamic subtemplating. Adding translations was a major pain.
STEP BACK
With as much Javascript we had in the client nothing
is going to go fast. Fact #1 We need to load Javascript lazily.
None
How does the YUI lazy loading work?
None
<a href="#m=Albums&f=index" onclick="Bootloader('t-albums- showcase','Request.click','?m=Albums&f=index');return false;" title="My photo albums">…</a> Each link
does an HTTP request to retrieve the Javascript needed. YUI().use('t-albums')
None
We can remove the loading bar.
Fact #2 We need to start from scratch on the
template engine.
None
works using a Lexical Parser. Based on Jison, a Javascript
parser generator.
<div class="entry"> <h1>{{title}}</h1> <div class="body"> {{{body}}} </div> </div> Template: Compilation:
$ npm install handlebars $ /usr/bin/handlebars sample_template.js Builds a grammar based on HTML that compiles to Javascript.
(function() { var template = Handlebars. template['sample_template.js'] =function (Handlebars,depth0,helpers,partials,data) {
helpers = helpers || Handlebars.helpers; var self = this; buffer += "<div class=\"entry\">\n <h1>"; ..... } buffer += escapeExpression(stack1) + "</h1>\n <div class=\"body\">\n ” .... buffer += escapeExpression(stack1) + "\n </div>\n </div>\n"; return buffer; }); })()
DOM manipulation.
Why Handlebars? If/else constructors. Handlebars is actively worked on. Compilation
available.
How do we download templates? With YUI, just like anything
else, templates now are Javascript. <a href="#m=Albums&f=index" onclick="Bootloader('t-photo','Request.click', '?m=Albums&f=index); return false;" title="My photo albums">…</a>
YUI walks the dependency tree.
None
Translations client side. {{{translate "Photos" "%(photo_save_title) Save"}}} We hope to
open source our I18N for Handlebars.
Do we use Client Side Rendering for everything? No. 1.
Features that exist only client side, like overlays, autocomplete, spinners, chat UI. 2. Features for which there are significant CPU savings to be done, e.g. high traffic pages like photos.
What's next? Server Side.
Last Thoughts.
Do not think about problems in isolation.
Use the right tool for the job.
Measure Everything.
5 times faster
Questions?