Should I switch from EJS to Dust.js while using Kraken.js?

Question

We have been developing a Express app with EJS as templating engine for sometime. After Kraken.js released its version for compatible with expressJS 4, I am given the task of migrating from express to Kraken. My app is not a MVC app. It is a view Model, gets all its data from another node.js server via restify.

I started researching on Dust.js which comes in default with Kraken.js. I am having a hard time trying to decide whether I need to switch my templating language from ejs to Dust. Some of things with regards to Dust.js that are relevant to my app are:

1. It is a less logic templating engine. I can easily switch the templating engine in the future
2. I really only care about Client side templating
3. It can be used for asynchronous rendering( not sure if it can be on the client side)
4. It has partials both static and dynamic
5. It has helper methods which can help with logic. It has for loops, math etc

My question is I was able to do all the above with EJS. Why do I need to switch to Dust.js? What advantages does Dust.js bring with respect to EJS in the context of Kraken.js?

Answer 1

It is not inherently necessary to use dust with kraken. PayPal uses dust and has, therefore, built a lot of infrastructure around it, but if you have no need for those bits of functionality, using any other templating language is all the same (save the fundamental difference between those templating languages).

As for what you gain by using dust with kraken: the simplest explanation is localization. A couple of modules in the krakenjs stable of monsters presently have a hard dependency on dust. Namely, engine-munger (specialization and l18n), makara (l18n—largely superseded by engine-munger), and adaro (an express dust renderer). Some modules leverage dust if that's in use (bundalo, for one, puts things into the dust cache on your behalf) or expose first-class support for dust (kraken-devtools which handles environment specific asset compilation; e.g., compiling assets on the fly in dev vs with a build step on prod).

All said, if you don't need to use the supported method for internationalization, you won't necessarily lose anything. You may end up having to write some of your own infrastructure if you want to use certain things like kraken-devtools or karka, but those are definitely not insurmountable issues.