Smashing Podcast Episódio 21 Com Chris Ferdinandi: As Melhores Práticas Modernas São Ruins para a Web?

Hoje, estamos perguntando se as práticas recomendadas modernas são ruins para a web? As estruturas modernas estão nos levando para o caminho errado? Eu falo com o especialista em Lean Web Chris Ferdinandi para descobrir.

Mostrar notas

• Página de Chris com links e notas para o podcast
• O livro Lean Web
• Chris Ferdinandi na web
• Cris no Twitter
• O podcast JavaScript de baunilha

Atualização semanal

• “Traduzindo Wireframes de Design em HTML/CSS Acessível”
  por Harris Schneiderman
• “Construindo aplicativos de desktop com Electron e Vue”
  por Timi Omoyeni
• “Técnicas CSS modernas para melhorar a legibilidade”
  por Edoardo Cavazza
• “Como usar componentes com estilo no React”
  por Adebiyi Adedotun Lukman
• “Como criar um Porsche 911 com esboço”
  por Nikola Lazarevic

Transcrição

Drew McLellan: Ele é o autor da Vanilla JS Pocket Guide Series, criador do Vanilla JS Academy Training Program e apresentador do Vanilla JS Podcast. Ele desenvolveu um boletim informativo de dicas, que é lido por quase 10.000 desenvolvedores todos os dias da semana. Ele ensinou desenvolvedores em organizações como Chobani e The Boston Globe. E seus plugins JavaScript foram usados ​​por organizações como Apple e Harvard Business School. Acima de tudo, ele gosta de ajudar as pessoas a aprender JavaScript Vanilla. Então, sabemos que ele prefere o Vanilla JavaScript em vez de um framework, mas você sabia que ele já foi escolhido em uma fila policial como sendo a pessoa menos provável de ter cometido o crime? Meus amigos Smashing, por favor, dêem as boas-vindas a Chris Ferdinandi. Olá Chris. Como você está?

Chris Ferdinandi: Ah, estou arrasando. Obrigado por me receber.

Drew: Eu queria falar com você hoje sobre esse conceito de Lean Web, que é uma paixão para você, não é?

Chris: Sim, muito.

Drew: Por que você não prepara o cenário para nós? Quando falamos de Lean Web, qual é o problema que estamos tentando resolver?

Chris: Sim, ótima pergunta. Apenas como uma ressalva para todos os ouvintes, este episódio pode fazer com que um velhinho grite com a nuvem. Vou tentar evitar isso. Quando olho para a forma como construímos para a web hoje, parece um pouco com uma bagunça inchada de engenharia excessiva. Cheguei a acreditar que muito do que consideramos como melhores práticas hoje pode estar piorando a web.

Chris: A Lean Web é uma abordagem de desenvolvimento web que se concentra na simplicidade, no desempenho e na experiência do desenvolvedor sobre... Desculpe, não na experiência do desenvolvedor. A experiência do usuário, em vez da experiência do desenvolvedor, e a facilidade de construir as coisas de uma perspectiva de equipe, que é o que acho que colocamos muito foco hoje e como provavelmente entraremos em nossa conversa.

Chris: Na verdade, descobri que muitas dessas coisas que consideramos melhorar a experiência do desenvolvedor fazem isso para um subconjunto de desenvolvedores, mas não necessariamente para todos que estão trabalhando no que você está construindo. Portanto, há um monte de problemas com isso também, que podemos investigar. Mas, na verdade, a Lean Web é focar na simplicidade e no desempenho para o usuário e realmente priorizar ou colocar o foco nas pessoas que usam as coisas que fazemos em vez de nós, as pessoas que estão fazendo.

Drew: À medida que a web amadurece como plataforma de desenvolvimento, parece haver um impulso cada vez maior para a especialização.

Cris: Sim.

Drew: Pessoas que cobriam Full Stack, e então dividimos em front-end e back-end. E então esse front-end se dividiu em pessoas que fazem desenvolvimento CSS ou JavaScript. E então cada vez mais dentro do JavaScript, ele se torna mais especializado. Alguém pode se considerar e se comercializar como um desenvolvedor React ou um desenvolvedor Angular, e toda a sua identidade e perspectiva são baseadas em uma estrutura específica na qual eles são altamente qualificados. Essa dependência de estruturas, o núcleo do nosso trabalho na web, uma coisa ruim?

Chris: Tem nuances. Eu costumava ser muito forte no sim, sempre camp. Eu penso amplamente, ainda sinto que sim, nossa obsessão como uma indústria com frameworks e ferramentas em geral, é potencialmente um pouco em nosso detrimento. Eu não acho que frameworks sejam inerentemente ruins. Eu acho que eles são úteis para um subconjunto muito restrito de casos de uso. E acabamos usando-os para quase tudo, incluindo muitas situações em que eles não são necessariamente a melhor escolha para você ou para o projeto.

Chris: Quando penso em muitos dos problemas que temos na web hoje, o núcleo desses problemas realmente começa com nossa dependência excessiva de frameworks. Todo o resto que vem depois disso é de várias maneiras, porque lançamos muito não apenas frameworks que são JavaScript em geral, na web. Digo isso como alguém que ensina profissionalmente as pessoas a escrever e usar JavaScript. É assim que ganho meu dinheiro. E estou aqui dizendo que acho que usamos muito JavaScript, o que às vezes é um pouco estranho.

