To BEM or not to BEM : Razvan Spatariu
“Don’t assume it will auto-magically solve your scalability issues. It is a good start, but there is a lot of work to be done.”
Date: 15 May 2016
Q. Hi Razvan, thank you for accepting to be the next interviewee for this project.
First of all, some introductions: I know you work at Funding Circle, here in London. What is your role in the company, in which team do you work?
Indeed, I work at Funding Circle. I am a Frontend Engineer there (since December 2014). We are a fairly small FE team (5 people) so we shift around in different teams. Right now I am working in the Investor team (taking care of the experience for the users that invest money using our platform), but I think it’s fair to say that my self-assigned role in the company is to always remind everyone about the importance of CSS and good CSS architectures :)
Q. So you are the “CSS guy” I understand. Are you the only one working on the CSS codebase, or are there other people getting their hands dirty with classes, selectors and properties? How do you split the work? Someone works on the CSS and someone else does the JS (where the HTML is everyone’s land) or is more of a hybrid approach?
I ask because I see more and more the rise of a CSS developer figure, in many companies (mine included), thing that up to a few years ago was inconceivable.
Q. So, a small front-end team, 5 people. Why the need for adopting BEM? Was not the simple “team communication” enough?
A. Great question.
I strongly believe that the way you architect your CSS is not related to the size of your team or the hype / trend at that moment. I think it is more related to the product that you are building. And talking about the product, a really important part on deciding that BEM is the way to go was played by our design team.
Sitting with the design team, looking at what we had in the past in Funding Circle, looking at what we want to build in the present and future, everything yelled: components.
And when it comes to components, I think BEM as a base methodology (with sprinkles from others) is the way to go.
And related somehow to the numbers of people working on the codebase, BEM is also quite easy to understand by non-front-end people. And considering that only in the UK we have around 80 back-end devs, using BEM to keep everything under control made sense.
Q. You talked about CSS architecture. Last week I saw a tweet about the CSS Architecture being “organising stylesheets” which in some way is terribly right, but at the same time is drastically wrong, in the same way as “programming” is “writing lines of code”.
Are we over-engineering something that should — and could — be much much simpler? (at the end, is not even a programming language, is a presentational / declarative language)
Or actually there is a real problem to solve? And in that case, why is BEM the right solution in your case, in your opinion? What problem do you have with the back-end developers? :)
A. We are far from over-engineering. I can say that CSS is easy because it is declarative. But I can also say that CSS is hard because it is declarative. Styling a page with CSS is easy. Making a scalable, organised CSS architecture where a new joiner can come and understand where / how to use existing code is hard.
Q. Great response :)
A. I was looking at the existing CSS codebase, written by various people in 5 years of crazy growth for our company. Because it wasn’t started with scalability in mind we found it really difficult to maintain.
Mostly because there was no logic in including Sass partials in compiled stylesheets.
We now took the idea of BEM and components and decided to create small partials corresponding to each component.
The result of that is that you won’t include that
_clear.scss 30 times in your project because it’s imported in files that are imported in a main file and everything makes sense now.
Q. But “making sense of things” could not be achieved without BEM? With good practices, clean code, team communication and some documentation?
Importing 30 times _clear.scss is not inherently a problem of CSS or Sass, but of how people work. Could you have achieved a good “CSS architecture” without BEM, in your case?
A. You are right. BEM does not translate to “making sense of things”. If it’s a logical decision that can be understood and extended by anyone in your team just by reading the code / documentation, then it’s the right decision.
In our case, BEM made sense because we wanted a modular approach for the platform and helped us integrate it easier with our always-work-in-progress pattern library. Being able to copy/paste an HTML structure with existing classes without the fear of uncontrolled bleeding / inheritance of styles was really important for us.
And, from the start we knew that only by adopting BEM wouldn’t be enough. It would just solve the problem of nested selectors and brittle CSS.
One advice for anyone thinking about BEM: don’t assume it will auto-magically solve your scalability issues. It is a good start, but there is a lot of work to be done. We had to bend the rules a bit and use ideas from other methodologies so that things are still under control.
Q. You say “adopting BEM isn’t enough” and “bend the rules a bit and use ideas from other methodologies”. Can you be more specific? What part of BEM didn’t work well (or well enough) for you? Or what BEM is missing, for example.
A. Well, as I was saying before, you need to structure your files well. We did a project where we used BEM but structured the partials according to the page that we were building (e.g.
_about-us.scss) and importing it into the main stylesheet. I still cringe about that decision and it’s still a hot topic in our front-end meetings. Then we switched to component partials and everything is much better now.
Then there’s the good ol’ saying “naming things is hard”. When writing CSS I think I spend most of the time thinking on how to uniquely name my BEM blocks.
Also, I think the biggest disadvantage of BEM is that it was built for static components. So, when I say “we bent the rules” I mean: we had to adopt state classes from SMACSS. And a bit of OOCSS + ITCSS by creating prefix-named reusable utility classes (e.g.
Q. I’ll come back to the components in a second, but before another question.
You were talking about “reading the code” which is one of the main issues I have with BEM (not only in the CSS/Sass/Less files, but also in the HTML files with the proliferation of class-names that make my eyes cry)
I mean, this is real code from a real website:
<div class="select select-theme-default select-element select-enabled select-abutted select-abutted-left select-element-attached-top select-element-attached-left select-target-attached-bottom select-target-attached-left select-open">
Anyway, about reading the code: did it already happen to you to refactor your own code, maybe written 6 months before? How did it go?
And someone else’s code structured using BEM? Went well in the same way?
The question is: is it easy to read and work with BEM code that you have not written, or that you have written but you don’t remember anymore how and why you have built in such way?
A. My opinion is that if you don’t cringe over the code you wrote 6 months ago and say “what was I thinking?”, you’re doing it wrong.
Q. Ahahahh :)
A. We did refactor a lot of HTML / CSS from the code that we wrote less than a year ago and it went decent. The main reason for refactoring is because we chose the wrong name for a component.
Regarding the BEM class names, I wish I had a smart answer to give you, but in all honesty, they are ugly. But we will never have the perfect solution. You just have to weigh the pros and cons and I think ugly class names are a small con when compared to the pros.
And looking at your example, I think that is a perfect demonstration of how BEM is not suited for all projects.
Sometimes you have to look at the design patterns in a different way. And if you have so many variations of a single element, maybe it’s time to have a chat with your design team.
Q. OK, but then when you work with components, why the simple namespacing is not enough? What value BEM adds, in your experience?
I mean, if you have a component, let’s say a breadcrumb, why do you need:
plus all the modifiers, when you could simply use
If you have a component “breadcrumbs” no one is going to create a second component or override its properties, with or without BEM, without clearly doing something wrong.
Why don’t we “CSS developers” can do and learn the same, and stop polluting the global scope? why can’t we just namespace, in the same way as in JS you use closures?
What BEM adds in your experience?
A. I’ve asked myself in the past the exact same thing. If we look at components individually, yeah, it makes no sense to use BEM.
But if we look at a real-life project, if you want to scale and reuse code, you might end up with components INSIDE components.
Take this example:
<h2 class="title">This is my sidebar</h2>
<h3 class="title">Title of a component inside another component</h3>
In this case
.sidebar .title will bleed into your
Q. Ok, makes sense
A. You could, of course do some specificity magic and avoid this, but then you end up either with an ugly CSS or with CSS that is tightly connected to your HTML structure, making both of them brittle.
Q. But are
article actually components? in Atomic Design they are more at the “templates” or “pages” level
So maybe we could find a different way to assign the style, maybe less based on “where they are in the DOM”, and more on “what they look like”
Anyway, there is no clear simple solution for that, it’s years we are struggling with it :)
I have another question, that interests me a lot.
One of the strength point of BEM in my opinion is that, whoever will join your team, be it a newcomer or a junior developer, he/she will probably know BEM (at least in its own basic rules, and whatever happens, he will always be able to find resources on BEM online, on stackoverflow, on Google, etc.)
As compared to “having our own special naming conventions” that probably will require some time to understand and master
Did it already happen to you to have a newcomer or a junior developer joining the team? how did it go, how it was his impact with BEM?
A. Before answering your question, I want to add something to what you’ve said “it’s years we are struggling with it”.
A. That is the beauty of front-end development and that will always be the case. We’ve come a long way and we’re not even close to what can be achieved. We started with using
<table> to create faux columns, we continued with quirky floats / clears, now we’re moving to flex while looking forward to grids. I think BEM is one of those things. We’re gonna look at BEM in a few years and say “how could we work that way? Now it’s so much easier with <insert solution>.”
Q. You’re so right :)
A. To answer your question: yes, we did have 3 new joiners in our team since we started using BEM regularly. All of them were already familiar with it, so it went very smooth. And I’m very happy to say that we improved the way we write our CSS since they joined.
Also, as you’ve said, being able to Google something is invaluable :)
Q. Ok, let’s go back to the components.
Web Components and the “React revolution” on the other side (like it or not, it changed a lot in the way we look at the front-end today)
If we look at BEM, on one side it makes total sense for a framework or a component library, where everyone can pick and use a component and you don’t know (and don’t have control) where and how he/she will use it.
But on the other side, as you also said before, at a component level BEM loses its own reason of being.
If then you add the way in which CSS Modules are integrated within React (and I expect other frameworks will start to do the same) all the reasons that led to BEM, all the inheritance and leaking problems that we have, they all appear to be magically solved. Is this the case, do you think? Or simply we have not yet discovered where the downsides of this approach are?
A. As I was saying before, we’re gonna look back at BEM and cringe. BEM will cease to exist when it will not be needed anymore.
And CSS modules might be the way to go in the near future. But I hope that the solution to the inheritance problem in CSS will come from CSS.
It might be the unpopular opinion of the day, but I think JS should be kept away from CSS. If today we need to involve JS to fix CSS, then we still need BEM, as we want to build apps that are not JS dependent.
Q. I am pretty sure a lot will come in the very near future, about CSS and JS.
Anyway, my last question is the same I asked to Christoph Reinartz last week: 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 choose BEM?
A. There is no black or white answer. I would say: BEM if it makes sense. Take a step back, look at your project as a whole, understand the design language, find the patterns and then take an informed decision, not a trendy one.
Q. Great answer, again :)
One very last question: you are one of the organisers of London CSS meetup, one of my favourite events here in London. When will be the next appointment?
A. First of all, I never got to thank you for all the great advices you gave us for this meetup. So… Thank you!
Organising this meetup is very important for us and we noticed that the community is really interested in it, as this is kind of a missing piece in the whole London frontend meet-ups puzzle.
We are looking for speakers for the next one (if anyone is interested, tweet us at LondonCSS or you’ll end up with me rambling about Sass for an hour :D), we also are looking into finding more venues where we can host it (again, LondonCSS if you have a venue).
Q. Thanks you for your time. It’s a sunny Sunday here in London, so you would be probably in a park or along Southbank at this time, sipping Pimm’s or enjoying the nice weather. So thank you again Razvan, I really enjoyed our conversation.
Razvan Spatariu is currently working as a Front-end Engineer at Funding Circle where he works on improving the quality and scalability of their front-end.
Loves everything CSS related and has an unhealthy obsession with using Sass as a programming language.
Big fan of a happy designer–developer relation.
Co-organiser of London Sass Meetup.
This is the second of a series of ten interviews, originally published at www.didoo.net/to-bem-or-not-to-bem.