HipHop VM: now at 98.5% PHP framework parity, 16% faster

On the surface most of the popular PHP frameworks are not much different from each other. Basic MVC separation, some sort of dependency injection container (actually a service locator), Composer and standardized autoloading, etc. Once you dig into the coding aesthetics then the differences start to become clear. Yii isn't PSR compliant, both FuelPHP and Laravel make liberal use of Facades and/or __callStatic to preserve the style of static function calls that are prevalent in CodeIgniter. I guess what makes Laravel stand out is the sheer amount of documentation and examples that are available, both on the website and in the code itself. This makes it really easy to get started.

Me, I'm not really keen on the Component::function() syntax. Feels like a crutch to me. Especially when people go out of their way to avoid specifying namespaces by abusing class_alias. Plus you're not really saving that many keystrokes compared to, say, $this->app['component']->function(). (Yes, I like Silex).

I would if their PDO implementation supported postgres :(

Yii still exists? Why?

Laravel has a half decent API and doesn't rely overmuch on (untestable) static functions. My evaluation of FuelPHP was admittedly brief, but let's take another look:

http://fuelphp.com/docs/general/controllers/base.html

and http://fuelphp.com/docs/general/models.html

For those who may be unaware, the issue with static functions is that, if you are calling a static method, you will execute that method. You're not able to choose not to execute that method (unless you do something surpassingly stupid like checking whether you're in test mode), and you can't generally make that method return anything other than what it normally does. Isolating that static method is rather difficult, and if that static method happens to call another one, well, it had better not be an issue with your test, because you're not going to stop it happening.

I know the FuelPHP devs have gone on record saying that Fuel doesn't rely heavily on static methods, and that static methods aren't a problem, and that to the degree to which there is a problem, they are gonna fix it, but...

http://pastebin.com/K03HMyVs

Here we compare CakePHP, Laravel, and FuelPHP (Thank you to Sebastian Bergmann for providing the statistics utility). For anyone actually evaluating these platforms, you may want to check out these benchmarks as well:

http://www.techempower.com/benchmarks

Without saying anything about how easy or fast it would be to develop for each of them, it seems that for trivial tasks Laravel > Fuel > Cake. From the code statistics, we have: Fuel: 785 static methods (22.45%) Cake: 530 static methods (7.96%) Yii: 483 static methods (7.95%) Laravel: 0 (0.00%)

Laravel seems pretty light as far as that goes, and generally when I'm faced with a large project I want the framework to be large as well. I feel like otherwise I'm going to end up finding or writing libraries for things that I feel like the framework should take care of. I would have a hard time recommending a PHP framework, imo they're all pretty much crap. Laravel is not better per se than other frameworks, but it does (far) less, and therefore does it less badly. Divine intervention alone will fix the PHP world at this point, but if you can avoid CodeIgniter, Yii, and FuelPHP, probably no other choices will be as bad.

Yes, I do. I have a PHP app that can be CPU bound (lots of ML baked into async threads). It has been a godsend.

I tried it two days ago after they made the fastcgi announcement. My day job sites are fairly big with what I consider a pretty large number of contrib modules. I managed to get it up and running, but the HHVM logs were full of notices and it finally bombed out after several requests (not enough to really warm up the VM) on something related to apachesolr, and another one related to GD, which is strange because we use imagemagick, but whatever. Sad Trombone.

The really cool part though, it truly was "drop in". Every bit of my existing nginx/fpm configs worked as is, so once it's a bit further along, it's just a matter of shutting down fpm and firing up HHVM.

There were also a couple of gotchas in the setup related to the fact that their apt installer installed HHVM configs that don't assume Fastcgi, so it took a little bit to figure out the correct edits to the init script and HHVM config so it'd listen on :9000 instead of :80, but all in all that it worked at all was really fun for a minute. Very excited about this project.