Cum să alegeți cel mai bun cadru front-end

Publicat: 2022-03-11

Lumea JavaScript este un mediu bogat cu zeci de instrumente, biblioteci și cadre. Dar, cu o mulțime de opțiuni vine o mulțime de confuzie. Este într-adevăr o sabie cu două tăișuri.

Deși aveți mult spațiu pentru creativitate și experimentare, uneori nu sunteți sigur ce bibliotecă sau cadru să alegeți.

Cadrul front-end pe care îl alegeți vă poate realiza sau distruge proiectul pe termen lung.

În acest articol, ne vom uita la unele dintre cele mai populare cadre JavaScript și la modul în care se comportă unul împotriva celuilalt. Vom examina cinci perspective diferite ale acestor cadre, care, în general, ușurează procesul de luare a unei decizii cu privire la următorul cadru JavaScript.

Fie că alegi dintr-unul dintre aceste cadre JavaScript populare sau din ceva mai ezoteric, ar trebui să iei în considerare fiecare dintre aceste aspecte.

Disponibilitatea resurselor de învățare

Acesta este evident, dar de multe ori trecut cu vederea. În timp ce pagina de pornire elegantă a unui cadru îți poate atrage atenția, mai ai nevoie de câteva cursuri, cărți, tutoriale și articole suplimentare, pe lângă documentație plictisitoare și uscată, pentru a te ajuta să începi.

Crearea unui cadru minunat este un lucru, iar comunicarea ideilor de bază din spatele lui este diferită. De fapt, există mulți dezvoltatori profesioniști care se specializează în coaching. O resursă de învățare bine concepută vă va reduce dramatic curba de învățare.

Căutați resurse de la autori de încredere cu care aveți experiență anterioară - va merita timpul dvs. în cele din urmă. Dacă te străduiești să găsești ceva util, fii precaut: cadrul pe care încerci să-l înveți ar putea fi nou sau nu este încă bine adoptat de comunitate.

Deși am menționat că doar documentarea nu este suficientă, există și excepții de la aceasta. EmberJS, de exemplu, are o documentație excelentă. Caracteristicile de bază și cazurile de utilizare sunt descrise frumos cu exemple generice ici și colo. Din păcate, pe lângă documentație, ne-au rămas puține cărți de resurse, cursuri video sau alte materiale.

Pe de altă parte, există o abundență de resurse pentru Angular și React. Aproape orice site educațional orientat spre front-end va avea un articol sau două despre ele, poate chiar un curs video complet sau o carte.

Vue ajunge într-un fel la mijlocul: are o documentație bună și există câteva cursuri frumoase din care puteți alege.

Aurelia, de exemplu, are aproape zero resurse; singura speranță pentru tine este documentarea și norocul.

Prefer să am alegeri.

Chiar dacă citești o carte sau un curs grozav, există șansa să înveți ceva nou expunându-te la diferite resurse. Dacă ești familiarizat cu subiectul, de multe ori poți să răsfoiești și să cauți posibile zone care nu sunt încă destul de clare.

Din păcate, această strategie nu va funcționa dacă ești limitat cu opțiunile tale, ceea ce ne conduce la următorul punct.

Popularitate

S-ar putea să fii mândru să înveți ceva exotic, dar dacă te uiți la asta dintr-o perspectivă de afaceri, nu este același lucru. Compania sau clientul dvs. probabil preferă să fie folosit un set de instrumente testat în luptă.

Există mai multe motive pentru aceasta. Dacă un cadru nu este atât de popular, înseamnă că există câțiva dezvoltatori specializați în el. Ce se întâmplă dacă abandonezi proiectul sau găsești un nou loc de muncă? Angajatorul tău ajunge să fie blocat în căutarea unui dezvoltator care cunoaște cadrul pe care l-ai folosit.

Acest proces poate deveni o adevărată povară pentru o companie. Același lucru este valabil chiar dacă rămâi cu proiectul și acesta crește. Acum angajatorul are nevoie de mai mulți dezvoltatori pentru a accelera dezvoltarea.

Există și alte motive personale pentru care ați putea opta pentru un cadru popular, utilizat pe scară largă. Ce se întâmplă dacă te simți blocat cu o problemă și nu există cu adevărat o comunitate la care poți cere ajutor? Deoarece sunteți singur cu documentația, sunt șanse să pierdeți mult timp.

Pe lângă asta, vrei să te gândești la oportunități viitoare și mai atractive în cariera ta. Dacă te-ai specializat în ceva popular și te pricepi cu adevărat la asta, vor exista o mulțime de proiecte pentru tine.

