Resumo geral
O desenvolvimento excessivamente centrado em JavaScript está destruindo a web
- O abuso de frameworks JS aprofunda a complexidade dos sites
- A experiência do desenvolvedor (DX) sufoca a experiência do usuário (UX)
- Até tarefas simples exigem uma estrutura excessiva
- Desempenho, acessibilidade e manutenibilidade pioram
- Recuperar a função original da web é a solução
Introdução
Os males de uma web centrada no desenvolvimento
- A maioria dos sites é complexa e lenta demais
- O design centrado em JS mudou a estrutura para priorizar desenvolvedores, não usuários
- Tornou-se comum que até mudanças simples exijam processos de deploy complexos
Desenvolvimento
O desejo de parecer um app é a causa
- Desde os anos 2010, com a popularização dos apps móveis, cresceu a demanda por uma “web com cara de app”
- A adoção de frameworks JS como Angular aumentou drasticamente a complexidade
- Até conteúdo simples passou a ser desenvolvido como se fosse um sistema
Cultura de priorizar a experiência do desenvolvedor (DX)
- Os frameworks mais recentes focam na conveniência do desenvolvedor
- A abstração de componentes gera distanciamento em relação à UX
- Antes da pergunta “por que usar React em um blog?”, a discussão sobre compatibilidade com SSR vem primeiro
A realidade em que a complexidade virou padrão
- Mesmo tarefas simples exigem estruturas em múltiplas etapas, com build, roteamento, API, cache etc.
- Por causa de stacks complexas, pessoas não técnicas não conseguem editar conteúdo
- As mudanças tecnológicas são rápidas demais, o que dificulta a manutenção
Os prejuízos do abuso de frameworks
- SSR, cache, metadados e outras funções já existentes da web estão sendo reimplementados
- O desempenho cai, enquanto as dependências aumentam
- No fim, surge a contradição de recriar um CMS com frameworks JS
Repetição sem sentido e custo
- A adoção e o descarte de frameworks se repetem, sem uma estrutura estável
- Em vez de resolver problemas reais dos usuários, o foco vai para resolver a complexidade interna
- Marketing de conteúdo, SEO e experimentos atrasam, enquanto a experiência do usuário piora
Os prejuízos para usuários e profissionais de marketing causados pelo abuso de JS
- Alterações de conteúdo exigem intervenção de desenvolvedores
- SEO e qualidade das páginas pioram
- Para os usuários, aumentam os incômodos como atraso no carregamento e falhas de interação
JS é apenas uma ferramenta, não um objetivo
- JS é uma ferramenta poderosa, mas exagerada para a maioria dos sites
- Para conteúdo estático, HTML, CSS e um pouco de JS já bastam
- Vanilla JS, renderização no servidor e o mínimo de scripts são mais eficientes
Concentração de poder e problema estrutural
- Por causa de stacks complexas, todo trabalho passa a depender de desenvolvedores
- Na estrutura organizacional, o poder se concentra em torno dos desenvolvedores
- As decisões técnicas passam a ser tomadas com base na conveniência do desenvolvedor, não do usuário
Conclusão
Recuperar a essência da web é a solução
- Precisamos de sites que carreguem rápido, sejam encontrados em busca e sejam fáceis de manter
- Voltar ao básico — HTML renderizado no servidor, marcação semântica e o mínimo de JS — é a resposta
- É preciso uma abordagem centrada em resultados, não em tecnologia
- É necessário perguntar: “por que usar esta tecnologia?”
- Uma web simples e centrada no usuário traz desempenho, redução de custos e flexibilidade
23 comentários
Basta olhar para o WordPress... acho que isso já responde à questão acima. A participação de mercado do WordPress também é muito maior, mesmo sendo lento...
Acho que, se houver resultados de benchmark como evidência, os desenvolvedores vão conseguir se identificar mais com o argumento. É claro que, quando há excesso de código de framework, o site certamente fica mais lento, mas, pessoalmente, já vi muito mais sites feitos com código vanilla serem mais lentos nas transições entre páginas internas do que sites com framework bem otimizados. Claro, se for um site composto apenas por dados estáticos, talvez ter só HTML + CSS seja mais rápido, mas não sei dizer o quão comum é, hoje em dia, um site feito apenas com dados estáticos.
Se não existirem coisas como React ou Vue,
mesmo implementando a mesma funcionalidade, é preciso escrever o código de forma mais complexa, não é?
Principalmente ao lidar com pop-ups, até mesmo passar uma
propem JavaScript puro deixa o código bem mais complicado.Se até algo simples assim já deixa o código complexo, então
fica realmente difícil implementar funcionalidades complexas.
É uma complexidade inevitável. Não é mais como o simples HTML com templates de antigamente.
Os navegadores que as pessoas usam nem são tantos assim, então por que existem tantos frameworks? Não seria melhor as empresas que gerenciam os navegadores criarem um framework ideal e o manterem junto? Até quando vamos repetir esse ciclo vicioso?
As filosofias de desenvolvimento buscadas variam demais.........
Concordo com o diagnóstico do fenômeno, mas não com a conclusão.
A causa superficial do fenômeno, como o próprio texto menciona, é o aumento da demanda por uma “web parecida com app”,
e acho que, tanto agora quanto naquela época, a web nunca foi realmente adequada para criar “algo com cara de app”, embora, com muito improviso, desse para “fazer algo parecido”.
Na verdade, a própria origem da web está em ser uma plataforma criada para compartilhar uma espécie de “documento”, como artigos acadêmicos.
Basta olhar para os elementos básicos do HTML.
Depois surgiram tecnologias capazes de gerar conteúdo dinâmico, como CGI, e, com a incorporação de linguagens de script no lado do navegador, passou a ser possível dar dinamismo ao resultado, iniciando o afastamento da “web como documento”.
O problema é que, desde esse primeiro afastamento até hoje, a base da web continua sendo um sistema fundamentado em “documentos”.
Claro, surgiram muitas tecnologias novas que fogem dessa orientação de “documento”, como WebSocket, WebRTC e WASM, mas, até hoje, a maioria dos sites ainda é desenvolvida dependendo da plataforma tradicional baseada em “documentos”.
Ainda precisamos empilhar tags
divpara desenhar a tela.Até aqui é a análise do fenômeno, e isso leva à pergunta: então qual seria a resposta?
Se eu imaginar as características ideais da próxima plataforma, sem pensar nem um pouco na viabilidade prática, seria algo assim.
(Não estou dizendo que todo site deveria ser assim, e sim apenas os sites com natureza mais próxima de aplicação.)
Antes de tudo, o navegador se tornaria uma espécie de launcher de apps.
Depois de baixado uma vez, ele deveria poder ser executado também offline.
E o app seria implementado em outras linguagens, saindo do modelo atual de HTML/CSS/JS.
Nesse processo, talvez o navegador pudesse fornecer uma espécie de framework, como no Android.
A forma de comunicação com o servidor também poderia sair do modelo tradicional de requisições web e adotar outro paradigma.
No caso de comunicação que exige tempo real, talvez fosse possível usar a comunicação TCP como ela é hoje,
e também daria para criar e usar uma comunicação RPC mais simples, que não utilizasse o protocolo HTTP.
Não entendo muito bem o que você quis dizer na última parte, sobre ser uma plataforma ideal.
No fim das contas, estamos falando da época em que se baixava um programa nativo e se usava ActiveX nele.
A essência do problema é que isso acaba sendo uma gambiarra para criar uma web parecida com app dentro do protocolo HTTP, que é baseado em "documentos" da web,
e a opinião era a de que, se são necessárias funcionalidades em nível de aplicativo para resolver isso, talvez fosse melhor criar um novo protocolo e framework voltados para apps.
Assim como em smartphones não rodam programas puramente nativos, mas sim apps executados em uma espécie de sandbox, a ideia seria uma estrutura em que isso rodasse no nível do navegador.
Claro, para não virar algo no estilo ActiveX, abertura e padronização teriam de vir primeiro.
Mesmo que seja uma web parecida com um app, acho que devemos buscar algo próximo do que foi concluído no texto. Se usar muito JavaScript, do ponto de vista do cliente a coisa fica pesada.
Na prática, também não é como se não existissem frameworks capazes de implementar isso. O próprio Next.js já permite algo mais ou menos nessa linha se você minimizar o uso de componentes de cliente e só os usar quando necessário, e, no ecossistema Rails que outra pessoa mencionou, o Hotwire (https://hotwired.dev/) oferece um conjunto de frameworks que dá suporte a uma web com cara de app para chegar bem perto da conclusão mencionada pelo autor (Turbo, Stimulus etc.).
Concordo com a consciência temática fundamental deste texto, mas há partes que também me fazem inclinar um pouco a cabeça em dúvida.
Por exemplo, o site promocional de um determinado serviço operado pela nossa empresa mantém justamente a mesma simplicidade que este texto elogia. Felizmente, a maior parte dos elementos desse site é suficientemente estática. O código de frontend, como HTML e CSS, foi escrito manualmente por pessoas, sem framework algum, e de JS há apenas algo como jQuery e Google Analytics. Avisos e quadro de mensagens são implementados com AJAX usando jQuery, mas não considero isso algo irracional nem excessivamente complexo. Acho que está no nível que eu conseguia implementar com base em jQuery quando comecei a aprender desenvolvimento web básico há muito tempo. Pelo que sei, esse site já era operado desde a era do Internet Explorer, então não fui eu quem o fez, mas acho que ele não é nada mau.
Mas nele há controle de versão com Git e um pipeline de CI/CD, e os servidores de staging e de produção estão separados. Quando um Pull Request é mesclado na branch Main, o pipeline executa o bundler e faz deploy automático do artefato gerado no servidor de staging; depois que o responsável verifica o servidor de staging e aprova o deploy final, isso é implantado novamente no servidor de produção. Antigamente, o método era simplesmente sobrescrever diretamente os arquivos originais no servidor de produção via FTP, mas, depois que esse trabalho passou para a nossa equipe, mudamos para esse modelo.
Isso é realmente uma complexidade irracional? No passado, alterar a tag de título desse site era um trabalho que terminava ao entrar diretamente no arquivo HTML do servidor de produção com o AcroEdit com suporte a conexão FTP (sim, as pessoas que originalmente escreveram o HTML daquele site ainda usavam isso), modificar uma única linha e salvar, então talvez essas pessoas realmente sintam assim.
Mas, na minha opinião, esse nível de complexidade adicional era perfeitamente suportável. Nem todo trabalho é do mesmo nível de simplesmente alterar uma única tag de título. E poder apagar sem peso na consciência um código antigo que antes ficava grudado em comentários, porque agora é possível restaurá-lo a qualquer momento; ter rastreamento transparente de mudanças e rollback; e poder adicionar, se necessário, otimizações mais básicas por meio do bundler são, a meu ver, vantagens suficientes. A adição de um servidor de staging para pré-visualização antes do deploy no ambiente real também poderia ser vista como uma forma de complexidade, mas eu acho que isso era necessário.
Eu também tenho muitas queixas sobre como a estrutura interna do código de vários sites ficou excessivamente complexa e pesada. Hoje em dia, o aplicativo Outlook do Windows é baseado em web app e, ultimamente, ficou ainda mais pesado. A ponto de travar só por redigir o corpo de um e-mail na tela ou até mesmo por selecionar todo o texto do corpo, chegando inclusive a mostrar “página sem resposta”. Fui abrir as ferramentas de desenvolvedor no Outlook Web para entender por que isso acontecia e fiquei chocado. Depois de limpar o cache e recarregar, mesmo um minuto depois ainda continuavam aparecendo requisições. Quando fui verificar no navegador, havia vários gigabytes de dados armazenados só relacionados ao site do MS Office.
No entanto, este texto mistura várias coisas; há partes com as quais concordo, mas outras com as quais não concordo muito. Pelo que sei, no caso de HTML semântico e acessibilidade, o passado era na verdade ainda mais terrível. Além disso, a ideia de que melhorar a experiência do desenvolvedor piora a experiência do usuário é algo com que eu simplesmente não consigo concordar, embora talvez isso seja porque eu não sou desenvolvedor frontend web. E dizer até que todo o poder e controle ficou concentrado nos desenvolvedores soa como um absurdo. O poder na empresa não fica com a diretoria? Ou a estrutura das empresas no Ocidente é um pouco diferente da da Coreia?
Como sempre, concordo plenamente que equilíbrio e moderação, assim como simplicidade e praticidade, são valores importantes e devem ser priorizados nas decisões. Mas este texto argumenta como se “tratar todos os sites como produtos de software” fosse algo inteiramente responsabilidade dos desenvolvedores, e acho que justamente essa parte acaba obscurecendo a consciência do problema fundamental. E também acho que a parte que parece romantizar os “bons velhos tempos”, quando não havia processos bem estabelecidos, deveria sim ser criticada.
Não é uma história completamente diferente daquilo que você está dizendo?
Em que parte você acha que isso é uma história completamente diferente?
No fim das contas, acho que o que este texto critica é a complexidade excessiva e o inchaço causado por ela. Não considero que meu comentário seja totalmente sem relação só porque eu não falei de JavaScript nele. De certa forma, trata-se de uma crítica a um aspecto mais pontual. E, como mencionei desde o começo no meu comentário, eu também concordo com a consciência temática fundamental do texto original.
Acho que você entendeu mal a intenção do texto original.
Você disse:
"...aqui temos controle de versão com Git e um pipeline de CI/CD, além de separar o servidor de staging do servidor de produção. Quando um Pull Request é mesclado na branch main, o pipeline executa o bundler e faz o deploy automático do artefato gerado no servidor de staging; depois que o responsável verifica o staging e aprova o deploy final, isso é então implantado novamente no servidor de produção. No passado, simplesmente sobrescrevíamos os arquivos originais diretamente no servidor de produção via FTP, mas depois que esse trabalho passou para a nossa equipe, mudamos para esse modelo.
Isso é realmente uma complexidade irracional?"
Mas me parece que esse texto não tem muito a ver com o assunto. O nível de trabalho de fazer deploy e gerenciamento dessa forma e o que este artigo está defendendo são coisas bem diferentes, na minha opinião.
A intenção do texto original não é simplesmente criticar apenas os frameworks JS que ficaram mais complexos.
Para facilitar, vou citar a partir do link da tradução em coreano acima.
Ao contrário da cultura de desenvolvimento na Coreia, em que o trabalho desce da gestão para o planejador e depois para o desenvolvedor, no Ocidente não existe esse mesmo conceito de planejador como na Coreia, e há casos em que os desenvolvedores participam ativamente do planejamento de produto e afins. PMs no Ocidente, por exemplo, não correspondem perfeitamente ao planejador coreano, assim como cover letters e cartas de apresentação não são conceitos totalmente idênticos. Claro, no caso dos jogos, que têm um caráter mais fortemente criativo e em que diversão e jogabilidade são importantes, o Ocidente também é mais horizontal do que a Ásia, mas ainda assim o trabalho desce do diretor para o desenvolvedor.
Entendi, há essa diferença.
Mas não parece ser algo muito relacionado ao conteúdo acima.
Use Rails, seja feliz
Concordo com a ideia principal deste texto. Hoje em dia o JS está sendo usado em excesso, então é comum ver sites engasgando mesmo usando um i9-9900k. Pode até ser uma configuração meio indefinida para jogos ou trabalho, mas a realidade é que existem muitos computadores de escritório com especificações ainda inferiores.
Por isso eu gosto do Astro e do Hotwired, frameworks com a filosofia de usar JS só quando ele é realmente necessário, como em partes interativas ou em navegação de páginas interativa. Também gosto de renderização no lado do servidor, ou seja, de fazer a renderização no servidor. Por outro lado, detesto CSR (incluindo os casos em que só as meta tags são renderizadas no servidor e todo o resto é tratado com CSR). Isso porque vejo isso como transferir para o cliente o trabalho que deveria ser feito pelo servidor. Pessoalmente, acho que a abordagem tradicional de SPA usando CSR deveria ser usada quando o frontend roda localmente em apps como Electron. Claro, quando o frontend é carregado a partir do servidor, aí deve-se usar SSR.
Abaixo está um resumo que classifica as reações dos comentários à postagem em 5 tipos:
1. Concordância total e apoio
Principais características: Concordam plenamente com a argumentação do texto e reconhecem os problemas de uma stack JS complexa.
Exemplos de opiniões:
2. Preocupação com o abuso de frameworks
Principais características: Criticam o uso excessivo de frameworks como React e Angular, defendendo que tecnologias simples já são suficientes.
Exemplos de opiniões:
3. Concordância parcial + consideração da realidade
Principais características: Têm empatia com a argumentação, mas também existe uma visão pragmática de que a complexidade é inevitável ou necessária em alguns casos.
Exemplos de opiniões:
4. Crítica à cultura de desenvolvimento e à estrutura da indústria
Principais características: Apontam que o excesso de frameworks não é apenas um problema técnico, mas o resultado de estruturas de contratação, cultura e marketing.
Exemplos de opiniões:
5. Crítica ou oposição
Principais características: Não concordam com a premissa do texto ou criticam a argumentação por ser unilateral.
Exemplos de opiniões:
Ah, ao dividir por tipos, ficou fácil de ver e bem legal.
Concordo com o problema da “complexidade excessiva da web” apontado no texto original. Mas é difícil concordar com o diagnóstico que atribui essa causa apenas à cultura de desenvolvimento ou ao uso excessivo de frameworks. Hoje, a complexidade da web em grande parte é a sombra das funcionalidades e da segurança inevitavelmente exigidas pelo “modelo de negócios”. Sem esse ponto, o diagnóstico inevitavelmente fica pela metade.
A web já não é mais uma “galeria gratuita”. Hoje, a maioria dos serviços web, exceto os sites públicos, tem como objetivo gerar receita. Portanto, a pergunta central na escolha tecnológica não deve ser “este código é puro?”, mas sim “esta tecnologia faz nosso negócio dar certo?”.
Visto por essa perspectiva, a “web leve de conteúdo” idealizada no texto original acaba esbarrando na parede das exigências reais do negócio. Por exemplo, um negócio que vende conteúdo não pode operar apenas com páginas estáticas simples. Para processar assinaturas pagas e pagamentos, são necessárias lógicas baseadas em estado, como autenticação de usuários, verificação do status da assinatura e gestão de permissões; e, para proteger o conteúdo, camadas de segurança como validação de tokens em tempo real para impedir cópia ilegal ou acesso não autorizado são indispensáveis. Além disso, para melhorar a experiência do usuário e a taxa de conversão por meio de personalização e testes A/B, também é necessário processamento dinâmico de dados.
Tudo isso pertence ao campo de “aplicações sofisticadas”, e os frameworks são ferramentas realistas para implementá-las.
Claro, nem toda complexidade pode ser justificada. Precisamos distinguir a complexidade em dois tipos.
Complexidade inevitável: é a complexidade com ROI claro, gerada para implementar funcionalidades de negócio, como autenticação, pagamentos e personalização. É um custo que precisa ser assumido.
Complexidade acidental: é a complexidade desnecessária gerada por conveniência no desenvolvimento ou abstração técnica excessiva. Trata-se de dívida técnica e desperdício que precisam ser medidos e removidos continuamente.
Serviços bem-sucedidos diferenciam essas duas coisas e constroem arquiteturas realistas. Ou seja, adotam uma estratégia híbrida que deixa o front de marketing e SEO o mais leve possível, enquanto garante estabilidade com base em frameworks nas áreas internas onde são necessárias transações centrais ou funcionalidades de personalização, conseguindo assim unir velocidade e funcionalidade.
O texto original focou apenas na cultura de frameworks como causa da piora na experiência do usuário, excluindo as “exigências inevitáveis trazidas pelo modelo de receita”. Falar de desenvolvimento web sem considerar esse ponto não é diferente de falar apenas em servir “comida rápida e saborosa” na mesa do cliente, fingindo que a cozinha complexa onde o prato é preparado e o caixa onde o pagamento é feito simplesmente não existem.
Só porque a web está pesada não significa que possamos abandonar frameworks de forma indiscriminada. Acho que a questão deveria ser como implementar, da forma mais eficiente e com o menor custo possível, as funcionalidades exigidas pelo negócio para entregar valor ao usuário.
A tradução para o coreano está abaixo.
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…