Da molto tempo mi occupo dello sviluppo di applicazioni web. Molto tempo. 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 ristretta e un'interfaccia non così terribilmente sovraccarica come quella di Yahoo!
Lo sviluppo di applicazioni, di qualsiasi applicazione, non solo per il web, è un lavoro creativo. È improbabile che qualcuno possa contestare questa affermazione. E la bellezza nella creatività è come la pratica nella conoscenza scientifica: un criterio di verità. Ma se la pratica scientifica è obiettiva e si basa su misurazioni, la bellezza è un oggetto soggettivo, dipende da chi guarda. Quindi mi sono posto la domanda: cosa rappresenta per me un'applicazione web bella?
(sul KDPV il mio occhio non è mio, è femminile, ma, IMHO, l'occhio femminile su KDPV è più pertinente di quello maschile, dato che questo è il) !)
Sotto ho elencato i miei criteri personali di cosa rende attualmente un'applicazione web bella. Una visione molto soggettiva, influenzata dalla mia esperienza personale. Potrebbe sembrare a qualcuno che i miei criteri di bellezza siano criteri di bruttezza. Non sorprendetevi, semplicemente avete un'esperienza diversa.
E dato che siete scesi sotto, vi prego di fare attenzione nei commenti. Infatti, se potete interrompere la lettura dell'articolo non appena ciò che è esposto vi sembra brutto o addirittura orrendo, io, in qualità di autore, sono costretto a leggere tutti i commenti.
Ambiente di vita
Protocolli
Non so nemmeno se valga la pena estrapolare questo criterio. Le applicazioni web vivono in rete e devono conformarsi alle Leggi della Rete (protocollo). I protocolli principali della rete sono e . Su di essi si basano molti altri protocolli, ma per le applicazioni web considero il più importante (meglio, la sua estensione basato su ). Cioè, un'applicazione web bella è accessibile tramite HTTPS/TLS (come alternativa — tramite HTTP), mentre gli altri protocolli (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, …) la rendono meno bella con ogni protocollo aggiuntivo supportato. L'applicazione stessa può utilizzare risorse esterne grazie a questi protocolli aggiuntivi.
Per quanto riguarda , quindi non ho esperienza sufficiente nell'uso di questo protocollo con le applicazioni web. Sembra bello e promettente, ma non posso dire quanto sia stabile e pratico.
Browser
L'applicazione web poggia su un piede sul lato server e sull'altro piede sul lato client. Il lato client è il browser. Un moderno browser offre , che un'applicazione web moderna può e deve utilizzare a proprio favore. Una bella applicazione web sfrutta le moderne capacità dei browser e non deve necessariamente funzionare nei browser che non offrono queste possibilità moderne. Capisco che siano una misura forzata, ma è poco elegante. Alla fine, non solo gli sviluppatori devono stare al passo con le tecnologie moderne, ma anche gli utenti e le aziende.
Linguaggi di programmazione
Con i linguaggi di programmazione utilizzati per creare applicazioni web, la situazione è molto confusa. Per la parte client delle applicazioni web ci sono molte tecnologie che permettono agli sviluppatori di semplificare la creazione della triade HTML/CSS/JS (quello che tutti i moderni browser capiscono). Ma io, a suo tempo, ho avuto un forte contatto con e considero bello quando uno sviluppatore vede nel browser il codice originale e non il risultato di una compilazione o transpilation. Pertanto, l'uso di e di prodotti simili per generare codice client è, IMHO, poco elegante. Più il codice eseguibile nel browser somiglia al codice sorgente creato dallo sviluppatore, meglio è. Non ci credete? Provate a fare debug in produzione del codice creato da GWT.
Dall'altra parte del server c'è più libertà (Java, PHP, Perl, Python, C#, Ruby, ...), ma mi sembra bello quando sia sul lato server che nel browser viene utilizzato lo stesso linguaggio di programmazione: JavaScript. Dopotutto, , e le squadre di persone affini sono più produttive.
Umanità
Una bella applicazione web deve essere utile. Utile, prima di tutto, per l'uomo come utente finale. Pertanto, non posso considerare una bella applicazione web . Alla persona comune (non sviluppatore web) è difficile avere a che fare con loro. I servizi web sono belli a modo loro,
Una bella applicazione web deve avere un'interfaccia intuitiva. Si può discutere su che è una cosa piuttosto soggettiva. Ma con è tutto molto più semplice, se l'utente non può utilizzare l'app senza il talismano — una cattiva esperienza utente, un'app web brutta. Le app web più belle relativamente a questo criterio possono essere facilmente utilizzate da bambini che non sanno ancora leggere.
Scalabilità inversa
Molto tempo fa i programmi potevano essere trasferiti su floppy disk, ora — su chiavette USB o scaricati direttamente da Internet. Copiare un'applicazione normale e farla funzionare su un altro computer è un compito banale. La situazione con le applicazioni web è un po' diversa. La rete rappresenta un ambiente globale, in cui non è necessario avere cloni della stessa applicazione web. Su Internet basta un solo Facebook, Twitter, Instagram, Mail.ru o Yandex. È possibile avere diverse applicazioni web nella stessa nicchia tematica, ma con pubblici diversi (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 ho idea di come siano organizzate all'interno. Per garantire il funzionamento di tali applicazioni web sono necessari team di specialisti appropriati e data center dedicati. Mi sorprende la capacità delle persone di cooperare su tali scale e di creare prodotti simili, ma il mio standard di bellezza è un'app web che può essere lanciata su un singolo laptop.
Una bella applicazione web si scala non solo verso l'alto e verso l'esterno (per gli utenti), ma anche verso il basso e verso l'interno (per gli sviluppatori).
«Anfibi»
Per accedere alle moderne applicazioni web si utilizzano dispositivi di due tipi:
- computer (laptop, desktop);
- dispositivi mobili (smartphone e tablet);
Da qualche parte all'orizzonte si intravede anche «», ma per ora è così.
I computer si differenziano dai dispositivi mobili tanto quanto gli esseri terrestri si differenziano dagli animali acquatici. Sono ambienti diversi e pongono requisiti diversi agli esseri che vi abitano (programmi). Le belle applicazioni web non sono quelle che somigliano a , ma quelle che in acqua — come i pesci, sulla terra — come gli animali, e nell'aria () — come gli uccelli.
Non considero bella ««, è come cercare di sedersi su due (con SEO — tre) sgabelli. Meglio essere come Fiona di Shrek — sola di giorno, ma diversa di notte. Sì, costa di più. Ma è meglio.
Cross-sharing
Ho già sottolineato nel punto «Scalabilità Inversa» che la globalità della Rete offre la possibilità di avere un'unica web-app per il pianeta. Pertanto, ogni web-app deve differenziarsi in qualche modo dalle altre per garantire la propria sopravvivenza. Tuttavia, la mia esperienza pluriennale con (struttura per la creazione di negozi e-commerce) dimostra che ci può essere più comunanza tra le singole web-app rispetto alle differenze. Una web-app ben progettata non solo deve essere modulare, ma deve anche condividere i propri moduli con altre web-app. In qualche modo, questa idea è riflessa in JSR 168 e JSR 286 e in framework come , e la stessa Magento. Maggiore è il numero di moduli della web-app utilizzati da altre web-app, più bella è, dal mio punto di vista. Il cross-sharing consente di creare moduli di qualità superiore e, di conseguenza, web-app più stabili.
Con modulo non intendo librerie come jQuery o RequireJS — piuttosto entità più grandi, come i plugin in e . Ma anche per le librerie è valido il principio che una distribuzione ampia della libreria la rende più qualitativa e resistente.
Architettura di Harvard
, a differenza dell'attuale predominio di , implica la separazione di codice e dati. L'architettura non ha avuto successo, ma l'idea stessa mi sembra bella. Soprattutto per le web-app. Qualsiasi risorsa statica (HTML/CSS/JS/Immagini/…) è codice. Deve e può essere memorizzato in cache sia sul lato server che sul lato client. E i dati sono / (bello) o / (un po' meno bello). Oppure WebSockets/JSON (potrebbe essere la scelta migliore, ma non l'ho mai provato).
Localizzazione
Ci sono due cose che mi preoccupano particolarmente durante lo sviluppo di web-app: l'interfaccia multilingue e i fusi orari. Vengo dalla Lettonia, dove sono in uso tre lingue: LV, RU, EN. Una web-app bella deve permettere non solo l'uso di più lingue all'interno dell'app stessa, ma anche consentire di ampliare il numero di lingue utilizzate tramite risorse esterne, come . Questo vale anche per i moduli da cui è composta la web-app.
Per quanto riguarda i fusi orari, è semplice: ogni volta che non è chiaro come gestire la data e l'ora, seguite questa regola: tutto ciò che è sul server viene inviato e ricevuto dal server in UTC, mentre tutto ciò che viene visualizzato sul client segue il fuso orario del profilo utente. È elegante.
Fucine invece di «Stelle della Morte»
Tanto tempo fa, in ogni cittadina più o meno grande c'era una propria fucina. Forse anche più di una. Alcune migliori, altre peggiori. C'erano fabbri celebri in tutto il mondo, e altri verso cui ci si rifugiava per mancanza di alternative. Guerre, epidemic, disastri naturali imperversavano. Alcune cittadine scomparivano insieme alla loro popolazione. Ma l'arte della lavorazione dei metalli continuava a esistere. Al posto delle città scomparse venivano costruite nuove fucine.
E ora guardate un servizio come . Quando i server radice si fermano, .
A mio avviso, un'app web bella non può avere le stesse dimensioni di Facebook o Mail.ru. Questo si avvicina di più a «» sia per le risorse necessarie alla costruzione che per quelle necessarie al mantenimento. Sì, in caso di distruzione di Facebook, l'umanità non scomparirà, le sue funzioni verranno rapidamente assunte da altre applicazioni (come sul territorio della Federazione Russa e limitrofi, Instagram, Twitter, ...). Tuttavia, concentrare una parte significativa della popolazione del Pianeta su un'unica applicazione è poco elegante. Soprattutto considerando che ci sono alternative molto più robuste (per esempio, ).
Riepilogo
Se sei arrivato alla fine e ti senti confuso — «che cos'era?», ti porgo le mie più sincere condoglianze. Non ti ho costretto a leggere. Ho semplicemente cercato di esprimere i miei pensieri a parole, per trovare coloro che la pensano come me. Forse riuscirò a discutere con loro alcuni aspetti della creazione di applicazioni web belle e scoprire le risposte alle mie domande. E ne ho molte.
Grazie per aver letto.
Fonte: habr.com
