Canvas Canvas vs Laravel vs Symfony
Last updated: 2026-10-28
Laravel, Symfony, and Canvas are all full-stack PHP frameworks, but they solve different problems well. Laravel optimizes for shipping features fast with a huge first-party ecosystem (Eloquent, Blade, Forge, Nova). Symfony optimizes for long-lived, highly configurable applications built from reusable components, with a service container and Security system that scale to large teams. Canvas optimizes for two things most frameworks treat as secondary: a dependency injection container that can resolve different implementations per parameter, and per request through an explicit call, rather than only per class, and a built-in path for adopting a modern architecture inside an existing legacy PHP codebase without a rewrite.
At a glance
| Concern | Canvas | Laravel | Symfony |
|---|---|---|---|
| Routing | @Route annotations directly on controller methods; auto-discovered, cached | Centralized routes/web.php / routes/api.php files | PHP attributes, YAML, or XML, resolved by the Routing component |
| Cross-cutting concerns | Aspect-Oriented Programming — @InterceptWith before/around/after aspects on methods or classes | Middleware pipeline — ordered stack of classes, assigned globally, by group, or per route | Kernel events (kernel.request, kernel.controller, …) plus event subscribers |
| Dependency injection | Autowiring plus @WithContext per-parameter context tags and a for() method for runtime-computed context | Autowiring plus registration-time contextual binding (when()->needs()->give()) | Autowiring plus named aliases / service locators, wired in container config |
| ORM | ObjectQuel — Data Mapper pattern, QUEL-inspired query language | Eloquent — Active Record pattern, fluent query builder | Doctrine — Data Mapper pattern, DQL |
| Legacy PHP migration | Legacy Bridge — route-by-route fallthrough to existing files, no framework-level equivalent elsewhere | No official equivalent; typically a custom reverse-proxy or catch-all route | No official equivalent; typically a custom reverse-proxy or catch-all route |
| HTTP foundation | Built on Symfony's HttpFoundation component | Own Illuminate\Http layer | Own HttpFoundation component |
| Templating | Smarty (configurable per project) | Blade | Twig |
| Ecosystem & maturity | Newer and growing; smaller package ecosystem, core framework covers routing, DI, AOP, ORM, and security out of the box | Very large — official packages (Nova, Horizon, Livewire), hosting (Forge, Vapor), hiring pool | Very large — hundreds of bundles, long-term support releases, heavy enterprise adoption |
Legacy PHP migration: the clearest differentiator
Most PHP codebases that need modernizing aren't greenfield — they're ten-year-old applications with thousands of working, revenue-generating URLs. Laravel and Symfony both assume you're either starting fresh or fully committing to a rewrite; neither ships an official mechanism for running old and new code side by side at the routing layer.
Canvas's Legacy Bridge checks its own routes first; if nothing matches, the request falls through to your existing legacy files, matched by filesystem convention (/admin/users → legacy/admin/users.php or legacy/admin/users/index.php) or a custom resolver you write for non-standard URL schemes. Legacy files immediately gain access to Canvas's services through a canvas() helper, and calls to header(), http_response_code(), die(), and exit() are preprocessed so they don't short-circuit Canvas's request/response lifecycle. You migrate one route at a time — once a Canvas controller exists for a URL, it takes precedence, and the legacy file stays in place, untouched, until you're confident enough to delete it.
What this means in practice
A team can put Canvas in front of a legacy application on day one, with zero URLs breaking, then spend the next year migrating controllers incrementally — instead of needing a dedicated rewrite project with its own budget, timeline, and freeze on feature work.
Dependency injection: contextual resolution, two ways
All three frameworks autowire concrete classes from constructor type hints without manual configuration — that part is table stakes now. The real difference shows up once you need an interface to resolve to different implementations in different situations.
Laravel solves this with contextual binding, declared once in a service provider: "when PhotoController asks for Filesystem, give it the local disk." Symfony solves it with named autowiring aliases or service locators, wired into the container at compile time. Both are decided by which class is asking, fixed once when the application boots.
Canvas offers two mechanisms, at different levels. A @WithContext(parameter="cache", context="redis") annotation tags a single method parameter with a context string, so one method can inject two different implementations of the same interface into two different parameters. As of Canvas 1.20, that context argument can also name a class implementing ContextProviderInterface, which the container resolves and calls on every request — so the tag can be a fixed string decided ahead of time, the same way Laravel's and Symfony's bindings are, or a value computed per request. Either way it's scoped to the parameter rather than the whole class, and declared right at the injection site instead of in a separate provider. For context that genuinely needs to vary while the app is running — a tenant ID, a locale, a header — the container separately exposes $container->for($context)->get(CacheInterface::class) as a direct call: $context is any value your own code computes at that point, and a ServiceProvider's supports() method inspects it to pick the implementation.
Laravel and Symfony aren't incapable of that second case either — a factory binding or a service locator called with a runtime-computed value reaches the same result — but it's something you assemble yourself. Canvas's for() is a container-native method with a matching provider contract, rather than a pattern built from closures.
Routing and cross-cutting concerns
Canvas and Symfony both support attribute/annotation-driven routing directly on controller methods; Laravel keeps routes in dedicated files, which centralizes the route list at the cost of separating a route from the method that handles it.
For cross-cutting concerns — auth checks, caching, rate limiting, logging — Laravel uses a middleware pipeline (an ordered stack every matching request passes through), and Symfony dispatches kernel events that listeners subscribe to. Canvas uses Aspect-Oriented Programming: concerns are declared with @InterceptWith directly on the controller method or class they apply to, with explicit before/around/after phases, a priority parameter controlling execution order, and inheritance so a base controller's aspects apply to every subclass automatically. The real cost of that design: a middleware stack or a listener list is something you can read top to bottom in one place to know exactly what runs on a request — it's also the pattern most PHP developers already know. Annotation-based aspects spread that same information across every controller and its ancestors, so seeing everything that applies to a given request means checking the class hierarchy too, not just one file. What you get in exchange is each concern's declaration sitting next to the code it modifies, instead of registered somewhere else — useful, but it doesn't erase the extra indirection.
ORM: ObjectQuel, Eloquent, and Doctrine
Eloquent is Active Record — a model class is both the data and the query builder for its own table, which keeps simple CRUD code short. ObjectQuel and Doctrine are both Data Mapper — entities are plain objects with no persistence logic, and a separate layer (the EntityManager) maps them to the database — which trades some boilerplate for entities that don't need to know how they're stored.
Where ObjectQuel differs from Doctrine is its query language. Doctrine uses DQL, which mirrors SQL's SELECT/FROM/JOIN structure even though it also navigates entity associations. ObjectQuel's QUEL-inspired syntax instead declares each range as an entity type and traverses relationships via its own properties (range of p is PostEntity via u.posts), so the query stays expressed in domain vocabulary — entities and their properties — rather than shifting into join clauses or table and column references.
That matters most for genuinely hard queries — window functions, recursive relationship traversal, relational division — where DQL can't express the query at all and Doctrine's usual answer is dropping to raw SQL via createNativeQuery(). ObjectQuel handles these directly in QUEL, so you keep retrieving and filtering through the same entity-and-property language the rest of your domain model already uses, instead of stepping outside the ORM entirely once a query outgrows a simple lookup.
Security model
Laravel ships CSRF protection and other hardening as part of its default global middleware group — on unless you remove it. Symfony's Security component is comprehensive but configuration-heavy, centered on firewalls declared in security.yaml. Canvas splits the two: browser/transport security headers are resolved once by the kernel and applied to every response, including error pages, with no opt-in required; everything else — CSRF, rate limiting, validation, step-up re-authentication — is a per-route @InterceptWith aspect you compose deliberately, because the framework's position is that there's no single correct default for those beyond "headers always on." See the Security Overview for the full model.
Ecosystem and maturity — and what Canvas trades for it
Laravel and Symfony both have a decade-plus head start: official first-party packages, hosting platforms, a large hiring pool, and — for Symfony especially — hundreds of community bundles covering almost any integration you'd need. Canvas is newer and its catalog is smaller. It has the same auto-registration mechanism behind it — Discover reads composer.json metadata and registers providers automatically, the same job Symfony Flex or Laravel's package auto-discovery does — and an official catalog already built on it, including payment gateways, shipping carriers, the Loom page builder, and the Recommender. It just can't match a decade of community contributions yet.
What it trades that breadth for is the Legacy Bridge, covered above: the one piece of this comparison neither Laravel nor Symfony ships at all, and the reason a team with an existing legacy codebase would pick a less mature ecosystem over a more established one.
Frequently asked questions
Is Canvas a replacement for Laravel or Symfony?
Yes — Canvas is a full-stack framework that covers the same ground as Laravel and Symfony: routing, dependency injection, an ORM, security, templating. It just makes different choices for each of them — annotation-driven routing and AOP instead of a routes file or middleware/events, contextual DI that can change per request, and a Legacy Bridge for adopting it inside an existing codebase instead of requiring a greenfield start. Which set of choices fits depends on your team and codebase, covered throughout this page.
Can I use Canvas with an existing legacy PHP codebase?
Yes — this is Canvas's core migration story. The Legacy Bridge lets Canvas sit in front of your existing application, routing unmatched requests to your current files while giving those files access to Canvas's services, then lets you migrate routes to Canvas controllers one at a time with no required cutover date.
How does Canvas's dependency injection differ from Laravel's service container?
Both autowire concrete classes automatically. For resolving an interface to different implementations, Laravel's contextual binding is static, decided ahead of time, per consuming class. Canvas's @WithContext annotation tags a parameter the same way by default, but its context argument can also name a class that resolves a value on every request, so the same annotation covers both the fixed and the runtime-varying case. Canvas's container additionally exposes $container->for($context) as a built-in method for resolving based on a value computed at runtime, something Laravel and Symfony can also do, just via a hand-written factory or locator rather than a container-native method.
Does Canvas have an ORM like Eloquent or Doctrine?
Yes — ObjectQuel. Architecturally it's closer to Doctrine than Eloquent (Data Mapper rather than Active Record), but it uses its own QUEL-inspired query language instead of Doctrine's DQL. The benefit shows up on genuinely hard queries — window functions, recursive traversal, relational division — where DQL can't express the query at all and Doctrine's usual answer is dropping to raw SQL via createNativeQuery(). ObjectQuel handles these directly, so you stay inside your domain model even there.
What's the learning curve compared to Laravel?
Not basic CRUD — ObjectQuel's find()/persist()/flush()/ remove() is about as simple as Eloquent's for straightforward create, read, update, and delete. Laravel's real edge is tutorial volume: a decade of blog posts, screencasts, and Stack Overflow answers that ObjectQuel doesn't have yet. Canvas's routing and DI will feel familiar to Symfony developers; its AOP model, contextual container, and ObjectQuel's own query language for anything beyond basic CRUD are the concepts most likely to be new, even to experienced PHP developers.
Is Canvas production-ready?
Yes. Canvas is younger than Laravel or Symfony and hasn't had a decade to accumulate their track record, but the framework itself — routing, DI, AOP, the ORM, security — is stable and actively maintained. Check the release history if you want to see that activity for yourself.