Riepilogo
SVGOMG: un frontend bello, materiale e reattivo per SVGO.
Cosa ci piace?
Creato dallo stesso Jake Archibald, SVGOMG è un esempio perfetto di strumento completamente reattivo e avanzato scritto con tecnologie web. Offre un bellissimo look Material Design, e ServiceWorker assicura che l'app si carichi rapidamente, che sia disponibile offline e che le transizioni siano fluide sui dispositivi mobili.
Possibili miglioramenti
L'unico aspetto interessante che dovremmo offrire è che l'UX iniziale è poco chiara, perché manca l'UI principale. A parte questo, ben fatto!
Domande e risposte con Jake Archibald
Perché il web?
Pigria. Pigria totale. Non sono esperto di sviluppo di app native Windows, non sono esperto di app native OSX, né sono esperto nella creazione di app native per iOS, Android, Windows Phone o Linux. Posso comunque dedicarmi al web e quelle competenze mi permettono di creare qualcosa una volta che ha funzionato su tutte le piattaforme.
Cosa ha funzionato molto bene durante lo sviluppo?
Sono molto soddisfatto del rendimento. Mi assicuro che la pagina venga visualizzata prima che sia disponibile JS. Infatti, effettua il rendering iniziale con solo 5 kB di HTML con alcuni file CSS e SVG incorporati. Gli script principali e i CSS vengono tutti caricati in background. Questo significa che il sito sembra caricarsi in 1, 5 secondi anche su 3G con una cache vuota e la maggior parte dei quali è DNS e SSL.
La schermata iniziale è molto semplice, quindi farlo in 5K non è stata una sfida. Mi infastidisce davvero il fatto che molti siti attendano su JS per il loro primo rendering, alcuni richiedono persino che il codice JS faccia ulteriori richieste prima di eseguire il rendering. In questo modo, il tempo di rendering 3G si avvicina a 10 secondi. Da utente mobile, non me ne sarei occupato.
Il codice JS principale è di 15 kB, ma non include le parti che analizzano e minimizzano il file SVG, che viene caricato come fase aggiuntiva in background. È una funzionalità fantastica perché l'interattività avviene molto rapidamente e l'utente non si accorge del carico aggiuntivo. Se l'utente riesce a selezionare un SVG prima che questo script sia disponibile, il suo caricamento sembra far parte del tempo di elaborazione.
Ho anche utilizzato ServiceWorker per far funzionare il tutto offline. Il lavoro offline è una funzionalità molto interessante, ma lo faccio soprattutto per migliorare le prestazioni. Le visite successive a SVGOMG vengono visualizzate quasi istantaneamente, a prescindere dalla connessione dell'utente. Date le variazioni nella connettività mobile, sono davvero preziosi.
Se potessi avere un'API per migliorare la tua app, quale sarebbe?
Ho usato Babel per poter sfruttare i futuri elementi JavaScript. Sarebbe bello che alcune di queste soluzioni funzionassero in modo nativo sulla piattaforma. Nello specifico: asinc/in attesa, funzioni a freccia, valori predefiniti di argomenti e destrutturazione.
Ho dovuto usare una libreria per comprimere l'output con gzip e scoprirne le dimensioni. L'uso di una libreria è un po' fastidioso perché il codice è già nel browser per i contenuti HTTP, non ha semplicemente un'API. Idealmente, dovrebbe essere una sorta di flusso di trasformazione in modo da poter contare le dimensioni dell'output senza avere l'intero processo in memoria.