En køreplan for Angular – fortiden, nutiden og fremtiden for Angular

Angular-opdateringer: Hvad er nyt i version 11

Med virkning fra november 2020 er Angular version 11.0.0.0 nu tilgængelig. Denne version bringer mange opdateringer til platformen, men de vigtigste funktioner omfatter hurtigere builds med TypeScript 4.0, komponenttestharnes og ESLint-opdateringer.

Paleolithic JavaScript – SproutCore

I begyndelsen var der SproutCore. Det var den første omfattende JavaScript-ramme, der havde til formål at gøre det nemt at bygge webapps af skrivebordskvalitet med en enkelt side på nettet. Det er ikke fordi, det ikke var muligt før. Da Google udgav Gmail, viste det verden, at webapps virkelig kunne erstatte komplekse desktopprogrammer. Google åbnede endda Closure-værktøjssættet – et sæt biblioteker og en optimerende compiler, som Google brugte til at bygge Gmail – for at give adgang til det.

Problemet var, at Googles Closure-værktøjer ikke var særlig udviklerværdige. De var i høj grad afhængige af Java, hvilket fremmedgjorde webudviklere, som var vant til at arbejde med JavaScript, PHP, Ruby og Python. Gmail var en god demonstration af, hvad der var muligt, men udvikling af lignende applikationer føltes stadig uden for rækkevidde for mange.

Det lykkedes nogle modige udviklere at sammensætte fantastiske enkeltsideapplikationer ved hjælp af en kombination af jQuery, gaffatape og håb. Mens disse apps så fantastiske ud for slutbrugerne, blev appsne for de udviklere, der arbejdede på dem, hurtigt til store bunker af teknisk gæld, som fik udviklerholdet til at frygte at tage på arbejde om morgenen.

Som følge heraf begyndte nogle få initiativrige udviklere at arbejde på rammer, der ville bringe Gmail-lignende apps inden for rækkevidde for webudviklere overalt. SproutCore var det første af disse frameworks, der tog fart. Det kom med et komplet sæt widgets, der gjorde det muligt at bygge komplekse webapplikationer uden at skulle røre ved HTML eller CSS.

Det endte med at være fantastisk for tidligere desktop-udviklere, som var blevet slæbt sparkende og skrigende over på nettet. Flere andre frameworks dukkede op med lignende mål; GWT og Cappuccino var de mest fremtrædende. Disse frameworks undgik endda JavaScript ved at transpilere andre sprog til JS. Igen var dette godt for desktop-udviklere. Men det efterlod passionerede webudviklere ude i kulden og fik dem til at føle, at deres hårdt tilkæmpede HTML-, CSS- og JavaScript-færdigheder ikke var værdifulde.

Det efterlod en åbning for en ramme, der virkelig omfavnede internettet, i stedet for at forsøge at plastre over det og lade som om, det var noget andet. Et par tidlige frameworks (Backbone og Knockout) dukkede op og opnåede en moderat mængde succes. Ember dukkede også op omkring dette tidspunkt. Det tog SproutCore, strippede det ned til dets knogler og forsøgte at genopbygge det til noget virkelig webvenligt. Ember ønskede at være JavaScript-verdenens Six Million Dollar Man: genopbygget bedre, stærkere og hurtigere.

Ingen af disse frameworks steg voldsomt i popularitet. Verden ventede på noget bedre. I 2010 dukkede dette noget bedre op – det blev kaldt Angular.

Guldalderen for Angular

Selv før Angular version 1.0 var blevet udgivet, tog Angular front-end-udviklingsverdenen med storm. Endelig havde vi en brugervenlig JavaScript-ramme, der behandlede HTML som en førsteklasses borger. Udviklere og designere kunne nu arbejde sammen om at bygge fantastiske enkeltsidede applikationer. Dette kom som en lettelse for designere, der havde været irriterede og fornærmede, fordi ældre frameworks havde behandlet HTML og CSS som redskaber for barbarer, redskaber, som ingen civiliseret udvikler skulle have lov til at røre ved.

