Sometimes you need to build a project. You have all requirements, ideas and now ready to smash it. And of course in order to avoid reinventing the wheel and falling in the same pit - it is time to choose a framework. Hooray!
Let's imagine you decide to start with API. A simple CRUD system which would be responsible for storage, retrieval, modification and deletion of user account. Aaaand by Googling the "best framework for API" and evaluating the first five pages - voila, SpringBoot entered the game.
@Did @You @See @How @Many @Annotations @Are @Required @To @Do @A @Simple @Thing @?
Look, I love simplicity. But I completely dislike magic. Things should be easy to understand and investigate in case something goes wrong. Something which is not that straightforward in some cases with frameworks.
I would rather write FROM SCRATCH on vanilla Kotlin/Java any required functionality which would be easy to debug and clear for everyone, rather than hide ugly complexity under misleading annotations [yes, Springboot reference].
It reminds me a situation when you need a lightweight screwdriver, but instead use a Swiss Knife with a hammer, drilling machine, saw, meter and coffee machine in the same pack.
Sure, in some cases it is a good idea to use frameworks, but only when you clearly understand their limitations architecture. Otherwise a technical debt will be colossal in future.