Da jeg browset YouTube forrige uke, ble jeg gledelig overrasket: Honeypot har kommet ut med en ny dokumentar!
Forrige gang så vi dramaet til Vue og React, fra idé til populært verktøy, og denne gangen ser vi historien om … 🥁 Angular!
Angular er misforstått
Personlig har jeg bare rørt Angular én gang. Det var da jeg lagde en todo-app som forberedelse til et jobbintervju, hvor jeg hadde hørt bedriften brukte Angular. Det viste seg at jobben ikke var i en stilling som webutvikler, så det ble med den samtalen.
Ellers er min kilde til kunnskap om Angular fra memes, hvor det gjerne gjøres narr av hvor komplisert eller gammelt det er.
Etter å ha sett dokumentaren, tror jeg at Angular er misforstått. Fireship syns hvert fall at det bør ha mer respekt.
Dokumentaren belyser noen av årsakene til at Angular ikke er så lett å forstå. Massive omskrivinger har ført til at utviklere både har falt av og ikke helt skjønt hvilken variant det egentlig snakkes om. I dag er Angular på versjon 19, og brukes av et av de største selskapene i verden — Google — som det også finansieres av.
Selv om jeg sikkert ikke kommer til å bruke Angular med det første, har jeg likevel tre refleksjoner jeg tar med tilbake i min lille React-boble:
#1: Angular har påvirket frontend-verdenen gjennom årene
Før Angular, var jQuery det dominerende verktøyet for å oppdatere UI. Men jQuery kunne føre til mye komplisert kode, der utviklere manuelt måtte manipulere DOM-en. Angular forenklet dette ved å popularisere deklarative komponenter — en tilnærming som har inspirert mange moderne frontend-rammeverk.
Et annet modig valg, var å ta i bruk TypeScript. Angular møtte mye skepsis for å ta i bruk et typesystem, som før bare hørte hjemme i backend. Men i dag er TypeScript standard for nye frontend-prosjekter.
For ett år siden tok Angular også i bruk signals, inspirert av SolidJS og Svelte. Forenkling eller ikke, opp gjennom har Angular prøvd ut mange ting for å prøve å gjøre webutvikling enklere.
4 ting Jørn Are gleder seg til i versjon 19: «Liker renere kode!»
#2: State kan løses på mange måter
Angulars introduksjon av signals viser at du kan løse tilstand på mange måter.
Opprinnelig benyttet Angular2 RxJS for tilstandshåndtering, hvor utviklere brukte “observables” og “subscriptions” for å håndtere tilstandsendringer, både for synkron og asynkron tilstand. Dette kunne føre til kompleks kode og krevde manuell håndtering av abonnementer for å unngå minnelekkasjer. For å forenkle denne prosessen, byttet Angular den synkrone oppdateringen med signals. Om du er nysgjerrig på hvorfor ha begge deler, har Joshua Morony en forklaring her.
I React endrer du tilstand, så re-rendrer du hele komponenten. Men med signals ser du på ikke på tilstand som en rekke av hendelser, men du ser på hvordan den enkelte verdien endres over tid. Dermed kan du presist endre deler av grensesnittet, uten å re-rendre hele komponenten. Dette kan forbedre ytelsen ved å redusere unødvendig arbeid.
Signals høres nå lurt ut, så hvorfor har ikke også React tatt signals i bruk?
React har flere ganger diskutert bruken av signals. Men React og Angular går mot forskjellige veier når det kommer til UI-oppdatering. React har sett til andre løsninger for å forbedre tilstandshåndteringen, som å effektivisere re-rendringen som følger. React la til memoiseringsfunksjoner som useMemo, og nylig introduserte de React-kompilatoren hvor du slipper å tenke på å legge til disse funksjonene selv — det skjer automatisk. React kom også nå med RSC, hvor du laster inn UI-et sammen med dataene på forhånd — så du slipper å holde dataene i sync.
Velge rammeverk? Nicklas mener du bare har to valg
#3: Du kan miste mange brukere ved store endringer — eller for få
Angular-teamet har introdusert hvert fall to store endringer som har utfordret brukerne deres.
Overgangen fra AngularJS til Angular2 tvang konsumerne å gjøre store omskrivinger. “Omskrivingen kunne likegodt bli kalt ‘GoogleJS’”, sa en utvikler, for omskrivingen var så stor at det kunne fått et nytt navn. Det var heller ikke bare å google til seg endringene som var gjort, fordi det dukket opp dokumentasjon for det gamle, og det var ikke tydelig hva som var nytt eller gammelt.
Angular-teamet gjorde også en stor endring i det såkalte Ivy-prosjektet, som var en massiv refaktorering. Konsumerne merket lite til refaktoreringen direkte, men det krevde mye tid av Angular-teamet, som førte til at det var flere år hvor det ikke kom noe særlig ny funksjonalitet. Angular opplevdes derfor død, så Angular mistet moment.
React har lykkes ved å jevnlig levere mindre oppdateringer. Altså, du har den store introduksjonen av hooks som ga noen hjertesukk, men også denne var opt-in. React har til nå vært mer forsiktig med radikale endringer. Men med introduksjonen av RSC, kanskje vi kan se lignende utfordringer?
Elkjøp vraka Angular: «Morsomste jeg har gjort!»
Hvordan starte et React prosjekt i 2025?
Om ikke annet, så har Angular hvert fall en fordel over React: du må ikke årlig lære deg hvordan du starter opp et nytt prosjekt.
Angular kommer med batterier inkludert, mens med React må du gjøre en drøss med valg. Heldigvis har Robin Wieruch gitt oss React-guiden for i år.
Artikkelen gir oss tre alternativer å vurdere: Vite, NextJS eller Astro. Så hva skal brukes når?
- Om du bare trenger en lettvekts-app, bruk Vite. Da kan du selv dra inn de bibliotekene du vil ha. Det er best om du bare trenger klientside-rendring. Vite passer også bra når du skal lære deg React. For da kan du lære det fundamentale ved React, istedenfor å havne borti NextJS-spesifikke greier.
- Om du ser etter å ha batterier inkludert, er NextJS er godt valg. Det er den mest modne løsningen nå, og gir deg funksjonalitet som routing, rendringsstrategier, SEO og bildeoptimalisering. En stor fordel med NextJS er at det er et fullstack rammeverk, så du kan koble deg til databaser og autentisering, uten å skifte mellom kodebaser.
- Om du hovedsakelig skal håndtere innholds-fokuserte nettsider, kan Astro være et bedre valg enn NextJS. Årsaken er at Astro har en øy-arkitektur — altså hver side er sin egen greie. Dette gjør at sidene lastes mye raskere. Med Astro har du altså ikke en SPA, men en MPA — multi page application.
Det var alt for denne gangen — snakkes neste uke! 👋
