Passei quase três anos a escrever Angular no BNP Paribas. Angular 9, para ser preciso, cheio de services, pipes RxJS, módulos e uma opinião muito clara sobre como se deve estruturar uma aplicação. Depois mudei de cargo internamente, e a nova stack era React com TypeScript.
As pessoas adoram comparar os dois online como se fosse uma guerra santa. Na prática, a mudança foi menos dramática do que a internet faz parecer, mas houve algumas coisas que genuinamente me apanharam de surpresa.
O Choque da Gestão de Estado
Este foi o grande.
Em Angular, a gestão de estado parecia natural. Criava-se um service, injetava-se onde fosse necessário e usavam-se BehaviorSubjects ou outros primitivos do RxJS para gerir e partilhar estado entre componentes. Os dados fluíam através de observables, e a framework dava-te um modelo mental claro de onde o estado vivia e como se movia.
// Angular: um service gere o estado, os componentes subscrevem
@Injectable({ providedIn: 'root' })
export class DocumentService {
private documents$ = new BehaviorSubject<Document[]>([]);
getDocuments(): Observable<Document[]> {
return this.documents$.asObservable();
}
}Depois abri uma codebase React e encontrei useState, useEffect, useContext, useReducer, useMemo, useCallback, e isto era só o que vinha incluído. Por cima disto, havia todo um debate sobre usar Redux, Zustand, Jotai, ou apenas React Context.
Em Angular, a framework fazia a escolha por ti. Em React, fazes tu todas as escolhas. Isso é simultaneamente o ponto forte e o problema.
Fui totalmente para hooks. Sem RxJS, sem observables. De uma vez. Não foi porque hooks são melhores ou piores, mas porque tentar misturar paradigmas parecia estar a lutar contra a framework. O React quer que penses em termos de estado do componente e efeitos, não em termos de streams. Assim que aceitei isso, as coisas encaixaram.
O Que Realmente Prefiro no React
Aqui está o que não esperava: gosto da simplicidade do React.
Os componentes Angular vêm com um ficheiro TypeScript, um template HTML, um ficheiro CSS e um ficheiro spec. Tens decorators, lifecycle hooks com nomes específicos (ngOnInit, ngOnDestroy, ngAfterViewInit), e um sistema de módulos que liga tudo. Há muita cerimónia antes de conseguires pôr algo no ecrã.
Os componentes React são apenas funções. Recebem props, retornam JSX, e é isso. Precisas de estado? Chama useState. Precisas de um side effect? Chama useEffect. Queres partilhar lógica? Escreve um custom hook. Não há hierarquia de classes, não há decorators, não há declarações de módulos.
// React: é apenas uma função
function DocumentList({ teamId }: { teamId: string }) {
const [documents, setDocuments] = useState<Document[]>([]);
useEffect(() => {
fetchDocuments(teamId).then(setDocuments);
}, [teamId]);
return (
<ul>
{documents.map(doc => <li key={doc.id}>{doc.name}</li>)}
</ul>
);
}Isto é sempre melhor? Não. Para aplicações enterprise grandes com equipas grandes, as opiniões do Angular previnem muitos debates de "como é que devemos estruturar isto?". Mas para mover rápido e manter as coisas lean, o React sai-te da frente de uma forma que o Angular nunca fez.
A Vantagem do Ecossistema É Real
Em Angular, se precisavas de chamadas HTTP, usavas HttpClient. Formulários? ReactiveFormsModule. Routing? @angular/router. Testes? TestBed do Angular. Está tudo incluído, tudo funciona junto, e a documentação cobre tudo.
Em React, escolhes tudo. HTTP? Talvez fetch, talvez axios. Formulários? React Hook Form, Formik, ou fazes o teu próprio. Routing? React Router. Considerei Next.js mas queríamos um frontend puro já que a lógica do backend precisava de ser Python por causa do seu ecossistema de libraries de AI.
Ao início, isto parecia avassalador. Mas assim que defines a tua stack, o ecossistema React é genuinamente massivo. O que quer que precises, alguém já construiu, documentou, e há quinze blog posts sobre isso. Precisas de animar algo? Framer Motion. Precisas de uma component library headless? Radix.
O ecossistema Angular também existe, mas é mais pequeno. Algumas libraries parecem abandonadas. A comunidade gravita para o React, e isso nota-se na qualidade e variedade do que está disponível.
O Que Realmente Sinto Falta
Módulos e Lazy Loading
Esta é a coisa que acho que o Angular tratou de forma mais limpa. O sistema de módulos do Angular permitia agrupar componentes, services e rotas relacionados e fazer lazy-load de feature modules inteiros sem esforço:
// Angular: lazy load de uma feature inteira
const routes: Routes = [
{
path: 'documents',
loadChildren: () =>
import('./documents/documents.module')
.then(m => m.DocumentsModule)
}
];A fronteira era clara. Tudo dentro daquele módulo era autónomo, e o router tratava do code splitting automaticamente.
Em React, podes absolutamente fazer code splitting com React.lazy e Suspense. Mas a fronteira organizacional não é tão limpa. Não há equivalente de "este módulo encapsula estes componentes, estes services e estas rotas." Tens de criar essa estrutura tu próprio através de convenções de pastas, e nem toda a gente na equipa vai concordar sobre como isso deve ser.
Coisas Que Não Importam Tanto Quanto as Pessoas Pensam
Suporte TypeScript. Ambos são excelentes com TypeScript. O Angular foi construído para isso, o React apanhou completamente. Isto já não é um diferenciador.
Performance. Para o tipo de ferramentas internas e plataformas que construo, nenhuma framework foi alguma vez o bottleneck. A query à base de dados ou a chamada API é sempre a parte lenta, nunca o rendering.
Curva de aprendizagem. O Angular tem uma curva inicial mais íngreme porque há mais para aprender à partida. O React tem um tipo diferente de curva. É fácil começar, mas vais passar semanas a descobrir os padrões e libraries certos para o teu caso de uso específico. Escolhe o teu veneno.
O Que Diria a Alguém a Fazer a Mudança
Não tentes escrever Angular em React. Vejo pessoas a criar classes "service" em React, a tentar replicar dependency injection com context providers, ou a usar RxJS porque lhes é familiar. Não faças isso. Aprende a forma React de fazer as coisas: hooks, composição, custom hooks para lógica partilhada. Resiste ao impulso de recriar o que conheces.
Aceita a paralisia de escolha e segue em frente. Sim, vais passar um dia a decidir entre libraries de gestão de estado. Escolhe uma, compromete-te, e reavalia em seis meses se não estiver a funcionar. A escolha errada feita rapidamente é melhor do que nenhuma escolha feita lentamente.
A tua experiência Angular é mais valiosa do que pensas. Compreender arquitetura de componentes, gestão de ciclo de vida, padrões de dependency injection e programação reativa não desaparece só porque a sintaxe mudou. Descobri que o meu background em Angular me fez um melhor developer React porque já compreendia porquê certos padrões existem. Só precisava de aprender o novo como.
A Minha Opinião Honesta
Nenhuma framework é objetivamente melhor. O Angular dá-te estrutura e opiniões, o que é valioso quando tens uma equipa grande e queres consistência. O React dá-te liberdade e um ecossistema massivo, o que é valioso quando queres mover rápido e escolher a melhor ferramenta para cada trabalho.
Passei de Angular para React e estou contente com a mudança. Mas se o meu próximo cargo usasse Angular outra vez, não me queixava. Os fundamentos transferem-se. O resto é sintaxe.
Mudaste de stack recentemente? Tinha curiosidade de saber o que mais te surpreendeu. Entra em contacto.