Nativo e PWA: escolhas, não desafiadores!

É difícil dizer exatamente onde a cisão entre “nativo” e “web” realmente começou. Eu sinto que é uma daquelas coisas que estavam se agitando logo abaixo da superfície desde os primeiros dias do Flash, apenas para explodir mais recentemente com o surgimento das plataformas móveis. Independentemente disso, os desenvolvedores enfrentaram esse “grande abismo”, lançando insultos uns aos outros na tentativa de reforçar seu próprio lado.

Não tenho interesse nessa luta. Claro, eu sou um “cara da web”, mas isso não significa que eu não possa ver o apelo do desenvolvimento nativo; Também sou desenvolvedor de software. Acima de tudo, porém, sou um pragmático. Percebo que cada projeto é diferente e que nossa abordagem para cada um deve ser adaptada às necessidades e objetivos do projeto.

Com os Progressive Web Apps (PWAs) invadindo o território do desenvolvimento nativo, achei que seria um bom momento para voltar atrás e fazer um balanço dessas duas abordagens para a criação de produtos. Minha esperança é que todos saiamos com a capacidade de ver claramente os pontos fortes de cada abordagem na esperança de encontrar o ajuste certo para os produtos que criamos.

Uma comparação de tiro rápido

Desde o início, as experiências baseadas na web têm sido comparadas com tudo, desde software de desktop (os "aplicativos nativos" originais) até CD-ROMs interativos, Flash e, mais recentemente, aplicativos móveis. Apesar de ter sido declarado morto em várias ocasiões, a web persistiu. Em muitos casos, até sobreviveu a seus supostos assassinos (RIP Flash).

Um dos principais pontos fortes da web nesse sentido é sua adaptabilidade. Ele foi capaz de ir praticamente a qualquer lugar onde haja uma conexão com a Internet e continua a ganhar novos recursos. Todas as linguagens de programação evoluem, por isso não é inesperado, mas com o tempo as fronteiras crescentes da web continuaram a invadir o território do software tradicional.

Uma área em que a web historicamente ficou aquém, no entanto, foi no domínio do desempenho. O software instalado é capaz de se conectar ao sistema operacional subjacente de uma forma que a web simplesmente não consegue. Eles são escritos na língua franca de seu host, com acesso direto ao hardware ou “mais perto do metal”, como costumamos dizer. A web, que quase sempre opera uma ou mais camadas de abstração acima disso, tem enfrentado dificuldades para competir quando se trata de desempenho. Embora a diferença de desempenho tenha diminuído com o tempo, o código nativo provavelmente continuará sendo executado mais rápido que o código da web, pelo menos até que a web se torne capaz de interpretar sinais diretamente dos pinos do hardware.

De mãos dadas com a vantagem de desempenho, o desenvolvimento nativo tem acesso muito maior (e anterior) aos recursos do dispositivo, como NFC, Bluetooth, sensores de proximidade e luz ambiente e muito mais. A web também está obtendo acesso constante a esses recursos, mas sempre ficará atrás do nativo porque as APIs nativas precisam ser desenvolvidas antes que a web possa acessá-las e a padronização no ambiente do navegador leva tempo.

Além disso, o código nativo pode se conectar a recursos no nível do sistema operacional, como o catálogo de endereços e os calendários. As notificações push foram outro grande problema, mas os Service Workers agora permitem que a Web também aproveite esse recurso. O processamento de pagamentos também melhorou recentemente na web. Talvez o acesso ao catálogo de endereços e ao calendário chegue à web eventualmente também.

Voltando aos Service Workers por um momento, esta adição recente à caixa de ferramentas do desenvolvedor da Web também tem vários outros truques na manga. Em primeiro lugar, oferece um sistema de cache muito mais robusto do que a web tinha anteriormente com o AppCache. Você pode usar Service Workers para gerenciar solicitações offline, armazenar recursos específicos em cache, sincronizar dados com um servidor remoto quando o usuário não tiver o site aberto e muito mais. Talvez mais do que qualquer outra tecnologia única, os Service Workers permitiram que a web oferecesse uma experiência mais semelhante a um aplicativo.

Os Service Workers são um dos três pilares técnicos dos PWAs. Outro é o Manifesto do Aplicativo da Web. Embora possa parecer um pouco chato, um Web App Manifest é, na verdade, uma ferramenta incrivelmente poderosa, pois permite que um site se anuncie como um aplicativo. Esse formato de arquivo JSON relativamente simples fornece uma riqueza de informações sobre o site que descreve e permite que navegadores e sistemas operacionais compatíveis com PWA instalem o site como se fosse um software nativo.

Algumas lojas de aplicativos estão começando a indexar PWAs, usando seu manifesto para preencher suas entradas associadas. Do ponto de vista do usuário, os PWAs nas lojas de aplicativos não são diferentes dos aplicativos nativos que os cercam. Eles são instaláveis, não instaláveis ​​e podem até expor suas configurações à ferramenta de gerenciamento de aplicativos do sistema operacional subjacente. Também vale a pena notar que os PWAs não precisam que um usuário os instale explicitamente para usá-los porque, bem, eles vivem na web.

Estar dentro e fora da web também significa que os PWAs estão sempre atualizados. Os usuários não precisarão baixar ativamente nada novo para acessar novas funcionalidades. E mesmo quando novos conteúdos e recursos são lançados, é altamente improvável que um usuário precise baixar novamente todo o seu PWA, como faria no caso da maioria dos aplicativos nativos. Se alguma coisa, eles podem obter alguns novos ativos e alguns novos HTML, e isso aconteceria instantaneamente, sem necessidade de loja de aplicativos. Claro, você ainda tem a opção de descoberta e distribuição fornecida pelas lojas de aplicativos, então realmente é o melhor dos dois mundos.

Estar em lojas de aplicativos coloca os PWAs em pé de igualdade com os aplicativos nativos em termos de descoberta, distribuição e monetização. Na verdade, ele pode até proteger a Web sobre nativos, pois os PWAs também podem ser descobertos por meio de mecanismos de pesquisa e são infinitamente mais compartilháveis ​​do que os aplicativos porque existem em um URL. Quando bem construídos, os PWAs também são interoperáveis ​​entre navegadores, plataformas e dispositivos. Os PWAs funcionam até mesmo em navegadores que não oferecem suporte a recursos como Service Workers, porque os recursos do PWA são aprimoramentos progressivos.

A web também oferece suporte de acessibilidade muito maduro, tornando relativamente fácil garantir que seus projetos sejam utilizáveis ​​pelo maior número de usuários. Interfaces complexas exigem um pouco mais de diligência quando se trata de programação, mas os benefícios de acessibilidade proporcionados pelo HTML semântico lidam com a acessibilidade de linha de base com desenvoltura - especialmente quando se trata de produtos pesados ​​de texto, informativos ou baseados em formulários simples. Por outro lado, você quase sempre precisa estar ciente e incorporar APIs de acessibilidade em seu código nativo.

No tópico de desenvolvimento, não acho que haja um vencedor claro quando se trata de experiência de desenvolvimento. Cada idioma tem seus fãs, e o mesmo pode ser dito para ferramentas de desenvolvedor. Você gosta do que gosta e tende a ser mais eficiente com as ferramentas e os idiomas que conhece e pelos quais é apaixonado. Nem a web nem o desenvolvimento nativo têm qualquer vantagem distinta lá.

Onde o desenvolvimento nativo brilha, no entanto, é quando se trata de garantir um nível consistente de qualidade para UIs, construídos usando seus SDKs (Software Development Kits). A maioria dos SDKs nativos oferece ferramentas para testar desempenho, design, funcionalidade e muito mais. Eles também incluem código clichê, sistemas de design e outras ferramentas que ajudam a elevar o nível geral das ofertas de software nativo. Claro, existem ferramentas semelhantes para a web, mas elas estão espalhadas pela web e não são universais em todos os diferentes ambientes de desenvolvimento que as pessoas usam para criar sites. Não existe uma entidade única que defina experiências na web de qualidade e forneça as ferramentas para construí-las (embora muitos tenham tentado).

Quando se trata de pessoal para o desenvolvimento de um produto, é definitivamente mais fácil contratar pessoas que sabem como construir para a web. Enquanto digito, o Índice de Linguagem de Programação atualmente classifica JavaScript como a linguagem mais popular, com Java logo atrás dela. C# está em 5º lugar, HTML em 7º, CSS em 9º e Swift em 15º. Esse índice faz referência cruzada às tags do Stack Overflow com linhas alteradas em repositórios públicos no GitHub, portanto, deve ser considerado com um grão de sal, mas fornece uma indicação bastante clara de que muitas pessoas conhecem (e usam) tecnologias da web. Por outro lado, muitas vezes pode ser um desafio encontrar e contratar desenvolvedores nativos talentosos porque há menos deles e eles estão em alta demanda.

Talento escasso significa que você provavelmente acabará pagando mais pelo desenvolvimento nativo. Cada projeto é obviamente diferente e tem características e requisitos diferentes, mas pode ser ilustrativo olhar para os custos médios de desenvolvimento como uma comparação. A Comentum sugere que a construção de um aplicativo da web de tamanho moderado varia de menos de US$ 10.000 a US$ 150.000. Na ponta nativa, Appster estima que projetos de aplicativos móveis de tamanho moderado custam entre US$ 110.000 e US$ 305.000 para serem construídos. Provavelmente, é seguro assumir que projetos nativos provavelmente custarão cerca de duas vezes mais para serem desenvolvidos do que um projeto da web. E isso é por plataforma. Os aplicativos nativos também costumam levar mais tempo para serem desenvolvidos.

Vale a pena notar que existem opções para construir software nativo usando tecnologias da web sem construir um PWA. Estruturas como React Native, PhoneGap, Ionic e Appcelerator Titanium permitem que você gere código nativo de HTML, CSS e JavaScript. O uso de uma dessas ferramentas pode reduzir seus custos com pessoal e desenvolvimento em comparação com a contratação de uma equipe de desenvolvedores nativos, mas em termos de acesso aos recursos do dispositivo, seu projeto será limitado aos que o framework implementou. Planeje de acordo.

Depois que o aplicativo é desenvolvido, você também deve contabilizar os custos de manutenção contínuos desse aplicativo ou aplicativos. Em resposta a uma pesquisa realizada pela Clutch, a Dom & Tom recomenda orçar 50% do preço inicial do produto no primeiro ano, 25% no segundo ano e entre 15-25% para cada ano seguinte.

Uma vez que você tenha uma compreensão decente de como o desenvolvimento web e nativo se compara e contrasta, você pode começar a avaliar quais pontos fortes e fracos são relevantes para seu projeto. Você provavelmente terá que fazer algumas trocas, e isso é de se esperar. Não existe uma solução única para todos. E se houvesse, não caberia bem em ninguém.

Vamos analisar alguns projetos hipotéticos para trazer as distinções entre desenvolvimento para nativo e PWA mais claramente em foco.

Projeto nº 1: um aplicativo nativo existente

Digamos que você já tenha passado pelo processo de criação de um aplicativo nativo. Se tudo está indo bem, não há razão para mudar de rumo. Não jogue fora todo o seu trabalho existente para mudar para um PWA, a menos que você tenha um bom motivo para fazê-lo. Só consigo pensar em um cenário que pode justificar a mudança para o PWA: trazer suporte para um novo sistema operacional. E mesmo assim, só faz sentido se as necessidades do seu aplicativo puderem ser atendidas apenas pela web.

Se você está adicionando suporte para uma nova plataforma a um produto, isso cria a oportunidade perfeita para avaliar as necessidades e objetivos do projeto em relação ao custo de atender a essas necessidades. Se a web não estiver à altura da tarefa, fique com o nativo. Se for, no entanto, pare e considere o seguinte: Adicionar suporte para a nova plataforma usando um PWA permitiria que você oferecesse suporte a plataformas adicionais (incluindo a Web) no futuro e poderia até mesmo permitir que você substituísse seu aplicativo nativo existente assim que o PWA foi exaustivamente testado.

Se substituir um aplicativo nativo existente por um PWA parece impensável para você, considere o seguinte: a Starbucks e o Twitter já estão explorando essa ideia.

Se houver motivos específicos pelos quais você precisa manter seus aplicativos nativos, ainda vale a pena considerar “terceirizar” determinados recursos de aplicativos para a web. Alguns anos atrás, eu estava trabalhando em um projeto para uma grande empresa de serviços financeiros, e eles optaram por mover o fluxo de login de seus aplicativos nativos para a Web, a fim de permitir que eles implementassem recursos de segurança mais rapidamente do que a loja de aplicativos típica processo de aprovação permitiu-lhes alcançar. Talvez seu projeto tenha necessidades semelhantes que a Web possa capacitar seu aplicativo nativo a atender.

Projeto nº 2: um aplicativo multiplataforma existente

Se você tem um aplicativo existente que funciona em várias plataformas, provavelmente está gastando muito dinheiro com o desenvolvimento e manutenção contínuos desse aplicativo. Você provavelmente também verá alguns recursos de divergência no aplicativo, pois cada plataforma nativa tende a ter seu próprio cronograma de desenvolvimento. O aplicativo da varejista Target, por exemplo, atualmente permite que os usuários gerenciem uma lista de compras no iOS, mas a versão Android não possui esse recurso. De muitas maneiras, é semelhante à divergência que às vezes vemos entre as versões “desktop” e “mobile” de um site.

