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.
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.
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.
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.
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
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âŚ
- Blade is simple enough, but itâs definitely different from whatâs traditional
- Yarn and task-runners in general were definitely new to me when I started with Sage
- The base template; again this is a simple enough concept but itâs one more thing thatâs different
- 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.
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.
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.
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.
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
I like the idea of having it removed by default and having documentation on how to integrate it. I usually end up removing it so that I can use the Foundation front end framework. Just a personal preference.
Submitted a PR that has includes the option for removing Bootstrap when creating a new project: