Por favor pare de se preocupar com o Angular 3

Tradução livre de “Please stop worrying about angular 3” by @toddmotto

Uma outra versão do Angular? O que?

O Angular 2 não acabou de chegar? Por que Angular 3?

Antes de tudo, não há nenhum re-design grande para o Angular 3. Segundo, me deixe explicar um pouco sobre o futuro do Angular 2 e o que Angular 3 e Angular 4 vão significar para você.

O Angular 3 não será um re-design como o Angular 2 foi.

De volta na história do Angular 1.x para Angular 2

O Angular 1.x e o Angular 2 são frameworks completamente diferentes, então vamos trata-los assim. Vamos começar pelo Angular 1 e logo em seguida o Angular 2.

Limitações do Angular 1.x

Resumindo, a maneira que o Angular 1.x foi desenvolvido fez com que a equipe do Google precisasse reescrever o Angular 1.x para ser compatível com o ciclo "moderno" de desenvolvimento de software, por exemplo o Angular 1.x não consegue ser:

  • Renderizado no server-side
  • Compilado para linguagem nativa
  • Renderizado em outros ambientes com a mesma qualidade

Para entender as limitações do Angular 1.x também precisamos entender a maneira que ele processa o DOM, ele praticamente se conecta ao DOM existente e dá “mais poderes” à aplicação.

O Angular 2 foi criado para acabar com essas limitações e essas mudanças de design são conceituais e complicadas, então não poderiam ser somente adicionadas ao código já existente. Assim que nasceu o Angular 2.

Angular 2

O Angular 2 foi projetado para resolver as questões citadas acima, e nelas também incluem problemas que o$scope apresenta quando tentamos alcançar os objetivos acima. A maneira que o dirty-checking foi desenvolvido usando um loop $digest deixou claro que seria preciso reescrever o framework para conseguir atingir os novos objetivos. A arquitetura do Angular 1.x não poderia ser reescrita sem grandes problemas e mudanças, pois isso iria causar problemas para futuras versões do Angular 1.x

Essa é a razão pela qual o Angular 2 foi criado. Pense no Angular 2 como um meio de desenvolvimento multiplataforma com alta escalabilidade, velocidade, desempenho. Tudo isso criado gratuitamente para a comunidade (e para eles é claro) pelo time incrível do Google.


SemVer e Breaking Changes

Angular 1.x

Se nós voltarmos até o nascimento do Angular 1.x vamos ver que estamos usando o Angular 1.x a muito tempo, ele tem várias versões e com grandes breaking changes,você pode conferir isso buscando por “breaking changes” no changelog do 1.x

Praticamente nós estamos usando um framework que tem em torno de 99 registros no changelog com breaking change, com vários outros registros reais de breaking changes sem este nome na branch do 1.x ao longo desse tempo. Sinceramente, se eu nunca realmente vi essa quebra de paradigma, tem alguma coisa errada.

Angular 2 e Angular 3

Ainda existe muita confusão sobre isso no Twitter e no Reddit. Para falar a verdade, essa thread foi o que me levou a escrever esse artigo.

O Angular 2 foi criado para mergulhar de cabeça num novo paradigma: offline apps, navite compilation e várias outras coisas que você já deve ter escutado.

O Angular 1.x precisa esperar pelo DOM para “carregar”, e se incluir na aplicação. Já o Angular 2 é totalmente diferente, ele tem o poder total no controle dos templates e consegue fazer todas as mudanças necessárias e antes mesmo delas serem alcançadas pelo DOM.

Um exemplo simples disso pode ser o evento de “click” que é ligado antes de carregar o componente ao DOM, por isso que se você inspecionar a aplicação nunca vai ver alguma coisa parecida com (click)="fooFn()". Por isso que o Angular 2, por padrão é grande.

Mais ou menos metade do código do Angular 2 parece criar um compilador interno (que você pode tirá-lo usando a compilação offline sem problemas), chamado Ahead-of-Time, para chegar ter um payload muito pequeno, que quando combinando com o módulo de lazy-load você consegue ter performance muito melhor.

Se você não compilar o AoT, está passando essa responsabilidade pra o navegador e isso vai resultar em um codebase mais pesado, então por padrão você está adotando uma compilação “Just-in-Time”. A bordagem do AoT é similar a ideia do ReactJS com JSX, tudo é pré-compilado.

Versionamento real

Antes de tudo, aqui está o Google’s versioning and release.

Agora se você está confuso imagine da seguinte maneira, no Angular 1.x era desse jeito:

  • Angular 1.0 — major version
  • Angular 1.1 — major version (preview do Angular 1.2)
  • Angular 1.2 — major version
  • Angular 1.3 — major version (sem suporte ao IE8)
  • Angular 1.4 — major version
  • Angular 1.5 — major version

No “Angular 2”, você tem isso:

  • Angular 2 — major version
  • Angular 3 — major version
  • Angular 4 — major version
  • Angular 5 — major version
  • Angular 6 — major version
  • Angular 7 — major version

Nada “físico” mudou vou ou vai mudar, essa é somente uma estratégia de versionamento diferente da usada para o Angular 1.x. O time vai sem dúvida alguma trabalhar em mudanças mais transparentes e limpas, e fazer melhores guias para atualização de codebase (se necessário) com qualquer breaking changes que venham a ocorrer.

APIs estáveis e experimentais

Se você visitar esta página, pode ver todas as APIs estáveis. Se visitar esta outra, vai conseguir ver todas as APIs experimentais. Você também pode ver flags em toda parte da documentação, por exemplo a FormGroup docs que tem a tag stable.

Google: As APIs experimentais vão seguir o SemVer (sem breaking changes fora das major releases), mas não a nossa política de depreciação. Se você usa uma API experimental fique atento as mudanças, algumas podem não seguir essa política de depreciação. Tentamos diminuir as “quebras” para os corajosos desenvolvedores da comunidade e nós vamos documentar qualquer mudança.

Desse jeito as atualizações para versões futuras será mais fácil, o Google está fazendo de tudo para garantir que a comunidade saiba quais recursos são experimentais, o que pode significar que eles não serão depreciados ou reescritos como vimos durante as versões alpha, beta e release candidates. O mais provável que a API fique estável o suficiente para a implementação.


Continua no Angular 1.x?

Se você nunca tocou em uma linha de código com Angular 2 e está trabalhando feliz com o Angular 1.x, não fique com medo de precisar aprender Angular 2 e depois Angular 3 tudo de novo como se fosse um novo framework. Angular 3 vai ser o Angular 2, mas com algumas coisas legais a mais :)

As coisas vão evoluir rápido, mas isso é uma coisa boa. Quem quer um framework que não se mantenha atualizado com as ultimas features da plataforma e que facilite a utilização dessas features?