Firma la care lucrez are o bucătărie cum alta nu mai este. Și asta nu din cauza aparatului industrial de cafea la care se face coadă în fiecare dimineață. Nu, motivul e altul: conversațiile. Cu greu se poate să treci pe acolo și să nu te alegi cu o conversație. Concedii, grădinițe, vreme, filme, mașini, gadgeturi și… convingeri. Și când spun convingeri, desigur că mă refer la aspectul tehnic al muncii noastre.
Săptămânal, îmi e dat să aud afirmații precum "Și uite,de aia nu-mi place mie Angular." Sau, "JavaScript? Hahaha…" Nelipsind nici "Voi front-end developers nici măcar nu sunteți programatori adevărați!" (Asta chiar a durut.) Dar stai, că nu durează mult și intervine "Angular? Să fim serioși..." Și nu în cele din urmă, eternul "Typescript? Păi, ăla e JAVA toată ziua!" Folclor sau nu, ai înțeles ideea. Știu, dragă cititorule, că la fel ca și mine, te confrunți cu adversari foarte abili. Așa că m-am gândit să trecem în revistă câteva cuvinte cheie din lumea proaspătului-lansat Angular 2. Pentru că niciodată nu știi pe cine întâlnești data viitoare în bucătărie.
Dacă cumva n-ai fost prin zonă în ultimii 5 ani, astăzi scriem SPA-uri (Single Page Applications), nu doar site-uri. De ce? Pentru că utilizatorii vor viteză. Nu au timp să aștepte după server roundtrips sau după pagini HTML servite una câte una. În concluzie, nu ne permitem să servim 20 de fișiere JS într-o pagină. Nicidecum. Astăzi, servim unul singur, care conține toată aplicația noastră. El se numește bundle. Dar acest bundle nu conține doar JS. El poate conține tot: atât HTML și CSS, cât și JS.
"Nu sună rău," vei zice, "dar cine știe să îmi adune toate fișierele și să le pună în acest bundle?" Există mai multe tooluri, dar unul de top este Webpack. Webpack este un module bundler. Ce înseamnă asta? Un module bundler e un tool căruia îi servești modulele pe care le-ai scris. Apoi el rezolvă dependințele dintre module, urmând ca rezultatul să consiste dintr-un fișier: bundle-ul tău. Acel bundle creează toate elementele HTML necesare în momentul în care e rulat în browser. De asemenea, tot bundle-ul aplicației e cel care injectează CSS-ul în aplicația ta la runtime. Magic!
"Dar ce sunt acelea module?" Excelentă întrebare! Toată lumea râdea de JavaScript până nu demult. Și principalul motiv era faptul că JS îți permitea să declari variabile globale cu ușurință. Adică, orice zonă a aplicației tale putea să aibă acces la variabila creată de tine și s-o modifice. Și de aici problema: Devine tot mai greu să urmărești starea aplicației tale în timp. Cine modifică variabila și de ce? Aici intervin modulele. În loc să fie totul expus în câmp deschis, cum era în cazul variabilelor globale, un modul e ca și un gard în jurul curții tale. Orice faci în curtea ta rămâne acolo. Dacă vrei să îi arăți vecinului ce faci, iei ce ai și exporți peste gard. În acest fel, vecinul poate folosi din ce ai tu în curtea ta, dar tu controlezi exact ce anume. Așadar, aplicația ta poate fi considerată un cartier. Un cartier care e format din mai multe curți închise care comunică în mod controlat între ele.
Deci, un modul poate importa elemente din alte module și poate exporta în aceeași manieră către alte module. Ceea ce înseamnă că aplicația devine un graf format din dependințe între module. Cine ne oferă acestă funcționalitate? Chiar JavaScript, prin noua versiune ES2015 (denumită și ES6, nume care vine de la grupul care defineste standardele JS: ECMAScript, pe scurt — ES)! Lucrurile s-au schimbat destul de mult de la era jQuery încoace, nu-i așa? Și nu te plafona în faptul că avem nevoie să convertim codul ES6 în ES5. Această problemă e temporară. Producătorii de browsere sunt mai convinși ca niciodată că trebuie să țină pasul mai îndeaproape cu noile standarde ECMAScript, așadar, în câțiva ani nu vom mai avea această problemă.
Dacă încă citești aceste rânduri, poate te întrebi de ce nu am zis nimic de Angular 2 până acum. Bună întrebare! Felul în care scriam JavaScript în trecut (inclusiv Angular 1) e diferit de felul în care scriem Angular 2. De altfel, schimbarea majoră a venit odată cu… React. Da, ai citit bine! În 2013, când apare React în lumea JS, acesta introduce un nou concept care avea să influențeze web development-ul considerabil: Web Components. Adică elemente customizate, create de către developer care să permită reutilizarea lor pe parcurs. Cu alte cuvinte, o parte de aplicație care primește o informație și știe ce să facă cu ea. O parte încapsulată. Modulele și clasele introduse de către ES2015 ne pun la dispoziție tocmai vocabularul de care aveam nevoie pentru a putea scrie aceste Web Components. Știm că React e performant tocmai datorită felului în care e transmisă informația între componente, permițănd optimizarea operațiilor costisitoare de UI. Deci Angular 2, în mod natural, devine mult mai performant decât versiunea inițială tocmai din acest motiv. Faptul că există un astfel de nivel de deschidere care să permită lucrul în echipă între diferite proiecte din lumea JS e un avantaj pentru fiecare din noi.
Acum că avem noțiuni de bază despre Web Components, probabil ne întrebăm cum comunică acestea între ele. Change Detection e complet rescris în Angular 2. Acest nou mecanism de administrare a schimbărilor care apar în structura informației a fost încapsulat într-o nouă librărie: Zone.js. Această librărie oferă posibilitatea execuției codului într-un mediu delimitat (denumit Zone), în care schimbările asupra variabilelor sunt detectate chiar și asincron. Datorită performanței și utilității lor, Zones au fost propuse pentru a fi incluse într-o versiune viitoare de JavaScript.
O altă schimbare intervine în felul în care circulă informația în cadrul aplicațiilor Angular 2. Dacă în versiunea precedentă eram obișnuiți să modificăm date într-o parte și schimbările să fie reflectate peste tot pe unde se folosesc acele date (concept numit Double Data Binding), aceasta s-a dovedit a nu fi cea mai bună abordare din cauza problemelor de performanță. Așadar, cum am amintit mai sus, Angular 2 pășește din nou pe urmele lui React și adoptă ca stil default de lucru Single Data Binding. Dacă înainte aveam o stradă cu două sensuri pentru circularea datelor în aplicații, acum avem by default o stradă cu sens unic. Informația întotdeauna pleacă dintr-o parte și circulă către layerul UI. Ca urmare a acestei schimbări, performanța lui Angular 2 e vizibil îmbunătățită față de predecesorul său.
Dacă deja simți că se lasă tăcerea în bucătărie, acum e momentul să spui "Dar stați, că n-am terminat!" Angular 2 recomandă să folosim TypeScript. Ce e Typescript? E o extensie a limbajului JavaScript care permite anotarea tipurilor de date. Știu, e controversat. Acum mai bine de un an, când am văzut prima dată TypeScript, ideea nu mi-a surâs foarte tare. Dar între timp, am văzut că există două feluri de a folosi TypeScript: ca pe un tool care să ajute la viteza de development, respectiv ca pe o povară, din cauză că vrei ca totul să fie anotat până la ultimul punct și virgulă. Pe scurt, recomandarea mea e pentru a folosi TypeScript în măsura în care e util și ne ajută să fim mai eficienți. Dar am observat din proprie experiență că sunt mult mai rapid folosindu-l.
E imposibil să acoperim totul despre Angular 2 într-un articol. Deja am sentimentul că trebuie să scriu mai mic, ca să fiu sigur că încape tot. Noua versiune a frameworkului ne oferă și alte funcționalități. Server-Side Rendering permite generarea primului view direct pe server și servirea lui în variantă statică -- totul în numele vitezei sporite. Faptul că nu e gândit doar pentru browser, ci și pentru server (ajungând chiar și în ecosistemul mobile), face din Angular 2 o platformă, nu doar un framework. Ahead of Time Compilation (AoT) înseamnă că template-urile HTML pot fi compilate direct pe server si apoi trimise direct către browser pentru a fi folosite. Vechea metodă, Just in Time Compilation (JiT) presupune că browserul trebuie să facă toată munca de randare a template-urilor. De asemenea, se poate folosi acum și Tree Shaking, o metodă care presupune analizarea statică a bundle-ului generat și eliminarea codului care nu e necesar. Scopul acestei tehnici este să elimine cât mai mult cod din framework cu putință. Lista nu se termină aici, dar acestea sunt cele mai importante noutăți.
În încheiere, sper că subiectele abordate mai sus să te ajute data viitoare când te găsești în mijlocul unei conversații despre lumea frontend. Angular 2 e un tool excelent, care va fi cu noi… încă preț de câteva luni. Pentru că Google pregătește deja lansarea Angular 4 în prima parte a lui 2017 (au trecut pe Semantic Versioning). Saltul peste versiunea 3 se datoreaza faptului că vor să păstreze constistența cu librăria de routing pentru Angular, ea însăși ajunsă la versiunea 4. În mod evident, diferențele nu vor fi așa dramatice ca și trecerea de la versiunea 1 la 2, dar schimbări tot vor fi. Și acesta nu e rău, chiar dimpotrivă, pentru că nu e doar datoria toolurilor pe care le folosim să progreseze, ci și a noastră să ținem pasul cu ele. În loc să ne plângem de afluxul de librării și tooluri din lumea JS, mai bine să fim mulțumitori pentru toate jucăriile care ne sunt puse la dispoziție în lumea connected în care trăim. Pentru că, până la urmă, să fii JS Dev in 2016 e ca și cum ai fi un copil mic scăpat liber într-un magazin de jucării, cum ar spune Eric Elliott. E o lume dură în bucătăriile firmelor. Vreau să cred că și tu și eu avem acum o armă în plus care să ne ajute să supraviețuim.