A Response To "Have Single-Page Apps Ruined the Web?"

Rich Harris는 새로운 싱글 페이지 애플리케이션(SPA) 프레임워크인 Svelte.js를 개발한 유명한 웹 개발자입니다.

2021년 10월, 그는 JamStack에서 “싱글 페이지 앱이 웹을 망쳤는가?“라는 주제로 강연을 했습니다.

우리는 이 강연에 대한 의견을 요청받았고, 이 에세이는 그에 대한 우리의 응답입니다.

강연에 대해 첫 번째로 언급할 것은, 이 강연이 매우 잘 만들어졌다는 점입니다. 잘 제작되었고, 사려 깊으며, 유머러스하고, 논쟁의 양측에 공정하며, 전반적으로 매우 합리적입니다. 우리는 아래에서 자세히 설명할 것처럼 Harris 씨의 많은 의견에 동의하지 않지만, 그의 의견과 그가 작업한 기술들을 존중하고 감사하게 생각합니다.

#SPA의 문제점

강연은 SPA의 몇 가지 타당한 비판으로 시작됩니다. 특히 Facebook의 대표적인 SPA 구현인 Instagram에서 발견되는 사용성 문제에 초점을 맞추고 있습니다. 그는 SPA의 다음과 같은 단점들을 공정하게 다루고 있습니다:

• 부피가 큰 JS 프레임워크가 필요하다.
• 성능이 저하될 것이다.
• 버그가 많을 것이다.
• 접근성 문제가 있을 것이다.
• 툴링이 복잡하다.
• 덜 견고할 것이다.

Instagram의 사용성 문제를 고려한 후, Harris 씨는 다음과 같이 말합니다:

여러분, 제발. 세계 최고의 프론트엔드 엔지니어들이 5MB의 자바스크립트 없이 텍스트와 이미지를 작동시킬 수 없다면, 우리는 아마도 웹 플랫폼을 포기해야 할 것입니다.

여기서 우리는 Harris 씨와 강력하게 동의합니다. 단, “웹 플랫폼” 대신 “자바스크립트 웹 플랫폼“을 사용해야 한다고 생각합니다. Instagram에서는 바로 그것이 문제가 되고 있기 때문입니다.

우리는 또한 SPA 애플리케이션과 프레임워크가 종종 원래의 REST-ful 모델을 단지 부트스트랩 메커니즘으로만 사용하면서 실제 웹 플랫폼을 단순히 무시한다는 점을 명확히 하고 싶습니다.

#MPA의 문제점

그런 다음 Harris 씨는 “전통적인”, 링크를 클릭하면 HTML 페이지가 로드되는 방식의 MPA(Multi-Page Applications)와 관련된 문제로 넘어갑니다. MPA는 우리가 모두 익숙한 방식이며, SPA에 의해 어느 정도 대체되고 있습니다.

아래에서 그는 “표준” MPA와 관련된 여러 문제를 설명합니다. 우리는 이들 문제를 검토하고, 하이퍼미디어 지향 기술인 htmx을 사용하여 각각의 문제를 어떻게 해결할 수 있는지 설명할 것입니다.

#“네비게이션 중에 비디오를 유지할 수 없다”

표준 MPA의 일반적인 문제는 모든 요청에서 전체 페이지 새로 고침이 발생한다는 것입니다. 이로 인해 비디오나 오디오 플레이어와 같은 콘텐츠가 요청 시 교체되어 중단될 수 있습니다.

이 문제는 htmx의 hx-preserve 속성을 사용하여 각 요청 간에 특정 콘텐츠를 유지하도록 함으로써 해결할 수 있습니다.

#“뒤로 가기 버튼 및 무한 스크롤이 작동하지 않는다”

무한 스크롤 동작이 있는 경우(아마도 자바스크립트로 구현됨) 뒤로 가기 버튼이 MPA에서 제대로 작동하지 않을 것입니다. 전통적인 MPA는 무한 스크롤 대신 페이징을 사용하므로, MPA라는 용어 자체가 의문시될 수 있습니다.

그렇긴 하지만, 무한 스크롤은 htmx를 사용하여 하이퍼미디어 지향적이고 명확한 방식으로 쉽게 구현할 수 있습니다. hx-push-url 속성과 결합하면, 히스토리와 뒤로 가기 버튼이 개발자가 거의 노력을 기울이지 않고도 올바르게 작동하며, 종종 SPA 커뮤니티에서 “딥 링크“라고 부르는 멋진 복사-붙여넣기 가능한 URL도 제공합니다.

#“멋진 내비게이션 전환은 어떻게 되는가?”

멋진 전환은 확실히 좋습니다. 그러나 우리는 디자이너들이 애플리케이션 사용성에 대한 기여를 과대평가하는 경향이 있다고 생각합니다. 데모에서는 멋질 수 있지만, 사용자가 여러 번 클릭할 때는 UI가 빠르게 응답하기를 원할 때가 많습니다.

그럼에도 불구하고, htmx는 표준 CSS 전환을 사용하여 애니메이션을 가능하게 합니다. 순수한 CSS 기술로 달성할 수 있는 것에는 한계가 있지만, 이 방법이 80/20 상황의 80%를 제공할 수 있다고 믿습니다. (어쩌면 95/5 상황의 95%일 수도 있습니다.)

#“MPA는 모든 요청에서 자바스크립트 라이브러리를 로드한다”

Harris 씨는 “엉망인 광고 기술“을 웹 사용성 문제의 주범으로 꼽으며, 오늘날 대부분의 웹사이트가 사용자에게 제공하는 2.5MB의 추적기, 스파이웨어, 애드웨어를 방어할 수 있는 사람은 없다고 지적합니다. 그는 SPA가 이 문제를 완화한다고 지적하며, SPA는 이 쓰레기 더미를 한 번만 로드하면 되므로 MPA처럼 매번 로드할 필요가 없다고 말합니다.

사실, 기본적인 MPA는 첫 번째 요청 후에 해당 쓰레기들을 캐싱하므로, 다운로드 비용은 SPA와 거의 동일합니다. 그러나 MPA는 각 페이지에서 이 쓰레기들을 다시 실행해야 하므로, CPU를 소모하고 사용자 경험을 악화시킬 수 있습니다.

그러나 htmx로 구동되는 MPA는 SPA와 정확히 동일한 특성을 가지고 있습니다. 광고 쓰레기는 첫 번째 요청에서 한 번만 다운로드되고 실행되며, 그 후 모든 요청은 상대적으로 가벼운 DOM 요소 교체로 이루어집니다.

#“MPA는 네트워크 지연 문제를 가지고 있다”

이것은 유효한 지적입니다. MPA 스타일 애플리케이션에서는 UI 상호 작용이 서버의 응답 속도, 즉 지연 시간에 의해 제한됩니다. 이 지연 시간의 일부는 네트워크 지연인데, 이는 중앙 집중식 데이터 저장소의 장점을 포기하지 않으면 극복하기 어려운 문제입니다. 그러나 네트워크는 빠르고 점점 더 빨라지고 있으며, 응답 시간을 모니터링하고 최적화하기 위한 수십 년 동안 개발된 잘 알려진 기법이 있습니다. SQL 튜닝, Redis 캐싱 등이 잘 확립되어 있으며 100ms 이하의 응답 시간을 목표로 할 수 있습니다. 많은 htmx 사용자는 htmx 기반 애플리케이션이 매우 빠르게 느껴진다고 말하지만, 우리는 지연이 고려해야 할 문제가 아니라고는 말하지 않겠습니다.

물론 지연 문제는 애플리케이션이 느리게 느껴질 수 있는 문제입니다. 그러나 여러분도 알다시피, 우리는 느린 SPA도 많이 작업해왔기 때문에 SPA 프레임워크를 채택한다고 해서 문제가 깔끔하게 해결되지는 않는다고 말할 수 있습니다. 게다가 서버와의 데이터를 낙관적으로 동기화하는 것은 매우 이해하기 어려운 데이터 일관성 문제를 초래할 수 있으며, 전반적인 애플리케이션 복잡성을 크게 증가시킬 수 있습니다. 이는 나중에 다시 다룰 주제입니다.

#“GitHub에는 UI 버그가 있다”

GitHub에는 실제로 UI 버그가 존재합니다. 그러나 이러한 버그 중 어느 것도 해결하기 어려운 것은 아닙니다.

htmx는 타겟 요소 이외의 콘텐츠를 업데이트하는 여러 가지 방법을 제공하며, 이 모든 방법은 매우 간단하고 Harris 씨가 지적한 UI 일관성 문제를 해결하는 데 효과적입니다.

