SCSS vs styled-Components

Lina Hongbi Ko·2024년 10월 30일

CSS_memo

목록 보기

2/2

✏️ SCSS(Sass)

SCSS를 검색하면, Sass에 대해서 설명하는 글을 먼저 볼 수 있다.

why?

SCSS는 Sass 3버전부터 새롭게 등장했기 때문이다.
SCSS는 Sass의 모든 기능을 지원하는 Superset이다. 게다가 SCSS는 CSS와 거의 비슷한 문법으로 Sass의 기능을 사용할 수 있어 편리하다.
(= CSS 구문과 완전히 호환되도록 새로운 구문을 도입해 만든 Sass의 모든 기능을 지원하는 CSS의 상위집합)

먼저, Sass에 대해서 잠깐 보면

📍 SASS

: Syntactically Awesome Style Sheets

CSS(Cascading Style Sheets)의 단점들을 보완하기 위한 CSS 전처리기.

❓ CSS의 어떤 점들이 불편했을까?

1. 선택자를 만들때 매번 불필요한 부모 요소 선택자를 적어야함
2. 작업, 코드가 많아질수록 유지보수가 불편
...

💡

따라서,
CSS 내 반복되는 내용은 줄이고 보다 효율적으로 스타일시트를 관리하기 위해 Sass가 만들어졌고,
그다음 SCSS로 업그레이드(?) 되었음!

차이점은 (mixin 등 기능이 몇가지 다르지만, 대표적으로)

Sass : 들여 쓰기 사용

.text
  font-size: 20px
  a
    color: #fff

SCSS : CSS처럼 {}와 ;을 사용

.text{
  font-size: 10px;
  a{
    color: #fff:
  }
}

본격적으로 SCSS에 대해서 살펴보자.

📍 SCSS

: CSS 전처리기(Preprocessor)로써 CSS를 더욱 쉽고 편리하게 사용하게 함

SCSS(Sass)는 CSS의 확장 언어이고 스크립팅 언어이다. SCSS(Sass)가 제공하는 문법을 기반으로 코드를 작성한 다음, 이를 컴파일해 CSS 파일을 만든다.

이를 통해,

코드의 재활용성과 가독성을 높임 -> 유지보수 쉬워짐
CSS를 구조화해 사용
CSS의 한계를 보완하기 위해 SCSS(Sass)는 추가 기능과 유용한 도구들을 제공
- 변수의 사용
- 조건문과 반복문
- Import (모듈화)
- Nesting (선택자 반복 작성 줄여주는 기능)
- Mixin (함수 개념)
- Extend/Inheritance (확장/상속)

몇 가지 예시를 보면,

변수 사용

/* css */
.box {
  width: 200px;
  margin-left: 200px;
  background: #e96900 url("/assets/images/bg.jpg");
}

/* SCSS */
$color-primary: #e96900;
$url-images: "/assets/images/";
$w: 200px;

.box {
  width: $w;
  margin-left: $w;
  background: $color-primary url($url-images + "bg.jpg");
}

반복문 사용

/* CSS */
.through:nth-child(1) { width: 20px; }
.through:nth-child(2) { width: 40px; }
.through:nth-child(3) { width: 60px; }

/* SCSS */
@for $i from 1 through 3 {
  .through:nth-child(#{$i}) {
    width : 20px * $i
  }
}

선택자의 중첩(Nesting)을 통해 반복되는 부모요소 선택자 사용 줄임

/* CSS */

.section {
	width: 100%;
 }

.section .list {
	padding: 20px;
}

.section .list li {
	float: left;
}

/* SCSS */

.section {
  width: 100%;

  .list {
    padding: 20px;

    li {
      float: left;
    }
  }
}

변수 사용 -> CSS 속성값을 통일해서 관리
조건문, 반복문 -> 동적으로 CSS 관리 가능
css-in-css 기법으로 속도가 빠름 (별도의 자바스크립트 전환이 필요 없어서 속도가 빠름)
...(더 많은 장점들이 있을 것이다)

❗️ SCSS를 사용하면 위의 장점들이 있지만, 반대로 단점도 있다.

전처리기를 위한 도구가 필요
컴파일 과정이 필요
컴포넌트의 상태값에 따라 스타일을 바꾸는것이 CSS-in-JS에 비해 상대적으로 어려움

✏️ Styled-components

: 컴포넌트 기반으로 CSS를 작성할 수 있게 도와주는 라이브러리

❓ 왜 Styled-components를 사용하게 되었을까?

기존의 웹사이트는 HTML, CSS, JavaScript를 별도의 파일로 두었는데, 최근(벌써 시간이 좀 지났지만..)에는 React나 Vue, Angular와 같은 모던 자바스크립트 라이브러리가 인기를 끌고 컴포넌트 기반 개발 방법이 주류가 되고 있다.

따라서, 각 컴포넌트에 HTML, CSS, JS를 모두 포함하는 패턴이 많이 사용되고 있는 추세여서 CSS-in-JS방식을 많이 선택해서 사용한다.

