Quando as mudanças ocorrem gradualmente, passo a passo, às vezes é difícil ver quão dramáticas e abrangentes elas são. Parece que apenas alguns anos atrás a plataforma da Web estava perdendo o aplicativo nativo em quase todas as frentes, e a diferença entre o que poderia ser feito no navegador e o que estava disponível por aplicativos baixados de lojas como a Apple App Store ou Google Play Store, era terrivelmente grande. Uma das evidências desse abismo é que, em 2007, a web era de fato a principal plataforma de desenvolvimento de aplicativos para o primeiro iPhone, mas essa plataforma claramente não decolou. A App Store apareceu apenas um ano depois da segunda versão do sistema operacional e imediatamente houve um boom de aplicativos nativos, que formaram o cenário de mercado como o conhecemos agora.
Muita coisa mudou desde então, e as tecnologias da web não pararam. Eles seguiram o caminho da remoção de restrições e o que antes era impossível em princípio - trabalho offline, sincronização de dados em segundo plano, notificações push, suporte para login e pagamento com um clique usando cartões de crédito, Apple Pay, Google Pay e outros métodos integrados o navegador agora é uma realidade. Essas funções complementam organicamente a parte principal da plataforma - HTML / CSS e JavaScript, que nos últimos anos vem se desenvolvendo em um ritmo mais do que ativo. Por exemplo, o novo projeto Houdini , que ainda está em um estágio bastante inicial, remove quase todas as restrições sobre o que pode ser feito usando CSS, possibilitando, entre outras coisas, criar seus próprios layouts e usá-los em pé de igualdade com o Grid e o Flexbox e abrir acesso programático aos CSS internos motor. Mas mesmo sem o Houdini, você pode criar animações CSS que funcionam a 60 FPS (quadros por segundo).
O desenvolvimento contínuo de padrões da Web atraiu os desenvolvedores. Muitas pessoas com boas razões acreditam que o desenvolvimento de tecnologias da Web é mais rápido, fácil e barato. Portanto, se você procurar, por exemplo, aplicativos de desktop modernos, veremos que a maioria deles está escrita em Electron, uma estrutura que permite escrever aplicativos para Windows, Linux e macOS baseado na Web. Exemplos de aplicativos da Electron são o Visual Studio Code, Slack, Skype na área de trabalho etc.
Por outro lado, a plataforma cruzada, que é parte integrante das tecnologias da Web, agora é mais relevante do que nunca. O suporte para bases de código independentes separadas para iOS e Android é muito caro. Portanto, mesmo para aplicativos nativos, os desenvolvedores estão cada vez mais escolhendo tecnologias de plataforma cruzada, como o React Native, o Xamarin ou o Flutter do Google (se você é um desenvolvedor móvel e ainda não viu o Flutter , recomendo fazer isso, apenas para fins educacionais). E com a PWA , conseguimos o que todo mundo sempre sonhou - aplicativos verdadeiramente multiplataforma.
Falando sobre remover as limitações da plataforma da web, não podemos deixar de mencionar o WebAssembly. Agora, graças a essa tecnologia, praticamente não há restrições à velocidade de execução do código no navegador e nas linguagens de programação usadas. Já é possível obter desempenho apenas metade do código C nativo que funciona diretamente no sistema operacional e esse não é o limite. Obviamente, isso não significa que você precisa jogar fora o JavaScript e mudar para escrever interfaces de usuário em C ou Rust, pois o pacote JavaScript + Angular, React ou Vue.js é extremamente eficaz para esses fins e o próprio JavaScript (ECMAScript), disponível hoje para nós - na verdade, é uma linguagem completamente nova, conveniente e moderna, com suporte para async / waitit, a sintaxe usual de classe, a desestruturação, as seqüências de modelos e muito mais. Mas o WebAssembly traz desempenho em segmentos críticos, como jogos, AR / VR, inteligência artificial, processamento de áudio e vídeo para desempenho nativo, e custa muito. Além disso, agora é muito mais fácil portar códigos existentes em C, C ++, Rust, C # e outras linguagens de programação para o navegador. Um bom exemplo dessa transferência é o AutoCAD, lançado recentemente , que funciona em um navegador usando o WebAssembly.
É importante ter um ambiente de tempo de execução rápido (com acesso direto à placa de vídeo) no dispositivo pelo motivo de que, dados os requisitos modernos de privacidade e segurança, quando alguns dados simplesmente não conseguem sair do cliente e ir para o servidor, todos os dados devem ser processados no cliente aplicação. Por exemplo, se ouvirmos um microfone em antecipação a uma frase-chave ou analisarmos o fluxo da câmera, é improvável que os usuários concordem em enviar todo o som e vídeo ao servidor para processamento. Agora, temos acesso a bibliotecas como o TensorFlow.js , que permitem não apenas lançar modelos treinados (redes neurais) no navegador, mas também treinar esses modelos diretamente no cliente. O que em muitos cenários aumenta a segurança e a privacidade e reduz a carga do servidor.
Outra área na qual as limitações da plataforma da Web são tradicionalmente manifestadas é o acesso ao sistema operacional e os recursos de hardware do dispositivo do usuário. Mas aqui, as restrições são gradualmente apagadas, embora deva-se admitir que no iOS elas apagam muito mais lentamente do que no Android. Se falamos sobre interação com o sistema operacional, a API da área de transferência para trabalhar com a área de transferência apareceu recentemente, a API de apresentação para detectar a conexão de um segundo monitor / projetor e controlar o que é exibido nele, a API de compartilhamento da Web para integração com a caixa de diálogo de compartilhamento do sistema (enquanto aplicativos da Web pode atuar apenas como uma fonte, mas há trabalho em andamento no recebimento de dados, a API de destino do compartilhamento da Web pode ser testada no Chrome incluindo os recursos da Plataforma da Web experimental em aproximadamente: sinalizadores). Por falar em sensores e transferência de dados, temos acesso à API Bluetooth da Web para trabalhar com dispositivos físicos localizados nas proximidades (que é muito usado ativamente em soluções IoT), bem como à nova API de sensor genérico para trabalhar com vários sensores, como acelerômetro, giroscópio , sensor de luz, bússola e outros. E não mencionei os padrões da web que estão conosco há muito tempo, como trabalhar com câmera e microfone, suporte a vibrações, obter informações sobre a bateria, tipo e velocidade da rede e a memória disponível do dispositivo do usuário.
Graças a todas essas mudanças e inovações, agora os aplicativos da Web e nativos não são mais divididos pelo abismo. Agora eles estão ombro a ombro.
Mas não tome minhas palavras como um sinal de que os recursos de aplicativos nativos e plataformas da Web são iguais. Grosso modo, se há cinco anos a plataforma da Web oferecia oportunidades suficientes para 20% dos aplicativos (aqui, quero dizer aplicativos que exigem lógica complexa, e não sites com conteúdo - nesses casos, há AMP - Páginas Móveis Aceleradas e tecnologias semelhantes, cobrindo cenários de conteúdo de blogs e sites de notícias a lojas on-line e sites de várias instituições e organizações, quase cem por cento) e, em outros casos, era necessário criar soluções nativas, agora os recursos da plataforma web são suficientes em 70-80% com Uchaev. E para um número crescente de aplicativos, os desenvolvedores têm uma escolha. Geralmente, essa opção é a coexistência do PWA e do aplicativo nativo, como é o caso do Uber, Starbucks, Aviasales, Twitter, Tinder, Google Maps, AliExpress e outros.
Fonte: https://twitter.com/necolas/status/829128165314306048
Quais são esses recursos que exigem a criação de aplicativos nativos ou, pelo menos, o empacotamento de aplicativos da Web usando o Apache Cordova ou outros meios de distribuição nos armazenamentos de aplicativos?
- Trabalhe com contatos e calendário no dispositivo do usuário.
- Enviando / recebendo SMS, fazendo chamadas telefônicas diretamente do aplicativo. Interação com o cartão SIM do telefone.
- Trabalhar com NFC
- Geofencing
- Trabalhe com o flash e sensores não padrão, como sensor de pressão, monitor de batimentos cardíacos, etc.
- Trabalho de baixo nível com o sistema - gerenciamento de aplicativos, configurações do sistema, acesso total ao repositório.
- Crie teclados e widgets.
- Registrando o aplicativo como o aplicativo padrão para abrir qualquer tipo de arquivo ou tipo de link.
Naturalmente, esta é uma lista incompleta. Por outro lado, não tenho dúvidas de que muitos desses recursos estarão disponíveis para a plataforma da Web em um futuro muito próximo. Mas você não deve esperar que os sistemas operacionais e suas plataformas também fiquem parados. Sim, a lacuna será reduzida, mas sempre haverá algo disponível apenas para aplicativos nativos. Portanto, se você é um desenvolvedor de dispositivos móveis com foco no iOS ou Android, é vital que você esteja sempre um passo à frente para que seus aplicativos sejam os melhores do mercado.
Não esqueça que os aplicativos da Web possuem recursos que não estão disponíveis para nativos. Isso se refere principalmente à distribuição de aplicativos, ao custo de atração de usuários e à ausência de dependência da vontade do proprietário da loja de aplicativos e à velocidade de verificação de atualizações pela loja. Sim, de acordo com as estatísticas, os usuários de dispositivos móveis passam muito mais tempo em aplicativos e menos no navegador, mas, em média, metade dos usuários instala 0 (zero) novos aplicativos por mês, e a maior parte do tempo gasto em aplicativos é contabilizada por gigantes como o Facebook . Por outro lado, os usuários visitam mais de uma centena de sites diferentes por mês e visitam facilmente novos sites. Portanto, o custo de atrair um usuário para um site (aplicativo da Web) pode ser até dez vezes menor que o custo de atrair um usuário para um aplicativo baixado de uma loja. A tecnologia Google Play Instant resolve parcialmente esse problema, permitindo que você execute aplicativos nativos do Android por meio de um link de um navegador, ignorando a loja e sem instalação. Tais aplicativos naturalmente têm funcionalidade limitada, mas oferecem uma conversão muito boa. O que apenas confirma a hipótese de que o modelo de distribuição de aplicativos da web é uma vantagem. Embora a presença nas lojas de aplicativos, especialmente no topo das classificações, também permita atrair usuários, mas agora funciona muito pior do que há dez anos, pois há muito mais aplicativos nas lojas.
Se você precisar da presença do seu aplicativo da Web (PWA) nos armazenamentos de aplicativos, isso também será possível. A Microsoft Store já suporta a adição do PWA. No caso de outras lojas, você pode compactar o aplicativo manualmente ou usar uma ferramenta pronta, como o site pwabuilder.com, que permite, entre outras coisas, gerar pacotes do PWA com base no Apache Cordova para a Apple App Store e Google Play. Além disso, em versões futuras do Chrome para Android, haverá uma capacidade sistemática de incorporar o PWA em aplicativos Android usando o mecanismo Atividades da Web confiáveis .
Aplicativos Web progressivos em 2018
Ao falar sobre aplicativos da Web que se aproximam dos nativos em termos de experiência do usuário, interface, velocidade e recursos, eles usam o termo PWA - Progressive Web Apps . O PWA não é algum tipo de estrutura ou SDK. É uma abordagem ou, se você preferir, uma filosofia de como criar aplicativos da web modernos.
Do ponto de vista tecnológico, o PWA usa modernos padrões da Web disponíveis nos navegadores e nada mais. A abordagem do PWA não impõe nenhuma restrição especial aos próprios aplicativos da web. Por exemplo, os PWAs podem ser aplicativos de página única (SPA) ou podem não ser. É importante que todos os usuários possam interagir com seu aplicativo, e a abordagem de melhorias graduais (progressivas) é usada - quanto mais moderno o navegador do usuário, mais oportunidades ele terá.
O principal recurso do PWA e o fato de nos permitir chamar o aplicativo da Web de nome orgulhoso do Progressive Web App é o suporte ao trabalho offline usando o mecanismo Service Worker e a capacidade relacionada de adicionar o ícone do aplicativo à tela inicial do dispositivo do usuário (não queremos adicionar a tela inicial do aplicativo do dispositivo que não será carregada sem uma conexão com a Internet?).
Os funcionários de serviço oferecem uma oportunidade única de executar o código separadamente das páginas do seu site, mesmo quando as páginas podem ser fechadas (mas você não poderá executar o código em segundo plano por um período arbitrariamente longo, mesmo assim, as restrições são significativas). E essa oportunidade encontra mais e mais aplicativos em novos padrões da web.
No campo da implementação de padrões da Web relacionados ao PWA, na primavera de 2018, uma revolução aconteceu. O termo PWA tem sido amplamente usado por vários anos, mas anteriormente era aplicado apenas ao navegador Google Chrome, e o trabalho offline era inicialmente suportado tanto na área de trabalho quanto no Android, mas a instalação de aplicativos funcionava apenas no Android. Muitos desenvolvedores ainda percebem o PWA como pura tecnologia Android. Mas no iOS 2018, lançado em março de 2018, a Apple adicionou o suporte do Service Worker ao Safari móvel. Também foi adicionado suporte ao Safari para macOS. A Microsoft, por sua vez, um mês após a Apple, em abril de 2018, adicionou suporte para Service Workers ao seu navegador Microsoft Edge. Além disso, o Windows 10 agora oferece suporte à distribuição do PWA através da Microsoft Store. A próxima etapa, esperamos a possibilidade de instalar o PWA na área de trabalho a partir de navegadores em todas as plataformas, e não apenas no Chrome OS, onde já funciona.
Você pode testar a instalação na área de trabalho incluindo os sinalizadores de PWAs e Banners de aplicativos ou Banners de aplicativos experimentais em: banners no Chrome. Depois de ativar esses recursos experimentais, a interface de instalação do PWA da área de trabalho no Chrome na área de trabalho será semelhante à captura de tela abaixo.
Com o advento do PWA na área de trabalho, eles provavelmente ocuparão parte do nicho que a Electron agora domina.
Portanto, agora você pode fornecer trabalho offline usando o mecanismo Service Worker nos iOS, Android, Windows, Linux, macOS e Chrome OS nos navegadores Chrome, Safari, Firefox, Edge e Samsung na Internet. E em todas as plataformas móveis, a adição do ícone do aplicativo à tela inicial já é suportada.
Fonte: https://caniuse.com/#feat=serviceworkers
Há meio ano, era difícil imaginar que a introdução de tecnologias relacionadas à PWA fosse tão rápida. Na captura de tela abaixo, você pode ver parte da tela inicial do iOS com ícones do PWA, indistinguíveis dos aplicativos nativos instalados na loja. E quero enfatizar separadamente que, falando sobre iOS, quero dizer, tanto o iPhone quanto o iPad - não há diferença no suporte ao PWA entre o tablet e o telefone.
Fonte: https://medium.com/@firt/progressive-web-apps-on-ios-are-here-d00430dee3a7
Além de implementar padrões modernos da Web em vários navegadores, há mudanças e melhorias no trabalho do PWA no Chrome. E se a exibição do ícone de instalação do PWA no OmniBox (barra de endereços e barra de pesquisa) ainda estiver em desenvolvimento, a instalação do PWA no Android usando o mecanismo WebAPK (APK - Pacote Android, contêiner de aplicativos Android) já funcionará. Inicialmente, o PWA após a instalação era apenas um atalho do navegador na tela inicial. Agora, este modo também é suportado. Os atalhos do PWA contêm um pequeno ícone do navegador no canto. Mas agora o principal método de instalação é o WebAPK. Em essência, o PWA no Android se torna aplicativos completos gerados em tempo real durante a instalação. E os PWAs agora são exibidos não apenas como um atalho na tela inicial, mas também são mostrados junto com outros aplicativos nativos instalados na lista de todos os aplicativos. Embora o mecanismo WebAPK não permita o acesso a nenhum recurso nativo do sistema operacional que não seria acessível no navegador (exceto no suporte à abertura de links do domínio do qual o PWA foi carregado, no próprio PWA e não no navegador), mas no fato de o PWA do ponto de vista do sistema operacional são aplicativos completos, ele não pode deixar de se alegrar.
A maturidade da tecnologia Service Worker também confirma o fato de que todas as ferramentas populares do SPA (aplicativos de página única) suportam a geração de Service Workers em um comando, como é feito na CLI Angular, ou mesmo geram o Service Worker padrão, como em caso com create-react-app. Por outro lado, muitos desenvolvedores desejam entender melhor o que, como e quando é armazenado em cache no aplicativo, para que desejem escrever o código do Service Worker por conta própria. Mas isso não é uma boa ideia, repleta de erros difíceis de reproduzir e, como resultado, os usuários podem ficar com uma versão em cache desatualizada do aplicativo. Uma opção intermediária, e do meu ponto de vista, é usar bibliotecas prontas para implementação de estratégias de cache e sincronização em segundo plano, mas que oferecem liberdade máxima para os desenvolvedores. A mais popular dessas bibliotecas no momento é a Caixa de Trabalho . Por exemplo, com a Caixa de trabalho, armazenamento em cache de imagens e, para que não haja mais de sessenta no cache, por até trinta dias, fica assim.
workbox.routing.registerRoute( /\.(?:png|gif|jpg|jpeg|svg)$/, workbox.strategies.cacheFirst({ cacheName: 'images', plugins: [ new workbox.expiration.Plugin({ maxEntries: 60, maxAgeSeconds: 30 * 24 * 60 * 60, // 30 Days }), ], }), );
Não pense que implementar o trabalho e o cache offline implica oferecer suporte a cem por cento da funcionalidade do aplicativo no modo offline, embora isso também seja possível e possa ser um bom objetivo a longo prazo. O principal é que, na ausência de uma conexão com a Internet, os usuários não têm a impressão de que o aplicativo não funciona (o pior de tudo é que eles vêem um dinossauro no Chrome, indicando a impossibilidade de fazer o download). Portanto, tudo, desde exibir o aplicativo em cinza com uma mensagem sobre a falta de uma conexão com a Internet até implementar todas as funcionalidades offline, é uma boa opção.
Levado pelo cache, você também não deve esquecer que ele acelera significativamente apenas a segunda carga do seu aplicativo (e, é claro, permite adicionar suporte ao trabalho offline). Portanto, se você realmente deseja melhorar a experiência do usuário, precisa acelerar o primeiro download o máximo possível. Uma maneira de fazer isso é a renderização do servidor. Graças à renderização no servidor, o usuário poderá ver imediatamente o conteúdo do aplicativo, o que reduz a probabilidade de o aplicativo ser fechado antes do carregamento, porque o usuário se cansará de esperar. E aumenta a probabilidade de uma segunda chamada e, como resultado, dá esperança de que o esforço despendido no suporte ao armazenamento em cache seja realmente necessário. Portanto, seus aplicativos da web devem ser isomórficos - para que o mesmo código JavaScript possa funcionar no lado do cliente e no servidor.
Então, você decidiu que seu próximo aplicativo Web será o PWA. Surge a pergunta: quais são as possibilidades de implementação dos trabalhadores em serviço? Se você estiver desenvolvendo um novo aplicativo, recomendo que você comece a adicionar recursos na ordem em que estão listados na lista abaixo. Todos esses recursos fazem sentido para o usuário, juntos e separadamente.
Mas primeiro, leia a lista de verificação do Google , que descreve os principais recursos de bons aplicativos da web.
Se você já possui um aplicativo existente ou se está desenvolvendo um novo aplicativo Web, recomendo começar com uma auditoria. Isso pode ser feito usando a ferramenta Lighthouse , disponível para lançamento nas Ferramentas do desenvolvedor do Chrome (guia Auditorias), bem como um pacote NPM. O Lighthouse automatiza muitas das verificações da lista de verificação. Idealmente, você não deve apenas começar com uma auditoria usando o Lighthouse, mas também integrá-la ao processo de construção. O Lighthouse permite que você veja os pontos fortes e fracos de seu aplicativo da Web e também ajuda a obter idéias sobre quais outros recursos, padrões da Web e práticas recomendadas podem ser implementados.
Se você quiser experimentar alguns recursos completamente experimentais, use o mecanismo Trials do Origin no Google Chrome. Usando esse mecanismo, após enviar e aprovar um aplicativo, você pode ativar novos padrões experimentais da web para os usuários do seu aplicativo da web. Esse mecanismo é usado para testar os padrões da Web não para toda a Internet (já que nesse caso será muito difícil fazer alterações ou abandonar completamente o padrão), mas apenas para um número limitado de sites selecionados que estão interessados nesses padrões. No momento da redação deste artigo, estava disponível um teste de origem, por exemplo, para a WebXR Device API, um novo padrão para realidade mista que suporta AR (realidade aumentada) e VR (realidade virtual).
Conclusão
Na última década, as tecnologias da Web passaram do estágio de esperanças e expectativas do domínio universal da Web 2.0 e HTML5 (eu me pergunto se alguém está usando esses bizvords agora?) Quando Steve Jobs declarou em 2007 que “Você não precisa de um SDK. Você tem tudo o que precisa (se você sabe escrever aplicativos usando os mais recentes padrões da Web) para escrever aplicativos impressionantes do iPhone hoje. ”, No estágio de frustração de 2010-2013, quando Chris Anderson, da revista Wired, em 2010, disse que“ Por mais que gostemos de web aberta e ilimitada, a recusamos em favor de serviços mais simples e elegantes [aplicativos nativos] que simplesmente funcionam ”. E Mark Zuckerberg em 2012 observou que“ o maior erro que cometemos como empresa é Apostar no HTML5, não no ativo ".
Mas a noite mais escura acontece antes do amanhecer, e para as tecnologias da Web em concorrência com aplicativos nativos, esse amanhecer foi o movimento associado aos Aplicativos Web Progressivos. Agora, em 2018, todos os navegadores já suportam os principais recursos do PWA - trabalhando offline e instalando na tela inicial em dispositivos móveis. Os PWAs funcionam em qualquer lugar, são independentes das lojas de aplicativos e fornecem uma experiência de usuário nativa próxima. E assim o Gartner prevê que "os PWAs substituirão 50% dos aplicativos de uso geral". Mas não exagere nas expectativas, você quase certamente pode dizer que cem por cento do mercado de PWA não serão ocupados.
Agora, o PWA é uma vantagem competitiva. Por exemplo, o Twitter da PWA aumentou o número de páginas visualizadas por sessão em 65% . Graças à PWA, Lancome aumentou a conversão em 17% . O OLX mostrou resultados ainda mais impressionantes e aumentou os reengajamentos em 250%. E existem muitos exemplos. Em breve, a disponibilidade do PWA será simplesmente necessária para qualquer negócio sério e a ausência será percebida como uma desvantagem significativa.
Sergey Pugachev, especialista em desenvolvedores do Google
PS. O artigo é da opinião pessoal do autor e pode não coincidir com a opinião de empregadores anteriores, presentes ou futuros;)