My previous post, The MicroPHP Manifesto, resulted in much excitement. In between fits of rage and crying, I found some time to answer folks questions, and also discuss the topic on the /dev/hell podcast with my cohost Chris Hartjes. To summarize and address some of the common questions, I felt I should write a small FAQ.
Got a question? Ask me. I’ll add additional entries here as things come up.
No. I think sometimes they’re very appropriate. It depends on your needs: will the pros you get with library/component/framework X outweigh the negatives? If so, it’s probably a good choice. If not, it’s probably not.
Sometimes you do. My experience at FictiveKin has been that our small team is able to work faster, smarter, and more efficiently by minimizing the size of our PHP codebase and removing all unnecessary layers of abstraction. In some cases that meant not doing certain tasks in PHP anymore (almost all HTML generation was moved to the browser). In others, it meant ripping out a bunch of code and replacing it with a simpler solution that required far less boilerplate and replication. We still kept some code that had more dependencies than we’d like because the wins we get with it outweigh the downsides.
I’ve certainly seen situations where choosing a popular full-stack framework is a better idea. As teams get larger, enforcement of coding standards and not doing Dumb Shit becomes harder. Hiring and training engineers is usually easier with popular, full-stack frameworks. On the other hand, we’ve found that devs coming from non-PHP backgrounds liked how quickly they can be productive with simpler libraries and frameworks. Your mileage may vary.
Good God no. There is lots of very good, well-written code out there that’s already solved the problem you’re facing. Most of the time I don’t want to try to solve an issue like oAuth request signing, because it makes my brain hurt and I’d rather focus on building stuff. So, I’ll look for an existing solution that fits my needs first. I sometimes choose to write something from scratch because the existing solutions (that I can find – discovery is a whole other issue) don’t fit well with my existing application structure, or I feel it will introduce more maintenance issues than I’m comfortable with.
Sure. Generally I think people should work on writing libraries/components, personally. We have plenty of framework choices. But this is PHP, so you have to write your own framework sometime.
Long answer: I tend to believe that the reference implementation of “microframework” is Sinatra. Routing, request/response objects, sessions, maybe some hooks for template rendering. Generally I think the inclusion of an ORM is a clear sign of non-micro-ness.
Short answer: I don’t care, really – and you shouldn’t either. If it works for you, awesome.
Generally I think about these things:
None of these are hard and fast rules, though. I encourage people to share things with me they think others would find useful.
I don’t. I like some of their songs, but don’t own any of their work. I also think they’re incredibly smart, talented musicians. My point was to suggest there are other valid approaches, not to reject complexity outright.
Update 2012-01-06:
Update 2012-01-04:
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 “rock” –– 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:
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 “microframework.” 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 “lightweight” 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.
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
-------------------------------------------------------------------------------
Here’s the same for the Slim framework:
Mon Dec 26 19:42:27 EST 2011
coj@PsychoMantis ~/Sites > cloc Slim
54 text files.
51 unique files.
13 files ignored.
cloc.sourceforge.net v 1.53 T=0.5 s (82.0 files/s, 17752.0 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
PHP 31 660 4473 3280
Bourne Shell 10 56 155 252
-------------------------------------------------------------------------------
SUM: 41 716 4628 3532
-------------------------------------------------------------------------------
and the Epiphany framework:
Mon Dec 26 19:42:30 EST 2011
coj@PsychoMantis ~/Sites > cloc Epiphany
83 text files.
70 unique files.
31 files ignored.
cloc.sourceforge.net v 1.53 T=0.5 s (102.0 files/s, 5246.0 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
PHP 40 218 309 1632
Bourne Shell 10 56 155 252
HTML 1 0 0 1
-------------------------------------------------------------------------------
SUM: 51 274 464 1885
-------------------------------------------------------------------------------
When there are more files and lines of code in your component than in my entire base framework, I can’t call it “lightweight.”
It doesn’t mean that stuff is bad, in the grand scheme of things. It doesn’t mean it has no value or is the wrong approach for many. But it’s the wrong approach for me, for sure. And I don’t think I am alone.
I don’t want to be the prog rock superstar, writing a pretentious rock opera. I want to play shitty power chords in a punk rock band that plays shows in a VFW lodge with no stage, and leaves you so fucking pumped that you go out and form your own band. That’s the coder I want to be.
I don’t want to be Neil Peart. I want to be Gregg Ginn.
So I wrote this. A “micro PHP manifesto,” if you will. I plan to use it to guide my PHP dev. Maybe you will find it useful as well.
I am a PHP developer
I like building small things
I want less code, not more
I like simple, readable code