Korolev. Pilula de slăbit pentru Web
În urmă cu aproximativ un an, Nikita Prokopov a publicat un articol-manifest „Dezamăgirea software-ului”. Judecând după feedback-ul pozitiv, dezvoltatorii vor să aibă grijă de calitatea produselor pe care le produc. Este timpul să începem să acționăm, poate?
În această postare, vreau să vorbesc despre proiectul meu, care, în opinia mea, poate vindeca principalele probleme de performanță ale Web-ului modern și poate face utilizatorul un pic mai fericit. Iată-le - dimensiunea pachetelor JS, timp mare până la interactivitate, consum ridicat de RAM și CPU.
Înainte de a citi mai departe, urmați linkul. Încercați să jucați mai multe meciuri. Este de dorit să se joace de pe un desktop.
Un pic de istorie
La început, creatorii Web-ului au conceput browserul ca un client subțire pentru servere web. Browserul afișa pagini de hipertext primite de la un server. A fost simplu și elegant. Așa cum se întâmplă adesea, o idee frumoasă s-a confruntat cu realitatea și, după câțiva ani, producătorii de browsere au adăugat suport pentru un limbaj de scriptare. La început, era destinat doar decorării. Până la mijlocul primului deceniu, s-a considerat adecvat să se creeze site-uri web cu JS doar ca o opțiune.
Abordarea modernă a dezvoltării site-urilor web este rezultatul creșterii cerințelor de interactivitate a interfeței utilizatorului. Sarcinile de îmbunătățire a interactivității au căzut pe umerii proiectanților de șabloane. De multe ori nu au competența și autoritatea de a dezvolta o soluție „transversală”. Designerii de șabloane au învățat JS și au devenit ingineri front-end. Logica a început treptat să curgă de la server la client. Este convenabil ca tipul frontend să scrie totul pe partea clientului. Pentru tipul de backend, este convenabil să nu vă gândiți la utilizator. „Îți dau JSON și apoi nu-mi pasă” - spun ei. Acum doi ani, arhitectura fără server a devenit populară. Sugestia a fost că aplicațiile JS ar funcționa direct cu baza de date și cozile de mesaje.
Pentru moment, un site web obișnuit este o aplicație complexă scrisă în JS și un server API simplu. Logica principală se execută pe un client gros, iar partea server degenerează într-un proxy de bază de date.
Dacă o datorie tehnică din partea serverului nu poate afecta direct utilizatorul dvs., atunci din partea clientului va afecta. Dacă pornirea dvs. „decolează” și începe să câștige, atunci mai mult cu creșterea sarcinii, situația se va înrăutăți doar în ceea ce privește performanța. Cerințele se vor schimba. O bază de cod se va umfla și o rată de rotire într-o echipă va crește. Pagina se va îngrășa din dependențe. Site-ul va încărca JSON învechit. Sarcinile de fundal se vor înmulți în număr, fiecare dintre ele rulează câteva milisecunde în fiecare secundă, ceea ce după un timp va duce la decalaje și încălzirea iPad-ului unui utilizator nefericit, astfel încât el sau ea să poată prăji ouă pe el. Nimeni nu va îndrăzni să o remedieze din cauza fricii de a sparge sistemul. Se va termina cu tipii front-end arși care vin la manager cu o propunere de a renunța la vechiul cadru urât și a rescrie totul de la zero pe unul nou strălucitor. Managerul va refuza, iar tipii front-end vor începe să le folosească pe amândouă împreună.
Cum funcționează Korolev
Deci, dacă ne întoarcem la punctul de cotitură? În momentul în care cineva a venit cu ideea de a actualiza conținutul fără a reîncărca pagina, iar inevitabilitatea istorică a dat naștere AJAX? Ce se întâmplă dacă lăsăm totul pe server și facem un client subțire? Cele mai bune site-uri fac o redare prealabilă a paginilor de pe server, astfel încât un utilizator să poată vedea o interfață înainte de încărcarea JS. Putem merge mai departe și lăsăm doar codul pe client, care este responsabil pentru procesarea I/O, ținând cont de cerințele actuale de interactivitate. Gândurile despre acest lucru m-au condus la proiectul Korolev.