A “web application framework” is a bundle of code that is suppose to help web designers/programmers build web sites. The framework usually takes care of some setup tasks, and helps make some complicated tasks easy. At this point in time, the framework receiving the most hype is Ruby on Rails. As the name suggests, it is a framework written in the Ruby language. Ruby on Rails is a very elegant system that demonstrates great care of thought in every aspect of its design. Here at Category 4, we will start using Ruby on Rails in the near future. However, most of the programming work we’ve done during the last 6 years has been done in the PHP language, and we will probably be using PHP for years to come. Therefore, we’d like to find a PHP framework that is as elegant as Ruby on Rails.

There are a lot of web frameworks written in PHP. I’d guess that most of them are junk and that a few of them are gems. That is the way of things in most creative endevours (I’d say the same of music, or of films - most are junk, a few are gems) It is impossible to tell from their names or feature sets whether they are well designed or whether they are disasters.

A few of these are ones we’ve had personal experience with. I tried PHP-Nuke. The template system was impossible. A great deal of HTML was hard-coded in the PHP code, forcing programmers to do work that designers could do better. A co-worker of mine tried CakePHP, but found that it simply didn’t work on our servers.

Given the vast number of frameworks to test, I’ve asked for other people’s experiences. I asked what were some good frameworks and a fellow who goes by the handle “NC” replied:

None. The best framework is no framework. Frameworks help developers quickly and cost-effectively (with “cost” meaning “development cost” rather than “total cost of ownership”) develop resource-hogging software, so they should be avoided in all instances where performance and scalability are important.

What he’s really saying, with a bit of hyperbole, is that most frameworks are bad and need to be avoided. I’m sure it’s true that most frameworks use up more resources than they need to. And I don’t doubt that most frameworks are badly engineered. Still, as Tony Marston pointed out on that thread, it is usually more important for web design firms to save developer time than to save CPU processing time. We’ve got plenty of processing power, what we lack is unlimited programming time.

Most of these frameworks are doing a hideous job of marketing themselves. Looking at their sites makes me realize what a masterful marketing job David Heinemeier Hansson has done for Ruby On Rails. Hansson seems to understand what I need to know before I’ll give his framework a try: I need to know the framework’s philosophy. Hansson sums up the Ruby On Rails philosophy in a series of pithy one-liners: “convention over configuration“, for instance. “Optimize for programmer happiness, don’t optimize for machine happiness” is another. These slogans give me a sense of what kind of projects I’d use Ruby On Rails for - rapid iteration projects, projects that will have a lot of programming, and where I need to save developer cycles, not CPU cycles. I wouldn’t use Ruby On Rails for a simple site that is mostly flat files with just a few conditional includes. “Optimize for programmer happiness” assures me that Rails might be needlessly expensive, in terms of performance, for a mostly flat site.

Most of the PHP frameworks advertise their feature set rather than their philosophy. This is bad, because it forces me to actually use the framework to find out if I agree with its core assumptions. This is a huge drain on time and limits the number of frameworks that I’ll be able to test. I’d rather simply be told up front what the core assumptions are.

Consider this supposedly “explanatory” text on the front page of the CakePHP site:

Cake is a rapid development framework for PHP which uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. Our primary goal is to provide a structured framework that enables PHP users at all levels to rapidly develop robust web applications, without any loss to flexibility.

This text gives me information, though not the information I need to determine whether I agree with CakePHP’s core assumptions. This text assures me that the team that is building CakePHP has tried to use design patterns to sovle well known design problems, but it doesn’t give me a sense of how they handle edge cases where they have had to make hard choices. They use MVC - okay, but is the template system friendly to programmers or friendly to designers? Does the controller get in the way of the designers?

Also bad is BinaryCloud:

The centerpiece of this framework is the presentation system (Node Tree), which enforces a strict separation of your business logic from your presentation logic. The Node tree uses a unique, hierarchical scale free object design that is extremely powerful because applications can be arbitrarily infinitely nested. The Smarty template engine is the default rendering layer and is tightly integrated into binarycloud.

Now, by luck, I’ve had experience with the Smarty template system, so this paragraph does actually give me useful information. I found the Smarty system to be too rigid and to introduce too much complexity for no gain that I could discover, so this convinces me not to use BinaryCloud. But if I didn’t already have experience with Smarty, then this paragraph wouldn’t tell me much. It says it enforces a strict separation of business logic from presentation logic, but all frameworks say that, and it doesn’t say how, or why, or what tradeoffs it made between competing design demands.

