The Friendly Story

In Summer 2005 I received an assignment to develop an ambitious database-driven content management system requiring dozens, if not hundreds, of HTML views and complex relationships spanning several database tables. I had just discovered Ruby on Rails and had gotten interested in agile practices and structures.

But Rails was not an option. This project—like so many I’ve worked on outside the corporate/enterprise sphere—had to be deployed onto a typical shared hosting environment, where we had no control over the configuration (other than the use of .htaccess files), no access to any folders outside the public root and no way to convince the client that they should spend the extra money to upgrade to more flexible developer-level hosting.

So we couldn’t count on shell access, Ruby, MySQL bindings, etc, so what could we count on? PHP. Plain, boring, frustrating old PHP. This sounds far more critical than it should, but PHP is the lowest common denominator among web platforms. It’s limited, overly verbose and aggressively procedural. But it also comes installed in a usable version with MySQL bindings on almost every web host in the world.

PHP code is easy to write, but using it to build well-architected, easily maintainable web applications can be challenging. While PHP can be quite powerful, that power is often hiding behind a cluttered API with 1,000+ functions, and the fact that PHP code can be embedded in an HTML document often leads to poor practices. I can’t tell you how many websites I’ve worked on, that I’ve inherited from another developer, that were a tangled mess of unnecessarily verbose code, business logic all mixed up with HTML and huge stability and security blunders.

Tossing some PHP into an HTML document is fine for something simple, like an include or simply outputting a few rows from a database. But larger websites developed that way are impossible to manage. Fixing bugs becomes an onerous process of scanning through hundreds of lines looking for an error, and forget about adding features in any kind of timely way.

PHP has hundreds (thousands?) of functions, but the average PHP developer only uses maybe a few dozen. More importantly, they use those dozen in some very repetitive ways. It’s not just that one finds oneself typing mysql_fetch_assoc a lot—it’s always the same ten-line structure where you query the database and use some loop to iterate across the result. As I began building what I then called my “MVC engine,” I started keeping an eye out for tasks I was performing over and over again, so I could incorporate them into my core framework and save myself time on the next job.

About six weeks into the project I had something that was not only making it easy to work on such a large project, but which could be somewhat easily included and reused on all sorts of future projects. My goals for this framework were to build something that was true to the nature of PHP’s simple, C-style syntax, but which provided a cleaner, more friendly environment to get real work done.

By the end of the summer that project was completed, and from that codebase I extracted version 0.1 of what I was now calling the Friendly Framework. Since then Friendly has been used in some form or another on over a dozen public websites. Projects that would have taken weeks to complete with pure PHP have taken 14 days or less to build and deploy using the framework, and the API has only gotten simpler and more powerful in the last few months.

There are other PHP-based frameworks, but many of them are designed for use with PHP 5.x and are overly complex besides. What’s more, while Cake and Symfony (to name just two) seem useful and powerful, it also seems like they work too hard to make PHP behave like something it’s not. Friendly is all about embracing constraints, because you shouldn’t have to learn Ruby and shell out for a dedicated server or VPS just to have an easier time building web sites.

David Demaree
Friendly Developer