Com uma máquina absurdamente barata, talvez dê? Um escritório de advocacia absurdamente grande provavelmente compraria. Mas aí seria tipo deixar máquina de fábrica rodando 24 horas por dia kkk
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.
Agora, até para mudar um simples título, são necessários 4 engenheiros, 3 frameworks e um pipeline de CI/CD. Publicar uma página web ficou absurdamente complexo.
Aos poucos, a web se tornou algo que precisa ser compilado antes de ser publicado. Não porque os usuários precisassem disso. Mas porque os desenvolvedores queriam se sentir modernos.
Tudo foi otimizado para os desenvolvedores e se tornou hostil para todo o resto.
Não estamos mais apenas tolerando a complexidade; passamos a tratá-la como algo natural. Assumimos que todo site precisa de etapa de build, bundler, estratégia de hydration, camada de roteamento, camada de API, design system e lógica esperta de invalidação de cache. Construímos com microsserviços, hospedamos em redes de edge e implantamos pipelines para entregar conteúdo simples.
Estamos recriando as funcionalidades de plataformas como o WordPress, mas produzindo um resultado 10 vezes mais pesado e com usabilidade muito pior. Pior ainda, cada nova camada introduz novos bugs, novos problemas de compatibilidade e uma nova carga cognitiva. Agora estamos mantendo lógica de hydration, estratégias de cache e pipelines de build só para colocar uma homepage simples no ar.
Campanhas de marketing atrasam porque a biblioteca de componentes não é flexível o suficiente. Testes A/B são cancelados porque a camada de analytics não é compatível com a estratégia de hydration. Atualizações de conteúdo precisam esperar dias por um build. Ajustes básicos de SEO acabam enterrados no backlog.
Profissionais de marketing não conseguem atualizar o texto nem rodar experimentos sem abrir um ticket. Não conseguem pré-visualizar conteúdo, testar layouts nem publicar páginas. Toda mudança precisa passar por desenvolvedores, pipelines, aprovações e rebuilds.
Profissionais de marketing, editores de conteúdo, responsáveis por SEO e designers, todos eles ficam excluídos do processo. Porque agora até tarefas simples exigem fluência técnica. Se você quiser mudar uma title tag, vão mandar falar com um engenheiro; se quiser publicar uma campanha, vão mandar abrir um ticket e esperar dois sprints.
Tudo passa pela equipe de desenvolvimento. Isso significa que a equipe decide o que é importante, o que será publicado e o que ficará indefinidamente sem prioridade. E quanto mais complexidade eles adicionam, mais indispensáveis se tornam.
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.
Em serviços como chatbots que precisam oferecer streaming, quando há processamento simultâneo, o trabalho de prefill acaba afetando até o decode, então mesmo com VRAM de sobra, do ponto de vista do usuário parece que o desempenho cai bastante.
Também testei opções relacionadas a chunk prefill e o recurso experimental de Disaggregated Prefilling oferecido no vLLM, mas ainda acontece de, quando entra uma nova requisição, as respostas que já estão sendo geradas começarem a travar e picotar, então, do ponto de vista de um desenvolvedor iniciante, fico curioso se existe uma forma mais eficiente além de aumentar o número de GPUs ou de nós.
No Android, se você usar o Vanced, dá para remover a UI dos comentários, então recomendo.
No navegador, também recomendo remover isso com algo como Improve Youtube ou Adguard
Provavelmente, depois daquela atualização, as empresas de adblock até aumentaram a receita.
Apps independentes que bloqueiam tudo diretamente no nível da rede só podem ser usados na versão paga, então devem ter vendido bastante.
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.
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.
Obrigado por apreciar o texto!
Muito obrigado pelas palavras!
Com uma máquina absurdamente barata, talvez dê? Um escritório de advocacia absurdamente grande provavelmente compraria. Mas aí seria tipo deixar máquina de fábrica rodando 24 horas por dia kkk
Uma pessoa que só pensa no preço de um Porsche e não considera nem um pouco os custos de manutenção, combustível, seguro etc.
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.
Acho que isso não se aplica a empresas coreanas.
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.
Em serviços como chatbots que precisam oferecer streaming, quando há processamento simultâneo, o trabalho de prefill acaba afetando até o decode, então mesmo com VRAM de sobra, do ponto de vista do usuário parece que o desempenho cai bastante.
Também testei opções relacionadas a chunk prefill e o recurso experimental de Disaggregated Prefilling oferecido no vLLM, mas ainda acontece de, quando entra uma nova requisição, as respostas que já estão sendo geradas começarem a travar e picotar, então, do ponto de vista de um desenvolvedor iniciante, fico curioso se existe uma forma mais eficiente além de aumentar o número de GPUs ou de nós.
Não seria justamente uma postura de assumir responsabilidade? Eu até concordo com a direção que o Google está tomando.
Também concordo. Não sei se isso é uma postura dupla. Mas eles parecem deixar em paz os que são bem feitos.
Não sei por que isso seria considerado uma postura dupla...
No Android, se você usar o Vanced, dá para remover a UI dos comentários, então recomendo.
No navegador, também recomendo remover isso com algo como Improve Youtube ou Adguard
Tudo depende do caso!
Provavelmente, depois daquela atualização, as empresas de adblock até aumentaram a receita.
Apps independentes que bloqueiam tudo diretamente no nível da rede só podem ser usados na versão paga, então devem ter vendido bastante.
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.
Fiquei curioso sobre o que é
Faceted Searche fui atrás; tem mais coisas interessantes para ler.https://www.cybertec-postgresql.com/en/faceting-large-result-sets/
https://roaringbitmap.org/about/
https://github.com/cybertec-postgresql/pgfaceting
Concordo muito com isso. Também larguei as redes sociais e agora quase nem olho mais os comentários no YouTube.
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.
https://pt.news.hada.io/topic?id=21581
Achei que isso me parecia familiar e, quando fui ver, era só o Nxtscape com outro nome.
Entendi, há essa diferença.
Mas não parece ser algo muito relacionado ao conteúdo acima.