My freelance business has grown, and reached a critical decision point for my future development. I've been puzzling over this for a while - why not puzzle it out in public!?
I need to pick a PHP framework. Or maybe not pick one. But my dilemma is kind of unusual. I'd love the opinions of other experienced PHP devs! But hear me out, my situation is a bit unique.
Unhelpful Metrics
Extensive research has given me endless comparisons of Laravel vs Symfony & others, using completely useless (to me) metrics like:
- Number of GitHub stars.
- Google search popularity.
- Job postings.
- Number of StackOverflow questions.
- Millisecond differences in speed.
- Etc.
These comparisons aren't helpful. Let me explain why.
My Situation
I build websites & web applications for small to medium sized businesses. Most start as a basic website with a contact form, Google Map, and that's it. Many never grow past this. Some eventually add custom dynamic elements. Say a work-order status page. A searchable directory, etc. A few have grown bigger.
But, and this is key... I also provide hosting, so ongoing maintenance is on me. I don't deliver a project & wash my hands of it. I make future text changes, fix bugs, add things & keep it running - for sometimes many, many years. My oldest PHP project in production is over 10 years old!
Over time I will end up with DOZENS of these projects to take care of.
I don't have the luxury of one, beautiful application to keep front-of-mind.
And so, stability over time is a key. Easy upgrades are key. This is why WordPress replaced my internal CMS for clients who fit that use-case: one-click upgrades baby! That's gold.
Until recently I was using a simple, custom MVC framework that I built. Most of my existing projects are on that. But it's over 8 years old, pre-Composer, and time for a new direction. To give that old workhorse some credit though- it has needed almost zero updates over that time (likely due to stagnating on PHP v 5.6).
I have a few months of experience & learning with Laravel, it's nice. But ongoing updates are a concern. Backward compatibility isn't a priority for Laravel. And it's overkill for 90% of what I do.
I've built a few things with SlimPHP.
I'm intrigued by Symfony because it starts as a micro-framework & grows with you. Awesome!
I'm also considering sticking a few stable Composer packages together for a light version of a 'framework' that will cover all but my few large projects. Maybe Slim is exactly that?
Maybe 90% of what I do doesn't need a framework at all.
It all boils down to not wanting to regret my choice 10 years from now. My youngest child starts school next year & when that happens I'll be throwing my efforts into my business full time. Between now & then I want my ducks in a row & to do the necessary learning.
TL;DR - My Priorities
- PHP based.
- Stability over time.
- Well documented & clear upgrade process.
- Grows with my needs over time.
- Doesn't break backward compatibility on a whim.
- Ok to have one option for small stuff and one for big projects.
Thoughts?
Do you have experience maintaining several framework-based projects over time? What do you use? Is it painful?
Am I crazy for thinking everything even needs a framework?
How does your company handle the time spent maintaining & upgrading a client's project? Do you bill them for the time? Offer a Support Licence with a monthly fee that covers this type of work? Bundle it in the hosting fee?
Thanks everyone!
Latest comments (82)
Here's my argument for Laravel:
You're wrong about backwards compatibility. Laravel has been very stable for years. There have been very few upgrades over the past 5 years or so that I've done that have taken me more than an hour to do. It's in their interest to keep breaking changes to a minimum. At this point, given that you've said you won't use most of what it has to offer, I wouldn't stress over these BC breaks when they come as they likely won't affect you.
It doesn't break backward compatibility on a whim, it has shifted to adhere more closely to SemVer and has a regular and predictable release cycle for major versions and support lifetime.
It's extremely well documented You say you've spent some time with it already, so I'd say you're already a few steps ahead there. You'll know the docs are very approachable and there are lots of other learning materials within the ecosystem. I've not found better elsewhere yet.
It will grow with your needs. Laravel has almost everything you're likely to need ready for you out of the box. If it's not part of the core, it's often available as a first-party package or a third-party package developed by a reputable dev house with years of experience.
Use only what you need and don't worry about cutting stuff out that you don't need. PHP has become very good at keeping your app performant when there's a load of code you have but don't use. Unless you've got a really good reason to only ship hot code paths, don't worry about this at all.
It's a known quantity
While you may not use most of it, whatever you do need is there and well understood and for the most part, well covered by first-party packages. You won't be struggling learning some new set of dependencies or making trade-off decisions between multiple possible options and then figuring how to plug those in to your application reliably every time you realise that your standard setup is missing something that you now need.
You won't even get this with Symfony, which is generally un-opinionated about this sort of thing. Caveat emptor: my experience here is with a company running multiple large Symfony apps that they are essentially afraid to upgrade because of how custom their structure is. I haven't actually tried to do the upgrade.
If you keep your app structure aligned with how Laravel does things, then you'll benefit in multiple ways:
To answer some of your final questions, I have spent the past ~10 years building and maintaining applications on Laravel. I've built everything on it. And I've loved every minute.
By contrast, when I've worked with Symfony, I've felt a lot of pain - the docs need a lot of work and the way some folks have built on top of it is just plain crazy. The fact that it's so un-opinionated has led to a wild variety of styles of doing things, which is fine, but it does make things trickier.
This is only anecdotal, so take it with a pinch of salt.
As for how I handle upgrades for my clients, I explicitly tell them this is a part of my work and I will take time out from their monthly retainer to keep things up to date, that it's necessary for their safety and security and that it improves my efficiency.
This ends up being just a few minutes worth of work each week (
composer update) and then I know that in Q1 each year I'll likely need a bit more time for the next major release - I currently budget for about 2 hours from start to finish, just to give myself some headroom.I refuse to work solely on feature work and bug fixes at the expense of upgrades. The further behind you let those upgrades slip, the worse it becomes.
Totally fair.
Though this decision was made long ago & I'm all-in with Symfony. Though I do touch a Laravel app from time to time.
I'm very happy with laravel. I like some concepts they provide for developing manageable applications.
I was in the same boat as yourself. I've used my own MVC Framework but after a while, I felt it would be best to start relying on a more robust solution.
I compared Laravel and Symfony, and ultimately ended up using Symfony. Laravel's interpretation of semver, scares the hell out of me. I built an app based on Symfony 4.3 a while back and have recently upgraded it to Symfony 5 without a hitch. The whole process took a matter of minutes. Granted the app was not that sophisticated. I was also fortunate that some 3pl bundles I was using were updated within a few days of Symfony 5's release...
I'd recommend giving Symfony strong consideration.
Thanks geeShoe
Thanks! I very much agree with you.
It's funny that Laravel moved to SemVer recently, but that just means all their packages are getting a major version bump almost every update. I also heard that even core packages that weren't changed are getting the version bump to keep them all at the same version num. Strange.
I want stability. At least save up the BC breaks & pack them all together in a major release less often. It feels like they still don't get the point.
Which sucks because I want to use Laravel. It's beautiful & the ecosystem is great.
I may be a little late to the game, but...full disclosure I have about 20 years experience with PHP, I've used Cake (large oil & gas company and large computer manufacturer), CodeIgniter (also at o&g company), and for the past 4-ish years Symfony (3.x) for a smaller HR company (we're now migrating to 4.x and it's pretty painless). None of what I've developed would equate to a small site with little traffic. We're (small dev team) tasked with keeping things current/up to date and Symfony has been the easiest to update relative to the other frameworks (very few bc breaks). With the built in debugger, extensive logging, and well written framework error messages, pinpointing a problem is much easier in Symfony than the other frameworks though that may have changed over time.
It's completely possible to wire your ORM or heavy business logic into a Twig template if you work at it in Symfony - but you shouldn't. Symfony doesn't so much enforce good coding as it encourages it. You can bloat up your controllers with business logic, forms, and all sorts of junk or you can spin your business logic off into services, put your queries in reusable libraries, write a mess of reusable twig filters, and get your controllers down to a scant dozen or so lines of code.
I only have about 2 months of experience with Laravel - just long enough to know it's just too tempting for me to wire things incorrectly "just to test something out". I know I'd be coming back in 6 months to try to fix that little shortcut and it would be pinned in place by 20 other things that grew off of it in the meantime. Laravel to me seemed like it would be a great framework to knock together a quick prototype/proof of concept.
My vote would obviously be for Symfony - it's not really a beast to set up, you can spin up a default Symfony project in a minute or two with composer. In a few more minutes you can have a workable prototype - a few views and matching controllers, some queries/repositories/tables using Doctrine. Symfony 4 with Flex is really nice. I imagine you could say most frameworks are overkill if you're doing simple websites but I'd still use Symfony - if the site starts to grow you've got the ability to bolt on all sorts of stuff, if not, you're good where you are. Look into the Symfony LTS versions - read up on their release processes, backwards compatibility promise, how frequently they release, etc. symfony.com/doc/current/contributi...
Good luck with the decision if you haven't already made one.
Thank you. This was a very nicely detailed reply. And very much in line with the conclusion I came to as well.
I've never used Symfony so I can't speak to that. But having written sites in PHP from scratch, with Laravel, with Angular + Laravel + Lumen, I've never been happier since switching to Node.
As far as longevity, the Angular + Laravel + Lumen app has been in production for years and it's not terrible to maintain from a code perspective, but any deviation from the norm was a headache. I can throw some pointers your way if you decide to go that route.
The tooling 5 years ago also isn't what it is now and if I started today it may be easier.
But I just enjoy the experience so much more in the JS / TypeScript ecosystem. Pick the level of abstraction you want and go from there. I only touch PHP today because I have to maintain things.
Straight up fark php!!
Fark docker!!
Fark k8s!!
I have developed with both laravel and symfony (which is the best)
Choose a cloud provider and build server less. I choose AWS
Cognito user pools
Amplify
Appsync (graphql)
Dynamodb
Lambda functions
Greengrass
IoTAnalytics
Sagemaker
S3
Quicksight
Build this with a framework.... Hahahaha I'll see you in 2080, at which time you'll be dead or uploaded to the cloud
The biggest problem I see is not Laravel vs. Symfony. You want 10 years of backwards and 10 years of forward compatibility. Do you really want to use the same thing for 20 years?
I don't want that at all.
Well, my awnser would be this: dev.to/phpandcigars/why-i-choosed-...
Start with the domain,have conversation and learn about the domain, take a look at architecture,try to decouple your domain from infrastructure/framework or if you go cqrs/es understand libraries or framework that facilitate that. The frameworks are good for things that everybody does like cruds or helping you with some infrastructure like database or http, but won't help you with your domain,only learning and storming ideas(together with clients/domain experts) will do. Frameworks may help you cook something fast but won't help when customization will come into your way if of course you are coupled with the framework.
Do you really need a framework? You have one in WordPress. 180+million installs does have some weight. I use WP+PHP for my work and rarely do I miss anything "frameworky" that WP doesn't offer.
If you absolutely positively need a framework on top of WP just take one of the big ones - it really doesn't matter at all. Cake, Symfony, Laravel. Pick one. Laravel is basically Symfony in better looks, Cake has its own thing going but is a veteran and very well put together.
Good luck and welcome to the choice effect. :-)