Dino Esposito: Dezvoltarea de aplicații web moderne. Analiza domeniilor și tehnologiilor. Ce trebuie să înveți pentru a dezvolta aplicații web moderne
În acest sens, întrebarea este - ce altceva trebuie să știți?În orice caz, aveți nevoie de un backend. Dacă am înțeles bine, Angular, Vue și alte cadre sunt doar frontend.
Așa este. Oriunde te întorci, despre dezvoltare web se vorbește peste tot ca dezvoltare front-end și, cu siguranță, este conectată cu Node.js (pentru a scrie ceva în Angular, nu te poți descurca fără ea). Nu înțeleg cum este conectat interfața la Node.js, deoarece... Node.js este în esență o modalitate de a rula JS în afara browserului.
Cel mai probabil, citiți articole despre front-end, deoarece nu există nimic despre backend în ele. După cum știți, front-end-ul este scris în JS și mulți sunt captivați de faptul că puteți instala NodeJS pe backend și puteți crea site-uri web folosind o singură limbă.Dacă vreau să rulez o aplicație într-un browser, atunci de ce am nevoie de node ? Toate acestea mă încurcă; văd doar contradicții.
Nu fi confuz. Există tehnologii care sunt utilizate în timpul procesului de aplicare și există tehnologii care sunt utilizate în timpul procesului de dezvoltare a aplicației. Toate aceste Gulp, Grunt, Babel, Webpack și altele sunt instrumente de dezvoltare. Acestea accelerează, simplifică și îmbunătățesc calitatea muncii. La acel moment, jQuery, Angular, React sunt bibliotecile și cadrele cu care va funcționa aplicația.
Dacă anterior site-urile web au fost create folosind câteva tehnologii, atunci aplicatii moderne pot folosi zeci, sau chiar sute dintre acestea din urmă. Mai mult, acestea ar putea fi diferite limbaje de programare, biblioteci, cadre, servicii etc. Toate acestea sunt adesea numite „grădina zoologică” a tehnologiei.
Aici pot doar să presupun că serverul, în loc de html, ar trebui să facă schimb de date cu aplicația prin json sau altceva.Da, JSON este cel mai comun. Aveți nevoie de un cadru de backend pe care să puteți implementa API-ul REST. Din câte știu eu majoritatea cadrelor moderne limbile moderne programele de programare care sunt utilizate pentru dezvoltarea web pot face acest lucru. Nu pot spune cu siguranță că lucrez în aceeași limbă.Totuși, serverul este baza oricărei aplicații de rețea și, în primul rând, trebuie să dezvoltați partea de server.
Categoric. Aplicațiile moderne de o singură pagină (SPA) constau din două părți separate - frontend și backend. Ele pot fi create complet separat de diferiți dezvoltatori, principalul lucru este de a conveni asupra formatului de transfer de date și a tuturor nuanțelor.
Frumusețea unui SPA constă în separarea acestor părți. Oricare dintre ele poate fi înlocuit cu altul fără consecințe speciale. Un backend poate servi site-uri, aplicatii mobile, oferă acces la date pentru terți aplicații partenereși toate printr-un singur API.
Ce altceva trebuie studiat? Sau cunoștințele enumerate sunt suficiente?Nu cred că este suficient. Vei determina cu precizie sarcinile pe care trebuie să le rezolve proiectul tău și vei selecta tehnologii pentru acestea. Trebuie să vă concentrați pe un singur lucru, nu veți putea studia totul modern, nu va fi suficient timp. Este posibil să nu folosiți Node.js și, în consecință, npm dacă JS (TS) este necesar doar în browserul? În același timp, este necesară și testarea.
Da, este destul. Pe partea clientului, de exemplu, JS+Angular. Și pe partea de backend, de exemplu, PHP + Laravel. Acum există o mulțime de limbi și chiar mai multe cadre pentru ele. Alege ce este mai ușor pentru tine.
Recent, în principal datorită UX și performanței.
Vreau să prezint 7 principii acționabile pentru site-urile web care doresc să utilizeze JavaScript pentru a controla interfața de utilizare. Aceste principii sunt rezultatul muncii mele ca web designer, dar și ca utilizator de lungă durată a WWW.
JavaScript a devenit, fără îndoială, un instrument indispensabil pentru dezvoltatorii front-end. Acum domeniul său de aplicare se extinde și în alte domenii, cum ar fi serverele și microcontrolerele. Acest limbaj de programare a fost ales de universități prestigioase pentru a preda studenților noțiunile de bază ale informaticii.
În același timp, există o serie de întrebări referitoare la rolul și utilizarea specifică a acestuia, la care multora le este greu să răspundă, inclusiv autorii cadrelor și bibliotecilor.
- Ar trebui folosit JavaScript ca înlocuitor pentru funcțiile browserului: istoric, navigare, redare?
- Backend-ul moare? Este necesar să redați HTML deloc?
- Este adevărat că aplicațiile pe o singură pagină (SPA) sunt viitorul?
- Ar trebui JS să genereze pagini pe un site web și să reda paginile în aplicații web?
- Ar trebui să folosesc tehnici precum PJAX sau TurboLinks?
- Care este diferența exactă dintre un site web și o aplicație web? Ar trebui să rămână ceva?
În primul rând, trebuie să subliniez greșeala comună de a separa „aplicațiile redate pe server” de „aplicațiile cu o singură pagină”. Dacă dorim să obținem cea mai bună experiență din punctul de vedere al utilizatorului, nu trebuie să ne limităm la astfel de limite și să abandonăm o alternativă în favoarea alteia.
Motivele sunt destul de evidente. Paginile sunt transmise prin Internet, care are limitări fizice, așa cum a ilustrat memorabil Stuart Cheshire în celebrul eseu „It’s Latency, Fool”:
Distanța dintre Stanford și Boston este de 4320 km.Viteza luminii în vid este de 300 x 10^6 m/s.
Viteza luminii în fibra optică este de aproximativ 66% din viteza luminii în vid.
Viteza luminii în fibra optică este de 300 x 10^6 m/s * 0,66 = 200 x 10^6 m/s.
Întârziere unidirecțională la transmiterea către Boston 4320 km / 200 x 10^6 m/s = 21,6 ms.
Latență dus-întors 43,2 ms.
Ping-ul de la Stanford la Boston pe internetul modern este de aproximativ 85 ms (...)
Asa de, echipament modern Internetul transmite un semnal cu o viteză de 0,5 ori mai mare decât viteza luminii.
Rezultatul raportat de 85 ms poate fi îmbunătățit (și este deja puțin mai bun), dar este important să înțelegeți că există limitare fizică la întârzierea transmiterii informațiilor prin internet, indiferent de cât de multă lățime de bandă crește pe computerele utilizatorilor.
Acest lucru este deosebit de important odată cu creșterea popularității aplicațiilor JavaScript, care de obicei conțin doar markup și un câmp gol lângă el. Așa-numitele aplicații de o singură pagină (SPA) - serverul returnează o pagină, iar orice altceva este apelat prin cod pe partea clientului.
Imaginați-vă un scenariu în care un utilizator accesează direct app.com/orders. Până în momentul în care aplicația dvs. primește și procesează această solicitare, aceasta are deja o importanță importantă informație despre ceea ce trebuie afișat pe pagină. Poate, de exemplu, să încarce o comandă din baza de date și să o adauge la răspuns. Dar majoritatea SPA-urilor în această situație returnează o pagină goală și o etichetă. Apoi va trebui să schimbați din nou solicitări pentru a primi conținutul scriptului și din nou pentru a primi conținutul.
Analizarea codului HTML trimis de server pentru fiecare pagină SPA
Mulți dezvoltatori fac în mod conștient un astfel de sacrificiu. Ei încearcă să asigure acea rețea suplimentară hamei se va întâmpla o singură dată pentru utilizator, trimiterea titluri corecte pentru stocarea în cache a răspunsurilor cu scripturi și CSS. Înțelepciunea convențională este că aceasta este o afacere bună, deoarece odată ce toate fișierele sunt descărcate pe computer, majoritatea acțiunilor utilizatorului (cum ar fi navigarea către alte secțiuni) au loc fără a necesita pagini sau scripturi suplimentare.
Totuși, chiar și luând în considerare cache-ul, există o anumită pierdere de performanță dacă luăm în considerare timpul de parsare și execuție a scriptului. În articolul „Este jQuery prea mare pentru mobil?” spune cum doar jQuery poate încetini unele browsere mobile timp de sute de milisecunde.
Pentru a înrăutăți lucrurile, utilizatorul nu primește de obicei niciun feedback în timp ce scripturile se încarcă. rezultat - pagină goală pe ecran, care apoi se transformă brusc într-o pagină complet încărcată.
Cel mai important, avem tendința să uităm că cel mai comun transport de date pe Internet (TCP) începe lent. Acest lucru aproape sigur garantează că majoritatea pachetelor de scripturi nu vor fi transferate dintr-o singură mișcare, înrăutățind situația de mai sus.
O conexiune TCP începe cu schimbul de pachete de handshake. Dacă utilizați SSL, care este important pentru transferul securizat de scripturi, există două schimburi suplimentare de pachete (unul dacă clientul recuperează sesiunea). Abia după aceasta serverul poate începe să trimită date, dar practica arată că face acest lucru lent și în loturi.
Este încorporat un mecanism de control al congestiei numit Slow Start Protocolul TCP pentru a trimite date, crescând treptat cantitatea segmente. Acest lucru are două implicații serioase pentru SPA:
1. Încărcarea scripturilor mari durează mult mai mult decât par. După cum se explică în cartea „High Performance Browser Networking” de Ilya Grigorik, este nevoie de „patru schimburi de pachete (...) și sute de milisecunde de latență pentru a ajunge la 64 KB de schimb de date între client și server”. De exemplu, în cazul unei conexiuni rapide la Internet între Londra și New York, durează 225 ms înainte ca TCP să ajungă dimensiune maximă pachet.
2. Întrucât această regulă se aplică și pentru descărcare inițială pagina, atunci este foarte important ce conținut este încărcat pentru a fi redat mai întâi pe pagină. După cum concluzionează Paul Irish în prezentarea sa Delivering Goods, primii 14 KB sunt critici. Acest lucru este clar dacă te uiți la graficul care indică volumele de transfer între client și server în primele etape ale stabilirii unei conexiuni.
Câți KB poate trimite serverul la fiecare etapă de conectare, pe segment
Site-urile web care reușesc să livreze conținut (chiar și markup de bază fără date) în această fereastră par excepțional de receptive. De fapt, mulți autori de post aplicatii server percepe JavaScript ca pe ceva inutil sau care trebuie folosit cu mare precauție. Această atitudine este întărită și mai mult dacă aplicația are un backend și o bază de date rapide, iar serverele sale sunt situate în apropierea utilizatorilor (CDN).
Rolul serverului în accelerarea prezentării conținutului depinde direct de aplicația web. Soluția nu se rezumă întotdeauna la „redarea paginilor întregi pe server”.
În unele cazuri, irelevant în acest moment Pentru utilizator, este mai bine să excludă o parte a paginii din răspunsul inițial și să o lași pentru mai târziu. Unele aplicații, de exemplu, preferă să redeze doar „nucleul” paginii pentru a asigura o capacitate de răspuns imediată. Apoi solicită diferite părți ale paginii în paralel. Acest lucru oferă o mai bună capacitate de răspuns chiar și în situații cu un backend lent, vechi. Pentru unele pagini opțiune bună Doar partea vizibilă a paginii va fi redată.
Foarte important evaluare calitativă scripturi și stiluri, ținând cont de informațiile pe care le are serverul despre sesiune, client și URL. Scripturile care sortează comenzile vor fi, evident, mai importante pentru /comenzi decât logica paginii de setări. Poate că nu este atât de evident, dar există o diferență în încărcare " CSS structural„ și „CSS pentru stil”. Primul poate fi necesar pentru Cod JavaScript, deci este necesar blocare, iar al doilea este încărcat asincron.
Un bun exemplu de SPA care nu are ca rezultat schimbul inutil de pachete este clona de concept StackOverflow de 4096 de octeți, care teoretic s-ar putea încărca cu primul pachet după o strângere de mână pe o conexiune TCP! Autorul a reușit să realizeze acest lucru refuzând memorarea în cache, folosind inline pentru toate resursele în răspunsul de la server. Folosind SPDY sau HTTP/2 server push, este teoretic posibil să transferați tot codul client din cache într-un singur salt. Ei bine, în prezent, randarea părților sau a întregii pagini pe partea serverului rămâne cea mai populară modalitate de a scăpa de runde inutile de schimb de pachete.
SPA-dovada de concept folosind inline pentru CSS și JS pentru a scăpa de călătoriile inutile dus-întors
Un sistem destul de flexibil care împarte randarea între browser și server și oferă instrumente pentru încărcarea treptată a scripturilor și stilurilor ar putea foarte bine să estompeze linia dintre site-uri webȘi aplicații web. Ambele folosesc adrese URL, navigare și demonstrează date utilizatorului. Chiar și o aplicație de calcul tabelar care se bazează în mod tradițional pe funcționalitatea clientului trebuie să arate mai întâi clientului informațiile care trebuie editate. Și a face acest lucru în cel mai mic număr de călătorii dus-întors este de o importanță capitală.
Din punctul meu de vedere, cel mai mare defect de performanță din mulți sisteme populareîn timpurile moderne se explică prin acumularea progresivă de complexitate în stivă. De-a lungul timpului, au fost adăugate tehnologii precum JavaScript și CSS. Popularitatea lor a crescut, de asemenea, treptat. Abia acum putem aprecia cum pot fi folosite diferit. Vorbim și de îmbunătățirea protocoalelor (asta o arată progresul actual al SPDY și QUIC), dar cel mai mare beneficiu vine din optimizarea aplicațiilor.
Poate fi util să ne amintim câteva dintre discuțiile istorice despre design. versiuni anterioare HTML și WWW. De exemplu, această listă de corespondență din 1997 sugerează adăugarea etichetei în HTML. Marc Andreessen reiterează importanța furnizării rapide a informațiilor:
Sarcina noastră este accelerație maximă reacții la acțiunile utilizatorului. Indiferent de cât de mult efort am depune pentru a reduce numărul de hopuri atunci când lucrăm cu o aplicație web, există lucruri în afara controlului nostru. Aceasta este limita teoretică a vitezei luminii și ping-ul minim între client și server.
Un factor important este calitatea imprevizibilă a comunicării dintre client și server. Dacă calitatea conexiunii este slabă, atunci pachetele vor fi retransmise. Acolo unde conținutul trebuie să se încarce în câteva călătorii dus-întors, este posibil să aveți nevoie de mult mai mult.
Acesta este principalul beneficiu al JavaScript pentru îmbunătățirea UX. Dacă interfața este scriptată pe partea clientului, putem ascunde latența rețelei. Putem crea o impresie de mare viteză. Putem obține în mod artificial o latență zero.
Să presupunem din nou că acesta este HTML simplu. Documentele sunt conectate prin hyperlinkuri sau etichete . Dacă faceți clic pe oricare dintre ele, browserul face o solicitare de rețea, care durează un timp imprevizibil, apoi primește și procesează datele primite și în cele din urmă intră într-o nouă stare.
JavaScript vă permite să răspundeți imediat și optimist la acțiunile utilizatorului. Făcând clic pe un link sau un buton rezultă un răspuns imediat, fără a fi nevoie să accesați Internetul. Un exemplu binecunoscut este interfața Gmail (sau Google Inbox), în care arhivarea unui mesaj de e-mail are loc imediat, în timp ce cererea corespunzătoare către server este trimisă și procesată asincron.
În cazul unui formular, în loc să așteptăm un cod HTML ca răspuns la completarea acestuia, putem răspunde imediat de îndată ce utilizatorul apasă „Enter”. Sau și mai bine, așa cum face căutarea Google, putem reacționa chiar mai devreme, pregătind în avans marcajul pentru o pagină nouă.
Acest comportament este un exemplu a ceea ce numesc eu adaptarea markupului. Ideea de bază este că pagina „își cunoaște” markup-ul viitor, așa că poate trece la ea atunci când nu există date care să o indice încă. Acesta este un comportament „optimist”, deoarece există încă riscul ca datele să nu ajungă niciodată și să fie raportat un mesaj de eroare, dar acest lucru este evident rar.
Pagina de pornire a Google este un bun exemplu, deoarece demonstrează foarte clar primele două principii din articolul nostru.
La sfârșitul anului 2004, Google a devenit un pionier în domeniul folosind JavaScript pentru a oferi indicii în timp real în timpul tastării interogare de căutare(interesant, angajatul a dezvoltat această funcție în 20% din timp liber de la locul de muncă principal, la fel ca Gmail). Aceasta a devenit chiar baza pentru apariția lui Ajax:
Uită-te la Google Suggest. Urmăriți-vă actualizarea termenilor de căutare pe măsură ce introduceți, aproape instantaneu... fără a întârzia reîncărcările paginilor. Google Suggest și Hărți Google sunt două exemple ale unei noi abordări pentru crearea de aplicații web pe care noi, la Adaptive Path, le numim „Ajax”Și în 2010, au introdus Căutarea instantanee, în care JS joacă un rol central, eliminând complet reîmprospătările manuale ale paginilor și trecând la marcajul „rezultatele căutării” la prima apăsare a tastei, așa cum se vede în ilustrația de mai sus.
Un alt exemplu proeminent de adaptare a marcajului poate fi în buzunarul tău. Încă din primele zile, iPhone OS a cerut autorilor aplicațiilor să furnizeze o imagine implicit.png, care poate fi afișat imediat pe ecran în timp ce aplicația în sine se încarcă.
iPhone OS forțează default.png să se încarce înainte de lansarea aplicației
Un alt tip de acțiune, altul decât clicurile și trimiterile de formulare, care se îmbunătățesc foarte mult cu folosind JavaScript, este o redare a încărcării fișierului.
Putem înregistra încercarea unui utilizator de a descărca un fișier căi diferite: drag-n-drop, lipiți din clipboard, selectați fișierul. Apoi, datorită noilor API HTML5, putem afișa conținutul ca și cum ar fi fost deja descărcat. Un exemplu de acest tip de interfață este munca noastră cu descărcări în Cloudup. Observați cum este generată și redată instantaneu miniatura imaginii:
Imaginea este redată și afișată până la finalizarea încărcării
În toate aceste cazuri ne îmbunătățim percepția vitezei. Din fericire, există o mulțime de dovezi pentru utilitatea acestei abordări. Luați măcar un exemplu despre cum crește distanțe până la transportorul de bagaje de pe Aeroportul Houston scăzut numărul de plângeri privind bagajele pierdute, fără a fi nevoie de a accelera procesarea bagajelor.
Această idee ar trebui să aibă un impact serios asupra interfeței de utilizare a aplicațiilor noastre. Consider că indicatorii de încărcare ar trebui să devină o raritate, mai ales că trecem la aplicații de informare în timp real, care sunt descrise în secțiunea următoare.
Există situații în care iluzia acțiunii instantanee are de fapt un efect negativ asupra UX. Aceasta poate fi o formă de plată sau încheierea unei sesiuni pe site. Luând aici o abordare optimistă, înșelând de facto utilizatorul, riscăm să-l irităm.
Dar chiar și în aceste cazuri, afișarea spinnerelor sau a indicatorilor de încărcare pe ecran ar trebui oprită. Acestea ar trebui să fie afișate numai după ce utilizatorul consideră că răspunsul nu este imediat. Potrivit unui studiu Nielsen des citat:
Sfatul de bază privind timpul de răspuns a rămas același timp de treizeci de ani Miller 1968; Card și colab. 1991:*0,1 secunde este limita pentru ca utilizatorul să perceapă răspunsul ca fiind imediat, nu este necesară afișarea aici Informații suplimentare, cu excepția rezultatului operației.
* 1,0 secunde este limita pentru continuitatea gândirii utilizatorului, chiar dacă va observa întârzierea. De obicei, nu este necesară nicio indicație suplimentară pentru întârzieri mai mari de 0,1 secunde, dar mai mici de 1,0 secunde, dar utilizatorul pierde sentimentul de a lucra direct cu datele.
* 10 secunde este limita pentru menținerea atenției utilizatorului asupra dialogului. La întârziere mai mare utilizatorii vor dori să efectueze o altă sarcină în timp ce așteaptă un răspuns de la computer.
Tehnici precum PJAX sau TurboLinks ratează, din păcate, majoritatea caracteristicilor descrise în aceasta sectiune. Codul client-side nu „știe” despre starea viitoare a paginii până când nu are loc schimbul de date cu serverul.3. Răspuns la modificările de date l;DR: Când datele sunt actualizate pe server, clientul trebuie anunțat fără întârziere. Aceasta este o formă de îmbunătățire a productivității în care utilizatorul este eliberat de a fi nevoit acțiuni suplimentare(apăsați F5, reîmprospătați pagina). Probleme noi: managementul (re)conexiunii, recuperarea stării.
Al treilea principiu se referă la răspunsul UI la modificările datelor la sursă, de obicei unul sau mai multe servere de baze de date.
Modelul de transmisie devine un lucru din trecut. date HTML, care rămân statice până când utilizatorul reîmprospătează pagina (site-uri web tradiționale) sau interacționează cu aceasta (Ajax).
Interfața dvs. de utilizare ar trebui să se actualizeze automat.
Acest lucru este critic într-o lume cu un flux din ce în ce mai mare de informații surse diferite, inclusiv ceasuri, telefoane, tablete și dispozitive portabile care vor veni în viitor.
Imaginați-vă Facebook News Feed imediat după introducerea sa, când informațiile erau publicate în principal de pe computerele personale ale utilizatorilor. Redarea statică nu a fost optimă, dar avea sens pentru persoanele care și-au reîmprospătat feedul, să zicem, o dată pe zi.
Acum trăim într-o lume în care încarci o fotografie și primești aproape imediat aprecieri și comentarii de la prieteni și cunoscuți. Nevoia de răspuns instantaneu a devenit o necesitate firească în mediul competitiv al altor aplicații.
Ar fi greșit, totuși, să presupunem că beneficiile actualizărilor instant UI sunt limitate la aplicațiile multi-utilizator. De aceea îmi place să vorbesc despre puncte de date agreate, în loc de utilizatorii. Să luăm un scenariu tipic pentru sincronizarea fotografiilor între telefon și propriul laptop:
O aplicație cu un singur utilizator poate beneficia și de reactivitate.
Util de imaginat toate informații care sunt trimise utilizatorului ca „reactive”. Sincronizarea sesiunii și a stării de autorizare este un exemplu de abordare universală. Dacă utilizatorii aplicației dvs. au mai multe file deschise în același timp, atunci încheierea sesiunii de lucru pe una dintre ele ar trebui să dezactiveze imediat autorizarea pentru toate celelalte. Acest lucru duce inevitabil la o siguranță îmbunătățită și protectie mai buna informații confidențiale, mai ales în situațiile în care mai multe persoane au acces la același dispozitiv.
Fiecare pagină reacționează la starea sesiunii și la starea de autorizare
Odată ce ați stabilit o regulă prin care informațiile de pe ecran se actualizează automat, este important să lucrați sarcina noua: Recuperarea statului.
Când trimiteți solicitări și primiți actualizări atomice, este ușor să uitați că aplicația dvs. ar trebui să se actualizeze în mod normal chiar și după o perioadă lungă de inactivitate. Imaginați-vă că închideți capacul laptopului și îl deschideți câteva zile mai târziu. Cum se va comporta aplicația?
Un exemplu de ceea ce se întâmplă dacă conexiunea nu este actualizată corect
Capacitatea aplicației de a se reconecta interacționează în mod normal cu principiul # 1. Dacă alegeți să trimiteți date la prima încărcare a paginii, trebuie să luați în considerare și timpul care trece înainte ca scripturile să fie încărcate. Acest timp este în esență echivalent cu timpul de deconectare, așa că conexiunea inițială a scripturilor dumneavoastră este reluarea sesiunii.
4. Controlul schimbului de date cu serverul tl;DR: Acum putem ajusta schimbul de date cu serverul. Asigurați gestionarea erorilor, solicitări repetate în favoarea clientului, sincronizarea datelor în fundalși salvarea memoriei cache offline.Când a apărut web-ul, comunicarea dintre client și server a fost limitată în mai multe moduri:
Principalele restricții se referă la al doilea punct. Incapacitatea de a trimite date fără a încărca neapărat o pagină nouă a fost un dezavantaj din perspectiva performanței. Dar cel mai important lucru este că a spart complet butonul „Înapoi”:
Probabil cel mai enervant artefact al vechiului web
Acesta este motivul pentru care web-ul ca platformă de aplicații a rămas incomplet fără JavaScript. Ajax a reprezentat un salt uriaș înainte în ceea ce privește ușurința publicării utilizatorilor.
Acum avem multe API-uri (XMLHttpRequest, WebSocket, EventSource, doar pentru a numi câteva) care oferă control complet și precis asupra fluxului de date. Pe lângă capacitatea de a publica datele utilizatorilor printr-un formular, avem noi oportunități de îmbunătățire a UX.
Direct legat de principiul anterior are spectacol starea conexiunii. Dacă ne așteptăm ca datele să fie actualizate automat, trebuie să informăm utilizatorul despre fapte pierderea conexiuniiȘi încearcă să o restaureze.
Când este detectată o deconectare, este util să stocați datele în memorie (sau mai bine zis, în localStorage) pentru a putea fi trimise ulterior. Acest lucru este deosebit de important în lumina utilizării viitoare a ServiceWorker, care permite aplicații JavaScript muncă in fundal. Dacă aplicația dvs. nu este deschisă, puteți continua să încercați să sincronizați datele cu serverul în fundal.
Luați în considerare posibilitatea de timeout-uri și erori la trimiterea datelor; astfel de situații ar trebui rezolvate în favoarea clientului. Dacă conexiunea este restabilită, încercați să trimiteți din nou datele. Când eroare permanentă, informați utilizatorul despre acest lucru.
Unele erori trebuie tratate cu deosebită atenție. De exemplu, un 403 neașteptat ar putea însemna că sesiunea utilizatorului a fost invalidată. În astfel de cazuri, este posibilă restabilirea sesiunii arătând utilizatorului o fereastră pentru introducerea numelui de utilizator și a parolei.
De asemenea, este important să vă asigurați că utilizatorul nu întrerupe accidental fluxul de date. Acest lucru se poate întâmpla în două situații. Primul și cel mai evident caz este închiderea browserului sau a filei, ceea ce încercăm să prevenim cu handlerul beforeunload.
Avertisment înainte de descărcare
Un alt caz (și mai puțin evident) este atunci când încercați să navigați către o altă pagină, de exemplu făcând clic pe un link. În acest caz, aplicația poate opri utilizatorul folosind alte metode, la discreția dezvoltatorului.
5. Nu spargeți istoricul, îmbunătățiți-l tl;DR: Dacă browserul nu gestionează URL-urile și istoricul, vom avea noi probleme. Asigurați-vă că îndepliniți comportamentul de derulare așteptat. Salvați-vă propriul cache pentru feedback rapid.În lipsa trimiterii formularelor, utilizarea doar a hyperlink-urilor într-o aplicație web ne va oferi o navigare înainte/înapoi complet funcțională în browser.
De exemplu, o pagină tipică „nesfârșită” este de obicei realizată cu un buton JavaScript care solicită date suplimentare/HTML și îl inserează. Din păcate, puțini oameni își amintesc să apeleze history.pushState sau replaceState ca pas obligatoriu.
De aceea folosesc cuvântul „pauză”. Cu modelul simplu al rețelei originale, această situație nu a fost posibilă. Fiecare schimbare de stare sa bazat pe o modificare a adresei URL.
Dar există și partea din spate medalii - oportunitate îmbunătăţi istoric de navigare, pe care acum îl controlăm folosind JavaScript.
O astfel de posibilitate a fost numită Fast Back de Daniel Pipius:
Butonul înapoi ar trebui să funcționeze rapid; utilizatorii nu se așteaptă la o schimbare prea mare a datelor.Este ca și cum ai trata butonul înapoi ca pe un buton dintr-o aplicație web și i-ai aplica principiul #2: răspunde imediat la acțiunile utilizatorului. Principalul lucru este că aveți posibilitatea de a decide cum să organizați stocarea în cache pagina anterioarăși afișați-l instantaneu pe ecran. Apoi puteți aplica principiul #3 și apoi informați utilizatorul când sosesc date noi pe pagina respectivă.
Există încă câteva situații în care nu aveți control asupra comportamentului cache-ului. De exemplu, dacă ați randat o pagină, apoi ați accesat un site terță parte, iar apoi utilizatorul a făcut clic pe „Înapoi”. Aplicațiile care redau HTML pe partea serverului și apoi îl modifică pe partea clientului sunt deosebit de susceptibile la acest mic bug:
Operarea incorectă a butonului „Înapoi”.
O altă modalitate de a întrerupe navigarea este să ignorați memoria stării de defilare. Încă o dată, paginile care nu folosesc JS și gestionarea manuală a istoricului probabil nu vor avea o problemă aici. Dar vor fi pagini dinamice. Am testat două dintre cele mai populare fluxuri de știri Bazat pe JavaScript pe Internet: Twitter și Facebook. Ambii aveau amnezie de defilare.
Întoarcerea fără sfârșit a paginii este de obicei un semn de amnezie de defilare
La urma urmei, fiți atenți la schimbările de stare care sunt relevante doar atunci când vizualizați istoricul. De exemplu, acest caz cu schimbarea stării subarborilor cu comentarii.
Schimbarea tipului de comentarii trebuie salvată în istoric
Dacă pagina a fost redată din nou după ce a făcut clic pe un link dintr-o aplicație, utilizatorul s-ar putea aștepta ca toate comentariile să fie extinse. Când starea se schimbă, aceasta trebuie salvată în istorie.
6. Actualizarea codului prin mesaje pushtl;DR: Nu este suficient să trimiteți doar date prin mesaje push, aveți nevoie și de cod. Evitați erorile API și îmbunătățiți performanța. Utilizați DOM fără stat pentru a vă reproiecta fără durere aplicația.Este extrem de important ca aplicația dvs. să răspundă la modificările din cod.
În primul rând, reduce numărul de erori posibile și crește fiabilitatea. Dacă ați făcut o modificare importantă API-ului backend, atunci trebuie sa actualizați codul programelor client. În caz contrar, este posibil ca clienții să nu accepte noile date sau să trimită date într-un format incompatibil.
Un motiv la fel de important este să adere la principiul nr. 3. Dacă interfața se actualizează singură, atunci există puține motive pentru ca utilizatorii să recurgă la reîncărcarea manuală a paginii.
Rețineți că, pentru un site obișnuit, o reîmprospătare a paginii declanșează două lucruri: o reîncărcare a datelor și o reîncărcare a codului. Organizarea unui sistem cu actualizări de date push fără actualizări de cod push este incompletă, mai ales într-o lume în care o filă (sesiune) poate rămâne deschisă foarte mult timp. pentru o lungă perioadă de timp.
Dacă canalul push server funcționează, atunci utilizatorul poate fi notificat despre disponibilitatea unui nou cod. Dacă nu, numărul versiunii poate fi adăugat la antetul solicitărilor HTTP trimise. Serverul îl poate compara cu cea mai recentă versiune cunoscută, poate fi de acord să proceseze cererea sau nu și să emită un job clientului.
După aceasta, unele aplicații web reîncarcă forțat pagina în numele utilizatorului. De exemplu, dacă pagina nu se află în zona vizibilă a ecranului și nu există formulare completate pentru introducere.
O abordare și mai bună este schimbarea la cald a codului. Aceasta înseamnă că nu trebuie să efectuați repornire completă pagini. În schimb, sigur module sunt înlocuite din mers, iar codul lor este retrimis spre execuție.
In multe aplicațiile existente Este destul de dificil să schimbi codul la cald. Pentru a face acest lucru, trebuie să aderați inițial la o arhitectură care separă comportament(cod) din date(stat). Această diviziune ne va permite să lansăm destul de repede multe patch-uri diferite.
De exemplu, în aplicația noastră web există un modul care configurează o magistrală pentru transmiterea evenimentelor (cum ar fi socket.io). Când are loc un eveniment, starea unei anumite componente se schimbă și acest lucru se reflectă în DOM. Apoi modificați comportamentul acelei componente, de exemplu, astfel încât să genereze un marcaj DOM diferit pentru starea existentă și cea nouă.
În mod ideal, ar trebui să putem schimba codul modular. Nu va fi nevoie să restabiliți o conexiune la priză, de exemplu, dacă este posibil să actualizați pur și simplu codul componentei necesare. Arhitectura ideală pentru actualizările de cod push este, prin urmare, modulară.
Dar se pune imediat problema cum să evaluăm modulele fără efecte secundare nedorite. O arhitectură precum cea oferită de React este cea mai potrivită aici. Dacă codul unei componente este actualizat, logica acestuia poate fi pur și simplu re-execută și DOM-ul este actualizat. Citiți explicația lui Dan Abramov despre acest concept.
În esență, ideea este că actualizați DOM-ul (sau îl recolorați), ceea ce ajută foarte mult la înlocuirea codului. Dacă starea este stocată în DOM sau handlerele de evenimente sunt instalate de aplicație, atunci actualizarea codului poate deveni o sarcină mult mai dificilă.
7. Predicția comportamentului tl;DR: Întârziere negativă.O aplicație JavaScript modernă poate avea mecanisme pentru a prezice acțiunile utilizatorului.
Cea mai evidentă aplicație a acestei idei este pre-descărcarea datelor de pe un server înainte ca utilizatorul să le solicite. Încărcarea unei pagini web cu cursorul mouse-ului trecând peste ea, astfel încât clic pe linkuri să o afișeze instantaneu este un exemplu simplu.
O metodă ceva mai avansată de monitorizare a urmăririi mouse-ului analizează traiectoria mouse-ului pentru viitoarele „coliziuni” cu elemente interactive precum butoanele. :
Pluginul jQuery prezice calea mouse-ului
Paginile cu hyperlink sunt elemente de bază bune pentru orice aplicație. Încărcarea progresivă a codului, stilurilor și marcajului pe măsură ce utilizatorul interacționează asigură o performanță excelentă fără a sacrifica interactivitatea.
Noile caracteristici unice sunt furnizate de JavaScript. Dacă aceste tehnologii sunt utilizate pe scară largă, vor oferi cea mai bună experiență pentru utilizatorii celei mai libere platforme existente - WWW.
Etichete:
- latenta
- performanţă
- PJAX
- TurboLinks
INSTRUMENTE MODERNE PENTRU DEZVOLTAREA SITE-URILOR DE INTERNET SI APLICATIILOR WEB
Krupina Tatyana Aleksandrovna 1, Shcherbakov Svetlana Mikhailovna 1
1 Moscova Pedagogic Universitate de stat, masterand
adnotare
Acest articol este dedicat revizuirii mijloace moderne dezvoltarea de site-uri Internet și aplicații Web. Sunt discutate și problemele predării elevilor și școlarilor acestor tehnologii.
INSTRUMENTE MODERNE DE DEZVOLTARE SITE-URI ONLINE ȘI APLICAȚII WEB
Krupina Tatiana Aleksandrovna 1 , Shcherbakova Svetlana Mikhajlovna 1
1 Universitatea Pedagogică de Stat din Moscova, absolvent al Departamentului de Matematică Aplicată și IT
Abstract
Acest articol oferă o privire de ansamblu asupra dezvoltării site-urilor web moderne și a aplicațiilor bazate pe web. De asemenea, se discută problema formării studenților și elevilor cu aceste tehnologii.
Informatizarea societăţii moderne este asociată cu introducerea mijloacelor şi metodelor de informare şi tehnologii de comunicare(TIC) în diverse zone activitate umana. Un rol special în acest proces revine, fără îndoială, dezvoltării tehnologiilor de rețea și comunicațiilor, care, printre altele, se manifestă prin crearea de sisteme automatizate corporative. sisteme de informareși proiecte de rețea de comerț electronic. Într-adevăr, activitățile oricărui întreprindere modernă, într-un fel sau altul, este legat de crearea și întreținerea unui site web corporativ.
Standardele educaționale moderne ale statului federal (FSES) în multe domenii nu numai de inginerie, ci și umanitare necesită absolvenți să aibă abilitățile de a dezvolta și gestiona site-uri de internet.
Metodele și instrumentele pentru dezvoltarea site-urilor Internet și a aplicațiilor Web se dezvoltă dinamic de la capacitatea de a crea site-uri simple de cărți de vizită până la dezvoltarea de aplicații server care procesează și stochează cantități mari de date.
Pentru a dezvolta un site web simplu, inclusiv un site de carte de vizită cu o descriere și informații de contact, puteți utiliza diferite metode:
- Creare document HTML, adică folosind editorul Notepad, introduceți codul în limbaj HTML V mod manualși implementați-l folosind un browser pe stația de lucru client și, ulterior, îl publicați cu furnizorul utilizând serviciile sale de găzduire;
- creând același document HTML folosind Editor Adobe Dreamweaver, profitând de o gamă largă de caracteristici și facilități;
- utilizați site-uri shell gata făcute pentru a dezvolta site-uri Web cu diverse domenii tematice și design și, de asemenea, publicați site-ul pe Internet folosind servicii de găzduire gratuite sau plătite.
Spre deosebire de dezvoltarea site-urilor simple și neinteractive, pentru dezvoltarea aplicațiilor Web care rulează și prelucrează date pe server sunt necesare metode și instrumente care să le completeze pe cele indicate în paragraful anterior. Dezvoltarea aplicatiilor Web presupune, pe langa crearea de cod HTML, si programarea intr-un limbaj special. Limbajul folosit pentru dezvoltarea aplicațiilor Web este Programare PHPși, de asemenea, nu pot face fără, de exemplu, server local Baze de date Apache și MySQL.
Să ne uităm la câteva instrumente de programare a aplicațiilor web:
- limba Programare JavaScript folosit pentru a crea documente HTML interactive;
- VBScript este utilizat pentru scripting client, precum și scripting server;
- Perl este folosit pentru dezvoltarea instrumentelor administrarea sistemului, precum și în dezvoltarea de scripturi, sisteme CGI prelucrare automată E-mailși suport pentru site-uri web.
Pentru a dezvolta independent aplicații Web, puteți utiliza resursa Denwer distribuită gratuit.
Denwer (din abrevierea DNVR - un set de dezvoltatori Web pentru gentleman) este un set de distribuții și un shell software care sunt concepute pentru crearea și depanarea aplicațiilor Web și a altor conținuturi dinamice ale paginilor Web pe un PC care rulează un sistem de operare.
Setul Denwer include:
- local server Apache pentru a rula aplicații pe computerul utilizatorului, simulând funcţionalitate server unde furnizorul va instala ulterior aplicația dezvoltată. Apache este software– multiplatformă, distribuită gratuit și susținută de diverse sisteme de operare;
- Sistemul de programare PHP este un limbaj asemănător C pentru dezvoltarea codurilor de program încorporate în codul HTML al unui site și executate pe server în scopul procesării datelor primite de la utilizatorii unui anumit site. PHP (Hypertext Preprocessor, inițial Personal Home Page Tools) este un limbaj de scripting scop general, folosit pentru dezvoltarea de aplicații Web, a fost creat de Rasmus Lerdorf în 1994;
- MySQL este un software disponibil gratuit pentru procesarea bazelor de date, inclusiv atunci când lucrați cu date primite de la browserele client. MySQL (Structured Query Language) a fost creat de Michael Widenius de la compania suedeză TcX în 1995.
Suita de software Denwer sau componentele sale individuale sunt utilizate pe scară largă atât de amatori, cât și de profesioniști pentru a crea și depana aplicații și site-uri web. Acest set este, de asemenea, utilizat pe scară largă în scopuri educaționale pentru a preda programarea Web școlarilor și elevilor.
Ce este dezvoltarea de aplicații web?
Dezvoltarea de aplicații web este un termen general pentru procesul de creare a paginilor web sau a site-urilor web. Paginile web sunt create folosind HTML, CSS și JavaScript. Aceste pagini pot conține text și elemente grafice simple, asemănătoare unui document static. Paginile pot fi, de asemenea, interactive sau pot afișa informații în schimbare. Crea pagini interactive puțin mai complexe, dar vă permit să creați site-uri web bogate în conținut. Astăzi, majoritatea paginilor sunt interactive și oferă servicii interactive avansate, cum ar fi cărucioare de cumpărături online, vizualizări dinamice și chiar rețele sociale sofisticate.
Dezvoltare de aplicatii pentru calculatoare moderne realizate folosind limbaje de programare specializate. Aceste materiale introductive vă vor ajuta să vă familiarizați cu ele.
Video | 15 minute | Limbaje de programare
Acest raport vorbește despre motivul pentru care sunt necesare limbaje de programare, despre ce sunt acestea și pentru ce scopuri sunt destinate. Limbajele de marcare (HTML), reprezentarea datelor (XML) și limbajele de interogare (SQL) sunt, de asemenea, menționate pe scurt.
Video | 23 minute | Limbaje de programare
Acest raport oferă o scurtă prezentare generală a limbajului de programare C#, a principalelor caracteristici și design-uri și demonstrează exemple de creare a aplicațiilor simple pentru consolă și fereastră pentru Windows în Studio vizual 2010.
Explorați capabilitățile bogate ale sălii de operație sisteme Windows, care poate și ar trebui utilizat la dezvoltarea aplicațiilor web.
| 4 | instrumente de dezvoltare |
Video | 10 minute | WebMatrix
O scurtă poveste despre WebMatrix - un mediu pentru dezvoltarea site-urilor web. WebMatrix vă permite să creați site-uri web de complexitate diferită: de la pagina principala prea mic portal corporativ. Mediul include un set de șabloane de site web care pot fi folosite ca bază pentru crearea propriului site web. WebMatrix vă permite să creați și să editați codul și marcarea site-ului web, precum și să gestionați baze de date și să publicați site-uri web gata făcute pe găzduire.
Video | 11 minute | Internet Explorer
Această discuție oferă o scurtă prezentare generală a tehnologiei Site-uri fixate introdusă în Internet Explorer 9. Demonstrează cum să lucrați cu listele de salt, pictogramele suprapuse și butoanele din bara de instrumente pentru miniaturi.
Resursele de mai jos vă vor ajuta să obțineți abilități suplimentare în domeniul dvs. de interes.
