De mult timp mă ocup cu dezvoltarea de aplicații web. Foarte mult timp. Primele mele aplicații web le-am creat în mediul în vremurile când cuvântul „google” nu devenise încă verb, iar oamenii căutau informații pe internet folosind Yahoo! și Rambler. Eu foloseam — aveau o căutare restrânsă și o interfață mai puțin aglomerată decât Yahoo!
Dezvoltarea aplicațiilor, oricăror aplicații, nu doar pentru web, este o muncă creativă. Cu siguranță, nimeni nu va contesta această afirmație. Iar frumusețea în creație este ca practica în cunoașterea științifică — un criteriu al adevărului. Dar dacă practica științifică este obiectivă și se bazează pe măsurători, atunci frumusețea este un subiect subiectiv, depinzând de ochiul privitorului. Așa că m-am întrebat, ce înseamnă pentru mine personal o aplicație web frumoasă?
(la KDPV, ochiul nu e al meu, e al unei femei, dar, IMHO, ochiul feminin la KDPV este mai adecvat decât cel masculin, pentru că este — !)
Sub catastrofă se regăsesc criteriile mele despre ce aplicație web poate fi considerată frumoasă în prezent. O expunere foarte subiectivă, determinată de experiența mea personală. Poate că pentru unii criteriile mele de frumusețe vor părea criterii de urâciune. Nu vă mirați, doar aveți o experiență diferită.
Și, de vreme ce ați intrat sub catastrofă, vă rog să fiți mai atenți în comentarii. Fiindcă, dacă voi puteți opri citirea articolului de îndată ce ceea ce este prezentat vi se pare urât sau chiar inestetic, eu, ca autor, trebuie să citesc toate comentariile.
Mediul de Habitat
Protocole
Nu știu dacă merită să scot acest criteriu separat. Aplicațiile web trăiesc în Rețea și sunt obligate să respecte Legile Rețelei (protocolele). Principalele protocoale din Rețea sunt și . Pe ele se bazează multe alte protocoale, dar pentru aplicațiile web consider cel mai important (sau mai bine zis, extensia sa bazat pe ). Adică, o aplicație web frumoasă este disponibilă prin HTTPS/TLS (sau, ca alternativă, prin HTTP), iar celelalte protocoale (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, …) o fac mai puțin frumoasă cu fiecare protocol suplimentar suportat. Aplicația însă poate folosi aceste protocoale suplimentare pentru a accesa resurse externe.
În ceea ce privește , dar nu am destulă experiență în utilizarea acestui protocol cu aplicațiile web. Arată frumos și promițător, dar cât de stabil și practic este — nu pot spune.
Butoane
Aplicația web stă cu un picior pe partea serverului și cu celălalt pe partea clientului. Partea clientului este browserul. Un browser modern oferă , ceea ce o aplicație web modernă poate și ar trebui să folosească în avantajul său. O aplicație web frumoasă utilizează capacitățile moderne ale browserelor și nu trebuie să funcționeze în acele browsere care nu oferă aceste posibilități moderne. Înțeleg că sunt o măsură forțată, dar nu este estetic. La urma urmei, nu doar dezvoltatorii trebuie să țină pasul cu tehnologiile moderne, ci și utilizatorii și afacerile.
Limbaje de programare
Cu limbajele de programare utilizate pentru crearea aplicațiilor web, totul este foarte complicat. Pentru partea clientului a aplicațiilor web există o mulțime de tehnologii care permit dezvoltatorului să faciliteze crearea triadei HTML/CSS/JS (ceea ce toate browserele moderne înțeleg). Dar eu, la vremea mea, am avut de-a face strâns cu și consider că este frumos ca dezvoltatorul să vadă în browser codul original, nu rezultatul compilării sau transpilerii. De aceea, folosirea și a produselor similare pentru generarea codului client este, în opinia mea, neestetic. Cu cât mai mult codul executabil în browser seamănă cu codul sursă creat de dezvoltator, cu atât este mai bine. Nu credeți? Încercați să debugați în production codul generat de GWT.
Pe partea serverului există mai multă libertate (Java, PHP, Perl, Python, C#, Ruby, ...), dar mi se pare frumos ca atât pe partea serverului, cât și în browser să fie folosit același limbaj de programare — JavaScript. Până la urmă, , iar echipele de neînțeleși sunt mai productive.
Umanitate
O aplicație web frumoasă trebuie să fie utilă. Utilă, în primul rând, pentru om, ca utilizator final. De aceea nu pot numi o aplicație web frumoasă . Oamenilor obișnuiți (nu dezvoltatorilor web) le este greu cu acestea. Serviciile web sunt frumoase în felul lor,
O aplicație web frumoasă trebuie să aibă o interfață intuitivă. Se poate discuta despre frumos — este un lucru destul de subiectiv. Dar cu totul este mult mai simplu, dacă utilizatorul nu poate folosi aplicația fără dorința sa. — UX slab, aplicație web inestetică. Cele mai frumoase aplicații web, în raport cu acest criteriu, pot fi utilizate cu ușurință de copii care încă nu știu să citească.
Scalabilitate Inversă
Cu mult timp în urmă, programele puteau fi transferate pe dischete, acum — pe stick-uri USB sau direct descărcate din rețea. Copierea unei aplicații obișnuite și rularea ei pe o altă mașină este o sarcină trivială. Situația cu aplicațiile web este oarecum specială. Rețeaua reprezintă un mediu global în care nu este nevoie de clone ale aceeași aplicații web. În rețea există deja un singur Facebook, Twitter, Instagram, Mail.ru sau Yandex. Se pot avea diferite aplicații web în aceeași nișă tematică, dar cu audiențe diferite (ca Facebook și Vkontakte, Mail.ru și Gmail, Google Maps și Azure Maps). Resursele de calcul necesare pentru a asigura disponibilitatea globală a acestor aplicații web sunt, să spunem, .
Nu am lucrat niciodată cu aplicații web de acest nivel ca dezvoltator și nu îmi dau seama cum sunt structurate, în interior. Pentru a asigura funcționalitatea acestor aplicații web sunt necesare echipe de specialiști corespunzători și centre de date separate. Mă impresionează capacitatea oamenilor de a colabora la o astfel de scară și de a crea astfel de produse, dar etalonul meu de frumusețe este o aplicație web care poate fi rulată pe un laptop separat.
O aplicație web frumoasă se scalează nu doar în sus și în lățime (pentru utilizatori), ci și în jos și în interior (pentru dezvoltatori).
„Amfibiență”
Pentru accesarea aplicațiilor web moderne se folosesc dispozitive de două tipuri:
- computere (laptopuri, desktopuri);
- dispozitive mobile (smartphone-uri și tablete);
Pe orizont, mai apare și „“, dar deocamdată atât.
Computerele diferă de dispozitivele mobile atât de mult cum se diferențiază creaturile de uscat de cele acvatice. Acestea sunt medii diferite și ele impun cerințe diferite asupra ființelor care trăiesc în ele (programelor). Aplicațiile web frumoase nu sunt cele care seamănă cu , ci cele care în apă — ca peștii, pe uscat — ca animalele, iar în aer () — ca păsările.
Consider „“ inestetic, este ca și cum ai încerca să stai pe două (cu SEO — trei) scaune. Mai bine ca Fiona din Shrek — ziua una, iar noaptea alta. Da, mai scump. Dar mai bine.
Cross-sharing
Am menționat deja în secțiunea „Scalabilitate Inversă” că globalitatea rețelei permite să existe o singură aplicație web pe planetă. Prin urmare, fiecare aplicație web trebuie să se deosebească prin ceva de celelalte, pentru a-și asigura supraviețuirea. Totuși, experiența mea de lungă durată cu (cadru pentru construirea magazinelor e-commerce) spune că între aplicațiile web individuale poate exista mai mult comun decât diferențe. O aplicație web frumoasă nu doar că trebuie să fie modulară, ci trebuie, de asemenea, să își împărtășească modulele cu alte aplicații web. Într-o anumită măsură, această idee este reflectată în JSR 168 și JSR 286 și în framework-uri precum , și aceeași Magento. Cu cât mai multe module ale aplicației web sunt utilizate de alte aplicații web, cu atât este mai frumoasă din perspectiva mea. Partajarea încrucișată permite crearea de module de calitate superioară și, ca urmare, aplicații web mai stabile.
Prin modul nu mă refer la biblioteci de tip jQuery sau RequireJS — ci mai degrabă la entități mai mari, de tipul pluginurilor în și . Dar și pentru biblioteci este valabilă afirmația că o distribuție largă a unei biblioteci o face mai calitativă și mai stabilă.
Arhitectura Harvard
, spre deosebire de bal , presupune separarea codului de date. Arhitectura nu a avut succes, dar ideea în sine mi se pare frumoasă. În special pentru aplicațiile web. Orice statica (HTML/CSS/JS/Imagini/…) este cod. Acesta poate și trebuie să fie cached atât pe partea serverului, cât și pe partea clientului. Iar datele sunt / (frumos) sau / (puțin mai puțin frumos). Sau WebSockets/JSON (poate fi cea mai bună opțiune, dar nu am încercat).
Localizare
Există două lucruri care mă preocupă în mod special atunci când dezvolt aplicații web — este vorba despre interfața multilingvă și fusurile orare. Eu provin din Letonia, unde se vorbesc trei limbi: LV, RU, EN. O aplicație web frumoasă ar trebui să permită utilizarea mai multor limbi în aplicație, dar și să permită extinderea numărului de limbi utilizate prin resurse externe, precum . Aceasta este, de asemenea, valabilă pentru modulele din care este construită aplicația web.
Cu privire la fusurile orare, totul este simplu: în toate cazurile în care nu este clar cum să gestionăm data-timpul, faceți astfel: tot ce se află pe server, pleacă de pe server și vine de pe server - UTC, tot ce se afișează pe client - în conformitate cu fusul orar din profilul utilizatorului. Este frumos.
Fierăria în loc de „Stelele Morții”
Cu mult timp în urmă, în fiecare oraș mai mare sau mai mic, exista o fierărie. Poate chiar mai multe. Unele erau mai bune, altele nu. Existau meșteșugari fierari cunoscuți pe tot globul, iar unii erau căutați din lipsă de alternative. Au trecut războaie, epidemii, dezastre naturale. Unele orașe dispăreau împreună cu populația. Dar meșteșugul fierariei a continuat să trăiască. În locul orașelor dispărute, s-au ridicat altele noi, unde au apărut de asemenea fierării.
Acum, priviți un astfel de serviciu, cum ar fi . Când serverele rădăcină pică, .
Din punctul meu de vedere, o aplicație web frumoasă nu poate avea dimensiunea lui Facebook sau Mail.ru. Acesta este mai aproape de „” atât în ceea ce privește resursele necesare pentru construcție, cât și în ceea ce privește resursele necesare pentru menținerea funcționalității. Da, în cazul distrugerii Facebook-ului, umanitatea nu va dispărea, funcțiile sale vor fi preluate rapid de alte aplicații (aceeași pe teritoriu, Instagram, Twitter, ...). Cu toate acestea, închiderea unei părți semnificative a populației Globului într-o singură aplicație - nu este frumos. Cu atât mai mult, având alternative mult mai rezistente (de exemplu, ).
Rezumat
Dacă ați citit până la final și vă simțiți confuz - „ce a fost asta?“, atunci vă exprim sincerele mele condoleanțe. Nu v-am spus să citiți asta. Pur și simplu am încercat să-mi exprim gândurile în cuvinte, pentru a găsi pe cei care gândesc la fel. Poate voi putea discuta cu ei câteva aspecte legate de crearea de aplicații web frumoase și voi afla răspunsuri la întrebările mele. Iar întrebările mele sunt multe.
Vă mulțumesc pentru lectură.
Sursa: habr.com
