> Two major versions with breaking changes per year? This seems a bit too fast paced for my taste.
They provide LTS releases (similar to Ubuntu). I'd definitely recommend sticking to them for projects that are / will be in maintenance mode. The breaking changes are usually minor, so for actively developed projects, using the regular versions is fine.
You can also use https://laravelshift.com/. I always manually updated using the documentation upgrade guide and never had a problem which will apply to most people who don't use internal undocumented functions.
The changes in each major version are pretty small. They’re sticking to semantic versioning now so if there is a major version bump, it’s likely a small change to some internal library that would only be breaking in the technical sense.
Plus, this is the pace the framework has adopted for a long time now so most of the devs in the ecosystem are used to doing an upgrade once or twice a year. Generally they’re very quick. < 15 min.
edit: to clarify, historically they've bumped the minor version number whenever they had major changes in the API, and now the major version bumps are usually non-breaking changes. I don't think the team fully understands Semver.
Laravel is great - makes getting routine things done in PHP a lot less bothersome with the ol' convention over configuration philosophy that Rails introduced.
I've used it for several web applications running in production and have always been very pleased with what it has to offer. The documentation is pretty good too.
Great work going in this framework, along with Symfony are a driving force for PHP. This is no-bullshit tool for making web sites where most details are thought out. It may be opinionated but if you learn and follow it instead of working against it you can have a super quick turnaround from concept to production.
I love Laravel and used it for several projects. My only issue with it currently is its landing page. Where I can't easily distinguish Free parts of the ecosystem and Paid parts. And have to go over each component landing page to see the pricing.
For example they show Passport which is a free OAuth2 library exactly the same way as Nova which is a pay-per-project admin dashboard.
Laravel seems to be doing great. The number of improvements in DX and the ecosystem is moving at a nice pace. I often compare it with Ruby On Rails framework (my primary stack) which is unfortunately not focusing much on DX anymore.
For instance, Laravel has been consistently improving authentication by providing official packages right into the framework. Whereas, Rails still doesn't have an official gem backed into the framework. The recent change of hands of "devise" gem would have been a great opportunity for Rails to take it over.
The problem with RoR is still a Basecamp Framework. Even though it is used by Github and Shopify. Things like ActionView-Component [1] couldn't be merged because it is not used in Basecamp, even though it is used in production at Github.
Auth / Devise as mentioned is another one. Active Storage problem is another one, ( which leads to Paperclip stop being maintained )
Laravel Airlock is my favorite thing about this release. I already started using it for one of my sites, it makes API authentication so much easier than it used to be with Passport.
One of the most interesting things about the Laravel ecosystem is how an open source project has allowed multiple independent businesses spring up around the core project that facilitate things like management, deployment, etc. I know laravel is not unique in this respect, and that lots of the tooling around it is from Taylor Otwell (founder) but there are lots of others as well.
I’ve always been impressed by how developer quality of life is such a high priority goal of Laravel. I think much of its adoption, and the successful businesses that have sprung up around it is a validation that they’ve done that right.
do you work with Laravel ... it has not advanced dev quality of life. It has great marketing and has grabbed a % of the dev base so lots of people work with it. It has done nothing better than symfony, codeigniter, Zendframework.
I feel it breeds bad coding habbits, many coders like it simplicity but when they use it they implement many inefficient functions, mostly around querying the database. Laravel has this robust query builder api so you have many novices accessing the database through it without understanding what they are doing.
I dont really know what "quality of life" is provided by Laravel. Its just another MVC.
Quality of life is better because you can build so much, so quickly with laravel. There is a ton that laravel can bootstrap for you out of the box and then add to that the very large ecosystem of plugins that has come out of the community.
I've worked with Laravel in the past few months. Having never worked with PHP, I went from eew PHP?! to a delightful, fast-paced development model. It shows that good documentation and listening to your user-base will get an Open Source project really far.
It just gets even small things right, nice testing support, database migrations, request validations, events and broadcasting, you name it!
We are ever grateful to Taylor otwel and the team for developing and maintaining Laravel, ever wonder why most of us African web developers use Laravel as a web framework? Because it works and fast without much need for fancy tweaks (here a decent internet is still a luxury in most parts of the continent), Laravel allows you to spring up a decent web app fast without much hassle, you can easily set it up in the cloud and it will be up and running with need for maintenance and site reliability issues. More grease to your elbows Taylor and the rest of the Laravel team.
I've stopped using since Laravel 5.4, switched to Symfony 2.8 up to now (5.0) and recently also Flask or Django (at least for back end).
My biggest pains were the facades and also I wasn't a big fan of the Active Records (with the empty classes and only doing autocomplete by regularly generating loads of annotations).
Being a freelancer and the increasing popularity, I suppose it's worth taking a look again.
Though I'm still a bit hesitant to use it for my own long-term projects, especially since there are so many breaking changes and there are some side projects I won't be able to update for 3 to 12 months while I work freelance or build up new projects.
Can anyone share their experience using + updating a Laravel-based website which is at least 2 years old, especially regarding maintainability?
No, not really. It was my entry point into Python, now I use Django mostly.
PHP opportunities are much more. I like using Symfony, though I also get Laravel or E-Commerce (e.g. Shopware, Spryker) offers. But of course this is because my profile is PHP / JS, so I get these offers.
Though Node.js as back end is noticeably increasing.
I was turned off of Laravel from a bad experience of the very reason you're afraid of it. Back in 2017 I was hired to take over a large Laravel 4.2 project, which included upgrading it to 5.0+ version. The upgrade was a very long, extremely painful experience, and Laravel itself progressed from 5.0 to 5.2 during our upgrade so it was like trying to hit a moving target.
I know there is a lot of capability wrapped up in the framework which enables rapid development, but for long lived applications, you're going to spend a not-insignificant amount of your time keeping up with upgrades. So in a sense, the framework itself becomes technical debt. That makes it a bad framework from my point of view.
Your code base should not be forced to be so tightly coupled to the framework that you have to spend time updating it to keep up with the framework versions (or get stuck on an old version).
Yeah, my first Laravel application (actually my first use of a framework) was Laravel 4.2 because my personal project was getting more and more complex.
When I wanted to upgrade, reading this did make me wonder a bit: "The recommended method of upgrading is to create a new Laravel 5.0 install and then to copy your 4.2 site's unique application files into the new application. This would include controllers, routes, Eloquent models, Artisan commands, assets, and other code specific to your application."
My worry was: "Do I have to do this with every version??!"
Fortunately not, but the updates did take some time; I still updated a few minor versions before moving to Symfony.
I have 4 years old project. Currently stacked at 5.5 (5.2->5.3->5.5), because updating to 5.8 had some issues with socialite logins.
But main issue was the new jwt token package version completely change how it's working.
Having android app users that rely on old jwt package, I don't have much motivation to upgrade to new version and wasting lots of time and having headache. Imo easier will be to completely move to other framework.
Especially since I really don't like laravel facades.
two things I noticed:
1) the great majority of features were authored or contributed by Taylor Otwell - in any cases he was the only name next to each feature. How this is sustainable in the long term?
2) it is still using a lot of singletone/static methods and so on, how they can promote some solid testing culture?
As a long-time PHP developer, I love Laravel, all of its features, and how the community has built around it, but there are a couple of pain points I felt when I used it last year, not sure if these have improved:
1. Very difficult to get running in shared hosting.
2. Feels a bit heavyweight for a SPA (Single Page Application) where the Javascript front-end framework (e.g. Angular, React) is doing most of the work, and the PHP Laravel backend is just processing the CRUD APIs in REST.
31 comments
[ 2.1 ms ] story [ 69.1 ms ] threadTwo major versions with breaking changes per year? This seems a bit too fast paced for my taste.
But I haven't used the framework and would love the input of someone that had to maintain a Laravel project for more than a year.
They provide LTS releases (similar to Ubuntu). I'd definitely recommend sticking to them for projects that are / will be in maintenance mode. The breaking changes are usually minor, so for actively developed projects, using the regular versions is fine.
Plus, this is the pace the framework has adopted for a long time now so most of the devs in the ecosystem are used to doing an upgrade once or twice a year. Generally they’re very quick. < 15 min.
I will believe that when I see it.
edit: to clarify, historically they've bumped the minor version number whenever they had major changes in the API, and now the major version bumps are usually non-breaking changes. I don't think the team fully understands Semver.
I've used it for several web applications running in production and have always been very pleased with what it has to offer. The documentation is pretty good too.
For example they show Passport which is a free OAuth2 library exactly the same way as Nova which is a pay-per-project admin dashboard.
For instance, Laravel has been consistently improving authentication by providing official packages right into the framework. Whereas, Rails still doesn't have an official gem backed into the framework. The recent change of hands of "devise" gem would have been a great opportunity for Rails to take it over.
[1] https://github.com/github/view_component
I’ve always been impressed by how developer quality of life is such a high priority goal of Laravel. I think much of its adoption, and the successful businesses that have sprung up around it is a validation that they’ve done that right.
I feel it breeds bad coding habbits, many coders like it simplicity but when they use it they implement many inefficient functions, mostly around querying the database. Laravel has this robust query builder api so you have many novices accessing the database through it without understanding what they are doing.
I dont really know what "quality of life" is provided by Laravel. Its just another MVC.
The alternatives remain popular, if less so since Laravel's marketing has kicked in. To each their own.
It just gets even small things right, nice testing support, database migrations, request validations, events and broadcasting, you name it!
My biggest pains were the facades and also I wasn't a big fan of the Active Records (with the empty classes and only doing autocomplete by regularly generating loads of annotations).
Being a freelancer and the increasing popularity, I suppose it's worth taking a look again.
Though I'm still a bit hesitant to use it for my own long-term projects, especially since there are so many breaking changes and there are some side projects I won't be able to update for 3 to 12 months while I work freelance or build up new projects.
Can anyone share their experience using + updating a Laravel-based website which is at least 2 years old, especially regarding maintainability?
PHP opportunities are much more. I like using Symfony, though I also get Laravel or E-Commerce (e.g. Shopware, Spryker) offers. But of course this is because my profile is PHP / JS, so I get these offers.
Though Node.js as back end is noticeably increasing.
I know there is a lot of capability wrapped up in the framework which enables rapid development, but for long lived applications, you're going to spend a not-insignificant amount of your time keeping up with upgrades. So in a sense, the framework itself becomes technical debt. That makes it a bad framework from my point of view.
Your code base should not be forced to be so tightly coupled to the framework that you have to spend time updating it to keep up with the framework versions (or get stuck on an old version).
When I wanted to upgrade, reading this did make me wonder a bit: "The recommended method of upgrading is to create a new Laravel 5.0 install and then to copy your 4.2 site's unique application files into the new application. This would include controllers, routes, Eloquent models, Artisan commands, assets, and other code specific to your application."
My worry was: "Do I have to do this with every version??!"
Fortunately not, but the updates did take some time; I still updated a few minor versions before moving to Symfony.
1. Very difficult to get running in shared hosting.
2. Feels a bit heavyweight for a SPA (Single Page Application) where the Javascript front-end framework (e.g. Angular, React) is doing most of the work, and the PHP Laravel backend is just processing the CRUD APIs in REST.