As a new solo founder, I decided to move away from my initial Laravel MVP for performance reasons. It may be good for small or medium scale apps, but it's one of the slowest frameworks in existence (even with performance optimizations like Swoole) so scalability becomes a concern much earlier than if you were to go with something else.
@@SylvainReiter I've been building a few saas on Laravel for the last 2 years. I'm amazed by the support, community, and how easy it's to maintain it and focus on the core features of my products. The DX is like coding Ruby on Rails.
Until very recently the makers of Laravel released new versions every six months - with breaking changes. They were proud of it. I understand that they have now slowed down the pace of rewrites. Nevertheless, Laravel remains the most frequently rewritten, and therefore - by definition - the least stable of all the leading PHP frameworks. So, I have a question. When you build a commercial app for a client and their app quickly becomes obsolete, because of Laravel's insane rewrites, do you: A). Leave the client with a site that is out of date. B). Charge your client for the various updates that are required to keep Laravel up to date - telling your client, honestly, that they are now being financially punished because they chose Laravel. or C). Charge your client under the pretence that it has something to do with 'security' (aka, "The Laravel Deception"). What kind of Laravel developer are you? A, B or C?
Hi David - thanks for the question, worth addressing! I cannot pick any of your option as this is not how we see it. Most Laravel updates we are doing are done alongside PHP upgrades (PHP8 recently) and are indeed for security reasons (which is outside of Laravel's control). It also includes refactoring which is always a must-have in any framework, as the webapp's business requirements are evolving and the code written many years ago is no longer optimal. I don't agree with "financially punished because they chose Laravel" as we usually discuss the pros and cons of various solutions and we have found the TCO (Total Cost of Ownership) of Laravel to be better than most other options. Tools like Laravel Shift help speed up the upgrades and we found going from Laravel 5.1 to 9 much less painful than Drupal 7 to 9! The vast majority of our clients are actually platforms we inherited from incumbent, and we made it our speciality to "rescue" such project by improving the reliability, performance, tests and overall release velocity of such projects. Our enterprise clients are also satisfied with the support, as they all expect "BaU support agreements" to take care of ongoing security upgrades. We are happy with the performance of Laravel and find it very flexible, reliable, providing good value for money (compared to other enterprise frameworks) and our team enjoys working with it too, so a good developers' retention tool. Because Laravel is built with testing in mind, we enforce this as tested code - in any framework - is what helps you maintain and improve reliability. Unfortunately, this is not to good standard on most projects we take over from incumbent developers. At the end of the day, the tech does not really matter. The success of a project will depend on many other factors I discuss on ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-A60ZrAWOgCo.html
@@SylvainReiter Whilst I don't agree with your perspective, I'm very impressed by the graceful and eloquent manner with which you responded. Most people in your position would have deleted or hidden my comment. So, I have no retort to offer. Your response was excellent. Best of luck!
@@davidconnelly Having an obsolete application is not something unique to Laravel, but we have applications in ASP, Java, among others, that are obsolete and running ae, but there is an enormous difficulty in updating, in my view it is less painful in Laravel, but this possibility still exists, however annoying it may be it is.
