Atualmente aqui no trabalho estamos definindo uma framework para o lado cliente (somente HTML e JS) que possa salvar nossas vidas, que seja “componetizada”, de fácil uso e acima de tudo tenha pouca dependência no layout utilizado na página (podendo usar Bootstrap, Foundation, 960.gs e zas).

1

{{handlebars}}

1
2
3
4
5
6

//Exemplo do site da engine HandleBars 
var source   = $("#entry-template").html();
var template = Handlebars.compile(source);

var context = {title: "My New Post", body: "This is my first post!"}
var html    = template(context);

Em meio a elaboração do projeto nos deparamos com a necessidade de utilizar um template JS, eu já tinha trabalhado com EJS mas estava fortemente voltado ao HandleBars (culpa do Meteor), sendo assim, fui dar uma googlada e percebi que existiam dezenas de engines de template e que o LinkedIn tinha feito um comparativo com várias opções para definir o que eles usariam na parte de view do site (clique aqui para ver os resultados).

Dentre as opções o HandleBars teve alguns elogios por parte da equipe do LinkedIn e por esse e outros motivos acabamos escolhendo-o. Mesmo sendo uma excelente engine e que também suporta templates do Mustache (que tem uma comunidade enorme) creio que testes de conceito sejam a melhor maneira de averiguar o que atende a sua necessida, assim como fez a equipe do LinkedIn.

Teve um ponto em específico levantado pela nossa equipe que me fizeram pensar 2 vezes antes de apoiar totalmente o HandleBars: “O CACHE”. No EJS para “cachear” um template é estupidamente simples pois já vem nativo já no HandleBars sua implementação é um pouco mais trabalhosa.

1
2

//Inativando o cache...
EJS.config({cache: false});

Mas creio que para saber como funciona esse lance de template JS a melhor opção seja o EJS, é mais tranquilo de trabalhar (com coisas simples), caso a idéia (como é a do nosso framework) seja mexer com vários componentes criando helpers e plugins aconselho o HandleBars por ter uma documentação mais vasta já que ele veio do Mustache.