Svelte란 - OhMinsSup/tip-review GitHub Wiki

Svelte는 프론트엔드 프레임워크다. svelte는 몇가지 특징을 가지고 있다.

svelte는 속도가 매우 빠르다. Svelte는 DOM의 변화가 있을 때 그 부분만 업데이트하므로 실행 속도가 매우 빠르다. 하지만 그건 다른 여타 프론트엔드 프레임워크도 똑같은 부분이다. 하지만 svelte와 다른 프레임워크와의 차이는 가상 돔을 사용하냐 안하냐이다.

Svelte는 가상 DOM을 사용하지 않는다.

가상 DOM 프레임워크는 실제 DOM에 변경을 커밋하기 전 보이지 않는 트리에서 컴포넌트를 그리기 위한 시간을 소비하는 반면, Svelte는 이런 중간 단계를 뛰어넘고 바로 변경한다. DOM 업데이트가 느릴수는 있지만, Svelte는 어떤 요소에 변화가 일어났는지 정확하게 알고 있기 때문에 빠르게 처리할 수 있다

가상 DOM에 대해서 얘기를 해보자면 가상 DOM은 충분히 빠르고 유용하지만 이는 기능이 아닌 수단일 뿐이며, 이를 사용하지 않고도 유사한 프로그래밍 모델을 얻을 수 있다고 Svelte는 설명합니다. 새로운 가상 DOM을 이전 Snapshot과 비교하거나(Diffing), 상태 변화에 따른 새로운 가상 요소생성 등에 많은 오버헤드가 있을 수 있으며 최종적으론 실제 DOM을 업데이트해야 하므로 그 과정을 생략하는 것이 더욱 빠를 수 있다고 합니다.

이에 대한 더 자세한 내용은 Virtual DOM is pure overhead에서 더 자세하게 확인할 수 있습니다. 기존 UI 프레임워크와 달리, Svelte는 런타임에 작업을 기다리지 않고 빌드 시간에 앱에서 변경 사항이 어떻게 발생하는지 알고 있는 컴파일러입니다.

Svelte의 컴파일된 번들 크기는 다른 인기 있는 프레임워크들과 비교해보면 매우 작은 크기를 갖는다.

"Hello World!" 앱의 bundle.js 파일의 크기는 2.3KB이다. 이 번들 파일은 하나의 JS 파일로 Svelte를 모두 포함하고 있다!

이 결과는 React 호환 라이브러리인 작고 멋진 Preact보다 작은 결과이다. Preact는 라이브러리 자체를 위해 용량이 3kb로 시작하게 된다. 그리고 위 예제를 Create React App을 통해 빌드 했을 때 124KB의 자바스크립트 파일이 결과로 나오게 된다. 그래, 그래. gzip을 한 결과가 아니다. gzip을 적용해보면..

$ gzip -c hello-svelte/public/bundle.js | wc -c
    1190
$ gzip -c hello-react/build/static/js/*.js | wc -c
    38496

각 파일은 1.16KB vs 37.6KB 로 작동하게 된다. unzip이 된 이후에도, 브라우저는 여전히 2.3KB vs 124KB를 파싱해야 한다. 작은 번들은 모바일 환경에서 큰 이점이다. 다른 좋은 점은, node_modules 의 폴더 개수는 Hello World Svelte 앱을 띄울 때 단지 29MB, 242개의 패키지뿐이었다. Create React App 프로젝트는 204MB, 1017개의 패키지가 포함되어 있었다. 그래 어쨌든 Dave. 그런 숫자들은 의미가 없어. 그건 작위적인 예시야.

맞다. 물론, 현재 제공되고 있는 큰 규모의 앱들은 1KB든 38KB든 앱을 작동시키는 프레임워크의 크기를 왜소하게 만들 것이다. 하지만 그것이 기본이며, 개인적으로 작고 빠른 환경에서 시작하는 것이 더 좋다고 생각한다.

그리고 심지어 규모가 더 큰 앱의 경우일지라도, Svelte가 더 큰 장점을 누릴 수 있을 것으로 생각한다. 그 이유를 살펴보자.

반응성은 변경된 값이 DOM에 자동으로 반영됨을 의미합니다. Svelte는 별도의 Setter 없이 값의 할당(assignments)만으로 업데이트를 트리거(Trigger)할 수 있습니다. 실제로 상당히 편리합니다! 예를 들어 리액트에서는 이런식으로 값을 변화 시키는데 Svelte는 script 영역에 선언한 것은 반응성있게 값이 변화가 된다는 것이다.

<!-- Svelte -->
<script>
  let count = 0;
  const onClick = () => {
    count += 1;
  };
</script>

<button on:click="{onClick}">+</button>
<div>{count}</div>

// React
const Count = () => {
  const [count, setCount] = useState(0);

  const onClick = useCallback(() => {
    setCount(count++);
  }, [count]);

  return (
    <div>
      <button onClick={onClick}>+</button>
      {count}
    </div>
  );
};

export default Number;

번들 크기가 이렇게 작을 수 있는 이유는 Svelte는 프레임워크이자, 컴파일러이기 때문이다.

아마 당신은 React Project를 컴파일하기 위해 yarn build를 실행하는데 익숙할 것이다. Webpack과 Babel을 호출하여 프로젝트 파일을 번들링 한 뒤, 최소화(minify) 하고, react와 react-dom 라이브러리를 번들에 추가한 뒤, 그 파일을 최소화(minify)하고, 하나의 출력 파일을(혹은 몇 개의 chunk로 분리된 파일을) 생성한다.

반면 Svelte는, 자체적으로 컴포넌트를 컴파일할 수 있다. 결과는 (앱) + (Svelte 런타임 환경)이 아닌, (Svelte가 독자적으로 실행하는 방법을 알려준 앱) 이다. Svelte는 Rollup(혹은 Webpack)의 트리 쉐이킹 이점을 가져와 이용하여 내 코드에서 사용하는 프레임워크의 부분만을 포함해 자체적으로 만든다.

컴파일 된 앱은 여전히 작성한 컴포넌트를 구동시키기 위해 조금의 Svelte 코드를 갖게 된다. 마법처럼 그 코드는 전부 사라지지 않는다. 하지만 이런 부분은 다른 프레임워크들이 작동하는 방법과 반대이다. 대부분의 프레임워크는 실제로 앱을 실행하고, 나타내기 위해 존재해야한다.