O foaie de parcurs Angular – Trecutul, prezentul și viitorul Angular

Actualizări Angular: Ce este nou în versiunea 11

În noiembrie 2020, versiunea 11.0.0 a Angular este acum disponibilă. Deși această versiune aduce multe actualizări platformei, cele mai importante caracteristici includ compilări mai rapide cu TypeScript 4.0, hamuri de testare a componentelor și actualizări ESLint.

Paleolithic JavaScript – SproutCore

La început, a existat SproutCore. A fost primul cadru JavaScript cuprinzător, menit să faciliteze crearea de aplicații web cu o singură pagină de calitate desktop. Nu că acest lucru nu ar fi fost posibil înainte. Când Google a lansat Gmail, a arătat lumii că aplicațiile web pot înlocui cu adevărat aplicațiile desktop complexe. Google a pus la dispoziție în mod deschis chiar și setul de instrumente Closure – un set de biblioteci și un compilator de optimizare pe care l-a folosit pentru a crea Gmail.

Problema a fost că instrumentele Closure ale Google nu erau foarte prietenoase cu dezvoltatorii. Ele se bazau foarte mult pe Java, ceea ce i-a îndepărtat pe dezvoltatorii web care erau obișnuiți să lucreze cu JavaScript, PHP, Ruby și Python. Gmail a fost o demonstrație excelentă a ceea ce era posibil, dar dezvoltarea unor aplicații similare părea încă inaccesibilă pentru mulți.

Câțiva dezvoltatori curajoși au reușit să înlănțuie aplicații uimitoare de o singură pagină folosind o combinație de jQuery, bandă adezivă și speranță. În timp ce aceste aplicații arătau uimitor pentru utilizatorii finali, pentru dezvoltatorii care lucrau la ele, aplicațiile s-au transformat rapid în grămezi uriașe de datorii tehnice care au făcut ca echipa de dezvoltatori să se teamă să se îndrepte dimineața spre muncă.

Ca urmare, câțiva dezvoltatori întreprinzători au început să lucreze la cadre care să aducă aplicații de tip Gmail la îndemâna dezvoltatorilor web de pretutindeni. SproutCore a fost primul dintre aceste cadre care a luat avânt. Acesta venea cu un set complet de widget-uri care făceau posibilă construirea de aplicații web complexe fără a atinge măcar HTML sau CSS.

Acest lucru a sfârșit prin a fi grozav pentru foștii dezvoltatori desktop care fuseseră târâți cu forța pe web. Au apărut alte câteva cadre cu obiective similare; GWT și Cappuccino au fost cele mai importante. Aceste cadre au evitat chiar și JavaScript prin transpunerea altor limbaje în JS. Din nou, acest lucru a fost grozav pentru dezvoltatorii desktop. Dar i-a lăsat pe dezvoltatorii web pasionați pe dinafară și i-a făcut să se simtă ca și cum abilitățile lor HTML, CSS și JavaScript obținute cu greu nu erau valoroase.

Aceasta a lăsat o deschidere pentru un cadru care a îmbrățișat cu adevărat web-ul, în loc să încerce să se plastoneze peste el și să pretindă că este altceva. Au apărut câteva cadre timpurii (Backbone și Knockout), care au obținut un succes moderat. Ember a apărut, de asemenea, în această perioadă. Acesta a luat SproutCore, l-a dezbrăcat până la oase și a încercat să îl reconstruiască în ceva cu adevărat prietenos pentru web. Ember a vrut să fie omul de șase milioane de dolari al lumii JavaScript: reconstruit mai bine, mai puternic și mai rapid.

Nici unul dintre aceste framework-uri nu a cunoscut o popularitate fulminantă. Lumea aștepta ceva mai bun. În 2010, acel ceva mai bun a apărut – s-a numit Angular.

Era de aur a lui Angular

Chiar înainte ca versiunea 1.0 să fi fost lansată, Angular a luat cu asalt lumea dezvoltării front-end. În sfârșit, aveam un cadru JavaScript ușor de utilizat care trata HTML ca pe un cetățean de primă clasă. Dezvoltatorii și designerii puteau acum să lucreze împreună pentru a construi aplicații uimitoare pe o singură pagină. Acest lucru a venit ca o ușurare pentru designeri, care fuseseră supărați și jigniți pentru că cadrele mai vechi tratau HTML și CSS ca pe niște instrumente pentru barbari, instrumente pe care niciun dezvoltator civilizat nu ar trebui să le atingă.

