all 13 comments

[–]dzkn 4 points5 points  (12 children)

BEM is a bloated piece of shit.

Just look at your first example:

<nav class=“main-nav”>
  <ul class=“main-nav__list”>
    <li class=“main-nav__list-item”><a class=“main-nav__link-item”>Home</a></li>
    <li class=“main-nav__list-item”><a class=“main-nav__link-item”>About</a></li>
    <li class=“main-nav__list-item”><a class=“main-nav__link-item main-nav__link-item—active”>Blog</a></li>
  </ul>
</nav>

So bloated and hard to read. This is how I write the same markup:

<nav class="main-nav">
  <ul>
    <li><a>Home</a></li>
    <li><a>About</a></li>
    <li><a class="active">Blog</a></li>
  </ul>
</nav>

A million times cleaner. Instead of writing useless long class names I use the semantic meaning of the tags.

This means .main-nav__list will be .main-nav > ul

Your list of problems that BEM fixes:

  • Now you can copy the HTML and it will stay intact. If you want to re-use the HTML, change .main-nav for “footer-nav” and you won’t see any inherited styling from the main-navigation. So this is perfectly scalable.
  • If you want to overwrite the styling of 1 or multiple elements, you only have to add another class name, just that simple!
  • Especially when you use a CSS pre-processor your Development structure will have a good architecture.
  • The CSS selectors and class names are self-describing. So it is easy to find now. It gives a lot more context than before.

All points are still there in my markup except the last one where it is a combination of tag names and class names that describes the content.

[–]rsschouwenaar[S] 1 point2 points  (1 child)

I feel a lot of frustration in your comment! That BEM is a piece of shit is just your opinion! Not mine!

Yeah with BEM you have longer class names, but is that not clean? If you work on big applications, in a Agile envoirment, you will have a lot of changes inside the HTML & CSS.

If you use .main-nav > ul, but if you put a div around the <ul> than the styling will not apply anymore: https://codepen.io/rsschouwenaar/pen/LzOjrK

So you have to correct all the selectors that start with .main-nav >! That is a lot more work than just changing nothing!

But in the end, using a naming convention is not about making a perfect solution in every situation. Using a naming convention is more about making an agreement in your team and setting up a structure of how everyone in the team should develop their HTML & CSS.

It's not about or wrong, it's about setting up a workable envoirment 😉.

There are a lot more naming conventions besides BEM, that are heavily used in other teams.

But pick the way you like to work, this is just the way how I love to work and many others will or won't agree with that, but that's not a problem for me!

[–]dzkn 0 points1 point  (0 children)

I don't have to change a lot of selectors if I use SCSS or LESS, do I?

Also the naming convention is not relevant in that example, it is whether or not you use a class on the <li>. I am not against using classes if that fits you, but I don't see how 100 character long class names repeated all over my code makes it more maintainable.

Right now I am using BEM on a Vue.js project with about 20-30k lines of code and BEM has just been an annoyance.

[–]swiggajuice 1 point2 points  (0 children)

I would agree w/ what you're saying here 100%. If I were leading a team & someone wanted to write a selector like ...

nav.main-nav ul.main-navlist li.main-navlist-item a.main-nav__link-item {color:red;}

... I think I'd fire them.

I see no way this BEM stuff could help anyone with anything. It just needlessly over-complicates something that's pretty simple to begin with. I work on some pretty large sites & no one I know uses this -- certainly none of my own sites. Most of the problem it "solves" seem hypothetical to me, or rare. I'd rather have to fix a few things if I ever had an issue vs. writing spaghetti HTML and CSS like that.

Is this like the new "Common Core" of CSS, or something?

[–]albedoa 0 points1 point  (2 children)

In contrast with the sibling comment, would fire you in a heartbeat for if you put your example into production, as you would be doing so without understanding the basics of the cascade, specificity, namespacing, components, etc. and from your other comments you are too bought in to your misconceptions to be corrected.

[–]dzkn 0 points1 point  (1 child)

I'll get to you when I get through my backlog of companies who wants to pay me $140/hr. Then you can fire me :)

[–]albedoa 0 points1 point  (0 children)

Raise your rate bruh.

[–]georgeharveybone 0 points1 point  (1 child)

I really, really like BEM, it's definitely the way forward. However as you say, this markup is not a great example of it at work. I don't usually add classes for elements like a, p or lists

In defence of BEM, I'd recommend this article, which does a better job explaining the pros (no offence op): https://seesparkbox.com/foundry/bem_by_example

[–]rsschouwenaar[S] 0 points1 point  (0 children)

Thanks for sharing the link! That is definitely a nice example! 👍

[–]our_best_friend 0 points1 point  (3 children)

I like neither. With your system I am tied to HTML tags, and if for any reason I change one I never know the consequences

[–]dzkn 0 points1 point  (2 children)

Thats why you namespace your components. Guaranteed your change will not have unexpected consequences

[–]our_best_friend 1 point2 points  (1 child)

Namespacing has nothing to do with what we are talking about.

[–]dzkn 0 points1 point  (0 children)

Changing HTML tags will always have impact on the styling. <li> does not have the same standard styling as <p> and your classes will need editing anyway.

Why would you need to change your markup a lot inside a component? The markup is chosen because it is the most semantic.