An Angular Roadmap – Az Angular múltja, jelene és jövője

Angular Updates: Újdonságok a 11-es verzióban

Az Angular 11.0.0 verziója 2020 novemberétől már elérhető. Bár ez a kiadás számos frissítést hoz a platformhoz, a legjelentősebb funkciók közé tartozik a TypeScript 4.0-val történő gyorsabb építés, a komponens tesztkészletek és az ESLint frissítések.

Paleolitikus JavaScript – SproutCore

A kezdetekben volt a SproutCore. Ez volt az első átfogó JavaScript-keretrendszer, amelynek célja az egyoldalas, asztali minőségű webes alkalmazások egyszerű elkészítése volt. Nem mintha ez korábban nem lett volna lehetséges. Amikor a Google kiadta a Gmailt, megmutatta a világnak, hogy a webes alkalmazások valóban helyettesíthetik az összetett asztali alkalmazásokat. A Google még a Closure eszközkészletet – egy könyvtárkészletet és egy optimalizáló fordítóprogramot, amelyet a Gmail létrehozásához használt – is nyíltan hozzáférhetővé tette.

A probléma az volt, hogy a Google Closure eszköztára nem volt túlságosan fejlesztőbarát. Erősen támaszkodtak a Java-ra, ami elidegenítette a JavaScripthez, PHP-hoz, Ruby-hoz és Pythonhoz szokott webfejlesztőket. A Gmail nagyszerűen demonstrálta a lehetőségeket, de a hasonló alkalmazások fejlesztése sokak számára még mindig elérhetetlennek tűnt.

Néhány bátor fejlesztőnek sikerült elképesztő egyoldalas alkalmazásokat összeállítania a jQuery, a ragasztószalag és a remény kombinációjával. Míg ezek az alkalmazások a végfelhasználók számára lenyűgözőnek tűntek, a rajtuk dolgozó fejlesztők számára az alkalmazások hamarosan a technikai adósság hatalmas halmaivá váltak, amelyek miatt a fejlesztőcsapat rettegett reggelente munkába menni.

Ennek eredményeképpen néhány vállalkozó kedvű fejlesztő olyan keretrendszereken kezdett el dolgozni, amelyek a Gmail-szerű alkalmazásokat mindenhol elérhetővé teszik a webfejlesztők számára. A SproutCore volt az első ilyen keretrendszer, amely beindult. Egy teljes widgetkészletet tartalmazott, amely lehetővé tette komplex webes alkalmazások készítését anélkül, hogy a HTML-hez vagy a CSS-hez hozzá kellett volna nyúlni.

Ez végül nagyszerű volt a korábbi asztali fejlesztők számára, akiket rúgkapálva és sikoltozva rángattak át a webre. Számos további keretrendszer bukkant fel hasonló célokkal; a GWT és a Cappuccino voltak a legkiemelkedőbbek. Ezek a keretrendszerek még a JavaScriptet is elkerülték azzal, hogy más nyelveket transzpiláltak JS-be. Ez ismét nagyszerű volt az asztali fejlesztők számára. De a szenvedélyes webfejlesztőket hidegen hagyta, és úgy éreztette velük, hogy a nehezen megszerzett HTML-, CSS- és JavaScript-tudásuk nem értékes.

Ez nyitva hagyott egy olyan keretrendszer előtt, amely valóban átöleli a webet, ahelyett, hogy megpróbálná bepaszírozni és úgy tenni, mintha valami más lenne. Megjelent néhány korai keretrendszer (Backbone és Knockout), és mérsékelt sikert értek el. Az Ember is ez idő tájt jelent meg. Fogta a SproutCore-t, lecsupaszította a csontjaira, és megpróbálta valami igazán webbarátra átépíteni. Az Ember a JavaScript-világ hatmillió dolláros embere akart lenni: jobban, erősebben és gyorsabban újjáépítve.

Ezek közül a keretrendszerek közül egyik sem vált népszerűvé. A világ valami jobbra várt. 2010-ben megjelent ez a valami jobb – Angularnak hívták.

Az Angular aranykora

Még az Angular 1.0-s verziójának megjelenése előtt az Angular viharszerűen meghódította a front-end fejlesztők világát. Végre volt egy könnyen használható JavaScript-keretrendszer, amely a HTML-t első osztályú állampolgárként kezelte. A fejlesztők és a tervezők most már együtt dolgozhattak, hogy csodálatos egyoldalas alkalmazásokat építsenek. Ez megkönnyebbülést jelentett a tervezők számára, akiket bosszantott és sértett, hogy a régebbi keretrendszerek a HTML-t és a CSS-t a barbárok eszközeinek tekintették, olyan eszközöknek, amelyekhez egy civilizált fejlesztőnek sem kellett volna hozzányúlnia.

Az első dolog, ami varázslatosnak tűnt az Angular-t először kipróbáló fejlesztők számára, a kétirányú adatkötés volt. Ezt megelőzően a legtöbb fejlesztő csak olyan asztali keretrendszerekben látott ilyen adatkötést, mint a WPF és a Windows Forms. Nagyszerű volt, hogy űrlapokat és más UI-elemeket lehetett JavaScript modellobjektumokhoz kötni. Bár a kétirányú adatkötés túlzott használat esetén teljesítményproblémákat okozhatott, az azt körültekintően használó csapatok úgy találták, hogy az Angular segítségével sokkal gyorsabban tudtak komplex front-end alkalmazásokat létrehozni, mint korábban bármikor.

Az Angular nem csak a HTML-elemekhez való egyszerű adatkötés miatt bizonyult népszerűnek. Az Angular direktívák egyszerű módot biztosítottak az újrafelhasználható HTML + CSS komponensek létrehozására. Bár az Angular előtt más JavaScript keretrendszerek is biztosították ezt, az Angular volt az első, amely rendkívül népszerűvé vált. Az újrafelhasználható komponensek már régóta használatosak voltak a szerveroldali keretrendszerekben. Az ASP.NET felhasználói vezérlők és a Rails és a Django részleges sablonjai csak néhány
példa.

Elvégre az Angular tette népszerűvé a függőségi injektálást a front-end fejlesztés világában. A függőségi injektálás már régóta népszerű volt a vállalati alkalmazásokban, talán ezért nem terjedt el a JavaScript világában. A front-end fejlesztők régóta idegenkednek a szerintük feleslegesen bonyolult vállalati szoftvertervezési mintáktól. Ez az aggodalom nem alaptalan. Előfordult már, hogy egy alkalmazás írása közben azt mondta magának: “Itt tényleg szükségem van egy “SimpleBeanFactoryAwareAspectInstanceFactory”-re?”

A függőségi injektálás azonban bebizonyította a hasznosságát. Az Angular pedig könnyen használhatóvá tette a függőségi injektálást egy olyan közönség számára, amely korábban nem sokat használta. Szükséged van egy HTTP-kliensre? Vagy esetleg animációt szeretnél csinálni? Nem probléma. Az Angularnak ezekhez is voltak beépített szolgáltatásai. Csak kérni kellett őket, és az Angular befecskendezte őket a komponensekbe. Nem kell semmit sem instanciálnod magadnak.

Vagy talán a böngésző window vagy location objektumait szerette volna használni anélkül, hogy lehetetlenné tenné a komponensek böngészőn kívüli egységtesztelését? Az Angular ezt is megoldotta a beépített $window és $location szolgáltatásaival. Futásidőben megkaptad a böngésző objektumait, amire számítottál. A Node.js szerveroldali egységtesztek futtatásakor pedig mock szolgáltatásokat adhatott át a komponensekbe, hogy megbizonyosodjon arról, hogy azok a különböző forgatókönyvekben a várt módon viselkednek.

Ha mindez nem lenne elég, az Angular a saját szolgáltatások regisztrálását és injektálását is egyszerűvé tette. Azoknak a fejlesztőknek, akik megszokták, hogy minden adatukat a DOM-hoz kötik, és a legjobbat remélik, ez fantasztikus volt. Ha egy új front-end alkalmazást írnál, amely olyan API-kat hívott, amelyek túlhasználat esetén sok pénzbe kerülnének a cégednek, valószínűleg jobban örülnél, ha előre írhatnál teszteket, hogy megbizonyosodj arról, hogy az alkalmazásod nem próbál meg olyasmit csinálni, mint például 800 milliószor meghívni a Twilio API-t.

Ezért létrehozna egy Twilio szolgáltatást, amelyet futásidőben injektál. Teszteléskor létrehoznál egy mock szolgáltatást, amely rögzíti minden egyes API-hívás költségét, amelyet az alkalmazásod megpróbál végrehajtani. Olyan teszteket írna, amelyek lefedik a gyakori felhasználási forgatókönyveket, és biztosítják, hogy ezek a forgatókönyvek nem eredményeznek 7 számjegyű számlát a vállalatnak. Összességében a legtöbb fejlesztő úgy találta, hogy az Angular direktívák a függőségi injektálással kombinálva lehetővé tették, hogy moduláris, tesztelhető front-end alkalmazásokat írjanak a bevált szoftverfejlesztési technikák alkalmazásával. Sok fejlesztőcsapat úgy döntött, hogy ez boldog állapotot eredményezett, és úgy döntöttek, hogy mindent beleadnak az Angularba.

Az Angular hanyatlása? A React felemelkedése

Míg az Angular világában többnyire jól mentek a dolgok, nem volt csupa napsütés és nyalóka. A fejlesztők komoly teljesítményproblémákba kezdtek ütközni, amikor túl sok modellobjektumot próbáltak túl sok DOM-elemhez kötni. Néhány alkalmazás lassult le. A $digest közvetlen hívása és más fekete mágikus varázslatok kezdtek szükségessé válni az elfogadható teljesítmény eléréséhez. Nagyjából ugyanebben az időben jelent meg egy új kihívó: A React. Eleinte úgy tűnt, hogy a React nem jelent túl nagy veszélyt az Angularra. Elvégre ezek a React-furcsák vették a fáradtságot, hogy feltalálják a JSX-et, ami nagyon úgy nézett ki, mintha markupot kevertek volna a kódba. Nem azért fáradoztunk sokat a templating nyelvek kitalálásával, hogy kifejezetten elkerüljük a jelölés és a kód keveredését?

Amint kiderült, a React megközelítése elég népszerű volt a front-end fejlesztői közösségben. A népszerűség azonban nem robbant be a rakéták közé. Az Angular még mindig domináns volt, és úgy tűnt, hogy ez így is marad. Egészen addig, amíg az Angular népszerűsége nem kapott egy váratlan forrásból: magától az Angular csapatától.

Az Angular 2 bemutatása

Az Angular 2-t először a 2014-es ng-europe konferencián jelentették be. Az Angular csapat tervei enyhén szólva sokkolták az Angular közösséget. Az Angular fejlesztők reakciója gyors és negatív volt… és nem ok nélkül. Az Angular 2 megszabadulna számos, az Angular 1-ből ismert koncepciótól, bevezetne egy új, inkompatibilis templating nyelvet (és ó, mellesleg) egy teljesen új nyelvvel is programoznák.

AngularJS

Noha mind az Angular 1, mind az Angular 2 az “Angular” nevet kapta, a valóságban nagyon különböző keretrendszerek voltak, néhány közös dologgal. A félreértések elkerülése érdekében az Angular csapat elkezdett az Angular régi verziójára ‘AngularJS’-ként, az új verzióra pedig egyszerűen ‘Angular’-ként hivatkozni. Ennek intuitív értelme van, mivel az AngularJS JavaScriptben íródott, az Angular pedig nem. Hogy a keretrendszerek közötti különbségtétel egyértelmű maradjon, innentől kezdve az Angular 1-re AngularJS-ként fogok hivatkozni.

