En Angular Roadmap – Det förflutna, nuet och framtiden för Angular

Angular Updates: Vad är nytt i version 11

Från och med november 2020 finns Angular version 11.0.0.0 nu tillgänglig. Den här versionen ger många uppdateringar till plattformen, men de viktigaste funktionerna inkluderar snabbare byggnationer med TypeScript 4.0, testhärdar för komponenter och ESLint-uppdateringar.

Paleolithic JavaScript – SproutCore

I början fanns det SproutCore. Det var det första heltäckande JavaScript-ramverket som syftade till att göra det enkelt att bygga webbsidor med en enda sida av skrivbordskvalitet. Det är inte så att detta inte var möjligt tidigare. När Google släppte Gmail visade man världen att webbappar verkligen kunde ersätta komplexa skrivbordsprogram. Google har till och med öppnat Closure-verktygslådan – en uppsättning bibliotek och en optimerande kompilator som företaget använde för att bygga Gmail.

Problemet var att Googles Closure-verktyg inte var särskilt utvecklarvänliga. De var starkt beroende av Java, vilket alienerade webbutvecklare som var vana vid att arbeta med JavaScript, PHP, Ruby och Python. Gmail var en bra demonstration av vad som var möjligt, men att utveckla liknande tillämpningar kändes fortfarande utom räckhåll för många.

Vissa modiga utvecklare lyckades sätta ihop fantastiska appar för en enda sida med hjälp av en kombination av jQuery, tejp och hopp. Dessa appar såg fantastiska ut för slutanvändarna, men för de utvecklare som arbetade med dem förvandlades apparna snabbt till stora högar av teknisk skuld som gjorde att utvecklingsteamet fruktade att gå till jobbet på morgonen.

Det ledde till att några företagsamma utvecklare började arbeta på ramverk som skulle göra Gmail-liknande appar lätt tillgängliga för alla webbutvecklare. SproutCore var det första av dessa ramverk som tog fart. Det kom med en komplett uppsättning widgets som gjorde det möjligt att bygga komplexa webbapplikationer utan att ens röra HTML eller CSS.

Detta slutade med att vara bra för tidigare skrivbordsutvecklare som hade dragits över till webben med sparkar och skrik. Flera andra ramverk dök upp med liknande mål; GWT och Cappuccino var de mest framträdande. Dessa ramverk undvek till och med JavaScript genom att transpila andra språk till JS. Återigen var detta bra för datorutvecklare. Men det lämnade passionerade webbutvecklare ute i kylan och fick dem att känna att deras hårt förvärvade kunskaper i HTML, CSS och JavaScript inte var värdefulla.

Detta lämnade en öppning för ett ramverk som verkligen omfamnade webben, i stället för att försöka plåstra över den och låtsas att den var något annat. Ett par tidiga ramverk (Backbone och Knockout) dök upp och nådde en måttlig framgång. Ember dök också upp vid den här tiden. Den tog SproutCore, rensade ner den till grunden och försökte bygga om den till något verkligt webbvänligt. Ember ville bli JavaScript-världens Six Million Dollar Man: ombyggd bättre, starkare och snabbare.

Ingen av dessa ramverk blev särskilt populära. Världen väntade på något bättre. År 2010 dök detta något bättre upp – det fick namnet Angular.

Angulars guldålder

Även innan Angular version 1.0 hade släppts tog Angular front-end-utvecklingsvärlden med storm. Äntligen hade vi ett lättanvänt JavaScript-ramverk som behandlade HTML som en förstklassig medborgare. Utvecklare och designers kunde nu arbeta tillsammans för att bygga fantastiska enkelsidiga program. Detta kom som en lättnad för designers, som hade varit irriterade och förolämpade eftersom äldre ramverk hade behandlat HTML och CSS som verktyg för barbarer, verktyg som ingen civiliserad utvecklare skulle behöva röra.

Den första sak som verkade magisk för utvecklare som provade Angular för första gången var tvåvägsdatabindning. Dessförinnan hade de flesta utvecklare bara sett denna typ av databindning i skrivbordsramverk som WPF och Windows Forms. Det var fantastiskt att kunna binda formulär och andra UI-element till JavaScript-modellobjekt. Även om tvåvägsdatabindning kunde orsaka prestandaproblem vid överanvändning, upptäckte team som använde den med omdöme att Angular gjorde det möjligt för dem att skapa komplexa front-end-applikationer mycket snabbare än någonsin tidigare.

Angular visade sig vara populärt för mer än bara enkel bindning av data till HTML-element. Angular-direktiv gav ett enkelt sätt att skapa återanvändbara HTML + CSS-komponenter. Även om andra JavaScript-ramverk tillhandahöll detta före Angular var Angular det första som blev extremt populärt. Återanvändbara komponenter hade länge använts i serverbaserade ramverk. ASP.NET-användarkontroller och partiella mallar i Rails och Django är bara några
exempel.

Slutligt gjorde Angular beroendeinjektion populär i front-end-utvecklingsvärlden. Beroendeinjektion hade länge varit populärt i företagsapplikationer, vilket kanske är anledningen till att det inte hade slagit igenom i JavaScript-världen. Front-end-utvecklare har länge varit ovilliga till vad de anser vara onödigt komplexa designmönster för företagsprogram. Denna oro är inte obefogad. Har du någonsin, under skrivandet av en applikation, sagt till dig själv ”Vad jag verkligen behöver här är en ”SimpleBeanFactoryAwareAspectInstanceFactory?”

Dependency injection har dock bevisat sitt värde. Och Angular gjorde beroendeinjektion lätt att använda för en publik som inte hade använt det så mycket tidigare. Behöver du en HTTP-klient? Eller kanske vill du göra några animationer? Inga problem. Angular hade inbyggda tjänster för dessa. Det var bara att be om dem och Angular injicerade dem i dina komponenter. Du behöver inte instantiera något själv.

Och kanske du ville använda webbläsarens window eller location objekt utan att göra det omöjligt att enhetstesta dina komponenter utanför en webbläsare? Angular hade dig täckt där också, med sina inbyggda tjänster $window och $location. Vid körning fick du de webbläsarobjekt som du förväntade dig. Och när du körde enhetstester på serversidan i Node.js kunde du skicka in mock-tjänster i dina komponenter för att se till att de uppförde sig som förväntat i olika scenarier.

Om allt detta inte var tillräckligt gjorde Angular det också enkelt att registrera och injicera egna tjänster. För utvecklare som var vana vid att binda all sin data till DOM och hoppas på det bästa var detta fantastiskt. Om du skrev en ny front-end-app som kallade på API:er som skulle kosta ditt företag mycket pengar om de användes för mycket, skulle du förmodligen föredra att kunna skriva tester i förväg för att se till att din applikation inte försöker göra något som att ringa Twilio API 800 miljoner gånger.

Så du skapar en Twilio-tjänst som injiceras vid körning. Vid testtillfället skapar du en mock-tjänst som registrerar kostnaden för varje API-samtal som din applikation försöker göra. Du skriver tester som täcker vanliga användningsscenarier och ser till att dessa scenarier inte leder till att ditt företag får en sjusiffrig räkning. På det hela taget tyckte de flesta utvecklare att Angular-direktiv i kombination med beroendeinjektion gjorde det möjligt att skriva modulära, testbara front-end-applikationer med hjälp av beprövade tekniker för programvaruteknik. Många utvecklingsteam beslutade att detta resulterade i ett lyckligt läge och bestämde sig för att satsa helt och hållet på Angular.

Den angulära nedgången? The Rise of React

Men även om saker och ting för det mesta var bra i Angular-världen var det inte bara solsken och lollipops. Utvecklare började få allvarliga prestandaproblem när de försökte binda för många modellobjekt till för många DOM-element. Vissa tillämpningar saktade ner till en krasch. Direkta anrop till $digest och andra svart magiska trollkonster började bli nödvändiga för att uppnå acceptabel prestanda. Ungefär samtidigt dök en ny utmanare upp: React. Till en början verkade React inte utgöra någon större fara för Angular. Dessa React-knäppgökar hade trots allt gjort sig besväret att uppfinna JSX, som såg mycket ut som ett sätt att blanda in markeringar i koden. Hade vi inte gjort oss mycket besvär med att uppfinna mallspråk av den uttryckliga anledningen att vi ville undvika att blanda ihop markeringar och kod?

Det visade sig att Reacts tillvägagångssätt var ganska populärt inom front-end-utvecklingen. Den blev dock inte så populär som en raket. Angular var fortfarande dominerande, och det såg ut som om det skulle förbli så. Tills Angulars popularitet fick en rejäl spark mot tänderna från en oväntad källa: Angular-teamet självt.

Introduktionen av Angular 2

Angular 2 tillkännagavs först på ng-europe-konferensen 2014. Angular-teamets planer kom minst sagt som en chock för Angular-communityn. Reaktionen från Angular-utvecklare var snabb och negativ… och inte utan anledning. Angular 2 skulle göra sig av med många välkända koncept från Angular 1, införa ett nytt, inkompatibelt templating-språk (och oh, förresten) skulle också programmeras med hjälp av ett helt nytt språk.

AngularJS

Och även om både Angular 1 och Angular 2 kallades ”Angular” var de i verkligheten mycket olika ramverk med några få saker gemensamt. För att undvika förvirring började Angular-teamet kalla den gamla versionen av Angular för ”AngularJS” och den nya versionen för ”Angular”. Detta är intuitivt logiskt eftersom AngularJS var skriven i JavaScript och Angular inte var det. För att hålla skillnaden mellan ramverken tydlig kommer jag från och med nu att referera till Angular 1 som AngularJS.

Som ett resultat av allt detta tappade AngularJS-utvecklarna tron på ramverkets framtid. De hotade med att gå över till ett nytt ramverk i framtida projekt, och det är precis vad många av dem gjorde. React var den största mottagaren av massflykten från AngularJS.

Och även om React inte gjorde lika mycket som AngularJS var det på ett sätt positivt. Om du använder ett vybibliotek som inte försöker inkludera allt plus diskbänken är det mycket svårare för utvecklarna av det biblioteket att dra undan mattan under dig i framtiden. I början var det lite jobbigt att använda React jämfört med AngularJS. Du var tvungen att pussla ihop ett lapptäcke av bibliotek bara för att täcka den funktionalitet som AngularJS tillhandahöll direkt från början.

Många team såg detta som ett bra sätt att minska risken, eftersom det var osannolikt att utvecklarna av alla dessa bibliotek skulle bestämma sig för att göra bakåtkompatibla brytande ändringar samtidigt, vilket i huvudsak var vad Angular hade gjort.

Uppkomsten av Vue

För att förvärra AngularJS’ problem dök ett annat ramverk vid namn Vue upp ungefär samtidigt som dramatiken kring Angular 2 ägde rum. Vue var inspirerad av AngularJS men syftade till att förenkla det och göra sig av med vad Vues skapare såg som onödig komplexitet (så Vue kändes mycket bekant för befintliga AngularJS-utvecklare). Vue erbjöd en fristad för många AngularJS-utvecklare som inte ville gå över till React.

Detta betyder inte att AngularJS-utvecklare inte tålmodigt väntade på att Angular 2 skulle dyka upp. Men det är tydligt att det skedde en massflykt från AngularJS till React och Vue på grund av den osäkerhet som orsakades av planerna för Angular 2.

Rising From the Ashes with Angular 2

Till slut släpptes Angular 2. Som väntat gjorde man sig av med många välkända koncept från AngularJS men behöll några av de bästa delarna som tjänster och injektion av beroenden. Lyckligtvis för utvecklarnas förnuft använder Angular vanlig TypeScript och inte en gaffel som ursprungligen planerats.

För att göra saker och ting ännu mer förvirrande, upprätthöll Angular-teamet en gaffel av det nya ramverket som använde programmeringsspråket Dart i stället för TypeScript. Initialt utvecklades TypeScript- och Dart-versionerna synkront och genererades från en enda kodbas. Så småningom bestämde sig TS- och Dart-versionerna av Angular för att gå skilda vägar, och Angular Dart existerar nu på egen hand.

Trots denna förvirring började Angulars popularitet öka igen efter Angular 2-utgåvan. Det skedde långsamt. Som ofta sker inom mjukvaruutveckling skiftade trenderna. Utvecklare insåg att ett stort, batteriinkluderat ramverk faktiskt kunde vara användbart. När din applikation blir tillräckligt stor slutar det trots allt med att du faktiskt behöver alla dessa batterier.

Enterprise-utvecklare, i synnerhet, började flytta tillbaka till Angular. Detta är logiskt. När man startar en webbapplikation för företag vet man vanligtvis att den kommer att vara komplex. Det är ingen idé att börja med en liten MVP när man redan från början vet alla 87 saker som applikationen förväntas göra.

Var finns Angular 3?

Och även om Angular 2 inte var perfekt började många utvecklare av komplexa webbapplikationer inse att den nya och förbättrade Angular passade bra för deras behov. Lyckligtvis för dem hade Angular några spännande förbättringar i beredskap. Ännu viktigare var att Angular-teamet visade att de konsekvent kunde publicera nya versioner av ramverket med få brytande ändringar mellan versionerna

I ett drag som verkade märkligt vid tidpunkten beslutade Angular-teamet att hoppa över version 3 helt och hållet och gå över till version 4. Detta gjordes av goda skäl: teamet som arbetade med Angulars routerpaket hade redan gått vidare och släppt version 3, medan resten av Angular fortfarande befann sig i version 2.3. De bestämde sig för att hålla alla Angular-paketversioner synkroniserade framöver, och att flytta upp allt till version 4 för nästa version var det enklaste sättet att uppnå detta.

Angular 4

Angular 4 hade några betydande förändringar, bland annat lades kompilering i förväg till, vilket resulterade i små JavaScript-paket för produktion och kortare laddningstid för applikationer. Stöd för server-side rendering lades till, vilket var ett lyft för team som ville rendera sin app i förväg för att förbättra den initiala laddningsprestandan. Många andra förbättringar lades till i hela ramverket, men att uppgradera appar från Angular 2 till 4 gick snabbt och smärtfritt i de flesta fall.

Angular 4.3 och Angular 5

Angular 4.3 lade till en ny HTTP-klient som var lättare att använda än den gamla HTTP-tjänsten. I Angular 5 var den gamla HTTP-tjänsten föråldrad och skulle slopas i nästa version. Trots denna olägenhet var det relativt lite gnäll eftersom uppgraderingen i de flesta fall var okomplicerad. Angular 5 lade också till bättre stöd för internationalisering och ytterligare byggoptimeringar.

Angular 6 och 7

Angular 6 och 7 var en besvikelse för vissa utvecklare. Det fanns inga stora förändringar, men det fanns många små förbättringar av livskvaliteten, särskilt när det gäller Angular CLI-verktygen. Det minskande antalet synliga förändringar är inte ett tecken på att Angular-teamet har slutat med innovation. I stället visar det att ramverket är moget och att utvecklingsteamet nu kan arbeta mer bakom kulisserna för att åtgärda fel och förbättra prestandan.

Stabiliteten hos ramverket sedan Angular 2 släpptes har lockat en del AngularJS-utvecklare av den gamla skolan tillbaka till Angular-världen. Det har också dragit till sig uppmärksamhet från företagens utvecklingsteam. När du bygger företagsappar som kan leva i årtionden är det idealiskt att använda ett ramverk som får nya versioner enligt ett förutsägbart schema men som inte förändras för snabbt. En utvecklare som bara har använt Angular 2 kan vara igång och bidra till en Angular 7-app inom några minuter.

Angular 8 och Angular Ivy

Och det för oss till idag. Som vi har sett har Angular kommit långt. Det har gått från att vara älskat av webbutvecklare till att vara smädat till att vara beundrat, även om det ännu inte är älskat igen som det var i början.

På horisonten har vi Angular 8. En massa arbete har gjorts i Angular 8 för att göra det enkelt att använda med Bazel-byggsystemet, vilket är helt fantastiska nyheter för alla 3 utvecklare som använder det utanför Google. Läs mer om ändringarna i Angular 8.

Mer spännande är dock att Angular-teamet arbetar hårt på en ny renderad som kallas Angular Ivy. Den är tänkt att vara en drop-in ersättning för den nuvarande renderingen. För det mesta kommer nuvarande appar inte att behöva göra några ändringar för att använda Angular Ivy.

Om Angular Ivy är en drop-in ersättning, varför ska utvecklare bry sig? Två viktiga skäl: snabbhet och paketstorlek – två mycket viktiga frågor. Under några år verkade det som om webbutvecklare hade blivit lite galna. Grupperna levererade JavaScript-paket som var 5 MB, 10 MB eller till och med större, och trodde att det inte var något problem med detta. Programmen fungerade trots allt perfekt på utvecklarnas i7-drivna MacBook Pros så de borde väl fungera bra för alla?

I verkligheten är det tyvärr inte alla som har den senaste och bästa hårdvaran. Hundratals miljoner människor har tillgång till internet enbart på äldre Android-telefoner med lite mer processorkraft än en potatis, via internetanslutningar som bara är lite snabbare än uppringning. För dessa användare tar det en evighet att ladda ett stort JavaScript-paket och ännu längre tid för enheten att analysera och köra det. Även i mindre extrema fall finns det otaliga användare runt om i världen som inte använder den senaste och bästa hårdvaran. För dem är massiva JavaScript-appar användbara (men smärtsamma).

Angular Ivy

Renderern Angular Ivy kommer att hjälpa till på flera sätt:

1. Den skrivs med tanke på effektivitet, så den kommer att utföra samma uppgifter samtidigt som den utför betydligt färre CPU-instruktioner. Detta kommer att förbättra både batteritiden och förnuftet hos användare med mindre kraftfulla enheter.
2. Renderern kommer att skrivas på ett mycket mer modulärt sätt än den nuvarande renderern. Detta kommer att göra den mycket mer mottaglig för trädslagsarbete och eliminering av död kod. Som ett resultat av detta kommer ditt JavaScript-paket i produktionen endast att innehålla den kod som behövs för att köra din applikation, i stället för att bunta ihop allt plus diskbänken som ofta händer med den nuvarande rendern.
3. Förutom minskningen av paketstorleken och den förbättrade renderingshastigheten har Angular Ivy ytterligare några förbättringar av livskvaliteten för Angular-utvecklare. Ombyggnadstiderna är betydligt snabbare. Så om du kör din app i utvecklingsläge och väntar på att dina ändringar ska visas kommer du nu att tillbringa mycket mindre tid med att vänta.
4. Kontrollen av malltyper är förbättrad, vilket innebär att du fångar upp fler fel vid kompileringstid istället för vid körning. Fel i mallar vid körning är irriterande, eftersom de antingen biter dig under testning eller biter dina användare när de försöker använda din app.
5. Mallkompilatorn för Angular Ivy-mallar kommer att generera kod som är läsbar för människor, vilket den nuvarande View Engine-kompilatorn inte gör. Detta kommer att vara praktiskt när man försöker spåra svåra fel i mallar.

Nettoresultatet: mindre appar, snabbare appar, nöjdare utvecklare och nöjdare användare.

Angular 9

Här finns en översikt över Angular 9.

De viktigaste höjdpunkterna är bland annat:

• Inbyggda Angular-funktioner
• Mogen utveckling med Angular
• Förstå Angular View Engines
• Angular Ivy löser långvariga problem
• Angular Ivy och mobiler
• Selector-less Directives
• Angular Diagnostics Improvements
• Internationalisering med Angular Ivy
• DI och Type-Safe i Angular 9
• Dependency Injection Ändringar i Angular Core
• Angular Benchmarks (Angular 8.2.7 vs. 9.0.0.0-next.5)

Angular 10

Angular version 10.0.0 släpptes i slutet av juni 2020. Angular 10 är en större version och innehåller ändringar som till exempel en ny valmöjlighet för datumintervall i Angular Material, uppgradering av TypeScript-versioner, uppdateringar av biblioteksversioner med mera.

Nya funktioner inkluderar:

• Ngtsc Compiler Interface
• Configure Async Timeouts
• Stale Lock File Reporting
• Lazy Computation of basePaths
• Sammanslagning av översättningsfiler
• Explicit mappning

Angular 11

Angular version 11.0.0 släpptes i november 2020. Den större versionen av Angular 11 innehåller uppdateringar i hela plattformen, inklusive CLI och ramverket för komponenter.

Väsentliga funktioner är bland annat:

• Snabbare byggnationer med TypeScript 4.0
• Component Test Harnesses
• ESLint-uppdateringar
• Uppdaterad Language Service Preview
• Uppdaterat stöd för Hot Module Replacement (HMR)
• Förbättrade rapporter och loggning
• Automatisk teckensnittsinlärning

Angular’s Past, Present, and Future

Om du har använt Angular från dess tidiga dagar ända fram till nu, så grattis! Även om det har funnits gott om grova punkter har vi till slut fått ett snabbt och modernt ramverk som är roligt att använda.

Om du har varit AngularJS-utvecklare men gått över till React, Vue eller något annat, uppmanar jag dig att ge Angular en ny titt. Det är värt din tid, även om du bestämmer dig för att hålla dig till det du använder nu.

Och om du aldrig har använt Angular alls, varför inte ge det en chans?

Vi har just varit på en tur i virvelvind genom Angulars förflutna, nutid och framtid. Utan tvekan har det varit en rejäl resa. Oavsett din Angular-bakgrund hoppas jag att du har njutit av rundturen!

Vilket ramverk arbetar du med och varför? Om du har frågor eller kommentarer får du gärna skriva dem nedan.

Söker du ramverksoberoende UI-komponenter? GrapeCity har en komplett uppsättning JavaScript UI-komponenter, inklusive datagaller, diagram, mätare och inmatningskontroller. Vi erbjuder också kraftfulla kalkylarkskomponenter, rapporteringskontroller och förbättrade presentationsvyer. Vi har djupt stöd för Angular (liksom React och Vue) och är dedikerade till att utöka våra komponenter för användning i moderna JavaScript-ramverk.