Qual sua opinião sobre o movimento Frameworkless?

Começo dizendo que não conhecia o movimento, acho interessante porque bate com minha opinião, no geral.

Porém, eu não sou muito fã de movimentos assim por três razões.

• Eles costumam ser bobos
• Tendem a ser deturpados
• É só mais uma modinha

Eu não quero impor minha opinião para ninguém. Eu gosto de expor minha experiência, minhas preocupações, eu tenho um interesse genuíno em buscar um mundo melhor, especialmente para mim, egoisticamente, junto com outras pessoas, altruisticamente, podermos usar aplicações melhores e fazer que mais e mais pessoas entrem nesse caminho, e faça da profissão algo realmente importante para a sociedade e entregue valor concreto em vez de apenas qualquer resultado.

A impressão que me dá é que esses movimentos passam um pouco desse ponto. A linha é tênue, mas hoje vemos muito a sociedade escolhendo pautas de pouco valor para se expressar, mesmo que não faça sentido para ninguém, ou não faça para si, ela está fazendo porque outras pessoas estão fazendo, é uma coisa que um amigo meu chama de dick contest, se é que você me entende. Não deixa de ser uma modinha.

Modinha não é algo passageiro como muitos entendem. E muitas decisões são tomadas baseadas em premissas falsas como esta exemplificada agora. Modinha é algo adotado porque outras pessoas estão adotando, é sobre o que você não tem interesse real, está só querendo fazer parte de uma tribo.

Um exemplo que eu dou é orientação a objeto. Uma técnica que descobri nos anos 80, fui ferrenho defensor, usei errado quase a vida toda, até porque sempre existe material ruim sobre isso, a crença se espalhou, e com o tempo entendendo melhor e vendo como as pessoas usam, descobri que ele não era essa maravilha toda que as pessoas acham. Veja bem, é bom, é útil, e deve ser usado. Mas é modinha, não porque ele deveria passar rápido, mas porque as pessoas usam só porque dizem que isso é bom. Você vê o tempo todo as pessoas procurando pelo "melhor". Elas só querem estar bem na foto. Ao ponto de você ver gente pedindo ajuda e falando "preciso de ajuda no meu código orientado a objeto, ele não entra no if". Ela não precisa entregar um resultado bom, ela só quer estar na moda.

Qualquer coisa adotada por moda está errada. Até o que eu sempre defendi. Por isso é diferente de apoiar algo dentro da "minha ideologia". Por isso que é diferente de ser moda. Por isso que eu faço ressalvas até quando algo é favorável para mim. Questionar é um princípio básico de quem quer fazer algo melhor, mesmo que não alcance totalmente o objetivo. Mesmo que seja considerado um chato que sempre está vendo problemas nas coisas. E por isso deve refletir bem sobre o assunto porque ele é mais complexo do que parece.

E sem entender o todo, sem que a decisão seja baseada em estudo sério da computação, da engenheria de software, da profissão de desenvolvimento de software, do mercado, você não pode tomar uma boa decisão, vai adotar isso como modinha, como provavelmente faz, até porque é fácil fazer, tenho inúmeros casos próprios para contar, e fará errado, e apenas mudará de problema.

Nem todo caso deve fazer sem framework. Já tentou fazer GUI sem um? Se a única opção for um deles, o que vai fazer? Sabe a produtividade que ele pode dar? Se você não sabe programar, é melhor ou pior com ele? Já pensou que o seu caso pede para criar um framework?

Essa última é polêmica, porque há críticas específicas. E de fato você deve se frear de fazer um. A não ser que faça sentido. Existem projetos que fazem todo sentido, são raros, provavelmente você não os fará, mas pode fazer sentido.

A questão é sempre a pertinência. Adotar ou não, não pode ser dogma, não pode ser imposição de um movimento (que você pode aderir ou não). Eu não quero o compromisso de adotar algo. Eu quero a liberdade de fazer a escolha certa para cada caso, seja por motivos técnicos, e até políticos, que importa também. Eu tenho que tomar a melhor decisão para aquele momento, não posso me prender a dogmas. Isso leva a erro.

É bobo achar que aderir a um movimento fará sua vida melhor, que sua carreira será melhor, que obterá melhores soluções, ou que fazendo parte dessa tribo fará o mundo ser melhor, mesmo que a ação em si possa fazer. Você pode divulgar o movimento, expressar sua opinião, até fazer parte dele como um statement, mas tem que ter cuidado para não ser apenas massa de manobra, em todo "movimento" na vida.

Esses movimentos não costumam obter muito sucesso porque ou ele não é natural, ou porque ele não alcança o objetivo. E quando tem sucesso, mesmo que parcial pode ser pior, as pessoas adotarão por motivos errados e de forma errada.

É como o movimento que prega o não uso de if. Vira um telefone sem fio. As pessoas começam a adotar pelos motivos errados, e fazem atrocidades para dizer que está nessa moda (goto is harmful), piorando seu código. Por isso é bobo participar de algo assim. O mesmo vale para Agile, que é completamente deturpado porque quase todo mundo cria burocracias de como fazer ele certo. E bate de frente com o que diz o manifesto. As pessoas dizem que fazem, sem fazer, só para dizer que são modernas, competentes e conformes.

Por que eu deixaria de usar um framework que me traz vantagens importantes em um cenário em particular porque alguém que não paga minhas contas me disse que eu deveria?

Por que eu abandonaria algo que está funcionando bem e traz vantagens, para adotar algo da moda, que pode não trazer vantagens suficientes para compensar as desvantagens?

Por que eu adotaria algo que atrapalha a experiência do usuário só para facilitar meu trabalho? A UX é uma das coisas mais importantes de um software, o que inclui performance, e um framework pode não entregar isso. Ou pode ser a melhor opção para isso. Quem tem experiência sabe disso. Quem não tem, adota o que o "mercado" manda ela fazer. Tem caso que facilitar a vida do desenvolvedor é importante, mas quase nunca em detrimento da UX, e vemos o tempo todo as pessoas fazendo isso. Muitas vezes com justificativas que não param em pé. Em alguns casos chega ser brutal, quase todo mundo toma certa decisão porque está todo mundo fazendo, até em certo momento pode fazer sentido, porque o mercado começa pedindo errado.

Você faz tudo para web porque é bom para você ou para seu usuário? Você adota NoSQL em favor de quem? Quer fazer microsserviços com que objetivo? (bem, isso nem ajuda o desenvolvedor, no máximo o currículo dele).

Vai adotar React por que está todo mundo adotando? Sabe todos os benefícios e desvantagens? De verdade, não o que está nas páginas por aí para incentivar você a usar, ou para não usar, mas em favor do Angular. Você tem conhecimento profundo e experiência para tomar a decisão certa? E se não tem, então o certo é ouvir quem? Um movimento bobo organizado por algumas pessoas inconformadas com o erro, ou com a esmagadora maioria do mercado?

O que você responder aqui dirá muito sobre você. Não tem resposta certa, ambas estão erradas. Não é assim que se decide.

Para tomar uma decisão de usar ou não um framework você deve saber de tudo, até da existência desse movimento. Que me parece bastante cuidadoso, não querendo impor nada você, só te alertando para tomar melhores decisões. No exemplo citado na postagem original nós nunca saberemos se tomaram a decisão certa, e para quem foi certo.

Mas você percebeu que ele não entende o movimento? Me pareceu que ele disse "eu tenho que ir contra framework porque o movimento que eu resolvi fazer parte diz para eu ser contra, mas eu serei a favor do que você quiser porque eu estou tomando a decisão certa". Mas o movimento nem deveria entrar na equação, e se entrou, tomar a decisão certa é o que ele prega, não o que diz no título dele, que parece ser só um chamariz.

Já parou para pensar que escolher entre React ou vanilla tanto faz quando a decisão de fazer para web já era errada? Eu sempre falo, muitas das decisões que as pessoas tomam são para consertar o erro da decisão anterior, quando deveria consertar o erro original. Assim como usar Java, Kotlin, Swift, Objective C, C#, ou outra coisa para fazer mobile tanto faz quando ninguém quer instalar seu app no celular.

Minha experiência mostra que migrar de algo vanilla para um framework, só pode ser a decisão certa quando antes foi tomada a decisão errada. O contrário é mais comum. Se deu a produtividade necessária no começo, para depois entregar mais valor ao usuário, então se abandona o framework, o que é uma decisão corajosa, porque é difícil fazer isso. Sabe quando eu falo que se você aprende o errado, pratica o erro e sempre o reproduzirá? Vale aqui também. Depois de feito é difícil desfazer. E por isso que eu critico bastante o tal de MVP, onde ele vira eterno, é raro consertar, até porque fica mais difícil e caro depois, mas se o fizer, é isso que eu falei, você migra do ruim para o melhor para benefício do usuário, já que no começo fez o melhor para você.

Pra mim o melhor ponto do "movimento" é ele falar que deve analisar seu contexto. Se você tiver competência fará a melhor decisão, se não tiver, é o que tem, fazer o que...

Por isso que bato tanto na tecla dos fundamentos. Não tem sênior que toma decisão baseada em mercado, em movimento, ou outros motivadores assim.

Com ou sem movimento continuaremos tomando decisões erradas, assim como certas, para os dois lados.

As justificativas para uma decisão, especialmente de usar um framework, costumam ser falaciosas, em geral por ingenuidade.

Tem que ficar esperto porque em muitos casos criadores de modinhas só querem notoriedade.

O mundo não precisa de mais uma divisão, desta vez entre "só deve usar framework" ou "nunca usar framework".

Ah, e pra deixar claro, essas plataformas no e low code, Wordpress e muitos outros softwares de programação são frameworks disfarçados. Só porque não leva o nome ou não é classificado assim, não quer dizer que não seja. É que eles ainda possuem uma camada ou uma ferramenta a mais ou entregam um exemplo de implementação pronto, e podem ser classificados como outra coisa.

Faz sentido para você?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Minha opinião é a mesma que eu já disse aqui:

De forma geral, todo framework é uma faca de 2 gumes.

Por um lado, te dá muita coisa pronta e pode agilizar e facilitar sua vida.

Por outro lado, te dá muita coisa pronta, mas que vc não necessariamente precisa, e seu sistema fica com aquele "peso" extra sem utilidade.

Além disso, nem sempre ele te dá flexibilidade suficiente. Às vezes vc precisa de algo um pouco diferente do que o framework faz, e tem vezes que não é possível. Ou até é, mas precisa dar tantas voltas que compensaria mais fazer tudo na mão.

Cada caso é um caso, e como tudo em computação, o ideal é estudar bem os prós e contras, e decidir de acordo com o seu contexto e necessidades.

Ou seja, nem 8 nem 80. Usar framework pra tudo pode ser ruim, porque pode cair em casos nos quais ele não é a melhor solução (ou é um canhão pra matar mosca). Mas nunca usar também pode ser ruim, pois tem casos em que ele é a solução mais adequada e pode poupar o trabalho que teria se fizesse sem ele.

Sobre o movimento em si, eu gostei da ideia geral, que bate com minha opinião. Por exemplo, citar que a falta de conhecimento pode levar a decisões ruins (como a escolha de um framework que não é adequado para a situação), ou que frameworks são apenas ferramentas, e toda ferramenta é um trade-off ("cada escolha, uma sentença", ou seja, vc ganha as partes boas, mas vai ter que conviver com as partes ruins - que todas as ferramentas têm).

Também acho que os princípios do movimento fazem sentido (em tradução livre):

• O valor de um software não está no código em si, mas no motivo pelo qual esse código existe.
• Cada decisão deve ser feita considerando o contexto. Uma boa escolha feita em determinado contexto pode ser uma má escolha em outro.
• A escolha de um framework é técnica e deveria ser feita por pessoas técnicas, levando em conta as necessidades do negócio.
• O critério de decisão que levou a escolha de um framework deve ser conhecido por todos da equipe.

Então eu entendi que apesar do nome (Frameworkless - "sem framework"), a ideia não é "nunca use", e sim "avalie bem se precisa ou não". Tanto que o primeiro parágrafo do site já diz que "Não odiamos frameworks, e nem iremos fazer campanhas contra eles" - ou seja, não leve o nome tão ao pé da letra :-)

Como já foi dito, o lado bom dos Frames é que eles tem muita coisa pronta, o lado ruim é que eles tem muita coisa, e as vezes pode ser limitante.

Já vi casos de demandas que foram entregues com certo atraso apenas pq o dev responsável até sabia resolver o problema, mas não através do Frame utilizado (se fosse outro Frame ou se fosse código nativo, ele teria entregue antes).

