O que justifica?

• Produtividade e velocidade de organização
• Complexidade
• Organização
• Escolha técnica da empresa

O que deveria ser ABOLIDO?

• Falta de conhecimento

Justificativas:

Jquery

Essa lib só deveria ser considerada se você estiver vivendo em um universo paralelo antes de 2018. Nessa época cada brawser implementava a engine javascript da sua maneira. Não era difícil encontrar uma propriedade css assim:

--webkit-align: middle # Chrome
--firefox-align: center # Firefox
--ms-align: center # Internet Explorer
align: center

Ou seja, uma propridade css PARA CADA NAVEGADOR. Imagine ter funções javascript inteiras:

if(browser == `Chrome`)
    abreModalChrome()
else if (browser == `Firefox`)
    abreModalFirefox()
else if(browser == `InternetExplorer`)
    abreModalIE()

SIM! ISSO EXISTIA! ERA HORRÍVEL

Imagina dar manutenção em uma página web assim, claro, tinha muito menos javascript e eram sadas apenas para funções pontuais. Tudo era estático.

Hoje o javascript evoluiu e tudo que se faz com JQuery pode ser feito de forma fácil com javascript puro, sem qualquer lib.

Era Vue, React, Angular

Quando surgiram esses frameworks interativos tudo muda, imagina voçê numa listagem de produtos selecionar um filtro e não precisar ir pro backend para calcular os filtros aplicados na tela. Imagina não precisar fazer um for entre todos os <li> de uma página procurando o que o id é igual a filtroOrdemDecrescente.

Você seleciona algo na tela e ele MAGICAMENTE dá o feedback sem você precisar cuidar manualmente disso. É uma maravilha

Argumento da complexidade

Já mecheu com Data em javascript? tenho traumas até hoje! por isso a lib date-fns se encaixa muito bem no quesito complexidade. Ela permite você trabalhar com soma e subtração de intervalos como se trabalha com a nova api de data do Java. apenas chamando uma função. É perfeita!

Argumento abolido: Falta de conhecimento

Pergunte para qualquer um desses Novos Front-End consumidores de curso para fazer uma página com um mínimo de interatividade apenas usando CSS, Javascript PUROS

90% não vai saber fazer. E esse é o principal motivo hoje de er o meme de centralizar uma div.

Claro que esse meme perdeu sentido depois do flexbox e grid.

Era TailwindCSS

Esse framework me dá arrepios. Quando olho para os códigos feitos nele meus olhos doem. A maioria deixa o HTML extremamente poluído com dezenas de classes em cada elemento. E o pior: O que mais vejo são pessoas escolhendo ele por não saberem CSS simplesmente com um argumento de "não gosto de CSS"

Sim, a WEB hoje está muito moderna, as vagas estão cada vez mais concorridas, a pressão por produtividade está cada vez maior

Mas nenhuma escolha deveria ser baseada em os devs não saberem fazer de outra forma

Na minha opinião NENHUM desenvolvedor deveria escolher um framework antes de saber fazer tudo que ele faria com aquele framework na mão.

Se um desenvolvedor escolhe Vue, React, Tailwind, DateFns, Lodash, [insira qualquer outro framework/lib aqui] porque não sabe fazer de outra forma ele deveria primeiro estudar o problema, fazer da forma "classica" e depois escolher.

A escolha deveria ser feita por utilidade e n por conhecimento

Disclaimer

Em nenhum momento falei que quem usa X tecnologia não sabem fazer. Apenas falei que quem não sabe fazer prefere X tecnologia.

Conheço pessoas extremamente competentes que usam qualquer uma das tecnologias aqui. Mas sabem fazer qualquer uma das suas funções sem elas

Não sou do "mundo JS", mas fico imaginando se, no meu dia a dia, eu abolisse o uso do Spring Boot e resolvesse tratar de todo o pipeline do backend, desde a interface com o banco de dados até as conexões HTTP, na unha...

Isso me levaria tempo e ainda o risco de despadronizar projetos grandes (pois cada um faria do jeito que acha que sabe), fazendo o projeto cair muito nos quesitos qualidade e segurança.

