I would never use Java for web or for anything else, PHP more so. Kind of a bait comment, tbh.

For web there is SO many better alternatives in 2025. There is zero reason to pick PHP. Literally.

Which ones do not require JavaScript AT ALL? Simple use-case: in which language may I make a CAPTCHA that does not require JavaScript? What about a full-blown e-commerce website?

What does a server side languge has to do with captcha? What are you on?

Case in point, then.

I made a PHP CAPTCHA that requires no JavaScript, so pretty much everything?

What would a client-side language have to do with CAPTCHA? Kind of defeats the purpose of it, or rather, what it (server-side) does not have to do with it?

Go. C#. Kotlin. I could name many. I think you’re confused.

How does any of these languages help me write a proper HTML document?

All of them? You can have typesafe HTML in most of them.

How?

C#? Kotlin? For a CAPTCHA? Funny.

Have you tried building web apps at all in these languages as opposed to PHP?

I do not like PHP much but I don't get the hatred. I chose PHP as opposed to Go (and I never, ever considered a JVM-like language) when trying to make a simple CAPTCHA, but I did choose PHP for a full-blown e-commerce website too.

PHP has built-in session handling, the deployment is extremely simple and works out of the box, and PHP's server-side rendering aligns perfectly well with no-JavaScript sites, form handling and image submission work natively with PHP, and so on. Go may offer better raw performance but it does not make sense to use Go, and it is laughable to ever consider Java or Kotlin for it.

If you need an exhaustive list as to why picking PHP is the right (or pragmatic) choice here as opposed to Go or JVM-like languages, let me know and I will provide you one.

I argue that there is nothing more easy than deploying something like Go (or anything else that is compiled). With PHP you STILL ens up with a complex deployment pipeline even the apologists argue "just ftp it like in the 90s".

Deployment has not been an issue for me using PHP, nor Go, in all honesty. I did find Go more as-if I was using the wrong language for the job though.

I don't use it myself but Laravel is arguably a good reason to pick PHP.

Why is the only PHP defence i hear always the same "use a framework!". I did those for decades, and they always end up sucking. Either you need to hack around them, they have shitty defaults and finally they are abandoned and bitrot without any way of rewriting because of the huge size of the app.

How about just write the code, using the stdlib and picking highly focused libraries for things you dont want to write (crypto, drivers etc.) your self.

Because using the particular framework in my experience once you have a basic grasp of it's concepts, makes development time of applications extremely fast. Delivering is what pays the bills.

I did not like the popular frameworks either, they were too limiting.

I always ended up writing most things from scratch (using stdlib).

So... I agree.

Why make your own framework in PHP instead of other languages?

PHP has unicode support which what you need. You only need to understand when to use what function.

Concurrency support is not needed because that is what the webserver is for.

You cant have unicode without the mess of mb_real_uppercase and friends. Concurrency on a webserver? LOL, this is like the lowest bar i have heard. This limit SO much and pretty much forces the concurrency to the client, and thats not always an option.

Of course you can. Write your own abstraction of Unicode string, it is easy. Php has all the tools for it.

Yes, in mainstream PHP you use the webserver to leverage forking. The great thing about that is that vastly simplifies the language and any frameworks written in that language. No, it doesn’t force anything to the client.

Also any performance gains made in web server technology is given to PHP for free.

In Java and Python and the like you typically have a thread pool to handle every request, this has the benefit that you can share memory with mutexes between request (threads) . However 99% of cases that is not typically something you want, to have leaky requests, thus most of the time you write code similar to PHP to avoid any hard to debug lock. In Python you also have bad threading performance because of the GIL, thus you avoid anything that steps into that.

Thus PHP share-nothing-model wins again. It is also a natural fit to stateless REST. In PHP you use the database to share memory (data), which is a natural fit in a web stack. And as with the web server you can now leverage any performance gains in database technology.

Nodejs is of course complete trash with the mini freezes of the event loop. And to leverage multiprocess you have to use something like cluster, thus you are back to share-nothing again.

Thus what you argue for is to change a successful request and memory model because of that 1% use case. That is dumb.