Oi @GheistLycis,

Eu sou o interlocutor mencionado no artigo e, por conta disso, acho importante esclarecer alguns pontos que podem gerar mal-entendidos.

Antes de tudo, é importante separar conceitos diferentes para não colocar todas as controvérsias no mesmo balaio.

Um conceito fundamental é o REST. REST é um estilo arquitetural descrito na dissertação de Roy Fielding, um dos autores das RFCs que definiram o protocolo HTTP — parte essencial do que chamamos de Web.

Quando ele escreveu essa dissertação (e as primeiras RFCs da Web), JSON ainda não existia. Mas o HTML já existia, assim como todo o conjunto de ideias que compõem os sistemas hipermídia (hypermedia): documentos com diferentes representações interligados por meio de URLs.

Os clientes que acessavam esses sistemas — chamados de User Agents — eram, principalmente, os navegadores (browsers).

Nesse ponto da história, a Web já funcionava perfeitamente com sua arquitetura REST (embora o termo ainda não tivesse sido cunhado), com servidores e clientes se comunicando sem necessidade de JavaScript ou JSON (que sequer existia).

Com o tempo, a Web evoluiu de um sistema hipermídia para uma plataforma de aplicações. Essa evolução foi rápida — mais rápida do que os servidores e navegadores conseguiam acompanhar.

Essas limitações impediam o desenvolvimento de certos tipos de aplicação, até que o Google implementou um “hack” usando uma extensão peculiar do JavaScript chamada XMLHttpRequest para seu cliente de e-mail, o Gmail. Assim nasceu uma revolução no desenvolvimento Web. Vale notar: o nome do objeto é XML — não JSON.

Esse recurso, junto com o surgimento da excelente engine V8, possibilitou uma Web muito mais dinâmica, onde aplicações com interfaces complexas — como Onshape, Figma, Miro e Google Docs — passaram a ser inteiramente implementadas em JavaScript, no cliente, com altíssima responsividade.

Foi aí que surgiram as primeiras SPAs (Single-Page Applications). Pareciam uma ideia genial! Finalmente, desenvolver para a Web se parecia com desenvolver para desktop. O backend poderia ser apenas uma interface para o armazenamento, enquanto tudo rodava no cliente. E o JSON nascia como um formato leve para transportar dados, sem se preocupar com semântica.

Com o Node.js, então, bastava aprender uma linguagem: JavaScript.

O problema começou quando essa abordagem se tornou a única forma possível de se desenvolver para a Web.

Se é verdade que, para fazer um Miro, Figma ou Google Sheets, rodar tudo no cliente é vantajoso (se não a única opção) — quais são as vantagens dessa abordagem para uma aplicação corporativa que, na prática, é apenas um CRUD um pouco mais sofisticado?

Evitar recarregar a página inteira ao clicar em “Salvar” porque isso seria “lento”? Honestamente, quantas vezes você viu um spinner girando na tela enquanto a API demora para responder? De que adianta reimplementar em JavaScript algo que qualquer navegador moderno já faz “de fábrica” — renderizar um HTML pronto — se o tempo total para receber e processar um JSON (deserializar, injetar no DOM, renderizar via JS) é o mesmo?

Sim, o ecossistema de JS (e TS) evoluiu muito. Mas os navegadores também evoluíram — e os protocolos idem (já leu sobre HTTP/3 e QUIC e suas capacidades de comunicação assíncrona e paralela?).

Se usarmos a Web como ela foi concebida — com navegadores e servidores modernos, boa arquitetura (cache, CDNs, workers, microfronts etc.) — é bem provável que o seu projeto precise de muito menos JavaScript do que você imagina.

É claro que não estou dizendo que dá para desenvolver tudo na Web sem JS (embora esse seja meu sonho). JavaScript é — e continuará sendo — necessário em vários pontos. A questão é: precisamos usar JS para tudo? Precisamos reimplementar, em JS, coisas que o navegador já faz?

Deixo um desafio: tente desenhar suas aplicações Web sempre se perguntando:

“Como eu faria isso funcionar em um navegador com o JavaScript completamente desabilitado?”

A discussão sobre monólito vs. microserviços, mencionada pelo @GheistLycis, é independente dessa aqui — e grande demais para caber neste comentário. Posso falar sobre isso depois: já tive sucesso com um projeto em microserviços, e no projeto atual estou fazendo o caminho inverso (microserviços → monólito). Cada caso pede uma arquitetura diferente. O importante é refletir profundamente sobre o problema antes de decidir.

Por fim, gostaria de dizer que alguns comentários deste post refletem muito bem o que tentei explicar (por exemplo, o do @thiagoandre).

Aos que pedem exemplos práticos: eles ainda são poucos, porque essa discussão — que propõe um “retorno às origens” — é relativamente recente (surgiu por volta da pandemia) e nasceu de forma “tumultuada”, muito por causa do tom irreverente da turma do HTMX, principal proponente dessa abordagem.

Para quem quiser se aprofundar, seguem algumas referências:

• Fielding’s Dissertation — dissertação que introduz o conceito de REST.
• Hypermedia Systems — livro gratuito dos criadores do HTMX, que fundamenta vários conceitos abordados aqui (como HATEOAS).
• A Web é uma API — slides da minha palestra sobre a ideia de criar APIs que também funcionem como aplicações Web. Faz par com meu projeto Toy, que apresentarei como tutorial na Python Brasil 2025 em outubro. Há também o vídeo dessa palestra.

Esse texto foi revisado e as ênfases foram dadas pelo ChatGPT.