Smashing Podcast Episódio 32: Revisão do ano de 2020

Neste episódio, estamos analisando 2020. Com quem falamos em nossos episódios deste ano e o que aprendemos? Vamos ouvir alguns clipes para descobrir.

Mostrar notas

Você pode encontrar todos os nossos episódios anteriores, incluindo uma transcrição completa de cada entrevista em podcast.smashingmagazine.com.

Nos vemos em 2021, pessoal!

Transcrição

Drew McLellan: Em janeiro, conversei com Amy Hupe sobre seu trabalho no sistema de design do governo do Reino Unido e, em particular, como a equipe aumentou a adoção do sistema pela organização mais ampla, incentivando contribuições. Aqui está Amy.

Amy Hupe: Começamos muito cedo. Então, muito antes de termos um tipo de sistema de design público, começamos a nos envolver com pessoas que pensávamos que seriam contribuintes interessados. Devo mencionar aqui que tínhamos um designer de serviço brilhante na equipe. Ela se juntou a nós… Não vou acertar as datas de forma alguma no momento, mas acho que ela trabalhou conosco durante todo o ano de 2018, e o nome dela é Ignacia. Ela simplesmente fez um trabalho fantástico de sair por aí e envolver as pessoas. Então, uma das coisas que ela fez foi identificar todos os diferentes padrões no governo e todos os diferentes tipos de variações desses padrões. Então, saindo e meio que dizendo: “Ok. Há 10 maneiras diferentes de pedir um endereço no governo. Vamos analisá-los todos juntos e decidir qual achamos ser a abordagem mais apropriada. Como podemos consolidá-los em um?”

Amy Hupe: Ela fez um grande workshop para tentar fazer com que as pessoas olhassem para eles e fizessem esse tipo de consolidação como uma equipe. Eu acho que definitivamente sua abordagem de construir uma colaboração antes de lançarmos qualquer coisa para o público realmente ajudou com isso porque significava que as pessoas já tinham esse tipo de consciência disso, e muitas pessoas já haviam contribuído para isso de alguma forma ou outro antes de realmente torná-lo público. Então estávamos meio que alguns passos à frente. Então eu acho que isso foi muito importante e apenas persistência, muita persistência de toda a equipe em ajudar as pessoas a contribuir.

Amy Hupe: Acho que há uma ideia de que se você conseguir que as pessoas contribuam para um sistema de design, isso é um trabalho muito legal, porque você pode fazer com que as pessoas façam todo o trabalho para você, e você fica sentado lá, e você faça suas pequenas correções de código, e todo mundo está realmente dando a você todas as coisas boas. Mas, na verdade, como qualquer um que trabalhou em um sistema de design saberá, é incrivelmente complexo. É muito difícil criar uma solução centralizada que funcione para várias equipes diferentes.

Amy Hupe: Realmente, a menos que você tenha trabalhado em um sistema de design, não é razoável esperar que alguém realmente entenda o que é preciso. Então, há muito tipo de mão. Há muito trabalho envolvido em apoiar os contribuidores para contribuir. Acho que já disse isso antes, mas provavelmente leva mais tempo, eu acho, para ajudar alguém a contribuir para um sistema de design do que simplesmente fazer a coisa você mesmo e a equipe centralizada. Mas acho que reconhecer o valor que isso traz e ser persistente em seus esforços para conscientizar as pessoas sobre a contribuição, ajudá-las a fazê-lo, ajudá-las a se sentirem motivadas a fazê-lo, acho que sim, essa persistência foi realmente a chave para nosso sucesso nessa área.

Drew: Nós fomos acompanhados por Stephanie Stimac e Aaron Gustafson da Microsoft para falar sobre o Edge adotar o Chromium como seu mecanismo de renderização. Perguntei a Aaron sobre o cenário competitivo entre navegadores e onde os vários navegadores reunidos no mesmo mecanismo de renderização acabariam com essa competição saudável e, portanto, seriam ruins para a web aberta.

Aaron Gustafson: Isso é algo com o qual eu definitivamente sou uma pessoa de padrões da web há muito tempo, meio que luto um pouco. Eu entendo totalmente a justificativa comercial para isso. Do ponto de vista da Microsoft, fazia muito sentido. De uma perspectiva de desenvolvimento de front-end, é bom não ter que atender a um monte de motores diferentes. Quero dizer, no geral, aqueles de nós que trabalham na web há muito tempo certamente viram muita convergência em termos de renderização. Não temos tantos problemas quanto tivemos, digamos, na Netscape por sete dias, onde tivemos como... Eu conhecia empresas que estavam criando folhas de estilo exclusivas para cada navegador diferente, o que era simplesmente insustentável.

Aaron Gustafson: Mas acho que o que é diferente agora é que nas guerras dos navegadores originais, você tinha todos esses mecanismos proprietários, e todo mundo estava meio que em um jogo de superioridade em termos de tentar lançar novos recursos de plataforma e novos recursos de JavaScript ou no caso de JavaScript de engenharia reversa da Microsoft para criar JScript e tentar descobrir como encaixá-lo.

Aaron Gustafson: Mas agora temos a capacidade de trabalhar juntos em projetos de código aberto e ainda ter o diálogo e ainda... não sei. Lutar não é a palavra certa, mas ter discussões sérias sobre o impacto de diferentes abordagens e discordar uns dos outros e realmente trabalhar para tornar as especificações realmente boas e também ter abordagens concorrentes para o código subjacente dentro do contexto de, digamos, um Chromium projeto ou WebKit ou algo dessa natureza ou Missoula no espaço Firefox.

Aaron Gustafson: Então sim. Por um lado, perdemos outro mecanismo de renderização e senti a mesma dor quando a ópera decidiu ir para o Chromium. Mas me sinto um pouco animado por estar dentro da Microsoft e ver como estamos comprometidos em realmente participar do projeto Chromium de maneira significativa e não apenas sentar e aceitar tudo o que vem do Chromium, mas na verdade meio que vetando o que está acontecendo a plataforma e participando disso... Sim.

Aaron Gustafson: Estou um pouco animado com isso e sinto que não estamos lá apenas para tirar esse projeto e apenas aceitar o que quer que seja transmitido por todas as diferentes pessoas que têm interesse nesse projeto, mas para realmente estar colaborando lá também.

Drew: Em fevereiro, conversei com Stephanie Walter sobre como trabalhar com estruturas de interface do usuário como Bootstrap e amigos e equilibrar isso com as necessidades personalizadas de uma interface utilizável. Perguntei a Stephanie se era possível criar uma interface de usuário altamente utilizável usando uma estrutura pronta para uso ou se sempre seria um compromisso um pouco estranho.

Stephanie Walter: Sim. Eu acho que é. Mas também depende do nível de compromisso que você está disposto a fazer, e isso compromete os dois lados. No momento, estou comprometendo muitos botões, por exemplo, porque você tem alguns botões realmente específicos em uma interface de material. Eu realmente não gosto do efeito cascata no botão. Acho que funciona muito bem em dispositivos móveis porque, em dispositivos móveis, você precisa de um grande feedback quando o usuário clica ou toca no botão. Mas então eles pisam esse tipo de efeito cascata que vai até o botão. É um pouco exagerado, especialmente quando há muitos botões. Mas ainda vamos manter esse efeito cascata porque seria super complexo removê-lo porque isso foi embutido no framework React e ter outro efeito hover nesse botão, algo mais sutil que não seria esse tipo de coisa espessa aqui. Seria supercomplexo. Então esse é o tipo de compromisso que você faz.

Drew: Design ético foi o assunto da minha conversa com Trina Felber e Martin Michael Fredrickson. Perguntei se adotar uma abordagem ética ao design e evitar padrões obscuros era um caso de pensar a longo prazo sobre a saúde e o crescimento de um negócio, em vez de apenas as metas de vendas de curto prazo. Aqui está Martinho.

Martin Michael Fredrickson: Isso é perfeitamente verdade. Eu acho que você tem que olhar para o negócio que você faz online como se você tivesse uma loja na rua principal de uma cidade de médio porte, onde você tem que manter sua reputação intacta. Se você não tratar bem seus clientes, se não tratar bem seus clientes, a longo prazo, você ficará sem negócios porque as pessoas irão para alguma outra loja ou comprarão online. Então, o que quer que você faça online, você realmente tem que pensar que há um efeito de longo prazo e também há um custo oculto em fazer coisas complexas ou manipuladoras. Se você desorganizar, como diz Trina, haverá uma economia de longo prazo, e isso nunca é calculado quando se fala em modelo de negócios. Você sempre fala sobre quanto dinheiro pode ganhar. Você nunca fala sobre o custo de fazer essa quantia de dinheiro.

Drew: Em março, conversei com Eduardo Boucas sobre uma ferramenta open source chamada Sourcebit que reúne conteúdo de fontes díspares e disponibiliza para o seu gerador de site estático. Perguntei ao Eduardo se isso poderia melhorar a experiência do usuário de autorizar um SSG, permitindo a integração com ferramentas como CMSs headless.

Eduardo Boucas: Exatamente. Sim. Do jeito que poderia… Eu meio que vejo duas maneiras diferentes de usar a ferramenta que pode ajudar os desenvolvedores. Uma delas é tornar o Sourcebit parte de sua rotina de implantação. Então, se você está usando uma plataforma de hospedagem, como o Netlify, por exemplo, e configura seus comandos deploy para ser, sei lá, Hugo build, é, o comando build para Hugo ou algo assim, o tipo de comando que gera os arquivos estáticos para Hugo. Você também teria outro comando como parte dessa rotina. Isso seria algo como Sourcebit fetch. Então, no momento da compilação, o Sourcebit irá puxar todos os outros dados, gerar todos os arquivos que Hugo precisa e, em seguida, toda a implantação já usará esses arquivos e implantará todo o conteúdo que está vindo do CMS.

Eduardo Boucas: Então esse é um caso de uso possível para o Sourcebit. A outra é usar o Sourcebit como um desenvolvimento local no fluxo de trabalho de desenvolvimento local. Assim, você pode executar o Sourcebit com algo que chamamos de modo de observação. Portanto, o Sourcebit continua procurando por alterações na fonte de dados remota, portanto, neste caso, o CMS headless. Portanto, sempre que você publicar um artigo ou alterar uma entrada no CMS, o Sourcebit reconhecerá isso e gerará novamente todos os arquivos para você localmente.

Eduardo Boucas: Então o que isso significa para o desenvolvedor trabalhando localmente é que você pode ter sua janela do CMS ao lado do seu site Hugo rodando localmente, e então você pode ver as mudanças acontecendo em tempo real. Você altera algo no CMS e pode ver essa alteração refletida no site local, o que acho super útil. Então, essas são as duas maneiras pelas quais você pode usar o Sourcebit.

Drew: A otimização de conversão foi o tópico do dia. Quando falei com o podcaster e consultor veterano, Paul Boag. Falamos sobre algumas das técnicas que os sites usam para converter visitantes em clientes. Mas eu queria perguntar a Paul como você mede o impacto das mudanças que você faz. Paulo explicou.

Paul Boag: Sim. Absolutamente. Eu acho que, novamente, isso é algo em que muitas organizações são muito ruins em ser claro sobre como eles vão medir o sucesso. Agora, sim, sua taxa de conversão é uma métrica. Você deve absolutamente estar seguindo. Mas mesmo com a conversão, você precisa ser um pouco mais sofisticado do que quantas pessoas estão comprando. Você também precisa prestar atenção ao valor médio do pedido. Você precisa prestar atenção especial ao valor da vida útil, certo? Então, quanto vale um cliente ao longo de toda a sua vida, porque você pode descobrir que está obtendo uma rotatividade bastante alta de clientes, se estiver usando padrões escuros e coisas assim. Mas, na verdade, a conversão deve ser apenas uma das métricas que você está medindo.

Paul Boag: Também há coisas como você precisa prestar atenção ao engajamento, quão engajadas estão as pessoas com seu conteúdo, porque isso faz uma grande diferença se elas eventualmente irão converter. Então você está olhando para coisas como, quanto custam seus vídeos, eles assistem, quanto tempo eles passam em seu site e o que eles estão vendo enquanto estão fazendo isso? Eles estão se envolvendo nas mídias sociais e esse tipo de coisa? Então o aspecto final é obviamente a usabilidade. Você precisa medir a rapidez com que alguém pode concluir uma tarefa específica em seu site e quão fácil eles acham que o sistema deve usar e vários outros critérios diferentes.

