I don't know what the requirements of these sites are, but throwing out all the things you get with a framework such as a battle-hardened authentication system for "plain old PHP" hardly seems like a pragmatic decision. Was a full rewrite in a base language only really an easier/superior decision then finding more simply caching solutions (which many frameworks support out of the box)?
Yes. That's part of my job.
I don't know what the requirements of these sites are
Then anything else is just blather. I know more about my systems than you do.
Was a full rewrite in a base language only really an easier/superior decision then finding more simply caching solutions (which many frameworks support out of the box)?
Yes. For my purposes. Perhaps not for the sites you work with.
Rolling your own auth system is very likely not going to produce an auth system as battle hardened/tested as <popular framework>.
Rewriting an entire site from scratch is rarely the correct choice and is one of the most common engineering fallacy. https://en.wikipedia.org/wiki/Second-system_effect
Caching is a problem you need to solve regardless of whether you're using a framework or not.
These problems don't magically go away when you decide to rewrite these components yourself. You probably aren't going to write code as well as a community of coders that have contributed to a years-old codebase. Especially not on your first pass.
These are all pretty legitimate "what-if" questions to ask.
Still though, auth is just one arbitrary requirement I plucked from many that popular frameworks solve such as request handling, response rendering, database operations, routing, etc.
Yes, you can use a hodgepodge of libraries to solve these requirements but your argument that your codebase will be leaner than a "heavy framework" using codebase gets a bit flimsier in my experience.
Look, I'm not saying you shouldn't use a framework, every project has different needs. I'm saying that frameworks have made people lazy and they try to fit their project into the framework they know when when it's wrong.
What do you think the components in a framework are? They're just libraries, and often can be/are used standalone. I've seen no evidence that there are less bugs in a library not used for frameworks than one used for it.
> If I use the big framework, I'm stuck with it if I ever have to change my data storage method and it's outside of the frameworks normal scope.
There's no reason you can't use a different library within the framework. It's the exact same as writing from scratch, you're just doing it within the patterns of the framework instead of the patterns you've created on your own.
> Look, I'm not saying you shouldn't use a framework, every project has different needs. I'm saying that frameworks have made people lazy and they try to fit their project into the framework they know when when it's wrong.
I'm not advocating for blanket usage of frameworks either but I've yet to see a compelling reason to in this discussion thread not to.
With a framework you not only have to learn how build things in the framework (which takes a lot of time to become truly proficient) I also have to build what I am already supposed to be building.
I find personally that frameworks
* Simple things hard. Hard things simple.
* Anything outside of the happy flow they present to you in the docs is a major PITA.
* I frequently find myself scrabbling around for information when I need to override how the framework works in a particular scenario.
* They nullfy much of your pre-existing knowledge e.g. I am described at a lot of places as a JavaScript guy in the team, because I get JavaScript. When I use Angular or React, most that is irrelevant. It doesn't really help me.
If I am just using well established patterns + my existing knowledge of the programming language and environment. I can normally put something together myself that does just what I need it to do and I use a library for things like date time calculations or Ajax requests or something else that is mundane.
The only thing I'd counter to this with is when I see this approach taken, an informal "framework" of sorts tends to evolve naturally. First you write something that handles the routing, then soon you want to organize the code the route endpoints call, then you layer on the authentication at the top level request handling area, so on and so forth. Over time, as new requirements come in and new people work on the project, more and more patterns, conventions, and library are added to the codebase - pretty soon all that "glue" code meant for interfacing with libraries is reaching or exceeding the complexity of a framework based codebase (except your codebase probably has less documentation for things like conventions and patterns than a framework would).
That said, I don't think it's the wrong approach especially when the scope of the project is limited and/or there are ways to manage feature creep (e.g., frontend only, limited lifespan, internal facing apps, etc)
Because I'm in healthcare, the web sites have gone crazy in the last four months, and there are updates upon additions upon updates of the additional content over and over and over. Think 14-hour days.
The sites that have been migrated out of the framework jungle can be updated in minutes to hours. The sites that are still stuck in framework hell can take hours to days.
When things happen (for example, when another state locks down), the framework sites get slow. The non-framework sites keep zipping along, which was my main reason for moving them in the first place.
The next time you're looking at a government or healthcare web site that doesn't have the latest COVID-19 information on it, look at the source code and try to figure out what it's been generated with.