Drew: Antes do surgimento dos grandes frameworks, costumávamos construir interfaces de usuário e coisas com jQuery ou qualquer outra coisa. E então surgiram os frameworks e eles nos deram mais desse conceito de uma interface do usuário baseada em estado.

Cris: Sim.

Drew: Agora, essa é uma engenharia bastante complexa que você precisa implementar. Trabalhar com menos JavaScript exclui usando algo assim ou você precisa reimplementá-lo? Você está apenas criando um clichê carregado?

Chris: Muito disso depende do que você está fazendo. Se você tem uma interface que não muda, você pode construir uma interface do usuário baseada em estado com... não sei, talvez uma dúzia de linhas de código. Se você tem uma interface que não muda, eu honestamente provavelmente diria UI baseada em estado. Não é necessariamente a abordagem correta. Provavelmente há outras coisas que você pode fazer em vez disso. Pense em geradores de sites estáticos, algumas marcações pré-renderizadas, até mesmo um site WordPress ou PHP da velha guarda.

Chris: Mas onde isso começa a ficar interessante é quando você entra em interfaces mais dinâmicas e interativas. Não apenas aplicativos. Eu sei que as pessoas adoram traçar essa linha entre sites e aplicativos, e acho que há essa mistura estranha entre os dois e a linha nem sempre é tão clara. Quando você começa a entrar mais o usuário faz coisas, algo muda. A interface do usuário baseada em estado se torna um pouco mais importante. Mas você ainda não precisa de toneladas de código para fazer isso acontecer.

Chris: Eu olho para algo como React ou Vue, que são peças de engenharia absolutamente incríveis. Eu não quero tirar das pessoas que trabalham neles. Acabei como um exercício de aprendizado, construindo meu próprio mini-framework apenas para ter uma noção melhor de como essas coisas funcionam sob o capô. É realmente difícil explicar todas as diferentes peças em movimento. Portanto, tenho um enorme respeito pelas pessoas que constroem e trabalham nessas ferramentas. Mas o React e o Vue têm cerca de 30 kilobytes após a minificação e o gzip. Então, uma vez que você os descompacte, eles são substancialmente maiores do que isso.

Chris: Nem tudo, mas uma boa parte desse peso é dedicada a essa coisa chamada DOM virtual. Existem alternativas que usam APIs ou abordagens semelhantes. Para React, você tem Preact, que tem 2,5 kilobytes ou cerca de 3 kilobytes em vez de 30. É um décimo do tamanho. Para o Vue, você tem o Alpine JS, que tem cerca de 7 kilobytes. Ainda assim, substancialmente menor. A grande diferença entre eles e seus colegas irmãos mais velhos é que eles abandonaram o DOM virtual. Eles podem descartar um método ou dois. Mas, geralmente, é a mesma abordagem e o mesmo tipo de API na maneira de trabalhar com código, e eles são substancialmente menores.

Chris: Acho que muitas das ferramentas que usamos são potencialmente superadas para as coisas que estamos tentando fazer. Se você precisa de uma interface do usuário baseada em estado e precisa de dados reativos e essas interfaces dinâmicas, isso é ótimo. Acho que uma das grandes coisas que tento e falo hoje é não... nunca usar ferramentas. Para mim, Vanilla JS não é você escrever à mão cada linha de código e cada projeto que você faz. Isso é loucura. Eu não poderia fazer isso, eu não faço isso. Mas está sendo mais seletivo sobre as ferramentas que usamos. Sempre optamos pela multiferramenta, o canivete suíço que tem todas essas coisas. E às vezes, tudo o que você realmente precisa é de uma tesoura. Você não precisa de todas as outras coisas, mas nós temos de qualquer maneira.

Chris: O que é um longo caminho para… Desculpe, responder sua pergunta. O que às vezes é mais código do que você poderia ou gostaria de escrever sozinho, mas não é tanto código quanto acho que achamos que requer. Quando digo que você não precisa de um framework, recebo muitas críticas em torno dessa ideia de que “Bem, se você não usa um framework, você está basicamente escrevendo o seu próprio”. Então isso vem com seus próprios problemas. Eu acho que há um lugar entre usar React ou Vue e escrever seu próprio framework, e talvez seja escolher algo um pouco menor. Às vezes, existem razões pelas quais escrever sua própria estrutura pode ser a escolha certa, dependendo do que você está tentando fazer. É tudo muito fluido e subjetivo.

Drew: É muito interessante que, como exercício de aprendizado, você implementou sua própria estrutura baseada em estado. Lembro-me que, no passado, costumava pensar que toda vez que procurava uma biblioteca ou algo assim, gostava de pensar que poderia implementá-lo sozinho.

Cris: Claro, claro.

Drew: Mas alcançar a biblioteca me salvou do incômodo de fazer isso. Eu sabia que se eu mesmo tivesse que escrever esse código, sabia que abordagem usaria para fazê-lo. E isso era verdade até o uso de coisas como jQuery e outras coisas. Hoje em dia, acho que se eu tivesse que escrever minha própria versão do Vue ou do React, quase não tenho ideia do que está acontecendo agora nessa biblioteca, em todo esse código.

Drew: Para aqueles de nós que não estão familiarizados, quando você diz algo como Preact descarta o DOM virtual e torna tudo muito menor, o que esse DOM virtual está nos dando?

