Frameworks javascript são horríveis!?

Cara, primeiramente parabéns pela coragem de expor suas idéias e opiniões tão fortes assim em um fórum, de fato vai de contra-mão com o que a comunidade acaba indo, mas eu gosto de pensar como você, fora da caixa, acho que é assim que as coisas melhoram, não apenas seguindo cegamente pra uma tendência, ainda que estando no jogo, precisamos muitas vezes jogar pra não ficar de fora também, como você já sabe bem.

As dores...

Eu compartilho das mesmas dores que você com relação à complexidade desnecessária trazida pelos frameworks e outras bibliotecas. Eu realmente vejo no dia a dia o quão fácil é fazer as coisas da forma mais tradicional ou nativa, porém também nao acredito que javascript vanilla é a solução.

Isso não é um problema só do front, na vida, tudo usamos ferramentas, fazer sem o apoio das ferramentas é de fato não conseguir ser produtivo e muitas vezes não conseguir nem resolver os problemas, imagina a construção civil, medicina, biologia, etc sem instrumentos. Não é uma questão apenas da nossa área. Não acho que a linguagem tem o papel de resolver todos os problemas, ela pura assim como uma série de api's tem um propósito de servir como base.

Talvez, pra muitos casos trabalhar só com o vanilla seja super suficiente, mas eu tomaria um certo cuidado pra estrapolar pra todos os casos.

Minha visão

Eu acho que a linguagem, as ferramentas, e uma série de bibliotecas já evoluíram muito a ponto de que resolver uma gama muito grande de problemas, então a classe de problemas que necessitam de frameworks é muito menor hoje.

Percebi que trabalhar com o Js puro é sim potencializar o problema de deixar o código mais desorganizado em geral, porque não são todos os devs que tem preocupação ou experiencia pra deixar o código estruturado, o framework ajuda um pouco nessa estrutura inicial, deixar o código com a mesma carinha, mas eu concordo com você isso não é totalmente garantidor de ter um código bem estruturado, mas é um pouco mais estruturado, você ganha um pouco de familiaridade sim se você trabalha com aquele framework, o que com certeza não ajuda muito, se você não trabalha com aquele framework específico.

Complexidade

Existem várias formas de identificarmos complexidade, ainda que seja um conceito subjetivo. A minha visão sobre complexidade tem haver com a estrutura do framework.
Eu gostaria de compartilhar a minha visão com relação ao o que eu considero como complexidade.

Angular

O Angular tem uma complexidade inerente ao framework que é trazer uma série de conceitos back-end que não necessariamente casa com os tipos de problemas que existem no ambito de UI. É como vc usar conceitos MVC em uma aplicação de Jogos, não faz sentido, porque a forma como se abstrai os problemas nesse contexto é diferente.

Vuejs

Tem muito pouca personalidade na minha visão. Ele tem tantas formas diferentes de resolver os problemas que ele traz uma complexidade e falta de padronização que é justamente o que se espera de um framework. Voce pode usar SFC ou pode usar jsx, pode usar orientação à objetos, pode usar a forma funcional, tem os hooks assim como React, então além de ter a sua cara apenas pra fazer as coisas, tem a cara de outros Frameworks, como hooks do React... então fica um frankenstein de conceitos.

React

O react resolve um problema clássico que é, escrever da mesma forma os componentes html no lado do server side, seja gerando estático, seja servindo como SSR, e a mesma estrutura de código ser usada para os problemas client-side.
E isso ao mesmo tempo que resolve um problema, ele gera outro, que é misturar renderização de html estático com a lógica em si.

Então, antes voce separava os conceitos ou interesses, como usar um template engine pra renderizar o front, usando sei lá, Pug, PHP, Erb do Rails, ou qualquer template system, toda a complexidade e coisas com relação a importação de html, imagens, svg's etc ficavam por conta dessa parte. Quando o javascript entrava, ele se preocupa apenas na adição de eventos, na orquestração das mensagens e gerenciamento de estado etc.

