logo
About

스벨트와 리액트

스벨트와 리액트에 대해 정리한 글

2021-12-12

Svelte vs React: Ending the Debate를 읽으며 정리한 글입니다.

리액트

리액트는 페이스북에서 자체적으로 사용하기 위해 만든 라이브러리이며, 지금도 페이스북에서 관리하고 있다.

처음 접하는 사람도 배우기가 쉽고, 개발속도도 빠르며 많은 개발자들이 사용하는 만큼 참고할 만한 사례들이 많다.

또 가장 큰 특징은 재사용이 가능한 컴포넌트를 사용해 인터페이스를 구성하고, Virtual DOM을 사용해 앱의 성능을 향상시킨다는 것이다.

스벨트

스벨트는 최근에 등장한 언어이고, 리액트, 뷰 등의 기존 프레임워크 및 라이브러리를 보완하고자 2016년에 출시되었다.

Rich Harris가 개발했으며, 스벨트의 멤버들이 관리하고, 현재 스포티파이, 어베스트, 등의 회사에서 사용하고 있다.

스벨트의 공식사이트에서는 프레임워크라 소개하고 있지만 사실 컴파일러와 유사하다.

가볍고 빠른 앱을 만들기 위해 가능한 적은 양의 JS코드를 생성하고 적절한 최적화를 보장한다.

- 등장 배경

리치 해리스는 템플릿 기반 UI 라이브러리인 리액티브의 개발자다. 해리스는 이 언어를 그닥 좋아하지 않았고, JS는 덩치가 커 모바일 환경에서는 부담이 크고 치명적인 단점이 있으며 이를 해결하지 못했기 때문이다.

스벨트와 리액트의 차이점

post image post image

스벨트의 장점

1. 스벨트가 더 성능이 좋다.

스벨트는 리액트, 뷰, 앵귤러 보다 더 좋은 성능을 보여준다.

속도, 로딩, 메모리 등 모든 테스트에서 스벨트가 우위에 있다.

그 이유는 스벨트가 런타임이 아닌 빌드 타임에 애플리케이션 코드를 해석하기 때문이다.

또 HTML, CSS, JS가 최적화된 작은 번들로 컴파일이 되기 때문에 스벨트는 앱 비즈니스 로직 처리에만 신경쓰면 된다.

다른 프레임워크는 브라우저가 무거운 작업을 수행할 수 밖에 없도록 강제하므로 모든 부분에서 느려진다.

또 가장 큰 이유는 Virtual DOM이 없다는 것이다.

2. 스벨트는 Virtual DOM을 비교하지 않는다.

리액트에서는 Virtual DOM을 사용해 좋은 성능을 제공했고, 뷰도 이것을 보고 큰 영향을 받았다.

여기서 Virtual DOM(가상 돔)이란 사용자 인터페이스에서 발생한 모든 변경 사항에 대한 문서 객체 모델(Document Object Model)을 메모리에 유지하는 가상 임시 저장소이다.

실제 DOM을 사용하면 각각의 변경 사항이 발생할 때마다 DOM이 이를 반영하기 때문에 애플리케이션의 속도가 느려질 수 밖에 없다.

반면에 가상 DOM은 실제 DOM의 변경사항을 업데이트하고 렌더링하는 가장 효율적인 방법을 찾을 때까지 해당 프로세스를 지연시킨다.

이를 **조정(reconciliation) 프로세스 또는 비교(diffing)**라고 한다.

스벨트는 꼭 가상 DOM을 사용해야만 뛰어난 성능을 달성할 수 있다라는 점에 동의하지 않았고, 이를 증명했다.

3. 스벨트가 더 반응이 뛰어나다.

리액트는 선언적(declarative) 언어로써 어떠한 결과를 얻기 위해 각 단계를 모두 정의하는 대신에 원하는 결과만 지정하고 나머지는 리액트가 알아서 처리한다.

그러나 값이 변경되었을때 자동으로 DOM에 반영하지 않는다. 리액트는 정해진 일정에 따라 컴포넌트를 업데이트 한다. setState, Hook을 사용하지 않으면 제대로 반영되지 않는다.

스벨트도 이와 비슷하게 동작하지만 업데이트 명령을 받았을 때 동작한다. 그전까지는 발생한 모든 변경 사항이 한번에 처리된다.

그러나 고려해야할 부분은 반응형 선언문과 변수이다. 반응형 선언문(reactive delaration)은 업데이트가 발생하는 동안 자동으로 로직을 다시 계산하는 역할을 한다. 그리고 반응형 변수는 일단 선언하면, 변경이 발생할 때마다 다른 변수들도 자동으로 변경한다. 이는 $ 기호를 추가하는 것 만으로 쉽게 가능하다.

4. 스벨트의 컴포넌트는 약간 다르게 처리된다.

우선 스벨트는 컴포넌트를 내보내기 위해 아무런 동작도 할 필요가 없다. 스벨트가 자동으로 export해주기 때문이다. 이에 반해 리액트에서는 이를 수동으로 수행해야 된다.

또 스벨트는 스타일 태그에서 컴포넌트의 범위를 지정하므로 유연한 스타일 지정을 할 수 있다.

또 컴파일 단계에서 생성하므로 고유한 클래스를 작성하는데 애쓸 필요가 없다.

5. 스벨트에는 외부 라이브러리가 필요하지 않다.

리액트는 뷰 영역에 초점을 맞춘 가벼운 라이브러리이며, 상태관리나 애니메이션을 구현하려면 외부 라이브러리를 사용해야 한다.

이것이 꼭 나쁜것은 아니며 기능이 거의 없는 소규모 프로젝트의 경우에는 완벽할 수 있다.

그러나 스벨트에는 앱의 크기를 늘리지 않으면서도 효과, 전환, 애니메이션 등이 내장되어 있어 필요한 부분만 불러오면 된다.

또 스벨트는 다음과 같이 상태 관리를 할 수 있다.

6. 스벨트가 더 가볍다.

GZIPPED(압축된) 버전의 리액트는 42.2KB(ReactDOM포함), 스벨트는 1.6KB 이다.

7. 스벨트는 더 빠른 웹 개발을 제공한다.

리액트의 개발 속도는 너무 빠르다 못해 이를 단점 중 하나로 인용되기도 한다.

하지만 스벨트의 개발 속도는 이보다 더 빠르다.

컴파일을 통해 생성된 코드는 리액트보다 짧고 읽기도 쉽다. 더 적은 수의 코드로 비슷한 결과를 얻어 낼 수 있으며, 이는 유지보수와 디버깅이 더 쉬워진다는 것을 의미한다.

8. 스벨트가 더 배우기 쉽다.

리액트와 스벨트 둘 다 HTML, CSS, JS에 대한 지식이 필요하다.

그러나 리액트에서는 JS에 대한 XML과 유사한 JSX를 배워야하지만, 스벨트는 더 쉬운 구문을 사용해 이해하기 쉬운 자체 템플릿 언어를 가지고 있다.

스벨트의 단점

1. 커뮤니티 규모가 작다.

리액트는 많은 사용과 큰 인기로 커뮤니티 규모도 크고 많은 무료 강좌와 가이드 등을 쉽게 구할 수 있고, 개발자 도구(React Revdloper, Redux DevTools 등) 생산성 향상에 도움을 주는 도구들이 많이있다.

그러나 스벨트는 리액트 규모만큼의 커뮤니티와 기술 지원을 기대하기 어렵다.

특히 플러그인, 통합, IDE에 대한 부족한 지원이 가장 큰 장애물이고, 문제가 발생하면 사용자에게 도움을 주지 못할 수도 있다.

2. 스벨트는 기업이 지원하지 않는다.

리액트는 페이스북이 지원하고 있고, 페이스북에서 직접 사용할 목적으로 만들고 관리를 하고 있다.

또 페이스북은 리액트의 지속적인 업데이트와 유지, 발전을 하기위한 자금을 가지고 있다. 이는 리액트에 미래에 대해 크게 걱정할 필요가 없다는 것을 의미한다.

하지만 스벨트는 미래가 명확하지 않다. 작은 커뮤니티에서 유지 관리를 하고 있지만, 그들의 열정이 얼마나 오래갈지는 아무도 알 수 없다.

또 스벨트에서 영감을 받은 또 다른 언어가 등장해 이 자리를 대체 할 수도 있다.

3. 스벨트는 대규모 웹에 거의 사용되지 않는다.

스벨트는 최근에서야 대기업 애플리케이션에 규모를 지원하도록 성장했다. 이는 스벨트의 사용 사례가 많지 않다는걸 의미한다.

결론

스벨트는 많은 것을 제공한다.

크기, 효율적은 코드, 빠른 성능으로 리액트, 뷰 또는 앵귤러에 강한 경쟁자로 보일 수 있다.

하지만 스벨트는 아직 갈 길이 멀다. 지금까지는 인터넷 연결이 낮거나, 블로그, 포트폴리오 등 단순히 개인 웹사이트를 만드는 단일 페이지 애플리케이션을 구축하는데 사용하는 것이 좋다.

또 큰 회사들의 기술 스택을 스벨트로 교체하기에는 많은 시간이 필요할 것이며 스벨트의 개발자들의 수요 또한 거의 없다.