I need to know the tradeoffs!

The Seagull project makes the same mistake as the others:

Seagull offers the following key features:
* PHP 4/5 compatible
* compact core framework with basic CMS and other modules included to get you started
* ease of use: learning curve not as steep as other frameworks
* enterprise ready, performance conscious design
* tight integration with PEAR libraries, great for prototyping complex projects
* integrated ORM for RAD
* highly configurable, easy to integrate with 3rd party code
* community support: the project enjoys participation from a large and active developer community, want the documentation in Chinese, looking for Seagull devs near you?
* loosely coupled components, use template engine of your choice, output to multiple devices or CLI
* staying power: started in 2001, the Seagull project has been steadily growing in popularity and now enjoys international recognition

This sounds great, but what can’t it do? Surely the designers had to favor some set of design considerations over others. I’d have a clearer sense of what this framework is about if they told me what it’s limits are. For instance, it says it is highly configurable, does that mean I’ll have to waste a lot of time configuring it, or does it come with a lot of preset defaults? If it does have a lot of defaults, what sort of situations do those defaults assume? It says it is enterprise ready, should I then assume it is complete overkill for a small site? It says it has tight integration with PEAR libraries, does that mean that it fails to work unless I install PEAR?

I’ll say it again:

I need to know the tradeoffs!

CodeIgniter does a slightly better job of giving me a sense of what kind of situations it is optimized for:

Designed to enable, not overwhelm, Code Igniter is a powerful PHP framework with a very small footprint, built for PHP coders who need a simple and elegant toolkit to create full-featured web applications. If you’re a developer who lives in the real world of shared hosting accounts and clients with deadlines, and if you’re tired of ponderously large and thoroughly undocumented frameworks that require rocket science to understand, Code Igniter might just be the right tool for you.

Ok, so it sounds like it is optimized for shared hosting accounts. It sounds like it is for small scale sites. There is still too much marketing jargon (in the worst sense) in that paragraph, but at least the “shared hosting” line gave me a concrete example of where I might use this.

PHP frameworks have been a frequent discussion topic on comp.lang.php. Peter Fox did a wonderful job summarizing the problems with most of the existing PHP frameworks:

There are certainly some clever things going on but IMHO I’m not sure if there is anything mature

“Works” is the first problem. I’ve had another go at frameworks recently and they don’t work out of the box, documentation is poor to non-existent, support is patchy and there is still a lot of development going on.

“Does what you want” is the second problem. Even if you can get the framework to take your spec and spit out something, is it really what you want or close enough to make a start hacking by hand.

“Hackable” is the third problem. Is it possible to tweak the results to achieve your goals? Does it require weeks of study (without documentation) to work out how to make changes in the right place.

My quest to find good frameworks arose from the fact that I found myself developing my own, and I realized that there were so many open-source frameworks already in existence, I was probably repeating work that others had already done. So I set out to find the open source framework that was like mine. And, to my disappointment, I found that most of the frameworks have explanatory text that is completely opaque. The text gives me no clue if the framework is like mine or not. The explanatory text doesn’t let me know if the tradeoffs they are making are the same as the tradeoffs that I am making.

If I were to describe the framework that I started to work on, I might have listed the assumptions and tradeoffs like this:

1.) The designer is the client - we optimize for designer happiness.

2.) Minimal programming - whatever can be left to designers should be left to designers.

3.) “Scaffolding” for non-programmers - the system should allow non-programmers to do most of the set up work.

4.) The framework should be useable in other frameworks.

5.) Simple coding is preferable to perfect coding (thus simple functions are better than object oriented code).

6.) Adding new code needs to be drop-dead simple.

7.) Novice programmers should have an easy time picking it up.

8.) Optimized for small sites (where “small” means “can fit on one web server”)

9.) The framework is for building custom content management systems, therefore no assumptions should be made about logging or security.

10.) Templates should be transparent to designers - plain HTML pages with embeded PHP commands will be preferred over systems that create the whole page from inside of the PHP code.

To elaborate on #1 -

The designer is the client. In this model of web development, the web designers serve the needs of the client, and the programmers serve the needs of the web designers. Unlike Ruby On Rails, we are not optimizing for “programmer happiness”. We are optimizing for designer happiness. The template system should be whatever system the designers think best. It needs to be based around the PHP include() function, because many designers regard the include() as their best friend. Variables shouldn’t be used in the include statement, because variable includes tend to be opaque to the designers. Darren Hoyt, our lead designer, recently suprised me by saying that he liked the fact that conditional statements were clearly visible in the templates in Typo. I thought that designers would hate seeing that much code in their templates, but actually they seem to like the transparency of being able to see what is really going on. It isn’t code that they hate, it is obscure code that they hate. If they want to edit a file that is being included() but they can’t figure out what file it is because the include is a variable, then they are losing productivity. And this happens, often, with some of the PHP software we’ve used in the past.

