BEM CSS: Okay or Terrible

[JingleH]

Hello friends, just checking on a potentially personal and opinionated thing, and let me if know discussions around it already happened and concluded:

- How frowned upon will it be for a block to use CSS in the BEM approach?

My immediate thoughts are longer class names leading to more code/bytes in css and js files, but for pages with non-trivial number of nodes, layout, rules, interactions and reflow, it might help reduce quite some TBT/INP caused by a non-shallow CSSOM/Render tree and expensive rendering & style recalculations.
As a consumer, I know I can build my blocks however I want, but as we're onboarding new people, I'm hoping to get more discussions/insights and help me explain & justify why we're not doing it. I might be able to do an experiment/comparison using one of the more involved Express block later too, but if someone from the community already proved it, it can save me some time 😆.

[auniverseaway]

How frowned upon will it be...

Frowned upon is probably the right phrase.

Forbidden: no.
Bad idea: no
Recommended: no.

it might help reduce quite some TBT/INP caused by a non-shallow CSSOM

I would lean into the words, "it might help..." if you don't know for certain, the general rule in Helix land is to not try to solve problems that don't actually exist. I would guess in this specific example, you likely wouldn't see any tangible benefits on TBT/INP. As a reminder: CSS selectors work backwards. They start with the lowest selector and work up the tree...

.my-block > .my-child

is less performant than

.my-block .my-child

Not only does the browser have to look up based on selectors, but it then has an additional check to see if the element is a direct descendant. Keep in mind: Milo does not have an INP problem right now (without martech). We know this from CWV data.

I'm personally not opposed to BEM, and have often wanted double hyphens without stylelint getting upset, but I haven't been bothered enough to change the linting rules. These are the rules Milo inherits from the larger Edge Delivery community.

It's also worth noting that even in a non-BEM world, Milo has probably only shipped two collisions in its 2+ year lifespan... which is one of the drivers of BEM. So you're back to solving problems we don't necessarily have in Milo. If it was my personal decision that did not take into the broader community into account, I would probably choose SUIT CSS which is a slightly less obtuse naming convention system. I think it would require less JS to decorate the DOM, too.

...as we're onboarding new people, I'm hoping to get more discussions/insights and help me explain & justify why we're not doing it.

From an on-boarding perspective, the Milo Community is in lock step with the larger Edge Delivery community with the current linting rules. When you deviate, anyone who is used to other Edge Delivery projects will have work to do to learn the system you chose. I would not change just to satisfy some onboarding request because that's what they have used in the past. These types of conversations could also be said about build systems, React, etc.

I would also argue, when you don't deviate from the OOTB stylelint configuration, there's also less work to maintain custom rules. The moment you deviate, you are responsible for maintaining your rules. That's work you have signed yourself up for instead of building software. You have to ask yourself if that overhead is worth it.

If this is for Express, you also have to take into account the larger community here. If Express decided to ship their own CSS conventions, you will differ from Milo. Any time an engineer has to move between the two projects, they will have to re-learn whichever system they are working on.

To implement BEM:

1. BEM requires more code (JS & CSS).
2. BEM will require more engineering oversight for compliance.
3. BEM will require more engineering education to achieve number 2.

BEMs advantages:

1. Reduce scoping collisions (something we don't really have today)
2. Better for engineers who are familiar with it (the minority of our staff)
3. ... (the INP argument is questionable)

If you feel like your project has the complexity to warrant deviating from Milo and Edge Delivery communities and you have advantages that outweigh the disadvantages, I'd consider it. If this is motivated by your comment, "...as we're onboarding new people" and you're just trying tamp down questions, I would not consider it. Someone will always have a pet feature, framework, or naming convention they want to use on your project.

Hope this helps.

[JingleH]

Thanks @auniverseaway! This man always breaks expectation when it comes to expecting a detailed answer for a question 😉! Just to strengthen your arguments, for whoever that might read this later, regarding advantages of BEM:

1. Collisions happen more in Express due to some legacy css and design of dom structure, but we always manage to work around it with plainly more javascript or class names.
2. This can also be a our community vs. other trends thing. I feel that some of the philosophy represented by our community is still less visible compared to other forces (like ones coming from SPA or SSR world), so we definitely want to stay more cohesive and grow as a community. Eventually we'll hit a point where junior or people coming from different contexts naturally and intuitively fit into our rhythm and and we won't need much "onboarding".
3. We are exploring a browsing experience with potentially infinitely scrolling and quite some nesting within each element. We are not planning on dealing with the complexities of virtualization just yet, so the number of nodes can theoretically grow to a point that can affect INP. I still need to test out the idea and verify which can happens first: INP impact starts becoming significant, or the visitor behavior can be classified into an edge case. Such a block could be an interesting case study for testing out different approaches and assumptions (not just BEM) so I might update in the future if i get the chance

[overmyheadandbody]

I'd say that Suit, as referenced by Chris is a good iteration of BEM. We're planing on creating a document with some CSS best practices for Milo developers in the future, Suit will definitely be part of the inspiration for it.

Performance-wise, I'm not sure we'll get measurable improvements with either of them. However, any of them would definitely be an improvement over some selectors we currently have, like .table.merch.button-right .row-heading .col.col-heading .buttons-wrapper > *. As Chris mentioned, this selects all elements on the page, then looks at the parent of each, checks whether it matches .buttons-wrapper, checks its parent and whether it matches a class and then the other, etc. That is simply not a performant selector.

So in my mind, the issue to be solved is sticking to a convention for ease of readability and avoiding context switching overhead, whatever that convention may be between the 2 models.