Chris: Para responder a essa pergunta, quero dar um pequeno passo para trás. Uma das coisas mais legais que os frameworks e outras bibliotecas baseadas em estado oferecem é a diferenciação do DOM. Se você não está realmente atualizando tanto a interface do usuário, pode dizer: “Aqui está uma sequência de como a marcação deve ser. Em HTML, vou colocar toda essa marcação nesse elemento.” Quando você precisa mudar alguma coisa, você faz de novo. Isso é um pouco caro para os navegadores, porque aciona um redesenho.

Chris: Mas acho que potencialmente mais importante do que isso, um dos problemas de fazer isso é que você tem algum tipo de elemento interativo lá, um campo de formulário, um link no qual alguém se concentrou. Esse foco é perdido porque o elemento... mesmo que você tenha uma coisa nova que pareça semelhante, não é o mesmo elemento literal. Portanto, se o foco for perdido, isso pode criar confusão para as pessoas que usam leitores de tela. Há apenas um monte de problemas com isso.

Chris: Qualquer coisa de interface do usuário baseada em estado que valha a pena implementará algumas diferenças de DOM, onde eles dizem: “Aqui está a aparência da interface do usuário. Aqui está o que parece agora no DOM. O que é diferente?" E vai mudar essas coisas. Ele está efetivamente fazendo as coisas que você faria apenas atualizando manualmente a interface do usuário, mas está fazendo isso por você nos bastidores. Então você pode apenas dizer: “Aqui está como eu quero que seja”. E então a biblioteca ou framework descobre.

Chris: As coisas menores como Preact ou Alpine, eles estão fazendo isso diretamente. Eles estão convertendo a string que você fornece a eles da aparência da interface do usuário em elementos HTML. E então eles estão comparando cada elemento com sua parte correspondente no DOM literal. À medida que você acaba com UIs cada vez maiores, isso pode ter uma implicação no desempenho, porque consultar o DOM repetidamente se torna caro. Se você quiser ter uma noção do tipo de interface em que isso se torna um problema, clique com o botão direito do mouse e inspecione o elemento no botão “Favorito” no Twitter ou no botão “Curtir” no Facebook. E dê uma olhada no aninhamento de divs que leva você a esse elemento. É muito, muito profundo. É como uma dúzia de divs, aninhados um dentro do outro apenas para aquele único tweet.

Chris: Quando você começa a descer tantas camadas, isso começa a realmente afetar o desempenho. O que o DOM virtual faz é, em vez de verificar o DOM real todas as vezes, ele cria um mapa baseado em objeto da aparência da interface do usuário em JavaScript. E, em seguida, faz a mesma coisa para a interface do usuário com a qual você deseja substituir a existente e compara essas duas. Isso é muito mais desempenho na teoria do que fazer isso no DOM real. Uma vez que obtém uma lista das coisas que precisa mudar, ele simplesmente sai e faz essas mudanças. Mas ele só precisa atacar o DOM uma vez. Não está verificando todos os elementos, todas as vezes. Se você tem interfaces como Twitters ou Facebooks ou QuickBooks ou algo assim, o DOM virtual provavelmente faz muito sentido.

Chris: O desafio com isso é… a diferença entre Preact e React é de 27 kilobytes antes de você descompactar a coisa toda em sua onda de código real. O download bruto e o tempo de descompactação e compilação podem adicionar um pouco de latência à carga inicial em uma interface do usuário. Isso se torna ainda mais pronunciado se seus usuários não estiverem nos dispositivos mais recentes da Apple. Mesmo um dispositivo Android de alguns anos atrás ou um feature phone, ou se você tem pessoas em países em desenvolvimento, é realmente… o tempo para começar é mais lento. Além disso, o tempo interativo real é mais lento por causa da abstração extra.

Chris: Então não é só você carregá-lo e eles são comparáveis ​​em velocidade. Cada microinteração que alguém faz e as mudanças que precisam acontecer também podem ser um pouco mais lentas apenas por causa de todo esse código extra lá. Se você tiver uma interface do usuário muito, muito complexa com muitos elementos aninhados e muitos dados, os ganhos de desempenho do DOM virtual superam esse peso extra de código. Mas qualquer interface de usuário típica para um aplicativo típico para o qual vejo desenvolvedores usando React ou Vue, o benefício que você obtém do DOM virtual simplesmente não existe e seria melhor. Mesmo que você queira manter a mesma conveniência do React, use o Preact. É uma fração do tamanho, funcionará exatamente da mesma maneira e terá mais desempenho. Esse é o tipo de coisa que eu costumo argumentar.

Chris: Precisamos ser melhores ao escolher a ferramenta certa para o trabalho. Se você seguir uma abordagem como essa, se chegar a um ponto em que um DOM virtual realmente faça sentido, é muito mais fácil portar o Preact para o React do que se você rolasse o seu próprio. Essa é a situação. Se você está realmente preocupado com isso, você também tem alguma proteção para o futuro.

Drew: Alguns podem dizer, eles podem argumentar que esses frameworks, coisas como Vue, React são tão altamente otimizados para desempenho que você obtém tantos benefícios que certamente apenas emparelhando isso com um gerenciador de pacotes em um empacotador para garantir que você está apenas enviando o código que você deseja. Certamente, você já está muito à frente apenas fazendo isso?

Cris: Sim. Eu não concordo. Eu realmente não tenho muito mais para elaborar sobre isso além de... acho que talvez, mas não realmente. Mesmo com um bundler, você ainda precisa desse núcleo React. Mesmo com o pacote, isso ainda será maior do que usar algo como o Preact.

