Recentemente estava em um bate papo com um amigo sobre a diferença entre frameworks opinativos e frameworks não-opinativo.
Apresentei o Angular como exemplo de framework¹ opinativo em comparação com o React e Vue que seriam exemplos de frameworks não-opinativos.
Isso se deve ao fato de que o Angular, já trazer uma definição de como deve ser feita a construção dos componentes e serviços, como criar as rotas, como faz a injeção de dependência, etc. Ou seja ele é completo de tudo (incluíndo ar-condicionado e direção elétrica :) #entendedoresEntenderão)
Já no caso do React ou Vue não há uma única forma de fazer isso, já que é necessário fazer a "configuração" da aplicação com a escolha dos componentes que serão responsáveis por cada uma dessas responsabilidades.
Outra comparação pode ser feita é entre o Jakarta EE (JEE) e o Spring Boot², onde o Jakarta EE é não-opinativo e o Spring Boot é opinativo.
No Jakarta EE, você pode escolher qualquer implementação de JPA, como o Hibernate ou Eclipse Link ou qualquer outra implementação da especificação. Já no caso do Spring, você tem os projetos Spring Data (JDBC, JPA...). Não há muita alternativa para o mundo Spring para utilizar outros fora desse ecosistema (Ressalva: sim, existem alternativas mas elas não fazem parte do ecosistema Spring como componentes oficiais).
No caso do Jakarta EE, você pode escolher entre o Jersey e o RestEasy como implementações do JAX-RS (essas são apenas as opções mais conhecidas e comuns, mas não são as únicas opções). No caso do Spring há o Spring Web.
A diferença entre esses 2 caminhos (opinativos e não-opinativos) é a cola que é feita entre todos esses componentes e o tempo inicial para o projeto ganhar velocidade de cruzeiro (ou seja, ter um ritmo de evolução constante).
No caso das opções não-opinativas (como o Jakarta EE - como representante do backend e React/Vue - como representantes para o frontend), normalmente você tem muito mais opções que podem ser utilizadas para atender a necessidade do seu projeto e isso pode trazer uma maior complexidade e esforço no início do projeto.
Já no caso do Spring, essas combinações são mais padronizadas e normalmente já são bem azeitadas para funcionar em conjunto.
Enfim não há um melhor que o outro. Vai depender do teu cenário e dos requisitos envolvidos. Normalmente em opções opinativas (de framework, biblioteca, componentes), você tem um ganho de produtividade inicial maior por que os encaixes das peças são mais ajustadas. Basta "ligar" e já está pronto para uso.
Talvez você pode ter problema quando precisar sair um pouco da linha predefinida pela opção opinativa escolhida e vai ter que penar um pouco mais para contornar as limitações encontradas.
No caso de uma escolha não-opinativa, você vai ter que amarrar tudo na unha e o resultado inicial pode ser um pouco mais lento. Em compensação você tem controle total para fazer as personalizações necessárias para as situações enfrentadas.
Entretanto pode ser que você não tenha nenhuma situação que exija essas personalizações e o resultado é que o custo envolvido nessa liberdade desejada não seja suficiente para compensar essa escolha.
Cada caminho tem suas vantagens e suas desvantagens com seus respectivos custos associados. A escolha deve ser pensada levando em consideração os cenários encontrados no projeto e nas situações de exceção.
¹ - Framework ou biblioteca ou sistema operacional ou qualquer outra coisa
² - Destaco que é o Spring Boot (e não o Spring Framework).
Photo by Artem Sapegin on Unsplash
Top comments (0)