Smashing Podcast Episódio 45 Com Jeremy Wagner: O que é JavaScript responsável?

Este episódio foi gentilmente apoiado por nossos queridos amigos do Wix, a plataforma para profissionais criarem sites de clientes, gerenciarem projetos complexos e expandirem negócios online. Obrigado!

Neste episódio, estamos falando sobre JavaScript responsável. O que significa para o código ser responsável e como devemos abordar os projetos de maneira diferente? Falei com o especialista Jeremy Wagner para descobrir.

Mostrar notas

• Site JavaScript responsável
• Compre o livro na A Book Apart
• Site pessoal de Jeremy
• Jeremias no Twitter

Atualização semanal

• Lei de Fitts na era do toque escrito por Steven Hoober
• Web Design Feito Bem: Perfeitamente Inútil escrito por Frederick O'Brien
• Tudo o que você quer saber sobre como criar interfaces de usuário de voz escrito por Nick Babich e Gleb Kuznetsov
• Implicações do WordPress juntando-se ao protocolo Block escrito por Leonardo Losoviz
• Pensamentos sobre Markdown escrito por Knut Melvar

Transcrição

Drew McLellan: Ele é um redator técnico, nerd de desempenho na web, desenvolvedor e palestrante, atualmente trabalhando no Google. Ele escreveu para A List Apart, CSS-Tricks e Smashing Magazine, e é o autor de um novo título, Responsible JavaScript for A Book Apart. Então, sabemos que ele é um técnico e comunicador habilidoso, mas você sabia que ele quer dar a volta ao mundo em uma prancha de standup paddle? Meus amigos, por favor, dêem as boas-vindas a Jeremy Wagner. Olá Jeremias, tudo bem?

Jeremy Wagner: Estou arrasando. Como você está?

Drew: Estou muito bem. Obrigada. Eu queria falar com você hoje sobre essa ideia de JavaScript Responsável. Isso é algum tipo de nova abordagem ou técnica, ou você está literalmente falando sobre usar JavaScript com responsabilidade?

Jeremy: Estou falando literalmente sobre usar JavaScript com responsabilidade. Assim, de acordo com o arquivo HTTP, vimos um aumento médio de quase 58% na quantidade de JavaScript baixado por dispositivos móveis de aproximadamente 290 kilobytes para quase 500 kilobytes no ano passado.

Drew: Uau.

Jeremy: Então, quando eu falo sobre o uso de JavaScript de forma responsável, é um tipo de abordagem do usuário que diz… avaliar criticamente o que estamos construindo e é o objetivo do que estamos construindo servido por práticas modernas de desenvolvimento web, então falar. E eu acho que isso é meio que… talvez não seja uma brincadeira, mas eu não estava dando um soco no desenvolvimento web moderno, mas um subproduto do desenvolvimento web moderno é que é muito fácil adicionar dependências a projetos. Tudo está à distância de uma instalação de MPM e cada instalação de MPM tem um custo, esse custo varia. Mas o que vemos é que nesses dados de arquivo HTTP, o percentil 95… significando os 5% das experiências que são as mais lentas… ou não as mais lentas, mas que enviam mais JavaScript, que aumentou no ano passado em cerca de 875 kilobytes para cerca de 1,4 megabytes.

Drew: Uau.

Jeremy: Portanto, é uma quantidade enorme de JavaScript que é transferida e tem implicações tanto no desempenho de carregamento quanto no desempenho do tempo de execução.

Drew: Então você mencionou desempenho lá. Parece que a experiência web moderna, do meu ponto de vista, é 10% HTML e CSS e 90% JavaScript. E tem que haver uma espécie de considerações de desempenho para isso. Quero dizer, você falou sobre a quantidade de dados que estamos transferindo, mas há outras considerações de desempenho por ter muito JavaScript.

Jeremias: Certo. Então, ter uma conexão de internet lenta e você sabe… onde eu moro nos Estados Unidos, se você for longe o suficiente fora de uma grande cidade, fica meio difícil dependendo de onde você vá… tipo dessas áreas rurais e é significativo para as pessoas que vivem em áreas como esta. E, portanto, o aspecto de desempenho de carregamento já é desafiador o suficiente quando você começa a enviar megabytes de JavaScript, mas também pode estar lidando com alguém que não tem um iPhone … como um iPhone X ou um iPhone 13.

