Chris Tankersley

PHP Frameworks as Extensions - Will They Catch On?

Posted on 2012-05-19

Over on someone posted a link to a new PHP framework, PhalconPHP. This is a new framework with an interesting twist - it's a C Extension, much like APC or xdebug. In theory this means that it should be much, much quicker than any PHP-land framework like Zend Framework or symfony2.

PhalconPHP is not the first extension-based framework though. YAF was introduced in the middle of 2011 and is available as a pecl extension. As far as I know, these are the only two extension-based frameworks that PHP has. If there are more, I'd love to hear about them. For the sake of some comparison, I'm going to put them up against Zend Framework 1 and Silex, two of the normal PHP frameworks I am most familiar with.


As with every framework, you need to install something for your site to work. In the case of our two extension we have to actually modify our PHP installation by installing and configuring extra software. For Silex and Zend Framework we basically unpackage the files and they are ready to go.

This is the big thing that I think will keep extension-based frameworks from catching on as mainstream solutions. I personally can install them since I run my own servers for my personal projects, but I can't suggest them at work since we don't always have control over the servers. Deploying to a PHP cloud SaaS? Sorry, no way to use YAF or PhalconPHP. Want to run on most shared hosts, or even Rackspace Cloud Sites? Again, you don't have the ability to install extensions, so no go.

Many programmers are not system admins (though I really think they should be to an extent). The installation routines for these frameworks is not much more complicated than PHP-based frameworks, but the lack of ability to do the install (either because of the host or the programmers lack of knowledge) ignores one of the good things about PHP - the barrier for entry is low. Installing an extension to use a framework is a much higher barrier of entry compared to downloading files that will work on 90% of the web hosts out there.


Installing YAF is pretty straight forward. Since it's a pecl extension, you can install it through the pecl command. On Debian I did the following:

$ pecl install yaf
$ echo '' > /etc/php5/conf.d/yaf.ini
$ php -i | grep yaf

If you see the config for YAF spit out, it's installed.


PhalconPHP is not available as a pecl extension, so it requires a bit more work.

$ aptitude install php5-dev php5-mysql gcc
$ git clone git://
$ cd cphalcon/release
$ phpize
$ ./configure --enable-phalcon
$ make && make install
$ echo '' > /etc/php5/conf.d/phalcon.ini
$ php -i | grep phalcon

Oddly enough, if you're on FreeBSD PhalconPHP is available as a port, but there isn't a pecl repo.


I just use Composer to install Silex. This pulls in all the stuff I'll need for a basic site.

Zend Framework 1

I'm actually trying something different. I'm using Composer to install Zend Framework 1.11.11 using 'breerly/zf1'. I then ran the zf.php file to create a new project. I also modified the index.php file to point to the vendor install of ZF1 instead of to the default 'library' folder.

It Broke, What Now?

Way back when, there was a bug in Zend_Db when using the MySQL extension. It would throw an error about references on certain versions of PHP. It was a fairly easy fix so we implemented the fix and were good to go. This is true for many different PHP frameworks. When you encounter an error you can put your PHP knowledge to use and fix it.

For YAF and PhalconPHP you need to understand C to debug and possibly fix the code. You'll need to also understand how the PHP extension system works. This makes it harder to deal with problems and even submit patches. I think this will make businesses think twice before building a platform on an extension-based system.

Another issue is deploying upgrades. Let's say you are running 3 servers behind a load balancer. When Silex updates, you can update it with a regular code push to your servers. When an extension updates you now have to recompile. In the best case you can compile on one machine and push it, and restart your PHP instance. In the worst case, you're doing this on each box.

Code Reuse

With PHP-based frameworks you can pick and choose parts of the frameworks and move them from application to application. symfony2 and Zend Framework 2 are very well componentized to the point they can be used outside their full frameworks. Silex is built using symfony2 components, and I've used many of the symfony2 components in different projects without needing the entire framework. Code reuse becomes high as my code isn't tied to a specific full stack.

Using YAF or PhalconPHP means less code reuse. You can't decide to use the model system in PhalconPHP as it requires the full extension to be installed on the target system. Same thing for something as simple as logging - you need to install the entire framework instead of being able to just move parts of the library around. Neither of them stop you from using Zend/symfony/[insert framework here], but their very nature stops you from using peices of them in other projects.

So Why Even Use Them?

The biggest answer to that is speed. shows a multitude of benchmarks, with YAF beating all the PHP-based frameworks it is put against. Since these frameworks run at the C level and are compiled the framework code itself skips the entire opcode compilation that other frameworks have to go through. This means parsing and opcoding 5 or 6 files per request instead of hundreds. Even with APC there is still more overhead compared to extensions. If you need to run as close to bare-metal as possible then YAF or PhalconPHP is a great way to squeeze out performance.

I haven't done much work with either of them, but they follow the common Front Controller MVC that most of the other frameworks use. Developers on the PHP side should not have much trouble using YAF or PhalconPHP.

This speed and power comes at the cost of availability. For projects that can support themselves YAF and PhalconPHP would be a great option for high traffic or heavy applications. Neither will be terribly useful for general purpose applications like Wordpress, Drupal, or anything else that wants to run just about anywhere. It will take getting more hosting platforms to start offering these as options.


I think that extension-based frameworks have their place, but I don't think they will ever catch on as mainstream options. Projects based on them will be regulated to specific installations, and you will see very few major applications using them. Patches and enhancements will need to be done in C, which will reduce the number of contributers and therefore users. I like the idea of moving frameworks to extensions, but I just don't think it will work in the long run.