Chrome Summit 2016

Então pessoal, como alguns de vocês já sabem, tive o prazer de ir ao Chrome Summit em novembro, na Califórnia, e trouxe comigo muitas novidades. Além do Chrome Summit, participei também de outros eventos. Compartilharei as novidades com vocês mais para frente. Confere algumas fotos que tirei lá.

Todas as palestras estão disponíveis em vídeo no site do evento.

Mas aqui vai um resumo de minhas impressões (em português) sobre algumas das palestras. Tentei fazer o conteúdo ser ÚTIL, não apenas um "resumão".

Experiências

Rahul Yadav falou sobre o Lyft (ferramenta para transporte terrestre concorrente do Uber) e a implementação de sua app na Web. Ele focou bastante na Índia, e realçou o fato de que apps instaladas nos dispositivos ocupam muito mais espaço. Ele comentou também sobre a Web em mercados emergentes. Interessante ressaltar que a própria Lyft diz ter recebido em sua página na web um tráfego 5x maior que o esperado e, por isso, resolveram investir em torná-la uma PWA.

Em outra palestra, Thao Tran fala sobre os contatos com diversas empresas justamente a respeito de PWAs. Entre os exemplos, falaram da FlipKart que passou a ter muito mais acessos mobile em sua página web do que tinha em sua app!

Outra curiosidade veio do MakeMyTrip, site de reservas de hotéis. Eles perceberam que 80% das pessoas que acessavam seu site estavam procurando reservas para o mesmo dia (reservas de última hora). Quando disponibilizaram uma PWA, o número de reservas foi 3x maior que o número de reservas na App! Isto indica que as pessoas não estavam dispostas a baixar ou a instalar uma app simplesmente para fazer uma única reserva para o dia seguinte e, depois, desinstalar. Mas uma PWA era muito mais viável.

Na apresentação de Robert Nyman, ele comentou que, pela primeira vez, o time do Blink fechou mais bugs do que foram abertos. Eles estão focados em "arrumar a casa". Eles estão trabalhando muito no que chamam de predictability, e estão cuidando muito para que não sejam lançadas tecnologias que se tornem "chrome-only". A ideia é justamente contar com a colaboração e contribuição de outros navegadores para tornar a Web melhor e, para isto, precisamos planejar antes de sair executando.

Progressive Web App

Algo que percebi é o verdadeiro foco em PWAs (Progressive Web Apps). Isso é ótimo e é algo que tenho focado bastante meus estudos ultimamente. [spoiler alert] Sim, preparem-se para uma coleção de artigos sobre o tema muito em breve ;)

Já Jeff Posnick aproveitou para falar de algumas ferramentas para auxiliar no desenvolvimento com Service Workers, como o sw-precache e o sw-toolbox.

Ele falou também de um plugin para webpack e do polymer starterkit.

Além disto, estão trabalhando no lançamento do que será um "sw-framework".

Ele realçou também a importância de usarmos o lighthouse.

Aqui, quero lembrar que temos o DSW, projeto brazuca e da comunidade que oferece as mesmas funcionalidades e algumas coisinhas mais. São abordagens diferentes (o DSW tenta ser mais simples e objetivo, enquanto o sw-framework tenta ser... um framework mesmo). Não deixe de ler sobre todas as alternativas, de testá-las e, porque não, de enviar um feedback ou até mesmo contribuir com o projeto.

Durante outro evento que participei lá (o GDE Summit, evento para Google Developer Experts, programa do Google do qual faço parte), tive a oportunidade de apresentar uma palestra justamente sobre o DSW.

Números

Durante o evento vários dados importantes foram apresentados. Serviços como Alibaba notaram 76% no aumento de conversão (vendas online efetivamente) ao passar a usar ServiceWorkers em suas páginas.

Um dado muito relevante é que 53% dos usuários abandonam sites que levam mais de 3 segundos para carregar. A questão é que, há apenas um ano, este número era de menos de 40%, ou seja, usuários estão cada vez com menos paciência. Junte isso ao fato de que a média de carregamento das páginas é de 19s (sim... DEZENOVE SEGUNDOS)! E cerca de 77% das páginas mobile levam, em média, mais de 10 segundos para tornarem-se interativas.

