LESS와 같이 중첩 가능한 스타일 시트 언어를 사용하는 것보다 BEM을 더 좋게 만드는 것은 무엇입니까?

저의 동료는 그가 강요하고 있는 프로젝트에서 CSS에 대한 BEM ( Block Element Modifier ) 방법을 강하게 추진하고 있으며 , 우리가 몇 년 동안 작성한 LESS CSS보다 무엇이 더 나은지 이해할 수 없습니다.

그는 "고성능"을 주장하지만이 코드 샵에서 작성하는 웹 응용 프로그램의 종류에있어 성능이 얼마나 중요한지 상상할 수 없습니다. 우리는 여기서 트위터 나 페이스 북을 만들지 않습니다. 가장 많이 사용하는 앱의 월간 조회수가 10000 회 이상 이고 대부분 1000 미만인 경우 매우 놀랍습니다 .

그는 "가독성"과 "재사용"을 주장하지만 LESS는 이미 제 생각에 훨씬 더 잘하고 있습니다. 그리고 BEM은 이러한 초장 급 클래스 이름 전용 수십 개의 추가 문자를 사용하여 마크 업을 심하게 망쳐 서 가독성을 크게 떨어 뜨린다 고 생각합니다 .

그는 "중첩 CSS는 반 패턴"이라고 주장했다. "안티 패턴"이란 무엇을 의미 하며 중첩 된 CSS가 나쁜 이유는 무엇입니까?

그는 "모두가 BEM 사용을 향해 나아가고 있기 때문에 우리도 그래야한다"고 주장했다. 내 카운터는 "모든 사람이 다리에서 뛰어 내리면 따라가겠습니까?"입니다. 그러나 그는 여전히 이것에 대해 완전히 단호합니다.

누군가가 BEM을 LESS보다 나은 점을 자세히 설명해 주시겠습니까? 제 동료가 저를 설득하는데 실패했지만, 선택의 여지가 있는지 모르겠지만 따라야합니다. BEM을 진지하게 받아들이는 것보다 BEM을 높이 평가할 수 있기를 바랍니다.

저의 동료는 그가 강요하는 프로젝트에서 CSS에 대한 BEM (Block Element Modifier) ​​방법을 강하게 추진하고 있으며, 우리가 몇 년 동안 작성한 LESS CSS보다 무엇이 더 나은지 이해할 수 없습니다.

BEM은 CSS 방법론입니다. 다른 것들은 OOCSS 및 SMACSS를 포함합니다. 이러한 방법론은 확장 성이 뛰어나고 재사용 가능한 모듈 식 코드를 작성하는 데 사용됩니다.

LESS는 CSS 프리 프로세서입니다. 다른 것들로는 Sass와 Stylus가 있습니다. 이 전처리 기는 각 소스를 확장 CSS로 변환하는 데 사용됩니다.

BEM과 LESS는 서로 "더 나은"것으로 비교할 수 없으며 다른 목적을 수행하는 도구입니다. 특정 문제를 해결하기 위해 유틸리티를 고려할 때를 제외하고는 스크루 드라이버가 망치보다 낫다고 말할 수는 없습니다.

그는 "고성능"이라고 주장합니다 ...

다음과 같은 고전적인 CSS 스타일 사이에서 성능을 측정해야합니다.

.widget .header

그리고 BEM 스타일 :

.widget__header

그러나 일반적으로 CSS 선택기 성능은 병목 현상이 아니며 최적화 할 필요가 없습니다.

BEM "성능"은 일반적으로 개발자의 성능 작성 코드와 관련이 있습니다. BEM 방법론이 일관되고 정확하게 사용되면 개발자 그룹이 스타일 충돌없이 고유 한 모듈을 동시에 작성할 수 있습니다.

그는 "가독성"과 "재사용"을 주장한다 ...

나는 새로운 개발자에게 BEM이 더 읽기 쉽다고 말할 것입니다. 클래스의 의미와 구조에 대해 잘 정의 된 지침을 제공한다고 말할 수 있습니다.

같은 수업을보고

.foo--bar__baz

상태에 있고 요소를 포함하는 foo블록 이 있다고 알려줍니다 .barbaz

나는 BEM이 클래식 모델보다 더 재사용 가능하다고 절대적으로 말할 것입니다.

두 개발자가 블록 ( foo및 bar)을 작성 하고 두 블록 모두 표제가있는 경우 이름 충돌에 대한 걱정없이 다른 컨텍스트에서 블록을 안전하게 재사용 할 수 있습니다.

고전적인 맥락에서의, 때문에 그 .foo .heading와 .bar .heading충돌하고, 가능한 경우에 따라 해결 될 필요가 특이 충돌을 소개한다.

BEM 사이트에서 클래스는 .foo__headingand .bar__heading이며 결코 충돌하지 않습니다.

