Laravel NO Reutiliza código

Hola por aquí quería dar otro video un poco de opinión antes que nada porque vi que el video anterior:

Laravel, un framework cada día más dificil de aprender, fragmentado y redundante

Este tipo de cosas, a veces, me ocasionaban algunos conflictos existenciales. Es decir, como que me empezaba a poner un poquito negativo en ese sentido.

A ver, a mí me encanta Laravel —yo creo que eso queda más que claro. Si no, no me molestaría en crear tres libros sobre Laravel: uno de ellos tiene más de 700 páginas, y los otros dos tienen alrededor de 330 páginas cada uno, porque son libros hermanos.
Y como te digo, me encanta el framework. Pero yo creo que, por más bueno que sea, uno no puede fanatizarse.

Es decir, uno siempre tiene que ser crítico con las cosas, independientemente de si te escuchan o no, o si simplemente lo haces porque te quieres expresar.
Para, como quien dice, comentar lo que uno piensa, y poco más.

Por eso es que yo hago estos videos.
Precisamente para romper un poquito el lineamiento normal que sigo en este canal, y también porque quiero dar mi opinión.
Porque no me gusta guardármela, y también para ver qué piensan los demás —que me imagino que es un poco el motivo por el cual estás viendo este video.

Para saber qué pienso yo, si estás de acuerdo o no, si quieres comentar algo distinto o simplemente compartir tu perspectiva.
Y por más que sea, ahí se va mandando una idea, y cualquier persona que lo vea puede tener mi opinión, la tuya, la de quien comente.

Y yo creo que eso es lo interesante de todo esto.
Simplemente eso.
No es como quien dice, proteger una postura a capa y espada.
Es simplemente dar aquí un poquito de opinión, y que cada quien lo considere como quiera.

Laravel no reutiliza el código de la versión anterior

Entonces, aquí vengo con otro videíto que sigue un poco el mismo lineamiento del anterior.
Es una crítica —se pudiera decir—, otra vez desde el cariño, porque a mí me encanta Laravel.

Y, realmente, estos cambios —a nivel personal— me traen un poco sin cuidado.
Aunque claro, cuando uno tiene proyectos montados en Laravel, y uno quiere, como quien dice, tener lo último, como tener el último teléfono, la cosa se vuelve un poco tediosa.

Porque sí, uno lo hace un poco por eso: por estar al día, por aprovechar lo último.
Por más que sea, ya estás parado ahí sobre el trabajo de gente que implementó el framework.
Y tú lo que quieres es estar ahí, al día con los cambios, para no quedarte atrás.

Pero también, lo haces para evitar la fragmentación —eso que te comentaba en el otro video.
Porque, oye, cuando algo no funciona, cuando algo se rompe por estar evolucionando de versión en versión… eso pasa.

Suponte que en algún punto —Laravel 13 o 12, que son de las últimas al momento— se rompe algo con Breeze.
Y tú no sabes por qué se rompió, por qué este componente de Breeze ya no funciona como antes.

Y eso sucede porque Breeze ya no forma parte del paquete oficial.
Entonces, estas cosas pueden suceder en algunos proyectos y, en general, pueden pasar cosas locas.

Y creo que eso es lo normal cuando fragmentas demasiado las cosas.
A la final, algo se te puede salir de las manos. Eso pasa.

Ahora, no es exactamente de eso de lo que quiero hablar.
Lo quería mencionar para contextualizar un poco, pero el punto de este video es otro.

Y está ahí en el título:

"Laravel no reutiliza código"

¿A qué me refiero con esta afirmación?
Bueno, creo que esto es algo que se puede deducir fácilmente...

Viendo un proyecto en Laravel Inertia

Si comparamos un proyecto antiguo de Livewire o inertia, veras que hay muchos cambios, es como si compares dos plantillas para Bootstrap o Tailwind de desarrolladores distintos, no es que una sea mejor que otra, si no, son simplemente distintas y tienen una estructura distinta, y eso es lo que tenemos actualmente.

En un proyecto en Inertia, veremos cambios como:

• Una estructura distinta en los componentes y nombrados, por ejemplo, ahora todas las rutas son en minuscula:

resources\js\pages\settings\Appearance.vue

Ahora emplean TypeScript.

El layout en general al igual que los componentes, son completamente distintos, por ejemplo, el Label:

<Label label='Type' />

Ahora es:

<Label>Type</Label>

Menos opciones

Con Jetstream teníamos aquí el manejo de API Tokens, que es una especie de… no sé cómo llamarlo...
una especie de Spatie, pero para la API.
Como decir: “este usuario puede realizar ciertas acciones sobre alguna REST API”.
Aunque esa API ni exista todavía, pero bueno, ahí está implementado.

Y luego tenemos un poco lo mismo que comentaba antes, que era para personalizar precisamente esas pantallas.
Aquí también viene la parte que siempre he criticado un poquito: los roles y permisos.

Pero aquí no lo llamaron así.
Ellos, por alguna razón, decidieron no usar Spatie —que es un paquete que funciona excelente, que ya todos conocemos—
y se inventaron algo llamado Teams.

Entonces... en vez de usar el sistema tradicional de roles y permisos, que además es compatible con todo,
decidieron reinventar la rueda.

Y claro, las funciones son prácticamente las mismas que tú encuentras con roles y permisos en Spatie.
Pero... le cambiaron el nombre. Y ya con eso, te perdiste toda la comunidad, la documentación,
las integraciones que ya existen, etc.

Este es un buen ejemplo de lo que te comentaba en otros videos:
Laravel tiene paquetes buenísimos, pero a veces parece que no reutiliza su propio ecosistema.

Y bueno, en definitiva:
Nos quitaron un montón de cosas supergeniales que teníamos antes.
Por ejemplo, la carga del avatar, que estaba súper útil.
Y ahora apenas tienes una página de autenticación, registro, perfil y poco más.

Dualidad en tecnologías

Breeze con fortify ahí si tuviera un sentido Porque fortify te permite hacer lo mismo que hace Breeze pero si la parte de inter de interfaz gráfica por lo tanto si tú querías cambiar la parte interfaz gráfica y colocar otra cosa perfectamente habías podido emplear Fortify ahí sí tenía sentido pero aquí no porque estás empleando lo mismo entonces para qué lo para o sea por qué no utilizas de raiz ese paquete es un paquete oficial de Laravel y le agregas la parte del estilo.

Comparando la vista de Profile.vue

• Si comparamos un proyecto en la versión 12 o superior con lo que teníamos en la versión 11, veremos un completo cambio en:
• Estructura

Nombrado de componentes Internos como botones y su estructura.

Por ejemplo:

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>
                    ***

En Laravel 11 con 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>

En Livewire, tenemos exactamente el mismo escenario, cuando antes de usaba componentes internos, ahora todos fueron reemplazador por Flux.

En definitiva, es como si compararas dos proyectos de un mismo tipo de dos desarrolladores distintos, una estructura completamente cambiada.