Harris 씨가 언급한 Instagram의 UI 문제와 비교해보면, Instagram 문제는 훨씬 더 정교한 엔지니어링 작업이 필요합니다.

#전환 애플리케이션

Harris 씨는 SPA와 MPA 기술이 혼합된 “전환 애플리케이션” 개념에 대해 논의합니다. 이 용어는 합리적이며, 이 용어가 업계에 정착될지 지켜보겠습니다.

우리는 종종 htmx를 애플리케이션에서 단순함을 유지하는 것이 의미 있는 부분에 사용하고, 다른 기술을 필요에 따라 사용하는 것을 권장합니다: alpine.js, hyperscript, 소규모 반응형 프레임워크 등.

그래서 우리는 여기에서 Harris 씨와 어느 정도 동의하며, 웹 개발에 “전환” 접근 방식을 권장합니다. 그러나 우리는 가능한 경우 MPA/하이퍼미디어 쪽으로 기울일 것을 권장하며, Harris 씨는 SPA/자바스크립트 쪽으로 기울일 가능성이 높아 보입니다.

#방 안의 코끼리: 복잡성

불행하게도, Harris 씨가 논의하지 않은 주제가 하나 있습니다. 그리고 아마도 그가 이 주제를 보지 못한 이유는 그가 자바스크립트 개발자이며, 프론트엔드 프레임워크의 엔지니어링 문화 속에서 생활하기 때문일 것입니다. 현재 자바스크립트 프론트엔드 개발의 복잡성이 그에게는 자연스러워 보일지 모르지만, 우리 중 많은 사람들에게 자바스크립트 생태계는 단순히 미친듯이 지나치게 복잡하게 느껴집니다. 사실, 대부분의 웹 애플리케이션 요구 사항을 고려할 때 그 복잡성은 우스꽝스러울 정도입니다.

Harris 씨가 언급한 여러 “전환” 기술들, 예를 들어 React Server Components (그가 “HTML over the wire와 비슷하지만 훨씬 더 정교한 것“이라고 부르는 기술), Marko (부분적 하이드레이션을 수행하는 기술), Quik (아주 적극적으로 게으르게 로드하는 기술로 보임) 등은 모두 놀라운 엔지니어링 성과이지만, 동시에 매우 복잡한 기술들이기도 합니다.

안타깝게도, 이는 현재 프론트엔드 개발 문화의 일부입니다. 애플리케이션 프레임워크, 빌드 도구 체인, 배포 모델 등에서 하늘 높이 치솟은 복잡성을 용인하고, 이러한 복잡성으로 인해 문제가 발생할 때, 더 많은 복잡성이 종종 해결책으로 제시됩니다.

“단순함“은 경시되고 “정교함“은 높은 평가를 받습니다.

이 복잡성은 오늘날 많은 개발자와 개발 팀에게 압도적입니다. Harris 씨 자신이 Instagram을 논의할 때 지적한 것처럼, 세계 최고의 프론트엔드 엔지니어들조차 모든 것을 통제할 수 없게 된 것처럼 보입니다.

여기에는 문화적인 문제가 있습니다.

또한 기술적인 문제도 존재합니다.

이 기술적인 문제는 “하이퍼미디어 접근법” 대 “원격 프로시저 호출 (RPC) 접근법“으로 요약할 수 있습니다.

웹 애플리케이션이 MPA에서 SPA로 전환되면서, 개발자들은 종종 무의식적으로 애플리케이션 개발에 RPC 접근 방식을 채택했습니다. AJAX는 데이터 직렬화 형식으로 JSON으로 이동했고, 대체로 (정당하게) 하이퍼미디어 개념을 버렸습니다. 이 하이퍼미디어 접근법의 포기는 바닐라 MPA의 사용성 문제로 인해 발생했습니다.

그러나 이러한 사용성 문제는 종종 하이퍼미디어 접근법을 사용하여 해결할 수 있음이 밝혀졌습니다: RPC로 하이퍼미디어를 포기하는 대신, 당시와 오늘날 우리가 필요로 하는 것은 더 강력한 하이퍼미디어입니다.

이것이 바로 htmx가 제공하는 것입니다.

하이퍼미디어 접근법으로 돌아가면, 대부분의 인기 있는 SPA 프레임워크에서 요구하는 복잡성의 일부로 Harris 씨의 MPA에 대한 많은 우려를 해결할 수 있는 적당히 정교한 웹 애플리케이션을 구축할 수 있습니다. 게다가 많은 생각을 하지 않아도, 진정한 REST-ful 아키텍처에 대해 Roy Fielding이 설명한 모든 이점을 얻을 수 있습니다.

