An Angular Roadmap – Angularin menneisyys, nykyisyys ja tulevaisuus

Angular Updates: Mitä uutta versiossa 11

Marraskuussa 2020 Angularin versio 11.0.0 on nyt saatavilla. Vaikka tämä julkaisu tuo monia päivityksiä alustaan, merkittävimpiä ominaisuuksia ovat nopeampi rakentaminen TypeScript 4.0:n kanssa, komponenttien testivaljaat ja ESLint-päivitykset.

Paleoliittinen JavaScript – SproutCore

Alussa oli SproutCore. Se oli ensimmäinen kattava JavaScript-kehys, jonka tarkoituksena oli helpottaa työpöytätasoisten yksisivuisten verkkosovellusten rakentamista. Kyse ei ole siitä, etteikö tämä olisi ollut mahdollista jo aiemmin. Kun Google julkaisi Gmailin, se näytti maailmalle, että verkkosovellukset voivat todella korvata monimutkaiset työpöytäsovellukset. Google jopa julkisti Closure-työkalupaketin – joukon kirjastoja ja optimoivan kääntäjän, jota se käytti Gmailin rakentamiseen.

Ongelmana oli, että Googlen Closure-työkalut eivät olleet kovin kehittäjäystävällisiä. Ne tukeutuivat vahvasti Javaan, mikä vieraannutti web-kehittäjiä, jotka olivat tottuneet työskentelemään JavaScriptin, PHP:n, Rubyn ja Pythonin kanssa. Gmail oli loistava osoitus siitä, mitä oli mahdollista tehdä, mutta vastaavien sovellusten kehittäminen tuntui edelleen monista mahdottomalta.

Jotkut rohkeat kehittäjät onnistuivat kokoamaan hämmästyttäviä yhden sivun sovelluksia jQueryn, ilmastointiteipin ja toivon yhdistelmällä. Vaikka nämä sovellukset näyttivät loppukäyttäjien silmissä hämmästyttäviltä, niiden parissa työskentelevien kehittäjien mielestä sovellukset muuttuivat nopeasti valtaviksi teknisen velan kasoiksi, jotka saivat kehittäjätiimin pelkäämään aamulla töihin lähtöä.

Tämän seurauksena muutamat yritteliäät kehittäjät alkoivat työskennellä kehysten parissa, jotka toisivat Gmailin kaltaiset sovellukset helposti kaikkien web-kehittäjien ulottuville. SproutCore oli ensimmäinen näistä kehyksistä, joka lähti liikkeelle. Se sisälsi täydellisen joukon widgettejä, joiden avulla oli mahdollista rakentaa monimutkaisia verkkosovelluksia koskematta edes HTML:ään tai CSS:ään.

Tämä oli lopulta loistava asia entisille työpöytäkehittäjille, jotka oli raahattu potkien ja huutaen verkkoon. Useita muitakin kehyksiä ponnahti esiin samankaltaisilla tavoitteilla; GWT ja Cappuccino olivat merkittävimpiä. Nämä kehykset jopa välttivät JavaScriptin kääntämällä muita kieliä JS:ksi. Tämäkin oli hienoa työpöytäkehittäjille. Mutta se jätti intohimoiset web-kehittäjät kylmäksi ja sai heidät tuntemaan, että heidän vaivalla hankitut HTML-, CSS- ja JavaScript-taitonsa eivät olleet arvokkaita.

Tämä jätti aukon kehykselle, joka todella omaksui webin sen sijaan, että yrittäisi kipsata sen päälle ja teeskennellä, että se oli jotain muuta. Pari varhaista kehystä (Backbone ja Knockout) ilmestyi, ja ne saavuttivat kohtalaista menestystä. Myös Ember ilmestyi näihin aikoihin. Se otti SproutCoren, riisui sen luitaan myöten ja yritti rakentaa siitä jotain todella web-ystävällistä. Ember halusi olla JavaScript-maailman kuuden miljoonan dollarin mies: parempi, vahvempi ja nopeampi.

Kumpikaan näistä kehyksistä ei noussut räjähdysmäisesti suosioon. Maailma odotti jotain parempaa. Vuonna 2010 tuo jotain parempaa ilmestyi – sen nimi oli Angular.