Com essa mescla de "concerns", não é incomum vc ver componentes com vários imports nos arquivos de componentes, que fazem parte de renderização e também com relação à lógica, então o componente fica enorme e muitas vezes a saída é mais complexidade, quebrando em mais arquivos.

Além disso, com a biblioteca invadindo a parte de renderização além da lógica, ela te força a usar metaframeworks como Next ou algo do tipo pra poder renderizar no server-side, voce fica preso no JSX e à um servidor node, não é como era antigamente, onde a partir do html já existente, o js fazia sua mágina, o JS é dependente desse html dentro do código, inclusive fazendo com que o bundle fique enorme, porque toda a sua aplicação fica dentro do seu javascript.

Com tudo isso, você perde completamente o valor de pensar em fazer as coisas de forma separada, inclusive pensar em como montar UI systems / Design System de forma apartada fica dificil com esse framework, porque o componente tem que já nascer com o html e css embutido, importado dentro do js. Então cria-se o que a gente chama de Vendor Lock-in.

Se seu time precisa pensar em criar um design system, ele já sai de fábrica acoplado à um framework e só será compatível com aquele framework.

Isso força o Dev a não pensar mais de maneira desacoplada, porque ele foi "ensinado" à pensar de forma acoplada com um framework.

Design systems mais desacoplados, como Bootstrap, Foundation, Material UI, Semantic UI poderiam ser usados como referência na hora de você pensar em criar um design system personalizado e assim poder distribuí-lo para que as equipes pudessem trabalhar em páginas usando qualquer tipo de framework, desde que importando o css base daquele produto.

Considerações finais

Além de tudo isso, desde o início esses frameworks foram responsáveis por trazerem uma visão statefull da aplicação como um todo o que é trazer ainda mais complexidade, através da idéia SPA. E no final, muita complexidade é trazido por conta disso, fazer toda a aplicação estar em memória e trackeado pelo framework, problemas de memory leak porque a página nunca recarrega etc etc...

E sempre foi algo que eu fui meio contra, desde o início, sempre desenvolvi criando páginas estáticas, porque recarregando a tela, vc tira uma série de complexidades que vc não teria, e existem várias técnicas pra fazer a transição das páginas suave.

E na prática a conclusão que se chegou é que ir pra linha de geração de estáticos se tornou sendo o caminho mais inteligente hoje, porém, muitas aplicações foram pra esse caminho sem a menor necessidade e hoje são legados.

Eu compartilho das mesmas dores que você, no final eu também quis contribuir de alguma forma para ao invés de ficar só reclamando e apontando esses problemas, tentar resolver esses problemas e compartilhar com a comunidade, e como vc abriu espaço, compartilho aqui a minha: https://jails-js.org/

No meu caso, eu já usei tanto nas empresas que trabalhei, como também com projetos próprios, ele me serviu inclusive pra defender a idéia de que é possível fazer aplicações complexas sem necessitar necessáriamente de frameworks como o que temos hoje. Nesse projeto eu queria mostrar que é possível ainda ter soluções que geram html, seja server-side, seja estático, usando qualquer tipo de template system e ainda assim poder usar um js mais estruturado para a lógica... Ainda acredito que é mais saudável, separar html, css e js, para poder criar projetos que podem ser consumidos e compartilhados inclusive com outros frameworks.

Valeu!

Gostei do seu post, espero que aqui no Tabnews tenha mais posts assim.

Discordo totalmente quando você diz que os Frameworks de hoje são terríveis, para mim são ferramentas excelentes já estudei várias React, Angular, Vue, Svelte, Solid, Alpine, Qwik...

elas são apenas uma visão dos seus criadores de como criar aplicações de forma que eles acreditam que é mais simples.

Para mim o problema são os desenvolvedores que ficam refém do framework e não aprende de fato a linguagem, começa a virar Fanboy e se sente ofendido se alguém falar mal.

