Laravel vs Symfony

La relacion entre Laravel y Symfony: una historia de colaboracion

Para entender la comparativa entre Laravel y Symfony, es fundamental comprender algo que muchos desarrolladores desconocen: Laravel no compite con Symfony en el sentido tradicional, sino que se construye sobre el. Esta es una de las relaciones mas singulares en el ecosistema open source.

Cuando Taylor Otwell creo Laravel en 2011, tomo la decision estrategica de no reinventar la rueda. En lugar de escribir su propia implementacion de HTTP, su propia consola CLI o su propio sistema de eventos, opto por utilizar los componentes desacoplados de Symfony como base. Esta decision ha sido clave en el exito de Laravel: le permitio centrarse en la experiencia del desarrollador y en las capas de abstraccion, delegando la infraestructura de bajo nivel a componentes probados en produccion por miles de empresas.

En la actualidad, Laravel utiliza aproximadamente 20 componentes de Symfony de forma directa. Los mas importantes son:

• symfony/http-foundation: gestiona objetos Request y Response, cookies, sesiones y archivos subidos
• symfony/http-kernel: el ciclo de vida de la peticion HTTP (aunque Laravel lo envuelve con su propio Kernel)
• symfony/console: la base de Artisan, el CLI de Laravel
• symfony/routing: Laravel usaba este componente directamente en versiones anteriores; ahora tiene su propio router pero la influencia es clara
• symfony/event-dispatcher: el sistema de eventos que Laravel expone como Events y Listeners
• symfony/finder: para buscar archivos y directorios (usado internamente por auto-discovery)
• symfony/process: para ejecutar procesos del sistema operativo
• symfony/mailer: la base del sistema de correo de Laravel desde Laravel 9
• symfony/mime: para construir mensajes MIME de email
• symfony/var-dumper: la funcion dd() que tanto usan los laravelers es Symfony puro
• symfony/error-handler: gestion de errores y excepciones
• symfony/translation: el sistema de traducciones (i18n)
• symfony/uid: generacion de UUIDs y ULIDs
• symfony/string: utilidades para manipulacion de strings (Str helper de Laravel lo usa)
• symfony/css-selector: para testing con aserciones CSS en vistas
• symfony/dom-crawler: para testing de respuestas HTML

Esto significa que cuando haces dd($variable) en Laravel, estas usando Symfony. Cuando ejecutas php artisan migrate, Symfony Console esta detras. Cuando Laravel procesa una peticion HTTP, el objeto Request es una instancia de Symfony HttpFoundation envuelta en la clase Illuminate\Http\Request.

Fabien Potencier, creador de Symfony, ha expresado en multiples ocasiones que esta relacion es beneficiosa para ambos proyectos. Laravel aporta un numero enorme de usuarios que, indirectamente, testean y contribuyen a los componentes Symfony. A su vez, Symfony se beneficia de la popularidad de Laravel para demostrar que sus componentes son lo suficientemente buenos como para que el framework PHP mas popular del mundo los utilice.

Filosofia: convencion vs configuracion

La diferencia filosofica entre Laravel y Symfony es la clave para elegir entre ambos. No se trata de que uno sea mejor que otro, sino de que priorizan cosas diferentes.

Laravel apuesta por la experiencia del desarrollador (DX). Su objetivo es que escribas el menor codigo posible para lograr el mayor resultado. Las convenciones son claras: un modelo User busca automaticamente la tabla users, las migraciones se ejecutan en orden cronologico, las rutas se definen en archivos predefinidos, y el Service Container resuelve dependencias automaticamente sin necesidad de configuracion explicita.

Symfony apuesta por la flexibilidad y el control explicito. Cada decision es configurable. Puedes elegir exactamente que componentes usar, como se inyectan las dependencias, como se mapeael ORM, y como se procesan las peticiones. Esta flexibilidad tiene un coste: mas codigo de configuracion, mas archivos YAML, mas conceptos que aprender. Pero a cambio, tienes un control granular que en proyectos enterprise complejos es invaluable.

