Today at DrupalCon we had the infamous Driesnote. The tone of the Driesnote focused on what we, as a project, should strategically focus on while building features on the Drupal 10.x.x branch. Dries wants to bring Drupal back to its roots by focusing on the site builder audience. This includes automatic updates, the project browser, and reimagining distributions as composable starter kits. This blog is an extension of a tweet I made at lunch, before catching my airplane home.
Update: the recording has now been uploaded: https://youtu.be/Ig676RzJbLo
Note: Dries has not yet published the slides on his website and I didn’t grab any pictures of the slides from my phone. I am sure you can find many on Twitter, though.
I like that the new Drupal strategic initiatives will focus on the end-users who build and compose Drupal sites. Drupal is an interesting project. It is a hybrid of:
- developer framework, which empowers developers to build solutions
- software-as-a-service platform, which empowers non-developers to build solutions.
There have been so many times I picked up Laravel or Symfony to build a little project and reverted to Drupal because…
- It has amazing role-based access control (RBAC) that I don’t have to rebuild
- It provides a backend administrative interface out of the box
- The Typed Data API + Serialization + Symfony Validator is a great hidden secret in the developer toolbox
- JSON:API in Drupal core is 🤌
However, I hope we also focus on the developer experience for backend developers as well. It’s not bad but Drupal also has the ability to shine as a framework. I will also admit that it is hard to make that a marketable strategic initiative since it’s nearly impossible to quantify. What kind of object key results can we extrapolate to define “success” on developer experience? You can’t. But you can verify a better end-user experience.
The developer experience is mediocre in Drupal, in my honest opinion. We could do more to make an elegant developer experience in Drupal. And, honestly, this lies at the feet of developers like myself who hoard little helpers and don’t provide patches to Drupal core. I know we have quite a lot of goodies accumulated in the Commerce module and Entity API module which haven’t bubbled to Drupal core yet. Are the Drupal core committers willing to accept these items? I don’t know. They are very busy with landing required work for strategic initiatives and other deadlines.
I hope we the focus that each improvement is improving Drupal’s core APIs. It should also lend to an elegant developer experience. It should fix the problems we had to quickly dance around years ago.
We need to make writing Drupal code fun and exciting. It is right now, but I think we could do more. Remember when bundle classes landed in Drupal core? There was a bunch of hype. Because it improves the life of the developers building with Drupal. I don’t have a lot of time to contribute to Drupal core. But I know I will begin opening issues and advocating for developer experience improvements as I encounter them.