들어가기에 앞서 필자는 노드 버전 v20.10.0을 사용하였으며
Next.js는 v14.0.4를 사용함

Next.js 설치

먼저 StyleX를 적용하기 위해 Next.js를 먼저 설치해준다.

npx create-next-app@latest .

그 다음부터는 공식문서를 보고 따라했다.
StyleX 설치 공식문서

StyleX 패키지 설치

npm install --save @stylexjs/stylex

위 명령어를 실행하여 StyleX에 대한 패키지를 설치해준다.
그리고 Babel을 별도로 설정해주어야 한다.

여기서 바벨이란?
=> 바벨은 크로스 브라우징 이슈를 최소화하기 위해 ES6+ 버전의 자바스크립트나 타입스크립트, JSX 문법 등을 모든 브라우저에서 호환 가능하도록 변환시켜주는 역할을 한다.
따라서, 크로스 브라우징 이슈와 밀접한 관계가 있는 프론트엔드 개발자에게 바벨 설정의 능력이 요구되고는 한다.

StyleX도 자신만의 표현을 브라우저가 알아들을 수 있게 번역(?)해줄 필요가 있는데 바벨 설정을 통해 해결할 수 있다.
현재 Rollup, Webpack 등 모듈 번들러에 대한 바벨 플러그인을 별도로 지원하는데,
맨 아래 보면 Next.js 전용으로 지원하는 플러그인이 존재해 이를 사용할 예정이다.

Babel Plugin 설정

공식문서에 따르면 babel.config.js 파일과 .babelrc.js 파일 두 가지를 제공하고 있는데
둘 다 바벨 설정이 가능한 파일이라 하나만 골라 쓰면 된다.

위에서 언급했듯이 필자는 Next.js 용으로 제공되는 .babelrc.js 설정을 통해 바벨 플러그인을 설정하였다.

npm install --save-dev @stylexjs/nextjs-plugin

먼저 패키지를 설치해주고 나서
.babelrc.js 파일을 작성한다.

//.babelrc.js
module.exports = {
  presets: ['next/babel'],
  plugins: [
    [
      '@stylexjs/babel-plugin',
      {
        dev: process.env.NODE_ENV === 'development',
        runtimeInjection: false,
        genConditionalClasses: true,
        treeshakeCompensation: true,
        unstable_moduleResolution: {
          type: 'commonJS',
          rootDir: __dirname,
        },
      },
    ],
  ],
};

그 다음 next.config.js 파일을 수정한다.

//next.config.js
const stylexPlugin = require('@stylexjs/nextjs-plugin');

module.exports = stylexPlugin({
  rootDir: __dirname,
})({});

여기까지만 설정해도 StyleX는 적용된다.

StyleX 코드 작성 및 실행

폴더 구조는 아래와 같으며 page.tsx에는 스타일을 확인하기 위한 코드를 작성했다.

여기서 하나 주의할 점이 있는데, app 디렉토리 하위에 globals.css는 layout.tsx에 import 되어있어야 한다.
(globals.css가 없으면 오류는 발생하지 않지만 스타일 적용이 되지 않는다… 이거 찾느라 5시간 정도 걸린 것 같다…!)

저 코드를 작성하고 npm run dev를 실행시키면 스타일이 잘 적용된 것을 볼 수 있다.

이전 포스트에서 처음에 StyleX를 소개하길 JS Object 형태로 스타일을 정의하나
서버 코드로 동작시킬 수 있다고 언급했었는데 크롬 설정에 자바스크립트를 꺼놓고 확인을 해보았다.

마무리

StyleX 설치 및 동작에 대해 알아보았다. 중간에 막히는 부분이 있었지만 다행히 다음 Step으로 넘어갈 수 있었다.
현재까지는 겉핥기 수준이라 좋은지 아닌지는 잘 모르겠다. StyleX에서 지원하는 강력한 기능들이 있는데 직접 써보고 별도 포스팅을 할 예정이다.

-끝

(혹시 제가 작성한 내용에 오류가 있어 수정이 필요한 부분을 친절히 알려주시면 정말 감사드리겠습니다…!)

Meta(Facebook)에서는 얼마 전 StyleX라는 명칭의 라이브러리를 오픈소스화 하여 제공하고 있다.
StyleX는 Meta 내부적으로 사용하던 스타일링 방식인데 소개 및 특징에 대해 다루고자 한다.

StyleX가 무엇일까?

우리는 보통 Web Frontend 페이지에 스타일을 적용할 때 Css를 사용한다. 그러나 차츰 JS 형태로 스타일링을 구현하는 형태를 사용하기 시작하였고 CSS-in-JS, Styled-Components 등이 대표적이다.

기존에 이런 훌륭한 기술들이 존재하는데 왜 또 StyleX라는게 나타나서 개발자들을 괴롭히는가?

아무리 좋은 라이브러리라고 해도 약점이 있기 때문이다.
때문에 기존 유명한 라이브러리들의 약점을 보완하며 장점들을 살릴 수 있는 새로운 기술이 지속적으로 개발되고 있다.

