DEV Community

Cover image for From standard framework to ITCSS & BEM

Posted on • Updated on

From standard framework to ITCSS & BEM

Cyclically I usually make a point on my level, on what I am doing in my profession as a front-end developer and today I realize that the biggest revolution has been to abandon the standard frameworks.

For several years I have worked in many companies and web agencies, usually with the technologies in vogue and the solutions required by the market. Working specifically on the interfaces, I used a lot of Bootstrap and jQuery.
While it was quick and easy to build functional layouts, on the other it was frustrating to customize structures and be pixel perfect with designer mockups.

Following the flow of modern technologies such as SCSS and Gulp easily predisposed me to the pleasant discovery of atomic css.
The revolutionary aspect was to not have to look for the most similar boostrap construction to the one required, but rather to build it faithfully, with the design system specifications!

Coding with the simple concept of atomic CSS was not enough, it was necessary to know how to organize, structure and recall it.
ITCSS and BEM were the solutions to this block!

Structuring of the framework requires a design system as a reference: padding, margin, colors, fonts are among the most important definitions that guarantee harmony and consistency.
To organize the classes such as utilities, components, objects, elements, tools and settings allows you to mentally organize the specificity of the classes and not least their single functionality.

The construction of components, for example a dropdow, becomes simple and quick: by calling only the utility classes, the development of the component is generally 80% complete, however, sometimes it is necessary to be more โ€œdeclarativeโ€ and then write additional properties. In this case it is useful to exploit the BEM convection and consider the component as the block with its elements and variations as modifiers.

In the project I'm still developing on, using these approaches and tools made me see natural consequences:

  • a much shorter compiled css, with a very low number of declarations
  • a lighter css in loading and reading for the browser
  • a more full-bodied DOM, but with easier css properties to load

The framework developed with my colleagues, although it has been thought for an editorial project, I believe it is easily scalable and transferable for another kind of project - obviously excluding the components.

Here a piece of code, from my last project, about the button component, to show you how much longer could be the HTML:

<button class="c-btn c-btn--{{modifier}} {% if rounded %}c-btn--rounded{% endif %} {% if link %} c-btn--link {% endif %}{% if size=='large' %}c-btn--large u-label-04{% elif size=='small' %} c-btn--small u-label-05{% else %}u-label-04{% endif %} {% if iconleft %}u-row-reverse{% endif %} u-cursor-pointer u-flex u-items-center u-label-04" {% if disabled %}disabled{% endif %}>
  {{ label }} 
  {% if icon %}
    <svg class="o-icon {% if label %}{% if iconleft %}u-mr-xxsmall {% else %} u-ml-xxsmall{% endif %}{% endif %} 
    {% if size=='large' %}o-icon--md{% elif size=='small' %}o-icon--sm{% else %}o-icon--md{% endif %} ">
      <use xmlns:xlink="" xlink:href="#icon-{{ icon }}"></use>
  {% endif %}
Enter fullscreen mode Exit fullscreen mode

However, by recommending this approach, there are several valid frameworks such as:

IMHO Definitely a good time investment!

Discussion (0)