Framework front-end: soluții sau probleme umflate?

Cadrele front-end moderne necesită să descărcați un mediu de dezvoltare, complet cu dependențe și să vă compilați codul înainte de a încerca chiar să îl vizualizați în browser. Este acesta un lucru bun? Problema este că construim site-uri mai complexe, sau este că cadrele sunt complexe în sine, introducând un nivel inutil de complexitate?

Dezvoltarea web de astăzi a evoluat mult din anii '90; suntem capabili să creăm experiențe întregi care sunt foarte aproape de ceea ce poate face orice aplicație nativă, iar procesul de dezvoltare s-a schimbat și el. Au dispărut vremurile în care a fi dezvoltator web front-end era o chestiune de a deschide Notepad, de a tasta câteva rânduri de cod, de a-l verifica în browser și de a-l încărca într-un folder FTP.

Dezvoltarea web front-end din trecut

Trebuie să încep prin a afirma ceea ce este evident: lumea nu este ca acum 10 ani. (Șocant, știu.) Singurul lucru care rămâne constant este schimbarea. Pe vremuri, aveam foarte puține browsere, dar existau o mulțime de probleme de compatibilitate. Astăzi, nu vedeți prea mult lucruri precum „cel mai bine vizualizat pe Chrome 43.4.1”, dar pe atunci, era destul de comun. Avem mai multe browsere acum, dar mai puține probleme de compatibilitate. De ce? Din cauza jQuery . jQuery a satisfăcut nevoia de a avea o bibliotecă standard, comună, care să vă permită să scrieți cod JavaScript care manipulează DOM-ul fără a fi nevoie să vă faceți griji cu privire la modul în care va rula pe fiecare browser și pe fiecare versiune a fiecărui browser - un adevărat coșmar în anii 2000 .

Browserele moderne pot manipula DOM-ul ca standard, astfel încât nevoia unei astfel de biblioteci s-a diminuat mult în ultimii ani. jQuery nu mai este necesar , dar încă putem găsi o serie de plugin-uri extrem de utile care depind de el. Cu alte cuvinte, cadrele web pot să nu fie necesare, dar sunt totuși suficient de utile pentru a fi populare și utilizate pe scară largă. Aceasta este o trăsătură comună pentru majoritatea cadrelor web populare, de la React, Angular, Vue și Ember până la modele de stil și formatare precum Bootstrap.

De ce oamenii folosesc cadrele

În dezvoltarea web, ca și în viață, a avea o soluție rapidă este întotdeauna la îndemână. Ați mai făcut vreodată un router în JavaScript? De ce să treceți prin procesul dureros de învățare când puteți instala npm un cadru front-end pentru a depăși problema? Timpul este un lux când clientul dorește ca lucrurile să fie făcute ieri sau moșteniți cod de la un alt dezvoltator proiectat pentru un anumit cadru sau dacă vă integrați cu o echipă care folosește deja un anumit cadru. Să recunoaștem – cadrele există cu un motiv. Dacă nu ar exista beneficii pentru ele, nimeni nu le-ar folosi.

Deci, care sunt unele dintre beneficiile și proprietățile unice ale utilizării unui cadru de dezvoltare web?

Timpul inseamna bani. Când dezvoltați un proiect și clientului nu îi pasă ce cadru folosiți - într-adevăr, probabil nici măcar nu este conștient de ceea ce utilizați - îi pasă doar să obțineți rezultate și cu cât mai repede, cu atât mai bine. Cadrele stabilite vă permit să creați un sentiment instantaneu de progres de la început, pe care clientul îl tânjește din prima zi. În plus, cu cât vă dezvoltați mai repede, cu atât câștigați mai mulți bani, deoarece timpul eliberat de framework poate fi redirecționat pentru a prelua mai mult. proiecte.

Totul tine de comunitate. Atunci când alegeți un cadru, acesta este un punct foarte important - cine vă va ajuta atunci când rămâneți blocat într-o problemă? Tu și cu mine știm amândoi că se va întâmpla la un moment dat. Veți ajunge într-un punct în care trebuie să faceți ceva la care cadrul nu a fost intenționat să facă sau la care cadrul nu a fost conceput niciodată pentru a vă oferi acces, așa că este esențial să aveți o comunitate care să vă sprijine. Dezvoltarea – în special freelance – poate fi dificilă, deoarece sunteți cufundat într-o lume virtuală, iar dacă sunteți singurul dezvoltator web front-end dintr-o echipă, înseamnă că sunteți singurul cu experiența și expertiza necesară pentru a găsi un soluţie. Dar dacă cadrul front-end pe care îl utilizați are un suport solid, va exista cineva de cealaltă parte a lumii care s-a confruntat cu aceeași problemă și s-ar putea să vă ajute.

