Echo JS 0.11.0

Here’s an alternative for PostHTML users:

https://www.npmjs.com/package/posthtml-bem

It’s not as sophisticated as reBEM, but it works quite well for small to mid-sized projects.

My second question is a “reset layout” a good thing? It is completely in non-BEM philosophy of having uncontrolled side-effects.
I think with BEM or CSS Modules, we should think about “local reset” rather than “global reset”. For example, postcss-autoreset, which put reset properties to every block and element selector.
What do you think about it?

Yeah, you might be right with this one, maybe it would be better to have styles reset automated. Though in this case it's not really global, we use reset locally for certain blocks, not globally with tag selectors. Also, theme-reset is absolutely optional, it's just an example.

Great work. Compact syntax is always better
But what is a BEM benefits compare to CSS Modules with React. I thought that BEM should be used only for server-render sites, when it is hard o use CSS Modules. But when you have client-render with React. CSS Modules will have more clear code, than BEM.

CSS modules are great and I personally like them. But BEM is just simpler, more familiar and more flexible. One of the main reasons people might consider to stick with BEM instead of css-modules is cascade. In most cases you can do without it (for example, with BEM mixes https://en.bem.info/method/key-concepts/#mix). But if you want to style internals of the component (for example, Calendar), cascade is much more convenient way to do that (ex: `.some-context__calendar .calendar__day`) instead of having a huge API of different classNames for all Calendar internals.

Cascade seems like very dangerous thing, that kills all benefits of isolation and BEM philosophy. But OK, it is fare point.

But why BEM is more simple? Examples in your article is much more complicated, than with CSS Modules. In CSS Modules you just forget about selector conflicts and write any selector you want (same feeling like with Autoprefixer, when we just forget prefixes rather than writing a mixins). In BEM you need to use (and think of) special methods and CSS functions.

I still don't get CSS Modules, cascade was a powerful feature of CASCADING style sheets. Like in OO or a mixins an object can inherit properties of another. I don't think that conflicts were a justifiable reason for ditching all that power, css just has to be written with a small amount of care and you don't have conflicts. I know you can compose classes but that's not the same as you end up with a larger css base, that's different from say prototypal inheritance in JS which simply uses memory pointers and doesn't cause bloat.

True, cascade can be dangerous, but omitting it completely seems like a bold move — it's just a use case for cascade is very limited.

BEM is simpler to use because it's just a naming convention and doesn't require any tools (reBEM is just a set of optional helpers). It's also simpler to debug because with css-modules classNames are mixed with generated hashes, and with BEM you can clearly understand who is this className belongs to.

I agree, that BEM can be used without any tools. And it is his benefit. But in this article you use so many tools for them, that CSS Modules become more easy.

Compare:
1. You have helpers in JSX and CSS.
2. With CSS Modules you will have helpers only in JSX ;).

Why CSS Modules debug is harder? Does .Logo_name_ke3l45 is more tricky than .logo__name?

It is for some people. I'm not telling that css-modules are bad in general, it's just nice to have an alternative. I know some people who are talking about css-modules as an ugly hack (though I don't agree with them).