Sabe-se também que 50 mil domínios já estão usando push notifications.

Uma coisa que eu ainda não havia visto e que achei impressionante foi um cálculo do custo que uma empresa pode ter ao investir em PWAs ou em Apps nativas. A housing fez os cálculos e percebeu que cada usuário que baixava sua app custava US$3,75 (com base no custo do desenvolvimento da app, manutenção, divulgação, etc). Já ao tornar sua página uma WebApp, o custo para cada usuário que instalava a PWA era de US$0,07!

Ainda na dúvida se vale o investimento na Web? Bem, eles comentaram também que o tamanho da sua App para Android era de 17MB, e para IOS era de 75MB ( !! ) ... enquanto que, para Web, era de ~1MB.

Na Índia, estima-se que 90% dos usuários desinstalam apps em até 6 meses.

Uma frase que ouvi durante o evento (de Alex, citado mais abaixo) foi:

Se em até 1 segundo, eu não posso clicar em um botão na sua página e ver algo acontecer, sua pagina não está carregada - mesmo que visualmente pareça estar. Ela está quebrada!

APIs

Algumas palestras focaram bastante em APIs. Algumas destas APIs já estão descritas em português nesta coleção de artigos sobre APIs.

Além de sensores, falaram bastante em duas APIs em especial (escreverei um artigo focado nelas em breve). São a Credential Management API e a Payment API.

O Jake Archibald, que palestrou na BrazilJS desse ano, falou um pouco mais sobre ServiceWorkers, mas também falou de várias APIs que ainda estão apenas no "imaginário". Citou eventos como backgroundfetch, transitionUntil e interactive. Coisas que ainda estão sendo discutidas e, quem sabe, um dia ainda veremos em algum navegador beta, alpha, nightly...

Código

Aconteceram também palestras bem técnicas, como a do Paul Irish, que falou sobre as novidades na atualização do Chrome DevTools, e palestras sobre WebComponents e o lançamento do Polymer 2.0. Aliás, uma das coisas mais legais do Polymer e do novo visual do webcomponents.org é que agora os próprios demos tem códigos editáveis.

O Alex Russel deu uma palestra muito legal também sobre a valorização do JavaScript mais simples e leve. Ele, inclusive, comenta sobre "jogarmos fora" nossos frameworks sempre que eles não forem estritamente necessários. Pessoalmente, isso é algo que venho dizendo há tempos e concordo com ele :)

Use VanillaJS e descubra quão rápido um browser pode ser.

