Comment by reaperducer | Hacker News Reader

Comment by reaperducer | Hacker News Reader

Parent Full thread

I currently maintain nine web sites, internal and customer-facing. For the last two years I've been migrating them off of the framework-go-round into plain old PHP→HTML + CSS + minimal JS where there is no other option.

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.

So you profiled the sites enough to understand that the actual bottleneck for these sites was the framework CPU/memory overhead?

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)?

These are the kinds of what-if questions that scare people into using the most popular framework-- well, what if security isn't as good? What if it's not properly cached? What if the rewrite is hard? What a load of bologna.

No, it's not a load of bologna.

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.

You don't need to use heavy frameworks for auth, it's not a choice between rolling your own and using a huge framework.

The original poster said "plain old PHP" so without making assumptions I am taking that statement at face value.

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.

Maybe not leaner, but you'll understand it better.

Why would you understand a mix-match of libraries better than a framework? You have to learn their interfaces either way to use them.

You'll understand your code better and the limited scope of the libraries allows for less bugs in each component and easier migration later if needed. 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. If I use a separate library, I can change over to whatever I need.

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.

> You'll understand your code better and the limited scope of the libraries allows for less bugs in each component and easier migration later if needed.

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.

I guess we'll both just do what we like then :) you have a fair argument.

Because each library does one thing only and it is easy to understand that particular abstraction.

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.

I think this is a pretty succinct counterpoint. I especially agree the sunk-cost of investing time learning a framework isn't something to take lightly.

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)

Very good comment!

So you profiled the sites enough to understand that the actual bottleneck for these sites was the framework CPU/memory overhead?

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.

Sorry, but I'm extremely skeptical that rewriting a framework based codebase into plain old PHP is ever a good idea. I've maintained too many legacy (mostly PHP) codebases in my career where the creator thought he knew better than everyone else to think otherwise.

Reply on news.ycombinator.com