Dust.js Is Still Awesome

Edit 2019: Just go with Vue.js — it’s similar but a lot better.

I just wanted to give Dust.js a quick shoutout. I feel like it’s one of the more overlooked template libraries. Recently it got some well-deserved love from The New York Times.

For reference, I’ve been primarily an end-to-end JS developer for a few years. In that time I’ve used Jade, Handlebars, Mustache, EJS, and before that I used EBS in Ruby on Rails, and jQuery templates. Before that I used HTML or XML for templates, with a DOM node innerHTML replace system.

I’ve been using Dust at my workplace for almost 3 years. Originally, they had done research on the various libraries and came to a similar conclusion as LinkedIn in their article. Since then, we’ve rebuilt the entire architecture and still chose to use Dust, not only because we were familiar, but also because nothing else seemed better. In my opinion, most seem lacking in comparison.

That was, until, React. But I’ll save that for another post… If you’re going to choose a template library, I recommend Dust.

In 2014, while building my own platform I also looked into which template library, and felt like Dust was still the best fit all these years later. Lets break down the biggest benefits:

1. It’s an extension of HTML. Any HTML can be copy/pasted and continues to work.
2. It’s fast. It compiles down into JavaScript with some strings as values, which can be done before deployment for performance.
3. It has very simple but powerful helpers, which can be extended, and statements for conditions, looping, etc.
4. It can be compiled on client side and server side, so with a little effort, can have isomorphic SEO-friendly pages.
5. It has very little syntax constraints, so it supports JavaScript or possibly even other template library.

Some gotchas:

1. If embedding JavaScript, it can choke on // comments. However, the comment style /* */ works fine.
2. If embedding JavaScript, debugging can be a pain.
3. Nothing built in to support a component system for UI.
4. With hundreds of templates, the bundled size may end up quite large due to the HTML strings, but there are some ways around that.

For the first and second issue, we simply don’t embed JavaScript inside Dust templates anymore. It’s really not needed. We just put the script tag. For the last issue, it looks like The New York Times came to the same conclusion as us, and we both built Dust helpers for components. In our case, ours something like this:

The `{@c-something /}` convention is to use a custom Dust helper, and we’ve defined a new helper for each component (automatically using a config). It ends up looking a bit like React components, which is a nice bonus since we use React extensively now as well.

In conclusion, I’d like to re-iterate how useful Dust.js has been in our journey and even if we end up switching to React.js in the next iteration of the platform, there are some things I will miss. No matter which route you choose, stay stylin’ folks.

Godspeed,
Eric