SVGOM

Captura de tela do Svgomg

Resumo

SVGOMG: um front-end responsivo bonito e material para SVGO.

O que gostamos?

Criado pelo nosso Jake Archibald, o SVGOMG é um exemplo quase perfeito de uma ferramenta totalmente responsiva e capaz, criada com tecnologias da Web. Ele tem um visual bonito do Material Design, o ServiceWorker garante que o app seja carregado rapidamente e esteja disponível off-line, e as transições são suaves em dispositivos móveis.

Possíveis melhorias

A única crítica que temos é que a UX inicial é confusa por causa da falta da interface principal. Fora isso, bom trabalho!

Perguntas e respostas com Jake Archibald

Por que a Web?

Preguiça. Preguiça total. Não sou especialista em desenvolvimento de apps nativos do Windows, não sou especialista em apps nativos do OSX e nem em criação de apps nativos para iOS, Android, Windows Phone ou Linux. No entanto, posso fazer a Web, e esse conjunto de habilidades me permitiu criar algo uma vez que funcionava em todas essas plataformas.

O que funcionou muito bem durante o desenvolvimento?

Estou muito feliz com o desempenho dele. Eu garanto que a página seja renderizada antes que o JS esteja disponível. Na verdade, ele é renderizado pela primeira vez com apenas 5 mil de HTML com alguns CSS e SVG inline. Os scripts principais e o CSS são carregados em segundo plano. Isso significa que o site parece carregar em 1,5 segundo, mesmo em 3G com um cache vazio, e a maior parte disso é DNS e SSL.

A tela de abertura é muito simples, então fazer isso em 5k não foi um desafio. É muito chato que tantos sites esperem o JS para a primeira renderização. Alguns até exigem que o JS faça mais solicitações antes da renderização. Isso aumenta o tempo de renderização de 3G para 10 segundos. Como usuário de dispositivos móveis, sei que não aceitaria isso.

O JS principal é de 15k, mas não inclui as partes que analisam e minimizam o SVG, que é carregado como uma fase extra em segundo plano. Isso é ótimo porque a interatividade é exibida muito rapidamente, e o usuário não percebe o carregamento extra. Se o usuário conseguir selecionar um SVG antes que o script esteja disponível, o carregamento desse script vai parecer fazer parte do tempo de processamento.

Também usei o ServiceWorker para fazer com que tudo funcionasse off-line. Trabalhar off-line é um recurso muito legal, mas estou fazendo isso principalmente para melhorar a performance. As visitas subsequentes ao SVGOMG são renderizadas quase que instantaneamente, seja qual for a conexão do usuário. Considerando as variações na conectividade de dispositivos móveis, isso é muito valioso.

Se você pudesse ter qualquer API para melhorar seu app, qual seria?

Usei o Babel para poder usar recursos futuros do JavaScript. Seria ótimo se algumas dessas coisas funcionassem de forma nativa na plataforma. Especificamente, async/await, funções de seta, argumentos padrão e desestruturação.

Tive que usar uma biblioteca para compactar a saída com gzip e descobrir o tamanho dela. Usar uma biblioteca para isso é um pouco irritante, já que o código já está no navegador para coisas HTTP, não há uma API para isso. O ideal seria algum tipo de stream de transformação para que eu possa contar o tamanho da saída sem ter tudo na memória.