[POLL] Removing Bootstrap by Default

Hey crew!

So as Sage 9 gets better and leaner, we’re trying to figure out how many people actually want Bootstrap included by default anymore. The production build time for a project without Bootstrap is 6x faster with Bootstrap removed. We were chatting about it and we think it might be best to ask what everyone else thinks.

I feel like with all the new changes in Sage 9, this is a perfect time to shed the Bootstrap weight once and for all. What do y’all think? Thanks!

  • Keep Bootstrap by default
  • Remove Bootstrap by default and add steps to re-add to documentation

0 voters

Keep in mind – if we keep Bootstrap we will be adding a dedicated place in the documentation on how to remove it completely. I’d add that to the poll but it won’t let me edit.

1 Like

:-1: on removing Bootstrap by default.

It’s easier to remove it than it is to add it back in. The majority of our users are also Bootstrap users.

4 Likes

There’s a point at which you’ve stripped things back so far that you’re just shipping the “concept of PHP and HTML”. Strong, working examples are a valuable jumping off point especially for users new to one or more of the technologies involved in developing with Sage. I know it helped me when I was new.

3 Likes

Well, that’s probably because the theme comes with it. Maybe some devs avoid Sage because it comes with Bootstrap, and maybe some would use other frontend frameworks if Bootstrap wasn’t in there by default.

1 Like

That’s a good point, and honestly Bootstrap was one of the main reasons why I started picking up Roots. I do feel like reading docs is an important skill however and if we blatantly advertised “It’s easy to add Bootstrap and this is how!” – going through that process might help people understand better how to add 3rd party dependencies in general (which is like 50% of our support threads haha). ¯\(ツ)

Why not just feature the various forks more prominently in the docs?

I’ve started removing it. There are a few CSS files that have to be rewritten, but it’s a small amount, mainly in wp-classes.scss. Removing bootstrap also makes it easier to remove jquery down the line. I think more and more devs will move in this direction in time, but I may be wrong.

1 Like

We are clearly thinking along the same lines today :slight_smile:

1 Like

Some of us have said it might be good to allow integration guides to other frameworks in the docs, but the problem is that forks might not be maintained, or explain how they’re implemented. IMO a solid piece of documentation on adding Bootstrap would be more useful and not too hard for us to maintain (every decision we make on adding/removing things to Sage effects how much we all need to maintain as a community).

The main goal should be to teach users how to add their own frontend library of choice. A specific walkthrough for adding Bootstrap could be used to illustrate that practically.

2 Likes

Exactly. I feel like if we keep the Bootstrap one maintained, we have a clear example for people to add a 3rd party lib with JS, CSS, and (optionally) a font (Font Awesome). Helps people understand how it’s done, and encourages them to dive a little bit deeper into how Sage works.

How about official forks, maintained by the Roots team? I’d help out however needed.

I understand the thought behind it, but some of the selling points for Bootstrap, for me, is that it provides a great set of standard defaults and it allows us to get projects up and running fast.

I feel like, by definition, the person building a bespoke front end probably has more time to remove Bootstrap. I don’t feel like reducing a production build from 8 seconds, or 12 seconds to 3 seconds is compelling enough to remove Bootstrap.

Just my .02

1 Like

I guess my concern with removing Bootstrap is that, when I was new to Sage, Bootstrap was one of the “technologies” I recognized, and it made me more confident that I could handle this.

There are a lot of projects that, while not intentionally so, are discouraging to approach.

Right now, with Sage 9, the potentially discouraging factors for someone coming from traditional theme development are…

  1. Blade is simple enough, but it’s definitely different from what’s traditional
  2. Yarn and task-runners in general were definitely new to me when I started with Sage
  3. The base template; again this is a simple enough concept but it’s one more thing that’s different
  4. Dependency management and the asset chain. Common enough in modern workflows, but not in WordPress theme dev.

If you add to that the fact that you have to choose and set up your own grid system, that’s a lot of mental overhead for a new user.

I’m definitely in favor of maintaining examples of how to add libraries (see my other thread posted almost simultaneously with this one!), but that example could be hover.css, rather than Bootstrap. Similar educational value without sacrificing that little bit of confidence for new users.

4 Likes

We’re almost certainly not going to do this. It’s hard enough maintaining one project let alone multiple forks which need to be in sync. Even with other people helping it still requires a lot of work on our part and there’s no guarantee that any maintainer keeps it up.

2 Likes

What about yarn tasks to add frameworks?

Right on, that makes sense, and I get it. That probably came of as a bit presumptuous on my part, that definitely wasn’t my intent.

All valid points, but I think the items you’ve mentioned require more mental overhead than including Bootstrap as a dependency.

We’re really talking about doing the following -

npm i bootstrap --save

main.js

import 'bootstrap/dist/js/bootstrap';

main.scss

@import '~bootstrap/scss/bootstrap';

The user would need to write some Bootstrap specific SCSS, which Sage users should be comfortable doing as it’s a starter theme.

The appeal of Sage for me has always been the modern workflow and implementing best dev practices early on. I think the trend to drop larger frameworks for smaller libraries or use only flexbox or the upcoming grid specification is going to increase.

It’s a marketing thing, though. “A WordPress starter theme with a modern workflow built with yarn, node, and Bootstrap”. Oh, hey, I know one of those things. I can learn this.

2 Likes

Just changed my vote from removing Bootstrap to keeping it in. Personally I would like to have a version of Sage without Bootstrap, because not every project requires all those styles and assets. It’s however quite easy to remove Bootstrap if you know what you’re doing. The documentation states that Sage should not be used if you’ve never developed a WordPress theme, so most developers will be able to add and remove libraries as they see fit.

However, when you do start developing with Sage Bootstrap provides some nice scaffolding and pointers as to how third-party libraries are integrated into Sage. Also beginners will more likely to struggle to add Bootstrap as compared to experieced developers removing it.

The speed increase when building is nice in theory, but with modern hardware (decent CPU and SSDs) I feel those (milli)second gains are mostly theoretical benefits.

Including a simpeler framework as proposed in this thread might be a good alterrnative. Bootstrap is by no means the holy grail or de facto standard, I think.

1 Like

Just a thought. What does Google Analytics say? Does Roots get much traffic for Bootstrap theme keywrods? I’m one of those that found it through Bootstrap theme 2 years ago (i can’t believe it’s been that long).

Adding removing it isn’t really a problem for me. But Sage is still a product even if it’s open source, some things that make it grow should stay :wink:

2 Likes