자바스크립트 웹 프레임워크의 발전사와 최신 트렌드 (3)

흩어지고 분열되는 자바스크립트 생태계

SPA는 여전히 프론트엔드 개발의 기본 스펙이고, React는 논쟁의 여지없이 대표적인 SPA 어플리케이션입니다. React는 오직 하나의 계층만을 제공하고 필요한 다른 계층은 생태계에 맡기면서, 다른 모든 중요한 측면에서의 변화를 야기했습니다.

라우팅, 상태 관리, 데이터 가져오기 등은 각각 고유한 개념과 API들을 가지고 있었고, 불변성과 가변성, 클래스 기반의 OOP와 함수형 스타일 등에 대한 다양한 토론과 함께 라이브러리들이 계속해서 개선되고 새롭게 추가되는 환경 속에서, 너무나 많은 개발자들이 어떤 선택을 해야 하고 어떻게 설계해야 하는지에 대한 불확실성에 빠져 버리고 말았습니다.

React의 대안들

React의 컴포넌트 모델은 여전히 확고한 개발의 축으로 기능하고 있지만, 런타임 비용, 자바스크립트 기반 JSX와 복잡성 등은 여전히 논쟁의 대상이 되고 있는데, 이에 대한 대안으로 Vue, Svelte, Solid 등의 다른 자바스크립트 프레임워크가 새롭게 많은 개발자들의 주목을 받게 됐습니다.

Vue

개발자들이 Angular2 또는 React로 마이그레이션 하는 것을 논의할 때, Vue는 상대적으로 낮은 진입 장벽을 통해 Angular2, React와의 차이를 좁힐 수 있었습니다. Vue는 복잡한 웹팩 구성 때문에 골치 아플 필요가 없었고, CDN의 도입으로 많은 개발자가 직관적으로 사용할 수 있는 템플릿으로 컴포넌트 구축을 시작할 수 있었습니다.

또 라우팅 및 스타일링과 같은 핵심 컴포넌트들을 템플릿에서 사용할 수 있었기 때문에 의사결정의 피로를 줄일 수 있었고, 템플릿에 정적 분석을 사용하여 더 빠른 런타임을 위한 최적화를 허용함으로써 React의 조정 알고리즘을 개선했는데, 이것을 컴파일러 정보 가상 DOM이라고 합니다.

Svelte

Svelte는 사전 컴파일이라는 접근 방식으로 런타임에서 개발자들이 겪는 복잡성과 오버헤드를 제거했는데, 이 아이디어는 최소한의 자바스크립트를 간소화된 출력으로 자체 컴파일하는 프레임워크를 갖는 것이었습니다.

Svelte는 익숙한 가변 스타일의 자바스크립트를 사용하는 선언적 컴포넌트를 기반으로 현대적인 개발 경험을 유지하려고 했는데, 가상 DOM을 완전히 탈피하여 상태 업데이트와 같은 작업을 수행하기 위한 불변 스타일의 자바스크립트를 작성하는 제약에 얽매이지 않았고, 이를 통해 많은 개발자들에게 웹 애플리케이션을 만드는 훨씬 더 간단하고 건전한 모델을 제공하고 있습니다.

Solid

Solid는 Knockout에서 영감을 받은 간단하고 예측할 수 있는 반응형 모델을 제공하는데, React와 마찬가지로 기능의 합성이 용이하도록 템플릿화를 피했지만, React가 끊임없는 리렌더링이라는 접근 방식을 선택한 것에 비해 Solid는 한 번 렌더링한 후 다음에는 간소화된 반응형 시스템을 사용하여 가상 DOM의 오버헤드 없이 세밀한 업데이트를 수행하는 방식을 선택했습니다.

Solid는 많은 React 개발자들이 사용하는 hooks와 코드가 유사하지만, API는 더 효율적이고, 세밀한 반응성과 합성할 수 있는 기본 요소들에 초점을 맞추어 hooks 종속성 배열과 같은 것들을 더 매끄럽게 처리할 수 있습니다.

서로에게서 배우기

각 프레임워크는 기본적인 모델과 선호도에 따라 서로 다른 장단점을 가지고 있지만, 가장 크고 중요한 주제는 간소화와 단순화입니다. 즉 런타임에서 컴파일 시간을 줄이는 것이 이러한 가장 중요한 주제 중 하나인 만큼 메모이제이션에 대한 필요성을 잠재적으로 제거하는 기능인 “React forget”에도 영감을 주게 됐습니다.

