Comment by CM30 | Hacker News Reader

Comment by CM30 | Hacker News Reader

It's not that surprising to be honest. WordPress' success comes down to the following:

1. It was simple to use in an era where CMS meant 'large, complicated system that was tailored towards technies rather than the general population'. It didn't have a ton of features, but it was easy to use for the average blogger wanting to write posts without worrying about all the setup and coding and what not.

2. You could pretty much install it anywhere without minimum technical skill, since PHP and MySQL was (and is) supported by about 99.99% of shared hosts. Its newer competitors tend to be written in languages that are usually only available on a VPS or dedicated server.

3. It has a very large ecosystem for themes, plugins and other such things, so someone with no technical skill could find add ons for anything they wanted without needing to call in a developer or know PHP.

It's not the best written software and its not the best optimised for anything in particular, but it is one of the easiest to install and use for someone without a technical background, which is why it's so widespread.

What's more amazing is Google had the nascent market in their grasp when they acquired Blogger, then promptly ignored it.

I agree with your points, but always wonder why shared hosting is often PHP/MySQL only. E.g. if you are using Python, say Django or Flask, and want to outsource your devops (i.e. shared hosting) you do not have many options.

Of course, there is pythonanywhere or you might want to use PAAS like Heroku, but I find it interesting non the less. Is it so much more work for shared hosting providers to provide Python?

PHP guys are very smart about not trying to reinvent the wheel. They always supported the most common web setup: Apache running on its standard configuration. That's why every shared host company in the world is confident in deploying PHP and avoids like the plague more complex solutions based on Python, Java, and Rubi.

I'd say it's actually the opposite - the users are comfortable with PHP and not the more complex solutions. I'd love for us to support other stuff, but anyone who is using anything else wants more control over their environment than the average shared host can offer. We have as many deployment issues etc. with PHP as we would anything else... possibly more.

That said, isn't 'IaaS' like Heroku basically 'shared hosting for other stuff'?

> but always wonder why shared hosting is often PHP/MySQL only.

It's easy. Compare with trying to track Rails upstream, particularly in the 2.x/3.x days when minor version increments could sometimes see you building a whole new set of ruby binaries compare to what shipped with your base Linux distro.

How often do you hear PHPers handwringing about virtual environments, locking dependencies, and whatnot? Like DOS and Windows, the PHP world has done a pretty good job of making it easy to install PHP, run PHP programs, and not spend hours of your life dinking with mutually-incompatible bits of the stack.

Why would a shared hosting service want the pain of other solutions?

I've studied this one a few times and it's very much a positive feedback loop.

Rewind to 2005: Django and Rails had just been released. PHP had already been out for 10 years and there were dozens of large systems - PostNuke, phpBB, WordPress, Drupal - that were already out there being useful.

For many hosts, their customers wanted to get a blog, forum, etc online quickly and easily. The vast majority were written in PHP, so they set up with PHP by default. Throw in the fact that most of these companies deployed Cpanel (or similar) with one-click installers like Fantastico, etc - which dealt with PHP exclusively iirc - and it was a no-brainer.

The availability of apps drove PHP deployments.

The sheer number of PHP deployments drove the installation of the same apps.

I provide shared hosting for some clients.

The simple answer is that the last time I looked I couldn't find good documentation for getting Python (and Ruby) support working side-by-side with a modern LAMP stack. Most Python (and Ruby) hosting-related documentation assumed nginx, which, while I like it otherwise, still lacked good support for .htaccess files, which are a must-have when providing hosting for people using things like Wordpress and Joomla and Drupal. The documentation that I could find for Apache environments was way, way behind the best practices for a PHP+Apache environment and some of the recommendations were orthogonal to my current environment.

I still would like to provide a hosting environment that can handle a mix of PHP and Python and Ruby, but it's going to be fiddly and involve a lot of trial-and-error and I haven't been able to justify the time sink yet.

Getting suexec + event-mpm + fcgid + PHP opcode caching has been enough of a headache as it is.

Take a look at webfaction. They support apache+php as well as a host of other languages and frameworks (python+django, ruby+rails) by treating them as separate webapp (e.g. each php websites run their own apache instance under local linux user) and uses nginx as reverse proxy in front of those webapps.

>why shared hosting is often PHP/MySQL only

PHP was designed from the ground up to work well on shared hosting with things like restrictions on CPU and memory use so one user wouldn't bring down the others. Here's PHP's inventor explaining:

https://youtu.be/6uodrhwUXFM?t=10m48s

You forgot backwards compatibility. For #3, the large ecosystem didnt grew overnight, it was an accumulation of themes, plugins, and dev hours throughout the years. It was made possible by WP's backwards compatibility.

Reply on news.ycombinator.com