I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

Can you use PHP without frameworks nowadays?

  • submit to reddit

Initially I thought the answer was a big "No, you are in the stone age."

Then things started changing.

The PHP community mindset

For example, I met Ilia Alshanetsky, a contributor to the PHP core, at the PHP Barcelona conference in October.  He said he's not considering frameworks in his work. I don't know if he meant going procedural or only avoiding incorporating frameworks as external code, but that's a start.

The costs of frameworks

In the same days, I attended Matteo Vaccari's talk at Webtech 2010. It was in Italian, but the translation would sound like Framework-free web programming. The context was the Java platform, where frameworks are even more invasive than in PHP.

In that talk, I learned some interesting points which are often overlooked while considering frameworks adoption, delighted by the hope of writing less code.

  • Learning curve and lock-in: you have to work for a certain amount of time with the framework in order to become accustomed to it; then you'll find difficult to come back as you have invested a lot of time (which is money) and lines of code into that framework. I developed my Bachelor's thesis with SMILA, a Java framework for search applications, and half of the time went away to get it to work.
  • Upgrading and version management: frameworks are similar to libraries, and they have to be upgraded regularly, and embedded in the build or in the repository.
  • Errors, bugs, missing features that we difficult to push in, magic features which we would want to push out. Frameworks are another level of abstraction which opens new way for bugs and errors to get in.

Thus typically, the costs of libraries integration are underestimated, and frameworks are not an exception.

How to integrate a library

The first thing you do when you integrate a library is to wrap it in an interface that your code finds easy to work with, and define only the functionalities you use in this Facade.

That's a good way to keep a library isolated, far from the core of your codebase, so that you can swap it in the future with a similar one in case the project dies or take new directions you don't like at all.

The catch is - you can't do that with a framework. Framework are defined as libraries that call you, instead of you calling them. For example, in Zend Framework you define controllers as

class MyController extends Zend_Controller_Action
public function indexAction() {}

and an object of this class will be instantiated and called for you. That's incredibly handy for generating an application from scratch, but it's difficult to isolate. While a layer of abstraction over a library is simply a couple of interface and class, I've never seen someone trying to abstract away a controller by implementing different "controller drivers". The best we can do (in PHP) is to keep controllers as small as possible.

Frameworks are catch-all facilities, that have to support many different use cases

Zend Framework, which is actually an hybrid, is easy to use as a library: you create Zend_Locale, Zend_Translate, or Zend_Filter objects and compose them.

But the framework side (Zend_Controller mainly) pushes for defining Zend_Locale and Zend_Translate as global objects which magically intervene in your input and output handling. Testing code that involves a framework is a blood bath, unless the framework provides you some utility as workarounds for the magic functionalities, like Zend_Test (which disactivates exits(), redirect, and Zend_Session).

Is this really cool? To manage a full application, the framework is littered with Singletons and global state (which are under rework in Zend Framework 2.0), lots of configuration, and many issues on how to define ini values, and with what names.

The folder structure is also different from standard autoload but somewhat a standard in the framework's application (another lock-in). There are many different conventions you have to follow - uppercase names, lowercase ones, underscores, camelCase, and all-lower case.

And for what? For example, supporting multiple paths for view helpers so that some paths overwrite the previous ones magically. In your view, you could call $this->url() and the right Url view helper will be dispatched.

Do you really need that? Some of us do, but it's a minority. I would just provide an hardcoded list of view helpers classes to inject in my view (I know class maps will probably do something like this).

The same goes for resources, plugins, form elements and decorators; Zend_Form supports filtering, validation, rendering, decoration, display groups... I never use more than half of them at a time.

Each moving part adds to the complexity of understanding how the framework works, and how to fix it when it breaks. At the same time, it adds little to the developer as it is a generic implementation which will have to be tailored to the current needs anyway.


Summing it up, a framework tries to save you work by make you define an overly complex configuration, that has to accomodate every possible use case. This declarative approach to building an application is not always superior to the programmatic one, where you build object graphs by hand.

