Spring vs. Java EE

I and others have generally found that using Constructor injection greatly decouples a design and simplifies testing.

And the Spring team have been saying so for at least as long as I've paid attention to the question[0]:

> Constructor-based or setter-based DI?

> ...

> The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state.

> ...

[0] https://docs.spring.io/spring/docs/current/spring-framework-...

I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right".

Dependency injection is important because it provides a healthy way to compose an application from many components or services. It's not exclusive to Spring of course, you can do DI/IoC without Spring (even without any framework), but it's baked into the very nature of Spring.

Next, Spring provides "right" way to do a lot of more-or-less standard things. You have solutions for ORM, REST interfaces, security, batch processing and a thousand more tasks. From my experience, Spring solutions are mostly good or very good, at least much better than I'd design in a limited time frame. This gets me faster to the working solution.

I also don't thing that Spring brings that much of a complexity overhead. Once you got past the first threshold (like, you can assemble you application from a few components) you're good to go. Ok, you will eventually need to learn concepts of individual Spring components (like ORM or security), but you'd need to learn them anyway.

Eventually you'll need to fight Spring here and there, I won't deny it. This is normally related to the "automagical" stuff like autowiring or autoconfigurations - things which make your work easier in 98% but might make you crazy for the rest 2%.

Java is great, the best, when I'm trying to build something creative. It's like having access to an entire parts warehouse vs a toolshed for most other languages. Unlike especially JS, most libraries are well tested and most people agree on doing things a certain way. There's not a lot of unknowns, almost no flux, and once you know the rules you can focus on your problem and ignore the "ecosystem" almost entirely.

The complexity can be looked at from a different perspective, I see it as similar to Roman characters vs Chinese. Learning 26 characters is a hell of a lot easier but with a couple thousand you can say the same things with a lot less writing. Once you've gotten over the cognitive hill of learning the complexity it doesn't really get in the way. It's there when you need it, and you ignore it when you don't.

Contrast this to JavaScript where most advancements redefine workflows or parts of the language core libraries. It feels like the most exciting thing about JavaScript is how unstable it is, something that scares the hell out of me after working on 15+ year old code. What you trade off with complexity in Java is definitely less work than keeping up with js for more than a year.

This sort of became a js/Java comparison because there's a ton of similarity in the hype between them and their lifecycle so far. Java was not always so complex after all. You can see the complexity of the JS ecosystem and language growing steadily and I have no doubt that in five years it will be just as complex as Java. The complexity is driven by the big guys that actually need it, and being the big guys, they also have the most influence on what the language eventually becomes.

So to recap, no, for the vast majority of projects the complexity is definitely not justified. It's there so the language can support the 1% of projects that need all that. On the other hand, once you know your way around it's fairly easy to ignore those parts. What access to all this stuff really gives you is power. As a footnote, give JS some time and it will be the same. Any language picked up by corporate interests is basically destined for overengineering.

It is the failure of concepts so if the tool brings the right concepts, it helps avoid such design mistakes in the first place.