Standardele sunt frumoase. Ați observat vreodată că, atunci când vă uitați într-o bucată veche a propriului cod, puteți naviga prin ea destul de ușor? Sau cel puțin, mai ușor decât o bucată de cod scrisă de altcineva? Gândești într-un anumit fel și ai propriul tău mod de a numi lucrurile și de a organiza codul. Acesta este un standard. Cu toții îi urmăm, chiar dacă sunt doar pentru noi. Tindem să mâncăm lucruri similare la micul dejun, să ne trezim la o anumită oră și să ne punem cheile în același loc în fiecare zi. Și într-adevăr, dacă ne-am schimba rutinele în fiecare zi, viața ar fi mult mai grea doar din cauza faptului că ne-am gândit cum să facem lucruri. Ți-ai pierdut vreodată cheile pentru că le-ai pus în alt loc decât în ​​mod normal? Standardele fac viața mai ușoară. Când lucrează ca parte a unei echipe sau a unei comunități de dezvoltatori, aceștia devin absolut indispensabili.

Framework-urile oferă un standard din momentul în care le instalați, ghidându-vă să gândiți și să codificați într-un mod specific. Nu trebuie să petreci timp creând un standard cu echipa ta; poți doar să urmărești cum se fac lucrurile în cadru. Acest lucru face mai ușor să lucrați împreună. Este mai ușor să cauți o funcție când știi că funcția trebuie să fie într-un anumit fișier, deoarece este construită pentru adăugarea unei rute într-un SPA, iar în cadrul tău, toate rutele sunt plasate într-un fișier cu acel nume. Oamenii cu diferite niveluri de calificare pot lucra împreună dacă aveți acest nivel de standardizare, deoarece, în timp ce programatorii avansați știu de ce lucrurile se fac așa, chiar și dezvoltatorii juniori pot urma standardul în sine.

Când cadrele eșuează

Cu câțiva ani în urmă, a spune ceva de genul „Nu folosesc cadre – nu văd niciun beneficiu real din ele” ar aduce oameni cu torțe și furci la ușa ta. Dar astăzi, din ce în ce mai mulți oameni se întreabă: „De ce ar trebui să folosesc un cadru? Chiar am nevoie de ele? Este atât de greu de codat fără ele?”

Sunt cu siguranță unul dintre ei — nu am fost niciodată un fan al vreunui cadru specific și am programat fără ele toată cariera mea. Dacă am de ales în această problemă, alegerea mea este întotdeauna „Nu, mulțumesc”. Am dezvoltat în JavaScript de ani de zile și înainte de asta în ActionScript. Codificam în Flash când majoritatea oamenilor deja îl considerau moartă. (Știu, știu... dar făceam o mulțime de animații, iar animația în HTML simplu este dificilă.) Așa că, dacă ești unul dintre mulți care nu se gândesc niciodată la codificare fără cadre, permiteți-mi să vă arăt câteva motive pentru care ați putea fii chinuit.

„Mărime unică pentru toate” este o minciună. Vă puteți imagina să scrieți o singură bucată de software care să facă tot ce ați realizat în cariera dvs.? Aceasta este una dintre principalele probleme cu cadrele de dezvoltare web. Proiectul dumneavoastră are nevoi foarte specifice, pe care tindem să le rezolvăm adăugând biblioteci, pluginuri sau suplimente pentru a extinde domeniul de aplicare al cadrului. Niciun cadru nu oferă 100% din ceea ce aveți nevoie și niciun cadru nu este compus 100% din lucruri pe care le veți găsi utile.

Dacă aveți prea mult cod pe care nu îl utilizați, poate avea ca rezultat un decalaj de încărcare pentru site-ul dvs., care devine mai important cu fiecare utilizator suplimentar. O altă problemă este că mentalitatea „o mărime potrivită pentru toate” are ca rezultat un cod ineficient. Luați, de exemplu, $('sku-product').html('SKU 909090'); , care este codul jQuery despre care, în cele din urmă, știm cu toții că va fi tradus în ceva de genul document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

Acest tip de diferență pe o singură linie ar putea părea neimportant, dar schimbarea conținutului unui anumit element al paginii este tocmai virtutea React. Acum, React trece prin procesul de creare a unei reprezentări a DOM-ului și de a analiza diferențele dintre ceea ce încercați să redați. Nu ar fi mai ușor să vizați conținutul pe care doriți să îl schimbați de la început?

Acea încurcătură de buruieni prin care treci crește spini. Ați fost vreodată în situația în care vă utilizați cadrul și încercați să adăugați o bibliotecă la acesta, doar pentru a realiza că versiunea bibliotecii de care aveți nevoie nu funcționează bine cu versiunea de cadru pe care o utilizați? Uneori este nevoie de mai mult efort pentru a face două bucăți de cod să funcționeze împreună decât pentru a scrie codul singur. Și deoarece cadrele și bibliotecile pe care le utilizați sunt adesea construite pe alte cadre și biblioteci care pot avea incompatibilități ascunse pe care nici nu le puteți anticipa, problema poate deveni exponențial mai complexă, ajungând într-un punct în care sunt imposibil de gestionat dacă doresc ca proiectul să continue să crească.

A ține pasul cu Jones este un lucru. Ați lucrat vreodată la un proiect în AngularJS doar pentru a afla că aveți nevoie de ceva care nu a apărut până la lansarea Angular 4? Știați măcar că Angular 5 a fost lansat? Aceasta este o altă problemă uriașă; chiar dacă rămâneți la un singur cadru front-end, atunci când are loc o nouă lansare majoră, lucrurile se pot schimba atât de mult încât codul pe care ați muncit atât de mult să îl creați nici măcar nu va rula pe noua versiune. Acest lucru ar putea duce la orice, de la mici modificări enervante care trebuie făcute pe o mulțime de fișiere până la o rescrie completă a codului.

A ține pasul cu cele mai recente versiuni ale unui cadru este o provocare, dar în aceeași notă, alte cadre au de suferit atunci când actualizările se opresc complet și nu pot ține pasul cu restul tehnologiei. În 2010, atât AngularJS, cât și Backbone au fost lansate pentru prima dată. Astăzi, Angular se află la a cincea versiune majoră, iar Backbone este complet în afara reflectoarelor. Șapte ani par mult timp. Dacă construiți site-uri web, probabil că acestea s-au schimbat complet din punct de vedere estetic și funcțional. Dacă construiți o aplicație, pariul pe un cadru greșit ar putea pune compania într-o situație grea – și costisitoare – mai târziu, când lucrurile trebuie rescrise.

Când tot ce ai este un ciocan, totul arată ca un cui. Dacă ați folosit frecvent cadre de dezvoltare web, probabil că vi s-a întâmplat acest lucru, în care o singură bază de cod definește forma codului pe care îl utilizați în viitor, chiar dacă este legat doar periferic. Să presupunem că vei construi o platformă precum YouTube și că vrei să folosești Framework X. S-ar putea să existe un moment în care, chiar dacă sună ridicol în zilele noastre, te decizi să folosești Flash pentru videoclipuri, pentru că asta vine. construit cu cadrul.

Framework-urile au opinii și sunt puternice; React, de exemplu, vă obligă să utilizați JSX într-un mod specific. Puteți vedea codul folosit în acest fel peste tot. Există o alternativă? Da. Dar cine îl folosește? Acesta nu este întotdeauna un lucru rău, dar dacă aveți nevoie să efectuați animații complexe, este posibil să aveți nevoie doar de un cadru pentru animare și nu de întregul React. Am văzut oameni făcând lucruri nebunești, cum ar fi adăugarea jQuery la o pagină doar pentru a adăuga un nod la un element, ceva ce ar putea fi realizat în vanilla JS cu document.getElementById('id_of_node').appendChild(node); .

Eval este rău, dar .innerHTML este machiavelic

Vreau să îmi iau timp pentru a explora acest punct separat, deoarece cred că acesta este unul dintre motivele pentru care mai mulți oameni nu codifică fără cadre. Când vedeți cum funcționează majoritatea codului când încercați să adăugați ceva la DOM, veți găsi o grămadă de HTML injectat de proprietatea .innerHTML . Se pare că toți suntem de acord că eval este rău pentru rularea codului JavaScript, dar vreau să pun .innerHTML în centrul atenției aici. Când injectați cod HTML ca șir simplu, pierdeți orice referință pe care ați fi avut-o la oricare dintre nodurile pe care le-ați creat. Este adevărat că le puteți recupera folosind getElementsByClassName sau atribuindu-le un id , dar acest lucru este mai puțin practic. Când încercați să schimbați valoarea unuia dintre noduri, vă veți trezi că redați din nou întregul HTML.

