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

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

Carregando publicação patrocinada...
1
1

hahaha, eu vi acontecendo na prática, tinha um site legado em Vanilla, entregue há muitos anos, maluco era dev react jr, na hora que largaram no colo pra fazer um botão abrir uma popup o doidão demorou tipo umas 2 semanas, travado em coisa boba, nunca tinha criado um eventListener na vida e no começo quando eu fui ajudar no primeiro dia, ele tava perguntando qual comando iniciava o projeto, "não achei o package.json e npm start não funciona".

1