Paul Boag: Existem muitos mecanismos que você pode usar para medir essas coisas diferentes. Existem algumas ótimas ferramentas por aí e também algumas boas métricas que você pode adotar. Assim, por exemplo, com usabilidade, há algo chamado escala de usabilidade do sistema que pode ser uma métrica muito útil para medir. Mas igualmente, existem ferramentas como maze.design que eu uso com frequência, que vai medir quanto tempo está levando alguém para fazer uma compra, por exemplo, passar pelo checkout. Então sim. Tendo esse tipo de ampla gama de métricas, você não está apenas focando em quantas vendas fizemos neste trimestre? Você tem que olhar para o quadro maior.

Drew: Em abril, conversei com Laura Kalbag da Better Blocker sobre privacidade online. Conversamos sobre as fronteiras cada vez mais estreitas entre o que é considerado público e o que é privado e como as coisas que consideramos privadas podem não ser vistas dessa forma pelas empresas às quais confiamos nossos dados. Aqui está a Laura.

Laura Kalbag: Eu tenho um exemplo clássico disso que aconteceu comigo alguns anos atrás. Então eu estava no Facebook, e minha mãe tinha acabado de morrer, e eu estava recebendo anúncios para diretores de funerais. Achei muito estranho porque ninguém da minha família havia dito nada em uma plataforma de mídia social naquele momento. Ninguém da minha família disse nada no Facebook porque concordamos que ninguém quer descobrir esse tipo de coisa sobre um amigo ou membro da família pelo Facebook. Então não dissemos sobre isso.

Laura Kalbag: Então perguntei aos meus irmãos: “Ah, alguém disse alguma coisa no Facebook que possa causar isso estranho”. Porque geralmente só recebo anúncios de maquiagem e vestidos e testes de gravidez e todas aquelas coisas divertidas que eles gostam de falar. São mulheres de uma certa idade. Em vez disso, minha irmã voltou para mim. Ela disse: “Bem, sim. Meu amigo mora na Austrália.” Então, enviei uma mensagem para ela no Facebook Messenger e disse a ela que nossa mãe havia morrido. Claro, o Facebook sabia que somos irmãs. Ele tem aquela conexão de relacionamento que você pode optar por adicionar lá. Quero dizer, provavelmente poderia adivinhar que éramos irmãs de qualquer maneira, pelos locais em que estivemos juntas, pelo fato de compartilharmos um sobrenome e decidir: “Ah, esse é um anúncio apropriado para colocar nos pés dela”.

Drew: É preocupante, não é, pensar que a tecnologia está tomando essas decisões por nós, que realmente afeta as pessoas potencialmente neste exemplo em um momento bastante sensível ou vulnerável?

Laura Kalbag: Sim. Dizemos que é assustador. Muitas vezes as pessoas dizem: “Ah, é quase como se o microfone do meu telefone ou laptop estivesse me ouvindo porque eu estava conversando sobre esse produto em particular e, de repente, ele está aparecendo no meu feed em todos os lugares”. Acho que o mais assustador é o fato de que a maioria deles não tem acesso ao seu microfone. Mas é o fato de que seus outros comportamentos, sua busca, o fato de saber com quem você está falando por causa de sua proximidade e sua localização em seus dispositivos. Ele pode conectar todas aquelas coisas que talvez não nos conectemos apenas para dizer: “Ah, talvez eles estejam interessados ​​neste produto porque provavelmente já estavam pensando, falando sobre isso”.

Drew: Quando a pandemia de coronavírus chegou e muitas nações entraram em alguma forma de bloqueio, conversei com Rachel Andrew sobre como o Smashing estava adaptando sua conferência pessoal programada para acontecer online. Tendo acabado de adiar a conferência Smashing, em São Francisco, perguntei a Rachel qual era o plano para transferir as próximas conferências e workshops para o domínio virtual.

Rachel An Drew: Muito, muito rapidamente, uma vez que percebemos que teríamos que adiar San Francisco, obviamente, temos workshops, tanto eu quanto Vitaly organizamos workshops em smash e comp, e eles estavam esgotados em San Francisco, ambos de nossas oficinas. Obviamente, temos muitas outras pessoas que vêm e realizam workshops para nós, pessoas com quem trabalhamos há muito tempo, e eles estavam descobrindo que todos os seus workshops, e para aqueles de nós que fazem workshops, eles realmente parte fundamental de nossa renda.

Rachel An Drew: Falando em público, você não ganha muito dinheiro normalmente indo e falando em público. A maioria das pessoas não recebe muito, não quando você considera a quantidade de tempo que leva para escrever palestras e assim por diante. Workshops tendem a ser uma boa maneira para as pessoas que são boas em ensinar essas coisas de ganhar algum dinheiro. Então eles representam a renda das pessoas. Então, não só precisava de mim e Vitaly havia perdido nossas oficinas no início deste ano. Também percebemos que muitos dos nossos palestrantes do Smashing também dependiam desses workshops.

Rachel An Drew: Então pensamos: “Bem, por que não apenas levá-los online?” Muito, muito rapidamente, realmente poucos dias depois disso acontecer, decidimos que eu e Vitaly seríamos os primeiros a colocar nossas cabeças sobre o poder, mas dado que somos nós, poderíamos descobrir como fazê-lo. Também temos oficinas muito diferentes. Vitaly é muito mais colaborativo. Ele tem atividades em grupo e coisas. Eu ensino estilo de sala de aula. Então, entre nós, pensamos: “Bem, estamos cobrindo todas as bases”. Então pensamos: “Vamos fazer isso. Vamos ver se funciona.” Então nós os anunciamos. Nós meio que descobrimos quanto tempo cada um levou, e então sentamos e dissemos: “Bem, como é realmente um workshop online? O que é isso?"

Drew: Eu acho que de uma perspectiva técnica como desenvolvedores da web que imediatamente pensam, como diabos vamos entregar algo assim, quero dizer, deve haver muitas plataformas diferentes que você olhou. Quais foram as diferentes coisas que você olhou e o que Smashing eventualmente veio com?

Rachel An Drew: Então nós demos uma olhada em todo tipo de coisa, e ainda estamos meio que no processo de fazer isso. Estamos usando o Zoom no momento. O motivo pelo qual estamos usando o Zoom é a acessibilidade. Era a mais acessível das plataformas. Obviamente, não queremos excluir as pessoas por causa da plataforma que escolhemos. Eu acho que as outras plataformas estão melhorando e as pessoas estão… Eu acho que muitas plataformas tiveram pessoas vindo até elas e dizendo: “Sim, você está ótima. Mas precisamos que você seja acessível.” Portanto, o zoom é o mais fácil para as pessoas usarem no momento.” Então é por isso que acabamos usando-os. Não sei se faremos para sempre. Mas é isso que estamos usando no momento, e funcionou muito bem como uma maneira de fazer essas coisas.

Drew: À medida que a fadiga do Zoom se instalou e o mundo começou a se ajustar ao que estava sendo rapidamente chamado de novo normal, conversei com Phil Smith sobre como a tecnologia pode nos ajudar a responder a situações como o COVID-19. Construindo o aplicativo React Native, CardMedic em apenas 10 dias. Perguntei a Phil como ele equilibra a escolha da melhor tecnologia para o trabalho versus as tecnologias com as quais ele está familiarizado e com as quais pode trabalhar rapidamente.

Phil Smith: Essa é uma boa pergunta. Acho que assim que o projeto foi mencionado para mim, pensei que sabia exatamente como vou construir tudo isso. Se eu não tivesse filhos e me sentasse em um quarto escuro, acho que provavelmente poderia ter mudado tudo em cerca de cinco dias se estivesse trabalhando nisso de maneira sólida, sólida, sólida, porque os requisitos estavam muito em de acordo com a minha experiência de criação de aplicativos. Eu construí coisas semelhantes, onde ele chama uma API, armazena os resultados no estado e os apresenta. Agora estou em uma posição em que há algumas partes em que estou tipo: “Ok, preciso voltar e refatorar isso”.

Phil Smith: Eu já falei sobre digitar tin, mas na verdade os tipos podem ser bastante soltos no aplicativo, e isso precisa ser reforçado. No back-end, não há muitos testes e agora estamos começando a lançar o back-end porque muitas pessoas se apresentaram e disseram: “Na verdade, este é um ótimo recurso. Eu gostaria de oferecer meus serviços para traduzir isso para minha língua nativa.” O back-end está sendo usado por mais pessoas, então estou pensando: “Espere, preciso de mais alguns testes aqui para garantir que nada possa quebrar porque há pessoas usando isso em produção agora”. Acho que respondi sua pergunta. Essencialmente, não houve tomada de decisão. Eu só tinha que colocá-lo lá fora o mais rápido possível.

Drew: À medida que os locais de trabalho fechavam e muitos de nós nos adaptamos ao trabalho em casa, conversei com Ben Frain sobre como otimizar seu espaço de trabalho doméstico para ser um local confortável e produtivo não resultará em problemas de saúde física a longo prazo. Com orçamentos limitados disponíveis para montar em casa, perguntei a Ben se uma boa cadeira era o melhor lugar para começar.

Ben Frain: Esse seria meu conselho. Sim. Quer dizer, não posso professar ser uma autoridade nessas coisas, mas parece que é provavelmente a coisa mais importante que você pode fazer para se sentir confortável ao longo do dia. Você pode começar com algo bastante caro. Cometi o mesmo erro e acabei comprando uma cadeira de escritório de 45 libras da Amazon, e não percebi que ela não tinha uma inclinação para frente, seja qual for a palavra certa para essa coisa, no eixo. Então, o que eu descobri é que estava cavando na parte de baixo das minhas coxas, meio atrás dos meus joelhos, e eu estava pensando: “Por que minhas pernas estão morrendo depois de 45 minutos sentado nessa coisa?”

Ben Frain: Eu acho que particularmente se você trabalha para uma empresa que fornece cadeiras de escritório decentes, você simplesmente as considera como certas, e só quando você olha para aquela marca e marca em particular é que você pensa: “Oh meu Deus, isso é uma cadeira de US$ 700.” Quando você percebe isso, as pessoas pensaram sobre isso e fizeram muito por você, e então, obviamente, você chega ao seu ambiente doméstico e pensa: “Por que não gastar X cem dólares em uma cadeira?” Mas talvez valha a pena. Especialmente se você estiver aqui por um longo tempo.

Drew: E o longo prazo é o que temos. Outra coisa que está por aí a longo prazo é o Drupal. Em junho, conversei com Angie Byron sobre as mudanças no Drupal 9. 20 anos desde seu primeiro lançamento, o Drupal percorreu um longo caminho. Perguntei a Angie como era o processo de atualização de um site Drupal existente ao mudar para o Drupal 9 e se era provável que fosse um grande fardo para aqueles com sites de longa duração.

Angie Byron: Acho que existem basicamente três cenários. Então, se você estivesse executando o Drupal 8, e toda vez que uma nova versão secundária do Drupal 8 fosse lançada, você a atualizasse imediatamente e começasse a usar as novas coisas. Seu caminho vai ser basicamente nada. Você já fez todo o trabalho e está bem. Se você mudou para o Drupal 8 há algum tempo e não está acompanhando as mudanças do BC, há um pouco de trabalho para você.

Angie Byron: É definitivamente a atualização mais fácil em mais de uma década do nosso software, e temos várias ferramentas diferentes para ajudá-lo. Há um painel que mostra todos os módulos contribuídos e qual é a situação do Drupal 9. Existem ferramentas automatizadas para examinar e verificar seu código e sinalizar quaisquer funções obsoletas que você tenha, e existem ferramentas para subir automaticamente e encontrar: “Ah, esta é a versão mais recente do seu módulo e está pronta para o Drupal 9? Você deveria fazer o download”, esse tipo de coisa.

Angie Byron: Então, do Drupal 8 ao 9, eu diria que essa parte está muito bem coberta. Se você está vindo de uma versão anterior do Drupal, digamos Drupal 7 ou inferior ao Drupal 9, isso começa a parecer um pouco mais complicado. Entre as mudanças que fizemos no Drupal 8, onde, por exemplo, mudamos inteiramente para PHP orientado a objetos, e começamos a utilizar padrões de design encontrados em outros projetos de software, o que é uma coisa muito inteligente de se fazer arquitetura, mas não significa que se você tivesse uma tonelada de código personalizado em sua antiga vida, que no Drupal 9, você precisaria encontrar alternativas para isso.

