Executando verificação de segurança...
2

O que você já fez que justificou o uso de um Framework JavaScript?

Deixe-me ser específico aqui para evitar dúvida: Qual projeto ou parte de um projeto você já criou que realmente um framework JavaScript complexo foi realmente necessário? Seja ele React, Angular, Solid, Vue, Svelte, etc. Estou excluindo dessa lista frameworks e bibliotecas mínimas como Alpine, Petite Vue ou até mesmo Jquery. Quero também deixar claro que estou considerando a alternativa o tradicional ssr em qualquer linguagem com templates e qualquer framework js mínimo, web components ou até mesmo htmx.

Essa pergunta surgiu da minha observação de como 90% da web é construída. Se olhar para a maioria dos sites vai ver que a interatividade se baseia em alguns modals, drawers, rich text editors, lazy loading entre outros, em que caímos entre duas situações: ou pode ser implementado de forma mínima seja com js puro ou bibliotecas pequenas com alguns eventos aqui e ali. Ou já tem soluções prontas para serem integradas em qualquer site. Existem exceções a isso, interfaces podem ser muito complexas onde ferramentas arrojadas pode ser necessarias. Para citar algumas dessas interfaces como exemplo: Figma, Canva e Trello.

Mas por isso pergunto: quando em seu trabalho realmente esses ferramentas se mostraram necessárias? Quando uma renderização server side com algumas linhas de js se mostraram insuficientes? Acha que esses frameworks são essenciais para seu trabalho? Consideraria trocar por algo mais simples se possível?

PS: ignore o fator "necessário pois a minha empresa usa". A ideia da discussão não é essa.

Carregando publicação patrocinada...
10

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

3

Acho que seu comentario sobre o estado da web na era jQuery é o que causou a insanidade que vemos hoje em dia. Por que existem tantos frameworks: Por que javascript era horrivel, por que o suporte era segmentado, por outros N defeitos que tinhamos até então. Hoje js é uma liguagem de script (repito, de script) decente. Css não é mais um inferno. E ainda sim todo mundo usa React e Tailwind por padrão.

Eu acredito que ainda que existam defeitos no modelo atual. E que mesmo o simples ainda precise de uma ajuda de alguma biblioteca aqui ou ali. Mas para o que vem sendo feito, o básico seria o suficiente para a maioria dos projetos. E digo mais: Até mais eficiente de desenvolver.

E nossa, como eu concordo com seu argumento:

O que deveria ser ABOLIDO?

  • Falta de conhecimento

A primeira escolha se tornou o complexo por ser julgado mais fácil. Apesar de muitos nunca terem tentado fazer de outro jeito. Muito bem colocado.

2

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.

1

Eu acredito que algumas vezes é o caso. Muitos frameworks são overkill para o trabalho que está sendo realizado no frontend e são utilizados apenas por que "convenção". Mas utilizando seu exemplo, realmente fazer tudo na "unha", o que nesse caso se traduziria a utilizar apenas js puro seria um pouco massante. Por isso eu acredito em soluções intermediárias. Bibliotecas mínimas. Muito obrigado por comentar!

2
0
2

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.

2

Muito interessante, acho que você viu ambos os casos que citei, onde um framework era necessário e onde talvez uma biblioteca menor fosse o ideal. É interessante ver como em muitos casos equipes escolhem um grande framework para projetos que como o seu em Asp apenas requerem uma tela de certa interatividade. E gostei muito da sua consideração sobre htmx para esse caso.

Foi o uso de htmx e Alpine js que me fizeram realizar essa pergunta já verdade. Utilizá-los para substituir um framework em um grande projeto comercial foi uma grande decisão pra mim e que teve impactos positivos muito maiores do que eu imagiva.

Muito obrigado por compartilhar sua experiência!

1

Quem usa JQuery nos dias de hoje gosta de sofrer, não vejo ele mais necessário há mais de 5 anos!

Porém, optei por não adicionar nenhum pois complicaria o restante do sistema só por conta dessa tela.

Vue e React são Progressivos, ou seja, se você quiser adicionar em apenas uma tela, ou até em apenas uma div vc consegue. Não é algo trivial, vai importar uma bazooka para matar uma formiga, mas em um caso que daria muito estresse vamos de bazooka mesmo!

1

Eu entendo o teu ponto. Mas mesmo usando uma lib dessas, existe uma complexidade que quem trabalha com nodejs ou com desenvolvimento frontend não imagina: dev backend (não-nodejs) não tem nodejs e nem instalados em suas máquinas. Se eu optasse por esse caminho, além de instalar uma bazuca de coisas pelo node_modules, como tu disseste, eu ainda obrigaria os outros devs do projeto a instalar o nodejs, usar um nvm pra não ter conflito de versão, além de ter que adicionar essa etapa na esteira de CI/CD. Tudo isso por causa de 1 tela.

2

vc nao entendeu meu ponto. pfvr leia meu outro comentário que tem uma sessão inteira só sobre JQuery.

Em resumo: ele foi muito util no passado. o JQuery em si nao é mais util hoje. tudo que ele faz pode ser feito de forma até melhor com JS puro.

Se eu optasse por esse caminho, além de instalar uma bazuca de coisas pelo node_modules, como tu disseste, eu ainda obrigaria os outros devs do projeto a instalar o nodejs

libs sao arquivos JS. nao precisa de node modules para usar. precisa pra buildar e otimizar pode incluir na pagina e usar inline (nao poderia usar coisas como JSX) mas sim, dá pra usar sem ter stack node

1
2

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.

1

Isso é particularmente vantajoso se você não tem um especialista em CSS no time, que foi o meu caso. 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.

Na minha opinião se um dev Front-end não sabe CSS a ponto de precisar de uma ferramenta para solucionar o problema ele não é um dev Front-end qualificado. Para um júnior essa desculpa é aceitável. Mas se um Pleno/Sênior usar essa desculpa algo está errado com o processo de contratação

1

concordo plenamente. Mas as vezes vc não tem um dev frontend no time e precisa entregar uma aplicação web, mesmo assim! Justamente nestes casos se justifica o uso de framework de componentes UI!!!

1

Eu concordo com você, e não posso deixar de pontuar quão problemático é adicionar complexidade desnecessária ao código por mera conveniência. A entrega da solução não pode esperar pela evolução da qualificação do profissional. E o profissional precisa entregar para manter o emprego.

2

Perfeito sua colocação sobre complexidade desnecessária, mas é exatamente isso, no fim a feature mais importante de qualquer software é ser entregue dentro do prazo e do custo, atendendo aos requesistos de qualidade claro, mas todo o resto é superfulo!

1

Discordo. Já se fazia isso com Bootstrap (e outros). Inclusive, as primeiras bibliotecas de componentes que usei pra esses frameworks frontend eram desenvolvidas com bootstrap.

2

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

1
1
1

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.

1

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