CSS-in-JS 라이브러리에는 styled-components, emotion 등이 있지만 Styled-components는 사람들이 보편적으로 많이 사용하는 라이브러리 중 하나이다.

Styled Components를 사용하면 컴포넌트 단위로 스타일링하기 때문에 개별 케이스로 분리해 CSS를 작성할 수 있다.(라이브러리를 이용해서 스타일을 바로 입힘 -> 컴포넌트마다 고유한 클래스를 가짐)

💡

이를 통해,

페이지에서 렌더링 되는 요소에 맞춰 자동으로 해당 스타일만 삽입 -> 그때그때 필요한 스타일만 로드 => 컴포넌트 단위의 추상화

import styled from 'styled-components';

const Button = styled.button`
  display: block;
  padding: 6px 10px;
  color: #fff;
  font-size: 18px;
  border-radius: 3px;
  background-color: crimson;
  border: 0;
`;

function App() {
  return (
    <div>
      <Button>버튼</Button>
    </div>
  );
}

export default App;

스타일에 대한 고유 클래스명 생성 -> 중복이나 오타 걱정 X => 진정한 분리 법칙
더이상 사용되지 않는 CSS를 쉽게 삭제 가능 (모든 스타일은 특정 요소와 연결되어 있기 때문에 해당 요소가 삭제되면 스타일도 삭제됨)

동적 스타일링이 편함 -> props를 통해 직관적으로 개별 스타일링 가능


import styled from 'styled-components';

const Button = styled.button`
  background-color: ${(props) => porps.bgColor || 'lightgray' };
  display: block;
  // ...
`;

function App() {
  return (
    <div>
      <Button bgColor="skyblue">확인</Button>
      <Button bgColor="salmon">취소</Button>
    </div>
  );
}

export default App;

// props로 bgColor가 있을 경우 그 값이 적용되고,
// 아니라면 ‘lightgray’ 값이 적용.

밴더 프리픽스 (-webkit-, -moz, -webkit- 등)가 자동생성
SCSS와 마찬가지로 Nesting(중첩) 가능 -> &을 이용한 스타일링
...(더 많은 장점들이 있을 것이다)

❗️ StyledComponents를 사용하면 위의 장점들이 있지만, 마찬가지로 단점도 있다.

스타일까지 하나의 파일로 관리하다보니 컴포넌트의 규모가 커지면 그만큼 파일 하나의 내용이 많아져서 한눈에 파악하기가 어려움 -> 스크롤 계속 위 아래로 왔다갔다하는 번거로움 발생
별도의 라이브러리 설치로 인한 번들 크기 커짐 -> JS가 모두 로딩된 후에 CSS 코드가 생성되어 다운로드 시간이 길어짐
인터랙션의 시간이 늦어짐 -> css-in-js 방식으로 인해 컴포넌트가 렌더링 될 때 해당 스타일 정보를 읽음 -> 동적인 이벤트가 많은 사이트라면 컴포넌트가 자주 렌더링 되어서 그만큼 스타일 정보도 다시 읽어와야해 성능 이슈 발생
(css in css는 이미 html문서에 읽혀져 있는 상태이기 때문에 처음에 스타일 정보를 가져오는 양이 많더라도 그 후 추가적인 렌더링은 상대적으로 style-components보다 적음)

✏️ 어떤 방식이 더 효과적?

둘을 비교해봤는데, 그럼 어떤 것을 쓰는게 더 효과적일까?

어떤 프로젝트를 하느냐에 따라 다르다.

둘의 가장 큰 차이점은

SCSS : css-in-css vs Styled-components : css-in-js

프로젝트에 둘 중, 하나 효과적인 것을 선택해야할 때
css-in-css방식이 효과적일지, css-in-js의 방식이 효과적일지 비교해보고 사용하는게 좋을 듯하다.

둘 중 하나를 선택할 때 생각해보면 좋을 것들

컴포넌트 기반인 프로젝트인가?
렌더링이 많이 필요한 인터렉티브한 웹사이트인가?
초기 로드 속도가 중요한 콘텐츠가 많은 웹사이트인가?
개발 생산성과 유지보수에 어떤 것이 더 효율적인가?

💡 어떤 프로젝트에 더 적합할까?

사람들이 말하는 '좀 더 적합'한 경우

css in css (SCSS)
- 큰 규모의 프로젝트를 개발하는 경우
- 분업에 용이한 구조를 원하는 경우
- 렌더링 성능을 최적화해야 하는 경우 -> 컨텐츠가 많은 웹사이트
- 렌더링 속도가 빨라야 하는 인터렉티브한 프로젝트에 적합
- 별도의 자바스크립트 전환이 필요 없이 빠른 속도
css in js (Styled-components)
- 개발의 효율성이 중요한 컴포넌트 위주의 프로젝트에 적합
- 웹 컴포넌트를 개발하는 경우
- CSS와 자바스크립트의 상호 작용이 용이한 구조를 원하는 경우
- CSS의 재사용성을 높이고 싶은 경우