Um Roteiro Angular – O Passado, Presente e Futuro do Angular

Atualizações Angulares: O que há de novo na versão 11

A de Novembro de 2020, a versão angular 11.0.0 está agora disponível. Enquanto esta versão traz muitas atualizações para a plataforma, as características mais significativas incluem construções mais rápidas com TypeScript 4.0, arneses de teste de componentes e atualizações ESLint.

Paleolítico JavaScript – SproutCore

No início, havia o SproutCore. Foi a primeira estrutura JavaScript abrangente destinada a facilitar a construção de aplicações web de uma página com qualidade de desktop. Não é que isso não fosse possível antes. Quando o Google lançou o Gmail, ele mostrou ao mundo que aplicativos web realmente poderiam substituir aplicativos desktop complexos. O Google até abriu o Closure toolkit – um conjunto de bibliotecas e um compilador de optimização que utilizou para construir o Gmail.

O problema era que as ferramentas Closure do Google não eram muito amigáveis ao desenvolvedor. Elas dependiam muito de Java, o que alienou os desenvolvedores web que estavam acostumados a trabalhar com JavaScript, PHP, Ruby, e Python. O Gmail foi uma grande demonstração do que era possível, mas desenvolver aplicações similares ainda se sentia fora do alcance de muitos.

Alguns corajosos desenvolvedores conseguiram juntar incríveis aplicações de página única usando uma combinação de jQuery, fita adesiva, e esperança. Enquanto esses aplicativos pareciam incríveis para os usuários finais, para os desenvolvedores que trabalhavam neles, os aplicativos rapidamente se transformaram em pilhas de dívidas técnicas que fizeram a equipe de desenvolvimento ter medo de ir trabalhar pela manhã.

Como resultado, alguns desenvolvedores empreendedores começaram a trabalhar em frameworks que colocariam aplicativos parecidos com o Gmail ao alcance dos desenvolvedores web em todos os lugares. O SproutCore foi o primeiro desses frameworks a decolar. Ele veio com um conjunto completo de widgets que tornou possível construir aplicações web complexas sem sequer tocar em HTML ou CSS.

Isso acabou sendo ótimo para ex-desenvolvedores de desktop que tinham sido arrastados para a web. Vários outros frameworks apareceram com objetivos similares; GWT e Cappuccino foram os mais proeminentes. Estes frameworks até evitaram o JavaScript, transpondo outras linguagens para o JS. Mais uma vez, isso foi ótimo para desenvolvedores de desktop. Mas deixou desenvolvedores web apaixonados no frio e os fez sentir como se suas habilidades de HTML, CSS e JavaScript não fossem valiosas.

Isso deixou uma abertura para um framework que realmente abraçou a web, ao invés de tentar gessar sobre ela e fingir que era algo mais. Um par de frameworks iniciais (Backbone e Knockout) apareceram, e alcançaram uma quantidade moderada de sucesso. Ember também apareceu por esta altura. Pegou no SproutCore, despojou-o até aos ossos e tentou reconstruí-lo em algo verdadeiramente amigo da web. Ember queria ser o Six Million Dollar Man do mundo JavaScript: reconstruído melhor, mais forte, e mais rápido.

Nenhum destes quadros se tornou popular. O mundo estava à espera de algo melhor. Em 2010, que algo melhor aparecesse – chamava-se Angular.

The Golden Age of Angular

Antes do lançamento da versão 1.0 do Angular, Angular tomou de assalto o mundo do desenvolvimento de vanguarda. Finalmente, tínhamos um framework JavaScript fácil de usar que tratava o HTML como um cidadão de primeira classe. Desenvolvedores e designers podiam agora trabalhar juntos para construir incríveis aplicações de página única. Isto veio como um alívio para os designers, que tinham sido incomodados e ofendidos porque frameworks mais antigos tinham tratado o HTML e CSS como ferramentas para bárbaros, ferramentas que nenhum desenvolvedor civilizado deveria ter que tocar.

A primeira coisa que parecia mágica para os desenvolvedores tentando Angular pela primeira vez foi o binding de dados bidirecional. Antes disso, a maioria dos desenvolvedores só tinha visto esse tipo de vinculação de dados em frameworks desktop como WPF e Windows Forms. Era ótimo ser capaz de vincular formulários e outros elementos de UI a objetos de modelo JavaScript. Embora a vinculação de dados bidirecional pudesse causar problemas de desempenho quando usada em excesso, as equipes que a usavam judiciosamente descobriram que a Angular lhes permitia criar aplicações front-end complexas muito mais rapidamente do que nunca.

