Add a new framework base theme to Drupal core

I wanted to chime in here with my opinion as I am part of the

"Since many "I want a framework" people are not front-end developers, there are probably more of them than the other 2 groups combined. We are not catering to them at all in Drupal core."

I believe https://www.drupal.org/project/bootstrap is the next best thing to Views and Admin Menu that happened to Drupal in a while. It is a fantastic theme and framework. Why? It makes a Drupal site mobile friendly out of the box and it also supports http://bootswatch.com/ (change the look and feel with a click...). All my Drupal sites now run on Bootstrap, and I simply don't have to care about anything anymore when it comes to theming, and I can focus on making sure that my content serves its purpose.

Hey guys, I'm one of the maintainers of Bootstrap, and currently leading the charge for the 8.x branch of the project. Mark Carver pointed me to this issue and I just wanted to pop in the say I fully support this initiative and would like to recommend that Bootstrap be used for this. I would also like to volunteer to lead the charge here and take on this initiative (If the community agrees with using Bootstrap), since I am already doing similar work for the 8.x branch of Bootstrap. If that jives with everyone, we can go ahead and assign this task to me.

I know we've marked this as postponed until after #2289511 and 8.0 but I'd like to start the discussion so that as I work on Bootstrap 8.x I can align it with this end goal in mind.

Bootstrap is nice, but I don't think it's fundamentally better than Zurb Foundation, or probably other frameworks. I'd think we'd want to have a more substantive discussion before we just throw a huge framework into core.

Which isn't to say I disagree with John's proposal, I think it's a good one. I'm just saying we need to talk for a bit about which framework makes the most sense.

Also note his important question about what to do about versions and versioning -- we need to figure that out in any case before we start pushing forward.

Front enders are a varied bunch and we should allow things like this to flourish in contrib, framework themes in D8 should be well integrated as long as we get core right to begin with.

All I can say is I'm not convinced, and that consensus is likely impossible to achieve. Contrib is a wonderful thing and new users have always gone to contrib to find what they need - its hands down the best place for things like this.

I've actually been following this issue (and slowly creating a comprehensive response) since DC Austin. Was just reminded of it again by the recent activity on #1801582: Add a new, non-default framework-based theme to Drupal core.

Due to the nature of this topic (which can easily get heated rather quickly), I'm trying things a little differently. I think this issue deserves mindful reading and thoughtful discourse and will keep it short here for now. I will reply again next week with a link to the blog post where I publish my response. That way people can read it when they have a moment to get to it.

This issue is, however, definitely postponed to at least 8.1.x (if not later, but we'll cross that bridge when we get to it).

https://drupalwatchdog.com/blog/2015/8/drupal-should-use-external-front-...

Let's not kid ourselves, any framework will very likely bring some JS with it.

Fantastic Mark! Thx for the post. Bootstrap has become the de facto "linux of frontend" and Drupal has long missed the boat of defining a frontend for the web or even being influential in frontend circles. I love your Drupal Bootstrap theme. Thank you.

Bootstrap and a well implemented base theme for it in core would be amazing. I like the Bootstrap contrib theme but maybe for core we should have a lighter implementation.

Bootstrap contrib theme but maybe for core we should have a lighter implementation.

The current contrib implementation (7.x) is a little overly bloated due to having to "fight" with what core provides. This is why adding the classy base theme in 8.x was so important and the default markup/classes core provides is currently be migrated to it.

The 8.x implementation of Bootstrap is still under development, but if it were to make it into core, it would also obviously go through a bit of a rewrite to adhere to core standards and to streamline it more than if it were a standalone contrib project (as has happened with other contrib projects).

Pinged this issue over here :) #2152519: [meta] Make sure Drupal 8 looks good and works right on browsers (both mobile+desktop)

I appreciate the effort to bring light to this topic. On issues like that however, mentioning a massive issue like this without also mentioning that it's just an "FYI comment" tends to shut people down to the overall concept rather quickly. I commented on that issue as well to help "soften the blow" (so to speak) of the heaviness this issue implies.

This issue is, and will be, a beast in and of itself.

The entire issue summary needs updating based on my blog post, but for now I will just add the link at the top (so people know about it without having to dig through comments).

Just to be clear, markcarver, based on your comment in #2152519: [meta] Make sure Drupal 8 looks good and works right on browsers (both mobile+desktop) are you talking about rewriting all the themes in core with Bootstrap? Adding Bootstrap as an additional core theme is one thing, but making all our front-end code Bootstrap would be quite another. Maybe I'm misunderstanding.

No, this issue isn't about "rewriting" existing themes. It's about adding an additional external framework to core (in 8.1.0 or some other future minor 8.Y.0 release) and how I think core should move forward in the future (9.x) regarding any "themes" it wants to provide.

Please, read the blog post (edit: and comments).

Just tried to find some of the "reasons" behind why Joomla moved to Bootstrap. Unfortunately, I am not all that familiar with where to look and the only thing google produced that was relevant was this old post by Kyle Ledbetter (the lead UX core individual for Joomla?): http://kyleledbetter.com/jui/bootstrap/. It's really striking to see the similarities between his post and mine...

markcarver - joomla +bootstrap -- Kyle offered a new template to joomla based on bootstrap which was excepted .

The reasons where that Joomla has a seperate admin /frontend split ( ie. a component will have two parts , one built for admin and the other for frontend. )
At that time when components where made available to add features from contrib ( especially pay for components ) they very often supplied with an admin interface with ui that looked / worked completely different from the Joomla admin ui.
So Kyle proposed Bootstap to try to unify the admin interface for core and contrib .
Unfortunately ? this also meant that the frontend template was redesigned to also use Bootstrap ( ie. forced everyone to use Bootstrap as default template ).
The Joomla template houses ( ie . Paid templates ) did not want to use Bootstrap so they provided their own framework as part of the template ( ie . A component which allowed them to use core output in a way that suited them ) .
I would not want to see Bootstrap in core , i do not see any compelling reason for not allowing contrib to provide a base theme based of Bootstrap which allows users to use if they want but does not force its use on all.

Mark:

I had read your post when it went up, and I just reread it again a couple days ago. My understanding is that you are proposing introducing Bootstrap not only as a framework theme included in Drupal core (whenever that gets introduced), but also ensuring that any other themes included in core are based on that framework.

Here's my understanding of what you're proposing and why:

- The number of front-end developers involved in core is small, so expecting Drupal core developers to sustain and maintain core themes would be simplified through the use of an external framework.
- Because Drupal's test infrastructure does not currently support front-end testing, we should use an external front-end framework that can use front-end testing infrastructure.
- Common Drupal base themes reset core theming, but do not necessarily provide tools to make it easy to create a custom design for a Drupal site without the involvement of designers and front-end developers.
- Bootstrap should be the framework we use because it is popular at present, and back-end developers tend to like it, so Drupal core back-end developers will be able to work with it.
- Part of the reason Joomla adopted Bootstrap was in order to standardize admin UI components so that core extensions like modules could have a reliable standard for how to implement UI elements.

One of the big accomplishments in D8 that we've almost completed is to separate D8's visual classes and styles into the Classy theme, only leaving truly functional markup, CSS and JS in core output. That makes it a lot easier for a framework-based theme like Bootstrap to exist without nearly as much overhead. The same is true of lots of other front-end frameworks. This frees us up to introduce new themes in the d8 release cycle, and for the contrib theme landscape to do a lot less work.

If we did end up using a front-end framework within core, and part of its goal was to allow consistent admin components for the module ecosystem, I'd be concerned that we'd risk entangling that front-end framework in core's default output in order to ensure consistency. Personally I think the flexibility we've added in d8 is a good thing so that people who like Bootstrap can use it much easier, and the same is true for those who like Foundation, or whatever else might be the most popular thing in 2-3 years. Maybe that's Bootstrap, maybe not.

Front-end development does move fast, and that happens less fast with front-end things in core. Once a major release hits, changing markup in templates or core CSS/JS is very difficult, because existing sites depend upon that staying the same. A contrib theme has a lot more flexibility to change as an external framework changes and easily update to Bootstrap 4 or Bootstrap 5 or Foundation 6 when those are available, and not when we are hitting 8.2 or 8.2 or 8.3.

