Por alguma razão, muitos pensam que aplicativos da web progressivos (PWA) são aplicativos de página única (SPA) ou mais comumente enquadrados por pessoal de marketing, aplicativos JavaScript.
Isso está errado, muito errado.
Um SPA pode ser um PWA, mas um PWA não precisa ser um SPA.
Recomendo não ser um aplicativo de página única para sites que segmentam tráfego de pesquisa orgânica e para a maioria das soluções online.
Por quê?
Porque o JavaScript do lado do cliente não fornecer a melhor experiência do usuário que os desenvolvedores acham que oferecem. Na verdade, eles criam uma experiência do usuário relativamente ruim na maioria dos casos. E não, seus desenvolvedores provavelmente não são a exceção que faz boas experiências de usuário do SPA.
Requisitos para ser um aplicativo de página única não são os mesmos requisitos para ser um aplicativo da web progressivo. Isso significa que você pode fazer um SPA, mas não é um PWA e vice-versa.
Então, por que tantos desenvolvedores e profissionais de marketing presumem que um aplicativo da web progressivo é um aplicativo de página única?
A equipe do Google Chrome pode ser a causa dessa confusão?
É apenas a popularidade esmagadora do que chamo de frameworks JavaScript de’fast food’?
E qual é o melhor tipo de site para um PWA?
O que é um aplicativo de página única
Aplicativos de página única são sites pesados em JavaScript que, por definição pura, contam com uma única página da web com marcação do lado do cliente renderizada dinamicamente. Em vez de carregar páginas individuais (HTML) completamente do servidor, a marcação parcial ou os dados são carregados do servidor e compostos no navegador antes de renderizar a marcação no DOM.
A principal atração que muitos de nós tínhamos que usar aplicativos de página única era o desejo de criar sites que parecessem mais com aplicativos nativos.
Sem a viagem tradicional entre o navegador e o servidor para a página inteira, o app shell permanece visível no navegador enquanto o conteúdo é recuperado e renderizado.
Em outras palavras, a renderização do lado do servidor é movida para o cliente.
Para fazer isso, um aplicativo de página única utiliza um mecanismo de renderização baseado em JavaScript e AJAX. Essa renderização é acionada por uma alteração no URL, alterando o hashfragment, o valor após um #. Outro evento é uma alteração puramente orientada por JavaScript, normalmente devido a uma ação de uso, como clicar em um botão.
Em vez de recuperar páginas inteiras, páginas parciais ou apenas dados são recuperados usando uma chamada de rede nos bastidores. Isso foi feito usando AJAX, mas hoje mudou para ‘fetch’.
A página principal é o’shell do aplicativo’, ou a quantidade mínima de marcação para compor o que chamamos de cromo do aplicativo. Isso normalmente significa o cabeçalho, rodapé e navegação primária do layout.
Como qualquer coisa que os desenvolvedores tocam, eles tendem a jogar quantidades excessivas de código em uma solução. É por isso que os aplicativos de página única evoluíram da era jQuery para frameworks JavaScript gigantes, com muitos códigos,’fast food’.
Exemplos populares são Angular e React, mas há vários outros que não conseguiram ganhar massa popularidade ou estão emergindo. Provavelmente foi lançado um novo enquanto eu escrevia este artigo!
Eu os chamo de frameworks de fast food porque estão cheios de código superprocessado e açúcar sintático com falta de nutrientes técnicos. Assim como o fast food real está cheio de carboidratos processados e açúcar, o que torna muitos de nós obesos!
Infelizmente, a natureza dessas estruturas atrai o desenvolvedor médio porque elas são pesadas em código (JavaScript). Eles também dão a ilusão de abstrair o JavaScript ou conveniência. Isso é semelhante à maneira como pensamos que os restaurantes de fast food nos poupam tempo e dinheiro.
Essa conveniência percebida e almofada de código excessivo torna essas estruturas uma força irresistível para a maioria dos desenvolvedores.
Mas a escolha dessas estruturas tem um custo e é compensada pela experiência do usuário insatisfatória e redução do envolvimento ou produtividade do cliente.
Voltando ao ponto principal, os aplicativos de página única podem ser aplicativos da Web progressivos, mas os PWAs não têm que ser SPAs.
Isso porque um aplicativo de página única não requer um serviço de trabalhador , arquivo de manifesto da web ou sendo servido via HTTPS. Eles também ficam aquém do espírito dos aplicativos da web progressivos, em que o objetivo final é oferecer experiências incríveis ao usuário.
Por que os aplicativos da web progressivos não são aplicativos de página única
Progressive Web Applications são sites que atendem a três requisitos técnicos:
- Servido usando HTTPS (seguro )
- Tenha um arquivo de manifesto da web válido com um conjunto mínimo de ícones
- Registre um Service Worker com um Fetch Event Handler e suporte mínimo offline
Nenhum lugar nesses requisitos diz que o PWA não deve solicitar páginas renderizadas pelo servidor ou que o conteúdo deve ser renderizado no navegador.
Também não há nada nesses requisitos dizendo que o site deve usar JavaScript. Bem, mais ou menos, você deve registrar o service worker usando JavaScript do lado do cliente
Este é todo o JavaScript que você deve incluir em suas páginas da web para registrar um service worker:
if ("serviceWorker"no navegador) {navigator.serviceWorker.register ("/sw.js").then (function (registration) {//O registro foi bem-sucedido console.log ("Registro de ServiceWorker bem-sucedido com escopo:", registration.scope);}).catch (function (err) {//registro falhou:( console.log ("Registro de ServiceWorker falhou:", err);}); }
O service worker do seu site é escrito usando JavaScript, mas é executado em um processo diferente, então não conta na sua experiência de usuário front-end. Falando em UX…
Existem algumas expectativas de experiência do usuário em aplicativos da web progressivos, como velocidade, envolvimento e integração. Essas expectativas são avaliadas mais pelo observador, mas, novamente, nada sobre o cliente renderização do lado t.
À medida que os aplicativos da web progressivos crescem em demanda, os desenvolvedores naturalmente desejam manter seu amor pelos aplicativos de página única, mesmo quando eles não são mais necessários.
Espere, eu digamos que os aplicativos de página única não sejam mais necessários?
Vamos mergulhar nessa posição interessante.
Por que os aplicativos da Web progressivos matam os aplicativos de página única
Há vários anos, eu estava Aguardo ansiosamente minha primeira apresentação no Velocity de O’Reilly sobre criação de aplicativos rápidos de página única assistindo a Patrick Meenan demonstrar os prestadores de serviço . Enquanto observava Patrick, não pude deixar de pensar que tudo o que estava prestes a mostrar era um polyfil.
Fiquei maravilhado com esse novo recurso da plataforma da web, service workers, porque pude ver como projetei meu single aplicativos de página agora como um recurso nativo ou embutido do navegador!
Eu arquiteturei meus aplicativos de página única de forma diferente do que Angular e React projetaram suas estruturas de aplicativo. Minha arquitetura foi construída com a experiência do usuário como requisito principal do recurso. Estruturas de fast food são projetadas para tornar a experiência do desenvolvedor o objetivo principal.
Uma regra simples é: quanto mais JavaScript do lado do cliente, pior é a experiência do usuário.
Os navegadores devem carregar o arquivo pela rede, descompactar o script (presumindo que você use compactação, o que deve ser feito), analisar e executar o script antes que ele possa continuar com o rende processo de anel. Isso ocorre porque o JavaScript é um processo de bloqueio.
Se o JavaScript alterar o DOM, o caminho de renderização crítico deve ser reciclado, atrasando a renderização do conteúdo.
O processo é mais complexo, mas não quero ser rastreado. Aceite o fato de que o JavaScript faz com que suas páginas sejam renderizadas lentamente, mesmo quando dentro do contexto de um aplicativo de uma única página.
Então, como os PWAs eliminam os SPAs?
Um aplicativo da web progressivo projetado corretamente antes-Caches muitos ativos do site: scripts, css, imagens e marcação, antes que eles sejam necessários. Isso elimina a rede do processo de renderização e permite que o aplicativo funcione offline.
Um PWA ainda pode usar o modelo de shell do aplicativo, mas agora, em vez de a marcação principal sendo renderizada no thread de IU, ela pode ser pré-buscada no service worker ou renderizado dinamicamente no service worker.
A chave para este processo é que o service worker é executado em um thread separado da IU. Isso significa que a guia do navegador não fica travada enquanto o JavaScript é executado para renderizar o conteúdo.
Isso significa que você pode remover completamente a sobrecarga excessiva do JavaScript do aplicativo de página única que os frameworks JavaScript adicionam aos seus aplicativos da web. Em vez disso, você pode mover essa lógica para o service worker.
Demonstrei esse conceito no início deste ano quando publiquei um PWA para o Philly Code Camp . Eu me aprofundo ainda mais no uso de service workers para gerenciar a renderização de conteúdo em meu novo livro de desenvolvimento de aplicativos da Web progressivos .
Seguindo esse modelo, descobri que posso reduzir minha pegada de JavaScript para menos de 10 kb em muitos casos, não os megabytes exigidos pelas estruturas e seu ecossistema de extensão.
Por que a equipe do Chrome May Have Created PWA é um equívoco do SPA
A equipe do Chrome é ótima, eles fornecem muito conteúdo excelente para ajudar os desenvolvedores a serem mais produtivos e produzir páginas da web de melhor qualidade. E, embora sua intenção seja nobre, pode ser mal interpretada.
A equipe do Chrome sabe que existem muitos sites construídos usando estruturas de fast food. Eles tentam ser úteis para dar aos desenvolvedores alguma orientação sobre como fazer essas estruturas funcionarem melhor.
Uma dessas áreas é o conceito de um ‘shell do aplicativo’.
Para aplicativos de página única, gosto de pensar no shell do aplicativo como a tela principal ou contexto para pintar o aplicativo, impulsionado pelas ações do usuário para renderizar o conteúdo atualizado.
… … …
De qualquer forma, a equipe do Chrome tem vários recursos em torno do conceito de shell do aplicativo e eles fazem um ótimo trabalho mostrando como usar este modelo.
O que eu odeio nisso, porém, é que muitos desenvolvedores e proprietários de sites consomem esse conteúdo e presumem que é a maneira de construir aplicativos da web progressivos.
Isso está errado.
Usar um shell de aplicativo é uma maneira de conduzir um aplicativo da web progressivo, mas não um requisito nt.
Na verdade, acho que pode ser uma maneira ruim de fazer aplicativos da web progressivos.
Quando você usa técnicas de cache de service worker adequadas, não precisa de um shell de aplicativo porque seu as páginas tendem a vir de uma resposta em cache local, que quando projetada corretamente deve renderizar em algumas centenas de milissegundos, não em 22 segundos!
Por que 22 segundos?
Esse é o tempo médio que isso leva uma página da web média para renderizar em um dispositivo cliente médio, de acordo com a pesquisa do Google.
O tempo médio que leva para carregar totalmente a página de destino móvel média é de 22 segundos. No entanto, a pesquisa também indica que 53% das pessoas sairão de uma página para celular se ela demorar mais de 3 segundos para carregar. Mobile Page Speed Benchmarks
Deixe-me ser claro, você não pode pré-armazenar em cache todas as páginas de todos os sites. Alguns sites você pode, mas não todos.
Eu sempre uso a Amazon como meu exemplo. Isso porque eles têm milhões de páginas de produtos e armazenar todo o site em cache em um telefone ou em qualquer computador cliente é simplesmente impossível e, claro, irresponsável.
Nesses cenários, o uso de um shell de aplicativo é uma boa ideia. Mas, em vez de usar um aplicativo de página única, você pode aproveitar seu service worker para armazenar modelos de página em cache e recuperar JSON de cada página sob demanda e renderizar a página no service worker.
Embora você não para ter uma experiência de renderização de página’instantânea’, o uso do shell do aplicativo ajuda a compensar qualquer ansiedade devido às latências da rede e do framework JavaScript. Além disso, você pode armazenar em cache localmente o resultado para solicitações futuras do mesmo recurso.
A principal vantagem de aproveitar o service worker não é a necessidade de uma estrutura JavaScript ou de um aplicativo de página única para conduzir essa experiência. Um SPA é congruente com os objetivos gerais desejados da página.
Minha solução favorita é aproveitar um mecanismo de modelo simples, como Mustache e modelos de conteúdo em cache para renderizar páginas no service worker. Ou tenha páginas parciais pré-renderizadas no servidor e apenas busque-as. Assim que o conteúdo da página estiver disponível, você pode enviá-lo ao cliente e fazer um document.querySelector simples (“target-element-selector”). InnerHTML=[page content HTML].
Sem a sobrecarga da estrutura esse processo parece’instantâneo’mesmo em telefones celulares comuns.
Portanto, um problema importante de desempenho é abordado com os service workers, mas e os links?
Resolvendo problemas de vinculação de aplicativos de página única
O principal superpoder da web é a capacidade de links profundos. Os aplicativos de página única tendem a usar fragmentos hash, procure o #! em um URL. O valor do fragmento hash aciona um evento do lado do cliente usado por essas estruturas para conduzir o processo de renderização. Mas esse valor de fragmento hash não é passado para o servidor.
Além do fragmento hash não registrado no servidor os mecanismos de pesquisa não indexam conteúdo com base em fragmentos hash .
Deve haver uma’prática recomendada’de PWA ou tipo de site, certo?
Este é onde vence o site estático com URLs reais.
Imagine que páginas da web com endereços reais resolvem muitos problemas criados por aplicativos de página única.
Mesmo se o navegador não for compatível com aplicativos da web progressivos e service workers, que não são muitos hoje em dia, páginas estáticas simplesmente funcionam.
Meu modelo de site de aplicativo da Web progressivo recomendado
Se um aplicativo da Web progressivo não for um aplicativo de uma única página, o que é?
É simples, um site que usa o melhor que a web tem a oferecer para oferecer ótimas experiências ao usuário.
Então, qual é o melhor que a web tem a oferecer? Bem, isso depende do que um site precisa.
Alguns aplicativos precisam de mais recursos de hardware, outros animações ricas ou integrações de mídia. Mas quase todos os sites têm um conjunto central de expectativas em comum.
- Carregamento rápido
- Animações suaves
- Responsivo, design móvel primeiro
- Alguns recursos de renderização dinâmica
No passado, eu era um campeão de aplicativos de página única, mas não posso mais ser. Hoje sou um campeão progressivo de aplicativos da web, a progressão natural dos SPAs.
Nenhuma surpresa nisso, mas isso pode surpreendê-lo:
Agora, recomendo usar um site estático.
Isso mesmo, o tipo original de site, estático e enfadonho.
Mas, ao contrário de quando a web estreou originalmente, esses sites estáticos não são 100% estáticos, na verdade, nem mesmo estão em um servidor web.
Intrigado?
Eu uso a renderização do lado do servidor, mas utilizo uma série de AWS Lambdas que usam nodejs para produzir marcação estática quando o código-fonte da página é criado ou atualizado. Em outras palavras, a marcação só é renderizada quando o conteúdo muda, não sob demanda e não no cliente.
Essas páginas são’hospedadas’no AWS S3 e utilizam o AWS CloudFront CDN.
Não posso te dizer o quão mais simples esta configuração configuração é para gerenciar do que eu costumava lidar ao usar o IIS e outras plataformas de servidor da Web.
No entanto, há cenários em que um site pode precisar ser renderizado sob demanda.
Para exemplo, quando o conteúdo é orientado por um perfil de usuário autenticado. Um bom exemplo disso é quando um cabeçalho de site é personalizado para um usuário autenticado, em vez de mostrar um botão de login.
Existem milhares de outros cenários’comuns’que poderiam ser considerados para impulsionar o JavaScript ou Experiência de SPA. A maioria pode ser contestada como um meio de justificar um aplicativo de página única e renderização pesada baseada em navegador.
No final das contas, tudo se resume a quão bem você pode refinar esses cenários. Se eu precisar de mais renderização do lado do cliente, vou limitar os cenários mais ao que pode ser chamado de SPAlet.
É onde uma página é responsável por criar uma interface para gerenciar ou interagir com uma coleção de dados intimamente relacionados. Vejo esse modelo como uma forma de retornar à inspiração original que tive de criar os primeiros aplicativos de página única, uma lista com um diálogo modal para editar registros.
Dez anos atrás, comecei a usar jQuery e jQuery UI para páginas de design. Uma das primeiras coisas que fiz foi modificar meus formulários sobre a estratégia de dados para renderizar dados em tabelas com um botão de edição e novo registro.
Quando um registro era selecionado, eu exibia uma caixa de diálogo modal (em muitos casos) para inserir e atualizar os dados do registro. Quando a caixa de diálogo fosse enviada, os dados seriam postados no servidor e a lista atualizada.
Esse modelo simples pode ser aplicado a muitos cenários de linha de negócios e até mesmo alguns casos de uso de consumidor. Mas você não precisa gerenciar cada visualização ou página necessária em um aplicativo em um conjunto gigante de JavaScript do lado do cliente.
Resumindo
Infelizmente, muitos parecem ter sido pegos pelo popular equívoco de que os aplicativos progressivos da web são aplicativos de página única. Embora possam ser SPAs, não precisam ser SPAs.
Na verdade, você se sentirá melhor evitando aplicativos de página única hoje. Em vez disso, use service workers para implementar muito do que os aplicativos de página única foram projetados para fazer. Mas, em vez de obstruir o encadeamento da IU com JavaScript excessivo, você pode descarregar tarefas de renderização do lado do cliente para o service worker.
Além disso, avalie quais páginas em seu site são candidatas à renderização do service worker. Nem toda página é uma boa candidata para renderização do lado do cliente. Você pode aproveitar o cache do service worker para eliminar a solicitação de rede para muitas páginas, bem como a necessidade de cargas úteis de JavaScript pesadas.