Chris: Drew, eu realmente aprecio você liderar a questão sobre isso. Porque uma das outras coisas que eu falo no meu livro, The Lean Web, e minha conversa com o mesmo nome, é como essas ferramentas... Você mencionou o empacotamento, por exemplo. Uma das coisas que fazemos para contornar o impacto no desempenho que levamos ao usar todo esse JavaScript é lançar ainda mais JavaScript no front-end para explicar isso. Uma das maneiras de fazer isso são gerenciadores de pacotes e empacotadores de módulos.

Chris: Como você mencionou... para aqueles que não sabem, essas são ferramentas que irão... compilar todos os seus pequenos bits individuais de JavaScript em um grande arquivo. Os mais novos e os mais... não quero chamá-los de pensativos. Mas os mais novos usarão um recurso chamado tree shake, onde eles se livram de qualquer código que não seja realmente necessário. Se esse código tiver algumas dependências que não são usadas para o que você realmente fez, eles descartarão algumas dessas coisas para tornar seus pacotes o menor possível. Na verdade, não é uma ideia terrível, mas resulta nessa coisa que eu normalmente chamo de saúde de dependência, onde você tem esse castelo de cartas realmente delicado de dependências em cima de dependências em cima de dependências.

Chris: A configuração do seu processo leva tempo. E qualquer um que já executou uma instalação do NPM e descobriu que várias dependências estavam desatualizadas e tiveram que passar uma hora tentando descobrir quais precisavam ser corrigidas e, na verdade, é uma dependência em uma dependência e você não não tem a capacidade de ir corrigi-lo sozinho. É uma coisa toda. Talvez funcione para você, mas prefiro gastar meu tempo não brincando tentando juntar minhas dependências.

Chris: Comecei a coletar tweets de pessoas que reclamam do tempo perdido em seu fluxo de trabalho. Um dos meus favoritos, Brad Frost, há alguns anos, estava falando sobre a deprimente percepção de que a coisa que você está percorrendo no JS moderno poderia ter levado 10 minutos no jQuery. Não sou muito fã de jQuery, mas sinto essa dor quando se trata de trabalhar com frameworks.

Chris: O outro problema com muitas dessas ferramentas é que elas começam a se tornar guardiãs. Eu não sei o quanto você realmente quer mergulhar nisso ou não, Drew. Mas um dos meus grandes contra-ataques contra JS, todas as coisas em um fluxo de trabalho. Especialmente quando você começa a dizer: “Bem, se já estamos usando JS para o HTML, por que não usá-lo para o CSS também?” Você começa a excluir muitas pessoas realmente talentosas do processo de desenvolvimento. É apenas uma perda muito grande para o projeto para a comunidade como um todo.

Drew: Bem, eu certamente estou… Comecei a pegar o React no início de 2020, adicionando isso ao meu conjunto de habilidades. Eu tenho feito isso agora por quase sete meses. Devo dizer que uma parte na qual estou menos confiante é configurar as ferramentas para iniciar um projeto.

Drew: Parece que há muito trabalho para conseguir algo para o Hello World, e há ainda mais que você precisa saber para deixá-lo pronto para a produção. Isso deve dificultar o início do desenvolvimento se isso estiver sendo apresentado como o que você deve fazer em 2020 para aprender a ser um desenvolvedor web. Alguém vindo novo para ele vai ter um problema real. Vai ser uma verdadeira barreira à entrada, não é?

Cris: Com certeza. A outra parte aqui é que os desenvolvedores de JavaScript nem sempre são as únicas pessoas trabalhando em uma base de código ou contribuindo de forma significativa para essa base de código. Quanto mais tornamos o conhecimento de JavaScript um requisito para trabalhar com uma base de código, menos provável é que essas pessoas possam realmente participar do projeto.

Chris: Um exemplo disso, que eu gosto de falar, é o WordPress, que foi recentemente… Eu não deveria dizer recentemente neste momento. Já faz alguns anos. Mas eles estão mudando sua pilha de back-end cada vez mais para JavaScript, longe do PHP, o que não é inerentemente uma coisa ruim. Seu novo editor, Gutenburg, é construído em React.

Chris: Em 2018, a principal consultora de acessibilidade do WordPress, Rian Rietveld, cujo nome eu quase certamente matei… ela renunciou publicamente ao seu posicionamento e documentou o porquê em um artigo realmente detalhado. O cerne do problema era que ela e sua equipe foram encarregadas de auditar esse editor para garantir que ele fosse acessível. O WordPress compreende agora 30% da web. O objetivo deles é democratizar a publicação, então a acessibilidade é uma parte muito importante disso. Deve ser uma parte importante de qualquer projeto web. Mas para eles em particular, é extremamente importante. Todo o trabalho de sua equipe é garantir... todo o trabalho de sua equipe era garantir que esse editor fosse acessível. Mas porque nem ela nem ninguém em sua equipe tinha experiência em React e porque eles não conseguiam encontrar voluntários na comunidade de acessibilidade com essa experiência, tornou muito difícil para ela e sua equipe fazer seu trabalho.

