SVGOMG

Captura de pantalla de Svgomg

Resumen

SVGOMG: Un frontend atractivo, responsivo y de Material para SVGO.

¿Qué nos gusta?

Creado por nuestro propio Jake Archibald, SVGOMG es un ejemplo casi perfecto de una herramienta completamente responsiva y capaz escrita con tecnologías web. Tiene un hermoso aspecto de Material Design, ServiceWorker garantiza que la app se cargue rápidamente y esté disponible sin conexión, y que las transiciones se realicen sin problemas en dispositivos móviles.

Posibles mejoras

El único punto débil que tendríamos para ofrecer es que la UX inicial es confusa debido a que falta la IU principal. Además 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 de Windows, no soy experto en aplicaciones nativas de OSX ni tampoco en la creación de aplicaciones nativas para iOS, Android, Windows Phone o Linux. Sin embargo, puedo crear en la Web y ese conjunto de habilidades me permite crear algo una vez que funcionó en todas esas plataformas.

¿Qué funcionó muy bien durante el desarrollo?

Estoy muy contento con el rendimiento. Me aseguro de que la página se renderice antes de que JS esté disponible. De hecho, primero se renderiza con solo 5,000 HTML, con algunos CSS y SVG intercalados. Las secuencias de comandos principales y 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 es DNS y SSL.

La pantalla de apertura es muy simple, por lo que hacer eso en 5K no fue un desafío. Me molesta mucho que tantos sitios esperen en JS su primera renderización, algunos incluso requieren que su JS realice más solicitudes antes de renderizarlos. Esto lleva el tiempo de renderización de 3G a 10 s. Como usuario de dispositivos móviles, sé que no toleraría eso.

El JS principal es 15,000, pero no incluye las partes que analizan y reducen el SVG, que se carga como una fase adicional en segundo plano. Es genial porque la interactividad llega muy rápido y el usuario no percibe la carga adicional. Si el usuario logra seleccionar un SVG antes de que esa secuencia de comandos esté disponible, la carga de esa secuencia parece ser parte del tiempo de procesamiento.

También usé ServiceWorker para que todo funcionara sin conexión. Trabajar sin conexión es una función genial, pero lo hago principalmente para mejorar el rendimiento. Las visitas posteriores a SVGOMG se renderizan casi al instante, sin importar la conexión que tenga el usuario. Dadas las variaciones en la conectividad móvil, eso es realmente valioso.

Si pudieras tener una API para mejorar tu app, ¿cuál sería?

Usé Babel para poder usar JavaScript en el futuro. Sería genial tener algo de eso funcionando de forma nativa en la plataforma. Específicamente, async/await, funciones de flecha, valores predeterminados de argumentos y desestructuración.

Tuve que usar una biblioteca para comprimir el resultado con gzip para descubrir el tamaño comprimido en gzip. Usar una biblioteca para esto es un poco molesto, ya que ese código ya está en el navegador para HTTP, pero no hay una API para él. Idealmente, debería ser algún tipo de transmisión de transformaciones para que pueda contar el tamaño de la salida sin tener todo el contenido en la memoria.