Den første ting, der virkede magisk på udviklere, der prøvede Angular for første gang, var tovejs databinding. Før dette havde de fleste udviklere kun set denne form for databinding i desktopframeworks som WPF og Windows Forms. Det var fantastisk at kunne binde formularer og andre UI-elementer til JavaScript-modelobjekter. Selv om tovejs databinding kunne give problemer med ydeevnen, når den blev brugt for meget, fandt de teams, der brugte den med omtanke, at Angular gjorde det muligt for dem at skabe komplekse front-end-applikationer meget hurtigere end nogensinde før.

Angular viste sig at være populært for mere end blot nem binding af data til HTML-elementer. Angular-direktiver gav en nem måde at skabe genanvendelige HTML + CSS-komponenter på. Selv om andre JavaScript-rammer gav dette før Angular, var Angular den første, der blev ekstremt populær. Genanvendelige komponenter havde længe været i brug i server-side frameworks. ASP.NET-brugerkontroller og delvise skabeloner i Rails og Django er blot nogle få
eksempler.

Endeligt gjorde Angular afhængighedsinjektion populær i front-end-udviklingsverdenen. Dependency injection havde længe været populært i virksomhedsapplikationer, hvilket måske er grunden til, at det ikke havde slået igennem i JavaScript-verdenen. Front-end-udviklere har længe været afvisende over for det, de ser som unødigt komplekse designmønstre for virksomhedssoftware. Denne bekymring er ikke ubegrundet. Har du nogensinde, mens du har skrevet en applikation, sagt til dig selv: “Hvad jeg virkelig har brug for her er en “SimpleBeanFactoryAwareAspectInstanceFactory?”

Dependency injection har dog bevist sit værd. Og Angular gjorde afhængighedsinjektion let at bruge for et publikum, der ikke havde brugt det meget tidligere. Har du brug for en HTTP-klient? Eller måske vil du gerne lave noget animation? Intet problem. Angular havde indbyggede tjenester til disse. Du skulle bare bede om dem, og Angular ville injicere dem i dine komponenter. Du behøver ikke selv at instantiere noget.

Og måske ønskede du at bruge browserens window eller location objekter uden at gøre det umuligt at enhedsteste dine komponenter uden for en browser? Angular havde dig også dækket der, med sine indbyggede $window- og $location-tjenester. Ved kørselstid ville du få de browserobjekter, du forventede. Og når du kørte enhedstests server-side i Node.js, kunne du sende mock-tjenester ind i dine komponenter for at sikre, at de opførte sig som forventet i forskellige scenarier.

Som om alt dette ikke var nok, gjorde Angular det også nemt at registrere og injicere dine egne tjenester. For udviklere, der var vant til at binde alle deres data til DOM’en og håbe på det bedste, var dette fantastisk. Hvis du skrev en ny front-end-app, der kaldte på API’er, som ville koste din virksomhed mange penge, hvis de blev overudnyttet, ville du sandsynligvis foretrække at kunne skrive tests på forhånd for at sikre, at din applikation ikke forsøger at gøre noget som at kalde Twilio API’et 800 millioner gange.

Så du ville oprette en Twilio-tjeneste, der bliver injiceret på køretid. På testtidspunktet vil du oprette en mock-tjeneste, der registrerer omkostningerne ved hvert API-opkald, som din applikation forsøger at foretage. Du ville skrive tests, der dækker almindelige brugsscenarier og sikre, at disse scenarier ikke resulterer i, at din virksomhed modtager en regning på et 7-cifret beløb. Samlet set fandt de fleste udviklere, at Angular-direktiver kombineret med dependency injection gjorde det muligt at skrive modulære, testbare front-end-applikationer ved hjælp af gennemprøvede softwareudviklingsteknikker. Mange udviklingsteams besluttede, at dette resulterede i en lykkelig situation, og besluttede at gå all-in på Angular.