Something like this:

if ($_GET[”category”] == “shoes”) {
include(”shoes.php”);
} else {
include(”all_products.php”);
}

is preferable to this:

include($fileCatShow);

because in the first example the designer can see the names of the files being included, and so has an easier time figuring out what they need to edit to get the design the way they want.

Designers have emphasized to me that they prefer one page templates, with every optional variation on that template being done as a conditional statement. That is, apparently, easier for them to manage.

To elaborate on #2 -

Minimal programming. Few of the frameworks I’ve seen take into account the real-life economics of web design. Designers are generally paid less than programmers, therefore a framework should strive to maximize what work is left in the hands of the designers, and it should minimize programmer involvement. I’ve seen shops where the designers always have time on their hands and the programmers are always over-worked, and often the designers have time on their hands only because they are waiting for the programmers to get done with something. This is wasted money (or increased cost for the client, if you bill it). When it comes to web design, programming is the most common production bottleneck, therefore, it should be minimized. A framework that doesn’t get in the way of the designers is a framework that reduces costs for the client.

The other advantage of minimal programming is that the system can be easily understood by people who are newly hired. For instance, someone with a little experience of web design can probably understand this:

<div id=”navigation”>
<p><a xhref=”index.php” mce_href=”index.php”>Home</a></p>
<p><a xhref=”shoes.php” mce_href=”shoes.php”>Shoes</a></p>
<p><a xhref=”all_products.php” mce_href=”all_products.php”>Other Products</a></p>
If ($_SESSION[”logged_in”] == true) {
print “Welcome back!”;
}
</div>

but this would be more opaque:

$tmp->render(”html”, “div”, “navigation”);
$tmp->session->userMessage(”welcome”, “default”);

This second example is more object oriented and therefore, in the minds of many programmers, more theoretically correct. But is it correct for the real world economics of web design? How well newly hired designers can learn a system is an important test of any framework. If a framework shifts work from designers to programmers, then it is raising costs for the web design firm. If it does that, then what is the point?

This is my biggest concern with Ruby On Rails: It makes a programmer mandatory. That makes inappropriate for a large category of web sites. What I’d like most is a simple framework that offers some templating functions to the designers, and which gives programmers an easy path to add more code, but which doesn’t make programming mandatory. Most designers I know can install WordPress with no help from a programmer. I’d like a framework that is that easy to install.

To elaborate on #3 -

“Scaffolding” for non-programmers . At a lot of web design firms the project managers do the job of collecting from the client what information needs to be stored in a database. (We could say “the programmers are not in charge of the data model, the project managers are”.) If the client is a real estate company, then, for instance, the project managers, during their consultations with the client, will figure out that we need to have a database table that stores information about houses, and that for each house we need to know the model, square footage, how many bathrooms, how many bedrooms, the size of the kitchen, the street address, and possibly the name of the neighborhood, or distance to some major urban center.

The project managers then give this information to the programmers, who establish the tables in the database and begin coding. Ruby On Rails has a “scaffolding” system that automates the creation of the forms needed to interact with the database. However, a programmer is needed to set this up. Symfony, which may be the best documented of all the PHP frameworks, has a terrific “scaffolding” setup, just like Ruby On Rails. However, this too requires a programmer.

There is no reason why we can’t have a “scaffolding” system that needs only a few clicks of a button to set up. We need a framework that automates as much work as possible, and empowers non-programmers to do as much of the work that programmers might otherwise do. This is simple economics. Dreamweaver has allowed some designers to do good (or at least “accepted by the market”) quality work without learning HTML. Ideally, in the same way, we could build a scaffolding system that helps with the setup of the database tables and the forms needed to interact with the database. Phillip Greenspun, in his book on web publishing, insisted that non-programmers can and should define the data models for their websites. Greenspun insisted that to establish a data model all that was needed was the ability to think clearly about what data needed to be collected. The actual code that’s needed to turn clear thinking into a working, database-driven site is the kind of thing that can be automated and hidden from the user.

To elaborate on #4 -

