gistfile1.txt

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:

- https://github.com/laravel/framework/pull/1799
- https://github.com/laravel/framework/issues/1963
- https://github.com/laravel/framework/issues/2089
- https://github.com/laravel/framework/issues/2234
- https://github.com/laravel/framework/issues/2243
- https://github.com/laravel/framework/pull/2564

Hostility and/or trolling in issues, with a couple of regulars that are made no
effort towards silencing:

- https://github.com/laravel/framework/issues/3132
- https://github.com/laravel/framework/issues/1820#issuecomment-32828170
- https://github.com/laravel/framework/issues/3134
- https://github.com/laravel/framework/issues/3295
- https://github.com/laravel/framework/pull/2952

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.

https://github.com/laravel/framework/commit/73c3c18787838881b9a78b46c66f16f872d1214d#commitcomment-5133770
Taylor removes a public filesystem function in a bugfix release because the core
framework isn't using it anywhere.

https://github.com/laravel/framework/commits/v4.1.16
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.

https://github.com/laravel/framework/commit/1d0add9955e932a5bfb3900a3c99ee94455ebc3e
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.

https://github.com/laravel/framework/commit/04253bd4d3a188af39f2b6b4beb95849a91943ce
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.

https://github.com/laravel/framework/commit/3816e425ae3fdaa69474763737d5e906e073c9a9
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
Manager::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.

"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."

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.

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.

The wild troll in his natural environment.

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! 😄). It's been pulled out of the flame for perhaps the last time and is now being sharpened and honed to perfection. It's got enough of an edge to cut through the bush, but at the same time, enough of an edge to cut the swordsman if not wielded correctly.

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.

Every project had good/bad. If you can solve the problem with the framework use it.

tl;rd: Young project has growing pains.

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.

As far as UserScape goes random business needs aside we don't plan on changing the time we give Taylor to work on Laravel. I think Phil covered the rest of the points sufficiently.

RIP Laravel. Goes and installs Backdrop CMS

@bgallagh3r phpnuke still alive.

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.

Well said.

I can't believe how rude they are to other developers, no wonder the php community is so sparse compared with node/ruby. It's people/responses like those listed above that scare people away from getting involved, they are part of the problem.

@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.

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.

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.

Re: trolling

I saw first hand (on one of my issues, in fact) a few troll responses that were deleted after a day or two, with no comments or mention of it.

"Choosing a framework is a bit like choosing a wife, for long term."
I agree with this. Nothing is perfect. If you think it is not perfect, fork , fix and make merge request. Or make your own.

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. :)

hahahaha @nmabhinandan awesome 😄

Not much has changed ... my findings from the last review I made for a project

• laravel/framework#2085
• laravel/framework#17508
• laravel/framework#7889
• laravel/framework#14763
• laravel/framework#8840

... and decided against Laravel.