Eu e o Angular

Semana passada colocamos no ar a nova versão do /dev/All que mudou radicalmente sua arquitetura (detalhes não técnicos neste link): dentre as principais mudanças está o fato de que agora a interface com o usuário é um SPA. Este é o primeiro post no qual compartilho com vocês algumas das coisas que aprendi no processo.

Note que esta é a visão de alguém que tinha como ferramenta principal para o desenvolvimento de aplicações SPA o Vue.js. Sendo assim minhas impressões em sua maior parte fazem uma comparação com ele. Leve em consideração que são “novas novas impressões” a respeito do Angular. Muita coisa pode mudar conforme minha experiência progride.

Por que não gostava

Uma das principais razões pelas quais aprendi Vue.js, confesso, foi para não usar o Angular. Além do trauma da quebra de compatibilidade da versão 1 para a 2, naquele momento ele me parecia muito mais complexo do que eu precisava. E o fato da versão 2 ser essencialmente TypeScript e não mais JavaScript também me incomodava (que ironia, eu, que amo Grails, dizer isto…). Também me incomodava horrores a documentação oficial que peguei na época: era horrível.

Eu já havia experimentado o Angular em projetos legados e, acredito, isto contribuiu também para minha péssima impressão original do framework. Vue.js era para mim como um copo d’água para quem estava no inferno. O tempo passou e acabei dominando o Vue, que se tornou até agora minha ferramenta favorita para o desenvolvimento de SPAs, aplicações híbridas e qualquer projeto que envolvesse interatividade mais rica. Até agora.

Mas o grande lance é que minha visão a respeito do Angular estava errada. Enquanto o Vue é essencialmente focado na camada de visualização (e essencialmente apenas nela), não havia ainda atinado o Angular como um framework, mas sim como uma biblioteca.

Resumindo, minha aversão ao Angular era resultado destes fatores:

• A documentação de anos atrás que era bem ruim.
• O trauma da quebra de compatibilidade da versão 1 para a 2 do Angular (acaba que sempre penso nos projetos a médio e longo prazo).
• O fato de se mostrar mais complexo do que minha real necessidade na época.
• A adoção do TypeScript como linguagem e não JavaScript.
• Eu estar ignorando o aspecto essencial do Angular: o deste ser um framework (este doeu) para aplicações maiores.

Por que estou gostando

O que me fez realmente gostar do Angular foi criar vergonha na cara e perceber que já havia passado da hora de aprender o framework a fundo.

Chegou um dia no qual quis finalmente transformar a interface do /dev/All em um SPA e me peguei adotando o Vue.js sem sequer me questionar a respeito. Por que apenas Vue.js estava no meu radar? Era hora de sair da zona de conforto, o que me fez passear pelo React e… Angular novamente.

Um bom livro e uma melhor documentação

Dado que a documentação oficial do Angular que conhecia até então era um lixo, optei por desta vez escolher um bom livro ao invés da documentação oficial, e acertei. Comprei o “Angular in Action”, de Jeremy Wilken, publicado pela editora Manning. Sem sombra de dúvidas foi uma das melhores leituras do ano: é um excelente ponto de partida pra quem está começando, e como foi publicado em março de 2018, eu podia ter certeza de que estava lidando com uma das últimas versões do framework (olha o trauma se manifestando!).

Logo na sequência resolvi visitar novamente a documentação e, que surpresa! Está MUITO melhor. Segui o tutorial de uma ponta a outra e, numa experiência que começou em uma sexta-feira a noite e terminou no domingo, já havia devorado uns 90% da documentação oficial. Esta foi a primeira mudança: um bom livro e uma documentação muito melhor.

O ferramental

Mas mais do que a documentação, me encantou o ferramental do Angular. Quando comecei, muitos anos atrás, ainda não havia a ferramenta de linha de comando (ao menos eu não a conhecia). E caramba, como ela ajuda! Foi graças a ela que o aspecto framework do Angular ficou nítido pra mim (e até agora me pergunto: por que ignorei o essencial por tanto tempo???). Não só isto: o VS Code também oferece um suporte maravilhoso ao Angular e TypeScript (claro, é criação da Microsoft). Este foi o segundo fator: o ferramental do Angular é incrível e está muito à frente do que eu tinha no Vue.js.

Aliás, diga-se de passagem, minha experiência com o VS Code trabalhando no /dev/All foi tão boa que este acabou substituindo meu editor favorito até então, que era o Atom.

Ionic framework

É importante mencionar aqui outra razão importante que me motivou a estudar o Angular: Ionic. Apesar de haverem planos de no futuro este suportar o Vue.js, hoje ele suporta BEM mesmo é o Angular. De todos os frameworks híbridos que analisei, de longe Ionic foi o que, de novo, apresentou o melhor ferramental (isto merece um post no futuro).

(e olha que na itexto existe um framework que desenvolvemos para aplicações híbridas, baseado em Vue.js, que é simplesmente incrível)

TypeScript

