I am here to empower developers, designers and marketers to deliver better digital products and solutions. From my 15y experience in growing a digital agency from 2 to 100+ staff, I have discovered that to succeed in digital, you need to combine user experience, technology & compliance.
My mission is to make you grow into a digital leader and deliver better experiences for your team and customers. This is achieved by applying UX principles, embracing Compliance and understanding Tech. This additional knowledge will help you make better decisions and stand out from the crowd by delivering results.
as a sitebuilder, the biggest problem for me is the upgrade status of modules. another frontier or limit of Drupal is how to manage the data, I mean updating nodes with new data, importing new nodes from external data sources, letting scripts update node data. it's very painful.
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.
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.
@@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.
Same here Nawin, we are enjoying D9 but it's time to prepare D10! The beta2 is out on www.drupal.org/project/drupal/releases/10.0.0-beta2 if you want to try it (not ready for production yet)
You have a good channel with great content. Keep it up. It's sad to see that despite having such good content, the views and subscribers are so less. I hope youtube fixes their algorithm soon. And more Drupal related videos please!! Thanks.
As a developer/company the white label concept is great like you said. For the client I have my doubts. Most of the times I see huge clients going with the white label route and sometimes ends up not differentiate enough. And other times I see small businesses that want a full custom application and invest a ton of money while probably they could going the other way around by using a white label application. I think it's important as a developer/company who sells this products to really explain this to theirs clients
Thanks Mário, this is true - We've seen it work well for both large international clients and smaller entities with a complex product, but it's not for everyone as you said. It's important to prove the concept works for your clients, then you can scale. There's a lot of education to be done from us developers/agencies and this is why clients need our expertise.
