Ultimamente, tem havido muita discussão sobre os Apps Web Progressivos. Eles ainda são um modelo relativamente novo, mas os princípios deles podem melhorar apps criados com JS puro, React, Polymer, Angular ou qualquer outro framework. Nesta postagem, vou resumir algumas opções e apps de referência para você começar a usar seu próprio App Web Progressivo hoje mesmo.
O que é um App Web Progressivo?
É importante lembrar que os Apps Web Progressivos funcionam em qualquer lugar, mas são turbinados nos navegadores mais recentes. O aprimoramento progressivo é a base do modelo.
Aaron Gustafson comparou o aprimoramento progressivo a um M&M de amendoim. O amendoim é o conteúdo, a cobertura de chocolate é a camada de apresentação e o JavaScript é a casca de doce dura. Essa camada pode variar de cor, e a experiência pode variar de acordo com os recursos do navegador que a utiliza.
Pense na casca de chocolate como o local onde muitos recursos do App Web Progressivo podem ficar. São experiências que combinam o melhor da Web e dos apps. Eles são úteis para os usuários desde a primeira visita em uma guia do navegador, sem necessidade de instalação.
À medida que o usuário cria um relacionamento com esses apps pelo uso repetido, eles tornam a experiência ainda mais agradável: carregam muito rápido em conexões de rede lentas (graças ao service worker), enviam notificações push relevantes e têm um ícone de primeira classe na tela inicial do usuário que pode carregá-los como experiências no app em tela cheia. Eles também podem aproveitar os banners inteligentes de instalação de apps da Web.
Os Apps Web Progressivos são
- Progressivos: funcionam para todos os usuários, independentemente do navegador escolhido, porque são criados com o aprimoramento progressivo como um princípio fundamental.
- Responsivo: se adapta a qualquer formato, computador, dispositivo móvel, tablet ou o que vier a seguir.
- Independência de conectividade: aprimorado com service workers para funcionar off-line ou em redes de baixa qualidade.
- Semelhante a um app: use o modelo de shell do app para fornecer navegações e interações no estilo de um app.
- Atualizado: sempre atualizado graças ao processo de atualização do service worker.
- Seguro: veiculado via TLS para evitar espionagem e garantir que o conteúdo não tenha sido adulterado.
- Detectáveis: são identificáveis como "aplicativos" graças aos manifestos do W3C e ao escopo de registro do service worker, o que permite que os mecanismos de pesquisa os encontrem.
- Reengajável: facilite o reengajamento com recursos como notificações push.
- Pode ser instalado: permite que os usuários "mantenham" os apps que consideram mais úteis na tela inicial sem o incômodo de uma app store.
- Vinculável: compartilhe facilmente por URL sem precisar de uma instalação complexa.
Os Apps Web Progressivos também não são exclusivos do Google Chrome para Android. Abaixo, vemos o App Web Progressivo Pokedex funcionando no Firefox para Android (Beta) com os recursos iniciais de adicionar à tela inicial e de armazenamento em cache do service worker funcionando perfeitamente.
Um dos aspectos positivos da natureza "progressiva" desse modelo é que os recursos podem ser desbloqueados gradualmente à medida que os fornecedores de navegadores oferecem melhor suporte para eles. Os Progressive Web Apps, como o Pokedex, também funcionam muito bem no Opera para Android, com algumas diferenças notáveis na implementação:
Para saber mais sobre os Apps Web Progressivos, leia a postagem do blog original de Alex Russell que os apresenta. Paul Kinlan também criou uma tag do Stack Overflow muito útil para Apps Web Progressivos que vale a pena conferir.
Princípios
Manifesto do app da Web
O manifesto permite que o app da Web tenha uma presença mais nativa na tela inicial do usuário. Ele permite que o app seja iniciado no modo de tela cheia (sem uma barra de URL), oferece controle sobre a orientação da tela e, em versões recentes do Chrome no Android, permite definir uma tela de apresentação e uma cor do tema para a barra de endereço. Ele também é usado para definir um conjunto de ícones por tamanho e densidade usados para a tela de apresentação e o ícone da tela inicial mencionados acima.
Um exemplo de arquivo de manifesto pode ser encontrado no Web Starter Kit e nos exemplos do Google Chrome. Bruce Lawson escreveu um gerador de manifestos, e Mounir Lamouri também escreveu um validador de manifestos da Web (links em inglês) que vale a pena conferir.
Nos meus projetos pessoais, uso o realfavicongenerator para gerar os ícones com o tamanho correto para o manifesto do app da Web e para uso no iOS, em computadores etc. O módulo Node favicons também pode alcançar um resultado semelhante como parte do processo de build.
Os navegadores baseados no Chromium (Chrome, Opera etc.) oferecem suporte a manifestos de apps da Web, o Firefox está desenvolvendo ativamente o suporte e o Edge os lista como em consideração. O WebKit/Safari ainda não publicou indicadores públicos sobre as intenções de implementar o recurso.
Para mais detalhes, leia Apps da Web instaláveis com o manifesto de app da Web no Chrome para Android em Fundamentos da Web.
Banner "Adicionar à tela inicial"
O Chrome no Android já permite adicionar seu site à tela inicial há algum tempo, mas as versões recentes também oferecem suporte para sugerir proativamente que os sites sejam adicionados usando banners de instalação de apps da Web nativos.
Para que as solicitações de instalação do app sejam exibidas, seu app precisa:
- Ter um manifesto do app da Web válido
- Ser exibido por HTTPS (consulte letsencrypt para receber um certificado sem custo financeiro)
- Ter um service worker válido registrado
- Ser visitado duas vezes, com pelo menos 5 minutos entre as visitas
Há vários exemplos de banners de instalação de apps disponíveis, que abrangem desde banners básicos até casos de uso mais complexos, como a exibição de aplicativos relacionados.
Service worker para armazenamento em cache off-line
Um service worker é um script executado em segundo plano, separado da página da Web. Ele responde a eventos, incluindo solicitações de rede feitas em páginas que ele exibe. Um service worker tem um ciclo de vida intencionalmente curto.
Ele é ativado quando recebe um evento e é executado apenas pelo tempo necessário para processá-lo. O service worker permite que você use a API Cache para armazenar recursos em cache e pode ser usado para oferecer aos usuários uma experiência off-line.
Os service workers são eficientes para o armazenamento em cache off-line, mas também oferecem melhorias significativas de desempenho na forma de carregamento instantâneo para visitas repetidas ao seu site ou app da Web. É possível armazenar em cache o shell do aplicativo para que ele funcione off-line e preencher o conteúdo usando JavaScript.
Um conjunto abrangente de exemplos de service worker está disponível nos exemplos do Google Chrome. O guia de receitas off-line de Jake Archibald é uma leitura obrigatória, e recomendamos que você teste o tutorial seu primeiro app da Web off-line de Paul Kinlan se você não tiver experiência com service workers.
Nossa equipe também mantém vários utilitários auxiliares de service worker e ferramentas de build que consideramos úteis para reduzir a sobrecarga na configuração do service worker. Eles estão listados em Bibliotecas de service worker. Os dois principais são:
- sw-precache: uma ferramenta de tempo de build que gera um script de service worker útil para pré-armazenar em cache o shell do app da Web.
- sw-toolbox: uma biblioteca que fornece armazenamento em cache de ambiente de execução para recursos usados com pouca frequência.
Jeff Posnick escreveu uma introdução rápida sobre o sw-precache chamada Offline-first, fast, with the sw-precache module e um codelab sobre a mesma ferramenta que pode ser útil.
O Chrome, o Opera e o Firefox já implementaram o suporte para service workers, e o Edge tem sinais públicos positivos de interesse no recurso. O Safari mencionou brevemente o interesse no recurso por meio do plano de cinco anos proposto por um engenheiro.
Notificações push para reengajamento
Na prática, é possível criar apps da Web com que os usuários podem interagir fora de uma guia. O navegador pode ser fechado, e os usuários nem precisam estar usando o app da Web para interagir com a experiência. O recurso requer um service worker e um manifesto do app da Web, com base em alguns dos recursos resumidos anteriormente.
A API Push está implementada no Chrome, em desenvolvimento no Firefox e em consideração no Edge. Ainda não há sinais públicos do Safari sobre a intenção de implementar esse recurso.
Notificações push na Web aberta é uma introdução abrangente à configuração de notificações push, escrita por Matt Gaunt. Um codelab de notificações push também está disponível no Fundamentos da Web.
Michael van Ouwerkerk, da equipe do Chrome, também tem uma introdução de 6 minutos ao Push se você preferir vídeos.
Adição de recursos avançados
Lembre-se de que a experiência do usuário pode ter diferentes níveis de doçura, dependendo do navegador usado para acessar o app da Web. Você está no controle da casca de açúcar.
Outros recursos que estão chegando à plataforma da Web, como a Sincronização em Segundo Plano (para sincronizar dados com um servidor mesmo quando o app da Web está fechado) e o Web Bluetooth (para se comunicar com dispositivos Bluetooth pelo app da Web), também podem ser adicionados ao seu App Web Progressivo dessa maneira.
A sincronização em segundo plano única foi ativada no Chrome, e Jake Archibald tem um vídeo do app off-line da Wikipédia e um artigo demonstrando isso em ação. François Beaufort também tem várias amostras de Bluetooth da Web disponíveis para quem quiser testar essa API.
Compatível com frameworks
Não há nada que impeça você de aplicar qualquer um dos princípios acima a um aplicativo ou framework que esteja criando. Outros princípios que vale a pena lembrar ao criar seu App Web Progressivo são o modelo de desempenho centrado no usuário RAIL e as animações baseadas em FLIP.
Espero que, em 2016, vejamos um número cada vez maior de modelos e projetos iniciais que ofereçam suporte nativo aos Apps Web Progressivos como um recurso principal. Até lá, a barreira para adicionar esses recursos aos seus apps não é muito alta e, na minha opinião, vale muito a pena.
Arquitetura
Há diferentes níveis de como "apostar tudo" no modelo de App Web Progressivo, mas uma abordagem comum é arquitetá-los em torno de um shell do aplicativo. Isso não é um requisito obrigatório, mas traz vários benefícios.
A arquitetura do shell do aplicativo incentiva o armazenamento em cache do shell do aplicativo (a interface do usuário) para que ele funcione off-line e preencha o conteúdo usando JavaScript. Em visitas repetidas, isso permite que você receba pixels significativos na tela de forma muito rápida sem a rede, mesmo que seu conteúdo venha dela. Isso traz ganhos significativos de desempenho.
Jeremy Keith comentou recentemente que, nesse tipo de modelo, talvez a renderização do lado do servidor não deva ser vista como um substituto, mas a renderização do lado do cliente deve ser vista como uma melhoria. Esse feedback é justo.
No modelo de shell do aplicativo, a renderização do lado do servidor deve ser usada o máximo possível, e a renderização progressiva do lado do cliente deve ser usada como uma melhoria, da mesma forma que "melhoramos" a experiência quando o service worker é compatível. Há muitas maneiras de abordar isso.
Recomendo que você leia nosso artigo sobre a arquitetura e avalie como princípios semelhantes podem ser aplicados ao seu aplicativo e à sua pilha.
Textos padrão para começar
Shell do aplicativo
O repositório app-shell contém uma implementação quase completa da arquitetura do shell do aplicativo. Ele tem um back-end escrito em Express.js e um front-end escrito em ES2015.
Como ele abrange as partes do modelo do cliente e do lado do servidor e há muita coisa acontecendo, vai levar algum tempo para você se familiarizar com a base de código. Caso contrário, é o nosso ponto de partida mais abrangente para App Web Progressivo no momento. Os documentos serão nosso próximo foco neste projeto.
Kit inicial do Polymer
O ponto de partida oficial para apps da Web do Polymer é compatível com os seguintes recursos de App Web Progressivo:
- Manifesto do aplicativo da Web
- Tela de apresentação do Google Chrome para Android
- Armazenamento em cache off-line do service worker com os elementos Platinum SW
- Notificações push (configuração manual necessária) com os elementos Platinum Push
A versão atual do PSK não é compatível com alguns dos padrões de desempenho mais avançados (por exemplo, modelo de shell do aplicativo, carregamento assíncrono) que você encontra em alguns apps da Web do Progressive Polymer.
Nosso objetivo é tentar incorporar esses padrões ao PSK em 2016, mas os primeiros experimentos sobre isso podem ser encontrados no app Polymer Zuperkulblog, de Rob Dodson, e na excelente palestra Polymer Perf Patterns, de Eric Bidelman.
Web Starter Kit
Nosso ponto de partida opinativo para novos projetos simples inclui os seguintes recursos de App Web Progressivo:
- Manifesto do aplicativo da Web
- Tela de apresentação do Google Chrome para Android
- Pré-armazenamento em cache do service worker graças ao sw-precache
Se você prefere trabalhar com JS/ES2015 puro e não pode usar o Polymer, o Web Starter Kit pode ser útil como um ponto de referência para reutilizar ou copiar snippets de código.
Apps Web Progressivos com e sem frameworks
Vários Apps Web Progressivos de código aberto já foram criados por membros da comunidade com e sem bibliotecas e frameworks JS. Se você estiver procurando inspiração, os repositórios abaixo podem ser úteis como referência. Eles também são apps muito bons.
JavaScript puro
- O Gravador de Paul Lewis foi criado usando uma arquitetura semelhante à do
app-shell(artigo) - Offline Wikipedia de Jake Archibald (vídeo)
- Air Horner, de Paul Kinlan
- Guitar Tuner de Paul Lewis (artigo)
Polymer
- Zuperkulblog de Rob Dodson (slides)
React
- iFixit, de Jeff Posnick: usa
sw-precachepara o armazenamento em cache do shell do aplicativo (slides)
DOM virtual
- Pokedex de Nolan Lawson: um excelente App Web Progressivo que aplica uma abordagem de "fazer tudo em um worker da Web" para ajudar na renderização progressiva. (artigo)
Angular.js
- Timey.in (em inglês) de Kenneth Auchenberg: também usa
sw-precachepara pré-armazenamento em cache de recursos.
Notas de encerramento
Como mencionado, os Apps Web Progressivos ainda estão em sua infância, mas é um momento empolgante para brincar com as metodologias por trás deles e ver como eles podem ser aplicados aos seus próprios apps da Web.
Paul Kinlan está planejando as orientações do Fundamentos da Web sobre Apps Web Progressivos. Se você tiver sugestões sobre áreas que gostaria de ver abordadas, comente na conversa.
Leitura adicional
- Apps Web Progressivos: Escapando de Guias Sem Perder Nossa Alma
- Por que os Progressive Web Apps são o futuro do desenvolvimento para a Web
- Apps Web Progressivos: prontos para o horário nobre
- Como criar um Progressive Web App com o ServiceWorker
- Progressive Web Apps Are the Future
- App Web Progressivo: Uma Nova Maneira de Experimentar o Mobile
- Introducing Pokedex.org: a progressive webapp for Pokémon fans
- Resumo do Chrome Developer Summit: Apps Web Progressivos