Chris: Historicamente, eles podiam identificar erros e depois corrigi-los. Mas com o novo fluxo de trabalho baseado em React, eles foram reduzidos a identificar bugs e então arquivar tickets. Eles foram adicionados a uma lista de pendências junto com todas as outras solicitações de desenvolvimento de recursos nas quais os desenvolvedores de JavaScript estavam trabalhando. Muitas coisas que poderiam ter sido facilmente consertadas não chegaram ao primeiro lançamento.

Chris: Em maio de 2019, cerca de um ano após a renúncia de Rian, houve uma auditoria detalhada de acessibilidade feita em Gutenburg. O relatório completo tinha 329 páginas. Só o sumário executivo tinha 34 páginas. Ele documentou 91 bugs relacionados à acessibilidade com bastante detalhe. Muitos deles eram realmente… Eu não quero chamá-los de simples frutos de baixo custo, mas muitos deles eram coisas básicas que a equipe de Rian poderia ter consertado e teria liberado os desenvolvedores para se concentrarem no desenvolvimento de recursos. Isso é o que parece que eles acabaram fazendo, gastando muito tempo no desenvolvimento de recursos e deixando essas coisas para mais tarde. Mas essa equipe é super importante para o projeto e, de repente, eles ficaram de fora do processo por causa de uma escolha técnica.

Chris: Alex Russell é um desenvolvedor da equipe do Chrome. Ele escreveu este artigo alguns anos atrás chamado The Developer Bait and Switch, onde falou sobre o argumento espantalho dos frameworks. Essa ideia de que essas ferramentas permitem que você se mova mais rápido e, por causa disso, você pode iterar mais rapidamente e fornecer experiências melhores. É essa ideia de que uma melhor experiência do desenvolvedor significa uma melhor experiência do usuário. Acho que este é um exemplo muito claro de como esse argumento nem sempre funciona da maneira que as pessoas acreditam. É uma experiência melhor para talvez algumas pessoas, não para todos.

Chris: Desenvolvedores de CSS, pessoas que trabalham em sistemas de design, sua capacidade de criar ferramentas que outros podem usar às vezes também fica limitada por essas opções de ferramentas. Na minha experiência, eu costumava ser melhor em CSS. Mudou muito nos últimos anos e não estou nem perto de ser tão bom quanto costumava ser. Na minha experiência, as pessoas que são desenvolvedores CSS realmente avançados... e eu quero dizer isso no sentido mais verdadeiro. As pessoas que trabalham em CSS são desenvolvedores web adequados que trabalham em uma linguagem de programação. É uma coisa muito especial, ou pode ser uma coisa muito especializada. As pessoas que são excepcionalmente boas nisso, na minha experiência, nem sempre são muito boas em JavaScript, porque você acaba mergulhando muito fundo em uma coisa e desliza um pouco em outras coisas. Sua capacidade de trabalhar com essas tecnologias também é prejudicada, o que é muito ruim porque costumava não ser o caso.

Chris: Quando a pilha era mais simples, era mais fácil para pessoas de várias disciplinas participarem do processo de desenvolvimento. Acho que isso prejudica tanto as coisas que construímos quanto a comunidade em geral, quando não é mais o caso.

Drew: Eu encontrei recentemente em um projeto pesquisando maneiras de lidar com alguns dos problemas de CSS, problemas de fluxo de trabalho, estamos tendo vários trabalhos no projeto e o tamanho do pacote aumentando e o CSS antigo nunca sendo removido. Era um projeto React, então estávamos analisando algumas dessas abordagens de CSS em JavaScript para ver o que seria melhor para nós usarmos para resolver os problemas que tínhamos. O que se tornou rapidamente aparente é que não há apenas uma solução para fazer isso. Existem dezenas de maneiras diferentes de fazer isso.

Drew: CSS em JS é uma abordagem geral, mas você pode ir de um projeto para outro e é completamente influenciado de uma maneira completamente diferente. Mesmo se você for uma pessoa de CSS e aprender uma abordagem específica em um projeto, essas habilidades podem não ser transferíveis de qualquer maneira. É muito difícil ver como alguém deve investir muito tempo aprendendo isso se não estiver particularmente confortável com JavaScript.

Cris: Sim. A outra coisa interessante que acho que você acabou de falar um pouco é que quando falo sobre isso, uma das maiores críticas que recebo é que os frameworks impõem convenções. Você está indo com Vanilla JavaScript, você tem esse campo verde-céu azul, você pode fazer o que quiser de projeto. Com o React, existe uma maneira React de fazer as coisas.

Chris: Mas uma das coisas que descobri é que existem abordagens Reacty, mas não há uma maneira correta e rígida de fazer as coisas com React. É uma das coisas que as pessoas adoram nele. É um pouco mais flexível, você pode fazer as coisas de duas maneiras diferentes, se quiser. O mesmo com o Vue. Você pode usar aquela coisa baseada em HTML onde você tem suas propriedades corretas no HTML e Vue as substitui, mas você também pode usar um tipo de sintaxe de template mais parecida com JSX se você preferir.

Chris: Eu ouvi várias pessoas reclamarem quando estão aprendendo React, um dos grandes problemas é que você procura no Google como fazer X em React e você recebe uma dúzia de artigos dizendo uma dúzia de maneiras diferentes de fazer isso. Isso não quer dizer que eles não colocam algumas barreiras em um projeto. Eu não acho que seja tão claro quanto “Eu escolhi uma estrutura. Agora esta é a maneira que eu construo com isso.” Para ser honesto, eu não sei se isso é necessariamente algo que eu gostaria também. Eu não acho que você iria querer aqueles bem confinados... algumas pessoas querem, talvez. Mas se você está divulgando isso como um benefício, não acho que seja tão pronunciado quanto as pessoas às vezes fazem parecer.