Para aprendizes, eu recomendo, como primeira experiência, tentar fazer na unha, entender as dificuldades e a lógica dentro do capô. Mas no dia a dia, na maioria dos casos, é inconcebível não utilizar frameworks e seus padrões bem estabelecidos e firmados.

Óbvio que é sempre uma decisão que deve ser repensada em cada projeto. Se a solução proposta por um framework parece maior e mais complicada que o problema que vc quer resolver, isso é um mau sinal.

Minha experiência maior é com desenvolvimento backend, seja sistema web clássico (SSR), APIs (REST e SOAP) ou jobs agendados. Tenho apenas 1 experiência em que fui dev mobile (React Native) e 1 em que fui fullstack (o frontend era Angular).

No caso de desenvolvimento mobile, assim como desenvolvimento desktop, não há o que discutir. É absolutamente necessário um framework desses pra desenvolver.

No caso de desenvolvimento web, só em 2 situações que senti a necessidade de um framework frontend desses. A primeira foi o projeto em Angular, que mencionei.

A segunda foi em um projeto ASP.NET MVC (que é SSR clássico), em que uma determinada tela precisava da criação de elementos na DOM de maneira dinâmica e dependendo dos inputs. Implementei isso com o jQuery (que já vem no boilerplate do ASP.NET MVC), mas foi um sacrifício, muito complicado.

Lembro que pensei que se estivesse usando um framework desses, essa ação seria muito mais simples. Porém, optei por não adicionar nenhum pois complicaria o restante do sistema só por conta dessa tela.

Não conhecia o htmx na época, mas teria sido muito mais simples adicionar o htmx só nessa tela pra fazer isso.

Um aspecto que justifica plenamente a adoção dessas ferramentas é o emprego de Frameworks de Componentes UI, como Quasar para Vue ou Ant Design para React. Para alguns, essas ferramentas podem parecer aberrações e, de certa forma, concordo completamente. No entanto, elas permitem a construção de interfaces funcionais e belas em tempo recorde, sem escrever uma única linha de CSS. Isso é particularmente vantajoso se você não tem um especialista em CSS no time, que foi o meu caso.

Nesses casos, a escolha de um framework base torna-se um pré-requisito, não apenas uma preferência. Essa decisão permite que 'equipe frontend' foque exclusivamente na lógica de apresentação e na entrega de valor, ao invés de detalhes estéticos.

Fora isso, para a interatividade em si, hoje em dia não vejo muitas razões para utilizar esses frameworks complexos, a menos que você esteja desenvolvendo algo como o feed de notícias do Facebook. Como você mesmo observou, para 90% das aplicações, Vanilla JS é mais do que suficiente. Esse cenário é novidade porém; não era o caso há 10 anos, quando presenciamos o primeiro boom dos frameworks de JavaScript.

Vale ressaltar que estou afastado do desenvolvimento web há alguns anos, mas havia uma tendência de Frameworks de Componentes UI baseados em web components e Vanilla JS. Se estivesse desenvolvendo um frontend web hoje, eu certamente exploraria essa opção.

Acredito que o uso de bibliotecas assim se justificam quando se esta tendando criar um front-end mais complexo, mais responsivo e mais "divertido".

Na empresa em que trabalho o nosso sistema é antigo e todo em PHP estruturado e Jquery, nada de errado por que foi um absoluto sucesso e rendeu uma empresa que emprega mais de 50 pessoas hoje.

Acontece que agora estamos usando um novo Design System, com telas mais complexas e ricas, nesse caso se viu a necessidade de usar uma biblioteca reativa JS para agilizar o trabalho e componentesar o sistema, nesse caso se justifica totalmente

Falta de mão de obra que domine realmente JS, produtividade e medo de nao conseguir acompanhar a evolução das demandas 'apenas com JS.

Bom, posso falar da experiência que tenho na empresa em que estou hoje, onde trabalho majoritariamente WordPress há quase uma década, para projetos com um foco muito grande em SEO.

