At DrupalCon Nashville 2018, I became deeply interested in the realm of first-time Drupal experiences, specifically around technical evaluation, and how people would get their feet wet with Drupal. There were two great BoFs related to the topic which I attended, and which I hope will bear some fruits over the next year in making Drupal easier for newcomers:
There are a number of different tools people can use to run a new Drupal installation, but documentation and ease of use for beginners is all over the place. The intention of this project is to highlight the most stable, simple, and popular ways to get a Drupal site installed and running for testing or site building, and measure a few benchmarks to help determine which one(s) might be best for Drupal newcomers.
For reference, here's a spreadsheet I maintain of all the community-maintained local Drupal development environment tools I've heard of.
Throughout the week at DrupalCon, I've been adding automated scripts to build new Drupal environments, seeing what makes different development tools like Lando, Drupal VM, Docksal, DDEV, SimplyTest.me, and even Drupal core (using code from the active issue Provide a single command to install and run Drupal) tick. And now I've compiled some benchmark data to help give an overview of what's involved with the different tools, for someone who's never used the tool (or Drupal) before.
All the code for these benchmarks is available under an open source license in the Drupal, the Fastest project on GitHub.
Time to Drupal
One of my favorite metrics is "time to Drupal": basically, how long does it take, at minimum, for someone who just discovered a new tool to install a new Drupal website and have it running (front page accessible via the browser) locally?
drupal quick-start command that will be included with Drupal core once this patch is merged is by far the fastest way to go from "I don't have any local Drupal environment" to "I'm running Drupal and can start playing around with a fresh new site." And being that it's included with Drupal core (and doesn't even require something like Drush to run), I think it will become the most widely used way to quickly test out and even build simple Drupal sites, just because it's easy and fast!
drupal quick-start environment doesn't have much in the way of extra tools, like an email catching system (to prevent your local environment from accidentally sending emails to people), a debugger (like XDebug), a code profiler (like Blackfire or Tideways), etc. So most people, once they get into more advanced usage, would prefer a more fully-featured local environment.
There's an obvious trend in this graph: Docker-based environments are generally faster to get up and running than a Vagrant-based environment like Drupal VM, mostly because the Docker environments use pre-compiled/pre-installed Docker images, instead of installing and configuring everything (like PHP, MySQL, and the like) inside an empty VirtualBox VM.
Now, 'time to Drupal' isn't the only metric you should care about—there are some good reasons people may choose something like Drupal VM over a Docker-based tool—but it is helpful to know that some tools are more than twice as fast as others when it comes to getting Drupal up and running.
Another important aspect of choosing one of these tools is realizing what you will need to have installed on your Computer to make that tool work. All options require you to have something installed, whether it be just PHP and Composer, or a virtualization environment like VirtualBox or Docker.
Almost all Drupal local development environment tools are settling on either requiring Docker CE, or requiring Vagrant and VirtualBox. The two exceptions here are:
- SimplyTest.me runs in the cloud, so it doesn't require any dependencies locally. But you can't run the site you create in SimplyTest.me locally either, so that's kind of a moot point!
quick-startcommand requires PHP and Composer, which in some sense are less heavyweight to install locally (than Docker or VirtualBox)—but in another sense can be a little more brittle (e.g. you can only easily install and one version of PHP at a time—a limitation you can bypass easily by having multiple PHP Docker or VM environments).
Overall, though, the number of required dependencies shouldn't turn you off from any one of these tools, unless there are corporate policies that restrict you from installing certain software on your workstation. Docker, VirtualBox, PHP, Composer, Git and the like are pretty common tools for any developer to have running and updated on their computer.
Number of setup steps
While the raw number of steps involved in setting up a local environment is not a perfect proxy for how complex it is to use, it can be frustrating when it takes many commands just to get a new thing working. Consider, for example, most Node.js projects: you usually
git clone a project, then run
npm install, and
npm start. The fewer steps involved, the less can go wrong!
The number of individual steps required for each environment varies pretty wildly, and some tools are a little easier to start using than others; whereas Drupal VM relies only on
vagrant, and doesn't require any custom command line utility or setup to get started, tools like Lando (
lando), Docksal (
fin), and DDEV (
ddev) each require a couple extra steps to first add a CLI helper utility, then to initialize the overall Docker-based environment—then your project runs inside the environment.
In reality, the tradeoff is that since Docker doesn't include as many frills and plugins as something like Vagrant, Docker-based environments usually require some form of wrapper or helper tool to make managing multiple environments easier (setting up DNS, hostnames, http proxy containers and the like).
In the end, these particular benchmarks don't paint a perfect picture of why any individual developer should choose one local development environment over another. All the environments tested have their strengths and weaknesses, and it's best to try one or two of the popular tools before you settle on one for your project.
But I'm most excited for the new
drupal quick-start command that is going to be in core soon—it will make it a lot faster and easier to do something like clone drupal and test a core patch or new module locally within a minute or two, tops! It's not a feature-filled local development environment, but it's fast, it only requires people have PHP (and maybe Composer or Git) installed, and it works great on Mac, Windows (7, 8, or 10!), and Linux.
Hello! Awesome report, I love performance tests that take a creative or different approach. I understand you might have reservations about throwing commercial brands into the mix here but actually engineered a system that keeps fresh installations ready for testing that beats simplytest time-to-drupal by about 1000% :) you can check it out on trysooperthemes.com
Of course simplytest is better in other ways, it will attempt any installation profile you throw at it. My server simpy keeps a reserve of installations on standby for you to be logged in on.
Great Blogpost. I like the motivational approach.
Quick comment: I think first time users don't need composer either as they would use just the tarball and the php script.
You list Acquia Dev Desktop in the spreadsheet, though not in the post. I continue to find it incredibly convenient and I'm surprised more people don't use it. Dev Desktop was how I tried Drupal for the very first time and it's usually my choice if I need to look something in core, or a module - and I can either tell it to download Drupal for me, or download the dev branch from Git and then use Dev Desktop to setup a DB on top. I'd still use DrupalVM or ansible playbooks of my own for proper dev sites where the config needs to match production, but Dev Desktop is handy when you want to quickly experiment with content types or blocks. The only pain is having to run the setup process manually and fill out the details for user 1...
Good point, but Acquia Dev Desktop isn't scriptable/automatable in a cloud testing environment, so it's really hard to run reliable, consistent, automated benchmarks against it :(
I will add, I've been using Lando for the past few days and am finding it fast and very convenient. Though whether I'd recommend it to brand new users, or use it over DrupalVM for anything more complicated than a LAMP/LEMP stack, I'm not sure.
I noticed you didn't include Wodby's docker4drupal and I am just wondering, "Why?" The "vanilla Drupal" site setup is pretty simple although the documentation could definitely be better if there was a separate page for beginners imo.
Download files (git clone or download zip)
Edit /etc/hosts file (might not even be needed for Chrome)
cli from your chosen docroot $> docker-compose up -d
One question: "Who are these really targeting?" My feeling is that you want to give a site builder/junior developer or above the ability to try Drupal this gives them all the tools they could ever want to grow to the nth degree. In my experience too many people get hamstrung by their setup, struggling through devops limitations of a setup they chose out of recommended "ease". When they really want to take their skills up a single use the tools. They might end up down the rabbit hole of configuration and get a lost but a lot of that is solved by documentation and people contributing to a community, not to mention it is how you learn.
If you are simply introducing a non-technical person who has no interest in understanding Drupal then they are, imho, probably better off spinning up something on the cloud where they can get support.
Drupal is not and won't ever be the best solution for a brochure site that can be handled by some cheap service. It is however, the best solution for people who need more than that. Docker4Drupal is on the other hand arguably the best of the current lot for intermediate to advanced users and CI/CD pipeline integration. With some community contribution or even perhaps a fork it might become the best for noobs as well.