Mas ele vai além. Fala sobre como devemos testar nossas páginas web em dispositivos de verdade (não apenas em simuladores e emuladores, pois eles mentem). Em um experimento, Alex colocou o celular sobre uma bolsa de gelo, e ele passou a carregar páginas 15% mais rápido. A temperatura do processador influencia muito. Dissipadores tradicionais em processadores normalmente conseguem dissipar o equivalente a 60W (o que seria capaz de acender uma lâmpada... ou de queimar uma mão), mas celulares não têm espaço para se darem ao luxo de ter um dissipador sobre seus processadores (algumas vezes, usando a própria capa do celular para dissipar o calor, os botões, ou até mesmo a placa principal.

Uma outra frase de impacto dele foi

Se você está usando algum framework para fazer algo muito simples, você errou, por padrão.

E...

Mobile hates you...fight back!

(dispositivos mobile odeiam você, reaja!)

HTTPS

Nós já ressaltamos na BrazilJS sobre a importância de usar HTTPs, e o Google deixou isso ainda mais claro.

Usuários passam cerca de 75% do tempo em páginas https em dispositivos não mobile, mas no Android, fazem apenas 30% de sua navegação (em browsers) em páginas seguras. Acredita-se que isso aconteça porque boa parte da navegação mais segura que usamos (e-mails, redes sociais, microbloggers, etc) sejam usadas mais em apps instaladas que em navegadores mobile. Mas esse número está aumentando.

O Chrome passará a exibir uma notificação um pouco mais chamativa para páginas não HTTPS e, uma mensagem BEM chamativa para páginas não HTTPS que contenham formulários. E o Firefox já anunciou que fará o mesmo.

A intenção é exibir mensagens assim também para páginas em HTTP que façam download de arquivos e, em breve, para todas as páginas HTTP.

#httpsEverywhere

E para aqueles preocupados com performance, o site Is TLS Fast Yet tem várias informações muito úteis.

Mais sobre performance

Sam saccone falou ainda um pouco mais sobre performance, sobre a importância de usarmos link rel=preload e como podemos fazer para usarmos CPU Throttling (palavrinha fácil essa, né?) usando o Chrome DevTools.

Alguns dados muito interessantes trazidos por ele foi em relação ao tempo que o device leva para processar o JavaScript, não apenas para baixá-lo.

Por exemplo, 300kb de JavaScript levam de 300ms a 500ms para serem processados pela engine de parser do navegador. Um script de 1MB chega a levar até 2500ms, e isso após o download. Acha que é só para casos de "celulares fracos"? MacBook Pro leva em média 400ms para processar um script de 1MB.

Ele cita também exemplos com Webpack, React e Redux e como alguns Frameworks já têm a opção de lazy-loading de scripts, ou bundles. Code-spliting é bem importante também (falamos sobre code spliting com o splittable justamente na BrazilJS Weekly desta semana.

Addy Osmani também falou sobre performance e mostrou alguns resultados ao usarmos certos Frameworks. Resultados bem impressionantes! Ele utilizou o projeto source map explorer para mapear um projeto que usava React e a visualização ficou assim:

Mas se você está pensando que fizeram isso apenas para tentar te convencer a usar Angular no lugar de React, bem, eles falaram to Preact e o defenderam mostrando que seu bundle era muito otimizado.

Mais uma vez, falou-se sobre testar em dispositivos físicos de verdade, não apenas em simuladores.

Paul Bakaus falou sobre PWAs + AMP e salientou que, sim, é possível desenvolvermos um site que usufrua de ambas as tecnologias.

Outra coisa que estão focando muito por lá, é sobre estes três possíveis estados no carregamento de uma página:

• first paint: exibiu algo para o usuário, ele não está vendo apenas uma aba do navegador em branco.

• first meaningful paint: exibiu algo útil ao usuário, como um menu, título, resumo, algo do conteúdo.

• interactive: o usuário pode realmente clicar em algo, interagir com a página.

Adentrando-nos no V8, engine JavaScript do Blink, no Chrome, Seth Thompson comenta sobre os testes feitos até então nestas engines, por meio de microbenchmarks, e que eles simplesmente não estavam mostrando a realidade da performance no V8. O Google instrumentalizou o V8 para realizar testes por samplings. Lançaram assim, o Ignition, uma camada que fica acima do V8 e pré-compila o script. Uma vantagem aqui é que a equipe de desenvolvedores pode agora otimizar esta camada, sem precisar colocar uma nova versão inteira do V8 no ar.

É claro que citações a async e await não faltariam, e também foi anunciado que, na versão preview do Chrome (apenas para 2017), haverá suporte para webassembly e asm.js.

Concluindo

Foi um evento muito legal, com um networking fantástico e foi ótimo reencontrar uma galera que não via fazia tempo e, é claro, fazer novos contatos. Acho que este é, para mim, um dos principais motivadores para ir a um evento. :)

E foi ótimo também ver quanta gente lá, entre participantes e palestrantes vindos de todo canto do mundo, que já conhecia a comunidade brasileira de JavaScript e já tinha ouvido falar do trabalho que temos feito com a BrazilJS. Foi um feedback muito importante. Além disso, notamos também que muito do que estamos fazendo, falando ou escrevendo por aqui, são justamente os temas abordados lá. Isto quer dizer que estamos no caminho certo, que estamos nos mantendo no mesmo ritmo que eles, e aqui, me referencio a nós como comunidade, como Desenvolvedores Web brasileiros.