Angie Byron: Então Acquia é um produto e desenvolvimento chamado Acquia Migration Accelerator que visa resolver esse problema, onde estamos criando um bom aplicativo definido pelo React, que lê seus dados antigos do Drupal 7, cria dados equivalentes do Drupal 8 para você juntamente com todos os módulos que você vai precisar que mapeiem para seus módulos antigos do Drupal 7, sempre que possível, para tentar agilizar um pouco esse processo, porque queremos ter certeza de que todos que estão em versões mais antigas ainda podem passar para o nova ordem mundial, onde todos estão na mesma versão e estamos todos trabalhando juntos.

Angie Byron: Além disso, também estendemos o Drupal 7... A comunidade de código aberto do Drupal, seu fim de vida no Drupal 7 a partir de novembro do próximo ano. Atualmente, de qualquer forma, precisamos discutir se o COVID afeta isso ou não. Mas existem várias empresas diferentes, e a Acquia é uma delas que oferece suporte estendido ao Drupal 7 além disso, pelo menos até 2024. Então, isso faz com que as pessoas que tenham uma atualização fácil tenham um ano e meio para fazê-la, as pessoas tenham uma atualização menos fácil, tenham potencialmente três anos e meio para fazê-la ou mais, se precisarem, e estamos nos esforçando muito para possibilitar que todos se mudem e, em seguida, criando ferramentas como Acquia Migrate Accelerator para ajudar a acelerar o processo.

Drew: Learning React foi o assunto de uma conversa com Mina Markham. Mina e eu estávamos na posição de aprender React pela primeira vez. Refletindo sobre quanta carga os frameworks como o React colocam no navegador, perguntei a Mina se colocar tanto controle nas mãos do cliente era um erro.

Mina Markham: Quero dizer sim com a ressalva de que, novamente, minha experiência está muito restrita a sites estáticos. Eu não faço muito desenvolvimento de produtos. Então, talvez nesse reino, isso faça mais sentido. Mas da minha perspectiva, sinto que muitas vezes usamos um machado quando precisamos apenas de uma faca de manteiga. Não sei por que precisamos colocar tudo isso no navegador, colocar tanto trabalho e tanta pressão sobre o cliente quando podemos fazer muito as coisas... Sinto que poderíamos fazer isso muito mais simples. Uma das coisas que sempre me deixou um pouco hesitante em usar o React, ou digo hesitante, mas o que quero dizer quando isso me deixou visceralmente irritado e me opus ativamente foi quando eu ia a um site e literalmente nada renderia porque houve um erro ou algo como realmente a página inteira está quebrada porque uma função quebrou.

Mina Markham: Isso meio que me incomodou que muitas vezes, era uma abordagem de tudo ou nada. Uma das palestras que dei na AEA no passado e em outros lugares no passado foi meio que falando sobre como incluir aprimoramento progressivo e não apenas seu desenvolvimento, mas também uma direção de arte maior e design de sites. Eu destacaria especificamente exemplos de sites que não fizeram aprimoramento progressivo ou qualquer tipo de degradação graciosa. Ou você tem o JavaScript rodando no navegador, ou não recebe absolutamente nada. Seria apenas um site simples que representasse informações sobre a história do web design, que foi um dos sites realmente falados, a história do web design de 1990 até agora. Era um site lindo com muitas timelines, animação das coisas. Mas também poderia ter sido renderizado estaticamente com apenas uma lista. Houve etapas entre não mostrar nada e mostrar aquela experiência maravilhosamente aprimorada que acho que se perdeu por causa da maneira como estamos abordando o desenvolvimento web moderno agora.

Drew: Conversei com Andy Bell sobre CUBE CSS, uma metodologia de estilo no estilo de BEM, SMACSS e OOCSS. Muitas abordagens CSS tentam trabalhar contra as propriedades naturais do CSS como a cascata. CUBE abraça muito esse comportamento. Aqui está Andy.

Andy Bell: Um bom tipo de analogia para isso é SCSS, como Sass, é uma extensão da linguagem CSS natural, não é? Você está praticamente certo em CSS ainda. Então CUBE CSS é assim. Então é uma extensão do CSS. Então ainda devemos escrever CSS, como CSS deveria... bem, deveria ser escrito. Sejamos honestos, é assim que deve ser escrito. O nome indica, Cascading Style Sheets. Então, está abraçando isso novamente porque o que descobri é que desci até o nível de micro-otimização. Eu estive no caminho que vejo muitas pessoas indo recentemente onde... Eu mencionei isso no artigo também, onde posso ver... Há algumas evidências disso recentemente. Eu vi pessoas criando componentes espaçadores e coisas assim, e eu entendo esse problema. Eu estive nessa situação.

Andy Bell: A maneira como eu consertei foi, em vez de detalhar e tentar micro-otimizar, na verdade comecei a pensar nas coisas em um nível de composição porque não importa quão pequenos sejam seus componentes. Em algum momento eles vão ser páginas. Serão visualizações. Você não pode evitar isso. É assim que vai ser. Então, em vez de tentar dizer: “Certo, preciso desses pequenos ajudantes para fazer esse layout”, você diz: “Certo, tenho uma visualização de página de contato ou uma visualização de página de produto, e essa é uma composição de layout esquelética. Então, dentro disso, posso encaixar os componentes que quiser lá.”

Andy Bell: Temos coisas como Grid e Flexbox agora que tornam isso muito mais viável, e você pode essencialmente colocar o que quiser dentro do layout do esqueleto. Não importa. Em seguida, os componentes devem, nesse ponto, se comportar como você deseja que eles se comportem, com ou sem consultas de contêiner.

Drew: Gatsby foi o assunto da minha conversa com Marcy Sutton. Enquanto a maioria dos geradores de sites estáticos são agnósticos de código front-end, o Gatsby usa React e, portanto, você acaba com o código Gatsby sendo executado como parte de sua experiência final na web. Perguntei a Marcy o que era esse código e qual funcionalidade ele estava fornecendo.

Marcy Sutton: Sim. Eu diria que a maior parte disso é o roteamento do lado do cliente. Então Gatsby agora está usando recauchutador sob o capô. É apenas meio que sua própria implementação. Mas essa é a parte que quando você carrega seu site estático pela primeira vez, há arquivos HTML lá. Portanto, se o usuário desativar o JavaScript por algum motivo, seu site ainda deve estar lá, ainda ter conteúdo. Mas se o JavaScript estiver habilitado, é quando essa etapa de hidratação acontece, onde quando você usa links em seu site Gatsby, ele pré-busca recursos dessa página. Assim ele vai carregar mais rápido. Então, tudo isso está habilitado com essa camada JavaScript que Gatsby oferece a você.

Marcy Sutton: Então, além disso, realmente depende do que você está usando em seu site, o que vai acabar nesse pacote JavaScript. Mas para coisas que usam muita interatividade, como interfaces acessíveis, é um bom lugar para se estar. Para mim, eu realmente gosto de ter JavaScript disponível para mim o tempo todo e ter minha marcação em um bom lugar. Eu sei que é uma questão de preferência, se você quer seu HTML e seu JavaScript e seu CSS, todos bem acoplados, e há espaço para variações na construção do Gatsby. Você nem sempre precisa usar algo como CSS e JS. Mas trata-se realmente de obter o poder dessa camada dinâmica de JavaScript disponível para você enquanto escreve seu site. Não é como este complemento em um arquivo separado.

Drew: Quando penso em como um gerador de site estático geralmente funciona, estou pensando em conteúdo em talvez arquivos de markdown e o gerador percorre esse conteúdo e o mescla com modelos e cria dezenas, centenas, milhares de arquivos HTML, que são os páginas do seu site. Quando penso em um site ou aplicativo React, estou pensando mais na experiência de página única, onde as interfaces são criadas pelo React na hora. Então você está dizendo que Gatsby faz as duas coisas? Está criando todas as páginas e também aprimorando com JavaScript?

Marcy Sutton: É, sim. O Gatsby usará o Node.js em tempo de compilação, ele passará pelos seus componentes React e os compilará em arquivos HTML, o que honestamente, na primeira vez que olhei para o Gatsby, não desativei o JavaScript e fiquei tipo, “Tudo bem, existem outras páginas aqui? O que é isso?" Fiquei tão feliz que Gatsby funciona dessa maneira por padrão. Ele criará arquivos construídos a partir de seus componentes React, o que é incrível.

Marcy Sutton: Eu explorei abordagens de aprimoramento mais progressivo, já que é em JavaScript, tipo, e se você quiser produzir algo progressivamente aprimorado para os usuários, onde, se eles tiverem o JavaScript desativado, você não quer todo esse código quebrado que assume JavaScript existe. Portanto, há algumas peculiaridades com ele. Mas você pode contornar esse tipo de coisa, pelo menos para seus fluxos de usuários principais, onde você deseja que alguém ainda possa comprar algo. Pode ser necessário adicionar algum suporte e para esses casos de uso. Mas fiquei agradavelmente surpreso com a maneira como Gatsby lança isso por padrão.

Marcy Sutton: Então é uma escolha que eles fizeram para construir sites dessa maneira, e estamos sempre avaliando, ainda é a melhor maneira? O que precisamos fazer para dar aos nossos usuários o que eles estão pedindo? Então, estamos fazendo algumas explorações internamente, em andamento apenas para garantir que Gatsby esteja fazendo o melhor trabalho possível na construção de um site, mantendo os tamanhos dos pacotes pequenos e certificando-se de que, para fazer compensações pelo que dizemos ser código de desempenho com pré -fetching, temos os dados para fazer backup disso? Esse é o tipo de coisa que eu estou super interessado como um defensor do desenvolvedor, é ter certeza de que o que estamos empacotando e agrupando em sites é realmente necessário e realmente fará o melhor site Gatsby que ele pode fazer.

Drew: Conversando com Chris Ferdinandi em julho, perguntei se as melhores práticas modernas eram ruins para a web. Chris apoia um movimento conhecido como Lean Web, e eu perguntei a ele o que isso implicava. Aqui está o Cris.

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. Cheguei a acreditar que muito do que consideramos como melhores práticas hoje pode estar piorando a web. The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

Chris Ferdinandi: As we'll probably get into in our conversation, I've actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers but not necessarily everybody who's working on the thing you're building. So there's a whole bunch of kind of issues with that too that we can kind of dig into. 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: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? Mas você também pode escolher idiomas de pré-processador. Digamos que você goste de Sass. Você ativa o Sass no CSS e escreve Sass. Bem, algo tem que processar o Sass. Hoje em dia, Sass é escrito em Dart ou algo assim. Theoretically, you could do that in the client. Mas essas bibliotecas que fazem pré-processamento são bem grandes. Acho que não quero enviar toda a biblioteca Sass para você, apenas para executar essa coisa. I don't want to. That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. Mas é assim que funciona agora, existe um lambda. Ele processa Sass. Tem um trabalho minúsculo, minúsculo, minúsculo. You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. Você não precisa se preocupar com escala. You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. I don't know what that is. I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. Mas há um para Sass. Há um para menos. Há um para Babbel. Há um para TypeScript. Há um para… Todos esses são lambdas individuais que executamos. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Mas nós o usamos para muito mais do que isso, mesmo recentemente.

Chris Coyier: Here's an example. Cada caneta no CodePen tem uma captura de tela. Isso é legal, certo? So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Se você compartilhá-lo no Slack, terá uma pequena prévia dele. We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? Não é animado de qualquer maneira. Apenas ganhos de desempenho como esse.

Chris Coyier: So each of those screenshots has a URL to it, obviously. We've architected it so that that URL is actually a serverless function. É um trabalhador. So if that URL gets hit, we can really quickly check if we've already taken that screenshot or not. That's actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store. So the ID of that, we can just check really quick, and it'll be, “True or false, do you have it or not?”

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. Sirva-o como essas dimensões.” Eu não tenho que fazer a imagem nessas dimensões. You just put the dimensions in the URL, and it comes back as that size, magically.

Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here's Guillermo.

Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. Just like different materials have different densities and weights, irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. Esses se tornam pontos de entrada para seu aplicativo que você pode compartilhar por meio de todos os tipos de mídia.

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js também, que é muito, muito bom, pré-busca automaticamente o restante das páginas que estão conectadas a esse ponto de entrada, de modo que pareça um aplicativo de página única. So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here's Cassie.

Cassie Evans: I think that that's what I love the most about SVG is I'm really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding. But without fail, I've managed to get anyone that I taught on board with SVG because there some really approachable entry points because it does look like HTML.

Cassie Evans: So you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it's the graphics instead of documents, and then you can animate that with CSS to start off with, which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it's a really good learning curve.

Drew: Of course, it can be dynamic. It's not just a case of creating motion. You can actually make the properties of it dynamic. So one of the interesting things I've seen SVG used for, and it's a grand term, but data visualization, dataviz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that, isn't it?