Angular provou ser popular para mais do que apenas a ligação fácil de dados a elementos HTML. As diretivas Angular forneceram uma maneira fácil de criar componentes HTML + CSS reutilizáveis. Embora outros frameworks JavaScript fornecessem isso antes da Angular, Angular foi o primeiro que se tornou extremamente popular. Os componentes reutilizáveis já estavam em uso há muito tempo nos frameworks do lado do servidor. Controles de usuário ASP.NET e templates parciais em Rails e Django são apenas alguns
exemplos.

Finalmente, Angular tornou a injeção de dependência popular no mundo de desenvolvimento front-end. A injeção de dependência há muito tempo era popular em aplicações empresariais, e talvez seja por isso que ela não tinha pegado no mundo JavaScript. Os desenvolvedores front-end têm sido avessos há muito tempo ao que eles vêem como padrões de design de software empresarial desnecessariamente complexos. Esta preocupação não é sem mérito. Você já disse a si mesmo, no decorrer da escrita de uma aplicação, “O que eu realmente preciso aqui é de uma “SimpleBeanFactoryAwareAspectInstanceFactory?”

Injeção de dependência, no entanto, já provou o seu valor. E Angular fez a injeção de dependência fácil de usar para um público que não a tinha usado muito no passado. Precisa de um cliente HTTP? Ou talvez você gostaria de fazer alguma animação? Sem problemas. A Angular tinha serviços embutidos para eles. Basta pedir por eles, e a Angular os injetaria em seus componentes. Não precisa instanciar nada você mesmo.

ou talvez você quisesse usar os objetos do navegador window ou location sem tornar impossível testar seus componentes fora de um navegador? Angular também o tinha coberto lá, com os seus serviços de $window e $location embutidos. Em tempo de execução, você obteria os objetos do navegador que estava esperando. E ao executar os testes unitários do lado do servidor no Node.js, você poderia passar serviços simulados em seus componentes para garantir que eles se comportassem como esperado em vários cenários.

Se tudo isso não fosse suficiente, Angular também tornou simples registrar e injetar seus próprios serviços. Para os desenvolvedores que estavam acostumados a ligar todos os seus dados ao DOM e esperando pelo melhor, isto foi fantástico. Se você estava escrevendo um novo aplicativo front-end que pedia APIs que custariam muito dinheiro à sua empresa se fossem usadas em excesso, você provavelmente preferiria ser capaz de escrever testes antes do tempo para garantir que sua aplicação não tente fazer algo como chamar a API do Twilio 800 milhões de vezes.

Então você criaria um serviço Twilio que é injetado em tempo de execução. Em tempo de teste, você criaria um serviço de simulação que registra o custo de cada chamada de API que sua aplicação está tentando fazer. Você escreveria testes que cobrem cenários comuns de uso e asseguraria que esses cenários não resultem em sua empresa receber uma conta de 7 dígitos. Em geral, a maioria dos desenvolvedores descobriu que as diretrizes angulares combinadas com a injeção de dependência tornaram possível escrever aplicações front-end modulares e testáveis usando técnicas de engenharia de software testadas e confiáveis. Muitas equipes de desenvolvimento decidiram que isso resultou em um feliz estado de coisas, e decidiram fazer all-in em Angular.

O Declínio Angular? The Rise of React

Embora as coisas tenham sido, na sua maioria, fantásticas no mundo do Angular, não foi só sol e chupa-chupas. Os desenvolvedores estavam começando a ter sérios problemas de desempenho quando tentaram prender muitos objetos modelo a muitos elementos DOM. Algumas aplicações abrandaram para um rastejamento. Chamadas diretas para $digest e outras feitiçarias de magia negra começaram a se tornar necessárias para atingir um desempenho aceitável. Na mesma época, um novo desafiador apareceu: Reagir. No início, Reagir não parecia representar um perigo muito grande para a Angular. Afinal, estes estranhos do React tinham tido o trabalho de inventar o JSX, o que se parecia muito com uma forma de misturar as marcas no seu código. Não tínhamos tido muito trabalho para inventar templates de idiomas por uma razão explícita de evitar misturar marcação e código?

Como se viu, a abordagem do React foi bastante popular na comunidade de desenvolvimento front-end. No entanto, não foi muito popular. O Angular ainda era dominante, e parecia que continuaria assim. Até lá, a popularidade do Angular foi dada um bom chute nos dentes de uma fonte inesperada: a própria equipe Angular.

A Introdução do Angular 2

Angular 2 foi anunciada pela primeira vez na conferência ng-europe em 2014. Os planos da equipe Angular vieram como um choque para a comunidade Angular, para dizer o mínimo. A reação dos desenvolvedores Angulares foi rápida e negativa… e não sem razão. O Angular 2 estaria se livrando de muitos conceitos familiares do Angular 1, introduzindo uma linguagem nova e incompatível (e oh, a propósito) também seria programado usando uma linguagem totalmente nova.

AngularJS

Embora ambos Angular 1 e Angular 2 fossem chamados de ‘Angular’, na realidade, eram frameworks muito diferentes com algumas coisas em comum. Para ajudar a evitar confusão, a equipa Angular começou a referir-se à versão antiga do Angular como ‘AngularJS’, e a nova versão como simplesmente ‘Angular’. Isto faz sentido intuitivamente, uma vez que AngularJS foi escrito em JavaScript, e Angular não foi. Para manter a distinção entre os frameworks claros, vou me referir ao Angular 1 como AngularJS a partir deste ponto.

Como resultado de tudo isso, os desenvolvedores do AngularJS perderam a fé no futuro do framework. Eles ameaçaram passar para um novo framework em projetos futuros, e foi exatamente isso que muitos deles fizeram. Reagir foi o maior beneficiário do êxodo em massa da AngularJS.

Embora a React não tenha feito tanto quanto a AngularJS, de uma forma que foi positiva. Se você está usando uma biblioteca de visualização que não tenta incluir tudo mais a pia da cozinha, é muito mais difícil para os desenvolvedores dessa biblioteca tirarem o tapete de baixo de você no futuro. No início, usar React foi um pouco doloroso em comparação com AngularJS. Tiveste de juntar um patchwork de bibliotecas só para cobrir a funcionalidade que o AngularJS fornecia fora da caixa.

Muitas equipas viram isto como uma boa forma de reduzir o risco, porque era improvável que os programadores de todas essas bibliotecas decidissem fazer alterações de quebra incompatíveis ao mesmo tempo, que é essencialmente o que a Angular tinha feito.

A Emergência da Vue

Para compor os males do AngularJS, outra estrutura chamada Vue apareceu mais ou menos na mesma altura em que o drama sobre o Angular 2 estava a ocorrer. Vue foi inspirado pelo AngularJS mas tinha como objectivo simplificá-lo e livrar-se do que o criador de Vue via como complexidade desnecessária (por isso Vue sentia-se muito familiarizado com os criadores do AngularJS já existentes). A Vue forneceu um porto seguro para muitos desenvolvedores do AngularJS que não queriam se mudar para o React.

Isto não significa que os programadores do AngularJS não esperassem pacientemente pelo Angular 2 aparecer. Mas é claro que houve um êxodo em massa do AngularJS para o React e Vue devido à incerteza causada pelos planos para o Angular 2.

Rising From the Ashes with Angular 2

Eventualmente, o Angular 2 foi lançado. Como esperado, eliminou muitos conceitos familiares da AngularJS mas manteve algumas das melhores peças como serviços e injeção de dependência. Felizmente para a sanidade dos desenvolvedores, Angular usa o TypeScript simples e não um garfo, como planejado originalmente.

Para tornar as coisas mais confusas, a equipe da Angular manteve um garfo do novo framework que usava a linguagem de programação Dart em vez do TypeScript. Inicialmente, as versões TypeScript e Dart foram desenvolvidas em sincronia, geradas a partir de uma única base de código. Eventualmente, as versões TS e Dart da Angular decidiram seguir caminhos separados, e Angular Dart agora existe por conta própria.

Even com esta confusão, a popularidade da Angular começou a aumentar novamente após o lançamento do Angular 2. Aconteceu lentamente. Como muitas vezes ocorre no desenvolvimento de software, as tendências mudaram. Os desenvolvedores perceberam que um framework grande, com baterias incluídas, poderia realmente ser útil. Afinal, quando a sua aplicação cresce o suficiente, você acaba realmente precisando de todas essas baterias.

Enterprise developers, em particular, começaram a voltar para Angular. Isto faz sentido. Normalmente, quando você inicia uma aplicação web corporativa, você sabe que ela vai ser complexa. Não faz sentido começar com um pequeno MVP quando você sabe desde o início todas as 87 coisas que se espera que a sua aplicação faça.

Onde o Angular 3?

Embora o Angular 2 não fosse perfeito, muitos desenvolvedores de aplicações web complexas começaram a perceber que o novo e melhorado Angular era um bom ajuste para as suas necessidades. Felizmente para eles, Angular tinha algumas melhorias excitantes em vista. Mais importante, a equipe Angular demonstrou que podia publicar consistentemente novas versões do framework com poucas mudanças entre as versões

