Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to Safari
Join our communityThe Best 1 of 9 OptionWhy?
Top Con
•••
Top Con
•••
Top Pro
•••
Top Con
•••
Top Con
•••
Top Pro
•••
Top Con
•••Top Pro
•••Top Con
•••Top Pro
•••Top Con
•••
Top Pro
•••Top Con
•••
The dependency container schema of Slim is one of the biggest PROS and CONS of the framework. It is true that this schema brings so much flexibility to add anything, but another thing that is true is that you need to have strong bases of patterns, and an extensive knowledge of your libraries to convert it into a Slim dependency. See More
While it's true that Slim is a microframework, it's still too minimal. When used for throwaway projects or simple prototypes, it's perfect. But in the long run, it becomes less and less useful and you end up in implementing a fully custom framework in trying to tackle all the missing features. So in the end, if the project would go further than a prototyping stage it would be easier to just implement another microframework that has those missing features out of the box. See More
Rack is an interface used in Ruby frameworks used to group and order modules, which most of the time are Ruby classes, and specify between them. Slim uses a simple concept for it's middleware. By wrapping HTTP requests and responses it unifies the middleware into a single method call. See More
Documentation for Lumen is the worst. If it exists, it's probably the wrong version or inadequately covered in the Laravel doc instead. What doc that is there is sparse to the point of useless. You're going to have to love "iterative development" b/c you'll be trying an infinite number of possibilities just to get basic stuff to work. See More
Lumen as a framework is at it's full potential when used alongside it's older brother. Lumen was created to be used for microservices alongside Laravel, which is used for more user-facing applications. If a project is already using another framework other than Laravel, it would be better to use another microframework for microservices instead of Lumen. See More
Laravel supports event queuing and it does so in a very simple way. To create an event that should be queued just run: php artisan handler:event SendPurchaseConfirmation --event=PodcastWasPurchased --queued This creates a handler that implements the Illuminate\Contracts\Queue\ShouldBeQueued interface. Now when this handler is called it will automatically be queued by the event dispatcher. See More
While a lot of times you can write things in plain PHP, it will hinder you down the line when you want to use core features and find that you have to rewrite code which then causes issues throughout the app. Documentation is good, but you need to know what you are looking for and practical examples are non-existent. Many features have been updated throughout the versions in such a short time that tutorials you find online are confusing to sort through outdated tutorials and guides that no longer work or have been depreciated. See More
Laravel has a powerful template system called Blade. It's quite similar to Twig or Moustache with lots of curly braces but the real power comes from the usage of PHP code directly in the view. Blade templates compile directly to raw PHP and are processed in the server when a request is made. See More
Laravel has two primary configuration files for it's bootstrapping: this one and this one. The Kernel defines some global middleware that execute on every request, while app.php registers several service providers which go through two booting phases: Registration, which is the first to happen Boot, which is executed after all the other service providers are registered. Another reason why Laravel's bootstrapping is slow is because Laravel sits on top of Symfony's HTTPFoundation, which is relatively heavyweight. See More
Laravel uses many libraries built for the Symfony PHP framework. Many of these libraries are well-built and have been tested by users before. Since the point of using a web framework is to shorten development time and to avoid reinventing the wheel for problems that have already been solved, then it's logical for a framework to use libraries already built to solve problems that have already been solved. See More
While the speed doesn't seem to be an issue with it (on local tests), in production it may be hindered. The framework creates a ton of files and folders, some of which your app might not even use. Not good if you don't like having a ton of folders and rigid non-standard PHP folder structure for development. See More
By using Pimple, the Silex application extends the Pimple class, which in turn is nothing more than an implementation of the ArrayAccess interface that has been a part of PHP since version 5.0. This makes it possible to use an instance of the Application class as if it were an array. Like so: $app = new Silex\Application();
$app['config'] = new Config($config_path); This gives developers a great deal of flexibility when injecting dependencies and when testing. See More
The default ORM for this framework is missing some features such as joins. But it's important to keep in mind that it's a small plugin, only 23KB in size which still can be replaced with a larger ORM if needed. An alternative the drop in f3-cortex ORM which is popular, and supported by the community, which supports Joins and much more. See More