An Angular Roadmap – The Past, Present, and Future of Angular

Angular Updates: What’s New in Version 11

Vanaf november 2020 is Angular versie 11.0.0 nu beschikbaar. Hoewel deze release veel updates voor het platform brengt, omvatten de belangrijkste functies snellere builds met TypeScript 4.0, component testharnassen, en ESLint-updates.

Paleolithic JavaScript – SproutCore

In het begin was er SproutCore. Het was het eerste uitgebreide JavaScript framework gericht op het eenvoudig bouwen van desktop-kwaliteit single-page web apps. Het is niet dat dit niet eerder mogelijk was. Toen Google Gmail uitbracht, liet het de wereld zien dat webapps echt complexe desktoptoepassingen konden vervangen. Google heeft zelfs de Closure toolkit open-sourced-een set van bibliotheken en een optimaliserende compiler die het heeft gebruikt om Gmail te bouwen.

Het probleem was dat Google’s Closure tools niet erg ontwikkelaar-vriendelijk waren. Ze leunden zwaar op Java, waardoor webontwikkelaars die gewend waren met JavaScript, PHP, Ruby en Python te werken, zich van hen vervreemdden. Gmail was een geweldige demonstratie van wat mogelijk was, maar het ontwikkelen van soortgelijke toepassingen voelde voor velen nog steeds buiten bereik.

Sommige moedige ontwikkelaars slaagden erin om verbazingwekkende single page apps aan elkaar te rijgen met behulp van een combinatie van jQuery, duct tape, en hoop. Terwijl deze apps er geweldig uitzagen voor eindgebruikers, voor de ontwikkelaars die eraan werkten, veranderden de apps al snel in kolossale stapels technische schuld waardoor het dev-team ’s ochtends bang was om naar het werk te gaan.

Als gevolg hiervan begonnen een paar ondernemende ontwikkelaars te werken aan frameworks die Gmail-achtige apps binnen het bereik van webontwikkelaars overal zouden brengen. SproutCore was de eerste van deze frameworks die van de grond kwam. Het kwam met een complete set van widgets die het mogelijk maakten om complexe web applicaties te bouwen zonder zelfs maar HTML of CSS aan te raken.

Dit was uiteindelijk geweldig voor voormalige desktop ontwikkelaars die schoppend en schreeuwend naar het web waren gesleept. Verschillende andere frameworks doken op met vergelijkbare doelen; GWT en Cappuccino waren de meest prominente. Deze frameworks vermeden zelfs JavaScript door andere talen te transponeren naar JS. Nogmaals, dit was geweldig voor desktop ontwikkelaars. Maar het liet gepassioneerde web-ontwikkelaars in de kou staan en gaf ze het gevoel dat hun hard bevochten HTML, CSS, en JavaScript vaardigheden niet waardevol waren.

Dit liet een opening voor een framework dat echt het web omarmde, in plaats van te proberen er overheen te pleisteren en te doen alsof het iets anders was. Een paar vroege raamwerken (Backbone en Knockout) verscheen, en behaalde een matige mate van succes. Ember verscheen ook rond deze tijd. Het nam SproutCore, stripte het tot op zijn botten, en probeerde het te herbouwen tot iets echt web-vriendelijk. Ember wilde de Six Million Dollar Man van de JavaScript-wereld zijn: beter, sterker en sneller herbouwd.

Geen van deze frameworks schoot omhoog in populariteit. De wereld wachtte op iets beters. In 2010, dat iets beter verscheen – het werd Angular genoemd.

De Gouden Eeuw van Angular

Nog voordat Angular versie 1.0 was uitgebracht, veroverde Angular de front-end ontwikkelwereld stormenderhand. Eindelijk hadden we een gebruiksvriendelijk JavaScript-framework dat HTML behandelde als een eersteklas burger. Ontwikkelaars en ontwerpers konden nu samenwerken om verbazingwekkende single-page applicaties te bouwen. Dit kwam als een opluchting voor ontwerpers, die zich hadden geërgerd en beledigd omdat oudere frameworks HTML en CSS hadden behandeld als gereedschappen voor barbaren, gereedschappen die geen beschaafde ontwikkelaar zou moeten aanraken.

