Hacker News Reader

Comment by debaserab2 | Hacker News Reader

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.

View on HN

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!

Reply on news.ycombinator.com