Angularin kulta-aika

Jopa ennen kuin Angularin versio 1.0 oli julkaistu, Angular valloitti front-end-kehitysmaailman. Vihdoinkin meillä oli helppokäyttöinen JavaScript-kehys, joka kohteli HTML:ää ensimmäisen luokan kansalaisena. Kehittäjät ja suunnittelijat saattoivat nyt työskennellä yhdessä rakentaakseen upeita yksisivuisia sovelluksia. Tämä oli helpotus suunnittelijoille, joita oli ärsyttänyt ja loukannut se, että vanhemmat kehykset olivat kohdelleet HTML:ää ja CSS:ää barbaarien työkaluina, joihin sivistyneen kehittäjän ei tarvinnut koskea.

Ensimmäinen asia, joka vaikutti maagiselta kehittäjille, jotka kokeilivat Angularia ensimmäistä kertaa, oli kaksisuuntainen datan sitominen. Tätä ennen useimmat kehittäjät olivat nähneet tällaista datan sitomista vain työpöytäkehyksissä, kuten WPF:ssä ja Windows Formsissa. Oli hienoa pystyä sitomaan lomakkeita ja muita käyttöliittymäelementtejä JavaScript-malliobjekteihin. Vaikka kaksisuuntainen datan sitominen saattoi aiheuttaa suorituskykyongelmia, kun sitä käytettiin liikaa, tiimit, jotka käyttivät sitä harkitusti, huomasivat, että Angularin avulla he pystyivät luomaan monimutkaisia front-end-sovelluksia paljon nopeammin kuin koskaan ennen.

Angular osoittautui suosituksi muutenkin kuin vain tietojen helpon sitomisen vuoksi HTML-elementteihin. Angular-direktiivit tarjosivat helpon tavan luoda uudelleenkäytettäviä HTML + CSS-komponentteja. Vaikka muut JavaScript-kehykset tarjosivat tätä ennen Angularia, Angular oli ensimmäinen, josta tuli erittäin suosittu. Uudelleenkäytettäviä komponentteja oli jo pitkään käytetty palvelinpuolen kehyksissä. ASP.NET-käyttäjäohjaimet ja osittaiset mallit Railsissa ja Djangossa ovat vain muutamia
esimerkkejä.

Viimein Angular teki riippuvuusinjektiosta suosittua front-end-kehitysmaailmassa. Riippuvuusinjektio oli jo pitkään ollut suosittua yrityssovelluksissa, minkä vuoksi se ei ehkä ollut saanut jalansijaa JavaScript-maailmassa. Front-end-kehittäjät ovat jo pitkään suhtautuneet vastenmielisesti tarpeettoman monimutkaisiksi koettuihin yritysohjelmistojen suunnittelumalleihin. Tämä huoli ei ole aiheeton. Oletko koskaan sovellusta kirjoittaessasi miettinyt itsellesi: ”Mitä minä todella tarvitsen tässä, on ”SimpleBeanFactoryAwareAspectInstanceFactory?”

Riippuvuusinjektio on kuitenkin osoittanut arvonsa. Ja Angular teki riippuvuusinjektiosta helppokäyttöisen yleisölle, joka ei ollut käyttänyt sitä paljon aiemmin. Tarvitsetko HTTP-asiakasta? Tai ehkä haluaisit tehdä animaatioita? Se ei ole ongelma. Angularissa oli niitä varten sisäänrakennetut palvelut. Kysy vain niitä, ja Angular injektoi ne komponentteihisi. Mitään ei tarvinnut instansoida itse.

Vai haluaisitko kenties käyttää selaimen window– tai location-objekteja ilman, että komponenttien yksikkötestaaminen selaimen ulkopuolella olisi mahdotonta? Angular kattoi sinut tässäkin asiassa sisäänrakennetuilla $window- ja $location-palveluillaan. Suoritusaikana saisit odottamasi selainobjektit. Ja kun suoritat yksikkötestejä palvelinpuolella Node.js:ssä, voit siirtää mock-palveluja komponentteihisi varmistaaksesi, että ne toimivat odotetulla tavalla eri skenaarioissa.