De uns anos pra cá, vimos o quanto o aspecto de "performance" nos sites se tornou algo cada vez mais importante e relevante para mecanismos de busca, principalmente com a chegada de iniciativas como o Lighthouse. Com isso, conseguir uma nota 90+ no Lighthouse para sites focados em SEO era quase sempre a tão desejada meta.

No nosso caso, garantir uma ótima performance com um site WordPress sempre foi custoso. Talvez não pelo WordPress em si, mas por como é trabalhoso juntar diversas funcionalidades como: entrega por CDN, Load Balancer, Cache no Servidor, Cache na CDN, Disponibilidade do Servidor, etc. E tudo isso, em projetos multinacionais, com equipes editoriais enormes e um tráfego consideravelmente alto no site.

Foi aí que entrou nossa primeira experiêcia com o headless, onde desacoplamos o front-end do WordPress e passamos a entregá-lo com Next.js na Vercel, usando o WordPress apenas como CMS e API.

Na minha experiência, tivemos melhoras significativas com:

• Static Site Generator – O fato de termos uma arquitetura pronta, que facilita entregar arquivos estáticos na CDN de forma simples, sem nos preocupar com cache, e sem perder o gerenciamento por um CMS poderoso, é algo que, se não usassemos um framework pra isso, estariamos basicamente criando um novo para possibilitar tais funcionalidades.
• Estrutura de código mais comum – Com o uso de um framework moderno, existe uma certa arquitetura pré-definida, que nos ajuda a ter escalabilidade sem dificultarmos muito a entrada de novos contribuidores no projeto;
• Infraestrutura extremamente facilitada – Com o uso de plataformas como Vercel e Netlify, temos uma infraestrutura de extrema qualidade, toda pronta a alguns cliques de distância. Claro que dá pra usá-las só com HTML, CSS e JS, mas não seria o bastante para construir algo em grande escala de forma produtiva;
• Lógica facilitada com State Management – Em casos onde precisamos de uma lógica um pouco mais complexa no front-end, como em um painel ou filtro avançado, montar scripts com JavaScript puro (ou jQuery) requer um esforço bem maior do que usando as funcionalidades de State Management de frameworks como Vue, React, ou outros, o que simplifica o código da aplicação e facilita sua manutenção.

Enfim, eu poderia ficar mais um tempo aqui descrevendo mais benefícios que essas tecnologias nos trazem, mas acho que já deu para dar uma visão superficial de como elas ajudaram no meu contexto.

O ruim é quando escolhem usar um framework específico só por que é "modinha", ou por que está todo mundo usando. Eu acho que precisamos entender a necessidade do projeto e escolher as tecnologias que melhor se adequam a isso, e também que se encaixam com a experiência de quem vai trabalhar no projeto. Afinal, adotar uma nova tecnologia requer um certo investimento de tempo, e talvez por isso muitos devs usam esses frameworks onde nem precisava, por que é o que eles sabem usar.

Mesmo depois de termos adotado a abordagem headless (com esses "novos" frameworks) para a maioria dos nossos projetos, ainda decidimos não usá-la em casos onde vimos que não seria o ideal. É tudo uma questão de contexto.

Na faculdade tive contato direto com Angular, o que na minha cabeça, me fez perder um pouco de tempo, e eu explico. Nunca tinha programado nada além de HTML e CSS antes, após um semestre, vi que realmente não estava entendendo nada e só copiando código, então tive que retroceder, comecei a ver Javascript do zero, fiz alguns projetos pessoais e até hoje resolvo problemas de lógica com JS. Mas o ponto que quero levantar é, o uso de frameworks é muito válido, agiliza muitos processos e te dá uma arquitetura muitas vezes organizada, como no Angular com os componentes e utilizando uma lib como PrimeNG, a estruturação e beleza do app fica muito mais fácil de ser estruturada. PORÉM se escorar em frameworks sem ter uma base sólida do que está por trás do framework, é perder tempo, assim como aconteceu comigo. Aprender programação é como construir uma casa, e começar por frameworks é como começar a construir a casa pelo telhado