Skip to main content Skip to secondary navigation Accessibility Feedback

Kraken, Sass, and Open Source

I’ve started planning version 3 of Kraken. I think it should use Sass. And that’s creating some challenges with the way the project is currently structured and my desire to keep it open and accessible to everyone.

Lightweight & Modular #

What makes Kraken different from frameworks like Foundation and Bootstrap is scope.

Other frameworks—I actually consider Kraken more of a boilerplate than framework—try to include everything you’ll need for a project. Kraken is just a starting point.

I’ve built a ton of handy little add-ons that are designed to integrate with Kraken, but they’re not included. You have to download them separately and drop the code into your project.

This has two practical benefits:

  1. You’re not removing a bunch of unused code when you move a project into production.
  2. You can (and a lot of people do) use the add-ons as standalone components in other projects that aren’t using Kraken.

Sass & Modularity #

Sass makes modularity really easy.

You can keep a library of modular code, and include just what you need into each build using @import. Need to update colors? Change a few variables in your variables.scss file and they populate throughout your CSS.

But that approach is really different from how Kraken is structured today, with separate code bases that you manually pull in. It also makes using add-ons as standalone products a lot harder. And the last thing web workers need is another “everything you’ll ever need and a ton of stuff you don’t” framework.

I’m currently working through how to merge these use cases and development approaches that are a bit at-odds with each other.

A possible solution #

The solution I’m currently leaning towards combines some of the best things about Sass with the Kraken approach to web development.

Today, add-ons for Kraken all share the same typographic scale, color palette, and coding conventions. It’s what makes them easy to just drop into a project and go.

In version 3, they can instead share the same variables and mixins, while still being standalone projects. I’ll simply include a common variables.scss file with all of them that can be omitted when dropping them into a project built on Kraken.

While this will involve a bit more manual work than an all-in-one framework, I think it maintains what makes Kraken so awesome and allows for greater flexibility. And for folks who still work in CSS, it allows them to keep using Kraken the way they always have. I’ll still include a compiled version as part of the download package.

Are there any big things I’m missing with this approach, or other ways I might balance multiple concerns that I’m not thinking of?

Have any questions or comments about this post? Email me at chris@gomakethings.com or contact me on Twitter at @ChrisFerdinandi.

Get Weekly Digests