First let me say that I love so much to patch or tweak, even if there is no special need for that. So, recently, considering XCache statistics on my server, I’ve thought that I could optimize memory space, which it consumes for the opcache of files from various frameworks. It is easy to do – to rewrite all, using only one framework, the files of which would be common to all sites. I have about 20 of them, but they are mostly quite simple and it would be easy enough for me to rewrite them.
So, I started searching for the framework, which would ideally have enough features for the development to be simple and at the same time easy and quick. Here are those ones that I liked and my ideas about them.
It is interesting, first of all, for the reason that it is written in C and is compiled as a module for PHP. Judging from the benchmarks, it works much faster than the others (about 3 times faster than an average one); herewith, it observes quite a habitual MVC structure. I was also rejoiced that Phalcon uses Dependency Injection and provides its own DI container. But judging from the tutorials, all the same, the classes are often used directly, herewith, including static methods, but I’m personally trying to avoid this. By the way, the module has been compiled and started working after the first try, without practicing shamanism that is always pleasant. Having looked a little bit deeper, I saw more disadvantages. First, there are not so many PHP programmers, quite well knowing C to help to develop it, as consequence, Phalcon will develop slower than its PHP fellows. Second, there are a lot of ugly hacks in it, as for example PHQL (Phalcon Query Language) as a replacement for SQL etc. As a result we have quite a daring project with an unforeknowable future.
I’ve found out about it only recently: Phil Sturgeon (PyroCMS developer and PHP-FIG member) mentioned it in his twit, and I thought that it’s just a joke. Seriously, I believe that none of PHP programmers can listen to the intro on the main page till the end, without laughing. The PHPixie philosophy is that the framework must be quick and light, as a little elf. The developers try to achieve this, using the approach, known by Pythonists as «Simple things should be simple, hard things should be possible». That means that the PHPixie components are written so that it is possible to cope with 90% of routine tasks while developing sites easily and quickly, and remaining 10% of difficult and rarer tasks are supposed to be solved by a developer himself/herself and there is no need to include them into the framework. I must say that I didn’t use in my sites anything that you wouldn’t find in PHPixie, and even their Dependency Injection is good enough, though it tends towards Service Locator. In contrast to other realizations of DI containers, new elements are added into it by way of expending the class that is less flexible, but more transparent, herewith, it allows to avoid a procedural code completely and receive the recognition of the class of elements from the container in IDE. Talking about weak points, I can only say that it is very difficult to treat it seriously, and you will hardly convince your office employees to write something on the framework with elves and ponies.
The entire framework with one file! A huge advantage is evident: one file from a disk will be downloaded quicker than a set of them, besides a file size is about 50 Kbyte. Though, as it turned out to be, this file does not contain the entire framework, but only its main part; so, if you need the access to the database, you should upload the classes. Moreover, XCache caches PHP code anyway; in such a case if we have the benefit of this approach, it won’t be big. Together with framework a huge number of libraries are provided that is convenient if Composer is not used and is not necessary if it is used. Also I was surprised that their ORM doesn’t provide connection between the grids, without which it can be thrown away, as it narrows the field of its use very much. In fact, this is the only framework from those, analyzed by me, that was a complete disappointment for me.
There is quite a lot of info about these two frameworks. As both of them are not a full stack for development, everything will depend on which libraries you will bind to them and how you will do this. Microframework is based on this, but, from the other side, it will be more difficult to find community and support, as, all in all, every programmer has his/her own system. Besides, if all the parts of the framework are written by the same people, it is much easier to understand it, as the philosophy of the code is similar. But if you have a Frankenstein gathered from various libraries, which have different style and approach, it will be more difficult to work it out. Eventually my efforts to make a complete framework out of Silex lead to developing something similar to Symfony. Here it should be mentioned that writing the code on Slim and Silex is an intuitive process, a quick one and doesn’t need any magic.
There is a bit more innovations here, for instance a single API for database SQL and NoSQL, and also, according to the developers, a decentralized filter system. The framework is developed by the former CakePHP developer, and it is even very evident in some places, for example when using models. The filters actually allow to intercept the call to the class method and to change its parameters and result quickly. Flexibly, but as a result you can get a spaghetti code, a kind of that how plug-ins in WordPress work. It is also surprising that such an innovational framework so steadily uses static methods. What does surprise is a simple architecture; that means that if you develop a simple site, an amount of code you will need to write does not differ a lot from the use of Silex. In fact, it will suit well for those, who worked with CakePHP in past, but wants to try something new.
So, which framework did I choose? At the end I was choosing between Silex and PHPixie (yes, I wasn’t cowed by elves) and finally I decided to use both. I transferred most of the sites to Silex, and those, written in Kohana, were ported to PHPixie, which interface is quite similar to it, especially ORM realization. By doing that, I managed to reduce the amount of memory, used by XCache, in 6 times, enhanced the generation of pages and I even had time to refactor some things. In general, PHP is a world of thousands of frameworks, so, I believe that everyone can find something to his/her liking.
Subscribe to our email newsletter for useful tips and freebies.