Perdendo o preconceito com o novo Angular

Perdendo o preconceito com o novo Angular – Com tantas pessoas mais experientes que eu listando coisas boas e ruins, eu realmente desanimei. Mesmo assim, por saber da demanda no mercado, eu continuei seguindo a evolução dele, pensando que as coisas iriam melhorar. Muitas coisas que vejo ainda me desanimam, mas mudei alguns pensamentos e até vejo o novo Angular como um aliado.

Vou listar aqui alguns itens que me desanimavam e o motivo de eu ter mudado de ideia. Quem sabe você se inspire e considere utilizá-lo para o seu próximo projeto? É sempre bom manter a mente aberta, não? 😉

Major version a cada 6 meses

O novo Angular não tem nada a ver com o Angular 1. Ele foi criado do zero. No final de 2016 foi anunciado que uma nova versão seria lançada a cada 6 meses, ou seja, logo logo teremos o Angular 4.

Por causa desse versionamento “agressivo”, não há mais razão para chamarmos de Angular 2. O recomendado é chamar o antigo de AngularJS e o novo simplesmente de Angular.

Lembro do AngularJS em sua versão 1.2. Após um tempo eu precisei muito de algumas funcionalidades lançadas no 1.4, mas isso quebrou muitas coisas de bibliotecas de terceiros. Tive que me contentar com algumas coisas que já haviam na 1.3 mesmo.

Até mesmo quem quis sair na frente e escreveu livros e criou cursos na fase alpha ou na fase de lançamento do novo Angular teve que arrumar muita coisa. Várias coisas mudaram de um dia para o outro.

Estão dizendo que agora todas as versões serão compatíveis com versões mais antigas. Já ouvi essa história antes no AngularJS, e não aconteceu. Mas eu aceitei, porque realmente há momentos em que temos que evoluir algumas funcionalidades, e outras acabam se tornando obsoletas. Faz parte do desenvolvimento e, com o tempo, algumas funcionalidades acabam sendo removidas. Seria muito pior uma ferramenta que não evolui ou que fica carregando código legado o “resto da vida”.

Será que o seu sistema realmente vai precisar ficar migrando para cada versão nova que sair? Se for o caso, será que você escolheu bem a ferramenta ou modo de desenvolver?

Sintaxe completamente diferente

Se tanta gente já estava acostumada com o modo de desenvolver do AngularJS, por que criar uma sintaxe tão diferente?

AngularJS:

<input type="text" ng-model="name" ng-click="doSomething()" />

<ul>
   <li ng-for="item in list" ></li>
</ul>

Angular:

<input type="text" [(ngModel)]="name" (click)="doSomething()" />

<ul>
   <li *ngFor="let item of list" ></li>
</ul>

Esse foi um tapa na cara de quem veio do AngularJS e achou que poderia reaproveitar algumas coisas no Angular. Mesmo as partes mais simples e conhecidas do AngularJS são bem diferentes das do Angular, como podemos ver no exemplo acima, ao utilizar o famoso ng-model, fazer loopings ou chamar eventos.

Quem conhece o novo Angular sabe o motivo por trás da sintaxe [()], conhecida como “banana in a box”, ou o * do *ngFor. Mas dava muito bem para tentar deixar algumas coisas com a sintaxe igual, né? Facilitaria muito, pois aprenderíamos intuitivamente, só de lembrar da sintaxe do AngularJS, sem ter que procurar como fazer algo.

Hoje eu tenho outra opinião. Por ser uma ferramenta totalmente diferente, funcionar diferente, é importante que saibamos conscientemente o que estamos fazendo.

Trabalhar com um serrote levando em conta a sua experiência com um martelo pode fazer com que você não faça um bom códigão.

Hanashiro, Akira

A mudança até nos detalhes que já conhecíamos nos força a estudar do zero. O nome da ferramenta pesou bastante por seu legado. Por ser algo feito do zero, talvez teria sido bom (ou essencial) criar um novo nome. Chamar de Angular 2 foi puro marketing.

Lembre-se: Angular é uma ferramenta totalmente diferente do AngularJS.

Início de projeto muito complicado

Nossa, essa no começo era indiscutível. Tínhamos que configurar o transpilador para o TypeScript, pegar as dependências do Angular como o zone.js, pegar o SystemJS, angular2-polyfills, etc.

Depois o arquivo principal. Tem que saber o que importar. Tem coisas que vêm do @angular/core, outras do @angular/forms, @angular/platform-browser, etc. Com o tempo você se acostuma.

E então criamos uma classe e passamos algumas (muitas!) informações para a anottation @ngModule. Várias das coisas que importamos temos que passar para a anottations. E isso, após um tempo, começa a cansar, concorda?

E depois de várias linhas, estamos prontos para nosso primeiro Hello World! Para quem está iniciando na profissão, a sensação é tipo essa:

Sendo que no AngularJS, bastava importar o código, colocar um ng-app no container da aplicação e pronto! Até mesmo o React, que necessita transpilar o JSX, o que nos faz ir em busca de ferramentas como Babel, é bem mais simples para quem está iniciando.

Hoje em dia podemos iniciar facilmente uma aplicação com o @ang/cli, ferramenta feita em cima do ember-cli, que serve para estruturar a aplicação automaticamente a partir de comandos. Até os imports são colocados automaticamente.

Eu não gosto muito de ferramentas assim, pois muitas vezes produzem muito código que não iremos utilizar, e se precisarmos apagar alguma coisa, teremos que conhecer bem o que foi criado, pois teremos que apagar na mão.

Outros podem dizer: “Estruturar automaticamente sem nem saber o que está acontecendo? Isso é loucura. Não dá certo!”.

Bem, já foi provado que aprendemos mais rápido se formos logo de “cabeça” em algo ao invés de ficar estudando a teoria primeiro. É como dizem: “Aprendemos a andar caindo, não observando.”

Muitos cursos modernos de línguas estimulam a prática do idioma já no início, ao invés de ficar primeiro te ensinando pronomes, depois verbos, e só depois formar frases. Esse é um dos motivos por trás do sucesso de aplicativos como o Duolingo, que para muitos é só uma brincadeira mas para outros é uma ferramenta muito bem elaborada.

Tenho que admitir que depois que parei de me preocupar com o que cada linha fazia, e mergulhei de cabeça na criação de código, aprendi mais rápido. Agora que já conheço melhor a ferramenta, entender o que cada uma daquelas linhas faziam ficou mais fácil.

Mais uma vez: É uma ferramenta diferente e com propósitos diferentes. Esteja aberto à mudanças ao invés de ignorá-las e ficar comparando com outras soluções.

TypeScript

Muita gente reclama do TypeScript, mas eu sou neutro neste item. Realmente não me incomoda. Muitas das funcionalidades que utilizamos no Angular faz parte da nova versão do EcmaScript.

Fora isso, o que o TypeScript tem de diferente mesmo é a tipagem, mas você pode muito bem continuar declarando variáveis sem declarar o tipo.

Complica o que o React facilita

Criar componentes no AngularJS era chatinho. Tinha muita coisa que não era tão simples ou intuitiva, e tentar explicar para os outros da equipe só fazia eles desejarem não chegar mais perto do front-end.

Não há como negar que criar componentes no Angular agora é mais simples, mas nem tão simples quanto no React. Há muitas reclamações contra o React e sobre o uso do JSX, mas também há reclamações do Angular por termos que importar os módulos e declararmos mais umas duas vezes no @decorator .

Tem gente que defenderia o Angular simplesmente por dizer que código no React fica feio por “misturar HTML e JS”. Não adianta dizer: “É JSX! Você pode escrever JS se quiser!” para os outros. Essas pessoas não estão abertas a testar algo novo só porque já foi considerado ruim há muitos anos.

Só digo que é pouco JSX que vai nos componentes. Se você tem muito código no seu componente, pode ser que você esteja fazendo errado, pois, praticamente você está criando uma View.

Saindo do React, outros podem acabar dizendo: O Aurelia faz o mesmo de maneira bem mais simples! Sim! Quem já testou o Aurelia vai concordar que nem parece que temos um framework lá. Escrevemos um HTML no arquivo HTML e no arquivo JavaScript criamos uma classe comum, tornando tudo muito intuitivo! Fim.

Para quem tem seguido a evolução do Angular, muitas funcionalidades têm sido simplificadas. Quem sabe esse monte de código que repetimos uma hora saia?

Não sei como defender esse ponto. Só decidi aceitar que é uma ferramenta diferente e torço para que as partes ruins sejam melhoradas o quanto antes.

Documentação ruim

Não tem desculpa. Se formos comparar a qualidade da documentação do Angular com outras, como React ou Vue.js, ela é bem complicada para quem está começando.

Quando decidi estudar Vue.js, apenas umas 2 horas lendo a documentação já foi suficiente para aprender como trabalhar com ele, discutir com minha equipe sobre as vantagens e desvantagens e porque deveríamos considerá-lo para nosso próximo projeto.

Uma das razões que me desanimavam no Angular é que no começo a documentação era nossa única fonte de estudo, quando ele ainda estava em fase alpha.

Hoje em dia isso não me incomoda mais, pois já temos muitos cursos, livros e posts sobre o assunto (esse foi fácil defender :p).

Concluindo

Bom, a ideia desse post não foi falar mal ou bem de Angular, Vue, React, Ember, Aurelia, etc. Foi mais para apontar os principais motivos de eu (e várias pessoas) evitarmos tanto ele e a razão de eu ter dado mais uma chance.

Como eu disse muitas vezes, é uma ferramenta nova com ideias novas para projetos novos. Pense bem nas suas necessidades, estude ferramentas diferentes, analise a melhor para a necessidade do seu projeto, pois não existe ferramenta perfeita que se encaixa em tudo, e mesmo se existir, um dia ficará ultrapassada.

Somos maduros e profissionais o bastante para experimentar coisas novas, e não crianças discutindo o que é melhor: Pokémon ou Digimon. Espero que este texto tenha te inspirado a refletir sobre o assunto, não só sobre Angular, mas também sobre outras ferramentas.