Comment by kugelblitz
2 years ago
I've been maintaining my own side project. It started 12-13 years ago, with vanilla php, later rewritten with Laravel, later rewritten again with Symfony in 2017-ish. Since then I've had phases from 6-18 months where I had a total of 2-3 tiny commits (I was working full time as a freelancer, so I didn't have energy to work on my side project). But then when I had time, I would focus on it, add features, upgrade and just experiment and learn.
This was super valuable to me to learn how to maintain projects long-term: Update dependencies, remove stuff you don't need, check for security updates, find chances to simplify (e.g. from Vagrant to Docker... or from Vue + Axios + Webpack + other stuff to Htmx). And what to avoid... for me it was to avoid freshly developed dependencies, microservices, complexified infrastructure such as Kubernetes.
And now I just developed a bunch of features, upgraded to PHP 8.2 and Symfony 7 (released a month ago), integrated some ChatGPT-based features and can hopefully relax for 1-3 years if I wanted to.
In the last 4-5 years the project has made about the same revenue as an average freelance year's revenue, so it's not some dormant unknown side project.
I think PHP, as horrible as it feels to go back, is one example of something that’s truly backwards compatible even to its own detriment.
Haven’t worked with it for years, went back to find that the horrible image manipulation functions are still the same mess that I left behind 8 years ago.
Yeah, some things are still a mess, but many things I use constantly have improved so much. Here is an excerpt of a function that shows many of the updates that I use regularly:
You have attributes, much better type-hinting, constructor property promotion, read-only properties / classes. Additionally you have native Enums, named arguments and also smaller things such as match expressions (instead of case switch), array spread operator, null coalescing assignment operator, etc, etc.
Especially in a CRUD-heavy setting like mine (I run a niche jobboard) it reduces so much boilerplate and increases type-safety, thus makes it way less error-prone. Combined with new static analyzers (phpstan, php-cs-fixer, psalm - take your pick), you find possible errors way earlier now.
I think it gets a lot of inspiration from Java. Symfony gets lots of inspiration from Spring Boot. The Twig templating language is heavily related to the Django templating language. So many of the tools and concepts are somewhat battle-tested.
And this is on top of the huge performance improvements in the last years.
So yeah, there's many things that are still fixable. But the improvements have been staggering.
As a person who’s considered learning more native symphony, can I ask - what was your reason moving to it from something like laravel?
Laravel was easier to get into but once you strayed from "The Laravel Way", it gets quite messy.
I got into Symfony by "accident", because a freelance colleague put me on projects that used Symfony. So for a couple of years I used Laravel and Symfony in parallel, but after a few years I decided to go full Symfony.
Some of the things that were better for my use case:
Many of the Laravel components are "Laravel only". Whereas in Symfony, you can just pick and choose the components you need - it's very modular and extendible without forcing your hand. You don't even need the Symfony framework and just choose the components you want.
That's how Laravel can depend on Symfony modules; but Symfony can't depend on Laravel modules.
Entities vs. Models (Data Mapper vs. Active Record): The entities in Symfony (equivalent to Models in Laravel) were just simple PHP objects. I can see what properties an entity has, I can configure directly there in a simple way. I can add my own functions, edit the constructor, etc, etc. Also: You create the properties, and the migrations were generated based on that. In Laravel, you create the migrations, and the actual model is based on going through the migration steps. This just feels odd to me.
In Laravel, the Models extend the Eloquent Model class and it feels "heavier" and I had more trouble re-configuring some things. Plus without using an additional "auto-complete" generator, I couldn't just see what the properties / columns of the model / table was.
I also don't like Facades (because they hide too much stuff and I have trouble figuring out the service that it actually represents).
Templating: I also like that Twig is more restrictive, it forces me to think more about separating logic and the view, whereas Blade allows way more things. You don't have to use it, but I reckon since it's allowed, people will do so.
One thing I still envy from Laravel, though, is the testing suite.
This is pretty neat:
I tried integrating it in Symfony, but it was quite messy and somewhat incompatible. That shows the above point, that it's "Laravel only". It's really nice, but not enough for me to advocate for Laravel over Symfony.