Laravel NO Reutiliza código

▶

Antes que nada, quiero aclarar que este es un post de opinión. Laravel me encanta —y eso creo que queda más que claro si consideramos que he escrito tres libros sobre Laravel, uno de más de 700 páginas y dos de 330 páginas cada uno.

Sin embargo, por más cariño que le tenga al framework, creo que siempre es importante ser crítico. No se trata de fanatismo ciego, sino de observar y comentar aspectos que afectan la productividad y la experiencia de desarrollo.

Laravel y la evolución de sus paquetes

Con los cambios de versión, especialmente a partir de Laravel 12 y 13, se nota que no siempre se reutiliza el código de versiones anteriores. Esto genera ciertos problemas:

• Cuando actualizas proyectos, algunas funcionalidades pueden romperse.
• Breeze, por ejemplo, dejó de ser parte del paquete oficial, lo que puede causar confusión.
• Al fragmentar tanto, se pierde consistencia y se puede generar incertidumbre sobre qué funciona y qué no.

Cambio en la estructura de proyectos Inertia

Si comparas un proyecto antiguo con uno nuevo en Inertia, notarás diferencias significativas:

• Estructura de componentes: ahora todos los nombres de rutas y componentes están en minúscula y organizados de forma distinta.
  • Antes: resources/js/Pages/Profile.vue
  • Ahora: resources/js/pages/settings/Appearance.vue
• Uso de TypeScript: se ha incorporado en muchos proyectos nuevos.
• Cambio en componentes internos:
  • Antes: <Label label='Type' />
  • Ahora: <Label>Type</Label>
• Menos funcionalidades integradas:
  • Jetstream antes ofrecía manejo de API Tokens y roles con Spatie.
  • Ahora inventaron el concepto de Teams, reemplazando roles y permisos ya conocidos, lo que dificulta reutilizar la documentación y la comunidad existente.

Comparación de vistas y componentes

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>

Conclusión: la estructura y los componentes han cambiado completamente, como si dos desarrolladores distintos hubieran trabajado en proyectos del mismo tipo. Esto complica la reutilización de código y genera un aprendizaje adicional.

Dualidad de tecnologías: Breeze y Fortify

• Breeze y Fortify cumplen funciones similares.
• Fortify permite separar la lógica de autenticación de la interfaz, lo cual tiene sentido.
• Pero en muchos casos, se reinventan componentes que ya existían, en lugar de reutilizar los paquetes oficiales y agregarles estilo.

Resumen

Laravel sigue siendo un framework excelente, pero:

• No siempre reutiliza su propio ecosistema de paquetes.
• Los cambios entre versiones pueden romper proyectos existentes.
• La fragmentación genera una curva de aprendizaje más alta y confusión en la estructura de componentes.

En definitiva, uno puede amar Laravel y aún así criticar decisiones de diseño y evolución del framework.