Cadre CSS sau grilă CSS: ce ar trebui să folosesc pentru proiectul meu?

Publicat: 2022-03-10
Rezumat rapid ↬ V-ați gândit vreodată dacă CSS Grid poate înlocui de fapt nevoia de cadre CSS sau biblioteci de componente terțe? Făcând acest lucru, Rachel Andrew a descoperit o serie de motive pentru care oamenii folosesc un cadru terță parte și lucrurile pozitive și negative despre acest lucru.

Printre întrebările care mi se pun cel mai frecvent se numără o varietate de întrebare, „Ar trebui să folosesc CSS Grid sau Bootstrap?” În acest articol, voi arunca o privire la această întrebare. Veți descoperi că motivele utilizării cadrelor sunt variate și nu se concentrează doar pe utilizarea sistemului de grile conținut în acel cadru. Sper că, dezvăluind aceste motive, vă pot ajuta să luați propria decizie, în ceea ce privește ceea ce este mai bine pentru site-urile și aplicațiile la care lucrați, precum și pentru echipa cu care lucrați.

În acest articol, când vorbesc despre un cadru , descriu un cadru CSS terță parte, cum ar fi Bootstrap sau Foundation. Ați putea argumenta că acestea sunt într-adevăr biblioteci componente, dar mulți oameni (inclusiv propriile documente) le-ar descrie ca un cadru, așa că acesta este ceea ce vom folosi aici. Factorul important este că acestea sunt ceva dezvoltat extern pentru tine, fără referire la problemele tale specifice. Alternativa la utilizarea unui cadru terță parte este să scrieți propriul dvs. CSS - care ar putea implica dezvoltarea propriului cadru intern, utilizarea unei grămadă de fișiere comune ca punct de plecare sau crearea fiecărui proiect ca un lucru nou. Toate aceste lucruri sunt făcute cu referire la propriile dvs. nevoi specifice, mai degrabă decât la cele foarte generice.

De ce să alegeți un cadru CSS?

Întrebarea dacă să folosiți Grid sau un cadru este greșită, deoarece CSS Grid nu este un înlocuitor pentru lucrurile pe care le face un cadru CSS. Orice explorare a subiectului trebuie să ia în considerare ce din cadrul nostru CSS Grid va înlocui. Am vrut să încep prin a afla de ce oamenii au ales să folosească un cadru CSS. Așa că am apelat la Twitter și am postat acest tweet.

Au fost o mulțime de răspunsuri. După cum mă așteptam, există mult mai multe motive pentru a utiliza un cadru decât pur și simplu sistemul de grilă pe care îl conține.

Mai multe după săritură! Continuați să citiți mai jos ↓

Un cadru oferă echipei dvs. documentație gata făcută

Dacă lucrați la un proiect cu un număr de alți dezvoltatori, atunci orice sistem intern pe care îl creați va trebui să includă și documentație pentru a ajuta membrii echipei să-l folosească eficient. Crearea de documentație utilă necesită timp, muncă calificată în sine și ceva pe care cadrele mari o fac foarte bine.

Captură de ecran a paginii de pornire a documentației Bootstrap
Documentația Bootstrap. (Previzualizare mare)

Documentația cadru a apărut din nou și din nou, cu mulți dezvoltatori front-end cu experiență care au intervenit și explicând de aceea ar recomanda și ar folosi un cadru CSS. Uneori aud părerea că oamenii folosesc framework-uri pentru că nu știu cu adevărat CSS, mulți dintre cei care răspund, totuși, îmi sunt bine cunoscuți ca dezvoltatori CSS experți. Sunt sigur că uneori sunt frustrați de alegerile făcute de cadru, totuși, aspectele pozitive ale acelei alegeri depășesc asta.

Comunități online: acces ușor la ajutor

Când decideți să utilizați un anumit instrument, obțineți și o comunitate de utilizatori care să ceară ajutor. Dacă nu aveți o problemă CSS foarte clară și puteți produce un caz de utilizare redus pentru a o demonstra, solicitarea ajutorului cu CSS poate fi dificilă. Este mai ales dacă doriți să întrebați cum să abordați construirea unei anumite componente. Utilizarea unui cadru vă poate oferi un punct de plecare pentru întrebarea dvs.; în general, vă veți întreba cum să modificați sau să stilați o anumită componentă, mai degrabă decât să începeți de la zero. Acesta este un lucru mai ușor de întrebat, precum și un lucru mai ușor de răspuns.

