-
-
Save anonymous/8565929 to your computer and use it in GitHub Desktop.
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. |
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.
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.