Laravel NO es *solo* un Framework PHP, Evolución y Fragmentación

Quiero compartir mis razones por las cuales considero que Laravel ha dejado de ser únicamente un framework PHP del backend y se ha convertido en algo más completo. Vamos a analizar ese “algo más”, especialmente en la versión Laravel 12, que introduce cambios importantes que consolidan esta visión.

Nuevas opciones al crear un proyecto

Cuando ejecutamos:

$ laravel new test

Fíjate que ya de raíz de base las opciones que tenemos:

○ None                                                     
○ React                                                    
● Vue                                                      
○ Livewire   

Si queremos una instalación “pura” de Laravel, es decir, solo backend, usamos None. Las otras opciones ya incorporan componentes frontend, convirtiendo a Laravel en un framework fullstack.

Laravel fullstack: Frontend y Backend en un solo lugar

En versiones anteriores, como Laravel 11, estas opciones no eran tan directas. Antes era necesario configurar Jetstream o integrar manualmente frameworks frontend. Con Laravel 12, estas tecnologías ya vienen integradas desde la instalación inicial, mostrando que el framework no solo soporta backend, sino también frontend de manera oficial.

• Esto significa que desde un solo proyecto podemos:
• Gestionar la lógica del servidor con Laravel.
• Integrar frameworks frontend como Vue, React o Livewire.

Aprovechar todas las características de estos frameworks sin necesidad de proyectos separados.

Ventajas frente a otros frameworks

Comparado con Django o Flask, donde normalmente necesitamos:

• Un proyecto backend (Django/Flask).
• Un proyecto frontend (Vue/React) que consuma una API.

Laravel simplifica todo a un solo proyecto, con integración completa entre backend y frontend, evitando la duplicidad de proyectos y la complejidad de mantener APIs separadas.

Livewire: la opción híbrida

Livewire es un enfoque intermedio: mantiene la esencia de Laravel pero permite interactividad en el frontend sin depender totalmente de frameworks como Vue o React. Además, se integra muy bien con Alpine.js, ofreciendo una experiencia más ligera y coherente con Laravel.

Inertia.js y Vue

Con Inertia, Laravel permite proyectos Vue totalmente integrados. La integración ahora incluye:

• TypeScript opcional.
• Configuración lista para usar con Laravel.
• Estructura limpia y profesional para proyectos robustos.

Esto no es solo un proyecto básico en Vue, sino una integración completa, mostrando que Laravel ya piensa en fullstack de manera seria, no solo como un complemento superficial.

Laravel ya no es solo un framework backend:

• Permite frontend y backend en un solo proyecto.
• Integra tecnologías modernas como Vue, React, Livewire y Alpine.js.
• Simplifica la creación de proyectos fullstack profesionales.

Esto demuestra que Laravel se ha consolidado como un framework completo, que facilita construir aplicaciones modernas sin dividir el proyecto en varias partes.

Laravel, Cada día un framework más Freemium o con características de Pago

Quería comentar un poco mi opinión sobre lo que creo que está pasando con Laravel. Siento que se está convirtiendo en un producto "Premium", pero viéndolo desde el lado negativo; es decir, un ecosistema cada vez más enfocado al pago. Antes de comenzar, quiero aclarar que esto es netamente mi opinión y una especulación personal. Sé que a algunas personas no les gusta que se comenten estas cosas, pero creo que para eso están estos medios: para compartir puntos de vista de manera educada. Puedes dejar tu comentario indicando si estás de acuerdo, en total desacuerdo o si tienes una opinión diferente.

Laravel: Cada día más enfocado al negocio

Mi preocupación principal es que siento que Laravel se está transformando, poco a poco, en un servicio de pago. Esto es algo que he notado en las últimas versiones. Fíjate que ahora, en Laravel 12, te lo presentan directamente: apenas creas un proyecto, sin importar el starter kit que elijas (Livewire, Inertia o Laravel base), ya te están promocionando Laravel Cloud.

