Misago가 성능과 유지보수 향상을 위해 React.js에서 HTMX로 마이그레이션

Misago가 중복된 코드를 제거하고 성능을 향상시키기 위해 React.js를 HTMX로 대체하고 있습니다

Misago는 HTMX로 구동되는 서버 사이드 렌더링으로 돌아가기 위해 React.js 기반 Single Page Application(SPA) 접근 방식에서 프론트엔드 아키텍처를 마이그레이션하고 있습니다. 이 변경은 페이지가 두 번 구축되는 'double implementation' 문제를 해결하는 것을 목표로 합니다—한 번은 초기 로드/SEO를 위한 Django 템플릿으로, 또 다른 한 번은 상호작용을 위한 React 컴포넌트로—これにより 유지보수 오버헤드가 증가하고 응답 시간이 느려집니다.

React.js와 Django 하이브리드 접근 방식의 문제점

이전 아키텍처는 백엔드와 프론트엔드 간의 복잡한 동기화가 필요했으며, 이로 인해 여러 기술적 병목 현상이 발생했습니다:

• 중복 구현: 대부분의 페이지는 Django 템플릿과 React 컴포넌트 둘 다 존재했으며, 이는 UI 변경 시 두 곳 모두를 업데이트가 필요함을 의미합니다.
• 개발 마찰: Django 템플릿을 편집하는 커스터마이저는 종종 자신의 변경 사항이 brevemente 반짝였다가 React의 클라이언트 사이드 렌더링에 의해 덮어쓰이는 것을 보았습니다.
• 지연 시간 증가: React 앱을 "미리 구워넣기" 위해 데이터를 JSON으로 직렬화해야 하는 필요성이 서버 응답 생성을 느리게 했습니다.
• 번들 블로트: 번역 메시지가 django.po와 djangojs.po 파일에 중복되어 사용자의 초기 다운로드 크기가 증가했습니다.
• 성능 저하: 큰 JavaScript 번들이 성능에 부정적인 영향을 미쳤으며, 특히 오래된 모바일 기기에서 두드러졌습니다.
• 플러그인 복잡성: 플러그인 개발자는 Django 템플릿과 React 컴포넌트 둘 다 구현하도록 강요받았으며, 이는 사이트 빌드 프로세스 내에서 JavaScript 빌드 단계가 필요함을 의미합니다.

왜 포럼 상호작용에 HTMX가 선택되었는가

포럼 소프트웨어는 일반적으로 완전한 SPA 경험보다는 중립적인 '섬'—예를 들어 관리자 작업, 투표 설문, 알림 업데이트 등—에서 상호작용이 필요합니다. HTMX는 상호작용 시 새로운 서버 렌더링 HTML로 HTML의 일부를 교체함으로써 이러한 특정 영역을 동적으로 만들며, 전체 페이지 reload 없이 이를 수행합니다.

By using HTMX, Misago removes the need for JSON serialization and dedicated JavaScript components for these interactions. The backend simply returns the necessary HTML fragment for the requested "island," which the browser then swaps into the existing page.

JavaScript 번들 크기에 대한 측정 가능한 영향

초기 마이그레이션 단계에서 이미 총 JavaScript 발자국이 감소함을 보여주었습니다. 예를 들어, 'Forum options' 페이지를 'Account settings'로 대체하고 Django 뷰와 HTMX를 사용하여 'Threads lists'를 다시 작성함으로써 misago.js에서 다음과 같은 감소가 발생했습니다:

• Account settings migration: misago.js가 37kb (gzipped 17kb) 감소했습니다.
• Threads lists migration: misago.js가 48kb (gzipped 8kb) 감소했습니다.

이러한 변경 이전, Misago 0.39의 기본 JS 크기는 vendor.js가 679kb이고 misago.js가 615kb(압축되지 않음)였습니다.

HTMX 전환에 대한 커뮤니티 관점

이 마이그레이션에 대한 기술적 논의는 서버 사이드 렌더링의 간단함을 선호하는 측과 클라이언트 사이드 상태 관리의 필요성을 주장하는 측 사이의 차이를 강조합니다.

포럼에서 HTMX에 대한 찬성 논점

많은 개발자는 포럼이 주로 텍스트 기반 콘텐츠를 제공하기 때문에 HTMX의 이상적인 사용 사례라고 주장합니다. 한 기여자는 다음과 같이 언급했습니다:

저는 HTMX가 포럼 소프트웨어에 매우 적합하다고 생각합니다. 포럼 웹사이트는 대부분 비대화형 콘텐츠를 제공합니다... HTMX를 사용하면 서버 전송 이벤트를 통해 부분 렌더링과 실시간 업데이트를 수행할 수 있습니다.

제한 사항 및 트레이드오프

다른 개발자들은 HTMX가 '풍부한' 상호작용이나 높은 빈도의 DOM 업데이트에서 어려움을 겪을 수 있다고 지적했습니다. 한 사용자는 제품 목록 페이지에서의 부정적인 경험을 공유했습니다:

제가 겪었던 문제는 모든 것이 하나의 "response"로 함께 작동할 때 전체 경험이 정말 느려졌다는 것이었습니다. 전체 폼에 대한 모든 HTML을 다시 보내는 것...이 반 dozen 이상의 결과가 있을 때 눈에 띄게 느려졌습니다.

또 다른 비판은 React과 비교하여 세부적인 DOM 조정의 부족에 초점을 맞췄습니다:

React은 그런 종류의 것을 중심으로 설계되었습니다. 그들은 원활한 DOM 조정을 지원하기 위해 후드 아래에서 재미있는 마법을 수행합니다... 만약 누군가가 htmx와 같은 SSR-like 것을 출시한다면 무언가가 부족하다고 느낄 것입니다.

미래 마이그레이션 전략

Misago는 개별 구성 요소(Navbar, threads list, 사용자 프로필 등)를 한 번에 한 릴리스씩 이동하면서 점진적인 단계로 HTMX로 전환할 것입니다. 이 전환 기간 동안 일부 페이지는 AJAX 또는 HTMX가 사용되어 게시물 좋아요나 투표 설문과 같은 참을 수 없는 사용자 경험 마찰을 방지하는 경우를 제외하고는 전체 페이지 reload를 갖는 표준 다중 페이지 애플리케이션(MPA)으로 일시적으로 작동할 수 있습니다.