PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

The MicroPHP Manifesto

Note: This article was originally published at Planet PHP on 17 April 6800.
Planet PHP

The standard line about the history of Punk is that it was a reaction to the excesses of modern rock, particularly progressive rock of the time. The reality is undoubtedly more complex, but I suspect there is some truth to that. Rock n roll did seem to be the realm of Golden Gods in the late 60s and 70s, inaccessible to average folk. The contrast between bands like Rush and Black Flag -- both supposedly playing aorocka -- was extreme.

For fun, let's take a look at Rush drummer Neil Peart's drum kit:

Now, here's Black Flag playing in LA in 1979:

You can fit the entirety of Black Flag in the space of Neil Peart's drum kit. And they would still play awesome shit and rock you the fuck out.

In the past few years, the PHP Zeitgeist seems like it's been moving in the Neil Peart direction. Lots of work by lots of smart people is going into complex, verbose solutions. Lots of files, lots of nested directories, and lots of rules. I frequently see PHP libraries/components that look like this:

https://gist.github.com/1555472

All that, just to start your application.

It doesn't mean this approach is bad, per se. But when I see it, I have a visceral negative reaction. My brain screams

FUCK.

THAT.

SHIT.

I can't do it. I don't want it. And I don't think we have to do it this way to do cool things and build awesome stuff.

The approach I've been taking lately is to start with as lightweight a foundation as possible, in the form of a aomicroframework.a A few of these exist for PHP (of course), including Slim, Epiphany, Breeze, Limonade, and others. For additional functionality, I pull in lightweight libraries that help me accomplish only the tasks I need. Clarity and brevity are my top considerations.

My other big consideration is the commitment I make when I use code I didn't write. Typically I don't have time to do a full code audit on libraries, so there's a level of trust that goes with it. And each dependency means more trust. Not just that there aren't bugs (I expect that if they're anything like me), but security issues - both whether they exist, and how they will be handled. Will an announcement go out to a mailing list? How long will security fixes be provided that don't break backwards compatibility? Will I have to upgrade all my dependencies if I upgrade to the next PHP point release? And all of that assumes the author will have the time and motivation to provide prompt fixes. If they don't, you've just added a bunch of technical debt to your codebase.

Finding lightweight libraries that don't pull in lots of additional code dependencies is much harder than it should be. Mostly I think that's attributable to PHP devs being more interested in framework-specific development. Some work is being done to make mature frameworks less monolithic, and many devs on Twitter have recommended Symfony components as an option. Unfortunately, I think my definition of aolightweighta is not the same as theirs.

Here's the cloc output for a git clone of the symfony2 HTTP Kernel component:

Mon Dec 26 19:42:23 EST 2011 coj@PsychoMantis ~/Sites cloc HttpKernel 94 text files. 93 unique files. 12 files ignored. http://cloc.sourceforge.net v 1.53 T=0.5 s (164.0 files/s, 18736.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- PHP 72 1175 3440 4290 Bourne Shell 10 56 155 252 ------------------------------------------------------------------------------- SUM: 82 1231 3595 4542 ------------------------------------------------------

Truncated by Planet PHP, read more at the original (another 4020 bytes)