Preface

The purpose of this blog post is intended to be a comprehensive analysis and response to:#2289619: [meta] Add a new framework base theme to Drupal core; to encapsulate how I believe core should move forward with a default theme. For brevity, the term "framework" in this post will always refer to "front end framework".

The Problem

Core has always provided its own themes, however the benefit of sustaining this model is becoming increasingly difficult to justify.

Fast Moving Front End Technologies

In regards to the front end, core has historically been more reactive than proactive. This isn’t all that surprising, nor a bad approach, when you take into account what core originally had to deal with.

Now consider for a moment, all the different technologies and techniques that are used on the front end today and compare that with when Bartik was created ~6 years ago. Things have changed rather drastically with the advent of Responsive Web Design, HTML5 and CSS preprocessors like SASS and LESS.

Web Components are possibly the next major milestone in front end development with an impact potentially just as large, if not larger, than that of HTML5 and Responsive Web Design. While the concept isn't necessarily new (frameworks have had "components" for years), it is definitely being sought to become a "web standard" with Google leading the way. Web Components are an encapsulation of multiple front end technologies supported directly by the browser. This could also likely be the future of what we now consider "frameworks" today: a consolidation of web components. Perhaps the web as a whole, only time can tell.

Video:2015 DrupalCon Los Angeles Session: Drupal 9 Components Library: The next theme system

The 1% of the 1%

Generally known as the 1% rule, only ~1% of any given internet community is responsible for creation. In regards to Drupal, this figure is actually even more drastic with only about 0.02% that are core developers.

This fact is what makes core developers a "rare commodity". I would, however, like to take this a step further. Of that 0.02%, how many of those core developers are front end developers? I’m sure no one knows the exact ratio, but it is commonly accepted that core front end developers are an even "rarer commodity".

Back end developers are the majority. They have little to no interest in current front end technologies, techniques or "Best Practices™". I'm not discounting the fact that there are back end developers that cross over or vice versa, but there are just a handful of "unicorns" .

Without enough of a front end ratio in core development, it is impractical and unfair for everyone involved to expect any sort of "solid theme" from core. It is because of this fact that not having an external framework is actually hurting us from a community, development and maintainability standpoint.

"Getting off the Island"

Core has already adopted the "Proudly Found Elsewhere" mentality for a lot of its back end architecture. The benefits that this approach has brought to our community has proven predominantly fruitful. The front end should be no different.

Core really hasn't accepted this direction for front end themes, but doing so would allow core development to focus solely on the integration of an external framework. This would reduce a lot of the technical debt required to sustain the design and implementation of CSS and JS in a core theme.

Video:Keynote: Angela Byron — Drupal 8: A Story of Growing Up and Getting Off the Island — php[world] 2014

Automated testing

While the automated testing infrastructure (DrupalCI) is definitely improving, it is still primarily focused on the back end side of things.

Core has wonderful unit testing. These unit tests include and ensure that a theme can implement the necessary hooks available to it via the theme system APIs. It is also great at ensuring that a theme's markup is correctly generated.

However, that is where the benefits of automated testing of core themes ends. Any patch that affects CSS or JS must undergo a very manual process which requires contributors to physically apply patches and "test" changes in multiple browsers. This often results in bucket loads of before and after screenshots on an issue. This is hardly ideal.

The reason many front end oriented projects live on GitHub is because of their ability to integrate amazing automated tests through tools like Travis CI and Sauce Labs. Being on GitHub allows front end projects to rigorously test around the specific areas for which their technologies implement and leads to the stability of their codebase.

Perhaps one day the core and contrib themes could leverage the same type of abilities on drupal.org, perhaps not.

Regardless, testing is just as paramount to the front end as it is for the back end.

Unless the testing infrastructure is willing to entertain the possibility of theme-based CSS and JS testing, an external framework is really our only alternative for stable front end code. At the very least, implementing an external framework allows us to defer this decision.

Popular Drupal-grown base themes

There will always be use cases for the popular Drupal-grown base themes. It really just depends on the project and capabilities of a front end developer. There's nothing wrong with them and I have used them all. They are without a doubt a very powerful and necessary part of our ecosystem.

There is often a lot of misunderstanding around what these base themes actually are, though. Many of them started out simply as a way to "reset" core. Over time, many have added structural components (grid systems), useful UI toggle and other tools. However, the foundation for many of them is simply to provide a starting point to create a completely custom sub-theme. Intended or not, they are essentially by front end Drupal developers for front end Drupal developers.

The priority for these base themes is not "out-of-the-box" visual consumption, but rather providing a blank canvas supported by a well groomed toolset. It is because of this "bare nature" that they can actually become more of an obstacle than a benefit for most. They essentially require an individual to possess knowledge of CSS or more, to get even the most basic of themes up and running.

Their target audience is not the other 99.9998% and not viable for core.

The Solution

Due to the complexity of the theme system, the work with Twig has been a daunting task. This alone has pushed a lot of what we thought we would "get to" into even later stages. I propose that the next stage for a default core theme is to think long term: adoption of an external framework.

Proudly Found Elsewhere

Core cannot continue to support in-house theme development, at least until there is a higher ratio of core front end developers. External frameworks live outside of Drupal and helps ensure fewer "Drupalisms" are added to our codebase. It also allows Drupal to engage more with the front end community on a level it never has before.

Vast and Thriving Ecosystems

Because frameworks typically live outside of larger projects, they usually have a vast and thriving ecosystem of their own. These often produce a flurry of additional and invaluable resources like: documentation, blog posts, in-depth how-to articles, specific Q&A sites, support sites, template sites, forums, custom plugins/enhancements. Drupal would instantly benefit from these existing resources and allow our community to offset some of the learning curves.

Back end developer friendly

These resources also allow a back end developer to focus more on how to implement existing patterns than worrying about having to create new ones. This would allow core developers to focus solely on the theme system itself and providing the necessary APIs for theme integration, rather than the more complicated front end CSS or JS implementations.

Why Bootstrap?

There are many frameworks out there and, quite frankly, attempting to find the one that is "better" than the other is futile; frameworks are simply opinionated "standards". You may agree with one’s opinion or you may not. It does not change the fact that they all work.

The question that remains is: Which framework do we put in in core?

I strongly believe that it should be Bootstrap. A lot of individuals, including myself, have already put in a great deal of time and effort in contrib to solve this exact issue: how to use an external framework with Drupal.

Another advantage of using Bootstrap is that it is already backed by a massive external community.

The main strength of Bootstrap is its huge popularity. Technically, it’s not necessarily better than the others in the list, but it offers many more resources (articles and tutorials, third-party plug-ins and extensions, theme builders, and so on) than the other four frameworks combined. In short, Bootstrap is everywhere. And this is the main reason people continue to choose it.
Ivaylo Gerchev

In just two and half years, the Drupal Bootstrap base theme has grown exponentially at a whopping 2596.67% (based on 7.x installs from: 1,070 on January 6, 2013 to: 70,531 on July 12, 2015*) and has become the third top most installed Drupal theme on drupal.org.*Note: I have chosen to exclude the past two weeks of statistics as I believe they are in error due to #2509574: Project usage stats have probably gone bad (again).

While I cannot attest to the exact reason this rapid adoption has occurred, here is an educated guess: it's what the people want. I purposefully made something that was easy to install and worked right "out-of-the-box". Ensuring that the focus of the project was on the other 99.9998%.

No other Drupal project that implements an external framework can claim this or even come close to it.

Ease of use is paramount and often overlooked by developers. This "philosophy" is what has allowed sites like Dreditor to be born and this one, Drupal Watchdog, to be redesigned given some rather severe time constraints.

Conclusion: Drupal 8, 9, 10...

Adopting an external framework is just the logical next step in core's "Proudly Found Elsewhere" mission on the front end. Regardless of which framework is ultimately chosen, I think it is more important to see why Drupal needs an external framework.

We already have too many issues and tempers flaring around even the smallest of details on the front end. By outsourcing a theme's design (CSS & JS), we would allow our community to instead focus on the integrations of themes, like the future of components and much larger issues.

While this issue isn't about trying to add a framework to core just yet, I think it is very important to have this discussion early on. I do think that ultimately, a framework based theme in core should replace Bartik, but that won't and should not happen until D9.

Since adding an external framework base theme would be purely an API addition, there isn't anything that would prevent us from adding it in an 8.Y.0 release (solely opt-in, of course). In fact, I would strongly recommend that we add one before D9 so we can smooth out any remaining details before tackling something as gigantic as #1843798: [meta] Refactor Render API to be OO.

I have a feeling that D9 will be "the year(s) of the front end". While yes, Twig is awesome, the fact remains that the underlying theme system (and default theme) itself hasn't changed all that much and needs some serious tough love.

I believe integrating an external framework is an excellent way for us to, not only reduce both our technical debt and maintenance burden, but also focus how we should be developing our theme system. We have an opportunity to transform the first visual impression of Drupal.

Let's do it for the 99.9998%.

Tags: 
Drupal 8 Drupal 9 Proudly Found Elsewhere Themes Theming Community Front End Framework Bootstrap