Eu não odeio o Angular

O ano de 2016 foi bem agitado. Muitas coisas aconteceram, novas ferramentas JavaScript nasceram (normal), e dentre essas novas ferramentas tivemos duas que chamaram a atenção: o Vue.js e o Angular v2.

Não é segredo para ninguém que eu sou fã do Vue.js, porém nem todos sabem porque eu optei por ele, e não pelo Angular. Antes de diferenças técnicas, muita coisa aconteceu.

Disclaimer:
Esta é a minha opinião, as chances de você não concordar com elas são de quase 100%

Eu e o Angular.js

Antes de começar com NG (Angular.js), eu testei o Ember e o Knockout.js. Ember foi bem difícil, Knockout.js foi mais simples, mas igualmente complicado.
Quando fiz a primeira demo com o Angular, foi incrível, simplesmente funcionava.

Hoje eu olho para essa época e percebo o que aconteceu. Não era o Ember ou o Knockout.js que eram complicados. Eu que não sabia nada de JavaScript.

O velho e recorrente erro de quem só “sabe” jQuery: Achar que sabe JavaScript

E por mais incrível que pareça, consegui me virar com o Angular, fiz vários projetos. Porém quanto mais complexo o projeto ficava, nem que fosse um pouquinho, a parada começava a desandar.

Eu e o JavaScript

Com o tempo eu me senti meio merda, achando que o problema era comigo. Decidi parar, e voltar as raízes, comecei a estudar JavaScript.

Foi fantástico, aprendi muito e comecei a ver o JavaScript como a linguagem incrível que ele é. Quando voltei meus olhos ao Angular muita coisa passou a fazer sentido, o problema não era só meu.

Não vou ficar listando os problemas que o Angular.js possuía, isso é chover no molhado, estamos caminhando para 2017 e isso é insignificante.

Eu e o Vue.js

No final de 2015, o Laracasts e o Fábio Vedovelli começaram a falar sobre Vue.js. Eu assim como a maioria das pessoas, não dei importância. De início você acha que o Vue.js é um Angular.js simplificado. Em janeiro de 2016 eu testei o Vue.js em um projeto do trabalho, algo rápido, que deveria ser feito em pouco mais de uma semana.

A simplicidade dele me conquistou de cara, já me imaginei usando ele em projetos mais simples. Porém, quanto mais eu utilizava, mais claro se tornava a ideia de que ele era bem mais do que eu imaginava.

Nesse período, eu já estava com um péssimo relacionamento com Angular, e relutante em usar React (JSX me parecia nojento). Quando vi a proposta para Single File Components do Vue.js fiquei assustado, imaginei o problema que seria ter HTML, JS e CSS em um único arquivo, mas decidi testar.

Nesse mesmo período conheci o vue-router, e me decidi: Vue.js seria a minha nova ferramenta, não o React, e não o Angular 2.

Eu e novos desafios

Em meados de fevereiro mudei de emprego, passei a trabalhar na Decision6. Lá, eu assumi um projeto feito em Angular 1.5 com previsão de migrar para Angular 2.

Foi uma fase complicada, afinal, eu voltei a usar Angular. O produto que eu estava mantendo sofria com o Angular, todos os defeitos conhecidos dele se voltavam contra mim, eu estava fazendo 70% do sistema em JavaScript puro para contornar esses problemas.

Betas e testes

Durante todo esse processo, o Angular 2 estava tendo seus betas lançados, então eu fui lá fazer meu dever de casa. Estudei sua doc, precária, mas não tinha muito o que exigir de algo em beta/alpha.

Voltei a estudar TypeScript (conhecia ele antes do NG2). Meu chefe também começou a ver mais sobre o NG2, porém, segundo ele “Angular 2 está mais complicado que Java”.

Mesmo assim, decidi apostar um pouco mais, e comecei um projeto mobile com NativeScript. Tentei duas vezes, uma com o NativeScript puro e outra com Angular + TS. Ambas foram um fiasco…. Voltei ao Ionic + Angular.js, mesmo com seus problemas, supriu a necessidade.

Eu + Angular + Vue.js

No meio do ano migrei a versão do Angular.js para 1.6 e minha empolgação com o modelo de componentes dele durou pouco… Tive também uma demanda nova no projeto, uma demanda bem complexa, coisa que eu choraria sangue para fazer no Angular.js. Então, fiz essa parte com Vue.js, e foi muito bem obrigado.

Mesmo com o workflow prejudicado por estar fazendo as coisas dentro do Angular, foi bem mais produtivo do que fazer com Angular.js.

Nesse momento, já havíamos desistido do NG2 como opção para a nova versão da plataforma. Eu acompanhava de perto commits e PRs no projeto do Angular 2, gosto de ver como o código-fonte das ferramentas que uso ou pretendo usar caminha, e não estava contente com o que eu via.

Finalmente: Angular 2 => Angular

No meio disso tudo e algumas quebras de compatibilidade entre as versões RC do Angular, saiu oficialmente o Angular, nada de Angular 2, apenas Angular.

E, finalmente, pude ter uma visão macro de toda a ferramenta… Até então eu estava confiante sobre essa versão, aparentemente a filosofia da ferramenta tinha mudado para melhor.

Quem me conhece sabe que sou bastante ativo nas comunidades que participo, e vejo muitas pessoas com as mais diversas dúvidas. Em vários momentos, pego opiniões sobre os mais diversos assuntos. E não poderia ser diferente com o Angular.

Ficou claro para mim que a grande maioria dos usuários de Angular.js não sabe JavaScript, focam tanto na ferramenta que esquecem do que ela é feita. Outros muitos são completamente dependentes de pacotes de terceiros. Vejo o mesmo comportamento entre devs que só sabem usar jQuery com plugins.

