Unless one's need is trivial or very specific to a narrow scenario, frameworks are helpful. At the least, they give new devs a common understanding to begin from when they join or take over an existing project.
I've been working with Java for 20 years now, and Spring is the ultimate "framework" - it's so framework-y that it doesn't actually do anything or offer anything, it's just a thing that gets in your way. When people defend Spring, they invariably say "but why would you want to do all of that by yourself" and I say "do all of what by myself?" The Spring framework saves you the trouble of... calling the "new" operator (by making everything a global variable)? At least with an ORM framework I can see what it actually does, even if I don't really want it to do that, but Spring just doesn't do anything except add libraries you don't need and make your stack traces useless.
Ok, I take it back, I don't hate frameworks, I hate Spring.
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?
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).
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...
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.
I also reject the idea of "They either use an existing framework, or they eventually end up creating a custom framework which only they understand and which gets thrown out and replaced with a common framework when they leave the company". The popular open-source frameworks were created by people like you and me. Those people were good, for sure, but not perfect, just like us. They also often try to make something very generic that may not fit your specific use case. Trying to bend a framework to do something it's not meant to isn't better than writing your own code.
I think that these days we have too much worship of open source code. Sure, not having to write code is sometimes very nice, but sometimes a few lines of code can help you avoid a dependency.
Of course, the bigger your codebase and the more unique your needs, the more reasonable it becomes to create your own.
No, it's not.
> Use an existing one , or write one that only you (and your team) know.
Not only my team, pretty much any people working with it in the company. The difference with something like Django is that people don't know it before coming in the company, which doesn't make a big difference.
To go back to the message I replied to, you said
> "They either use an existing framework, or they eventually end up creating a custom framework which only they understand and which gets thrown out and replaced with a common framework when they leave the company."
I disagree. There's no reason to replace our custom framework, as it's working well and since the codebase is getting a bit old, this would be just too much. We also have good training material around it, better than what you can usually find about open source framework online, without even mentionning mentoring. Then there's
> "At the least, they give new devs a common understanding to begin from when they join or take over an existing project."
The flip side of that is that you need to recruit developers that know a framework, which will by definition limit your talent pool.