Laravel is NOT *just* a PHP Framework, Evolution and Fragmentation

I want to share my reasons why I consider that Laravel has ceased to be solely a PHP backend framework and has become something more complete. Let's analyze that “something more,” especially in the Laravel 12 version, which introduces important changes that consolidate this vision.

New options when creating a project

When we run:

$ laravel new test

Notice that right from the base root these are the options we have:

○ None                                                     
○ React                                                    
● Vue                                                      
○ Livewire   

If we want a “pure” Laravel installation, meaning only backend, we use None. The other options already incorporate frontend components, turning Laravel into a fullstack framework.

Laravel fullstack: Frontend and Backend in one place

In previous versions, like Laravel 11, these options were not so direct. Previously it was necessary to configure Jetstream or manually integrate frontend frameworks. With Laravel 12, these technologies are already integrated from the initial installation, showing that the framework not only supports backend but also frontend officially.

• This means that from a single project we can:
• Manage server logic with Laravel.
• Integrate frontend frameworks like Vue, React, or Livewire.

Take advantage of all the features of these frameworks without the need for separate projects.

Advantages over other frameworks

Compared to Django or Flask, where we normally need:

• A backend project (Django/Flask).
• A frontend project (Vue/React) that consumes an API.

Laravel simplifies everything into a single project, with complete integration between backend and frontend, avoiding project duplication and the complexity of maintaining separate APIs.

Livewire: the hybrid option

Livewire is an intermediate approach: it maintains the essence of Laravel but allows interactivity on the frontend without completely relying on frameworks like Vue or React. Furthermore, it integrates very well with Alpine.js, offering a lighter and more coherent experience with Laravel.

Inertia.js and Vue

With Inertia, Laravel allows fully integrated Vue projects. The integration now includes:

• Optional TypeScript.
• Ready-to-use configuration with Laravel.
• Clean and professional structure for robust projects.

This is not just a basic Vue project, but a complete integration, showing that Laravel is now seriously thinking about fullstack, not just as a superficial complement.

Laravel is no longer just a backend framework:

• It allows frontend and backend in a single project.
• It integrates modern technologies like Vue, React, Livewire, and Alpine.js.
• It simplifies the creation of professional fullstack projects.

This demonstrates that Laravel has consolidated itself as a complete framework, which facilitates building modern applications without dividing the project into several parts.

Laravel: Increasingly a Freemium Framework or with Paid Features

I wanted to share my thoughts on what I believe is happening with Laravel. I feel it is becoming a "Premium" product, but looking at it from a negative side; that is, an ecosystem increasingly focused on payment. Before starting, I want to clarify that this is purely my opinion and personal speculation. I know some people don't like these things being discussed, but I believe that's what these platforms are for: to share points of view in a polite manner. You can leave your comment indicating if you agree, completely disagree, or if you have a different opinion.

Laravel: Increasingly Business-Focused

My main concern is that I feel Laravel is transforming, little by little, into a paid service. This is something I've noticed in recent versions. Notice that now, in Laravel 12, they present it to you directly: as soon as you create a project, regardless of the starter kit you choose (Livewire, Inertia, or base Laravel), they are already promoting Laravel Cloud.

It is a very direct promotion. As soon as you generate the project to start developing, they place it on a clean page with a centered button whose color contrasts completely with the rest of the interface. Everything is dark and the button stands out in light gray or white. Obviously, it's there to stand out. I understand how the world works and I don't expect everything to be free —it would be hypocritical of me, since I also offer paid material— but the way it is integrated catches my attention.

The "Ubuntu Effect" in Laravel

It seems to me that Laravel is following Ubuntu's path. When you install Ubuntu, you find a lot of pre-installed proprietary software, which in some way breaks the original sense of free software. Something similar is happening with Laravel: they are already introducing services like Laravel Cloud from the start, a paid service owned by the same Laravel people for hosting applications in the cloud.

Paid Options When Creating a Project

When creating a new project, especially if you select Livewire or Inertia, they immediately ask if you want the native authentication system or one called WorkOS. This option appeared out of nowhere as a preferred alternative and, guess what, it's a paid service.

I mention this because precisely on the Laravel Daily channel (in English) they were discussing this topic. A post was mentioned where they claimed that Laravel was not receiving money for this integration. If so, why place it there in such an intrusive way? Sometimes I don't understand where the ecosystem is heading.

Laravel Fragmentation: Innovation or Student Nightmare?

Every year, Laravel incorporates changes that, while powerful, make learning difficult. If we compare a Laravel 11 project with Livewire 3 against one from Laravel 12 with Livewire 3, we find completely different structures. The introduction of packages like Volt and Flux means that, from one year to the next, the project looks like it was written in a different framework.

Livewire Fragmentation: A Thousand Ways to Do the Same Thing

