About coding good practices and Kirby bootstraps

Hi everyone,

I wanna talk about your “front-coding” habits and advice about good practices.
Especially in a context where I believe it’s important today to be able to work with multiple people on a common code, design it so you will reuse it or sections of it and share it so others can learn or used it.

So, I want to start discussions with those subjects:

  1. What do you think of BEM (Block Element Modifier) and SMACSS (Scalable and Modular Architecture for CSS) practices?

  2. In a scalable and modular architecture, where do you fix the limit between useful and reusable?

  3. In the context of Kirby, is it more pertinent to multiply small plugins with their own CSS or keep things separated using the existent assets/ and snippets/? That is where I think about Kirby bootstraps solutions, like how can we design them intelligently?

I ask as a graphic designer how learn to code by himself. I’m not an engineer. That is why I would love to have your opinions and advice :slight_smile:

This subject has already been discussed on the forum, but it could be interesting to list them in a common topic or share any external resources you find relevant.

For me, these considerations have started watching this presentation about BEM and SMACSS and developing this Kirby bootstrap.

Thank you for reading!

1 Like

Disclaimer / about me: I’m a full time front-end developer at a digital agency in The Netherlands. I’m coding (with co-workers, front-end developers and back-end developers) about 30 - 40 sites a year, with a different range of audiences. Some have 1000 visitors a day, while other projects have around 1,850.000 visitors a day.

This is exactly the topic we have struggled with as well. We started with Bootstrap, which is rich and robust, but we’d found it to be ‘too rich’ and ‘demanding’. We didn’t need all the features, but somehow: everything seemed connected to one and another. So, we decided to create our own (internal) front-end framework to learn the basics of setting up projects and prototypes. It’s based on the grid system of Bootstrap (which I find genius), has a ‘traditional’ float grid and flex as well. For us, this was a great chance to learn SASS and control everything that’s being added to the framework. There are several clever resets and starting points, to quickly create prototypes for our clients, but they make excellent templates and building systems as well.

We use SASS as our CSS-preprocessor and the power of Twig for logic and DRY-er templates. We’ve ended up using a mixture of BEM and SMACSS, but with some ‘limitations’ or exceptions:


  • We only nest 1 level deep for BEM elements, so : block__element, but never block__element__another-element.
  • We only prefix utility classes, that do 1 thing only and we prefix it with .u- , like: .u-rounded or .u-radius and elements that ‘connect’ with javascript in some way: .js-menu-trigger. The .js- classes don’t occur in the SASS files.

The most important thing that we’ve learned: Code for the future you and your colleagues. When you come back to this project a (half) year later to add something, you don’t want to be struggling for half a day to understand the inner workings of your components. Be generous with comments in your code, to describe features of a block or element and be consistent when you’ve chosen your ‘syntax’ of choice.


  • We found that it’s super important for everyone to have clearly documented what’s already in your ‘toolkit’. Call it a styleguide, a style tile or pattern library, just have your inventory somewhere :). If you have this, you can easily spot what you can re-use when you need to make another element or part of a page. Also, designers can see what you’ve already made and come up with new components, based on your current toolkit.


  • I like the browser to have as little HTTP trips as possible, so we basically bundle all Sass together and compile it to one (compressed and Gzip’d) css file (*.min.css). We do the same with the javascript. For larger projects, we use Critical CSS. It extracts the CSS that’s needed to display and build the ‘above-the-fold’ part of the page (which is kind of tricky, because: where is the fold in this era?) and inject that CSS in the <head> of the HTML document. The css file is then loaded via javascript, to eleminate render blocking.

I know from first hand that all the Javascript frameworks and front-end frameworks can seem daunting and lifesaving at the same time, but: start with the basics: learn (vanilla) Javascript to understand how Javascript works and how it’s behaviour, learn CSS and then giggle at what SASS brings in play for your convenience as a front-end developer (variables, mixins, maps, lists :)) and use all of that to create fast loading, semantic websites with excellent user experience, powered by Kirby of course ;)!