If a framework included in core is not in sync with the latest and greatest version that is in the wild, then the large ecosystem is not going to be as effective if some plugins or tutorials are inapplicable to what's included in core. I'd think that keeping Bootstrap in contrib would allow it to be much more successfully used with Drupal than if it were a part of core.

I very much agree that front-end testing is critical, and once d8 is out, I'd love for us to look into how that could potentially work with d.o.'s testing infrastructure. Having visual regression testing would make core front-end work much, much easier.

I also think that providing theming components for admin UI is a good goal. Lewis Nyman has been working on that. We've had a number of other competing priorities, and hopefully that's something that can continue to progress as we move forward. Drupal providing its own theming components may be more work than adopting an external frameworks' components, but it also provides less risk of getting out of sync with an external system outside our control.

It's definitely true that getting off the island has been a big goal of d8. I think there are special challenges to do the same with Drupal's framework because of the difficulty in making changes to markup, CSS and JS during a major release cycle. Our upgrade system is focused on back-end changes, not front-end changes. It's hard to envision how we could provide a reliable upgrade system for markup, CSS and JS that would provide backward compatibility. Maybe we need to research how other systems handle those sorts of changes.

I know you put a great deal of thought and consideration into your post, Mark, so I'm not trying to stomp on that. I have practical concerns about integrating an external front-end framework with core, and that would be true regardless of which framework it was.

@mdrummond, I definitely appreciate the detailed follow-up! I'll try to just summarize your comment (for possible future issue summary iterations):

• Versioning: yes, this is something that must be figured out before an issue like this could ever hope to move forward. This shouldn't be the sole reason for argument though, it's just a problem to be solved. Unless we can figure out a solution in D8, I would almost imagine this issue getting postponed until D9 when we can completely overhaul the theme system (which would make it easier to account for versioning). (edit: Twig could possibly make it easier to deal with versioning via something like its extends/block capabilities, not sure yet).
• Updating: this goes kind of hand in hand with versioning, but if themes were able to participate in core's update process, like modules currently do with hook_update_N(), this could at least provide a way for themes to "update" certain things between versions (e.g. theme settings, perhaps even templates?).
• Default/Admin themes: yes, I kind of implied that this would be a nice "out-of-the-box" experience, but in all reality this would not even remotely happen until D9 (if at all). It was also more of a "what if" scenario and directed more towards Bartik, not Seven (which has already received a major overhaul).
• Components: yes, this is also another area that will need to be figured out and addressed before something like this can move forward.
• Bootstrap: along with the "popular" aspect, I think the stats for the d.o contrib project should be taken into account as well

I really like the idea of making it easy for "new to Drupal" or "not very frontend-y" types to get Drupal in a flavor of a popular solid front end framework. But this seems like the job of a Distribution, or a suite of themes/modules.

Call it Drupstrap and Drurb Foundation :P

Having a Drupal install that comes up all ready to rock in your favorite front end framework (with a distro) seems like a much more appealing user experience to me than downloading core and turning on the right things.

Aside from that, including these things to core seems like we're inviting bloat. These things change often and they could be 'dethroned'. We'd be stuck stuff in the API that we can't/shouldn't remove.

</twocents>

But this seems like the job of a Distribution, or a suite of themes/modules.

This kind of goes in hand with #2385387: Permanently split Drupal and Drupal core into seperate repositories. If we were to actually make core about just the API's it offers (and not include the modules/themes that consume them), this would make sense to do. Until the above issue happens though (and we split the themes core provides into their own separate projects too), core currently ships with a default theme. Ignoring this fact doesn't solve the issues.

Aside from that, including these things to core seems like we're inviting bloat.

The same could have been said about views or any other contrib project that has since made it's way into core. "Bloat" is often an overused and abused "go to" word; where its sole purpose is to start bike-shedding.

These things change often and they could be 'dethroned'. We'd be stuck stuff in the API that we can't/shouldn't remove.

Again, just a problem to be solved (aka versioning).

---

I've already addressed these issues/topics in my post and subsequent comments (here and in my post).

We can argue all day long about "why we shouldn't do this" (and I'll likely rebuttal with facts). Until someone responds with a different solution (that doesn't take 10 years to implement) to address the issues I have identified in my post, I would prefer that we try and limit the bike-shedding please.

Mark, I appreciate this is something you'd like to see happen. There are practical concerns that would pose a barrier to adding a non-default framework. Even if those barriers were removed, I don't think that equates to "now we will add a framework-based theme" to core. There was plenty of disagreement in #1801582: Add a new, non-default framework-based theme to Drupal core, particularly over which framework might be added. I don't think it's particularly helpful to rehash that discussion in this thread, but... if it came to the point where it actually was feasible to add in a framework, and a decision had to be made about what to actually add in, I'd expect you'd see a lot of those arguments crop up again.

We're not at that point in time right now, and it might be quite some time before that happens, if we ever get there. I don't think upgrading theme assets is a trivial problem to solve. If we get to that point, frameworks may have changed in a way that alleviates some of the previous concerns that were raised. Or maybe not.

Either way, I don't think it's particularly helpful to dismiss any disagreement with this proposal as bikeshedding. When everybody agrees a bike shed should be built, but can't agree on what color to paint it, so it never gets built, that's bikeshedding. That's not the same thing as disagreeing about whether we need a bike shed in the first place.

I'll need to see a compelling case as to why this should happen, i.e. I don't see anything in the IS that actually makes a compelling case for doing this - so lets see a decent argument as to why this might be vialbe in the first place.

Lots of reasons why not, you need to counter those first, going ahead with a plan now is wasted time and resources, this might take years to discuss so there is no hurry for such a huge decision to be made. I have plenty of time, 10 years is OK with me.

There are practical concerns that would pose a barrier to adding a non-default framework.

Yes, which is why this issue is postponed (perhaps even until D9). It doesn't hurt to discuss this in the mean time though.

I want to make it clear, I'm under no grandiose illusion of trying to "just get this in core". No, I want this to be done correctly and with careful thought.

Either way, I don't think it's particularly helpful to dismiss any disagreement with this proposal as bikeshedding.

I wasn't dismissive. Most of #20 was basically saying "yes it would be an improvement", yet immediately countered that with the same rhetoric, generalizations and propaganda that has caused other issues like this to not stay on point. Also, specifically, I was referring to the "bloat" comment which is "bikeshedding".

---

I'll need to see a compelling case as to why this should happen

https://drupalwatchdog.com/blog/2015/8/drupal-should-use-external-front-...

I don't see anything in the IS that actually makes a compelling case for doing this

No, the entire IS isn't yet updated fully. However I did put the link to this blog post at the very, very top.

No, I haven't had time to condense and organize my entire post (and comments) into bullet points for this particular IS yet. Maybe this weekend, maybe not. Just because I haven't changed the IS doesn't mean I haven't already addressed this in my post which did give compelling cases (plural) for why this needs to happen.

lets see a decent argument as to why this might be vialbe in the first place

Which is what I want: an actual debate. This isn't something that I've just decided to wake up one day and say "oh this would be fun". No it has come from over a years worth (since DC Austin) of contemplation of why this is an issue in core and what to do about it.

Lots of reasons why not, you need to counter those first

What reasons? Because people don't like it? That isn't a reason. The majority of "reasons" people have brought up (in the past issue) and this one have either a) already been refuted or b) are nullified due to the passing of time and newer versions.

The only reason (thus far) that has any real merit (for any framework) is how to deal with "versions" of frameworks and not introduced BC breaks. As I have stated before, I agree that is an issue that needs to be addressed. But it is just a problem to be fixed. It shouldn't be considered a "reason" for why we shouldn't do this.

I have plenty of time, 10 years is OK with me.

Personally, that isn't OK for me. I'm tired of seeing Drupal lacking on the FE. I'm tired of continuing to just throwing band-aids on Bartik. I'm tired of having no focus or leadership on the FE. This kind of attitude will get us no where (regardless if you were joking or not).