Sistemul Grid

În ciuda faptului că avem CSS Grid, mulți oameni au răspuns că principalul motiv pentru care au decis să folosească un cadru a fost pentru sistemul grid. Desigur, multe dintre aceste proiecte ar fi putut fi începute cu mult timp înainte ca CSS Grid să fie disponibil. Chiar și astăzi, totuși, preocupările legate de compatibilitatea anterioară sau de înțelegerea în echipă a metodelor mai noi de aspect ar putea determina oamenii să decidă să folosească un cadru în loc să adopte CSS nativ.

Viteza de livrare a proiectului

Optarea pentru un cadru va face, în general, mult mai rapidă livrarea proiectului dvs., în special dacă acel proiect se potrivește foarte bine cu modul în care cadrul face lucrurile și nu necesită multă personalizare.

În cazul dezvoltării unui MVP pentru o idee nouă, un cadru poate fi o alegere excelentă. Veți avea multe lucruri pentru care să petreceți timp și veți încă testa ipoteze în ceea ce privește ceea ce are nevoie proiectul. A fi capabil să dezvolti acea primă versiune folosind un cadru vă poate ajuta să puneți produsul în fața utilizatorilor mai rapid și să economisiți mult timp în timpul dezvoltării lucrurilor pe care apoi decideți să nu le utilizați.

Un alt loc în care viteza și o grămadă de componente gata construite pot fi foarte utile este atunci când se dezvoltă sistemul de administrare backend pentru un site sau aplicație. În cazul în care pur și simplu trebuie să creați câteva ecrane de administrare, un cadru poate economisi mult timp pentru stilarea câmpurilor de formular și a altor componente! Există chiar și teme de tablou de bord pentru Bootstrap și Foundation care pot oferi un punct de plecare util.

Captură de ecran a unui kit de tablou de bord pentru Foundation
Colecțiile de componente ale tabloului de bord fac mai rapidă construirea administratorului pentru o aplicație. (Previzualizare mare)

Nu sunt un designer!

Acest punct este motivul pentru care am optat pentru un cadru CSS în trecut. Nu sunt designer și dacă trebuie să proiectez și să construiesc ceva, voi petrece mult timp încercând să iau decizii de design pe care nu sunt în totalitate calificat să le iau. Ar fi minunat să ai fondurile necesare pentru a angaja un designer pentru fiecare proiect secundar, totuși, nu am, așa că un cadru ar putea însemna diferența între a livra lucrul și nu.

Tratarea erorilor CSS și a problemelor de compatibilitate cu browserul

Menționat mai puțin decât am crezut că ar putea fi a fost faptul că autorii cadrului s-ar fi ocupat deja de problemele de browser, fie că se datorează erorilor reale sau lipsei suportului pentru anumite funcții. Cu toate acestea, acesta a fost încă un factor în luarea deciziilor pentru mulți oameni.

Pentru a ajuta la proiectarea receptivă

Acest lucru a apărut de câteva ori; oamenii optau pentru un cadru special datorită faptului că era receptiv sau că am luat decizii cu privire la punctele de întrerupere pentru ei. Mi s-a părut interesant că acesta a fost ceva numit în mod special ca un factor în alegerea utilizării unui cadru.

De ce să nu folosiți un cadru?

Printre motivele pozitive pentru care cadrele au fost selectate au fost unele dintre problemele pe care oamenii le-au avut cu această alegere.

Dificultatea de a suprascrie codul cadru

Mulți oameni au comentat faptul că ar putea deveni dificil să suprascrieți codul folosit în cadru și că cadrele erau o alegere bună dacă nu aveau nevoie de multe suprascrieri. Beneficiile ușurinței în utilizare și toată lumea din echipă care înțelege cum să folosească cadrul se pot pierde dacă există apoi un număr mare de personalizări.

Toate site-urile web ajung să arate la fel

Vina pentru toate site-urile web care încep să arate la fel a fost plasată direct la ușa binecunoscutelor cadre CSS. Am văzut site-uri în care sunt sigur că a fost folosit un anumit cadru, apoi am descoperit că sunt CSS personalizate, așa că predominante sunt alegerile de design făcute în aceste cadre.

Dificultatea de a suprascrie stilurile de cadru deja menționate este o mare parte din motivul pentru care site-urile dezvoltate folosind un anumit cadru vor avea tendința de a arăta similar. Aceasta nu este doar o problemă de creație, ci poate fi foarte ciudată ca un utilizator al câtorva site-uri web care au optat toate pentru același cadru să simtă că toate sunt același lucru. În ceea ce privește transmiterea mărcii dvs. și integrarea unei experiențe bune pentru utilizator, poate pierdeți ceva când optați pentru opțiunile generice ale unui cadru.

Moștenirea problemelor CSS ale întregii lumi

Indiferent dacă este front sau back-end, orice instrument sau cadru care încearcă să lovească mainstream-ul trebuie să rezolve cât mai multe probleme posibil. Dacă instrumentul nu este strâns cuplat cu rezolvarea unui anumit caz de utilizare, acesta va conține o mulțime de cod foarte generic și cod care rezolvă probleme pe care nu le aveți și nu le veți avea niciodată.

Este posibil să vă aflați în poziția fericită de a avea nevoie doar de experiența dvs. completă pentru a fi vizualizată în cele mai recente browsere, permițând o experiență mai limitată în Internet Explorer sau versiuni mai vechi de Chrome. Utilizarea unui cadru cu o mulțime de suport încorporat care revine la IE9 ar avea ca rezultat o mulțime de cod suplimentar - mai ales având în vedere îmbunătățirile recente ale aspectului CSS. De asemenea, s-ar putea să vă împiedice să fiți creativ, deoarece totul în cadru își asumă această cerință de sprijin. Lucrurile care sunt posibile folosind CSS pot fi limitate de cadru.

De exemplu, sistemele de grilă din cadrele populare nu au capacitatea de a se întinde pe rânduri, deoarece nu există niciun concept sau rânduri în sistemele de aspect înainte de Grid Layout. CSS Grid Layout permite cu ușurință acest lucru. Dacă sunteți legat de Bootstrap Grid și designerul dvs. vine cu un design care include elemente care se întind pe rânduri, nu puteți să-l implementați - în ciuda faptului că Grid ar putea fi acceptat de browserele dvs. țintă.

Probleme de performanta

Legate de cele de mai sus sunt probleme de performanță inerente utilizării unui cod destul de generic, mai degrabă decât ceva optimizat pentru cazurile de utilizare exacte pe care le aveți. Când încerci să îmbunătățești performanța, te vei lovi de deciziile cadrului.

Creșterea datoriei tehnice

Deși un cadru ar putea fi o modalitate excelentă de a-ți demara rapid startup-ul, iar în momentul luării acestei decizii, ești sigur că îl vei înlocui, există un plan pentru a face acest lucru?

Învățarea unui cadru, mai degrabă decât învățarea CSS

Când vorbesc cu participanții la conferințe și ateliere, am descoperit că mulți oameni au folosit doar un cadru pentru a scrie CSS. Nu este nimic greșit în a intra în dezvoltarea web prin intermediul unuia dintre aceste instrumente, având în vedere complexitatea platformei web de astăzi, îmi imaginez că va fi calea pentru mulți oameni. Cu toate acestea, poate deveni o alegere care limitează cariera, mai ales dacă cadrul pe care ți-ai bazat abilitățile nu este favorabil.

Având dezvoltatori front-end fără cunoștințe CSS ar trebui să îngrijoreze o companie. Este incredibil de greu să te îndepărtezi de acel cadru dacă echipa ta nu înțelege de fapt cum să faci CSS fără el. Deși acesta nu este cu adevărat un motiv pentru a nu folosi un cadru, este ceva de avut în vedere atunci când utilizați unul. Când va veni ziua plecării, ai spera că echipa va fi pregătită să facă ceva nou, fără a fi nevoie să-și amintească (sau să învețe pentru prima dată) cum să scrie CSS!

Alegerea nu ia în considerare utilizatorii finali

