{ dust.js } at LinkedIn
Yevgeniy Brikman

2011: LinkedIn adopted dust.js, a
client side templating language

This is the story of client side
templating 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)

Outline
1. A little LinkedIn history
2. A new direction: client side rendering
3. Picking a templating technology
4. Take dust for a spin
5. Challenges: SEO, i18n, logic
6. The Future

Outline
1. A little LinkedIn history
2. A new direction: client side rendering
3. Picking a templating technology
4. Take dust for a spin
5. Challenges: SEO, i18n, logic
6. 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

Outline
1. A little LinkedIn history
2. A new direction: client side rendering
3. Picking a templating technology
4. Take dust for a spin
5. Challenges: SEO, i18n, logic
6. 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

Outline
1. A little LinkedIn history
2. A new direction: client side rendering
3. Picking a templating technology
4. Take dust for a spin
5. Challenges: SEO, i18n, logic
6. 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 Templates
Pros
● 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.

Mustache
Pros
● 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

Handlebars
Pros
● 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.js
Pros
● 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)

Outline
1. A little LinkedIn history
2. A new direction: client side rendering
3. Picking a templating technology
4. Take dust for a spin
5. Challenges: SEO, i18n, logic
6. The Future

The LinkedIn Fork
● The original maintainer abandoned dust
● The LinkedIn fork is now the most active
● We've 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)

Outline
1. A little LinkedIn history
2. A new direction: client side rendering
3. Picking a templating technology
4. Take dust for a spin
5. Challenges: SEO, i18n, logic
6. The Future

How do you handle view logic?

Yes, there is such a thing as view logic
and it's separate from business logic

Complicated
Logic logic
Logic

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 formatting
code to the browser is expensive

Option #1: everything server side
Java 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 side
Pros
● Simple, easy to understand
● Clean templates
Cons
● Controller code cluttered with view logic

Option #2: dynamic pre-processing
Original 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-processing
Java 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-processing
Pros
● All view logic is in the templates
● Clean server side code
Cons
● 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-processing
Original 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-processing
Pros
● Hybrid approach: i18n is in the templates,
only formatting/link generation is in controller
● Simpler, easier to debug than dynamic pre-
processing
Cons
● Custom build process
● Increased template payload, but i18n strings
now cached with template

Outline
1. A little LinkedIn history
2. A new direction: client side rendering
3. Picking a templating technology
4. Take dust for a spin
5. Challenges: SEO, i18n, logic
6. 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
Embed
A 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 doesn't see anything below the fold

Typical page
HTML Skeleton
Dust
template
Dust template
Dust
The fold template
Dust template Dust
template
No need
to 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

Outline
1. A little LinkedIn history
2. A new direction: client side rendering
3. Picking a templating technology
4. Take dust for a spin
5. Challenges: SEO, i18n, logic
6. 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
● It's an evolving technology; now is a good time to get
involved

Questions?