Neste episódio, estamos dando uma olhada em 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 .
Vemo-nos 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 por toda a organização, incentivando contribuições. Aqui está Amy.
Amy Hupe: Começamos muito cedo. Portanto, muito antes de termos uma espécie de sistema de design público, começamos a nos envolver com pessoas que pensávamos que seriam contribuidores interessados. Devo mencionar aqui que tivemos um designer de serviços brilhante na equipe. Ela se juntou a nós em… Não vou acertar as datas de forma alguma no momento, mas acho que ela trabalhou conosco durante todo o ano de 2018, e seu nome é Ignacia. Ela simplesmente fez um trabalho fantástico de circular e envolver as pessoas. Portanto, uma das coisas que ela fez foi identificar todos os diferentes padrões de governo e todos os diferentes tipos de variações desses padrões. Então, saindo e dizendo:”Tudo bem. Existem 10 maneiras diferentes de solicitar um endereço no governo. Vamos examiná-los todos juntos e decidir qual achamos que é a abordagem mais apropriada. Como podemos consolidá-los em um?”
Amy Hupe: Ela conduziu um grande workshop para tentar fazer com que as pessoas olhassem para isso e fizessem esse tipo de consolidação como uma equipe. Acho que definitivamente a abordagem dela para construir uma colaboração antes de lançarmos qualquer coisa ao público realmente ajudou nisso, porque significava que as pessoas já tinham esse tipo de conhecimento sobre isso, e muitas pessoas já haviam contribuído para isso de alguma forma ou outro antes de realmente torná-lo público. Portanto, estávamos alguns passos à frente. Então eu acho que foi muito importante e apenas persistência, muita persistência de toda a equipe ajudando as pessoas a contribuir.
Amy Hupe: Eu acho que há uma ideia de que se você faz as pessoas contribuírem para um sistema de design, é um trabalho muito legal, porque você pode simplesmente fazer com que as pessoas façam todo o trabalho para você, e você fica sentado lá , e você faz suas pequenas correções de código, e todo mundo está realmente dando a você todas as coisas boas. Mas, na verdade, como qualquer pessoa que já trabalhou em um sistema de design sabe, é incrivelmente complexo. É muito difícil fazer uma solução centralizada que funcione para várias equipes diferentes.
Amy Hupe: Na verdade, a menos que você tenha trabalhado em um sistema de design, não é razoável esperar que alguém realmente entenda o que é necessário. Portanto, há muitos tipos de apoio para as mãos. Há muito trabalho envolvido no apoio aos contribuintes para contribuir. Eu 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 apenas 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 fazer isso, ajudá-las a se sentirem motivadas a fazê-lo, acho que sim, essa persistência foi realmente tão importante para nosso sucesso nessa área.
Drew: Stephanie Stimac e Aaron Gustafson da Microsoft se juntaram a nós para falar sobre a adoção do Chromium pelo Edge como mecanismo de renderização. Perguntei a Aaron sobre o cenário competitivo entre os navegadores e onde os vários navegadores reunidos no mesmo mecanismo de renderização eliminariam essa competição saudável e, portanto, seria ruim para a web aberta.
Aaron Gustafson: Isso é algo que eu definitivamente tenho sido uma pessoa de padrões da web há muito tempo, meio que me esforço um pouco. Eu entendo totalmente a justificativa de negócios para isso. Do ponto de vista da Microsoft, fazia muito sentido. De uma perspectiva de desenvolvedor de front-end, é bom não ter que atender a um monte de motores diferentes. Quero dizer, de modo 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, no Netscape por sete dias, onde tínhamos apenas… 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, na guerra dos navegadores originais, você tinha todos esses motores 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 do JavaScript de engenharia reversa da Microsoft, para criar JScript e tentar descobrir como encaixá-lo todos juntos.
Aaron Gustafson: Mas agora temos a capacidade de realmente trabalhar juntos em projetos de código aberto e ainda ter o diálogo e ainda… eu não sei. Lutar não é a palavra certa, mas ter discussões sérias sobre o impacto de diferentes abordagens e discordar entre si e realmente trabalhar para tornar as especificações realmente boas e também ter abordagens concorrentes para o código subjacente no contexto de, digamos, um Chromium projeto ou WebKit ou algo dessa natureza ou Missoula no espaço do Firefox.
Aaron Gustafson: Sim, sim. Por um lado, perdemos outro motor de renderização e senti a mesma dor quando a ópera decidiu ir para o Chromium. Mas me sinto um tanto encorajado por estar dentro da Microsoft e ver o quão comprometidos estamos em participar do projeto Chromium de uma forma significativa e não apenas sentar e aceitar tudo que vem do Chromium, mas na verdade meio que vetar o que está acontecendo a plataforma e participando dela… Sim.
Aaron Gustafson: Estou um pouco animado com isso e sinto que não estamos lá apenas para tirar proveito desse projeto e apenas aceitar o que quer que seja transmitido por todas as diferentes pessoas que têm uma participação nesse projeto , mas para realmente colaborar lá também.
Drew: Em fevereiro, conversei com Stephanie Walter sobre como trabalhar com frameworks de IU como Bootstrap e amigos e como equilibrar isso com as necessidades personalizadas de uma interface utilizável. Perguntei a Stephanie se era possível criar uma IU altamente utilizável enquanto se usava uma estrutura de prateleira ou se sempre seria um meio-termo 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 IU de material. Eu realmente não gosto do efeito cascata no botão. Acho que funciona muito bem no celular porque, no celular, você precisa de um grande feedback quando o usuário clica ou toca no botão. Mas então eles atuam nesse tipo de efeito cascata que atinge todo o botão. É um pouco exagero, especialmente quando há muitos botões. Mas ainda vamos manter esse efeito cascata porque seria muito complexo removê-lo porque isso foi integrado à estrutura do React e ter outro efeito de foco neste botão, algo mais sutil que não seria esse tipo de coisa espessa aqui. Seria super complexo. Portanto, esse é o tipo de compromisso que você faz.
Drew: O design ético foi o assunto da minha conversa com Trina Felber e Martin Michael Fredrickson. Perguntei se adotar uma abordagem ética para projetar e evitar padrões obscuros era uma questão de pensar a longo prazo sobre a saúde e o crescimento de uma empresa, em vez de apenas as metas de vendas de curto prazo. Aqui está Martin.
Martin Michael Fredrickson: Isso é perfeitamente verdade. 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 média, onde você tem que manter sua reputação intacta. Se você não trata bem seus clientes, então se você não trata bem seus clientes, a longo prazo, você ficará sem negócios porque as pessoas irão a alguma outra loja ou comprarão online. Portanto, tudo o que você faz online, você realmente tem que pensar que há um efeito de longo prazo e também, há um custo oculto em fazer coisas que são complexas ou manipuláveis. Se você organizar, como diz Trina, haverá uma economia a longo prazo, e isso nunca é calculado quando você fala sobre modelo de negócios. Você sempre fala sobre quanto dinheiro pode ganhar. Você nunca fala sobre o custo de ganhar tanto dinheiro.
Drew: Em março, conversei com Eduardo Bouças sobre uma ferramenta de código aberto chamada Sourcebit que reúne conteúdo de fontes distintas e o disponibiliza para seu gerador de site estático. Perguntei a Eduardo se isso poderia melhorar a experiência do usuário de autorização para um SSG, permitindo a integração com ferramentas como CMS sem comando.
Eduardo Bouças: Exatamente. Sim. Da maneira que poderia… Eu meio que vejo duas maneiras diferentes de usar a ferramenta que podem ajudar os desenvolvedores. Um é tornar o Sourcebit parte de sua rotina de implantação. Então, se você está usando uma plataforma de hospedagem, como Netlify, por exemplo, e você configura seus comandos de implantação para ser, não sei, 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 busca Sourcebit. Então, no momento da compilação, o Sourcebit irá puxar todos os outros dados, gerar todos os arquivos de que Hugo precisa e, em seguida, toda a implantação já usará esses arquivos e implantará todo o conteúdo que vem do CMS.
Eduardo Bouças: Esse é um tipo de caso de uso possível para o Sourcebit. O outro é 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 relógio. Assim, a Sourcebit continua procurando por mudanças na fonte de dados remota, neste caso, o CMS sem cabeça. Portanto, sempre que você publicar um artigo ou alterar uma entrada no CMS, o Sourcebit reconhecerá isso e regenerará todos os arquivos para você localmente.
Eduardo Bouças: Então, o que isso significa para o desenvolvedor que trabalha localmente é que você pode ter sua janela CMS ao lado do seu site Hugo rodando localmente, e então você pode ver as mudanças acontecendo em tempo real. Você muda alguma coisa no CMS, e então você pode ver essa mudança sendo refletida no site local, o que eu acho muito útil. Essas são as duas maneiras de usar o Sourcebit.
Drew: Otimização de conversão era o assunto do dia. Quando falei com o veterano podcaster e consultor, 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, mais uma vez, isso é algo em que muitas organizações são muito ruins, sendo claro sobre como irã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 a quantidade de pessoas que 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 muito bem descobrir que está tendo uma rotatividade muito alta de clientes, se usar padrões sombrios e coisas assim. Mas, realmente, a conversão deve ser apenas uma das métricas que você está medindo.
Paul Boag: Há também coisas como você precisa prestar atenção ao engajamento, o quão engajadas estão as pessoas com seu conteúdo, porque isso faz uma grande diferença no fato de elas eventualmente converterem. Então, você está olhando para coisas como: quanto custam seus vídeos, eles assistem, quanto tempo passam em seu site e o que eles olham enquanto fazem isso? Eles estão se engajando nas redes 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 como é fácil para eles usar o sistema e vários outros critérios diferentes.
Paul Boag: Existem muitos mecanismos que você pode usar para medir essas coisas diferentes. Existem algumas ferramentas excelentes e também algumas boas métricas que você pode adotar. Então, por exemplo, com usabilidade, há algo chamado escala de usabilidade do sistema que pode ser uma métrica muito útil para medir. Mas, da mesma forma, existem ferramentas como maze.design é uma que eu uso com frequência, que medirá quanto tempo leva para alguém fazer uma compra, por exemplo, finalizar o caixa. Então sim. Tendo esse tipo de ampla gama de métricas, você não está apenas se concentrando em quantas vendas fizemos neste trimestre? Você tem que ver o quadro geral.
Drew: Em abril, conversei com Laura Kalbag, do Better Blocker, sobre privacidade online. Falamos 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á Laura.
Laura Kalbag: Tenho um exemplo clássico disso que aconteceu comigo há alguns anos. Então, eu estava no Facebook, minha mãe tinha acabado de morrer e eu estava recebendo anúncios de agentes funerários. Achei muito estranho porque nenhum membro da minha família havia dito nada em uma plataforma de mídia social naquele momento. Nenhum membro da minha família disse nada no Facebook porque concordamos que ninguém quer descobrir esse tipo de coisa sobre um amigo ou parente pelo Facebook. Portanto, não dissemos sobre isso.
Laura Kalbag: Então eu perguntei aos meus irmãos,”Oh, alguém disse alguma coisa no Facebook que pode causar isso estranho.”Porque normalmente só recebo anúncios de maquiagem, vestidos, testes de gravidez e todas aquelas coisas divertidas que eles gostam de conversar. São mulheres de certa idade. Em vez disso, minha irmã voltou para mim. Ela disse:”Bem, sim. Meu amigo mora na Austrália.”Então mandei uma mensagem para ela no Facebook Messenger e disse que nossa mãe havia morrido. Claro, o Facebook sabia que somos irmãs. Ele tem essa conexão de relacionamento que você pode escolher adicionar lá. Quero dizer, provavelmente poderia supor que éramos irmãs de qualquer maneira, pelos locais que estivemos juntos, o fato de compartilharmos um sobrenome e decidir:”Oh, esse é um anúncio apropriado para colocar no pé dela.”
Drew: É preocupante, não é, pensar que a tecnologia está tomando essas decisões por nós, o que realmente afeta as pessoas potencialmente neste exemplo, um momento bastante sensível ou vulnerável?
Laura Kalbag: Sim. Dizemos que é assustador. Muitas vezes as pessoas dizem:”Oh, é quase como se o microfone do meu telefone ou meu laptop estivesse me ouvindo porque eu estava apenas tendo uma conversa sobre este produto específico e de repente ele está aparecendo em meu feed em todos os lugares.”Acho que o que é realmente assustador é o fato de que a maioria deles não tem acesso ao seu microfone. Mas é o fato de seus outros comportamentos, sua pesquisa, o fato de que ele sabe com quem você está falando por causa da proximidade um do outro e de sua localização em seus dispositivos. Ele pode conectar todas essas coisas que talvez não nos conectemos apenas para dizer:”Oh, talvez eles se interessem por este produto porque provavelmente já estavam pensando, falando sobre ele.”
Drew: Quando a pandemia do coronavírus atingiu, e muitas nações entraram em alguma forma de bloqueio, falei com Rachel Andrew sobre como o Smashing estava adaptando sua conferência presencial programada para acontecer online. Tendo acabado de adiar a conferência Smashing, em San Francisco, perguntei a Rachel qual era o plano para mover as próximas conferências e workshops para o domínio virtual.
Rachel AnDrew: Muito, muito rapidamente, uma vez que percebemos que teríamos que adiar São Francisco, obviamente, temos workshops, tanto eu quanto Vitaly realizamos workshops em smash and comp, e eles se esgotaram em San Francisco, ambos os nossos workshops. 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 nós que fazemos workshops, eles realmente parte fundamental de nossa receita.
Rachel AnDrew: Falar em público, você não ganha muito dinheiro normalmente falando em público. A maioria das pessoas não é bem paga, não quando você considera a quantidade de tempo que leva para escrever discursos e assim por diante. Os workshops tendem a ser uma maneira agradável de ganhar algum dinheiro para pessoas que são boas no ensino dessas coisas. Então, eles representam a renda das pessoas. Portanto, não só precisava que eu e Vitaly tivéssemos perdido nossos workshops no início deste ano. Também percebemos que muitos de nossos palestrantes do Smashing também dependiam desses workshops.
Rachel AnDrew: Então pensamos:”Bem, por que não colocá-los online?”Muito, muito rapidamente, realmente dentro de alguns dias após isso acontecer, decidimos que eu e Vitaly seríamos os primeiros a questionar o poder, mas somos nós, e poderíamos meio que descobrir como fazer isso. Também temos workshops muito diferentes. Vitaly é muito mais colaborativo. Ele tem atividades em grupo e coisas assim. Eu ensino o estilo de sala de aula. Então, entre nós, pensamos:”Bem, estamos cobrindo todas as bases.”Então pensamos:”Vamos apenas fazer isso. Vamos ver se funciona.”Então, nós os anunciamos. Nós meio que descobrimos quanto tempo cada um demorava e, em seguida, sentamos e dissemos:”Bem, como é realmente um workshop on-line? O que é isso?”
Drew: Acho que de uma perspectiva técnica, como desenvolvedores da web que pensam imediatamente, como diabos vamos entregar algo assim, quer dizer, deve haver muitas plataformas diferentes que você olhou. Quais foram as diferentes coisas para as quais você olhou e o que Smashing acabou trazendo?
Rachel AnDrew: Então, demos uma olhada em todos os tipos de coisas e ainda estamos no processo de fazer isso. Estamos usando o Zoom no momento. O motivo pelo qual estamos usando o Zoom é a acessibilidade. Foi a mais acessível das plataformas. Obviamente, não queremos cortar pessoas por causa da plataforma que escolhemos. Eu acho que as outras plataformas estão ficando melhores e as pessoas estão… Eu acho que muitas plataformas têm pessoas que vêm até elas e dizem:”Sim, você está ótima. Mas precisamos que você seja acessível.”Portanto, o zoom é o mais fácil para as pessoas usarem no momento.”É por isso que acabamos usando. Não sei se faremos para sempre. Mas é isso que estamos usando no momento e tem funcionado muito bem como uma maneira de fazer isso.
Drew: À medida que a fadiga do zoom se instalou e o mundo começou a se ajustar ao que estava rapidamente sendo chamado de novo normal, conversei com Phil Smith sobre como a tecnologia pode nos ajudar a responder a situações como 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 com as tecnologias com as quais 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 tivesse trabalhado nisso sólido, sólido, sólido, porque os requisitos estavam muito em de acordo com minha experiência de construção de aplicativos. Eu construí coisas semelhantes, onde ele chama uma API, armazena os resultados em estado e os apresenta. Agora estou em uma posição em que há algumas partes em que penso,”Ok, preciso voltar e refatorar isso.”
Phil Smith: Já falei sobre digitar lata, mas na verdade os tipos podem ser bem soltos no aplicativo e isso precisa ser melhorado. No back-end, não há muitos testes e agora estamos começando a implementá-lo porque muitas pessoas se apresentaram e disseram:”Na verdade, este é um ótimo recurso. Gostaria de oferecer meus serviços para traduzir para a minha língua nativa.”As extremidades traseiras estão sendo usadas por mais pessoas, então estou apenas pensando:”Espere, preciso de mais alguns testes aqui para ter certeza de que nada pode quebrar porque há pessoas usando isso na produção agora.”Acho que respondi sua pergunta. Essencialmente, não houve tomada de decisão. Só precisava divulgá-lo o mais rápido possível.
Drew: À medida que os locais de trabalho fechavam e muitos de nós se adaptavam para trabalhar em casa, conversei com Ben Frain sobre a otimização do seu espaço de trabalho em casa para ser confortável e produtivo não vai resultar em problemas de saúde física a longo prazo. Com orçamentos limitados disponíveis para configuração em casa, perguntei a Ben se uma boa cadeira era o melhor lugar para começar.
Ben Frain: Esse seria o 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 não tinha uma inclinação para a frente, seja qual for a palavra certa para essa coisa, no eixo. Então, o que descobri é que ele 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 naquela coisa?”
Ben Frain: Acho que principalmente se você trabalha para uma empresa que fornece cadeiras decentes para escritório, você simplesmente as considera naturais, e não é até que você olhe para essa marca e marca em particular que você dirá,”Oh meu Deus , esta é uma cadeira de $ 700.”Quando você percebe isso, as pessoas têm pensado sobre isso e feito muito por você, e então, obviamente, você chega em 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í para o 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 já 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 provavelmente seria um grande fardo para aqueles com sites de longa duração.
Angie Byron: Acho que existem basicamente três cenários. Então, uma é se você estivesse executando o Drupal 8 e toda vez que uma nova versão menor do Drupal 8 fosse lançada, você o atualizaria imediatamente e começaria a usar o novo material. 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 tem acompanhado as mudanças no BC, há um pouco de trabalho para você.
Angie Byron: De qualquer forma, é definitivamente a atualização mais fácil em mais de uma década do nosso software, e temos uma tonelada de ferramentas diferentes para ajudá-lo com isso. 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ê possui, e existem ferramentas para acessar automaticamente e encontrar:”Oh, esta é a versão mais recente do seu módulo e está pronto para Drupal 9? Você deve ir baixe”, 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 que foram encontrados em outro projeto de software, o que é uma coisa muito inteligente de se fazer arquitetonicamente, mas é significa que se você tinha uma tonelada de código personalizado em sua antiga vida, no Drupal 9, você precisará 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 o Drupal 8 equivalente dados para você, juntamente com todos os módulos de que você vai precisar, que mapeiam para seus módulos Drupal 7 antigos, sempre que possível, para tentar agilizar esse processo um pouco, porque queremos ter certeza de que todos que usam versões mais antigas ainda podem fazê-lo para a nova ordem mundial, onde todos estão na mesma versão e todos trabalhamos 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 em novembro do próximo ano. Atualmente, de qualquer maneira, precisamos discutir se COVID afeta isso ou não. Mas há uma série de empresas diferentes, e a Acquia é uma delas que oferece suporte estendido para o Drupal 7 além disso, até 2024 pelo menos. Isso faz com que as pessoas que têm uma atualização fácil tenham um ano e meio para concluí-la, outras pessoas tenham uma atualização menos fácil, tenham potencialmente três anos e meio para concluí-la ou mais, se necessário, e estamos tentando muito tornar possível que todos mudem de lugar e construam ferramentas como o 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 em uma posição de aprender React pela primeira vez. Refletindo sobre a quantidade de trabalho que frameworks como React colocam no navegador, perguntei a Mina se colocar tanto controle nas mãos do cliente era um erro.
Mina Markham: Eu quero dizer sim com a ressalva de, novamente, minha experiência está muito contida em sites estáticos. Eu não faço muito desenvolvimento de produto. Então, talvez nesse reino, isso faça mais sentido. Mas, da minha perspectiva, sinto que muitas vezes estamos usando uma machadinha quando só precisamos de uma faca de manteiga. Não sei por que precisamos colocar tudo isso no navegador, colocar tanto trabalho e tanta pressão no cliente quando podemos fazer muitas coisas… Eu sinto que poderíamos fazer isso de forma 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 me deixou visceralmente zangado e me opus ativamente foi quando eu ia a um site e, literalmente, nada renderia porque ocorreu um erro ou algo como a página inteira quebrou porque uma função quebrou.
Mina Markham: Eu meio que me irritou que, na maioria das 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 falar sobre como incluir o aprimoramento progressivo e não apenas o seu desenvolvimento, mas também uma maior direção de arte e design de sites. Gostaria de apontar especificamente exemplos de sites que não fizeram aprimoramento progressivo ou qualquer tipo de degradação elegante. Ou você tem o JavaScript em execução no navegador ou não obtém absolutamente nada. Seria apenas um simples site 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 linhas do tempo, animação das coisas. Mas também poderia ter sido processado estaticamente com apenas uma lista. Houve etapas entre não mostrar nada e mostrar aquela experiência lindamente aprimorada que acho que se perdeu devido à forma como estamos abordando o desenvolvimento da web moderno agora.
Drew: Falei com Andy Bell sobre CUBE CSS, uma metodologia de estilo na forma de BEM, SMACSS e OOCSS. Muitas abordagens CSS tentam trabalhar contra as propriedades naturais do CSS, como a cascata. O CUBE adota muito esse comportamento. Aqui está Andy.
Andy Bell: Uma boa analogia para isso é o SCSS, assim como o Sass, é uma extensão da linguagem CSS natural, não é? Você ainda está muito certo no CSS. Então CUBE CSS é assim. Portanto, é uma extensão do CSS. Portanto, ainda devemos escrever CSS, como CSS deve… bem, é para ser escrito. Vamos ser honestos, é assim que deve ser escrito. O nome mostra isso, Cascading Style Sheets. Então, estou abraçando isso novamente porque o que eu descobri é que desci até o nível de micro-otimização. Eu estive no caminho que vi muitas pessoas indo recentemente onde… Eu mencionei isso no artigo também, onde posso ver… Há algumas evidências disso recentemente. Eu percebi que pessoas criaram componentes espaçadores e coisas assim, e eu entendo esse problema. Já estive nessa situação.
Andy Bell: O jeito que eu consertei foi, em vez de aprofundar e tentar micro-otimizar, na verdade comecei a pensar sobre as coisas em um nível de composição porque não importa o quão pequenos seus componentes sejam. Em algum momento, eles serão páginas. Eles 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 isso é uma composição de layout esquelética. dentro dele, posso encaixar todos os componentes que quiser.”
Andy Bell: Agora temos coisas como Grid e Flexbox que tornam isso muito mais viável, e você pode basicamente 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 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 site estáticos são agnósticos de código de front-end, Gatsby usa React e, portanto, você acaba com o código de Gatsby rodando como parte de sua experiência final na web. Perguntei a Marcy o que era esse código e que 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 o recauchutador sob o capô. É apenas uma espécie de implementação própria. 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 deverá 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 irá pré-buscar recursos dessa página. Portanto, ele carregará mais rápido. Então, tudo está habilitado com esta camada JavaScript que Gatsby oferece.
Marcy Sutton: So beyond that, it really depends kind of what you’re using in your site, what will end up in that JavaScript bundle. But for things that use a lot of interactivity, like accessible interfaces, that’s a good place to be. For me, I really enjoy having JavaScript available to me at all times and having my markup just be in a good spot. I know it’s a matter of preference, whether you want your HTML and your JavaScript and your CSS, all kind of neatly coupled, and there’s room for variations within building Gatsby. You don’t always have to use something like CSS and JS. But it’s really about getting the power of that dynamic JavaScript layer available to you while you’re writing your website. It’s not like this add-on in a separate file.
Drew: When I think of how a static site generator usually works, I’m thinking of content in perhaps markdown files and the generator runs across that content and merges it with templates and creates tens, hundreds, thousands of HTML files, which are the pages of your website. When I think of a React site or app, I’m thinking more about single-page experience, where the interfaces be created by React on the fly. So you’re saying Gatsby does both of those? It’s creating all the pages and also enhancing it with JavaScript?
Marcy Sutton: It is, yes. Gatsby will use Node.js at build time, it will go over your React components and compile them into HTML files, which honestly, the first time I looked at Gatsby, I wouldn’t turn JavaScript off and was like,”All right, are there other pages here? What is this?”I was so happy that Gatsby works that way by default. It will create built files from your React components, which is awesome.
Marcy Sutton: I have explored more progressive enhancement approaches since it’s in JavaScript, like, what if you want to output something progressively enhanced for users, where if they do have JavaScript turned off, you don’t want all this broken code that assumes JavaScript is there. So there are some quirks with it. But you can work around that kind of thing, at least for your core user flows where you want someone to still be able to buy something. You might need to add some support and for those use cases. But I’ve been pleasantly surprised that the way that Gatsby rolls that out by default.
Marcy Sutton: So it is a choice that they made to build sites that way, and we’re always evaluating, is it still the best way? What do we need to do to give our users what they’re asking for? So we’re doing some explorations internally, ongoing just to make sure Gatsby is doing the best job it can at building a website, so keeping bundle sizes small and making sure that for making trade-offs for what we say is performant code with pre-fetching, do we have the data to back that up? That’s the kind of thing as a developer advocate that I’m super interested in, is making sure that what we’re packaging and bundling on websites is actually needed and will really make the best Gatsby site it can make.
Drew: Talking with Chris Ferdinandi in July, I asked if modern best practices were bad for the web. Chris backs a movement known as the Lean Web, and I asked him what that entailed. Here’s Chris.
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. I’ve come to believe that a lot of what we think of as best practices today might actually be making the web worse. 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. But really, the Lean Web is about focusing on simplicity and performance for the user and really prioritizing or putting the focus on the people who use the things we make rather than us, the people who are making it.
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? But you can pick pre-processor languages as well. Let’s say you like Sass. You turn Sass on in the CSS, and you write Sass. Well, something has to process the Sass. These days, Sass is written in Dart or something. Theoretically, you could do that in the client. But these libraries that do pre-processing are pretty big. I don’t think I want to ship the entire Sass library to you, just to run that thing. 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. But here’s how it does work now, is there’s a lambda. It processes Sass. It has one tiny, tiny, tiny, little job. 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. You don’t have to worry about scale. 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. But there’s one for Sass. There’s one for Less. There’s one for Babbel. There’s one for TypeScript. There’s one for… All those are individual lambdas that we run. Here’s some code, give it to the lambda. It comes back, and we do whatever we’re going to do with it. But we use it for a lot more than that, even recently.
Chris Coyier: Here’s an example. Every single Pen on CodePen has a screenshot. That’s kind of cool, right? 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. If you share it in Slack, you get the little preview of it. 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? It’s not animated anyway. Just performance gains like that.
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. It’s a worker. 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. Serve it as these dimensions.”I don’t have to make the image in those dimensions. 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. Those become entry points to your application that you can share through all kinds of media.
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 also, which is very, very nice, automatically pre-fetches the rest of the pages that are connected to that entry point, such that it feels like a single-page application. 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. So first of all, there was a motivation to change the reactivity. 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. But okay. We will teach you anyway.
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. It was 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: So this was again a huge part. The last one was we kind of missed the functionality to abstract logic, in terms of not components, but compossible logic parts, like functions helpers and so on, but they should be able to include Vue activity as well. A nice example here could be React Hooks, right? They allow you abstract the parts of the functionality, and this was clearly missing in Vue. I know that right now it sounds like,”You stole the feature from React.”Not in fact. I believe that ideas cross-pollination is a big and nice part in our ecosystem, and also it helps developers to switch between favorites, right? So we were working on these main features to create the Vue 3 as major version.
Drew: Following that we dived into TypeScript with Stefan Baumgartner to find out how it can help us write better code with fewer bugs. Observing the trend for organizations to move their code basis entirely to JavaScript, I asked Stefan if TypeScript was something larger teams would benefit from more than individuals.
Stefan Baumgartner: So I’m currently in the same transition. So we have lots of Java and C++ developers who are going to write a lot of JavaScript in the future. TypeScript can be some sort of guide for those scary areas of new programing language. JavaScript has a lot of quirks, a lot of history, and a lot of prejudices if you come from a different programing language. So TypeScript can be a guide because there’s some concepts that you’re familiar with it in the type system.
Stefan Baumgartner: But also, I think, especially when you have lots of people working in the same code base or lots of people who need to work with each other, this can be an additional layer of guidance in your project, where you don’t have any bad surprises in the end. So of course, technology doesn’t solve any communication problems. This is not what TypeScript is intended for. But it can lower, or it can make lot more room for the right discussion then if you don’t have to talk about, what do you expect from me in your code, but rather, what should your code do, or what should your library do?
Stefan Baumgartner: I always say that if you ever write code for other people or if you write code with lots of people or if you just write code for yourself, you have to revisit the next day, consider TypeScript because it might help you in the long run. This is not just an investment for the next project of next week, but more for one who say, okay, especially if you have long lasting projects for month, two, or years, definitely offer that. You’re never going to know what you’ve been thinking of when you wrote the little piece of code one year ago, but types can give you a hint of what you meant.
Drew: In November, I chatted with David Darnes about the static site generator, Eleventy. We talked about templating and how many static site generators are quite heavily opinionated about what type of templating you should use. I wondered if Eleventy held the same sort of strong beliefs. Here’s Dave.
David Darnes: No, I have to say it’s as close as unopinionated as you could get. A bit of a personal view, but I struggled to see any framework or anything that can be unopinionated because, in order to create something, you have to have an opinion on how you want to do something. It’s kind of oxymoron. I’m sure people could correct me on that. But yeah. You can switch to whatever templating language you feel most comfortable with. I mean, we were just talking about languages that you are comfortable with. Eleventy appeals to that in a sort of sense with what templating languages use inside your HTML, or heck even your CSS, if you want.
David Darnes: For me, I just went straight to the nunjucks because nunjucks is the default templating language inside of Eleventy. That means I can use the dot HTML extension and kind of leave it as it is. Now, I’m just going to confuse people even more and say,”You can name that however you want anyway. You can have real fun with it.”But you can use handlebars. I think you can just use regular JavaScript templating and iterate through it like that. Handlebars quite popular and Liquid as well. I can’t think of all of them off the top of my head, but if you set it all up in the configuration, you can just pick however you want it.
David Darnes: I’d say I’m a real big fan of just templating languages in general. It wasn’t too long ago when I found out that you could use twig inside of WordPress, and that kind of blew my mind. I was like,”Oh, thank goodness. I don’t have to handle a for loop inside of PHP.”Again, I think something a little bit more comfortable and understandable, more readable as well. So yeah. Eleventy has lots of different templating options, and it should appeal to people who are comfortable with those different ones.
Drew: I spoke with Leslie Cohn-Wein about how Netlify uses its own platform to build Netlify and how their Deploy Preview functionality becomes an effective staging platform for front-end changes.
Leslie Cohn-Wein: Maybe my favorite part of that whole process is the magic of Deploy Previews, which we get through Netlify. So what happens is you’re working in GitHub, you push up your PR. So you open up your PR in GitHub, and that is going to automatically create a build of your Deploy Preview of the app. So we actually use Deploy Previews of the app itself to test out, to make sure everything is working the way it should. We run our tests. That’s what we use sort of to manually verify during code review. So we have sort of all of that continuous deployment set up right from GitHub.
Leslie Cohn-Wein: Then one of the other cool things that we have set up is that we actually have a couple of different Netlify sites that are pulling from the same repository where our app lives. So we have both our app. We’ve got an instance of Storybook that has sort of our UI components for the app. So we have both our app itself. We’ve got the Storybook UI components, and we have basically a Netlify site that shows our Storybook UI, and then we also have a third site that runs a webpack bundle analyzer. So it’s sort of a visual UI that gives you a tree map visualization of all of the apps bundles, and we can sort of gauge their size, and it’s just a reminder for us to double-check sort of as every deploy of the app goes out, we can check and make sure we’re not doing anything weird with our bundle size there.
Leslie Cohn-Wein: So all three of those sites get generated in one pull request of the app. So you’ll get links to preview, your Deploy Previews essentially, of both the app Storybook and to that app profile for us to check through.
Drew: In December, I talked with Chris Murphy about product design and what it means for business to be designed focused. We discussed if an individual founders design focus, does that leak into the business, and if a product is naturally an extension of the person who created it.
Chris Murphy: I think that’s a really good question, Drew, and I think that the answer to it is it depends. I think it depends on that person, and it depends on the scale of the company. If you take a look at Hiut Denim, and I use Hiut a lot in my teaching, it’s a really good example of a company that’s doing one thing well, and that’s their sort of strapline jeans. I think if you look at David’s previous… David and Clare, because they’re a partnership. If you look at David Hieatt and Clare Hieatt’s previous company, which was Howies, that company had grown so big, there were so many people involved.
Chris Murphy: Once scale starts to creep in, it starts to become very difficult to keep an eye on all of the little touchpoints that matter in the customer journey. I think it’s really telling that when they left Howies, because Howies had been bought by… It’s complicated. Go read it on the internet. But it was Timberland, and Timberland was bought, and there’s all this story.
Chris Murphy: I think it’s really interesting that what they’re focused on now is jeans. É isso aí. They’re telling an amazingly good story around jeans. They’re also packaging everything really, really well, and the jeans are like a vehicle for stories, really. This is something I think, Drew, is going to become more important as we come out the other end of COVID, which I hope we come out the other end of. Everyone who’s making those jeans is being paid a proper wage. One of the problems I have at the minute when I look at the world is not everybody is being paid a proper wage, and I find that a little bit concerning, as someone… Look, I’m 51. My son is 25, 24, 25, something like that. It’s terrible. I should know all this stuff. He’s a wedding photographer. He has been a wedding photographer for like a year and a bit. His business is completely decimated because no one’s really getting married at the minute because it’s just difficult. He has no salary because he didn’t have enough self-employed books to get the support.
Chris Murphy: He’s fallen through the cracks, and there’s a lot of other people who’ve fallen through the cracks. I would argue that’s a design problem, that we need to look at that as a design problem. But if I also look at that wider issue of COVID and the government and all of these things without getting too political, I read an article in the Guardian yesterday about Matt Hancock’s neighbor, and anyone who’s listening who’s not from the UK, Matt Hancock is the Health Secretary. His neighbor, who was running a business, was texting him and asking for advice about,”How do I supply products for this COVID thing?”There’s an awful lot of rumblings around the chumocracy, is what the papers call it, friends of friends of government ministers who seem to be getting jobs because they know the right people.
Chris Murphy: I get this sense that we’re going to come to the other end of this and see this… Individuals see that, and they think,”Well, where is this money going, and are people being paid properly? What’s the price of this one-pound T-shirt from shop X?”I don’t want to mention any brands. But everything has to be paid for, and everything that’s made, people have to be paid to make it. I think people are increasingly interested in, are people being paid fairly?
Drew: GraphQL was the topic of our final, full episode of the year, and I had a chat with Eve Porcello and asked where GraphQL fits into the development stack.
Eve Porcello: Yeah. GraphQL kind of fits between the front end and the backend. So it’s kind of living in the middle between the two and gives a lot of benefits to front-end developers and backend developers. If you’re a front-end developer, you can define all of your front end’s data requirements. So if you have a big list of React components, for example, you could write a query, and that’s going to define all of the fields that you would need to populate the data for that page.
Eve Porcello: Now, with the backend piece, it’s really own, because we can collect a lot of data from a lot of different sources. So we have data in REST APIs and databases and all these different places, and GraphQL provides us this nice little orchestration layer to really make sense of the chaos of where all of our data is. So it’s a really useful for kind of everybody all over the stack.