Nicole Sullivan a pus cam aceeași întrebare cu câteva zile înainte de întrebarea mea, când mă gândeam să scriu acest articol, deși ea a luat în considerare cadrele front-end ca un întreg, mai degrabă decât cadrele CSS. Jeremy Keith a remarcat că exact zero dintre răspunsuri au vizat utilizatorii finali. Acesta a fost și cazul răspunsurilor la întrebarea mea.

În cursa noastră de a construi rapid site-ul nostru, în dorința noastră de a face lucrurile cât mai bune posibil pentru noi înșine, ca designeri și dezvoltatori ai site-ului, uităm pentru cine facem asta? Deciziile luate de dezvoltatorul framework-ului se potrivesc cu nevoile utilizatorilor site-ului pe care îl construiți?

Putem înlocui cadrele cu CSS „Vanilla”?

Dacă vă gândiți să vă înlocuiți cadrul sau să începeți un nou proiect fără unul, care sunt câteva dintre lucrurile pe care le-ați putea lua în considerare pentru a facilita acest proces?

Înțelegeți de ce părți ale cadrului aveți nevoie

Dacă înlocuiți utilizarea unui cadru cu propriul dvs. CSS, un bun loc de început ar fi să auditați utilizarea cadrului actual. Află ce folosești și de ce. Luați în considerare cum veți înlocui aceste lucruri în noul design.

Ai putea urma un proces similar atunci când te gândești dacă să selectezi un cadru sau să-l scrii pe al tău. De ce părți din asta vă puteți aștepta în mod rezonabil să aveți nevoie? Cât de bine se potrivește cerințelor dumneavoastră? Va exista o mulțime de coduri pe care le importați, pe care să le cereți vizitatorilor să îl descarce, dar de care nu le folosiți niciodată?

Creați o bibliotecă de modele documentată sau un ghid de stil

Sunt un mare fan al lucrului cu biblioteci de modele și puteți citi postarea mea aici pe Smashing Magazine despre utilizarea Fractal. O bibliotecă de modele sau un ghid de stil permite crearea de documentație împreună cu toate componentele dvs. Încep toate proiectele mele lucrând la CSS în biblioteca de modele.

Încă va trebui să scrieți documentația, ca cineva care scrie documentație, cu toate acestea, știu că de multe ori cel mai greu este să știți de unde să începeți și cum să structurați documentele. O bibliotecă de modele ajută la acest lucru, păstrând documentele împreună cu CSS-ul pentru componenta în sine. Această abordare poate ajuta, de asemenea, la prevenirea ca documentele să devină învechite, deoarece sunt strâns legate de componenta la care se referă.

Dezvoltați-vă propriile linii directoare pentru codul CSS

Consecvența în cadrul echipei este incredibil de utilă și, fără un cadru, este posibil să nu existe nimic care să dicteze asta. Cu metodele de amenajare mai noi, în special, există adesea mai multe moduri în care un model ar putea fi construit, dacă toată lumea alege unul diferit, este probabil să apară inconsecvențe.

Locuri mai bune pentru a cere ajutor

În afară de trimiterea oamenilor în direcția Stack Overflow, se pare că există foarte puține locuri în care să ceri ajutor pentru CSS. În special, par să existe puține locuri care sunt accesibile pentru începători. Dacă vrem să încurajăm oamenii să se îndepărteze de instrumentele terțe, atunci trebuie să răspundem nevoii de sprijin prietenos și util, care vine de la comunitățile din jurul acelor instrumente.

În cadrul unei companii, este posibil ca dezvoltatorii mai experimentați să devină suportul CSS pentru membrii echipei mai noi. Dacă treceți de la un cadru la propria soluție, ar fi înțelept să luați în considerare ce formare ar putea fi necesară pentru a ajuta la reducerea decalajului, mai ales dacă oamenii sunt obișnuiți să folosească ajutorul oferit în jurul instrumentului terță parte atunci când au avut nevoie de ajutor în trecut .

Ghiduri de stil sau puncte de plecare pentru non-designeri

Mă leg în noduri cu întrebări precum: „Ce fonturi ar trebui să folosesc?”, „Cât de mari ar trebui să fie titlurile în relație cu corpul textului?”, „Este în regulă să folosești o umbră?” Pot scrie cu ușurință CSS - dacă știu ce încerc să fac! Ceea ce îmi trebuie cu adevărat sunt niște reguli pentru realizarea unui design deloc groaznic, un fel de punct de plecare tipografie sau un set de linii directoare de bază care ar înlocui posibilitatea de a utiliza valorile implicite ale unui cadru în multe cazuri.