Mindezek hatására az AngularJS fejlesztői elvesztették a keretrendszer jövőjébe vetett hitüket. Azzal fenyegetőztek, hogy a jövőbeli projekteknél új keretrendszerre térnek át, és sokan közülük pontosan ezt tették. Az AngularJS-ből való tömeges kivonulás legnagyobb haszonélvezője a React volt.

Bár a React nem csinált annyit, mint az AngularJS, bizonyos szempontból ez pozitív volt. Ha olyan nézetkönyvtárat használsz, ami nem próbál mindent plusz a konyhai mosogatót is belevenni, akkor sokkal nehezebb az adott könyvtár fejlesztőinek a jövőben kihúzni a szőnyeget a lábad alól. Kezdetben a React használata egy kicsit fájdalmas volt az AngularJS-hez képest. Könyvtárak patchworkjét kellett összedobni, csak hogy lefedje azt a funkcionalitást, amit az AngularJS a dobozból nyújtott.

Néhány csapat úgy látta, hogy ez jó módja a kockázat csökkentésének, mert nem volt valószínű, hogy az összes ilyen könyvtár fejlesztői egyszerre döntenek úgy, hogy visszafelé inkompatibilis törő változtatásokat hajtanak végre, amit az Angular lényegében megtett.

A Vue megjelenése

Az AngularJS gondjainak súlyosbítására egy másik keretrendszer, a Vue nagyjából akkoriban jelent meg, amikor az Angular 2 körüli dráma zajlott. A Vue-t az AngularJS inspirálta, de célja az volt, hogy egyszerűsítse azt, és megszabaduljon attól, amit a Vue alkotója felesleges bonyolultságnak látott (így a Vue nagyon ismerősnek tűnt a meglévő AngularJS fejlesztők számára). A Vue biztonságos menedéket nyújtott sok AngularJS-fejlesztő számára, akik nem akartak átállni a Reactra.

Ez nem jelenti azt, hogy az AngularJS fejlesztők nem várták türelmesen az Angular 2 megjelenését. De egyértelmű, hogy az AngularJS-ből tömeges elvándorlás volt a React és a Vue felé az Angular 2 tervei által okozott bizonytalanság miatt.

Az Angular 2 hamvaiból való feltámadás

Egyszer csak megjelent az Angular 2. Ahogy az várható volt, az AngularJS-ből sok ismerős koncepciót eltüntetett, de megtartott néhányat a legjobb darabokból, mint például a szolgáltatások és a függőségi injektálás. A fejlesztők józanságának szerencséjére az Angular sima TypeScriptet használ, és nem egy forkot, ahogy azt eredetileg tervezték.

Az Angular-csapat, hogy még zavarosabbá tegye a dolgokat, fenntartotta az új keretrendszer egy forkját, amely TypeScript helyett a Dart programozási nyelvet használta. Kezdetben a TypeScript és a Dart verziókat szinkronban fejlesztették, egyetlen kódbázisból generálva. Végül az Angular TS és Dart verziója úgy döntött, hogy külön utakon járnak, és az Angular Dart ma már önállóan létezik.

Az Angular népszerűsége még ezzel a zűrzavarral együtt is újra növekedni kezdett az Angular 2 kiadása után. Ez lassan történt. Ahogy a szoftverfejlesztésben gyakran előfordul, a trendek eltolódtak. A fejlesztők rájöttek, hogy egy nagy, elemeket tartalmazó keretrendszer valóban hasznos lehet. Elvégre, ha az alkalmazásod elég nagyra nő, végül valóban szükséged lesz az összes elemre.

Különösen a vállalati fejlesztők kezdtek visszatérni az Angularhoz. Ennek van értelme. Általában, amikor elkezdesz egy vállalati webes alkalmazást, tudod, hogy az összetett lesz. Nincs értelme egy apró MVP-vel kezdeni, ha már az elején tudod mind a 87 dolgot, amit az alkalmazásodtól elvárnak.

Hol van az Angular 3?

Noha az Angular 2 nem volt tökéletes, sok összetett webes alkalmazás fejlesztője kezdett rájönni, hogy az új és továbbfejlesztett Angular megfelel az igényeiknek. Szerencséjükre az Angular néhány izgalmas fejlesztést tartogatott. Ennél is fontosabb volt, hogy az Angular csapat bebizonyította, hogy következetesen képes a keretrendszer új verzióit közzétenni úgy, hogy a verziók között kevés törő változtatás történt

Egy akkoriban furcsának tűnő lépéssel az Angular csapat úgy döntött, hogy teljesen kihagyja a 3. verziót, és áttér a 4. verzióra. Ennek jó oka volt: az Angular router csomagján dolgozó csapat már előrehaladt és kiadta a 3-as verziót, míg az Angular többi része még mindig a 2.3-as verziónál tartott. Úgy döntöttek, hogy a jövőben az összes Angular csomag verzióját szinkronban kell tartaniuk, és a legegyszerűbb módja ennek az volt, hogy a következő kiadásra mindent a 4-es verzióra emeljünk.

Angular 4

Az Angular 4 néhány jelentős változást tartalmazott, többek között hozzáadott idő előtti fordítást, ami kisebb termelési JavaScript-csomagokat és rövidebb alkalmazásbetöltési időt eredményezett. Hozzáadták a szerveroldali renderelés támogatását, ami lendületet adott azoknak a csapatoknak, amelyek az alkalmazásukat előre renderelni akarták, hogy javítsák a kezdeti betöltési teljesítményt. A keretrendszerben számos más fejlesztés is helyet kapott, de az alkalmazások frissítése az Angular 2-ről a 4-re a legtöbb esetben gyors és fájdalommentes volt.

Angular 4.3 és az Angular 5

Az Angular 4.3 új HTTP-klienssel bővült, amelyet könnyebb volt használni, mint a régi HTTP-szolgáltatást. Az Angular 5-ben a régi HTTP szolgáltatás elavulttá vált, és a következő kiadásban elhagyásra kerül. A kellemetlenségek ellenére viszonylag kevés volt a morgolódás, mert a frissítés a legtöbb esetben egyszerű volt. Az Angular 5 emellett jobb nemzetköziesítési támogatással és további építési optimalizációkkal bővült.

Angular 6 és 7

Angular 6 és 7 néhány fejlesztő számára csalódást okozott. Nagy változások nem voltak, de sok apró életminőségbeli javulás volt, különösen az Angular CLI eszköztárában. A látható változások csökkenő száma nem azt jelzi, hogy az Angular-csapat felhagyott az innovációval. Ehelyett ez azt mutatja, hogy a keretrendszer kiforrott, így a fejlesztőcsapat most már szabadon végezhet több munkát a színfalak mögött, javíthatja a hibákat és javíthatja a teljesítményt.

A keretrendszer stabilitása az Angular 2 megjelenése óta visszacsábított néhány régi vágású AngularJS-fejlesztőt az Angular világába. A vállalati fejlesztőcsapatok figyelmét is felkeltette. Amikor olyan vállalati alkalmazásokat építünk, amelyek akár évtizedekig is élhetnek, ideális egy olyan keretrendszert használni, amely kiszámítható ütemezéssel kap új kiadásokat, de nem változik túl gyorsan. Egy olyan fejlesztő, aki eddig csak az Angular 2-t használta, perceken belül készen állhat és hozzájárulhat egy Angular 7 alkalmazáshoz.

Angular 8 és az Angular Ivy

