Coduri de compromisuri
Slujba noastră presupune arbitrarea a ceea ce se numește compromisuri. Este vorba de definirea punctelor pozitive și negative ale unei soluții și de estimarea soldului. Alegem soluția care corespunde cel mai bine (cel puțin în ochii noștri) nevoilor noastre în acest fel.
Cu toate acestea, există un sistem de dogme în industria noastră. Nu mai căutăm să punem compromisurile în perspectivă și să le comparăm, ci să luptăm cu „școlile de gândire”, fiecare având dezvoltate axiome (principiu nedemonstrat, dar folosit ca bază pentru raționament).
În urma unei alte dezbateri cu privire la tehnologiile moderne utilizate în front-end, respinse de apărătorii unora dintre aceste axiome, voi încerca să raționalizăm abordarea noastră și să explic avantajele sale.
Ideea aici este de a face a intelege de ce folosim aceste abordări și tehnologii, în ce context, și să nu le impui nimănui. Cu puțin noroc, acest articol va schimba unele discursuri din „nimportawak (sic)” în „nu este pentru tipul meu de proiect”.
Inițial, web-ul este conceput ca un set de documente: fiecare pagină este una. Cu fiecare navigare, declanșăm un nou ciclu de viață de pagină: încheiem pagina curentă, inițializăm următoarea.
Acest model este foarte simplu și permite o experiență foarte corectă pentru paginile în mare parte statice.
Avem o pagină difuzată în HTML, o foaie de stil difuzată în CSS. Si asta e. Aflăm că trebuie să le separăm bine (în numele principiului separării preocupărilor, în cazul în care există unul care dă peste cap, trebuie propusă o experiență degradată.
De-a lungul anilor, cerințele utilizatorilor au devenit mai mari: au trebuit să li se răspundă cu pagini mai interactiv și tehnici de reîncărcări parțiale pagina (ciclul de viață al unei pagini fiind destul de scump). Așa că am început să adăugăm o inteligență limitată cu puțin JS, în special câteva cărămizi interactive, încărcând sfârșitul paginii cu AJAX.
Aceste tehnici au făcut posibilă drasticitatea îmbunătățiți experiența de navigare utilizatori: avem mai puține date de încărcat, afișăm ceea ce doresc oamenii să vadă mai repede (ar fi totuși puțin enervant să încărcați o pagină nouă imediat ce faceți zoom pe Google Maps). Și este aici primul compromis:
- încărcăm mai multe date la încărcarea inițială a paginii (JS),
- Dar acest lucru ne permite să încărcăm mai puține date despre încărcări succesive.
Apoi vine proliferarea platformelor mobile. Pentru a ajunge la utilizatori, Web-ul nu mai este THE platformă, dar A platformă printre altele. Apoi devine interesant strategic pentru companii să înceapă să dezvolte baze comune sub formă deAPI-uri la care se vor abona mai mulți clienți de pe diferite platforme.
În acel moment, front-end-ul a cunoscut o schimbare fără precedent: am început să creăm aplicații reale, nu mai sunt documente la care unele caracteristici sunt altoite aleatoriu. Apoi achiziționăm instrumente mai avansate, bazate pe tipare deja dovedite în alte domenii ale software-ului (cum ar fi MVC). S-au dus zilele fișierului JS care inițializează 3 pluginuri jQuery pentru a face carusele.
Apoi începem să gândim în termeni de vederi. De asemenea, obținem o anumită independență față de back-end, ne putem genera interfața direct din JS.
Nu mai trebuie neapărat să învățăm cum funcționează stiva back-end, organizarea ei, limbajul său de modelare: devenim stăpânii stivei noastre.
Abordăm noi probleme, cum ar fi rutare, preluarea datelor și crearea de cache-uri inteligente pentru clienți. Cadrele care oferă soluții la acestea apar (Angular, Ember și Backbone pentru a numi câteva).
Apoi React ajunge cu o abordare unică a concurenților săi: componentele. Creăm câte unul pentru fiecare bloc reutilizabil al aplicației.
O componentă este o cutie neagră care ia parametri (recuzită), poate avea o stare locală și care va descrie interfața în orice moment.
React vine și cu JSX, o extensie a JS, care permite descrierea interfeței sale într-o formă asemănătoare HTML (XML), dar fără limitările sale (cum ar fi necesitatea serializării atributelor). În timp ce păstrează familiaritatea HTML (și relevanța unei astfel de sintaxi pentru a reprezenta un arbore de elemente), JSX răspunde la o frustrare din ce în ce mai mare cu șabloane „fără logică” care au forțat crearea de asistenți și transformarea datelor în amonte.