Chris: Você entrou em uma coisa interessante lá, onde você mencionou o CSS que não é mais necessário. Eu acho que é uma das coisas legitimamente interessantes que algo como CSS e JS… ou amarrar seu CSS a componentes JavaScript de alguma forma pode te dar é se esse componente cair, o CSS também em teoria, vai embora com ele. Muito disso para mim parece jogar engenharia em problemas de pessoas. Invariavelmente, você ainda depende de pessoas em algum lugar ao longo da linha. Isso não quer dizer que nunca use essas abordagens, mas elas certamente não são a única maneira de resolver esse problema.

Chris: Existem ferramentas que você pode usar para auditar seu HTML e extrair os estilos que não estão sendo usados ​​mesmo sem usar CSS e JavaScript. Você pode escrever CSS “à moda antiga” e ainda fazer o linting de estilos não utilizados. Existem abordagens de autoria para CSS que fornecem um CSS em uma saída semelhante a JS e mantêm sua folha de estilo pequena sem cuspir esses nomes de classe ilegíveis humanos sem sentido que você obtém com CSS e JS às vezes. Como X2354ABC, ou apenas essas palavras sem sentido que são cuspidas.

Chris: É aqui que eu começo a me interessar muito pelo tipo de coisa que o velho grita com a nuvem. Estou realmente mostrando minha idade de desenvolvedor aqui. Mas sim, não é necessariamente que essas coisas sejam ruins, e elas são construídas para resolver problemas legítimos. Às vezes eu sinto que há um pouco de… se é bom o suficiente para o Facebook, é bom o suficiente para nós o tipo de coisa que acontece com isso. Bem, o Facebook usa essa ferramenta. Se somos um programa de engenharia real... equipe, departamento, organização, devemos também. Eu não necessariamente acho que essa é a maneira certa de pensar sobre isso. É porque o Facebook lida com problemas que você não faz e vice-versa. O tamanho e a escala do que eles trabalham são apenas diferentes, e tudo bem.

Draw: Exatamente. Eu vejo algumas dessas coisas como CSS e JavaScript quase como um polyfill. Temos problemas legítimos, precisamos de uma maneira de resolvê-los. A tecnologia ainda não está nos fornecendo uma maneira de resolvê-lo. Talvez enquanto esperamos que a plataforma da web evolua e consiga resolver esse problema, essa coisa que fazemos agora com JavaScript nos ajudará e ficaremos bem. Sabemos que é ruim. Sabemos que não é uma ótima solução, mas nos ajuda neste momento. E espero que, enquanto isso, possamos retirá-lo e usar a solução nativa.

Chris: É muito engraçado você trazer isso à tona. Porque literalmente ontem à noite, eu estava assistindo a uma palestra de Jeremy Keith do ano passado sobre aplicativos da web progressivos. Mas ele estava falando sobre como, algumas décadas atrás, ele estava tentando convencer as pessoas a usar JavaScript. O que parece ridículo na época, mas JavaScript era essa coisa nova. Ele mostrou às pessoas como você pode fazer coisas legais como mudar a cor de um link ao passar o mouse com este novo… Parece absurdo que você precise de JavaScript para isso agora, porque é isso que o CSS faz por você. Mas coisas como o atributo ou propriedade de foco simplesmente não existiam na época.

Chris: Uma das coisas que ele disse na palestra que eu acho que realmente ressoou em mim é que o JavaScript de muitas maneiras, pavimenta esses caminhos de vaca. É essa linguagem muito flexível e aberta que podemos usar para criar ou agregar recursos que ainda não existem. E então, eventualmente, os navegadores alcançam e implementam esses recursos de uma maneira mais nativa. Mas leva tempo. Eu entendo perfeitamente o que você está dizendo sobre isso. Não é a solução perfeita, mas é o que temos agora.

Chris: Acho que, para mim, a maior diferença entre polyfills e algumas dessas soluções é que polyfills são projetados para serem removidos. Se eu tenho um recurso que eu quero implementar que o navegador ainda não suporta, mas há algum tipo de especificação para ele e eu escrevo um polyfill… mudar nada. Mas quando você segue o caminho de usar algumas dessas ferramentas, rasgá-las significa reescrever toda a sua base de código. Isso é muito caro e problemático. Isso não quer dizer nunca usá-los, mas sinto muito fortemente que devemos pensar em escolher ferramentas que possam ser facilmente retiradas mais tarde. Se não precisarmos mais deles ou a plataforma os alcançar, não será necessária uma grande reescrita para retirá-los.

Chris: Então, chegando a isso, temos um monte de estilos que não usamos mais, é por isso que eu pessoalmente preferiria uma tecnologia de ferramenta de construção que audite seu CSS em relação à marcação renderizada e extraia as coisas que você não precisa. Porque no futuro, se uma plataforma alcançar, você pode retirar essa peça da ferramenta de construção sem ter que mudar tudo. Está apenas aumentando o que você já tem, enquanto CSS e JS não oferecem o mesmo tipo de benefício. Estou apenas escolhendo essa, mas penso em muitas dessas tecnologias de forma mais ampla.

