PHP Yolo

Web development differs from environment to environment. If you are a .Net developer, you may have a different mindset than a person who works with PHP or ruby. In .Net, when you compile and deploy your code, an application is started and waits for web requests. It is up and spinning in a loop until a request comes. Not so in PHP. Before you make the request, there is nothing.

PHP is not entirely unique in this, but it is the one language that is deeply coupled to the web server. Very similar in the way that JavaScript is tied to the browser.

With PHP, each request starts with a blank slate. If you designed a framework to handle your web application, for each request PHP will read it from the ground up and try figure out how it can respond properly. Let's contrast it with .Net where you compile the entire framework first before anything happens. By the time you are getting a request, the code is already in memory. All it needs to do is process.

In PHP, we read the logic for the router first, then we read the instruction for the database connection, then we read the logic on how to respond to this particular request and so one and so forth. To someone who is just trying to get started with PHP, it seems absurd. But this happens to be one of PHP’s biggest advantage over other environments.

If I make a small error in my PHP and users are requesting the page, it will throw an error. When I discover the error, I can fix that line and the next request will work just fine. (no need to restart or recompile)

If I forget to close my database connection after fetching data, I don't have to worry about it. When the request is complete, it will close it automatically.

How does PHP do that?

PHP has the advantage of being a single process, born at request time, and dead after the last byte is sent to the user. When the process is about to be destroyed, every connection opened by that process is destroyed. Whether it is a database connection, a port service, or a file handle. They are all closed at the end of the request.

On Linux, the most popular web servers that run PHP are Apache and Nginx. They are the applications running in the background and waiting for a TCP connection on port 80 (default). When they deem a connection to be a legit web request, they spin a new PHP process and set up a few environment variables to help it get started ($_POST, $_GET, $_SERVER, etc.) At that point, the PHP process processes the request then sends some html output (or whatever necessary) to the web server. When the webserver is satisfied with the content, like a black widow, it kills the PHP process and hand over the content to the requester.

Killing the PHP process, kills every connection it opened along the way to gather content.

If two requests come at the same time, then Apache (web server) will open up two PHP processes. If three, then three processes. And so on, until the maximum number allowed in the web server configuration is reached. Here is the thing though, for each new PHP process, php script will be read from the ground up. Meaning, if I make changes as requests are being made, they will be updated as they are being read. Meaning, the last request will always have the latest changes.

Of course, the PHP Just In Time compiler can make some optimization (Opcache) when the files haven't change their content.

What does this do to development time?

Obviously, you shouldn't be changing code in your production environment. But the cool thing is, when you are developing in your local machine, this makes it very easy to test new feature.

As opposed to when you are working with compiled languages, (or something like nodejs), with PHP checking that new feature you added is simply a matter of refreshing the page. If you are trying to add a new meta-tag, add it in your php file and press F5 (to refresh). That's it. Want to check the value of a variable? write var_dump($var); and refresh. It takes one second.

I understand the value of debuggers and statically typed languages that shows you your errors as you type, but to me after working for years with PHP, I cannot understand why I have to wait 10 seconds or more to see my changes. I make a change, refresh and it is there instantly, no compile time whatsoever. In a real world scenario, when I work in .Net a single change often requires I rebuild a project and wait for compilation before I can see anything on the screen. This takes minutes sometimes. With PHP it takes 1 second.

I may do it 200 times in one sitting with PHP, quickly iterating through my mistakes and moving on. In .Net, Nodejs, or any language were I have to restart the server, or recompile, or transpile, it may take 20 seconds with a decent machine.

200 times in PHP is 200 seconds, around 3 minutes. 200 times in other environments is 4000 seconds or roughly an hour of me sitting down and waiting for my code to respond.

It's all the same in production.

Yes, I have to admit, when the code is deployed in production, things even out. All the services are spun, the .Net code runs in a jiffy, so does nodejs and others. But my issue is for Development. That extra hour spent working on the project is more valuable to me than just sitting and waiting. And the problem is, while I am waiting for code to compile I can't work on something else. It's not like I get a full hour of continuous wait. It happens sporadically. One of the things I have learned to do when working in non-PHP environment is to consolidate my changes. I don't test one thing at a time but a collection of changes, to save time.

It's not that one thing is better than the other, the reality is that a developer simply has to adapt to the technology presented to him. We don't all have the luxury of changing programming environment.

What we need to be ready to do is to have the ability to change our mindset.

---