Cassie Evans: Yes, definitely. SVG is great for dataviz. All the way from kind of small dataviz up to D3 which is very well known dataviz library that uses SVG under the hood. But you could also just, if you've got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program, and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don't have to go all in with a massive database library. You can kind of just start off small.

Drew: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.

Anthony Campolo: Yeah, it's pushing the boundaries of what a Jamstack application can be. So by calling it full-stack Jamstack, it's about, how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed? How do we get that but also with our back end and have it all connected?

Drew: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. Então, em primeiro lugar, havia uma motivação para mudar a reatividade. Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. Mas tudo bem. Nós vamos te ensinar de qualquer maneira.

Natalia Tepluhina: So reactivity was one of the things. Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster, and also, there was one pain point for a particular part of our, let's say audience, people that use Vue. Era TypeScript. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you were working with our state management Vuex.

Natalia Tepluhina: Então esse foi novamente um grande papel. A última foi que perdemos a funcionalidade de abstrair a lógica, em termos não de componentes, mas de partes lógicas compossíveis, como auxiliares de funções e assim por diante, mas eles deveriam ser capazes de incluir atividades Vue também. Um bom exemplo aqui poderia ser React Hooks, certo? Eles permitem que você abstraia as partes da funcionalidade, e isso estava claramente ausente no Vue. Eu sei que agora soa como “Você roubou o recurso do React”. Não de fato. Acredito que a polinização cruzada de ideias é uma parte grande e agradável do nosso ecossistema, e também ajuda os desenvolvedores a alternar entre os favoritos, certo? Então estávamos trabalhando nesses recursos principais para criar o Vue 3 como versão principal.

Drew: Depois disso, mergulhamos no TypeScript com Stefan Baumgartner para descobrir como ele pode nos ajudar a escrever um código melhor com menos bugs. Observando a tendência das organizações de mover sua base de código inteiramente para JavaScript, perguntei a Stefan se o TypeScript era algo que equipes maiores se beneficiariam mais do que indivíduos.

Stefan Baumgartner: Então estou atualmente na mesma transição. Portanto, temos muitos desenvolvedores Java e C++ que escreverão muito JavaScript no futuro. O TypeScript pode ser uma espécie de guia para aquelas áreas assustadoras da nova linguagem de programação. JavaScript tem muitas peculiaridades, muita história e muitos preconceitos se você vem de uma linguagem de programação diferente. Portanto, o TypeScript pode ser um guia porque há alguns conceitos com os quais você está familiarizado no sistema de tipos.

Stefan Baumgartner: Mas também, eu acho, especialmente quando você tem muitas pessoas trabalhando na mesma base de código ou muitas pessoas que precisam trabalhar umas com as outras, isso pode ser uma camada adicional de orientação em seu projeto, onde você não t ter quaisquer surpresas ruins no final. Então, é claro, a tecnologia não resolve nenhum problema de comunicação. Não é para isso que o TypeScript se destina. Mas pode diminuir, ou pode abrir muito mais espaço para a discussão certa do que, se você não precisar falar sobre o que você espera de mim em seu código, mas sim, o que seu código deve fazer ou o que seu biblioteca faz?

Stefan Baumgartner: Eu sempre digo que se você escrever código para outras pessoas ou se você escrever código com muitas pessoas ou se você apenas escrever código para si mesmo, você tem que revisitar no dia seguinte, considere o TypeScript porque pode ajudá-lo no longo prazo. Este não é apenas um investimento para o próximo projeto da próxima semana, mas mais para quem diz, tudo bem, especialmente se você tem projetos de longa duração para meses, dois ou anos, definitivamente ofereça isso. Você nunca saberá o que estava pensando quando escreveu o pequeno pedaço de código um ano atrás, mas os tipos podem lhe dar uma dica do que você quis dizer.

Drew: Em novembro, conversei com David Darnes sobre o gerador de site estático, Eleventy. Falamos sobre templates e quantos geradores de sites estáticos são fortemente opinativos sobre que tipo de templates você deve usar. Eu me perguntei se Eleventy tinha o mesmo tipo de crenças fortes. Aqui está Davi.

David Darnes: Não, devo dizer que é o mais próximo possível sem opinião. Um pouco de uma visão pessoal, mas eu me esforcei para ver qualquer framework ou qualquer coisa que possa ser sem opinião porque, para criar algo, você tem que ter uma opinião sobre como você quer fazer algo. É uma espécie de oxímoro. Tenho certeza que as pessoas poderiam me corrigir sobre isso. Mas sim. Você pode mudar para qualquer linguagem de template com a qual se sinta mais confortável. Quer dizer, estávamos falando sobre idiomas com os quais você se sente confortável. Eleventy apela a isso de certa forma com o que as linguagens de modelagem usam dentro de seu HTML, ou até mesmo seu CSS, se você quiser.

David Darnes: Para mim, eu fui direto para o nunjucks porque nunjucks é a linguagem de template padrão dentro do Eleventy. Isso significa que posso usar a extensão dot HTML e deixá-la como está. Agora, vou confundir ainda mais as pessoas e dizer: “Você pode nomear isso como quiser de qualquer maneira. Você pode se divertir muito com isso.” Mas você pode usar guidão. Eu acho que você pode simplesmente usar o modelo JavaScript regular e iterar por ele assim. Guidão bastante popular e líquido também. Não consigo pensar em todos eles de cabeça, mas se você configurar tudo na configuração, poderá escolher o que quiser.

David Darnes: Eu diria que sou um grande fã de linguagens de templates em geral. Não faz muito tempo quando descobri que você poderia usar o Twig dentro do WordPress, e isso me surpreendeu. Eu fiquei tipo, “Oh, graças a Deus. Eu não tenho que lidar com um loop for dentro do PHP.” Novamente, acho que algo um pouco mais confortável e compreensível, mais legível também. Então sim. Eleventy tem muitas opções de templates diferentes e deve atrair pessoas que se sentem confortáveis ​​com essas diferentes opções.

Drew: Falei com Leslie Cohn-Wein sobre como a Netlify usa sua própria plataforma para construir a Netlify e como sua funcionalidade Deploy Preview se torna uma plataforma de teste eficaz para mudanças de front-end.

