Choosing the right UI templating tool - dust.js? [closed]

Question

I work on a large Java based web application, it has been built up over the past 5 or so years - the UI needs an overhaul / to be largely re-written. We are investigating the available UI tools/libraries/frameworks to use and have come across dust.js as an option for templating.

The questions: I'm interested in hearing what users of dust.js think of it:

1. Has it been successful?
2. Is it easy to use?
3. Is it sufficiently documented?
4. Is community support good? (only 6 questions on ST tagged 'dust.js'!)
5. What are the pros and cons when compared to other templating tools such as Underscore's templating, Google Closure Templates, Handlebars and Mustache.
6. Are there any problems using it with an MV* structure framework, e.g Backbone.js (online book)?

Some background:

• Why are we interested in dust.js: The following LinkedIn blog posts first drew our attention to it:

  • Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates

  • The client-side templating throwdown: mustache, handlebars, dust.js, and more

    The second of the two posts very nicely answers question 5, but asides from LinkedIn, very few results from Google detail the templating system or imply that it is a popular choice. In addition, the post mentions that they have extended the functionality and hope to one day contribute to the original project. I'm concerned that until they do that, we may also need to extend functionality.

    Having said this, LinkedIn's original requirements for a templating system are very close to ours (see below) and they have clearly done some very thorough investigations before choosing.

• Our requirements:

  1. DRY: We ideally want to use the templating system on the server (Java based) and client-side, or just client-side if we opt for LinkedIn's complete approach; Instead of using a JSP, GSP, or ERB to assemble a page server side and send back HTML, we have the server send back just the dynamic data as JSON and have the page assembled in the browser using a static client-side template served from a CDN"
  2. Fully internationalised
  3. Good community support
  4. Sufficiency easy to use / pick up
  5. Works happily with jQuery and Backbone.js
  6. Well documented

Beanery

This is a neat little test page I found: linkedin.github.com/dustjs/test/test.html – Beanery

Answer 1

Dust.js is a good option. It is better than some of the other templating frameworks because it does not constrain that the data should be in a file, or in a string, etc.

Also it is being actively maintained https://github.com/linkedin/dustjs.

1. Has it been successful?

   Yes, I know at least LinkedIn is using it and also contributing improvements/patches, etc.

2. Is it easy to use?

   I have tried using it and it is as easy as Mustache or Handlebars.js.

3. Is it sufficiently documented?

   Yes http://akdubya.github.com/dustjs.

4. Is community support good? (only 6 questions on ST tagged 'dust.js'!)

   If you are comparing Mustache or Handlebars.js, dust.js does not have as many users, but I believe if you have an issue and post it on the LinkedIn repo they would definitely respond. I will too since I'm watching it :-)

5. What are the pros and cons when compared to other templating tools such as Underscore's templating, Google Closure Templates, Handlebars and Mustache.

   As for pros, you can check when you should consider using dust.js here https://github.com/linkedin/dustjs#readme.

   As for cons, there aren't enough users for dust.js compared to popular ones like Mustache or Handlebars.js. That said, the other libraries like Google Closure suffer the same problem.

   But like I mentioned before, dust.js is designed very well compared to other frameworks IMHO.

6. Are there any problems using it with an MV* structure framework, e.g Backbone.js (online book)?

   I have not used it with other MVC frameworks, but I don't think it should be a problem at all.

Hope that helps.

Rondure

Thanks, I had missed this page in my searches - github.com/linkedin/dustjs – Beanery

engineering.linkedin.com/frontend/… – Multifarious

Paypal is also using it for client and server side rendering. – Broaddus

Answer 2

1. I'm doing a freelance project now for quite a big and established niche IT company and they've chosen dust.js for their HTML5 mobile app framework. And yes, LinkedIn is a big and successful company.

2. Sort of. Nothing really difficult but I needed to get accustomed to it. I worked with Freemarker on Java - Freemarker seemed quite a bit easier to use because of a lot of built-in power features. However, many may find dust.js nice - it has its clear logic, very lightweight syntax - there are things in dust.js to really like for many.

3. Freemarker for Java was documented much better. dust.js's GitHub page is very OK for starters but, for example, I couldn't find the description of all the dust.js filters there and needed to search on Google for it - however, that search easily provided me with the info I needed.

4. Didn't see much community support but the library is really lightweight and clear - a couple of Google searches was all I needed to gather all the necessary info.

5. Didn't use other JS templating tools.

6. The company I mentioned in the answer to the 1st question has built a lightweight HTML5 framework using dust.js together with both jQuery and Backbone.js. I'm doing the project for them using that framework and tapping to both jQuery and Backbone.js functionality all the time - nothing to complain about. dust.js is a little bit like Backbone.js - lightweight and not imposing much restrictions on your coding style or other libraries you use. Using it you will see that there is some preferrable form of JS objects you use to feed it with the data but it's easy to get accustomed to (I mean if you need lists of something in your views it's better to feed dust.js with lists and not JS object hashes which at the same time are natural at describing separate entities).

One thing about performance - you can develop your app with "full" version and then compile your templates for production (using for example node.js + dust.js npm module - grunt can be useful here) to be used with "core" version. In this case you could get quite a boost in real-world performance - putting all the templates together and minifying them will free the client browser from fetching the templates from server every time it needs them. "Full" and "core" are not about commercial/free - the core version just doesn't have the template compiler and is to be used with pre-compiled templates.

Propitious