Shared publicly  - 
Great review by kangax of the BEM style of frontend architecture. This style is emerging as the best scalable approach these days. Snook and +Nicolas Gallagher also promote similar methodologies.
I read this BEM article ( 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 ( 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.
Jamis Charles's profile photoMickael Daniel (mklabs)'s profile photoRavi teja's profile photopeng mengc's profile photo
The problem with these component-based methodolgies is that talk about html, but are heavily influenced by css. In the long run, this is counter-productive. It might work for separate projects, but code still isn't portable over different projects.
Interesting, but those incredibly long class names make me cringe. I know with GZipping etc there hardly any performance hit, but still.
Add a comment...