CSS의 역사로 보는 CSS가 어려워진 이유 https://velog.io/@teo/css-history-1
1) CSS는 문서에서 서식과 콘텐츠를 분리하기 위해서 만들어졌다.
2) 콘텐츠를 제공하는 솔루션을 기반으로 CSS를 커스텀하는 방식으로 발전했다.
3) 그로 인해 시맨틱 웹과 복잡한 Selector를 사용하는 방식으로 진화했다.
4) CSS의 규모가 커져가는데 CSS의 발전은 늦어지자 CSS의 문법을 확장시키고자 하는 방향으로 발전했다.
5) 백엔드는 데이터만 처리하는 웹 애플리케이션 방식으로 발전했다.
6) 문서를 만드는 방법으로 애플리케이션을 만들어야 하는 과도기를 겪었다.
7) Flexbox라는 애플리케이션을 위한 스펙들이 활성화되기 시작했다.
8) 컴포넌트를 기반으로 하는 프레임워크가 보편화되면서 CSS의 구조상의 문제가 드러났다.
9) Selector는 단순화되는 방향으로 진화하며 컴포넌트 개발방식에 맞는 CSS설계가 주요 아젠다가 되었다.
10) CSS 방법론은 BEM이 살아남았으나 CSS 구조의 한계를 느끼고 JS로 CSS의 부족함을 메꾸려는 방향으로 발전했다. - PostCSS, CSSModules, CSS in JS
11) CSS 자체적으로는 Utiliy-First라는 TailwindCSS가 새로운 대안으로 떠오르게 되었다.
12) IE11의 방파제가 무너지면서 Grid Layout이나 CSS Variable과 같은 CSS의 새로운 스펙들의 사용빈도가 높아지고 있다.
13) 현재는 CSS in JS, Atomic CSS 두 가지 갈래의 방향으로 프레임워크와 번들 생태계와 함께 진화 중이다.
출처 - https://yozm.wishket.com/magazine/detail/1326/
https://nykim.work/15
https://velog.io/@te-ing/%EB%8D%B0%EB%B8%8C%EC%BD%94%EC%8A%A4-26%EC%9D%BC%EC%B0%A8-TIL-CSS-%EC%8B%AC%ED%99%94
Tailwind
https://velog.io/@jinsu2504/tailwind-1
https://wonny.space/writing/dev/hello-tailwind-css
https://blog.rhostem.com/posts/2021-06-05-tailwind-css
https://tailwindui.com/
https://tailwindcomponents.com/
단어 그대로 자바스크립트 코드에서 CSS를 작성하는 방식을 말합니다. 2014년 페이스북 개발자인 Christopher Chedeau aka Vjeux가 처음 소개하였습니다.
이때 사용하는 것이 map 파일들인데, 이 파일들은 원소스파일과의 대응관계를 알려주는 역할을 한다. Javascript와 CSS의 주석 일부에 Map 파일의 경로를 적어주면, Chrome 디버깅 창에서 해당 맵파일을 이용하여 원 소스를 참조할 수 있게 해준다. (컴파일 기반 언어에서 링크 결과물로 부수적으로 산출할 수 있는 map 파일과 그 목적이 비슷하다.)
프로젝트를 build하고 나면 기본적으로 소스가 그대로 보인다.
크롬 기준 > 개발자 도구(ctrl+shift+i or F12) > Sources
웹팩 소스맵
https://joshua1988.github.io/webpack-guide/devtools/source-map.html#%EC%86%8C%EC%8A%A4-%EB%A7%B5
1) 컴포넌트 위주의 프레임워크
CSS-in-CSS : 사용하지 않는 CSS 스타일 요소까지 로딩하기 때문에 비효율적이다.
CSS-in-JS : 필요한 컴포넌트 페이지의 CSS 스타일 요소만 로딩한다.2) 인터랙티브한 웹사이트
CSS-in-CSS : 랜더링할 때 모든 CSS 스타일 요소를 로딩하기 때문에 컴포넌트 상태가 변하더라도 바로 적용이 가능하다.
CSS-in-JS : 상태 변경으로 인한 랜더링 때마다 JS 파일 내의 CSS 코드를 로딩 (파싱 등)해야하기 때문에 성능이 떨어질 수 있다. (컴포넌트 내 인터렉티브한 변화는 다를 수 있다)3) 콘텐츠가 많은 웹사이트
콘텐츠가 많은 웹사이트의 경우 초기 랜더링 시간이 길어져버리면 유저가 불편함을 느낀다.
CSS-in-JS를 사용할 경우 라이브러리를 설치해야하기 때문에 번들링 크기가 커져 초기 구동 속도가 늦어질 수 있다.
이를 해결하기 위해 html이 먼저 렌더링 되는 서버사이드 랜더링을 사용한다고 해도 SSR를 위한 라이브러리를 설치해야하기 때문에 잘 고려해야한다.
(서버사이드 렌더링인 next.js는 9.3버전 부터 CSS Modules를 권장한다.)
출처 - https://seizemymoment.tistory.com/145
웹스타일링 컴포넌트 관리 css-in-js vs css-in-css
https://s-core.co.kr/insight/view/%EC%9B%B9-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%EC%8A%A4%ED%83%80%EC%9D%BC%EB%A7%81-%EA%B4%80%EB%A6%AC-css-in-js-vs-css-in-css/
css-in-js 잘 써보자
https://velog.io/@altmshfkgudtjr/CSS-in-JS%EB%A5%BC-%EC%9E%98-%EC%8D%A8%EB%B3%B4%EC%9E%90
잘 알려지지 않은 CSS 속성들
https://ahnheejong.name/articles/less-famous-css-properties/