자바스크립트가 0kb가 되는 날이 올까?

---

원문: Ryan Carniato, https://dev.to/this-is-learning/is-0kb-of-javascript-in-your-future-48og

제로 자바스크립트는 최근 자바스크립트 라이브러리에서 생긴 새로운 유행어이다. 필자는 지금이 누구나 알고 있지만 말하지 않는 문제를 해결할 때라고 생각한다. 각각의 라이브러리가 조금씩 다른 것을 이야기하고 있어서 무슨 일이 일어나고 있는지 알기 어렵다. 한번 이를 명확하게 할 수 있을지 확인해보자.

먼저 '자바스크립트가 0kb가 되는 날이 올까?'라는 질문에 답하자면, 아마 아닐 것이다. 그럴리가 없다. 우리는 근본적인 작동 방식을 바꾸지 않았다. 일부 비평가가 이야기했던대로 자바스크립트가 완전 엉망이었다면 지금의 위치에 도달하지 못했을 것이다.

웹 페이지에 자바스크립트를 사용하는 이유는 자바스크립트가 좋기 때문이다. 자바스크립트는 사용자 경험에 매우 긍정적인 영향을 줄 수 있다. 더 부드럽게 전환되고, 동적 콘텐츠를 더 빠르게 로드하고, 더 나은 상호작용을 제공하고, 접근성을 향상시킨다.

그렇다면 사람들이 0kb 자바스크립트에 대해 이야기할 때, 무엇을 이야기하고 있을까?

점진적 향상

지난 주에 HTML 폼으로 자바스크립트 없이 POST 요청을 하는 데모를 하나도 아니고 두 개나 보았다. Remix Run과 SvelteKit은 모두 서버에서 페이지를 렌더링한 다음 자바스크립트 번들을 로드하지 않고도 폼이 완벽하게 동작하도록 하는 기능을 갖추고 있다.

당연히 링크(<a> 앵커 태그)도 이 조건에서 잘 작동한다. 이는 획기적인 것이 아니며, 모든 서버 렌더링 라이브러리가 폼을 처리하도록 API를 설계하는 경우 이점을 누릴 수 있다. 하지만 확실히 입이 떡 벌어지게 만든다.

스포일러 경고 - 필자는 특히 처음 30분 동안 브라우저에 자바스크립트를 보내지 않는다고 청중에게 말하지 않은 Remix Run 데모를 즐겼다. 그래서 그들이 클라이언트 앱을 구축하고 있다고 생각했다.

Svelte를 만든 Rich Harris는 4일 전에 매우 유사한 데모를 공개했다. 필자는 그다지 놀랍지 않았는데, 이는 웹의 핵심적이고 기본적인 사항이고 인기가 덜한 프레임워크마저도 똑같은 일을 몇 년 정도 하고 있고, React도 마찬가지다.

우리 대부분은 자바스크립트를 없애기 위해 노력할 필요가 없을 수도 있다. Ryan과 Michael은 위 영상에서 "이것은 정말 멋지지만, 해당 장점은 플랫폼에 내장된 메커니즘을 사용해서 개발자가 작성해야 하는 로직을 단순화할 수 있다"는 것을 반복적으로 강조하고 있다.

점진적 향상의 가장 좋은 점은 모든 프레임워크에서 사용할 수 있다는 것이다. 이는 브라우저에 내장되어 있다. 더 많은 메타 프레임워크가 이를 지원해야 한다. 결국, 아마도 개발자들은 여전히 자바스크립트를 보내고 있을 것이다. 그러지 않더라도 괜찮다. 하지만 그것은 페이지 단위에서 보면 자바스크립트를 다 전송하거나 전송하지 않는 문제이다.

React 서버 컴포넌트

이 발표는 확실히 획기적이었다. React에서 소개한 서버에서만 렌더링되는 컴포넌트이다. 이들은 번들 크기가 0인 컴포넌트로 광고되고 있다.

번들 크기가 없다는 것은 실제로 어떤 의미일까? 이는 이러한 컴포넌트를 번들과 함께 전송하지 않는다는 것을 의미한다. 렌더링된 템플릿은 결국 직렬화된 형식을 통해 브라우저에 전달된다. 그래도 그것을 렌더링하기 위해 React 코드 전송을 저장한다.

서버 컴포넌트는 상태가 없다. 그럼에도 불구하고 각 VDOM 노드를 하나씩 생성하기 때문에 템플릿 크기에 따라 코드가 확장되는 React 같은 라이브러리를 번들하지 않아 많이 절약할 수 있다. Lit 또는 Solid처럼 프레임워크의 상태가 없는 템플릿은 어쨌든 보내야 하는 템플릿 자체 외에 한 줄짜리 DOM 템플릿의 복제본일 뿐이다.

더 나은 관점은 이것을 새로운 유형의 통합 API로 보는 것이다. 최소한 여러분이 저장하는 것은 일부 데이터를 로드한 뒤 컴포넌트에만 사용되는 데이터 처리 코드이다. React 서버 컴포넌트를 사용하면 해당 컴포넌트의 요구 사항에 완벽하게 맞춰진 컴포넌트별 API를 자연스럽게 만들게 된다. 해당 API는 일부 마크업을 포함할 수 있다.

이는 브라우저에서 더 이상 Lodash 또는 Moment가 필요 없다는 것을 의미한다. 이것만 해도 큰 승리이다. 그러나 진정한 이득은 성능 절벽을 피하는 것이 쉬워졌다는 것이다. 우리는 이미 API를 사용하여 전송을 피할 수 있었지만 이러한 API를 작성해야 했다.

