1. Framework vs. Library

React.js는 라이브러리이고, Next.js는 React.js의 프레임워크이다.
이 둘의 궁극적인 차이점은 "응용 프로그램의 흐름 주도권을 누가 가지고 있느냐"이다.

1) Framework

• 코드를 작성하는 기본적인 틀을 제공해서 보다 효율적으로 어플리케이션을 만들 수 있도록 하는 소프트웨어 환경
• 응용 프로그램은 프레임워크에 의해 사용된다.
• 키워드: Rule, Logic, Auto

2) Library

• 어플리케이션을 만들 때 필요한 자원(기능: 함수)의 모임
• 응용 프로그램이 라이브러리를 사용한다.
• 키워드: Freedom, Custom
즉, React에서는 우리가 모든 것을 직접 생성하고 설정해 주었던 것들이 Next에서는 이미 만들어져 있다.
우리는 Next 규칙에 따라 코드만 작성하면 된다.

2. CSR vs SSR

create-react-app로 만든 React.js 앱은 CSR(Client-Side-Rendering)이고,
creat-next-app로 만든 Nest.js 앱은 SSR(Server-Side-Rendering)이다.
CSR과 SSR은 유저가 브라우저에서 보는 화면인 "UI를 어디서 만들어 주는지"에 따라 구분한다.
CSR은 클라이언트(프론트)에서, SSR은 서버(백)에서 화면을 구성한다.

1) React 동작 방식 (CSR)

유저와 서버, 브라우저 각각의 입장을 나눠서 생각하면 이해하기가 쉽다. (브라우저는 유저와 앱의 연결통로)
1. 유저가 브라우저를 통해 앱에 접속하면,앱은 브라우저에게 javascript 정보가 들어있는 빈 html 문서을 전달한다.
즉, 브라우저에게 javascript파일을 전달하는 것으로 볼 수 있다.
2. 브라우저는 javascript파일을 다운로드하고 동시에 유저는 빈 화면을 보게 된다(접속에 대한 응답).
3. 브라우저에서 js 파일의 다운로드가 끝나면, 리액트 코드가 있는 js파일을 실행한다.
4. 브라우저에 있는 리액트 코드가 UI를 렌더링한다. (동적으로 렌더링)
5. 유저는 드디어 앱이 보여주고자 했던 화면을 보게 된다.
즉, 브라우저가 javascript 코드를 가지고 있지 않거나, 요청 중인 상태라면 UI를 구성할 수 없고, 유저는 빈 화면을 보게 된다. 리액트 코드가 실행되기 전까지는 유저 화면에 아무것도 보이지 않는 것이다. 이렇게 클라이언트 측에서 UI를 빌드하는 것을 CSR 방식이라 한다.

👍 장점

• 초기 로드만 완료되면 이후 렌더링이 빠르다.
• 서버에 요청할 것이 거의 없어 서버 부담이 적다. (data 필요할 때만 요청)
• Web Applications에 좋다.

👎 단점

• SEO에 좋지 않다. (초기 HTML 파일이 비어있기 때문에 봇이 데이터 수집하기 어려움)
• 초기 로드가 오래 걸린다.
• 외부 라이브러리가 필요한 경우가 많다.

2) Next 동작 방식 (SSR)

유저와 서버, 브라우저 각각의 입장을 나눠서 생각하면 이해하기가 쉽다. (브라우저는 유저와 앱의 연결통로)
1. 유저가 브라우저를 통해 앱에 접속하면, 서버에서 리액트를 실행한다. -> 리액트는 UI를 렌더링한다.
2. 렌더링된 결과를 통해 브라우저에게 HTML을 제공한다. 이때 유저는 앱의 초기화면을 보게 된다(접속에 대한 응답).
3. 이후 브라우저는 리액트 코드가 있는 Javascript 파일을 다운받고 실행시킨다. 이때부터 일반적인 리액트 앱과 같이 CSR의 동작(동적 렌더링)을 하게 되고 이 과정을 hydration이라고 한다.
즉, 서버에서 UI를 모두 구성한 후 유저에게 응답해 화면을 보여주는 방식으로, 화면이 pre-rendering되어 유저는 인터넷 속도에 상관없이 화면에 뭔가 나오는 것을 볼 수 있다. 이렇게 서버 측에서 UI를 렌더링하는 것을 SSR 방식이라 한다.
cf) hydration - 리액트 코드가 브라우저에 이미 존재하는 HTML과 동기화하여 앱이 동적으로 상호작용할 수 있도록하는 과정

👍 장점

• SEO에 좋다. (HTML 파일에 모든 정보가 포함되어 있기 때문에 봇이 데이터 수집 가능)
• 초기 로딩 속도가 빠르다.
• Static sites에 좋다.
• Next는 기본적으로 웹팩과 바벨을 사용하고있어 SSR 및 개발에 필요한 설정이 이미 되어있어 빠르게 개발을 시작할 수 있다.

👎 단점

• 서버에서 전체 앱을 미리 렌더링하기 때문에 컴포넌트 로딩이 오래 걸리면 유저는 빈 화면을 볼 수도 있다.
• 서버에 매번 요청하기 때문에 서버 부하가 크다. (view 변경 시 요청)
• 페이지를 요청할 때마다 새로고침되어 UX가 다소 떨어진다.
과거의 웹사이트들은 대부분 SSR로 동작 되어 왔기 때문에, 페이지가 여러 개로 구성된 Multi Page Form 방식을 사용했었습니다. 하지만 스마트폰이 등장하게 되면서, 예전 웹들은 모바일에 최적화가 되어있지 않았기 때문에 사용에 불편함이 커지게 되었습니다. 그래서 사용자들은 모바일 앱과 같은 형태의 웹페이지가 필요하게 되었는데요.
CSR(Client Side Rendering)이 가능한 SPA(Single Page Application)가 등장하게 되었습니다.
이 SPA의 특징은 기존의 웹페이지와는 다르게 1개의 페이지에서 여러 동작이 이루어지는 방식입니다.
그래서 마치 모바일 앱과 비슷한 형태로 Header 영역은 고정되어 있고, Main 영역의 상태만 계속 변경하는 방식

1. SSR vs CSR

일반적인 React 렌더링 방식은 render() 함수가 먼저 실행되고, 그다음에 ComponentDidMount() 함수를 통해 데이터를 가져와서 다시 한 번 렌더링이 됩니다.
반면에 Next는 getInitialProps() 라는 함수를 사용하기 때문에 데이터를 먼저 가져와서 한 번에 렌더링을 해줍니다. 보시다시피 SSR은 한 번에 렌더링이 되기 때문에 초기로딩 속도는 빠르지만, page 이동 시에는 CSR보다 느립니다.
왜냐하면, page를 요청할 때마다 중복되는 파일을 내려받아야 하기 때문입니다.
하지만 CSR은 초기로딩 속도는 느리지만, 첫 페이지 로딩 때 모든 파일을 내려받기 때문에 페이지를 이동할 때마다 해당 페이지에서 필요한 데이터만 불러서 사용하면 됩니다.

2. Next특징

- 코드 스플리팅

일반적인 리액트 싱글페이지에서는 초기 렌더링 때 모든 컴포넌트를 내려받습니다. 하지만 규모가 커지고, 용량이 커지면 로딩속도가 지연될 수 있는 문제점이 있습니다.
Next는 이러한 문제점을 개선해서 필요에 따라 파일을 불러올 수 있게 여러 개의 파일을 분리하는 코드 스플리팅을 사용하였습니다. 폴더구조에pages 폴더 안에 각 page 즉, 라우트들이 들어가며, Components 폴더에는 React 컴포넌트들이 들어가게 되는데요.
예를 들어, 브라우저가 실행되고, 사용자가 접속을 하게 되면, 첫 페이지인 index page만 불러오게 되고, 그 이후에 다른 페이지로 넘어갔을 때는 해당 페이지만 불러오게 됩니다.

- 간단한 클라이언트 사이드 라우팅 제공

- getInitialProps()

Next의 핵심기능인 getInitialProps 함수를 통해 데이터를 가져올 수 있습니다. 밑에 코드를 보시면 React의 ComponentDidMount 는 렌더링이 두 번 되지만, Next에서는 데이터를 미리 갖고 오기 때문에 한 번에 렌더링이 가능합니다.