La câteva luni distanţă de 2022, deja ne stă gândul la anii ce urmează. Tehnologic vorbind, ne-am schimbat modul de a ne raporta la viitor. Începând cu un sprint agil ce se termină în două sau trei săptămâni, un deadline de câteva luni, până la un răspuns la întrebările "Unde te vezi peste cinci ani? Dar zece? ".
Totodată, știm cu toții că experiența din trecut ne definește prezentul și ne modelează viitorul. Putem ajunge la un moment dat să ne căutăm adevărul pe care îl bănuim deja, adeverind ceea ce se numește, de fapt, confirmation bias.
Pe parcursul articolului voi răspunde la una dintre cele mai grele întrebări din istoria dezvoltării de aplicații web: "eu ce framework să pun pe proiect?"
Se vorbește mult în web despre framework versus librării. Fie că alegem un framework sau o librărie, deși sunt lucruri total diferite, acestea reprezintă de cele mai multe ori un punct de cotitură pentru o aplicație şi cea mai importantă decizie pentru aceasta.
O diferență superficială menționată pe scurt evidențiază că un framework ne oferă un model sau un anumit design, pe când o librărie este o colecție de funcții sau clase, fără însă limitare la design. În momentul de față, are câștig de cauză librăria/frameworkul cu cel mai bun state management.
Cam aceasta este cea mai des întâlnită situație din web. State management. Pe scurt, aplicațiile web de până nu demult erau în mare parte fără stare (stateless). Un utilizator apela o pagină web și serverul răspundea cu informație (în general cu un HTML). De aici, comunicarea utilizator - server se oprește, până când utilizatorul solicită altă pagină sau formular. Starea se resetează și tot procesul de comunicare cu serverul începe din nou. Iar state-ul este la momentul actual diferența dintre o pagină de tip document și o aplicație web de genul Gmail, cu ale sale funcționalități de drag & drop și interacțiuni cu emailuri, comunicări impresionante user-server, toate fără ca pagina să se și miște din loc! Aparent.
În ceea ce privește serverele, încă nu am fost convins- cel puțin personal- de JavaScript. Dar pentru cei care doresc să fie aventurieri, cea mai bună variantă din ultimii ani este Node.Js împreună cu framework-ul Express. Sunt multe argumente pro și contra într-un debate de a pune JavaScript pe server. În ceea ce mă privește, mai multe contra.
Rămânem pe moment cu acest răspuns temporar și propun să ne întoarcem în istorie.
Undeva prin 2009, când am luat prima dată contact cu acest limbaj de programare, JavaScript era înfiinţat de 14 ani, iar prima și cea mai mare librărie de pe atunci, jQuery, avea trei ani.
JavaScript era atunci acel limbaj de programare pentru care trebuia să scrii de cel puțin două ori mai mult cod față de alternativa în jQuery. Pe atunci încă nu înțelesesem că Microsoft a decis să nu implementeze un interpretor pentru JavaScript în browserele Internet Explorer ci pentru un alt limbaj de programare, JScript, care a fost până la urmă un limbaj reverese-engineered, izbitor de asemănător cu originalul. Prin urmare, acest framework jQuery a fost în principal răspunsul problemei de compatibilitate existent între browsere, prin deviza "write less, do more!" Cu toate că este o librărie pe care mulți o consideră pe picior de plecare, aceasta încă se află prezentă în peste 70% din site-urile live. Nu degeaba, încă mai avem zicala "Nu merge? Păi, punem jQuery."
În 2013, ajuns în Cluj-Napoca, descopăr că jQuery și knockout.js erau deja plictisitoare. Acesta a fost primul semnal de alarmă personal, acela de a sări din barca aparent în scufundare a acestor tooluri.
Colegii din breaslă povesteau entuziasmați de un nou framework AngularJS dezvoltat de o echipă de la Google încă din 2010. Acesta a ieșit învingător pentru că a răspuns cererii din exterior de a renunța la pagini statice, de a construi interfețe și conținut dinamic, animat și nu în ultimul rând, adaptabil pe smartphone-uri. Și dus am fost, luat de val.
Urmează modelul din 2016. Mă regăseam visând la o nouă librărie dezvoltată de Facebook și lansată undeva prin 2013. Această librărie a răspuns din nou cererii, rezolvând de această dată problema "prea multe tooluri și linii cod, pentru o simplă aplicație".
Trecerea de la Angular la React a fost plină de peripeții. Acele multe unelte (pline de opinie) pe care le aveam la dispoziție în Angular au dispărut complet în React. Aveam impresia că trebuie să construiesc un zgârie-nori, folosind piese de lego. Dar, pe măsura ce anii au trecut, piesele de lego au ajuns să crească în înălțime, iar curba de învățare a devenit una interesantă și mai puțin complicată.
Opinii găseam și aici, iar modul atomic de a dezvolta o aplicație, se putea aplica și înainte. Însă această librărie m-a cucerit cu perfecta balanță între a programa foarte aproape de sintaxa limbajului în sine, având în mânecă și câteva concepte ajutătoare din sfera librăriilor și, totodată, una dintre cele mai bune compatibilități cu sisteme de state management văzute până atunci. Mă arunc să spun precum alții: ideologia reactivă de programare va dăinui mulți ani după inevitabila dispariție a librăriei React.
Pe bună dreptate, mulți dezvoltatori sunt de părere că React a fost și încă este un direct competitor pentru Angular. La această afirmație aș adăuga că abia de acum am început să dezvoltăm un ecosistem stabil într-un limbaj de programare relativ nou. Ceea ce pare a fi competiție este de fapt stabilitate într-un domeniu aflat în plină expansiune.
VueJs ar putea fi unul dintre competitorii direcți ai Angular, iar React s-ar număra printre aceștia doar dacă luăm în calcul transferul dezvoltatorilor de pe o tehnologie pe alta. Dar acest lucru se întâmplă în mare parte de ambele tabere.
În anii ce au urmat, am început să aprofundez și mai mult acest limbaj, iar entuziasmul cu care afirmam că "JavaScript o să fie peste tot, îl punem pe sateliți, îl punem pe frigider, practic îl punem și în cafea!", era de-a dreptul stânjenitor. Evident că s-a adeverit că nu e chiar așa. Dacă astăzi ar fi ceva de menționat despre acest limbaj, aș afirma tocmai opusul. Fiecare decizie de a pune un limbaj de programare într-un anume medium, doar de dragul de a face asta, devine într-un final chiar imposibilă. Pentru că de cele mai multe ori locul unui limbaj de programare este acolo unde a fost conceput să fie. Iar locul limbajului JavaScript rămâne în browser sau într-un motor de browser. Acum, că am început să punem motoare de browser în mașini și sateliți, afirmația de mai sus poate că nu mai are sens, dar încă se aplică!
Începând din 2021 mă uit entuziasmat spre o altă librărie, Svelte. Aceasta promite că poți scrie mai puțin cod, nu deține virtual dom, fiind o librărie cu adevărat reactivă. Şi de această dată, librăria parcă este scrisă fix pentru mine!
Prin urmare, la întrebarea "eu, ce framework să pun pe proiect?" putem avea două variante de răspuns. Unul, pentru prezent: Ce-ţi sună mai bine dintre Angular, VueJS, React? Alege varianta preferată, cu coding-style preferat şi vei avea pace câțiva ani. Acestea încă sunt în plină expansiune. Și altul, pentru viitor: Svelte este cea mai bună variantă pentru o privire în viitor, pentru următorii trei- patru ani. Acest tool are potențialul de a detrona librărie după librărie în fiecare an. Inclusiv în ceea ce privește full-stack.
Ce putem remarca în istoria acestui limbaj? Cele mai vechi frameworkuri sunt încă de actualitate, cu toate că jQuery pierde treptat popularitate. Acesta rămâne o librărie de nișă, folosită la nevoie sau în fundal, îndeajuns de populară chiar și pentru ziua de azi. Aş fi spus în urmă cu zece ani (când și atunci era pe punct de plecare) că este deja veche!
Cât privește Angular și React... Acestea au un ecosistem matur, de ani de zile îmbunătățit constant, dar este îndeajuns cât să mai reziste în luptele pentru supremație, unde zicala "new is better" este definitorie? Probabil că nu, probabil că da. Dacă le privim ca pe simple branduri care se reinventează ori de câte ori au ocazia și inovează atât de bine, încât împing de la spate limbajul de programare spre a ține pasul cu acestea, am putea spune că și peste zece ani vom mai povesti despre Angular versus React.
Ce factori ar mai putea detrona acești doi giganți? Unul ar fi o librărie care oferă răspunsul la probleme și care ne determină să ne punem întrebări pe care nu știam că le aveam. Al doilea ar fi limbajul în sine. Limbajul JavaScript a ajuns în sfârșit la maturitate și deține avantajul stabilității. Putem pune niște baze pe acesta. Baze, care puse azi, pot sta și mâine în picioare. Singurul dezavantaj al unui limbaj ajuns la maturitate este acela de a fi concurat de alte limbaje. De exemplu, Dart excelează în performanţă, iar Python se evidențiază cu al său framework Django la capitolul complexitate şi capabilități de machine learning.
Influența și înclinarea spre o librărie pornește, în primul rând, din exterior și prinde contur în funcție de experiența proprie.
Cum știi dacă ai ales librăria perfectă? Un răspuns rapid e că nu știi. Apoi, chiar dacă ai ales greșit, este important bagajul și experiența cu care pleci spre alte librării și frameworkuri.
Ne întoarcem din nou la întrebarea "eu, ce framework să pun pe proiect?". Dacă vrem să aflăm răspunsul, trebuie să mai adresăm și următoarele întrebări și îndemnuri: Care sunt bagajele tale de cunoștințe curente? Construiește în jurul lor. Ai învățat Python în facultate? Dă-i o șansa lui Django, înainte de a te arunca într-un alt ecosistem.
Așadar, dacă ne punem întrebarea pornind de la ecosistemul JavaScript, aș recomanda perfecționarea limbajul în sine. Ulterior, ce vine pe lângă poate fi catalogat ca un factor de ajutor.
Din păcate sau din fericire, în acest domeniu care se modelează constant, lucrurile nu stau foarte bine fixate, iar adevărul de ieri este adevăr azi până la proba contrarie.
Experiența anilor de programare devine din ce în ce mai puțin relevantă, ieșind la suprafață importanţa dezvoltării continue. Așadar pierdem mai bine de 40% de informație relevantă anual, dar rămânem cu siguranța că și de această dată ne putem avânta în necunoscut, fie el limbaj nou de programare, proiect nou sau un domeniu cu totul diferit. De aici încolo ne ajută și patternul neuronal care își amintește de evenimente asemănătoare și ne susține inconștient.
Prin urmare, la întrebarea ,,pentru ce tip de proiect?" răspundem că doar un aspect este cert: cu cât proiectul este mai complex, cu atât te ajută să poți controla librăria sau să te aliniezi cât mai aproape de limbajul de programare, pentru un control a tot ceea ce înseamnă performanță și stabilitate. În cealaltă extremă, cu cât este mai mic, se poate încerca orice librărie sau framework , oricât de experimentală este. În mare parte, adevărul este undeva la mijloc.
Evenimentele externe ale lumii înconjurătoare precum şi schimbările climatice pot și vor influența atât modul nostru de lucru cât și felul în care gestionăm într-un final energia în aplicații.
Acest nou normal poate însemna că vremurile în care adăugăm librării peste librării, fiecare încărcată cu mai multe linii de cod câte nu au văzut sisteme de operare în secolulul 20, încep să apună. Lăsând la o parte performanța, eficienţa codului și necesitatea de a transmite un flux cât de mic la server cu un răspuns și mai mic la utilizatori, era oare necesar un factor extern, pentru a ne forța să ne realiniem? Cel mai probabil că da.
În ultimii ani, a devenit un standard ca o pagină web formată dintr-un formular și câteva texte, împreună cu un framework principal și alte câteva zeci de librării să ajungă să cântărească ordinul megabiților. Era oare nevoie de o schimbare climatică să ne pună în situația de reflexie asupra amprentei de carbon pe care o pot avea aplicațiile noastre?
Așadar, scrie mai puțin, fă mai mult ( write less, do more) !
Dacă privim strict din punct de vedere al maturității unei librării sau al unui limbaj de programare, remarcăm că principiul ,,Cu cât mai vechi, cu atât mai bine" (The older, the better) se luptă constant cu acela ,,Noul este mai bun" (New is better).
Când încercăm să rezolvăm o problemă existentă sau viitoare, apar, de regulă, noi limbaje sau noi frameworkuri şi de cele mai multe ori noi librării. Insistând să rezolvăm probleme noi sau inexistente, le putem uita pe acelea care au fost deja rezolvate sau pe acelea care își așteaptă soluțiile. Oricum, ceea ce este esențial de luat în considerare este că problemele nerezolvate ies întotdeauna la suprafață.
de Ovidiu Mățan
de Ovidiu Mățan
de Mircea Ifrim
de Ovidiu Mățan
