PHPixie vs Laravel

The main reason for writing this article is that I am asked this question almost regularly and it would be nice to just have a link at hand. I’ll say right away that there will be no holivora in the power of Emacs against Vi, like any attempt to strongly reproach Laravel. No one doubts that he works, sites are spinning on him and nothing bad happens to them, so it’s stupid to say that he’s bad with something. I want to show what kind of niche PHPixie and Laravel are trying to take here just as an example, so I hope the reader will perceive the article as a review in the style of HTC vs Samsung, designed to show the advantages and differences in the paradigm, but not to post who is better.

Version system

It is worth noting that both frameworks have come a long way, and if you were familiar with them 2 years ago, then most likely you will not recognize them at all today. In this they both differ from Symfony, which changes much more slowly, and even the difference between versions 2.7 and 3.0 is not very big. However, when compared to Linux distributions, Symfony is similar to Debian, Laravel to Ubuntu and PHPixie to Arch. PHPixie uses the rolling-release approach, and all new features and bug fixes immediately go to the wizard and get the version tag, which makes them available as quickly as possible. But “composer update” will have to be done more carefully, and follow the changes. I’ll remind you right away that if you use “composer install”, then you always install the same version, and you don’t have to wait for any surprises. This approach makes the framework developer think about backward compatibility, and not break the existing API. As a result, you upgrade your code a little bit along with the framework, and then you don’t need to think about Laravel 4-style jumps to Laravel 5, where everything changed at once, and the code for Laravel 4 is now considered legacy.

Work speed

With speed in PHPixie, everything remains as before, it is just as fast further, since the routing code and the kernel itself remained practically unchanged, it only became overgrown with new libraries that affect speed only when you use them. Techempower benchmarks show that Laravel even on HHVM cannot catch up with PHPixie in PHP . In principle, I rarely hear that Laravel is praised for its speed, it is more praised for its development speed, so most likely productivity just never was a priority in it.

Entry threshold

Here Laravel undoubtedly wins, larakastas, facades, all sorts of snippets from tutorials and ready-made bundles allow even beginners to make a site in a minimum amount of time, and now it is also possible to replenish it directly with artisan. All this is due to the monolithic nature of the framework itself, which, although it consists of components, but Laravel itself merges them into one whole. PHPixie is strictly modular, so there is not even a single DI container, and all the dependencies are built through separate factories, and as a result, you need to understand more what is happening behind the scenes. But over time, I would say so for half a year, the learning curve changes. PHPixie is built from scratch, and all components are created according to a single paradigm, which makes debugging code much easier, understanding one part of the framework makes it easier to understand the other. At that time with Laravel you will spend a lot of time in the code of different developers with different approaches and different qualities. However, if the facades and all that is really important to you, then the optional DI component will allow you to get the same result.

Work with a DB

Database and ORM components have evolved the most and are one of the best parts of the framework. Only a few months ago, ORM began supporting Nested Sets, while applying optimization techniques. Models are clearly distributed across repositories, queries, and entities themselves. Instead of inheriting some base class of the model, the extension is carried out by the Decorator pattern, which makes your code completely independent of the logic of working with the database itself and elementarily testable. Even to build queries, you can use several syntax options. And of course, the killer feature that all this works both with SQL databases and with Mongo, including relations between entities in different databases. Here Laravel loses a lot, because Eloquent did not go far from Kohana ORM and PHP ActiveRecord. Most experienced developers use either Doctrine or Propel when working with Laravel. Again, it all depends on your tasks, for most CRUD applications Eloquent works very well.

Community

Laravel developers are undoubtedly much more, as well as mitaps and freelance orders for them. The only thing PHPixie can cover is our chat in which I can be found every day and most of the problems are solved right there on the spot. By the way, if users in the chat arrive after writing this article, then I will be very happy. Even if you are not using PHPixie, still come to us, even with Laravel we will be able to help if that.

Tests