Livewire is perhaps the component that has suffered the most from this metamorphosis. Currently, to return a view to the browser, a student is faced with an overwhelming number of paths:

• Routes that return views directly.
• Traditional controllers.
• Livewire class components (the classic approach similar to MVC/MTV).
• Volt, which merges logic and view into a single file.
  • Now in Livewire 4, when creating a project, it asks if we want it to be single or traditional type.

For an experienced developer, these options are great tools that speed up modern development. However, for a beginner consulting Google or ChatGPT, this is a trap. They will see five different ways to solve a problem and won't have the criteria to know which is the most modern or suitable for their case.

Redundancy and "Dead" Packages (Jetstream, Breeze, and UI)

Another great source of confusion is the redundancy of authentication packages and the creation of systems that then fall into oblivion.

• Jetstream: It implemented its own roles and permissions system instead of standardizing with proven solutions like Spatie, only to be displaced by other alternatives.
• Laravel UI vs. Breeze: Historically, both packages did the same thing (managing base authentication). One used Bootstrap and the other Tailwind. In the end, the student finds tutorials for technologies that have already been deprecated or replaced by the "new big idea" from the Laravel team.

Laravel DOES NOT Reuse Code

First of all, I want to clarify that this is an opinion piece. I love Laravel—and I think that's more than clear considering I've written three books about Laravel, one of more than 700 pages and two of 330 pages each.

However, as much as I care for the framework, I think it's always important to be critical. It's not about blind fanaticism, but about observing and commenting on aspects that affect productivity and the development experience.

Laravel and the evolution of its packages

With version changes, especially starting from Laravel 12 and 13, it's noticeable that code from previous versions isn't always reused. This creates certain problems:

• When you update projects, some functionalities may break.
• Breeze, for example, stopped being part of the official package, which can cause confusion.
• By fragmenting so much, consistency is lost, and uncertainty can be generated about what works and what doesn't.

Change in Inertia project structure

If you compare an old project with a new one in Inertia, you'll notice significant differences:

• Component structure: now all route and component names are lowercase and organized differently.
  • Before: resources/js/Pages/Profile.vue
  • Now: resources/js/pages/settings/Appearance.vue
• Use of TypeScript: it has been incorporated into many new projects.
• Change in internal components:
  • Before: <Label label='Type' />
  • Now: <Label>Type</Label>
• Fewer integrated functionalities:
  • Jetstream previously offered API Tokens and role management with Spatie.
  • Now they invented the concept of Teams, replacing already known roles and permissions, which makes it difficult to reuse existing documentation and community.

Comparison of views and components

Laravel 12/13 (Inertia + TypeScript)

<SettingsLayout>
 <div class="flex flex-col space-y-6">
   <HeadingSmall title="Profile information" description="Update your name and email address" />
   <form @submit.prevent="submit" class="space-y-6">
     <div class="grid gap-2">
       <Label for="name">Name</Label>
       <Input id="name" v-model="form.name" required />
       <InputError :message="form.errors.name" />
     </div>
     <div class="grid gap-2">
       <Label for="email">Email address</Label>
       <Input id="email" type="email" v-model="form.email" required />
       <InputError :message="form.errors.email" />
     </div>
   </form>
 </div>
</SettingsLayout>

Laravel 11 (Jetstream + Livewire)

<FormSection @submitted="updateProfileInformation">
 <template #title>Profile Information</template>
 <template #description>Update your account's profile information and email address.</template>
 <template #form>
   <div v-if="$page.props.jetstream.managesProfilePhotos">
     <input id="photo" ref="photoInput" type="file" class="hidden" @change="updatePhotoPreview">
     <InputLabel for="photo" value="Photo" />
     <div v-show="!photoPreview">
       <img :src="user.profile_photo_url" :alt="user.name" class="rounded-full h-20 w-20 object-cover">
     </div>
   </div>
 </template>
</FormSection>

Conclusion: the structure and components have completely changed, as if two different developers had worked on projects of the same type. This complicates code reuse and generates additional learning.

Duality of technologies: Breeze and Fortify

• Breeze and Fortify perform similar functions.
• Fortify allows separating the authentication logic from the interface, which makes sense.
• But in many cases, components that already existed are reinvented, instead of reusing the official packages and adding style to them.

Summary

Laravel is still an excellent framework, but:

• It doesn't always reuse its own package ecosystem.
• Changes between versions can break existing projects.
• Fragmentation generates a higher learning curve and confusion in the component structure.

In short, one can love Laravel and still criticize design and evolution decisions of the framework.

Conclusion

Laravel is a robust framework and its evolution is impressive, but this constant fragmentation creates an increasingly high barrier to entry. The paradox is that the more "facilities" added to write less code (as in the case of Volt), the more concepts the student must master to understand what is actually happening behind the scenes.

As an educator, which of these "fragmentations" do you feel confuses your students the most currently: the Volt file structure or the choice between multiple Starter Kits?