I read this BEM article (http://coding.smashingmagazine.com/2012/04/16/a-new-front-end-methodology-bem/) couple of times and it's really interesting, but I'm having a hard time understanding how this would fit into a real workflow.

There's this other video by the authors (http://video.yandex.ru/users/ya-events/view/302 in russian), which shows some examples.

Much better.

Seems like advantages of using BEM (in the video) — comparing to more classic layout/styling — boiled down to:

1) Prefer classes over tag names
- element might change
- another element of same type might be added

2) Prefer classes over ids
- element might need to be duplicated

3) Avoid cascading
- performance is better
- easier to move things around without breaking things (at the cost of being overly explicit)

So if you stick to these rules, you get all the flexibility benefits of BEM without adhering to its structure? Structure itself is a benefit (and overhead) of course.

Things I'm skeptical about (=need more research):

- How much overhead is it to change/move things around when styles/behavior are so segregated?
- How do you create MVC-style apps, when JS/behavior is confined to a block? Do you think in terms of blocks or views? Are these the same? What if relationship is more complex than 1-to-1? Or do you ditch this type of organization for more complex apps?

Need to dig more / try using it.
Shared publiclyView activity