Hi, to give a bit of background I have more than 15 years experience in PHP, started by doing small business website and hosting (pretty much what you are doing) and now developing full backend application that have millions of users. I also did a master's degree about PHP framework for startup.
That being said I'll make some assumption:
you don't build SPA (using frontend framework like React/Angular/View and just use the backend as the api)
you don't build mobile application (same concept as SPA)
you do manage your own server (maybe not but this is really not clear)
most of the website your develop have really low to low traffic (meaning less than 50 people connected simultaneously)
sometime you need to build some admin section
Base on that and reading the other comments here are some thoughts.
API Platform is not for you. If you are not building SPA/Mobile application that need a API there is no reason to use this.
Laravel have a history of bug, low quality, breaking backward compatibility and I agree that thy push wrong programming practices. They might have put a LTS for their version 6 but this is pretty new.
Never heard of ZendExpressive but heard of ZendFramework that it's based on, not a good track record either.
So to keep it for the last Symfony would be my recommendation. Learning curve is a bit hard but they have the track of building the best component/libraries (Laravel is base on Symfony component and probably a few tools mention bellow). It's impossible to not update your stack for 10 years, Symfony have probably the best track to be backward compatible, even some bundle (how to provide extension to the framework) from version 2 are still compatible with version 4 and most of the time they provide tools to upgrade their major release but for sure a good UPGRADE documentation. They are really transparent about the roadmap (LTS) symfony.com/roadmap
If you have a admin to build you could use those to bundle:
A more light one but will still cover most of you need symfony.com/doc/current/bundles/Ea...
Or a more complex but flexible solution. They also have some CMS extension symfony.com/doc/current/bundles/So...
If one of your customer project become bigger or want to have a mobile app (or progressive web app) with symfony you will be ready (there is plenty of bundle to do this event the API platform could be add later). There is also a HTTPCache layer that can be easily configure with file if you just have one server and don't have access to a cache proxy like Varnish (building your site thinking about how to cache it could increase drastically the response time going from hundreds of ms to less than 90 ms)
On a more long term point of you I would use Symfony and be really careful about which bundle you use. I encourage you to develop your own bundle (when you have specific needs) and release them open source and manage them via packagist so it will be easy to maintain. There is also a way to have a private package hosting solution if you don't want them to be open source. For the hosting part of your business I suggest you to find a great hosting solution (shared in your case) and open the your customer account on it, there is legal issue (ssl, data privacy security, etc) up time, etc. That you don't want to be responsible for. You are still the point of contact for your customers and charge for the application maintenance but it's a lot easier, the time you save on hosting issue can be put in finding other customers.
Thank you for your very helpful feedback! You're correct in your assumptions - most projects are small and low traffic. I do resell robust shared hosting to my clients with the whole suite of their needs (email, SSL, etc).
I too am leaning toward Symfony. I love that it starts as a microframework and can grow with my needs, and focuses on backward compatibility. :)
You're comparing Laravel 3 with Symfony 2. And telling symfony 2 is compatible with v4 is anything but true. Our team put ~ 100hrs (!) upgrading a medium sized symfony 3.3 project to v3.4.
The problem is that most of the comments here are based on random rants found on the net and vague, vague experience.
This Laravel encourages bad practice vs. symfony is the enterprise php framework mantra is super outdated in 2019 and is also very superficial.
Both systems are very mature, very similar and have their pros and cons. Not to mention that they're copying each other a lot.
There's no jolly joker. The less upgrades you want the more you should think about managed platforms. Do you really have to actually write code to solve your client's problems?
Why do you stick to php?
The requirements you define put you in a position where there's no right choice for you. And the more seasoned you become, the more you'll see.
I suggest to start the requirements from the client needs and not from your preferred tech stack.
I don't see the comparison of Laravel 3 with Symfony 2... Never said that everything in symfony 2 is compatible with 4 but on a lot of thing are backward compatible and dependent of the bundle it might be compatible (if composer requirement allow it). In any case if the bundle is not about modifying core behaviour or advance stuff they are pretty easy to update following the guideline that are normally provided.
I have put less effort to migrate a medium size project (we should define medium) from Symfony 3 to 4...
But yes I do fount that Laravel enforce bad practices, never check the version 6 maybe the "fix" this but this is more a design choice than anything else. I do agree that they do copy each other, the same way Symfony did copy concept from Spring framework in Java and that Doctrine is greatly inspired from Hybernate too (at least a while ago).
For the "stick with php" I would make the point of knowing a stack on the tips of your finger help a lot. Maybe if you have a "expert" in every stack you may be able to pick the best stack every time but most of the time the best choice is to pick the stack that you have the resource to with. Than it's just a question of being professional and being able to let potential client that the stack you know and use is not well suited for there needs and refer someone else. From what I understand of the use case he might be alone in the company, having a lot of different technology may not be a option.
And if you have only one project a rule of thumb is to put the lowest amount of different technology in it, it's easier to maintain, document and find new employee if you need too. I am not saying that we should do "standard" web site rendering html because we don't want to add Angular in you stack, but you don't want to have php, node js, python in your backend stack just because you could. The same way you should not try to force php in to do a socket server for a real time application (like a game) even if it's possible, it's not made for that.
What I wanted to point out is that we could solve many of the problems without writing a single line of code.
I've been struggling with developers (incl myself) to open their minds and take a fresh look at the requirements without opening the IDE first.
Programmers have an obsession to the code. We should write much less code. Static sites don't necessarily require code (wix, managed wp, etc). Data processing and visualization doesn't require code (AWS Glue, Athena, QuickSight). Many many webshops don't require code (shopify, hosted magento, woocommerce).
I was surprised at my current work how many brilliant things were solved without writing code. It just needed non-programmers in the room.
Back to Laravel: I've been working with Symfony since 2007 and used to say this Laravel bad practice mantra as well. The reason was I never did a single project with Laravel, just opened the Laravel doc saw some static calls, went to some random forums, read ppl ranting about it and called it a day. Then we were kinda forced into a Laravel project and after a few months I've realized I knew nothing about Laravel before.
And then when I saw the new features of Symfony 4 at SymfonyCon in 2017 I was nodding because quite a few were concepts existing in Laravel. Dotenv, FQCN as service name in the DI container, Interface binding to implementation, class name based injection, the updated folder structure just to name a few.
We should be much more pragmatic about our profession and be less obsessed with the choice of technology.
Yes you are right about using tools that are not related too coding. He does it by using wordpress (pantheon offer and self hosted solution) and it would be worth to expand those solution with the tools you mention. Having a few tools predetermined for some use case to pick from is a good idea and evaluate where the project will go and the plan if it need to grow is the way to go. I am personally only working on project that is worth using symfony it's more a "if you could do it with word press or shopify, (or something else) go for it since it's the best solution but this is not what I do/work on."
For the laravel point I have been force to work with Laravel (version 4.*) and mhy opinion didn't change. I do agree that Symfony did bring some feature from Laravel, I think they did it better, but we could look at it another way Angular2 was doing injection with FQCN detection on service, did they do it before Laravel ? (I honestly don't know and don't care really) my point is that everything is getting better (I do hope so) and it's hard to know who did it first but having some serious competition help to push things further.
Hi, to give a bit of background I have more than 15 years experience in PHP, started by doing small business website and hosting (pretty much what you are doing) and now developing full backend application that have millions of users. I also did a master's degree about PHP framework for startup.
That being said I'll make some assumption:
Base on that and reading the other comments here are some thoughts.
API Platform is not for you. If you are not building SPA/Mobile application that need a API there is no reason to use this.
Laravel have a history of bug, low quality, breaking backward compatibility and I agree that thy push wrong programming practices. They might have put a LTS for their version 6 but this is pretty new.
Never heard of ZendExpressive but heard of ZendFramework that it's based on, not a good track record either.
So to keep it for the last Symfony would be my recommendation. Learning curve is a bit hard but they have the track of building the best component/libraries (Laravel is base on Symfony component and probably a few tools mention bellow). It's impossible to not update your stack for 10 years, Symfony have probably the best track to be backward compatible, even some bundle (how to provide extension to the framework) from version 2 are still compatible with version 4 and most of the time they provide tools to upgrade their major release but for sure a good UPGRADE documentation. They are really transparent about the roadmap (LTS) symfony.com/roadmap
If you have a admin to build you could use those to bundle:
A more light one but will still cover most of you need
symfony.com/doc/current/bundles/Ea...
Or a more complex but flexible solution. They also have some CMS extension
symfony.com/doc/current/bundles/So...
If one of your customer project become bigger or want to have a mobile app (or progressive web app) with symfony you will be ready (there is plenty of bundle to do this event the API platform could be add later). There is also a HTTPCache layer that can be easily configure with file if you just have one server and don't have access to a cache proxy like Varnish (building your site thinking about how to cache it could increase drastically the response time going from hundreds of ms to less than 90 ms)
On a more long term point of you I would use Symfony and be really careful about which bundle you use. I encourage you to develop your own bundle (when you have specific needs) and release them open source and manage them via packagist so it will be easy to maintain. There is also a way to have a private package hosting solution if you don't want them to be open source. For the hosting part of your business I suggest you to find a great hosting solution (shared in your case) and open the your customer account on it, there is legal issue (ssl, data privacy security, etc) up time, etc. That you don't want to be responsible for. You are still the point of contact for your customers and charge for the application maintenance but it's a lot easier, the time you save on hosting issue can be put in finding other customers.
Thank you for your very helpful feedback! You're correct in your assumptions - most projects are small and low traffic. I do resell robust shared hosting to my clients with the whole suite of their needs (email, SSL, etc).
I too am leaning toward Symfony. I love that it starts as a microframework and can grow with my needs, and focuses on backward compatibility. :)
You're comparing Laravel 3 with Symfony 2. And telling symfony 2 is compatible with v4 is anything but true. Our team put ~ 100hrs (!) upgrading a medium sized symfony 3.3 project to v3.4.
The problem is that most of the comments here are based on random rants found on the net and vague, vague experience.
This Laravel encourages bad practice vs. symfony is the enterprise php framework mantra is super outdated in 2019 and is also very superficial.
Both systems are very mature, very similar and have their pros and cons. Not to mention that they're copying each other a lot.
There's no jolly joker. The less upgrades you want the more you should think about managed platforms. Do you really have to actually write code to solve your client's problems?
Why do you stick to php?
The requirements you define put you in a position where there's no right choice for you. And the more seasoned you become, the more you'll see.
I suggest to start the requirements from the client needs and not from your preferred tech stack.
I don't see the comparison of Laravel 3 with Symfony 2... Never said that everything in symfony 2 is compatible with 4 but on a lot of thing are backward compatible and dependent of the bundle it might be compatible (if composer requirement allow it). In any case if the bundle is not about modifying core behaviour or advance stuff they are pretty easy to update following the guideline that are normally provided.
I have put less effort to migrate a medium size project (we should define medium) from Symfony 3 to 4...
But yes I do fount that Laravel enforce bad practices, never check the version 6 maybe the "fix" this but this is more a design choice than anything else. I do agree that they do copy each other, the same way Symfony did copy concept from Spring framework in Java and that Doctrine is greatly inspired from Hybernate too (at least a while ago).
For the "stick with php" I would make the point of knowing a stack on the tips of your finger help a lot. Maybe if you have a "expert" in every stack you may be able to pick the best stack every time but most of the time the best choice is to pick the stack that you have the resource to with. Than it's just a question of being professional and being able to let potential client that the stack you know and use is not well suited for there needs and refer someone else. From what I understand of the use case he might be alone in the company, having a lot of different technology may not be a option.
And if you have only one project a rule of thumb is to put the lowest amount of different technology in it, it's easier to maintain, document and find new employee if you need too. I am not saying that we should do "standard" web site rendering html because we don't want to add Angular in you stack, but you don't want to have php, node js, python in your backend stack just because you could. The same way you should not try to force php in to do a socket server for a real time application (like a game) even if it's possible, it's not made for that.
What I wanted to point out is that we could solve many of the problems without writing a single line of code.
I've been struggling with developers (incl myself) to open their minds and take a fresh look at the requirements without opening the IDE first.
Programmers have an obsession to the code. We should write much less code. Static sites don't necessarily require code (wix, managed wp, etc). Data processing and visualization doesn't require code (AWS Glue, Athena, QuickSight). Many many webshops don't require code (shopify, hosted magento, woocommerce).
I was surprised at my current work how many brilliant things were solved without writing code. It just needed non-programmers in the room.
Back to Laravel: I've been working with Symfony since 2007 and used to say this Laravel bad practice mantra as well. The reason was I never did a single project with Laravel, just opened the Laravel doc saw some static calls, went to some random forums, read ppl ranting about it and called it a day. Then we were kinda forced into a Laravel project and after a few months I've realized I knew nothing about Laravel before.
And then when I saw the new features of Symfony 4 at SymfonyCon in 2017 I was nodding because quite a few were concepts existing in Laravel. Dotenv, FQCN as service name in the DI container, Interface binding to implementation, class name based injection, the updated folder structure just to name a few.
We should be much more pragmatic about our profession and be less obsessed with the choice of technology.
Yes you are right about using tools that are not related too coding. He does it by using wordpress (pantheon offer and self hosted solution) and it would be worth to expand those solution with the tools you mention. Having a few tools predetermined for some use case to pick from is a good idea and evaluate where the project will go and the plan if it need to grow is the way to go. I am personally only working on project that is worth using symfony it's more a "if you could do it with word press or shopify, (or something else) go for it since it's the best solution but this is not what I do/work on."
For the laravel point I have been force to work with Laravel (version 4.*) and mhy opinion didn't change. I do agree that Symfony did bring some feature from Laravel, I think they did it better, but we could look at it another way Angular2 was doing injection with FQCN detection on service, did they do it before Laravel ? (I honestly don't know and don't care really) my point is that everything is getting better (I do hope so) and it's hard to know who did it first but having some serious competition help to push things further.
Why would you want to call yourself a programmer if you don't even code, if you want to do content management / admin work, be a data input guy.