Se a web já faz parte do seu mix de plataforma cruzada, ela oferece uma boa oportunidade de dobrar seus investimentos e considerar a substituição de seus aplicativos nativos por PWAs. Ferramentas como sonar e Lighthouse podem fornecer informações sobre o quão bem preparado seu site existente está para a certificação de PWA e também podem informar no que você precisa trabalhar. A partir daí, transformar seu site em um PWA é relativamente simples. Existem até ferramentas gratuitas que podem ajudá-lo a atualizar seu site para um PWA em poucos minutos. Se não for, no entanto, não há realmente muito incentivo para fazer esse movimento, a menos que a divergência de recursos entre as plataformas se torne realmente notória ou você esteja pensando em adicionar outra plataforma nativa (ou a web) à mistura.

Projeto nº 3: um novo produto multiplataforma

Se você está iniciando um novo projeto voltado para mais de uma plataforma, criá-lo e mantê-lo em um só lugar como um PWA definitivamente deve estar na mesa. Dependendo do seu orçamento e da equipe, é provável que estenda ainda mais seu orçamento. Dito isto, se o seu produto requer uma conexão direta com o hardware ou o sistema operacional subjacente, você ainda pode precisar ser nativo. Mas antes de seguir esse caminho, faça uma lista de todos os seus requisitos e verifique o que a web pode fazer (e o que não pode). Certifique-se de verificar o suporte em mais de um navegador também.

Projeto nº 4: um novo produto hiperfocado

Se você está construindo um novo produto e parte do propósito desse produto é sua conexão profunda com uma plataforma específica, por favor, construa para essa plataforma. Por exemplo, se o seu produto depende da plataforma de mensagens da Apple ou da integração com o HomeKit, por favor, crie para iOS e/ou macOS no Swift. Se o seu produto atender melhor às necessidades do usuário por meio de um widget ou se você estiver criando um iniciador personalizado, é melhor criar o Android e precisará usar o Java.

Nem todas as características nativas são jardins murados, no entanto. Embora o Alexa da Amazon, o Siri da Apple e o Google Assistant exijam código nativo (ou uma API JSON) para se integrar ao seu aplicativo, curiosamente a Cortana da Microsoft habilitará seu PWA por voz usando apenas um arquivo XML vinculado ao head do seu HTML. Talvez outros sigam seu exemplo.

PWA ou nativo? A escolha é sua

A web e o nativo têm muito a oferecer. Se você me perguntar qual é o melhor, eu simplesmente responderia “Depende” porque depende. Não estou sendo evasivo ou evasivo; descobrir qual é o ajuste certo para o seu projeto depende inteiramente das necessidades específicas do seu projeto. Isso requer levar em consideração o que você está construindo, a composição da equipe existente encarregada de construí-lo ou a equipe que você precisará contratar para fazê-lo e o orçamento com o qual você precisa trabalhar. Em muitos casos, a web provavelmente oferece tudo o que você precisa para atingir os objetivos do seu projeto, mas sempre há exceções. Se você quiser explorar as possibilidades que a web oferece, incluí alguns recursos no final deste artigo.

A coisa mais importante que você pode fazer ao avaliar diferentes abordagens de desenvolvimento de software — ou diferentes frameworks, bibliotecas, linguagens, sistemas de design, etc. — é considerar suas opções em relação ao projeto em questão. Faça sua pesquisa e pese suas opções. E não se deixe influenciar de uma forma ou de outra por marketing inteligente, demonstrações sensuais ou fanboys raivosos. Incluindo este.

Recursos relacionados a PWA

• Construtor de PWA
  Uma ferramenta de criação de site para PWA em 3 etapas com recomendações e receitas úteis. Ele também permite que você transforme seu PWA em aplicativos nativos instaláveis ​​para Windows, Android e iOS.
• Um roteiro progressivo para seu aplicativo da Web progressivo
  Jason Grigsby sobre como sua equipe começou a incorporar aspectos de PWAs em seu site ao longo de vários meses, demonstrando bem como os diferentes recursos podem ser adicionados um pouco de cada vez.
• Sim, esse projeto da Web deve ser um PWA
  Uma visão geral das oportunidades (e riscos) de UX dos PWAs, escrita por você.
• Aplicativos da Web progressivos no MDN
  Um hub para todos os detalhes técnicos que você precisa saber sobre o que caracteriza um PWA de qualidade.
• O que a Web pode fazer hoje
  Dê uma olhada nas APIs que seu dispositivo, SO e navegador suportam. O que você encontrar pode surpreendê-lo.
• Eu posso usar
  O banco de dados definitivo de quais APIs e recursos estão disponíveis em todos os principais navegadores e como esse suporte é medido em relação aos navegadores que as pessoas estão realmente usando. Ele também pode fornecer uma excelente visão de volta no tempo para ver como certos recursos são compatíveis com versões anteriores.