A multitude of recent developments have aided me to make a choice. Some of them are

• Apple going for thinner, lighter instead of stronger performance, and
• Microsoft integrating Bash into Windows 10 with WSL (Windows Subsystem for Linux)

While the new Macbook Pro is quite a feet of engineering, it is hardly “Pro”. Surely intel graphics are enough for typing letters and calculating spreadsheets, it’s not Pro. A 16GB memory limit (which with the compression tech used is like 24GB for any other OS) is great for battery life, but it’s not “Pro”. The keyboard is ultra thin and has good tactile feedback, but the keys need a firm press, and travel almost nothing. Great for thinning the device, but again, not “Pro”. For the same amount of money you can buy a portable powerhouse like the Asus ROG G752vy (seen in my post about this). This one has other issues, but at least it has got awesome graphics (nVidia 980), max 64 GB RAM and a “normal” laptop keyboard.

(Yeah, I know, I KNOW, I don’t need ‘awesome graphics’ for web development, but I like to game also, and to be honest; my favorite IDE – phpStorm – DOES prefer a sturdy GPU. Don’t know why, but it runs so much better on a discrete GPU than it does on intel Graphics)

Reasons to stay with macOS are rapidly diminishing, and reasons to start using Windows again are gaining support. Since the Windows 10 Anniversary Update, Windows offers Bash and all goodness that comes with Ubuntu linux, right at your fingertips. Well, not ALL goodness, but most of it.

I still dislike windows, but unless Tim Cook gets a bonk on the head and starts to rethink his decisions, I probably will not be developing on a Mac for much longer. The 2010 MacBook pro is running on it’s last legs, the 2011 iMac is in urgent need of replacement. The new iMac’s are slow, unless one buys the biggest, largest, most expensive version, and the MacBook Pros, well, we’ve discussed that. MacPro? Don’t get me started. Mac mini then? with Intel Iris Graphics, 16GB RAM limit? No thank you!

This is becoming a rant… Sorry! :) Back to the topic at hand.

Recently a pre-existing piece of software emerged from relative obscurity (emphasis on ‘relative’) which is pushing me a fair distance toward a switch back to Windows.
This software I’m talking about is re-branded and now free, and soon(-ish) available for Windows; I’m talking about

From here, Local with capital L is Local (by Flywheel). I will not repeat the ‘by Flywheel’ part. I originally did repeat it, but it was a bit much :P. This post is long enough without it :).

In earlier posts, starting with this one, a long journey is documented to create a fully functional development environment and an as-universal-as-possible script to maintain it, leaving you, the developer, with nothing to do other than

1. Create a project directory
2. run the script.

The script here being the RBA.sh script which, in a nutshell generate VirtualHost entries for Apache2 and set the domain/ip relation in the hosts file.

Now, this last part is something that is troublesome under WSL. Let me elaborate; WSL is Linux on Windows. While Microsoft keeps telling it is not a virtual machine (and that is correct), the integration is less than perfect; you, the Bash user, are still boxed in.

• sudo in Bash will not elevate you to system-admin, just Bash superuser. Running the bash prompt as Administrator allows you to edit windows system files from Bash, but makes the Bash-user a Windows-system-admin without the protection that Bash provides.
• There is no GUI support in WSL; only command-line is available
• There is no chaining of Windows software to Linux software and vice-versa (which in macOS is not a problem AT ALL)
• The Windows hosts file (c:\Windows\System32\Drivers\Etc\hosts) is NOT used by Bash on Windows. The Bash hosts file (/etc/hosts) is NOT used in Windows.

How is this last item important? well, in macOS, writing to /etc/hosts as super-user works perfectly, for command-line tools as well as the macOS GUI apps. In Windows with WSL, two files need to be maintained; /etc/hosts and c:\Windows\System32\Drivers\etc\hosts. Sym-linking or hardlinking from Windows to Bash or the other way round just gets you in a heap of troubles, up to a point that Bash on Windows will not start-up anymore. RBA can write to the Windows file if Bash is ran elevated as Administrator but that would compromise security. Microsoft suggested using a third-party file-sync application… Right… Moving on!

In comes Local;

While there is not yet a Windows version, it has been announced, so going ahead with this, Local will solve some issues.

1. I won’t be needing RBA.sh anymore. Local will handle all configuration for me, and better! (see below)
2. I won’t be limited by Bash-on-Windows-limitations because of this. Sure, it does not solve the hostname-in-windows-hosts-file-resolution-from-within-bash-on-windows-problem (boy, this must be hard to read :P), but it probably won’t use WSL anyways and go with the VirtualBox/Docker/Debian combo.
   While the Debian environment provided by Local has the approximately-same limitations of Bash on Windows; both being a separate environment, Local does solve one issue; I can reach the website from Windows and from Bash, because Local maintains ALL relevant hosts files. Both in the host and guest OS.

Man, all this introduction just to get to the good part. Remind me to make a TL:DR; link at the top ;). Moving on!

Local (by Flywheel)

Local is based on/makes use of a number of other open-source projects;

• Virtual Box
• Debian linux
• Docker

Local creates containers for every web-project, giving you an isolated system based on

• Apache2 or nginx
• PHP version 5.2, 5.3, 5.6 or 7.0
• MySQL 5.5 or 5.6

It’s your choice!

Local also allows you to

• Create a demo link so you can share your local development site temporarily, using another piece of open-source software: ngrok. With a secure tunnel toward your machine, your client, or remote co-worker can see your work, even though you are behind one, two, maybe 3 firewalls :)
• SSH into the virtual machine with a few clicks (two, to be exact), never knowing – or needing – the password. You are root :)
• Pre-install WordPress, even generate config files and the first (admin) user, giving you a very easy and fast startup of a new WordPress project. WordPress was the main reason for PressMatic, but maybe, one day, we can choose a different CMS or framework. WordPress is not obligatory though, Local can be used for any LAMP-based project.
• distill a template from an installation, allowing you to create a default installation with, for example, your favorite plugins and themes pre-installed and configured.

How does this compare with my own and other tools?

	macOS + rba.sh	Local	XAMPP/WAMPP
Apache2	macOS built in	debian package	included, one version for all projects.
nginx	not easily available	debian package	nope
MySQL 5.5	via Brew or macPorts, (or MariaDB)	debian package	included (MariaDB)
MySQL 5.6	either 5.5 or 5.6	every project has own version	nope
PHP	built in or Brew, one version as mod_php, one as FPM – if you can get it running!	any version for any given project (as far as I can tell, always as FPM)	multiple versions included, one version selection for all projects.
domain name handling in /etc/hosts/	yes	yes	nope, use VirtualHostX or similar*
SSL	yes, but self created and self-signed === warnings	yes, self signed, with single click “trust”; no more warnings	probably… sorry, don’t know. Would be bad if ‘no’.

*) VirtualHostX was one of the reasons I started developing the RBA script…

How about the other stuff?

Tool	macOS + rba.sh	Local	XAMPP/WAMPP
SequelPro (macOS)	use local connection	single click starts a tunnel and opens the database	use local connection
adminer.php	install yourself	single click install-and-use	install yourself
E-mail	if configured properly	mailcatcher available with single click	if configured properly
xdebug	via Brew/macPorts, configure yourself	available with single click	with help from Google
mcrypt	not easy, see this post(link)	installed	unknown. probably ;)

Seems to me, Local has got you covered! Everything you really need is included in and handled by Local. All projects are nice and isolated, have their own unique configuration. It’s bliss.

Well, ok, it’s not perfect, some things I/we have been doing with the posts here cannot yet be done with Local;

What is not (yet) possible in Local?

The following are not presently available through Local and I have yet to find out how to install them;

• MongoDB
• MemCache

Shouldn’t be too hard, something like

1. Click to SSH into the project
2. type something like
   Shell commandapt-get install mongodb memcached

Again; haven’t tried it yet.

Also, I have yet to try

• FTP to the box (we need to test FTP-features of some of our projects)
• git/svn (again; some of our projects do this from WordPress :P)

Good thing though; there is a great support forum for Local with the option to request features, on which other users can vote. And -- presumably -- the features with high votes will get implemented, if possible.

Will this be the end of the long-running series of blogposts about setting up and maintaining a local development environment on macOS?

Yes it probably will! And that’s a good thing! With Local your development environment…

• is clean
• is portable (possibly cross platform, but that has to be (dis-)proven at a later date)
• can be cloned through templating an existing configuration
• is not restricted to the max number of open files (google: osx Too many files open)
• is as flexible as can be
• will survive a system upgrade
• can support old web-software without impact on your other projects (we all have that one project that only runs on php 5.2, right?)
• allows you to experiment with new software without interrupting your work on other projects
• allows you to try a different PHP or MySQL version (or even a switch to nginx) and switch back if it fails, all without ever touching a single config file.

Is Local perfect? no. I did find a few bugs, but have yet to check if they have been reported already, but the ones I found are minor at the most. Also there are some restrictions that stop me from a mass-convert of all my projects to Local, but that too is a minor inconvenience; you cannot use /Development as basis. You can set it… but you cannot use it, (That’s both a restriction and a bug :) ), you can only use a /Users/<username>/… or a /Volumes/<volume name>/… path.

So I can honoustly -- and hastily* -- say; there really is no reason not to start using Local, unless you really really REALLY need MongoDB or MemCache for all your projects.

*) Hastily, you say? Well, yes; I got so excited about Local that I did not take the time to try out every other alternative, or take screenshots/-casts, or check the support forum for already listed/announced/solved bugs etc. Local is more than good enough as it is. So; go get it, NOW! Yes NOW! Don’t stick around here, GO! Download! NOW! Shoo! If you want you can hate me later, but you won’t want to, I promise.

Happy coding!