Het eerste wat magisch leek voor ontwikkelaars die Angular voor het eerst probeerden was twee-weg data binding. Daarvoor hadden de meeste ontwikkelaars dit soort data binding alleen gezien in desktop frameworks zoals WPF en Windows Forms. Het was geweldig om formulieren en andere UI-elementen te kunnen binden aan JavaScript-modelobjecten. Hoewel bidirectionele gegevensbinding bij overmatig gebruik tot prestatieproblemen kon leiden, ontdekten teams die het oordeelkundig gebruikten dat Angular hen in staat stelde complexe front-end applicaties veel sneller te maken dan ooit tevoren.

Angular bleek populair te zijn voor meer dan alleen het eenvoudig binden van gegevens aan HTML-elementen. Angular-richtlijnen boden een eenvoudige manier om herbruikbare HTML + CSS-componenten te maken. Hoewel andere JavaScript-frameworks dit vóór Angular boden, was Angular de eerste die extreem populair werd. Herbruikbare componenten waren al lang in gebruik in server-side frameworks. ASP.NET user controls en gedeeltelijke sjablonen in Rails en Django zijn maar een paar
voorbeelden.

Ten slotte maakte Angular dependency injection populair in de front-end ontwikkelingswereld. Dependency injection was al lang populair in bedrijfsapplicaties, wat misschien de reden is waarom het niet was aangeslagen in de JavaScript-wereld. Front-end ontwikkelaars zijn al lang afkerig van wat zij zien als nodeloos complexe ontwerp-patronen voor bedrijfssoftware. Deze zorg is niet zonder verdienste. Heb je ooit, tijdens het schrijven van een applicatie, tegen jezelf gezegd “Wat ik hier echt nodig heb is een “SimpleBeanFactoryAwareAspectInstanceFactory?”

Dependency injection heeft echter zijn waarde bewezen. En Angular heeft dependency injection makkelijk te gebruiken gemaakt voor een publiek dat het in het verleden niet veel had gebruikt. Heb je een HTTP client nodig? Of misschien wil je wat animatie doen? Geen probleem. Angular had daar ingebouwde services voor. Vraag er gewoon om, en Angular injecteert ze in je componenten. Je hoeft zelf niets te instantiëren.

Of misschien wilde u gebruik maken van window of location objecten van de browser, zonder het onmogelijk te maken uw componenten buiten de browser te testen? Angular had je ook daar gedekt, met zijn ingebouwde $window en $location services. Tijdens runtime, zou je de browser objecten krijgen die je verwachtte. En bij het uitvoeren van unit tests server-side in Node.js, kon je mock services doorgeven aan je componenten om ervoor te zorgen dat ze zich gedroegen zoals verwacht in verschillende scenario’s.

Als dit alles nog niet genoeg was, maakte Angular het ook eenvoudig om je eigen services te registreren en te injecteren. Voor ontwikkelaars die gewend waren om al hun gegevens te binden aan het DOM en hopen op het beste, dit was geweldig. Als je een nieuwe front-end app aan het schrijven was die API’s opriep die je bedrijf veel geld zouden kosten als ze te vaak werden gebruikt, zou je waarschijnlijk liever van tevoren tests kunnen schrijven om ervoor te zorgen dat je applicatie niet iets probeert te doen zoals het 800 miljoen keer aanroepen van de Twilio API.

Dus maak je een Twilio service die tijdens runtime wordt geïnjecteerd. Op het moment van testen, zou je een mock service die de kosten van elke API-oproep die uw aanvraag probeert te maken registreert. Je zou tests schrijven die veel voorkomende gebruiksscenario’s dekken en ervoor zorgen dat deze scenario’s er niet in resulteren dat je bedrijf een 7-cijferige rekening ontvangt. Over het algemeen vonden de meeste ontwikkelaars dat Angular directives in combinatie met dependency injection het mogelijk maakten om modulaire, testbare front-end applicaties te schrijven met behulp van beproefde software engineering technieken. Veel ontwikkelteams besloten dat dit resulteerde in een gelukkige gang van zaken, en besloten om all-in te gaan op Angular.

