I have been working with Phalcon for a half year now and I love the concept of the framework built in C.
However,
I recently migrated my servers to PHP56 with Phalcon 2.0 and some subtle things broke which made my clients rather unhappy. This makes me reconsider using all Phalcons features, so please don't be offended with these 3 points of criticism.
ORM: I have been struggling with beforeSave since apparently in the recent version of Phalcon storing arrays as JSON strings broke my application. After extensively researching I found that isset($this->field) does not work properly. This is essential if you want to optionally format and store a field... So a lot of work here to manually convert arrays to strings and store them. Also, when storing fields an empty string is interpreted as a NULL value. There is a documented workaround involving some juggling with RawValue but isn't ORM meant to take away these burdens? At this point I would not use Phalcon ORM in my next project... there are better (though perhaps not so fast) alternatives.
Template handling The Phalcon default view handling has a somewhat inflexible 3 level structure most likely related to Module/Controller/Actions level of granularity. However, this should not be imposed by the framework. When using mature template engine in stead of PHP it is more likely to use template inheritance rather then these 3 levels that are carved in the Phalcon view. Therefore I passed the View in favour of SimpleView, and have the template decide in which enclosing template it will live. But SimpleView is a stepchild.. why doesn't it offer basic functions such as templateExists()?
This all is perfectly possible with Volt, and having a template engine written in C makes a lot of sense. Unfortunately, Volt does not support nested blocks, essentially limiting template inheritance to 2 levels. So if you want more, you will need to use some more mature template engine such as ageold Smarty or Twig which do support full template inheritance.
Webservices Okay, so in todays arena you need to support REST services and the like. With the advent of Angular.js, Ember.js, Backbone.js and many more webservices make out the most part of your application. In the end, PHP frameworks need to be able to compete in the same field as for instance Meteor and PHP is a long way from there. This is not something that Phalcon can help but still one would expect Phalcon to take a stronger position to simplify rest services.
I really think that a framework today has a strong need to parse and validate JSON based requests, checking existence and types and formats of JSON entities in a json string. This is still stuff you need to build yourself into Phalcon and it is not that difficult but aren't frameworks supposed to take away the long and tedious tasks?
Another thing is the Phalcon response object that fiddles with the output buffer. It has long been a PITA with PHP to stream content to a HTTP response, but PHP rather buffers content before sending it out. That is memory consuming and makes it difficult to serve large files, but it is avoidable, and I think I would have expected Phalcon to enable this easily, rather than adopting this PHP paradigm.
Okay, that was pretty biased criticism. I do love Phalcon and if there are parts of Phalcon that do not suit my needs, well, of course I can always plug in another library. But it would be a shame for such a great project to rely on a bunch of external libs while building these in Zephir or C would offer a tremendous advantage.