Desenvolvedor que só aprende coisas voltado para o trabalho e não apenas por achar legal ver coisas novas, sério tem uma infinidade de projetos legais que os “influencers” não falam e se você não está disposto a procurar e brincar só vai ficar sabendo quando todo mundo já estiver usando.

Outra coisas são as empresas que acham que ferramentas de big tech são a verdade suprema, eu adoro o React, mas até hoje me pergunto como ele ganhou essa força monstruosa, e a única coisa que vem em mente é porque tinha a Meta por traz(claro que ele também trouxe coisas novas).

E concordo com você quando você diz que as empresas querem “peões” porque fica mais fácil de contratar e trocar, mas ao mesmo tempo é entendível porque muitas empresas precisam ter seus produtos rodando o mais rápido possível com o mínimo de padronização, por isso vemos vagas para “desenvolvedor React ” e raramente para “desenvolvedor JavaScript”.

Eu criei a minha própria bliblioteca por acreditar que certas coisas estavam faltando ou deveriam ser mais simples e limpas:

https://github.com/diogoneves07/bemtvjs

E durante o processo de desenvolvimento eu me divirto muito.

Concordo que frameworks são maneiras de reinventar a roda. Afinal, não têm proposta de criar nada, só melhorar o que já existe. No final, tudo transpila pra HTML, CSS e JS puro. Se quiser codar cada linha nesses três apenas, vá em frente.

Os dois maiores benefícios das frameworks são: primeiro, deixar tudo menos verboso (principalmente se for batteries included); segundo, induzir o mínimo de padronização no projeto pra que o programador que revisitar aquele código meses depois consiga entender o que tava passando na cabeça de quem escreveu. Boa sorte conseguindo essa robustez em JS vanilla. Até o React que é só uma lib e tem 0 padronização acaba sendo mais organizado e legível que JS puro e JQuery.

De qualquer modo, não entendi o que você considera bom. Se todas as principais ferramentas que são usadas pelo mundo são ruins pra você, então o que você considera uma stack boa pra projetos grandes e escaláveis?

Além do mais, você só citou frameworks de front. O que usa pro back? E por quê?

Parabéns pelo post ToCodando, parabéns novamente pela análise e embasamento, concordo com a maioria de suas considerações.

Sou a favor de um framework principalmente para garantir a continuidade de projetos independente do programador que criou.

Minha experiência em desenvolvimento web vem de 1996, passei por quase tudo até hoje, desenvolvi em inúmeras linguagens, plataformas, frameworks e realmente por ser programador profissional a muitos anos me senti frustrado com os frameworks mas quando passei a liderar desenvolvimento e gerenciar projetos de médio e grande porte os frameworks provaram seu valor.

O mundo corporativo precisa de garantia e estabilidade antes de ter o estado da arte em código e é por isso que os frameworks tem e terão força.

Para escalar o desenvolvimento de software onde programadores profissionais de alto desempenho é algo cada vez mais raro, precisamos de padrão e compartilhamento.

Podemos conseguir isso com os frameworks de programação ou também com ferramentas no conde ou low conde que além de acelerar, garantem a continuidade das aplicações com baixo esforço e baixo custo de manutenção.

Acredito que estamos apenas no começo dessa padronização trazida pelos frameworks.

E toda essa arquitetura é excelente para dar espaço a inteligência e perspicácia de programadores talentosos, aplicando seu conhecimento e energia no core das soluções, agregando valor a solução, deixando de perder tempo com funções básicas e que sem os frameworks teriam que ser reescritas, testadas, refatotadas a cada projeto.

Eu já usei Angular e o React, os dois são bons mas prefiro React por ser mais organizado.

Programo desde 2005.Vi a ascenção e a morte de muitos frameworks e até de algumas tecnologias. NUNCA usei frameworks JavaScript. Concentrei-me nos conceitos e na linguagem. Estou vivo até hoje.