StyleX도 다르지 않다. CSS-in-JS와 유사한 형태로 사용자에게 익숙한 느낌을 주되, 여러가지 불편한 부분들에 대해 보완이 진행된 버전이라고 볼 수 있겠다.

StyleX의 특징

StyleX의 특징을 알아보자.
먼저 StyleX는 CSS-in-JS의 솔루션이다.

1. CSS-in-JS의 약점 극복

CSS-in-JS는 아래와 같은 약점을 가지고 있다.

1. 같은 요소에 여러가지 스타일을 적용할 수 없다.
2. 조건부 스타일을 사용할 수 없다.

Ex) css-in-JS의 형태

const styles={
	button: {
		background: 'red';
	},
	button2: {
		fontSize: 1rem;
	}
}

const button = () => <button style={styles.button}>Hello!</button>
// button에 이미 스타일이 적용되었기 때문에 button2는 적용 불가

이러한 제약은 서비스를 만들어낼 때 많은 불편함을 초래한다.
기본적으로 코드가 길어지고 인적, 시간적 비용이 자연스럽게 늘어나게 된다.

반면에 StyleX를 사용하면 위 문제들을 해소할 수 있다.

import * as stylex from '@stylexjs/stylex'
const styles = stylex.create({
	button: {
		background: 'red';
	},
	button2: {
		fontSize: 1rem;
	}
})

const button = () => <button {...stylex.props(
	styles.button,
	styles.button2,
	isActive && styles.active
)}>Hello!</button>

2. StyleX는 컴파일러다.

컴파일러 : 사람이 작성한 코드를 기계어로 번역하는 것

프로젝트를 빌드할 때 StyleX는 사용자가 정의한 스타일을 JS 객체로 가져와 이를 원자적 css로 변환한다.

import * as stylex from '@stylexjs/stylex'
const styles = stylex.create({
	button: {
		background: 'red';
	}
})

const button = () => <button {...stylex.props(styles.button)}>Hello!</button>

위와 같은 코드가 있을 때

const button = () => <button className="2cbc1xo">Hello!</button>

이와 같은 코드로 컴파일 한다.

기존 CSS-in-JS는 스타일 적용시 자바스크립트에 의존적이므로 속도가 느려질 수 있는데,
컴파일을 진행되면 렌더링 과정에서 style에 대한 자바스크립트 코드가 적용될 필요가 없어지므로 이를 개선할 수 있다.

그리고 필자는 아래와 같은 이유 때문에 StyleX을 공부하게 되었는데
바로 Next.js와 같은 서버 컴포넌트 사용시 JS 기반 스타일링을 사용하기 위함이다.

브라우저 렌더링 과정을 보면 HTML, CSS를 파싱하여 트리구조를 만들고 이후에 JS 코드를 적용하는데,
StyleX를 사용하면 스타일링에 대한 부분을 hydration하는 과정이 사라지기 때문에
JS 적용 이전에 스타일링이 적용된 화면을 제공할 수 있게 된다.

3. Type 안정성이 보장된다.

StyleX는 모든 css 스타일링에 대해 Type 지정이 내장되어있다.

예컨데 아래와 같을 수 있겠다.

type position = 'static' | 'relative' | 'absolute' | 'sticky' | 'fixed';

이러면 유저에게 명확한 속성을 제공하고, 오류가 발생했을 때 원인을 찾기 용이하다.

마무리

여러가지 특징이 더 존재하지만 앞서 소개한 세 가지가 대표적이라고 할 수 있을 것 같다.
이 정도만 봐도 StyleX는 정말 많은 것을 제공한다.
그렇지만 다른 라이브러리가 절대 약하다는게 아니다.
프로젝트 규모와 컨셉, 각 회사에 맞는 코드 컨벤션에 따라 어떤 Style 방식을 적용할지에 대해서는 답이 없다.

그래도 필자는 꼭 써볼 예정이다.
써보고 괜찮으면 주력 스킬로 가져가야지

CSR(Client Side Rendering)이란?

어떤 유저가 리액트로 제작된 어떤 웹사이트에 접속한다고 가정해보자.
유저는 바로 Client가 되는 것이고 웹 서버에 접속하려는 사이트를 요청한다.

서버에서는 요청을 받고 빈 HTML 파일을 우선 전송한다.
클라이언트의 화면에는 빈 HTML을 그리기 때문에 빈 화면이 나타나고, 뒤늦게 React 소스 코드와 개발자가 웹 페이지를 구현하기 위해 작성한 JS파일을 다운로드 받아 읽어내고, 그리고 마침내 화면에 그려낸다.

요약하자면 클라이언트의 요청에 따라 HTML, React 라이브러리 자체, 개발자가 구현한 소스 코드 등의 파일을 모두 다운로드 한 후 DOM을 구성하고 그려내 화면에 나타내는 것.
바로 이것이 Client Side Rendering이라고 할 수 있다.

CSR의 장점

1. Client Side Rendering의 장점으로는 한번 로딩 되면, 빠른 UX를 제공한다.
2. Client에 화면을 구성하는 대부분의 요소가 존재하기 때문에 서버의 부하가 그만큼 적다.

CSR의 단점

1. 서버로부터 화면 구현에 필요한 요소를 받아와야 하기 때문에 페이지 로딩 시간 (Time To View)이 길다.
2. 자바스크립트 활성화가 필수이다.
   사용자가 브라우저 설정을 통해 자바스크립트 활성화를 꺼버린다면 어떠한 페이지도 볼 수 없다.
3. SEO 최적화가 힘들다.
   검색 엔진 로봇들이 웹사이트를 돌아다니며 메타 데이터 / Sementic Tag 등을 분석해 검색어와 연관 있는 요소들을 찾아 검색 엔진에 등록하는데, CSR의 경우 웹 페이지가 Client측에서 그려지고 나서야 이런 작업들이 가능하다.
4. 보안에 취약하다.
   페이지를 표기하기 위해서 어떤 서버에서 어떤 데이터를 받아오는지 이런 불안 요소들이 외부에 노출 될 수 있다.
5. CDN에 캐시가 안된다.
   Content Delivery Network의 약어로 각 국가나 지역에 있는 네트워크를 뜻한다.
   예를 들어 한국에서 미국으로 웹서버 요청을 전송 했을때, 도쿄 혹은 싱가포르 등 근처의 네트워크에 데이터를 캐싱할 수 있다.
   따라서 동일한 미국 서버에 여러번 접근 하더라도 근처에 이미 캐싱 된 데이터가 있기 때문에 응답이 빨라지는데,
   CSR에서는 HTML이 텅텅 비어있기 때문에 CDN에 캐싱하기 어렵다.

SSG (Static Site Generation)이란?

CSR이 처음에는 좋아보였지만, 앞선 포스팅에서 꽤나 비중 높은 단점들이 존재했고 이런 애로사항을 해소하고자 배포할때는 정적인 사이트로 전환해서 배포하는게 어떨까? 해서 나온게 SSG이다.

SSG의 특징

위에서 설명했듯이 렌더링 하는 주체자가 서버이다.
이후에 나타날 SSR과 동일하게 서버에서 렌더링을 하지만, 차이가 있다면 렌더링이 되는 시점이다.
SSG는 어플리케이션을 빌드할 때 렌더링한다.
빌드를 하는 과정에서 HTML에 React/JS 코드를 적용하고 필요하다면 클라우드나 DB에 있는 데이터를 fetch하여 정적인 웹페이지들을 미리 제작해둔다.

SSG의 장점

1. 페이지 로딩 시간이 빠르다.
2. 자바스크립트가 필요 없다.
3. SEO 최적화가 좋다.
4. 보안이 뛰어나다.
5. CDN 캐시가 된다.

SSG의 단점

1. build 시점에 렌더링이 되기 때문에 데이터가 정적이다.
   => 데이터가 가변적으로 변경되는 웹사이트의 경우 적절하지 않다. (예를 들면 실시간 날씨 정보 등등)
2. 사용자별 정보 제공이 어렵다.
   => 사용자가 1,000명 10,000명이라면 그만큼의 정적 파일들을 미리 렌더링해야 한다.
   => 이런 경우 서버 부하가 심하다.

ISR (Incremental Static Regeneration)이란?

SR도 SSG와 마찬가지로 빌드 단계에서 정적인 html을 전부 만들어 놓는 것은 동일하지만 주기적으로 변경사항에 대응할 수 있도록 한 방식이다.

ISR의 특징

SSG의 특징을 전부 가지고 있으며 주기적으로 빌드를 하기 때문에 데이터 업데이트가 가능하다.

SSG의 장점

1. 페이지 로딩 시간이 빠르다.
2. 자바스크립트가 필요 없다.
3. SEO 최적화가 좋다.
4. 보안이 뛰어나다.
5. CDN 캐시가 된다.
6. 데이터가 주기적으로 업데이트 됨

SSG의 단점

1. 데이터가 주기적으로 업데이트 되지만 이 또한 실시간 데이터가 아니다.
2. 사용자별 정보 제공이 여전히 어렵다.

SSR (Server Side Rendering)이란?

SSR은 렌더링을 하는 주체가 서버이며, 클라이언트가 요청을 할 때마다 렌더링을 진행하는 특징이 있다.

SSR의 장점

1. 페이지 로딩 시간이 빠르다.
2. 자바스크립트가 필요 없다.
3. SEO 최적화가 좋다.
4. 보안이 뛰어나다.
5. CDN 캐시가 된다.
6. 실시가 데이터를 사용한다.

SSR의 단점

1. SSG, ISR과 비교했을 때 상대적으로 느릴 수 있다.
2. 클라이언트의 요청마다 서버에서 렌더링을 진행하기 때문에 부하가 굉장히 커질 수 있다.

마무리

CSR, SSG, ISR, SSR에 대해 간략하게 알아보았다.
각각의 장단점이 뚜렷하기 때문에 Next.js에서는 위 네 가지 방식을 적재적소 사용할 수 있도록 지원한다.

어플리케이션을 어떻게 구성하고 각 기능마다 어떤 렌더링 기법을 사용할 것인지 많은 고민이 있어야 사용자 경험이 좋은 페이지를 제작할 수 있을 것 같다.