Este artigo foi escrito há um ano, e por sugestão de um leitor, adiciono aqui alumas considerações sobre o que escrevi naquela época.

Algum tempo depois da primeira versão deste artigo ir ao ar, recebi a notícia de que Rob Eisenberg hávia deixado o core team do AngularJS. Isso ocorreu devido alguns desentendimentos entres os membros, segundo o proprio Rob Eisenberg.

Eis que surge então o Aurelia, que na verdade é/será algo muito similar ao AngularJS 2.0. A atual versão estável do AngularJS é: 1.4.7, e está muito melhor do que a versão 1.3, quando saiu o artigo abaixo.

Entretanto, com pouco mais de 2 anos desenvolvendo com AngularJS, 8h por dia, 5 dias por semana, seu tool kit e snippets já estão maduros o suficiente para iniciar qualquer aplicação do zero e com muita rapidez. O $http está mais conciso e eficiente, além de muitas outras alterações. Mas enquanto a versão nova não chega, desenvolver com a verão 1.4.x é uma ótima opção.

Neste link esta uma pesquisa sobre as mudanças na nova bibilotéca. Uma delas não me agrada, a Typescript. Mas isso é tema para outro artigo.

A razão principal para toda essa mudança é uma só: performance – o que é ótimo. Se voce já desenvolveu alguma aplicação realmente grande, sabe que a performance é bastante sacrificada.

Onde você não deve utilizar Angular.JS.

Apesar de robusto e bem popular, este excelente framework não é a solução para todos os seus problemas. Isso infelizmente é um fato muito verdadeiro.

A opinião é bastante dividida quando o assunto é Angular, e quem não gosta realmente consegue apresentar inúmeros pontos fracos para sua utilização. E quem gosta, realmente ama e denfende com unhas e dentes, geralmente como tudo da Google.

Escrevi este artigo porque após 8 meses trabalhando em um projeto com Angular, pude verificar que, apesar do projeto ter sido finalizado com sucesso, perdemos um tempo relevante em seu desenvolvimento e, após concluído, o mesmo foi engavetado. Poderíamos ter concluído o projeto em metade do tempo utilizando jQuery e alguma Lib, ou com Observable (na época, ainda não tinha Object.observe()) e com certeza poderíamos ter realizado o pivô do negócio, antes do fracasso. Não entenda que o projeto fracassou devido a utilização do framework, e sim porque fizemos a escolha errada para este projeto, devido ao conhecimento da equipe.

É fundamental saber onde você não deve utilizar o Angular e buscar alternativas semelhantes. Não ele não é indicado para pequenos sites ou landing pages, mas utilizá-lo em aplicações de grande porte pode ser muito complexo, vamos entender porque:

O Angular compila todos os elementos do HTML antes de mostrá-los no browser, exatamente tudo na aplicação é compilado, data-binding, directivas etc. Isso pode impactar no tempo de carregamento e no browser utilizado.

A curva de aprendizado inicial é muito breve, mas a medida que a aplicação cresce, e você tem que sair da caixinha, esta curva se torna absurdamente grande e para alguns problemas simples a solução encontrada pode não ser tão simples assim.

Ele é flexível e quando este elemento não está acompanhado de uma padrão de organização previamente estabelecido, a flexibilidade se torna bagunça e mais dor de cabeça.

Se a equipe está acostumada a manipular o DOM com jQuery, vai ter que aprender a pensar diferente com Angular.js. Existe um versão light do jQuery dentro do Angular com alguns métodos, mas para utilizá-lo você vai ter que gastar um tempo aprendendo, senão corre o risco de estar utilizando jQuery para fazer muitas coisas que o framework tem seus próprios recursos para fazer.

Aplicações que deve oferecer suporte a browsers desatualizados (IE 7,8), não devem utilizar Angular. E acredite ainda existem muitos usuários de IE por aqui.

Atualmente existem poucos desenvolvedores (front-end) realmente experientes em Angular no mercado. Isto é uma realidade (entenda que falo de desenvolvedores com experiência na solução de problemas complexos de interface, não apenas para escrever TO-DO app).

Erros de principiantes, como:

• Escrever a lógica da aplicação na View;
• Manter um único arquivo para todos os Controllers;
• Deixar o client acessar diretamente os dados, sem passar por um Model;
• Deixar a View alterar os dados do Model antes de exibi-los (não confundir com filtros).

E coisas deste tipo, ao longo do tempo, trazem conseguências indesejadas.

O futuro

A versão 2.0 será uma fusão entre a evolução do Angular com outro framework, o Durandal.js que é um mix de jQuery, Knockout.js e Require.js.

A evolução para esta nova versão está a passos largos, veja este report de março, a própria versão 1.3 já mostra alguns sinais do que vem por aí – esta versão já não oferece suporte ao IE8. Mais detalhes podem ser encontrados nos rascunhos da documentação.

Então, o Angular irá passar por grandes mudanças em seu core, nenhuma aplicação atual será compatível com a nova versão. Rob Eisenberg um dos desenvolvedores do Durandal.js foi integrado ao core do Angular com a missão de inserir todas as peculiaridade do Durandal.js na nova versão do Angular. E o Durandal.js permanecerá na versão 2.0.

Angular 2.0 As we’re starting into the implementation of Angular 2.0, we thought we should put pen to paper and give you some insight into how we’re thinking about the design and why we’re making the changes we are. We’re sharing it with you now so you can help make the right choices. Angular 2.0 is a framework for mobile apps. It is for desktop as well, but mobile is the hard bit that we will get right first. The Angular you know and, hopefully, love will still be there with data-binding, extensible HTML, and a focus on testability.
All the design docs for Angular 2 are publicly available on Google Drive. This document contains a summary of our approach and design principles with links to specific designs in context.

Muita coisa vai mudar e acredito que para melhor; mas coisas como Controllers, $scope, não existirão mais da maneira que conhecemos. Recentemente tem ocorrido um murmúrio muito grande em relação a todas estas mudanças e isso tem desapontado muita gente envolvida diretamente com o core de desenvolvimento do Angular.

Considerações finais

Entretanto, algumas coisas realmente funcionam muito bem, melhor ainda se o back-end for muito bem construído em uma arquitetura Restful bem estruturada, $resource e $httpProvider para lidar com autenticação utilizando interceptors são ótimos. Escrever objetos JavaScript puros dentros dos Controllers também é muito bom.

Se você tem tempo e o custo beneficio da utilização for compensadora, recomendo a utilização, e recomendo mais ainda ter um especialista na sua equipe. Ter em mente que menos é mais também ajuda na escolha das ferramentas para seu próximo projeto.

Este texto tem o intuito de facilitar a tomada de decisão, afinal é muito fácil encontrar inúmeros motivos para utilizar os frameworks mais populares; a comunidade é vibrante e, sem duvida, o Angular é o mais popular, além disso atualmente muitas empresas estão buscando profissionais front-end com conhecimentos em Angular, Backbone, Ember.

Mas atenção! Já observei alguns projetos muito simples (site institucional/ hotsite) terem em sua especificação a utilização do Angular, apenas porque dizem que ele é robusto e rápido. Isso tem inspirado pessoas (líderes e gestores de TI) com pouco conhecimento a exigirem este tipo de coisa em pequenos projetos pontuais.

Frameworks facilitam a sua vida e, sem dúvida, o Angular é ótimo, mas utilizá-lo em todos projetos possíveis e imagináveis não é uma atitude muito racional.