모든 프레임워크의 공통점은 도큐먼트의 상호작용 부분을 해결하는 것이었는데, 앞에서 살펴본 것처럼, 이것은 쉽게 확장할 수 있는 방식으로 바로잡기에는 어려운 측면이었고, 페이지를 로딩할 때, 비어있는 흰 화면이 너무 오래 지속되는 것은, 특히 모바일 장치와 네트워크에서 이런 현상이 자주 발생한다면 재앙에 가까운 일이 됩니다.

많은 웹사이트의 경우에는 성능이 저하되지 않고, 화면이 빠르게 전환되는 것이 중요한 경쟁 우위가 될 수 있는 만큼, 서버에서 우선 콘텐츠를 렌더링함으로써 콘텐츠를 더 빨리 렌더링 하는 방법을 모색하게 되었는데, 이는 많은 “메타” 프레임워크와 같은 HTML 우선의 프론트엔드 프레임워크의 새로운 트렌드로 발전하게 됐습니다.

자바스크립트 웹 프레임워크의 새로운 트렌드

PHP에서 영감을 얻은 Next.js는 CDN으로 푸시 되는 정적 페이지를 생성하는 프로세스를 간소화하고, React 앱에서 SSR을 사용하는 번거로운 부분도 원활하게 처리했으며, 파일 기반의 라우팅을 사용하여 앱을 구성하는 간편한 방식을 제시했습니다.

Next.js 이후 “메타” 프레임워크의 사용자가 늘어나게 되었는데, Vue의 경우에는 Nuxt.js라는 유사한 프레임워크가 있고, Svelte에는 Sveltekit, Solid에는 SolidStart라는 유사 프레임워크가 있습니다.

이 프레임워크들은 모든 부분을 통합하고 효율적으로 설계된 서버 우선 프레임워크로, 이런 프레임워크들의 등장으로 인해 인터렉티브한 요소뿐만 아니라, 사용자 경험과 개발자 경험을 서로 손상하지 않고 개선하는 것에 대한 대화가 본격적으로 시작되었습니다.

MPA의 재등장

멀티 페이지 아키텍처에서는 서버에서 HTML을 제공하고, 내비게이션을 클릭했을 때 풀 페이지 새로고침이 일어나는데, 빠른 시작은 많은 사이트에서 중요한 요소이고, 검색 순위와 이탈률 등에 직접적인 영향을 미치는 만큼 MPA가 다시 부상하는 계기가 되었습니다.

React와 같은 클라이언트 렌더링 라이브러리는 낮은 상호작용성을 가진 많은 사이트와 앱에서는 굳이 사용할 필요가 없을 수도 있고, 생각보다 많은 사람에게는 자바스크립트보다 HTML이 더 우선적인 요소가 될 수도 있습니다. 또 SPA보다 MPA를 선호하거나, 브라우저의 기본 설정을 자바스크립트 사용하지 않음으로 해놓는 경우도 있을 수 있습니다.

그래서 Marko, Astro, Fresh, Rocket, Enhance와 같은 프레임워크들은 MPA의 접근 방식을 사용하는데, 일부 메타 프레임워크들과는 대조적으로, 라우터는 첫 페이지를 로드한 후 클라이언트로 이관되지 않고 서버에 남아있는 방식을 취하고 있습니다.

이런 현상은 자바스크립트 생태계의 서버 기반 템플릿으로의 회귀라고 볼 수도 있지만, 이전의 MPA와는 조금 다른데, 컴포넌트 기반 모델에 작성된 스프링클은 종종 아일랜드 아키텍처를 사용하고 있고, 프론트엔드와 백엔드 코드가 동일한 언어로 제공되며, 종종 같은 파일에 있기 때문에, 이를 통해 일부 상호작용을 추가할 때 프론트엔드와 백엔드에 걸쳐 다르게 구성된 중복된 템플릿 코드 문제가 제거될 수 있습니다.

점진적인 개선을 위한 Remix

Remix는 React 생태계의 점진적인 개선을 가져왔는데, 기술적인 관점에서 Remix는 곧 출시될 다른 메타 프레임워크와 마찬가지로 엣지 호환의 런타임 React Router 컴파일러라고 할 수 있습니다.

즉 Remix는 중첩 레이아웃과 데이터 가져오기 API를 페이스북이 Relay로 대규모로 해결한 것과 같이 동일한 방식으로 문제를 해결하고 있는데, 코드와 데이터를 병렬로 빠르게 가져오는 것은 Suspense와 함께 “렌더링 할 때 가져오기” 패턴의 좋은 전제 조건입니다.

점진적 향상에 중점을 둔다는 것은 그것의 API가 웹 표준을 기반으로 하고, 데이터 변형 스토리는 HTML 형식을 기반으로 한다는 것을 의미하는데, 이벤트 핸들러를 연결하여 필수적인 가져오기 요청을 수행하는 대신, 서버에서 데이터를 처리하는 수행 기능에 데이터를 제출하는 양식을 렌더링하는 방식이라고 할 수 있습니다. 이런 방식은 PHP에서 영감을 받았다고 합니다.

Next.js와 마찬가지로 Remix 애플리케이션은 전통적인 서버 렌더링 방식의 MPA처럼 자바스크립트 없이도 작동하도록 축소하거나 페이지 단위의 대화형 React 앱으로 확장할 수 있고, 낙관적인 UI 업데이트, 경합 상태 처리, 우아한 성능 저하 등 잘 갖춰진 프레임워크가 제공하기를 바라는 것들을 처리하기 위한 최종 사용자 경험에 초점을 맞춘 많은 API와 패턴을 제공합니다.

하이브리드의 미래, Qwik

Qwik 프레임워크는 불필요한 자바스크립트를 최소화하는 것이 전부이고, 그것의 API는 React처럼 보이지만, 하이드레이션 과정을 개선하는 접근 방식으로 다른 메타 프레임워크와는 다른 방식을 취하고 있습니다.

Qwik은 가상 머신을 일시 중지하고 다른 물리 머신으로 이동하는 방법과 같은 방식으로 동작하는데, Qwik은 이 아이디어를 서버와 브라우저 사이에서 발생하는 작업에 적용하고 있습니다. 이는 “재개 가능한 하이드레이션”이란 개념으로, 서버에서 무언가를 시작하고 클라이언트에서 재작업없이 다시 시작할 수 있음을 의미합니다.

이는 하이드레이션이 발생하면 따라오는 “부분 하이드레이션”과는 대조적으로 Qwik은 애초에 그것을 피하는 방식을 취하고 있는 것인데, 이것은 동적 번들링과 서비스를 가능하게 하는 서버와 클라이언트의 긴밀한 통합의 힘을 활용하기 때문에 흥미로운 아이디어라고 할 수 있습니다.

이런 개념은 애플리케이션이 MPA로 시작하여 동적으로 SPA로 전환이 가능한 만큼 MPA와 SPA 사이의 경계를 흐리게 되는데, 이런 방식으로 구현된 어플리케이션을 “전환 앱“이라고 부르기도 합니다.

정리

최고의 프레임워크, 아키텍처 또는 패턴이 무엇인지에 대한 보편적인 답은 없습니다. 이런 것들은 항상 특정 지표에 대한 교환으로 이루어지기 때문에 우리가 무엇을 얻고, 무엇을 포기해야 하고, 무엇을 만들고 있느냐에 따라 달라질 수 있는 것이죠.

또 사용자가 누구인지, 사용 패턴은 무엇인지와 같이 성능을 포함한 주요 사용자 경험과 관련된 다른 요구사항들도 중요한 요소인데, 프레임워크와 새로운 혁신적인 기술들의 가치를 결정하는 것은, 필요에 따라 기술을 확장하거나 축소할 수 있는 “레버”를 제공하느냐의 여부에 달려 있는 것이 아닐까요?

프레임워크의 진화는 네이티브 웹을 더 빠르게 실현하는 도구가 되어 주겠지만, 기술에 대한 투자를 해야 한다면 가장 좋은 베팅은 기본에 투자하는 겁니다. 현재까지 나온 모든 프레임워크와 혁신적인 기술들도 결국은 기본을 통해 완성되어 나온 것들이고, 더 많은 네이티브 웹의 기능을 구현하고, 적용해 가는 것 역시도 프레임워크가 아닌 우리의 상상력일 겁니다.