Entendendo a relação entre Ember, Handlebars e Glimmer

(Last Updated On: 6 de outubro de 2017)

Qualquer peça ou produto complexo é composto de vários módulos. A medida que algum desses módulos apresentarem defeitos ou não estiverem mais apresentando o desempenho necessário, ele poderá ser trocado.

Isso acontece com um carro, por exemplo, depois de uma certa quilometragem você precisar trocar os pneus, algumas peças do motor, etc. O mesmo acontece com o seu computador que, depois de um tempo precisa de um upgrade, um disco maior, adição de mais memória RAM e assim por diante…

A aplicação de técnicas por meio da engenharia de software tem o objetivo de utilizar esses mesmos conceitos: módulos plugáveis que podem ser atualizados ou trocados.

No mundo dos softwares open source as comunidades acabam fazendo isso com certa normalidade, evitando ao máximo que essas atualizações gerem impactos negativos no que já está funcionando.

Falando no framework Emberjs, podemos citar a relação entre o Ember, Handlebars e Glimmer como um exemplo. Apesar de seu surgimento ter acontecido em momentos diferentes, estão em busca de uma mesmo ideal: tornar o desenvolvimento web mais eficaz.

O projeto Ember surgiu como um fork do Sproutcore e a engine de templates Handlebars foi um aprimoramento do Mustache.

Uma engine de templates serve para interpolar valores dinâmicos obtidos em uma Linguagem de Programação a trechos de código HTML.

No caso do Handlebars isso pode ser feito utilizando a linguagem Javascript, rodando em praticamente qualquer navegador de internet, evitando de usar HTML embutido, base de tecnologias que são utilizadas em arquivos .erb, .jsp, .asp, etc. Por exemplo, tendo o seguinte template:


Quero aprender {{ferramenta}}!

Combinado com o Objeto:


{ ferramenta: "Emberjs" }

Traria o seguinte resultado:


<div>Quero aprender Emberjs!</div>

Além do Ember e Sproutcore já mencionados, outros projetos também usam o Handlebars, como o YUI, que tem sua própria versão do Handlebars, ou o Marionette.Handlebars, que é a integração com a biblioteca Marionette.

O Ember extende o Handlebars, dando a ele uma forma de estruturar os arquivos e suporte ao binding de propriedades automaticamente. Vamos exemplificar com um componente no Emberjs


import Ember from 'ember';

export default Ember.Component.extend({

 ferramenta: 'Emberjs'

});

Quero aprender {{ferramenta}}!

{{input value=ferramenta}}

A principio teríamos o HTML:


<div>

 Quero aprender Emberjs!

 <input value="Emberjs"/>

</div>

Mas a medida que o alterarmos o conteúdo do input, o valor do também será alterado, por exemplo se digitarmos Glimmer, teríamos algo parecido com o HTML:


<div>

 Quero aprender Glimmer!

 <input value="Glimmer"/>

</div>

Essa “facilidade” do two way data binding, onde você altera o valor do atributo no HTML refletindo no Javascript ou vice-versa, tem seu custo e até a versão 2.9.X, o Ember tinha um problema de performance, se comparado aos concorrentes do mercado(Angular, React, etc).

A partir da versão 2.10 o Ember trouxe uma grande atualização e baseada no conceito de “estabilidade sem estagnação”, a transição entre as versões 2.9 e 2.10 pode ser feita de maneira suave.

Além dos problemas de performance, essa atualização também diminuiu significativamente o tamanho dos assets gerados no processo de build. Para se aprofundar nisso é só dar uma pesquisada que vai achar benchmarks bem interessantes!

Até a versão 2.9, a integração entre o Ember e o Handlebars era feito pelo HTMLBars, posteriormente, a partir da versão 2.10, esse motor de renderização foi trocado por um novo, chamado de Glimmer, ele se denomina como uma biblioteca de componentes gráficos rápida e leve feita pela equipe do Ember e apesar dele ser composto de vários projetos nos referiremos a ele de maneira singular.

O Glimmer pode ser usado de maneira independente do Ember, porém parece não fazer sentido termos apenas o motor sem as rodas e chassi.

Resumindo…

Em resumo, poderíamos dizer que o Glimmer 2 – assim nomeado em seu anúncio – foi uma evolução do HTMLBars(Glimmer 1), em que o processamento dos templates era feito utilizando a API do DOM, revitalizado como um novo projeto, utilizando várias técnicas de engenharia onde o processamento dos templates é feito de maneira incremental.

Agora pode surgir outra pergunta:

“É possível usar o Glimmer sem o Ember?”

A resposta seria sim, mas lembre-se, ele é apenas uma biblioteca de componentes. Um fato para ainda utilizar o Ember seria o sistema de roteamento de endereços e templates.

Esperamos que com o tempo surjam mais e mais atualizações como essa, podendo melhorar nossas aplicações sem necessidade de reescrevê-las completa ou parcialmente.

Quer conhecer mais sobre o Ember, veja nosso livro em português pela Casa do Código! Acompanhe também as novidades da Casa do Código no Facebook e Twitter! 😉

FIQUE POR DENTRO

Próximo ArtigoConheça as principais etapas da criação de um logo