Marco Alka What positive aspects?
Starting to feel a bit like John Adams in the play 1776 in regards to Dickinson asking him what's wrong "Sharing the benefits and protections of Great Britain". Benefits? What benefits? Crippling taxes? Cruel repressions? Abolished rights?
What it's for and what it does serves zero purpose if you're not throwing classes at everything, and leveraging your semantics, nesting order, and selectors properly to keep the HTML as small and tight as possible.
Particularly when using classes to say what things ARE and not what you want them to look like.
Take something like a menu, where your BEM re-re's would slop out halfwitted GARBAGE like this:
<ul class="menu">
<li class="menu__item">
<a href="#" class="menu__link">About</a>
</li>
<li class="menu__item">
<a href="#" class="menu__link">Blog</a>
</li>
<li class="menu__item">
<a href="#" class="menu__link">Contact</a>
</li>
</ul>
272 bytes of mentally enfeebled trash doing the job of 131 bytes:
<ul class="menu">
<li><a href="#">About</a></li>
<li><a href="#">Blog</a></li>
<li><a href="#">Contact</a></li>
</ul>
Oh noes, our CSS goes from saying "menu__item" to saying "menu li" as our selectors, notz thatsies!!! or if you're worried about nesting menu > li
When I say this type of rubbish DOUBLES or more the markup written, I mean it. But tell me again how some myth about slower render time is more important than the bandwidth of using twice the markup. Tell me again how it's magically "easier" to keep track of.
The "render time" BS is one of the claims that really yanks my chain -- it's like (making a simile here for those of you who don't know what "it's like" means... no, a simile, I did not misspell smilie!) the myth of the 'render time' of tables being slower. Yes render is DELAYED until the markup is complete, but in that case keep the markup tiny... the render itself is not any "slower" and really if a 386/40 under Win 3.1 with IE5.01 can handle it, people can sierra tango foxtrot uniform about the render time of 'tables' in an age where my bloody phone is an 8 core 64 bit 1.5ghz.
In that same way this claim of "don't use deep selectors" that even Google Pagespeed is how herpaderping as advice holds water like a steel sieve. It's ANOTHER of the many lies resulting in slower, bloated, harder to maintain websites where people are using two to ten times the HTML needed and having to write as much if not more CSS as they'd have had without whatever hot and trendy BS they've been suckered into.
But again, what do I know? I still say there's no legitimate reason for the majority of websites to need more than 48k of CSS in one file per media target like "screen". Anything more than that typically means the developer wasn't qualified to work with HTML or CSS.
... and remember, I Mr. Scott my size estimates.
Same for HTML. I do this crazy thing called "practicing size targets" where I can tell how well written HTML is with simple math. Content should dictate document structure. Content + structure should dictate the markup. Content structure + markup + device capabilities should dictate layout (and therein the stylesheet) for each media target. As such if you know what the content is, and what things like contentn media elements (images, videos) and behaviors (anchors, forms) are going to be present, you can estimate how big the HTML should be!
Expected HTML size in bytes = 2048 +
plaintext 1.5 +
content media elements 256 +
form elements 128 +
anchors 128
Content media elements being images / videos that are actually CONTENT and not part of the skin/template, form elements of course being input/select/textarea.
That is how big the markup for a normal website should be, if you exceed those numbers it is probably poorly written. If you are two to ten times those numbers you need to back away from the keyboard and go take up something a bit less detail oriented like macrame.
The above numbers INCLUDING room full formatting and closing comments on your DIV; so no cheating via minification!
But even when under those numbers, a LOT of times the code can still be bloated nonsense. If you're 30% under those numbers, or 50% or more below minified, it's possible you've forgotten to include non-optional elements resulting in invalid markup.
Look at getbem's site where they 'cheat' by omitting the flipping HTML tag's opening/close, and the close for BODY. This isn't HTML 3.2 you're making the browser work harder and have to GUESS!
Their ~7k of minified markup on the home page being well under the above formula, but had I written the same page that doesn't warrant the use of more than 5.3k of unminified code -- so probably around 4.7k minified?
Not quite half, but pay attention to the fact that they don't even use BEM on the majority of code ON A BLOODY FLIPPING SITE ON THE TOPIC!!! They have a little thrown in here or there, but they don't really go all-in on it.
Let that sink in. Like many evangelists at the pulpit they don't even practice what they preach.
Also why I laugh when I see people minify their HTML when most of the time I'd have less code WITHOUT wasting time and effort on that step.
Of course all I need to know about the competence of the folks promoting these types of techniques is apparent when they throw a class like "button" on an anchor tag, or "btn" on a BUTTON tag. Ermahgerd aherpaderp!