Un ejemplo practico: para crear un controlador con una ruta en Laravel, escribes esto:

// routes/web.php
Route::get('/posts', [PostController::class, 'index']);

// app/Http/Controllers/PostController.php
class PostController extends Controller
{
    public function index()
    {
        return view('posts.index', [
            'posts' => Post::latest()->paginate(15),
        ]);
    }
}

En Symfony, el enfoque es diferente:

// src/Controller/PostController.php
#[Route('/posts', name: 'post_index')]
class PostController extends AbstractController
{
    public function __construct(
        private PostRepository $postRepository,
    ) {}

    #[Route('/', methods: ['GET'])]
    public function index(): Response
    {
        return $this->render('post/index.html.twig', [
            'posts' => $this->postRepository->findLatestPaginated(15),
        ]);
    }
}

Ambos logran lo mismo, pero el enfoque es distinto. Laravel usa un archivo de rutas centralizado y Eloquent con su interfaz fluida. Symfony usa atributos PHP para las rutas y un repositorio inyectado explicitamente. Ninguno es objetivamente mejor: son filosofias diferentes.

ORM: Eloquent vs Doctrine

Esta es quiza la diferencia tecnica mas significativa entre ambos frameworks, y merece un analisis detallado porque el ORM condiciona toda la arquitectura de la aplicacion.

Eloquent sigue el patron Active Record: cada modelo es simultaneamente una representacion de los datos y el mecanismo de acceso a la base de datos. Un modelo Post sabe como guardarse, borrarse, actualizarse y consultarse.

// Eloquent - Active Record
$post = new Post();
$post->title = 'Mi artículo';
$post->slug = 'mi-articulo';
$post->user_id = auth()->id();
$post->save();

// Consultas fluidas
$posts = Post::where('published', true)
    ->with(['author', 'tags'])
    ->orderByDesc('created_at')
    ->paginate(15);

// Relaciones declarativas
class Post extends Model
{
    public function author(): BelongsTo
    {
        return $this->belongsTo(User::class, 'user_id');
    }

    public function tags(): BelongsToMany
    {
        return $this->belongsToMany(Tag::class);
    }
}

Doctrine sigue el patron Data Mapper: las entidades son objetos PHP puros (POPOs) que no saben nada de la base de datos. El EntityManager se encarga de la persistencia por separado.

// Doctrine - Data Mapper
#[ORM\Entity(repositoryClass: PostRepository::class)]
#[ORM\Table(name: 'posts')]
class Post
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 255)]
    private string $title;

    #[ORM\ManyToOne(targetEntity: User::class)]
    #[ORM\JoinColumn(nullable: false)]
    private User $author;

    // Getters y setters...
}

// Persistencia con EntityManager
$post = new Post();
$post->setTitle('Mi artículo');
$post->setAuthor($user);

$entityManager->persist($post);
$entityManager->flush();

// Consultas con DQL o QueryBuilder
$posts = $postRepository->createQueryBuilder('p')
    ->where('p.published = :published')
    ->setParameter('published', true)
    ->orderBy('p.createdAt', 'DESC')
    ->getQuery()
    ->getResult();

Las diferencias practicas son notables:

• Velocidad de desarrollo: Eloquent es significativamente mas rapido para prototipar y construir CRUDs. Menos codigo, menos archivos, menos configuracion.
• Separacion de responsabilidades: Doctrine separa limpiamente el dominio de la persistencia. En proyectos con Domain-Driven Design (DDD), esto es una ventaja enorme.
• Testing: Las entidades Doctrine son mas faciles de testear en aislamiento porque son POPOs sin dependencia de la base de datos. Eloquent requiere una base de datos (o mocking mas complejo) para testear modelos.
• Rendimiento con datos complejos: Doctrine gestiona mejor los grafos de objetos complejos gracias a su Unit of Work y su Identity Map. Eloquent puede sufrir con relaciones muy anidadas y lazy loading (N+1 problem, aunque se mitiga con with()).
• Migraciones: Doctrine puede generar migraciones automaticamente comparando las entidades con el esquema de la base de datos. Laravel requiere escribir las migraciones manualmente (aunque son mas predecibles).

