> Frameworks actually add to a deplorable side of the software industry. They encapsulate truly great efforts and wisdom into a package which cannot be unwrapped and used partially.

Do you have a concrete non-hypothetical example? Because I don't think I've seen this.

Exactly. The framework I’m most familiar with, Symfony, specifically is arranged to be antithetical to this statement.

Same for it's Java-based cousin, Spring :-)

Say what? That unholy mess of annotations, unusable outside of the Spring "walled garden" where you have to search the internet on how to do the most basic thing (with annotations)? Spring(Boot) is the perfect example --to me-- of a framework that dictates, and does not allow to be get out of your way when all you want is "just libraries".

I have to disagree with that. I have developed software without frameworks before, and have come to love a good framework. Spring Boot is a performance multiplier. It may look scary at first because it has so many (optional) modules that supports everything from basic injection to cloud infrastructure.

You don't need to use everything just because it is available. Even basic web services are not enabled by default, and is something you need to explicitly add as a dependency. If you don't want to use Hibernate, just import a different dependency instead.

It lets me focus on business logic, while handling the interface outside the "garden" for me. In my experience, the use of annotations is confined outside the business logic. If that's not the case, the code is organized badly and will cause issues regardless of framework.

Example (could be improved of course)

  @RestController
  @RequestMapping("/dogs")
  public class DogController {
     private final DogRegister dogRegister;

     public DogController(DogRegister dogRegister) {
       this.dogRegister = dogRegister;
     }

     @PostMapping
     public void registerDog(@RequestBody Dog dog) {
       dogRegister.registerDog(dog);
     }
  }

If I decided to change it to a message based approach, I could do that without changing any business logic, by replacing the controller with a queue listener. Also note how IOC will automatically inject the business logic component.

  @Service
  public class DogListener {
    private final DogRegister dogRegister;

    public DogListener(DogRegister dogRegister) {
      this.dogRegister = dogRegister;
    }

    @JmsListener("dogs")
    public void registerDog(Dog dog) {
      dogRegister.registerDog(dog);
    }
  }

In my view this is a framework that gets out of your way. I did not have to change the business logic (dog service). Spring takes care of the interface outside the program. If I wanted to switch to a different standard than JMS, I would most likely in many cases just need to change to a different annotation.

If the code is organized badly, the business logic would have been included in the controller and be harder to change. But isn't that the case of bad structure in general?

Spring nowadays supports the JDK-native annotations where the exist, and they have a lot of Spring-agnostic libraries under their umbrella.

But I'm inclined to agree on the case of Spring Boot... It's meant to be a "convention over configuration" kind of thing, so I guess by nature it ties you in pretty hard.

Yeah Spring is obviously deliberately obfuscated, which makes perfect sense considering the business model.

Haha yeah I'm curious what Spring will become now that the big ones like IBM are milking the cloud-native cow with Quarkus instead of Spring...