Liderii evidenti aici sunt Angular și React.

Majoritatea listelor de locuri de muncă legate de front-end de acolo necesită una sau alta. Sunt susținute de Google și, respectiv, de Facebook și, prin urmare, angajatorii se simt „în siguranță” în alegerea lor.

Uneori, alegerea cadrului pentru compania sau clientul dvs. nu depinde de dvs.; poate a fost făcut de un angajat anterior sau de o altă persoană din echipă. Sunt șanse să fie Angular sau React. Acum există și alte opțiuni, cum ar fi Ember și Vue. Dar, trebuie să cauți în mod deliberat companii care le folosesc.

Puteți determina popularitatea unui cadru analizând rapid cât de bine se descurcă proiectul pe GitHub și în alte locuri. Iată câteva statistici colectate la scrierea acestui articol:

unghiular 2 Reacţiona Ember Vue
Stele pe GitHub 26.924 73.530 18.154 63.438
Colaboratori pe GitHub 495 1044 679 122
Întrebări etichetate pe StackOverflow 66.152 54.158 21.651 8.598

Deși aceste biblioteci există suficient de mult pentru a se dovedi a fi opțiuni populare, dacă încercați ceva cu adevărat nou, statistici similare pentru ele vă pot ajuta să faceți alegerea.

Învățând doar Angular sau React te va duce doar atât de departe în carieră. Desigur, veți avea o mulțime de oportunități, dar există un motiv pentru care există și alte cadre. Încercați să aflați despre ele în timpul liber și, din când în când, faceți câteva experimente. Chiar dacă nu le folosiți niciodată în proiecte reale, veți obține informații valoroase care vă vor ajuta în activitatea de dezvoltare de zi cu zi.

Caracteristici principale

Să fim puțin tehnic acum.

La început, doriți să prezentați pe scurt caracteristicile de bază ale cadrului pentru a avea o așteptare adecvată când veți începe să codificați. În acest scop, scanați documentația. Trebuie să înțelegeți despre ce este acest cadru în general. Este doar un strat de vizualizare, cu drepturi depline sau ceva între ele?

Compararea abstractă a cadrelor front-end.

Dacă aveți o experiență anterioară bogată cu alte cadre, acest proces este ușor și rapid. Căutați următoarele subiecte în documentație: șabloane, managementul stării, comunicarea HTTP, procesarea și validarea formularelor și rutare. Acestea sunt lucruri de zi cu zi pe care le faci ca dezvoltator. Nu toate acestea pot fi prezentate în cadrul de bază sau ar putea exista o abordare diferită a unei anumite probleme.

Să atingem pe scurt opțiunile populare.

Vom începe cu React și Vue. Nu sunt cu adevărat cadre; ele reprezintă doar stratul de vizualizare al aplicației dvs. Înseamnă că toate celelalte părți — comunicarea HTTP, validarea formularelor etc. — sunt la latitudinea dvs.

După cum am menționat mai devreme, ar putea fi o sabie cu două tăișuri. În cele din urmă, veți ajunge să vă construiți propriul cadru personalizat. Ambele au ecosistemul lor de biblioteci pentru a oferi soluții pentru cele mai comune probleme, dar structura generală va varia de la proiect la proiect.

JSX-ul lui React m-a făcut mereu să mă încremenesc. A trebuit să mă obișnuiesc. Cu toate acestea, șablonul Vue este foarte frumos, mai ales dacă veniți de la Angular.

Pe de altă parte, Ember are aproape totul. În mod surprinzător, nucleul lui Ember nu oferă procesare avansată a formularelor. Are doar niște ajutoare de intrare și atât. Este foarte obișnuit și chiar are propriul strat de date. Totul trebuie făcut „pe calea Ember”.

Dacă aveți un fundal în alte cadre sau JavaScript în general, s-ar putea să fiți frustrat deoarece Ember folosește propriul său model de obiect. Clasele standard ES2015 nu sunt utilizate pe scară largă, după cum arată documentația lor. S-ar putea să te trezești că atribui valoarea direct unei proprietăți și Ember se plânge de asta.

Un alt lucru semnificativ diferit de alte cadre este Ember Data. Este un strat de date pentru aplicațiile Ember. Vă puteți gândi la asta ca la un fel de ORM pentru front-end. Creați modele și mapați relațiile dintre ele.

