GN⁺: 의존성 관리의 피로함: React를 버리고 Go+HTMX+Templ 를 선택한 이유
(blog.erodriguez.de)- 올해 Go, HTMX, Templ을 사용하여 개인 프로젝트를 진행한 후 React 사용을 포기하기로 결정
- HTMX 공식 웹사이트에서 React를 포기하고 HTMX를 선택하는 여러 설득력 있는 주장을 찾을 수 있지만, 의존성 관리 피로에 대해 이야기하는 사람이 많지 않다고 느낌
- "의존성 관리 피로"란 무엇인가?
- React를 사용한 마지막 개인 프로젝트(인터랙티브 카탈로니아어 사전)에서 주로 React 패키지의 의존성 업데이트에 너무 많은 시간을 소비하고 있음을 깨달음
- 패키지를 최신 릴리스로 업데이트하면 API에 중대한 변경 사항이 발생하여 코드 리팩토링에 시간을 투자해야 했음
- 웹앱이 EC2 인스턴스에서 공개 서비스로 배포되었기 때문에 의존성 업데이트를 유지하고자 했음
- 새로운 주요 버전 릴리스가 정말 필요한가?
- wouter(React 라우터 패키지)와 TanStackQuery(백엔드에서 데이터를 가져오고 캐시하며 상태를 관리하는 데 사용)와 같은 패키지가 주요 버전 업데이트로 인해 웹앱이 치명적으로 손상됨.
- 첫 번째 주요 버전 업데이트로 인해 애플리케이션이 손상되었을 때는 의문 없이 코드를 리팩토링했지만, 두 번째로 발생했을 때는 의문이 생김.
- 웹앱이 보안 패치를 제외하고 주요 버전 릴리스로부터 실제로 어떤 이점을 얻고 있는지 의문을 가짐.
- 주요 구성 요소의 API를 5번이나 깨뜨리는 것이 필요한지 의문을 가짐.
- 새로운 기능이나 다른 제품을 출시할 수 있는 시간을 얼마나 잃고 있는지 고민함.
- 시간 부족 문제
- 개인 코딩 프로젝트에 할애할 시간이 많지 않기 때문에 의존성의 주요 버전 업데이트 후 코드를 리팩토링하는 데 시간을 낭비하고 싶지 않음.
- 고객을 위한 제품을 구축하고 향후 유지보수 작업에 대해 비용을 청구할 계획이라면 불안정한 의존성을 많이 사용해도 좋음.
- 그러나 최소한의 유지보수가 필요한 제품을 만들고자 한다면 JS 생태계에서 멀리 떨어져 있겠음.
-
Go+HTMX+Templ 사용
- 개인 프로젝트에서 Go+HTMX+Templ을 사용하는 주된 이유는 Go 프로젝트가 기능을 출시하는 데 집중할 수 있게 해주면서도 일반적인 의존성/보안 업데이트를 무시하지 않기 때문임.
- Go 언어 자체는 안정적인 표준 라이브러리와 언어 사양을 유지하고 있음.
의존성 관리의 피로함 VS 바퀴를 새로 만드는 지겨움
오래된 논쟁입니다. 필요 없는 바퀴는 안 쓰는 게 맞긴 한데, 오늘 필요 없다고 내일도 필요 없을지...
GO는 사용해본 적 없긴 한데, 요즘 GO로 만든 서버가 많이 보이네요. 당장 쓰진 않더라도 한 번 다뤄보긴 해야 겠어요.
HTMX 는 긍정적인 평이 많네요.
SSR 기반의 어플리케이션의 보완책 으로써 HTMX 를 많이 찾는걸까 싶네요.
사이드에서 한번 시도 해 보아야겠네요.
TanStack 라이브러리는 필요 이상으로 복잡하고 최근 몇년동안 문서 품질이 낮아져서 고르지 않았습니다. 그리고 npm 패키지들의 교체주기가 너무 짧아서 항상 최신버전을 고집할 필요가 있나 싶기도 합니다
다만 회사일할때는 React를 버릴수는 없을거 같아요. 개인 프로젝트라면 뭘 써도 상관없겠지만요
얼마 전에 사내에서 돌아가는 스케쥴 잡 중에 파이선2로 돌아가는 녀석을 봤는데, 숨이 막히더군요.
고민하다가, 지금은 잘 돌아가니 일단 두자고 했습니다. 언제까지고 업데이트 안하고 버틸 수는 없겠죠.
Hacker News 의견
-
React와 같은 라이브러리를 포기하고 Actix, Tera, HTMX로 웹 앱을 개발한 경험을 공유함. 이러한 스택은 유지보수성이 뛰어나며, 사용자들에게 인기를 끌고 있음
- 새로운 웹 앱을 빠르게 개발하여 테스트 사용자에게 배포한 경험을 설명함
- "의존성 관리 피로"가 없었기에 도구에 대한 깊은 이해를 얻을 수 있었음
-
Tanner의 라이브러리는 기능이 많지만 API 디자인이 부족하다고 평가함
- React Table과 React Query는 강력하지만 경계가 잘못 설정되어 있어 문제를 일으킴
- React의 장점은 프레임워크가 아니라는 점이며, 잘 설계된 경계에서 멈춤
- 이러한 기준을 충족하는 라이브러리만 채택하려고 노력함
-
HTMX 예제가 복잡성을 다른 부분으로 옮긴다고 느끼며, JSX가 템플릿을 피하는 우아한 방법이라고 설명함
- 라우팅, 상태 관리, 인증 등 여전히 해결해야 할 문제들이 많음
-
React를 포기한다고 말하는 것이 이상하다고 느끼며, 문제는 React가 아닌 다른 의존성에 있다고 주장함
- Go로 백엔드를 작성하는 선택은 항상 가능했음
-
패키지의 다음 주요 버전으로 업데이트할 때 변경이 예상된다는 점을 잊지 말라고 강조함
- Remix의 예를 들어, 변경 사항을 점진적으로 적용할 수 있는 방법을 설명함
- 좋은 패키지는 큰 노력이 필요하다고 주장함
-
Django와 HTMX로 SPA 프로젝트를 마이그레이션한 경험을 공유하며, JavaScript 의존성을 크게 줄였다고 설명함
- SPA가 시간 폭탄처럼 느껴졌다고 표현함
-
React는 잘못 유지되는 서드파티 패키지의 책임이 아니라고 주장함
- 라우터나 Redux 같은 상태 관리 도구가 필요하지 않다고 설명함
-
react-query의 v5가 v3 API와 호환되었어야 한다고 생각하지만, 마이그레이션이 쉽고 필수적이지 않다고 설명함
- "의존성 관리 피로"가 과장되었다고 느끼며, 합리적인 수의 의존성을 유지하라고 조언함
-
웹 앱이 추가적인 이점을 얻지 못했음에도 불구하고 업그레이드한 이유를 의문시함
- 최신 버전으로 업그레이드하는 것이 이점이 없다고 설명함
-
React와 nextjs를 포기하고 다른 스택으로 전환한 후 스트레스가 줄어들고 업데이트가 더 이상 우울증을 유발하지 않는다고 설명함