Skip to content

Instantly share code, notes, and snippets.

@MihailoJoksimovic
Last active August 6, 2019 09:02
Show Gist options
  • Save MihailoJoksimovic/04158ddaa1427cdb96202b69c3acf066 to your computer and use it in GitHub Desktop.
Save MihailoJoksimovic/04158ddaa1427cdb96202b69c3acf066 to your computer and use it in GitHub Desktop.
This is my quick evaluation of Laravel vs Symfony frameworks; the task was intentionally simple --> build simple API returning JSON responses and three simple routes. Observations below
Laravel:
1. What I liked:
1. Super-easy initial setup
2. Working with Eloquent is pretty damn easy
3. Repository pattern implemented quite easily
4. Seems to be working pretty fast (in comparison to Symfony)
5. Feels pretty friendly and easy going. BUT:
2. What I dislike:
1. From the moment #1, I feel like Eloquent is forcing me to think about DB and relations. I don’t want that. I want to think about OBJECTS first, and think about persistence separately
2. Too many assumptions are being made by framework and I think this might become a problem
1. For example, based on what I return from controller, Framework will assume whether the Response should be JSON or HTML …
2. My mantra is that assumption is mother of all failures and since PHP is one big assumption-making-language, I think this can be more of a problem then it is a benefit
3. Too much magic is being used. For example in Eloquent, but from what I’ve seen — this is generally the case in framework
3. In general, Laravel seems to be pretty IMPLICIT (i.e. making assumptions on what you want to do) which is generally making writing code easier, but I think this is two-edged sword. I’m more of a fan of being EXPLICIT in WHAT YOU WANT AND NEED, even though it takes more time to write such code. This goes by hand with what Andrei mentioned about Laravel being pretty opinionated
Symfony:
1. What I liked:
1. Super simple to start with (looks like they hit a jackpot with SF4)
2. Out of the box great API support (you can expose data to API through Annotations, for example)
3. I LOVE the fact that it’s so flexible and basically lets you do whatever you want in any way that you want
4. What I like the most —> repository pattern was introduced from the VERY BEGINNING. This makes clear separation between data loading and usage of data, and I like that
5. You have to be pretty EXPLICIT on WHAT YOU WANT and in general you need to write more code to achieve something that’d probably be like a line or two in Laravel. I honestly LIKE this and I think this is generally a better approach since it’s more obvious on WHAT is happening
2. On the cons side:
1. It seems to be way slower whenever I make any code changes. Second-request is always fast (cached) but the initial request seems to be way slower than Laravel
2. Due to it’s EXPLICITNESS, it takes more time and probably knowledge to achieve whatever you want
3. Not opinionated and allows you to do anything you want in any way you want. This is probably double-edged sword
4. Overall, I think it’d take some time for everyone to grasp how it works but I think this is just a short-term loss and long-term this would probably pay off
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment