Laravel DOES NOT Reuse Code

Hello, I wanted to give another video, a little opinion first of all because I saw that the previous video:

Laravel, a framework that is becoming more difficult to learn, fragmented and redundant every day

These kinds of things sometimes caused me some existential conflicts. I mean, I was starting to get a little negative about it.

Look, I love Laravel—I think that's abundantly clear. Otherwise, I wouldn't bother writing three books about Laravel: one of them is over 700 pages long, and the other two are around 330 pages each, because they're sister books.
And like I said, I love the framework. But I think that, no matter how good it is, you can't become a fanatic about it.

I mean, you always have to be critical of things, regardless of whether they listen to you or not, or if you're just doing it because you want to express yourself.
To, so to speak, comment on what you think, and little else.

That's why I make these videos.
Precisely to break a little bit with the normal guidelines I follow on this channel, and also because I want to give my opinion.
Because I don't like to keep it to myself, and also to see what others think—which I imagine is partly why you're watching this video.

To find out what I think, whether you agree or not, if you want to comment on something different, or simply share your perspective.
And no matter how much, an idea is being sent out, and anyone who sees it can have my opinion, yours, or the opinion of whoever comments.

And I think that's the interesting thing about all this.
Simply that.
It's not, as they say, protecting a position tooth and nail.
It's simply giving a little bit of opinion here, and everyone can consider it however they want.

Laravel does not reuse code from the previous version

So, here I am with another little video that follows somewhat the same line as the previous one.
It's a critique—you could say—again from a place of affection, because I love Laravel.

And, really, these changes—on a personal level—don't bother me much.
Although, of course, when you have projects built in Laravel, and you want, so to speak, to have the latest, like having the latest phone, things get a bit tedious.

Because yes, that's partly why you do it: to stay up-to-date, to take advantage of the latest.
No matter what, you're already standing there on top of the work of the people who implemented the framework.
And what you want is to be there, up-to-date with the changes, so you don't get left behind.

But also, you do it to avoid fragmentation—what I mentioned in the other video.
Because, hey, when something doesn't work, when something breaks due to evolving from version to version... that happens.

Suppose at some point—Laravel 13 or 12, which are the latest versions at the moment—something breaks with Breeze.
And you don't know why it broke, why this Breeze component no longer works the way it used to.

And that happens because Breeze is no longer part of the official package.
So, these things can happen in some projects, and in general, crazy things can happen.

And I think that's normal when you fragment things too much.
Eventually, something can get out of hand. That happens.

Now, that's not exactly what I want to talk about.
I wanted to mention it for some context, but the point of this video is something else.

And it's right there in the title:

"Laravel doesn't reuse code."

What do I mean by this statement?
Well, I think this is something that can be easily deduced...

Viewing a project in Laravel Inertia

If we compare an older Livewire or Inertia project, you'll see a lot of changes. It's like comparing two Bootstrap or Tailwind templates from different developers. It's not that one is better than the other; they're simply different and have a different structure, and that's what we have today.

In an Inertia project, we'll see changes such as:

• A different structure in the components and names, for example, now all the routes are in lowercase:

resources\js\pages\settings\Appearance.vue

They now use TypeScript.

The overall layout, like the components, are completely different. For example, the Label:

<Label label='Type' />

Now is:

<Label>Type</Label>

Fewer options

With Jetstream, we had API Token management here, which is a kind of... I don't know what to call it...
a kind of Spatie, but for the API.
Like saying: "this user can perform certain actions on a REST API."
Although that API doesn't exist yet, but hey, it's implemented there.

And then we have a bit of the same thing I mentioned before, which was to customize precisely those screens.
This is also the part I've always criticized a bit: roles and permissions.

But they didn't call it that here.
For some reason, they decided not to use Spatie—which is a package that works excellently, and that we all already know—
and invented something called Teams.

So... instead of using the traditional system of roles and permissions, which is also compatible with everything,
they decided to reinvent the wheel.

And of course, the functions are practically the same as those you find with roles and permissions in Spatie.
But... they changed the name. And with that, you've lost the entire community, the documentation,
the integrations that already exist, etc.

This is a good example of what I was saying in other videos:
Laravel has great packages, but sometimes it doesn't seem to reuse its own ecosystem.

So, in short:
They took away a lot of super cool stuff we had before.
For example, the avatar upload, which was super useful.
And now you just have an authentication page, registration, profile, and little else.

Duality in technologies

Breeze with Fortify would make sense there. Because Fortify allows you to do the same thing Breeze does, but without the graphical interface part. Therefore, if you wanted to change the graphical interface part and add something else, you could have perfectly used Fortify. There, it would make sense, but here it doesn't because you're using the same thing. So, why stop it? I mean, why don't you use that package from the root? It's an official Laravel package and add the style part.

Comparing the Profile.vue view

• If we compare a project in version 12 or higher with what we had in version 11, we'll see a complete change in:
• Structure

Naming internal components such as buttons and their structure.

For example:

resources/js/Pages/settings/Profile.vue

import { Button } from '@/components/ui/button';
import { Input } from '@/components/ui/input';
import { Label } from '@/components/ui/label';
import AppLayout from '@/layouts/AppLayout.vue';
import SettingsLayout from '@/layouts/settings/Layout.vue';
***
  <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" class="mt-1 block w-full" v-model="form.name" required autocomplete="name" placeholder="Full name" />
                        <InputError class="mt-2" :message="form.errors.name" />
                    </div>

                    <div class="grid gap-2">
                        <Label for="email">Email address</Label>
                        <Input
                            id="email"
                            type="email"
                            class="mt-1 block w-full"
                            v-model="form.email"
                            required
                            autocomplete="username"
                            placeholder="Email address"
                        />
                        <InputError class="mt-2" :message="form.errors.email" />
                    </div>
                    ***

In Laravel 11 with Jetstream:

import InputLabel from '@/Components/InputLabel.vue';
import PrimaryButton from '@/Components/PrimaryButton.vue';
import SecondaryButton from '@/Components/SecondaryButton.vue';
import TextInput from '@/Components/TextInput.vue';
***
<FormSection @submitted="updateProfileInformation">
        <template #title>
            Profile Information
        </template>

        <template #description>
            Update your account's profile information and email address.
        </template>

        <template #form>
            <!-- Profile Photo -->
            <div v-if="$page.props.jetstream.managesProfilePhotos" class="col-span-6 sm:col-span-4">
                <!-- Profile Photo File Input -->
                <input
                    id="photo"
                    ref="photoInput"
                    type="file"
                    class="hidden"
                    @change="updatePhotoPreview"
                >

                <InputLabel for="photo" value="Photo" />

                <!-- Current Profile Photo -->
                <div v-show="! photoPreview" class="mt-2">
                    <img :src="user.profile_photo_url" :alt="user.name" class="rounded-full h-20 w-20 object-cover">
                </div>

In Livewire, we have exactly the same scenario: previously, internal components were used, but now they've all been replaced by Flux.

In short, it's like comparing two projects of the same type from two different developers, with a completely different structure.