Primul lucru care a părut magic pentru dezvoltatorii care încercau Angular pentru prima dată a fost legătura de date bidirecțională. Înainte de aceasta, majoritatea dezvoltatorilor văzuseră acest tip de legare a datelor doar în cadrele desktop precum WPF și Windows Forms. A fost grozav să poți lega formulare și alte elemente de interfață cu obiecte de model JavaScript. Deși legătura de date bidirecțională putea cauza probleme de performanță atunci când era folosită în exces, echipele care au folosit-o în mod judicios au descoperit că Angular le-a permis să creeze aplicații front-end complexe mult mai rapid ca niciodată.

Angular s-a dovedit a fi popular pentru mai mult decât pentru legarea ușoară a datelor la elementele HTML. Directivele Angular au oferit o modalitate ușoară de a crea componente HTML + CSS reutilizabile. Deși alte cadre JavaScript au oferit acest lucru înainte de Angular, Angular a fost primul care a devenit extrem de popular. Componentele reutilizabile erau de mult timp în uz în cadrele server-side. Controalele de utilizator ASP.NET și șabloanele parțiale din Rails și Django sunt doar câteva
exemple.

În cele din urmă, Angular a făcut ca injecția de dependențe să devină populară în lumea dezvoltării front-end. Injectarea dependențelor era de mult timp populară în aplicațiile de întreprindere, acesta fiind poate motivul pentru care nu prinsese în lumea JavaScript. Dezvoltatorii front-end au fost mult timp reticenți față de ceea ce ei consideră a fi modele de proiectare a software-ului de întreprindere inutil de complexe. Această preocupare nu este lipsită de temei. V-ați spus vreodată, în cursul scrierii unei aplicații, „Ceea ce am nevoie cu adevărat aici este un „SimpleBeanFactoryAwareAspectInstanceFactory?”

Injectarea de dependență, totuși, și-a dovedit valoarea. Iar Angular a făcut ca injecția de dependență să fie ușor de utilizat pentru un public care nu o folosise prea mult în trecut. Aveți nevoie de un client HTTP? Sau poate doriți să faceți o animație? Nicio problemă. Angular avea servicii încorporate pentru acestea. Nu trebuia decât să le cereți, iar Angular le injecta în componentele dumneavoastră. Nu este nevoie să instanțiați nimic singur.

Sau poate ați vrut să folosiți obiectele window sau location ale browserului fără a face imposibilă testarea unitară a componentelor dvs. în afara unui browser? Angular v-a acoperit și aici, cu serviciile sale integrate $window și $location. În timpul execuției, ați obține obiectele browserului pe care le așteptați. Iar atunci când executați teste unitare pe partea de server în Node.js, ați putea trece servicii simulate în componentele dvs. pentru a vă asigura că acestea se comportă conform așteptărilor în diverse scenarii.

Dacă toate acestea nu erau suficiente, Angular a simplificat, de asemenea, înregistrarea și injectarea propriilor servicii. Pentru dezvoltatorii care erau obișnuiți să lege toate datele lor la DOM și să spere la ce e mai bun, acest lucru a fost minunat. Dacă scriați o nouă aplicație front-end care apela la API-uri care ar costa compania dvs. o mulțime de bani dacă ar fi folosite în exces, probabil că ați prefera să puteți scrie teste din timp pentru a vă asigura că aplicația dvs. nu încearcă să facă ceva de genul apelării API-ului Twilio de 800 de milioane de ori.

Așa că ați crea un serviciu Twilio care este injectat în timpul execuției. În momentul testării, ați crea un serviciu simulat care înregistrează costul fiecărui apel API pe care aplicația dvs. încearcă să îl facă. Ați scrie teste care să acopere scenarii de utilizare comune și să vă asigurați că aceste scenarii nu duc la primirea de către compania dvs. a unei facturi de 7 cifre. În general, majoritatea dezvoltatorilor au constatat că directivele Angular combinate cu injecția de dependențe au făcut posibilă scrierea de aplicații front-end modulare și testabile, folosind tehnici de inginerie software verificate și testate. Multe echipe de dezvoltare au decis că acest lucru a dus la o stare de lucruri fericită și au decis să meargă cu totul pe Angular.

Declinul Angular? The Rise of React

În timp ce lucrurile au fost în mare parte minunate în lumea Angular, nu a fost numai soare și acadele. Dezvoltatorii începeau să se confrunte cu probleme grave de performanță atunci când încercau să lege prea multe obiecte model la prea multe elemente DOM. Unele aplicații deveneau foarte lente. Apelurile directe la $digest și alte vrăjitorii de magie neagră au început să devină necesare pentru a obține o performanță acceptabilă. Cam în aceeași perioadă, a apărut un nou concurent: React. La început, React nu părea să reprezinte un pericol prea mare pentru Angular. La urma urmei, acești ciudați de la React se chinuiseră să inventeze JSX, care semăna foarte mult cu o modalitate de a amesteca marcaje în cod. Nu ne chinuisem mult să inventăm limbaje de modelare pentru motivul explicit de a evita amestecul de markup și cod?

Cum s-a dovedit, abordarea React a fost destul de populară în comunitatea de dezvoltare front-end. Cu toate acestea, nu a ajuns la o popularitate fulminantă. Angular era încă dominant și se părea că va rămâne așa. Până când, popularitatea lui Angular a primit un șut bun în dinți de la o sursă neașteptată: însăși echipa Angular.

Introducerea lui Angular 2

Angular 2 a fost anunțat pentru prima dată la conferința ng-europe din 2014. Planurile echipei Angular au venit ca un șoc pentru comunitatea Angular, ca să spunem așa. Reacția dezvoltatorilor Angular a fost rapidă și negativă… și nu fără motiv. Angular 2 urma să scape de multe concepte familiare din Angular 1, să introducă un nou limbaj de modelare incompatibil (și oh, apropo) urma să fie programat, de asemenea, folosind un limbaj complet nou.

AngularJS

Deși atât Angular 1 cât și Angular 2 se numeau „Angular”, în realitate, erau cadre foarte diferite, cu câteva lucruri în comun. Pentru a ajuta la prevenirea confuziei, echipa Angular a început să se refere la vechea versiune de Angular ca fiind „AngularJS”, iar la noua versiune ca fiind pur și simplu „Angular”. Acest lucru are un sens intuitiv, deoarece AngularJS a fost scris în JavaScript, iar Angular nu. Pentru ca distincția dintre cadre să rămână clară, mă voi referi la Angular 1 ca AngularJS de acum înainte.

Ca urmare a tuturor acestor lucruri, dezvoltatorii AngularJS și-au pierdut încrederea în viitorul cadrului. Aceștia au amenințat că vor trece la un nou cadru pe proiectele viitoare și exact asta au făcut mulți dintre ei. React a fost cel mai mare beneficiar al exodului în masă de la AngularJS.

Deși React nu a făcut la fel de mult ca AngularJS, într-un fel a fost pozitiv. Dacă folosești o bibliotecă de vizualizare care nu încearcă să includă totul plus chiuveta de bucătărie, este mult mai dificil pentru dezvoltatorii acelei biblioteci să îți tragă preșul de sub picioare în viitor. La început, utilizarea React a fost un pic mai dificilă în comparație cu AngularJS. Trebuia să pui laolaltă un mozaic de biblioteci doar pentru a acoperi funcționalitatea pe care AngularJS o oferea din start.

Multe echipe au văzut acest lucru ca pe o modalitate bună de a reduce riscul, deoarece era puțin probabil ca dezvoltatorii tuturor acelor biblioteci să decidă să facă modificări de rupere incompatibile cu trecutul în același timp, ceea ce este în esență ceea ce făcuse Angular.

Emergența lui Vue

Pentru a agrava necazurile lui AngularJS, un alt cadru numit Vue a apărut cam în același timp în care avea loc drama legată de Angular 2. Vue a fost inspirat de AngularJS, dar a urmărit să îl simplifice și să scape de ceea ce creatorul lui Vue a considerat a fi o complexitate inutilă (astfel încât Vue părea foarte familiar pentru dezvoltatorii AngularJS existenți). Vue a oferit un refugiu sigur pentru mulți dezvoltatori AngularJS care nu doreau să treacă la React.

