Hit the Weights and Take the Bloat Out of Frameworks

wrote this on in . 196 reactions

Frameworks come under fire for being bloated. Some say they're too time consuming to style, and you can spend too much time overwriting styles. Or wrestling with important statements. Or removing unwanted code. Some say they come with too much stuff and at the same time complain that what is offered in a framework is not used.

Illustration of the Yeti running quickly

It's great to have many components with built-in styles when prototyping, but having these styles will inevitably require CSS overrides — unless you want all your sites to look the same. But frameworks give us a common language for designing websites. Not just HTML, CSS, and JavaScript, but also a repeatable base from which to build faster. People need a place to start their projects. Foundation was made for you to build off-of and make it your own. Frameworks don't make sites and apps for you, they help you get to end result more efficiently.

And yet the criticism continues.

There's a lot of concern that pages might be too heavy to load. Let's put that into perspective as to why pages are weighed down. Addy Osmani showed that a single page in a sample project built using Bootstrap or Foundation 90% of their CSS goes unused. That's truly a bummer to hear. There's got to be a better way.

Ditching the Bloat

yeti on the scale

Here at ZURB, we use Foundation every day on a variety of client and internal projects. We learn first-hand what it takes to move from prototype to production. We can't always deal with the extra weight and we can feel the pain of bloat ourselves.

Which is why make an effort to solve it. And sometimes that means taking risks, some which don't have the impact we hope. Take Foundation 4. We used Zepto, a lightweight jQuery library (9.1K when zipped!), to help reduce the bloat. But it wasn't necessarily faster so we dropped it.

Going back a even further, we worked to drop some weight with Foundation 3. You might not know this, but every component has had a mixin since that version. That means there is no need to import Foundation's class names. Its CSS less tedious to write, making it easy to remove components that aren't needed. You can even use the JS plugins individually to drop some unneeded poundage.

Beware the Pile of Components

Illustration of the Yeti and a pile of code

With the next version of Foundation for Sites around the corner, we've been thinking a lot about avoiding a big pile of components right out the box. And we've reached out to a lot of developers and designers — like Vice.com, Barclays and Toms — to learn how they've been using our framework. We also polled the community and received a lot of great feedback. One thing we learned: even our die-hard Foundation fans use only a fraction of the components on a given project.

And We're Looking to Address That

A lot of Foundation components are nice-to-haves that either don't make it to production or are simply left out. Things such as pricing tables, Clearing and Joyride. Sure, a lot of people like pricing tables, but if it's a component that is used once a year, does it belong in the core framework? That's a legit question we have to ask.

The _settings file is awesome, letting you quickly customize styles as needed. But having too many variables takes more time to find the right one than just writing CSS. We already solved some of this in Foundation for Apps. We combined some styles to reduce CSS output like our Menu-bar. It can be used horizontally, vertically, with icons, and with list items left, right, or spread out evenly.

Thinking ahead, components like card, alert and panel can all share the same base style in Foundation for Sites. Another example: Sites can have a menu component that replaces side-nav, inline-list, icon-bar and have dropdowns and buttons. Optimizations like this will not only reduce weight but also make our components more useful to you.

A Lighter Framework, FTW!

Illustration of a triumphant Yeti

Foundation's styles are easy to override in most cases, but it could be better. Fewer specific selectors and less use of important are definitely priorities. Some ideas we've bounced around are ways to get you from prototype to production more efficiently. One idea is to find a way to install Foundation with a core set of components, then progressively add as needed. Part of that is to have more components available from the soon-to-be updated Building Blocks library. These are ways you could have already optimized code by the end of your project speeding up workflow and reducing angst. These are just a few of the ideas that we're considering as we get into production soon.

Foundation for Sites has been through five iterations and very excited for the sixth. Foundation 5 was released on the platform of speed: faster to code, faster to learn, and faster page load. When it comes to speed and efficiency, frameworks help. There is still room for improvement and we're looking for those avenues. By listening to you, our amazing community, we get a sense of what matters to you in a framework. We want to make sure the core framework comes with the essentials you'll use every day. We find ways to give you the essentials and make it super easy to add whatever else you need. Making sure the components that are included fit most people's needs is more important.

Illustration of the Yeti and a screen shot of Trello

We want to know what matters to you. We've compiled feedback from our conversations on GitHub, the Forum, emails, and Twitter onto a Trello board we made public. It's your chance to be heard! We'll use this feedback to help guide development towards the features that are most important to you.

Get heard by voting on what matters to you!

Foundation Ideation Board

Brutalism
17 Web Design Trends That Will Take Over 2017
Container queries 2
Foundation & CSS Grid: Think Beyond the Page
Building blocks graphic
Foundation Building Blocks: Over 100 Components to Jump Start Your Projects