Es una promoción muy directa. Apenas generas el proyecto para empezar a desarrollar, te lo colocan en una página limpia con un botón centrado cuyo color contrasta completamente con el resto de la interfaz. Todo es oscuro y el botón resalta en un gris claro o blanco. Obviamente, está ahí para resaltar. Yo entiendo cómo funciona el mundo y no pretendo que todo sea gratis —sería hipócrita de mi parte, ya que yo también ofrezco material de pago—, pero me llama la atención la forma en que se integra.

El "Efecto Ubuntu" en Laravel

Me parece que Laravel está siguiendo el camino de Ubuntu. Cuando instalas Ubuntu, te encuentras con mucho software propietario preinstalado, lo que de alguna manera rompe un poco el sentido original del software libre. Con Laravel pasa algo similar: ya te están introduciendo servicios como Laravel Cloud de entrada, un servicio de pago propiedad de la misma gente de Laravel para alojar aplicaciones en la nube.

Opciones de pago al crear un proyecto

Al crear un proyecto nuevo, especialmente si seleccionas Livewire o Inertia, te preguntan de inmediato si quieres el sistema de autenticación nativo o uno llamado WorkOS. Esta opción apareció de la nada como una alternativa predilecta y, adivina, es un servicio de pago.

Menciono esto porque precisamente en el canal de Laravel Daily (en inglés) comentaban este tema. Se mencionó una publicación donde afirmaban que Laravel no estaba percibiendo dinero por esta integración. Si es así, ¿para qué colocarlo ahí de forma tan intrusiva? A veces no entiendo hacia dónde va el ecosistema.

La fragmentación de Laravel: ¿Innovación o Pesadilla para el Estudiante?

Cada año, Laravel incorpora cambios que, aunque potentes, dificultan el aprendizaje. Si comparamos un proyecto de Laravel 11 con Livewire 3 frente a uno de Laravel 12 con Livewire 3, nos encontramos con estructuras completamente distintas. La introducción de paquetes como Volt y Flux hace que, de un año a otro, el proyecto parezca escrito en un framework diferente.

La fragmentación de Livewire: Mil formas de hacer lo mismo

Livewire es quizás el componente que más ha sufrido esta metamorfosis. Actualmente, para devolver una vista al navegador, un estudiante se encuentra con una cantidad abrumadora de caminos:

• Rutas que devuelven vistas directamente.
• Controladores tradicionales.
• Componentes de clase de Livewire (el enfoque clásico similar al MVC/MTV).
• Volt, que fusiona la lógica y la vista en un solo archivo.
  • Ahora en Livewire 4 al momento de crear un proyecto nos pregunta si queremos que sea de tipo single o tradicional

Para un desarrollador con experiencia, estas opciones son herramientas geniales que agilizan el desarrollo moderno. Sin embargo, para un principiante que consulta Google o ChatGPT, esto es una trampa. Verá cinco formas distintas de resolver un problema y no tendrá el criterio para saber cuál es la más moderna o la más adecuada para su caso.

Redundancia y paquetes "muertos" (Jetstream, Breeze y UI)

Otra gran fuente de confusión es la redundancia de paquetes de autenticación y la creación de sistemas que luego caen en el olvido.

• Jetstream: Implementó su propio sistema de roles y permisos en lugar de estandarizar con soluciones probadas como Spatie, para luego ser desplazado por otras alternativas.
• Laravel UI vs. Breeze: Históricamente, ambos paquetes hacían lo mismo (gestionar la autenticación base). Uno usaba Bootstrap y el otro Tailwind. Al final, el estudiante se encuentra con tutoriales de tecnologías que ya han sido deprecadas o reemplazadas por la "nueva gran idea" del equipo de Laravel.

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 1700 páginas y dos de 700 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.

Conclusión

Laravel es un framework robusto y su evolución es impresionante, pero esta fragmentación constante crea una barrera de entrada cada vez más alta. La paradoja es que, mientras más "facilidades" se agregan para escribir menos código (como el caso de Volt), más conceptos debe dominar el alumno para entender qué está pasando realmente detrás de escena.

Como educador, ¿cuál de estas "fragmentaciones" sientes que es la que más confunde a tus alumnos actualmente: la estructura de archivos de Volt o la elección entre los múltiples Starter Kits?