|There are a lot of complaints going around about Laravel these days, but a lot|
|of the important ones seem to be missing from the spotlight.|
|Bugfixes, issues and pull requests being left open for months with no|
|clarification of intent:|
|Hostility and/or trolling in issues, with a couple of regulars that are made no|
|effort towards silencing:|
|Laravel is a one man project run by Taylor Otwell exclusively, and there is no|
|interest in changing this. The community is fortunate enough to have Taylor's|
|employer give him one week of dedicated Laravel time per month. Laravel's future|
|if/when its author's position should change is uncertain to say the least.|
|Again, there is no organization or company behind the framework, everything is|
|privately owned by Taylor.|
|Dealing with criticism: https://twitter.com/taylorotwell/status/422837742716727296|
|Laravel being a one-man show: https://twitter.com/taylorotwell/status/420577120188768257|
|There is no process around the development of Laravel - changes and features are|
|added and reverted as Taylor sees personally fit with no intent of following|
|semver (semantic versioning), no intent of imposing feature freezes to minimize|
|the number of bugs or to do long-term support on older versions of the|
|framework. No changelog between minor versions are maintained, and short of|
|crawling the commit log there are several bugfix versions without documented|
|changes. Bugfix versions are of course not that as most new features are|
|introduced not as a minor version on a developing branch but on the main stable|
|branch tagged as bugfix versions.|
|Taylor removes a public filesystem function in a bugfix release because the core|
|framework isn't using it anywhere.|
|Taylor renames a bunch of core classes in 4.1.15 but changes his mind in 4.1.16|
|which is released few minutes afterwards.|
|After 11 bugfix versions, backwards compatibility methods are added to Route/|
|Router, but only after a pull request for it was up.|
|Undocumented in 4.1 - Sessions and cookies are refactored into application|
|middleware and the default native driver is silently replaced with the custom|
|file one, causing lots of upgrade issues.|
|Right before 4.1 release, URL generation is largely rewritten to allow for query|
|strings, causing several bugs. On the same day as 4.1 release, 4 bugfix versions|
|are released mostly to deal with these. After 8 bugfix releases, Symfony's|
|routing component is brought back in to fix most issues.|
|In version 4.0.8, the session store's IoC binding is updated from 'session' to|
|'session.store', breaking several packages.|
|After the launch of 4.1 the idea of Laravel expansions - paid packages/plugins -|
|was announced, along with a statement that the framework is now more or less|
|complete, confirming the fears that the open source bit of the framework is|
|being further downprioritized.|
|Laravel comes with a ton of __call and __callStatic methods that are very good|
|at hiding the underlying architecture of the framework, and the documentation|
|does a poor job of explaining this. New users will not know that MyModel::foo()|
|under the hood calls (new MyModel)->newQuery()->foo() unless they read and can|
|understand the source code. Calls to facades like DB:: and Session:: are usually|
|redirected from the Manager class to the underlying Connection or SessionStore|
|classes, but if you call an undefined method you still get "undefined method|
|If you're a hobbyist developer, the framework is fine, but you can get an|
|equally intuitive and developer-friendly framework out of Django or Ruby on|
|Rails - without having to deal with breaking changes in "bugfix" versions, and|
|with the guarantee that these frameworks will have a lifetime of up to decades,|
|while who knows what Laravel will be doing in a couple of years' time. If you're|
|a dev team leader or project manager, the lack of response and blatant disregard|
|for maintaining stability in the framework should be a serious warning sign.|
You guarantee Django and Rails will be around in decades!? Who do you pick in this year's Superbowl? I only live a 5 hour drive away from Vegas.
I believe every framework (supported officially by a compnay or not) is going to have trade-offs. I personally enjoy the 'feel' of Laravel as a framework coming from an environment that regularly worked with Zend and Codeigniter, but I do see the overall concerns. In fact, we recently moved a few of our production applications to 4.1 and did hit a few hiccups. However, we protect ourselves with a solid development process for handling this issues. We were building 4.1 as soon as development releases dropped and had most of the kinks worked out. This is really no different than should be expected in any application-space.
In my opinion, the REAL problem is when you let a framework become a giant squid, working its tentacles into every aspect of your application domain and choking it out (thanks @chartjes for the analogy, I've used it a ton). This is a problem with how all frameworks can be used, no matter full-stack, mini, etc. I believe the effect is lessened with a component-based framework like Laravel, Symfony, etc. simply because at least at that point, you have the opportunity for more control in how you interface with each component. For example, Laravel's facades are a topic of heated discussion recently it seems (from posts I've seen on reputable blogs). In my opinion, Laravel's facades are a helpful hint to abstract the interface between your application and some foreign package.
Laravel promotes ideas you'll find in reputable literature (SOLID Design, DDD) but is not forcing anything down developers' throats. It's almost like a "framework for best practices". That said, Laravel (to me) is like a sword being forged by a lone blacksmith (and a bunch of apprentices!
When I cut myself cooking (with my sword), I don't blame the sword. I blame myself and realize that I have not achieved mastery. Likewise, placing ultimate dependence on a framework to the point that we're blaming Laravel when we back ourselves into a corner makes no sense. Instead, it's the communities job to point folks who have not yet mastered the skill-set to the appropriate literature. It's our job to write packages that embody these best practices.
In the end, I completely understand the hangups in "schizophrenic development" and other things you've listed above. However, I believe it better to solve the root of the problem. A stricter development process fixes the "unexpected issues" between framework upgrades. More experience in software architecture solves the problem of framework dependence.
All in all, I love Laravel to death RIGHT NOW but I am already prepared (as are my applications) to move to the next hotness if the need arises. Every good thing comes to an end. Thanks @taylorotwell.
@KoenDG The original poster goes on a 700+ word tirade, anonymously, about the character of Taylor Otwell and the Laravel community. Meanwhile, I make an admittedly sarcastic but true comment regarding his stance and I'm the troll? Come to think of it, I'm thinking maybe you were trolling me.
I'm all for criticism and I think it is good, as it does have it's place in open source. But, not having the guts to put your name to it is weak and makes anything said sound cowardish and whiny. Laravel is not forced upon any PHP developer, if you don't like it don't use it. I personally like it thats why I use it. 'nough said.
@EwanValentine not sure where you get "php community is sparse". I have seen the same issues in both ruby and node lately, every community has its outcasts or its dirty laundry. The PHP community is huge, is very articulated, very supportive and i'm saying this from the point of view of someone who had to depend on community when my life went upside down.
I agree that this way of handling the situation is horrible, but it hardly reflects on the PHP Community, or even the Laravel community in general, no need to take up to that level.
Anyway, off topic, but as a serial UG creator and Community nut i just want to separate these topics.
Choosing a framework is a bit like choosing a wife, for long term. Nobody and nothing is perfect in this world including open source projects, you have to admit that and learn to deal with the imperfections to make it work out.
I use Laravel in more than 30 production apps and haven't had any real problems despite the upgrades/version changes whatnot. It doesn't bother me that there are changes under the hood as long as syntax is well documented.
With Laravel becoming #1 open source PHP framework on Github three weeks ago no wonder there is a lot of ripples, the framework will be tested and refined by fire(take this gist and some other criticisms, some of which are true) like gold is refined and the framework and community will be purified and become more solid than ever.
Thank you Taylor and Ian and the community for making this framework possible.
I can vouch for the upgrade issues. I've been banging my head on my desk for weeks trying to figure out why cookies no longer persist across subdomains. It worked fine in 4.0.
The fact that the Laravel framework is still very young aside, and that I think it is a fantastic tool in any PHP devs armoury (yes just part of an armoury, we all know you need a few).... What I think is the single most outstanding feature is that the framework is actually making best practices available to those who wouldn't normally use them.
I have a team of mid level devs, and the fact that Laravel allows them to use its power without forcing them into strict development patterns is a HUGE contributor to their development. As their confidence grows in using the framework, so will there ability to master the more advanced techniques used under the Laravel hood, but without the proverbial fish slapping there face every time they don't use them from day one.
To me, Laravel is a swiss army knife of PHP, lots of tools with lots of uses, YET it's a swiss army knife made in partnership between Fisher Price and Priest Gorō Masamune.... Simply accessible to all skill levels :)
On behalf of me and my team, I am extremely grateful that Taylor has spent, and does spend the time he does on developing the framework... And of Course @ianlandsman for providing him with said time of course :)
I think this is great, I have a gist to look at hilarious responses to PRs and Issues, it's like Laravel bloopers. lol Other than that this has no value, Laravel is a great framework and nothing is perfect. I think in development there is always a margin for error as there is always human error, the key is reducing the the margin as much as possible and dealing with issues when they do occur. Laravel is very resilient in this sense and I believe in the practices Taylor and other contributors try to incorporate. Thank you Taylor for a great framework. :)