Poll Results: Local WordPress Development
We kicked a poll off three months ago asking y’all what kind of local development environment you set up for running WordPress locally. At the time of this writing, we got 2,623 votes, so a decent amount of significance here. Especially because the question was phrased:
If you’re running WordPress locally (i.e running PHP, MySQL, and a web server), how are you doing it?
Presupposes that you are running a local environment. (Please do that.)
Here’s an image of the results:
(If you can’t see that, don’t worry, we’re about to go through the results.)
The winner, at 61%, was using some kind of software-with-a-UI to manage it. WAMP / MAMP / AMPPS were mentioned, but it also said “Similar software with UI”, which I think is relevant as we’ll see in a second. This option was more than 3 times more popular than any other choice.
In third place was installing things directly at 13%. All these other options take at least some kind of stab at isolating the dependencies of local development. Meaning if you have multiple local development environments (very common), they don’t all need to share the same dependencies. This could be relevant even if you do all WordPress development. Perhaps one project is running PHP 7 and MySQL 5.7, but another is on some older hosting is at PHP 5.3 and MySQL 4. Matching those production versions in development is a good idea, so you can have some confidence what you do locally will work on production. Without any local isolation, you’re stuck with the same versions of everything across development environments. Might be just fine if you only work on one thing!
Docker was the penultimate choice at 7%. As hip as Docker seems to be, apparently it’s adoption amongst WordPress folks hasn’t caught on super strongly yet.
Gilbert Pellegrom has a great comparison of Vagrant and Docker:
The downside to [Vagrant] is that each virtual machine includes not only your application and all of its libraries but the entire guest operating system as well, which may well be tens of GBs in size.
Docker, however, uses “containers” which include your application and all of its dependencies, but share the kernel (operating system) with other containers. Containers run as isolated processes on the host operating system but are not tied to any specific infrastructure (they can run on any computer).
What is the upshot of all of this?
- Vagrant is easier to understand and is easier to get up and running but can be very resource-intensive (in terms of RAM and space).
- Docker’s architecture is harder to understand and can be harder to get up and running but is much faster, uses much less CPU and RAM and potentially uses much less space than Vagrant VM’s.
As a personal anecdote, I’m using Docker for all my WordPress stuff now (on my Mac), and didn’t find it particularly hard to set up or understand. One thing that bit me was not putting my MySQL stuff on a “volume” at first, which made the database susceptible to being wiped out when Docker rebuilt the container (but I have that fixed). I just followed this.
5% of folks voted “Other” and were asked to chime in in the comments. There were 63 comments, which is quite few for a CSS-Tricks post these days!
22 comments mentioned Laravel Valet, so I think that deserves and extra-special shout-out here.
Valet is a Laravel development environment for Mac minimalists. No Vagrant, no `/etc/hosts` file. You can even share your sites publicly using local tunnels…
Laravel Valet configures your Mac to always run Nginx in the background when your machine starts. Then, using DnsMasq, Valet proxies all requests on the *.dev domain to point to sites installed on your local machine.
In other words, a blazing fast Laravel development environment that uses roughly 7 MB of RAM.
There were also 8 mentions for Local by Flywheel (Mac and Windows), which looks like a nice UI for managing local WordPress development environments:
If you use Valet or Local, you could have either voted in the “Similar Software with UI” category or “Other” category, so in the grand tradition of CSS-Tricks polls, the data is a bit loose.