프론트 엔드/css
[CSS] CSS의 역사
삼삼고
2022. 10. 31. 16:20
인터넷이 만들어진 이후 CSS작성 방식은 꾸준히 진화해 오게 되었습니다.
오늘은 CSS의 과거 현재 그리고 미래에 대해 알아보며 그동안 어렵게만 느껴져 왔던
CSS에 한 발자국 더 가까워지는 시간을 가지고 싶어 이 글을 작성합니다.
🤠1990년대(CSS 대항해시대)
1990년도에는 말 그대로 아무런 규칙과 약속도 없는 CSS는 무법 개발자들의 시대였습니다.
인터넷이 발달하면서 웹 페이지를 표시하기 위해 개발된 HTML의 탄생하게 되었습니다.
이후 예쁜 웹 페이지를 원하는 개발자들의 요구의 의해 HTML에 서식을 입힐 수 있는 기능이 생기게 되었습니다.
(이것이 바로 Inline-style 기법이었습니다)
line안에 스타일을 집어넣어 태그에 서식을 넣을 수 있는 기법이었습니다.
CSS의 등장으로 사람들은 멋진 인터페이스를 만드는데 중점을 두기 시작했고
코드의 가독성과 규칙성 등을 생각하지 않고 웹페이지의 모습에 모든 것을 집중하였고
그럴수록 CSS는 자신만의 방법을 가지는 일관성 없는 상태로 남겨지게 되었습니다.
이런 일관성 없는 복잡한 코드들은 점점 양이 많아지면서 문제가 발생하게 되었는데....
태블릿이나 스마트폰이 등장하면서 디스플레를 커버해야 하는 display가 다양하게 되면서 css는 더욱 복잡하게 되었습니다.
또한 이런 복잡해진 코드들은 같은 팀원이나 새로 들어오는 신입들에게 큰 걸림돌이 되었습니다.
개발자들은 슬슬 새로운 css의 필요성을 느끼게 되었고
이를 구조화하게 된다면 가독성이 올라가지 않을까란 희망으로 연구하기 시작했습니다.
🦧2006년 SASS등장(전처리기의 시대)
연구하던 개발자들은 기존의 CSS의 반복적인 작업과 수정하는 방법이 용이하지 않다고 생각하게 되었고 차라리 CSS를 확장하여 사용하고자 마음먹게 되었고 그렇게 나온 것이 바로 그 시대에 가장 유명했던 SASS입니다.
SASS는 Syntactically Awesome Style Sheets의 약자로 CSS를 확장해 주는 스크립팅 언어입니다.
SASS는 컴파일을 통해 CSS파일을 번들 파일로 만들어 재사용성을 높였고 수정에도 용이했습니다.
때문에 많은 사람들이 CSS전처리기 방법을 사용하기 시작했습니다.
❗하지만!!!
전처리기 방식은 곧 장점보다 더 많은 단점들이 부각 대기 시작했습니다.
구조화를 해결하였지만 사람들은 내부의 작업을 신경 쓰지 않고 마구마구 계층구조를 만들었고 이로 인해 컴파일된 CSS의 용량은 어마어마하게 커지게 되었던 것입니다.
어마어마하게 커진 스타일 시트는 이내 점점 큰 문제로 부각되기 시작했습니다.
또 개발자들은 고민에 빠졌고 재사용성과 컴포넌트에 대해 생각했고 어떻게 하면 다음과 같은 문제들을 해결할 수 이 있을까 연구 하기 시작했습니다.
* 코드의 재사용
* 코드의 간결화(유지 보수 용이)
* 코드의 확장성
* 코드의 예측성(클래스 명으로 의미 예측)
🦍2013년 BEM등장(새로운 방법론 대두!)
개발자들은 고민하다가 Block Element Modifier으로 className을 고유하게 만든다면 위의 문제들이 해결되지 않을까 라는 아이디어를 떠올리게 되었고
Block Element Modifier의 앞글자를 하나씩 딴 BEM방법론이 등장하게 되었습니다.
BEM이란 말 그래도 Block Element Modifier로 구분하여 클래스명을 작성하는 방법 인대. 클래스명을 통해 모든 것을 간단하고 명료하게 나타낼 수 있었습니다.
❗하지만!!!
이번에는 반대로 클래스명이 너무 장황하고 길어서 문제가 발생하기 시작했다.
마크업이 불필요할 정도로 커지고 재사용하려고 할 때마다 모든 UI 컴포넌트를 명시적으로 확장해야만 했기 때문에 뭔가 깔끔하지만 더 피곤하게 돼버린 상황에 처해버렸리게 되었습니다.
개발자들은 더 편하고 깔끔한 코드를 위해 캡슐화가 필요하다고 느끼게 되었고 새로운 방법으로 CSS에 접근하기 시작했습니다.
🦍2021년 현재(CSS in JS의 대유행)
개발자들은 CSS를 캡슐화하여 나타내기 위해 연구했지만 지금까지 컴포넌트 기반의 방식을 위해 만들어진 적이 한 번도 없었기 때문에 JS파일에 CSS를 직접 넣어 CSS-in-JS를 탄생시켰습니다.
이는 곳 개발자 세계에 격변의 흐름을 가져왔고
현재 CSS-in-JS에서 가장 유명한 방법인 Styled-Component가 1위인 것을 알 수 있습니다.
근데 어떠한 라이브러리가 최종 승자가 될지는 좀 지켜보면서 천천히 갈아타고 될 것 같다고 생각합니다.
📌장단점 OVERVIEW
특징 | 장점 | 단점 | |
CSS | 기본적인 스타일링 방법 | - | 일관된 패턴을 갖기 어려움, important의 남용 |
SASS (Preprocessor) |
프로그래밍 방법론을 도임하여 컴파일된 CSS를 만들어내는 전처리기 | 변수/함수/상속 개념을 활용하여 재사용 가능 CSS구조화 | 전처리 과정이 필요 디버깅의 어려움이 있음 컴파일한 CSS파일이 거대해짐 |
BEM | CSS클래스명 작성에 일관된 패턴을 강제하는 방법론 | 네이밍으로 문제 해결, 전처리 과정 불필요 |
선택자의 이름이 장황하고 클래스 목록이 너무 많아짐 |
STyled-Component (CSS-in-JS) |
컴포넌트 기반으로 CSS를 작성할수 있게 도와주는 라이브러리 | CSS를 컴포넌트 안으로 캡슐화, 네이밍이나 최적화를 신경쓸 필요가 없음 | 빠른 페이지 로드에 불리함 |
👉추가적인 내용으로....
나는 잘 몰랐던 내용 인대
요새는 CSS를 자동으로 생성해두는 주문형(ON-DEMAND) 패러다임으로 발전하고 있다고 한다.
한번 이 부분도 공부를 해봐야 할 것 같다. 진짜 프로글램은 까도 까도 새로운 것만 나오네요
UnoCSS Playground
uno.antfu.me
어휴~~
CSS의 역사에 대해 한번 블로깅해봤는데 정말 어마어마하네요
중간중간 생략한 부분이 정말 많은데 자료들은 다 영어고 정리가 하나도
안돼 있어서 블로그 작성하기까지 오늘처럼 힘든 날은 처음입니다.
추신 : 아래 블로그가 진짜 진국입니다.
참고 사이트들 전부 첨부해놔요
https://velog.io/@teo/css-history-1#css-in-js% EC% 9D%98-%EB% 8C%80% EC% 9C% A0% ED%96%89-2021
CSS 역사로 알아보는 CSS가 어려워진 이유
저는 사실 UI 구현하는 것보다는 효율적인 CSS가 무엇인지 몰라서 늘 불만스러워요… > 구현은 어떻게든 해서라도 얼추 되겠는데... 그게 좋은 코드같아보이지않아서ㅜㅜ 프롤로그 맞습니다. CSS
velog.io
https://orezytivarg.github.io/css-evolution-from-css-sass-bem-css-modules-to-styled-components/
CSS의 진화 - CSS, SASS, BEM, CSS Modules로부터 Styled Components로
orezytivarg.github.io
728x90
반응형