SVGOM

Captura de tela do Svgomg

Resumo

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

Do que nós gostamos?

Criado pelo nosso próprio Jake Archibald, o SVGOMG é um exemplo quase perfeito de uma ferramenta totalmente responsiva e capacitada, desenvolvida com tecnologias da Web. Ele tem uma bela aparência do Material Design, o ServiceWorker garante que o app seja carregado rapidamente e esteja disponível off-line, e as transições sejam tranquilas em dispositivos móveis.

Possíveis melhorias

O único detalhe que temos a oferecer é que a UX inicial é confusa devido à ausência 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 desenvolver aplicativos nativos do Windows, não sou especialista em aplicativos nativos para OSX nem em criar aplicativos 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 funcionou 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 da disponibilização do JS. Na verdade, ele é renderizado primeiro com apenas 5.000 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 dele é DNS e SSL.

A tela de abertura é realmente simples, então fazer isso em 5k não foi um desafio. Realmente me incomoda que tantos sites aguardam a primeira renderização em JS e alguns até exigem o JS para fazer outras solicitações antes da renderização. Isso faz com que o tempo de renderização 3G chegue a 10 segundos. Como usuário de dispositivo móvel, sei que eu não aceitaria isso.

O JS principal é 15k, mas não inclui as partes que analisam e reduzem o SVG, que são carregadas como uma fase extra em segundo plano. Isso é ótimo porque a interatividade ocorre muito rapidamente, e o usuário não percebe a carga extra. Se o usuário conseguir selecionar um SVG antes que o script fique disponível, o carregamento desse script aparecerá como parte do tempo de processamento.

Também usei o ServiceWorker para fazer tudo funcionar off-line. Trabalhar off-line é um recurso muito legal, mas a maior parte dele é o desempenho. Os acessos subsequentes ao SVGOMG são renderizados quase instantaneamente, independentemente da conexão do usuário. Dadas as variações na conectividade móvel, isso é muito valioso.

Se você pudesse ter alguma API para melhorar seu app, o que seria?

Usei o Babel para fazer uso de coisas do JavaScript no futuro. Seria ótimo ter parte disso funcionando de forma nativa na plataforma. Especificamente, async/await, funções de seta, padrões de argumento e desestruturação.

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