Jeremy: Eles podem estar apenas em um telefone comum ou apenas como um telefone Android econômico, apenas tentando navegar pela vida. Quero dizer, pense em coisas como serviços bancários on-line, auxílio-desemprego ou outra assistência governamental, portais como esse para aplicativos. Aprendizado on-line, há muitos lugares onde o JavaScript excessivo pode realmente ter um efeito prejudicial para pessoas que podem não ter a sorte de morar em grandes áreas metropolitanas ou mesmo em áreas metropolitanas que não são bem atendidas pela Internet de banda larga e aquelas em dispositivos mais lentos . Eu meio que acho que, como desenvolvedores, temos essa tendência de olhar… compramos MacBooks ou esses dispositivos de ponta, e às vezes não vemos onde esses problemas podem surgir quando usamos JavaScript em excesso.

Drew: E como você mencionou lá, às vezes são os indivíduos que têm mais a perder por não conseguirem acessar um serviço que são penalizados por esse tipo de coisa. Essas pessoas sem conexões de dados rápidas ou sem dispositivos muito capazes às vezes acessam serviços que significam tudo para... significa tudo para eles que eles possam obter acesso. Então, de certa forma, torna-se quase uma questão de direitos humanos.

Jeremias: Sim. Quero dizer, tendemos a ver o desempenho da web ser enquadrado em termos de valor comercial. Eu era um consultor de desempenho para alguns e-com e como uma grande empresa de alimentos, um grande e-com... como uma loja, como uma loja de eletrônicos e é muito tentador fazer isso, certo? Porque quando você trabalha para uma empresa, quero dizer, obviamente, você quer que as finanças sejam saudáveis ​​e o desempenho da web desempenha um papel nisso, eu acho. Eu acho que há uma série de estudos de caso que comprovam isso. No entanto, existe esse aspecto humano e até mesmo para empresas, como mercearias e esse tipo de coisa. Sim, eles são movidos a receita. Eles querem ter finanças saudáveis ​​e, portanto, o desempenho na web faz parte disso, mas também estão atendendo a uma necessidade crítica, certo? Como você tem que comer, certo?

Jeremy: E como algumas pessoas podem ficar em casa por uma razão ou outra. Eles podem não ser capazes de entrar facilmente em um carro. Eles podem não ter um carro. Então eles estão contando com esses serviços para conseguir sustento, mas mais do que isso, assistência se precisarem e principalmente como intervenção em crises e esse tipo de coisa. Não acho muito exagerado dizer que um parceiro que foi abusado e expulso de casa pode recorrer ao smartphone e acessar o Google para tentar encontrar um portal para intervenção e assistência em crises. E o JavaScript meio que pode atrapalhar esses tipos de objetivos e atender a essas necessidades humanas. Quando temos a tendência de nos apoiarmos um pouco demais.

Drew: Quero dizer, nós vimos uma espécie de vislumbre disso nos últimos 18 meses, com COVID e pessoas se isolando e, como você diz, precisando encomendar mantimentos para serem entregues. A web se torna uma tábua de salvação para eles nesse ponto. Eles estão se sentindo mal, incapazes de sair de suas acomodações porque estão se isolando e precisam obter comida e suprimentos essenciais. Então, sim, é uma parte cada vez mais importante da vida cotidiana para todos nós, eu acho.

Jeremias: Exatamente. E voltando ao tipo de história do dispositivo, Tim Kadlec escreveu uma peça incrível alguns anos atrás, acho que foi dois anos, talvez três anos atrás, mas se chamava Priorizando a Cauda Longa da Performance. E quando você olha para isso... então, na linguagem de desempenho da web, nós meio que falamos sobre dados de laboratório versus dados de campo. E os dados de laboratório são como quando você está executando o lighthouse ou jogando um site em um teste de página da Web para ver como ele está se saindo. Essas são todas ferramentas realmente úteis, mas quando você olha para esses dados de campo, você realmente começa a ter uma visão mais ampla e uma visão mais ampla de quem seu público realmente é. E neste artigo, Tim Kadlec fala sobre o que significa priorizar a cauda longa do desempenho. Ou seja, todos esses dispositivos que... talvez não sejam tão robustos e poderosos quanto os dispositivos que nós, desenvolvedores, podemos ter.