Den angulære nedgang? The Rise of React

Selv om tingene for det meste gik godt i Angular-verdenen, var det ikke kun solskin og slikkepinde. Udviklerne begyndte at løbe ind i alvorlige problemer med ydeevnen, når de forsøgte at binde for mange modelobjekter til for mange DOM-elementer. Nogle applikationer blev langsommere og langsommere. Direkte kald til $digest og anden sort magi begyndte at blive nødvendige for at opnå en acceptabel ydeevne. Omkring samme tid dukkede der en ny udfordrer op: React. I første omgang syntes React ikke at udgøre en alt for stor fare for Angular. Når alt kommer til alt, havde disse React-narkomaner gjort sig den ulejlighed at opfinde JSX, som lignede meget en måde at blande markup ind i din kode på. Havde vi ikke gjort os meget umage med at opfinde templating-sprog af den udtrykkelige grund at undgå at blande markup og kode?

Det viste sig, at React’s tilgang var ret populær i front-end-udviklingsmiljøet. Den steg dog ikke med raketfart til popularitet. Angular var stadig dominerende, og det så ud til, at det ville forblive sådan. Indtil Angular’s popularitet fik et ordentligt spark i tænderne fra en uventet kilde: Angular-teamet selv.

Indførelsen af Angular 2

Angular 2 blev første gang annonceret på ng-europe-konferencen i 2014. Angular-teamets planer kom mildest talt som et chok for Angular-fællesskabet. Reaktionen fra Angular-udviklere var hurtig og negativ … og ikke uden grund. Angular 2 ville skille sig af med mange velkendte koncepter fra Angular 1, introducere et nyt, inkompatibelt templating-sprog (og oh, forresten) ville også blive programmeret med et helt nyt sprog.

AngularJS

Og selv om både Angular 1 og Angular 2 blev kaldt “Angular”, var de i virkeligheden meget forskellige frameworks med nogle få ting til fælles. For at undgå forvirring begyndte Angular-teamet at omtale den gamle version af Angular som “AngularJS” og den nye version blot som “Angular”. Dette giver intuitiv mening, da AngularJS var skrevet i JavaScript, og Angular ikke var det. For at holde sondringen mellem rammerne klar, vil jeg fra nu af henvise til Angular 1 som AngularJS.

Som følge af alt dette mistede AngularJS-udviklerne troen på rammens fremtid. De truede med at gå over til en ny ramme på fremtidige projekter, og det er netop, hvad mange af dem gjorde. React var den største begunstigede af masseudvandringen fra AngularJS.

Og selv om React ikke gjorde lige så meget som AngularJS, var det på en måde positivt. Hvis du bruger et view-bibliotek, der ikke forsøger at inkludere alt plus køkkenvasken, er det meget sværere for udviklerne af det pågældende bibliotek at trække tæppet væk under dig i fremtiden. I begyndelsen var det lidt besværligt at bruge React sammenlignet med AngularJS. Du var nødt til at sammensætte et kludetæppe af biblioteker for at dække den funktionalitet, som AngularJS leverede fra starten.

Mange teams så dette som en god måde at reducere risikoen på, fordi det var usandsynligt, at udviklerne af alle disse biblioteker ville beslutte sig for at foretage bagudkompatible, ødelæggende ændringer på samme tid, hvilket i det væsentlige var det, Angular havde gjort.

Vue’s fremkomst

For at forværre AngularJS’ problemer dukkede et andet framework ved navn Vue op på omtrent samme tid, som dramaet om Angular 2 fandt sted. Vue var inspireret af AngularJS, men havde til formål at forenkle det og slippe af med det, som Vue’s skaber så som unødvendig kompleksitet (så Vue føltes meget velkendt for eksisterende AngularJS-udviklere). Vue var en sikker havn for mange AngularJS-udviklere, som ikke ønskede at gå over til React.

Det betyder ikke, at AngularJS-udviklere ikke tålmodigt ventede på, at Angular 2 skulle dukke op. Men det er klart, at der var en masseudvandring fra AngularJS til React og Vue på grund af den usikkerhed, som planerne for Angular 2 medførte.

Opstå fra asken med Angular 2

Eventuelt blev Angular 2 udgivet. Som forventet blev mange velkendte koncepter fra AngularJS fjernet, men den beholdt nogle af de bedste dele som services og dependency injection. Heldigvis for udviklernes fornuft bruger Angular almindelig TypeScript og ikke en gaffel som oprindeligt planlagt.

For at gøre tingene mere forvirrende vedligeholdt Angular-holdet en fork af den nye ramme, der brugte programmeringssproget Dart i stedet for TypeScript. Oprindeligt blev TypeScript- og Dart-versionerne udviklet synkront og genereret fra en enkelt kodebase. Til sidst besluttede TS- og Dart-versionerne af Angular at gå hver til sit, og Angular Dart eksisterer nu selvstændigt.

Selv med denne forvirring begyndte Angular’s popularitet at stige igen efter Angular 2-udgivelsen. Det skete langsomt. Som det ofte sker i softwareudvikling, skiftede tendenserne. Udviklerne indså, at et stort, batteriinkluderet framework faktisk kunne være nyttigt. Når din applikation bliver stor nok, ender det jo med, at du faktisk får brug for alle disse batterier.

Der var især virksomhedsudviklere, der begyndte at gå tilbage til Angular. Det giver god mening. Normalt ved man, at når man starter en webapp til virksomheder, ved man, at den bliver kompleks. Der er ingen grund til at starte med en lille MVP, når du fra starten ved alle 87 ting, som din applikation forventes at kunne gøre.

Hvor er Angular 3?

Og selv om Angular 2 ikke var perfekt, begyndte mange udviklere af komplekse webapplikationer at indse, at det nye og forbedrede Angular passede godt til deres behov. Heldigvis for dem havde Angular nogle spændende forbedringer i vente. Endnu vigtigere var det, at Angular-teamet demonstrerede, at det konsekvent kunne udgive nye versioner af rammen med få brud på rammerne med få ændringer mellem versionerne

I et træk, der virkede mærkeligt på det tidspunkt, besluttede Angular-teamet at springe version 3 helt over og gå over til version 4. Dette blev gjort af en god grund: Holdet, der arbejdede på Angular’s routerpakke, havde allerede skubbet fremad og udgivet version 3, mens resten af Angular stadig var i version 2.3. De besluttede sig for at holde alle Angular-pakkeversioner synkroniseret fremadrettet, og det var den letteste måde at opnå dette på, ved at alt blev sat op til version 4 i den næste udgave.

Angular 4

Angular 4 havde nogle væsentlige ændringer, herunder tilføjede forudgående kompilering, hvilket resulterede i små JavaScript-bundles til produktion og kortere indlæsningstid for applikationer. Der blev tilføjet understøttelse af server-side rendering, hvilket var et løft for teams, der ønskede at rendere deres app på forhånd for at forbedre den oprindelige indlæsningsydelse. Der blev tilføjet mange andre forbedringer i hele rammen, men opgradering af apps fra Angular 2 til 4 var hurtig og smertefri i de fleste tilfælde.

Angular 4.3 og Angular 5

Angular 4.3 tilføjede en ny HTTP-klient, som var lettere at bruge end den gamle HTTP-tjeneste. I Angular 5 blev den gamle HTTP-tjeneste forældet og ville blive droppet i den næste version. På trods af denne ulempe var der relativt lidt brok, fordi opgraderingen i de fleste tilfælde var ukompliceret. Angular 5 tilføjede også bedre understøttelse af internationalisering og yderligere optimeringer af opbygningen.

Angular 6 og 7

