Hotwire vs. React: “One-Person Framework”를 위한 가이드

Source: Dev.to

기본 선택

지난 5년 동안 “표준 웹 스택”은 부인할 수 없었습니다:
백엔드 API (Rails/Node) + SPA 프론트엔드 (React/Vue).
부트캠프에서 가르치고, 채용 담당자가 요구하며, 한때는 “모던”한 느낌의 애플리케이션—페이지 리로드 없이, 빠른 전환, 실시간 업데이트—을 만들 수 있는 유일한 방법이었습니다.

하지만 비용이 따릅니다. 저는 이를 React 세금이라고 부릅니다.
Rails 7(그리고 이제 Rails 8)의 성숙도와 Hotwire가 등장하면서, 그 세금은 더 이상 필수가 아닙니다. 제가 Hotwire가 Rails 프로젝트의 95 %에 대해 더 나은 선택이라고 믿는 이유는 다음과 같습니다.

React의 숨은 비용

React를 선택하면 단일 앱을 만드는 것이 아니라 두 개의 앱을 만드는 것입니다:

• 백엔드 – 직렬화, JWT, CORS, 버전 관리.
• 프론트엔드 – 라우트 관리, 전역 상태(Redux/Context), 이펙트 훅, package.json 지옥.

“프로젝트 이름 바꾸기” 같은 간단한 기능도 다음과 같이 여러 단계로 확장됩니다:

• 프론트엔드: UI 상태를 낙관적으로 업데이트.
• 프론트엔드: API 호출 디스패치.
• 백엔드: 인증 처리.
• 백엔드: DB 업데이트.
• 백엔드: JSON 응답 직렬화.
• 프론트엔드: 성공/오류 처리.
• 프론트엔드: 로컬 상태 재동기화.

Hotwire의 간소화된 흐름

Hotwire를 사용하면 흐름이 다음으로 축소됩니다:

• 컨트롤러 – DB 업데이트.
• 뷰 – HTML 렌더링.

컴퓨터 과학에서 가장 어려운 문제는 이름 짓기입니다. 두 번째로 어려운 문제는 캐시 무효화입니다. 데이터베이스 상태를 Redux 스토어나 React Query 캐시에 복제하면 버그가 생깁니다: 오래된 리스트, 맞지 않는 카운트, UI는 “프리미엄”을 표시하는데 API는 403을 반환하는 경우 등. Hotwire는 이러한 전제를 거부합니다.

Turbo는 서버를 단일 진실의 원천으로 만듭니다. 데이터가 변경되면 화면에 있는 HTML 조각을 서버에서 새 HTML로 교체하여, 클라이언트‑사이드 상태가 없기 때문에 “상태 불일치” 버그 전체를 제거합니다.

원-퍼슨 프레임워크

Rails 8은 “원‑퍼슨 프레임워크” 개념을 추진합니다: 한 명의 개발자가 이전에 다섯 명 팀이 필요했던 스타트업을 구축할 수 있어야 합니다. React를 사용하는 솔로 개발자나 작은 팀은 백엔드와 프론트엔드 사이의 접합 작업에 전체 시간의 약 50 %를 소비합니다.

Hotwire(Turbo Drive + Turbo Frames + Stimulus)를 사용하면 작업의 약 90 %를 Ruby/ERB 환경에서 처리합니다:

• 표준 Rails 뷰 작성.
• Turbo Drive를 통해 SPA 수준의 네비게이션을 무료로 제공.
• Frames를 통해 동적 부분 업데이트 제공.

컨텍스트 전환 비용

이것은 2016년에 해당했지만, 오늘은 그렇지 않습니다.

Turbo Drive와 Turbo Streams

Turbo Drive는 링크 클릭과 폼 제출을 가로채서 표준 Rails 앱을 즉시 반응하도록 만듭니다. 전체 브라우저 리로드 없이 를 병합하고 를 교체합니다.

실시간이 필요합니까? ActionCable 위의 Turbo Streams를 사용하면 몇 줄의 Ruby만으로 수백만 사용자에게 업데이트를 방송할 수 있습니다:

# app/models/message.rb
after_create_commit { broadcast_append_to "chat_room" }

이 한 줄은 모든 활성 사용자에게 새로운 메시지를 DOM에 추가하는 WebSocket 연결을 생성합니다. 동일한 작업을 React에서 수행하려면 소켓 컨텍스트, 리스너, 상태 리듀서, 안전 검사 등을 모두 설정해야 합니다.

React가 여전히 의미가 있는 경우

저는 React를 싫어하는 사람이 아닙니다; 정말 뛰어난 엔지니어링 작품입니다. 다음과 같은 경우 React(또는 Vue/Svelte)를 사용해야 합니다:

• 고충실도 도구를 구축하는 경우(예: Figma, 브라우저 기반 비디오 편집기, 복잡한 드래그‑앤‑드롭 Trello 클론).
• “오프라인 퍼스트”(인터넷 연결 없이 100 % 동작해야 하는 PWA)가 필요한 경우.
• API가 여러 클라이언트(모바일, 웹, 데스크톱)에게 동일한 인터페이스를 제공해야 하는 경우—비록 네이티브 앱도 서버‑구동 UI로 이동하고 있지만.

대다수 경우

대부분의 SaaS 제품—대시보드, 마켓플레이스, 소셜 네트워크, 프로젝트‑관리 도구—에 대해 “React 세금”은 자원의 낭비입니다. Hotwire는 복잡도는 약 10 % 수준으로 React 인터랙티브성의 약 80 %를 제공합니다.

If you want to ship features quickly, use Hotwire.*
If you want to configure Webpack, use React.

Are you sticking with the React ecosystem, or have you tried the Hotwire life? Let’s discuss below.

Source: (source link remains unchanged)

기능을 빠르게 배포하고 싶다면 Hotwire를 사용하세요.*
Webpack을 구성하고 싶다면 React를 사용하세요.

React 생태계에 머무르고 있나요, 아니면 Hotwire 생활을 시도해 보셨나요? 아래에서 논의해 보세요.