[e7h4nz]

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.

[antonymoose]

Funny how that works - I started with Spring both before and after Boot as well as some Scala.

I wouldn’t trade Java / Spring for the world. It forces a coherence, perhaps not perfectly, but it provides guidelines to follow.

I’ve been stuck in Node / TypeScript / Microservice hell for most of the last 15 years and I couldn’t hate it more. The open-source ecosystem is extremely lacking, even now, on something like a good XML library. I think we’ve got four different ones installed in our core platform each handling different needs (traversal, generation, manipulation, validation).

On top of it all, since there isn’t “one way” we’ve got several dozen micro services. There isn’t a single bit of consistency other than “Express.” Logging, authentication, routing, validation - it’s all completely up in the air. It robs us all of efficiency from the lack of common language and pattern. We spend more time refreshing ourselves on any given project than doing feature work or bug fixes.

Madness!

[e7h4nz]

Removed microservices and RPC, keep all TypeScript codes in a single monorepo. Avoiding `any` and using ts-rest automatically keep types synchronized between the web and frontend applications.

This has made my life much easier.

[BariumBlue]

I hear this a lot from a lot of my coworkers who like Java Spring - they trust Spring to do things right, more than themselves.

On the other hand, I hate Java Spring because I feel like I don't trust it - it doesn't let me look into and understand the internals easily, making me feel like I'm afloat on a pile of abstracts I'm not allowed to look down into.

Looking at some other projects enterprise js/ts codebases though, I see a lot of "I don't understand how this works so I'll try random things until it works". In that kind of environment, I can understand the attraction of Spring - it's not great, but it also won't be a flaming pile of unbaked abstractions.

[ivan_gammel]

Spring framework may look complicated only at start, until you get it, but then it becomes quite easy to reason about.

OTOH, Spring Boot is a huge pile of various loosely coupled framework connectors, web, queues, security, databases etc. Some of them are of good quality, some are not so good. It is that uneven mix giving the perception that Spring is a mess.

[functional_dev]

Agreed, Spring Framework is quite simple... just look here - https://vectree.io/c/spring-framework

[nh23423fefe]

> it doesn't let me look into and understand the internals easily

what does this mean? you can single step into framework code

[antonymoose]

Mostly just boils down to a Chain-of-Responsibility pattern which is incredibly easy to reason about. Just a way to compose functions.

As far as digging into internal, how often do you look into Express or Rails internals or any other? For me it’s a rare day to need to do so.

Only time I recall having to read Spring source code was when I used their Social Media Auth library sometime in the early 2010s when it was quite a primitive experience.

[ekropotin]

I’ve Been stuck with Spring for many years too and I think it’s just awful choice for micro services that need to scale, simply due to startup time.

Not to defend Nodejs ecosystem - your points are 100% valid.

With that in mind, I think Go is much better option.

[ivan_gammel]

Spring may be a bad choice for microservices (context required, because it is not true in general), but it is strange to compare it (DI framework/mvc/orm abstraction etc) with Go (programming language). Java exists in many flavors, you do not have to use Spring to build a performant microservice.

[ekropotin]

Fair enough! Indeed, there are ways to build performant microservices on Java, e.g. Qwarkus + GraalVM, but I've never seen anyone in enterprise world is doing it - 99% of services are still being build on Spring Boot, so in my mind Java in SB are inseparable.

[tracker1]

That's kind of where I stand on this too... though I'm more fond of a lot of C# than Java, I find that it's the developer ecosystem and work environments themselves that exist on so many piles of abstractions and patterns that it's often hard to even grasp the meat of what's being done over the abstractions themselves.

I've trended towards feature oriented hierarchies over type of thing hierarchies as I find they tend to be simpler, easier to replace over time and often much easier to maintain than separating DAL/BLL/SVC/VM/M/V layers etc. I really don't mind if my endpoint file sits next to my database access file, next to my validation file along with the test files for all of them in a single directory for a given feature. The feature is the concern, not the fact that you have a web endpoint, or need to talk to a database.

They're also easier to manage in a monolith and break apart as needed without having to replicate the jungle for want of a banana.

[ivan_gammel]

I bet this is happening because in many enterprise applications you do not need high performance. Requirements to a service doing 1000 transactions a day are very different from requirements to a service doing HFT. Service per bounded context may be reasonable choice and Spring Boot/Spring Cloud may be adequate solution for it.

[tracker1]

I think this is probably a large part of it... I remember working on an app a few years ago, where it was explicit that it likely wouldn't see more than 15-20 active users at any given deployment... and with the level of normalization at the database layer, and literally 95% of the logic INSIDE the database (sprocs), it was just about falling over on a modest server trying to handle a dozen users.

Worse still, is the variance and onboarding for each customer was taking roughly twice as long as the previous one... I left during the dev cycle to bring in the 4th client. These were state/county agencies, each with slightly differing requirements. I was in charge of the UI and the API for the UI... putting all the logic inside the DB itself was emphatically NOT my decision.

[re-thc]

> because in many enterprise applications you do not need high performance

Looking at and having looked at some of their cloud spend etc, nah.

To be more specific there's a lot of fat. Whether that's HFT style high performance is a different story.

[amarant]

Minecraft builds their servers using Micronaut! It's such a breath of fresh air compared to spring.

I've only ever had to debug spring DI once, I'll admit it usually works. But when it doesn't..... All those proxy objects will drive you nuts!

It's a very clever solution really.. And that's the problem! You don't want to build your servers on a clever foundation, you want a simple one!

[reeredfdfdf]

I agree. Whenever I've tried jumping into NodeJS world, I quickly get overwhelmed by the lack of obvious "right" solutions to common problems. There's no way to know which of the dozens of ORM's, auth libraries or whatever will be still around 10 years from now. With Java & Spring the choice is always obvious.

Of course there are "batteries included" frameworks for NodeJS too, but they all seem to be unstable compared to Spring Boot.

[tracker1]

I tend to defer auth to JWT token usage... you have a properly RSA signed token against a valid public key, you're in.

In terms of ORMs, I actually avoid them... I like data adapters that make writing general SQL queries easier... for C# I tend to use Dapper... for JS/TS, I'll use a template string interpreter shim over the database adapter that returns Enumerable<T>?... very similar to my usage of Dapper.

Just about the simplest things that I can do to get things going, and generally in the simplest path forward. Today, generally speaking, hono, zod, openapi with a bit of hand-wiring as described above. At least for the backend, services, etc. With open-api configured, I can generate client adapters and relatively easily integrate with an OAuth provider of my choice (often AD/Entra in practice).

I will also usually create a self-signing JWT auth for dev/testing to make it easier to be "anyone" in any role for testing... where the release application is more restricted.

[ecshafer]

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.

[tracker1]

Similar for C# in practice... I actually really like a lot of modern C#, though I use FastEndpoints as an (imo) upgrade to minimal API surface, generally with Dapper and as few layers as possible in a feature oriented structure (single project as long as possible). I had to split off some logic into a separate shared library and worker service app from the api app on the server. Client is a React SPA.

[smrtinsert]

Nothing about Spring forces you to use or engage in or use design patterns. If it does im pretty sure that's a plus. Juniors can have clear path towards being productive and feel quickly oriented.

Like sibling comment mentioned you can integrate anything with Spring Boot. Its a high productivity framework to accomplish alot. Your frustrations speak more to the job you took rather than the framework they forced you to use.

[cogman10]

Spring is such a massive framework and it definitely has parts that aren't, frankly, well done. More than once Spring has ultimately been the source of performance issues for us with the solution being to ditch spring and do things with just the JDK. A lot of those cases have been fixed, however, even in the best case spring will take something that could have been a single function call and turn it into a maze of 20 different function calls because it's handling all sorts of weird edge and corner cases that aren't applicable to your code. It also doesn't help that some things are simply bolted in which makes it even harder to understand what is going on under the covers.

It also doesn't help that it's really easy to end up bringing in the entire framework for what you assumed were single function portions of the framework.

That said, it's the framework you probably want to use if you are doing Java. Just not if you are doing fast java.

[microflash]

> I also prefer using various SaaS solutions to handle authentication and user registration rather than rebuilding it all myself with Spring Boot Security.

I'm confused. Spring Security does provide you ways to create your own auth layer. However, you can use your existing identity provider or any external provider (there are starters for many providers).

[chasd00]

> I also prefer using various SaaS solutions to handle authentication and user registration rather than rebuilding it all myself with Spring Boot Security.

i haven't used Spring in a decade but even back then Spring Security had support for all kinds of federated authentication/authorization providers and standards.

[amarant]

Java is fine, but spring boot is an abomination. Give micronaut a go and see for yourself!