哪种方法更快,Express:服务器端渲染 vs 客户端渲染

13

我想知道的是,你是如何构建你的Web应用程序的?我很困惑应该使用哪种方法来完成我的项目。

已经决定了要选择哪些技术:

1)Node.js和Express作为其框架

2)MongoDB

3)React+ Flux

但现在的问题是,我应该使用方法(A)还是方法(B)

方法(A)- 服务器端渲染HTML

app.get('/users/', function(request, respond) {
     var user = "Jack";
     respond.render("user", { user: user });
});

方法(B) - 用于HTML的客户端渲染

 app.get('/users/', function(request, respond){ 
       var user = "Jack";
       respond.json({ user: user });
    });

方法A将从服务器渲染HTML以及数据。

方法B只会响应客户端所需的数据,即React.js,以便它可以操作数据。

我的问题是,我应该使用哪种方法?大多数创业公司使用哪种方法?

谢谢。


如果你要使用React构建应用程序,你应该遵循Flux模式。 - Hyung Cho
糟糕,没有看到标题上的Express。对Express不太熟悉,可能会有所不同。 - Hyung Cho
一般来说,在客户端进行更多的渲染并减少自己服务器上的操作是首选。但是,客户端只能渲染有限的内容,如果不指定创业公司的类型,很难回答您的问题关于大多数创业公司会做些什么。 - user2263572
如果您进行客户端渲染,那么您需要为搜索引擎进行服务器端渲染的并行路径(相同内容)。 - jfriend00
客户端渲染更具可扩展性(因为它使用客户端 CPU 来处理部分工作,并且可以更有效地进行模板缓存),并且在慢速链接上可能更快(下载内容较少)。如果服务器速度快、负载轻且链接速度快,服务器端渲染可能会与客户端渲染竞争速度。 - jfriend00
3个回答

6

这不是非此即彼的问题。

React是一个客户端框架。你必须在客户端上进行渲染。问题是是否要在服务器端进行渲染,除了在客户端上进行渲染。

答案是什么?如果可以的话,是的!

通过在服务器端进行渲染,您将获得SEO好处和初始性能提升。但您仍然需要进行相同的客户端渲染。

我建议搜索“同构React”并阅读一些文章。这是有关该主题的一篇文章。 http://www.smashingmagazine.com/2015/04/react-to-the-future-with-isomorphic-apps/


请注意:关于服务器端渲染React的“同构React”现在被称为“通用React”。 - Sgnl

5

嗯,这真的取决于你对现代网络的看法以及你愿意做什么。

你会更喜欢让用户等待,同时显示加载器,而数据是异步加载的,还是会尽可能让用户忙碌?

以下是不同的文章,将帮助您清晰思考,并了解通过进行服务器端渲染可以获得的不同优势,而客户端渲染则存在多个问题。

您可以查看Twitter博客上的这篇文章,他们通过将渲染移到服务器上,将初始页面加载时间提高了五分之一:

https://blog.twitter.com/2012/improving-performance-on-twittercom

这是来自airbnb的另一篇文章,描述了客户端渲染本身可能存在的问题:

http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/

还有一篇有趣的文章讨论了客户端/服务器端渲染,引发了关于何时使用/不使用服务器端或客户端渲染以及为什么的辩论:

https://ponyfoo.com/articles/stop-breaking-the-web

最后,我可以给您提供两个更加专注于React的链接,并描述服务器端渲染在您的情况下应该如何有帮助:

https://www.terlici.com/2015/03/18/fast-react-loading-server-rendering.html

http://reactjsnews.com/isomorphic-javascript-with-react-node/

现在,关于你应该做什么,我认为这取决于你确切需要做什么,但基本上,你可以同时进行客户端和服务器端的操作,以获得最佳用户体验。这个概念被称为“同构JavaScript”,并且在这些日子里越来越受欢迎。

你所提出的观点可能会有一个反驳意见:抛弃JSPs:将LinkedIn迁移到dust.js客户端模板。你的性能也取决于你如何实现客户端模板。 - jfriend00
是的,我猜是这样的,根据你可以实际实现客户端渲染或“同构”应用程序的许多不同方式。 - schankam
我阅读了您分享的大多数链接,这确实让我对两者有了更开阔的认识。但是,既然服务器端渲染速度快,如果我想进军移动端,是否需要复制我的API代码? - Jack Moscovi
我不确定理解你的问题;你是在谈论移动混合应用吗?还是原生的iOS / Android应用程序? - schankam

4
最简单的架构是仅在服务器上进行动态html渲染,没有Ajax,并且对于几乎任何客户端点击都会请求一个新的HTML页面。这是传统方法,有利有弊。
接下来最简单的是向客户端提供完全静态的html+js+css(即您的React应用程序),并使用XMLHttpRequest调用webservices获取所需的数据(即您的B方法)。
最复杂但理想的方法(从性能和SEO角度考虑)是构建一个支持两种方法的“同构”应用程序。其思想是服务器进行所有必要的WS调用,以呈现用户访问的初始页面(可能是应用程序的深度链接部分),有点像选项A,但使用React进行渲染,然后将控制权传递给客户机进行DOM更新。这随后允许通过Web服务调用快速增量更新页面,因为用户互动(例如,就像B一样)。此时,不同“页面”之间的导航涉及使用History API使其看起来像您正在更改页面,实际上只是使用Web服务操作当前页面。但如果您刷新了浏览器,则服务器会在将控制权再次传递给客户端React之前发送回当前页面的完整HTML。有许多使用支持服务器端渲染的不同Flux版本的React + Flux + Node示例可在网上找到此方法。
是否值得采用这种方法取决于您的情况。开始使用B方法(您可以在移动应用程序和网站之间共享HTTP API),但使用支持服务器端渲染的Flux架构并将其记在心中可能是有道理的。这样,如果需要改善初始页面加载的性能,则有手段可以实现它。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接