Em um movimento que parecia estranho na época, a equipe Angular decidiu pular a versão 3 completamente e passar para a versão 4. Isto foi feito por uma boa razão: a equipa que trabalhava no pacote de router da Angular já tinha avançado e lançado a versão 3, enquanto o resto da Angular ainda estava na versão 2.3. Eles decidiram manter todas as versões do pacote Angular em sincronia, e passar tudo para a versão 4 para o próximo lançamento foi a maneira mais fácil de conseguir isso.

Angular 4

Angular 4 teve algumas mudanças significativas, incluindo a compilação antes do tempo, o que resultou em pequenos pacotes JavaScript de produção e menor tempo de carga de aplicações. Foi adicionado suporte à renderização do lado do servidor, o que foi um impulso para as equipes que queriam renderizar sua aplicação antes do tempo para melhorar o desempenho da carga inicial. Muitas outras melhorias foram adicionadas em todo o framework, mas atualizar aplicativos do Angular 2 para o 4 foi rápido e indolor na maioria dos casos.

Angular 4.3 e Angular 5

Angular 4.3 adicionou um novo cliente HTTP que era mais fácil de usar do que o antigo serviço HTTP. No Angular 5, o antigo serviço HTTP foi depreciado e seria descartado na próxima versão. Apesar deste inconveniente, houve relativamente pouco resmungo porque a atualização na maioria dos casos foi direta. O Angular 5 também adicionou melhor suporte à internacionalização e mais otimizações de compilação.

Angular 6 e 7

Angular 6 e 7 foram decepcionantes para alguns desenvolvedores. Não houve grandes mudanças, mas houve muitas pequenas melhorias na qualidade de vida, especialmente nas ferramentas da CLI Angular. O número decrescente de mudanças visíveis não é uma indicação de que a equipe da Angular tenha parado de inovar. Em vez disso, ele mostra que a estrutura está madura, então a equipe de desenvolvimento está agora livre para fazer mais trabalho nos bastidores, corrigindo bugs e melhorando o desempenho.

A estabilidade do framework desde o lançamento do Angular 2 atraiu alguns desenvolvedores da velha escola AngularJS de volta ao mundo Angular. Também tem atraído a atenção das equipas de desenvolvimento empresarial. Quando você está construindo aplicativos empresariais que podem viver por décadas, é ideal usar um framework que receba novos lançamentos em um cronograma previsível, mas que não mude muito rapidamente. Um desenvolvedor que só tivesse usado Angular 2 poderia estar funcionando e contribuindo para um aplicativo Angular 7 em questão de minutos.

Angular 8 e Angular Ivy

E isso nos traz até hoje. Como já vimos, o Angular percorreu um longo caminho. Ele passou de amado por desenvolvedores web para ser injuriado a ser admirado, embora ainda não seja amado novamente como era em seus primeiros dias.

No horizonte, temos o Angular 8. Uma tonelada de trabalho foi feita no Angular 8 para torná-lo fácil de usar com o sistema de construção Bazel, o que é absolutamente incrível para todos os 3 desenvolvedores que o estão usando fora do Google. Leia sobre as mudanças do Angular 8.

Mais excitante, porém, a equipe do Angular está trabalhando duro em uma nova renderização chamada Angular Ivy. Pretende-se que seja um substituto para a renderização atual. Na maioria das vezes, os aplicativos atuais não precisarão fazer nenhuma alteração para usar Angular Ivy.

Se Angular Ivy é um substituto drop-in, por que os desenvolvedores devem se importar? Duas razões importantes: velocidade, e o tamanho do pacote – duas preocupações muito importantes. Por alguns anos, parecia que os desenvolvedores da web tinham ficado um pouco loucos. As equipes estavam enviando pacotes JavaScript de 5MB, 10MB, ou até maiores, e pensando que não havia nenhum problema com isso. Afinal de contas, as aplicações funcionavam perfeitamente no MacBook Pros dos desenvolvedores i7, então elas deveriam funcionar bem para todos, certo?

Felizmente, no mundo real, nem todos estão rodando o melhor e mais recente hardware. Centenas de milhões de pessoas acessam a internet apenas em telefones Android mais antigos com um pouco mais de poder de processamento do que uma batata, através de conexões de internet apenas um pouco mais rápidas do que o dial-up. Para esses usuários, um enorme pacote de JavaScript leva uma eternidade para carregar, e ainda mais tempo para que seu dispositivo seja analisado e executado. Mesmo em casos menos extremos, há inúmeros usuários ao redor do mundo que não estão usando o melhor e mais recente hardware. Para eles, aplicativos JavaScript massivos são utilizáveis (mas dolorosos).

Angular Ivy

