The tradeoff of today with Spring Boot is you might get bitten down the line with a little configuration mystery, although it’s such a well-blazed path you’re probably in good company and will find your error solved and documented.
In addition, it’s Java so virtually any serious task is done in a well-blazed fashion with numerous open-source options available. In contrast my Node library I used to generate and validate an XML document at work last month cannot read in its own XML output. It’s a boon for efficiency.
The only downside Java really has is that it’s a bit harder to “hack on” a dynamic, evolving JSON structure so it may be a bad fit for organizational reasons if your company lacks a cohesive, mature Engineering staff.
Also, Spring would be a miserable experience if it were not for Maven/Gradle. Have you ever counted the jar files included in a typical SpringBoot+Spring-Security+Spring-Data app?
All of this is long before Spring Boot. Embedding the web server so that your system is just a plain Java application is a great idea; annotation based config is a great idea; both of those are things you could do (and I did do) back in 2010 on Spring 3.3.
The stuff that Spring Boot adds - the spooky-action-at-a-distance classpath scanning, the we-can-use-them-but-you-can't annotations, the way you can't override part of an autoconfig but have to either accept what the library gives you or write a full config from scratch - is a big mistake. Those who forget Java EE are doomed to repeat it I guess.
> Also, Spring would be a miserable experience if it were not for Maven/Gradle.
Sure. "Have dependency management that doesn't suck" is good advice for any software ecosystem.