Laravel vs Rails: la comparación ha cambiado

Laravel empezó tomando lo que Rails había demostrado: que un framework puede tener opiniones, que la convención le gana a la configuración para la mayoría de los equipos, y que la experiencia de desarrollo es un objetivo de ingeniería legítimo y no una comodidad.

Eso fue hace quince años. Compararlos hoy en esos términos se pierde lo que de verdad los separa.

En qué siguen coincidiendo

Los dos son full-stack y opinados. Los dos usan active record. Los dos tienen migraciones, una CLI fuerte, una cultura de pruebas madura y una estructura de directorios que se puede predecir antes de abrir el repositorio.

Quien domina uno lee el código del otro con comodidad en una semana. Eso es inusual entre ecosistemas y merece decirse antes que las diferencias.

El trabajo en segundo plano es la mayor brecha práctica

El sistema de colas de Laravel es parte del framework: drivers, reintentos con retroceso, lotes, trabajos únicos, límites de tasa, una tabla de trabajos fallidos y un panel, todo documentado junto y versionado junto.

Rails tiene Active Job como abstracción con un adaptador debajo, con más frecuencia Sidekiq, que es excelente y es un producto aparte con sus propios niveles de pago para las funciones que quizá quiera.

Las dos disposiciones funcionan. La diferencia está en cuántas decisiones y cuántos sistemas posee, y para un equipo pequeño eso importa más que la matriz de funciones.

Tipado y herramientas

El sistema de tipos de PHP ha crecido de forma sostenida y el código Laravel moderno está tipado de punta a punta. El análisis estático sobre una base de código Laravel es maduro y forma parte de CI de forma rutinaria.

La historia de tipado de Ruby es más joven y menos asentada en la práctica. Si valora un comprobador de tipos con el que coopere la mayor parte del ecosistema, PHP va hoy por delante, que no es una frase que nadie habría escrito hace una década.

La economía del alojamiento

PHP se despliega en cualquier cosa. Un único servidor modesto mueve una aplicación Laravel con sus workers de cola y su planificador, y hay plataformas gestionadas hechas específicamente para ello a precios bajos.

El alojamiento de Rails está bien soportado y en general cuesta más en la gama baja, sobre todo por memoria por proceso. A escala pequeña esto es una línea real de un presupuesto. A escala grande deja de importar, porque los dos están dominados por la base de datos y la infraestructura de alrededor.

La contratación, que es el argumento que suele ganar

El mercado de PHP y Laravel es bastante mayor, en todo el mundo y en más niveles de experiencia. El de Rails es más pequeño y se inclina a senior: la gente suele ser excelente, son menos, y cuestan más.

Esto decide más de estas elecciones que cualquier punto técnico de este artículo, y las decide correctamente. Un framework para el que no puede contratar es un framework que estará reescribiendo en cuatro años.

Dónde Rails va genuinamente por delante

Profundidad de las convenciones. Rails lleva más tiempo asentando sus convenciones, y la respuesta a "dónde va esto" está acordada con más frecuencia. Laravel le da más libertad, que los equipos grandes tienen que convertir ellos mismos en reglas escritas.

La historia del frontend. Hotwire y Turbo son una respuesta coherente y madura para construir aplicaciones interactivas sin una pila de frontend aparte. Las opciones equivalentes en Laravel son buenas y son varias, o sea una decisión donde Rails tiene un valor por defecto.

Madurez del camino de actualización. La larga historia de versiones de Rails significa que sus convenciones de actualización están muy rodadas. El ritmo anual de Laravel es predecible y perdona menos quedarse atrás.

Elegir entre ellos hoy

Si tiene un equipo en uno de los dos, esa es la respuesta, y el margen no está cerca.

Si empieza de cero sin preferencia: Laravel si espera contratar y crecer, si el trabajo en segundo plano es central, o si el coste de alojamiento a escala pequeña importa. Rails si quiere las convenciones más asentadas que hay y una respuesta de primera parte para frontends interactivos.

Si está considerando pasar de uno a otro, el consejo honesto es el de siempre: averigüe primero qué le está costando. En la mayoría de estas conversaciones resulta ser el esquema, las pruebas ausentes o la gente que se fue, y nada de eso mejora cambiando de lenguaje.

Dentro de PHP la misma discusión sobre convención y opinión se da frente a Symfony, que es la comparación más cercana una vez fijado el lenguaje. Y si la duda real es la forma del framework y no cuál de ellos, hay una página para eso.