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.
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!
If the problem you are trying to solve is "I need to put content online and have a storefront for my product", there are plenty of hosting providers who will happily take care of all the headache from Wordpress for less than $10/month.
> We grab a framework because we lack the discipline to keep something simple.
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.
For me it's more like I bounce back and forth avoiding the pains from whatever the last project was using. Same with front-end frameworks vs vanilla JS etc.
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 make choices one of that is build a website in php. I do things from scratch so it involved learning the server, the setup (security/docker/podman), the stack (php/js/css/html). My limits made me do things. The code was and is ugly. Everything is a mess. There is no routing my URLs are pretty because of nginx rewrites. My limits make design choices like no user data because I cannot be sure about security. Once it is up and running you look at things like bootstrap to learn basics of css. Then you want it all gone because you learned the way of css.
I have no problem with sql but an ORM makes what I know about sql very ugly.
Not for me. But I am in the unique situation of sometimes having to spin up 12 projects a week only to come back to two of them 5 weeks later unpredictably.
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.
I intentionally avoided using a framework mainly to keep my code simple, and because the framework was too inflexible and I could not achieve what I wanted to.
So you then ended up building your own half baked of a … wait for it … framework, without even realizing it. Nothing wrong with that, it can be fun - just depends on if your goals are shipping or playing around.
Yes I did, but it serves only one purpose, it is not a general framework, and it is much more minimal. The "framework" is not intended to be used by anyone. The project is, but not as a dependency.
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.