Why I still use and maintain my own PHP framework

I consider myself a PHP developer first and foremost. I don’t tout myself as a
Pickles developer (my own framework) or a WordPress, Laravel,
CakePHP, Django, Flask or Meteor developer even though I have working experience
with all of them. At the end of the day those frameworks still require that you
have a core understanding of the language it’s built on.

That all being said, I’ve been asked more and more frequently why I still use /
maintain my own framework. Quite frankly, I’m a little sick of the question
because the short answer is “because it works and I can work quite fast with
it”. Not to mention that it’s been used to build platforms that have scaled to
tens of millions of monthly pageviews as well as handling a millions of dolllars
of monetary transactions a year.

Sadly, this answer tends to be negated due to the fact that there are larger and
arguably better maintained systems out there. I don’t deny that these systems
exist nor do I feel like I’m missing out too much because I still leverage the
myriad of packages out there via composer, npm or pip when developing
something myself isn’t practical from a time investment or learning curve
perspective.

On top of being asked “why?” so often, I’ve also had my skillset put into
question due to the fact that I have developed my own system. For me, having my
own framework is simply a way for me to set my own knowledge and best practices
into motion while still allowing me to do what I love to do, which is to code.
Having my own framework doesn’t make me any less of a developer because at the
end of the day, I have a strong working knowledge of the language itself.

One valid point regarding all this came from Ryan Parman who pointed
out that it seemed like I write quite a bit of small libraries that already
exist. To his point, he got to see my GitHub when I was breaking my
framework apart and was thinking of keeping those components around just for
posterity’s sake. Keep in mind that my framework actually predates many of the
modern frameworks and PHP package management as a whole. Truth is, I sorta have
a code hoarding problem. Since that conversation I went through each of those
libraries and found existing packages that provide the same (if not more)
functionality. Blog post to come on that 😉

In regard to being so reliant on leveraging third-party code, I wonder about the
code quality of these seemingly blind inclusions. Just because something has
already been written doesn’t mean it’s the best code out there. Let’s be honest
here, the package management systems out there are pretty unregulated and full
of noise / duplicate packages. You can go with the package that has the most
downloads but that guarantees nothing.

WordPress plugins are a prime example of this. More often than naught WordPress
installations are compromised not due a flaw in the core but because of a faulty
plugin. The plugin makes your day easier and saves you time, but if you don’t
take the time to understand / review the code you could be setting yourself up
for disaster. This obviously can change with the popularity of the project, the
more eyes the most likely issues are to be uncovered and patched.

For the record, even though I’ve had my skills put into question, I’ve never
once been asked to code something in a specific framework on an interview. Most
companies that are doing a good job vetting candidates are interested in your
ability to problem solve and actually code a solution, not do a composer
install
on an existing library. So yeah, who fucking cares if I continue to
hack on my pet project?

Josh Sherman - The Man, The Myth, The Avatar

About Josh

Husband. Father. Pug dad. Musician. Founder of Holiday API, Head of Engineering and Emoji Specialist at Mailshake, and author of the best damn Lorem Ipsum Library for PHP.


If you found this article helpful, please consider buying me a coffee.