Author
Gabriel FagundezGabriel Fagundez is the COO of Moove It. A results oriented executive, he has experience leading worldwide teams to match companys' expectations by providing a solid consultancy service.
A few days ago, Moove-it gave us the chance to meet Harry Roberts, an experienced Front End developer. Harry provides courses to companies such as Google, Etsy, and the BBC. The focus was on improving our Front End skills through a two-day workshop, but the experience gave us more than a bunch of technical skills and knowledge. Writing CSS is very simple. Learning the language is not a big deal. It takes no more than 2 minutes to write 3 lines of CSS to style an element of the DOM. But, let’s think beyond that. What if the application grows bigger than we had originally expected, at the beginning of the project? Is our code maintainable? What things should we consider in order to write more maintainable and scalable CSS code? As a javascript development company, Moove-It should concern about this things. Let’s look at just two technical elements we learned during the workshop.
BEM. Block, Element, Modifier
When building a typical website, the process is based on the assumption that the design and technical specifications for a website do not change over the course of its development. The designer and the developer will work with little or no interaction between them. Typically, we assume that the design is ready before working on the development.
This approach has the following iteration assumptions:
- First, the designer prepares a series of mock-ups visualizing the design of the website.
- Then, based on the mock-ups, a static page is created.
- Last, the developer brings the site to life with the integration with the BackEnd and adding JS logic.
This approach works well, if the assumption that we mentioned above is true. However, that is rarely the case, as normally the website begins to evolve and take on a life of its own. The design of the pages gradually changes and new pages or sections are added.
One of the most important features of using BEM, is that it ensures that everyone participating in the development of a website is working with the same codebase and using the same terminology. The design of the website can be changed at any moment, as site requirements change, without creating any problems or conflicts.
BEM Principles
Considering programming methodologies, one of the most common examples is Object Oriented Programming (OOP). We’re very familiar with OOP, and in some ways, BEM is similar to OOP. BEM is a way of describing reality in code, with a range of patterns, and a way of thinking about program entities regardless of the programming languages being used.
BEM Components
- Block: A block is an independent entity, a “building block” of an application. A block can be either simple or compound (containing other blocks). For example, a block can be a Search Box.
- Element: An element is a part of a block that performs a certain function. Elements are context-dependent: they only make sense in the context of the block that they belong to. In our example, elements are the input of the Search Box, or the Submit button.
- Modifier: If we want to add a particular attribute to an element, we should use modifiers. For example, to add two Search Boxes, but one with a bigger button, we can add the modifier –big to the Submit button.
In the above case, we will have something like this:
<block:search> <element:input/> <element:button modifier:big>Search</e:button> </block:search>
And the CSS should be something like this:
.b-search { } .b-search__e-input { } .b-search__e-button { } .b-search__e-button--big { }
As you can see, this approach gives us the chance to modify the block, remove it, or add new components, without any unexpected changes across the application. The code will be maintainable, easy to learn, and simply awesome.
ITCSS. A sane, scalable, managed CSS architecture from CSS Wizardry
The title of the official page is very descriptive. The workshop made us think a lot about our own apps and highlighted the importance of having our own CSS architecture. We usually build large and complex applications, which change over time. Having a defined architecture is something we can’t avoid and gives us the ability to offer better code in less time.
Managing CSS at scale is hard, and sometimes we make it a lot harder than it should be. The Inverted Triangle CSS is a simple effective and as yet unpublished methodology to help us manage, maintain and scale CSS projects of all sizes. ITCSS, is not a library, it’s a school of thought, a meta framework if you will. It helps us manage the problems associated with writing CSS at scale, and helps us maintain our sanity, at the same time. It’s also based on this statement: “each piece of CSS needs knowledge of what came before it, and what might come after it”. CSS is a giant dependency tree, and we need a way to manage this dependency at a very low level.
ITCSS was one of the most valuable topics that we learned in the workshop, and something that we have already started to use in our web applications.
Miscellaneous…
Last, but not least, let’s talk about Harry. We met not only a CSS expert, but also a great person. We can talk a lot about the workshop, the ITCSS architecture, BEM and all this great technical stuff, but that’s not the whole story. The workshop provided us with the opportunity to meet a person who has worked with leading companies across the globe, and we were able to learn a lot from his experience.
We also went out for a few beers to talk about culture, sports, technologies, etc, with a person we had met the day before. It was a great experience, which gave us a huge amount of technical knowledge, and the opportunity to make a new friend.
Interested in other services? Read about our highly- experienced Java Consulting firm.