This is definitely a big part of it. PHP as a language was, to a certain extent, made for the web. The language included things like MySQL access. That meant

This is definitely a big part of it. PHP as a language was, to a certain extent, made for the web. The language included things like MySQL access. That meant that projects didn't need a lot of dependencies. PEAR existed for libraries, but it's not like Java or Python where things like cookie handling or MySQL access isn't baked into the language. This also meant that a lot of the things you'd do on the web were basically written in C and fast. This made mod_php very useful. You could write a login.php file that would do a mysql_query and return a redirect and maybe a couple hundred lines of code would need to be interpreted. Everything dealing with the web or database was built-in to the language. If you're using Python, you're loading libraries. Because different users might want to use a different library (or a different version), you couldn't easily build something that would offer the same capability there (where the web server had already loaded most of the things you want to do and shared that with everyone on your box). PHP basically had a web framework built-in and that meant that it could be loaded and shared. Rather than having to interpret your logic plus the web framework, it would just need to interpret your logic. Now, there are benefits to a library-based ecosystem. You can update your DB library without updating the language. If most programs in the world aren't going to talk to MySQL, why include MySQL access in the language? But that's what PHP was about. I do think part of what made the execution model possible was the language itself. It's certainly not impossible in other languages, but PHP was really made for the web and it made the mod_php-style system work well. With no long-running processes, it was easy to offer cheap shared hosting. The PHP language would be in-memory and then the scripts could be small pieces calling into the language functions. If I'm running a Java app or Python/Gunicorn or whatnot, I'm holding onto memory even when I'm not serving requests. Even today, memory isn't free. If you have a lot of customers getting minimal traffic, you'd like to use your hardware efficiently. If you have a 32GB RAM box, you could slice that up into 1,000 customers holding on to 32MB of RAM. However, if they're each getting a hit per minute, you have a lot of wasted RAM. Imagine personal blogs and home pages and such. Plus, when customers need a burst of resources, they aren't available - everyone has their 32MB of resources whether they're using it or not. With mod_php, customers could be using basically zero resources for the 99% of the time that they're idle. They could burst when needed. Some shared hosts way oversold their capacity, but it enabled cheap hosting. A lack of long-running processes also meant that a lot of potentially sloppy things never bit you. PHP had some language features that enabled good performance on a shared system compared to other ecosystems and that made it a great target if you were looking to create such an app. Today, VMs are cheap, but they still require a level of knowledge/work above just sticking files on managed, shared server. The execution model really drove PHP's adoption, but I think the language design made that possible. If PHP apps needed to load lots of libraries on each run, that execution model wouldn't have worked as well.