I keep reading negativity about spring. I got curious, am building the backend for a new startup with spring boot 3. It’s been a breeze. Everything works, great tooling, very mature software. Am I missing something? Will I regret this in six months?

Spring before spring-boot was an unreadable sea of unique xml. Spring-boot is a guardrail that steers you into the correct usage of the spring framework.

spring => configuration over conventions

spring-boot => conventions over configuration

I disagree but know I’m in the minority.

I would take Spring config XML over the tightly coupled mess of Spring config annotations and code. Circa 2006, Spring config was about binding decoupled POJOs together and code didn’t require any build time dependency on Spring. Now Spring is required at build time and objects expect to be instantiated as beans, and unit tests either require a minimal spring context or some other method of injecting dependencies that would have otherwise existed as a constructor arg or mutator anyway. Now “config” is fully Turing complete as opposed to declarative. Yuck! I’m no fan of XML, but config as code is no longer config, imho.

I liked original Spring idea of being actually non-invasive framework as well and I never had any issues with Spring XML config. It worked for me and Idea has decent autocomplete for it.

There was time when Spring was considered lightweight. Oh, well.

Spring Boot is when it all went downhill.

I'm sure you can find terrible implementations using Spring/Spring Boot. But the only annotation you have to use all the time is @Component (or @Service) and you could still externalize that, even without XML configuration, by using @Bean in an @Configuration class. Even if you're not so worried about compartmentalizing your bean wiring, the number of annotations is often very minimal, and you can focus a lot on actually writing your best business code.

At the end of the day, complex applications need to deal with complexity somehow. The debate becomes: do you want to adopt and trust Spring's "under the hood" complexity, or is your team going to roll a lot of that themselves.

Typical spring boot application is absolutely full of annotations and extended helper classes for configuration, and implicitly running starter classes for further configuration.

My Spring Boot application launches entire tomcat under the hood without a single line of code. How terrible is that?

My preference when it comes to configuration is just pure code. Not @Configuration. Just construct necessary objects, wire them up and go. Just like with Golang. So no magic, all I wrote will be executed and no more. No classpath scanning will be performed. No code will be generated (I can tolerate code generation at pre-compile phase, so I can easily browse it with my IDE, something like mapstruct, but I hate all those java.lang.Proxy-ies, all those asm-generated wrappers around interfaces just so I can write @Transactional, like it matters).

I can actually fight Spring Boot. I can write XML configuration or configure things with code myself. But I live and work in community and I expected to follow so-called "commonly accepted" practice.

> How terrible is that?

Not terrible at all? For most people (not you, OF COURSE) I would ask: could you run Tomcat better than Spring can? Then why care?

The point isn't that one should reinvent the way that Tomcat is started, but that Spring Boot (by default) is using action at a distance and runtime reflection which have serious downsides if you want to understand what's actually going on because you're a) new to the technology, or b) have to debug some weird edge case.

The alternative is using explicit, reflection-less code - which you can do even with Spring, although it's experimental: https://github.com/spring-projects-experimental/spring-fu