Acest lucru este bun când începeți să codificați. Puteți face o mulțime de lucruri simple cu ușurință, fără prea multă experiență. Problema se întâmplă cu complexitatea site-urilor web moderne, care tind să fie mai degrabă ca aplicații - asta înseamnă că trebuie să schimbăm constant valorile nodurilor noastre, ceea ce este o operațiune costisitoare dacă o faci prin reatașarea întregii structuri. prin .innerHTML . React rezolvă această problemă în mod eficient printr-un DOM umbră, iar Angular o abordează folosind legarea ca o modalitate ușoară de a modifica o valoare afișată pe o pagină. Cu toate acestea, poate fi rezolvată destul de ușor ținând evidența nodurilor pe care le creați și salvându-le pe cele care vor fi reutilizate sau actualizate în variabile. Există și alte motive pentru a sta departe de .innerHTML în general.

Cele mai mari mituri despre codificare fără cadre

Timpul inseamna bani. Da, readuc acest concept de mai devreme. Mulți oameni simt că, dacă încetează să mai folosească un cadru web popular, vom trece instantaneu la internetul anilor 90, când <marquee> era eticheta preferată a tuturor, GIF-urile rotative de pe un site Geocities erau la modă și neclintite, Alta Vista era cea mai bună. pentru căutări pe web, iar contoarele de hit erau omniprezente.

Cu cadrele web, primele linii de cod par să facă o mulțime de progrese care economisesc timp, dar la un moment dat, câștigurile se transformă în pierderi. Îți petreci timpul citind despre cum să faci ca framework-ul să facă lucruri pentru care nu este construit, cum să integrezi biblioteci și să le faci să se joace frumos cu cadrul și să afli că codul pe care l-ai creat respectând standardele cadrului nu merge să funcționeze deloc și acum trebuie să-l rescrieți. Când faci lucruri fără un cadru, începi mai încet, dar faci progrese constante. În cele din urmă, totul este despre locul în care vrei să fie partea ușoară. Nu va face mare diferență în timpul total.

Codul meu va fi mai lung decât Marele Zid. A scrie fără un cadru este ca și cum ai cumpăra un film în loc să te abonezi la un serviciu de streaming. Nu aveți acces instantaneu la sute de filme pe care doriți să le vizionați, dar nici nu trebuie să cheltuiți bani pe mii de alte filme pe care nici măcar nu v-ați gândi să le descărcați din magazin. Puteți scrie doar ceea ce aveți nevoie.

Este util intermediarul? Sigur. Dar de obicei nu este necesar . Fiecare linie de cod pe care o scrieți are mai multă semnificație, deoarece nu este nevoie să vă adaptați la cerințele unui cadru. Se poate simți că scrii mai mult cod cu JavaScript pur, deoarece modul de a crea elementele DOM necesită linii pentru a crea un element, a-l atașa la DOM și poate adăuga o clasă pentru stil, spre deosebire de a apela o singură linie de cod în JSX. Dar dacă comparați codul folosind o bibliotecă precum jQuery sau React, vanilla JS poate fi destul de asemănător ca lungime. Uneori este mai lung, dar uneori este și mai scurt.

Nu este nevoie să reinventezi roata. Mantra profesorilor de informatică de pretutindeni. Și este adevărat – pur și simplu nu trebuie să însemne cadre în mod specific. Trimiterea unei cereri Ajax pentru a încărca sau a salva date este o cerință în aproape fiecare aplicație web, de exemplu, dar a nu avea un cadru nu înseamnă că trebuie să scrieți codul din nou de fiecare dată. Vă puteți crea propria bibliotecă sau bază de cod sau puteți extrage codul din alții. Cu cât este mai mic, cu atât este mai ușor de modificat sau ajustat după cum este necesar, așa că este util atunci când aveți nevoie de ceva specific pentru un proiect. Este mai ușor să modificați 100-200 de linii de cod decât să navigați prin muntele de fișiere pe care le-ar putea conține o bibliotecă sau un cadru terță parte.

Va funcționa doar pentru proiecte mici. Acesta este un mit foarte comun, dar deloc adevărat; în prezent, lucrez la un sistem întreg pentru a gestiona toate aspectele unei companii online într-un singur loc, inclusiv un modul care este ceva de genul Google Drive. Fie cu cadre sau fără ele, trec prin pași foarte asemănători și întâmpin probleme foarte asemănătoare. Diferența este neglijabilă. Cu toate acestea, fără cadre, întregul meu cod este mai mic și mai ușor de gestionat.

VREAU DOVAZA

Bine. Să nu mai vorbim despre teorie și să trecem la un exemplu din lumea reală. Acum câteva zile, trebuia să arăt o listă de mărci cu logo-uri pentru un magazin. Codul inițial folosea jQuery, dar a avut o problemă în care, la încărcarea în Mozilla, arăta o pictogramă de imagine ruptă pentru mărcile care nu aveau încă sigle încărcate. Nu putem avea magazinul să pară neterminat doar pentru că Compania X nu și-a încheiat încă sfârșitul lucrării, dar funcția trebuia să fie disponibilă.

Următorul cod folosește echivalentul jQuery al .innerHTML :

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

Fără a intra prea adânc în avantajele și dezavantajele jQuery, problema aici este că nu avem nicio referință la imaginile pe care le-am creat. Deși există soluții care nu implică schimbarea codului, să folosim această oportunitate pentru a vedea cum se poate face fără nicio bibliotecă:

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

Codul jQuery original avea șase rânduri, în timp ce soluția vanilla JS avea douăsprezece linii. Pentru a rezolva problema, ascunderea fiecărei imagini până când este încărcată, codificarea durează de două ori mai mult. Deci, să ne uităm la alternativa. Poate fi rezolvat și în jQuery? Verifică:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

Cu câteva linii suplimentare de cod, acum există doar o diferență de trei linii între jQuery și vanilla, dar pe jQuery, puteți vedea că linia img_out devine rapid foarte complexă, până la punctul în care trebuie să faceți pauză. și gândește-te bine la ceea ce faci. Codarea directă a DOM-ului prin utilizarea funcțiilor nodului pentru a adăuga atribute, funcții și altele asemenea ar putea fi mai lungă, dar fiecare linie are o semnificație mai clară și mai precisă, ceea ce face mai ușor de citit și de întreținut în viitor.

Să aruncăm o privire la React:

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

Această versiune este în mod clar sub-optimă. Codul nu este mai scurt decât este în vanilie și nici măcar nu am ajuns în punctul de a rezolva problema și de a ascunde legăturile până când imaginea din interiorul lor nu s-a încărcat.

Pentru fiecare exemplu, rezultatele vor fi diferite. Uneori, jQuery va fi mai scurt. Uneori, React va câștiga. Există momente când vanilla JS poate fi mai scurt decât ambele. În orice caz, scopul aici nu a fost de a demonstra că unul era în mod inerent superior celuilalt, ci de a demonstra că nu există o diferență semnificativă între utilizarea vanilla JS și utilizarea unui cadru când vine vorba de lungimea codului.

Concluzie

Ca în orice problemă din viața reală, nimic nu este alb sau negru. Codarea fără cadre de dezvoltare web ar putea fi cea mai bună soluție pentru unele dintre proiectele dvs. și un coșmar în altele. La fel ca în cazul oricărui instrument, cheia este în a învăța nu doar cum să-l folosești, ci când și care ar putea fi avantajele și dezavantajele utilizării acestuia. Codarea în JavaScript pur este la fel ca în orice cadru – stăpânirea ei necesită timp înainte să te simți confortabil să-l folosești.

Dar diferența cheie, cel puțin pentru mine, este că cadrele vin și pleacă și, chiar dacă un framework este popular pentru o lungă perioadă de timp, se poate schimba dramatic de la o versiune la alta. JavaScript pur va fi o opțiune pentru mult mai mult timp, până când nu va mai fi relevant și va apărea un alt limbaj. Chiar și atunci, vor exista mai multe concepte și strategii pe care le puteți migra direct dintr-o limbă în alta decât puteți cu un anumit cadru în altul. Timpul și efortul fiind aproximativ echivalente în ceea ce privește un singur proiect, reducerea deprecierii cunoștințelor și lecțiile pe care le puteți lua cu dvs. la următoarea provocare sunt factori foarte importanți de luat în considerare.