Hi Christoph, thank you for accepting my invite for this interview.
You are very welcome. Happy to chat about my experiences with BEM.
This is a side project, called "To BEM or not to BEM", and as you will guess, it's about the BEM methodology, but not only.
Everything started when one evening, a few weeks ago, I read your article on Medium, in which I found this phrase: “In the meantime, to fight the CSS structure problem we found that ITCSS is the way to go.” after having told that in the beginning you were using BEM as methodology
so, let's start from the beginning. can you tell me your role in trivago? how comes that you started to work on the project? what is your role?
I am currently leading the UI/UX Engineering team at trivago and I would describe myself a Front-End Developer. The company I am working for grew a lot the last years. When I started we were around 150 people and last week we celebrated employee Nr.1000. In such a fast growing environment we had issues with keeping consistency in code and design. In the beginning of 2015 we started creating a Design System and introduced a pattern library. After we redesigned our company pages we had to somehow bring in the new architecture into our core product, the trivago hotel search.
When you started to work on the project, as far as I understand, it's one year ago. How was built the CSS codebase? Less, Sass, "pure" CSS, other?
Yes correct one year ago we started with revising our coding guidelines and the way we built our UI patterns. Our CSS codebase was built with Sass but our coding guidelines didn't allow us to scale up our Front-End which let us rethink the way we built our CSS.
What was the reason for "not being able to scale"? What do you mean?
We started to repeat ourselves too often. we reinvented the wheel way all the time because re-usability was very low. This slowed us down in maintainability and in creating new features
And how BEM enter in all of this? Which were the reasons that made you choose to adopt it? Who decided, you on your own or was a collective/team decision?
I had a very deep look into BEM and was very convinced that this will help building more modular CSS. I think it is important that not one person decides but the team is comfortable with it. So I proposed it and asked my colleagues to try it out. At first people where very unlucky with the amount of classes BEM can add to the markup, but once they understood the structure and the benefits they felt comfortable with applying it. BEM was not designed to be pretty but to scale. Although we still often discuss about too many classnames, but in nearly every instance you can proof that moving the "problem" to CSS and try to save a classname with e.g. only using modifiers classes for block elements does not scale but will blow up your CSS.
Do you follow strictly the BEM dictations? e.g. “everything is a class and nothing is nested”.
Do you nest, for example? I have seen the worst things, caused by this “Thou shalt not nest!” :)
Do you have multiple components/blocks under the same file, or there is always a one-to-one relation?
No this might work in an ideal world. But e.g. in some cases you might not have access to the markup, because it is coming from a database. So we don't strictly apply BEM but in some cases like our new re-designed item element we use it extensively. The element is also very, very complex and so in some cases we nest, but in general the nesting level is max 2, way less than it was before applying BEM. It depends on the use-case. Also we combine BEM with OOCSS and Atomic CSS, which adds even more classes but keeps the CSS more DRY.
But if everything is in the root scope, how do you avoid to end up in clashing names (e.g. someone decides to use a class name, that doesn't know is already used somewhere else) or in spending time and mental energies trying to find names to the things?
I mean, once someone before me decided to use ".form" for something (where "form-new" is the block part, I mean), and maybe is not really a global "form" style across all the website/application, that name is taken and I will not be able to use it. so I have seen things like ".form-new" ".form-v2" and ".form-new-v2", because of that
We try to use BEM on components level as much as possible, so the form would be a component for us. But we sometimes have issues with our Atomic CSS / helper classes, e.g. something like "pull-left". It happened recently that we had different class names for this and I removed the deprecated one, which was the one everybody used :) In general knowledge sharing with workshops and code reviews is highly important for us. So it is important that people also understand the big picture of the CSS codebase. If they just would do BEM everywhere there might be e.g. a lot of color-definitions which you could also add with a atomic CSS class.
So you say BEM is working well for your project, and within your team. So why did you say that "ITCSS is the way to go"? What happened? Did you started to do BEMIT (as Harry Roberts calls it)?
OK we see ITCSS more of a structural approach for our files and it nicely goes along / combines with our BEM approach. Beginning from the components level we only use BEM but only a very rare cases on the layers below, e.g. objects. So this allows us that we always have our base CSS loaded on pagelaod and then beginning from the components layer we can conditionally load the components. I am still a big fan of having a global CSS but like also to have CSS chunks for your components (which rely on that the base CSS is loaded)
We had a look into BEMIT, but as our structure is working so good for us we didn't yet apply it.
So you are doing BEM + OOCSS + Atomic + ITCSS ? :)
Yes exactly! And the results are convincing us.
Let's talk about the future: I see two big "architectural" shifts on the CSS panorama: CSS Modules in React (and web components in general) and Atomic CSS.
With the first one, do you still see the need for BEM? You just said "We try to use BEM on components level as much as possible", but if the component is really "isolated" like in the case of a React component, and the CSS is "imported" like here:
import styles from './buttons.css' or
import styles from './forms.css'
at that point, why do you need the extra complexity of the B-E-M naming, when there's non risk of name clashing or property overriding/inheritance?
We try to built up a system / base which works for all our applications, some of them already use approaches of web components (we e.g. use already webpack to load and our CSS asyncronously) while others e.g. use wordpress with a way more simple approach to render a site and load their assets. It is important for us that we consider all ways to include our CSS so there will be most likely always a benefit of BEM for us.
OK, and what about Atomic CSS? At the end, it's BEM taken to the extremes, no? Every class is an "helper" (in some way a "*__*--" modifier), everything is in the root scope but because of the naming convention there's no risk of clashes, all the styles are declaratively applied in the HTML itself, no need to create "structure" in the CSS.
I see Atomic CSS only as a useful addition but I would never see the benefit of putting everything into the root scope. Your CSS would become completely unstructured. Also I think this would not make it maintainable anymore nor would it be encapsulated.
I agree.
What sometimes struggles me is that I don't find so many examples of "real world usage" of BEM as I would expect, given the fact that apparently everybody uses BEM. Do you have some preferred Git repository/project that you use as example/reference/inspiration? Or other sources of "real world use cases" that you can share?
What I mean is, of "good use" of BEM that goes beyond the "hello world" examples that you can find on every article or tutorial on BEM. Some large-scale project built using BEM consistently across all the codebase.
Ahaha yes. It is like with the Todo-Apps in the JS-area, there are so many articles and tutorials, but none of them helps you to apply BEM on large scale. We are thinking of making at least a part of our new CSS base public on GitHub. Also because we are curious about the feedback. I like what the e.g. theguardian is doing, they use BEM a lot. I even think they recently started using BEMIT.
You are so enthusiast of BEM. Is there something that you find doesn't work well, of this methodology? Or you simply have "adapted" it to your own taste (see the integration with OOCSS, Atomic, etc.)
Which is what in some way happened with the Agile methodologies: everybody “does Agile” but everyone has chosen his own flavour or pick of them.
“We do Agile but” and is something similar to what I generally hear of BEM: “We use BEM but”, “Yes, we use BEM. Kind of”.
In general I think it is quite bulletproof. And it helped us a lot. But as already said in some cases you might not have full access to the markup or content writers will add some text with a text editor which doesn't automatically add your element classes. So in this case you could write your own / adapt the editor or you just apply BEM where it works for you. And if some Atomic CSS classes make you develop fast and keep your CSS size smaller then we decide to do so.
Ok, make sense. very pragmatic (and smart).
So, last question, To BEM or not to BEM?
If someone should start a large-scale greenfield project today, would you advice her/him to use BEM? or yourself, would you still use BEM or you would go for {name your other choice here}?
Yes definitely! I would advise using BEM and ITCSS and make use of Atomic CSS + OOCSS if needed/suitable.
Good.
That's it, thank you so much for your time!
You are very very welcome! Was a pleasure. And I liked your questions
I know that in the next weeks you are going to present your experience (the so called Project Ironman) at many conferences across Europe. Can you mention them?
Official are Codemotion Amsterdam, Frontend United and ScotlandCSS. A few are pending and not official yet - I already had the pleasure at JSunconf Hamburg
Wow, great!
Thank you so much, thank you for sharing your experiences not only here with me, but also through your posts and your talks. Sharing is caring :)
Hope to see you soon, and thank you again!