우리가 얻은 것은 코드 분할을 수행하고 API를 작성하는 다른 방법이다. 우리가 크기를 줄이고 있는 건 확실하지만 번들 크기가 0인 것은 아니다.

섬(Islands)

1년 전 쯤, Preact를 만든 Jason Miller는 수년간 존재했지만 아무도 이야기하지 않는 서버 렌더링 접근 방식에 이름을 붙이려고 애썼다. 그는 섬 아키텍쳐로 결론내렸다.

아이디어는 비교적 간단하다. 자바스크립트 프레임워크에서 일반적으로 볼 수 있는 것처럼 전체 페이지의 렌더링을 제어하는 ​​단일 앱 대신 여러 진입점을 둔다. 이러한 상호작용 섬을 위한 자바스크립트는 브라우저로 전송되고 독립적으로 하이드레이션(hydrate)되어 나머지 대부분 정적 페이지의 나머지는 순수 HTML로 전송된다.

엄밀히 말하자면 새로운 아이디어가 아니었지만 마침내 이름이 붙여졌다. 이것은 상상할 수 있듯이 페이지에 있는 자바스크립트의 양을 크게 줄인다.

Astro는 이 아이디어 위에 구축된 다중 프레임워크 메타 프레임워크이다.

정말 멋진 점은 원하는 경우 상호 작용을 유지하면서 페이지에서 전송되는 자바스크립트를 적극적으로 줄일 수 있다는 것이다. 단점은 다중 페이지(서버 라우팅) 앱이라는 것이다. 물론 단일 페이지 앱을 만들 수 있지만 이는 이점을 무효화한다.

정확하게 말하자면, 0kb 자바스크립트 앱은 별도의 페이지로 작동해야 한다. 그리고 Astro를 이용한 0kb의 경우, 클라이언트 컴포넌트를 전송하지 않는 문제일 뿐이다. 위에서 설명한 점진적인 향상을 덧붙이는 건 자연스러운 것이다.

따라서 섬은 자바스크립트를 줄이는 확실한 방법이며 실제로 원하는 위치에서 결국 0kb의 자바스크립트가 될 수도 있다. 그렇게 되지 않더라도, 불필요한 자바스크립트를 로드할 필요가 없다. 그리고 Astro와 같은 라이브러리를 사용하면 익숙한 도구를 사용할 수 있다.

부분적 하이드레이션(Partial Hydration)

부분적 하이드레이션은 섬 아키텍쳐와 매우 비슷하다. 최종 결과는 상호작용 섬이다.

차이는 작성 경험이다. 정적 레이어와 섬 레이어를 작성하는 대신 일반적인 프론트엔드 프레임워크와 같은 단일 앱처럼 코드를 작성한다. 부분적 하이드레이션은 자동으로 섬을 생성하여 브라우저에 최소한의 코드를 전달할 수 있다.

Marko는 브라우저 번들에서 서버에서만 렌더링되는 컴포넌트를 제거하기 위해 컴파일러를 사용하여 이 부분적 하이드레이션 과정을 자동화하는 자바스크립트 라이브러리이다.

단일 앱을 유지보수할 때 개발자 경험 측면에서 얻는 이점 외에도 컴포넌트를 조정할 수 있는 가능성을 제공한다. 그러한 앱 중 하나는 점진적인(스트리밍) 렌더링이다.

이와 같은 로딩 경험은 자바스크립트 번들을 브라우저에 보내지 않고도 클라이언트와 서버 사이에서 조정할 수 있다. 페이지에 점진적으로 로드되는 데이터가 있다고 해서 자바스크립트 라이브러리가 필요하다는 의미는 아니기 때문이다. Marko의 폴백 플레이스 홀더가 있는 비순차적 스트리밍에는 렌더링될 때 인라인되는 페이지에 자바스크립트가 필요하다. 그러나 순차적으로 일어나는 점진적 렌더링에서는 자바스크립트가 여전히 작동하지 않는다.

Hacker News 데모의 클라이언트 로딩 상태를 확인한 다음 네트워크 탭을 열어보면 자바스크립트가 전송되지 않은 걸 확인할 수 있다.

특히 멋진 점은 페이지 로드가 시작될 때까지 브라우저의 내비게이션을 기다리는 방식이다. 페이지는 정적 콘텐츠를 빠르게 로드할 수 있고 자바스크립트 번들이 없이 클라이언트 사이드와 비슷한 스타일의 로딩바를 보여줄 수 있다.

일반적으로 부분적 하이드레이션은 섬의 이점을 확장하여 페이지를 통합된 단일 앱으로 취급할 수 있는 가능성을 제공한다.

그래서 0kb?

아닐 수도 있지만 이러한 접근 방식과 라이브러리는 몇 가지 좋은 이점을 제공한다. 자바스크립트는 많은 가치가 있지만, 모든 곳에서 그렇게 많이 필요하지는 않다. React 또는 Svelte 위에 서버를 활용하는 새로운 방법을 추가하면 개발자 경험을 근본적으로 변경하지 않고도 불필요한 확장을 줄이는 데 도움이 될 수 있다.

섬 접근 방식을 사용하면 자바스크립트 없이 또는 매우 적게 사용하여 작동하려는 애플리케이션을 각 페이지에 대해 모든 걸 취하거나 취하지 않고 증가되는 방식으로 구현할 수 있다. 심지어 자바스크립트 번들을 제공하지 않고도 동적 로드를 수행할 수도 있다.

진정한 승자는 개발자이다. 이러한 모든 접근 방식은 클라이언트-서버 상호 작용을 단순화하는 도구를 제공한다. 더 많은 것을 서버로 옮기려 하는 것이 무척 어려웠지만, 이런 기술 발전 덕분에 많이 쉬워졌다.