Jos tämä kaikki ei olisi vielä riittänyt, Angular teki myös omien palveluiden rekisteröinnistä ja injektoinnista helppoa. Kehittäjille, jotka olivat tottuneet sitomaan kaiken datan DOMiin ja toivomaan parasta, tämä oli mahtavaa. Jos olisit kirjoittamassa uutta front-end-sovellusta, joka kutsui API:ita, jotka maksaisivat yrityksellesi paljon rahaa, jos niitä käytettäisiin liikaa, haluaisit luultavasti mieluummin kirjoittaa testejä etukäteen varmistaaksesi, että sovelluksesi ei yritä tehdä jotain sellaista kuin Twilio API:n kutsuminen 800 miljoonaa kertaa.

Luot siis Twilio-palvelun, joka injektoidaan ajonaikana. Testauksen aikana loisit mock-palvelun, joka tallentaa kustannukset jokaisesta API-kutsusta, jota sovelluksesi yrittää tehdä. Kirjoitat testit, jotka kattavat yleiset käyttöskenaariot, ja varmistat, että nämä skenaariot eivät johda siihen, että yrityksesi saa 7-numeroisen laskun. Kaiken kaikkiaan useimmat kehittäjät havaitsivat, että Angular-direktiivit yhdistettynä riippuvuusinjektioon mahdollistivat modulaaristen, testattavien front-end-sovellusten kirjoittamisen käyttäen hyväksi havaittuja ohjelmistotekniikoita. Monet kehitystiimit päättivät, että tämä johti onnelliseen tilanteeseen, ja päättivät panostaa Angulariin täysillä.

Angularin taantuma? The Rise of React

Vaikka asiat olivat enimmäkseen hyvin Angularin maailmassa, kaikki ei ollut pelkkää auringonpaistetta ja tikkareita. Kehittäjät alkoivat törmätä vakaviin suorituskykyongelmiin, kun he yrittivät sitoa liikaa malliobjekteja liian moneen DOM-elementtiin. Jotkin sovellukset hidastuivat. Suorat kutsut $digestiin ja muut mustan magian taikatoimet alkoivat olla tarpeen hyväksyttävän suorituskyvyn saavuttamiseksi. Samoihin aikoihin ilmestyi uusi haastaja: React. Aluksi React ei näyttänyt muodostavan liian suurta vaaraa Angularille. Olivathan nämä Reactin kummajaiset nähneet vaivaa keksiessään JSX:n, joka näytti paljolti tavalta sekoittaa koodiin merkintöjä. Emmekö olleet nähneet paljon vaivaa keksiä templatointikieliä nimenomaan siksi, että vältettäisiin merkintöjen ja koodin sekoittamista?

Kuten kävi ilmi, Reactin lähestymistapa oli aika suosittu front-end-kehittäjäyhteisössä. Se ei kuitenkaan noussut rakettimaisesti suosioon. Angular oli edelleen hallitseva, ja näytti siltä, että se pysyisi sellaisena. Kunnes Angularin suosio sai kunnon potkun hampaisiin odottamattomasta lähteestä: Angular-tiimiltä itseltään.

Angular 2:n esittely

Angular 2 julkistettiin ensimmäisen kerran ng-europe-konferenssissa vuonna 2014. Angular-tiimin suunnitelmat tulivat Angular-yhteisölle lievästi sanottuna shokkina. Angular-kehittäjien reaktio oli nopea ja negatiivinen… eikä syyttä. Angular 2 olisi hankkiutumassa eroon monista Angular 1:stä tutuista konsepteista, ottamassa käyttöön uuden, yhteensopimattoman templatointikielen (ja oho, muuten) olisi myös ohjelmoitu täysin uudella kielellä.

AngularJS

Vaikka sekä Angular 1:n että Angular 2:n nimi oli ”Angular”, todellisuudessa ne olivat hyvin erilaisia kehyksiä, joilla oli muutamia yhteisiä asioita. Sekaannusten välttämiseksi Angular-tiimi alkoi kutsua Angularin vanhaa versiota nimellä ’AngularJS’ ja uutta versiota yksinkertaisesti ’Angular’. Tämä on intuitiivisesti järkevää, koska AngularJS oli kirjoitettu JavaScriptillä ja Angular ei. Jotta kehysten välinen ero pysyisi selvänä, viittaan tästä eteenpäin Angular 1:een nimellä AngularJS.

Kaiken tämän seurauksena AngularJS:n kehittäjät menettivät uskonsa kehyksen tulevaisuuteen. He uhkasivat siirtyä tulevissa projekteissa uuteen kehykseen, ja juuri niin monet heistä tekivätkin. React oli suurin hyötyjä AngularJS:n joukkopakolaisuudesta.

Vaikka React ei tehnyt yhtä paljon kuin AngularJS, tavallaan se oli positiivista. Jos käytät view-kirjastoa, joka ei yritä sisällyttää kaikkea plus keittiön tiskiallas, on kyseisen kirjaston kehittäjien paljon vaikeampi vetää mattoa alta tulevaisuudessa. Alussa Reactin käyttö oli hieman hankalaa AngularJS:ään verrattuna. Jouduit kasaamaan kirjastojen tilkkutäkkiä vain kattaaksesi AngularJS:n tarjoaman toiminnallisuuden.

Monet tiimit pitivät tätä hyvänä tapana vähentää riskejä, koska oli epätodennäköistä, että kaikkien näiden kirjastojen kehittäjät päättäisivät tehdä taaksepäin yhteensopimattomia rikkovia muutoksia samaan aikaan, mitä Angular oli periaatteessa tehnyt.

Vuen ilmaantuminen

AngularJS:n murheiden lisäämiseksi toinen kehys nimeltä Vue ilmaantui suunnilleen samaan aikaan, kun Angular 2:n draama oli käynnissä. Vue oli saanut vaikutteita AngularJS:stä, mutta sen tavoitteena oli yksinkertaistaa sitä ja päästä eroon siitä, mitä Vuen luoja piti tarpeettomana monimutkaisuutena (joten Vue tuntui hyvin tutulta nykyisille AngularJS-kehittäjille). Vue tarjosi turvasataman monille AngularJS-kehittäjille, jotka eivät halunneet siirtyä Reactiin.

Tämä ei tarkoita, etteivätkö AngularJS-kehittäjät odottaneet kärsivällisesti Angular 2:n ilmestymistä. Mutta on selvää, että AngularJS:stä tapahtui joukkopako Reactiin ja Vueen Angular 2:n suunnitelmien aiheuttaman epävarmuuden vuoksi.

Rising From the Ashes with Angular 2

Viimein Angular 2 julkaistiin. Odotetusti se luopui monista AngularJS:stä tutuista konsepteista, mutta säilytti muutamia parhaita paloja, kuten palvelut ja riippuvuusinjektio. Kehittäjien mielenterveyden kannalta onneksi Angular käyttää pelkkää TypeScriptiä eikä haarautumista, kuten alun perin suunniteltiin.

Sekaannuksen lisäämiseksi Angular-tiimi ylläpiti uudesta kehyksestä haaraa, joka käytti Dart-ohjelmointikieltä TypeScriptin sijaan. Aluksi TypeScript- ja Dart-versioita kehitettiin synkronoidusti, yhdestä koodipohjasta tuotettuna. Lopulta Angularin TS- ja Dart-versiot päättivät kulkea omia teitään, ja Angular Dart on nyt olemassa omana itsenään.

Tästä sekaannuksesta huolimatta Angularin suosio alkoi jälleen kasvaa Angular 2:n julkaisun jälkeen. Se tapahtui hitaasti. Kuten ohjelmistokehityksessä usein tapahtuu, trendit muuttuivat. Kehittäjät tajusivat, että iso, akkuihin sisällytetty kehys saattoi oikeasti olla hyödyllinen. Loppujen lopuksi, kun sovelluksesi kasvaa tarpeeksi suureksi, päädyt itse asiassa tarvitsemaan kaikkia niitä akkuja.

