Please tre

Laravel

@Codex404 You have countered your own point apparently.

@mega6382 explain how I countered it?

@Codex404 As in Laravel is the worst php framework ever.

@mega6382 your evidence?

@ScribeOfGoD Main things being its utilization of traits, singletons, its overwhelming reliance on static methods.

And not to mention the Facades and the Eloquent ORM. Laravel Facades aren't even real Facades, and the way they let you add any kind of dependency in the code without any proper channel for like dependency injections.

And Eloquent is just plain terrible.

@mega6382 they do have IOC containers in laravel.

And what is wrong with eloquent?

I don't want to counter it since I agree :D i don't dislike Laravel tho

I like CodeIgniter because it's small foot print, I can easily edit core functionality, and it is yet to fail me as an API layer. I've used Zend in the past and I find it to be bloated and fat and overweight and unnecessarily large.

Please don't hurt me.

@CodeMonkeyG I will agree with your point but only about ZF1. Because ZF2 and ZF3 can't be considered frameworks in the same way that Laravel or Codeigniter are frameworks.

ZF2 and ZF3 are more like a collection of libraries, and you yourself get to decide the architecture, whether it be MVC, MVVM or whatever, you are not bound by in anyway with the requirements of the framework for using any particular architectural pattern, because there is no such requirement by the framework.

@Codex404 Main thing wrong with Eloquent is the mere fact that it is an active record based ORM, terrible for big and complex projects.

Sure, you can replace it with another driver like Doctrine, but that's the thing, why make the integrated features so terrible that I have to use an external alternative?

@Codex404 I also found this rant by @bittersweet you should check that out as well to get some better idea of how terrible laravel is, and be sure to check the comments as well https://devrant.com/rants/1119754/...

@mega6382 then I haven't tried it on long enough. We'll see what the next project brings 😁

@mega6382

I love to hate Laravel, but I do actually think it has its place.

Laravel is great for small to medium CRUD-based business sites. Think of it as a way more flexible and clean WordPress. You start from scratch, but especially paired with Laravel Nova you can quickly build a clean CMS or webshop.

Laravel can also be used for large sites, but in my opinion Symfony is more suitable for building serious platforms. Laravel can be a bit painful to work with if you heavily rely on "smart" aggregated data instead of just plainly modeled REST stuff like articles with authors and comments.

I'd consider Symfony the best PHP framework in the sense that it is "correct". It's very unsexy to work with though, very verbose and strictly adhering to OOP principles.

Laravel is easy, sexy and a bit dirty... Which are usually signs to wear a condom.

@mega6382

Consider Airbnb.

Listing your apartment is simple Create/Read/Update/Delete. An active record strategy is viable for this.

But you would also want to match available apartments with candidates based on more complex metrics like distance, avg rating, maybe even previous experiences or behavior, etc — aggregates.

Laravel has its ORM heavily tied into the models, and while you can do joins and raw queries, there are lots of pitfalls. Ambiguous columns, Eloquent scopes can't be reused on sub selects, etc.

A part of Laravel's issues can be solved by creating database views and attaching extra models inherited from a common parent as the base model to it, but much of the solutions can feel hacky.

Symfony/Doctrine repositories are more work and more verbose for simple CRUD, but much more correct and flexible for complex data handling.

@bittersweet I will agree with you in regards to it being an OK, framework for small apps, but even then I wouldn't consider it to be the best at it.

For small and simple projects even CakePHP, Yii and CI would be OK, but the main issue is that these frameworks and especially Laravel promotes very bad practices, and if and when you have to scale those apps, you will be left with an utter mess and nothing else.

I will consider these framework to be only good for rapid prototyping and nothing more.

@mega6382

Although in my experience, no single framework scales well.

If you need scale, it's best to ASAP start thinking about functional domains, separate repositories, and communication models (message queues, shared databases, APIs) between internal products.

For example: I've worked at several companies trying to transition from PHP + blade/twig/etc templates to PHP REST + JS framework SPA.

Ideally, you should build up your backend as an API from day one, and have your frontend in a separate git repository. PHP code which generates HTML is "wrong".

But there's no reason to stop there: Why not build your data aggregration tools using Python, let it cache into Elastic, and let a tiny Laravel core consume that information?

Scaling is rarely about choosing one language or framework, it's about choosing the right languages for each segment of your application... and especially finding the right tools to enable smooth & failure-resistant communication between those microservices.