Jeremy: E a ideia por trás desse artigo é que, se pudermos nos concentrar nesse 90º ou 95º percentil, estamos… e melhorar essa experiência para essas pessoas, estamos construindo uma web mais rápida para todos, incluindo aqueles em dispositivos rápidos. E ataque um ponto de dados sobre isso nos EUA e isso é apenas como statcounter.com. Algo como 28 pontos… cerca de 28% das pessoas estão em um dispositivo iOS que esta ferramenta captura. E cerca de 21% deles são Android. E o Android tende a representar uma boa parte dessa longa cauda de dispositivos, porque o Android não é monolítico. Vários fabricantes de dispositivos fazem telefones Android, mas para contrastar isso com o mundo, porque o mundo é mais do que apenas os Estados Unidos, são cerca de 16% das pessoas que usam iOS e cerca de 41% das pessoas que usam Android. Portanto, realmente vale a pena priorizar essas experiências mais lentas ou potencialmente mais lentas.

Drew: Eu li em seu livro sobre a limitação térmica do dispositivo, que não é algo que eu realmente tenha considerado antes. Quais são as preocupações aí?

Jeremy: As preocupações estão aí, e eu não sou um especialista em microprocessadores de forma alguma. Eu sou apenas o desenvolvedor da web que provavelmente escreve um pouco demais, mas… então a ideia por trás da limitação térmica e isso existe em todos os sistemas, não apenas como telefones e tablets, é que um microprocessador irá… quando assumir cargas de trabalho excessivas ou realmente apenas cargas de trabalho em geral, o produto residual desse trabalho é o calor. E assim os dispositivos têm maneiras de mitigar isso. Como se seu laptop tivesse um dispositivo de resfriamento passivo e ativo.

Jeremy: Então, como um dispositivo de resfriamento passivo é como um dissipador de calor ou algum tipo de dissipador de calor. E a parte ativa disso é como um ventilador para dispersar o calor com mais eficiência. Alguns PCs customizados podem usar como refrigeração líquida, que é um exemplo relativamente mais extremo, mas um celular não tem isso porque onde você vai realmente encaixar um ventilador em tudo isso, se a portabilidade é o seu coisa, certo?

Jeremy: Então, para que esses dispositivos lidem com essas cargas de trabalho pesadas, eles podem reduzir artificialmente a velocidade do processador, como reduzir a taxa de clock até que o dispositivo entre em um estado em que essa taxa de clock possa ser aumentada. E isso tem implicações porque se você está mastigando toneladas e toneladas e toneladas e toneladas de JavaScript, você tem esses grandes pedaços descendo o fio, bem, isso inicia o processamento, certo? Portanto, é muito processamento por meio de avaliação e análise na compilação e depois na execução. E se você está fazendo isso com um megabyte ou dois de JavaScript, e você tem muitos outros processos acontecendo em segundo plano, como guias diferentes, esse tipo de coisa que pode colocar seu estado... isso aumenta a probabilidade de o dispositivo pode entrar em um estado termicamente estrangulado, o que significa que ele será menos capaz de assumir esse trabalho extra.

Drew: Então é uma espécie de loop de feedback negativo. Não é? Você dá ao dispositivo muito trabalho para fazer. Ele fica muito quente e, em seguida, é menos capaz de realmente executar esse trabalho porque está tendo que desacelerar.

Jeremias: Certo. E, novamente, não sou um especialista em microprocessadores. Tenho certeza de que se, se, se um engenheiro que estivesse intimamente familiarizado com isso pudesse me corrigir em alguns detalhes, mas a ideia geral é que sim, à medida que a pressão ambiental aumenta, o dispositivo é menos capaz de lidar com essas cargas de trabalho pesadas até que a pressão diminua.

Drew: então estamos escrevendo JavaScript para todo o tipo de dispositivos do mais recente Apple M1 Max é o novo processador, não é? Laptops até dispositivos que mal têm memória RAM suficiente para renderizar uma página da web. Mas a web não começou assim, os ouvintes mais jovens podem se interessar em saber que costumávamos construir experiências interativas na web sem nenhum JavaScript. Nossa estrutura grande e pesada será nossa ruína.

Jeremy: Eu diria que os frameworks têm um tempo e um lugar e aqueles que lêem trechos deste livro podem ter a ideia de que sou anti-framework. E sou definitivamente crítico de vários frameworks, mas eles servem a um propósito e é possível usá-los de uma maneira que preserve uma boa experiência do usuário ou possa resultar em uma boa experiência do usuário. Mas o que eu acho que não fazemos o suficiente é avaliar criticamente essas estruturas em termos de como elas prejudicam... o desempenho do tempo de execução, certo? Então, o tipo de coisa de que estou falando, se você clicar em um botão, o dispositivo leva um segundo, talvez dois, para responder a essa entrada, porque há muita coisa acontecendo em segundo plano. Você tem coisas de JavaScript de terceiros, como coleta de análises, e outras coisas em execução em threads.

Jeremy: E que se você não avaliar criticamente o desempenho de tempo de execução de uma estrutura, pode estar deixando algumas oportunidades na mesa para atender melhor seus usuários. Então, um bom exemplo que eu sempre gosto de usar é reagir versus pré-agir. Eu tenho meio que batendo neste tambor por um tempo. Eu fiz um artigo para CSS-Tricks um tempo atrás que perfilava uma interação básica de clique para um menu de navegação móvel. E parece trivial, mas o que você descobre é que, em todos os dispositivos, o react oferece melhor desempenho em tempo de execução, mas tem basicamente a mesma API. Existem diferenças, existem algumas pequenas diferenças e coisas que podem ser disfarçadas com a compatibilidade pré-atuação, mas tão simples… e eu não deveria dizer uma escolha simples, mas essa escolha, essa escolha fundamental pode ser a diferença entre uma experiência que funciona muito bem para todos os usuários ou pelo menos para a maioria dos usuários, ou uma experiência que funciona bem apenas para alguns. Espero que tenha feito algum sentido.]

Drew: Quero dizer, com todas as estruturas e ferramentas de construção, eles parecem estar melhorando o tempo todo em fazer coisas como agitar árvores e otimizar os pacotes que eles enviam e como eles são entregues ao navegador. Ao usar grandes frameworks, há um ponto de inflexão em que você pensa que está escrevendo um aplicativo tão grande, tanto código próprio, que o framework está permitindo que você envie menos código por causa de toda a sua abstração?

Jeremy: Essa é uma pergunta difícil de responder. Um aspecto disso é que o próprio framework representa uma quantidade de código que você nunca pode otimizar. Então, ter uma estrutura fina, como pré-atuação ou qualquer número de como… Ou como feitiço, por exemplo, isso ajuda muito. Mas o problema que eu vi e acho que os dados do arquivo HTTP meio que suportam esse ponto é que parece que sempre que temos esses avanços em microprocessadores e redes cada vez mais rápidos é que tendemos a consumir esse ganho, certo?

Jeremy: Nós tendemos a ficar nessa esteira onde nunca realmente avançamos. E eu não sei, como se eu não fosse clarividente sobre qual é a história de... ou desculpe, como será o futuro dos frameworks. Tenho certeza de que há alguns ganhos de eficiência que podem ser obtidos. Mas o que vemos no campo em termos de quanto JavaScript bruto é… apenas a quantidade bruta de JavaScript está sendo usada. Não me diz que este é um problema do qual podemos automatizar nossa saída. Acho que temos que... temos que ser seres humanos e intervir e tomar decisões que sejam do melhor interesse dos usuários. Caso contrário, não nos vejo saindo dessa esteira, não na minha carreira, talvez, mas não sei.

Drew: No livro, você fala sobre sites e aplicativos da web e como entender a diferença e com qual você está trabalhando ajuda a escolher sua estratégia para desenvolver e otimizar. Conte-nos um pouco sobre isso.

Jeremy: Essa é uma pergunta muito boa. E escrevo sobre isso no artigo homônimo que escrevi para A List Apart, chamado Responsible JavaScript Part One, que é uma espécie de prelúdio para este livro. É que nós carregamos muito nessa terminologia. Como um escritor técnico, vejo os dois serem usados ​​de forma intercambiável. O que eu vejo é com sites, a implicação é que é uma espécie de experiência multi-idade, certo? É uma coleção de documentos. Agora um documento... esses documentos podem ter funcionalidades incorporadas como essas pequenas ilhas, como o termo tem sido ultimamente, essas pequenas ilhas de funcionalidade que permitem que as pessoas façam as coisas.

