Yea, whenever a new abstraction makes the ”you won’t have to do all these things yourself” promise, I guarantee that the abstraction just replaces those things with another, potentially bigger set of things you’re going to now have to do.

Can someone explain why Spring, or J2EE in general, is a necessity for its target audience, and for that matter, what its target audience is? I've only worked on Spring applications when I had to, so forgive my ignorance, but every time I've worked on a Spring application, I never found a good reason why Spring was necessary.

I always thought that Spring was meant for maintaining large codebases with many interconnected parts that you might want to swap out at a given notice. We can talk about whether or not Spring is a good fit for that scenario, but I at least understand why you would use it. But the applications I've worked on that used Spring were offline, single-purpose, non-changing, and (relatively) small. I would then ask why we're using Spring for this, and I basically get the same responses as the parent post with a facial expression that's pondering if I'm high.

Am I missing something?

So if you go back to the early days of J2EE, you'll notice that it was very EJB-centric - for the most part, J2EE containers were EJB containers with some extra stuff to support EJB. EJB, for the most part, was pre-ORM ORM back when object-relational mapping was a relatively new concept. There was more to it than that, of course, but using Entity EJBs for object-relational mapping was the core of what J2EE was all about.

The problem was, it was a massive unusable beast of a mess. Rod Johnson came along, found some ways to simplify the concept into a "lightweight" container and called it "Spring" as an alternative to the heavyweight EJB containers of the late 90's.

The thing that everybody seems to be missing is that the only reason you needed the container in the first place was to support the Entity EJB's that were more trouble than they were worth. Standalone ORM tools like Hibernate solve the actual entity-relational mapping problem far less intrusively than J2EE or Spring ever did (Hibernate is still more trouble than it's worth but at least you can understand why it's there).

Spring doesn't actually do anything except make other things available in Spring, and it actually damages your codebase by forcing you to make most of your variables effectively global (which Spring calls singleton beans).

You don't need Spring to maintain large codebases with many interconnected parts that you might want to swap out at a given notice. You can just create ('wire up') your objects in your `main` method.

I hated React when I had to jimmy it into a Drupal website, I loved it when I was doing React + Redux on a data-driven project.

Pre-shopify, I loved Magento when we were just building basic eCommerce websites. I hated it when we had to provide bespoke functionality to suite various niche business purposes because rarely did any of the community plugins work well together, and life became a routine of building custom intermediary plugins that resolved the conflicts - but at least Magento had a way to resolve conflicts between plugins.

I loved Doctrine when I could define my object model with simple block comments. I hated it when the client's business model enforced an object model incompatible with Doctrine's, and we had to extend Doctrine to allow for it.

I tried making a game from scratch many times over the years. From writing my own assembly pixel routines (draw a line without gaps... that's a fun challenge), to decoupling logic from rendering, custom double-buffering, etc. At the end of the day, fuck it, Unity does everything I need much more efficiently than I have the time to figure out.

Unless you're doing really low-level embedded (and even these day's there's off the shelf hardware with frameworks rather than bit-bashing IO ports), having no framework at all is usually worse than having "a" framework. Want to build an entire game engine from scratch or why not just use Unity? If you have a good reason and can justify the cost of doing the stuff Unity does yourself, just to achieve the stuff Unity can't do, then go for it!

Like I guess, I don't hate frameworks, but I don't LOVE them either. Pick the tool for the job. I hate jingoism, where someone will tell you Redux is the only way we're going from now on because functional reactive programming is Jesus, or we've decided from now on the project will use webpack, even though it's been working fine for a decade using a different build strategy. Oh and we need to convert the APIs to GraphQL instead of OpenAPI on no budget, it's your fault for not understanding best practices duh...

I had that "I hate Spring" moment a few years ago as well.

Another part of the problem is that at some point you are programming in Spring more than Java. I've even interviewed candidates who struggled to tell the two apart.

The question becomes "would I rather program in Java or Spring?" and, generally, for all its other shortcomings, I'd prefer to program in Java over Spring.