svelte 한 달 써본 후기

스벨트란?

• Svelte는 2016년 출시한 오픈 소스 프론트엔드 웹 프레임워크이다.

• 기존의 React나 Vue.js 등의 널리 알려진 웹 프레임워크와 달리, 가상 DOM을 사용하지 않으며 빌드 단계에서 구성 요소를 컴파일하여 성능이 향상되었다.

스벨트는 왜 빠르다고 할까?

• 적은 코드

• 가상 돔 없음

• 진정한 반응형

적은코드

• 주워온 예시에 의하면 같은 기능(상태로 덧셈하기)을 구현할 때 스벨트는 145자를 사용하고 리액트는 442자, 뷰는 263자를 사용했다.

• 근데 이것도 이 예시는 그렇다해도 모든 경우에 대해 이렇게까지 확실하게 차이가 날까는 의문이다. value를 bind할 일은 value를 가진 input이나 button 정도 일텐데 버튼이나 input은 프로젝트의 아주 일부일 뿐 아닌가 싶다.

• 추가로 스벨트는 dx를 생각했다고 한다. 예를 들어 한번만 실행하고 싶은 경우 pipe처럼 once키워드를 사용할 수 있다거나 prevenDefault도 파이프 형태로 작성할 수 있다.

<script>
	function handleClick() {
		alert('no more alerts')
	}
</script>

<button on:click|once={handleClick}>
	Click me
</button>

진정한 반응형

• Svelte에서 주장하는 반응성이란 Virtual DOM을 사용하여 변경된 요소를 하나하나 비교하고 찾아내어 반영하는 것이 아닌, 빌드 시간에 정확하게 어디가 어떻게 변경될지 알고 반영하는 것이라고 말한다. 빌드 타임에 이러한 작업을 수행하기 때문에 Svelte는 자신이 컴파일러라고 주장한다.

• 컴파일러는 런타임에서 변경된 요소를 찾느라 시간을 허비하지 않고, 컴파일러와 같이 빌드 시 실제 변경된 요소가 어디에 어떻게 변경됐는지 정확하게 찾아내는 최적화된 작업을 수행한다.

• 컴파일이 뭐길래 이러냐한다면..

• 스벨트에서 js로 변환하는 과정이 컴파일이다. 그럼 리액트는 컴파일을 안쓰냐? 바벨로 쓴다. 스벨트는 자체 지원이 되는거고 리액트는 안되니까 바벨을 쓰는 것이다.

• 혹시나 해서 말하자면 웹팩, 롤업은 코드들을 압축시켜주는 번들러이다.

• 근데 한 가지 의문이었던 건 스벨트 프로젝트에 babel을 검색하니 검색 결과가 있었다. yarn.lock에서 발견되었는데 이는 tslint 등 스벨트가 아닌 다른 곳에서 babel을 사용하기 때문이다. 결국 스벨트는 babel을 쓰지 않았다.

가상 돔 없음

• 나는 이 부분이 가장 큰 핵심이라고 생각한다. 물론 가상돔을 채택하지 않은 건 스벨트뿐만 아니지만 스벨트에서 리액트를 어떻게 평가하고 있는지가 너무 재밌어서 주의깊게 봤다.

• 가상돔은 실제 브라우저를 그리는 dom과 매우 유사하게 만든 만든 가상의 dom이다.

• 스벨트는 가상돔이 빠르다라는 오해가 2013 리팩트 컨퍼런스에서 생겼다고 말하는데 이렇게 ppt 만들어놓으니까 오해가 생길 것 같기도 하다.

• 확실히 해둘건 가상돔은 실제 돔보다 빠르지 않다는 것이다. 중간에 연산을 하나 더 하는데 빠를리가 없지 않겠는가! 특히 구성 요소가 많은 대규모 프로젝트의 경우 diff 계산에 시간이 걸린다고 한다.

