Dan Abramov on possible futures for CRA - "client-only doesn’t make sense. way too limiting" Create React App의 미래에 대해 생각해보니 클라이언트 전용은 말이 안 된다는 것이 분명했습니다. 너무 제한적이죠. React가 HTML로 미리 렌더링할 수 있는데 왜 항상 빈 HTML 파일을 생성하는 걸까요? 디스크에 있는 마크다운 파일을 맵()하여 블로그를 만들 수 없는 이유는 무엇일까요? 한동안 저는 이것이 CRA의 다음 반복이 되어야 한다고 생각했습니다. 물론 여전히 Node.js 서버를 사용할 필요는 없지만 빌드 중에 코드를 실행하는 이점을 활용할 수 있어야합니다! 그런 옵션이 없다는 것은 말이되지 않습니다. CRA는 예전과 비슷하지만 컴포넌트 트리를 정적으로 미리 렌더링하여 HTML이 비어 있지 않도록 할 수 있습니다. 하지만 그 시점부터는 분명히 클라이언트 기능을 사용할 수 있습니다. 우리는 상호작용을 좋아합니다 :) 하지만 라우터와의 통합 없이는 그런 식으로 작동할 수 없습니다. 단일 페이지 이상을 어떻게 미리 렌더링할 수 있을까요? 무엇을 렌더링할지 알 수 없습니다. 좋아, "대부분의 경우 작동하는" 좋은 솔루션으로 파일 기반 라우터를 추가해 보겠습니다. 경로당 HTML + 클라이언트 핸드오프. 빌드 중에 일부 코드를 생성하고 나머지는 클라이언트에서 처리할 수 있는 도구가 생기게 됩니다. 내비게이션은 SPA처럼 느껴집니다. 동적 서버 경로를 하나 추가하고 싶다고 가정해 봅시다. 하지만 그렇게 할 수 없습니다. 서버를 사용하지 못하도록 잠겨 있기 때문입니다. 여기에 문제가 있습니다. 현재 최신 프레임워크(특히 Next.js와 Gatsby)는 이미 이런 방식으로 작동합니다. 100% 정적 + 클라이언트로 시작할 수 있습니다. HTML 생성, 파일 기반 라우팅, SPA 탐색, 실제 클라이언트 코드(원하는 만큼)가 기본입니다. 그러나 파일 대신 DB에서 읽는 것과 같은 동적 경로에 서버를 사용하려는 경우 쉽게 사용할 수 있습니다. 코드 몇 줄만 변경하면 기존 페이지는 정적/클라이언트로 유지됩니다. 프레임워크는 그런 의미에서 종속성이 적습니다. 그래서 저는 이것을 구축하는 것은 Next.js/Gatsby가 이미 제공하는 것의 더 제한된 버전을 구축하는 것일 뿐이라는 것을 깨달았습니다. 이미 하는 것과 똑같은 일을 하지만 더 많은 것을 할 수는 없습니다. 최신 프레임워크는 하이브리드입니다. 하이브리드 프레임워크를 사용하면 SPA를 *더 많이* 구축할 수 있습니다. React 서버 컴포넌트도 마찬가지입니다. 사람들은 "서버"라고 하면 Node.js를 떠올리지만, 빌드하는 동안 RSC가 실행될 수 있습니다. 사실, Next 13 App Router에서는 이것이 *기본값*입니다. RSC에서 무언가를 fetch()하면 동적 렌더링을 선택하지 않는 한, 빌드 시점에 *실행*됩니다. 우리가 보고 있고, 또 그렇게 하려고 노력하고 있는 변화는 "SPA 작성"에서 "SPA 미작성"으로의 전환이 아닙니다. "SPA에 종속되는 것"(나중에 빌드 시간이나 서버 측 통합을 추가하기 어려움)에서 "각 페이지에 적합한 모드를 사용하는 것"으로의 변화입니다. 하이브리드 시대. 변화이긴 하지만 대부분 정신적인 변화입니다. 과거: "클라이언트 전용으로 시작하고 빌드 시간이나 서버가 필요할 때 다른 접근 방식으로 다시 작성합니다." 미래: "빌드 시간 + 클라이언트로 시작하되 원하는 대로 분할하고, 원하면 페이지당 서버를 추가합니다." 모든 것이 하이브리드로 수렴함에 따라 기존의 용어는 정말 혼란스러워졌습니다. - 사람들은 서버를 실행하지 않아도 되기 때문에 "SPA"를 절약하고 싶어합니다. - 사람들은 페이지 재로딩 없는 탐색을 좋아하기 때문에 "정적"을 무시합니다. 하지만 하이브리드는 이미 이 모든 것을 지원합니다!