Utility First, Component Second

4 hours ago 1

  • 흔히 CSS에서 tailwindcss 같은 유틸리티 우선 방법론(Utility-First)은 HTML에 클래스를 주렁주렁 매달아 놓는 것으로 생각하곤 함.

  • 그러나 그것은 겉모양일 뿐이고 유틸리티 우선에서 핵심은 컴포넌트 구성 타이밍 문제.

  • CSS 등장 초기 유행한 방법은 유지보수 악몽을 일으킴.

  • OOCSS 조류는 컴포넌트 구성으로 문제를 해결하려 함. 재사용성이 올라갔지만 컴포넌트 범위 설정의 어려움이라는 문제에 부딪힘.

  • 컴포넌트는 재사용성을 위한 것인데, 미래에 무엇이 재사용될지 알 수 없다는 문제

  • Atomic CSS 조류는 하나의 속성에 하나의 클래스만 할당함으로써 문제를 해결하려 함. 초기 개발 속도가 빨라졌지만 유지보수성 문제가 다시 등장.

  • 단일 진실 공급원(Single Source of Truth)이 너무 쉽게 깨짐 - 전체 찾기 바꾸기에 의존 (외부 템플릿 의존은 번거롭고 한계 있음)

  • 유틸리티 우선은 아토믹과 달리 컴포넌트를 긍정. 또한 OOCSS와 달리 유틸리티로 시작. 컴포넌트는 실제 필요할 때 구성하면 됨

  • 무엇을 컴포넌트로 만들 것인가 하는 질문을 언제 만들 것인가 하는 질문으로 전환함

  • 즉, 유틸리티 퍼스트는 둘을 종합, 계승/발전시킨 것으로 봐야 함.

  • 따라서 유틸리티 퍼스트 방법론에서 컴포넌트는 좀더 강조될 필요가 있음. "우리는 컴포넌트를 허용한다"가 아니라 “우리는 컴포넌트가 정말로 필요한 시점까지 미룸으로써 재사용성을 극대화한다”가 돼야 함.

Read Entire Article