De neergang van Angular? The Rise of React

Hoewel het meestal goed ging in de wereld van Angular, was het niet allemaal zonneschijn en lollies. Ontwikkelaars kregen te maken met ernstige prestatieproblemen wanneer ze te veel modelobjecten aan te veel DOM-elementen probeerden te koppelen. Sommige toepassingen vertraagden tot een kruipende beweging. Directe aanroepen naar $digest en andere zwarte-magie tovenarij begon nodig te worden om acceptabele prestaties te bereiken. Rond dezelfde tijd verscheen een nieuwe uitdager: React. Aanvankelijk leek React geen groot gevaar te vormen voor Angular. Die mafkezen van React hadden immers de moeite genomen om JSX uit te vinden, wat veel leek op een manier om markup in je code te mengen. Hadden we niet veel moeite gedaan om templating talen uit te vinden met de expliciete reden om het mengen van markup en code te voorkomen?

Zo bleek, React’s aanpak was behoorlijk populair in de front-end ontwikkelingsgemeenschap. Het is echter niet razend populair geworden. Angular was nog steeds dominant, en het leek erop dat dat zo zou blijven. Totdat de populariteit van Angular een flinke schop onder de tanden kreeg van een onverwachte bron: het Angular-team zelf.

De introductie van Angular 2

Angular 2 werd voor het eerst aangekondigd op de ng-europe conferentie in 2014. De plannen van het Angular-team kwamen op zijn zachtst gezegd als een schok voor de Angular-gemeenschap. De reactie van Angular ontwikkelaars was snel en negatief… en niet zonder reden. Angular 2 zou zich ontdoen van veel vertrouwde concepten uit Angular 1, de introductie van een nieuwe, incompatibele templating taal (en oh, door de manier waarop) zou ook worden geprogrammeerd met behulp van een geheel nieuwe taal.

AngularJS

Hoewel zowel Angular 1 als Angular 2 ‘Angular’ werden genoemd, waren het in werkelijkheid heel verschillende frameworks met een paar dingen gemeen. Om verwarring te voorkomen, begon het Angular-team naar de oude versie van Angular te verwijzen als ‘AngularJS’, en naar de nieuwe versie als simpelweg ‘Angular’. Dit is intuïtief logisch omdat AngularJS in JavaScript is geschreven, en Angular niet. Om het onderscheid tussen de frameworks duidelijk te houden, zal ik vanaf dit punt naar Angular 1 verwijzen als AngularJS.

Als gevolg van dit alles, verloren AngularJS-ontwikkelaars het vertrouwen in de toekomst van het framework. Ze dreigden over te stappen op een nieuw framework voor toekomstige projecten, en dat is precies wat velen van hen deden. React was de grootste begunstigde van de massale uittocht uit AngularJS.

Hoewel React niet zo veel deed als AngularJS, was dat in zekere zin positief. Als je een view library gebruikt die niet alles plus de gootsteen probeert te omvatten, is het een stuk moeilijker voor de ontwikkelaars van die library om in de toekomst het kleed onder je uit te trekken. In het begin was het gebruik van React een beetje lastig in vergelijking met AngularJS. Je moest een lappendeken van bibliotheken in elkaar knutselen om de functionaliteit te dekken die AngularJS uit de doos bood.

Vele teams zagen dit als een goede manier om risico’s te verminderen, omdat het onwaarschijnlijk was dat de ontwikkelaars van al die bibliotheken zouden besluiten om achterwaarts incompatibele brekende wijzigingen op hetzelfde moment aan te brengen, wat in wezen is wat Angular had gedaan.

De opkomst van Vue

Om de ellende van AngularJS te verergeren, verscheen een ander framework genaamd Vue ongeveer op hetzelfde moment dat het drama over Angular 2 zich afspeelde. Vue was geïnspireerd door AngularJS, maar had als doel om het te vereenvoudigen en te ontdoen van wat de maker van Vue zag als onnodige complexiteit (dus Vue voelde heel vertrouwd aan voor bestaande AngularJS ontwikkelaars). Vue bood een veilige haven voor veel AngularJS-ontwikkelaars die niet wilden overstappen naar React.

