Do the pros outweigh the cons?

[kaelig]

Pros:

1. Nice abstraction
2. Enforces consistency

Cons:

1. Developers have to learn this thing (and look at the configuration of the library before they can write markup)
2. Hard to lint and enforce its usage in a team
3. Makes the codebase absolutely nightmarish to grep

I insist particularly on con # 3. Because it's impossible to search for things like block__element in the .scss files, this abstraction makes onboarding new people on a codebase or trying to refactor very difficult.

Do people use bemify on large projects in teams of more than 2 people? If so, what were the results?
Would it be fair to warn potential users of this library (in the README for example) that this might have adverse effects on the searchability of their codebase?

[franzheidl]

Hi Kaelig, thanks for your interest and taking the time for your questions and remarks.

First of all, bemify is an approach I made to make my life easier when writing SCSS in my projects, it exists solely as a proposal as to how this could be achieved, I’m not saying you have to use it, or that it is the only way to achieve what it tries to achieve, not at all.

1. True, and that is true for any new technology, abstraction or convention in software development. Bemify specifically was written to reflect the mental model of BEM directly when writing SCSS, so if anyone has a problem with this mental model or is not really into it, he’ll not get much out of using bemify.
2. Yes and No I think. Hard to lint as much as any more complex SCSS codebase that uses complex mixins/logic to create selectors dynamically. Re enforcing its usage on a team, that is true as much or not as with any other convention. I believe it’s up to a team to decide whether a technology or convention works for them or not.
3. 3.1 Sourcemaps!
   3.2 Yes, hard to grep if you’re after a specific element/modifier/state selector. You’ll only be able to get the block name and then have to find the element/modifier/state inside.
   3.3 I prefer human-readable code over grep-able code anyway, especially when you have additional source maps that will tell you exactly what came form where. In my experience, that makes for a much more maintainable codebase, but I concede this is dependent on context/team-/project setup, and I’m sure there will be people with a different experience/opinion they’re perfectly entitled to.

Bottomline: I believe it is up for each designer, developer or team to decide whether the pros outweigh the cons, according to their circumstances, priorities and preferences.

Oh, and I don’t know if other people use bemify on larger teams/projects (I do, and have been happy with it so far) – I’d be interested to learn that myself!

[bramsmulders]

The first question in my head when i found out about this project:

I get your point @franzheidl, but i really cannot imagine when someone would prefer to write this:

@include block('my-block') {
    @include element('element') {}
    @include modifier('modifier') {}
}

instead of:

.my-block {}
    .my-block__element {}
.my-block--modifier {}

What you gain is not writing .my-block every time, but what you get back for that is writing all those @include X statements. It just feels so cumbersome to write all those extra code just to create something very simple.

BEM is invented to make css more maintainable, readable and simpler for developers. In my opinion you just made a super simple syntax a lot harder to understand.

It seems that you just created a mixin library just for the sake of creating a mixin library. And that is your good right of course, don't get me wrong. But i think the real power of scss lies within the fact that you can stay as true to css as possible while gaining some programatic possibilities.

As with all in life: Use what you like to use, do what you like to do ;) i'm not going to use this abstraction.

[demrks]

@bramsmulders I might be wrong, but as far as I know you can always use & if you don't feel like writing .my-block every single time:

.my-block {
    &__element { }
    &--modifier { }
}

See: http://www.sassmeister.com/gist/ae2906d885544943b48c

[kaelig]

@demrks I'd avoid using this syntax as well, it makes it really hard to search the codebase for my-block--modifier.

[demrks]

@kaelig So do I... I always used

.my-block {}
    .my-block__element {}
   ...

and never had any problems with it (+ you can easily search your codebase). But if I was trying to avoid writing .my-block over and over again, I'd rather go for the much shorter & syntax. For me, the @include syntax seems a little bit long, especially if I had to write lots of selectors.

[franzheidl]

That's all fine gentlemen, I never said you had to use this approach. I see any piece of OSS software as an offering, a proposal to the community. It is up to each individual or team to make their choices and use or not use it, that's fine.

@kaelig As stated earlier, I personally would prefer human readable code that clearly states what it does over grep-able code any day. You don't have to, of course. For me, source maps do the job just fine.

@demrks The way you use .my-block__element inside a .my-block scope will always result in nested .my-block .my-block__element selectors. This will work (and might probably even be preferable for some), but using nested selectors for elements inside blocks it is not the idea of BEM or any of the other approaches to roughly the same thing that I referenced in the RM.

Anyway, thanks for the discussion, closing the issue now because it is not really about an 'issue' with the software itself. You can of course keep discussing in here if you wish.

[demrks]

@franzheidl Sorry, I might have missed something, but as you can see in this SassMeister Gist, the & approach doesn't create nested selectors (libsass or SASS 3.4 / 4 alpha).

[franzheidl]

That's true. In the example you posted above there's no &to be found though…