A framework's framework: Why SilverStripe 4 will use Bootstrap

We developers love SilverStripe because it speaks our language. It imposes very little and empowers us to create a customised administrative experience. We have virtually omnipotent control over the data model and particularly the forms we use to manage them. There are, however, limitations to this flexibility. The UI itself is a bit of an esoteric brain-baker.

Have you ever tried to make a simple CSS update to the CMS? Have you ever customised a template in the admin? If so, did you find yourself buried in various DSLs like “Pjax” response headers, and magical UI transformations imbued by jQuery plugins? It’s not exactly pleasant, but that’s not to say it can’t be done. All of this just needs to be better.

A few weeks ago, we heard from Stevie Mayhew from Little Giant, who discussed the concept of AX, or "Administrative Experience" in a blog post. This is an idea that clearly needs more attention. We need more developers to feel empowered to grow and adapt the CMS UI the same way they are to expand on its functionality, and it starts by adopting a CSS framework that people already understand.

Why is this just coming up now?

It’s perfectly reasonable to wonder why, in 2011, well into the Bootstrap Epoch, SilverStripe 3.0 did not opt to use a CSS framework. It was a well-established pattern at the time, and to make the case that it wasn’t mature enough is a bit of a stretch.

Many SilverStripe users may find it surprising that SilverStripe 3.0 actually wasn’t intended to have much of a UI refresh. It wasn’t until our lead designer at the time released a series of awesome designs that energised the community that we decided to invest heavily in a UI refresh. That refresh, in and of itself, was well beyond the scope of what we had planned for the 3.0 release, so a wholesale replacement of the CSS framework was just not viable at the time.

What we’ll gain

There are a lot of things we love about adopting a CSS framework. For one, most of them are plug-and-play, meaning that with minimal HTML/CSS skills, you can build something that looks well-designed. Further, it reduces the opportunity cost of putting a developer on pixel-pushing tasks instead of developing new features. Maintaining our own CSS “framework” has been very expensive in that regard. Lastly, by essentially outsourcing the UI core to a third party, we get to rely on their documentation, tests, and bugfixes, which allows us to focus on supporting core features rather than UI glitches.

The framework buffet

Bootstrap really championed the idea of a CSS framework that we could all use. It wasn’t the first, but it was revolutionary in its ability to provide beautiful and easily customisable UI to a website with little effort. Since then, there have been a lot of followers, some of which have more merit than others, and all of which are vying for a tiny slice of Bootstrap’s acclaim.

Initially, we felt like the best choice would be a library that provided minimal footprint, so that we could build a tailored solution on top of it, but in the end, we felt there would not be enough resources to do that well.

After surveying the developer community, we looked at several frameworks, ranging in size and scope, including, but not limited to:

• Bootstrap
• Foundation
• Foundation-apps
• Semantic UI
• Pure
• Skeleton
• Elemental UI

Making sense of it all

We had several criteria that we held each framework up against to help surface the one that was best suited to our needs.

• Broad browser support
• Good documentation.
• Ready to use in SCSS.
• A solid community base that won’t suddenly disappear, and big enough so that people will have guidance when creating modules or new elements.
• Good balance of functionality and tools versus file size.
• A component-based structure so we can easily and gradually integrate them with React when needed to improve the overall experience.
• A compatible licence

The winner

Based on these evaluations, we were able to produce two finalists: Bootstrap and Foundation (although Boostrap was subdivided into version 3 (stable) and 4 (alpha)).

In the end, it was a really tough decision, but Bootstrap 4 seemed to stand out just a bit more than everything else. In particular, we love the huge community and traction behind the product. Also, with the release of version 4, we’re excited about its smaller footprint. Lastly, we love that there is a popular, actively maintained React library for Bootstrap, which affords us UI and behaviour for free.

We realise that Bootstrap 4 is still alpha, but we are confident that we’ll be able to keep up with any and all API changes that are introduced as it stabilises. The upshot of choosing a nascent version of the product is that we maximise its lifetime. We hope the SilverStripe/Bootstrap marriage will be one that endures several major releases.

So what now?

In the next month, we'll see some movement on getting Bootstrap integrated for the alpha release. Right now, we are just planning to add it to the new Files & Images section, with the intention to roll it out across the entire UI farther down the track, per the proposed designs.

Welcome to SilverStripe, Bootstrap!

Header photo by Markus Grossalber.