Blade, Livewire o Inertia: decidirlo una vez, bien

Todo proyecto Laravel toma esta decisión y un número sorprendente la toma de forma implícita: por lo que agarró el primer desarrollador, y otra vez cuando llegó alguien nuevo con una preferencia.

Las tres opciones son apuestas realmente distintas sobre dónde vive el estado de la aplicación, y el coste de no elegir es una aplicación que lo hace de tres formas.

Blade: el estado vive en el servidor, las páginas recargan

Plantillas renderizadas en el servidor, formularios que envían, redirecciones. La respuesta más antigua y correcta con más frecuencia de lo que sugiere su fama.

Obtiene el modelo mental más simple posible, el menor JavaScript entregado, y una aplicación en la que cualquier persona que sepa Laravel puede trabajar de inmediato. Unas pizcas de Alpine resuelven el desplegable y el modal sin cambiar el modelo.

Deja de encajar cuando una interacción de verdad no puede recargar: un formulario de varios pasos que debe conservar su estado, una tabla que filtra en vivo, cualquier cosa donde una carga completa de página pierda el sitio del usuario.

Elíjalo para: sitios de contenido, CRUD sencillo, herramientas internas, cualquier cosa donde la interacción tenga forma de formulario. Es lo más barato de construir y de mantener, y "ya lo mejoraremos si hace falta" es una opción real aquí de un modo que no lo es en la dirección contraria.

Livewire: el estado vive en el servidor, la página se actualiza

Componentes escritos en PHP. Las interacciones envían una petición, el servidor vuelve a renderizar el componente y la diferencia se aplica al DOM. No hay estado de cliente que mantener sincronizado, porque solo hay una copia.

La ganancia es que un equipo de PHP construye interfaces interactivas sin un segundo lenguaje, una tubería de compilación ni una biblioteca de estado. La validación es su validación de siempre. La autorización son sus policies de siempre.

El coste es el viaje de ida y vuelta. Cada interacción es una petición, así que la latencia se ve donde un componente local sería instantáneo, y una interfaz habladora se convierte en un backend hablador. El otro coste es menos evidente: es fácil meter lógica sustancial en los componentes, y los componentes son la parte más difícil de la aplicación de probar de forma aislada.

Elíjalo para: paneles, administraciones, asistentes, cualquier cosa con forma de CRUD que quiera sentirse viva. Evítelo para: interfaces con mucha interacción local de alta frecuencia - dibujar, arrastrar, filtrar listas grandes en tiempo real.

Inertia: el estado vive en el cliente, el enrutado se queda en el servidor

Sus controladores devuelven props; un componente de página React o Vue los renderiza. Sin capa de API, sin enrutador de cliente, sin lógica de autorización duplicada, pero con un modelo de componentes de cliente de verdad donde importa.

Es la respuesta correcta cuando la interfaz es genuinamente de tipo aplicación y su equipo sabe escribir frontend. Es también la opción con más piezas móviles: un paso de compilación, dos lenguajes, y las complejidades habituales del estado en el cliente.

Elíjalo para: interfaces de producto con interactividad real, equipos que ya tienen capacidad de frontend, aplicaciones cuyo frontend va a seguir creciendo. Evítelo para: un panel de administración que usan tres personas y que no necesita una tubería de compilación.

La pregunta que lo decide

No "cuál es más moderno". Pregunte dónde ocurre la interacción.

Si la acción del usuario acaba naturalmente en un guardado, el servidor puede ser dueño del estado y Blade o Livewire basta. Si el usuario manipula algo un rato antes de confirmar - reordenar, dibujar, filtrar, construir - el estado quiere ser local, y eso es Inertia.

La segunda pregunta es el equipo. Un equipo de backend entregando Livewire rendirá más que ese mismo equipo entregando React, y al revés igual. La comparación de frameworks es menor que esa distancia.

La disposición que funciona

Una elección principal para la aplicación, escrita, con una regla de excepción declarada.

La forma sana habitual es Blade para las páginas de marketing y contenido, un enfoque interactivo para la aplicación en sí, y una nota documentada sobre cuándo se permite el otro. Eso es una página en el repositorio y es la diferencia entre una mezcla deliberada y una accidental.

La forma insana son las tres, llegadas por orden de contratación, con tres estilos de validación y sin forma de responder dónde debería ir una pantalla nueva. La vemos lo bastante a menudo como para que merezca la pena decidir pronto, y pronto es el único momento en que esta decisión es barata.

En un desarrollo nuevo lo resolvemos en la primera fase y lo dejamos por escrito, junto al esquema y al reparto de las colas. Las tres cosas son baratas sobre el papel y caras en cuanto hay código escrito contra ellas. La primera fase de un desarrollo existe sobre todo para decidirlas mientras todavía son baratas.