I may be misinformed about bootstrap but there is x bytes of CSS covering a variety of cases that core may well not need. (Snugugs cheeky slide show is likely go to source of propaganda)

To me that is my definition of bloat. Loading things we don't need.

How can this be curtailed so we don't load the entire library but only load the parts we need where we need them? Or do we?

And keep that strategy somewhat maintainable when they change versions and/or bug fix.

Short answer:
I'm aware of that slideshow.
We shouldn't worry about individual CSS/JS components for "out-of-the-box", that should be left to sub-theme customization.
Instead we use a CDN, load all the minified CSS/JS and actually use the components it provides instead of trying to invent our own.
No one is going to force you to use Bootstrap or any other framework, just like no one is currently forcing me to use Bartik or Sassy as a base theme.

Longer answer:
The slideshow was made shortly after Bootstrap 3 came out when it still had some serious issues (and still does to some degree). The fact of matter is this: it's an evolving software (just like Drupal is) and gets better over time. Many of the "myths" about Bootstrap stem from outdated sources and focus solely on the relatively minor negative aspects than what it does as a whole. The Bootstrap 4 alpha is certainly already more promising than Bootstrap 3 is, if only for it's official move to SASS and rewriting their JS components on ES6 standards.

How can we say anything remotely similar about our core theme Bartik. Seriously, the only reason they're able to focus on these aspects is because their a self-contained ecosystem. Why aren't we taking advantage of that.

To me that is my definition of bloat. Loading things we don't need.

So I guess then by that definition I can consider what core, Sassy and Bartik provides as "bloat" since I don't need them?

No. The definition of "bloat", and the rational behind offsetting any "cost" associated with it, is purely circumstantial and subjective at best.

I would recommend reading my comment (specifically the "Bootstrap's fundamental flaws" section) where I debunk many of the "myths" about Bootstrap or really any framework for that matter.

I would also recommend reading: Everything is Bloated.

This issue isn't really for or about us front-end developers, it's about the other 99.9998%.

---

So... this is a little OT, but here's another problem with how we are currently doing "SMACSS" in core: aggregation.

This wasn't so much of an issue in D7, but it has certainly been exacerbated in D8. Every time we add static CSS files that need to be aggregated, we're increasing the number of aggregate permutations (e.g. this user has access to this, that user does not, etc.).

That alone can easily lead to 4-10+ separate CSS and JS aggregate files that need to be loaded. That means extra HTTP requests. Granted this (in spec), could possibly be somewhat alleviated by the newer HTTP/2 protocol, but we're certainly not there yet.

Regardless, the current fact remains: this still keeps the responsibility on the server to generate these aggregates and determining which one a user should have and thus, asking clients (browsers) to request multiple files. Couple that with the fact that these aggregates are likely not even behind a CDN... that is where a lot of the "perceived page load slowness" really lies.

The solution for a framework: don't worry about this for "out-of-the-box". Just load the minimized/gzipped CDN files once and let the browser cache them. Core shouldn't be in the business of trying to provide all the FE performance solutions out-of-the-box (otherwise we'd all be out of jobs).

No, the time to "pick and choose" from a framework is when you need to sub-theme and have access to the source files to do so. That is not what this issue is, ultimately, about. It's about providing the fundamental Drupal integration (template overrides/preprocessing, etc) for an external framework.

Aside from that, including these things to core seems like we're inviting bloat. These things change often and they could be 'dethroned'. We'd be stuck stuff in the API that we can't/shouldn't remove.

Only addressing the first part of my comment on bloat does make it sound bikeshedding. Comparing this to Views is silly, Views is on an absurdly high percentage of Drupal 7 sites. Specific front end frameworks cannot make that boast.

I think it is bloat and not a good addition to core because:

• Front End Frameworks spawn often and change regularly
• There isn't a clear winner, and the majority of Drupal sites aren't using a specific framework
• Drupal's release cycle and API rules may not be a 'solveable' problem if this is in core, we'll just be angry that we included a junk version of Bootstrap in core when the new cool version came out
• This is such a great case for contrib, I fail to see how adding to core nets anywhere near positive in a pros/cons list

This issue isn't really for or about us front-end developers, it's about the other 99.9998%.

Totally agree, I think it's a great problem to solve, but I don't think this is the right way to solve it.

Considering the nice shiny awesome looking D8 theme layer, is this THAT hard to teach anymore? Adding markup and classes to Drupal has gotten really easy, especially considering there are good themes based on these frameworks!

It makes part of the premise for this problem harder to swallow. I'm also failing to see why contrib/distributions aren't the better solutions than including this in core.

The solution for a framework: don't worry about this for "out-of-the-box". Just load the minimized/gzipped CDN files once and let the browser cache them.

I'm not sure I'm reading this right, but if this is in core I don't think we shouldn't have external web dependencies by default for cases where someone's web sites shouldn't be accessing the public web.

If it's just meant to say we put these minified files in core without unminified ones I think that's a developer experience issue. I think the 'less front-endy' that this issue is geared towards would want to have a human readable version of the code that's running, if that's not what we're linking to in the theme by default.

@markcarver I read the articles, thanks for sharing. You twisted my words a bit on the quote in #26 but I'd rather not argue about it because it won't help this issue.

RE CDN points by @wesruv in #27 I agree completely with the CDN being a bit of a hangup for me too. Offline-mode for development or when the service inevitably goes down(power outages, system failures, gremlins, etc). As long as we can provide a fallback and to your point having the full source of the version we are using in core is important. @markcarver maybe a follow-up issue about improving support for CDN backed assets(attachments) with fallbacks in core would be a stepping stone in helping the plan?

Added some Tasks to the issue summary to hopefully help address concerns and maybe make some headway, hey we may improve core along the way;)

I don't think something like this can happen until Drupal has real proper package management / build processes in place so you install with dependancies that are required etc. Versions is the biggest headache and a super huge PITA with base themes, we need a real way of dealing with these things in Drupal, maybe that happens some time in D9, I am not following most of those issues (I am, but not keeping up with the latest), anyway that all looks a long way off.

I don't really buy the "get off the island" arguments that are often presented, to me this means "off the island" ideologically, not necessarily to include 3rd party code - for example we should use common patterns in code and UI/UX design, or as we have done use SMACCS and some BEM ideas to provide commonality for front enders.

Personally I way prefer making Drupal a good home for all frameworks, so its generic and easy to include any framework you want in contrib - thats where to focus energy IMO.

Oh Mark, yeah, of course i am mostly joking about the 10 years, but 4 or 5 years is not crazy if we were thinking D9 etc, but then again I have a very long view of things, I am not in a hurry at the best of times, to my thinking frameworks are trendy right now, but in 5 years I don't know, I think probably they will still be around but I also think there are some very fundamental changes coming and could switch it all up again. Tomorrows Twitter Bootstrap is yesterdays 960gs, one day you're "in", tomorrow you are out.

I have to voice disagreement with this statement being supportive of semantic versioning.

For example, we could add a new hot-framework-of-the-moment base theme to Drupal 8.1.0 without changing any APIs.

The larger issue with that sentiment is that it means that 8.2.x+ we now have to support the hot-framework-of-the-moment from years past. This would be a daunting task seeing as how a new javascript framework comes out every hour.

I would suggest that this is a great task for the examples module. Find a framework (preferably a light weight one) that would be a good example, and write an example for the examples module.

The problem, as stated in the issue summary, is

Drupal core provides no examples of how to integrate a 3rd party front-end framework with Drupal.

I would argue that specific integrations belong in the contrib domain because they are not universal and many people will want to support their flavor. Forcing support of a single framework will limit adoption and not encourage it.

Providing examples to do things should be done in the examples module. Drupal core should be well documented, but not littered with example code.

we now have #3050384: Provide a starterkit theme in core, still relevant?

Also, see #3214072: Provide an Olivero sub-theme creation tool, which was inspired by #3050384: Provide a starterkit theme in core. The tool generates a sub-theme based on a template folder inside the Olivero theme, but could be modified to support other themes.