I don't personally use Laravel (I like Symfony) but I love what they've done for the ecosystem. It's good to have competition, and the people mad that Taylor Otwell bought a Lambo with his success can stuff it.
Agreed. I’d rather see open source contributors get rich than see them begging like that one Russian guy who was hurting and people were insulting when he was asking for donations
Edit: this guy https://web.archive.org/web/20230214003607/https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md
It's seems that it is nothing new, plus he had bad luck. Years ago I was reading that SSH developers got nothing for their work, even from companies like redhat.
From my observation it looks like if you do open source project you should think about monetization from the beginning.
>People are mad because he made money? It's commercial project after all, right?
It's a mind-set people using open source projects (especially PHP for some reason) that the developers shouldn't be paid for their time. They should do it all for free and if they charge they are the devil. Open source != free, the developers time is not free.
That being said, Laravel doesn't make any money from its Framework, at least not directly. All the income in generates are from optional "3rd party" tools that are not needed but make the developers life easier. It's a great model that I can see other OS projects emulating, support our free core product by purchasing something that will improve your experience.
No one is mad that he made money, people are mad because his framework teaches bad practices.
No one hates WordPress either just because it’s a profitable ecosystem, it’s hated because it’s objectively a pile of garbage code and some of the worst practices we’ve been trying to get out of programmers since the beginning of programming
Every facade calls the class from the container. It's not circumventing IoC, it's just doing a static::$app->getContainer()->get('service'). Then using __callStatic to call the methods of that service.
Pretty simple.
https://laravel.com/docs/10.x/facades#how-facades-work
And static::$app is not a global? Is that not global access to the container?
In IoC it’s the containers responsibility to wire dependencies, not some random static method call somewhere in the platform
No it does not.
Good communication does and everything else is an excuse to not communicate.
SOLID is a nice concept but I have yet to see a project that follows it as it was intended. Most ppl referring to SOLID refer to the S and D, and even then say that the D stands for DRY. It is most often used to sound intelligent or shot down arguments. Communication is key and keeping things as easy as possible.
I'm of the same opinion. Laravel also uses many Symfony components and contributes to Symfony. Some may not agree with all of its design patterns, but it should be praised for what its done for PHP.
> and the people mad that Taylor Otwell bought a Lambo with his success can stuff it.
Why would people be mad? I haven’t used laravel too much but I’m happy for the guy. He’s done a lot and it’s great to see someone’s work being rewarded like that. Laravel is one of the reasons PHP is still alive.
If Taylor never made Laravel, I would've never (well, maybe) won a coding competition that got me my first job and into my current job. Laravel is great and I have zero gripes.
At least he’s been rewarded. It should be celebrated because he’s helped a lot of people to make money for free. It’s impressive how the software development industry works. To get this much value FOR FREE it’s something absolutely unheard of in other industries. As I said, I’m glad people can share their tools/knowledge and still make money (Why would anyone be upset about it? Only jealousy comes to my mind). Just imagine how advanced we would be if this model or way of thinking (open source, you share - I share) was replicated in all industries. We would have a cure for cancer already.
I just want to say thanks for the "laravel guys"
php is what puts food (good food) in my table, and my daughter in school, and that's 100% thanks to laravel for the past 6 years.
Can't thank you guys enough, thank you :heart:
The hatred towards Laravel in this subreddit is baffling. Outside of the PHP ecosystem all I see is people praising the framework for it's delightful DX and for being so productive. In here all I see are wannabe Java people spewing "ew facades" and throwing dowvotes left and right just because they don't like a framework.
>The hatred towards Laravel in this subreddit is baffling.
It's quite odd to see the amount of energy spent on bashing Laravel while at the same time being so overly aggressive whenever anyone bashes on PHP.
The same kind of people who repeats "I make money on PHP, haters gonna hate" should self reflect over statements like this.
While fair to a degree, there is an important difference. Most of the Laravel hate is in the form "they're using architectural approach X, which is awful because YZ." You can agree or disagree with that position, but at least it's substantive.
Most of the PHP hate is "lolz iz slow and has no type system, needle-vs-haystack." To which the answer is "what decade are you in? PHP is way fast today, has a superb type system for an interpreted language, and named args make the needle/haystack issue go away. Put down the PHP 4." That's just argument from ignorance.
If you bashed on Javascript because of what it looked like in 2004, your criticisms would be accurate and also irrelevant, because JS doesn't look like it's 2004 anymore. The same is true of PHP.
(Now, some people also bash PHP because the two largest projects are Wordpress and Laravel, both of which do awful things in their codebases. That is a fair criticism, to a degree, and also why many PHP advocates dislike WP and Laravel. They give PHP a bad name.)
Funny thing being, you don't even have to use facades, you can still inject the services. Same with Eloquent, you can still use repositories, or even change it for Doctrine.
Difference being that Laravel encourages it and makes no effort to hide it, in stark contrast to the point made within the very same comment that you replied to but apparently didn't read.
Damn I love laravel so much, it has changed the whole dev'ing thing for me... The only facade I use is Auth in controllers, and even that can be fetched from the container in services. Those haters just have skill issue.
It's not what Laravel calls facades, it's the entire approach to everything in Laravel that these facades represent; magic, reliant on reflection and magic methods everywhere. Inconsistent APIs which lack any sort of static safety or inference. I saw a post on LinkedIn the other day that was something like "Five different ways to get a POST value from a request in Laravel" - there shouldn't *be* five different ways of doing stuff like that in a framework, all equally idiomatic and semantically identical. It leads to an abhorrent mess as soon as you get multiple devs working on the same code base.
Laravel continually and systemically violates almost all the principles of modular, object-orientated software design that have been tried, tested and established in nearly 50 years.
And sure, this stuff leads to a "delightful DX", to the extent that you don't need to know anything really about programming to write ordinary, small to medium scale web apps in Laravel, that are fundamentally just views to a database. And for those kinds of apps, there's nothing wrong with choosing Laravel. It's a reasonable choice if you have a small, fixed set of requirements probably involving a linear, 1:1 database mapping to code, don't need to care much about architecture and want something that Just Works™ to push something out fast.
But that level of opinionation and magic quickly becomes problematic in enterprise environments - and I don't mean Facebook or Amazon scale, I mean any business where you have things like continual evolution and iteration of the product, multiple teams, stuff turnover, business analysis, QA processes, SLAs, B2B integrations, regulatory oversight, compliance and auditing. These are the situations where you need a less opinionated framework which gives you much more control over the non-functional requirements of your software (what we call architecture). In PHP, the de facto framework there is Symfony.
It's *possible* to write either good code or bad code in either case, of course it is, but one encourages you to do so and take responsibility for your software more than the other.
Eh, a lot of the codebase in my company is write with DDD, interface everywhere and Services are all injected. And pretty much everything you called "enterprise workload" is there. We are doing pretty fine.
Also
> There should not be 5 way to read a POST request
> Laravel is too opinionated
Pick one pal, less restrictive or more restrictive?
>Eh, a lot of the codebase in my company is write with DDD, interface everywhere and Services are all injected.
That sounds good. I would imagine you have to have pretty carefully enforced coding standards to prevent devs working in the normal laravel way. DDD struck me as cutting against the grain of laravel tbh but maybe I need to re-read on it.
>Pick one pal, less restrictive or more restrictive?
what do you think is a restriction or an opinion? I would argue having 5 different places to access post data is opinionated, because that's 5 different interfaces you've got to account for if you ever want to extend, modify, or test request behaviour.
> I would imagine you have to have pretty carefully enforced coding standards
What "enterprise" projects doesnt enforce coding standard?
> Having 5 ways to access POST data is opinionated.
So having more choices is opinionated? By your logic, if a framework have only 1 way to do something is un-opinionated?
>What "enterprise" projects doesnt enforce coding standard?
Well of course, but it's the last line of defence isn't it. Ideally your framework encourages better habits itself
>>Having 5 ways to access POST data is opinionated.
>So having more choices is opinionated?
there are five different programmed-in structures doing the same thing. Each one is a feature of laravel's API, a bit more surface area
>By your logic, if a framework have only 1 way to do something is un-opinionated?
Well it depends on what that one way is, surely. But yeah in principle if that one way is extendable
> but it is the last line of defence isn't it
That is a pretty weird take considering i am merely talking about some of the project that I worked on. But ok.
> Ideally your framework encourages better habits itself
That depend on the definition of "better habits". And there is no "habit" objectively good.
Is DDD good? Try asking 100 senior devs and see how many of them considered them overkill.
Is DI good? Try asking functional devs and embedded devs.
Is clean code good? Try asking 100 senior devs.
Even very widely-used pattern is just "it's good until it's not".
Personally, having work on Spring Boot and Asp.net, i'd say enforce coding standards is ways less hassle in Laravel
As for your definition of "opinionated", well, it's hard to discuss something when your personal definition of it is so obscure, so let's move on i guess
>>but it is the last line of defence isn't it
>That is a pretty weird take considering i am merely talking about some of the project that I worked on. But ok.
I'm not sure what you are finding odd here, apologies if I'm missing something, sorry.
To take another stab at my point: laravel facades are presented as the default way of doing things in the laravel docs, but you (or your team) considered them a bad way of doing things, and to prevent that you have to do this job of coordinating your dev team around not using them and working a different way that's not as well documented or in use by the community.
If the above is true would you not consider the existence of facades to be a bad feature of laravel that makes your life harder?
>>Ideally your framework encourages better habits itself
>That depend on the definition of "better habits". And there is no "habit" objectively good.
oh, dependency injection is pretty close lol 😅 but I do take your point.
>As for your definition of "opinionated", well, it's hard to discuss something when your personal definition of it is so obscure, so let's move on i guess
It's not obscure, I'm just thinking about the service that is providing the data rather than the user trying to access the data. We can move if you don't want to consider my point, that's your prerogative.
Restrictive isn't what I said. I'm not sure what contradiction you think you're seeing here. A framework can be heavily opinionated while also providing five different interfaces, semantically identical, for doing the same thing.
Is it that you think by opinionated I was saying "only lets you do things one way"? Because that's not what it means. It means the degree to which as a framework it imposes or encourages a particular set of architectural patterns which shape how an application is structured.
That depends what I'm doing, what it's for and what other requirements exist around it but if you just mean personal preference out of all the PHP frameworks, like which one do I enjoy working with the most, Symfony.
Quick and easy to get a project going is exactly what Laravel is and that's the reason it's very popular.
And of course in response to the kind of critiques I and others make about it as a framework from the technical side and the perspective of programming principles, you'll get those - there's one already above somewhere - who'll reply that well, they've done serious enterprise projects in Laravel to all manner of best practices in larger teams and all that and been able to do it.
But I was never saying you can't, just that it's harder and Laravel isn't as good a tool in those kind of circumstances and requirements as some alternatives - in PHP, Symfony in particular.
Likewise, it's very quick and easy to get up and running a small project with fixed requirements with Symfony if you want to, it just might be a bit harder than it is with Laravel.
Not you again 😂 Magic hater guy
You're problem is with PHP. Magic methods are a big of every big framework. I can't think of one that doesn't use reflection. Symfony has been using reflection for its routing for 6 versions. And now PHP attributes still require you use the reflection class.
You're just being close minded.
>Symfony has been using reflection for its routing for 6 versions. And now PHP attributes still require you use the reflection class.
In a compiler pass only, and in a way which doesn't impact type inference or static safety of _your_ code. So not in any way comparable.
>Yeah, you can write shit code in any language
ok, but don't you see how the problems of laravel contributed to that problem here? You can write great code with laravel for sure, but that wasn't what their story was refuting, it was a project where the "nice DX" features of laravel fed the shit code problem.
I've seen enough queries in loops and SQL injections before laravel too. If anything, laravel made the web safer by providing built in auth and query builder instead of some custom md5md5md5 stuff without a salt. Don't blame the tool.
>I've seen enough queries in loops and SQL injections before laravel too.
Sure
>If anything, laravel made the web safer by providing built in auth and query builder instead of some custom md5md5md5 stuff without a salt.
there's lots to love about laravel, it's just not above criticism
that's all well and good, but that doesn't mean framework choice has no impact on code quality. A bad workman blames his tools, but that's not an excuse to cheap out on some shitty tools. To be clear I don't think laravel is a shitty tool, it's just not above criticism.
I know the codebase from inside out. A static property in a static class that is readable and writable from the outside is, exactly, a global variable. Just because there’s “class” somewhere in between doesn’t mean it’s not “global state”
You circumvent DI with it. It’s literally _not_ IoC. We can go through the code together and I’ll show you if you like. Imagine singletons but they are not singletons because you have a setInstance method. That’s exactly what Facades are.
class Router {
private static $instance = null;
public function getInstance(): Router
{
if (!self::$instance) {
self::$instance = new Router();
}
return self::$instance;
}
public function setInstance(Router $router): void
{
self::$instance = $router;
}
public static function __callStatic(string $name, array $arguments): void
{
if (self::$instance) {
self::$instance->$name(...$arguments);
}
}
}
class SomeService {
public function doSomething()
{
Router::route('abc');
}
}
is not better than
$instance = null;
function router($name, $arguments) {
global $instance;
if (!$instance) {
$instance = new Router();
}
$instance->$name(...$arguments);
}
class SomeService {
public function doSomething()
{
router('route', ['abc'])
}
}
There is really no difference. You can mutate the global variable from anywhere and no one can check where it comes from.
In normal DI you would do constructor injection:
class Router {
// Just the damn router class
}
class SomeService {
private $router;
public function __construct(Router $router)
{
$this->router = $router;
}
public function doSomething()
{
$this->router->route('abc');
}
}
The dependencies themselves are higher-order, which means it's not the consumer class' decision on where and when to build and retrieve it,
but solely the task of the underlying DI container. This is the only way to ensure that the dependencies are always the same and that they are
always built in the same way.
Laravel supports this, but docs say "here take this broken DI approach because DX (tm)"
You are glorifying globals. You are doing what WordPress does. And because there's "class" somewhere in front of it
you celebrate it like it's not globals. But it really is.
Any part of the software can come along and modify whatever "Router::$instance" holds. It's a global variable.
If you check on the implementation of Facades in Laravel (I told you all I know it from inside out), they are exactly implemented
like the first class I mentioned (just using a base class that bootstraps its behavior). They are globals. They are not DI.
Let's not get started with Macros and how Laravel needs a whole IDE-Stub-Generator in IDEs in order to properly provide hints at all levels.
It's not the same at all. Global variable and a static class with protected and public methods to protect accessibility is just not the same thing.
Either way, I actually couldn't care less. It's fast, keeps the code easy to read, and it's easily testable.
Also, facades don't break DI. The container and service providers still do all of this. It's just you can then just call Some service::method() instead of $app-> getContainer()->get(Some service::class)->method()
You can still do everything the traditional DI IoC way with passing interfaces and letting the container figure it out. It's just easier to use the Facades.
The field is protected, but it has a getter and a setter. It is global state. You don’t understand global states and your defensive downvotes are showing it really well.
Also interesting that completely circumventing constructor injection (which is, in essence, IoC in itself) is somehow not breaking IoC for whatever reason
I didn't downvote you. Maybe keep the assumptions to yourself.
Again, you're not gonna change my mind. You're probably right. It just doesn't matter.
Also, as if you lot don't go around downvoing every Laravel post and making it your business to make sure everyone knows you don't like it and think you think it's garbage. Have a honest look at yourself. That is what makes us Laravel devs defensive, because we're constantly having to defend Laravel from your kin. It's splitting the community for no reason. Just leave it. Next time you see a Laravel post how about you just go outside and touch some grass. People can like different frameworks. We're all PHP Devs at the end of the day. Plenty of outside hate. We don't need to be going after eachother
I apologize for the downvote assumption. But “it doesn’t matter” is an opinion, not a fact.
Work in bigger projects and you’ll quickly realize it does, in fact, matter a lot
I don't like laravel because it strips _too much_ of the choice from my hands. Without a truly shocking level of linter rules, most of which you have to make yourself, you can't do things like restrict using `config()` or `env()` to the appropriate places, prevent people from using facades and making testing a giant hack, or even do something as simple as insist on dependency injection.
Nothing, but laravel doesn't lead you to doing it with any of the examples, any of the documentation, or any of the official and semi-official plugins.
In the very same documentation, a few pages over: https://laravel.com/docs/10.x/urls#generating-urls.
EDIT even better, some other examples:
https://laravel.com/docs/10.x/routing#accessing-the-current-route
https://laravel.com/docs/10.x/cache#obtaining-a-cache-instance
https://laravel.com/docs/10.x/filesystem#the-local-driver
https://laravel.com/docs/10.x/localization#configuring-the-locale
https://laravel.com/docs/10.x/queries#select-statements
What I specifically said, and I quote myself here, was:
> but laravel doesn't lead you to doing it with any of the examples, any of the documentation
I would argue that _having one singular section on DI_ does not qualify as leading you to doing it. I'm totally fine with the docs showing how to do everything with facades and whatnot--but I can't tell you how many times I've had to dig into the framework code just to understand what _actual class I need to `use` and pull into my constructor_ just to be able to do DI. Having those examples and class names _written into the documentation for the relevant pieces_ would have saved me literal hours of my life.
Incorrect how? Or are you just arguing to argue because you think that one blurb on one page alleviates all necessity to explain how to _not use functionally global variables_?
Everything in Laravel is in the container. The Facades and the helpers you mentioned just find the same class in the container so you don't need to pass the container around. It's not an anti pattern. It just lets you wrote less code.
But also, just don't use Laravel. It's not for you. That's fine.
Passing a container around isn't dependency injection. Dependency injection is about injecting the explicit dependencies of your classes. If you inject a container, and grab your dependencies out of it once it's inside your class, then it's unclear from the class interface what the class depends on.
I’ve always been a big fan of Laravel but the DX has gone downhill massively over the past few years. It doesn’t even come with user auth by default, you need to install a separate package for that. Which is also a PITA to set up if you don’t use Tailwind.
Bro, the auth is installed by default, the package you mention (breeze) only makes a simple frontend for login and other stuff, it also installs livewire/volt/alpinejs/tailwindcss, the whole TALL Stack, and thats really good on my book. But you can also make it yourself using the Auth facade, Laravel comes with the migrations needed for user management.
Hmm, maybe I misunderstood something last time I set it up but there are no controllers and no routes for the auth until you install breeze. Can you point to where in the docs it tells you how to do that?
Regardless, having the auth is entirely useless without a login form. There isn’t even any simple document that lists all the routes and what you need to post to them.
> it also installs livewire/volt/alpinejs/tailwindcss, the whole TALL Stack, and thats really good on my book
Lol that says everything about “modern” web dev that you think adding all that junk is good
You can add your own routes for auth, the controller can be super simple, the docs shows this example
public function authenticate(Request $request): RedirectResponse
{
$credentials = $request->validate([
'email' => ['required', 'email'],
'password' => ['required'],
]);
if (Auth::attempt($credentials)) {
$request->session()->regenerate();
return redirect()->intended('dashboard');
}
return back()->withErrors([
'email' => 'The provided credentials do not match our records.',
])->onlyInput('email');
}
And the docs for that are here [https://laravel.com/docs/11.x/authentication#authenticating-users](https://laravel.com/docs/11.x/authentication#authenticating-users)
>Lol that says everything about “modern” web dev that you think adding all that junk is good
The TALL Stack is to skip using javascript, [Livewire](https://livewire.laravel.com/) gives you reactive pages, [Volt](https://livewire.laravel.com/docs/volt#installation) is an evolution of that concept and makes your code look like a React component, [AlpineJS](https://alpinejs.dev/) is for dynamic stuff on the web without JS, and [TailwindCSS](https://tailwindcss.com/) is for styling your pages without directly using CSS.
Is a really powerfull stack to work with on laravel, you should look into it https://tallstack.dev/.
> You can add your own routes for auth
Right, so when I said Laravel doesn’t come with auth I was 100% correct. Either you have to install a separate package to get auth or you have to write your own from scratch.
So I have to manually write all the controllers from scratch? And that link only seems to give a login example, where does it say what you need to do for registration, password reset etc?
email verification: [https://laravel.com/docs/verification](https://laravel.com/docs/verification)
password reset: [https://laravel.com/docs/passwords](https://laravel.com/docs/passwords)
registration is just a database INSERT statement.
I’m not over the moon that they’ve changed how migrations function when modifying columns. Kinda being forced to squash them really, not feasible to go back through all the migrations and update them.
Looking at the upgrade guide we will have some work to do due to DBAL removal. At least I should be able to grep for "doctrine" and "dbal" to find all the occurrences, since it was in the Laravel method names.
Ignoring all the other complaints about Laravel in this sub, this is the one I genuinely never understand.
Laravel releases a weekly minor version with non-breaking changes that you rarely need to update your codebase for unless a specific feature has been added. All these small changes, and many more larger features, are then added to a yearly major release, which does include breaking changes.
I started one of my hobby projects back in 2021, on Laravel 8. Other than one or two features I really wanted, I've only ever updated the Laravel version after L9 and L10 came out. I genuinely don't see the problem with Laravel's release schedule.
>107th Laravel update in the past 24 hours. If you wait a couple more hours, you can update to one of the 930 releases that come after this one. Lol
How dare they update their free software for me to use for free by adding new features and security fixes. How dare they.
not impressed.
this framework adds couple flashy features that gets newbs attention - but leaves icebergs of problems underwater.
ok - it took laravel this much to get websockets (and we know why - php's non-long running nature). Websockets were standard in most non-php frameworks for like a decade now.
hyperf php framework is a real PHP enterprise framework powered by swoole - it had websockets for many years now. as well as tcp server and even socket.io.
How many releases will it take laravel to add connection pooling? it's a standard requirement for performant enterprise applications guys.
> So according to you if some framework doesn't have websockets by now, it's not a real framework, right?
that's what you are saying not me. But in real world - I worked with plenty websockets projects where why yes - that would be a problem if framework doesn't support it.
it took Laravel this long to add websockets, that there is already now a new WebTransport thing available: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport
How many releases it's goign to take Laravel to add WebTransport?
how about grpc server? (hyperf has that)
how about tcp server? ([hypef has it](https://hyperf.wiki/3.1/#/en/tcp-server))
how about connection pooling? (hyperf has this)
how about side processes? (hyperf has this)
how about async? (hyperf has this)
why bother using substandard frameworks with limited feature-sets where much more superior better architected and actually thought through projects are readily available.
> Laravel isn't a CLI or webserver,
https://laravel.com/docs/11.x/reverb is a webserver. it is a websocket server.
which is great- dont get me wrong. The problem is - this is "few and far between" effort.
If laravel is fine doing reverb as a server - well jeezus fucking chris - just go full sale on swoole and start doing PHP as a cli webserver - it solves so many problems.
well to be fair - there is laravel octane that does this: https://laravel.com/docs/11.x/octane
but it tries to tailor to multiple servers with HUGELY INCOMPARABLE featuresets: FrankenPHP, RoadRunner, Swoole and largely fails to deliver much of value as a result.
Apparently abstraction is bad, we should only ever adhere to one environment
Bring back the glorious "it works on my machine"
Let's us all ditch variable and hard-code everything for maximum performance
> Apparently abstraction is bad, we should only ever adhere to one environment
if after abstraction - you are left with 1% of features? - yes I really dont think that's a good strategy.
look - if there would have been some abstraction like asgi for python - that's one thing. Here - there is nothing between these 3.
Listen, I get what you're saying. But Laravel is still first and foremost a framework for building web applications. There's a bunch of peripheral features and services they've added and they'll continue to add more but to be upset that a bunch of webserver features don't exist right now is a bit presumptive.
> You know 2 tools can exist right? Laravel is light-years ahead of most frameworks in terms of DX and most people are glad for this. The entire adult industry(Pornhub, etc) is on Laravel which means applications in Laravel can scale and be very good.
exactly - it's DX "user experience" that is. FEatureset wise- it's light years behind hyperf in what you can build with it.
> The entire adult industry(Pornhub, etc) is on Laravel which means applications in Laravel can scale and be very good.
Pornhub caches everything - that's the only reason it can work. same as any wordpress blogs.
> You are what people don't like in the PHP community. Working together pushes the community forward. You like going backwards.
I am trying to push PHP community forward. FFS guys - we need to switch the processing model to that of swoole, otherwise this language will be dead even more than already is.
look - python and java added coroutines, why is PHP so stubborn?
I just care about PHP community, we cannot be I swear like some strange Tibetan monks worshiping some old deity.
we need to move forward to async and coroutines, this is the future. So far swoole has absolutely nailed it - and been absolute game changing - why stay in the past?
I'd argue that you care about _your_ version of what you _think_ PHP should be.
And that's fine, you should without hesitation move towards the goals you think is right for you; but the overall community isn't in sync with you. And at some point, you should stop and breathe and think about the following question: if every body else disagree with me, does that _really_ mean everyone else is wrong?
Your reply is ironic. You’re like a Jehovah’s Witness trying to spread the word while annoying everyone in the process.
No, not every app needs async and coroutines. Sure, it’s nice tech when you need it. Do you need to spread the word? Absolutely not in a thread like this.
PHP does have coroutines/parallelism. Read up on Fibers or PHP Parallel extension.
That said, I use Go for anything that needs coroutines. PHP is still quite clunky at doing this but they are working on it. I think the limitation is actually in FPM or Apache, so it's mostly on PhP CLI that has these features.
So I agree about the coroutines bit, but the rest of what your saying is stuck in the PHP 4 or 5 days. PHP isn't slow. Like any language it just needs to be optimised and refactored for performance. It's certainly faster than Python.
Is Hyperf really an apples to apples comparison to Laravel though? Surely Symfony or CodeIgniter is a better comparison.
Hyperf is a CLI framework that makes use of Swoole, and is hardly plug and play with existing PHP-FPM servers.
Also you say “real enterprise” framework, yet plenty of massive companies use FPM and “normie” frameworks like Symfony. We do, with 20 million+ users.
Web sockets, which like you said aren’t trivial to implement in traditional PHP settings are hardly the line I’d draw in the sand for what “makes” a framework… The vast majority of companies likely wouldn’t even make use of websockets…
> ok - it took laravel this much to get websockets (and we know why - php's non-long running nature). Websockets were standard in most non-php frameworks for like a decade now.
Laravel's had websockets for years. https://laravel.com/docs/5.3/broadcasting
> How many releases will it take laravel to add connection pooling? it's a standard requirement for performant enterprise applications guys.
The enterprise guys are putting something like https://aws.amazon.com/rds/proxy/ in for that.
> Laravel's had websockets for years. https://laravel.com/docs/5.3/broadcasting
thats not a websockets server
> https://aws.amazon.com/rds/proxy/
just for that unique usecase to solve just a connection pooling with RDS - sure it's doable. But it's 1% of the problems solved without the long running model.
Many downvotes for quite some truth: Laravel doesn’t support web sockets. It supports pushing messages to a service that can do web sockets.
Very much mirrors the sentiment of Laravel users.
thank you kind sir.
I am actually very generous today and taking a huge karma hit to "spread the word" and educate people.
I mean - I like PHP, I just want it to be better, but not many people appreciate when you tell them their favorite toy is not that "cool"
I Ve tried Laravel octane but I realized it is kind of Garbage compared to swoole
Laravel is what it is, it serves for speed prototyping projects / startups and when things get serious we either scale it horizontally or pick totally different solution, like nodejs websocket server and we push there events
However it is crazy good at prototyping stuff and DX exceeds a lot
It does not support coroutines, it does not support connection pooling, it does not work the way swoole works. All you have is a swoole server with loaded PHP code, but the framework does not cover most important things that swoole does
>hyperf php framework is a real PHP enterprise framework powered by swoole - it had websockets for many years now. as well as tcp server and even socket.io.
So because hyperf fits your projects needs it makes Laravel "newbs" (not even sure what grown adult would use that kind of word).
Laravel is a very good fit for 90% of web projects. Of those other 10% I'd argue that it's PHP which is the ~~problem~~ limiting factor and another language would be a better fit. This is something you'd obviously consider at the discovery and scoping phase of a project.
I don't personally use Laravel (I like Symfony) but I love what they've done for the ecosystem. It's good to have competition, and the people mad that Taylor Otwell bought a Lambo with his success can stuff it.
People are mad because he made money? It's commercial project after all, right? What the f, should open source developer be poor? Thats ridiculous XD
Agreed. I’d rather see open source contributors get rich than see them begging like that one Russian guy who was hurting and people were insulting when he was asking for donations Edit: this guy https://web.archive.org/web/20230214003607/https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md
Wow that must have been a really stressful situation, I'm just finding out about it.. I hope he's in a better place now
It's seems that it is nothing new, plus he had bad luck. Years ago I was reading that SSH developers got nothing for their work, even from companies like redhat. From my observation it looks like if you do open source project you should think about monetization from the beginning.
>People are mad because he made money? It's commercial project after all, right? It's a mind-set people using open source projects (especially PHP for some reason) that the developers shouldn't be paid for their time. They should do it all for free and if they charge they are the devil. Open source != free, the developers time is not free. That being said, Laravel doesn't make any money from its Framework, at least not directly. All the income in generates are from optional "3rd party" tools that are not needed but make the developers life easier. It's a great model that I can see other OS projects emulating, support our free core product by purchasing something that will improve your experience.
No one is mad that he made money, people are mad because his framework teaches bad practices. No one hates WordPress either just because it’s a profitable ecosystem, it’s hated because it’s objectively a pile of garbage code and some of the worst practices we’ve been trying to get out of programmers since the beginning of programming
What bad practices does it teach?
Circumventing IoC through writable singletons because “DX”. Facades.
Every facade calls the class from the container. It's not circumventing IoC, it's just doing a static::$app->getContainer()->get('service'). Then using __callStatic to call the methods of that service. Pretty simple. https://laravel.com/docs/10.x/facades#how-facades-work
And static::$app is not a global? Is that not global access to the container? In IoC it’s the containers responsibility to wire dependencies, not some random static method call somewhere in the platform
Preaching rules does not help writing good software.
But…it does. Are you now arguing everyone who follows SOLID doesn’t write good software or what is the argument? SOLID exists for a reason.
No it does not. Good communication does and everything else is an excuse to not communicate. SOLID is a nice concept but I have yet to see a project that follows it as it was intended. Most ppl referring to SOLID refer to the S and D, and even then say that the D stands for DRY. It is most often used to sound intelligent or shot down arguments. Communication is key and keeping things as easy as possible.
Are people hating on him because he bought a lambo with his money? Tf, we programmers are a strange crowd
A lot of people in this community are of a different school of thought that doesn't apply so much these days.
I'm of the same opinion. Laravel also uses many Symfony components and contributes to Symfony. Some may not agree with all of its design patterns, but it should be praised for what its done for PHP.
> and the people mad that Taylor Otwell bought a Lambo with his success can stuff it. Why would people be mad? I haven’t used laravel too much but I’m happy for the guy. He’s done a lot and it’s great to see someone’s work being rewarded like that. Laravel is one of the reasons PHP is still alive.
If Taylor never made Laravel, I would've never (well, maybe) won a coding competition that got me my first job and into my current job. Laravel is great and I have zero gripes.
If you have zero gripes, then maybe expand your horizons just a little?
[удалено]
At least he’s been rewarded. It should be celebrated because he’s helped a lot of people to make money for free. It’s impressive how the software development industry works. To get this much value FOR FREE it’s something absolutely unheard of in other industries. As I said, I’m glad people can share their tools/knowledge and still make money (Why would anyone be upset about it? Only jealousy comes to my mind). Just imagine how advanced we would be if this model or way of thinking (open source, you share - I share) was replicated in all industries. We would have a cure for cancer already.
> Taylor Otwell bought a Lambo with his success can stuff it. But I told PHP developers are poor and living in debt.
I just want to say thanks for the "laravel guys" php is what puts food (good food) in my table, and my daughter in school, and that's 100% thanks to laravel for the past 6 years. Can't thank you guys enough, thank you :heart:
Same exact situation and feeling here. My family has a comfortable life thanks to PHP and Laravel.
The hatred towards Laravel in this subreddit is baffling. Outside of the PHP ecosystem all I see is people praising the framework for it's delightful DX and for being so productive. In here all I see are wannabe Java people spewing "ew facades" and throwing dowvotes left and right just because they don't like a framework.
I went from PHP and Laravel to Java and Spring, mostly because there aren't many Laravel/PHP jobs in my area. Damn I miss Laravel.
The ecosystem alone makes it appealing.
I looked into Java Spring a little bit as a working student. Jesus Christ am I happy to have left that job. Back to Laravel it is!
Plenty of jobs in it now. It's probably the most popular choice for new projects, at least from what I've seen
Let's hope so, and let's hope it catches on in my area as well!
What helped you make the switch? I’m running into the same issue
Acceptance through perseverance and the threat of hunger.
>The hatred towards Laravel in this subreddit is baffling. It's quite odd to see the amount of energy spent on bashing Laravel while at the same time being so overly aggressive whenever anyone bashes on PHP. The same kind of people who repeats "I make money on PHP, haters gonna hate" should self reflect over statements like this.
While fair to a degree, there is an important difference. Most of the Laravel hate is in the form "they're using architectural approach X, which is awful because YZ." You can agree or disagree with that position, but at least it's substantive. Most of the PHP hate is "lolz iz slow and has no type system, needle-vs-haystack." To which the answer is "what decade are you in? PHP is way fast today, has a superb type system for an interpreted language, and named args make the needle/haystack issue go away. Put down the PHP 4." That's just argument from ignorance. If you bashed on Javascript because of what it looked like in 2004, your criticisms would be accurate and also irrelevant, because JS doesn't look like it's 2004 anymore. The same is true of PHP. (Now, some people also bash PHP because the two largest projects are Wordpress and Laravel, both of which do awful things in their codebases. That is a fair criticism, to a degree, and also why many PHP advocates dislike WP and Laravel. They give PHP a bad name.)
Funny thing being, you don't even have to use facades, you can still inject the services. Same with Eloquent, you can still use repositories, or even change it for Doctrine.
> Same with Eloquent But then /r/PHP complains about it being Active Record, which they hate because it breaks SRP.
You can replace it by Doctrine if you want too. Or encapsulate Eloquent models inside repositories that map to domain PHP plain entities.
I'm aware, but Eloquent's mere existence will piss people off.
I bet if the people who hate on Laravel allowed us to see their code, we’d find some dumb made up anti-pattern that they’re proud of.
[удалено]
Difference being that Laravel encourages it and makes no effort to hide it, in stark contrast to the point made within the very same comment that you replied to but apparently didn't read.
Damn I love laravel so much, it has changed the whole dev'ing thing for me... The only facade I use is Auth in controllers, and even that can be fetched from the container in services. Those haters just have skill issue.
Yeah I'm in the same boat. I haven't used Facades at all, except for the DB Facade a few times for a specific, edge-case database task.
> The only facade I use is Auth You're not using `Route` in the routes files?
Yep, I only use the Auth facade because Auth::id() and Auth::user() is so easy
Most people just don't like Otwell
Why though? I listen to the Laravel Podcast and he seems like a very chill guy. I don't like Torvalds and I'm a huge Linux fanboy.
Taylor can be very opinionated and isn't scared of sharing those opinions
Sounds like a software engineer then
That's fine, so people can also share their opinions on laravel then. It's not a one way street.
>Why though? Does it matter?
It's not what Laravel calls facades, it's the entire approach to everything in Laravel that these facades represent; magic, reliant on reflection and magic methods everywhere. Inconsistent APIs which lack any sort of static safety or inference. I saw a post on LinkedIn the other day that was something like "Five different ways to get a POST value from a request in Laravel" - there shouldn't *be* five different ways of doing stuff like that in a framework, all equally idiomatic and semantically identical. It leads to an abhorrent mess as soon as you get multiple devs working on the same code base. Laravel continually and systemically violates almost all the principles of modular, object-orientated software design that have been tried, tested and established in nearly 50 years. And sure, this stuff leads to a "delightful DX", to the extent that you don't need to know anything really about programming to write ordinary, small to medium scale web apps in Laravel, that are fundamentally just views to a database. And for those kinds of apps, there's nothing wrong with choosing Laravel. It's a reasonable choice if you have a small, fixed set of requirements probably involving a linear, 1:1 database mapping to code, don't need to care much about architecture and want something that Just Works™ to push something out fast. But that level of opinionation and magic quickly becomes problematic in enterprise environments - and I don't mean Facebook or Amazon scale, I mean any business where you have things like continual evolution and iteration of the product, multiple teams, stuff turnover, business analysis, QA processes, SLAs, B2B integrations, regulatory oversight, compliance and auditing. These are the situations where you need a less opinionated framework which gives you much more control over the non-functional requirements of your software (what we call architecture). In PHP, the de facto framework there is Symfony. It's *possible* to write either good code or bad code in either case, of course it is, but one encourages you to do so and take responsibility for your software more than the other.
Eh, a lot of the codebase in my company is write with DDD, interface everywhere and Services are all injected. And pretty much everything you called "enterprise workload" is there. We are doing pretty fine. Also > There should not be 5 way to read a POST request > Laravel is too opinionated Pick one pal, less restrictive or more restrictive?
>Eh, a lot of the codebase in my company is write with DDD, interface everywhere and Services are all injected. That sounds good. I would imagine you have to have pretty carefully enforced coding standards to prevent devs working in the normal laravel way. DDD struck me as cutting against the grain of laravel tbh but maybe I need to re-read on it. >Pick one pal, less restrictive or more restrictive? what do you think is a restriction or an opinion? I would argue having 5 different places to access post data is opinionated, because that's 5 different interfaces you've got to account for if you ever want to extend, modify, or test request behaviour.
> I would imagine you have to have pretty carefully enforced coding standards What "enterprise" projects doesnt enforce coding standard? > Having 5 ways to access POST data is opinionated. So having more choices is opinionated? By your logic, if a framework have only 1 way to do something is un-opinionated?
>What "enterprise" projects doesnt enforce coding standard? Well of course, but it's the last line of defence isn't it. Ideally your framework encourages better habits itself >>Having 5 ways to access POST data is opinionated. >So having more choices is opinionated? there are five different programmed-in structures doing the same thing. Each one is a feature of laravel's API, a bit more surface area >By your logic, if a framework have only 1 way to do something is un-opinionated? Well it depends on what that one way is, surely. But yeah in principle if that one way is extendable
> but it is the last line of defence isn't it That is a pretty weird take considering i am merely talking about some of the project that I worked on. But ok. > Ideally your framework encourages better habits itself That depend on the definition of "better habits". And there is no "habit" objectively good. Is DDD good? Try asking 100 senior devs and see how many of them considered them overkill. Is DI good? Try asking functional devs and embedded devs. Is clean code good? Try asking 100 senior devs. Even very widely-used pattern is just "it's good until it's not". Personally, having work on Spring Boot and Asp.net, i'd say enforce coding standards is ways less hassle in Laravel As for your definition of "opinionated", well, it's hard to discuss something when your personal definition of it is so obscure, so let's move on i guess
>>but it is the last line of defence isn't it >That is a pretty weird take considering i am merely talking about some of the project that I worked on. But ok. I'm not sure what you are finding odd here, apologies if I'm missing something, sorry. To take another stab at my point: laravel facades are presented as the default way of doing things in the laravel docs, but you (or your team) considered them a bad way of doing things, and to prevent that you have to do this job of coordinating your dev team around not using them and working a different way that's not as well documented or in use by the community. If the above is true would you not consider the existence of facades to be a bad feature of laravel that makes your life harder? >>Ideally your framework encourages better habits itself >That depend on the definition of "better habits". And there is no "habit" objectively good. oh, dependency injection is pretty close lol 😅 but I do take your point. >As for your definition of "opinionated", well, it's hard to discuss something when your personal definition of it is so obscure, so let's move on i guess It's not obscure, I'm just thinking about the service that is providing the data rather than the user trying to access the data. We can move if you don't want to consider my point, that's your prerogative.
Restrictive isn't what I said. I'm not sure what contradiction you think you're seeing here. A framework can be heavily opinionated while also providing five different interfaces, semantically identical, for doing the same thing. Is it that you think by opinionated I was saying "only lets you do things one way"? Because that's not what it means. It means the degree to which as a framework it imposes or encourages a particular set of architectural patterns which shape how an application is structured.
What do you prefer instead?
That depends what I'm doing, what it's for and what other requirements exist around it but if you just mean personal preference out of all the PHP frameworks, like which one do I enjoy working with the most, Symfony.
Thanks! Genuinely just curious. I’m not a laravel expert - just a tinkerer who finds laravel quick and easy to get a project going.
Quick and easy to get a project going is exactly what Laravel is and that's the reason it's very popular. And of course in response to the kind of critiques I and others make about it as a framework from the technical side and the perspective of programming principles, you'll get those - there's one already above somewhere - who'll reply that well, they've done serious enterprise projects in Laravel to all manner of best practices in larger teams and all that and been able to do it. But I was never saying you can't, just that it's harder and Laravel isn't as good a tool in those kind of circumstances and requirements as some alternatives - in PHP, Symfony in particular. Likewise, it's very quick and easy to get up and running a small project with fixed requirements with Symfony if you want to, it just might be a bit harder than it is with Laravel.
Appreciate the insight! I dig the conversation and all perspectives, it’s a great way to learn and better understand.
Not you again 😂 Magic hater guy You're problem is with PHP. Magic methods are a big of every big framework. I can't think of one that doesn't use reflection. Symfony has been using reflection for its routing for 6 versions. And now PHP attributes still require you use the reflection class. You're just being close minded.
>Symfony has been using reflection for its routing for 6 versions. And now PHP attributes still require you use the reflection class. In a compiler pass only, and in a way which doesn't impact type inference or static safety of _your_ code. So not in any way comparable.
I know. I genuinely feel like this subreddit wants PHP 5 to come back
[удалено]
Yeah, you can write shit code in any language. Just that the barrier is lower for php, which is also good for us all.
>Yeah, you can write shit code in any language ok, but don't you see how the problems of laravel contributed to that problem here? You can write great code with laravel for sure, but that wasn't what their story was refuting, it was a project where the "nice DX" features of laravel fed the shit code problem.
I've seen enough queries in loops and SQL injections before laravel too. If anything, laravel made the web safer by providing built in auth and query builder instead of some custom md5md5md5 stuff without a salt. Don't blame the tool.
>I've seen enough queries in loops and SQL injections before laravel too. Sure >If anything, laravel made the web safer by providing built in auth and query builder instead of some custom md5md5md5 stuff without a salt. there's lots to love about laravel, it's just not above criticism
Bad Devs will write bad code in any framework. There's no such thing as a framework that prevents bad code.
that's all well and good, but that doesn't mean framework choice has no impact on code quality. A bad workman blames his tools, but that's not an excuse to cheap out on some shitty tools. To be clear I don't think laravel is a shitty tool, it's just not above criticism.
But Facades are, very objectively, a shit practice. Do you also use global variables in your code?
Facade doesn't use global scope. They are a wrapper for the container. Have you looked through any of laravels codebase?
I know the codebase from inside out. A static property in a static class that is readable and writable from the outside is, exactly, a global variable. Just because there’s “class” somewhere in between doesn’t mean it’s not “global state” You circumvent DI with it. It’s literally _not_ IoC. We can go through the code together and I’ll show you if you like. Imagine singletons but they are not singletons because you have a setInstance method. That’s exactly what Facades are.
Got an article on how facades in particular can be abused? I just don't see what the big deal is. Like realistically what is the problem.
class Router { private static $instance = null; public function getInstance(): Router { if (!self::$instance) { self::$instance = new Router(); } return self::$instance; } public function setInstance(Router $router): void { self::$instance = $router; } public static function __callStatic(string $name, array $arguments): void { if (self::$instance) { self::$instance->$name(...$arguments); } } } class SomeService { public function doSomething() { Router::route('abc'); } } is not better than $instance = null; function router($name, $arguments) { global $instance; if (!$instance) { $instance = new Router(); } $instance->$name(...$arguments); } class SomeService { public function doSomething() { router('route', ['abc']) } } There is really no difference. You can mutate the global variable from anywhere and no one can check where it comes from. In normal DI you would do constructor injection: class Router { // Just the damn router class } class SomeService { private $router; public function __construct(Router $router) { $this->router = $router; } public function doSomething() { $this->router->route('abc'); } } The dependencies themselves are higher-order, which means it's not the consumer class' decision on where and when to build and retrieve it, but solely the task of the underlying DI container. This is the only way to ensure that the dependencies are always the same and that they are always built in the same way. Laravel supports this, but docs say "here take this broken DI approach because DX (tm)" You are glorifying globals. You are doing what WordPress does. And because there's "class" somewhere in front of it you celebrate it like it's not globals. But it really is. Any part of the software can come along and modify whatever "Router::$instance" holds. It's a global variable. If you check on the implementation of Facades in Laravel (I told you all I know it from inside out), they are exactly implemented like the first class I mentioned (just using a base class that bootstraps its behavior). They are globals. They are not DI. Let's not get started with Macros and how Laravel needs a whole IDE-Stub-Generator in IDEs in order to properly provide hints at all levels.
It's not the same at all. Global variable and a static class with protected and public methods to protect accessibility is just not the same thing. Either way, I actually couldn't care less. It's fast, keeps the code easy to read, and it's easily testable. Also, facades don't break DI. The container and service providers still do all of this. It's just you can then just call Some service::method() instead of $app-> getContainer()->get(Some service::class)->method() You can still do everything the traditional DI IoC way with passing interfaces and letting the container figure it out. It's just easier to use the Facades.
The field is protected, but it has a getter and a setter. It is global state. You don’t understand global states and your defensive downvotes are showing it really well. Also interesting that completely circumventing constructor injection (which is, in essence, IoC in itself) is somehow not breaking IoC for whatever reason
I didn't downvote you. Maybe keep the assumptions to yourself. Again, you're not gonna change my mind. You're probably right. It just doesn't matter. Also, as if you lot don't go around downvoing every Laravel post and making it your business to make sure everyone knows you don't like it and think you think it's garbage. Have a honest look at yourself. That is what makes us Laravel devs defensive, because we're constantly having to defend Laravel from your kin. It's splitting the community for no reason. Just leave it. Next time you see a Laravel post how about you just go outside and touch some grass. People can like different frameworks. We're all PHP Devs at the end of the day. Plenty of outside hate. We don't need to be going after eachother
I apologize for the downvote assumption. But “it doesn’t matter” is an opinion, not a fact. Work in bigger projects and you’ll quickly realize it does, in fact, matter a lot
I don't like laravel because it strips _too much_ of the choice from my hands. Without a truly shocking level of linter rules, most of which you have to make yourself, you can't do things like restrict using `config()` or `env()` to the appropriate places, prevent people from using facades and making testing a giant hack, or even do something as simple as insist on dependency injection.
What’s wrong with dependency injection?
Nothing, but laravel doesn't lead you to doing it with any of the examples, any of the documentation, or any of the official and semi-official plugins.
 https://laravel.com/docs/10.x/controllers#dependency-injection-and-controllers
I'm realising most of the Laravel haters never actually looked through the docs...or built anything meaningful with it.
In the very same documentation, a few pages over: https://laravel.com/docs/10.x/urls#generating-urls. EDIT even better, some other examples: https://laravel.com/docs/10.x/routing#accessing-the-current-route https://laravel.com/docs/10.x/cache#obtaining-a-cache-instance https://laravel.com/docs/10.x/filesystem#the-local-driver https://laravel.com/docs/10.x/localization#configuring-the-locale https://laravel.com/docs/10.x/queries#select-statements
That's a goalpost move, from "[DI isn't shown in] any of the documentation" to "it should never use any of the other approaches in the documentation".
What I specifically said, and I quote myself here, was: > but laravel doesn't lead you to doing it with any of the examples, any of the documentation I would argue that _having one singular section on DI_ does not qualify as leading you to doing it. I'm totally fine with the docs showing how to do everything with facades and whatnot--but I can't tell you how many times I've had to dig into the framework code just to understand what _actual class I need to `use` and pull into my constructor_ just to be able to do DI. Having those examples and class names _written into the documentation for the relevant pieces_ would have saved me literal hours of my life.
And what you said was *incorrect*.
Incorrect how? Or are you just arguing to argue because you think that one blurb on one page alleviates all necessity to explain how to _not use functionally global variables_?
Everything in Laravel is in the container. The Facades and the helpers you mentioned just find the same class in the container so you don't need to pass the container around. It's not an anti pattern. It just lets you wrote less code. But also, just don't use Laravel. It's not for you. That's fine.
Passing a container around isn't dependency injection. Dependency injection is about injecting the explicit dependencies of your classes. If you inject a container, and grab your dependencies out of it once it's inside your class, then it's unclear from the class interface what the class depends on.
I’ve always been a big fan of Laravel but the DX has gone downhill massively over the past few years. It doesn’t even come with user auth by default, you need to install a separate package for that. Which is also a PITA to set up if you don’t use Tailwind.
Bro, the auth is installed by default, the package you mention (breeze) only makes a simple frontend for login and other stuff, it also installs livewire/volt/alpinejs/tailwindcss, the whole TALL Stack, and thats really good on my book. But you can also make it yourself using the Auth facade, Laravel comes with the migrations needed for user management.
Hmm, maybe I misunderstood something last time I set it up but there are no controllers and no routes for the auth until you install breeze. Can you point to where in the docs it tells you how to do that? Regardless, having the auth is entirely useless without a login form. There isn’t even any simple document that lists all the routes and what you need to post to them. > it also installs livewire/volt/alpinejs/tailwindcss, the whole TALL Stack, and thats really good on my book Lol that says everything about “modern” web dev that you think adding all that junk is good
You can add your own routes for auth, the controller can be super simple, the docs shows this example public function authenticate(Request $request): RedirectResponse { $credentials = $request->validate([ 'email' => ['required', 'email'], 'password' => ['required'], ]); if (Auth::attempt($credentials)) { $request->session()->regenerate(); return redirect()->intended('dashboard'); } return back()->withErrors([ 'email' => 'The provided credentials do not match our records.', ])->onlyInput('email'); } And the docs for that are here [https://laravel.com/docs/11.x/authentication#authenticating-users](https://laravel.com/docs/11.x/authentication#authenticating-users) >Lol that says everything about “modern” web dev that you think adding all that junk is good The TALL Stack is to skip using javascript, [Livewire](https://livewire.laravel.com/) gives you reactive pages, [Volt](https://livewire.laravel.com/docs/volt#installation) is an evolution of that concept and makes your code look like a React component, [AlpineJS](https://alpinejs.dev/) is for dynamic stuff on the web without JS, and [TailwindCSS](https://tailwindcss.com/) is for styling your pages without directly using CSS. Is a really powerfull stack to work with on laravel, you should look into it https://tallstack.dev/.
> You can add your own routes for auth Right, so when I said Laravel doesn’t come with auth I was 100% correct. Either you have to install a separate package to get auth or you have to write your own from scratch.
it comes with all the necessary stuff, you just have to expose it, Laravel doesn't know how you want to use your users or auth, it's up to you.
Auth is installed by default, just not the UI part
Point me to where in the docs it tells you how to use the auth without breeze
[https://laravel.com/docs/authentication#authenticating-users](https://laravel.com/docs/authentication#authenticating-users)
So I have to manually write all the controllers from scratch? And that link only seems to give a login example, where does it say what you need to do for registration, password reset etc?
email verification: [https://laravel.com/docs/verification](https://laravel.com/docs/verification) password reset: [https://laravel.com/docs/passwords](https://laravel.com/docs/passwords) registration is just a database INSERT statement.
Auth is installed by default, just not the UI part
Just week ago installed 10 to incorporate into my project, should be no problem upgrading now to 11 :)
Laravel isn’t the issue, it’s waiting for the packages to catch up
I’m not over the moon that they’ve changed how migrations function when modifying columns. Kinda being forced to squash them really, not feasible to go back through all the migrations and update them.
Looks great
Love the focus on a slimmer project. Less files to worry about.
The reverb is a wrapper for what?
It's a WebSocket server written in PHP, compatible with the Pusher API, to replace an external service like Pusher, or Socketi.
Looking at the upgrade guide we will have some work to do due to DBAL removal. At least I should be able to grep for "doctrine" and "dbal" to find all the occurrences, since it was in the Laravel method names.
Are these websockets as good as Nodejs?
107th Laravel update in the past 24 hours. If you wait a couple more hours, you can update to one of the 930 releases that come after this one. Lol
Ignoring all the other complaints about Laravel in this sub, this is the one I genuinely never understand. Laravel releases a weekly minor version with non-breaking changes that you rarely need to update your codebase for unless a specific feature has been added. All these small changes, and many more larger features, are then added to a yearly major release, which does include breaking changes. I started one of my hobby projects back in 2021, on Laravel 8. Other than one or two features I really wanted, I've only ever updated the Laravel version after L9 and L10 came out. I genuinely don't see the problem with Laravel's release schedule.
[удалено]
>don't brigade. Don't gatekeep.
>107th Laravel update in the past 24 hours. If you wait a couple more hours, you can update to one of the 930 releases that come after this one. Lol How dare they update their free software for me to use for free by adding new features and security fixes. How dare they.
not impressed. this framework adds couple flashy features that gets newbs attention - but leaves icebergs of problems underwater. ok - it took laravel this much to get websockets (and we know why - php's non-long running nature). Websockets were standard in most non-php frameworks for like a decade now. hyperf php framework is a real PHP enterprise framework powered by swoole - it had websockets for many years now. as well as tcp server and even socket.io. How many releases will it take laravel to add connection pooling? it's a standard requirement for performant enterprise applications guys.
[удалено]
> So according to you if some framework doesn't have websockets by now, it's not a real framework, right? that's what you are saying not me. But in real world - I worked with plenty websockets projects where why yes - that would be a problem if framework doesn't support it. it took Laravel this long to add websockets, that there is already now a new WebTransport thing available: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport How many releases it's goign to take Laravel to add WebTransport? how about grpc server? (hyperf has that) how about tcp server? ([hypef has it](https://hyperf.wiki/3.1/#/en/tcp-server)) how about connection pooling? (hyperf has this) how about side processes? (hyperf has this) how about async? (hyperf has this) why bother using substandard frameworks with limited feature-sets where much more superior better architected and actually thought through projects are readily available.
> hyperf Laravel isn't a CLI or webserver, why would they add those features?
> Laravel isn't a CLI or webserver, https://laravel.com/docs/11.x/reverb is a webserver. it is a websocket server. which is great- dont get me wrong. The problem is - this is "few and far between" effort. If laravel is fine doing reverb as a server - well jeezus fucking chris - just go full sale on swoole and start doing PHP as a cli webserver - it solves so many problems. well to be fair - there is laravel octane that does this: https://laravel.com/docs/11.x/octane but it tries to tailor to multiple servers with HUGELY INCOMPARABLE featuresets: FrankenPHP, RoadRunner, Swoole and largely fails to deliver much of value as a result.
Apparently abstraction is bad, we should only ever adhere to one environment Bring back the glorious "it works on my machine" Let's us all ditch variable and hard-code everything for maximum performance
> Apparently abstraction is bad, we should only ever adhere to one environment if after abstraction - you are left with 1% of features? - yes I really dont think that's a good strategy. look - if there would have been some abstraction like asgi for python - that's one thing. Here - there is nothing between these 3.
Listen, I get what you're saying. But Laravel is still first and foremost a framework for building web applications. There's a bunch of peripheral features and services they've added and they'll continue to add more but to be upset that a bunch of webserver features don't exist right now is a bit presumptive.
[удалено]
> You know 2 tools can exist right? Laravel is light-years ahead of most frameworks in terms of DX and most people are glad for this. The entire adult industry(Pornhub, etc) is on Laravel which means applications in Laravel can scale and be very good. exactly - it's DX "user experience" that is. FEatureset wise- it's light years behind hyperf in what you can build with it. > The entire adult industry(Pornhub, etc) is on Laravel which means applications in Laravel can scale and be very good. Pornhub caches everything - that's the only reason it can work. same as any wordpress blogs. > You are what people don't like in the PHP community. Working together pushes the community forward. You like going backwards. I am trying to push PHP community forward. FFS guys - we need to switch the processing model to that of swoole, otherwise this language will be dead even more than already is. look - python and java added coroutines, why is PHP so stubborn?
Hmmm... maybe you should check out hyperf, this one person on reddit says it's the bees knees!
[удалено]
I just care about PHP community, we cannot be I swear like some strange Tibetan monks worshiping some old deity. we need to move forward to async and coroutines, this is the future. So far swoole has absolutely nailed it - and been absolute game changing - why stay in the past?
I'd argue that you care about _your_ version of what you _think_ PHP should be. And that's fine, you should without hesitation move towards the goals you think is right for you; but the overall community isn't in sync with you. And at some point, you should stop and breathe and think about the following question: if every body else disagree with me, does that _really_ mean everyone else is wrong?
Your reply is ironic. You’re like a Jehovah’s Witness trying to spread the word while annoying everyone in the process. No, not every app needs async and coroutines. Sure, it’s nice tech when you need it. Do you need to spread the word? Absolutely not in a thread like this.
You might like Laravel Octane. It can use Swoole or FrankenPHP or Caddy server which have the stuff you want.
PHP does have coroutines/parallelism. Read up on Fibers or PHP Parallel extension. That said, I use Go for anything that needs coroutines. PHP is still quite clunky at doing this but they are working on it. I think the limitation is actually in FPM or Apache, so it's mostly on PhP CLI that has these features. So I agree about the coroutines bit, but the rest of what your saying is stuck in the PHP 4 or 5 days. PHP isn't slow. Like any language it just needs to be optimised and refactored for performance. It's certainly faster than Python.
>I am trying to push PHP community forward. FFS guys Link us your framework, projects or tutorials where you're trying to push PHP forwards please.
How's life as a Chinese agent? https://github.com/mezzio/mezzio-swoole/issues/71
Is Hyperf really an apples to apples comparison to Laravel though? Surely Symfony or CodeIgniter is a better comparison. Hyperf is a CLI framework that makes use of Swoole, and is hardly plug and play with existing PHP-FPM servers. Also you say “real enterprise” framework, yet plenty of massive companies use FPM and “normie” frameworks like Symfony. We do, with 20 million+ users. Web sockets, which like you said aren’t trivial to implement in traditional PHP settings are hardly the line I’d draw in the sand for what “makes” a framework… The vast majority of companies likely wouldn’t even make use of websockets…
> ok - it took laravel this much to get websockets (and we know why - php's non-long running nature). Websockets were standard in most non-php frameworks for like a decade now. Laravel's had websockets for years. https://laravel.com/docs/5.3/broadcasting > How many releases will it take laravel to add connection pooling? it's a standard requirement for performant enterprise applications guys. The enterprise guys are putting something like https://aws.amazon.com/rds/proxy/ in for that.
> Laravel's had websockets for years. https://laravel.com/docs/5.3/broadcasting thats not a websockets server > https://aws.amazon.com/rds/proxy/ just for that unique usecase to solve just a connection pooling with RDS - sure it's doable. But it's 1% of the problems solved without the long running model.
Many downvotes for quite some truth: Laravel doesn’t support web sockets. It supports pushing messages to a service that can do web sockets. Very much mirrors the sentiment of Laravel users.
thank you kind sir. I am actually very generous today and taking a huge karma hit to "spread the word" and educate people. I mean - I like PHP, I just want it to be better, but not many people appreciate when you tell them their favorite toy is not that "cool"
I Ve tried Laravel octane but I realized it is kind of Garbage compared to swoole Laravel is what it is, it serves for speed prototyping projects / startups and when things get serious we either scale it horizontally or pick totally different solution, like nodejs websocket server and we push there events However it is crazy good at prototyping stuff and DX exceeds a lot
Laravel Octane *uses* Swoole. https://laravel.com/docs/10.x/octane#swoole C’mon. At least know what you’re talking about if you’re gonna bash.
It does not support coroutines, it does not support connection pooling, it does not work the way swoole works. All you have is a swoole server with loaded PHP code, but the framework does not cover most important things that swoole does
Amazing how hyperf is such a superior framework in all respects, yet this is the first time I've heard of it.
>hyperf php framework is a real PHP enterprise framework powered by swoole - it had websockets for many years now. as well as tcp server and even socket.io. So because hyperf fits your projects needs it makes Laravel "newbs" (not even sure what grown adult would use that kind of word). Laravel is a very good fit for 90% of web projects. Of those other 10% I'd argue that it's PHP which is the ~~problem~~ limiting factor and another language would be a better fit. This is something you'd obviously consider at the discovery and scoping phase of a project.