Acest lucru nu înseamnă că dezvoltatorii AngularJS nu așteptau cu răbdare să apară Angular 2. Dar este clar că a existat un exod în masă de la AngularJS la React și Vue din cauza incertitudinii cauzate de planurile pentru Angular 2.

Răsărit din cenușă cu Angular 2

În cele din urmă, Angular 2 a fost lansat. Așa cum era de așteptat, a renunțat la multe concepte familiare din AngularJS, dar a păstrat câteva dintre cele mai bune piese, cum ar fi serviciile și injecția de dependență. Din fericire pentru sănătatea mintală a dezvoltatorilor, Angular folosește TypeScript simplu și nu o bifurcație, așa cum era planificat inițial.

Pentru a face lucrurile și mai confuze, echipa Angular a menținut o bifurcație a noului cadru care folosea limbajul de programare Dart în loc de TypeScript. Inițial, versiunile TypeScript și Dart au fost dezvoltate în sincronizare, fiind generate dintr-o singură bază de cod. În cele din urmă, versiunile TS și Dart ale Angular au decis să meargă pe drumuri separate, iar Angular Dart există acum pe cont propriu.

Chiar și cu această confuzie, popularitatea Angular a început să crească din nou după lansarea Angular 2. S-a întâmplat încet. Așa cum se întâmplă adesea în dezvoltarea de software, tendințele s-au schimbat. Dezvoltatorii și-au dat seama că un cadru mare, cu baterii incluse, ar putea fi de fapt util. La urma urmei, atunci când aplicația dvs. crește suficient de mult, ajungeți să aveți de fapt nevoie de toate acele baterii.

Dezvoltatorii de întreprinderi, în special, au început să se întoarcă la Angular. Acest lucru are sens. De obicei, atunci când începeți o aplicație web de întreprindere, știți că va fi complexă. Nu are rost să începi cu un mic MVP atunci când știi de la început toate cele 87 de lucruri pe care aplicația ta va trebui să le facă.

Unde este Angular 3?

Deși Angular 2 nu a fost perfect, mulți dezvoltatori de aplicații web complexe au început să realizeze că noul și îmbunătățitul Angular se potrivește bine pentru nevoile lor. Din fericire pentru ei, Angular avea pregătite câteva îmbunătățiri interesante. Mai important, echipa Angular a demonstrat că poate publica în mod constant noi versiuni ale cadrului cu puține modificări de ruptură între versiuni

Într-o mișcare care părea ciudată la momentul respectiv, echipa Angular a decis să sară peste versiunea 3 în întregime și să treacă la versiunea 4. Acest lucru a fost făcut pentru un motiv întemeiat: echipa care lucra la pachetul de routere al Angular a avansat deja și a publicat versiunea 3, în timp ce restul Angular era încă la versiunea 2.3. Au decis să mențină toate versiunile pachetului Angular sincronizate în continuare, iar trecerea la versiunea 4 pentru următoarea versiune a fost cea mai ușoară modalitate de a realiza acest lucru.

Angular 4

Angular 4 a avut câteva schimbări semnificative, inclusiv adăugarea compilării înainte de timp, ceea ce a dus la pachete JavaScript de producție mici și la un timp de încărcare a aplicației mai scurt. A fost adăugat suportul pentru redarea pe partea serverului, ceea ce a reprezentat un impuls pentru echipele care doreau să își redea aplicația înainte de timp pentru a îmbunătăți performanța inițială de încărcare. Multe alte îmbunătățiri au fost adăugate în tot cadrul, dar actualizarea aplicațiilor de la Angular 2 la 4 a fost rapidă și nedureroasă în majoritatea cazurilor.

Angular 4.3 și Angular 5

Angular 4.3 a adăugat un nou client HTTP care a fost mai ușor de utilizat decât vechiul serviciu HTTP. În Angular 5, vechiul serviciu HTTP a fost depreciat și urma să fie abandonat în următoarea versiune. În ciuda acestui inconvenient, au existat relativ puține nemulțumiri deoarece, în majoritatea cazurilor, actualizarea a fost simplă. Angular 5 a adăugat, de asemenea, un suport mai bun pentru internaționalizare și alte optimizări de compilare.

Angular 6 și 7

Angular 6 și 7 au fost dezamăgitoare pentru unii dezvoltatori. Nu au existat schimbări mari, dar au existat multe mici îmbunătățiri ale calității vieții, în special în ceea ce privește instrumentele Angular CLI. Numărul tot mai mic de schimbări vizibile nu este un indiciu că echipa Angular a încetat să mai inoveze. În schimb, aceasta arată că structura este matură, astfel încât echipa de dezvoltare este acum liberă să lucreze mai mult în spatele scenei, reparând bug-uri și îmbunătățind performanța.

Stabilitatea cadrului de la lansarea Angular 2 a atras unii dezvoltatori AngularJS de școală veche înapoi în lumea Angular. De asemenea, a atras atenția echipelor de dezvoltare a întreprinderilor. Atunci când construiți aplicații de întreprindere care pot trăi zeci de ani, este ideal să folosiți un framework care primește versiuni noi într-un program previzibil, dar care nu se schimbă prea rapid. Un dezvoltator care a folosit doar Angular 2 ar putea să fie funcțional și să contribuie la o aplicație Angular 7 în câteva minute.

Angular 8 și Angular Ivy

Și asta ne aduce la ziua de azi. După cum am văzut, Angular a parcurs un drum lung. A trecut de la a fi iubit de dezvoltatorii web la a fi înjurat la a fi admirat, deși încă nu este din nou iubit așa cum a fost la începuturile sale.

La orizont, avem Angular 8. O tonă de muncă a fost făcută în Angular 8 pentru a-l face ușor de folosit cu sistemul de construire Bazel, ceea ce este o veste absolut uimitoare pentru toți cei 3 dezvoltatori care îl folosesc în afara Google. Citiți despre modificările din Angular 8.

Mai interesant, totuși, echipa Angular lucrează din greu la o nouă redare numită Angular Ivy. Acesta este destinat să fie un înlocuitor drop-in pentru actualul randat. În cea mai mare parte, aplicațiile actuale nu vor trebui să facă nicio modificare pentru a utiliza Angular Ivy.

Dacă Angular Ivy este un înlocuitor drop-in, de ce ar trebui să le pese dezvoltatorilor? Două motive importante: viteza și dimensiunea pachetului – două preocupări foarte importante. Timp de câțiva ani, se părea că dezvoltatorii web au luat-o puțin razna. Echipele expediau pachete JavaScript de 5MB, 10MB sau chiar mai mari și credeau că nu există nicio problemă în acest sens. La urma urmei, aplicațiile funcționau perfect pe MacBook Pro-urile cu motor i7 ale dezvoltatorilor, așa că ar trebui să funcționeze bine pentru toată lumea, nu?

Din păcate, în lumea reală, nu toată lumea rulează cel mai nou și cel mai bun hardware. Sute de milioane de oameni accesează internetul doar pe telefoane Android mai vechi, cu o putere de procesare puțin mai mare decât un cartof, prin conexiuni de internet doar puțin mai rapide decât dial-up. Pentru acești utilizatori, un pachet uriaș de JavaScript durează o veșnicie pentru a se încărca și chiar mai mult timp pentru ca dispozitivul lor să îl analizeze și să îl ruleze. Chiar și în cazuri mai puțin extreme, există nenumărați utilizatori din întreaga lume care nu folosesc cel mai nou și cel mai bun hardware. Pentru aceștia, aplicațiile JavaScript masive sunt utilizabile (dar dureroase).

Angular Ivy

Renaratorul Angular Ivy va ajuta în mai multe moduri:

1. Este scris cu gândul la eficiență, astfel încât va îndeplini aceleași sarcini executând mult mai puține instrucțiuni de CPU. Acest lucru va îmbunătăți atât durata de viață a bateriei, cât și sănătatea mintală a utilizatorilor cu dispozitive mai puțin puternice.
2. Rendor-ul va fi scris într-o manieră mult mai modulară decât randorul actual. Acest lucru îl va face mult mai ușor de a face tree-shaking și de a elimina codul mort. Ca urmare, pachetul JavaScript de producție va include doar codul necesar pentru a vă rula aplicația, în loc să adune laolaltă totul plus chiuveta de bucătărie, așa cum se întâmplă adesea cu randarea actuală.
3. În plus față de reducerea dimensiunii pachetului și îmbunătățirea vitezei de randare, Angular Ivy are alte câteva îmbunătățiri ale calității vieții pentru dezvoltatorii Angular. Timpii de reconstrucție sunt semnificativ mai rapizi. Deci, dacă vă rulați aplicația în modul de dezvoltare și așteptați ca modificările dvs. să apară, acum veți petrece mult mai puțin timp așteptând.
4. Verificarea tipului de model este îmbunătățită, ceea ce înseamnă că veți prinde mai multe erori la compilare în loc de la execuție. Erorile de tip șablon în timpul execuției sunt enervante, deoarece fie vă mușcă în timpul testării, fie îi mușcă pe utilizatorii dvs. atunci când încearcă să vă folosească aplicația.
5. Compilatorul de șabloane Angular Ivy va genera cod care este lizibil pentru oameni, ceea ce compilatorul actual al View Engine nu face. Acest lucru va fi util atunci când încercați să depistați bug-uri dificile ale șabloanelor.

Rezultatul net: aplicații mai mici, aplicații mai rapide, dezvoltatori mai fericiți și utilizatori mai fericiți.

Angular 9

Iată o prezentare generală a Angular 9.

Principalele repere includ:

• Funcționalități Angular încorporate
• Dezvoltare matură cu Angular
• Înțelegerea motoarelor de vizualizare Angular
• Angular Ivy rezolvă probleme de lungă durată
• Angular Ivy și Mobile
• Selectorul…less Directives
• Angular Diagnostics Improvements
• Internationalization with Angular Ivy
• DI and Type-Safe in Angular 9
• Dependency Injection Changes in Angular Core
• Angular Benchmarks (Angular 8.2.7 vs. 9.0.0-next.5)

Angular 10

Versiunea Angular 10.0.0 a fost lansată la sfârșitul lunii iunie 2020. O versiune majoră, Angular 10 include modificări cum ar fi un nou selector de intervale de date în Angular Material, actualizarea versiunilor TypeScript, actualizări ale versiunilor de bibliotecă și multe altele.

Noile caracteristici includ:

• Interfața compilatorului Ngtsc
• Configurarea timeout-urilor asincrone
• Raportarea fișierelor de blocare expirate
• Calcularea leneșă a basePaths

.

• Merging Translation Files
• Explicit Mapping

Angular 11

Angular versiunea 11.0.0 a fost lansată în noiembrie 2020. Versiunea majoră Angular 11 oferă actualizări în întreaga platformă, inclusiv în cadrul CLI și al componentelor.

Caracteristicile semnificative includ:

• Faster Builds with TypeScript 4.0
• Harnesses de testare a componentelor
• Actualizări ESLint
• Actualizări ale Serviciului de limbi actualizate de previzualizare
• Actualizări ale suportului Hot Module Replacement (HMR)
• Ambunătățirea rapoartelor și a înregistrărilor
• Inliinierea automată a fonturilor

Angular’s Past, Prezent și viitor

Dacă ați folosit Angular de la începuturile sale și până acum, atunci felicitări! Deși au existat o mulțime de momente dificile, am ajuns să avem un cadru rapid, modern și plăcut de utilizat.

Dacă ați fost un dezvoltator AngularJS, dar ați trecut la React, Vue sau altceva, vă încurajez să mai aruncați o privire la Angular. Merită timpul dumneavoastră, chiar dacă decideți să rămâneți cu ceea ce folosiți acum.

Și dacă nu ați folosit niciodată Angular deloc, de ce să nu-i dați o șansă?

Noi tocmai am făcut un tur în vârtej prin trecutul, prezentul și viitorul lui Angular. Fără îndoială, a fost o călătorie pe cinste. Indiferent de trecutul dumneavoastră în Angular, sper că v-ați bucurat de acest tur!

Cu ce framework lucrați și de ce? Dacă aveți întrebări sau comentarii, nu uitați să le introduceți mai jos.

Căutați componente UI agnostice pentru framework? GrapeCity are un set complet de componente UI JavaScript, inclusiv grile de date, diagrame, indicatoare și controale de intrare. Oferim, de asemenea, componente puternice de foaie de calcul, controale de raportare și vizualizări de prezentare îmbunătățite. Avem un suport aprofundat pentru Angular (precum și pentru React și Vue) și suntem dedicați extinderii componentelor noastre pentru utilizarea în cadrele JavaScript moderne.