Résumé
SVGOMG: interface responsive, magnifique et matérielle pour SVGO.
Ce que nous aimons ?
Conçu par notre propre Jake Archibal, SVGOMG est un exemple presque parfait d'un outil entièrement réactif et performant écrit à l'aide de technologies Web. Elle présente un beau design Material Design, ServiceWorker s'assure que l'application se charge rapidement et est disponible hors connexion, et que les transitions sont fluides sur mobile.
Améliorations possibles
Le seul point important à préciser est que l'expérience utilisateur initiale est déroutante en raison de l'absence de l'UI principale. À part cela, bien joué !
Questions-réponses avec Jake Archibald
Pourquoi le Web ?
paresse. Paresse totale. Je ne suis pas un expert en développement d'applications natives Windows, je ne suis ni un expert en applications natives OSX, ni un expert en création d'applications natives pour iOS, Android, Windows Phone ou Linux. Je peux toutefois faire le Web, et cet ensemble de compétences me permet de créer quelque chose une fois qui fonctionne sur toutes ces plates-formes.
Qu'est-ce qui a vraiment bien fonctionné pendant le développement ?
Je suis vraiment satisfait des performances. je m'assure que la page s'affiche avant que JS ne soit disponible. En fait, il s'affiche d'abord avec seulement 5 Ko de HTML, avec du CSS et du SVG intégrés. Les principaux scripts et 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 (le plus gros étant DNS et SSL).
L'écran d'ouverture est très simple, donc faire cela en 5K n'a pas été un défi. Cela me dérange vraiment que de nombreux sites attendent leur premier rendu sur JavaScript, et certains exigent même que ce dernier envoie d'autres requêtes avant l'affichage. Le délai d'affichage 3G est donc de 10 secondes, ce qui n'est pas le cas en tant qu'utilisateur mobile.
Le JS principal est de 15 Ko, mais n'inclut pas les parties qui analysent et minimisent le SVG, qui est chargé en tant que phase supplémentaire en arrière-plan. C'est génial, car l'interactivité arrive très rapidement et l'utilisateur ne remarque pas la charge 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 aussi utilisé ServiceWorker pour faire fonctionner l'ensemble hors connexion. Travailler hors connexion est une fonctionnalité intéressante, mais je m'en occupe principalement pour améliorer les performances. Les visites suivantes sur SVGOMG s'affichent presque instantanément, quelle que soit la connexion dont dispose l'utilisateur. Compte tenu des variations de connectivité mobile, c'est très intéressant !
Si vous pouviez avoir une API pour améliorer votre application, quelle serait-elle ?
J'ai utilisé Babel pour pouvoir utiliser les futures fonctionnalités JavaScript. L'idéal serait qu'une partie de cela fonctionne de manière native sur la plate-forme. Plus précisément, async/await, les fonctions fléchées, les valeurs par défaut des arguments et la déstructuration.
J'ai dû utiliser une bibliothèque pour compresser les résultats avec gzip, afin de connaître leur taille au format gzip. Utiliser une bibliothèque pour cela est un peu ennuyeux, car ce code est déjà dans le navigateur pour les éléments HTTP, il n'y a tout simplement pas d'API. Idéalement, il doit s'agir d'une sorte de flux de transformation pour que je puisse compter la taille de la sortie sans avoir l'intégralité en mémoire.