Is this a reason to ditch a framework? Only if you already know that your application won't need such a complex architecture. But meanwhile, I'll continue to make my controllers as small as possible. Hope to see your opinion in the comments.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Stephen Musoke replied on Fri, 2011/02/18 - 8:32am

The reality is that you have to pick one of the frameworks to prevent rolling out your own. My development team has just ditched 5 years of maintaining our own home grown framework to Zend Framework (after evaluating CakePHP and Symfony)

A framework in additon to providing standardized layouts, classes and approaches, makes it easy to share your work with others outside your internal team.

The bottom line is while a framework imposes a learning curve and specific rules, it saves you the hassle of trial and error to develop these rules yourself 

Michael Kimsal replied on Fri, 2011/02/18 - 11:11am

"makes it easy to share your work with others outside your internal team."


This is something that gets completely lost in most discussions on frameworks and libraries. In the Java world, Hibernate vs EJB might be a decision to make, but almost all projects of any size use one of those two, and new people coming in to the codebase over time have far less learning curve on those mechanical aspects of the code. They can spend their time learning about the application logic - business needs, etc.

I still come across PHP projects with hardcoded "mysql_query()" calls and hand-rolled custom libraries for, in effect, crude, half-baked ORM. The only person who understands that one library is either overworked on other projects, gone from the company, or says "yeah, I don't use that any more".

I'm not a particular fan of any framework out there, but advocate using one that has some community around it, because finding people who are familiar with the plumbing of one or more frameworks will be easier to integrate in to a project than someone who has no experience with any.

Giorgio Sironi replied on Fri, 2011/02/18 - 1:16pm in response to: Stephen Musoke

We use Zend Framework and we feel much better than by rolling plain old .php files. However we ditched many components (Action Helpers, Zend_Db) which didn't really add any value: Zend is cool in this scenarios as you can pick just the components you really need.

Giorgio Sironi replied on Fri, 2011/02/18 - 1:21pm in response to: Michael Kimsal

I think an ORM is really needed also in medium-to-large PHP applications. But there's also PDO between mysql_query() and a full-fledged ORM. In this sense in PHP probably Doctrine 2 is imposing a standard, while for frameworks there is great fragmentation: Zend Framework, Symfony, CakePhp, Lithium, CodeIgniter... The far less learning curve is a fact but only if you hire people who are familiar with one particular framework, which are a minority of the whole PHP world. :)

Marco Patania replied on Fri, 2011/02/18 - 5:06pm

My experience leads me to say: "absolutely use a framework!" The main reasons are: - hardly a development team will take current flexible solutions such as those taken by a framework (we all know that software is never finished;)) - hardly (if ever) the documentation is better than , and if there is a change of the team is easier to pass the work. - If the framework is 'famous' is easy to introduce new developers in the team - development of our products if the framework evolves - community support! For this and other reasons I chose Yii framework for my business, which I think is the most complete of all the ones I've got to try (symfony, zend, there, cakephp).

Ivan Iordanov replied on Sat, 2011/02/19 - 6:18am

I think I vote against frameworks. My experience says that all the logic should be in Model. By model I mean real model, not just database queries. Usualy my model is splited into 3 layers. Context, Implementation and Interface. Or with other words Strategy pattern. Context is the object my controller comunicates to. This object works only with given Interface and I pass to it a concrete implementation of the interface. Implementation is the object who cares about data in most cases (not only database queries). Such design gives me flexibility to switch between different cases without breaking current functionality and to handle requirements changes easily. No one of frameworks out there can't give me such abstraction so far (I think you guess why). About frameworks .. I have used some of them but I really don't care about them, because my logic does not depend of framework and I can migrate a project writed in zend to symfony project for example with minimal changes. So far I prefer to use my own "controllers" witch depends on .htaccess and to avoid complex url parsing or routing in dispatcher or front controller. Of course there are some good components/libraries in zend or pear (for example mail classes) witch I like to use but I always wrap them into adapter pattern. It's easy to change (switch at runtime) the library if I need new functionality that current library can't give me.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.