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.

Let's Talk About Laravel... The Good, The Bad, and The Ugly

Laravel has consolidated itself as one of the best web frameworks on the market thanks to its extensive ecosystem, its functional robustness, and the fluidity it offers during the development process. Unlike other tools focused exclusively on the backend, Laravel stands out for its ability to integrate natively with the client layer (frontend), offering multiple architectural alternatives to structure modern applications.

1. Frontend Integration Strategies: Livewire, Inertia, and REST APIs

The framework provides three main approaches to connect server logic with the user interface, allowing the developer to select the ideal technology depending on the type of project:

Laravel Livewire

It is an optimal solution for developing administrative panels (dashboards) or internal management systems. Livewire allows interacting with the server directly from the view using directives like wire:click.

In a traditional approach using environments like FastAPI, Django, or Node.js, communication with the server requires configuring manual asynchronous requests using libraries like Axios, managing states, routes, and JSON responses in separate files. With Livewire, multiple interactive actions in the interface are resolved natively by directly invoking backend methods, reducing code complexity.

Laravel Inertia

If the project requires the use of modern JavaScript frameworks like Vue, React, or Svelte, Inertia.js acts as a bridge that allows building single-page applications (SPA) using Laravel's standard routing and controllers, without the need to structure an independent API.

REST API with Flutter

For scenarios that demand a native mobile application, Laravel allows exposing its resources and business logic through the development of a REST API. This makes it easier for mobile frameworks like Flutter to consume data in a structured and secure manner.

Note on the language: Despite the framework's architectural excellence, the historical dependency on PHP generates debates in the community. Although modern versions of PHP have incorporated advanced features, backward compatibility support with legacy code can lead to inconsistencies if strict development guidelines are not maintained. As an alternative in other languages, frameworks inspired by Laravel's philosophy have emerged, such as GoFr or Buffalo in the Go (Golang) ecosystem, seeking to replicate its structure in high-concurrency environments.

2. The Release Cycle and Ecosystem Fragmentation

One of the critical points in Laravel's lifecycle is its versioning policy. The transition toward an annual release model for major versions (from Laravel 9 to the current version 13) has accelerated innovation, but it introduces a fragmentation scenario similar to what the Android ecosystem faced on its mobile platforms.

The framework's official authentication ecosystem illustrates this chaotic evolution of tools over short periods of time:

• Laravel UI: The initial standard that integrated Bootstrap and basic authentication scaffolding. It was deprecated shortly after.
• Laravel Jetstream and Laravel Breeze: Introduced to replace Laravel UI, migrating the default design toward Tailwind CSS and adding support for Livewire and Inertia.
• Laravel Fortify: A headless solution that exclusively provides the authentication backend (registration, validation, password recovery), delegating visual responsibility entirely to the developer.
• Laravel Flux: The most recent addition in modern versions (Laravel 12 and 13) for advanced management of user interface components over Livewire.

This rapid succession of tools causes recently introduced packages, such as Laravel AI SDK, to present internal dependency conflicts or functional limitations when trying to run on versions of the framework that differ by just a single annual cycle (for example, between Laravel 12 and Laravel 13).

3. Technical Debt in Legacy Projects

For a software engineer, taking over the maintenance of a legacy project in Laravel represents a considerable technical challenge. The fact that the configuration indicates the system runs under a recent version (such as Laravel 12) does not guarantee the modernity of its internal architecture.

A system originally developed in Laravel 7 or 8 may have had its core manually updated over the years to maintain server compatibility. However, within its internal structure, it is common to find obsolete dependencies such as Laravel UI with Bootstrap or early versions of Laravel Jetstream. If the developer plans to implement modern components (such as Laravel Flux), incompatibility with the old scaffolding will block the integration.

      SUPERFICIALLY UPDATED PROJECT (ARCHITECTURAL TRAP)
      
+-------------------------------------------------------------------------+
|  Framework Core: Laravel 12 (Updated via console)                       |
+-------------------------------------------------------------------------+
|  Internal Structure: Laravel UI + Bootstrap (Obsolete since Laravel 7)  |
+-------------------------------------------------------------------------+
|  Result: Incompatibility with Laravel Flux, Blade Components & IA SDK   |
+-------------------------------------------------------------------------+

This structural inconsistency scenario doubles when integrating third-party tools that also have their own aggressive update cycles, such as Inertia.js 2.0 or the transitions between different Vue APIs (Options API versus Composition API) with TypeScript.

4. Migration Recommendations and Best Practices

When working on long-running personal projects or third-party enterprise systems, updating the framework using traditional console commands can drag along bad habits and obsolete dependencies. To mitigate this problem, the following guidelines are recommended:

Migration from Scratch (Greenfield Approach)

Instead of performing an incremental update on the old repository, the safest strategy consists of creating a completely clean project in the latest stable version (Laravel 13). Subsequently, the business logic is migrated, controllers are adapted, and interface components are refactored manually.

Automated Testing Coverage

Laravel strictly requires the implementation of unit and integration tests. Having a robust test suite allows executing the manual migration and immediately detecting which logical components or Eloquent queries have been affected by the framework's structural changes.

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?