Hi @daniel,
Thanks for this post. You bring up a lot of great points that we routinely think about when making up the product backlog for Local.
Aside from the Lightning Public Beta release post, I haven’t personally touched on the reasoning behind Lightning a whole lot so I’ll take this as an opportunity to provide a deeper look into our thought-process:
Local’s core selling point since the beginning was its ability to select different PHP versions, MySQL versions, and web servers with a few clicks of the mouse. This was largely afforded by deciding to leverage Docker (specifically boot2docker) in the beginning. In fact, when I first built Pressmatic, I made sure to include this functionality so I could test various PHP versions out with a theme I worked on.
However, getting VirtualBox to work on hundreds of thousands of users’ devices proved itself to be extremely challenging. To even run VirtualBox, you have to have a device that supports virtualization. Not only that, if you’re on Windows, you can’t have Hyper-V enabled. Apple also threw a few curveballs our way, such as the Kernel Extension approval flow in High Sierra and then really locking things down with Notarization in Catalina. Long story short, our analytics proved that successful installation rates with VirtualBox were not where we had hoped.
Installation issues aside, there are issues with performance. A quick search for “slow” or “performance” here on the forums will yield a plethora of topics. We tried to mitigate these performance issues with the addition of Faster Docker Volumes, but even FDV didn’t provide the native-level performance we were seeking.
We did consider the possibility of using Docker Desktop (Docker for Mac/Windows). However, we dismissed it for a few key reasons: the inability to maintain Local as a single installer, performance, and virtualization requirements.
So, considering all of this and seeing the rising popularity of things like Laravel’s Valet, it became clear that people ultimately valued a performant, lightweight solution. This meant one thing: native processes.
We started Lightning testing in early 2019 to see if this ambitious idea could even work as a replacement for Docker in the Local we all know and love. The testing and proof of concepts turned out great, so we knew that building out Lightning was the next step for us.
It’s important to note that Lightning was a result of the challenges and limitations listed above and not a result of the WP Engine acquisition. Lightning was already in the works months before the acquisition. WP Engine very much believes in the Local Team and what Local is and always has been: a powerful, easy-to-use local development tool for building WordPress sites.
Fast-forwarding to the launch of Lightning as a “Public Beta,” this decision was primarily driven by a dramatic uptick in installation issues with VirtualBox and stability issues with the VirtualBox VM. It became clear that Lightning—even in its early state was already a superior user experience to Local Classic.
I will be the first to admit that this did create a considerable amount of confusion. Still, we ultimately wanted new users (and old) to get the best Local experience possible rather than us holding it back.
In the announcement post of the Lightning Public Beta, we acknowledged and promised the return of the missing features such as a one-click Adminer button, selecting PHP/MySQL versions, and choosing between Nginx/Apache. The one-click Adminer button made its return fairly quickly, and we remained committed to bringing back the Custom environment, which is now available in Local Beta 5.2.0.
We’re on track to releasing 5.2 to all Lightning users either later this month or in early February. With that, Lightning will officially be going stable and have its “Public Beta” label dropped.
Now, it is important to note that Lightning is not a silver bullet to everything. We know there are limitations in terms of using ancient versions of PHP, such as PHP 5.2 and adding services like Redis, Elasticsearch, etc. We have integrations with Docker Compose planned out in 2020 to solve for trickier setups, which we firmly believe will make Local more flexible than it has ever been.
To quickly touch on Local Pro and Teams (@flyjack can maybe share some more info here), we are ramping up efforts here and have started the process of building out a dedicated team to focus on Local Pro and Teams.
So, if I can try to sum this all up into a few key points:
- Local Lightning is the future of Local for three primary reasons: more accessible installation, performance, and stability.
- We will always remain committed to making the best local WordPress development tool. Things like Xdebug will always be top-of-mind for us.
- Local Pro and Teams have a dedicated team as of early 2020. Expect to see some amazing things there!
- WP Engine believes in the Local Team and Local! They (we!) are as committed as ever to making the local WordPress development experience the best it can be with Local. WP Engine helped us grow the Local team in Q4, and we’re excited about what this new capacity means for our roadmap!
- We will have a Docker Compose integration in 2020. Expect to have native disk performance with PHP while being able to add additional services like Redis!
- We are working diligently to bring back functionality from Local Classic to Local Lightning.