Angular 6 og 7 var skuffende for nogle udviklere. Der var ingen store ændringer, men der var mange små forbedringer af livskvaliteten, især med hensyn til Angular CLI-værktøjet. Det faldende antal synlige ændringer er ikke et tegn på, at Angular-teamet er holdt op med at innovere. Det viser i stedet, at rammen er moden, så udviklingsholdet kan nu arbejde mere bag kulisserne for at rette fejl og forbedre ydeevnen.

Frameworkets stabilitet siden udgivelsen af Angular 2 har trukket nogle AngularJS-udviklere af den gamle skole tilbage til Angular-verdenen. Det har også tiltrukket sig opmærksomhed fra virksomheders udviklingsteams. Når du bygger virksomhedsapplikationer, der kan leve i årtier, er det ideelt at bruge en ramme, der får nye udgivelser efter en forudsigelig tidsplan, men som ikke ændrer sig for hurtigt. En udvikler, der kun har brugt Angular 2, kan være i gang og bidrage til en Angular 7-app inden for få minutter.

Angular 8 og Angular Ivy

Og det bringer os til i dag. Som vi har set, er Angular kommet langt. Det er gået fra at være elsket af webudviklere til at være udskældt til at blive beundret, selv om det endnu ikke er elsket igen, som det var i sine tidlige dage.

I horisonten har vi Angular 8. Der er blevet gjort en masse arbejde i Angular 8 for at gøre det nemt at bruge med Bazel-buildsystemet, hvilket er helt fantastiske nyheder for alle 3 udviklere, der bruger det uden for Google. Læs om Angular 8-ændringer.

Mere spændende er det dog, at Angular-teamet arbejder hårdt på et nyt rendered kaldet Angular Ivy. Det er meningen, at det skal være en drop-in erstatning for den nuværende rendered. For det meste vil nuværende apps ikke skulle foretage nogen ændringer for at bruge Angular Ivy.

Hvis Angular Ivy er en drop-in erstatning, hvorfor skulle udviklere så bekymre sig? To vigtige grunde: hastighed og bundle-størrelse – to meget vigtige bekymringer. I et par år virkede det som om, at webudviklere var gået lidt amok. Teams leverede JavaScript-bundles, der var 5 MB, 10 MB eller endnu større, og troede, at der ikke var noget problem med det. Programmerne fungerede trods alt perfekt på udviklernes i7-drevne MacBook Pro’er, så de burde fungere fint for alle, ikke sandt?

I den virkelige verden er det desværre ikke alle, der kører med den nyeste og bedste hardware. Hundredvis af millioner af mennesker har adgang til internettet udelukkende på ældre Android-telefoner med lidt mere processorkraft end en kartoffel via internetforbindelser, der kun er lidt hurtigere end opkaldsforbindelser. For disse brugere tager det en evighed at indlæse et stort JavaScript-pakke og endnu længere tid for deres enhed at analysere og køre det. Selv i mindre ekstreme tilfælde er der utallige brugere rundt om i verden, som ikke bruger den nyeste og bedste hardware. For dem er store JavaScript-apps anvendelige (men smertefulde).

Angular Ivy

Angular Ivy-rendereren vil hjælpe på flere måder:

1. Den bliver skrevet med øje for effektivitet, så den vil udføre de samme opgaver, mens den udfører langt færre CPU-instruktioner. Det vil forbedre både batterilevetiden og fornuften hos brugere med mindre end kraftige enheder.
2. Rendereren vil blive skrevet på en langt mere modulær måde end den nuværende renderer. Det vil gøre den meget mere velegnet til at blive rystet i træer og til at eliminere død kode. Som følge heraf vil dit JavaScript-bundle i produktionen kun indeholde den kode, der er nødvendig for at køre din applikation, i stedet for at samle alt plus køkkenvasken, som det ofte sker med den nuværende renderer.
3. Ud over reduktionen af bundle-størrelsen og den forbedrede renderingshastighed har Angular Ivy yderligere et par forbedringer af livskvaliteten for Angular-udviklere. Genopbygningstiderne er betydeligt hurtigere. Så hvis du kører din app i udviklingstilstand og venter på, at dine ændringer vises, bruger du nu meget mindre tid på at vente.
4. Template-type kontrol er forbedret, hvilket betyder, at du fanger flere fejl på kompileringstidspunktet i stedet for på kørselstid. Fejl i skabeloner ved kørselstid er irriterende, fordi de enten bider dig under testning, eller de bider dine brugere, når de forsøger at bruge din app.
5. Angular Ivy-skabelonkompileren vil generere kode, der er læsbar for mennesker, hvilket den nuværende View Engine-kompiler ikke gør. Dette vil være praktisk, når man forsøger at opspore svære skabelonfejl.

Nettoresultatet: mindre apps, hurtigere apps, gladere udviklere og gladere brugere.

Angular 9

Her er en oversigt over Angular 9.

De vigtigste højdepunkter omfatter:

• Indbyggede Angular-funktioner
• Moden udvikling med Angular
• Forståelse af Angular View Engines
• Angular Ivy løser langvarige problemer
• Angular Ivy og Mobile
• Selector-less Directives
• Angular Diagnostics Forbedringer
• Internationalisering med Angular Ivy
• DI og Type-Safe i Angular 9
• Dependency Injection Ændringer i Angular Core
• Angular Benchmarks (Angular 8.2.7 vs. 9.0.0.0-next.5)

Angular 10

Angular version 10.0.0 blev udgivet i slutningen af juni 2020. Angular 10 er en større version og indeholder ændringer som f.eks. en ny datointervalgsvælger i Angular Material, opgradering af TypeScript-versioner, opdateringer af biblioteksversioner og meget mere.

Nye funktioner omfatter:

• Ngtsc Compiler Interface
• Configure Async Timeouts
• Stale Lock File Reporting
• Lazy Computation of basePaths
• Sammenlægning af oversættelsesfiler
• Explicit mapping

Angular 11

Angular version 11.0.0 blev udgivet i november 2020. Angular 11-majorudgaven indeholder opdateringer på tværs af platformen, herunder CLI- og komponentrammen.

Signifikante funktioner omfatter:

• Snellere builds med TypeScript 4.0
• Component Test Harnesses
• ESLint-opdateringer
• opdateret Language Service Preview
• opdateret Hot Module Replacement (HMR) Support
• forbedrede rapporteringer og logning
• automatisk Font Inliining

Angular’s Past, Nutid og fremtid

Hvis du har brugt Angular fra de tidlige dage og helt frem til nu, så tillykke! Selv om der har været masser af hårde punkter, er vi endt med en hurtig, moderne ramme, som er sjov at bruge.

Hvis du har været AngularJS-udvikler, men er gået videre til React, Vue eller noget andet, vil jeg opfordre dig til at give Angular et nyt kig. Det er din tid værd, selv om du beslutter dig for at holde dig til det, du bruger nu.

Og hvis du slet ikke har brugt Angular, hvorfor så ikke give det et forsøg?

Vi har netop været på en tur i hvirvelvind gennem Angular’s fortid, nutid og fremtid. Det har uden tvivl været noget af en tur. Uanset din Angular-baggrund håber jeg, at du har nydt turen!

Hvilket framework arbejder du med og hvorfor? Hvis du har spørgsmål eller kommentarer, skal du sørge for at skrive dem nedenfor.

Søger du efter rammeagnostiske UI-komponenter? GrapeCity har et komplet sæt JavaScript UI-komponenter, herunder datagitre, diagrammer, målere og indtastningskontroller. Vi tilbyder også kraftige regnearkskomponenter, rapporteringskontroller og forbedrede præsentationsvisninger. Vi har dyb understøttelse af Angular (samt React og Vue) og er dedikeret til at udvide vores komponenter til brug i moderne JavaScript-rammer.