그는 "중첩 CSS는 반 패턴"이라고 주장했다. "패턴 방지"란 무엇을 의미하며 중첩 된 CSS가 나쁜 이유는 무엇입니까?

"반 패턴"은 숙련 된 개발자가보다 적합한 대안보다 배우고 사용하기가 더 쉬운 코딩 패턴입니다.

중첩 CSS가 나쁜 이유 : 중첩은 선택기의 고유성을 증가시킵니다. 특이성이 높을수록 재정의하는 데 더 많은 노력이 필요합니다. 경험이 부족한 개발자는 종종 CSS가 여러 페이지에 영향을 줄 수 있으므로 다음과 같은 선택기를 사용합니다.

#something .lorem .ipsum .dolor ul.sit li.amet a.more

숙련 된 개발자가 CSS 가 여러 페이지에 영향을 미치지 않을까 걱정할 때 다음과 같은 선택기를 사용합니다.

.more

그는 "모두가 BEM을 사용하는쪽으로 나아가고 있으므로 우리도 그렇게해야한다"고 주장했다.

그것은 악의적 인 오류 이므로 나쁜 주장으로 무시하십시오. BEM 지원에 대한 잘못된 주장이 BEM이 좋지 않다고 믿을만한 이유가 아니기 때문에 오류 로 인한 오류에 빠지지 마십시오 .

누군가가 BEM을 LESS보다 나은 점을 자세히 설명해 주시겠습니까?

나는 이것을 전에 다루었 다 .BEM & LESS는 비교할 수 없다. 사과와 오렌지 등

제 동료가 저를 설득하는데 실패했지만, 선택의 여지가 있는지 모르겠지만 따라야합니다.

OOCSS, SMACSS 및 BEM을 살펴보고 각 방법론의 장단점을 팀으로 평가하는 것이 좋습니다. 형식의 엄격함을 좋아하고 추악한 선택자를 신경 쓰지 않기 때문에 BEM을 사용하지만 자신이나 팀에 적합한 것을 말할 수는 없습니다. 대변인이 공연을하게하지 마십시오. BEM에 익숙하지 않은 경우 팀에서 지원하기 쉬운 다른 대안이 있다는 점에 유의하십시오. 동료와의 입장을 변호해야 할 수도 있지만 장기적으로는 프로젝트 결과에 긍정적 인 영향을 줄 수 있습니다.

BEM을 진지하게 받아들이는 것보다 BEM을 높이 평가할 수 있기를 바랍니다.

BEM 작동 방식을 설명하는 StackOverflow에 대한 답변을 작성했습니다 . 이해해야 할 중요한 것은 이상적인 선택기가 0-0-1-0오버라이드 및 확장하기 쉽도록 특이성을 가져야한다는 것입니다 .

BEM을 사용한다고해서 LESS를 포기할 필요는 없습니다! 여전히 변수를 사용할 수 있고 @import를 계속 사용할 수 있으며 중첩을 계속 사용할 수 있습니다. 차이점은 렌더링 된 출력이 하위 체인이 아닌 단일 클래스가되기를 원한다는 것입니다.

당신이 가진 곳

.widget {
    .heading {
        ...
    }
}

BEM을 사용하면 다음을 사용할 수 있습니다.

.widget {
    &__heading {
        ...
    }
}

또한 BEM은 개별 블록을 중심으로 진행되므로 코드를 별도의 파일로 쉽게 분리 할 수 ​​있습니다. widget.less스타일을 포함 할 .widget때, 블록 component.less의 스타일 포함됩니다 .component블록을. 소스 맵을 사용하고 싶더라도 특정 클래스의 소스를 훨씬 쉽게 찾을 수 있습니다.

2017 년 편집

2017 년에 이것을 읽으면 shadow DOM 및 shadow DOM polyfill과 구성 요소는 코드를 작고 타이트하며 모듈화하면서 이러한 모든 문제를 해결합니다. 그린 필드 프로젝트 IMO에서 BEM을 사용하지 마십시오.

BEM 대신 ViewEncapsulation, Polymer, StyledJSX, SASS 모듈, 스타일 구성 요소 등과 같은 도구가 있습니다.

구성 요소 지향 아키텍처가없는 경우 BEM 사용을 고려하십시오. 지원할 레거시 코드가있는 경우 또는 툴링없이 모든 작업을 수동으로 수행해야하는 경우.

BEM은 스타일을 DOM 중첩과 독립적으로 만듭니다. 페이지에서 고유 할 수있는 큰 클래스 클래스 스타일을 지정하려는 모든 요소를 ​​제공하여이를 수행합니다. 그런 다음 대부분의 스타일링은 수업에서 수행됩니다.

중첩이 더 이상 고려되지 않기 때문에 코드가 더 모듈화됩니다.

BEM없이

BEM이 없으면 다음과 같이 작성할 수 있습니다.

<div class="widget">
  <a>Hello!</a>
  <ul>...</ul>
</div>

표준 CSS 스타일은 다음과 같습니다.

