The problem isn't the tool or the dependency—it's the developer's temptation to over-engineer. We grab a framework because we lack the discipline to keep something simple. Is self-control in coding just a lost art now?
Yes; a lot of people don't code because they need to make something work, they code for the joy of it. When the software they need to write is boring or solved - like another CRUD app, front- or back-end - instead of picking the boring and easy to build and comprehend languages and frameworks, they will make it interesting for themselves. Learn a new language, framework, or design paradigm; follow whatever is trending at the moment, etc.
A lot of new software is over-engineered from the start. A lot of that is cargo cult as well, e.g. big companies use microservices in their custom k8s cluster, therefore we should use microservices in our custom k8s cluster too.
> they will make it interesting for themselves.
Things like Wordpress sound super simple - you don’t even need to code!
But you do need to worry about managing an entire Apache server, managing a crappy database, hardcoding bullshit in PHP, cronjobs, cloud deployment and the fact that almost all “features” of it like plugins and themes etc are massive security vulnerabilities
I think the pitfall to avoid ITT is that there’s a single source of maintenance effort - there are likely many!
I was mainly providing an alternate example to “over-engineering is the only source of complexity” train of thought this thread largely has
If you can "make a website" by using a third-party provider but instead you opt into running wordpress on your own, you are still over-engineering.
I grab a framework to also keep my skills relevant, especially if I'm not practicing them in my day job. If I didn't have that impulse, I'd keep it simple all the time. I'm really good at it, because I really dislike complexity as it requires me to remember more things and I don't really like that feeling.
I'll optimize if I absolutely have to.
Not that businesses ever cared about this attitude. I mean, I've seen it work. The work that I do with LLMs is quick and pragmatic. No need to put stuff into production when it's just a prototype. No need to use a framework if gluing an LLM with some Python code and a well crafted prompt produces the result we need. It allows me to ship in days, not weeks. Obviously, if one then wants it productionized, additional work needs to be put into it and possibly the code needs to be refactored. But, in my opinion, that's the time and place where that type of stuff should happen.
As a rationalization, sure, but never as the reason.
They do offer more than coding standards.
For example, you work with ORMs and then you see all the problems with them as you maintain the project, so on your next app you create an app that is raw SQL. Then after maintaining that for awhile you start to see all the pitfalls of that approach and why people created ORMs in the first place. Then someone mentions the latest and greatest ORM that promises to be better this time and you use it, saving you from raw SQL you'd jumped to last time....ad infinitum.
I have no problem with sql but an ORM makes what I know about sql very ugly.
This means I treat every project like a letter to my future self that needs to be 100% self explainatory and work even if the environment around the project changed. And this means as few moving parts as possible.