Sobre frameworks

Existem frameworks e frameworks. Em alguns fica até difícil fugir. Outros você pode, e alguns você deve.

Se você os usa porque não sabe programar, ok, você não é programador, se meteu a fazer o'que não sabe, quer uma grana, é um direito seu, tem espaço para isso, não tem problema. O problema é você querer ser um desenvolvedor de software profissional sério e apostar em frameworks.

Note que eles podem ser usados para dar produtividade, e até robustez, entre outras vantagens, mas nunca para suprir a incapacidade de quem está "programando", pelo menos dentro do objetivo que citei. Eles são errados para o objetivo se a pessoa só conseguir fazer a entrega adequadamente com o uso deles. Mesmo isso, há casos e casos.

Tente fazer um GUI sem usar um framework. É possível, mas raramente será viável.

Não se pode demonizar por completo o uso deles, nem considerar como essencial. Nem colocar todos no mesmo saco, porque alguns ajudam muito mais que atrapalham, outros são aberrações.

Pensa em web que hoje é tão usado. Acha fácil fazer o backend sem um framework? Pode ser um pouco mais simples, mas tente fazer na mão tudo. Provavelmente você vai escolher usar um. Por exemplo, vai escolher PHP, que é um framework (curiosamente muita gente não sabe disso). Ou vai usar uma das várias facetas do ASP.NET, algumas mais modernas e simples que entregam mais valor que as mais antigas e complexas.

Se for no frontend, tem muitos casos que deveria usar um. Tem casos que não deveria nem cogitar, mesmo assim a pessoa usa, porque é o que está acostumada. Ela detona a UX em nome da sua vontade ou necessidade técnica ou política.

Toda vez que a pessoa escolhe um caminho porque todo mundo faz, porque é o padrão, ela está cometendo um erro, mesmo que acerte por coincidência. Tudo deve ser pensado. Deve avaliar as questões técnicas políticas por completo, olhando o lado do usuário, os objetivos de curto e longo prazo. E para isso precisa de experiência. Para o programador inexperiente errar faz parte do processo e serve muito bem a um propósito que também é nobre, que é aprender, e ganhar experiência, com o erro.

O problema de errar no geral é não aprender com ele, é achar que acertou. E vemos isso acontecendo o tempo todo, me parece que cada vez mais. No específico pode ter problemas mais palpáveis, por exemplo aumentar o custo, ter atraso, não entregar o que foi prometido, causar problemas para as pessoas, etc.

É importante entender as vantagens de desvantagens do que vai usar. E fazer isso sem viés. Considerá-las verdadeiramente. E achar todas elas, porque em tempos cada vez mais marketeiros a internet ajuda menos, muitas análises escondem alguns fatores. Você precisa não depender dos outros (que são frameworks humanos), você precisa fazer a análise por conta própria, ainda que use os outros para dar um início. Mas é fácil cair em armadilhas também.

Por isso que eu falo que o bom desenvolvedor precisa de uma formação completa, não pode escolher só algumas coisas para estudar.

Não tem resposta universal. O contexto e qual o framework importam muito mais que fatores gerais.

• https://pt.stackoverflow.com/q/362071/101
• https://pt.stackoverflow.com/q/17501/101

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).

Acho que o principal ponto para responder à pergunta "Até que ponto deveríamos apostar em frameworks como solução? " é entender o contexto em que estamos. Frameworks podem ser usados em diversos tipos de situação e podemos abordar seu uso de forma diferente em cada uma.

Vamos levar em consideração que temos uma ideia de produto e queremos valida-la o mais rápido possível para poder gerar receita o quanto antes. Nesse cenário temos que nos fazer a uma pergunta: "qual problema buscamos resolver com um framework?". A resposta nesse caso deve levar em conta a velocidade que precisamos ter no desenvolvimento do produto, então vamos utilizar um framework para agilizar esse processo, além de nos ajudar a seguir padrões que outros desenvolvedores vão conseguir entender futuramente por já ser algo convencionado pela comunidade da tecnologia escolhida.

Então alguns meses se passam e conseguimos validar que nosso produto gera valor e já temos clientes pagantes. É hora de melhorarmos o produto adicionando funcionalidades novas que serão úteis aos usuários. E novamente o framework nos ajuda a entregar rápido e gerar cada vez mais valor aos nossos clientes.

Mais meses se passam e agora o cenário é diferente: queremos continuar melhorando o produto, mas esse trabalho parece cada vez mais árduo, por termos usado e abusado do framework desde o começo do projeto agora temos uma base de código muito grande e desorganizada, não há uma separação muito clara do que cada função faz, muitas funcionalidades estão acopladas a outras sem necessidade e o software é difícil de ser testado e mais ainda de ser alterado, pois parece que estamos sempre brigando com o framework, que outrora foi nosso melhor amigo.

Agora é hora de dar outro passo: vamos estudar melhor sobre arquitetura de software e boas práticas para ter um código escalável e fácil de manter. Vamos sentar com o time e pensar em uma forma de deixar a lógica de negócio do nosso projeto separada do nosso framework.

Mais alguns meses se passam e terminamos o árduo trabalho de organizar nosso código, acho que agora podemos voltar à questão: "qual problema buscamos resolver com um framework?". Acredito que a resposta é bem simples nesse cenário: "resolver os problemas que o framework foi feito para resolver".

Pode parecer idiota, mas no fim é assim que devemos encarar frameworks. Eles são uma abstração para problemas comuns no cenário para o qual foram desenvolvidos.

Vamos tomar o Vue, um framework frontend, como exemplo: o Vue é uma solução que nos ajuda a abstrair muito do trabalho que temos ao desenvolver interfaces web, nos dando acesso a reatividade e a componentização de elementos do sistema a fim de tornar a interface mais modular. Obviamente conseguimos fazer esse tipo de coisa apenas com JavaScript, mas sabemos que manter um projeto muito grande feito dessa forma, ainda mais com várias pessoas mexendo no projeto, pode ser uma tarefa bem complicada.

E aí que está: o Vue quer resolver problemas relacionados à interface do usuário e nos ajudar a dar uma melhor experiência de desenvolvimento para criar interações melhores, além de estipular conceitos e boas práticas que qualquer programador que for utilizar a tecnologia deve seguir. Toda a lógica de como vamos lidar com os dados de entrada do usuário podem ser feitas dentro do próprio componente que criamos, mas não significa que devemos fazer isso, visto que podemos simplesmente delegar essa tarefa para as camadas de domínio da nossa aplicação.

O mesmo se aplica para frameworks backend, como o Express ou NestJS, por exemplo. Ambos foram criados para auxiliar na parte mais básica na criação de uma aplicação server-side: criar rotas de API, middlewares, renderizar telas etc. Esse tipo de coisa é comum em praticamente qualquer aplicação que rode no servidor, então por que não utilizar algo que facilite esse processo?

Em resumo, nosso produto não precisa saber o que são rotas, métodos HTTP , uma query SQL ou mesmo elementos do DOM, então nossas regras de negócio não devem estar acopladas a isso. O papel do framework deve ser apenas fazer uma interface com o usuário, recebendo e enviando os dados de volta.

Como exemplifiquei no início, obviamente faz sentido deixar tudo muito próximo do framework quando queremos ser rápidos na entrega, mas acredito que quanto mais o projeto e os desenvolvedores amadurecem, mais devemos tratar o framework apenas como uma interface para o que de fato gera valor na nossa solução.