코로나가 시작하기 전, 웹 개발에 처음 발을 들이고 React에 대해 알아가며 가장 많이 들었던 말은 SPA(Single Page Application) 와 CSR(Client Side Rendering) 관점에서 React가 기존 웹 프레임워크에 비해서 가지는 장점들이었다. 그 당시 웹 꼬꼬마였던 나는 SSR은 페이지 이동마다 화면이 깜빡거리고 페이지 전체를 다운로드 받아야 했던, 정적 웹 페이지가 가득했던 구시대의 산물로만 알고 있었다.
그런 내게 얼마 전, 새로 이전해 관리되고 있는 React 공식문서의 변경내용은 가히 충격적이었다.
구 React 공식문서
현 React 공식문서
React 공식 문서에서 React 프로젝트를 시작하는 방법으로 과거 React 초보들에게 빛과 소금같이 여겨졌던 CRA(Create-React-App) 대신 CNA(Create-Next-App)를 가장 먼저 권장하고 있었기 때문이다.
(https://react.dev/learn/start-a-new-react-project)
10/26(목)에 Next.js 컨퍼런스가 있습니다. 많관부
예전부터 Next.js에 대해서는 어느 정도 관심이 있었고, 토이 프로젝트에서 한 번 다뤄본 경험도 있었다. Next.js가 내세우는 여러 장점들의 배경에는 SSR(Server Side Rendering)이 있는데, 문득 이런 의문이 들었다.
UI 렌더링 방법이 어째서 다시 CSR에서 SSR로 돌아가는 걸까?
이와 같은 의문을 아래 Deno 공식 블로그의 한 포스팅을 보고 해답을 찾았다.
The Future (and the Past) of the Web is Server Side Rendering
그리고 이 아래는 블로그의 내용중 일부를 번역한 것이다.
예전 정적 웹 페이지들만 가득했던 과거와 달리, 지금의 웹페이지는 여러 소스들에서 데이터를 받아와 실시간으로 조작하고, 사용자와 상호작용을 하는 완전한 앱이다. 이로 인해 웹의 유용성은 크게 향상되었지만, 크기, 대역폭 및 속도 차원에서의 네트워크 비용이 발생하는데, 지난 10년 동안 웹페이지의 평균 사이즈는 468kb에서 2284kb로 약 4배 가까이 증가했다. 모바일의 경우 더 격차가 큰데, 145kb에서 2010kb로 13배에 가까이 증가했다.
이 부분은 곧 모바일 환경에서 네트워크로 전송해야하는 큰 부하가 되며, 결과적으로 사용자는 모든 것이 렌더링 될 때까지 느린 로드 시간 및 상호 작용 부재라는 끔찍한 경험을 하게 된다.
이것이 오늘날 프론트엔드 개발자에게 발생하는 문제이다. 크로스 브라우징, 코드 전송을 위한 느린 네트워크 및 불안정한 모바일 네트워크와 싸워야한다.