하이퍼미디어 아키텍처가 모든 웹 애플리케이션에 적합합니까? 분명히 그렇지 않습니다.

그러나 많은, 아마도 대부분의 웹 애플리케이션에 적합합니까? 우리는 적어도 일부에서 그렇게 생각합니다.

#자바스크립트: 저항

이제 강연에서 제기된 가장 감정적으로 충전된 주장에 도달했습니다. 바로 “자바스크립트의 시대는 이미 지나갔다“는 주장입니다. Harris 씨는 자바스크립트가 앞으로 웹 개발에서 지배적인 프로그래밍 언어가 될 것이라는 사실을 받아들여야 한다고 주장합니다.

Harris 씨는 최종적으로 남은 자바스크립트에 대한 저항을 없앨 주된 동력이 엣지 컴퓨팅일 것이라고 믿고 있습니다.

우리는 그렇게 확신하지 않습니다.

반대로, 우리는 가까운 미래에 엣지 컴퓨팅이 대부분의 웹 애플리케이션에 중요한 역할을 할 것이라고 기대하지 않습니다. 솔직히 말해, 절대 그렇게 될 것이라고 생각하지 않습니다. CPU는 저렴하고 네트워크 속도는 빠르고 계속 빨라지고 있으며 마이크로서비스는 복잡한 문제를 야기합니다.

Harris 씨의 말과는 달리, 오늘날 자바스크립트가 분명히 우세한 추세가 아니라는 사실을 볼 수 있습니다. 5년 전, 우리는 자바스크립트 저항의 창립 멤버로서 자바스크립트의 거대한 물결을 막을 희망이 없다고 절망하고 있었습니다. 그러나 그때 예상치 못한 일이 발생했습니다. 파이썬이 급성장했고, 동시에 자바스크립트의 성장세가 정체되었습니다:

이 자바스크립트가 2010년대 중반에 정점에 도달한 트렌드는 GitHub에서도 관찰할 수 있습니다:

물론, 이것이 자바스크립트가 결국 파이썬에게 “패배“하고 사라질 것이라는 것을 의미하지는 않습니다.

자바스크립트는 웹의 핵심 기술이며 영원히 우리와 함께할 것입니다. 자바스크립트 없이는 htmx (또는 hyperscript)를 구축할 수 없었을 것이며, 자바스크립트에 대해 매우 감사하게 생각합니다.

하지만 이는 자바스크립트가 미래의 웹에서 반드시 완전히 지배적이지 않을 수도 있음을 시사합니다. 이는 5년 전만 해도 그렇게 보였던 상황과는 다릅니다.

우리는 HOWL 스택, 즉 “Hypermedia On Whatever you’d Like“에 대해 자주 이야기합니다. 이는 더 강력한 하이퍼미디어 아키텍처로 돌아가면 원하는 백엔드 언어를 사용할 수 있다는 아이디어입니다: Python, LISP, Haskell, GO, JAVA, C#, 무엇이든 가능합니다. 자바스크립트도 사용하고 싶다면 말이죠.

서버 상호작용을 위해 하이퍼미디어와 HTML을 사용하고 있기 때문에, 거대한 자바스크립트 프론트엔드가 백엔드에서 자바스크립트를 채택하도록 하는 압력을 느끼지 않습니다. 물론 자바스크립트를 여전히 사용할 수 있습니다 (예를 들어 alpine.js 형태로). 그러나 이를 원래 의도된 방식으로, 즉 애플리케이션을 향상시키기 위한 가벼운 프론트엔드 스크립팅 언어로 사용합니다. 또는 용감하다면, 이러한 필요를 위해 hyperscript를 시도해 볼 수도 있습니다.

이것이 우리가 살고 싶은 세계입니다: 여러 프로그래밍 언어 옵션이 존재하고, 각 언어가 고유한 강점, 기술적 문화 및 활발한 커뮤니티를 가지고 있으며, 모두가 더 강력한 하이퍼미디어의 마법을 통해 웹 개발 세계에 참여할 수 있는 세상입니다. SPA가 JSON으로 Node와 통신하는 독점적인 구조 대신 말이죠. 다양성이야말로 우리의 강점입니다.

결론적으로,