[Study] CSS extended

productuidev·2022년 1월 18일

FE Study

목록 보기

11/67

CSS의 역사

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/

BEM (Blcok, Element, Modifier)

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

Famous CSS Libraries

Bootstrap https://getbootstrap.com/
Tailwind
https://tailwindcss.com/

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-in-JS

단어 그대로 자바스크립트 코드에서 CSS를 작성하는 방식을 말합니다. 2014년 페이스북 개발자인 Christopher Chedeau aka Vjeux가 처음 소개하였습니다.

장점

컴포넌트로 생각하기— 더이상 스타일시트의 묶음을 유지보수 할 필요가 없습니다. CSS-in-JS는 CSS 모델을 문서 레벨이 아니라 컴포넌트 레벨로 추상화합니다(모듈성).
CSS-in-JS는 JavaScript 환경을 최대한 활용하여 CSS를 향상시킵니다.
"진정한 분리 법칙"—스코프가 있는 선택자로는 충분하지 않습니다. CSS에는 명시적으로 정의 하지 않은 경우, 부모 요소에서 자동으로 상속되는 속성이 있습니다. jss-isolate 플러그인 덕분에 JSS 규칙은 부모 요소의 속성을 상속하지 않습니다.
스코프가 있는 선택자—CSS는 하나의 전역 네임스페이스만 있습니다. 복잡한 애플리케이션 내에서 선택자 충돌을 피할 수 없습니다. BEM과 같은 네이밍 컨벤션은 한 프로젝트 내에서는 도움이 되지만, 서드파티 코드를 통합할 때는 도움이 되지 않습니다. JSS는 JSON으로 표현된 것을 CSS로 컴파일 할 때, 기본적으로 고유한 이름을 생성합니다.
벤더 프리픽스—생성된 CSS 규칙은 자동적으로 벤더 프리픽스가 붙어있으므로 생각할 필요가 없습니다.
코드 공유—JavaScript와 CSS사이에 상수와 함수를 쉽게 공유할 수 있습니다.
현재 화면에 사용중인 스타일만 DOM에 있습니다(react-jss).
죽은 코드 제거
CSS 유닛 테스트!

단점

학습 곡선(Learning curve)
새로운 의존성
신규 팀원이 코드베이스에 적응하기 어렵게 만듭니다. 프론트엔드를 처음 접하는 사람들은 "더" 많은 것을 배워야합니다.
현상 유지를 위한 도전 (꼭 단점은 아니다.)

CSS-in-JS Libraries

Styled Components https://styled-components.com/
JSS-React https://d0gf00t.tistory.com/22

Source map

이때 사용하는 것이 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

서비스 환경에 맞는 CSS 사용방식 채택

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