Dit betekent niet dat AngularJS-ontwikkelaars niet geduldig zaten te wachten op het verschijnen van Angular 2. Maar het is duidelijk dat er een massale uittocht was van AngularJS naar React en Vue vanwege de onzekerheid die de plannen voor Angular 2 veroorzaakten.

Opgestaan uit de as met Angular 2

Eindelijk werd Angular 2 uitgebracht. Zoals verwacht, werden veel bekende concepten van AngularJS afgeschaft, maar een paar van de beste onderdelen bleven behouden, zoals services en dependency injection. Gelukkig voor de geestelijke gezondheid van ontwikkelaars, Angular gebruikt gewoon TypeScript en niet een vork zoals oorspronkelijk gepland.

Om het nog verwarrender te maken, handhaafde het Angular-team een vork van het nieuwe framework dat de programmeertaal Dart gebruikte in plaats van TypeScript. Aanvankelijk werden de TypeScript- en Dart-versies synchroon ontwikkeld, gegenereerd vanuit een enkele codebase. Uiteindelijk besloten de TS- en Dart-versies van Angular hun eigen weg te gaan, en Angular Dart bestaat nu op zichzelf.

Zelfs met deze verwarring, begon de populariteit van Angular weer te stijgen na de Angular 2-release. Het gebeurde langzaam. Zoals vaak gebeurt in softwareontwikkeling, verschoven trends. Ontwikkelaars realiseerden zich dat een groot, batterij-included framework eigenlijk nuttig zou kunnen zijn. Immers, als je applicatie groot genoeg wordt, heb je uiteindelijk al die batterijen nodig.

Met name ontwikkelaars in het bedrijfsleven begonnen terug te keren naar Angular. Dit is logisch. Meestal, als je een enterprise web app begint, weet je dat het complex gaat worden. Het heeft geen zin om te beginnen met een kleine MVP als je weet vanaf het begin alle 87 dingen die uw applicatie gaat worden verwacht om te doen.

Waar is Angular 3?

Hoewel Angular 2 niet perfect was, begonnen veel ontwikkelaars van complexe webapplicaties zich te realiseren dat het nieuwe-en-verbeterde Angular goed paste bij hun behoeften. Gelukkig voor hen had Angular een aantal opwindende verbeteringen in petto. Belangrijker nog, het Angular-team toonde aan dat het consequent nieuwe versies van het framework kon publiceren met weinig brekende veranderingen tussen versies

In een zet die op dat moment vreemd leek, besloot het Angular-team om versie 3 volledig over te slaan en over te gaan naar versie 4. Dit werd gedaan met een goede reden: het team dat werkte aan Angular’s router pakket had al doorgezet en versie 3 uitgebracht, terwijl de rest van Angular nog steeds op versie 2.3 zat. Ze besloten om alle Angular package versies synchroon te houden voor de toekomst, en om alles naar versie 4 te brengen voor de volgende release was de makkelijkste manier om dit te bereiken.

Angular 4

Angular 4 had een aantal belangrijke wijzigingen, waaronder toegevoegde compilatie vooraf, wat resulteerde in kleine productie JavaScript-bundels en een kortere laadtijd van applicaties. Ondersteuning voor server-side rendering werd toegevoegd, wat een boost was voor teams die hun app van tevoren wilden renderen om de initiële laadprestaties te verbeteren. Veel andere verbeteringen werden toegevoegd in het hele framework, maar het upgraden van apps van Angular 2 naar 4 was in de meeste gevallen snel en pijnloos.

Angular 4.3 en Angular 5

Angular 4.3 voegde een nieuwe HTTP-client toe die gemakkelijker te gebruiken was dan de oude HTTP-service. In Angular 5 werd de oude HTTP service afgeschreven en zou in de volgende release worden afgeschaft. Ondanks dit ongemak was er relatief weinig gemor omdat de upgrade in de meeste gevallen rechttoe rechtaan was. Angular 5 voegde ook betere internationalisatie ondersteuning en verdere build optimalisaties toe.

Angular 6 en 7

Angular 6 en 7 waren voor sommige ontwikkelaars teleurstellend. Er waren geen grote veranderingen, maar wel veel kleine verbeteringen in de kwaliteit van het leven, met name in de Angular CLI-tooling. Het afnemende aantal zichtbare wijzigingen is geen indicatie dat het Angular-team is gestopt met innoveren. In plaats daarvan laat het zien dat het framework volwassen is, zodat het ontwikkelteam nu vrij is om meer werk achter de schermen te doen, bugs te repareren en de prestaties te verbeteren.

De stabiliteit van het framework sinds de release van Angular 2 heeft sommige old-school AngularJS-ontwikkelaars terug in de Angular-wereld getrokken. Het heeft ook de aandacht getrokken van enterprise ontwikkelteams. Als je enterprise apps bouwt die tientallen jaren mee kunnen gaan, is het ideaal om een framework te gebruiken dat nieuwe releases krijgt op een voorspelbaar schema, maar niet te snel verandert. Een ontwikkelaar die alleen Angular 2 heeft gebruikt, kan binnen een paar minuten aan de slag en bijdragen aan een Angular 7 app.

Angular 8 en Angular Ivy

En dat brengt ons bij vandaag. Zoals we hebben gezien, heeft Angular een lange weg afgelegd. Het is van geliefd bij webontwikkelaars naar verguisd naar bewonderd gegaan, hoewel het nog niet weer geliefd is zoals het was in zijn begindagen.

Aan de horizon hebben we Angular 8. Een ton van het werk is gedaan in Angular 8 om het gemakkelijk te gebruiken te maken met het Bazel build systeem, wat absoluut geweldig nieuws is voor alle 3 ontwikkelaars die het gebruiken buiten Google. Lees over Angular 8 veranderingen.

Maar nog spannender is dat het Angular-team hard werkt aan een nieuwe render genaamd Angular Ivy. Het is bedoeld als een drop-in vervanging voor de huidige rendered. Voor het grootste deel, zullen de huidige apps geen wijzigingen hoeven aan te brengen om Angular Ivy te gebruiken.

Als Angular Ivy een drop-in vervanging is, waarom zouden ontwikkelaars zich dan druk maken? Twee belangrijke redenen: snelheid, en bundelgrootte-twee zeer belangrijke zorgen. Een paar jaar lang leek het alsof webontwikkelaars een beetje gek waren geworden. Teams verscheepten JavaScript-bundels van 5 MB, 10 MB of zelfs meer, en dachten dat dit geen probleem was. De programma’s werkten immers perfect op de i7-gevoede MacBook Pro’s van de ontwikkelaars, dus ze zouden voor iedereen goed moeten werken, toch?

In de echte wereld draait helaas niet iedereen op de nieuwste en beste hardware. Honderden miljoenen mensen internetten alleen op oudere Android-telefoons met iets meer verwerkingskracht dan een aardappel, via internetverbindingen die slechts iets sneller zijn dan een inbelverbinding. Voor deze gebruikers duurt het een eeuwigheid om een enorme JavaScript-bundel te laden, en nog langer voor hun toestel om te parsen en uit te voeren. Zelfs in minder extreme gevallen zijn er talloze gebruikers over de hele wereld die niet de nieuwste en beste hardware gebruiken. Voor hen zijn massieve JavaScript apps bruikbaar (maar pijnlijk).

Angular Ivy

De Angular Ivy renderer zal op verschillende manieren helpen:

1. Het wordt geschreven met het oog op efficiëntie, dus het zal dezelfde taken volbrengen terwijl het veel minder CPU-instructies uitvoert. Dit zal zowel de levensduur van de batterij en de geestelijke gezondheid van gebruikers met minder-dan-krachtige apparaten te verbeteren.
2. De renderer zal op een veel meer modulaire manier worden geschreven dan de huidige renderer. Dit maakt het veel meer vatbaar voor tree-shaking en het verwijderen van dode code. Als gevolg hiervan zal je productie JavaScript bundel alleen de code bevatten die nodig is om je applicatie te draaien, in plaats van alles plus het aanrecht te bundelen zoals vaak gebeurt met de huidige renderer.
3. Naast de bundel-omvang reductie en verbeterde render snelheid, heeft Angular Ivy nog een paar quality-of-life verbeteringen voor Angular ontwikkelaars. Rebuild tijden zijn aanzienlijk sneller. Dus als je je app in de ontwikkelmodus draait en wacht tot je wijzigingen verschijnen, zul je nu veel minder tijd kwijt zijn aan wachten.
4. Template-type checking is verbeterd, wat betekent dat je meer fouten zult vangen tijdens het compileren in plaats van tijdens runtime. Runtime template bugs zijn vervelend, omdat ze ofwel bijten je tijdens het testen, of ze bijten uw gebruikers wanneer ze proberen om uw app te gebruiken.
5. De Angular Ivy template compiler zal code genereren die leesbaar is voor mensen, wat de huidige View Engine compiler niet doet. Dit zal van pas komen bij het opsporen van lastige template bugs.

Het netto resultaat: kleinere apps, snellere apps, gelukkigere ontwikkelaars, en gelukkigere gebruikers.

Angular 9

Hier is een overzicht van Angular 9.

De belangrijkste hoogtepunten zijn:

• Built-in Angular Features
• Mature Development with Angular
• Understanding Angular View Engines
• Angular Ivy Solves Long-Standing Problems
• Angular Ivy and Mobile
• Selector-less Directives
• Angular Diagnostics Verbeteringen
• Internationalisatie met Angular Ivy
• DI en Type-Safe in Angular 9
• Dependency Injection Veranderingen in Angular Core
• Angular Benchmarks (Angular 8.2.7 vs. 9.0.0-next.5)

Angular 10

Angular versie 10.0.0 werd eind juni 2020 uitgebracht. Angular 10, een belangrijke release, bevat wijzigingen zoals een nieuwe datumbereikkiezer in Angular Material, het upgraden van TypeScript-versies, updates van bibliotheekversies en meer.

Nieuwe functies zijn onder andere:

• Ngtsc Compiler Interface
• Configure Async Timeouts
• Stale Lock File Reporting
• Lazy Computation of basePaths
• Merging Translation Files
• Explicit Mapping

Angular 11

Angular versie 11.0.0 werd uitgebracht in november 2020. De grote release van Angular 11 biedt updates voor het hele platform, waaronder de CLI en het components framework.

Belangrijke functies zijn:

• Snellere builds met TypeScript 4.0
• Component Test Harnesses
• ESLint Updates
• Updated Language Service Preview
• Updated Hot Module Replacement (HMR) Support
• Betere rapportages en logging
• Automatische Font Inliining

Angular’s Past,

Als u Angular al vanaf het prille begin tot nu gebruikt, gefeliciteerd! Hoewel er veel moeilijke momenten zijn geweest, hebben we uiteindelijk een snel, modern framework dat leuk is om te gebruiken.

Als je een AngularJS ontwikkelaar was, maar bent overgestapt op React, Vue, of iets anders, dan moedig ik je aan om Angular nog eens te bekijken. Het is je tijd waard, zelfs als je besluit te blijven bij wat je nu gebruikt.

En als je Angular helemaal nog nooit hebt gebruikt, waarom zou je het dan niet eens proberen?

We zijn zojuist op een wervelende tour door het verleden, heden en de toekomst van Angular geweest. Zonder twijfel, het is een hele rit geweest. Ongeacht je Angular achtergrond, ik hoop dat je genoten hebt van de tour!

Met welk framework werk je en waarom? Als je vragen of opmerkingen hebt, laat ze dan hieronder achter.

Op zoek naar framework-agnostische UI componenten? GrapeCity heeft een complete set JavaScript UI componenten, waaronder data grids, grafieken, meters en input controls. Wij bieden ook krachtige spreadsheet-componenten, rapportage-elementen en verbeterde presentatieweergaven. We hebben diepgaande ondersteuning voor Angular (evenals React en Vue) en zijn toegewijd aan het uitbreiden van onze componenten voor gebruik in moderne JavaScript frameworks.