• 그렇다면 가상돔은 빠르지도 않은데 도대체 왜만든 것인가.. 사실 나도 실제 돔과 비교해 효율적으로 그릴 수 있다고 알고만 있었지 왜 가상돔을 핵심 개념으로 잡았는지 의문이 생겼다. 여기서 깨달은 건 다음과 같다.
• 가상돔은 특별한 개념이다.
• 리액트부터 시작해서 그런지 가상돔이 당연하게 느껴졌는데 스벨트를 보면서 가상돔이 특별한 개념이고 보통은 가상돔을 채택하지 않고 만들어졌구나라고 깨달았다.
• 리액트는 가상돔을 채택했다. 왜!?
• 바로 복잡한 프로젝트를 위해서! SPA는 하나의 문서에서 모든 DOM이 조작된다. 복잡한 프로젝트의 경우 최적화되지 않은 작업이 많을 때 DOM이 과도하게 사용되는 경우가 있어 이를 방지하기 위해 만들었다.
• 예를 들어 리액트에서 리스트 a, b, c가 있을 때 a만 업데이트 했음에도 불구하고 b, c도 렌더링 되는 경우를 봤을 텐데 이걸 수백개라고 생각했을 때 리액트는 과한 컴퓨팅 연산이 일어날 것을 걱정했던 게 아닐까 싶다.
• DOM을 그리는 건 컴퓨팅 연산을 필요로하고 컴퓨터가 과부하되면 페이지가 다운되거나 느려지니까..
• 이것이 리액트가 상태가 자주 바뀌는 반응형 페이지에 적합하다고 말하는 이유이다.
• 그럼 가상돔은 돔 연산 비용을 줄일 유일한 방법인가?
• 아니다! ember js, angular, svelte는 다른 방식으로 같은 문제를 해결하고, 리액트 뷰 등은 가상돔으로 해결했을 뿐이다.
 

• 코드가 짧다. dx를 생각한 부분도 존재함.

• 가상 돔 없음

• 컴파일 단에서 js로 변환

리액트 vs 스벨트

• 이 표만 봐도 리액트는 스벨트보다 빠를 수 없다는 게 느껴진다.

• 좀 더 정확히 말하면 스벨트는 원하는 상태만 바꾼다. 하지만 리액트는 실제 돔과 가상돔을 diffng이란 알고리즘으로 전체를 비교하고 변경을 하고 부모가 바뀌면 자식들도 다시 렌더링되기 때문에 스벨트가 더 빠르다.

장단점

장점

• 빠르고 가볍다. 하지만 체감은 못했다.

단점

• 라이브러리 등의 자료가 부족하다.
• 페이지네이션을 만들 일이 있었는데 당연히 라이브러리가 있을 거라 생각했는데 v0.0.1인 라이브러리 말고는 발견하지 못했다. 그래서 결국 만들었다.
• 만들면서 사소한 부분은 계속 고쳤는데 만들면서 이걸 만드는 데 왜 시간을 쓰고 있어야 하지 라는 생각이 들었다.

• 비슷한 맥략으로 참고할만한 좋은 코드가 많이 없다.
• 예시들이 있긴 하지만 리액트만큼 많지 않다보니 버전이나 어떤 사람이 만들었는지 자꾸 보게 됐다. 그리고 물어볼 사람도 많지 않아서 스벨트 관련 오픈채팅방 들어가서 물어보고 그랬다.

• 그래도 한 가지 기대되는 건 sveltekit다. sveltekit는 next js처럼 페이지 폴더 하위에 생성한 파일은 페이지가 된다고 들었다. 이런 걸 보면 next js도 리액트 기반이니 잘 만들어져도 리액트처럼 만들어지는 건가 싶다. 스벨트로 프로젝트를 할 때 sveltekit 도입을 고려했지만 정식 1버전이 나오지 않은 채 next를 사용한 버전으로 맨날 업데이트 중이다. 심지어 공식문서에서도 바뀔 거라는 공지가 크게 적혀있어서 결국 도입하지 않았다 (빨리 나왔으면..).

마치며