Leslie Cohn-Wein: Talvez minha parte favorita de todo esse processo seja a magia do Deploy Previews, que recebemos através do Netlify. Então, o que acontece é que você está trabalhando no GitHub, você aumenta seu PR. Então, você abre seu PR no GitHub, e isso criará automaticamente uma compilação do seu Deploy Preview do aplicativo. Então, na verdade, usamos o Deploy Previews do próprio aplicativo para testar, para garantir que tudo esteja funcionando como deveria. Executamos nossos testes. Isso é o que usamos para verificar manualmente durante a revisão do código. Portanto, temos toda essa implantação contínua configurada diretamente do GitHub.

Leslie Cohn-Wein: Então, uma das outras coisas legais que configuramos é que na verdade temos alguns sites Netlify diferentes que estão puxando do mesmo repositório onde nosso aplicativo está. Então, temos tanto nosso app. Temos uma instância do Storybook que tem nossos componentes de interface do usuário para o aplicativo. Portanto, temos nosso próprio aplicativo. Temos os componentes da interface do usuário do Storybook e temos basicamente um site Netlify que mostra nossa interface do usuário do Storybook e também temos um terceiro site que executa um analisador de pacote webpack. Portanto, é uma espécie de interface do usuário visual que oferece uma visualização do mapa de árvore de todos os pacotes de aplicativos, e podemos avaliar seu tamanho, e é apenas um lembrete para verificarmos novamente à medida que cada implantação do aplicativo acontece out, podemos verificar e ter certeza de que não estamos fazendo nada estranho com o tamanho do nosso pacote lá.

Leslie Cohn-Wein: Então, todos os três sites são gerados em um pull request do aplicativo. Assim, você obterá links para visualização, essencialmente suas visualizações de implantação, tanto do aplicativo Storybook quanto para esse perfil do aplicativo para que possamos verificar.

Drew: Em dezembro, conversei com Chris Murphy sobre design de produto e o que significa para os negócios serem focados no design. Discutimos se um fundador individual se concentra no design, isso vaza para o negócio e se um produto é naturalmente uma extensão da pessoa que o criou.

Chris Murphy: Acho que é uma pergunta muito boa, Drew, e acho que a resposta é depende. Acho que depende dessa pessoa, e depende da escala da empresa. Se você der uma olhada no Hiut Denim, e eu uso muito o Hiut no meu ensino, é um exemplo muito bom de uma empresa que está fazendo uma coisa bem, e esse é o tipo de jeans de slogan. Eu acho que se você olhar para o David anterior… David e Clare, porque eles são uma parceria. Se você olhar para a empresa anterior de David Hieatt e Clare Hieatt, que era Howies, essa empresa cresceu tanto, havia tantas pessoas envolvidas.

Chris Murphy: Uma vez que a escala começa a aparecer, fica muito difícil ficar de olho em todos os pequenos pontos de contato que importam na jornada do cliente. Acho que é realmente revelador quando eles deixaram Howies, porque Howies tinha sido comprado por… É complicado. Vá ler na internet. Mas era a Timberland, e a Timberland foi comprada, e tem toda essa história.

Chris Murphy: Eu acho muito interessante que eles estão focados agora em jeans. É isso. Eles estão contando uma história incrivelmente boa sobre jeans. Eles também estão embalando tudo muito, muito bem, e os jeans são como um veículo para histórias, realmente. Isso é algo que acho, Drew, que se tornará mais importante à medida que sairmos do outro lado do COVID, do qual espero que saiamos do outro lado. Todo mundo que está fazendo esses jeans está recebendo um salário adequado. Um dos problemas que tenho no momento em que olho para o mundo é que nem todo mundo está recebendo um salário adequado, e acho isso um pouco preocupante, como alguém... Olha, eu tenho 51 anos. Meu filho tem 25, 24 anos. , 25, algo assim. É terrível. Eu deveria saber todas essas coisas. Ele é fotógrafo de casamentos. Ele é fotógrafo de casamento há um ano e pouco. Seu negócio está completamente dizimado porque ninguém vai realmente se casar no momento porque é simplesmente difícil. Ele não tem salário porque não tinha livros de autônomos suficientes para obter o apoio.

Chris Murphy: Ele caiu nas rachaduras, e há muitas outras pessoas que caíram nas rachaduras. Eu diria que isso é um problema de design, que precisamos olhar para isso como um problema de design. Mas se eu também olhar para essa questão mais ampla do COVID e do governo e todas essas coisas sem ficar muito político, li um artigo no Guardian ontem sobre o vizinho de Matt Hancock, e qualquer um que esteja ouvindo que não seja do Reino Unido, Matt Hancock é a Secretaria de Saúde. Seu vizinho, que administrava um negócio, estava enviando uma mensagem para ele e pedindo conselhos sobre: ​​“Como posso fornecer produtos para essa coisa do COVID?” Há muitos rumores em torno da chumocracia, é como os jornais chamam, amigos de amigos de ministros do governo que parecem estar conseguindo empregos porque conhecem as pessoas certas.

Chris Murphy: Tenho a sensação de que vamos chegar ao outro lado disso e ver isso… As pessoas veem isso e pensam: “Bem, para onde está indo esse dinheiro e as pessoas estão sendo pagas adequadamente? Qual é o preço desta camiseta de meio quilo da loja X?” Não quero mencionar nenhuma marca. Mas tudo tem que ser pago, e tudo que é feito, as pessoas têm que ser pagas para fazê-lo. Eu acho que as pessoas estão cada vez mais interessadas, as pessoas estão sendo pagas de forma justa?

Drew: GraphQL foi o tema do nosso último episódio completo do ano, e eu conversei com Eve Porcello e perguntei onde o GraphQL se encaixa na pilha de desenvolvimento.

Eva Porcello: Sim. O GraphQL se encaixa entre o front-end e o back-end. Portanto, é meio que viver no meio entre os dois e oferece muitos benefícios para desenvolvedores de front-end e desenvolvedores de back-end. Se você for um desenvolvedor front-end, poderá definir todos os requisitos de dados de seu front-end. Então, se você tem uma grande lista de componentes do React, por exemplo, você pode escrever uma consulta e isso definirá todos os campos que você precisaria para preencher os dados dessa página.

Eve Porcello: Agora, com o backend, é realmente próprio, porque podemos coletar muitos dados de várias fontes diferentes. Portanto, temos dados em APIs REST e bancos de dados e todos esses lugares diferentes, e o GraphQL nos fornece essa pequena camada de orquestração para realmente entender o caos de onde todos os nossos dados estão. Então é realmente útil para todo mundo na pilha.