Chris: Eu sinto que coisas como React ou Vue provavelmente estão abrindo alguns caminhos que os navegadores eventualmente alcançarão e provavelmente usarão abordagens semelhantes, se não as mesmas, então pode haver menos reescritas envolvidas. Muitas das coisas do ecossistema que ficam conectadas podem ser menos.

Drew: Acho certo, não é, que a plataforma web se mova devagar e com cuidado. Você acha que se cinco anos atrás, todos nós estivéssemos colocando carrosséis de JavaScript em nossas páginas. Eles estavam por toda parte. Todo mundo estava implementando carrosséis JavaScript. Se a plataforma web tivesse saltado e implementado uma solução Carousel para satisfazer essa necessidade, ela não estaria lá sem ninguém usando porque as pessoas não estão mais fazendo isso com Carousels. Porque era apenas uma moda passageira, uma tendência de design. Para neutralizar isso e impedir que a própria plataforma fique inchada e se torne um problema que precisa ser resolvido, ela precisa se mover em um ritmo muito mais constante. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. Você concordaria com isso?

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. Absolutamente. Absolutamente. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

Chris: Uma das outras coisas em que não entramos tanto quanto eu gostaria, mas acho que é muito importante, é que a plataforma alcançou grande sucesso nos últimos anos. Abraçar isso o máximo possível resultará em uma experiência na Web para as pessoas mais rápida, menos frágil, mais fácil para você construir e manter porque requer menos dependências, como usar o que o navegador oferece -a Caixa. Costumávamos precisar de jQuery para selecionar coisas como classes. Agora os navegadores têm maneiras nativas de fazer isso. As pessoas gostam do JSX porque ele permite que você escreva HTML em JavaScript de uma maneira mais simples. Mas também temos literais de modelo em Vanilla JavaScript que oferecem o mesmo nível de facilidade sem a dependência adicional. O próprio HTML agora pode substituir muitas coisas que costumavam exigir JavaScript, o que é absolutamente incrível.

Chris: Nós conversamos um pouco sobre… isso é uma coisa de CSS, mas paira sobre links e como isso costumava exigir JavaScript. Mas usando itens como detalhes e elementos de resumo, você pode criar divulgação, como expandir e recolher ou elementos de acordeão nativamente, sem necessidade de script. Você pode fazer entradas autocompletas usando apenas um… Eu não deveria dizer apenas, eu odeio essa palavra. Mas usando um elemento de entrada humilde e, em seguida, um elemento de lista de dados que é associado a ele, com algumas opções. Se você está curioso sobre como essas coisas funcionam no vanillajstoolkit.com, eu tenho um monte de coisas JavaScript que a plataforma oferece. Mas também tenho alguns usados ​​para exigir JavaScript e agora não há coisas que possam ser interessantes também se você quiser que alguns exemplos de código acompanhem isso.

Chris: No lado CSS das coisas, meu plugin Vanilla JS mais popular de todos os tempos é essa biblioteca que permite animar a rolagem para baixo para links âncora. É muito grande. É o pedaço de código mais difícil que já tive que escrever. E agora é completamente substituído por uma única linha de CSS, o comportamento de rolagem é suave. É mais performático. É mais fácil escrever. É mais fácil modificar seu comportamento. É apenas uma solução geral melhor.

Chris: Uma das outras coisas que eu gostaria que fizéssemos mais é usar aplicativos de várias páginas. Sinto-me um pouco justificado aqui, porque recentemente vi um artigo de alguém do Google que na verdade defende essa abordagem agora também. Achei muito interessante, dado esse enorme angular e então framework… todas as coisas, bum, que o Google começou alguns anos atrás. É legal vê-los voltar a isso. Usando coisas como geradores de sites estáticos e serviços incríveis como Netlify e cache de CDN, você pode criar experiências da Web incrivelmente rápidas para pessoas que usam arquivos HTML individuais para todas as suas diferentes visualizações. Então, meio que me apoiando em algumas dessas coisas fora da caixa.

Chris: Em situações em que isso não é realista para você, onde você precisa de mais JavaScript, você precisa de algum tipo de biblioteca, talvez dando uma olhada nas abordagens menores e mais modulares primeiro, em vez de apenas ir para os gigantes da indústria. Em vez de React, o Preact funcionaria? Em vez de angular... quero dizer, em vez de Vue, Alpine JS funcionaria? Há também um pré-compilador realmente interessante agora chamado Svelt, que oferece uma experiência semelhante a um framework e depois compila todo o seu código em Vanilla JavaScript. Então você obtém esses pacotes realmente minúsculos que têm exatamente o que você precisa e nada mais. Em vez de CSS e JavaScript, você poderia inserir algum linter CSS de terceiros que comparará seu HTML com seu CSS e retirará as coisas que foram deixadas lá por acidente? Uma maneira diferente de criar seu CSS, como CSS orientado a objetos de Nicole Sullivan, funcionaria? Nós realmente não chegamos a falar sobre isso, mas é uma coisa muito legal que as pessoas deveriam conferir.

