The Vanilla Web Diet - Smashing Magazine

Buletin informativ Smashing

În fiecare săptămână, trimitem tehnici utile front-end și UX. Abonați-vă și obțineți Liste de verificare pentru designul interfeței inteligente PDF livrat în căsuța de e-mail.

Nota editorului: Acesta este un articol introductiv despre un idee de carte care urmează să fie publicat de Smashing Magazine împreună cu Chris Heilmann. Verificați ce propunem ca idee - explicând o modalitate de a reconsidera modul în care creăm site-uri web pentru a ne asigura că acestea sunt mai slabe și mai rezistente la viitor. La sfârșitul articolului, vă vom cere să completați un sondaj rapid pentru a vă arăta interesul.

Web-ul, deoarece suferă acum de o problemă de obezitate. Dacă navigați pe web pe o conexiune mobilă fulgurantă sau pe o rețea fără fir de hotel, vă veți găsi de multe ori cu ochii pe o pagină sau o aplicație care nu face nimic și nu vă spune nici ce se întâmplă. Rotitorul din filă sau bara URL pare să fie cel mai mare kilometraj în browsere. Navigarea cu o filă netă deschisă în instrumentele de dezvoltator vă arată o cantitate incredibilă de date trimise pentru produse finale aparent foarte simple.

De ce este asta? Nu ar fi trebuit ca anii de dezvoltare web și de susținere a performanțelor de către Yahoo și Google și mulți alții să dea roade și să ne conștientizeze cât costă fiecare cerere HTTP? Dacă te uiți la produsele finale, nu pare așa.

Motive pentru o rețea obeză

Există câteva motive pentru care Web-ul nostru este pe partea dolofană, iar majoritatea dintre ele sunt de fapt posibile pentru noi ca dezvoltatori să le schimbăm.

Nu ne dezvoltăm în medii realiste

Probabil că principalul motiv este că, în calitate de dezvoltatori, lucrăm pe computere rapide și mari conectate la o linie grasă și prima dată când cineva testează produsele noastre pe conexiuni lente este în timpul asigurării calității (QA). Și întrucât QA este primul lucru care trebuie abandonat atunci când termenele limită nu sunt respectate, uneori acest lucru nu se întâmplă deloc.

Agățându-ne de trecut

Un alt motiv pentru mâncarea dragostei de pe produsele noastre web este un fals sentiment de loialitate față de tehnologia învechită și veche, și anume browserele din anii '90 care refuză să dispară. Există multe încercări de soluții la problema mediilor vechi, fiecare dintre ele având propriile sale probleme. Faptul este că există o mulțime de utilizatori finali pe computere teribil de învechite, cu - în viziunea noastră - browsere proaste și, probabil, conexiuni limitate. Acești utilizatori nu ar trebui să fie blocați, dar nu ar trebui să dicteze ceea ce construim.

Diferențe de browser

Un alt motiv important este supărarea diferențelor de browser. Nu există multe tehnologii web și API-uri în care toate browserele sunt de acord atunci când vine vorba de sprijinirea acestora și de multe ori trebuie să repetăm codul și furculița și să testăm pentru a le oferi tuturor aceleași funcționalități.

Îmbrățișând haosul și sărbătorind diferențele

Ultimul punct este principala greșeală pe care o facem: în loc să îmbrățișăm haosul care este webul și mediile și abilitățile utilizatorilor noștri finali, nu pare să putem renunța la visul de a avea un produs care să funcționeze și să arate exact la fel peste tot.

Browserul meu nu este lumea?

În cel mai rău caz, încercăm să realizăm acest lucru blocând toate browserele care nu ne plac și proclamând cu mândrie că „toată lumea folosește browserul X și oricine nu este un dușman al web-ului modern”. Bineînțeles, acest lucru ne minte pe noi înșine și se bazează pe conceptul trecător al unei „rețele moderne”. Multe dintre cele mai groaznice produse web bazate pe web au fost construite cu ani în urmă pentru a funcționa numai în Internet Explorer (IE) 6, care era genunchiul albinei în acel moment. Nu contează ce hardware interesant are un browser cablat, care este foarte activ acum - facem din nou aceeași greșeală dacă construim doar un browser și blocăm altele.

Blocarea oricărui browser înseamnă de fapt scrierea mai multor coduri pentru testarea browserelor și este aproape imposibil să detectăm în mod fiabil ce browser este utilizat. Dacă doriți dovezi, aruncați o privire rapidă asupra șirului de agent utilizator al browserului Yandex, care conține numele a aproape fiecare motor de browser de acolo:

_Mozilla/5.0 (Macintosh; Intel Mac OS X 10_82) AppleWebKit/536.5 (KHTML, cum ar fi Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5402 Safari/536.5

Sper că putem fi de acord că construirea unui singur browser (sau motor) funcționează numai pentru dvs. dacă vizați o anumită piață și un anumit grup și chiar și atunci nu sunteți în siguranță să nu le pierdeți în viitorul apropiat.

Bibliotecile sunt viitorul

O altă încercare de a realiza visul uniformității cross-browser-ului este o strategie de abstractizare, utilizând biblioteci, polifenituri și cadre pentru a ne permite să scriem într-o singură limbă și să avem toată magia diferenței de browser sub capotă. Pentru utilizare în producție, aceasta este o idee foarte bună. Pe termen lung, bibliotecile ar trebui să ne ducă unde vrem să fim - aproape fiecare mediu software, mai devreme sau mai târziu, rulează utilizând biblioteci care unifică accesul la hardware sau API-uri de date. Pentru dezvoltarea aplicațiilor, trebuie să definim și să cultivăm aceste biblioteci și să le folosim în avantajul nostru.

Redundanță încorporată

Problema pe care o avem acum este însă că bibliotecile și cadrele de abstractizare devin punctul de plecare și, în cazul site-urilor web simple, cu un pic de fler, nu sunt necesare. Tocmai am început să le folosim fără să ne gândim la impactul lor sau chiar am uitat cum să facem lucrurile fără ele. Și, în multe cazuri, multe dintre lucrurile pe care le facem cu ele sunt deja disponibile în browser pentru noi, trebuie doar să folosim ceea ce există în loc să simulăm. Bibliotecile încep să sufere de obezitate și, în multe cazuri, grăsimea suplimentară este funcționalitatea de a face browserele vechi să facă lucruri pe care nu au fost niciodată menite să le facă, dar browserele bazate pe specificațiile HTML5 au deja încorporat.

Death By A Thousand Plugins

Utilizarea greșită a abstractizării codului este în curs de desfășurare în zilele noastre. Folosim biblioteci și convertoare care ne permit să scriem cea mai mică cantitate posibilă de cod pentru a realiza multe. Aceasta vine cu un preț. Cele trei rânduri pe care le scriem într-un limbaj abstract pot duce la zeci după convertire în cod care poate fi înțeles de browser. Este foarte tentant să folosim 20 de scripturi mici pe paginile noastre atunci când toate sunt doar câteva rânduri, dar acest lucru înseamnă o masă de solicitări HTTP și cod generat care înăbușă browserul. Deoarece nu vedem niciodată acest cod, nu pare a fi greșeala noastră - am scris doar cea mai mică cantitate posibilă de cod. Sigur că adăugarea unui alt script cu doar cinci linii de cod nu poate face diferența?