És ezzel elérkeztünk a mai naphoz. Mint láttuk, az Angular hosszú utat tett meg. A webfejlesztők által szeretettől a szidalmazáson át a csodálatig jutott, bár még nem szeretik újra úgy, mint a kezdeti időkben.

A horizonton ott van az Angular 8. Az Angular 8-ban rengeteg munkát végeztek, hogy könnyen használhatóvá tegyék a Bazel build rendszerrel, ami teljesen elképesztő hír mind a 3 fejlesztő számára, akik a Google-n kívül használják. Olvass az Angular 8 változásairól.

Még izgalmasabb azonban, hogy az Angular csapat keményen dolgozik az Angular Ivy nevű új renderelésen. Ezt a jelenlegi renderelt helyettesítésére szánják. A legtöbb esetben a jelenlegi alkalmazásoknak nem kell semmilyen változtatást végrehajtaniuk az Angular Ivy használatához.

Ha az Angular Ivy egy drop-in csere, miért érdekli a fejlesztőket? Két fontos ok: a sebesség és a csomagméret – két nagyon fontos szempont. Néhány évig úgy tűnt, hogy a webfejlesztők kicsit megőrültek. A csapatok 5 MB-os, 10 MB-os vagy még nagyobb JavaScript-csomagokat szállítottak, és azt gondolták, hogy ezzel nincs probléma. Elvégre az alkalmazások tökéletesen működtek a fejlesztők i7-es MacBook Prókon, tehát mindenkinek jól kell működniük, nem igaz?

Sajnos a való világban nem mindenki használja a legújabb és legjobb hardvert. Több százmillió ember kizárólag régebbi, egy krumplinál alig nagyobb feldolgozási teljesítményű androidos telefonokon, a betárcsázásnál alig gyorsabb internetkapcsolatokon keresztül jut el az internethez. Ezeknek a felhasználóknak egy hatalmas JavaScript-csomag betöltése örökkévalóságig tart, és még tovább tart, amíg a készülékük elemzi és futtatja. Még a kevésbé szélsőséges esetekben is számtalan olyan felhasználó van világszerte, aki nem a legújabb és legjobb hardvert használja. Számukra a hatalmas JavaScript-alkalmazások használhatóak (de fájdalmasak).

Angular Ivy

Az Angular Ivy renderelő több szempontból is segíteni fog:

1. A hatékonyságot szem előtt tartva íródott, így ugyanazokat a feladatokat sokkal kevesebb CPU utasítás végrehajtása mellett fogja elvégezni. Ez javítani fogja mind az akkumulátor élettartamát, mind a kevésbé erős eszközökkel rendelkező felhasználók józanságát.
2. A renderelő sokkal modulárisabban lesz megírva, mint a jelenlegi renderelő. Ez sokkal alkalmasabbá fogja tenni a fa-rázásra és a halott kódok kiküszöbölésére. Ennek eredményeképpen a produktív JavaScript-csomagod csak azt a kódot fogja tartalmazni, ami az alkalmazásod futtatásához szükséges, ahelyett, hogy mindent és a konyhai mosogatót összecsomagolnád, ahogy az gyakran előfordul a jelenlegi renderelővel.
3. A csomagméret csökkentése és a jobb renderelési sebesség mellett az Angular Ivy további néhány életminőség-javítást is tartalmaz az Angular fejlesztők számára. Az újraépítési idők jelentősen gyorsabbak. Ha tehát fejlesztői módban futtatod az alkalmazásodat, és arra vársz, hogy a módosításaid megjelenjenek, mostantól sokkal kevesebb időt fogsz várakozással tölteni.
4. A sablon-típusok ellenőrzése javult, ami azt jelenti, hogy több hibát fogsz elkapni a fordításkor, nem pedig a futáskor. A futásidejű sablonhibák bosszantóak, mert vagy téged harapnak meg a tesztelés során, vagy a felhasználóidat harapják meg, amikor megpróbálják használni az alkalmazásodat.
5. Az Angular Ivy sablonfordítója ember által olvasható kódot fog generálni, amit a jelenlegi View Engine fordítója nem tesz meg. Ez jól fog jönni, amikor kemény sablonhibákat próbálunk felkutatni.

A végeredmény: kisebb alkalmazások, gyorsabb alkalmazások, boldogabb fejlesztők és boldogabb felhasználók.

Angular 9

Itt egy áttekintés az Angular 9-ről.

A főbb kiemelkedő pontok a következők:

• Beépített Angular funkciók
• Felnőtt fejlesztés az Angularral
• Az Angular View Engines megismerése
• Angular Ivy régóta fennálló problémákat old meg
• Angular Ivy és a mobil
• Selector…less Directives
• Angular diagnosztikai fejlesztések
• Internacionalizálás az Angular Ivy-val
• DI és Type-Safe az Angular 9-ben
• Dependency Injection változások az Angular Core-ban
• Angular Benchmarkok (Angular 8.2.7 vs. 9.0.0-next.5)

Angular 10

Angular 10.0.0 verziója 2020 június végén jelent meg. Az Angular 10 egy jelentős kiadás, amely olyan változásokat tartalmaz, mint az új dátumtartomány-választó az Angular Materialban, a TypeScript-verziók frissítése, könyvtárverzió-frissítések és még sok más.

Az új funkciók közé tartoznak:

• Ngtsc Compiler Interface
• Aszinkron időkorlátok beállítása
• Stale Lock File Reporting
• Lazy Computation of basePaths

.

• Fordítási fájlok egyesítése
• Explicit Mapping

Angular 11

Angular 11-es verziója.A 0.0 2020 novemberében jelent meg. Az Angular 11 főverzió frissítéseket biztosít a teljes platformon, beleértve a CLI-t és a komponensek keretrendszerét.

A fontosabb funkciók közé tartozik:

• Gyorsabb építés a TypeScript 4 segítségével.0
• Komponens-tesztkészletek
• ESLint-frissítések
• Felfrissített nyelvi szolgáltatás-előnézet
• Felfrissített Hot Module Replacement (HMR) támogatás
• Javított jelentések és naplózás
• Automatikus betűtípus-illesztés

Angular múltja, Jelen és jövő

Ha már a kezdetektől fogva egészen mostanáig használod az Angular-t, akkor gratulálok! Bár rengeteg rögös szakasz volt, végül egy gyors, modern keretrendszert kaptunk, amelyet szórakoztató használni.

Ha AngularJS-fejlesztő voltál, de áttértél a Reactra, a Vue-ra vagy valami másra, arra bátorítalak, hogy vess még egy pillantást az Angularra. Megéri az idődet, még akkor is, ha úgy döntesz, hogy maradsz annál, amit most használsz.

És ha még egyáltalán nem használtad az Angular-t, miért ne adnál neki egy esélyt?

Az imént egy örvénylő túrán vettünk részt az Angular múltján, jelenén és jövőjén keresztül. Kétségtelenül nagy utazás volt. Függetlenül attól, hogy milyen Angular háttérrel rendelkezel, remélem, élvezted a túrát!

Milyen keretrendszerrel dolgozol és miért? Ha kérdésed vagy észrevételed van, mindenképpen írd meg alább.

Keretrendszer-agnosztikus UI komponenseket keresel? A GrapeCity teljes körű JavaScript UI-komponenskészlettel rendelkezik, beleértve az adatrácsokat, grafikonokat, mérőórákat és beviteli vezérlőket. Emellett nagy teljesítményű táblázatkezelő komponenseket, jelentéskészítő vezérlőket és továbbfejlesztett prezentációs nézeteket is kínálunk. Mélyen támogatjuk az Angular-t (valamint a React-ot és a Vue-t), és elkötelezettek vagyunk a modern JavaScript keretrendszerekben való használatra szánt komponenseink bővítése iránt.