Erityisesti yrityskehittäjät alkoivat siirtyä takaisin Angulariin. Tässä on järkeä. Yleensä, kun aloitat yritysverkkosovelluksen, tiedät, että siitä tulee monimutkainen. Ei ole mitään järkeä aloittaa pienellä MVP:llä, kun tiedät alusta asti kaikki 87 asiaa, joita sovellukseltasi odotetaan.

Missä on Angular 3?

Vaikka Angular 2 ei ollutkaan täydellinen, monet monimutkaisten web-sovellusten kehittäjät alkoivat ymmärtää, että uusi ja parannettu Angular sopi hyvin heidän tarpeisiinsa. Heidän onnekseen Angularissa oli luvassa jännittäviä parannuksia. Vielä tärkeämpää oli, että Angular-tiimi osoitti, että se pystyi johdonmukaisesti julkaisemaan uusia versioita kehyksestä siten, että versioiden välillä oli vain vähän rikkovia muutoksia

Tässä vaiheessa oudolta vaikuttaneessa liikkeessä Angular-tiimi päätti jättää version 3 kokonaan pois ja siirtyä versioon 4. Tähän oli hyvä syy: Angularin reititinpaketin parissa työskentelevä tiimi oli jo edennyt eteenpäin ja julkaissut version 3, kun taas Angularin muu osa oli vielä versiossa 2.3. He päättivät pitää kaikki Angular-pakettien versiot synkronoituina eteenpäin, ja kaiken siirtäminen versioon 4 seuraavaan julkaisuun oli helpoin tapa saavuttaa tämä.

Angular 4

Angular 4:ssä oli joitain merkittäviä muutoksia, muun muassa lisätty etukäteiskompilointi, mikä johti pieniin tuotannon JavaScript-paketteihin ja lyhyempään sovelluksen latausaikaan. Tuki palvelinpuolen renderöinnille lisättiin, mikä oli lisäys tiimeille, jotka halusivat renderöidä sovelluksensa etukäteen parantaakseen alkulatauksen suorituskykyä. Kehykseen lisättiin monia muita parannuksia, mutta sovellusten päivittäminen Angular 2:sta 4:ään oli useimmissa tapauksissa nopeaa ja vaivatonta.

Angular 4.3 ja Angular 5

Angular 4.3 lisäsi uuden HTTP-asiakkaan, joka oli helpompi käyttää kuin vanha HTTP-palvelu. Angular 5:ssä vanha HTTP-palvelu oli vanhentunut ja siitä luovuttaisiin seuraavassa julkaisussa. Tästä epäkohdasta huolimatta nurinaa oli suhteellisen vähän, koska päivitys oli useimmissa tapauksissa suoraviivainen. Angular 5 lisäsi myös paremman kansainvälistämistuen ja lisää build-optimointeja.

Angular 6 ja 7

Angular 6 ja 7 olivat pettymys joillekin kehittäjille. Suuria muutoksia ei ollut, mutta monia pieniä elämänlaadun parannuksia, erityisesti Angular CLI -työkaluihin. Näkyvien muutosten määrän väheneminen ei ole merkki siitä, että Angular-tiimi olisi lopettanut innovoinnin. Sen sijaan se osoittaa, että kehys on kypsä, joten kehitystiimi voi nyt tehdä enemmän työtä kulissien takana, korjata virheitä ja parantaa suorituskykyä.

Kehyksen vakaus Angular 2:n julkaisun jälkeen on houkutellut joitakin vanhan koulukunnan AngularJS-kehittäjiä takaisin Angularin maailmaan. Se on myös herättänyt yritysten kehitystiimien huomion. Kun rakennat yrityssovelluksia, jotka voivat elää vuosikymmeniä, on ihanteellista käyttää kehystä, joka saa uusia julkaisuja ennustettavalla aikataululla mutta ei muutu liian nopeasti. Kehittäjä, joka on käyttänyt vain Angular 2:ta, voi olla valmiina ja osallistua Angular 7 -sovelluksen kehittämiseen muutamassa minuutissa.

Angular 8 ja Angular Ivy

Ja näin pääsemme tähän päivään. Kuten olemme nähneet, Angular on kulkenut pitkän matkan. Se on kulkenut web-kehittäjien rakastamasta halveksunnasta ihailuun, vaikkei sitä vielä rakasteta uudelleen niin kuin sen alkuaikoina.

Horisontissa on Angular 8. Angular 8:ssa on tehty valtavasti työtä, jotta sitä olisi helppo käyttää Bazelin build-järjestelmän kanssa, mikä on aivan mahtava uutinen kaikille 3 kehittäjille, jotka käyttävät sitä Googlen ulkopuolella. Lue Angular 8:n muutoksista.

Jännittävämpää on kuitenkin se, että Angular-tiimi työskentelee ahkerasti uuden renderoidun Angular Ivy -nimisen version parissa. Sen on tarkoitus olla drop-in korvaaja nykyiselle renderille. Suurimmaksi osaksi nykyisten sovellusten ei tarvitse tehdä mitään muutoksia käyttääkseen Angular Ivyä.

Jos Angular Ivy on drop-in korvaaja, miksi kehittäjien pitäisi välittää? Kaksi tärkeää syytä: nopeus ja nipun koko – kaksi erittäin tärkeää huolenaihetta. Muutaman vuoden ajan näytti siltä, että web-kehittäjät olivat tulleet hieman hulluiksi. Tiimit toimittivat 5 MB:n, 10 MB:n tai jopa suurempia JavaScript-paketteja ja ajattelivat, että tämä ei ole ongelma. Loppujen lopuksi sovellukset toimivat täydellisesti kehittäjien i7-käyttöjärjestelmällä varustetuissa MacBook Prossa, joten niiden pitäisi toimia hienosti kaikilla, eikö niin?

Valitettavasti reaalimaailmassa kaikilla ei ole käytössä uusinta ja parasta laitteistoa. Sadat miljoonat ihmiset käyttävät internetiä pelkästään vanhemmilla Android-puhelimilla, joissa on hieman enemmän prosessoritehoa kuin perunassa, internet-yhteyksien kautta, jotka ovat vain hieman nopeampia kuin dial-up. Näille käyttäjille valtavan JavaScript-paketin lataaminen kestää ikuisuuden, ja heidän laitteensa tarvitsee vielä kauemmin analysoida ja suorittaa se. Jopa vähemmän äärimmäisissä tapauksissa maailmassa on lukemattomia käyttäjiä, jotka eivät käytä uusinta ja parasta laitteistoa. Heille massiiviset JavaScript-sovellukset ovat käyttökelpoisia (mutta tuskallisia).

Angular Ivy

Angular Ivy -renderöijä auttaa monella tavalla:

1. Se on kirjoitettu tehokkuutta silmällä pitäen, joten se suoriutuu samoista tehtävistä suorittamalla paljon vähemmän suorittimen ohjeita. Tämä parantaa sekä akkukestoa että niiden käyttäjien mielenterveyttä, joilla on vähemmän tehokkaita laitteita.
2. Renderöijä kirjoitetaan paljon modulaarisemmin kuin nykyinen renderöijä. Tämä tekee siitä paljon helpommin puiden ravisteluun ja kuolleen koodin poistamiseen soveltuvan. Tämän seurauksena tuotantojakson JavaScript-paketti sisältää vain sen koodin, jota tarvitaan sovelluksen pyörittämiseen, sen sijaan, että se niputtaisi yhteen kaiken ja keittiön tiskialtaan, kuten nykyisellä renderöijällä usein tapahtuu.
3. Paketin koon pienentämisen ja paremman renderöintinopeuden lisäksi Angular Ivy -ohjelmassa on vielä muutama elämänlaadun parannus Angular-kehittäjille. Uudelleenrakennusajat ovat huomattavasti nopeampia. Jos siis käytät sovellustasi kehitystilassa ja odotat, että muutoksesi näkyvät, käytät nyt paljon vähemmän aikaa odotteluun.
4. Template-tyyppien tarkistusta on parannettu, mikä tarkoittaa, että saat enemmän virheitä kiinni jo kääntämisaikana eikä vasta suoritusaikana. Mallien ajonaikaiset virheet ovat ärsyttäviä, koska ne joko purevat sinua testauksen aikana tai ne purevat käyttäjiäsi, kun he yrittävät käyttää sovellustasi.
5. Angular Ivy -mallien kääntäjä tuottaa koodia, joka on ihmisen luettavissa, mitä nykyinen View Engine -kääntäjä ei tee. Tästä on hyötyä, kun yrität jäljittää vaikeita template-virheitä.