The framework should be useable in other frameworks. The framework should be thin, not much more than a collection of code I’d like to reuse with all my projects. The framework should have no dependencies outside of core PHP 4. The framework should not use constants, and it should avoid global variables. The only configuration needed should be the database connection info. The framework should have an easy way for other programmers to add in whatever code they want to, including whatever custom code they may want to use for their personal projects. To achieve these goals, a single include() statement should be enough to include the framework on any page. There will be only one global object, it will be responsible for including all other code. The other code will be included only on an “as-needed” basis. We must never include code merely to satisfy the requirements of the framework (save for the one global object we already mentioned).

Ruby On Rails has popularized the idea of favoring “convention over configuration” but some people have argued that this idea only helps when you’re dealing with a green field project. I tend to agree with that. An established web design firm will get a lot of its work from existing clients. The projects won’t be start-for-scratch projects. They’ll be extensions of existing projects. A framework like Ruby On Rails is of no use in such a situation. Ruby On Rails is a demanding framework - it wants to own the whole show and you have to obey its dictates to use it. For most of my work, I need a framework that is much less demanding than that.

To elaborate on #5 -

Simple coding is preferable to perfect coding. In theory, object oriented code is more flexible, over the long term, than code that only uses functions. In theory, object oriented code is easier to maintain and extend. All the literature on design patterns describes solutions to classic design problems using object oriented code. Nevertheless, object oriented code forces new hires to learn more about a system before they can make a change. Of course, functional code can be just as obscure as OO code. The goal here is to write simple functions that don’t depend too much on other functions - so that when new programmers take over a project, they will have an easy time figuring out how to change the code.

To elaborate on #6 -

Adding new code needs to be drop-dead simple. It should be “hackable” in the sense Peter Fox uses above. In some frameworks the only way to add new code is by adding a child class of some built-in base class. Most code added to a Ruby On Rails project is added in this way. If I’m building a site that needs vast built-in functionality, this can be a time saver. But most of the projects I work on are simpler than that - I just need to give the designer a very simple way of getting information out of the database and have it appear at a certain point in their template. I want to be free to write a quick 7 line function, perhaps called “getAllHouses”, drop it in a bin that holds all code, and send and email to the designer that says:

“Hey, wherever you want the listings from the database table ‘houses’ to appear, drop this line:

<?php getAllHouses(”each_house.htm”); ?>

(Here, each_house.htm would be a file that gets included() once for each house, and the designer could edit each_house.htm to control how the output looked.)

To elaborate on #7 -

Novice programmers should h ave an easy time picking it up. This dovetails with making designers happy. Most designers eventually learn to use a few simple PHP statements, like include() and if(). Experienced designers become, in some sense, novice programmers. As much as possible, the code should be written so beginners can read it. This also would allow a web design firm to get useful work from programmers who are still learning the ropes. PHP is a simple language and a great one for learning how to program in general. There will always be lots of beginners. Smart companies will find ways to get useful work from them, and one way is using a framework that is friendly to beginners.

To elaborate on #8 -

Optimized for small sites. Many of the frameworks seemed optimized to tackle the toughest problems in computing, such as how to serve a website from multiple servers at once, yet keep the site, and the session info, consistent for each user. I’ve never worked on a site that big and I doubt I ever will. For me, a big site would be a site that needs a whole web server all to itself, with its database on another server. That’s the biggest kind of site I expect to have to handle in the near future. If we skip ORM and other speed killers, and commit to MySql and simple functions, then one could handle a rather large site with just one server and a separate database server. And that is the biggest site that I need my framework to work for. More common, for me, are sites that are sharing a server with many other sites.

To elaborate on #9 -

9.) The framework is for building content management systems, therefore it does not have to be a content management system. Many of the frameworks I’ve looked at advertise that they have a built-in user system or they do automatic logging or they use XSL to create HTML, or the manage the use of style sheets and Javascript and images. User systems, logging, XSL, style sheets, Javascript and images are all things that should be left to the individual CMS. It might be different for each project. I’d rather not build these assumptions into the framework. The framework should be more general than that. (All the same, we might find that we do certain things the same for every project. If so, then we might develop a standard CMS that we use for every project.)

I’m possibly on thin ice with #9 since a lot of people like tight frameworks. Our lead designer was impressed that every site built with Ruby On Rails has exactly the same directory structure. I think if that is preferred, then people should use Ruby On Rails. It is perfect for what it does. The PHP framework we need is one that can be integrated into pre-existing projects, which are certain to have diverse directory structures.