After using Laravel 4 for an internal company tool I have a hard time recommending it (sadly, I was hopeful). I found the docs to be uneven in quality/scope, some key features (mostly around the ORM) missing and the 'feel' to be slightly off.
It's hard to quantify, but I have used CakePHP, Yii, Rails (0.9 through 4), Django and plenty of home-grown 'frameworks'. From all those the most cohesive and understandable to me was Rails followed by Yii (surprisingly).
Maybe it's the docs or structure, but Rails and Yii have a strong opinion and it seems their developers have both CS smarts and industry experience, which shows in the structure and code.
I'm sure in time Laravel will mature and improve. Currently it just feels like there's a lot more hype than it merits.
It strikes me as a project that should've been an internal framework, not a public one. Too many things break and change constantly. Rapid release cycles is a good thing for smaller libraries with specific tasks, but I expect a framework to remain largely unchanged (except bugfixes, of course) for longer periods of time.
Unless Taylor gives away control of the project, I don't see it happening. It'll keep being a popular framework, though.
As a Core developer of CakePHP, I'll tell you that the community at large loves major releases more than they like stability. Something about using the newest toy really gets a lot of people going. We actually have had quite a few developers tell us our framework is dead, despite ongoing development on a new major release and monthly minor/patch releases for the current stable line for 3+ years.
I can't comment on Laravel though, as my only experience with it was a negative one. I had a rejected bugfix for which Taylor decided to ignore the PHP documentation I linked to verifying the issue, and several other developers saying they have experienced the issue/would like to see my PR merged in.
I think it'll stay a popular PHP framework until the next popular framework comes around (CI => FuelPHP => Laravel).
The vocal community is likely in the realm of 5-10% of the actual active userbase. You should cater to most of your users, not just the bored ones.
Your framework is dead because you've continued to prove that you don't understand what PHP 5.3+ is and means. I say that as someone who has been forced to use CakePHP for ~10 years. You've always lagged far behind in the concepts that other frameworks have down pat.
I just tried to two days ago and did a complete project with it. Auth, CRUD, file management, etc. It's an instant love for me. Docs is mostly ok, Google provides instant answers. I'm happy to ditch CodeIgniter for this.
I spent two days just trying to get the thing installed and gave up. Kept hitting a snag somewhere. Such a bummer because I was excited about using it.
In my experience people who love Laravel are typically CI or WP refugees. I am yet to encounter a single person who has switched from Symfony2 or ZF2 to Laravel and liked what they saw.
Totally agree. I think that Symfony2 is a pain in the ass.
Laravel lets you have something working really fast. Then you can improve the code later on.
Agreed, Symfony2 is great, but I see it being used more in an open source project capacity. Working on it at a company where time frames are key, rapid development is huge. Plus, laravel is far more intuitive and I can ramp up new team members much faster.
I don't see how Laravel lends itself to "rapid prototyping" than any other framework. Sure, Symfony2 or ZF2 has best practices on how to do things, but at the end of the day it's just MVC - you can skip any best practice you want to just get something done. This isn't unique to Laravel.
It's less verbose than Symfony2 and, being pretty opinionated, requires much less configuration for new applications.
Facades, macros and route closures supports rapid prototyping and are pretty easy to replace as needed. Included libraries like Flysystem, Cashier, Elixir and the new cron wrapper also eases rapid development.
There are also a few tools around it, like Homestead and Forge, that makes it easy to set something up quickly.
It's not like you can't do rapid prototyping with other frameworks, but Laravel, to me, is the first PHP framework that actively supports it while providing a flexible enough structure to grow in.
I think it tends to do with the marketing. Lots of hand-holding walk-through tutorials and help people get "rapid" prototyping with laravel, moreso than the actual code itself. And, to an extent, when you present yourself as being good for "rapid dev", that's what people will associate with the framework. (by comparison, zf has never promoted itself as allowing for rapid development, AFAIK).
What could be those ORM features that you're missing? I've been working with Laravel 4 since before it had documentation when I had to go through all of the code to understand how it works and I know that besides what is described in documentation - there's a number of features that are available, but not listed.
Never had any problems with Eloquent relations and querying on them. I find them very powerful.
Yes, they aren't done in a single query format - which should be a problem since it may be faster just to do two simple queries then one complex.
Besides that relations could be eager loaded for when you have number of items in first query and want to load relations to all of them. With eager loading you won't have problems with N + 1 queries.
His 30 days to learn jQuery was a critical growing tool for me - if you're at all interested in low-level front end JS, definitely check it out. Its free.
That's actually the first course I took by him. I took a few of his other HTML/CSS courses and I am doing PHP Fundamentals (to get into Laravel later) because of the "jQuery and PHP" parts of the 30 days course. All good stuff.
Laravel represents what modern PHP can do and be. Clean, organised, fully object-oriented. Kudos to what Taylor Otwell has created both from a marketing perspective and technical standpoint.
I was a little scared by the heavy use of static method calls in Laravel 4. L5 has made the statics easier to ignore if that is not your thing.
But after understanding the Facade pattern that is widely used by the framework, I've concluded that the use of the static method calls is not an antipattern at all.
It really is less of an antipattern in PHP than other languages. With every request being its own process you don't have to worry about singletons as much, and as long as it's easy to swap with mocks/fakes/whatever it's all good.
Laravel is the shame of modern PHP - ZERO OOP, almost all methods are static, no DI, array-oriented programming everywhere, a lot of hardcoded "new" (so you can't mock and test).
Having watched Laravel 5 throughout development, I'm personally unhappy with the fact that most of the nice features of Laravel have been removed.
For example, the default version of Laravel 4.x shipped with the "Whoops" PHP stack trace view, which is far superior to the L5-default Symfony stack trace view. Other features were removed too, including the HTML library. Blade tags were changed for no reason.
Overall, it feels like instead of adding requested features, Taylor decided to redesign the architecture for no reason.
The "architecture" change is the bootstrap repository, which has a new folder structure. I know, scary stuff! Folders!
The "architecture" has some enhancements to middleware and fleshing out events/commands to a "command bus". Basically, you get more sugar on top of the (mostly) same architecture.
Whoops caused a lot of headaches behind the scenes, and did stupid things like convert ALL http error responses to 500, even on a 404 error (which showed up in Whoops, as HTTP errors are converted to exceptions within Symfony's HTTP stack).
Blade tags have one new tag, and the old ones still works.
This point might be the subjective one - HTML library. HTML libraries create an enormous amount of support for people's edge cases and generally are better pushed out as a third-party add on to suit your needs. The upgrade guide explains how you can add them back in if you want. https://github.com/illuminate/html
That's a shitty explanation for dropping Whoops. The first time I remember the discussion of it being dropped got brought up was because of a bug in the framework relating to the assets, where Taylor didn't hesitate to blame Whoops and deleted comments on Github pointing out that the problem was actually in his own code.
It would've been super easy to add some code that sets the HTTP code for Whoops's response if that was the problem - but the fact is you should demand your framework users define their own 404 handlers.
The old Blade tags now escape all HTML, that hardly counts as working.
You can easily change the config to make the Blade tags work as they previously did. I'm unhappy about this change as well though. It's very reminiscent of some design decisions PHP has taken:
1. Create feature X.
2. Users don't understand feature X, and use it when they should be using feature Y (for safety.)
3. Update the API so that feature X does what feature Y did, and create feature Z that now does what feature X did.
4. Old users using feature X incorrectly are now protected, while users who correctly used feature X must now convert to feature Z.
Not being familiar with Laravell, having a look at[1], I see what you mean:
> In Laravel 4 Blade included the following two styles: {{ and {{{.
> The double curly bracket was a raw echo and the triple curly bracket escaped.
>
> Now both the double and triple curly brackets escape the variable and a new {!! $var !!} is for raw.
I'd argue that having unescaped output be shorter/easier than escaped output was probably a design error in earlier versions -- but I'm not sure I like the "fix"... If it was a green-field design, I must admit I like the "danger!"-feel that unescaped output has in L5 though.
The single maintainer just didn't want to maintain them, which goes to show how Laravel really just is his personal project that got really popular, not a community-driven effort.
I don't know the reasoning behind the decision to not use Whoops by default, but I considered the beautiful and informative error pages to be a nice trait of Laravel that I will miss. It is also a feature that almost anyone who has used Laravel has come in contact with, so I am sure that it will be widely missed. I remember a non-developer coworker who was using Laravel 4.x for the first time commenting on how it was one of their favorite features.
I usually add the Raven PHP client [https://github.com/getsentry/raven-php] to report errors to Sentry when starting a new project and will likely do the same with Whoops by default.
I really like Laravel, it makes getting things started easier. I am glad I finally have a good way to manage my assets from within Laravel so that I don't have to deal with all of that myself every time. The only thing I find Laravel lacking is Web Socket support and every time I tried to implement something I would basically give up and switch to Node.js. Is there anything that can get web sockets working in Laravel?
I love the `Architecture Foundations` section in documentation [1]. I wonder why more frameworks don't do this. It happens a lot that I have no idea where to put files when I start with some frameworks. I am still not sure how good it is but I am reading through it right now.
There are 2 main packages of reusable components in php. Symfony and Zend.
Somewhat confusingly Zend and Symfony also make frameworks built on top of these components. But you can use the components on their own. Use the Composer to install the ones you need. You don't even need a framework to use them.
Laravel is built on top of Symfony components.
I think the main advantage to Laravel is people who use it really tend to like it... a lot. I hear a lot of complaining about other frameworks, but Laravel people enjoy. People that figure it out tend to get sites up really quickly. The main downside I hear about is performance.
For me documentation is key. I tried using Zend components, and while they worked I find the documentation really lacking. Zend have some great stuff like an api builder, but documentation is really important and its why I'll probably end up trying Laravel
Having worked with Kohana, CodeIgniter and WP, Laravel is the reason I started writing PHP again. Also being a node developer, Laravel feels at home with Express(both influenced by Sinatra).
Artisan command line utility, Migrations for DB version control, Blade template engine and the neat directory structure are some of the things I like apart from the community ofcourse
I just started with Laravel and can't compare it really well to the other frameworks, but this is what I like so far:
- it's well-documented
- it has an active community
- I simply enjoy working with it. It feels lightweight, although it probably isn't, if I take a good look at the "vendor" folder and the dependencies
- I get stuff done relatively quickly
Edit: So I started porting my small Laravel 4 project to 5 and to be honest, my first impression is: Laravel 5 is more like Zend Framework than the small and nice PHP framework. It lost a bit of its lightweight flair for a potentially more structured architecture, but I kind of hate to put everything in "Service Providers" and "Middleware" and whatnot.
E. g. before, you had a folder "app/controllers", now you have "app/Http/Controllers" and "app/Http/Middleware" and "app/Http/Requests". While this might make sense for bigger projects, it also loses a bit of its lightweight charm.
With Laravel 4, things seemed to be more straight forward.
As some other commenters wrote - there's not that many differences with Symfony approach-wise. But it's more fun to write code in Laravel, Symfony on the other hand is incredibly verbose which is not a good thing in my opinion. You have to write way more code to achieve same thing in Symfony compared to Laravel.
Laravel has very reasonable and easy to understand structure and you don't need to use .xml or .yml for configuration.
I've had experience in CodeIgniter, Symfony, FuelPHP and I've been sticking with Laravel for over two years because of how simply nice it is to work with.
Over cake, it's modern, widely used and supported.
Over Symfony, not a lot tbh (large parts of Laravel are built on Symfony), it's a lot more opinionated out the box than Symfony and Eloquent has a flatter learning curve than Doctrine.
The framework found a new home and its now under active development again. Unfortunately, since v3 which is still not officially out, the framework has fallen behind its competitors.
It wouldn't be the first time. When Laravel 4 came out, they decided the best way to announce that would be to make all the old URLs for Laravel 3 documentation point to Laravel 4 pages, and then take down the Laravel 3 documentation completely.
Yes. Completely. Not just "put it in a less prominent place" or "hide it six levels deep in the directory hierarchy" -- it was gone, overnight. Poof! Vanished.
I happened to be in the middle of a Laravel 3 project at the time, so the sudden removal of all documentation for the version I was working with was more than a little painful.
- Blade templating language. I don't need yet another templating syntax to learn, especially one that isn't analogous to others I know and are common among other frameworks.
- I really can't imagine going back to an active record based ORM. I've learned too many hard performance lessons from Doctrine1 and rails at this point.
- Facade/proxy pattern based classes. I think as they are implemented in the actual framework, these are done correctly. However, I think the userland understanding of this pattern is often lacking and leads to a lot of glorified singletons that are some how touted as acceptable because they call them facade/proxy based.
In the giant lineup of frameworks, ranging from something as simple as SlimPHP or silex, all the way to enterprise targeted frameworks like Zend Framework 2, I just don't see why I'd ever pick Laravel as the go-to solution in any use case.
All the major frameworks are just as decoupled, but as soon as you start selecting off the "native" defaults for things like templating and ORM you lose integration features that have been built into other areas of the framework to support that specific library.
Ive been so excited about this! Though I kinda miss the call to action buttons that they had on the old site. Scrolled down the page looking for the quickstart button before I had a "duh" moment and clicked on documentation.
Sure. PHP, especially post 5.4 has matured a lot and offers as many niceties as your favorite blub language. It has its warts, but at this point, nothing worse than what Javascript has for example.
That said, while you can write beautiful code in PHP, IMHO, Laravel is not that.
It full of "string typing", over-applied and mis-applied Design Patterns, and poorly thought abstractions.
It just saddens me that Laravel is considered well designed and advanced codebase, or, worse, a standard of how PHP should be coded.
While it's not as bad as the Wordpress spaghetti, it is mostly Java EE (circa 2004) in PHP, sans the strong typing assurances (and, fortunately, sans the gobs of XML too).
On the other hand, Laravel works and has a strong community going for it, which, as in the case of Wordpress, makes all the difference in the world.
A lot of the over engineering in Laravel comes from Symphony, which in turn inspires how Laravel is built. And with the Proxy pattern in use everywhere, it inspires high coupling in your code in a way that doesn't quite look like coupling but is nonetheless.
I would argue that Symfony is well engineered, not over engineered. The fact that Laravel is already at version 5 demonstrates just how poorly engineered it was in the first place.
That's an odd argument. Is Rails poorly designed because it's had 4 versions, or Django because it's had 8? Seems much more to do with the pace of the development than the architectural quality, to me.
EDIT: It depends on what the versioning represents.
I don't think there have been as many breaking changes in Rails vs Laravel, and Rails at v4 has been over ... 9-10 years? Laravel is < 6 years old, with, from what it seems to be, rather significant philosophical changes between major versions. Doesn't mean it's bad, but perhaps closer to using gentoo vs centos.
When I tried SF2 I found it to be a terrible, Java-like, pile of abstractions. This might work for some people, but if you prefer thinking about business logic (as opposed to "where do I extend this IoC dependency container so that it can find my ControllerFactory), it's not for you. It left me bitter.
Yii is supposed to be nicer, I heard from colleagues, but I left PHP programming the moment I saw the opportunity so I can't vouch for that.
Extending the IoC container?? A ControllerFactory?? You never do anything like that in Symfony. The thing I appreciate most about Symfony2 is how it enforces good design patterns.
One might argue that the SOLID principles applied in Symphony and inherited by Laravel are in fact anti-patterns which only serve to add massive cognitive overhead. They've wrecked countless Java projects over the years and are now going to do PHP the same favor.
There's even less reason for a scripting language with a GIL to be saddled with this level of complexity, than there is for Java.
Much of the complexity in Symfony comes from its "dependency injection" component (a misnomer, really) and the inclusion of annotation magic in the standard framework distribution.
These days, I'd rather use the basic components (e.g. Symfony's HttpFoundation library) with something like league/container (formerly orno/di) and a simple routing library like nikic/FastRoute.
> They've wrecked countless Java projects over the years and are now going to do PHP the same favor.
Oooh do enlighten. I made an argument when Symfony2 first came out that PHP isn't Java, and now I've been brainwashed to think the Symfony community is right.
Very refreshing to here an alternative point of view :)
Can you elaborate on "the SOLID principles [...] are in fact anti-patterns"? I don't see this point of view exposed often, can you point me to some resources in this regard?
Take a look at phabricator's source code, which was originally developed in house at facebook but is currently open sourced. It's not using any of the big MVC frameworks, but it's very well written (despite using PHP 5.2 compatible only syntax) and I think a good example of a well designed PHP codebase.
Though the Symfony2 community hasn't been open to criticism and suggestions for improvement.
And eventually, when they've taken some of the original criticisms on-board (at v2.6) [0], they themselves get shot down by parts of the community for spoiling the architecture.
https://laravel-news.com/2015/02/laravel-5-released/
It might be a better way to get an overview of this release as it links to various other articles about v5.
An article specifically on the changes:
https://laravel-news.com/2015/01/laravel-5/