Resumen
SVGOMG: Un frontend responsivo, material y atractivo para SVGO.
¿Qué nos gusta?
SVGOMG, creado por nuestro propio Jake Archibald, es un ejemplo casi perfecto de una herramienta totalmente responsiva y capaz escrita con tecnologías web. Tiene un aspecto atractivo de Material Design. ServiceWorker se asegura de que la app se cargue rápidamente y esté disponible sin conexión, y de que las transiciones sean fluidas en dispositivos móviles.
Posibles mejoras
La única crítica real que tenemos es que la UX inicial es confusa debido a que falta la IU principal. Aparte de eso, ¡buen trabajo!
Preguntas y respuestas con Jake Archibald
¿Por qué la Web?
Pereza. Pereza total. No soy experto en el desarrollo de apps nativas para Windows, ni para OSX, ni para iOS, Android, Windows Phone ni Linux. Sin embargo, puedo trabajar en la Web, y ese conjunto de habilidades me permite crear algo una vez que funcione en todas esas plataformas.
¿Qué funcionó muy bien durante el desarrollo?
Estoy muy contento con su rendimiento. Me aseguro de que la página se renderice antes de que JS esté disponible. De hecho, se renderiza por primera vez con solo 5,000 de HTML con algunos SVG y CSS intercalados. Las secuencias de comandos principales y el CSS se cargan en segundo plano. Esto significa que el sitio parece cargarse en 1.5 s incluso en 3G con una caché vacía, y la mayor parte de eso es DNS y SSL.
La pantalla de apertura es muy simple, por lo que hacerlo en 5K no fue un desafío. Me molesta mucho que tantos sitios esperen a JS para su primera renderización. Algunos incluso requieren que su JS realice más solicitudes antes de la renderización. Esto aumenta el tiempo de renderización de 3G a 10 s. Como usuario de dispositivos móviles, sé que no lo soportaría.
El JS principal es de 15,000, pero no incluye las partes que analizan y reducen el SVG, que se carga como una fase adicional en segundo plano. Es excelente porque la interactividad se carga muy rápido y el usuario no nota la carga adicional. Si el usuario logra seleccionar un SVG antes de que esa secuencia de comandos esté disponible, la carga de esa secuencia de comandos parece ser parte del tiempo de procesamiento.
También usé ServiceWorker para que todo funcione sin conexión. Trabajar sin conexión es una función muy interesante, pero lo hago principalmente por el rendimiento. Las visitas posteriores a SVGOMG se renderizan casi de inmediato, independientemente de la conexión que tenga el usuario. Dado las variaciones en la conectividad móvil, eso es muy valioso.
Si pudieras tener cualquier API para mejorar tu app, ¿cuál sería?
Usé Babel para poder usar elementos futuros de JavaScript. Sería genial que algo de eso funcionara de forma nativa en la plataforma. Específicamente, async/await, funciones de flecha, argumentos predeterminados y desestructuración.
Tuve que usar una biblioteca para comprimir el resultado con gzip y averiguar su tamaño comprimido. Usar una biblioteca para esto es un poco molesto, ya que ese código ya está en el navegador para los elementos HTTP, solo que no tiene una API. Lo ideal sería que fuera algún tipo de transmisión de transformación para que pueda contar el tamaño del resultado sin tener todo en la memoria.