▲

GN⁺: 싱글 페이지 앱 외에는 인터랙티브 웹 앱을 구축할 수 없다는 오해

 (htmx.org)
15P by neo 9일전 | favorite | 댓글 8개
  • 어떤 개발자들은 SPA 프레임워크(React, AngularJS 등)가 고품질 애플리케이션 개발에 필수적이라고 생각함
  • 그러나 SPA 이전에도 MPA 기반의 애플리케이션이 훌륭한 사용자 경험을 제공해 왔음
  • 나는 HTMX를 활용하여 데이터 중심의 MPA 기반 관찰 플랫폼 개발을 시도해봤고, 적절한 최적화를 통해 서버 렌더링 MPA에서도 뛰어난 성능과 사용자 경험을 제공 가능

MPA와 관련된 오해와 진실

오해 1: MPA는 페이지 전환 시 느림
  • 문제: 브라우저가 기본적으로 페이지 전환마다 JavaScript와 CSS를 다시 다운로드하기 때문
  • 해결책:
    • PJAX, Turbolinks, HTMX Boost 같은 라이브러리를 사용해 HTML body만 교체
    • 서비스 워커를 활용해 페이지 캐싱 및 요청 처리 개선 가능
    • 예시: 서비스 워커 적용 시 DOMContentLoaded 시간이 2.9초에서 500ms로 단축됨
서비스 워커 구현 방법
  1. sw.js 파일 생성: 캐싱 및 네트워크 요청 관리 스크립트 작성
  2. 캐싱 파일 목록 정의: HTML, CSS, JS 등 주요 자산을 지정
  3. 캐싱 전략 설정: 정적 자산을 영구 캐싱하거나 주기적으로 갱신
오해 2: MPA는 오프라인 작동 및 네트워크 복구 요청 저장 불가
  • 서비스 워커를 사용해 오프라인 상태에서도 앱 작동 가능
  • Workbox 활용:
    • 네트워크 실패 시 요청을 캐싱하고 최대 24시간 내에 재시도
    • 오프라인 핸들러를 설정해 요청 시 대체 콘텐츠 제공
오해 3: MPA는 페이지 전환 시 화면 깜박임이 발생
  • 해결책:
    • 서비스 워커와 사전 로드 API로 자산이 준비될 때까지 화면 페인팅 지연
    • 2019년 이후 브라우저는 동일한 도메인 내 전환 시 깜박임 없이 처리
오해 4: MPA는 화려한 페이지 전환 효과 구현 불가
  • SPA가 페이지 전환 애니메이션으로 유명하지만, 브라우저도 이를 지원하기 시작
  • Chrome 126에서 CSS만으로 크로스 문서 전환 애니메이션 구현 가능
  • 데모 링크
오해 5: HTMX나 MPA에서는 모든 사용자 작업이 서버에서 처리됨
  • HTMX는 일부 작업만 서버에서 처리하도록 설계됨
  • 필요한 경우 WebComponents나 JavaScript 프레임워크로 클라이언트 측 인터랙티브 기능 추가 가능
  • 특정 컴포넌트에만 SPA 방식 적용 가능
오해 6: DOM 조작은 느림. 따라서 React/Virtual DOM 사용이 필요
  • Virtual DOM은 극도로 복잡한 애플리케이션에서만 성능 차이를 보임
  • 대부분의 일반 애플리케이션에서는 DOM 직접 조작이 충분히 빠름
  • 참고 자료: "Virtual DOM is pure Overhead"
오해 7: 작은 인터랙티브 기능에도 JavaScript가 필요
  • 최신 브라우저 기술로 JavaScript 없이도 다양한 기능 구현 가능
    • HTML 체크박스와 CSS로 토글 기능 구현 가능
    • HTMX를 결합해 클릭 시 데이터 비동기 로드 가능
최종 오해: SPA 없이 클라이언트 측 코드는 스파게티 코드로 변질됨
  • 스파게티 코드 시절에도 많은 생산적인 소프트웨어가 개발되었음
  • 초기 MVP 단계에서는 간단한 구조가 더 유리할 수 있음

결론

  • 2024년 현재, 브라우저는 SPA 혁명에서 배운 점들을 통합해 많은 발전을 이룸
  • 기본 브라우저 도구(HTML, CSS, JavaScript)만으로도 인터랙티브하고 오프라인에서 작동 가능한 애플리케이션 구현 가능
  • 브라우저의 잠재력을 믿고 다시 한 번 활용해 보기를 권장함
▲
kwj9211 9일전  [-]

자네는 아직도 브라우저 스펙을 믿나...?

구지 말하면, SPA는 브라우저 동작에 그나마 덜 의존성을 갖는 앱 개발 방법이라 생각합니다.

SPA의 멋진 가능성들을 브라우저가 꽤 따라왔고 그게 http의 원래 설계된 통신 방식에 더 어울려 보이는것은 맞지만, 그건 크롬이 브라우저 세계에서 사실상 독점적인 지위를 가지면서 여유가 생겨서 그런게 아닐까 합니다... 이런게 과연 오래 갈진 모르겠네요. 여유든, 점유율이든...

답변달기
▲
clickin 9일전  [-]