Jeremy: Mas então há aplicativos da web e aplicativos da web meio que têm essa conotação de aplicativo nativo como funcionalidade. Então, estamos falando de aplicativos de página única, estamos falando de grandes quantidades de JavaScript para gerar interatividade complexa. E há momentos em que o modelo de aplicativo da web faz sentido. Como, por exemplo, o Spotify é um bom exemplo disso. Isso funciona melhor como um aplicativo da web. Você realmente não gostaria de tentar usar isso ou projetar isso como um aplicativo de várias páginas. Como um site tradicional, mas acho que não é um padrão sustentável porque quando seu padrão para cada projeto é dizer: "Bem, tudo o que precisamos é enviar um aplicativo de página única, como um roteador do lado do cliente e uma estrutura pesada e descarregar todos desse processamento de renderização do servidor para o cliente.” Acho que é aí que você começa a chegar a um ponto em que está excluindo usuários, embora sem querer, mas excluindo-os mesmo assim.

Drew: Existe um grande abismo, você acha que entre as pessoas que adotam a abordagem de publicar um site e ele pode ter qualquer funcionalidade interativa e aqueles que dizem: “Somos uma empresa de software, estamos fazer um produto, um produto de software e nossa plataforma pela qual vamos entregá-lo é a web, em vez de aplicativos nativos para várias plataformas.” É provável que eles estejam abordando o problema de maneiras completamente diferentes? As considerações são diferentes dependendo de sua perspectiva naquele momento?

Jeremy: Essa é uma pergunta difícil. Assim-

Drew: Foi difícil para mim dizer.

Jeremy: Eu diria que uma empresa que... então um bom exemplo seria como uma notícia, certo? Eles estão bem servidos pelo tipo de modelo de site, porque é literalmente uma coleção de documentos, artigos. E as pessoas que desenvolvem essas experiências provavelmente terão um conjunto de habilidades diferente do que, digamos, uma empresa como o Spotify ou uma empresa que tem um grande aplicativo da web como o Envision ou esse tipo de coisa. E então sim, eu acho que eles vão chegar a isso de diferentes ângulos. A maneira como eu olhei para isso é que há um segmento… ou pelo menos é assim que eu percebi a comunidade de desenvolvimento web em geral é que há um segmento de pessoas, de desenvolvedores web que vieram de desenvolvimento de software não tradicional fundos, certo? E eu sou uma dessas pessoas, eu estava mexendo na web quando eu era meio criança, certo?

Jeremy: Como no ensino médio e fazendo fanpages estúpidas para todos, como os videogames da época que eu realmente gostava. E eu nunca tive esse tipo de educação em ciência da computação. Existem conceitos de ciência da computação que aprendi ao longo do caminho. Depois, há também um segmento de desenvolvedores, especialmente acho que surgiram nos últimos cinco a 10 anos, que abordam isso de uma maneira mais orientada para a ciência da computação. E acho que isso vai... essas diferenças e experiências vão levar cada um desses grupos a tirar suas próprias conclusões sobre a melhor forma de desenvolver para a web. Mas acho que a única maneira que você pode realmente... Desenvolver de forma sustentável para a web é avaliar criticamente o que você está construindo e tentar alinhar em torno de uma abordagem que atenda melhor aos usuários desses produtos. E é aí que os modelos de sites e aplicativos da web ficam na minha cabeça quando avalio essas coisas.

Drew: Sim. É interessante. Quero dizer, no livro, você realmente cita alguns dos meus trabalhos. Muito obrigado. E minha escolha de tecnologias chatas notou basicamente PHP Apache e uma pitada de JavaScript enrolado à mão pode criar uma experiência de usuário muito rápida por padrão, sem precisar fazer nenhuma otimização específica. Acho que isso contribui para uma ótima experiência do usuário para os visitantes do front-end que chegam e visualizam o conteúdo do site.

Drew: Mas, na verdade, eu meio que sinto que esse ambiente para a autoria de conteúdo é o outro lado, uma vez que você está logado e suas coisas de publicação no site. Acho que sofre um pouco por ser construído com uma abordagem de site, em vez de uma abordagem de aplicativo da Web mais pesada em JavaScript, tanto que estou pensando… ou talvez precise ser as duas coisas. Eu preciso continuar publicando o front-end em HTML e CSS estáticos e pequenos pedaços de JavaScript. Mas o back-end onde eu quero fornecer uma experiência de criação de conteúdo talvez uma escolha de tecnologia diferente seja melhor. É bem interessante porque nem sempre tem que ser uma coisa ou outra, não é? Não é uma escolha binária. É mais um espectro, você diria?

