I worked on a core Spring Boot project for five or six years at a very large enterprise. In my opinion, the most dangerous thing about this framework is that it makes its core users feel far too self-assured.
When looking at problems, your mind becomes consumed with how to force everything into design patterns—like architectural separation, DI, or interface / implementation split. This causes developers to lose sight of the actual essence of the problem because they are obsessed with conforming to the framework.
Because the ecosystem and toolchain surrounding Spring Boot and Java are so mature and well-supported, it is very easy to find community tools that make you feel like you are doing things the "right way."
I only realized these issues after I left Spring Boot and Java development behind. Now, I much prefer using TypeScript or Python to write code (for example, web servers).
I also prefer using various SaaS solutions to handle authentication and user registration rather than rebuilding it all myself with Spring Boot Security. I honestly never want to go back to the days of writing Java again.
I like Java fine. I would probably prefer Ruby, Rust or LISP given the chance. But I can't disagree with anything you say. So many Java enterprise shops have absurd inheritance and "design pattern" abuse that makes it harder to actually work with the code, and slows things down.
Ops person here who has supported Java/SpringBoot applications. I think most of dislike of Java apps comes not from language or framework BUT from fact that most Java using workspaces are filled with mediocracy. They tend to be businesses with products that have extreme moats and thus quality of software barely matters. I imagine most people who would even read this medium article are dreaming of better than that.
Alternatively, I think of Java and Spring Boots as being incredibly valuable by letting companies that don't really have software as a core competency to make reasonably performant and structured applications.
Mediocrity will never not exist, and you unlock a lot of value by optimising for it.
I 100% agree. I have seen enterprise spring applications that throw away all of the speed through huge amounts of hot path object creation, nested loops, absurd amounts of factories, etc. After going through enough AbstractFactoryFactory calls to make object in an n^3 loop, the framework doesn't matter.
Usually languages are not the issue. It is the code that we write. As long as languages help us to find/debug a problem caused by crappy code - we should be good. Coding is kinda creative work. There is no standard to measure creativity or pitfalls of using wrong patterns. The incidents & RCAs usually find these. But most of the times it is already too late to fix core problem.
Huh, Enterprise usage of Blackberry was very very high and then it was not. And at one point SOA, SOAP/WSDL/XML usage was very very high and now I am told in my very enterprise job I'd be fired if I dared bring those names up.
Usage being high doesn't say anything about quality or suitability of a product specially in enterprise settings.
Im comparing against node equivalent ORMs and find spring consistently better. Yeah ive got to read up on annotations - but when it comes to transactions its always worth revisiting them to check for changes
Does this app take 5 minutes to start? That's so much dynamic Spring magic. Also, how do you keep track of control flow when anything at anytime could have been overridden by something else? It seems like tracing and debugging this thing would be like exploring someone else's codebase every time.
The class loading magic means you need to be exceptionally careful about things that would otherwise be very innocuous. It’s the rule, not the exception - that your average spring boot app will be doing tons of expensive stuff at startup. Most of which is unnecessary and was not even intended.
The JVM doesn’t need this kind of thing either, and it gets a bad wrap from the J(2)EE days, and the “simple” replacement that Spring was supposed to be.
No doubt there’s some benefits to be had, but I don’t think the trade-offs are worth it, especially at larger scales.
Just rewrote it in Go. Now we are using a server which consumes 30% of ram what the existing one used to and the latency and throughput have all improved.
Don't use these stupid java backend like sprinboot.
I wouldn’t reduce it to don't use Java/Spring Boot. Rewrites often (not always) look great because they remove years of accumulated complexity, not because the original stack was inherently bad.
Just rewrite it in X doesn't "just work" for complex systems. It ignores risk, and the fact that design usually matters more than language.
When looking at problems, your mind becomes consumed with how to force everything into design patterns—like architectural separation, DI, or interface / implementation split. This causes developers to lose sight of the actual essence of the problem because they are obsessed with conforming to the framework.
Because the ecosystem and toolchain surrounding Spring Boot and Java are so mature and well-supported, it is very easy to find community tools that make you feel like you are doing things the "right way."
I only realized these issues after I left Spring Boot and Java development behind. Now, I much prefer using TypeScript or Python to write code (for example, web servers).
I also prefer using various SaaS solutions to handle authentication and user registration rather than rebuilding it all myself with Spring Boot Security. I honestly never want to go back to the days of writing Java again.
I expected to see some new Spring 'tricks' in this post, but it's pretty much regular things that people might do in larger codebases.
Mediocrity will never not exist, and you unlock a lot of value by optimising for it.
Usage being high doesn't say anything about quality or suitability of a product specially in enterprise settings.
Now read up on all the dozen of annotations. But yeah, we did not want to "re-invent the wheel".
The JVM doesn’t need this kind of thing either, and it gets a bad wrap from the J(2)EE days, and the “simple” replacement that Spring was supposed to be.
No doubt there’s some benefits to be had, but I don’t think the trade-offs are worth it, especially at larger scales.
Just rewrote it in Go. Now we are using a server which consumes 30% of ram what the existing one used to and the latency and throughput have all improved.
Don't use these stupid java backend like sprinboot.
Just rewrite it in X doesn't "just work" for complex systems. It ignores risk, and the fact that design usually matters more than language.