– 내가 하면 더 잘 만들 것 같아서 만들어 본 세상 귀여운 on-demand Atomic CSS Library.
최근에 CSS 계에서 주목받고 있는 TailwindCSS를 써보셨거나 들어보신 적이 있나요? 혹은 Utility-first CSS, Atomic CSS, Functional CSS이라는 CSS 방법론을 들어 본 적이 있나요?
Bootstrap이나 Sass, BEM, 혹은 CSS-in-JS 와는 달리 조금 덜 주류이고 아직은 오해가 많지만 TailwindCSS를 통해서 조금씩 알려지고 있는 사실은 정말 괜찮은 방법인 Atomic CSS 방법론과 함께 이러한 방식으로 만들어본 기존 문제점들을 개선한 자체 개발한 CSS 프레임워크인 AdorableCSS를 소개해 보려고 합니다.
Atomic CSS나 TailwindCSS에 관심이 없더라도 이 글은 CSS에 대한 전반적인 내용을 다루고 있으니 CSS 자체에 관심이 있는 분들이라면 한번 읽어 보시면 좋을 거라고 생각합니다.
프롤로그
웹 애플리케이션 개발에서 CSS를 통해 UI를 만드는 작업은 생각보다 까다로운 작업입니다. 분명 난이도는 높지 않은데 절대적인 작업 공수가 많이 들어가다 보니 여기에 투자되는 시간이 비효율적이라는 생각이 들었습니다.
또한 UI 개발은 결과물을 빨리 낼수록 디자인과 기획을 검증하는 시간을 줄일 수 있고 이는 곧 더 나은 제품을 만드는 결과로 이어지기에 CSS 개발의 생산성이 높아지는 방법을 찾고 싶었습니다.
그동안 여러 가지 CSS 방법론과 프레임워크 및 도구들을 실험해 보면서 제가 확립한 저만의 CSS Best Practice의 결정체인 AdorableCSS를 소개하려 합니다.
그러면서 여기에 적용된 패러다임인 Atomic CSS에 대해서도 함께 이야기를 하고 싶었습니다. Atomic CSS는 사실 오래전부터 있었지만 최근에 와서야 다시 재발견되었으며 다소 오해가 많은 패러다임이기에 왜 이러한 방법이 지금에서 와서 채택이 되게 되었는지 CSS의 역사을 살펴보며 함께 설명드리려고 합니다.
이 글이 현대 CSS에 대한 이해를 높이고 CSS 생산성을 높일 수 있는 방법에 대한 하나의 인사이트가 될 수 있기를 바랍니다.
1부. Atomic CSS를 이해하기 위한 최소한의 CSS의 역사 이야기
HTML의 탄생, 1990
최초 웹은 문서를 공유하기 위해서 만들어졌습니다. 그리고 이 문서를 표현하기 위해서 HTML이 만들어졌죠. HTML은 콘텐츠에 의미를 부여하는 태그를 붙여주어 서식을 꾸미는 방식으로 만들어졌습니다. 이렇게 해서 의미에 맞는 적당한 서식의 형태로 문서를 보여줄 수 있었습니다.
<h1>제목</h1>
<p>문단입니다.</p>
inline-style
웹 문서가 보편화되면서 조금 더 다른 형태의 서식으로 꾸미기를 원했고 이를 위해서 style이라는 것이 추가가 되었습니다. 그래서 태그에 style을 입력해서 조금 더 다양한 형태의 문서를 만들 수 있게 되었습니다. 이렇게 태그에 직접 style을 지정하는 방식을 inline-style이라고 합니다.
<h1 style="color: red; text-decoration: underline">This is Red Underline Title</h1>
inline-style의 문제점
** 원칙 1. inline-style은 나쁘다!**
그래서 CSS를 만들게 됩니다. 1996
앞서 설명한 이유로 inline-style의 중복을 제거하기 위한 방법을 고안하게 되고 이것이 바로 우리가 현재 사용하고 있는 CSS입니다.
<strong style="color: red; text-decoration: underline">This is Red Underline Title</strong>
.... <strong style="color: red; text-decoration: underline">Other Red Unerline</strong>
... <strong style="color: red; text-decoration: underline">Underline Title 333<strong>
CSS는 위와 같이 중복해서 쓰이던 inline-style을 별도의 Rule로 선언을 하고 서식이 필요한 곳을 선택해서 반복해서 적용을 하는 방식으로 만들어졌습니다.
<style>
strong { color: red; text-decoration: underline }
</style>
<strong>This is Red Underline Title</strong>
.... <strong>Other Red Unerline</strong>
... <strong>Underline Title 333<strong>
콘텐츠와 서식의 분리
CSS를 별도로 작성을 하게 되면서 자연스럽게 콘텐츠와 서식이 분리되었습니다. 이렇게 콘텐츠와 스타일을 분리하고 보니 콘텐츠와 서식을 꼭 1:1로 매칭을 하지 않고 하나의 콘텐츠에 여러 가지 스타일을 선택적으로 적용할 수 있다는 것을 알게 됩니다.
<strong>This is Red Underline Title</strong>
.... <strong>Other Red Unerline</strong>
... <strong>Underline Title 333<strong>
/* 동일한 콘텐츠로 이러한 서식을 적용하거나 */
/* style1.css */
strong { color: red; text-decoration: underline }
/* 저러한 서식을 선택적으로 사용할 수 있다. */
/* style2.css */
strong { color: blue; font-weight:bold }
</style>
이러한 장점은 콘텐츠는 유지하고 디자인만 변경할 수 있는 테마형 솔루션의 형태를 발전을 하게 되면서 다음과 같은 원칙이 만들어집니다.
✌ 원칙 2. 관심의 분리: 콘텐츠와 서식을 분리하여 관리하자.
콘텐츠가 수정되면 HTML을 수정하고 서식이 변경될 때에는 CSS를 수정하자.
그러면서 유연하게 디자인을 적용할 수 있도록 HTML을 잘 구조화해서 작성을 하고 HTML 변화 없이 CSS 만으로 여러 가지 스타일을 만드는 것이 중요한 아젠다가 되었습니다.
하나의 콘텐츠에 여러개의 스타일! CSS Zen Garden을 기억하시나요?
Selector가 복잡해진다. Sass의 등장, 2006
이러한 배경으로 HTML을 수정하지 않고 CSS 만으로 디자인을 적용하려고 하다 보니 스타일을 하나하나 원하는 엘리먼트를 선택해서 스타일을 적용하는 것은 쉬운 일이 아니었습니다. 원하는 요소를 찾고 수정하기 위해서는 복잡한 Selector를 써야 했고 Selector 역시 세분화가 필요했습니다.
그래서 이렇게 복잡해진 Selector를 조금 더 쉽게 만들 수 있는 언어인 Sass와 같은 것들이 등장하였습니다.
Ajax의 등장과 HTML 편집권의 변화
이후 Ajax가 보편화가 되면서 백엔드에서 HTML을 제외한 데이터만 전달을 할 수 있게 되면서 이제는 HTML의 편집권은 백엔드가 아니라 프론트엔드로 내려오게 됩니다.
그렇게 HTML과 CSS를 동시에 편집을 할 수 있게 되면서 이제는 복잡하게 Selector를 쓸 필요가 없다는 것을 깨닫게 됩니다. 이제는 필요할 때 HTML을 수정할 수 있으니 CSS를 복잡하게 하는 것보다 HTML을 복잡하게(?) 쓰는 것이 더 낫다는 것을 알게 됩니다.
CSS에서 복잡한 Selector를 잘 쓰기보다는 HTML에서 미리 잘 지어둔 class 이름이 더 좋구나.
그래서 이후에는 Selector를 어떻게 잘 쓰는지 보다 어떻게 class 이름을 더 잘 지을 수 있는지를 고민하는 식으로 흐름이 변하게 됩니다.
의미 있는 이름 vs 시각적인 이름
복잡한 Selector보다는 단순한 Class Selector를 사용하는 것이 보편화되면서 어떤 식으로 이름을 지을지 고민을 하기 시작하였습니다.
class 이름을 짓는 방식에는 2가지가 있었습니다. 의미를 기반으로 하는 .error, .title과 같은 이름과 기능이나 시각적 요소를 기반으로 하는 .red .bold 와 같은 방식이었죠.
어떻게 이름을 짓는 것이 좋을까?
.errorvs.red.descriptionvs.text-right.titlevs.bold
스타일 변경 시 CSS를 수정한다는 원칙에 의거하여 변경된 디자인에 맞게 CSS를 변경하다 보니 시각적인 이름으로 짓게 될 경우 .red { color: orange} 라는 이상한 형태가 만들어진다는 것을 알게 되었습니다.
그래서 유지 보수와 유연한 대응을 하기 위해서는 class 이름을 의미기반으로 짓는 것이 더 좋다는 다음과 같은 원칙이 만들어집니다.
** 원칙 3. 시각적인 이름보다 시멘틱한 이름이 좋다.**
그래야 디자인 변경에 유연하고 같은 콘텐츠에 다양한 스타일을 적용할 수 있게 된다!
이제는 웹 문서가 아니라 웹 애플리케이션의 시대
웹이 발전을 하면서 웹은 더 이상 문서나 홈페이지 형태만 있는 게 아니게 되었습니다. 구글 지도나 구글 오피스와 같이 웹으로도 애플리케이션을 만들게 되고 CMS와 같은 데이터를 다루는 백오피스 등의 웹페이지의 요구사항이 커지면서 웹은 점차 애플리케이션의 형태로 발전을 하게 됩니다.
“이제는 웹 문서뿐만 아니라 웹 애플리케이션도 만들어주세요.”
??? : 나는 문서를 꾸미려고 했지. 앱을 만들려던 게 아니었어! 😱
웹 애플리케이션은 웹 페이지에 비해 비중은 낮지만 훨씬 더 고부가가치를 만들어 내기에 많은 개발자들에게는 웹 문서보다는 웹 애플리케이션을 만드는 것이 더 중요해집니다. 그러나 CSS는 웹 문서를 잘 꾸미기 위해서 설계되었죠.
그리하여 초기에 문서를 만들기 위해서 설계된 CSS는 웹 애플리케이션 개발 패러다임에서 과도기를 맞이하게 됩니다.
이제 CSS가 문제가 생기기 시작했다.
흔한 CSS로 개발하면서 겪게 되는 상황들…
1. HTML을 복사-붙여넣기 했는데 CSS가 제대로 적용이 안됨.
2. CSS를 수정했는데 엉뚱한 곳이 틀어져 보이는 문제
3. Selector가 안 먹어서 !important로 덮어써야 하는 경우
4.안 쓰이는 코드 찾기가 진짜 어려운 문제 (특히 JS와 결합된 class)
5. 도무지 CSS가 재사용이 되지 않는 문제
애플리케이션에서 CSS 사용 시 결정적인 2가지 문제점
CSS는 애플리케이션을 만들기 위해 설계가 된 것이 아닌데 이미 JS는 Component와 Framework 기반의 개발 방식으로 변해가고 있었습니다. 당시에는 flexbox와 같은 애플리케이션을 위한 레이아웃 스펙은 존재하지 않았기에 float 등을 억지로 사용하고 문서의 간격을 만들기 위한 margin 등을 통해서 레이아웃을 하는 스펙의 부재도 있었지만 결정적으로 큰 2가지 설계상 문제들이 존재했습니다.
1. Global Scope: 전역변수가 나쁜 것은 다 아시죠? 😫
- 내가 수정한 코드가 모든 프로젝트에 영향을 준다.
- 그래서 엉뚱한 곳이 문제가 생기기에 관리 비용이 증가한다.
- 기존에 한번 사용한 이름을 피해 가며 작성해야 한다.
2. Specificity: 왜 작성된 순서대로 적용이 되는 게 아닌 거죠? 😥
- HTML에서 지정한 class 순서가 아니라 CSS의 순서에 의해 서식 우선순위가 결정된다.
- 코드 순서도 있지만 무엇보다 Selector가 복잡할수록 서식이 나중에 적용된다.
- 다른 서식을 덮어쓰기 위해서는 Selector를 더 복잡하게 작성을 해야 한다.
- 이걸 간단한 Selector로 덮어쓰려면 !important를 해야 한다.
- !important를 한 속성을 덮어쓰려면 복잡한 Selector에 !important를 해야 한다. …
방법을 찾아보자 방법론! (feat. BEM), 2013
처음부터 CSS를 작성하는 규칙을 잘 짜면 이러한 문제들을 해결할 수 있지 않을까? 하는 생각에서 나온 것이 CSS 방법론입니다.
어떤 규칙으로 CSS를 만들어야 이런 문제들을 안 발생할 수 있을까요? 여러 가지 고민을 하면서 각자만의 방법론들이 만들어지기 시작했습니다.
SMACSS, OOCSS, BEM, ITCSS, ATOMIC CSS …
Winner is BEM!
– Specificity를 하나로 통일하면서 단순하여 기억하기 쉬운 컨벤션
하지만 이러한 방법론으로는 복잡성을 줄이거나 더 나은 생산성을 가져오는 것은 아니었고 CSS의 본질적인 문제를 해결해 주지는 않았습니다.
‘어쩌면 CSS로는 태생적으로 해결을 할 수 없는 게 아닐까? 그러면 JS의 도움을 받아보자!’ 라는 생각으로 CSS 자체보다는 JS의 도움을 받는 식으로 해결을 하고자 하는 움직임이 생겨납니다.
CSS Modules, 2015
CSS의 범위를 컴포넌트를 벗어나지 않도록 해주자!
Global Scope 문제의 해결책
CSS의 문제인 Global Scope를 막기 위해서 Component 단위에서 사용되는 CSS에 hash를 추가하여 CSS가 더 이상 Global 하지 않도록 하는 방식을 통해서 해결을 하고자 하는 방법이 만들어졌습니다.
CSS-in-JS
이후 React가 대세가 되면서 React에서 Style을 다루는 불편함을 해소하기 위해서 JS에서 HTML을 쓰기 위해 JSX를 만든 것처럼 JS에서 style을 쓰기 위한 방법으로 CSS-in-JS라는 방법이 등장하게 됩니다.
CSS-in-JS의 시작 (Vjeux), 2014
CSS는 비단 Global Scope와 Specificity 말고도 사실 문제가 많다.
JS에서 CSS를 해보면 어떨까?
최초 CSS가 아니라 JS를 통해서 문제를 해결해 보자는 시각이 제기되었고 이러한 방식은 이후 CSS-in-JS라는 방법으로 구체화되게 됩니다.
CSS-in-JS StyledComponent, 2016
그러면 CSS를 JS의 컴포넌트 방식으로 작성을 해보자!
그리고 그러한 방식의 대표주자가 되는 StyledComponent가 탄생을 하게 됩니다.
현재 2021 State of CSS
이후 지금은 CSS-in-JS가 새로운 흐름이 되어 계속 발전을 하고 있는 중입니다.
지금까지 CSS의 발전 방향성을 정리해 보자!
그래서 CSS의 발전 방향을 보면 다음과 같이 CSS를 컴포넌트 방식에 맞춰가는 형식으로 발전을 하고 있다는 것을 알 수 있었습니다.
복잡한 Selector → 간단한 Selector → No Selector
Global Scope → Local Scope
HTML과 CSS의 분리 → 컴포넌트로 결합
그렇다면 CSS의 최종 종착지는 결국 CSS-in-JS인 걸까요?
TailwindCSS의 등장! 2017
“Best practices” don’t actually work.
Utility-First CSS Framework
그 이후 지금까지의 Best practices는 사실 제대로 동작하지 않는다며 만들어진 새로운 시각의 CSS Framework, TailwindCSS가 등장을 합니다.
하지만 이 TailwindCSS는 다른 CSS의 새로운 기술과는 달리 많은 Hater들을 가지고 있습니다. 새로운 기술인데 이렇게 호불호가 갈리는 이유는 무엇일까요?
그 이유를 설명하기 위해 지금까지 CSS의 역사적 맥락이 필요했습니다. 😅
다음 장에서는 본격으로 TailwindCSS의 근간이 되는 Atomic CSS의 개념을 이해하면서 왜 논란이 되는지도 한번 살펴보려고 합니다.
Note
Utility-First, Atomic CSS, Functional CSS는 사실상 모두 같은 것을 의미합니다. 해당 방식이 비주류다 보니 인식의 전환을 위해 서로가 키워드를 선점하고자 새로운 키워드를 제시하고 있습니다… 인지도가 가장 높은 TailwindCSS는 이 중 Utility-First를 밀고 있지만 일단 이 글에서는 Atomic CSS라고 통일해서 부르도록 하겠습니다.
2부. Atomic CSS가 뭘까요?
“Best practices” don’t actually work.
지금까지 해왔던 방법은 틀렸다고 말하면서 시작된 TailwindCSS! 과연 지금까지의 Best Practice는 뭐였을까요? 이전 장에서 알아본 다음과 같은 원칙들이었습니다.
원칙 1. inline-style은 나쁘다.
원칙 2. 콘텐츠와 서식을 분리하자.
원칙 3. class 이름은 시멘틱한 게 좋다.
지금도 이 “Best practices”가 유효할까?
하지만 문서에서 앱으로 넘어오면서 우리는 이러한 방식에서 힘들어하면서 의문을 가지게 되었습니다. 정말 지금도 이 “Best practices”가 유효할까?
의문 1. inline-style이 정말 나쁜 걸까?
의문 2. 콘텐츠와 서식의 관점 분리가 가능한 걸까?
의문 3. 정말 시멘틱한 이름이 좋은 걸까?
정말로 inline-style 하게 콘텐츠와 서식의 관점 분리를 하지 않고 시멘틱 하지않고 시각적인 이름을 쓰는 게 정말 나쁜 것일까요?
Atomic CSS?
콘텐츠와 서식을 분리하지 않는다면 어떻게 작성을 하는 것일까요?
우리는 분명 CSS가 만들어지고 초기 자연 발생했던 .bold .hidden .red .text-right .mt10과 같은 Class를 만들어서 분명히 편하게 사용했던 경험들이 있었습니다. 그러나 이러한 방식은 시멘틱 하지 못했기에 일종의 편법으로 여겨졌었죠. 하지만 편리한 것은 분명한 사실이었습니다.
이 방식이 편리한 방식이라면 일부만 이러한 편법이 아니라 그냥 전부다 이러한 방식으로 만들어 보는 것은 어떨까요?
bg-gray-100 p-8 w-32 h-32 .text-center .text-lg .font-semibold
.pt-3 .pt-0 self-start flex-wrap mb-1
This is Atomic CSS!
👀 의미기반이 아닌 시각적 기능에 기반한 이름을 지은 변하지 않는 단일 클래스를 이용하자.
🎨 변하지 않는 CSS를 먼저 만들어두고 HTML에서 스타일을 작성하자.
이와 같이 의미기반이 아닌 미리 만들어둔 시각적인 이름을 바탕으로 HTML에서 필요한 스타일을 적용하는 방식으로 개발하는 방법론이 바로 Atomic CSS입니다.
왜 이렇게 작성하는 걸까요?
기존까지 역사적으로 합의된 원칙과는 정반대로 작성을 하는 이유는 무엇일까요?
“그것은 바로 의미론적으로 이름 짓기가 아주아주 어렵기 때문입니다.” 🤯
.button .card .gnb .side-bar
시멘틱한 이름 좋아요!
.homepage-section .collection-module .section-content .main-content
조금만 범위를 넓혀보면 시멘틱한 이름…? 어떤 모양인지 상상이 되나요?
.inner-main .wrap_cont .cp_more_wrap .inner_item .wrap_title
이런 이름들은 어떤가요? 어떤 의미가 있죠?
의미가 없는데도 의미를 부여해서 이름을 짓는 것은 더 어렵습니다.
하지만 주어진 디자인을 구현하기 위해서는 이렇게 선 하나, 배경색이나 글자색, 여백 등을 넣기 위해서 우리는 이러한 이름들을 지어야만 합니다.
(위 예시들은 지어낸 것이 아니라 실제로 사용하고 있는 이름들에서 가져왔습니다.)
의미론적 이름 짓기 방식의 한계점
.wrap_title .title_wrap_container .inner_g
이렇게 만들어진 CSS들은 어떠한 서식이라 하더라도 다른 프로젝트에서는 아마 재사용이 불가능할 겁니다. 다른 프로젝트에서는 다른 의미를 가지는 콘텐츠들로 만들어졌을 테니까요.
또한 이렇게 지어놓은 이름은 프로젝트 내에서 중복해서 사용할 수 없기 때문에 새로운 이름을 지을 때면 항상 기존에 만든 CSS를 피해가야 합니다.
.title .section-title .main-title .footer-title
그렇지 않으려면 결국 Selector를 조립해야 하는 데 ex) #main a.title > span 이런 식으로 Selector를 복잡하게 작성하게 되면 Specificity 문제가 그대로 발생하게 됩니다.
Traditional CSS vs Atomic CSS
Traditional CSS
이름 짓기도 어려운 CSS를 계속 만들어야 하고 만들어 놓은 CSS를 피해야 하니 점점 복잡해져가서 파일 크기가 점점 커지지만 재사용이 불가능하기에 매번 계속 작성해야 하는 악순환…
Atomic CSS
시각적 기능 기반 쉬운 이름을 가지며 미리 만들어 두기 때문에 1번 외워두면 계속 재사용이 가능하며 일정 크기 이상 파일이 안 커지지 않습니다.
무엇보다 필요 없는 이름을 짓는 고통에서 해방이 된다!
뿐만 아니라 의도하지 않더라도 누구나 동일한 형태의 코드 스타일을 작성하게 된다.
=> 협업에서 컨벤션을 맞추기 위한 노력이 줄어든다.
=> 컨벤션과 방법론의 역할을 함.
구조가 바뀌어도 문제 되는 분야가 국지적이다.
기존에 만들었던 코드를 의식하지 않고 작성해도 된다.
코드를 수정하고 구조가 바뀌어도 컨텍스트 파악이 쉽다.
= Global Scope (X) = Local Scope (O)
어떤가요? AtomicCSS가 괜찮아 보이나요?
하지만 이러한 AtomicCSS는 지금껏 주류는 고사하고 늘 논란의 대상이었습니다.
왜 AtomicCSS 방식은 주류가 되지 못할까?
이러한 장점이 있음에도 해당 방식은 그동안 주류가 되지 못했습니다.
왜 TailwindCSS는 왜 AtomicCSS가 아니라 Utility-First라고 이름을 지었을까? Functional CSS는 이들이랑 뭐가 다른 걸까요? 왜 같은 방법에 이렇게나 이름이 많을까요?
사실 AtomicCSS는 TailwindCSS가 시초가 아닙니다. 앞서 설명했듯이 이러한 방식은 CSS가 생긴 초창기 시절부터 꾸준히 그 편리함으로 인해서 제기되었으나 언제나 시멘틱한 방법이 옳다는 방식으로 CSS가 발전해 왔습니다.
그래서 처음에는 FunctionalCSS라는 이름으로, 그다음에는 AtomicCSS라는 이름으로, 이제는 Utility-First라는 이름으로 기존과는 다른 방식이라고 인식 전환을 시도했으나 번번이 올바르지 않은 방법이라고 인식되고 거론되었고 이러한 방식은 소수의 마니아들이 사용하는 방식이 되었습니다.
하지만 TailwindCSS가 유명해진 것은 커뮤니티를 통해 이러한 인식의 전환을 하기 위해서 부단한 노력을 했다는 점입니다. 또한 이러한 패러다임이 일부 편리함을 위한 차용이 아니라 전면적으로 사용해도 된다는 패러다임의 변화를 가져오고 지금까지 꾸준히 업데이트를 하고 있는 점이 인정을 받게 만들었습니다.
저 또한 이렇게 서론이 길었던 이유는 역시 제가 만들었던 프레임워크 역시 이러한 AtomicCSS 방식에 대한 인식의 전환 설득이 필요하기 때문입니다.
AtomicCSS를 싫어하는 이유
😡 “이미 10년도 전부터 안 좋다고 결론이 난 방법을 왜 또 계속 들고 오는 건가요?” 90년대나 있었던 inline-style과 뭐가 다른 거죠?
- HTML에 스타일 코드가 반복되는 것은 어떻게 해결할 건가요?
- 의미론적 구분이 없으면 전체적인 콘텐츠 파악이 어렵습니다.
- 콘텐츠와 서식의 분리를 할 수 없는데 다양한 테마 서식 적용은 어떻게 할 건가요?
- HTML이 너무 지저분해지고 코드의 가독성을 잃게 됩니다.
- HTML 기반의 문서에다가 전부 AtomicCSS를 붙일 건가요?
- CSS를 쓰지 않으면 CSS를 더 모르게 됩니다.
- CSS가 문제가 있는 것은 맞는데 CSS를 잘하면 해결되는 문제 아닐까요?
하지만 이제는 AtomicCSS를 써도 되는 이유
왜냐하면 시대가 변했으니까요…
이제는 CSS가 굳이 시멘틱하지 않아도 됩니다. 특히 WebFramework를 사용한 Component 기반 개발 시대인 지금은 Web Framework의 컴포넌트가 시멘틱과 중복방지 역할을 대신해주고 있습니다.
지금 시대는 하나의 콘텐츠에 여러 가지 디자인을 할 필요성이 줄어들었습니다. 디자인이 곧 아이덴티티인 시대이기에 더 이상 콘텐츠와 서식을 분리할 필요가 없어졌습니다.
= 디자인이 곧 아이덴티티
= 솔루션이 아닌 서비스의 시대!
= 시멘틱 하지 않아도 된다.
AtomicCSS도 진화하고 있었다.
뿐만 아니라 비주류였던 AtomicCSS로 알게 모르게 조금씩 진화를 하고 있었습니다.
FunctionalCSS -> Atomic CSS -> Utility First -> on-demand Atomic CSS
그래서 그때는 틀렸지만 지금은 어떨까요? 이다음 글에서는 Atomic CSS 패러다임이 어떻게 진화해 왔고 왜 TailwindCSS는 과거와 달리 사용할 수 있는지 그리고 어떤 점에서 아직은 아쉬운지 이야기해 보려고 합니다. 감사합니다.
