Over the last six months, the Drupal front-end community has had a lot of discussion about how to best use our theme system to work with design components. What would it mean to have a component-based theme system, and why does that matter?

With Drupal 8, we have several major improvements to our theme system.

Before you ask, yes, the image at the beginning of this post is a conductor, not a composer. The open source PHP package management Composer has a conductor as its official logo, and who am I to argue? An image of somebody scribbling away on sheet music may have been less compelling. A harmless sleight of hand.

As I work on more and more Drupal 8 sites, I am becoming convinced that given enough time, nearly all Drupal 8 sites will need to be managed with Composer. I think that's kind of a big deal.

One of the goals I am working on is learning how to write tests for Drupal. I have been collecting resources on how to do so, and I thought others might find these resources useful too.

What do you think about Drupal’s theme system? What’s your preferred way to change the appearance of a Drupal site? As with many things, that depends.

Your background and skills are going to have a big impact on what you need out of a system that helps change the way a Drupal site looks. What works well for me might not work well for you.

Drupal 8 offers big improvements to the front-end development experience. Twig improves working with markup; requiring libraries to declare dependencies allows us to deliver only necessary CSS and JS; and there are now two flavors of markup in core, provided by Classy and Stable. Yet we can still do more to improve front-end development with Drupal. At MidCamp in Chicago, a number of people who work with Drupal discussed some big potential improvements we could work towards, including: