One of the most rewarding things about web development is that it’s always changing. New code specifications, design trends, device capabilities, programming languages, API integrations… Wait, did I say rewarding?

Yes, it can be overwhelming, but for me it is also rewarding. Especially learning new development tools. Like a lot of folks, a few years back I switched my local WordPress development environment from MAMP Pro to Vagrant / VVV. At the time it was the trendy thing to do, and still is I’d presume. Quite a few influential developers were making the switch. My Twitter feed was overflowing with Vagrant awesomeness and tutorials on how to set it up. After (quite a) few initial hiccups, I had a Vagrant environment up and running, with VVV to manage WordPress.

While the initial setup wasn’t as smooth they said it would be, I was very excited to be learning some new tricks, using the command line, and being part of, well, the cool developer crowd. Yes, Vagrant took a long time to launch every morning, and even longer to shut down at night. But hey, it’s the price of progress I thought.

Well, a few months ago I switched back to MAMP Pro. Here’s why.

Matching development and production environments

One of the most compelling arguments for switching to Vagrant is that it allows a developer to set up a virtual environment that matches exactly the final production server configurations. This sounds both reasonable and good. In practice, however, I don’t really need this. And I wasn’t actually using it either.

VVV is a Vagrant configuration specifically designed for WordPress and comes with a default configuration. It also comes with the ability to alter that configuration, but I never took the time to do so. Perhaps I should have, but every WordPress site I’ve built has worked fine no matter what production environment they ended up in. The differences between environments never actually crossed my mind, because it never seemed to actually matter. I still to this day don’t know if a site would run differently on PHP 5.5 vs 5.6. Or what exact version of MySQL. As long as the server is hitting the WordPress minimum requirements, maybe it doesn’t matter.

MAMP doesn’t allow for much configuration either, so perhaps this is a draw. But matching dev environments is the first reason on most Why Vagrant articles, and I just took it away. So, strike 1.

Getting up and running

While most tutorials on how to set up Vagrant / VVV show how clearly easy it is, my experience was anything but… I followed along installing the necessary components and ran my first Vagrant up – and nothing. Tore it all down and tried again – nothing. Tore down and tried a third time –  wha-la – I guess third times are a charm. I’m not sure what went wrong the first couple of tries. Perhaps I’m just an idiot. I’ll admit it was pretty exciting to type that first (successful) Vagrant up in Terminal and see a default WordPress site sitting there. I quickly added Variable VVV and a VVV Dashboard I was off and running with a shiny new development environment.

Too bad it took me heavy parts of multiple days to do so. MAMP is not perfect, and is certainly a PITA to update, but getting it up and running is as easy as 1. Launch the App. 2. Start server. 3. That’s it.

Keeping Vagrant running smoothly

If you talk to a developer who’s used Vagrant long enough, they’ll tell you a time or two they’ve screwed it up somehow. I certainly did that a bit in the beginning, without knowing what or why. Some mornings Vagrant simply wouldn’t load, or I’d get an SSH timeout error. Without knowing exactly what I was doing, I’d try reprovisioning, or halting and restarting, and sometimes re-installing the entire thing. The hours of lost time trying to troubleshoot were astounding, even for someone who loves to waste time troubleshooting. I should have been getting real work done.

I was finally able to get reliable, steady production out of Vagrant after getting a new 5K iMac and installing everything from scratch. There was clearly some configuration or setting on the old computer that was mucking up Vagrant. From then on Vagrant was thankfully very stable. So kudos to nearly two years of Vagrant smoothness. And also kudos to MAMP, because I’ve never screwed it up.

Vagrant performance

For the most part, the speed of Vagrant was okay. Not great but it didn’t suck either. Except for the days that it did. I still don’t know why, but every now and again page load speeds would just drop, making development nearly impossible. If you Google the keywords Vagrant slow you see the first article is titled How to make Vagrant performance not suck. I tried following along but that article is clearly a notch or two above my pay grade. Nothing I did seemed to change the performance on these days and I just ended up dealing with it.

Since Vagrant is a virtual machine, it can only use as much resources as you give it. And perhaps it’s my bad that I didn’t provision more, but what ever the default amount of RAM and CPU was given is what it uses. I may be mistaken, but MAMP might have the entire cadre of resources my machine has at its disposal. I’ll say that I’ve never run into a performance is

vagrant up / vagrant halt

The other speed issue has to do with getting going in the morning, and shutting down at night. I suspect the slow startup and shutdown procedures has to do with the number of sites I had added to the box (20 or so). vagrant halt normally takes 4-5 minutes to run. I shut down every day, and never liked turning off the computer without first shutting down Vagrant. Maybe it doesn’t matter, but on the days I was running out late those 4 minutes seem like forever. MAMP shuts down with ⌘-q

My a-ha moment

I’d still be using my Vagrant development environment today if I hadn’t attended WordCamp SLC this year. Chris Reynolds of WebDev Studios gave a talk titled Building WordPress for Enterprise Clients (or How I Learned to Stop Worrying and Deal With My Imposter Syndrome). Amongst a ton of great information about how he goes about his work, he lightly mentioned how he’d gone back to using MAMP Pro again for development. He summed it up with the following slide:

I don’t know Greg Rickaby but I could see the wisdom in his words. I went to work the next day and dusted off my old copy of MAMP. Then upgraded to Version 5.

Conclusion

In the end, I’m glad I learned how to use Vagrant. It served me well for over two years. Yes it has it’s issues and took up too much of my time. Yes it’s still cool and yes it’s still fun to run vagrant up. Is MAMP perfect? No. I really (really) wish they’d figure out how to upgrade the app with single click. But it fires up quickly, is reliable, and performs really well.

But maybe I should be looking at Docker.