.widget {
  border: 1px solid red;
}

.widget a {
  color: green;
}

SASS와 동일한 내용은 다음과 같습니다.

.widget {
  border: 1px solid red;
  a {
    color: green;
  }
}

모든 사람이 CSS를 높은 표준으로 코딩 할 수있는 소규모 팀이고 프로젝트의 크기를 충분히 인식 할 수있을 정도로 작 으면이 방법은 훌륭하고 합리적인 솔루션입니다.

BEM으로

그러나 코드가 커지고 규모가 큰 혼합 능력 팀이있는 경우 이는 간단한 해결책이 아닐 수 있습니다. 예를 들어 다른 위젯에서 녹색 앵커를 원한다면 어떻게 될까요? 따라서 앵커를 모듈화하고 하위 선택기를 제거합니다.

이제 HTML이 훨씬 더 장황합니다.

<div class="widget">
  <a class="widget__anchor">Hello!</a>
  <ul class="widget__ul">...</ul>
</div>

CSS에는 자손 선택기가 없습니다.

.widget {
  border: 1px solid red;
}

.widget__anchor {
  color: green;
}

그러나 우리는 이제 이것을 할 수 있습니다 :

<div class="widget__2">
  <a class="widget__anchor">Hello!</a>
</div>

widget__anchor는 모듈 식입니다. 페이지에 .widget__anchor의 다른 정의가 존재할 가능성은 거의 없습니다.

트레이드 오프 :

BEM :

• 더 모듈화 된 코드를 제공합니다. 모든 조각을 따로 가져갈 수 있습니다.
• 누구나 CSS를 작성할 수 있습니다. 마스터 스타일과 사용자 정의 재정의에 대해 알 필요는 없습니다. 큰 팀에서는 이것이 좋습니다.
• 특이성 문제를 제거합니다.
• 훨씬 더 장황하다.

표준 CSS (자손 선택기 사용에 의존) :

• 스타일이 상황에 따라 달라짐을 의미합니다.
• 계단식에 대한 인식이 필요합니다. 한 번에 코드를 작성하면 다른 곳의 코드에 영향을 줄 수 있습니다. 소규모 팀에서는 이것이 좋습니다.
• 초보자 개발자가 디버그하기 어려운 특정 문제로 인해 어려움을 겪을 수 있습니다.
• 상당히 단단합니다.

세 번째 방법-실제 구성 요소.

React, Angular 2 또는 다른 최신 프론트 엔드 프레임 워드와 같은 것을 사용하는 경우 다른 해결책이 있습니다. 툴링을 사용하여 캡슐화를 시행 할 수 있습니다.

이 예제는 React 및 StyledJSX를 사용하지만 많은 옵션이 있습니다. 위젯은 다음과 같습니다.

const Widget = () => 
  <div>
    <a>Hello</a>
  </div>
  <style jsx>
    div {border:red }
    a { background: pink }
  </style>

그런 다음 다음과 같이 새 위젯을 사용하십시오.

<Widget />

위젯에서 선언 된 모든 스타일은 캡슐화되며 구성 요소 외부의 요소에는 적용되지 않습니다. 우리는 단순히 스타일 무료 div와 a직접 관련 실수로 걱정 페이지에 다른 어떤 스타일링없이.

완벽한 접근법은 없습니다. IMHO, 우리는 각 방법론 (BEM, SMACSS, OOCSS, DRY)의 가장 좋은 부분을 얻어야합니다. CSS에서 폴더 구조를 구성 할 때 SMACSS를 사용하십시오. 특히 전체 CSS의 논리적 수준 분석을 정의 할 때 사용하십시오. 유틸리티 라이브러리를 작성하기 위해 건조하거나 BEM 기반 클래스와 함께 사용되는 공통 수정 자 라이브러리 일 수 있습니다. 구성 요소에 대한 OOCSS. 작은 구성 요소 또는 하위 구성 요소의 경우 BEM. 이를 통해 복잡성을 분산시키고 대규모 팀 내에서 자유롭게 작업 할 수 있습니다.

그것의 본질을 이해하지 않고 사용하면 나쁜 결과가 발생합니다.

BEM은 대규모 팀에게는 좋은 접근 방법이지만 단점도 있습니다. 1. 때로는 큰 HTML 구조에서 매우 긴 이름이 만들어집니다. CSS 파일 크기가 큽니다. 2-3 단계 이상의 HTML을 중첩하는 경우 이름을 정의하기가 어려워집니다.

매우 기본적인 기본 스타일 집합과 함께 구성 요소 구조를 생각하면 충돌 해결을 쉽게 관리 할 수 ​​있습니다. 그것은 단지 두 가지 수준의 상속에 지나지 않습니다. 구성 요소 내부의 모든 요소에는 전역 스타일 규칙이 있거나 해당 구성 요소에 따라 다릅니다. 이것은 쉬운 옵션 중 하나입니다.