Comment by kingdomcome50 | Hacker News Reader

Comment by kingdomcome50 | Hacker News Reader

I've probably written some version of this comment over dozen times throughout the years when discussion about PHP rears its head (note that I'm fond of PHP):

PHP as a language is... okay. It's been modernized to include many of the faculties a developer would expect of a language in 2022. But honestly, I'm ready for the "improvements" to the language to stop. The closer you get to C# or Java the more obvious it is that PHP will never catch up! It's not that it has to catch up, rather, that few people actually choose PHP because the language is so great. If you were choosing a your stack based on "which language offers us the most features or highest ability to express our problem" you wouldn't be choosing PHP!

Here's the secret: PHP is probably the best language for server side webdev because of the runtime! It's so dead simple to develop and deploy PHP. I mean the language itself is basically a web framework right? How many other languages automatically parse an HTTP request and hand it to you by default? Or offer built-in templating semantics for composing HTML? Or have request routing by default? I don't know of another one. That's why I, and many others, choose PHP!

You know what I'd like to see? The trajectory of PHP's development change to lean in to the above -- to focus development on improving the reasons why it is chosen in the first place! I don't need a C# with slightly different syntax (or named parameters). I'd like:

- Improved templating semantics

- A better module system

- A way to bake routing into each file (overwriting the default semantics)

- Adding a built-in service-locator pattern/DI

- A way to make PHP scripts more testable

What I'm saying is just make it a better framework by default. I know I know... "Laravel this, Symfony that, have you heard of Slim?". Yes... I get it. There are community-made solutions to the above problems. And you know what? They won't be as performant or integrated as if the runtime itself was upgraded to make them obsolete. It's not like routing and DI are that complicated (the two most obvious reasons frameworks are employed).

I like that I can write a simple API in PHP without pulling in a single dependency! It makes so many things easier (the right things too). Now let's just extend that to all of the basic facets a modern web framework offers!

The odds of those things being worked into php-src are very, very small. Most of the time there has been discussion on these topics on the internals mailing list, it was clear that the majority favored keeping those things in userland.

The problem with templating systems, routers, DI containers, testing frameworks, etc.. is that they are all very opinionated. There is no one way to do it, and each implementation has upsides and downsides.

On top of that, the PHP ecosystem is so mature that for each of the possible implementations of these features, there is a stable, production-ready and actively maintained library/framework. Why reinvent the wheel?

An important detail is that most of these frameworks have also built a business around their product, which means that people are being paid to work on them. How would the financial situation work if you moved all that into the core?

For me, the current situation is close to the ideal one. For example, the recent addition of fibers into the core in PHP 8.1 was a logical step to allow cooperative multi-threading. It will be used by great userland frameworks like Revolt, Amp, ReactPHP and more. The full event loop feature would be too heavy for the core.

+ Composer is so great that installing any of these packages is a breeze anyway.

I used to look down on PHP, but after being forced to use it for a while I begrudgingly came to admire it for all the reasons that you've pointed out. And I started using PHP by choice, generally for writing small scripts (no frameworks or libraries) that I could "deploy" simply by copying the .php file into /var/www. It's a very productive language when used as intended.

PHP scripts on shared webhosting was the original "serverless" and you didn't have to be too careful about object lifetimes and leaking database connections because as soon as the request was finished the entire process was nuked from orbit.

But "modern PHP" is the complete antithesis of everything that I grew to admire about PHP because it's just another Java or C# with awful syntax and weird equality rules and gigantic frameworks with thousands of classes and interfaces.

I would very much like to see a version of PHP that dropped all the nasty namespace and object-oriented misfeatures and just focused on cleaning up the language semantics and enhancing the built-in framework features...

> because of the runtime! It's so dead simple to develop and deploy PHP.

As someone who had to deploy PHP applications: hell no. For developers it might be easy, but for admins, the runtime is nowhere near good. Sure if you think deploying your site using scp, already discovered rsync to do this, or even use the cutting edge way of deploying by using a git checkout on the server, you might think it's great. But that's how you take down sites or have service interruption.

The problem is not that it cannot be done right, the problem is that the runtime enables and even promotes such bad practices, and makes doing it properly harder than it should be. And then we don't go into php extensions, performance tuning, profiling, scaling, ...

I deploy PHP applications all the time! I simply cannot share your sentiment though.

I cannot think of an easier deployment paradigm than what essentially amounts to a copy and paste in the simplest case (i.e. what we should strive for), and maybe one or two more steps in a more complex case (e.g. `composer install`).

An entire PHP installation can literally be copied and pasted onto another machine and "just work"(though you may need to fiddle with some paths in the .ini). Similarly PHP is fast enough that it's unlikely to ever be the bottleneck in terms of performance/scaling for 99% of use-cases.

I suppose I can agree that PHP may lend itself well to certain kinds of "bad practices", but that's true for any system if not managed well.

I think we live in different worlds, and that's a bit PHP's problem, many of it's devs and users do.

From my pov, manually logging in on a server has been something for emergencies only for a long time now (10y+), and if it's frequently required or even essential to deploy and run an application, this is a sign of bad practices. So the last thing I want to read to deploy some software is "can literally be copied and pasted onto another machine". Maybe you can do that, but you never ever should even have to consider doing this. Where is your versioning, ci/cd (testing, quality gates, automated deploy), how do you roll back in case of a problem? How do you track when new versions were deployed? How do you address patching, runtime differences, active PHP modules and php-level config? What webserver do you use, how does it need to be tuned for your workload? PHP-FPM? Do you expect something specific? Do you rely on .htaccess files? The list goes on and on.

These things are a major hassle at the scale I've had to deploy PHP services. Its best option is containerise them, and then you have a bunch of other challenges due to the process per request runtime design impacting monitoring, metrics, autoscaling, ...

Agree.

The strength of PHP is also its weakness.

Because of the separation between PHP and the web server it makes developing PHP really easy because the web server handles the request for you.

But you pay the price when configuring your environment. Apache conf, php.ini, php modules, htaccess, etc.

To avoid too much craziness I tend to avoid custom htaccess files, unusual php modules, or weird php.ini settings to minimize the friction when deploying.

For large project you are almost required to run containers, but even then you can’t escape the custom bash script.

Sorry. I wasn't advocating for "copying and pasting", rather, I was using that as an example of how simply PHP can be managed. More generally, the simplest case is often a good proxy for what to expect when dealing with more complex scenarios. Of course we automate the above behind the proper pipelines!

Many of your other concerns are big "nothing burgers". It's not like versioning, patching, config, tuning, monitoring, etc. are any less of a pain in other runtimes. At worst you could argue that it's different.

Reply on news.ycombinator.com