Já li e ouvi várias vezes: Não tem um pacote que já faça isso?

Claro que existem exceções, porém é essa a realidade. Quanto mais popular e “fácil” é uma ferramenta, mais pessoas sem conhecimento técnico adequado vão começar a usar-la. Nenhuma ferramenta está imune a isso, nem o Vue.js.

No meu ponto de vista, Angular está com crise de identidade. Talvez, na tentativa de remover a má percepção sobre sua qualidade técnica, o Team Angular tenha perdido a mão.

Ficou difícil definir em que tipo de projeto o Angular se encaixa, afinal, ele agora possui “cara de enterprise”, cheio de passos para conseguir iniciar algo simples.

Vue/React X Angular

Façamos uma comparação objetiva: Vue.js e React são libs. Libs muito pequenas e especializadas. Um projeto de “grande porte” com eles exige uma combinação de outras Libs.

• Core [React /Vue.js]
• Router [react-router / vue-router]
• Store [redux + thunk / vuex]
• Http Client [axios]

Um projeto teria no mínimo 3~4 libs. Isso em si não é um problema, o problema é: qual a melhor disposição dessas libs?

A arquitetura passou a ser algo problemático para devs com pouca experiência. O Angular promete resolver isso, sendo mais opinativo. Porém sabemos que esse opinativo não resolve tanta coisa na hora do vamos-ver…

Angular.js possuía a mesma pegada, e mesmo assim um documento de guia foi feito para ajudar a padronizar determinadas situações. Pode-se dizer que o Angular leva vantagem pois incorporou isso em sua documentação oficial.

Com base nisso podemos afirmar que um monolítico como o Angular não tem tanta diferença se comparado a libs como React e Vue.js

Monolítico? Não tanto…

"dependencies": {
    "@angular/common": "2.2.3",
    "@angular/compiler": "2.2.3",
    "@angular/core": "2.2.3",
    "@angular/forms": "2.2.3",
    "@angular/http": "2.2.3",
    "@angular/platform-browser": "2.2.3",
    "@angular/platform-browser-dynamic": "2.2.3",
    "@angular/router": "3.2.3",
    "core-js": "^2.4.1",
    "rxjs": "5.0.0-beta.12",
    "ts-helpers": "^1.1.1",
    "zone.js": "^0.6.23"
  },

Estas são as dependências que vão para produção em um projeto iniciado com angular-cli (não vou me aprofundar nele, talvez em outro artigo)

Angular usa monorepo para facilitar a manutenção dos pacotes oficiais, porém eles são distribuídos separadamente. Fica evidente que não é uma situação tão diferente do React ou do Vue.js, ambas tem ferramentas de CLI para criar projetos e deixar de lado a parte “chata” de configuração.

No final paira a dúvida: Qual o perfil de projeto para o Angular?

Perfil

React e Vue.js podem ser utilizados em qualquer demanda, seja simples, complexa, grande, gigante, pet-project… Você vai conseguir encaixar e ter bons resultados em qualquer projeto.

Tudo isso é possível com o Angular? Provavelmente é, porém estamos falando de 12 dependências em produção no gerador (CLI) padrão. Em teoria só há 2 pacotes desnecessários ali: forms e router, que não vêm no CLI do Vue.js e React. Não vou entrar no tamanho do build…

Isso tudo me deixa confuso, qual o objetivo do Angular? Quer ser Enterprise? Ótimo, que seja… Porém dê o papo-reto pra comunidade.

O perfil dos devs e empresas que usam Angular é bem diversificado. Uma coisa que muitas pessoas não se dão conta é que a quantidade de devs em agências ou software-houses de pequeno/médio porte é bem maior do que nas grandes empresas de softwares.

Ou seja há mais micro-empresas do que empresas grandes. Esse não é um perfil enterprise, é um perfil ágil. Eles querem coisas prontas, de fácil acesso e manutenção. Se já há grande resistência no uso de ferramentas como webpack nessas empresas, não vejo elas prontas para a proposta do Angular, seja ela qual for.

Há rumores de que ele deseja se tornar uma plataforma, porém mesmo isso ainda é algo incerto.

Incertezas

Essas incertezas, decisões de design e workflow me afastam completamente do Angular. Optar por não usar ferramentas que são consideradas padrão por vários devs JavaScript…

Sem contar com o TypeScript. Não importa o que muitos digam, é virtualmente impossível usar Angular e não usar TS.

TS não é um monstro nem algo ruim, porém já comecei a ver devs cometendo erros bobos por se esquecem que TS vai virar JavaScript e nenhuma daquelas validações vai funcionar em runtime. Isso não é culpa do NG, mas é algo que a comunidade dele poderia disseminar melhor, muitos softwares de baixa qualidade vão ser gerados devido a isso.

Eu não odeio o Angular, ele possui um legado muito forte, até mesmo sua versão 1 vai se manter viva por muito tempo. Existe toda uma mítica de empresas que optam por ferramentas devido aos nomes por trás delas. Google possui um nome de extremo peso, porém ninguém quer lembrar dos vários erros e fiascos que o Google cometeu ao longo de sua história.

Não é por que um time de engenheiros da Google cria uma ferramenta que supre as demandas deles que esta ferramenta também vai servir para outras empresas, ou que vá servir para outros desenvolvedores…

Agradecimentos ao Igor Santos pela ajuda na revisão :)

Se quiser saber mais sobre meu trabalho visite codecasts.com.br. Lá você vai ver vídeos sobre Javascript, jQuery, Gulp, ES6, Vue.JS, Docker e muito mais.

that’s all folks