Desenvolvedores ainda relutam em usar primitivas nativas das plataformas

A tese do "use the platform" e seu ceticismo

Nolan Lawson, desenvolvedor e autor do blog Read the Tea Leaves, parte de uma posição que ele mesmo defendeu por anos: a de que desenvolvedores web deveriam usar as APIs nativas do navegador em vez de recriá-las em JavaScript, já que soluções próprias tendem a ter pior performance e pior usabilidade. O texto, porém, faz o exercício inverso: entender por que tantos desenvolvedores resistem a esse mantra.

Razões históricas e de ecossistema

A primeira explicação é histórica: por muito tempo, os navegadores corriam atrás do ecossistema. Bibliotecas como jQuery preenchiam lacunas enquanto APIs equivalentes eram implementadas - e era preciso esperar que navegadores defasados como o IE6 saíssem de cena. Até por volta dos anos 2020, a web era "irregular", e reimplementar era uma escolha sensível. Hoje a maioria dos navegadores é evergreen (Safari é discutível, mas Lawson nota que ~7 atualizações por ano não são ruins).

Há também a questão da familiaridade: quem está acostumado a buscar componentes React no npm tende a recorrer a eles independentemente do problema. Ele cita o exemplo de que não existe pacote no npm que diga "apenas use CSS position: sticky". Além disso, bibliotecas preenchiam uma lacuna real entre a ergonomia dos frameworks e a plataforma: muitos desenvolvedores React achavam as APIs de DOM cruas desagradáveis, mas aceitavam bibliotecas de mais baixo nível que as usavam por baixo dos panos. Isso criou uma divisão do trabalho em que quem tinha mais expertise empacotava APIs da plataforma em formatos mais familiares.

A documentação também pesou: pacotes do npm costumam ter READMEs detalhados, tutoriais e exemplos, enquanto a documentação da web ficava espalhada por blogs, StackOverflow e sites como CSS Tricks - que muitas vezes recomendavam bibliotecas como jQuery ou GreenSock. Lawson compara o site do Dragula com a página de Drag and Drop do MDN e argumenta que o primeiro ainda é mais convincente.

O prazer de construir

Além de preguiça ou ignorância, existe uma motivação mais profunda: para certo tipo de desenvolvedor, construir do zero é mais divertido, e o código resultante pode ser mais fácil de raciocinar. Lawson descreve o exemplo de um modal dialog feito à mão - position:absolute, z-index, bloqueio de scroll, focus trap, retorno de foco, tecla Esc - que para alguns parece pesadelo, mas para outros é aprendizado e diversão, podendo virar uma biblioteca no npm. Ele chama isso de "efeito IKEA": depois de construir, o autor quer manter e ajustar o próprio código.

Lawson se inclui nesse grupo: ele passou anos trabalhando em ferramentas para IndexedDB, WebSQL e outras APIs de armazenamento no PouchDB, o que o levou a participar de reuniões da W3C e a abrir issues e pull requests na própria especificação do IndexedDB. Sem a lacuna da plataforma a preencher, ele duvida que teria alcançado esse nível de expertise.

Limites e o paralelo fora da web

Nem tudo é virtude: às vezes reinventar vem de pura ignorância, como a proliferação de soluções em JavaScript para problemas que o CSS resolvia melhor - ainda que o CSS fosse historicamente difícil (clearfix, floats, o truque min-width: 0) e não tivesse por anos formas diretas de expressar padrões como line clamping ou esconder scrollbar.

O fenômeno não se limita à web. Lawson conta que na sua empresa, ao armazenar JSON grande no ClickHouse, ele e um colega criaram soluções próprias (compressão manual e um armazenamento chave-valor separado) - e ambos estavam errados. O ClickHouse comprime dados automaticamente e, como armazenamento colunar, obtém melhor compressão se o trabalho ficar com ele. Só descobriu isso após ler a documentação a fundo e escrever um benchmark. Ele vê o mesmo padrão em iOS, Android e game engines, exemplificado pelo estereótipo do engenheiro sênior que substitui um código confuso por uma única linha.

IA: leitura dupla

Sem querer falar de IA, Lawson não resiste. Visão otimista: LLMs conhecem enciclopedicamente as APIs e, após testes rigorosos, prefeririam a solução nativa, mais rápida e correta; além disso, o efeito IKEA desaparece quando o desenvolvedor não escreve o código. Visão pessimista: LLMs tendem a duplicar código (ignorando funções auxiliares existentes), o que faria explodir o código não idiomático, e os agentes podem iterar indefinidamente sobre soluções superengenheiradas que nunca deveriam existir. Nos seus próprios usos de código com IA, ele viu os dois fenômenos, e espera que modelos e harnesses melhores puxem para o cenário otimista - sem certeza.

Conclusão

Lawson conclui em tom dividido: ama o mantra "use the platform" ao ver código spaghetti superengenheirado, mas já foi o autor desse código e conhece a alegria de construí-lo. Por isso, entende que o mantra seguirá sendo repetido "enquanto existirem plataformas".