IMHO Laravel and Symfony are the best things that happened to PHP community since php5. PHP was an ugly mess of bad practices, fragmented into many outdated apps/frameworks and it was just exhausting to use. Symphony was a great improvement, but a bit too rigid and too enterprise-level for my taste. For me Laravel was honestly a breath of fresh air - finally I had something significantly more powerful than my custom framework and still highly flexible and light-weight.
Agreed! Framework == good doesn't mean any/all frameworks == good. Many of PHP's frameworks seem to have ignored PHP's unique run-time characteristics and adopted Java idioms (with Java, you pay once at compile time; with PHP, you pay with every single request). Ubiquity, near/at the top of the PHP benchmarks, seems to accept PHP's unique run-time characteristics (so performs well) and yet still provides all the benefits of a framework (consistency, etc). Ubiquity should see much more love than Laravel/Symfony/etc but doesn't :(
No, in 2022 it seems it's not. Just seen this benchmark today: Laravel is the 2nd fastest, after Kirby (but Kirby is static text files CMS so it's not really comparable). Not sure what exactly they've tested and it's probably not super realistic, but still it's far from calling Laravel the slowest.
As soon as you throw an MVC framework into the mix with an ORM the much-touted speed gains of PHP in recents years vanish into thin air. That's because with heavy frameworks PHP's shared nothing architecture works against you.
Generally yes, but there has been at least some improvements regarding this with preloading shipped with PHP 7.4 and with the inheritance cache added to PHP 8.1, both synergize well with framework heavy code.
TechEmpower appears[0] to be using Laravel 8.70, which was released about 3 months ago. Much less than 7 years ago.
The numbers there don't paint an encouraging picture either, but I'm happy to concede that performance isn't everything... it just doesn't matter for some applications. But, numbers like these are pretty appalling to me. (And yes, I feel the same way about Rails.)
Compared to Zend, Symfony and other FWs popular a decade ago, Laravel 4 felt very light... or perhaps less complex is the right word, as I never really compared the file sizes, but it subjectively felt way easier to find your way around...
Any app without a framework ends up creating a framework of its own. Complexity isn't something to hand-wave away, but neither is the mess of include's and SQL injection risks that many "vanilla" apps become.
Same applies for frameworks. Your hoping that the framework and ecosystem is clean as to get everyone to update the framework isn't an easy task espcially when a vulnerability arises from within.
> However your then hoping that there are not any vulnerabilities within the framework.
The likelihood of me introducing an injection, authentication/authorization bypass or RCE vulnerability in homegrown stuff is orders of magnitude larger than in an application where at least the sensitive core parts are handled by something that's battle tested in millions of deployments and regularly audited.
If the framework is promoted to be enhanced by a ecosystem of plugins, widgets, your still introducing the same exploitable ground as of developing your own. If not more dangerous because your operating already on core infrastructure and with a wider audience. How often does the developer get bored and start to neglect the plugin?
I do agree that a single home-hobbyist programmer should not be coding a bank and that sql injections and the rest are all lethal to the internet. However you end up with stagnation and lack of innovation if you pressure users to use a framework because there's a fear of some sort of exploit.
It's like riding a bike and forcing the rider not to ride without stabilisers because they may fall sideways.
>How often does the developer get bored and start to neglect the plugin?
For the most popular frameworks (e.g. Drupal, Symfony, PHPunit), the core ecosystem is (co-)maintained by the framework authors, who are funded through various means - usually consulting/webdev agencies. The "usual" FOSS burnout problem doesn't apply for them.
> However you end up with stagnation and lack of innovation if you pressure users to use a framework because there's a fear of some sort of exploit.
A framework is just that: a framework. You can develop all you want with that framework - I've seen Symfony being used for tiny microservices to the code for a bank's website. You can develop faster and better code because you don't have to re-invent wheels or do tedious interoperability tests for basic stuff allll the time, and whatever problem you encounter, someone else will have also encountered and posted a solution on Stackoverflow.
> It's like riding a bike and forcing the rider not to ride without stabilisers because they may fall sideways.
No. Symfony, Laravel and others are the vendors for the basic bike... you can always bolt on custom parts according to your need and for the PSR-standardized stuff like loggers, you can even choose between multiple different part vendors.
You have valid points, I disagree on personal preference and so I'll agree to disagree.
I guess what i'm saying is building from scratch makes different happen. I can see the purpose of frameworks but when it comes to a new start-up project, it just feels like it should be built from scratch otherwise you have a project which is pre-made and not really yours. Thats what puts me off from using a framework.
Myself was script-kiddie in the older-generation of the internet era, 15/16. I'm talking 2003. when extensions have .php3 and uploading scripts over 56k took hours. If you wanted a forum, same for a CMS either use a pre-existing platform and used the functionality it provided or built it yourself. PHPNuke, e107, PHPBB all come to mind. However the internet was young, compared to now where technology has evolved and time is less, so I can see where frameworks come in.
Node.js is only fine if you have the personal energy to keep up with all of JS tooling all the time. It strikes me as insanely unprofessional most of the time.
Laravel always seems to be the work of grownups; it's not cutting edge but it is solid and self-contained.
beside legacy cobol, wordpress plugins were the most horrendous code i've ever seen. dead code I should say since quite often half of it was left commented in the official running source.
You can use Laravel just for the basic wiring, integrated tooling, SQL query builder, auth, sessions, and HTTP routing. It really gets out of the way if you need to avoid features you don't like. All of the stuff I listed above are a PITA in plain PHP.
I went kind of in another direction a few years ago - CodeIgniter's routing/sessions/etc base was plenty for most of my projects, but I wanted a real ORM. So I integrated Eloquent from Laravel and ignored the built-in CI database layer. A bunch of these sites are still running smoothly on modern PHP.
Having worked in both environments (framework vs no framework), for anything other than very trivial apps, you want the framework to force everyone into a common way of doing things. Otherwise the project turns into a a massive clusterfuck of everyone doing their own thing, often with many instances of "reinventing the wheel" going on.
PHP as a platform is KISS and elegant, and I still admire some of its features such as built in templating, filesystem based routing, etc.
But whenever I look back at Laravel, I remember how dangerous overly complex fluff with a nice logo is to a platform.