Há cerca de 15 anos, eu trabalhava em uma empresa onde desenvolvíamos aplicativos para agentes de viagens, funcionários de aeroportos e companhias aéreas. Também construímos nossa própria estrutura interna para componentes de UI e recursos de aplicativos de página única. Tínhamos componentes para tudo: campos, botões, guias, intervalos, tabelas de dados, menus, selecionadores de data, seleções e seleções múltiplas. Tínhamos até um componente div. A propósito, nosso componente div era ótimo, nos permitia fazer cantos arredondados em todos os navegadores, o que, acredite ou não, não era uma coisa fácil de fazer na época.
Nosso trabalho ocorreu em um momento de nossa história em que JS, Ajax e HTML dinâmico eram vistos como uma revolução que nos trouxe para o futuro. De repente, podíamos atualizar uma página dinamicamente, obter dados de um servidor e evitar ter que navegar para outras páginas, o que era visto como lento e exibia um grande retângulo branco na tela entre as duas páginas. Havia uma frase, popularizada por Jeff Atwood (o fundador do StackOverflow), que dizia: “Qualquer aplicativo que possa ser escrito em JavaScript acabará sendo escrito em JavaScript.” - Jeff Atwood
Para nós, na época, parecia um desafio realmente criar esses aplicativos. Parecia uma aprovação geral fazer tudo com JS. Então, fizemos tudo com JS e não perdemos tempo pesquisando outras maneiras de fazer as coisas. Não sentimos realmente o incentivo para aprender adequadamente o que HTML e CSS poderiam fazer. Na verdade, não percebíamos a web como uma plataforma de aplicativos em evolução em sua totalidade. Víamos isso principalmente como algo que precisávamos contornar, especialmente quando se tratava de suporte ao navegador. Poderíamos simplesmente adicionar mais JS para fazer as coisas. Reservar um tempo para aprender mais sobre como a web funciona e o que está disponível na plataforma me ajudou? Claro, eu provavelmente poderia ter raspado um monte de código que não era realmente necessário. Mas, na época, talvez não tanto. Veja, as diferenças entre os navegadores eram bastante significativas naquela época. Esta foi uma época em que o Internet Explorer ainda era o navegador dominante, com o Firefox em segundo lugar, mas começando a perder participação de mercado devido ao rápido ganho de popularidade do Chrome. Embora o Chrome e o Firefox fossem muito bons em concordar com os padrões da web, os ambientes em que nossos aplicativos eram executados significavam que precisávamos oferecer suporte ao IE6 por um longo tempo. Mesmo quando tivemos permissão para oferecer suporte ao IE8, ainda tivemos que lidar com muitas diferenças entre os navegadores. Não só isso, mas a web da época simplesmente não tinha tantos recursos integrados à plataforma.
Avanço rápido para hoje. As coisas mudaram tremendamente. Não só temos mais destas capacidades do que nunca, mas a taxa a que se tornam disponíveis também aumentou. Deixe-me fazer a pergunta novamente: dedicar um tempo para aprender mais sobre como a web funciona e o que está disponível na plataforma ajudaria você hoje? Absolutamente sim. Aprender a compreender e usar a plataforma web hoje coloca você em uma enorme vantagem sobre outros desenvolvedores. Quer você trabalhe em desempenho, acessibilidade, capacidade de resposta, todos eles juntos, ou apenas enviando recursos de UI, se quiser fazer isso como um engenheiro responsável, conhecer as ferramentas que estão disponíveis o ajudará a atingir seus objetivos de maneira mais rápida e melhor. Algumas coisas para as quais talvez você não precise mais de uma biblioteca Sabendo o que os navegadores suportam hoje, a questão é: o que podemos abandonar? Precisamos de um componente div para fazer cantos arredondados em 2025? Claro, nós não. A propriedade border-radius é suportada por todos os navegadores usados atualmente há mais de 15 anos. E o formato de canto também chegará em breve, para cantos ainda mais sofisticados. Vamos dar uma olhada nos recursos relativamente recentes que agora estão disponíveis em todos os principais navegadores e que você pode usar para substituir dependências existentes em sua base de código. A questão não é abandonar imediatamente todas as suas bibliotecas amadas e reescrever sua base de código. Quanto a todo o resto, você precisará primeiro levar em consideração o suporte do navegador e decidir com base em outros fatores específicos do seu projeto. Os recursos a seguir são implementados nos três principais mecanismos de navegador (Chromium, WebKit e Gecko), mas você pode ter requisitos de suporte de navegador diferentes que o impedem de usá-los imediatamente. Agora ainda é um bom momento para aprender sobre esses recursos e talvez planejar usá-los em algum momento. Popovers e diálogos A API Popover, o elemento HTML
Claro, a velocidade da sua conexão com a Internet provavelmente também aumentou, mas esse não é o caso para todos. E nem todos têm os mesmos recursos de dispositivo. Em vez disso, extrair código de terceiros para coisas que você pode fazer com a plataforma provavelmente significa enviar mais código e, portanto, alcançar menos clientes do que normalmente faria. Na web, o mau desempenho de carregamento leva a grandes taxas de abandono e prejudica a reputação da marca. Executando menos código em dispositivos Além disso, o código que você envia nos dispositivos de seus clientes provavelmente será executado mais rapidamente se usar menos abstrações de JavaScript na plataforma. Provavelmente também é mais responsivo e acessível por padrão. Tudo isso leva a clientes mais e mais felizes. Verifique o blog anual sobre lacunas de desigualdade de desempenho do meu colega Alex Russell, que mostra que os dispositivos premium estão em grande parte ausentes dos mercados com milhares de milhões de utilizadores devido à desigualdade de riqueza. E essa lacuna só aumenta com o tempo.
Layout de alvenaria embutida Um recurso da plataforma web que será lançado em breve e que me deixa muito entusiasmado é o CSS Masonry.
Deixe-me começar explicando o que é a Maçonaria. O que é alvenaria Alvenaria é um tipo de layout que se tornou popular pelo Pinterest anos atrás. Ele cria trilhas independentes de conteúdo nas quais os itens são agrupados o mais próximo possível do início da trilha.
Muitas pessoas veem a Maçonaria como uma ótima opção para portfólios e galerias de fotos, o que certamente pode ser feito. Mas a Maçonaria é mais flexível do que você vê no Pinterest e não se limita apenas a layouts em cascata. Em um layout de alvenaria:
As trilhas podem ser colunas ou linhas:
As faixas de conteúdo não precisam ter todas o mesmo tamanho:
Os itens podem abranger várias faixas:
Os itens podem ser colocados em trilhas específicas; eles nem sempre precisam seguir o algoritmo de posicionamento automático:
Demonstrações Aqui estão algumas demonstrações simples que fiz usando a próxima implementação do CSS Masonry no Chromium. Uma demonstração da galeria de fotos, mostrando como os itens (o título, neste caso) podem abranger várias faixas:
Outra galeria de fotos mostrando faixas de diferentes tamanhos:
Um layout de site de notícias com algumas faixas mais largas que outras e alguns itens abrangendo toda a largura do layout:
Um quadro Kanban mostrando que os itens podem ser colocados em trilhas específicas:
Nota: Odemonstrações anteriores foram feitas com uma versão do Chromium que ainda não está disponível para a maioria dos usuários da web, porque CSS Masonry está apenas começando a ser implementado em navegadores. No entanto, os desenvolvedores web já usam bibliotecas para criar layouts de alvenaria há anos. Sites que usam alvenaria hoje Na verdade, a Maçonaria é bastante comum na web hoje. Aqui estão alguns exemplos que encontrei além do Pinterest:
E mais alguns exemplos menos óbvios:
Então, como esses layouts foram criados? Soluções alternativas Um truque que vi ser usado é usar um layout Flexbox, mudando sua direção para coluna e configurando-o para quebrar. Desta forma, você pode colocar itens de diferentes alturas em múltiplas colunas independentes, dando a impressão de um layout de alvenaria:
Existem, no entanto, duas limitações com esta solução alternativa:
A ordem dos itens é diferente daquela que seria com um layout real de alvenaria. Com o Flexbox, os itens preenchem primeiro a primeira coluna e, quando ela estiver cheia, vão para a próxima coluna. Com a Maçonaria, os itens seriam empilhados em qualquer trilha (ou coluna, neste caso) que tivesse mais espaço disponível. Mas também, e talvez mais importante, esta solução alternativa requer que você defina uma altura fixa para o contêiner Flexbox; caso contrário, nenhum empacotamento ocorreria.
Bibliotecas de alvenaria de terceiros Para casos mais avançados, os desenvolvedores têm utilizado bibliotecas. A biblioteca mais conhecida e popular para isso é chamada simplesmente de Masonry e é baixada cerca de 200.000 vezes por semana, de acordo com o NPM. O Squarespace também fornece um componente de layout que renderiza um layout de alvenaria, para uma alternativa sem código, e muitos sites o utilizam. Ambas as opções usam código JavaScript para colocar itens no layout. Alvenaria Embutida Estou muito animado porque o Masonry está começando a aparecer nos navegadores como um recurso CSS integrado. Com o tempo, você poderá usar o Masonry da mesma forma que usa o Grid ou o Flexbox, ou seja, sem precisar de nenhuma solução alternativa ou código de terceiros. Minha equipe na Microsoft tem implementado suporte integrado ao Masonry no projeto de código aberto Chromium, no qual o Edge, o Chrome e muitos outros navegadores são baseados. A Mozilla foi na verdade o primeiro fornecedor de navegador a propor uma implementação experimental do Masonry em 2020. E a Apple também está muito interessada em fazer esse novo layout primitivo da web acontecer. O trabalho para padronizar o recurso também está avançando, com acordo dentro do grupo de trabalho CSS sobre a direção geral e até mesmo um novo tipo de display: grid-lanes. Se você quiser aprender mais sobre Maçonaria e acompanhar o progresso, confira minha página de recursos CSS Masonry. Com o tempo, quando o Masonry se tornar um recurso de base, assim como o Grid ou o Flexbox, poderemos simplesmente usá-lo e nos beneficiar de:
Melhor desempenho, Melhor capacidade de resposta, Facilidade de uso e código mais simples.
Vamos dar uma olhada nisso. Melhor desempenho Criar seu próprio sistema de layout semelhante ao Masonry ou usar uma biblioteca de terceiros significa que você terá que executar o código JavaScript para colocar os itens na tela. Isso também significa que esse código bloqueará a renderização. Na verdade, ou nada aparecerá, ou as coisas não estarão nos lugares certos ou nos tamanhos certos, até que o código JavaScript seja executado. O layout de alvenaria é frequentemente usado para a parte principal de uma página da web, o que significa que o código faria com que seu conteúdo principal aparecesse mais tarde do que poderia, degradando seu LCP, ou métrica de pintura de maior conteúdo, que desempenha um grande papel no desempenho percebido e na otimização do mecanismo de pesquisa. Testei a biblioteca Masonry JS com um layout simples e simulando uma conexão 4G lenta no DevTools. A biblioteca não é muito grande (24 KB, 7,8 KB compactada com gzip), mas demorou 600 ms para carregar nas minhas condições de teste. Aqui está uma gravação de desempenho mostrando o longo tempo de carregamento de 600 ms para a biblioteca Masonry e que nenhuma outra atividade de renderização aconteceu enquanto isso acontecia:
Além disso, após o tempo de carregamento inicial, o script baixado precisava ser analisado, compilado e executado. Tudo isso, como mencionado anteriormente, bloqueava a renderização da página. Com uma implementação de Masonry integrada no navegador, não teremos um script para carregar e executar. O mecanismo do navegador fará seu trabalho durante a etapa inicial de renderização da página. Melhor capacidade de resposta Semelhante a quando uma página é carregada pela primeira vez, o redimensionamento da janela do navegador leva à renderização do layout dessa página novamente. Neste ponto, porém, se a página estiver usando a biblioteca Masonry JS, não há necessidade de carregar o script novamente, porque ele já estáaqui. No entanto, o código que move os itens nos lugares certos precisa ser executado. Agora, esta biblioteca em particular parece ser muito rápida em fazer isso quando a página carrega. No entanto, ele anima os itens quando eles precisam ser movidos para um local diferente no redimensionamento da janela, e isso faz uma grande diferença. É claro que os usuários não perdem tempo redimensionando as janelas do navegador tanto quanto nós, desenvolvedores. Mas essa experiência de redimensionamento animado pode ser bastante chocante e aumenta o tempo percebido que a página leva para se adaptar ao novo tamanho. Facilidade de uso e código mais simples A facilidade de usar um recurso da web e a simplicidade do código são fatores importantes que podem fazer uma grande diferença para sua equipe. Eles nunca poderão ser tão importantes quanto a experiência final do usuário, é claro, mas a experiência do desenvolvedor impacta a capacidade de manutenção. O uso de um recurso da web integrado traz benefícios importantes nesse aspecto:
Os desenvolvedores que já conhecem HTML, CSS e JS provavelmente conseguirão usar esse recurso facilmente porque ele foi projetado para se integrar bem e ser consistente com o resto da plataforma web. Não há risco de alterações significativas serem introduzidas na forma como o recurso é usado. O risco quase zero de esse recurso se tornar obsoleto ou sem manutenção.
No caso do Masonry embutido, por ser um layout primitivo, você usa ele a partir de CSS, assim como Grid ou Flexbox, sem JS envolvido. Além disso, outras propriedades CSS relacionadas ao layout, como gap, funcionam como você espera. Não há truques ou soluções alternativas para conhecer, e as coisas que você aprende estão documentadas no MDN. Para a lib Masonry JS, a inicialização é um pouco complexa: requer um atributo de dados com uma sintaxe específica, junto com elementos HTML ocultos para definir os tamanhos das colunas e dos espaços. Além disso, se quiser abranger colunas, você mesmo precisará incluir o tamanho do intervalo para evitar problemas:
Vamos comparar isso com a aparência de uma implementação de alvenaria integrada:
Código mais simples e compacto que pode usar apenas coisas como gap e onde a extensão das trilhas é feita com span 2, assim como na grade, e não exige que você calcule a largura correta que inclui o tamanho do gap. Como saber o que está disponível e quando está disponível? No geral, a questão não é se você deve usar o Masonry integrado em vez de uma biblioteca JS, mas sim quando. A biblioteca Masonry JS é incrível e vem preenchendo uma lacuna na plataforma web há muitos anos e para muitos desenvolvedores e usuários satisfeitos. É claro que tem algumas desvantagens se você compará-lo com uma implementação integrada de alvenaria, mas elas não serão importantes se a implementação não estiver pronta. É fácil para mim listar esses novos recursos interessantes da plataforma da web porque trabalho em um fornecedor de navegadores e, portanto, tenho tendência a saber o que está por vir. Mas os desenvolvedores costumam compartilhar, pesquisa após pesquisa, que é difícil acompanhar novidades. Manter-se informado é difícil e as empresas nem sempre priorizam o aprendizado. Para ajudar com isso, aqui estão alguns recursos que fornecem atualizações de maneira simples e compacta para que você possa obter as informações necessárias rapidamente:
A plataforma Web apresenta site explorador: Você pode estar interessado em sua página de notas de lançamento. E, se você gosta de RSS, confira o feed de notas de lançamento, bem como os feeds de linha de base recentemente disponíveis e amplamente disponíveis.
A WebPainel de status da plataforma: Você pode gostar das várias páginas do ano de referência.
Página de roteiro do status da plataforma Chrome.
Se você tiver um pouco mais de tempo, também poderá estar interessado nas notas de versão dos fornecedores de navegadores:
cromo Borda Raposa de fogo Safári
Para obter ainda mais recursos, confira meu Cheatsheet Navegando na Plataforma Web. Minha coisa ainda não foi implementada Esse é o outro lado do problema. Mesmo que você encontre tempo, energia e maneiras de acompanhar, ainda há frustração em fazer com que sua voz seja ouvida e seus recursos favoritos sejam implementados. Talvez você esteja esperando há anos que um bug específico seja resolvido ou que um recurso específico seja lançado em um navegador onde ainda está faltando. O que direi é que os fornecedores de navegadores ouvem. Faço parte de várias equipes interorganizacionais onde discutimos sinais e feedback dos desenvolvedores o tempo todo. Analisamos muitas fontes diferentes de feedback, tanto internas em cada fornecedor de navegador quanto externas/públicas em fóruns, projetos de código aberto, blogs e pesquisas. E estamos sempre tentando criar maneiras melhores para os desenvolvedores compartilharem suas necessidades e casos de uso específicos. Portanto, se puder, exija mais dos fornecedores de navegadores e pressione-nos para implementar os recursos de que você precisa. Entendo que leva tempo e também pode ser intimidante (sem falar que representa uma grande barreira de entrada), mas também funciona. Aqui estão algumas maneiras de fazer com que sua voz (ou a de sua empresa) seja ouvida: Participe das pesquisas anuais State of JS, State of CSS e State of HTML. Eles desempenham um papel importante na forma como os fornecedores de navegadores priorizam seu trabalho. Se você precisar que uma API específica baseada em padrão seja implementada de forma consistente em todos os navegadores, considere enviar uma proposta na próxima iteração do projeto Interop. Requer mais tempo, mas considere como Shopify e RUMvision compartilharam suas listas de desejos para o Interop 2026. Informações detalhadas como essa podem ser muito úteis para os fornecedores de navegadores priorizarem. Para links mais úteis para influenciar os fornecedores de navegadores, confira meu Cheatsheet Navegando na Plataforma Web. Conclusão Para encerrar, espero que este artigo tenha deixado você com algumas coisas em que pensar:
Emoção pela Maçonaria e outros recursos da web futuros. Alguns recursos da web que você pode querer começar a usar. Alguns trechos de código personalizado ou de terceiros que você pode remover em favor de recursos integrados. Algumas maneiras de acompanhar o que está por vir e influenciar os fornecedores de navegadores.
Mais importante ainda, espero ter convencido você dos benefícios de usar a plataforma web em todo o seu potencial.
