Taylor Otwell: What 14 Years of Laravel Taught Me About Maintainability
Key topics
The discussion is abuzz with Taylor Otwell's insights on maintainability gleaned from 14 years of Laravel, sparking a lively debate about the cultural and technical differences between Laravel, Symfony, and WordPress communities. Commenters like pbowyer and ahofmann point out that Laravel and Symfony, despite being technically intertwined, have distinct cultural flavors, with Laravel being more "US-American" and Symfony more "European". Meanwhile, others like jonwinstanley and no_wizard share their experiences on the trade-offs between Laravel's rapid development capabilities and Symfony's more comprehensive framework. As the conversation unfolds, it becomes clear that each community has its strengths and weaknesses, with some, like yurishimo, crediting Laravel with helping them level up their skills.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
4h
Peak period
45
Day 5
Avg / period
9.4
Based on 66 loaded comments
Key moments
- 01Story posted
Aug 26, 2025 at 8:37 AM EDT
4 months ago
Step 01 - 02First comment
Aug 26, 2025 at 1:03 PM EDT
4h after posting
Step 02 - 03Peak activity
45 comments in Day 5
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 11, 2025 at 12:51 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
At a high level the WordPress community doesn't mesh because of having the WordPress way of doing things, and having a history of writing for old versions of PHP years after others have moved on and told users to upgrade. The WordPress community is fragmented into separate sub-communities which again don't mesh. There's the users who only build sites with page builders and hardly know how to code, those whose goal is to sell copies of their paid plugin (or hosting services), and those with permission to make changes to WordPress itself.
I've no recent experience of Drupal so can't comment on them.
My biggest takeaway is Laravel is fast to get up and going with and ship something, while Symfony actually scales and is far more easily maintainable
If I were to choose building an app I expect to last I’d choose Symfony every time
Maybe they need to stay close to the metal based on the performance they need?
Laravel is designed from the ground up to be used by junior developers who don't care about pesky things like maintainability and scalability and just want to put out the minimum viable product as fast as possible, and with the least amount of work possible. It's full of "magic" abstractions built with the primary purpose of making the code look pretty at a glance to the inexperienced, completely disregarding good programming practices and even essential language features in the process, the programming equivalent of lipstick on a pig. It markets itself to beginners as "the magic framework that does everything for you" and is as big as it is today purely due to successfully capturing a large percentage of that audience.
Symfony goes in the complete opposite direction: it's designed to be used by experienced developers to build maintainable, extensible applications while employing good programming practices. It encourages you to "look under the hood" and understand how things work instead of just telling you "to do X, write Y" without elaborating. It has many convenience features but they're generally built on top of language features with good practices in mind instead of handwaving it all away. It's very modular and allows you to extend and/or replace almost every part of the framework with your own custom version if the included version isn't suitable for your use case. And so on.
One of the best examples of Symfony vs Laravel is the way database tables are mapped to PHP code. In Symfony, SQL tables are just PHP classes. To create a new table, you create a new class, add the columns you want as properties, add some attributes to tell the ORM how to map all of that to a table, and it's done. Your database columns match your class properties, every time you query the database you get instances of that class and can use them as a proper objects with properly typed fields.
Laravel, meanwhile, does none of that, your database tables are defined purely by the database itself at runtime, what they call "Models" are just empty classes that have the database columns injected into them at runtime as dynamic properties. You cannot know what properties your Model has just by looking at it, I believe you need a Laravel-specific IDE plugin just to autocomplete them. You're essentially working with glorified associative arrays the whole time. This alone is a massive red flag that should make any experienced programmer avoid Laravel.
Wordpress sits on its own little island as a big pile of legacy code that's almost frozen in time, full of bad practices that no self-respecting developer wants to touch. No lipstick on this pig, it's as ugly as it is obtuse. It's still commonly used today because someone with zero programming knowledge can load up a bunch of plugins full of security holes and make a somewhat usable site that vaguely matches their vision, but using it for any new project more complex than a basic blog is generally seen as a mistake.
Can't speak for Drupal as I have no experience with it.
It's fine if you don't like that pattern (I have my own misgivings), but it's a perfectly viable approach used by a lot of very experienced developers to build very successful applications.
Dismissing everyone who uses a framework or design pattern you dislike as "junior developers who don't care about pesky things like maintainability and scalability" is inaccurate, rude, and ignorant.
"Lots of people use it" doesn't make it good. Lots of people in the past have written "successful" web applications as loose PHP files with little structure, no classes, using associative arrays everywhere (including me when I was starting out), but today it's generally agreed upon that this is not a good idea and will result in more bugs, maintenance headaches and an all around inferior developer experience, so what makes "active record" different?
I'd understand your point if it had at least some advantages over the ORM approach to make up for the clear disadvantages, but I just don't really see any beyond "it seems easier and requires writing less code" (which, as I said, primarily appeals to beginner developers who just want to get things done as fast as possible and don't understand the long-term consequences). Are there any hidden advantages I'm not aware of?
I didn't say it was good (or bad), I said it's a perfectly viable approach.
> Lots of people in the past have written "successful" web applications as loose PHP files with little structure, no classes, using associative arrays everywhere (including me when I was starting out), but today it's generally agreed upon that this is not a good idea.
You're right, which is why, in 2025, no experienced developer builds web applications in this way.
Plenty of experienced developers build web applications using the active record pattern.
>Are there any hidden advantages I'm not aware of?
You mean aside from others having a different opinion about the relative pros and cons of active record, or personal preference?
Yes, but why? Why was the "loose PHP files with no framework" pattern abandoned, but not active record, when in many ways it's a remnant of the same era with many of the same drawbacks?
> You mean aside from others having a different opinion about the relative pros and cons of active record
I'm asking what the pros are.
Presumably because people still find active record to be a productive, sane, and scalable way to build web applications, unlike a disorganised collection of files.
> I'm asking what the pros are.
Speed, terseness, simplicity, and personal preference spring to mind.
You're talking as though there is some empirical "best way", but the fact is that every language, framework, tool, and design pattern has pros and cons, and those pros and cons will change depending on the project, and the individual.
Your list of pros and cons may differ to mine, simply because of personal perspective and preference, and that's fine.
Being blunt, I would expect an experienced, senior engineer to understand this.
Laravel is great for shipping things fast. Sometimes, that's what you want, even if that means a less maintainable app in the long run. Because sometimes there is no long run; you know it will just be an app made by you only as a rather one shot thing.
Same goes for wordpress. Lots of devs like to shit on it by default. But its like people shitting on PHP because of the PHP 5 days. You'd be surprised how quickly you can build really complex content websites with Wordpress. Way quicker than with barebones laravel or symfony. And with not that ugly code ;)
Laravel is more akin to rails with its rapid application development but rails does it better.
I’m super happy to have spent that time learning how to work with constraints to build absolutely giant systems (had a stint with an agency that worked for big online publishers that are known for using WP…) but after seeing the other side, I’m also happy to be past that and onto different and more interesting things.
Drupal took their time but finally started using composer and a lot of their components were Symfony components.
Wordpress just held their ground.
Lesson 1: Use the best tools available.
There's a reason why Laravel is more popular than Symfony.
Also, this is very regional.
Here in Europe, actual, big projects that need to make money use Symfony, not Laravel.
Yes, and that reason is being more beginner friendly at the cost of pretty much everything else. It's not related to overall quality at all.
On the other hand, Laravel decided to change from snake_case to CamelCase between versions 3 and 4, just because. Literally 0% compatibility
Things which you were able to configure in the past, are now hidden. The meaning of many files (e.g. bootstrap) is now completely different. All different service provider classes are gone.
But ultimately it got better IMO, indeed.
Is it even running on a still supported PHP version?
Can confirm. We started on Laravel 4 and it languished at that version until someone in leadership agreed to get it updated to version 8, which seemed to mostly be about some APIs changing. (The configuration system changed quite a bit for example.) Further upgrades from 8 to 10 then 11 have been very quick. (Note that we don't use Eloquent ORM so that wasn't part of these upgrades.)
It helps that the core language has been incredibly stable
I issue a `cargo update` to upgrade the leaf dependencies and do automatic minor version updates. Issue cargo check. Some new warnings from `clippy`, but it still compiles and runs without problems. Could have deployed for 5 more years, but I decided to experiment more...
I upgrade some of the libraries to major new versions - I am experienced and I know which ones will upgrade without problem. They do upgrade without problem. Could have deployed for 5 more years but decided to walk the extra mile...
I upgrade the more problematic ones, especially actix_web, the web framework, which had a massive rewrite and a huge new release with almost completely different API surface... It's a bit difficult to understand the changes, especially some parts of the old code written for the old version (which I no longer remember), but in an hour I'm done. Afterwards `cargo outdated` does not report any outdated libraries. I deploy for the next 5 years. Zero problems since then.
Well, it's not decades yet, but I can imagine similar effort to maintain it over the next decade.
I just pulled a PHP site out of my archive that I had taken down 7 years ago. Only one function call (each) had been removed, and everything else still works. There's been some major changes in some parts of PHP though; if I had been following along, I'd have gotten a deprecation warning, but I jumped two or three major versions.
I'd be pretty confident in any Perl code written for 5.8 or newer to continue working, with CPAN libraries as well. Earlier code is probably ok as long as you don't deal with binary data or non-ascii characters; 5.8 was the unicode reckoning.
If you ran FreeBSD 4, most of FreeBSD 13 will feel familiar. Although if you had a kernel driver for FreeBSD 4, it will likely need a lot of help to work in FreeBSD 13.
Of course, there are other communities where everything is thrown away every 6 months. I don't have that kind of time.
All subsequent upgrades have been easier (if not always easy) by comparison - it was kind of a one time thing.
4 onwards wasn’t.
A quick hack to solve current issue often becomes a maintenance nightmare for large systems.
Those who use Laravel don't typically care about performance though
The PR in question: https://github.com/laravel/framework/pull/48078
> taylorotwell commented on Sep 13, 2023 > I personally don't have the knowledge to trust merging this sadly. I would > prefer to either de-document cache tags or recommend their use with Memcached > only. Cache tags and Redis have been a maintenance and complexity nightmare.
https://github.com/laravel/framework/pull/48078#issuecomment...
Most of my work revolves around forms and SQL (Postgres). After translating designs from Figma and Marvellous, I export with Tailwind, which makes things easier. Still, I wish my UI/UX designer had listened to my struggles and made use of pre-built UI components to save time. Instead, they often executed poorly, rushed features, and changed things on a whim as though it were a toy, which was frustrating. Even so, I managed to overcome that as a sole developer and co-founder.
I did not expect to accumulate with such a large set of custom UI components, ranging from simple to complex logic, that are reused across different parts of the frontend. Managing that in Laravel’s workflow would have been a nightmare. I prefer JSX-like syntax over Blade because it is faster to work with TypeScript for both frontend and backend.
I also do not need to waste time dealing with routing, it was the same problem with Go + Echo, although Astro allows me to add flexibility with packages like micromatch for dynamic routes within middleware. Laravel, of course, has middleware too.
From my experience, I still have not found a convincing reason to adopt traditional MVC or to need that level of abstraction in Laravel.
Astro’s colocation (.astro) is optimised for developer velocity and a component-first mental model.
Despite my aim to strive for perfection, I have been out of work for years and have been affected by permanent hazy vision due to a health-related issue. My wish is to continue building with Astro.