O renderizador Angular Ivy ajudará de várias maneiras:

1. Está sendo escrito com um olho na eficiência, então ele realizará as mesmas tarefas enquanto executa muito menos instruções de CPU. Isto irá melhorar tanto a duração da bateria como a sanidade dos utilizadores com dispositivos menos potentes.
2. O renderizador será escrito de uma forma muito mais modular do que o renderizador atual. Isto fará com que seja muito mais fácil de agitar as árvores e eliminar o código morto. Como resultado, seu pacote JavaScript de produção incluirá apenas o código que é necessário para executar sua aplicação, em vez de juntar tudo mais a pia da cozinha como acontece com a renderização atual.
3. Além da redução do tamanho do pacote e da velocidade de renderização melhorada, Angular Ivy tem outras melhorias de qualidade de vida para desenvolvedores Angular. Os tempos de reconstrução são significativamente mais rápidos. Então se você estiver rodando sua aplicação no modo de desenvolvimento e esperando suas mudanças aparecerem, você agora vai gastar muito menos tempo de espera.
4. A verificação do tipo templates está melhorada, o que significa que você vai pegar mais erros em tempo de compilação ao invés de em tempo de execução. Bugs de template em tempo de execução são irritantes, porque ou eles mordem você durante o teste, ou mordem seus usuários quando eles estão tentando usar sua aplicação.
5. O compilador de templates Angular Ivy irá gerar código que é legível por humanos, o que o compilador View Engine actual não faz. Isto será útil ao tentar localizar bugs de template difíceis.

O resultado líquido: aplicações menores, aplicações mais rápidas, desenvolvedores mais felizes, e usuários mais felizes.

Angular 9

Aqui está uma visão geral do Angular 9.

Os principais destaques incluem:

• Built-in Angular Features
• Mature Development with Angular
• Understanding Angular View Engines
• Angular Ivy Solves Long-Standing Problems
• Angular Ivy and Mobile
• Selector-menos diretivas
• Aprimoramentos em Diagnóstico Angular
• Internacionalização com Hera Angular
• DI e Type-Safe em Angular 9
• Alterações de Injeção em Núcleo Angular
• Benchmarks Angulares (Angular 8.2.7 vs. 9.0.0-próximo.5)

Angular 10

A Versão Angular 10.0.0 foi lançada no final de junho de 2020. Um grande lançamento, Angular 10 inclui mudanças como um novo seletor de intervalo de datas em Material Angular, atualização de versões TypeScript, atualizações de versão de biblioteca e muito mais.

Novos recursos incluem:

• Interface do Compilador Ngtsc
• Configurar Timeouts Async
• Relato de Arquivo de Bloqueio de Escala
• Computação Preguiçosa de Percursos Base
• Fusão de Ficheiros de Tradução
• Mapa Explícita

Angular 11

Versão Angular 11.0.0 foi lançado em novembro de 2020. A versão principal do Angular 11 fornece atualizações em toda a plataforma, incluindo o CLI e a estrutura de componentes.

As características significativas incluem:

• Faster Builds with TypeScript 4.0

>

• Atenções de teste de componentes

>

• Actualizações de tinta

>

• Pré-visualização actualizada do serviço de idiomas

>

• Suporte de substituição do módulo quente (HMR)

>

• Relatórios e registos melhorados

>

• Inibição automática da fonte

>

>

Angular passado, Presente, e Futuro

Se você tem usado Angular desde os seus primeiros dias até agora, então parabéns! Embora tenha havido muitos remendos, acabamos com uma estrutura rápida e moderna que é divertida de usar.

Se você era um desenvolvedor AngularJS mas passou para React, Vue, ou outra coisa, eu o encorajo a dar outra olhada ao Angular. Vale a pena o seu tempo, mesmo que você decida ficar com o que está usando agora.

E se você nunca usou Angular, por que não tentar?

Acabámos de fazer um turbilhão pelo passado, presente e futuro do Angular. Sem dúvida, tem sido uma viagem e tanto. Independentemente do seu passado Angular, espero que tenha gostado da excursão!

Com que estrutura você trabalha e por quê? Se você tiver perguntas ou comentários, não deixe de inseri-los abaixo.

Procura de componentes de IU asfixiantes? GrapeCity tem um conjunto completo de componentes JavaScript UI, incluindo grelhas de dados, gráficos, medidores e controlos de entrada. Também oferecemos poderosos componentes de planilhas eletrônicas, controles de relatórios e visualizações de apresentação melhoradas. Temos suporte profundo para Angular (assim como React e Vue) e estamos dedicados a estender nossos componentes para uso em frameworks JavaScript modernos.