무엇이 나은가? nextjs / reactjs / nuxtjs / vuejs / ssr / csr /
server-side rendering, client-side rendering
next.js 인가 reactjs 인가에 대한 고민이 있어서 몇가지 사항을 정리해 본다.
다음 글에서, server-side rendering, client-side rendering 의 정도에 따라 어떤 면이 유리한지를 정리해 준다.
어느쪽이 나을까? 일관성을 위해서, 하나의 방법으로 모든 page 에 사용하는 것이 좋아보이긴 한다.
개인적으로 선호하는 쪽은 CSRB(Client Side Rendering with Boostrapped Data) 이다. 다만 이경우, 조금은 복잡한 행위가 필요하다. server side 에서 template engine 을 다루고, client side 에서 react 관련 작업을 따로 해야한다. 그래서 결과적으로 이 방법은 대부분의 경우 좋은 방법이 아닐 수 있다.
next.js vs react.js
다음 글은 Next.js 와 React.js 에 대한 비교 글이다. 여기서는 비교적 간단한 결론을 내리게 해준다. 대체로 search engine 에 노출되는 것이 필요한 경우 static page 가 필요하게 되는데, 이런 경우 Next.js 를 사용하라고 한다.
React.js 로 next.js 를 사용하지 않고, 비슷한 효과를 얻는 방법이 있지 않을까 찾아봤지만, CSRB 외에 특별한 방법을 찾긴 힘들었다.
SSR 을 사용하지 않는 Nextjs 방법에 대한 글도 있다.
SSG vs SSR
from: 10 Web Development Trends in 2023
SSR has been competing with static site generation (SSG) for quite a while for the perfect performance (see Next.js vs Gatsby.js) even though both patterns serve entirely different purposes. While the latter pattern is used for static content (e.g. websites like a blog), the former is used for dynamic content (e.g. web applications). If SEO is relevant, both SSR and SSG can make sense. However, with the requirement of highly dynamic content or user-centered content with authentication, developers cannot choose SSG (once build before deploy, therefore static) and have to decide between SSR (on-demand build per request with individual data on the server) or CSR (on-demand fetching of individual data on the client) these days.
SSR은 두 패턴이 완전히 다른 용도로 사용되지만 완벽한 성능을 위해 꽤 오랫동안 정적 사이트 생성(SSG)과 경쟁해 왔습니다(Next.js vs Gatsby.js 참조). 후자의 패턴은 정적 콘텐츠(예: 블로그와 같은 웹사이트)에 사용되는 반면, 전자는 동적 콘텐츠(예: 웹 애플리케이션)에 사용됩니다. SEO와 관련해선 SSR과 SSG 모두 의미가 있을 수 있다. 그러나 매우 동적인 콘텐츠나 인증이 필요한 사용자 중심 콘텐츠가 필요한 경우 개발자는 SSG(배포 전에 한 번 빌드하기에 static)를 선택할 수 없으며, 요즘에는 SSR(서버의 개별 데이터로 요청에 따라 온디맨드 빌드) 또는 CSR(클라이언트에서 개별 데이터의 온디맨드 페칭) 중에서 결정해야 한다.
댓글 없음:
댓글 쓰기