Da molto tempo mi occupo dello sviluppo di applicazioni web. Molto tempo fa. Le mie prime applicazioni web nell'ambiente le creai in un'epoca in cui la parola «google» non era ancora un verbo, e per cercare informazioni su internet le persone usavano Yahoo! e Rambler. Io utilizzavo — avevano una ricerca mirata e un'interfaccia non così congestionata come quella di Yahoo!
Lo sviluppo di applicazioni, di qualsiasi applicazione, non solo per il web, è un lavoro creativo. Raramente qualcuno potrà discutere questa affermazione. E la bellezza nella creatività è come la pratica nella conoscenza scientifica: un criterio di verità. Ma mentre la pratica scientifica è oggettiva e si basa su misurazioni, la bellezza è un oggetto soggettivo, dipende da chi guarda. Così ho iniziato a pormi la domanda: cosa considero personalmente un'applicazione web bella?
(su KDPV il mio occhio non è il mio, è femminile, ma, IMHO, l'occhio femminile su KDPV è più appropriato di quello maschile, dato che questo è — !)
Sotto il taglio ci sono i miei criteri personali su cosa può essere considerata un'app web bella al momento. Una descrizione molto soggettiva, influenzata dalla mia esperienza personale. Forse i miei criteri di bellezza possono sembrare criteri di bruttezza a qualcuno. Non sorprendetevi, semplicemente avete esperienze diverse.
E dato che siete qui, vi chiedo di essere cauti nei commenti, per favore. Infatti, se potete smettere di leggere l'articolo appena ciò che contiene vi sembra brutto o addirittura orripilante, io, in quanto autore, mi vedo costretto a leggere tutti i commenti.
Habitat
Protocolli
Non so nemmeno se valga la pena menzionare questo criterio separatamente. Le applicazioni web vivono in rete e devono conformarsi alle leggi della rete (ai protocolli). I principali protocolli nella rete sono e . Su di essi si basano numerosi altri protocolli, ma per le applicazioni web considero più importante (ovvero, la sua estensione basata su ). Quindi, una bella applicazione web è accessibile tramite HTTPS/TLS (o HTTP come alternativa), mentre gli altri protocolli (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, …) la rendono meno attraente con ogni protocollo in più supportato. L'applicazione stessa può, grazie a questi protocolli aggiuntivi, accedere a risorse esterne.
Per quanto riguarda , non ho abbastanza esperienza nell'uso di questo protocollo con le applicazioni web. Sembra accattivante e promettente, ma quanto sia stabile e pratico non posso dirlo.
Browser
L'applicazione web poggia solo parzialmente sul lato server, mentre l'altra parte sta sul lato client. Il lato client è il browser. I moderni browser offrono , che una moderna applicazione web può e deve utilizzare a suo favore. Una bella applicazione web sfrutta le moderne capacità dei browser e non è tenuta a funzionare nei browser che non forniscono tali capacità. Comprendo che sono una misura necessaria, ma non sono eleganti. In fin dei conti, non solo gli sviluppatori devono tenere il passo con le tecnologie moderne, ma anche gli utenti e le aziende.
Linguaggio di programmazione
Con i linguaggi di programmazione utilizzati per creare applicazioni web, la situazione è piuttosto confusa. Per la parte client delle web app ci sono molte tecnologie che consentono agli sviluppatori di semplificare la creazione della triade HTML/CSS/JS (quello che tutti i moderni browser comprendono). Tuttavia, io stesso ho avuto un forte legame con e trovo bello quando uno sviluppatore può vedere nel browser il codice originale, invece del risultato di una compilazione o transpilation. Pertanto, l'uso di e prodotti simili per generare codice client, a mio avviso, non è esteticamente piacevole. Più il codice eseguibile nel browser assomiglia al codice sorgente scritto dallo sviluppatore, meglio è. Non ci credete? Provate a debuggare in produzione il codice generato da GWT.
Per quanto riguarda il lato server, c'è maggiore libertà (Java, PHP, Perl, Python, C#, Ruby, ...), ma penso che sia bello quando si utilizza lo stesso linguaggio di programmazione, ovvero JavaScript, sia nel backend che nel browser. Dopotutto, , e i team di persone affini sono più produttivi.
Umanità
Una bella web app deve essere utile. Innanzitutto, per l'essere umano, come consumatore finale. Quindi, non posso definire un'app web bella. . Per una persona comune (non un web developer) sono complicati. I servizi web possiedono una loro bellezza,
Una bella web app deve avere un'interfaccia intuitiva. Si può discutere su questo — è una questione piuttosto soggettiva. Ma con è tutto molto più semplice: se l'utente non può utilizzare l'app senza il suo prezioso — cattiva UX, app web poco attraente. Le web app più belle, rispetto a questo criterio, possono essere facilmente utilizzate da bambini che non sanno ancora leggere.
Scalabilità Inversa
Un tempo, i programmi venivano trasferiti su dischetti, ora si usano le chiavette USB o si possono scaricare direttamente dalla rete. Copiare un'applicazione tradizionale e avviarla su un altro computer è un compito banale. La situazione con le applicazioni web è un po' diversa. La rete rappresenta un ambiente globale, dove non c'è bisogno di avere cloni della stessa applicazione web. Basta un Facebook, un Twitter, un Instagram, un Mail.ru o un Yandex. Possono esserci diverse applicazioni web nella stessa nicchia tematica, ma con pubblici differenti (come Facebook e Vkontakte, Mail.ru e Gmail, Google Maps e Azure Maps). Le risorse hardware necessarie per garantire la disponibilità globale di tali applicazioni web sono, per così dire, .
Non ho mai lavorato con applicazioni web di questo livello come sviluppatore e non posso nemmeno immaginare come siano strutturate internamente. Per garantire il funzionamento di tali applicazioni web sono necessarie squadre di specialisti e centri dati separati. Rimango affascinato dalla capacità delle persone di cooperare su tali scale e di creare prodotti simili, ma il mio ideale di bellezza è un'applicazione web che si può far funzionare su un singolo laptop.
Una bella applicazione web si scala non solo verso l'alto e in larghezza (per gli utenti), ma anche verso il basso e all'interno (per gli sviluppatori).
«Anfibi»
Per accedere alle moderne applicazioni web si utilizzano dispositivi di due tipi:
- computer (portatili, desktop);
- dispositivi mobili (smartphone e tablet);
Da qualche parte all'orizzonte si profila ancora «», ma per ora rimane così.
I computer si differenziano dai dispositivi mobili tanto quanto le creature terrestri si differenziano da quelle acquatiche. Sono ambienti diversi che pongono requisiti diversi alle forme di vita che li abitano (programmi). Le belle applicazioni web non sono quelle che assomigliano a , ma quelle che in acqua sono come pesci, sulla terra sono come bestie e nell'aria () — come uccelli.
Considero poco attraente «», è come cercare di sedere su due (con SEO — tre) sedie. Meglio come Fiona di Shrek — di giorno una, di notte un'altra. Sì, costa di più. Ma è meglio.
Cross-sharing
Ho già menzionato nel punto "Scalabilità Orizzontale" che la globalità della rete consente di avere una sola applicazione web per il pianeta. Pertanto, ogni applicazione web deve differenziarsi in qualche modo dalle altre per garantire la propria sopravvivenza. Tuttavia, la mia lunga esperienza con (framework per la creazione di negozi e-commerce) suggerisce che tra le singole applicazioni web ci può essere più in comune che differenze. Una bella applicazione web non solo deve essere modulare, ma deve anche condividere i propri moduli con altre applicazioni web. In qualche modo, questa idea è riflessa nelle JSR 168 e JSR 286 e in framework come , e la stessa Magento. Più un numero di moduli di un'applicazione web è utilizzato da altre applicazioni web, più è bella dal mio punto di vista. La condivisione incrociata consente di creare moduli di maggiore qualità e, di conseguenza, applicazioni web più stabili.
Con modulo non intendo biblioteche come jQuery o RequireJS, ma piuttosto entità più grandi, come i plugin in e . Ma anche per le biblioteche vale la tesi che una diffusione ampia della biblioteca consente di renderla più qualitativa e robusta.
Architettura di Harvard
, a differenza dell'attuale balletto , implica la separazione del codice e dei dati. L'architettura non ha decollato, ma l'idea stessa mi sembra bella. Soprattutto per le applicazioni web. Qualsiasi statico (HTML/CSS/JS/Immagini/…) è codice. Può e deve essere memorizzato nella cache sia lato server che lato client. E i dati sono / (elegante) o / (un po' meno elegante). O WebSockets/JSON (potrebbe essere la soluzione migliore, ma non l'ho provata).
Localizzazione
Ci sono due cose che mi preoccupano particolarmente nello sviluppo di applicazioni web: l'interfaccia multilingue e i fusi orari. Io provengo dalla Lettonia, dove usiamo tre lingue: LV, RU, EN. Una bella applicazione web dovrebbe non solo consentire l'uso di più lingue all'interno dell'applicazione stessa, ma anche permettere di ampliare il numero di lingue utilizzate tramite risorse esterne, come . Questo vale anche per i moduli da cui viene costruita l'applicazione web.
Con i fusi orari è semplice: in ogni caso in cui non è chiaro come gestire data e ora, procedete così: tutto ciò che è sul server, parte dal server e arriva dal server — UTC; tutto ciò che è visualizzato sul client — secondo il fuso orario nel profilo utente. È elegante.
Fucine invece di «Stelle della Morte»
In un tempo lontano, in ogni città di una certa importanza c'era la sua fucina. Forse anche più di una. Alcune erano migliori, altre peggiori. C'erano fabbri noti in tutto il mondo, e altri ai quali si andava solo per mancanza di alternative. Guerre, epidemie, disastri naturali si susseguivano. Alcuni paesini scomparivano insieme alla loro popolazione. Ma l'arte della fabbricazione continuava a vivere. Nuove città venivano costruite al posto di quelle scomparse, e anche in esse nascevano fucine.
E ora date un'occhiata a un servizio come . Quando i server root cedono, .
Secondo me, una bella web app non può essere delle dimensioni di Facebook o Mail.ru. Siamo più vicini alle «» sia per le risorse necessarie alla creazione, sia per le risorse necessarie a mantenere la funzionalità. Sì, anche se Facebook venisse distrutto, l'umanità non scomparirebbe, le sue funzioni verrebbero rapidamente riprese da altre applicazioni (come ad esempio sul territorio della Federazione Russa e nelle zone limitrofe, Instagram, Twitter, ...). Tuttavia, concentrare una parte significativa della popolazione mondiale su un'unica applicazione è poco elegante. Tanto più, considerando che ci sono alternative molto più solide (ad esempio, ).
Riepilogo
Se hai letto fino alla fine e ti senti confuso — «che cos'era?«, ti esprimo le mie sincere condoglianze. Non ti ho obbligato a leggere. Ho semplicemente cercato di esprimere i miei pensieri in parole, per trovare chi la pensa allo stesso modo. Forse, potrò discutere con loro alcuni aspetti della creazione di belle applicazioni web e scoprire le risposte alle mie domande. E ce ne sono molte.
Grazie per aver letto.
Fonte: habr.com
