Ironically enough, if people actually tried PHP, many would be amazed, especially at the quality frameworks. Productivity is very high in something like Laravel, and compared to JavaScript frameworks PHP frameworks are much more feature complete and well though out.
I'm a big fan of trying out different stacks, and I think a lot of people would love Laravel if they tried it. Give it a shot using PHPStorm and Laravel IDEA (free trials for both), and see what you think. Can't hurt.
As a PHP developer of 10+ years, large frameworks like Laravel and Symfony still bewilder me. I really have no idea why 99% of people would ever want to use them.
They add a layer of complexity over the top of PHP such that instead of learning how to write PHP, you need to learn how to write the framework.
Let's take an example right from Laravel's homepage:
Authenticating users is as simple as adding an authentication middleware to your Laravel route definition:
Route::get('/profile', ProfileController::class)
->middleware('auth');
Once the user is authenticated, you can access the authenticated user via the Auth facade:
use Illuminate\Support\Facades\Auth;
// Get the currently authenticated user...
$user = Auth::user();
As a developer, looking at that code tells me nothing. WTF is the "auth" middleware? Where is it configured? What's it doing?
Then we come to `Illuminate\Support\Facades\Auth` - another meaningless string with a seemingly arbitrary name. WTF is "Illuminate" and why is it in my code? Why do I need it to authenticate users?
So I have to go and learn all of this crap before I even begin to understand what the code is doing. And for every other thing I want to do with the framework I need to look up how to do it "the Laravel way".
The reason why many use frameworks like Laravel, Symfony, RoR or Django is often because they have non trivial needs. If I need to do something very simple like a small blog I might just throw something together on my own.
I personally have a large prject with a ton of code that was written in the last 16 years from when I was very inexperienced to now. After a while you realize that patterns are important, and you start building more and more features to make development and maintenance simpler and faster.
Here is a list of things I created over some years for that project:
- Authentication system that supported different types of login.
- Pretty routes.
- Simple dependency injection container.
- Emailing.
- A templating system.
- A scheduling system.
- A worker pool.
- Reusable forms.
- Simple DB migrations in code.
- Caching system.
- A file storage system.
- Data seeding.
- Testing.
- Websockets.
- Asset bundling and versioning.
- Localization.
- Payment integrations.
- +++
Sure, I could do it the JS way and find different packages instead of doing it myself, but I don't want to rely on a bunch of projects as that quickly can become maintenance hell.
After a while you realize that you're basically reinventing the wheel. Is Laravel and Somfony complex? Yes. Does it sometimes seem like magic? Yes. Is it hard to use, modify or figure out how it works? No.
You might not know why 99 % would want to use them, but I'd agrue that most probably should when the project achives some complexity. That way you can reap the benefits of the work and experience of thousands of contributors behind these projects.
I am one of those "I want to know what happens in the background" people too, and it's not that hard to figure out how Laravel works if you want to know. But most developers are not interested in how the framework they are using really works. The questions you have about what the auth middleware is, how it works, and what the Illuminate namespace is for(Laravel) is easy to figure out by checking the docs.
Laravel is definetly an opinionated framework, but personally I think most of the options are good ones.
These are more exceptions than rules. Rails, Laravel, and Django are the three massive frameworks that are languages themselves, so learning them as an introduction to their programming languages can be confusing for newcomers.
It seems, to me, that small server frameworks with middleware are what's in vogue right now. Flask, Express, Slim. C# added minimal API recently.
Well, I used to do PHP back in the day, and I know the language has changed and evolved a lot, but I've looked at Laravel thinking it would be something cool and interesting and productive, and it seems bewildering and bloated. Doing one simple thing seems to take a mountain of incomprehensible overhead.
Not to say it's bad, but even with some experience, I couldn't grok it.
Laravel annoyed me deeply when they spammed the installation page with garbage like "Meet Laravel" and "Why Laravel?" I stopped digging into Laravel right at this point. Unfortunately, this awkward documentation style is typical for most PHP frameworks, have also seen it in the TYPO3 and WordPress docs.
Out of curiosity, in your projects where you use PHP with frameworks such as Laravel, do you do server-side rendering, or SPA applications? I prefer the former but I wonder what's the trend now for the people into Symphony, Laravel, etc.
I personally use different approaches in different projects, but it works great both ways. Inertia is really excellent with frontend frameworks like React/Svelte, whilst Blade is brilliant for server-side templating too.
I have mostly used SSR, but in the last years I'm sometimes using Inertia with React/Vue/Svelte and SSR too. Not sure if there are any clear trends. Personally I prefer plain old blade templates, and I only use FE frameworks if I think it makes sense.
I don't know how the experience is with Livewire, but I've heard a lot of people like that too.
The common options with Laravel is plain blade templates[1], Intertia(React/Vue/Svelte, SSR optional)[2] or Livewire[3].
I'm a big fan of trying out different stacks, and I think a lot of people would love Laravel if they tried it. Give it a shot using PHPStorm and Laravel IDEA (free trials for both), and see what you think. Can't hurt.