Educarea oamenilor despre starea interoperabilității browserelor moderne

Am descoperit că oamenii care au fost cufundați în dezvoltarea bazată pe cadru de câțiva ani au adesea o viziune a interoperabilității browserului care este depășită de câțiva ani. Nu am fost niciodată într-o situație mai bună în ceea ce privește funcționarea CSS între browsere. Este posibil ca unele browsere să nu accepte un nou bit strălucitor de CSS, dar, în general, CSS (atunci când este acceptat) nu va fi plin de erori ciudate. De exemplu, în aproape toate cazurile, dacă utilizați Grila CSS într-un browser, CSS-ul dvs. va funcționa exact în același mod în altul.

Dacă încercați să argumentați pentru a nu folosi un cadru pentru membrii echipei care cred că cadrul îi salvează de erorile browserului, acest punct poate fi util de ridicat. Problemele de compatibilitate cu browser-ul sunt reale sau se bazează pe preocupările din trecut?

Vom vedea o nouă generație de cadre?

Ceva care mă interesează este dacă noile noastre metode de layout vor ajuta la introducerea unei noi tipuri de instrumente și cadre. Vom vedea instrumente care profită de noile metode de layout, permit mai multă creativitate, dar oferă totuși echipelor și indivizilor unele dintre avantajele incontestabile care au rezultat din răspunsurile la tweetul meu.

Poate că bazându-se pe noi metode de layout, mai degrabă decât pe un sistem de grilă încorporat, un cadru cu stil nou ar putea fi mult mai ușor, devenind o colecție de componente utile. Ar putea fi apoi capabil să scape de unele dintre problemele de performanță inerente codului foarte generic.

Un domeniu cu care ar putea ajuta un cadru ar fi acela de a ajuta la crearea unor soluții de rezervă solide pentru browsere care nu acceptă metode de layout mai noi sau prin faptul că au o accesibilitate cu adevărat solidă încorporată în componente. Acest lucru ar putea ajuta la furnizarea de îndrumare într-un mod de lucru care ia în considerare interoperabilitatea și accesibilitatea, chiar și pentru acei oameni care nu au aceste lucruri în prim plan.

Nu cred că simpla comutare a Bootstrap Grid pentru CSS Grid Layout va realiza acest lucru. În schimb, autorii care vin cu noi cadre, ar trebui probabil să se uite la unele dintre motivele prezentate aici și să încerce să le rezolve în moduri noi, folosind noua funcționalitate pe care o avem în CSS pentru a face asta.

Ar trebui să utilizați un cadru?

Tu și echipa ta va trebui să răspundeți singuri la această întrebare. Și, în ciuda a ceea ce oamenii ar putea încerca să te facă să crezi, nu există un răspuns universal corect sau greșit. Există doar ceea ce este corect sau greșit pentru proiectul tău. Sper că acest articol și numeroasele răspunsuri la întrebarea mea inițială vă pot oferi câteva lucruri de discutat în timp ce vă gândiți la această întrebare.

Amintiți-vă că răspunsul se va schimba în timp. Ar putea fi un experiment de gândire util să luați în considerare nu numai ceea ce aveți nevoie acum, în ceea ce privește realizarea inițială a dezvoltării site-ului, ci și durata de viață a site-ului. Te aștepți ca asta să fie în continuare peste cinci ani? Atunci alegerea ta va fi una pozitivă sau negativă?

Documentați-vă deciziile, nu vă fie teamă să le revizuiți și asigurați-vă că dvs. și echipa dvs. vă mențineți abilitățile în afara oricărui cadru pe care decideți să îl utilizați. Astfel, vei fi într-un loc bun pentru a merge mai departe și pentru a lua cele mai bune decizii pentru următoarele faze ale proiectului tău.

Mi-ar plăcea ca conversația începută în acel tweet să continue. Spune-ne poveștile tale în comentarii - ar putea ajuta alți oameni care încearcă să descopere ce este mai bine pentru proiectele lor chiar acum.