Tailwind
“Best practices” don’t actually work.
테일윈드 홈페이지에는 “Best practices don’t actually work”라고 자랑스럽게(?) 써왔는데, 소위 잘 작동하지 않는다는 “베스트 프랙티스”는 테일윈드가 제공하는 해법에 비해 훨씬 크고 복잡한 문제를 풀고자 하기 때문에, 그리고 아직 우리가 적절한 해법을 찾지 못했기 때문에, 어렵고 복잡하고 잘 작동하지 않는거다.
테일윈드를 쓸 때의 내가 느끼는 감정은 “죄송하지만 문제가 너무 복잡하고 아직 해법이 없는데 뭘 만들긴 해야겠으니 이렇게라도 해서 일부 문제라도 풀어볼게요”이지 “기존 베스트 프랙티스를 대체할 행복한 해법이 나왔어요”가 아니다.
중복에 대해
테일윈드 공식 문서에서는 중복되는 유틸리티 조합 문제에 대해 이렇게 말한다.1
- 다중 커서 편집 기능을 이용해서 한 번에 고치면 된다: 하지만 중복된 코드의 문제는 “여러번 편집하는 불편함”이 아니라, 중복 코드가 있는데 중복인줄 몰라서 하나만 고치고 나머지를 안고치는 순간 버그 혹은 동작의 비일관성이 생긴다는 점이다. 이런 문제는 보통 한참 뒤에야 발견되기 때문에 비용이 크다. (결함비용증가)
- 반복문: 이견 없음
- 반복되는 요소를 컴포넌트로 추출하기: CSS와 관련한 근본적 문제는, CSS가 풀고자 하는 디자인 문제는 근본적으로 다차원적 관심사 분리의 문제이기 때문에 트리 구조만으로 해결하기 어려운 반면 DOM 또는 컴포넌트 트리는 트리 구조로 제한된다는 사실에서 발생한다. “반복되는 요소를 컴포넌트로 추출하기”라는 해법은 다차원적 관심사 분리 문제를 해소할 수 없다.
- @apply: 이 방식은 테일윈드의 접근법과도 안맞고(되도록 저수준의 유틸리티 조합을 써야하는데
@apply를 많이 쓸수록 점점 전통적 접근과 같아지기 때문), 전통적 CSS와도 안 맞는다(CSS 코드 안에 테일윈드 유틸리티를 열거하기 때문). 그래서 테일윈드 문서는@apply사용을 되도록 자제하길 권한다. 하지만 어쩌면 이 방식이 내가 생각하기엔 오히려 더 나아보이는데, 왜냐하면 선택자를 임의로 쓸 수 있다는 점에서 AOP의 Join point 모델을 쓸 수 있으면서, CSS의 rule-set 대신 테일윈드의 유틸리티를 열거한다는 점에서 디자인에 일정한 제약을 주기 때문.
마음에 드는 점
- CSS의 자유도에 일정한 제약을 두어야 한다는 접근
- 모바일-우선
마음에 안드는 점
- 다차원적 관심사 분리를 생각조차 하지 않음.
- CSS랑 비슷하지만 여러모로 더 후진 새 언어(테일윈드의 어휘, 어휘의 조합 규칙 등)를 배워야 함.
- Logical properties는 버전 3.3에서야 추가됨. 그나마도 거의 어떤 문서에서도 소개하거나 권장하지 않음.