Hotwire: HTML 오버 더 와이어 기술

 (hotwired.dev)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Hotwire는 JSON 대신 HTML을 전송해 최신 웹 앱을 만드는 접근으로, 많은 JavaScript 없이도 빠른 첫 로드와 반응성을 노림
  • 렌더링을 서버 템플릿에 남겨 두기 때문에, 사용하는 언어와 무관하게 개발 흐름을 단순하게 유지할 수 있음
  • 37signals가 HEY를 위해 만든 프레임워크들은 함께 조합되어, 웹부터 여러 플랫폼까지 이어지는 Hotwire 생태계를 구성함
  • 중심 구성요소인 Turbo는 페이지 전환, 폼 제출, 컴포넌트 분할, WebSocket 기반 부분 업데이트를 JavaScript 작성 없이 처리함
  • Turbo로 부족한 맞춤형 상호작용은 Stimulus가 보완하고, Hotwire Native는 기존 웹 앱을 바탕으로 네이티브 모바일 앱을 만들 수 있게 함

HTML을 서버에서 렌더링해 보내는 접근

  • Hotwire는 HTML-over-the-wire 방식으로 최신 웹 애플리케이션을 구축하는 대안적 접근임
  • JSON 대신 HTML을 네트워크로 전송해 많은 JavaScript 없이 애플리케이션을 만들 수 있게 함
  • 빠른 첫 페이지 로드, 서버 측 템플릿 렌더링 유지, 더 단순하고 생산적인 개발 경험을 목표로 함
  • 전통적인 단일 페이지 애플리케이션에서 기대하는 속도와 반응성을 포기하지 않는 방향임
  • HTML-over-the-wire는 자체 도구를 만들기 위한 참고 방식으로 쓸 수도 있고, 37signals가 HEY를 위해 만든 Hotwire 프레임워크들을 그대로 사용할 수도 있음

Turbo, Stimulus, Hotwire Native의 역할

  • Turbo는 Hotwire의 중심 구성요소임
    • 페이지 전환과 폼 제출을 빠르게 처리하는 보완적 기법을 제공함
    • 복잡한 페이지를 컴포넌트로 나누고, WebSocket으로 부분 페이지 업데이트를 스트리밍함
    • 이 기능들을 JavaScript 작성 없이 제공함
  • Stimulus는 Turbo만으로 충분하지 않은 맞춤형 코드가 필요할 때 쓰임
    • Turbo는 전통적으로 JavaScript가 필요했던 상호작용의 최소 80%를 보통 처리함
    • Stimulus는 상태와 연결을 HTML 중심 방식으로 다룰 수 있게 함
  • Hotwire Native는 네이티브 모바일 앱을 만들기 위한 웹 우선 프레임워크임
    • 기존 웹 앱을 활용해 모바일 앱을 구축하는 데 필요한 도구를 제공함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 기능의 덜 마케팅된 버전으로 htmx가 있음: https://htmx.org/
    자바스크립트 파일 하나로 이런 기능을 가능하게 해주고, 주로 Go 백엔드와 함께 쓰는 걸 많이 봤지만 꽤 유연해 보임. 1년쯤 전부터 한번 써보려고 생각 중이었음

    • 적어도 Hacker News 기준으로는 htmx가 훨씬 더 많이 노출됐다고 봄
      지난 1년만 해도 HN 제출이 수백 건이고 0, 1000점을 넘긴 글도 있었음. 반면 Hotwire는 지난 1년 제출이 30건도 안 되고 1, 그중 가장 인기 있는 게 이 글임
    • htmx가 덜 마케팅됐다는 건 이해가 안 감. Hotwire는 처음 듣지만, htmx는 여기저기서 너무 많이 보임
      YouTube만 잠깐 봐도 프로그래머 인플루언서들이 htmx를 얼굴 썸네일과 함께 계속 띄우는 수준임
    • 다른 기능도 포함한 https://unpoly.com도 언급할 만함
    • HTMX는 어떤 프레임워크보다 마케팅이 잘된 편일 가능성이 큼
      Twitter도 매우 활발하고 The Primeagen의 YouTube 채널에도 자주 나오며 꽤 인기 있음
    • 덜 마케팅됐다고? 모든 소셜 플랫폼에서 htmx가 쏟아져 나오는 느낌임

  • PHP/Laravel에서 비슷한 걸 찾는다면 Livewire를 강력히 추천함: https://laravel-livewire.com/
    더 복잡한 프로젝트에는 여전히 React를 쓰지만, 반응형 UI 요소를 유지하면서 Blade/PHP로 전부 작성할 수 있는 건 늘 신선함. 필요할 때 Livewire 안에서 React/Vue 컴포넌트를 렌더링하게 해주는 패키지도 본 기억이 있음: https://minglejs.unitedbycode.com/. 기존 패키지를 끌어와야 할 때 흥미로운 탈출구처럼 보임

  • 예전에는 Hotwire/Livewire에 꽤 부정적이었지만, 지금은 상황에 맞는 도구라고 봄
    와이어로 부분 템플릿을 보내는 건 하이퍼미디어 방식이고, 요즘은 하이퍼미디어 앱을 잘 만들지 않을 뿐임. htmx와 RTF의 REST 논문을 다시 읽으면서 여기까지 왔고, 하이퍼미디어가 본질적으로 더 우월한 아키텍처라고 보진 않지만 여러 선택지 중 정당한 동료이며 느리게라도 계속 진화하는 건 좋음

  • React/Vue/Svelte의 토끼굴로 빠지지 않고 PWA를 만드는 가장 쉬운 방법에 가까움
    그것들도 써봤고 훌륭하다고 생각하지만, htmx와 비교하면 기술 중심보다 개발자 경험 중심처럼 느껴짐. 둘 사이의 경쟁은 결국 어떤 백엔드 프레임워크와 더 잘 통합되느냐에 달릴 듯함

    • 모바일 앱이 단순히 WebView라면 그럴 수 있음. 그렇지 않다면 모바일 앱용 REST API와 HTML 조각을 전달하는 Hotwire/Livewire 요청 처리기를 둘 다 유지해야 함
      개인적으로 PWA는 클라이언트 문제이며, 서버 의존성을 추가하지 말고 클라이언트 쪽에서 처리해야 한다고 봄
    • 이 방식이 언급한 대안들보다 덜 토끼굴인 이유가 뭔지 궁금함

  • 이게 처음 나왔던 시점에 더 가까운 2020년 HN 대화는 여기 있음: https://news.ycombinator.com/item?id=25507942

  • 거의 한 바퀴 돌아온 느낌임. 2005년이나 2006년쯤 클릭을 가로채서 매개변수를 붙이고, 렌더링된 HTML 부분 조각만 받아 .innerHTML로 본문을 교체하는 방식을 썼던 기억이 있음

    • 2000년대 초 AJAX가 나오기 전, Adam Rifkin이 자기 스타트업 KnowNow의 데모를 보여줬는데 당시에는 웹 페이지가 새로고침 없이 스스로 갱신되는 게 충격적이었음
      요령은 HTTP 요청을 계속 열어두고 서버가 가끔 업데이트를 보내는 것이었고, 그 업데이트도 HTML이었음. 그때는 DOM 조작도 못 했을 수 있어서, 말 그대로 닫히지 않는 태그가 있는 페이지였을지도 모름
    • 한 바퀴 돌았다기보다는 서로 다른 웹 UI 패러다임들이 범위를 넓히고 있다고 보는 게 더 정확함
      서버 렌더링 프레임워크는 클라이언트 상호작용을 더 쉽게 만들고 있고, React는 RSC를 통해 서버 렌더링을 더 쉽게 만들고 있음. 매우 상호작용이 많은 웹 앱이라면 여전히 SPA가 유리함
    • Hotwire나 비슷한 라이브러리가 올라올 때마다 이런 얘기를 듣지만, 현실적으로 AJAX 기반 단순 CRUD는 사라진 적이 없음
      SPA 프로젝트가 아주 많긴 해도, 그게 세상의 모든 웹사이트를 설명하진 않음
    • https://animasci.com/에서 비슷한 방식을 쓰고 있음
      페이지네이션은 스크롤을 내리고 “Show more”를 누르면 서버에서 다음 페이지를 HTML 조각으로 요청해 보이지 않는 iframe에 로드한 뒤, 로드가 끝나면 현재 페이지에 붙이는 식으로 구현했음
    • 2000년대 후반에 Wicket을 꽤 좋아했고 JavaScript는 싫어했지만, 서버에서 UI 상태와 템플릿을 관리하는 건 팀 환경에서 성능과 확장성 측면의 함정이 되기 쉬웠음
      그사이 웹, JavaScript, TypeScript가 많이 좋아진 걸 생각하면 이 접근에 다시 흥분하기는 어렵다

  • 고도로 상호작용적인 프론트엔드가 필요한 웹 앱은 많이 다뤄보지 않았지만, 전자상거래 상점과 내부 Rails 앱에서는 Turbo와 Stimulus가 새 개발자가 배워야 할 양을 크게 낮춰줬음

    • 스택을 단순하게 유지하면 원래 그렇게까지 어렵지 않았음
      예를 들어 Django 프로젝트 하나에서 검증된 KnockoutJS로 사무실용 도구를 통째로 빠르게 만들었고, 이건 HTMX의 정신과도 어느 정도 맞닿아 있음. 아직 초기인 Arrow.JS도 비슷함. 복잡성, 특히 UI 쪽 복잡성은 대체로 스스로 만든 것이었고, 오래된 방식은 전혀 낡지 않았으며 오히려 돌아오고 있음. 업계가 모든 웹 애플리케이션을 과하게 복잡하고 견디기 어려운 덩어리로 만들어야 한다고 설득하던 가장 어리석은 시기에 입문한 젊은 개발자 세대가 있음
    • Stimulus를 써본 입장에서 Stimulus는 형편없었고 다시는 쓰지 않을 것임. Hotwire는 괜찮았음

  • Hey를 출시 때부터 유료로 쓰고 있는데, Hey 웹앱 경험이 Hotwire의 최고 사례라면 사양하고 싶음
    느린 연결에서는 나쁘다. 개발자가 로딩 상태나 오류 상태를 안 넣은 탓일 수도 있고, 복잡성이 큰 탓일 수도 있고, Hey의 버그일 수도 있음. 모르겠지만 좋지는 않음
    중간에서 높은 지연 시간에서는 동작이 예측 불가능하거나 버그처럼 느껴짐. 내용 없는 박스가 열리고, 링크가 기대처럼 동작하지 않으며, 여러 동작을 빠르게 연속으로 했을 때 직관적인 방식으로 중단되지 않음. 그냥 어긋난 느낌임
    SPA가 아무리 나쁘다 해도, 이건 UI가 네이티브하고 자연스럽게 느껴지는 방향에서 한 걸음 멀어진 것 같음

  • 이 글이 지금 다시 뜬 이유는 지난주에 누군가가 Hey가 모달을 여는 속도가 느리다고 올렸기 때문임: https://x.com/noahflk/status/1795758603577545035
    Hey는 DHH가 만들었고, DHH는 Hotwire와 Rails도 만들었음. 그 뒤로 원본 영상이 제한된 네트워크에서 찍혔다는 DHH의 반박, 모달을 로드하는 데 시간이 걸린다면 Hotwire가 네트워크에 너무 의존한다는 반응, Rails/Hotwire 옹호, 접근 방식에 대한 반대 등이 섞여 뜨거운 논쟁이 됐음. 지난주 Twitter에서 큰 주제였음

    • DHH가 원본 영상이 제한된 네트워크에서 찍혔다고 한 건 맞음
      작성자도 “시연을 위해 의도적으로 느리게 한 것”이라고 썼음: https://x.com/noahflk/status/1795855075526471915. “SF의 좋은 MacBook과 기가비트 인터넷”을 쓰는 사람 경험을 보여주려던 게 아니라, 느린 모바일 인터넷과 싼 노트북을 쓰는 사람을 말하려던 것이라고 했음. Google Calendar SPA가 훨씬 느리다는 지적도 있었고, “SF 기가비트 인터넷”과 “강하게 제한된 3G”만 선택지가 있는 것도 아님. 원본 게시물은 매우 오해를 부르는 내용이었고, 사실상 거짓말에 가까웠음
    • DHH의 직접 답변 링크: https://x.com/dhh/status/1796163806650868149
    • 약 1년 전에 Hey를 봤을 때는 태평양 반대편에서도 꽤 빠릿해 보였음
      특히 페이지 구조가 인상적이었음. 예를 들어 컨텍스트 메뉴 오버레이에 details/summary/anchor 조합을 점진적 향상 방식으로 적용했고, JavaScript를 끄거나 애셋이 로드되지 않아도 단순한 레이아웃으로 메뉴 콘텐츠를 우아하게 불러오도록 되어 있었음. 그 밖에도 Web API를 신중하게 쓴 부분이 많았고, 클라이언트 코드도 거의 난독화되지 않고 소스 맵이 붙어 있었던 걸로 기억함. DHH의 팬도 아니고 그 주의 드라마를 따라갈 생각도 없지만, 이번에는 37signals가 제대로 했다고 느꼈음
    • 이미 고쳤음. 업데이트는 여기서 확인 가능함: https://x.com/dhh/status/1797370923391357143

  • 같은 아이디어를 더 미니멀하게 구현한 Swap JS를 2년 전에 만들었음: https://github.com/josephernest/Swap
    몇몇 프로젝트에서 써봤고 잘 동작함

답변달기