Acum, dacă serverul tău folosește API-ul JSON (este o specificație pentru implementarea API-urilor JSON), ești într-un loc bun cu Ember, dar, din păcate, majoritatea serverelor nu o fac. Deci trebuie să scrieți adaptoare și serializatoare personalizate. Cu toate acestea, dacă faci lucrurile în felul Ember, ar putea fi cu adevărat productiv. Are doar o curbă de învățare abruptă.

Angular 2 este un cadru bogat în caracteristici. Se livrează cu o mulțime de module precum Ember, așa că aveți la dispoziție o mulțime de instrumente din cutie. Cu toate acestea, deoarece Angular este destinat aplicațiilor mari, promovează TypeScript, care ar putea declanșa o oarecare rezistență înainte de a-l încerca.

Un alt lucru notabil este utilizarea intensă a observabilelor din biblioteca Rx, ceea ce este foarte frumos. Puteți reprezenta aproape orice ca un observabil și puteți aplica operațiuni de nivel înalt precum hartă, filtru etc. Dacă ați folosit Lodash sau Underscore, Rx este cam același, dar pe steroizi.

Iată un rezumat al caracteristicilor de bază ale celor patru cadre pe care le discutăm în acest articol:

unghiular 2 Reacţiona Ember Vue
Vizualizare/Sablonare
Router
Prelucrarea formularelor
Validarea formularului
Comunicare HTTP

Toate aceste caracteristici pe care le-am prezentat pe scurt sunt inutile dacă trebuie să ardeți lumânarea la ambele capete pentru a le folosi eficient - care este următorul punct.

Utilizabilitate

Dacă în acest moment încă mai aveți entuziasm pentru cadrul ales, următorul pas este să vă murdăriți mâinile.

Poate că cadrul se potrivește bine pentru tine din cauza antecedentelor tale. Poate că este puțin diferit și te provoacă în anumite privințe. Încă nu știți și nicio cantitate de citire sau vizionare a tutorialelor nu vă va ajuta până nu încercați singur.

Cel mai bun mod de a vă simți despre un cadru este să îl utilizați într-un mini-proiect. Acest lucru vă oferă posibilitatea de a rezolva problemele de zi cu zi menționate mai sus cu un cadru dat.

În timp ce lucrați la un proiect, luați-vă timp și reflectați dacă sunteți sau nu productiv. Cât de ușor este să obții rezultatul dorit? Trebuie să cauți biblioteci externe? Poate ai nevoie de niște pluginuri din comunitate. Există vreo structură convențională sau linii directoare în contextul cadrului? Poate că există un CLI pentru a accelera procesul de dezvoltare. La acest pas, acumulați experiență de bază, astfel încât să vă puteți gândi cum ar fi dacă utilizați acest cadru pentru proiectele viitoare sau chiar treceți la cele existente.

Ember este considerat a fi un cadru foarte productiv, cel puțin pentru utilizatorii săi de bază. Vine cu un CLI, care chiar ajută. Puteți genera rute, controlere, componente și modele cu propriile suite de testare. A face toate acestea manual este o sarcină plictisitoare. Generarea unui nou proiect este, de asemenea, posibilă. Acesta va crea structura de bază a folderelor, va instala pachetele necesare, va construi instrumente, va testa mediul etc. Dacă nu ați folosit niciodată un CLI într-o asemenea măsură, veți fi foarte mulțumit. Dar, așa cum am menționat mai devreme, Ember este foarte obișnuit; în ciuda tuturor acestor bunătăți, s-ar putea să te simți frustrat în timp ce încerci să îndeplinești sarcini comune.

Acum, pentru React și Vue, au un fel de CLI, create-react-app și vue-cli. Dar pe lângă generarea unui proiect inițial cu unele opțiuni, acestea nu oferă atât de mult în comparație cu Ember sau Angular. Este de înțeles deoarece ambele reprezintă un strat de vizualizare. Dacă vă plac fluxurile de lucru personalizate, experimentarea sau diferitele structuri de la un proiect la altul, atunci vă aflați într-un loc bun. Pentru unii dezvoltatori, flexibilitatea este cheia care vine în mod inerent cu utilizarea React sau Vue.

Angular 4 vine cu un CLI precum Ember. Puteți genera componente, directive, servicii etc. De asemenea, generează structura inițială pentru o aplicație, așa că trebuie să vă faceți griji doar pentru produs. Mediul de testare este foarte frumos, deoarece, cu fiecare bucată de aplicație generată, suita de testare se află aproape de ea (la propriu). Pe lângă asta, TypeScript ar putea oferi o creștere reală a productivității. Iata de ce:

De câte ori ați întâlnit codul cu linii ca aceasta...

 function doSomething(someData) { // do something }

… și m-am întrebat ce naiba este someData , ce proprietăți ar trebui să aibă, ce funcții ar trebui să ofere și care este comportamentul lor? Cu TypeScript, definiți tipul și așteptați datele corespunzătoare. Se poate merge mai departe dacă utilizați un IDE cu suport TypeScript. Puteți explora diferite părți ale aplicației într-o briză.

Nu ne-am referit la IDE-uri, dar, pentru majoritatea cadrelor populare, există câteva plugin-uri, care fac dezvoltarea cu adevărat ușoară. WebStorm, de exemplu, este livrat cu suport încorporat pentru Angular, React și Vue.

Ușurință de integrare (cu alte biblioteci)

Nu în ultimul rând, acest lucru ar putea fi considerat ca parte a gradului de utilizare, dar este atât de important încât merită propria sa secțiune.

Indiferent cât de bogat în funcții este cadrul selectat, sunt șanse să vă confruntați cu probleme în care sunt necesare instrumente suplimentare. Există biblioteci grozave care se concentrează pe o singură problemă, fie că este vorba despre manipularea DOM, procesarea datelor, formatarea timpului, editarea textului îmbogățit etc. Dacă încercați să integrați una dintre acestea și să petreceți ore întregi pe ea de fiecare dată, poate că aceasta nu este alegerea optimă. .

Testarea acestui lucru este foarte ușoară. Puteți veni rapid cu un scenariu imaginar în care aveți nevoie de o anumită bibliotecă. Uită-te la proiectele tale anterioare; ce instrumente ați folosit și în ce scenarii? Sunt șanse să te confrunți din nou cu aceleași situații și să vrei să fii pregătit pentru asta, sau cel puțin să ai o așteptare.

Nu toate bibliotecile de acolo acceptă TypeScript. Deoarece Angular îl folosește intens, o parte din bunătatea TypeScript ar putea dispărea în timpul utilizării unei astfel de biblioteci. Desigur, puteți găsi o soluție de soluție, dar este puțin mai mult o bătaie de cap. Datorită popularității Angular, este posibil să integrați instrucțiuni pe pagina bibliotecii în sine.

Pentru Vue și React, ești responsabil pentru aproape tot, iar utilizarea altor biblioteci nu este o excepție. Dacă utilizați Webpack sau un instrument de compilare similar, vă puteți referi direct la bibliotecile instalate folosind NPM. Am considerat că este o mică bătaie de cap pentru Vue să folosească pluginuri comunitare, mai ales când acestea conțin și logica interfeței cu utilizatorul.

Ember are EmberObserver, care este un site web de pluginuri comunitare. Fiecare dintre ele are un scor pe o scară de la zero la zece. Este un loc grozav pentru a căuta ceva de care ai nevoie. Dacă introduceți numele bibliotecilor dvs. preferate, cum ar fi Lodash, Rx sau Ramda, veți găsi pluginurile aferente din pachetele simple pentru a finaliza rescrierile. Desigur, există depozite Awesome React și Awesome Vue care adună resurse conexe, inclusiv biblioteci, dar mi s-a părut că EmberObserver este deosebit de util.

Angajarea la un cadru JavaScript

Alegerea cadrului JavaScript potrivit este unul dintre cei mai importanți pași pentru a face proiectul dvs. web un succes. Indiferent dacă lucrați la un proiect mic sau mare, fie că lucrați singur sau în echipă, fiecare dintre aceste detalii joacă un rol crucial în a determina care cadru este cel mai bun pentru proiectul dvs. (și mai puțin cadru pe care îl preferați ).

În ceea ce privește caracteristicile de bază și gradul de utilizare, am enumerat punctele care vor afecta productivitatea dezvoltatorilor în diferite grade. Utilizabilitatea este deosebit de dificilă, deoarece depinde în mare măsură de experiența și experiența dvs., precum și de compania sau organizația în care lucrați.

De-a lungul timpului, cadrele pe care le-am discutat în acest articol pot evolua, popularitățile lor se pot schimba și proiectele pentru care sunt potrivite se pot schimba, dar acest articol ar trebui să vă ofere o idee generală despre unde fiecare dintre aceste cadre poate funcționa cel mai bine.

Legate de:

  • Ce cadre JS vor declanșa o revoluție front-end în 2020?
  • Dezgroparea ClojureScript pentru dezvoltarea front-end