O código nativo vai ser mais objetivo e mais rápido para o que a empresa precisa e, se o time for grande, nada impede os devs de irem aos poucos criando uma biblioteca própria, que fará todo sentido pro negócio, e deixará o trabalho mais agilizado, como se estivessem usando um Frame.

No mais, Frames são ruins para aprendizado. O dev novato fica mal acostumado com "tudo pronto, só saber usar" e não aprende a criar nada, não sabe como a parada funciona. Dai um dia a empresa resolve vir com o papo de Frameworkless e o cara fica na m3rd@ kkk

Eu partiria do princípio que React não é um framework, hoje você tem diversas opções inclusive o HTML 5 é uma delas, mas com React você vai lidar com o estado da sua aplicação de forma muito mais produtiva do que com o HTML 5 in vanilla. Isso é um fato. E se ainda sim o React parecer pesado para sua equipe, você tem alternativas, como o preact, que pesa incríveis 3kb apenas.

Mas eu não vou entrar nessa conversa de peso de bundle, porque no próprio react você consegue "splitar" seu bundle, por "rotas" trazendo assim uma experiência mais leve e fluida em aplicações muito grandes (eu por exemplo fiz isso na ecompay https://ecompay.app)

Se quiser ler mais sobre, segue um artigo da própria documentação https://legacy.reactjs.org/docs/optimizing-performance.html

Outra opção se quiser trabalhar com estados, é, construir seu próprio reconciliador de virtual dom + gerenciador de estados, inclusive globais. Eu já fiz isso e não leva muito trabalho. Recomendo a série de artigos: https://pomb.us/build-your-own-react/

Sem entender o que o projeto faz, não da pra saber se um framework é importante.

No mais, de dados tirados do nada apenas vivencia. Uns 95% dos projetos não precisam de framework algum.

Vi gente fazendo projeto de 2 páginas com react. Só adicionando complexidade atoa!

A questão é, as pessoas sabem usar JS puro + html e CSS?

É um erro até bobo pensar que não usar framework é não ter DRY. Na verdade muita gente confunde DRY com não se repetir. Não é sobre isso. É sobre abstração e é preciso tomar cuidado com abstração!

No mais é preciso de mais informações. Eu sou adepto do não uso de frameworks o máximo possivel. Simplesmente por motivos de que na maioria das vezes não precisa.

Agora no seu projeto, não da pra saber se precisa ou não! Depende muito.

E algo importante. Com microfrontends da pra por um framework só onde precisa. Em certas partes.

Aqui precisa, então colocamos. Em 80% do projeto não precisa, então não colocamos!

Na minha humilde opinião, não existe "bala de prata", para nenhuma feature, framework, linguagem, cloud, (coloque o que mais você quiser), etc.

Linguagem é ferramenta, framework é ferramenta. O que mais vi na minha humilde experiência profissional e pessoal no mercado tech foram profissionais obcecados em fazer e assim esqueceram o "Como fazer?" ou até mesmo o "Por que fazer?".

Sempre pondere a necessidade, os requisitos. Aumente seu "portfólio mental" de soluções para saber qual é o melhor, de acordo com os seus conhecimentos, com o que o time sabe, e também com o que se consegue fazer naquele tempo.

Muitas vezes framework "A" pode resolver o problema tal qual o framework "B", perante certa necessidade, certos requisitos, e por incrível que pareça, pode não fazer significativa diferença no final das contas, usar um ou outro.

Já passei por projetos onde:

• foi escolhido uma linguagem por ser o "knowhow" da maioria do time
• foi escolhido o framework "X" por ter mais devs contribuindo no github, do que outro também largamente utilizado.
• foi escolhido usar cloud "Y" por que a empresa se beneficiaria em um negócio interno.

Fazer oq? Esse é o mercado, essa é a vida real. Devemos sempre dar o nosso melhor, de acordo com os parâmetros que temos, em cada momento e situação. A experiência (não em anos, mas em vivência) lhe ajudará nessas escolhas.

Parece muitas vezes uma questão filosófica, e é mesmo. A cultura de uma "bigtech" ou de empresas pequenas, pesa muitas vezes, de forma errada, em questões técnicas. Muitos são os fatores (do que tem menos peso, ao mais importante) que mudam a escolha de uma "ferramenta".

Software, ao meu ver, é "vivo". O código é "vivo". Deve ser sempre corrigido, melhorado, e muitas vezes refatorado (infelizmente kkk). Hoje o que funciona, amanhã pode não funcionar tão bem. E tudo bem, faz parte.

Todo esse assunto dá um excelente papo! Espero poder ter ajudado qualquer um que leu esse comentário.

Na minha opinião, estudar como fazer sem framework é uma ótima forma de se desenvolver e entender o que a por trás dos códigos.

Porém como bem dito nos outros comentários os framework ele tem uma razão para ser adotado, entrega velocidade e qualidade na produção, justamente por padronizar os códigos. Então é ótimo tentar fazer na forma vanilla, mas não escreva isso em pedra.

A idéia bate muito com o que eu penso. Eu sinto falta as vezes, e quero escrever um código do 0. Porém não consigo me imaginar reescrevendo os sistemas em que eu trabalho sem os frameworks, é um exercicio mental que faço as vezes. Me parece um trabalho desperdiçado comparando que o que eu vou ter que reescrever um código que ja ta la prontinho e bem organizado. Mas claro é um ponto de vista. Pra uma empresa grande com vários desenvolvedores pode valer a pena, pra um aluno que está aprendendo pode ser um bom ponta pé. Mas pensando em uma equipe pequena de desenvolvedores com uma demanda alta, não da.

não acredito nesses movimentos. Eles são passageiros!

dizer para não fazer nad acom framework e escrever tudo na mão é uma bobagem, oor exemplo ao escrever uma api e manipular uma request, você utiliza API do node pra isso, ninguém fica lá lendo os sinais da placa de rede e interpretando esses valores.A API da runtime oodemos dizer que é um tipo de framework.

Eu concordo como ponto de não criar "over-engineering", que também é algo bem comum, principalmente com coisas do hype. Mas o ponto o principal é, existem frameworks para tudo, de diferentes tamanhos, pewuenos médios e grandes, para serem utilizados em projetos pequenos médios e grandes. Se você for fazer algo simples, oode utikizar um framework mais simples, que tem só aquilo que você precisa. Outro ponto é que não dá rpa negar que extremamente difícil construir algo grandioso em vanilla. ja pensou como seria complicado fazer toda a mirabolancia que o next.js faz, como hidratation, SSG, Caching, CDN e etc?? e se tudo esse aparato for um requisito de desempenho de um projeto?

então eu acho que se dor algo maiorizinho vale a pena sim utilziar framework, o segredo está na decisão de qual utilizar

Primeiro gostaria de compartilhar um material que mostra como é possível fazer desenvolvimento profissional sem frameworks: https://modern-web.dev/docs/

Conteúdo muito bom, vale uma leitura com atenção.

Eu me sinto obrigado a usar frameworks e não gosto nem um pouco dessa obrigação. Mas, é o que paga os meus boletos.

Acredito que o desenvolvimento sem frameworks é o melhor e gostaria que no futuro fosse adotado como prática comum, mas, sei que para as empresas gigantescas que dominam os rumos dos frameworks de maior sucesso e da área de TI mundial isso não é interessante.

Hoje acredito que os frameworks são midiáticos. Formas para controlar como as pessoas engajadas no desenvolvimento de software o fazem.

É muito mais rápido definir uma estrutura e produzir um software sem framework. Basta usar padrões e seguir em frente.

Não complicar é a chave de solucionar problemas com velocidade. Mas, quem por ai não gosta de complicar?

Um ponto que facilmente passa desapercebido é que frameworks e grandes bibliotecas são construídos sob a experiência de desenvolvedores. Essa experiência é limitada, com certeza, porém React é construído sobre uma plataforma utilizada por centenas de milhões de pessoas. E a pergunta que fica é, quando vale apena não utilizar essa experiência em forma de código e construir a sua?

Se você considerar que o React nem foi lançado como um framework, isso ganha ainda mais força. Porque não utilizar-lo?

No final do dia, não vamos acabar criando um framework de toda forma? Imagina, qualquer empresa precisa:

• Codebase padronizado para acelerar a entrada de novos desenvolvedores;
• Camadas de abstração para DRY e evitar soluções muito complexas incompreensíveis.
• Contratos entre os desenvolvedores de como organizar o código para aumentar a colaboração entre os membros da equipe e paralizar trabalhos.

No fim, minha opinião é que parte de movimentos assim é de um desejo que nós desenvolvedores temos de construir coisas magnificas e manter controle sobre tudo que fazemos. Como um desenvolvedor experiente, saber lidar com esse lado emocional controlador e um tanto egocentrico é muito importante para tomar essa decisão.

Mas há sim situações onde o uso de framework não é necessário. Há talvez muitas situações, e gosto do movimento em fazer todos nos duvidar.

E até por isso concordo com o movimento, frameworkless (uma alternativa sem framework) e não "no framework", ou "frameworks nevermore" (morte os frameworks hahah).

Não usar um framework é o mesmo que não codar com DRY (don't repeat yourself) em mente, o framework tem muita coisa pronta, tu não precisar criar um addEventListener pra tudo, não tem problema de tempo de execução entre um listener e o outro no Event Loop, consegue usar o state pra rodar muita coisa na sequência sem precisar vincular tudo novamente em listeners, mas a comunidade tem muito peso, alguns pontos que gostaria de destacar

Pros:

• Na minha cabeça, com react a gente consegue acesso a algumas libs muito legais que não sei se funcionam fora do react, nunca tentei fazer Drag and Drop com js Vanilla mano, mas o react-dnd é bem massa, react-icons sempre me ajuda, fato é que existe uma comunidade já muito grande deixando coisas prontas que aumentam a capacidade do "framework".
• Com react é extremamente simples de migrar para um Next.js, e esse por sua vez me parece meio impossível de fazer com Vanilla, edge computing tem muito valor por velocidade, segue a premissa do:

Slow is the new Down

Cons:

• Muito código vai ser completamente inútil, se for uma aplicação simples não é necessário um context provider, useMemo, useRef, etc... mas mesmo assim eles serão entregues na build como base do pacote (no final não parece fazer qualquer diferença ter ou não ter eles no bundle).
• React por si só não me parece um framework por não resolver todos os problemas, tem muita dificuldade em aproveitar SEO que é uma limitação complicada que não teria no Vanilla certamente, é relativamente pesado comparado com um Angular bem otimizado ou Next.js com entregas em chunks bem definida, apesar de ter o lazy load esses outros caras são mais eficientes, em especial Next.js.
• O próprio item anterior mostra algo importante, escolher um framework acaba sendo uma tarefa e a pergunta "escolhi o correto?" sempre vai estar lá, que é um contra sem dúvida pra mim.
• Curva de aprendizado e nicho de mercado, nenhum dev sabe todos os frameworks, mas todos deveriam saber javascript puro, logo, assim que escolher um framework os próximos devs plenos ou seniors deverão ser contratados com isso na cabeça, limita os candidatos.

Conclusão

O peso da comunidade nessa tomada de decisão é muito alto, eu iria de framework no final das contas pois eu não quero saber absolutamente tudo do js,html e css pra entregar um novo Blaze da vida, me parece que fazer o Tabnews seria relativamente fácil em desenvolvimento puro, mas um IQOption pra operações binárias com gráficos em tempo real e animações pra todo lado o jogo muda, e resolver aprender o mundo de um framework só na hora que precisar é uma escolha igualmente ruim, logo usar framework quase sempre acaba se pagando pois vai estar mais pronto.

Espero que tenha feito algum sentido...

Onde que os frameworks facilitam a sua vida?

• Processamento de templates;
• Server de dev com hot reload;
• Transpilação de Typescript;
• Module bundling;
• Minificação de js e css;

Se você tivesse tudo isso de forma simples, o framework ainda faria sentido? Veja que todos os 3 frameworks da moda (angular, react e vue) tem isso, mas nada disso é o core do framework.

Eu passei algum tempo tentando entender como que essa parafernalha toda funciona e criei uma arquitetura com isso já pronto, usando as libs que eu escolhi (vc pode escolher as suas, tem várias), e que na hora de trabalhar com o browser, é tudo vanilla. Sim, getElementById mas com Typescript e hot-reload. Não foi fácil, e o resultado tá aqui.

Já botei alguns projetos em produção com essa arquitetura, e todos os devs que trabalharm com ela me disseram que era super simples de usar, além de que era visível como eles conseguiam entregar mais rápido do que usando qualquer outro framework.

Então sim, é possível e totalmente viável trabalhar "frameworkless" no front e ainda ser muito produtivo, só precisa entender o caminho das pedras.

então...voltar pro PHP?