I get where you're coming from but recent versions are quite different. Specially with the new one which requires also PHP >8.2 afaik.

But having 30s requests in general should be a red flag into other systems, laravel surely won't take that much to bootstrap.

Granted, this was on some virtual machine on a computer from 2007. But I did pare it down and down until all that was left was Laravel itself, doing "nothing".

I don't find it all that surprising. Overly-complex startup times are the convention for web frameworks that want to be taken seriously [by koolaid-driven managers]. These days I'm forced to work with Spring Boot, and it also takes for-eh-ver to get to the point where it can run my code. According to the logs, it's a lot of walking the classpath to find every different class and figure out how to assemble them into an application. Because heaven forbid someone call a constructor to make the object they want.

Hearing these negative laravel opinions is super interesting. As someone who absolutely dreads working with php, I’ve always been curious about laravel cause people seem to love it so much.

As someone who has worked in a lot of languages and a lot of frameworks, I never understood the hype around Laravel. It's very opinionated as to how you structure your application but it gives you very little for forcing all that structure. I thought it would be and should be more batteries included. And the active-record style ORM is also not my cup of tea.

Nothing to fear about it. It's just a scripting language. It has some bad history but not so much because of the language but how it was used. The same messes could have been (and were) created with VBscript (ASP) and Perl back in the day.

All I can figure is that a lot of people, especially those willing to put up with PHP's warts in the first place, look at a giant crusty knot and can only be impressed with its size and seek to emulate its design. If, upon seeing the huge crusty knot, you puke in your mouth a little and say "are you sure you needed a knot at all" they briefly look at you funny before carrying on to make bigger and bigger knot composition frameworks to blather about on their blogs where they have a picture of their head in a little circle, because that was trendy among the so-called artisans for a time.

"the ORM didn't support composite keys"

Well composite keys are a bad idea, so maybe it had a reason for that.

Composite keys are fine as long as all the key columns are surrogate keys.

High bridges without guardrails are fine as long as you don't fall off.

Using composite keys can help prevent you from representing invalid states in the database or in your application. They can be guardrails.

If an ORM can't be used to access a valid database, then that ORM sucks. (ORMs often suck for additional reasons, but that one's pretty hard to ignore if you have an existing database that you need to interact with.)

There are perfectly valid uses for composite keys. In a table that indicates a relationship between multiple other objects, for example.

ORMs only make easy things slightly easier. Complex queries are not expressable in ORMs, so you need SQL queries (usually as strings, in external files or generated with a tool like jOOQ/LINQ).

I think just doing all with SQL is easier to understand and maintain.

I see no benefit of ORM considering the small benefits vs cost of learning.

And your code become hugely dependent on them.

Agree 85%. 10% relates to cases where you want dynamically- generated queries, which is why Phrebar has facilities to help with this.

No off-the-shelf ORM that I've ever used has done anything but get in the way.

Another 5% disagreement over whether they even make easy things easy. They often require some contortion of your application code in order to work at all, like annotations or inheritance on value objects that lead to them being coupled to a specific data source.

100% agree :)