Reduce unnecessary breaking changes

[incodemode]

Hello
I'm a teacher and a developer. I teach my students about frameworks, package managers and web development through Laravel.
Every year I update the classes to fit the code changes. I understand that changes are usually needed to improve the quality of code. But I'm not here for the changes that improve the code. I'm talking about changes that make the upgrade from one version to another an unnecessary effort. Basically from now on I have decided to tell my students that even though this framework offers many improvements to raw PHP they should be aware that their application may be outdated in a couple of years if they choose to use Laravel. And that they will most certainly require a significant effort to stay up to date with the latest release.
Forms are gone, Middleware and Console changed, Classes changing location unnecesarily.

[ghost]

I totally agree. L 11 was a political breaking change only... NO real gains except for trying to attract new users with simpler promoted structure, but more complicated if you dig deep into it.

[Sophist-UK]

I would agree with this to some extent, but equally this will add to the existing chaos in the package ecosystem (whereby there is often a confusing number of choices of packages to achieve the same thing but they are vary widely in both quality and support).

So, to take the Eloquent example, I can see the benefits both of simplicity/readability of having more whereX methods, but also of simplicity/performance of keeping it minimalistic.

I might therefore advocate:

• Laravel itself having a minimalistic Eloquent; and
• The Laravel team maintaining a package of Eloquent enhancements on an all-or-nothing basis.

Then each user can decide which of these is best for them.

This could be extended to a lot of Laravel - and even to splitting off entire areas of functionality (like Queues) that are not needed for basic web functionality. After all, doing a composer require to add Queues functionality is hardly a major issue so long as it is done in a backwards compatible fashion.

I would also advocate for the Laravel team creating more 1st party packages containing the best features of multiple 3rd party packages (e.g. HMVC comes to mind).

[mbabker]

This could be extended to a lot of Laravel - and even to splitting off entire areas of functionality (like Queues) that are not needed for basic web functionality. After all, doing a composer require to add Queues functionality is hardly a major issue so long as it is done in a backwards compatible fashion.

Conceivably, it can already be done as the core framework components are all split into packages. Except for the Illuminate\Foundation namespace. So you're stuck in an impossible situation where you either require the full-stack laravel/framework package and deal with the bloat that comes with it or you use the individual components and you then have to re-roll the core foundation (which includes the main application class, a lot of CLI commands, the kernels, the exception handler, testing tools, features like form requests or maintenance mode, etc.).

For better or worse, Laravel is meant to be used as a full-stack framework with minimal deviation by its core team, it's not meant to be consumed as its individual components.

[Sophist-UK]

But it wouldn't be hard to create a partial-stack Laravel-Mini which has the core foundation and allow users to add back bits they want.

[mbabker]

It really wouldn't be hard at all. But, that assumes that the core team wants to support using Laravel as a "take what you need and ignore the rest" type of thing, and I just don't get the impression that the interest is there for this type of minimal skeleton from a core perspective. I've yet to adapt some of my applications to the Laravel 11 skeleton, and I doubt I will, because the changes to me reinforce the idea that you should just use things as is and only add on to the skeleton and never remove (in almost every Laravel application, I remove service providers for components I'm not using at all so none of those components even get registered during bootup, and I'm very weary about trying to adapt this with the new setup).

Of course, none of this stops projects like Laravel Zero which looks to be close to this type of setup, but even they got creative to deal with the missing foundation pieces by just copying the code out to a standalone repo.

[shaedrich]

Of course, none of this stops projects like Laravel Zero

There has also been Lumen, but this is deprecated now in favor of using Laravel

This could be extended to a lot of Laravel - and even to splitting off entire areas of functionality (like Queues) that are not needed for basic web functionality.

A similar/combined approach, some might agree more on, would be either

• Adding a list of modules to install to the install command
• Creating presets (console, API, SPA, etc.)

L 11 was a political breaking change only... NO real gains except for trying to attract new users with simpler promoted structure, but more complicated if you dig deep into it.

I sometimes feel like politics tend to get in the way of an otherwise great framework more often these days.

[macropay-solutions]

There is a saying: "If it works, leave it as it is!"

From our experience building an url query language to be used for complex filtering in lumen and laravel, over a period of more than 3 years, starting with laravel/lumen 8, we can say that there are parts of eloquent not so performant or even buggy that we had to replace with macros in our lib, that spread across versions 8 to 11, so it can work on hundred/indefinite number of tables with million rows of data and even with Elastic Search to improve the speed of the queries when sql has its limitations.

• One example is the paginate distinct which they did not fix but rather created a unit test to prevent (a wrong) type of fix for it. We fixed that over 3 years ago in our lib.
• Another one is the relation query: select * from table where exist (select * from table2 where table.key = table2.key and table2. {} = {}) which mysql can't process using indexes because of the table.key = table2.key condition that links the 2 selects.
  And there are more...

Sadly, bottom line is that we saw no interest whatsoever from Laravel (even if we sent them emails) in what we had to offer (free or paid) and we saw this L11 coming out + deprecation of lumen and we understood that Laravel is moving away from:

• microservices and services architectures
• spitted FE and BE
  and it is moving more and more towards monolithic architectures and what is worse, is targeting new users and does not care much about the old ones.

It is a matter of time until someone forks Lumen 10 and continues a proper api framework now that phalcon's core switched to php, making it a little slower and slim being well bellow lumen in functionalities.

UPDATE: Symfony we don't consider as an option for apis because it is slower than lumen, both in delivery time and processing speed.

[ghost]

This is it. This post will remain buried in here :))