I have colleagues using Laravel, and there's nothing muddy-ball about their apps at all. Their code is tidy, modern, readable, and clearly maintainable.

In terms of practical effect, frameworks influence developers more than languages do.

When people say they use "PHP" for webdev I recall BBOMs of flat files and raw SQL. Historically speaking, "PHP" does not necessarily imply "PHP+Laravel" or any other sane framework.

OTOH if someone says they use "Python" for webdev I assume Flask/Django/etc.

I think you've summarized it well: people tend to make technical judgments based on preconceived and historical notions, in spite of evidence to the contrary. :)

That's good, I think? I'm not claiming that Laravel was the first or the best PHP framework, just that they were using it. (Admittedly I assume it's a reason their code is so well organized.)

Laravel inherits its organisation from the underlying Symfony 2 framework, just like Drupal nowadays.

Thanks, I didn't know that.

The idea of using a "framework" in a language that gets completely reloaded on every new request doesn't make sense - at least I thought a framework was something that wrapped your own code and presented an event loop, etc. You'd want a "library" if you just wanted to improve on the original low quality PHP database connectors and such.

But PHP developers always did seem to have inappropriate jealousy over unrelated languages like Java where there is persistence over requests.

You sound like me, but ten years ago. :) I used to have a similarly negative and narrow-minded perspective about PHP, but my colleagues and their outstanding work have enlightened me.

PHP itself is perfectly designed to run CGI scripts and the correct architecture for web performance (shared-nothing). It's the third party developers that have second-system effect enterprise dreams.

Though maybe some of them have found simplicity again.

you're right. it was obvious when we started seeing templating engines for php while php is itself a templating engine

Only thing missing from PHP now is to programmatically detect tainted strings, i.e. strings that are dangerous like user input, if we had that we could continue with the built in templating and still be sure to escape output at the correct moment.

Tainted strings should be built into PHP (there was an RFC for it but it didn't pass). Another solution could be using operator overloading instead (that RFC didn't pass either).

Or do what Hack did with XHP and make XML/HTML a part of the language, and escape everything else by default. That was the one Hack feature PHP should have taken, but didn't.

I am entirely unfond of PHP as a language but Laravel - and competently written apps that use it - are damn impressive nonetheless.

If you can't like the current PHP, there's probably no language that will make you feel too well. What exactly is so bad about it?

The point I wanted to make was that Laravel is objectively impressive even to somebody who dislikes PHP, so going into details as to exactly why I dislike the language would distract from what I was trying to get across.

I'm not sure why you've been downvoted. Anyone who has ever seen a Laravel stack trace will surely have been appalled at the number of stack frames that sit below their own code, and all that machinery is loaded on every single request. It's truly shocking. PHP isn't Java and shouldn't be treated as such.

There is a very strong movement for using a large framework within the PHP community, like Laravel, upside is that is has helped PHP community to revitalize the PHP stack. The downside is that large frameworks is now considered best practice.

I wonder if OOP as a technique will eventually always end up as Rube Goldberg machine.

I know what you're saying... but using Java as the counterexample? I'm still reading the stacktrace from a Java error I raised in 2003.

I haven't paid attention to frontend web development in like 15 years so I don't have any newer examples ;(

I'd hope new stuff is also CGI-based and restart on every request, otherwise you're asking for security issues (like leaking another user's info Heartbleed-style).

It has somewhat become better in PHP with preloading and better caches like the inheritance cache.

This is not true. If you need 1000 lines of templates to display a page, it will be 1000 lines no matter whether you use Twig (PHP) or React (JS). And Twig in my opinion looks better than JS code mixed with HTML tags and split into 100 files 10 lines each.

For the uninitiated, BBOM = Big Ball Of Mud.

Because what we're witnessing in JS-land these days is completely sane and rational.

All successful projects end up as a BBOM. The framework or language or architecture you use has no bearing on this. It is just the thermodynamics of software development. If something is not a BBOM it just hasn't been around long enough.

BBOM > debugging SSR hydration issues.

productive ORM & simple HTML template engine > BBOM

Not my experience. Most Laravel projects I've seen are in a much much better shape than even the most minimal "microservices" I've seen around. You get so much done for you with Laravel that it makes it a bit more difficult to mess up.

I've seen microservices that had absolutely no guardrais going off the hill too many times. At my previous job "migrations" where bash scripts with SQL in them because they "didn't like ORMs and they were slow". LOL. They were handling signup form POSTs and profile updates.

You can write BBOM in any language/platform/technology.

It is always the programmers that is the limitation, not the chosen technology. Thus you should pick technology that makes sense for the majority of programmers. PHP fits that. Just follow a guide to avoid BBOM.