• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Dust.js
 

Dust.js

on

  • 22,099 views

In 2011, LinkedIn adopted dust.js. This is the story of client side templating at massive scale.

In 2011, LinkedIn adopted dust.js. This is the story of client side templating at massive scale.

Statistics

Views

Total Views
22,099
Views on SlideShare
21,625
Embed Views
474

Actions

Likes
41
Downloads
162
Comments
0

10 Embeds 474

http://www.ybrikman.com 247
http://www.linkedin.com 64
http://ybrikman.com 61
https://twitter.com 33
https://dia.log.pt 32
http://localhost 20
https://www.linkedin.com 8
https://si0.twimg.com 5
https://www.livingtree.com 2
https://twimg0-a.akamaihd.net 2
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Dust.js Dust.js Presentation Transcript

    • { dust.js } at LinkedIn Yevgeniy Brikman
    • 2011: LinkedIn adopted dust.js, a client side templating language
    • This is the story of client sidetemplating at massive scale
    • Dust in the wild Profile 2.0
    • Dust in the wild People You May Know
    • Dust in the wild Influencers
    • About me Presentation Infrastructure Team (also Hackdays, [in]cubator, Engineering Blog, Open Source)
    • Outline1. A little LinkedIn history2. A new direction: client side rendering3. Picking a templating technology4. Take dust for a spin5. Challenges: SEO, i18n, logic6. The Future
    • Outline1. A little LinkedIn history2. A new direction: client side rendering3. Picking a templating technology4. Take dust for a spin5. Challenges: SEO, i18n, logic6. The Future
    • LinkedIn in 2003 A single, monolithic webapp: servlets/JSPs
    • LinkedIn in 2010 New web frameworks to boost productivity: Grails/GSPs, JRuby/ERBs, plus others
    • Fragmentation● Each tech stack used a different templating technology (JSP, GSP, ERB, etc)● No easy way to share UI code for common components (e.g. profile, the feed)● The "global" nav had to be rewritten in multiple languages/technologies. Updating it was very time consuming.
    • We needed to unify the view layer
    • Outline1. A little LinkedIn history2. A new direction: client side rendering3. Picking a templating technology4. Take dust for a spin5. Challenges: SEO, i18n, logic6. The Future
    • We began looking at client side templating solutions
    • Traditional server side rendering All page content is rendered as HTML and sent to the browser
    • Client side rendering (simplified) Server sends JSON. The template is fetched from the CDN and rendered in browser.
    • Client side rendering (full) Server sends JSON embedded in an HTML skeleton. The skeleton has JavaScript code that fetches and renders the template.
    • Client side MVC Client side MVC makes client side rendering even more important.
    • Client side rendering (with MVC) Once a page has loaded, the client side MVC takes over, fetching JSON from the server and rendering it with client side templates
    • Client side rendering benefits● DRY: works with any server side stack plus client side● Performance: bandwidth, latency, caching● Productivity: fast iteration, mock JSON● Rich apps: client side MVC
    • Outline1. A little LinkedIn history2. A new direction: client side rendering3. Picking a templating technology4. Take dust for a spin5. Challenges: SEO, i18n, logic6. The Future
    • Decisions, decisions We evaluated 26 different options. They tended to fall into one of two groups: Embedded JavaScript and Logic Less.
    • Embedded JavaScript Templates <ul> <% for(var i = 0; i < supplies.length; i ++) { %> <li><%= supplies[i] %> </li> <% } %> </ul> Normal JavaScript code directly in the template.
    • Embedded JavaScript Templates● underscore.js● Jade● haml-js● jQote2● doT● Stencil● Parrot● Eco● EJS● jQuery templates● node-asyncEJS
    • Logic-less Templates <p> Hello {name}! You have {count} new messages. </p> Custom template language that limits logic
    • Embedded JavaScript Templates● mustache● dust.js● handlebars● Google Closure Templates● Nun● Mu● kite
    • The test Render a simplified LinkedIn profile
    • The rules● Produce this HTML output● Use this profile JSON as input● The same template should render on the server-side and client-side● Properly handle profile data display rules● Format numbers and dates correctly
    • The criteria● DRY● i18n● Hot reload● Performance● Ramp-up time● Ramped-up productivity● Server/client support● Community● Library agnostic● Testable● Debuggable● Editor support● Maturity● Documentation● Code documentation
    • Criteria are just guidelines;not all are weighted equally.
    • The finalists
    • Google Closure TemplatesPros ● Templates are compiled into JavaScript for client-side and Java for server- side. ● Good built-in functionality: loops, conditionals, partials, i18n. ● Documentation is enforced by the template.Cons ● Very little usage outside of Google. No plans to push new versions or accept new contributions. ● Some functionality is missing, such as being able to loop over maps. ● Not DRY: adding new functionality requires implementing plugins in both Java and JavaScript.
    • MustachePros ● Very popular choice with a large, active community. ● Server side support in many languages, including Java. ● Logic-less templates do a great job of forcing you to separate presentation from logic. ● Clean syntax leads to templates that are easy to build, read, and maintain.Cons ● A little too logic-less: basic tasks (e.g. label alternate rows with different CSS classes) are difficult. ● View logic is often pushed back to the server or implemented as a "lambda" (callable function). ● For lambdas to work on client and server, you must write them in JavaScript. ● Slow, interpreted templates
    • HandlebarsPros ● Logic-less templates do a great job of forcing you to separate presentation from logic. ● Clean syntax leads to templates that are easy to build, read, and maintain. ● Compiled rather than interpreted templates. ● Better support for paths than mustache (ie, reaching deep into a context object). ● Better support for global helpers than mustache.Cons ● Requires server-side JavaScript to render on the server.
    • Dust.jsPros ● Logic-less templates do a great job of forcing you to separate presentation from logic. ● Clean syntax leads to templates that are easy to build, read, and maintain. ● Compiled rather than interpreted templates. ● Better support for paths than mustache (ie, reaching deep into a context object). ● Better support for global helpers than mustache. ● Inline parameters. ● Blocks & inline partials. ● Overriding contexts. ● Support for asynchronous rendering and streaming. ● Composable templates.Cons ● Requires server-side JavaScript to render on the server. ● Maintainer of github repo is not responsive.
    • Spoiler alert!
    • dust.js won
    • Takeaways● Based on how we weighed our criteria, Dust fit our needs the best● Use real use cases and identify the most important criteria to you● For non-trivial views, no templating option works on client and server, unless your server executes JavaScript (v8, Rhino)
    • Outline1. A little LinkedIn history2. A new direction: client side rendering3. Picking a templating technology4. Take dust for a spin5. Challenges: SEO, i18n, logic6. The Future
    • The LinkedIn Fork● The original maintainer abandoned dust● The LinkedIn fork is now the most active● Weve added bug fixes, perf improvements, and helpers
    • Try it out● Homepage: http://linkedin.github.com/dustjs/● Try it in the browser: http://linkedin.github. com/dustjs/test/test.html● Source code: https://github. com/linkedin/dustjs
    • (demo)
    • Outline1. A little LinkedIn history2. A new direction: client side rendering3. Picking a templating technology4. Take dust for a spin5. Challenges: SEO, i18n, logic6. The Future
    • How do you handle view logic?
    • Yes, there is such a thing as view logic and its separate from business logic
    • ComplicatedLogic logicLogic
    • Homework assignment: implement this view with a truly logic-less template (no helpers/lambdas!)
    • Helpers to the rescue: @eq, @ne {@eq key="foo" value="foo"}The key and value are equal!{/ eq} {@ne key="foo" value="bar"}The key and value are not equal!{/ ne}
    • Helpers to the rescue: @gt, @lt {@gt key="22" value="3"}22 is greater than 3{/ gt} {@lt key="0" value="500"}0 is less than 500{/ lt}
    • Helpers to the rescue: @select {@select key=age} {@eq value="1"}Baby{/eq} {@lt value="10"}Child{/lt} {@lt value="18"}Teen{/lt} {@default}Adult{/default} {/select}
    • Helpers to the rescue: @size, @math You have {@ size key=list/} new messages {@math key="16" method="add" operand="4"/}
    • Full library of helpers is available at:https://github.com/linkedin/dustjs-helpers
    • How do we handled clients without JavaScript? What about SEO?
    • SSR: Server Side Rendering● Google V8 engine● A plugin for Apache Traffic Server● Executes arbitrary JavaScript server side, including rendering dust templates● Often nicknamed Unified Server Side Rendering... aka, USSR
    • Client side rendering (full, SSR) The HTML Skeleton is written in dust. SSR renders it as HTML.
    • SSR uses● Render dust skeleton into HTML skeleton● Render everything server side for: ○ Crawlers/bots/search engines ○ Clients without JavaScript ○ Slow clients (IE < 8)● Logic less templates help ensure that everything renders correctly server-side. No DOM dependencies!
    • What about i18n? Formatting? URLs?
    • Server side templates <p> <a href="${url.link( home-page }">$!{i18n(hello-world )}</a> </p> In JSPs, Java libraries did i18n, text formatting, URL generation
    • Sending an entire i18n dictionary,URL dictionary, and all formattingcode to the browser is expensive
    • Option #1: everything server sideJava controller json.put("name", "Jim"); json.put("home-page-link" , Url.link("home-page" )); json.put("hello-world-text" , I18n.get("hello-world" )); render("profile-page" , json);profile-page dust template <p> <a href="{home-page-link} ">{hello-world-text} </a> </p> All i18n, text formatting, and URL generation is done server side and added to the JSON payload
    • Option #1: everything server sidePros● Simple, easy to understand● Clean templatesCons● Controller code cluttered with view logic
    • Option #2: dynamic pre-processingOriginal profile-page dust template <p> <a href="{@pre.link key="home-page"} ">{@pre.i18n key="hello-world"} </a> </p>Pre-processed profile-page dust template <p> <a href="{link-123}">{i18n-456}</a> </p> Step 1: the @pre helper tags get replaced at build time with references to unique keys in the JSON
    • Option #2: dynamic pre-processingJava controller json.put("name", "Jim"); render("profile-page" , json);Pre-processed JSON { "name": "Jim", "link-123" : "http://www.linkedin.com" , "i18n-456" : "Hello World" } Step 2: whenever profile-page is rendered, automatically "enhance" the JSON with the requested i18n and URL values
    • Option #2: dynamic pre-processingPros● All view logic is in the templates● Clean server side codeCons● Complicated, hard to debug● Tight coupling: need special server and build logic to use templates● Performance: increased JSON payload and/or more server processing time
    • Option #3: static pre-processingOriginal profile-page dust template <p> <a href="{home-page-link}">{@i18n}Hello World{/i18n}</a> </p>Pre-processed profile-page dust template (one per language) <p> <a href="{home-page-link}">Hello World</a> </p> <p> <a href="{home-page-link}">Bonjour monde</a> </p> Generate one template per language with translated text already filled in. Link generation and formatting still happen server-side.
    • Option #3: static pre-processingPros● Hybrid approach: i18n is in the templates, only formatting/link generation is in controller● Simpler, easier to debug than dynamic pre- processingCons● Custom build process● Increased template payload, but i18n strings now cached with template
    • Outline1. A little LinkedIn history2. A new direction: client side rendering3. Picking a templating technology4. Take dust for a spin5. Challenges: SEO, i18n, logic6. The Future
    • LinkedIn in 2013 We now many services using client side rendering and many using server-side rendering
    • A full rewrite is too expensive
    • Fizzy: Composable UI
    • Fizzy Fizzy is an ATS plugin that reads the HTML (skeleton or full) returned by webapps
    • Fizzy <html> <body> <h1>Composable UI </h1> <script type="fs/embed" fs-uri="/news-feed/top" ></script> <script type="fs/embed" fs-uri="/pymk"></script> <script type="fs/embed" fs-uri="/ad"></script> </body> </html> If Fizzy finds an fs/embed in the HTML, it calls the URI and injects the response into the page.
    • Fizzy HTML skeleton Embed Embed EmbedA page now consists of a skeleton with a bunch of Fizzy- processed embeds.
    • Deferred rendering
    • Typical page HTML Skeleton Dust template Dust template Dust template Dust template Dust template Dust template
    • Typical page HTML Skeleton Dust template Dust template Dust The fold template Dust template Dust template Dust template On initial page load, the user doesnt see anything below the fold
    • Typical page HTML Skeleton Dust template Dust template Dust The fold template Dust template Dust templateNo needto render Dust template No need to fetch data or render
    • Deferred rendering● Dramatically improve performance by not rendering anything below the fold● Improve it even further by not fetching the data for things far out of view● The challenge: the fold is at different positions on different devices
    • Outline1. A little LinkedIn history2. A new direction: client side rendering3. Picking a templating technology4. Take dust for a spin5. Challenges: SEO, i18n, logic6. The Future
    • Final thoughts● Dust.js has improved developer productivity and code sharing at LinkedIn● Client side templating offers powerful new capabilities and benefits● It also introduces tough new challenges● Its an evolving technology; now is a good time to get involved
    • Questions?