Jeremy: Sim, absolutamente. E acho que estamos começando a ver mais discussões na comunidade sobre o desenvolvimento da web ser um espectro como esse. Para ser direto para as pessoas que podem estar interessadas no meu livro, ele definitivamente vem do lado do site do espectro. E novamente, porque eu sinto que isso é sempre um bom padrão. Se você não sabe como deseja construir algo, provavelmente é melhor tentar construí-lo de uma forma que minimize o uso de JavaScript e minimize o envio de mais trabalho para o cliente. Dito isto, acho que notado é uma excelente experiência. Eu acho que essas tecnologias bem desgastadas e meio “chatas” realmente funcionam bem para a tarefa em questão. E faz isso de uma forma que é meio aberta e capacitadora para o desenvolvedor, certo?

Jeremy: Você não precisa ter um conhecimento tão profundo de como... de armazenamentos de gerenciamento de estado ou estruturas de gerenciamento de estado para realmente fazer esse tipo de coisa. E eu acho que notado é bem servido por essa abordagem específica. Mas para o seu ponto, acho que há oportunidades em qualquer site para se aproximar do meio do espectro sem entrar em todos os roteamentos do lado do cliente, como estruturas pesadas que gerenciam tudo no cliente e esse tipo de coisa. Acho que a abordagem da ilha está começando a explorar o que parece. E eu admito, eu provavelmente fiz involuntariamente algumas coisas do tipo ilhas. Acho que já faz um bom tempo, só não colocamos um nome nisso. Mas acho que agora que identificamos isso como talvez um ponto médio, podemos começar a ver experiências na web que proporcionam uma boa experiência do usuário, mas ainda são mais interativas. Espero que não tenha sido terrivelmente sinuoso.

Drew: Isso meio que remonta um pouco aos dias em que incorporávamos uma ilha de Flash ou...

Jeremias: Sim.

Drew: Algo em uma página onde esta é a nossa pequena seção interativa, e o resto dela meio que flui.

Jeremy: Sim, como o Flash, meu Deus, três iterações do meu portfólio pessoal fora da faculdade eram realmente ruins para imitações avançadas do Flash e como efeitos de hover. E esse material foi muito, muito divertido. E eu sinto falta às vezes como se houvesse toda uma riqueza de conteúdo que vai desaparecer porque não usamos mais Flash. E isso realmente é uma merda, mas de certa forma foi meio que o precursor desse tipo de ilha de que estamos falando. Ou seja, você poderia ter apenas uma página da Web estática e tudo mais, mas então você teria essa experiência realmente rica e interativa, como se estivesse bem no meio dela.

Drew: Por muito tempo, o aprimoramento progressivo foi considerado uma forma de prática recomendada para construir experiências na web. Ainda é assim, você acha?

Jeremy: Eu diria que provavelmente... não provavelmente eu admitiria que é mais trabalhoso fazer melhorias progressivas porque, de certa forma, você está bifurcando sua experiência de desenvolvimento. Você está tentando fornecer uma funcionalidade mínima viável de um site de uma maneira que o servidor possa lidar com essas interações-chave. Mas, além disso, você está dizendo: “Ok, bem, agora quero facilitar essa interação para ser um pouco mais suave com JavaScript”. Ainda acho que é uma maneira viável de atingir seus objetivos com seu site, seu aplicativo ou seu produto.

Jeremy: Mas o que eu diria é que eu nunca recomendaria que cada interação em um site fosse facilitada por esse tipo de padrão de navegação síncrona. Então, como um bom exemplo pode ser sua página de checkout para o seu site econ deve definitivamente ter uma rota de servidor. Você deve ter uma rota de servidor para adicionar coisas ao carrinho e, em seguida, deve ser capaz de polvilhar JavaScript suficiente para tornar isso um pouco mais agradável, para que as coisas possam ser um pouco mais rápidas e assíncronas.

Drew: Quando se trata de medir o desempenho. Ouvimos muito sobre os principais elementos vitais da web, principalmente do Google. Esses são realmente os pontos de referência com os quais devemos medir? Ou é apenas isso que o Google quer que pensemos? Agora entendo que essa pode ser uma pergunta difícil porque você começou a trabalhar no Google.

