Javascript Templating Engine Chooser | Hacker News Reader

Javascript Templating Engine Chooser

garann.github.io

70 pointschunkyslink31 comments

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.

https://github.com/jlongster/nunjucks

Send in a pull request! It's on GitHub. That's what I did [0]

[0] https://github.com/garann/template-chooser/pull/20

It's missing DustJS, which is IMO a strong contender that does well in benchmarks

http://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

Came to say the same. Dust is a bit confusing and complex at times but overall is excellent.

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).

Dust is not logic-less, even disregarding the helpers.

Is there a way to deselect an option without reloading the page?

For example: Under "DOM Structure", once you select "DOM" or "String", you can never go back to seeing all the template options.

It seems a little buggy. There seem to be several state combinations that cause it to lock up.

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.

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.

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.

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.

Come back in 3 years. It'll have settled down.

Missing several from LinkedIn's throwdown: http://engineering.linkedin.com/frontend/client-side-templat...

I'd rather just see a matrix.

It might be more helpful if you provided an argument that wasn't just an assertion of your personal tastes.

If I don't know exactly what parameters I need it's easier to quickly scan a table than toggle individual options.

Maybe I want some subset of features that aren't available together but I'm willing to compromise on one or more of them.

Nicely put together :) Might want to hide a feature if the selection makes no difference (re-show when it does have potential to make a difference).

Example: Both, Entirety, Fastest, Then it doesn't matter if you say precompiled yes or no.

Helpful to learn about the options, but as soon as I said it was for the client and has to be fast, there were no options remaining.

Also, Swig.

http://paularmstrong.github.io/swig/

I encourage you who have found missing frameworks to submit a pull request instead of posting a comment.

Can't un-choose. If you choose in a particular department you cannot just take the choice away and it filters by it, forcing you to reload the page.

No plain mustache.js

What kind of chooser is this?

No option remains for Both, logic-less and fast.

Really surprised knockoutjs isn't mentioned. It is the default templating engine in a default .NET MVC project.

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.

jQote2 missing. In our benchmarks one of the fastest and a lot of features.

http://aefxx.com/jquery-plugins/jqote2/

Yea, I'm glad I'm not the only one using it. It's very fast and works great. Some bugs but workarounds aren't difficult.

Great work.

Unreadable font.

Reply on news.ycombinator.com