Chris: E então eu acho que talvez a terceira e mais importante parte aqui, mesmo que seja menos uma abordagem específica e mais apenas uma coisa que eu gostaria que mais pessoas tivessem em mente, é que a web é para todos. Muitas das ferramentas que usamos hoje funcionam para pessoas que têm boas conexões de internet e dispositivos poderosos. Mas eles não funcionam para pessoas que estão em dispositivos mais antigos, têm conexões de internet irregulares. Não se trata apenas de pessoas em áreas em desenvolvimento. Isso também são pessoas no Reino Unido, em certas partes dos EUA, onde temos conexões de internet absolutamente abismais. O meio do nosso país tem internet muito lenta. Eu sei que há lugares em parte de Londres onde eles não podem conectar uma nova banda larga por razões históricas, então você fica com essas conexões de internet antigas que são muito ruins. Há lugares assim em todo o mundo. Da última vez que estive na Itália, a mesma coisa. A internet lá era horrível. Não sei se mudou desde então.

Chris: As coisas que construímos hoje nem sempre funcionam para todos, e isso é muito ruim. Porque a visão da web, o que eu amo nela, é que ela é uma plataforma para absolutamente todos.

Drew: Se os ouvintes quiserem saber mais sobre essa abordagem, você entrou em muitos detalhes em seu livro, The Lean Web. E isso está disponível online. É um livro físico ou um livro digital?

Chris: É um pouco dos dois. Bem não. Definitivamente não é um livro físico. Você vai para leanweb.dev. Você pode ler a coisa toda de graça online. Você também pode, se quiser, há versões EPUB e PDF disponíveis por uma quantia muito pequena de dinheiro, esqueci quanto agora. Faz tempo que não olho. A coisa toda é grátis online se você quiser. Você também pode assistir a uma palestra sobre este tópico, onde eu entro em mais detalhes, se você quiser.

Chris: Mas eu também montei uma página especial só para os ouvintes do Smashing Podcast em gomakethings.com/smashingpodcast, porque eu sou muito criativo em nomear as coisas. Isso inclui vários recursos além do livro, sobre coisas sobre as quais falamos hoje. Ele se conecta a muitas das diferentes técnicas que abordamos, outros artigos que escrevi que se aprofundam em alguns desses tópicos e expandem um pouco meu pensamento. Se as pessoas querem aprender mais, esse provavelmente seria o melhor lugar para começar.

Drew: Isso é ótimo. Obrigada. Tenho aprendido tudo sobre a Lean Web. O que você tem aprendido ultimamente, Chris?

Chris: Sim, algumas coisas. Eu aludi a isso um pouco antes ao assistir ao vídeo de Jeremy em aplicativos da web progressivos. Eu tenho adiado aprender como realmente escrever meu próprio aplicativo da web progressivo por alguns anos porque eu não tinha uma necessidade específica em nada com que eu estava trabalhando. Recentemente, aprendi com um de meus alunos que está na África do Sul, que eles estão lidando com apagões por causa de algumas coisas que estão acontecendo lá. Como resultado, ela não pode trabalhar em alguns dos projetos que estamos fazendo juntos regularmente, porque a energia acaba e ela não pode acessar o portal de aprendizado e acompanhar.

Chris: Para mim, agora construir uma experiência em que funcione mesmo que alguém não tenha internet se tornou uma prioridade maior do que… Percebi que talvez fosse antes, então comecei a investigar isso e espero conseguir isso as próximas semanas. Veremos. Os recursos de Jeremy Keith sobre isso têm sido um salva-vidas absoluto. Fico feliz que eles existam.

Chris: Eu sei, Drew, você mencionou que uma das razões pelas quais você gosta de fazer essa pergunta é para mostrar que as pessoas, não importa o quão experientes sejam, estão sempre aprendendo. Apenas uma pequena anedota relacionada. Eu tenho sido um desenvolvedor web para eu acho, cerca de oito anos. Eu ainda tenho que pesquisar no Google a propriedade CSS a ser usada para fazer as coisas em itálico, literalmente toda vez que eu a uso. Por alguma razão, meu cérebro usa como padrão a decoração de texto, mesmo que não seja a correta. Vou tentar algumas combinações de coisas diferentes, e sempre erro uma palavra toda vez. Às vezes também escrevo itálico em vez de itálico. Sim. Se alguém já está se sentindo como, ah, eu nunca vou aprender essas coisas... apenas saiba que não importa o quão experiente você seja, sempre há alguma coisa realmente básica que você procura no Google repetidamente.

Drew: Sou desenvolvedor web há 22, 23 anos, e ainda tenho que pesquisar no Google as diferentes propriedades do Flexbox, sempre. Embora eu use isso por 23 anos. Mas sim, algumas coisas apenas… provavelmente haverá mais coisas assim à medida que envelheço.

Cris: Sim. Honestamente, acabei construindo um site inteiro de coisas que eu pesquisei várias vezes, apenas para ter uma referência mais fácil de copiar e colar, porque isso era mais fácil do que pesquisar no Google.

Drew: Isso não é uma má ideia.

Chris: Esse é o tipo de preguiçoso que eu sou. Vou construir um site inteiro para me salvar como três segundos de Google.

Drew: Se você, o ouvinte, gostaria de ouvir mais de Chris, você pode encontrar o livro dele na web em leanweb.dev, e seu boletim informativo Dicas para desenvolvedores e muito mais em gomakethings.com. Chris está no Twitter em Chris Ferdinandi. E você pode conferir o podcast dele em vanillajspodcast.com ou onde você costuma pegar seus podcasts. Obrigado por se juntar a nós hoje, Chris. Você tem alguma palavra de despedida?

Chris: Não. Muito obrigado por me receber, Drew. Eu tive um tempo absolutamente esmagador. Isso foi muito divertido. Agradeço muito a oportunidade de vir conversar.