Jeremy: Sim, sim. Você sabe, então eu estou falando por mim aqui. Acho que os web vitals são… os web vitals centrais iniciais são uma boa tentativa de definir quais partes da experiência do usuário são importantes. Eu acho que métricas como mudança de layout cumulativa e maior pintura Contentful começam a pensar sobre a experiência de maneiras que realmente não tínhamos começado a quantificar. Antes de uma mudança de layout particularmente cumulativa, porque se já houve um momento em que você toca com raiva é porque um botão gosta de se mover pela página ou algo assim. Quer dizer, eu acho que isso é uma coisa útil para medir isso. É imperfeito. E acho que qualquer pessoa que trabalhe com os principais elementos vitais da web concordaria que a melhoria é desejada em algumas dessas métricas. Existem outras métricas com as quais não concordo totalmente. Como o atraso da primeira entrada é uma métrica que é meio difícil de colocar um pino.

Jeremy: Eu acho que é muito útil, certo? Porque o que você está literalmente dizendo é que queremos medir o atraso e a interatividade nessa primeira interação que o usuário faz, mas falta um pouco de contexto, certo? Porque algumas… muitas coisas podem afetá-lo porque não necessariamente sempre está vinculado ao JavaScript. O atraso da primeira entrada pode representar o atraso incorrido ao focar o campo do formulário, certo? Esse tipo de coisa, coisas em HTML. Eu acho que essas métricas... tais métricas como o atraso na primeira entrada podem ser... elas podem ser benéficas se você puder contextualizá-las com coisas como entradas da API de tarefas longas, tempo de elemento e esses tipos de coisas. Em última análise, acho que o futuro dos principais elementos vitais da web provará que será útil e instrumental para medir o que faz uma boa experiência do usuário. Essa é minha opinião pessoal.

Drew: Acho que é uma daquelas coisas que você sempre pode medir contra si mesmo, medir suas próprias melhorias ou se sua experiência piorou se sua pontuação mudar, não se importando tanto com os semáforos, mas se preocupando com o que você sabe sobre o contexto do seu site e como uma mudança fez uma melhoria.

Jeremy: Acho que métricas como mudança cumulativa de layout são excelentes, mas também podem se beneficiar de um pouco de melhoria. Tal como está, a mudança cumulativa de layout mede principalmente as mudanças de layout que ocorrem durante a carga. E como sabemos, quando um usuário visita uma página e chega a uma página, essas mudanças de layout podem ocorrer a qualquer momento, certo? Então, definitivamente, acho que há trabalho que pode ser feito para melhorar a forma como observamos esse tipo de fenômeno, com certeza.

Drew: Acho que a estabilidade do layout é uma das coisas que na verdade é um pouco mais difícil de alcançar quando você está trabalhando com aprimoramento progressivo. Às vezes, quando você carrega uma página renderizada no servidor e começa a aprimorá-la no cliente, pode haver o perigo de criar esse tipo de mudança de layout, não é?

Jeremias: Com certeza. E é aí que a hidratação dos componentes se torna meio complicada porque as dimensões desse componente podem mudar por vários motivos. Como pode haver conteúdo presente no componente do lado do cliente que simplesmente não é renderizado no servidor devido ao estado que não é avaliado até que seja executado no cliente. É um problema extremamente difícil. Não vou sentar aqui e fingir que tenho a bala de prata para isso.

Drew: Eu queria falar um pouco sobre um tipo de dinâmica de importação e divisão de código, ambas técnicas diferentes para o problema de baixar e executar um enorme pacote de JavaScript no início da experiência. Existe o risco de otimizar demais fazendo muitas solicitações pequenas, principalmente em projetos menores mais simples, ou é algo que eles não fazem mal em implementar meio que desde o início antecipando que você terá esses problemas? Ou você deveria esperar até ver problemas de desempenho antes de pensar sobre esse tipo de coisa?

Jeremy: Então eu recomendaria que o final do que você acabou de dizer é uma boa maneira de começar com isso. Não devemos tentar otimizar prematuramente, a menos, é claro, que essas otimizações possam ser alcançadas com muita rapidez e facilidade, mas se for preciso muito esforço para otimizar no início, quando não houver muitos problemas de desempenho, eu diria que divisão de código é provavelmente algo que não precisa acontecer. Você provavelmente pode apenas carregar essa funcionalidade antecipadamente.

Jeremy: Mas, por exemplo, eu falo sobre isso no livro. Se você tem uma interação de alto valor que é impulsionada por um grande pedaço de JavaScript, e para mim, um grande pedaço de JavaScript pode significar 20 kilobytes porque sobre o fio é compactado e pode acabar sendo um pedaço de 60 kilobytes de JavaScript. Então, se você conseguir isso no pacote principal ou em qualquer um dos seus inúmeros pacotes, seu site pode estar enviando, você ajudará no desempenho da inicialização.

