Hacker News Reader

Comment by JonathanBeuys | Hacker News Reader

Even though I prefer Python over PHP, for web projects, I'm probably down with PHP forever. Because it so nicely supports stateless request handling without long running processes.

In PHP, you can just throw a php file on a webserver and it works. To update, you just update the file. You don't have to restart anything.

On the dev machine, you can just have Vim in one window and Firefox in the other, change code, hit F5, and you see what you did.

I don't like having to run a code watching process which then recompiles the whole codebase every time I save a file.

View on HN

PHP is underrated, especially as a learning resource. I'm very surprised I only ever built something with vanilla PHP on the job a few months ago - and how fast I could go from idea to prototype.

There is a very natural learning progression to: First build apps that run purely locally; then build a few static websites, maybe starting with hand-crafted HTML and eventually using something like Hugo; then build a small dynamic website with vanilla PHP; then finally build something with a more complex framework, like Laravel or Django. Going upwards in these iterations I think would help a lot ofd newer devs internalize where the tradeoffs of inital complexity vs. future ease of development lands for them.

The differences you speak about arise due to the nature of their design. PHP was created for the web whereas web programming support in python wasn't part of the language design. When you speak about web programming in python, the seam between the language and the web is usually a wsgi/agsi layer. This is where all the things you mentioned come into play. There's a whole lot of benefit imo to using python over php beyond that seam.

There's a fair bit of nuance and it really depends on the setup. You can run Python with CGI and execute once per request but it's much more common to use wsgi/asgi. Likewise, I think php-fpm is still pretty common which runs long running PHP processes.

The difference is striking the balance between developer's speed and performance. In case we don't want to reload everything and run from scratch, it's pretty easy to do with python too. But we "chose" to run it always and quick reload, so the requests aren't too slow [and scalable].

Rest of the things you mentioned are pretty same for Python as well.

You talk about performance, but I think that is another point for PHP. In my experience, PHP handles the same requests faster.

Yes, I could build everything from scratch myself in Python and have the same statelessnes as in PHP. But parsing headers, creating headers etc feels like it should be handled by a framework. In PHP, it is build right in.

And if I would build it, it would talk to the webserver via CGI. But I think CGI is slow. For PHP, you have mod-php which is super fast.

If PHP doesn't recompile your script imports, how does the reload tracking work with dependencies? Or does it punt somehow (eg only reloads your script but not is imports)?

There are various implementations of this kind of autoreload system for Python but it always seems to come with compromises on semantics (different initialization order causes behaviour differences).

Most major PHP frameworks like laravel, symfony, Drupal, Magento develops all kinds of complex caching layers to work around PHP's stateless 1 request/1 execution model, essentially poorly recreating shared application state you would get for free with a long running worker process.

Python's import model is not without its flaws either, but at least you have a working application state, no need to fully initialize your app for every single request.

For simple apps that are contained within a few files, PHP is hard to beat for simplicity and speed.

Imports are also updated the moment you update the imported file.

I'm not sure if PHP stores any compiled binary or byte-code at all. Maybe it compiles it all on each request. It's super fast though, even with tons of imports.

My guess would be that it keeps compiled versions of each file in memory and on each request, it walks down the whole import path. And when it encounters a changed import, it compiles only that one.

Would be cool if someone with more knowledge could shed a light on what is actually happening.

Afaik, PHP can have opcode caching enabled or disabled.

True. I see a "Zend OPcache" section in my phpinfo().

It says:

    Cache hits   4746528
    Cache misses   38875

Both values go up every time I execute phpinfo().

I wonder why. Shouldn't "Cache misses" only go up when a source file is changed?

AFAIK, before PHP even accesses opcache for bytecode, it checks the file's metadata (last modified, most likely). So an updated file might never trigger a cache hit or miss.

If it does not access the opcache, against what is it checking the last modified date?

In PHP, dependencies are just .php files just like your own code, it all works the same.

PHP code is also typically far less complex than Python modules - modern PHP code consists of a single index.php with procedural code, and everything else is just class / function definitions, so there are no side effects.

If you're talking about importing third party dependencies, composer takes care of that.

You can just do this with Flask or other frameworks/servers that support auto-restart

(yes I think some js frameworks also allow this)

When a framework "supports auto-restart", that usually means it has its own webserver for development and the auto-restart is supported when you use that.

I don't like having a different webserver in development and production.

For Python, gunicorn is suitable for production and development use and has a --reload option to reload on changed files. This functionality is framework-independent.

The way I understand the gunicord documentation, this has the same effect as if you set up a script which listens for file changes and restarts the server (or workers) every time a file changes.

That's way less efficient compare to how PHP handles it.

I don't want processes to be killed and new ones to be started every time I change a file.

PHP does it the right way: Only when a request that touches outdated code hits the server is that outdated code reparsed. As long as you just edit files, it uses up no resources at all.

I’ve never switched to the browser and reloaded the page fast enough to “beat” a gunicorn reload after editing a file. So I get not “wanting” a process restart but I don’t get why it’s such a big deal in a practical sense.

But hey if using what you use does what you want, then you do you.

Reply on news.ycombinator.com