Nettotulos: pienemmät sovellukset, nopeammat sovellukset, tyytyväisemmät kehittäjät ja tyytyväisemmät käyttäjät.

Angular 9

Tässä on katsaus Angular 9:ään.

Tärkeimpiä kohokohtia ovat muun muassa:

• Sisäänrakennetut Angular-ominaisuudet
• Kypsä kehitys Angularilla
• Angular View Enginesin ymmärtäminen
• Angular Ivy ratkaisee pitkäaikaisia ongelmia
• Angular Ivy ja mobiililaitteet
• Valikoima-less Directives
• Angular Diagnostics Parannukset
• Kansainvälistäminen Angular Ivyllä
• DI ja Type-Safe Angular 9:ssä
• Dependency Injection Muutokset Angular Coreen
• Angular Benchmarks (Angular 8.2.7 vs. 9.0.0-next.5).)

Angular 10

Angularin versio 10.0.0 julkaistiin kesäkuun lopussa 2020. Angular 10 on merkittävä julkaisu, joka sisältää muutoksia, kuten uuden päivämäärävälin valitsimen Angular Materialissa, TypeScript-versioiden päivittämisen, kirjastojen versiopäivityksiä ja paljon muuta.

Uusia ominaisuuksia ovat mm:

• Ngtsc-kääntäjän rajapinta
• Asynkronisten aikakatkaisujen määrittäminen
• Vanhan lukitustiedoston raportointi
• Lazy Computation of basePaths
• Käännöstiedostojen yhdistäminen
• Explicit Mapping

Angular 11

Angularin versio 11.0.0 julkaistiin marraskuussa 2020. Angular 11:n pääversio tarjoaa päivityksiä koko alustalle, mukaan lukien CLI ja komponenttikehys.

Tärkeitä ominaisuuksia ovat:

• Nopeammat rakennukset TypeScript 4:n avulla.0
• Komponenttien testausvaljaat
• ESLint-päivitykset
• Päivitetty kielipalvelun esikatselu
• Päivitetty HMR-tuki (Hot Module Replacement)
• Parannetut raportoinnit ja kirjaukset
• Automaattinen fonttitiedostojen lisääminen

Angularin menneisyys, Present, and Future

Jos olet käyttänyt Angularia sen alkutaipaleelta aina tähän päivään asti, niin onnittelut! Vaikka vaikeuksia on ollut paljon, olemme päätyneet nopeaan, moderniin kehykseen, jota on hauska käyttää.

Jos olit AngularJS-kehittäjä, mutta siirryit Reactiin, Vueen tai johonkin muuhun, kannustan sinua katsomaan Angularia uudelleen. Se on aikasi arvoinen, vaikka päättäisitkin pysyä siinä, mitä käytät nyt.

Ja jos et ole koskaan käyttänyt Angularia lainkaan, miksi et kokeilisi sitä?

Olimme juuri pyörrematkalla Angularin menneisyydessä, nykyisyydessä ja tulevaisuudessa. Epäilemättä se on ollut melkoinen kyyti. Riippumatta Angular-taustastasi, toivottavasti nautit kierroksesta!

Minkä kehyksen kanssa työskentelet ja miksi? Jos sinulla on kysymyksiä tai kommentteja, muista kirjoittaa ne alle.

Etsitkö framework-agnostisia UI-komponentteja? GrapeCityssä on täydellinen joukko JavaScript-käyttöliittymäkomponentteja, mukaan lukien tietoruudut, kaaviot, mittarit ja syöttöohjaimet. Tarjoamme myös tehokkaita taulukkolaskentakomponentteja, raportointiohjaimia ja parannettuja esitysnäkymiä. Meillä on syvä tuki Angularille (sekä Reactille ja Vue:lle), ja olemme sitoutuneet laajentamaan komponenttejamme käytettäväksi nykyaikaisissa JavaScript-kehyksissä.