PHPixie vs Laravel

The main reason for writing this article is that this question is asked almost regularly and it would be good to just have a link at hand. Immediately, I’ll say that there’s no holivor in the power of Emacs versus Vi, like any attempt to strongly reproach Laravel. Already no one doubts that it works, websites are spinning on it and nothing bad happens to them, so it’s stupid to say that it’s something bad. I want to show what kind of niche PHPixie and Laravel are trying to take here is just an example, so I hope that the reader will take the article as a review in the HTC-Samsung style, designed to show the advantages and differences in the paradigm, but not to postulate 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, you probably don’t recognize them at all today. In this, they both differ from symfony, which changes much slower, and even the difference between versions 2.7 and 3.0 is not very big. But if you compare it with Linux distributions, then Symfony is similar to Debian, Laravel to Ubuntu and PHPixie to Arch. PHPixie uses a rolling-release approach, and all new features and bugfixes immediately get into the master 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. Here I will immediately remind you that if you use “composer install”, then you always install the same version, and there are no surprises to wait for. This approach forces the framework developer to think about backward compatibility, and not to break the existing API. As a result, you upgrade your code a bit along with the framework, and then you don’t have to think about Laravel 4 jumping to Laravel 5, where everything changed at once, and the code on Laravel 4 is now considered legacy.

Work speed

With the speed in PHPixie, everything remained as it was, it’s just as fast further, since the routing code and the kernel itself didn’t change much, it only acquired new libraries that affect speed only when you use them. Benchmarks from Techempower show that Laravel, even on HHVM, cannot catch up with PHPixie in PHP . In principle, I rarely hear Laravel praised for the speed of work, it is more praised for the speed of development, so most likely the performance simply has never been a priority in it.

Entry threshold

There is no doubt that Laravel, laracasta, facades, all sorts of snippets from tutorials and ready-made bundles allow even beginners to make a website in the minimum amount of time, and now it can also be used directly from artisan. All this is due to the solidity 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 dependencies are built through separate factories, and as a result, you need to understand more what happens behind the scenes. But over time, I would say this 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 code debugging much easier by understanding one part of the framework that 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 quality. However, if facades and all that is really important to you, then the optional DI component will allow you to get the same result.
')

Work with DB

The Database and ORM components have evolved the most and are among the best parts of the framework. Only a few months ago, ORM began to support Nested Sets, while applying optimization techniques. Models are clearly distributed to repositories, requests and entities themselves. Instead of inheriting some base class of the model, the extension is performed by the Decorator pattern, which makes your code completely independent of the very logic of working with the base and elementarily tested. Even for building queries, you can use several variants of the syntax. And, of course, the killer feature is that it all works with both SQL databases and Mongo, including connections between entities in different databases. Here Laravel loses much, since 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 quite well.

Community

Laravel developers are undoubtedly much more, as well as mitaps and freelance orders for them. The only thing that PHPixie can do is to chat with us 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 arrive in the chat after writing this article, I will be very happy. Even if you do not use 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 a little for the framework as a whole, since there were 3 new components, to which there are still no documentation, and tests are only there in the process, but in a short time there will be 100% again. Here, by the way, it is important not only the code coverage itself, but also its testability. The lack of magic and facades just allows you to write short and fast unit tests to individual classes without having to raise a bunch of dependencies on each test. In Laravel, of course, there are also tests, but much less, and by the way, there is no badge with coverage percentage on the github page of the project, and I could not even google this percentage, so it is clearly not advertised. I was not lazy, and I myself ran tests and generated statistics, here’s the result:



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

Routing

Here we have again the paradigm difference. Laravel as a more monolithic framework provides the ability to buy 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 of the routes have a name and dynamic routing is completely absent (but it can be simulated). The routing component of PHPixie is more autonomous, and even the concept of a controller is not in it, all that it does is parse the request into a set of parameters and pass them to the user. In turn, this allows more flexible configuration with nested rules and prefixes. Another difference is that in PHPixie, the routes are stored in the configuration file by an array and in Laravel are set programmatically, which is more convenient if there is an IDE with prompts.

Template engine

PHPixie uses PCP as a templating engine, which means that all the usual functions such as ucwords , substr , trim, etc. already available and do not have to learn a new language. PHPixie has managed to get all the benefits of popular templating without compiling, so with it you will also have access to both 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 the previous articles, this template engine allows you to fasten any syntax, such as HAML, in a matter of minutes. Laravel Blade in 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 own wrappers, but you can always access the pure PSR-7 request. It can also receive requests from outside, which allows you to run the framework, for example, on ReactPHP without any effort. This was also possible due to the stateless architecture, together with ReactPHP, this means that after the execution of the request, the framework remains as it was before it and can immediately process the next one without restarting. Laravel is built on the HTTP component of symfony, which builds its requests, and you can turn them into PSR-7 only using symfony / psr-http-message-bridge , which at least adds overhead data on each request. Although most likely in the next version of Laravel will switch to PSR-7 completely.

Authentication

It is very easy to add authentication to Laravel, the configuration is actually available out of the box, but the implementation still leaves much to be desired. There was already an article about how Laravel just checked the encrypted user ID in cookies and how it was managed to exploit. The problem was not so in encryption, but in lax verification of the result using '=='. The hole was repaired, but now they made another one. In the documentation on the "remember_me" you will see that the authorization token is stored one for the entire account, that is, if you steal it, you can log in with it until it is valid. In PHPixie, the implementation of “remember_me” is based on the best practices, when each device has its own token for one account, and at the same time it is also updated with each use. It makes no sense to steal such a token just because of its disposability. If you are interested in the complete procedure, then it is described in the well-known response 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 using them with another framework is not so easy. PHPixie was originally conceived as independent components, it is significant 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 components.

At this point I’ll probably finish, and even then it’s already too long. At the end, I will only note that in no case do I think Laravel is bad or even worse. I just wanted to show the PHPixie niche as a more cutting-edge framework, as compared to 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 speed of development.

A little closer will get acquainted with the framework with my introductory video in which I show the configuration of the project and work with the main components: