Why I write, maintain and use my own framework (and you should too)

Note: The recommendations in this post are intended for a very advanced audience. While the content applies broadly, creating and maintaining your own framework is not advised for everyone, unless you know exactly what you’re doing.

For many of us in the PHP community, our identities are as much tied into the framework we use as the language that powers our products. For better or worse, we often tie our careers to a particular platform, and we spend considerable energy on the community and culture of that platform and it’s supporting tools.

And yet, tools are fleeting, moreso than the languages that lay beneath them. Countless frameworks have come and gone in PHP. Countless more will rise, be popular, and fade away. It’s the nature of things.

This is okay. Because what matters is not what framework we use, but the underlying principles we embrace in the work that we do.

Frameworks represent an opinionated way of developing software. They represent a particular maintainer’s paradigm for how software should be, and the users (who use the framework correctly) embrace that philosophy, either out of obligation or agreement. Either way, they are adopting the opinion of that particular maintainer(s) philosophy.

And because accepted paradigms change, so do the frameworks that are in vogue.

After spending years chasing the best framework for me to use, I realized that what really mattered to me was not the “right” paradigm, but the “right” practices. And that’s when I realized that I needed to develop, maintain and use a framework of my own making, one that fit the principles I held dear, not the paradigms I found useful in that particular moment.

Truth be told, I’m a little embarrassed to even call my skeleton code a “framework”. It doesn’t implement most of its own core functionality; in fact, most of the core behaviors come from packages I’ve adopted from others. Those packaged embrace best practices I’ve found useful. My “framework” is glue code, binding those packages together in a useful, cohesive way.

This is the beauty of the day and age in which we program. It is easy to incorporate disparate packages and create something new. You don’t need to adopt the whole of any particular framework or package library. Instead you can adopt a bit from one area, and a piece from another. This was unthinkable when I started working in PHP. But now Composer makes this possible.

I’ve focused on embracing the principles and practices that are important to me, rather than opinions and paradigms of a single framework maker. And it works, for me.

At the end of the day, what matters most is that your code is readable, maintainable and correct. The popular paradigm of the day won’t matter in the long run, but readability, maintainability and correctness always will.

It’s time that we stop searching for the “perfect” framework, and started focusing instead on the best practices and how we can use them to our advantage.

I am proud to build, maintain and use my own framework.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Patrik wrote at 5/25/2016 9:44 am:

Do you try nette framework (nette.org)? I think there are many good ideas to use, and you can use its parts separately. For example template system latte have IMHO best context aware escaping. I understand some OOP principles after read this FW source and documentation, for example dependency injection.

David Négrier wrote at 5/26/2016 3:16 pm:

Hi Brandon,

Couldn’t agree more, although the glue code is definitely tedious to write. I’m doing what I can to reduce that glue code by trying to define a standard to put things in a container (that way, the package maintainer becomes responsible from a part of the glue code).

This boils down to standardized service providers, and I believe this could reduce the amount of code in your framework. I’d be interested to gather some feedback if you have some time to look at it: https://github.com/container-interop/service-provider

Caryn wrote at 5/29/2016 11:45 pm:

Its more of a concept, instead of looking up to others, of using there work and not your own. For example if I said, look guys I made a framework thats like laravel but does x and y simpler, nine times out of ten the communities reaction will be “dont re-invent the wheel, use whats out there”

Copyright © 2023 by Brandon Savage. All rights reserved.