Jeremy: Mas no livro, discuto uma técnica sobre perceber quando... ou pelo menos tentar perceber quando o usuário pode fazer uma interação de alto valor. Então o exemplo que eu uso é um pedaço de JavaScript. Isso é usado para validar o conteúdo de um formulário porque a validação de formulário HTML é ótima, mas também não tem estilo e é bastante direta. Não há muita flexibilidade para coisas como tipo igual a e-mail, certo? Ele avalia de uma certa maneira. No entanto, essa validação do formulário no cliente é muito útil porque também podemos estilizá-lo. E podemos alinhar a aparência dessa validação para estar mais próxima do que é a estética da marca ou do que é a estética do site. E assim, neste exemplo, o que eu fiz foi, é o que eu disse, se um usuário foca... mesmo que apenas foca qualquer um dos campos no formulário, esse é o ponto em que nós pré-carregamos aquele pedaço de JavaScript.

Jeremy: Espero que no momento, e espero que, porque leva um pouco de tempo para preencher um formulário, a rede tenha tempo suficiente para puxá-lo para baixo, de modo que, quando a importação dinâmica for chamada, ela possa apenas acertar o dinheiro para obter o que já foi pré-carregado. É algo com o qual tenho trabalhado um pouco aqui e ali, e é difícil de fazer em todas as situações. Como, por exemplo, você não pode fazer isso de forma confiável o tempo todo em foco porque alguns dispositivos não têm um ponteiro preciso. Eles têm... eles são... são entradas de torneira, certo? Portanto, um foco ocorre em um momento diferente do que se você tivesse um ponteiro fino, por exemplo.

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy: Uma coisa que eu venho fazendo desde que saiu é mexer com a API de pintura CSS. Eu realmente gosto da API de pintura. Quero dizer, meio que sempre existiu por si só…. como à sua maneira, uma vez que o contexto 2D da tela tem sido uma coisa. Porque isso é… para quem não sabe, a API de dor CSS é uma maneira pela qual você pode incorporar um contexto de tela 2D e parametrizá-lo e controlá-lo com CSS, o que abre muitas possibilidades realmente interessantes, como você pode animar coisas que você não podia animar anteriormente e esse tipo de coisa.

Jeremy: E recentemente estou atualizando o blog. Ou seja... eu sou um grande nerd de Final Fantasy, como Final Fantasy II que acabei de jogar de novo e então, tem uns 15 deles e 16 serão lançados em algum momento, mas é meio que um campo retrô. Então, eu tenho usado a API de pintura CSS para gerar um mundo aleatório usando diferentes blocos. Então há rios e coisas que atravessam e telhas de grama e árvores e esse tipo de coisa. E parametrizando assim, se o usuário visitar meu site no modo escuro… esse trabalho de pintura será renderizado como se fosse noite. Vai ter uma espécie de sobreposição nele e esse tipo de coisa.

Jeremy: Mas a API de pintura é incrível. Eu tenho que dar um alô para Tim Holman. Ele, eu o vi na JSConf Australia e ele falou sobre arte generativa. Isso foi realmente justo, realmente me interessou. E então Sam Richard, na CSSConf no dia anterior, falou sobre a API de pintura CSS, quando essas duas coisas se juntaram para mim, foi como, “Uau, isso é tão legal”. E então eu realmente fiz uma coisa chamada Paintlets! É um Paintlets.Herokuapp.com se você visitar o Chrome e precisar, infelizmente, porque ainda não é super bem suportado. Você pode ver um monte de diferentes artes aleatórias geradas aleatoriamente e... sim, eu só... é nisso que eu tenho me interessado, desculpe. Longa história sobre isso.

Drew: Incrível. Isso parece ótimo.

Jeremias: Sim. Sim.

Drew: Se você, querido ouvinte, gostaria de ouvir mais de Jeremy, você pode encontrá-lo no Twitter onde ele é @malchata e encontrar suas apresentações de escrita, vídeos e projetos em seu site pessoal, jeremy.codes, JavaScript responsável está disponível agora em A Livro à parte. E você pode encontrar mais informações sobre isso em responsablejs.dev. Obrigado por se juntar a mim hoje Jeremy, você teve alguma palavra de despedida?

Jeremy: Apenas vá em frente e construa para a web da melhor maneira possível e tente manter o usuário em mente. Esse é o meu mantra e espero que este livro faça isso um pouco.