Motor de plantillas: Blade vs Twig

Blade es el motor de plantillas de Laravel. Su filosofia es “PHP mejorado”: las plantillas Blade se compilan a PHP puro, por lo que puedes usar cualquier codigo PHP nativo dentro de ellas. Las directivas como @if, @foreach, @authy @can son azucar sintactico sobre PHP.

{{-- Blade --}}
@extends('layouts.app')

@section('content')
    <h1>{{ $post->title }}</h1>

    @if($post->isPublished())
        <span class="badge">Publicado</span>
    @endif

    @foreach($post->comments as $comment)
        <x-comment :comment="$comment" />
    @endforeach

    @auth
        <x-comment-form :post="$post" />
    @endauth
@endsection

Twig es el motor de plantillas de Symfony, creado por el propio Fabien Potencier. Tiene su propia sintaxis, mas restrictiva que Blade, lo que impide ejecutar codigo PHP arbitrario en las plantillas. Esto es una ventaja en equipos grandes donde quieres garantizar que la logica de negocio no se filtre a las vistas.

{# Twig #}
{% extends 'layouts/base.html.twig' %}

{% block content %}
    <h1>{{ post.title }}</h1>

    {% if post.isPublished %}
        <span class="badge">Publicado</span>
    {% endif %}

    {% for comment in post.comments %}
        {{ include('comment/_card.html.twig', {comment: comment}) }}
    {% endfor %}

    {% if is_granted('ROLE_USER') %}
        {{ include('comment/_form.html.twig', {post: post}) }}
    {% endif %}
{% endblock %}

Blade tiene la ventaja de los componentes (desde Laravel 7): puedes crear componentes reutilizables con <x-button>, <x-modal>, etc., de forma similar a React o Vue. Twig tambien tiene un sistema de componentes (Twig Components / Live Components en Symfony UX), pero llego mas tarde y es menos maduro.

Una diferencia clave: con la llegada de Livewire y Inertia.js, muchos proyectos Laravel ya no usan Blade para el frontend completo. Livewire permite crear interfaces reactivas con PHP + Blade, mientras que Inertia permite usar React, Vue o Svelte como capa de vistas con Laravel como backend. Symfony tiene Symfony UX con Turbo y Stimulus como alternativa, pero el ecosistema es menos diverso.

Inyeccion de dependencias y Service Container

Ambos frameworks tienen contenedores de inyeccion de dependencias potentes, pero con filosofias distintas.

El Service Container de Laravel prioriza la auto-resolucion. Si un controlador necesita un servicio, Laravel lo resuelve automaticamente por type-hint sin necesidad de registrarlo manualmente. Los “bindings” solo son necesarios para interfaces o configuraciones especiales.

// Laravel - auto-resolución
class PostController extends Controller
{
    // Laravel resuelve PostService automáticamente
    public function store(StorePostRequest $request, PostService $service)
    {
        $post = $service->create($request->validated());
        return redirect()->route('posts.show', $post);
    }
}

// Solo necesitas binding explícito para interfaces
// AppServiceProvider.php
$this->app->bind(PaymentGatewayInterface::class, StripeGateway::class);

El DependencyInjection Component de Symfony tambien soporta autowiring desde Symfony 3.3, pero históricamente requeria configuracion explicita en YAML o XML. La configuracion se compila a un contenedor PHP optimizado, lo que puede ofrecer mejor rendimiento en aplicaciones con cientos de servicios.

# Symfony - services.yaml
services:
    _defaults:
        autowire: true
        autoconfigure: true

    App\:
        resource: '../src/'
        exclude:
            - '../src/DependencyInjection/'
            - '../src/Entity/'
            - '../src/Kernel.php'

    # Binding explícito para interfaces
    App\Payment\PaymentGatewayInterface:
        class: App\Payment\StripeGateway

En la practica, Symfony ha adoptado muchas de las conveniencias de Laravel en este aspecto. El autowiring de Symfony es ahora tan automatico como el de Laravel para la mayoria de casos. La diferencia principal es que Symfony compila el contenedor, lo que detecta errores de configuracion en tiempo de compilacion en lugar de en tiempo de ejecucion.

Testing y calidad de codigo

Ambos frameworks toman el testing en serio, pero de formas diferentes.

Laravel incluye testing integrado con PHPUnit y ofrece una API fluida para tests funcionales (feature tests) que es extremadamente expresiva:

// Laravel Feature Test
public function test_user_can_create_post(): void
{
    $user = User::factory()->create();

    $response = $this->actingAs($user)
        ->post('/posts', [
            'title' => 'Mi artículo',
            'body' => 'Contenido del artículo...',
        ]);

    $response->assertRedirect('/posts/mi-articulo');
    $this->assertDatabaseHas('posts', [
        'title' => 'Mi artículo',
        'user_id' => $user->id,
    ]);
}

Ademas, la comunidad Laravel ha adoptado masivamente Pest PHP, un framework de testing creado por Nuno Maduro (miembro del core team de Laravel) que ofrece una sintaxis mas limpia:

// Pest PHP
it('allows authenticated users to create posts', function () {
    $user = User::factory()->create();

    actingAs($user)
        ->post('/posts', [
            'title' => 'Mi artículo',
            'body' => 'Contenido...',
        ])
        ->assertRedirect('/posts/mi-articulo');

    assertDatabaseHas('posts', ['title' => 'Mi artículo']);
});

Symfony tambien usa PHPUnit y tiene su propio WebTestCase para tests funcionales. Ademas, el ecosistema Symfony promueve fuertemente herramientas de analisis estatico como PHPStan y Psalm, y frameworks de testing BDD como Behat.

// Symfony Functional Test
public function testCreatePost(): void
{
    $client = static::createClient();
    $client->loginUser($this->getUser());

    $client->request('POST', '/posts', [
        'title' => 'Mi artículo',
        'body' => 'Contenido del artículo...',
    ]);

    $this->assertResponseRedirects('/posts/mi-articulo');
    $this->assertCount(1, $this->getEntityManager()
        ->getRepository(Post::class)
        ->findBy(['title' => 'Mi artículo']));
}

Para testing E2E (end-to-end), Symfony cuenta con Panther, que permite testear con un navegador real (Chrome headless). En el ecosistema Laravel, se suele usarLaravel Dusk para lo mismo, con una API mas sencilla.

Ecosistema: la gran diferencia

Si hay un area donde Laravel ha superado claramente a Symfony, es en la amplitud y cohesion de su ecosistema. Taylor Otwell ha construido un universo de herramientas oficiales que cubren practicamente todas las necesidades:

• Livewire: interfaces reactivas con PHP y Blade, sin escribir JavaScript
• Inertia.js: usa React, Vue o Svelte como frontend con Laravel como backend, sin necesidad de API
• Filament: paneles de administracion completos con TALL stack
• Nova: panel de administracion premium oficial
• Forge: despliegue en servidores (DigitalOcean, AWS, Hetzner)
• Vapor: despliegue serverless en AWS Lambda
• Horizon: dashboard para monitorizar colas con Redis
• Telescope: debugging y monitoring en desarrollo
• Pint: code formatter basado en PHP-CS-Fixer
• Sail: entorno Docker para desarrollo local
• Breeze / Jetstream: scaffolding de autenticacion
• Cashier: integracion con Stripe y Paddle para suscripciones
• Socialite: autenticacion con OAuth (Google, GitHub, etc.)
• Scout: busqueda full-text con Algolia, Meilisearch o Typesense
• Octane: servidor de alto rendimiento con Swoole o RoadRunner
• Pennant: feature flags
• Reverb: servidor WebSocket nativo

Symfony tiene su propio ecosistema, mas orientado a componentes individuales:

• Symfony Flex: sistema de recetas para instalar y configurar bundles
• API Platform: la solucion mas completa para APIs REST y GraphQL en PHP
• EasyAdmin: panel de administracion rapido
• Messenger: sistema de colas y mensajeria asincrona
• Symfony UX: coleccion de herramientas frontend (Turbo, Stimulus, Live Components)
• Webpack Encore: gestion de assets frontend (alternativa a Vite)
• Panther: testing E2E con navegador
• MakerBundle: generacion de codigo (similar a Artisan make)

La diferencia clave es que el ecosistema Laravel es mas cohesivo: todas las herramientas estan disenadas para funcionar juntas de forma nativa. En Symfony, la modularidad es la prioridad, lo que da mas flexibilidad pero requiere mas trabajo de integracion. Donde Symfony destaca especialmente es en API Platform, que es probablemente la mejor herramienta para construir APIs en PHP, superando con creces a las opciones nativas de Laravel.

Rendimiento y escalabilidad

En cuanto a rendimiento puro, las diferencias entre Laravel y Symfony son menores de lo que muchos creen. Ambos frameworks estan escritos en PHP y se ejecutan sobre el mismo runtime.

Symfony tiene una ligera ventaja en benchmarks sinteticos porque su contenedor de dependencias se compila a PHP optimizado y tiene menos “magia” en tiempo de ejecucion. En benchmarks como TechEmpower, Symfony tiende a puntuar algo mejor en peticiones simples.

Sin embargo, Laravel ha dado un salto enorme con Laravel Octane, que ejecuta la aplicacion sobre Swoole o RoadRunner, manteniendo la aplicacion en memoria entre peticiones. Con Octane, Laravel puede igualar o superar a Symfony en rendimiento para muchas cargas de trabajo.

En cuanto a escalabilidad, ambos frameworks pueden escalar horizontalmente sin problemas. Laravel cuenta con Vapor para despliegue serverless en AWS Lambda, lo que permite escalar automaticamente a miles de peticiones concurrentes. Symfony no tiene un equivalente directo oficial, aunque se puede desplegar en AWS Lambda usando Bref.

Para carga de trabajo asincrona, Symfony Messenger es mas flexible que el sistema de colas de Laravel, soportando multiples transportes (AMQP, Redis, Doctrine) y patrones como CQRS de forma nativa. El sistema de colas de Laravel es mas sencillo de configurar pero menos flexible para patrones avanzados.

Curva de aprendizaje

Este es un punto donde Laravel tiene una ventaja clara. La curva de aprendizaje de Laravel es mas suave por varias razones:

• La documentacion de Laravel esta orientada a tutoriales y ejemplos practicos, no a referencia tecnica
• Las convenciones reducen la cantidad de decisiones que tienes que tomar
• Laracasts (la plataforma de video de Jeffrey Way) es probablemente el mejor recurso educativo de cualquier framework web
• La comunidad de Laravel es muy activa en YouTube, Twitter y Discord, con miles de tutoriales disponibles
• Laravel Bootcamp y el starter kit con Breeze permiten tener una aplicacion funcional en minutos

Symfony requiere mas conocimiento previo: necesitas entender inyeccion de dependencias, el patron MVC a nivel mas profundo, configuracion YAML, el concepto de bundles, el Event Dispatcher, y patrones como Repository y Data Mapper antes de ser productivo. La documentacion de Symfony es exhaustiva pero puede resultar abrumadora para principiantes.

Un desarrollador junior puede ser productivo con Laravel en 2-4 semanas. Para Symfony, el tiempo tipico es de 4-8 semanas, especialmente si el desarrollador no tiene experiencia previa con patrones enterprise.

Sin embargo, los conocimientos adquiridos aprendiendo Symfony son mas transferibles: los patrones de diseno, la arquitectura desacoplada y las buenas practicas que enseña Symfony son aplicables a cualquier lenguaje o framework. Laravel, al ser mas “magico”, puede crear desarrolladores que dependen mas del framework y menos de los fundamentos.

Mercado laboral en Espana

El mercado laboral para PHP en Espana tiene matices interesantes que diferencian a Laravel y Symfony.

Symfony tiene una presencia muy fuerte en grandes consultoras y empresas enterprise en Madrid y Barcelona. Empresas como Atresmedia, Typeform (Barcelona), BlaBlaCar (Madrid), Privalia, letgo y muchas consultoras (Accenture, Capgemini, Indra) tienen equipos Symfony. Las ofertas de Symfony suelen ser para perfiles mid-senior y estan asociadas a proyectos de mayor envergadura.

Laravel domina en startups, agencias digitales y empresas medianas. Agencias de marketing digital, estudios de desarrollo web, SaaS pequenos y medianos, y startups en fase temprana tienden a elegir Laravel por su velocidad de desarrollo. Tambien hay una presencia creciente en empresas de producto que necesitan iterar rapido.

En terminos de salarios (datos orientativos 2025 para Espana):

• Junior (0-2 anos): Laravel 22.000-28.000 EUR | Symfony 24.000-30.000 EUR
• Mid (2-5 anos): Laravel 30.000-40.000 EUR | Symfony 32.000-42.000 EUR
• Senior (5+ anos): Laravel 40.000-55.000 EUR | Symfony 45.000-65.000 EUR
• Lead/Arquitecto: Laravel 50.000-65.000 EUR | Symfony 55.000-75.000 EUR

Symfony tiende a pagar ligeramente mas porque las empresas que lo usan suelen ser mas grandes y los proyectos mas complejos. Sin embargo, Laravel ofrece mas oportunidades de trabajo remoto internacional, donde los salarios pueden ser significativamente mayores (60.000-100.000+ EUR para empresas europeas o americanas).

En cuanto a volumen de ofertas, Laravel supera a Symfony en Espana desde 2020, pero ambos tienen demanda constante. Conocer ambos frameworks es la mejor estrategia: te hace versatil y te abre las puertas a cualquier tipo de empresa PHP.

Casos de uso ideales

Elige Laravel cuando:

• Necesitas un MVP o prototipo rapido
• Tu equipo es pequeno o mediano (1-10 desarrolladores)
• Quieres un ecosistema todo-en-uno con herramientas oficiales integradas
• El proyecto es una aplicacion web estandar (CRUD, APIs, dashboards)
• Priorizas la velocidad de desarrollo sobre la arquitectura purista
• Necesitas despliegue serverless (Vapor) o WebSockets (Reverb)
• Tu equipo tiene desarrolladores junior o mid que necesitan ser productivos rapido
• Quieres usar Livewire para interfaces reactivas sin JavaScript

Elige Symfony cuando:

• El proyecto tiene logica de dominio compleja (DDD, CQRS, Event Sourcing)
• Trabajas en un equipo grande (10+ desarrolladores) que necesita convenciones estrictas
• Necesitas una API REST/GraphQL robusta (API Platform)
• El proyecto va a durar muchos anos y la mantenibilidad es critica
• Necesitas componentes especificos sin querer un framework completo (micro-framework)
• La empresa requiere cumplimiento estricto de estandares PSR
• Tu equipo tiene experiencia con patrones enterprise (Repository, Data Mapper, DDD)
• El rendimiento en bruto de peticiones HTTP es critico y no puedes usar Octane