- 저자가 50,000줄의 코드를 React Server Components(RSCs)로 이동하면서 경험하고 배운 교훈에 대한 기사
- RSCs는 클라이언트 대신 서버에서 실행되는 React 컴포넌트로, 서버 사이드 렌더링(SSR)보다 두 가지 주요한 이점을 제공
- 첫째, RSCs는 개발자가 코드가 실행되는 위치를 정의하게 해주어, 번들 크기를 줄이고 hydration 동안의 작업을 감소시킴
- 둘째, 서버 컴포넌트는 컴포넌트 내에서 직접 데이터를 가져와 클라이언트에 스트리밍함으로써, React에서의 데이터 가져오기를 더 쉽고 효율적으로 만듦
- 그러나 RSCs를 사용하는 데에는 일부 제한 사항이 있음. CSS-in-JS는 서버 컴포넌트에서 작동하지 않고, React Context는 클라이언트 컴포넌트에서만 접근 가능하며, 코드가 실행되는 위치를 관리하는 복잡성이 도전적일 수 있음
- 저자는 RSCs를 점진적으로 채택하기 위한 3단계 접근법을 제안함:
- 앱의 루트에 "use client" 지시문을 추가함
- 렌더링 트리에서 가능한 한 낮은 위치로 지시문을 이동함
- 성능 문제가 발생할 때 고급 패턴을 채택함
- 추가된 복잡성에도 불구하고, 저자는 RSCs의 이점들, 예를 들어 더 작은 번들 크기, 더 빠른 실행, 고급 데이터 로딩 패턴 등이 팀에게 성능 이점이 가치 있는 경우 비용을 상회할 수 있다고 결론 내림
Hacker News 의견
- 기사는 50K 코드 라인을 React Server Components (RSCs)로 전환하는 논의를 다룹니다.
- 일부 사용자들은 서버 측 렌더링의 속도와 간편함을 언급하며, 클라이언트가 즉시 볼 수 있는 HTML을 받는다는 점을 지적했습니다.
- RSCs 대신 Rails, Django, Laravel 등의 전체 스택 또는 클래식 웹 프레임워크를 고려하는 것이 더 빠르고 확장 가능한 해결책이 될 수 있다는 제안이 있습니다.
- 일부 사용자들은 현대 프레임워크의 복잡성에 대해 우려를 표현하며, 간단한 작업에도 필요한 광범위한 빌드 및 컴파일 파이프라인을 언급했습니다.
- 사용자들은 next.js와 그 새로운
app디렉토리 설정에 대한 개인적인 경험을 공유했으며, 작업이 어디서 일어나는지 (서버 또는 클라이언트) 이해하는 데 어려움이 있고, 클라이언트 측 작업을 가정하는 기존 React 라이브러리와의 문제점을 강조했습니다. - 일부 사용자들은 새로운 next.js 앱 디렉토리 패러다임에서의 버그와 거친 부분을 지적했으며, 동적 라우트와 병렬 라우트와 관련된 문제를 포함했습니다.
- 한 사용자는 PHP와 JavaScript의 유사성을 언급하며, JavaScript가 비록 더 많은 약어와 더 가파른 학습 곡선을 가지고 있지만, 유사한 서버 측 기능을 제공하도록 발전했다고 지적했습니다.
- 일부 사용자들은 정적 사이트 생성기나 캐싱이 있는 CMS와 같은 더 간단한 도구로 해결할 수 있는 작업에 React를 사용할 필요성에 의문을 제기했습니다.
- 서버가 모든 것을 렌더링하고 CSS와 JavaScript가 렌더링 후 페이지를 향상시키는 시절에 대한 향수 정서가 있습니다.
- 일부 사용자들은 React가 현대적이고 더 쉽고 빠른 대안을 따라잡기 위해 더 복잡해지고 있다는 견해를 표현했습니다.
- React를 백엔드에서 HTML을 렌더링하는 데 사용하는 것에 대한 논쟁이 있으며, 일부 사용자들은 그 필요성에 의문을 제기하고 다른 사용자들은 전통적인 서버 반환 방법보다 이점을 옹호했습니다.