Résumé
SVGOMG: un front-end responsif, matériel et élégant pour SVGO.
Ce que nous aimons
Créé par notre propre Jake Archibald, SVGOMG est un exemple presque parfait d'outil entièrement responsif et performant écrit avec des technologies Web. Il présente un superbe look Material Design. ServiceWorker garantit que l'application se charge rapidement et est disponible hors connexion, et que les transitions sont fluides sur mobile.
Améliorations possibles
Le seul vrai point négatif que nous pourrions formuler est que l'expérience utilisateur initiale est déroutante, car l'interface utilisateur principale est manquante. À part ça, bravo !
Questions-réponses avec Jake Archibald
Pourquoi le Web ?
Paresse La paresse totale. Je ne suis pas un expert du développement d'applications natives Windows, ni d'applications natives OSX, ni de la création d'applications natives pour iOS, Android, Windows Phone ou Linux. Je peux toutefois travailler sur le Web, et cet ensemble de compétences me permet de créer une seule fois un élément qui fonctionne sur toutes ces plates-formes.
Qu'est-ce qui a vraiment bien fonctionné pendant le développement ?
Je suis vraiment satisfait de ses performances. Je m'assure que la page s'affiche avant que le code JavaScript ne soit disponible. En fait, le premier rendu ne comporte que 5 ko de code HTML avec du CSS et du SVG intégrés. Les scripts principaux et le CSS sont tous chargés en arrière-plan. Cela signifie que le site semble se charger en 1,5 s, même en 3G avec un cache vide, et la plupart de ce temps est consacré au DNS et au SSL.
L'écran d'ouverture est très simple. Il n'a donc pas été difficile de le réaliser en 5K. Cela me dérange vraiment que tant de sites attendent le premier rendu en JavaScript. Certains exigent même que leur code JavaScript effectue d'autres requêtes avant le rendu. Cela porte le temps de rendu 3G à environ 10 secondes. En tant qu'utilisateur mobile, je sais que je ne supporterais pas cela.
Le code JavaScript principal fait 15 ko, mais n'inclut pas les parties qui analysent et minifient le SVG, qui est chargé en tant que phase supplémentaire en arrière-plan. C'est génial, car l'interactivité s'affiche très rapidement et l'utilisateur ne remarque pas le chargement supplémentaire. Si l'utilisateur parvient à sélectionner un SVG avant que ce script ne soit disponible, le chargement de ce script semble faire partie du temps de traitement.
J'ai également utilisé ServiceWorker pour que l'ensemble fonctionne hors connexion. Le travail hors connexion est une fonctionnalité intéressante, mais je le fais surtout pour des raisons de performances. Les visites ultérieures de SVGOMG s'affichent presque instantanément, quelle que soit la connexion de l'utilisateur. Compte tenu des variations de la connectivité mobile, c'est vraiment utile !
Si vous pouviez choisir une API pour améliorer votre application, laquelle choisiriez-vous ?
J'ai utilisé Babel pour pouvoir utiliser les futures fonctionnalités JavaScript. Il serait idéal que certaines de ces fonctionnalités fonctionnent de manière native sur la plate-forme. Plus précisément, async/await, les fonctions flèche, les valeurs par défaut des arguments et la déstructuration.
J'ai dû utiliser une bibliothèque pour compresser la sortie en gzip afin de connaître sa taille compressée. Utiliser une bibliothèque à cette fin est un peu gênant, car ce code est déjà dans le navigateur pour les éléments HTTP. Il n'y a tout simplement pas d'API. Dans l'idéal, il devrait s'agir d'un flux de transformation afin que je puisse calculer la taille de la sortie sans avoir l'ensemble en mémoire.