PHPixie is known for its 100% test coverage. This number has recently decreased slightly for the framework as a whole, since 3 new components have been released, for which there is no documentation yet, and tests are only in progress, but after a short time there will again be 100%. Here, by the way, it is important not only the coverage of the code itself, but also its testability. The lack of magic and facades allows us to write short and fast unit tests for individual classes without the need to raise a bunch of dependencies for each test. Of course, there are tests in Laravel too, but much less, and by the way on the github page of the project there is no badge with a percentage of coverage, and I could not even google this percentage, so it is clearly not advertised. I was not too lazy, and I ran the tests myself and generated statistics, here is the result:



By the way, when you try to run the test on fresh PHPUnit, when you turn on coverage generation, it simply throws an error.

Routing

Here we again have the paradigm difference. Laravel as a more monolithic framework provides the possibility of binding to models, allowing you to completely skip the controller code, for example:

$router->bind('user', function ($value) {
    return App\User::where('name', $value)->first();
});

Also, most routes have a name and dynamic routing is completely absent (but it can be simulated). The component of PHPixie routing is more autonomous, and even there is no concept of a controller in it; all it does is parse the request into a set of parameters and pass them to the user. This in turn allows for more flexible configuration with nested rules and prefixes. Another difference is that in PHPixie the routes are stored in the configuration file as an array and in Laravel they are set programmatically, which is more convenient if there is an IDE with prompts.

Template Engine

PHPixie uses PXP as a template engine, which means that all familiar functions like ucwords , substr , trim, etc. are already available and you don’t have to learn a new language. PHPixie managed to get all the advantages of popular template engines without resorting to compilation, so with it you will also be able to access template inheritance and block support. In addition, you will have full syntax highlighting in any IDE and debugging with Xdebug. By the way, as I showed in previous articles, this template engine allows you to fasten any syntax, such as HAML, in a matter of minutes. Laravel Blade itself is not much different from Twig, only the syntax is slightly different, but it does not bring anything new.

HTTP

PHPixie is built on PSR-7, it expands its functionality by adding its wrappers, but you can always access a clean PSR-7 request. It can also accept requests from outside, which allows you to run a framework for example on ReactPHP without any effort. It also became possible thanks to the stateless architecture, together with ReactPHP, this means that after the request is completed, the framework remains as it was before and can immediately process the next one without restarting it. Laravel is built on the Symfony HTTP component, which builds its requests, and you can turn them into PSR-7 only using symfony / psr-http-message-bridge , which at least will add an overhead on each request. Although most likely in the next version, Laravel will switch to the PSR-7 completely.

Authentication

Adding authentication to Laravel is very simple, the configuration is actually available out of the box, but implementation still leaves much to be desired. There was already an article about how Laravel simply checked the encrypted user ID in cookies, and how it was managed to exploit. The problem was not so much in encryption, but in a weak check of the result using '=='. The hole was repaired, but now made another. In the remember_me documentationYou will see that the authorization token is stored alone for the entire account, that is, if you steal it, you can log in with it as long as it is valid. In PHPixie, the remember_me implementation is built on best practices when each device has its own token for one account, and at the same time it is updated every time it is used. It makes no sense to steal such a token just because of its one-time use. If you are interested in the complete procedure, then it is described in the well-known answer to Stacokverflow . Also, setting up authorization in PHPixie is much more flexible, you can create several tokens, use a session or just cookies and now also social authorization, all in one config.

Components

Laravel, like PHPixie, consists of components, and using Eloquent for example without the framework itself is very simple. But other components, for example, the same authentication, are tied to the framework itself much more, and it will not be so easy to use them with another framework. PHPixie was originally conceived as independent components, it is indicative that on a github each PHPixie component is in a separate repository, while Laravel stores everything in one project and provides read-only repositories for the components.

I’m probably going to end on this, and even so it already turns out too long. In the end, I just note that in no case do I think Laravel is bad or even worse. I just wanted to show the niche of PHPixie as a more cutting-edge framework, as in comparison with Linux distributions at the beginning of the article. PHPixie are components that try to be one step ahead and are aimed more at experienced developers than at beginners and development speed.

A little closer to get acquainted with the framework is possible with my introductory video in which I show the project settings and work with the main components: