A discussão sobre os Progressive Web Apps tem sido muito aberta recentemente. Eles ainda são um modelo relativamente novo, mas os princípios podem melhorar igualmente os apps criados com vanilla JS, React, Polymer, Angular ou qualquer outro framework. Nesta postagem, vou resumir algumas opções e fazer referência a apps para começar a usar seu próprio Progressive Web App hoje.
O que é um App Web Progressivo?
É importante lembrar que os Progressive Web Apps funcionam em qualquer lugar, mas são potentes em navegadores modernos. O aprimoramento progressivo é uma espinha dorsal do modelo.
Aaron Gustafson comparou o aprimoramento progressivo à M&M de amendoim. O amendoim é o seu conteúdo, a cobertura de chocolate é a sua camada de apresentação e o seu JavaScript é a casca de doces. Essa camada pode variar de cor, e a experiência pode variar dependendo dos recursos do navegador que a utiliza.
Pense no Candy Shell como o local onde muitos recursos do App Web Progressivo podem ficar. São experiências que combinam o melhor da Web e o melhor dos apps. Eles são úteis para os usuários desde a primeira visita em uma guia do navegador, sem a necessidade de instalação.
À medida que o usuário constrói uma relação com esses aplicativos por meio do uso repetido, ele torna o shell dos doces ainda mais agradável: carregando muito rápido em conexões de rede lentas (graças ao service worker), enviando notificações push relevantes e oferecendo um ícone de primeira classe na tela inicial do usuário que pode carregá-lo como experiências do aplicativo em tela cheia. Eles também podem aproveitar os banners inteligentes para a instalação de apps da Web.
Os Progressive Web Apps são
- Progressivos: funcionam para todos os usuários, independente da escolha do navegador, porque eles foram criados com aprimoramento progressivo como locatário principal.
- Responsivo: se adapta a qualquer formato, computador, dispositivo móvel, tablet ou o que for seguinte.
- Independente de conectividade: aprimorado com service workers para trabalhar off-line ou em redes de baixa qualidade.
- Semelhante ao app: use o modelo de shell do app para fornecer navegações e interações no estilo do 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 seja adulterado.
- Detectáveis: são identificáveis como "aplicativos" graças aos manifestos do W3C e ao escopo de registro do service worker, permitindo que os mecanismos de pesquisa os encontrem.
- Reengajamento: facilite o reengajamento usando recursos como notificações push.
- Instalável: permite que os usuários "mantenham" os apps que consideram mais úteis na tela inicial sem precisar acessar uma app store.
- Vinculável: compartilhe facilmente por URL e não requer instalação complexa.
Os Progressive Web Apps também não são exclusivos do Chrome para Android. Veja abaixo o Progressive Web App Pokedex funcionando no Firefox para Android (Beta) com os primeiros recursos de armazenamento em cache "Adicionar à tela inicial" e "Service worker".
Um dos aspectos positivos da natureza "progressiva" para esse modelo é que os recursos podem ser desbloqueados gradualmente à medida que os fornecedores de navegadores oferecem um melhor suporte para eles. Progressive Web Apps, como Pokedex, também funcionam muito bem no Opera no Android, com algumas diferenças notáveis de implementação:
Para saber mais sobre os Progressive Web Apps, leia a postagem do blog original de Alex Russell sobre eles. Paul Kinlan também criou uma tag Stack Overflow muito útil para Progressive Web Apps que valem a pena conferir.
Princípios
Manifesto do app da Web
O manifesto permite que seu 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) e oferece controle sobre a orientação da tela. Nas versões recentes do Chrome no Android, oferece suporte à definição de uma tela de apresentação e 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 está disponível no Web Starter Kit (em inglês) e em outros nos exemplos do Google Chrome (links em inglês). Bruce Lawson escreveu um Gerador de manifestos, e Mounir Lamouri também escreveu um validador de manifesto da Web que vale a pena conferir.
Nos meus projetos pessoais, uso o realfavicongenerator para gerar os ícones com tamanho correto para o manifesto do app da Web e para uso no iOS, no computador e assim por diante. O módulo do nó favicons também pode alcançar um resultado semelhante como parte do seu processo de criação.
Atualmente, os navegadores baseados no Chromium (Chrome, Opera etc.) são compatíveis com manifestos de apps da Web. O Firefox desenvolve ativamente o suporte e o Edge os lista como em consideração. O WebKit/Safari ainda não postou sinais públicos sobre suas intenções para implementar o recurso.
Para ver 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"
Já faz algum tempo que o Chrome no Android é compatível com a adição do seu site à tela inicial, mas as versões recentes também são compatíveis com sugestões proativas de sites que podem ser adicionados usando banners nativos de instalação de apps da Web.
Para que as solicitações de instalação sejam exibidas, o app precisa:
- Ter um manifesto de app da Web válido
- Ser exibido por HTTPS (consulte letsencrypt para obter um certificado sem custo financeiro)
- Ter um service worker válido registrado
- Ser visitado duas vezes, com pelo menos cinco minutos entre as visitas
Vários exemplos de banners de instalação de apps estão disponíveis, abrangendo 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 nas páginas veiculadas. Um service worker tem uma vida útil intencionalmente curta.
Ele é ativado quando recebe um evento e funciona apenas no tempo necessário para processá-lo. O service worker permite usar 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 poderosos para armazenamento em cache off-line, mas também oferecem melhorias de desempenho significativas na forma de carregamento instantâneo para acessos repetidos ao seu site ou app da Web. É possível armazenar o shell do seu aplicativo em cache para que ele funcione off-line e preencher o conteúdo usando JavaScript.
Um conjunto abrangente de amostras de service workers está disponível nas amostras do Google Chrome. O manual off-line de Jake Archibald é uma leitura obrigatória, e eu recomendo muito testar o tutorial do seu primeiro app da Web off-line de Paul Kinlan, caso seja iniciante em service workers.
Nossa equipe também mantém diversos utilitários de assistente e ferramentas de build que consideramos úteis para reduzir a sobrecarga na configuração do service worker. Elas estão listadas em Bibliotecas de service workers. As duas principais são:
- sw-precache: uma ferramenta de tempo de build que gera um script de service worker útil para armazenar o shell do seu app da Web em cache.
- sw-toolbox: uma biblioteca que fornece armazenamento em cache no tempo de execução para recursos pouco usados.
Jeff Posnick escreveu um guia rápido sobre o sw-precache chamado Off-line, priorização, com o módulo sw-precache e um codelab na mesma ferramenta que pode ser útil.
O Chrome, o Opera e o Firefox implementaram o suporte para o service worker, e o Edge tem sinais públicos positivos sobre interesse no recurso. O Safari mencionou brevemente o interesse na plataforma por meio do plano de cinco anos proposto por um engenheiro.
Notificações push para reengajamento
Efetivamente, você pode criar aplicativos da Web com os quais os usuários possam interagir fora de uma guia. O navegador pode ser fechado, e eles não precisam usar seu app da Web ativamente para interagir com sua experiência. O recurso exige um service worker e um manifesto de app da Web, aproveitando alguns dos recursos resumidos anteriormente.
A API Push foi implementada no Chrome, em desenvolvimento no Firefox e sob 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 sobre como usar a configuração push por Matt Gaunt, e 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ê tiver mais interesse em vídeos.
Como adicionar camadas aos 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 visualizar o app da Web. Você está no controle do shell de Candy.
Recursos adicionais que chegam à plataforma da Web, como Sincronização em segundo plano (para sincronização de dados com um servidor mesmo quando o app da Web está fechado) e Web Bluetooth (para se comunicar com dispositivos Bluetooth pelo app da Web), também podem ser sobrepostos ao seu App Web Progressivo.
A sincronização única em segundo plano 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. Francois Beaufort também tem vários exemplos da Web Bluetooth (link em inglês) disponíveis caso você tenha interesse em testar essa API.
Otimização de framework
Não há nada que impeça você de aplicar qualquer um dos princípios acima a um aplicativo ou framework que você esteja usando para criar. Alguns outros princípios que vale a pena ter em mente 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 crescente de textos clichê e projetos sementes que são usados de forma orgânica para dar suporte aos Progressive Web Apps como recurso principal. Até lá, a barreira para adicionar esses recursos aos seus próprios apps não é muito alta e é IMHO, vale a pena o esforço.
Arquitetura
Há diferentes níveis de integração total no modelo de App Web Progressivo, mas uma abordagem comum é arquitetar em torno de um shell do aplicativo. Esse não é um requisito difícil, mas traz vários benefícios.
A arquitetura de shell do aplicativo incentiva o armazenamento em cache do shell do seu aplicativo (a interface do usuário) para que funcione off-line e preencha o conteúdo usando JavaScript. Em visitas repetidas, isso permite que você exiba pixels significativos na tela com muita rapidez sem a rede, mesmo que seu conteúdo eventualmente venha dela. Isso traz ganhos significativos de desempenho.
Jeremy Keith recentemente comentou que, nesse tipo de modelo, talvez a renderização no servidor não deva ser vista como um substituto, mas a renderização no lado do cliente deva ser vista como uma melhoria. Este é um feedback justo.
No modelo do 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 um aprimoramento da mesma forma que "aprimoramos" a experiência quando há suporte para o service worker. Existem muitas maneiras de fazer isso.
Minha recomendação é ler nosso texto sobre arquitetura e avaliar como princípios semelhantes podem ser mais bem aplicados a seu próprio aplicativo e pilha.
Como começar a usar boilerplate
Shell do aplicativo
O repositório app-shell contém uma implementação quase completa da arquitetura de shell do aplicativo (em inglês). Ele tem um back-end escrito em Express.js e um front-end escrito em ES2015.
Como ele abrange partes do lado do cliente e do servidor do modelo e há muita coisa acontecendo, vai levar algum tempo para você se familiarizar com a base de código. Fora isso, esse é nosso ponto de partida mais abrangente do Progressive Web App no momento. O Google Docs será nosso próximo foco neste projeto.
Kit de iniciação do Polymer
O ponto de partida oficial dos apps da Web da Polymer é compatível com os seguintes recursos do Progressive Web App:
- Manifesto do aplicativo da Web
- Tela de apresentação do 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 push Platina
A versão atual do PSK não oferece suporte a alguns dos padrões de desempenho mais avançados (por exemplo, modelo de shell de aplicativo, carregamento assíncrono) que você encontra em alguns apps da Web do Progressive Polymer.
Nosso objetivo é colocar esses padrões no PSK em 2016, mas os primeiros experimentos sobre ele podem ser encontrados no app Polymer Zuperkulblog (em inglês) de Rob Dodson e na excelente palestra Polymer Perf Patterns (em inglês) de Eric Bidelman.
Web Starter Kit
Nosso ponto de partida opinativo para novos projetos básicos inclui os seguintes recursos do App Web Progressivo:
- Manifesto do aplicativo da Web
- Tela de apresentação do Chrome para Android
- Pré-armazenamento em cache do service worker graças ao sw-precache
Se você prefere trabalhar com JS/ES2015 padrão e não pode usar o Polymer, o Web Starter Kit pode ser útil como ponto de referência para reutilizar ou roubar snippets de código.
Progressive Web Apps com e sem frameworks
Vários Progressive Web Apps de código aberto já foram criados por membros da comunidade, com ou sem bibliotecas e frameworks JS. Se você está em busca de inspiração, os repositórios abaixo podem ser úteis como referência. Eles também são apps muito bons.
JavaScript baunilla
- O Gravador de voz de Paul Lewis foi desenvolvido usando uma arquitetura semelhante ao
app-shell(escrita). - Off-line Wikipédia por Jake Archibald (vídeo)
- Air Horner, de Paul Kinlan
- Guitar Tuner por Paul Lewis (gravação)
Polymer
- Zuperkulblog por Rob Dodson (slides)
Reagir
- iFixit, de Jeff Posnick: usa
sw-precachepara armazenamento em cache do shell do aplicativo (slides).
DOM virtual
- Pokedex, de Nolan Lawson: excelente app da Web progressivo que aplica a abordagem "faça tudo em um web worker" para ajudar na renderização progressiva. (texto)
Angular.js
- Timey.in de Kenneth Auchenberg: também usa
sw-precachepara pré-armazenamento em cache de recursos.
Notas de encerramento
Como mencionado, os Progressive Web Apps ainda estão começando, mas é um momento empolgante para testar as metodologias por trás delas e ver como elas podem ser aplicadas aos seus próprios aplicativos da Web.
Paul Kinlan está planejando as orientações dos Fundamentos da Web relacionados aos Progressive Web Apps. Se você tiver sugestões sobre áreas que gostaria que fossem abordadas, sinta-se à vontade para comentar na conversa.
Leia mais
- Progressive Web Apps: como escapar de guias sem perder a alma
- Por que os Progressive Web Apps são o futuro do desenvolvimento da Web
- Progressive Web Apps: prontos para o horário nobre
- Como criar um app progressivo com o ServiceWorker
- Os Progressive Web Apps são o futuro
- Progressive Web App: uma nova maneira de usar dispositivos móveis (em inglês)
- Conheça Pokedex.org: um app da Web progressivo para fãs de Pokémon
- Resumo da Conferência de Desenvolvedores do Chrome: Progressive Web Apps