
To begin with, I will say that I am a very big fan of something to patch and podvikat, even if for this there is no particular need. And recently, while reviewing XCache statistics on my server, I thought that I could optimize the amount of memory that he spends on opcache of various framework files. It is easy to do this - to rewrite everything using only one, the files of which would be common for all sites, which I have about 20, but in most of them they are quite simple and I wouldn’t give them any special difficulty to rewrite them. And then I began to search for the same framework, which ideally would have enough features for the development to be simple, and at the same time easy and fast. Here are the ones that I liked and my thoughts about them.

Interesting primarily to those
written in C and compiled as a module for PHP. Judging by the benchmarks, it works much faster than others (about 3 times faster than the average) and at the same time observing a fairly familiar MVC structure. It is also very pleased that Phalcon uses Dependency Injection and provides its own DI container, but judging by the tutorials, it is still very often that classes are used directly, while including static methods, which I personally try to avoid. By the way, I must say that the module was compiled and earned the first time, without dancing with tambourines, which is always nice. Looking a little deeper, I began to see more flaws, firstly not many PHP programmers who know C well enough to help in its development, as a result Phalcon will develop more slowly than its PHP counterparts. Secondly, it has invented many of its crutches, such as PHQL (Phalcon Query Language) for replacing SQL, etc. As a result, we have a rather courageous project with an unknown future.

I heard about him quite recently, Phil Sturgeon (developer of PyroCMS and a member of PHP-FIG) mentioned it in his tweet and at first I thought it was just a joke. Seriously, I think that no PHP programmer will be able to listen to the intro on the main page until the end without laughing. The philosophy of PHPixie is that the framework should be quick and easy
as a little fairy , developers are trying to achieve this by approaching famous pythonists like "Simple things should be simple." That is, the PHPixie components are written so that the easiest and fastest way to cope with 90% of routine tasks in the development of sites, and the remaining 10% of complex, more rare tasks are supposed to be solved by the developer himself and there is no need to include them in the framework itself. I have to say that in none of my sites nothing like that would exist in PHPixie, and even Dependency Injection is pretty good for them, although it is leaning towards the Service Locator. Unlike other implementations of DI containers, new elements are added to it through class extension, which is less flexible, but much more transparent, while completely avoiding the procedural code and obtaining recognition of the class of container elements in the IDE. Of the minuses, I can only point out that it is rather difficult to take it seriously, and you can hardly convince your employees in the office to write something on the framework with fairies and ponies.
')

All framework in one file! A huge plus immediately to the face: one file from the disk will load faster than many, and the size of this file is about 50 kilobytes. The truth is, as it turned out in this single file, not the whole framework, but only the main part of it, that is, if you need access to the database, for example, you still have to load the classes. The same XCache caches the PHP code, in this case gain from such an approach if it is very small. Together with the framework comes just a bunch of libraries, which is convenient if you do not use Composer and do not need to use it at all. Also very surprised that their ORM does not support relationships between tables, without which it can be immediately thrown out the window, since this greatly narrows the area of its use. This is actually the only framework I have reviewed that really disappointed me.
Silex , Slim and microframes.

About these two is known and so much. Since both of them do not provide a full stack for development, everything will depend on which libraries you attach to them and how to do it. From this comes the flexibility of microframes, but on the other hand it will be harder to find the community and support, as each programmer has his own system as a result. In addition, if the framework is written all alone by people, it is much easier to master it, since the code philosophy is similar. But if you have Frankenstein collected from different libraries, in which there is a different style and approach, then it will be more difficult to understand this. In the end, attempts to make Silex a complete e framework lead to a collection of some kind of symfony. It should be noted here that writing code on Slim and Silex occurs intuitively, quickly and without any magic.

There are a few more innovations, for example, a single API for SQL and NoSQL databases, as well as a decentralized filter system according to the developers. The framework was created by a former CakePHP developer, and in some places it is very noticeable, such as when using models. Filters allow you to actually intercept a call to a class method and change its parameters and results on the fly. Flexibly, but in the end you can get pasta code, like the way WordPress plugins work. It is also surprising that such an innovative framework so persistently uses static methods. Pleases a simple architecture, that is, if you create a simple website, the amount of code that came to write is not much different from using Silex. In principle, it is very well suited for those who have worked with CakePHP in the past, but want to try something new.
So which one did I choose in the end? In the end, my choice was between Silex and PHPixie (yes, I was not afraid of the fairies) and as a result I still used both of them. Most sites translated to Silex, and those that were written to Kohana ported to PHPixie, whose interface is somewhat similar to it, especially the ORM implementation. With this, I was able to reduce about 6 times the amount of memory consumed by XCache, speed up page generation, and even managed to refactor a bit on the way. In general, PHP is a country of thousands of frameworks, so I think everyone can find something to their liking.