Still seems like most people write separate backend and Nest.js is most popular. I am not a biggest fan yet personally.
Laravel Livewire is pretty nice for basic interactivity, which is all many sites need, but React becomes useful as soon as you start needing app-like features. At that point, using Next, which is already plugged in to that ecosystem, is a very nice experience.
Next is great for static sites, too, so nowadays I prefer putting my time into that vs. fragmenting between a more purely server-side framework like Laravel.
Trying to build a "full stack" application with just Next.js is suiciding everyone that comes to the project after you leave.
The documentation is an almost perfect blend of examples and nitty gritty detail. The documentation is almost engaging if you’re coming from other frameworks.
I found myself thinking “wow that’s almost no code, what about this feature or that” and the next section would be the exact topic I was wondering about. Had a blast and could learn more php details as I went
Highly recommend
Back when I worked with PHP, we used Symfony and several coworkers very much looked down on Laravel. Symfony was modular and you could easily switch whichever component for your own by just implementing the interface and overriding the dependency injection thing. Word was that Laravel hardcoded many things and was less customisable.
What is your take on this? In what way is Laravel superior to Symfony?
I can live with both frameworks, but Symfony just feels cleaner and more transparent in its workings without using magic to make things look simpler.
I do lots of refactoring and modernizing of legacy or non-scalable codebases as a freelancer; with Symfony you can replace it module by module and slowly implement the Symfony framework structure.
Through some configs, it can do dependency injection, event listener stuff, etc, but the framework is mostly glue around components.
With Laravel, you need to go "all-in", and you had to do things the Laravel way. If I strayed from that path, it would make things really difficult.
I still work on projects with either of the frameworks, but if I had a choice, it would almost always be Symfony.
I have been working with Laravel on a daily basis since 6 years and have never felt more efficient with code.
Thanks for the info!
You can take a model for anything in your legacy code, and just set properties on the model to teach Laravel how to deal with things that don't follow conventions.
For example, you can override the table name. Suppose you had a legacy table called "postdata". In Laravel, this table would be called posts, and a model would be Post.
So you'd just tell Post to query postdata rather than posts.
Likewise, you can tell it which fields to cast as dates, booleans, etc. You can tell it which fields represent timestamps for updating, creating, deleting and so forth.
You can setup relations that don't follow naming conventions the same way.
The only issue I've run into is doing things like setting up relationships across databases. You can do it, it's just not super straightforward.
I think you'll find it's a breath of fresh air to have a modern wrapper around your legacy code, and that your legacy stuff will then fit in quite nicely with your new work.
Everything in Laravel is as obscured, "magical" and opinionated as possible for the sake of making the code "beautiful" (again, at a glance) to the detriment of basically everything else. I really have no idea how any experienced programmer can look at it and think it's usable for anything beyond the most simple project.
The mere fact that models are PHP classes but none of their properties that exist in the database are actually declared as properties in the class because the ORM just "magically" puts them there at runtime should be enough to drive away any sane person. And let's not forget the amazing "Facades" a.k.a. glorified global variables filled with magic methods that you're expected to make extensive use of.
Each of the facades comes with a corresponding dependency injection if you prefer. You can write an entire Laravel app without ever touching a facade.
Facades are not global glorified variables with magic methods. Usually they're just a way to instantiate and access a class with less code. People complain that facades limit testability. In fact, they're easily mocked. Etc.
The docs do a very good job of explaining how things work and how you can override any "magic" you may not like. If something is doing something you didn't expect, you probably didn't read the docs. In fact, a delight of working with Laravel is it's so intuitive that you can often guess how to achieve something and be right.
Have you worked with Laravel in practice?
I shouldn't need "real life examples" to explain why using objects with magic dynamic properties instead of declaring the properties on the class is stupid. If I can't look at a model class and know what properties and methods it has, why is it even a class? With all the improvements made to PHP in the past decade, it feels like going back to the days when I was just using associative arrays to represent database objects.
> Have you worked with Laravel in practice?
Yes, I tried using it, was immediately put off by the issues I've described, then tried Symfony and never looked back. For every piece of dumb nonsensical magic Laravel does, you can look at Symfony to see how it should be done properly.
As for properties -- yes, they're not explicitly described but mapped to the database schema. Other ORMs, like that in Ruby on Rails, also do not explicitly set model properties and just map to database columns. People have been upset about this forever, but everyone else has happily used Active Record and had no major issues, all while enjoying not having to add a dozen lines of code to annotate props.
In both Rails and Laravel you can define accessors and setters, either overwriting the magic property for the column or defining new properties.
If not seeing the properties on the model is a huge problem, there are plugins to generate them and put them in the model. My IDE gives me direct insight by inspecting the table.
I'm happy not to have to write out all the props twice when there's no tangible performance issue and I've never had any other problems with dynamically getting the model attributes from the schema.
You're taking a matter of taste and context-based tradeoffs and acting like those reflect unchallengeable principles.
Symfony is a great piece of software. So is Laravel. Github numbers alone will show you how compelling so many developers find Laravel. Of course, there will be haters who think they're all stupid, uneducated, bad, idiotic, lazy, etc.
Everyone makes trade-offs based upon taste or prior decisions. Consider Django. There, you explicitly define properties, but link them to the type of database column they'll use. Then, you can generate a migration based upon the model, and then run that migration. I really like that pattern. Removes tedium of writing migrations, preserves ability to modify the migrations, and makes things explicit.
When I used SQL Alchemy in Python, it completely allowed me to not write migrations, only models. That was very nice, until it wasn't. But then I just had to do a few things manually -- a reasonable price to pay for saving a bunch of time in the other 19/20 of cases.
These are all just different ways of getting to the same place. Each has benefits, each has drawbacks, the extent of each which will depend on the project and the developers' tastes.
And to be clear, Laravel is a piece of Symfony software, and a good example of what you can do with Symfony packages and a bit of opinion.
There are 13 Symfony dependencies in https://github.com/laravel/framework/blob/9.x/composer.json alone, and many of the Laravel packages listed in there also depend on them; the Laravel Request class extends Symfony\Component\HttpFoundation\Request, the Response class extends Symfony\Component\HttpFoundation\Response, etc.
In any event, Laravel has never been shy about its debt to Symfony.
>Consider Django. There, you explicitly define properties, but link them to the type of database column they'll use. Then, you can generate a migration based upon the model, and then run that migration. I really like that pattern. Removes tedium of writing migrations, preserves ability to modify the migrations, and makes things explicit.
This is exactly what Symfony with Doctrine does, and it's the correct way to do it. The benefits vastly outweigh the "drawback" of having to write slightly more code.
In most cases, it is a matter of taste and tradeoffs that vary based upon circumstance.
You can keep saying "this is the correct way" with all the conviction in the world, but it won't turn matters of opinion and circumstance into universal fact.
Separating the data access layer, the models and the business logic (basically a 3-tier architecture) is a widely used and proven industry standard to keep a sane, maintainable and testable codebase.
Active record ORMs like Eloquent mixes everything in a single layer (business logic in the model events, data accesses are done by the models), but as soon as you reach a significant level of complexity, it is unmaintainable.
Even Laravel codebases that grow in complexity often ends-up wrapping Eloquent in a repository layer.
At some point you have to accept the foundation you have as something that works, it's battle proven, and it's built by experienced and reliable developers and you build on top of the shoulders of giants. Reinventing everything from scratch so that you understand it makes you the only one that understands it.
There was a famous phrase by Arthur C. Clarke that I think applies here along the lines of "Any sufficient advanced technology is indistinguishable from magic".
For example, you don't need to use the ORM at all and can just use their query builder (which is pretty good). It's there if you want it, but the framework works happily without it and doesn't get in your way in that regard.
I inherited a Laravel codebase from a previous contractor and it was reasonably ergonomic to navigate and extend, because I was able to lean on the framework documentation to understand how it all worked. But there were several points where it was _not_ reasonable, because of Laravel/PHP magic and those were pretty painful to figure out and debug.
The reason I wouldn't choose it myself anymore is the magic, the little surprises and hard to debug idiosyncrasies that it provides in order to look pretty. Also generally Laravel, PHP and related ecosystems are moving too fast and are difficult to keep up to date without breaking and/or misunderstanding things. It's not quite JS/npm level of churn, but unnecessary regardless. A more minor point is the baseline performance tends to be on the lower end of what I need.
There are ecosystems out there that value stability and clarity more and provide better tools to test and debug the code if necessary, and I've come to appreciate those things much more with experience than other factors such as reducing the initial development time.
I don't know about that. I have been looking at Rails 7 and there's a lot things in Rails now I like better than Laravel.
Symfony did most of the heavy lifting with getting PHP relevant again, Laravel was just better at marketing. Laravel is good, don't get me wrong but everyone seems to think Laravel is the only good thing in PHP and a lot of Laravel is built with Symfony libraries.
Take a look at Symfony before Laravel. It will be very similar to Java developers who are familiar with Spring.
- Laravel uses Inertia for Vue.js or React integration while Symfony has an integrated solution with Symfony UX
- Symfony has become more modular with Symfony Flex
- Symfony has put a lot of effort into improving "developer experience" in the Symfony DX initiative
- Symfony has brillant docs in many languages including a new open book by Fabien Potencier and other Symfony collaborators
The ecosystem around Laravel is really incredible and unlike any other framework. They have libraries for every stage of a web application from taking payments all the way down to server management and hosting.
They even have awesome libraries like Inertia which are built for Laravel but can be used with other frameworks.
It's the only reason I still stay fresh on my PHP.