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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.