What PHP Is and Why It Still Powers the Web
· 5 min read
PHP has been running the web for three decades, and it is still, by raw numbers, the most widely deployed server-side language on the internet.
PHP has been running the web for three decades, and it is still, by raw numbers, the most widely deployed server-side language on the internet. This course exists because that fact surprises a lot of people who assume PHP is a relic. It is not. WordPress runs on it, a huge share of e-commerce runs on it, and modern PHP (the version you will actually write, PHP 8) looks nothing like the PHP that gave the language its bad reputation in the 2000s.
How PHP Fits Into The Web
Understanding why PHP exists at all helps explain the decisions you will see throughout this course. PHP was built specifically to generate HTML on a web server and send it to a browser. That is its entire original purpose: a request comes in, PHP runs, PHP produces HTML (or JSON, or anything else), and the response goes out. Unlike a language such as Java or C#, PHP does not keep a long-running process holding state between requests by default. Every request starts fresh, runs your script top to bottom, and then the process ends and all its memory is thrown away. This "request in, response out, then forget everything" model is called the shared-nothing architecture, and it is the single most important thing to understand before writing a line of PHP.
Here is the simplest possible PHP script, the kind that would have run on a server in 2005 and still runs today:
$name = "Tony Stark";
echo "Hello, " . $name . "!";
Reading A Simple PHP Script
Two things to notice. First, the opening tag tells the web server "everything after this is PHP code, not plain HTML to send as-is." Second, PHP files can freely mix HTML and PHP in the same file, which is both PHP's original superpower and the exact thing that caused it to get a bad name. Early PHP code often looked like this, with raw HTML markup and little PHP conditionals scattered directly between the tags, deciding line by line whether to print a welcome message or a login prompt:
start html body
open php tag, if user_logged_in, close php tag
Welcome back!
open php tag, else, close php tag
Please log in.
open php tag, end if, close php tag
end html body
That pattern works, but it is painful to read and painful to maintain once a page grows past a few lines of logic. The entire history of PHP's evolution as a language and ecosystem, from frameworks to Composer (which you will meet in lesson 5) to Blade templates (lesson 8), is really the community collectively solving the mess that this mixing created. Laravel, which this course spends most of its time on, exists largely to give you a structured, organized way to write PHP so you are never tempted to write a file that looks like the example above.
Common Misconceptions About PHP
A second misconception worth clearing up early: PHP is not "slow" or "insecure" by nature. Those reputations came from a specific era, roughly PHP 4 and PHP 5, when the language had genuinely dangerous defaults (like register_globals, long removed) and no enforced structure. Modern PHP, from PHP 7 onward, got a complete internal engine rewrite that made it dramatically faster, and PHP 8 added real type declarations, named arguments, enums, and a JIT compiler for CPU-heavy workloads. The language your production servers run in 2026 is a genuinely different tool from the one that earned PHP its reputation, even though the file extension and the dollar-sign variables look the same.
It also matters to understand what PHP needs to run at all. A PHP file by itself is inert text; you need an interpreter to execute it, and in a web context, something to connect incoming HTTP requests to that interpreter. Traditionally that has been a web server like Apache or Nginx paired with PHP running as a module or through a protocol called FastCGI (specifically PHP-FPM, the FastCGI Process Manager, which is what almost every serious production PHP deployment uses today, including a Laravel app in production). You can also run a PHP file directly from the command line with no web server involved at all, which is exactly how you will run most of the exercises in this course:
php hello.php
That one command starts the PHP interpreter, feeds it the file, and prints whatever the script outputs, directly to your terminal. This is also, not coincidentally, how Artisan (Laravel's command-line tool, covered in lesson 16) and PHPUnit (lesson 17) work under the hood: they are just PHP scripts you run from the command line rather than through a browser.
File Extensions And Running PHP
One more thing worth knowing before you move on: PHP file extensions matter to the web server. A file named page.php gets handed to the PHP interpreter before anything is sent to the browser; a file named page.html is sent as-is, with no processing. This is why you will occasionally see production misconfigurations where someone's PHP source code gets served as plain text to visitors, because the server was never told to treat .php files specially, or a file got renamed and nobody noticed. It is a small detail, but it is the kind of small detail that separates "I copied some code and it worked" from actually understanding what is happening when a request hits a server.
Try it yourself: install PHP locally if you have not already (XAMPP, as used for this course, bundles it), create a file called intro.php containing the "Hello, Tony Stark" example above, and run it with php intro.php from your terminal. Then try opening the same file in a browser via a local web server and compare: same code, two completely different execution paths, same output. That distinction is the foundation everything else in this course builds on.
KEEP READING