phoenix liveview 같은 방식의 websocket 기반으로 서버에서 dom 조작하는거면 패러다임이 다른데
htmx 써봤을 때는 서버에서 조각난 html을 내려줘야한다는 게 그닥 유쾌하진 않더라고요
특히 css 부분에서 class를 지정해서 내려주면 서버 입장에서는 화면에서 사용중인 css를 알 수가 없으니 사실상 공통 css를 강제하는 느낌입니다.

답변달기
▲
colus001 8일전  [-]

몇년전에 Phoenix liveview 로 다소 복잡한 UI 를 만들어본 적 있는데, 간단한 인터렉션을 구현하는게 너무 까다롭고, 하나의 liveview 가 하나의 elixir process 로 처리되기 때문에, 옆 컴포넌트와 인터렉션이 매우 어렵습니다. 결국 포기하고 react 로 돌아간 기억이 있네요.

답변달기
▲
silveris23 9일전  [-]

liveview가 미래같아요 저는…

답변달기
▲
clickin 8일전  [-]

liveview는 또 네트워크에 크게 의존하다보니까 서버가 원격지라서 핑이 높거나 제3세계 등 인터넷 인프라가 좋지 않은 경우에서는 약점이 크더라고요.

답변달기
▲
pcj9024 8일전  [-]

고만고만한 개발자들 데리고 개발해보면 이게 얼마나 환상에 찬 얘긴지 바로 알겁니다. 이거 쓴 분은 천재들에 둘러싸여있거나 혼자 일하거나 그러고있는듯... (철지난 angularjs를 지금 언급하는걸 봐도 그렇고) 그리고 개발은 천재들로만 하는게 아니죠
누군가는 '끼리끼리 모여있다'라고 폄하하겠지만 언제나 변화는 평범한사람들에 의해 이뤄졌습니다
이런거 보면 htmx는 절대로 수용되어서는 안되겠다는 생각이 먼저 드네요

답변달기
▲
konh2e 8일전  [-]

최근 들어서 계속 계속 나오는 주제이긴 한데,
리치 해리스가 몇 년전에 해당 주제에 대한 자신의 의견을 말한 영상이 있습니다.
https://www.youtube.com/watch?v=860d8usGC0o&t=635s

기억하기로는 파셜 HTML 을 기반으로 업데이트 하는 방식들은 화면과 데이터의 비 일관성이 생길 가능성이 있다. 라고 요약할 수 있겠네요.

답변달기
▲
neo 9일전  [-]
Hacker News 의견

  • 브라우저 캐시를 활용하여 정적 CSS와 JS 자산을 관리하는 방법이 기사에 언급되지 않은 이유에 대한 궁금증이 있음. 과거에 쇼핑 사이트를 MPA 방식으로 구축했을 때 페이지 전환이 거의 눈에 띄지 않았음

  • PHP와 jQuery 시절의 웹 개발이 가장 생산적이었다고 주장하는 사람도 있음. React 등 최신 기술보다 과거의 패러다임이 더 생산적일지 궁금해하는 의견이 있음. Amazon이나 Steam 같은 대형 사이트도 여전히 서버에서 HTML을 렌더링하고 JS를 추가하는 방식으로 만들어짐

  • 서비스 워커 전략이 기존의 HTTP 캐시 헤더와 비교해 어떤 점에서 더 나은지 설명을 요청하는 의견이 있음. 네트워크 왕복을 줄일 수 있지만, 작은 최적화를 위해 전체를 재발명하는 것처럼 느껴짐

  • "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths"라는 제목의 의미가 생략된 부분 때문에 클릭을 유도하는 느낌이 듦

  • 프로그래밍에서 가장 위험한 것은 개발자의 지루함과 과거에 대한 무지임

  • Node.js 웹 서버 시대에 서버 측과 클라이언트 측(SPA) 사이의 이분법이 왜 존재하는지 이해하지 못하는 의견이 있음. 서버에서 대부분의 작업을 초기화하고 클라이언트로 직렬화하여 SPA로 작동하게 할 수 있지 않을까 하는 질문이 있음

  • SPA와 MPA를 서로 반대되는 팀으로 보는 경향이 있지만, 웹 스택을 자연스럽게 사용하는 방법과 "해킹" 방식으로 구분할 수 있음. SPA는 현재 해킹 방식이지만, 과거에는 CGI, Java 애플릿, Flash 등이 있었음. 해킹 방식이 자연스러운 방법의 한계를 확장하는 역할을 함

  • 기술 스택 결정보다 먼저, 개발자들이 자신이 무엇을 작성하고 있는지 잘못 이해하는 경우가 많음. 높은 수준의 상호작용이 필요하지 않다면, 대부분 서버 측 프레임워크로 충분할 수 있음

  • "단일 페이지 앱이 아니면 상호작용 웹 앱을 만들 수 없다"는 신화에 대한 반박이 있음. SPA는 더 많은 제어를 제공하고 코드의 일부를 재작업할 가능성을 줄여줌

  • HN 헤드라인이 실제 헤드라인보다 더 공격적임. Tony Alaribe가 BigSkyDevCon에서 발표한 에세이로, 비-SPA 기반 웹 애플리케이션을 빠르고 매끄럽게 만드는 기술을 논의함. 새로운 기술을 소개하며, 컨퍼런스에서 최고의 발표였다고 생각함

답변달기