I am curious why this isn't ported to more languages like mustache is. I ported it to PHP, but it's not really language specific for just the templating part, though context assignment and callbacks might be (but aren't hard).
Hmmm, I wonder about the reliability of the information, or perhaps reliability is not the right word, maybe completeness would be better.
I don't know who Garann is, and I don't use Javascript templating, and yet just by playing with the options on the page I was able to predict that Garann is using with dot.js. A quick Google then confirmed the hypothesis, which makes me think that the options that are available are aimed quite specifically at Garann's use case, and might not be generally applicable.
The "app" is just a bit of jquery that hides/shows divs based on their classes. It skips a refresh if the filter is empty ( to avoid creating an invalid jquery selector?), so if you set "View Partials" to "Yes" and then "No", nothing changes. Anyways, I just forked it and fixed it.
This is a simple little app, but it's a good example of how using the DOM as a model and a view (as most jquery apps do) doesn't create the most elegant code.
It's also missing Nunjucks, which works in browser and server, can precompile templates (when done so is really fast), lets you do more logic in templates, has autoescaping, and a bunch of other stuff. Some big project like Mozilla's new Marketplace is using it.
This is just one of the reasons why I feel developing web apps has gotten harder. While there are a lot of javascript frameworks it is likely two projects pick different routes. It basically means if I need to maintain a project I will have to learn a new javascript library.
Hmm, I see why it could feel like that but I don't really agree. Here's another angle:
Would you rather learn some (hopefully) very well worked-out library with good documentation and all the edge-cases slaved over, with multiple contributors, with Stack Overflow questions about it ... or, would you like to learn some random guy's non-library library, because he was scared of libraries, so he just made up a load of ad-hoc conventions in his codebase.
I'd rather learn to use Backbone, Angular and Ember, than have to deal with big-ball of mud code based on no library in particular. Same goes for templating libraries, I'd rather learn a handful (after all they're relatively trivial to use), than come to a codebase that uses none at all.
Also, if you're using a tool that was built more than a year ago, you risk ridicule. Definitely a lot more work figuring out what the hottest new tools are than in traditional or backend development.
It's the ciiiiircle of life. We're at the "Cambrian Explosion" stage of front-end frameworks. The variance in approaches, technologies, and boundaries between the various moving parts is just the ecosystem sorting itself out.
Knockout is an MVVM (MV*) framework, it is much more than a templating engine. If it had a standalone templating module, then that module could qualify for the comparison for sure, but as it stands it would not make much sense to include it in the comparison.
32 comments
[ 2.9 ms ] story [ 70.9 ms ] threadhttp://linkedin.github.io/dustjs/
* Works in the browser and on the server
* Pretty fast
* logic-less but with a helpers API for when you need more power
* pre-compiles templates
* has template partials
I don't know who Garann is, and I don't use Javascript templating, and yet just by playing with the options on the page I was able to predict that Garann is using with dot.js. A quick Google then confirmed the hypothesis, which makes me think that the options that are available are aimed quite specifically at Garann's use case, and might not be generally applicable.
Example: Both, Entirety, Fastest, Then it doesn't matter if you say precompiled yes or no.
For example: Under "DOM Structure", once you select "DOM" or "String", you can never go back to seeing all the template options.
http://xinsight.github.io/template-chooser/
This is a simple little app, but it's a good example of how using the DOM as a model and a view (as most jquery apps do) doesn't create the most elegant code.
http://paularmstrong.github.io/swig/
Maybe I want some subset of features that aren't available together but I'm willing to compromise on one or more of them.
https://github.com/jlongster/nunjucks
[0] https://github.com/garann/template-chooser/pull/20
Would you rather learn some (hopefully) very well worked-out library with good documentation and all the edge-cases slaved over, with multiple contributors, with Stack Overflow questions about it ... or, would you like to learn some random guy's non-library library, because he was scared of libraries, so he just made up a load of ad-hoc conventions in his codebase.
I'd rather learn to use Backbone, Angular and Ember, than have to deal with big-ball of mud code based on no library in particular. Same goes for templating libraries, I'd rather learn a handful (after all they're relatively trivial to use), than come to a codebase that uses none at all.
Come back in 3 years. It'll have settled down.
http://aefxx.com/jquery-plugins/jqote2/
What kind of chooser is this?