Motivos irracionais me levaram a postergar o Angular por causa do TypeScript, confesso. Mas quando me atinei que uso Groovy no mundo Java esta irracionalidade foi aniquilada. Pouco a pouco fui aprendendo TypeScript e me encantando com a linguagem. Percebi que alguns dos erros comuns que cometemos com JavaScript não ocorrem no TypeScript: só isto já era razão para que a linguagem fosse adotada.

Devo confessar que parte da minha crescente adoção da linguagem se deu por causa do VSCode. Como ele me oferece um excelente suporte à linguagem (code complete, detecção de erros), ele me ajudou HORRORES a aprender os detalhes da linguagem e como ela funciona.

Sinceramente, não sei se o TypeScript terá lá uma grande longevidade dado que o JavaScript pouco a pouco vai se tornando um “TypeScript padrão”. Entretanto, hoje, e pelo menos pelos próximos três ou quatro anos, a linguagem se manterá, o que em si já justifica sua adoção.

(agora, sua documentação oficial, achei bem ruinzinha viu)

O framework em si

Quando comecei a entender mais a fundo como o Angular organizava e orquestrava seus elementos me apaixonei por ele. O conceito de módulos, por exemplo, achei incrível. De repente encontrei uma maneira muito mais interessante de modularizar código reutilizável entre projetos. É como um OSGi, só que no mundo JavaScript.

Os serviços também são muito interessantes: enquanto no Vue.js temos o Vuex para estado compartilhado, o que pode virar facilmente uma zona conforme o projeto cresce de tamanho, no Angular tenho serviços gerenciados por injeção de dependências e que podem ser singletons. Pronto: é como o Spring, só que no mundo JavaScript.

(OSGi… Spring… duas coisas que gosto no Java… agora do lado JavaScript/TypeScript da cerca…)

O modo como os arquivos que definem um componente são organizados também gostei bastante. No caso do Vue.js, temos os arquivos .vue do Vue Loader. É uma solução bacana, mas como tenho estilo, marcação e lógica no mesmo arquivo, conforme estes aumentam em complexidade, dificulta-se a manutenção (eu sei que o ideal é termos estes caras pequenos, mas eles crescem).  Gostei de ter arquivos em separado.

(Aliás, conto um segredo aqui: muito tempo atrás, quando comecei a aprender Vue.js, implementei o meu próprio “vue-kico-loader”, que era quase igual ao esquema adotado pelo Angular (sua manutenção ficou complexa, vi que o ideal era o Vue Loader, e aí abandonei o projeto))

Sabe do que não gostei? Da sintaxe dos templates: ter de usar coisas como [(ngModel)], *ngFor, coisas assim achei um saco. Neste aspecto o Vue.js é bem mais interessante.

Resumindo: para projetos maiores, a manutenção do código Angular se torna algo muito mais simples em relação ao Vue.js na minha experiência até agora.

Curva de aprendizado e produtividade

Aprende-se Vue.js muito mais rápido que Angular. Já tive experiências na itexto de pessoas sem nenhum conhecimento de desenvolvimento web que em quatro horas já se tornavam produtivas com o Vue.js. Aliás, este foi o fator que mais me encantou no Vue até hoje.

No caso do AngularJS, em minha primeira experiência, não observei isto. Levava um bom tempo até entender os controladores, o modo como eram as interações entre os elementos do framework e até mesmo alcançar uma produtividade mínima com ele.

No caso do Angular 6, que foi meu alvo, percebi que em um dia eu já estava conseguindo fazer alguma coisa com ele. Repare: “alguma coisa”. Ainda não me sentia confortável com a ferramenta. Mas passada uma semana de prática constante, hoje digo que sou bem mais produtivo com Angular que com o Vue.js. Em grande parte devido ao ferramental e do TypeScript.

No caso do Vue.js, usando o Vue.cli posso usar templates prontos que me dão um scaffolding similar ao do Angular, mas ele em si ainda não é tão evoluído, o que é natural, dado ser uma solução mais nova. Entretanto prevejo que no futuro este jogo vire, pois Vue.js ainda é mais fácil de dominar em pouco tempo, na minha experiência.

Como está sendo até agora

Está sendo ótimo. O grande teste é ter um sistema em produção no qual seja necessário dar manutenção de forma ágil. O projeto é o novo /dev/All, e sim, estou conseguindo realizar mudanças em minutos com um framework que ainda não domino inteiramente e com qualidade. Passou no teste.

Apesar de muita gente estar indo para o Vue.js e saindo do Angular, do ponto de vista corporativo, apostaria no Angular, pois a manutenção e o aspecto “framework” da ferramenta é realmente muito interessante. É fácil dar manutenção em uma aplicação Angular.

No final das contas o aspecto “ferramental” também conta bastante: é boas IDEs que ofereçam suporte decente ao framework adotado, e no caso do Angular, devido à sua própria história, isto fica evidente.

Esta tem sido minha experiência com o framework até este momento: aprendi algumas outras coisas que pretendo compartilhar com vocês em um futuro próximo conforme vou narrando aqui a jornada que entramos ao lançarmos o novo /dev/All, pois muitas das minhas concepções mudaram e estão mudando no processo.

Até lá. ;)

PS:

ainda me confundo um pouco com os termos Angular e AngularJS.