对于服务器端渲染，我发现了两种方法：
NextJs在GitHub上拥有很多明星，并且拥有一个很棒的社区，但是另一种方法（无头的chrome浏览器）看起来更干净，需要几乎零配置才能工作。
有没有一个有经验的人可以和他们一起工作？
每个人的主要利弊是什么？
答案 0 :(得分：3)
（前段时间我一直在为这个难题而苦苦挣扎，并想与大家分享一些我的个人观点）
有用的资料来源：Server-side vs client-side rendering in React apps，Next.js — React Server Side Rendering Done Right。
SEO的实际价值无与伦比，在撰写本文时，Google可以正确地抓取SPA（insights & analysis），而对于自然搜索而言，它通常已被认为是足够的，但是对于社交媒体来说，摘录如下内容是不可接受的链接不会对您的业务造成不利影响。
性能案例是有限的-React Apps（通常是SPA）被有效地存储在客户端上。首次运行通常是：安装脱机Web worker，将大量缓存加载到浏览器中。使得这种优势几乎仅在用户第一次加载网站的情况下才可行。
资源的可用性或它的优势与应用程序架构紧密相关，在某些情况下，通过缓存执行性能可能比完全涉及服务器要好。
JS的不断发展的特性正在快速推动这条线，因为这些框架需要跟上发展的步伐。这暗示了在一段时间内落后于其技术最佳功能的事实。
一个关键的例子是在 React-Router v4更新之后进行的炒作，它一炮而红，但在社区压力很大的情况下，它踩在NextJS Use with React Router 4 #1632之类的框架上，作为开发人员，被迫使用我们提供的架构。
这意味着要减少CRA（通常是React标准），而要像NextJS一样：
next/head，Document，<layout>，@zeit/next-css，@zeit/next-sass，styled-jsx，static async getInitialProps ()模式，next-redux-wrapper，next-redux-saga，<Link prefetch>来自next/link，/pages/开始路由，从/static/提供文件，等等。并使补丁的“感觉”像成熟的CRA一样起作用。
另一个失败点是标准no-SSR应用程序很难移植到像NextJS / Gatsby这样的SSR解决方案中，后者具有自己的规则和体系结构。在一开始就强迫做出这样的决定。
使您的应用程序不受SSR应用程序内解决方案的限制。 SPA站点假定使用API而不在服务器上呈现，因此许多模式/程序包没有从头准备好进行SSR，并且可能会污染您的标准代码库。
当您寻求SEO / SEM时，使用SSR为您的应用服务可能不是最佳的优化方法，这是非常简单明了的解决方案。
自动工具（如您由 ren-snap 提供的）可能会遇到一些Caveats，包括正确地快照网站正确HTML输出的问题（例如，对于SEO而言最有价值）。
尽管纯粹针对SEO的SSR方法没有什么问题，但是有一个合理的事实，即在不久的将来，任何爬网程序都将朝着SPA的最佳爬网性发展，因此，一段时间后，完整的SSR解决方案可能不是一个加分项。
>