与 JSF 相比，React 如何具有更好的性能答案

【问题标题】：How the React have better performance as compare with JSF与 JSF 相比，React 如何具有更好的性能
【发布时间】：2015-08-15 18:32:14
【问题描述】：

我是 React js 的新手。以前我使用 JSF 框架来构建 Web 应用程序。根据我对 JSF 的了解，实际上它会从服务器端生成相应 JSF 标签的 html 代码并将其发送到浏览器并显示它。如果您使用的是 JSF 2，则相应的前端 html 部分也可以通过 AJAX 替换。

我认为我们可以通过 React 框架完成同样的事情。在 react JS 中，您可以从服务器生成客户端 html 代码，它将使用一些 Javascript 引擎（Nashorn Javascript 引擎）在前端呈现。

所以在这两种情况下工作几乎相同（从服务器创建的响应）。现在每天每个人都说 React JS 是一个高性能框架。那么谁能解释它如何提供更好的性能？

我再说一遍，我是 React JS 的新手

【问题讨论】：

请至少阅读更多关于这两个框架的详细信息。 Jsf = full mvc 并且在 reactjs 的 wikipage 上，它声明它，reactjs，只是 v 部分
为什么你认为它会更快？您应该尝试一下并进行一些比较。
@WiredPrairie：他不能。这甚至不像比较苹果和橙子，而是苹果和七道菜的印尼餐。（没有一个更好，只是太不一样了）
@Kukeltje - 这绝对是可比的。你只需要决定成功的指标是什么。最终用户响应时间？浏览器使用的内存？每台服务器的用户数？使用的带宽？等等。
但是你将 reactjs + x + y + z 与 jsf 进行比较，而不是简单的 reactjs

标签： jsf jsf-2 reactjs

【解决方案1】：

在内部，ReactJS 使用一个虚拟 DOM，它将被“映射”到“真实”DOM。在 React 中，您将变量作为 state 或 props 提供给反应组件。 React 使用一种特殊的算法来检测组件 state 或 props 的变化，并且只会通过将虚拟 DOM 与“真实”DOM 同步来重新渲染受影响的部分。

【讨论】：

这个问题的答案如何？
问：谁能解释一下它如何提供更好的性能？ A：访问 DOM 非常慢。 React 使用速度更快的虚拟 DOM。
更好表示比较...在这种情况下与 JSF 相比。 JSF 本身对非 dom 操作几乎没有作用......所以它应该是闪电般的快速（在客户端）。如果您想要更复杂的 ui 组件，这取决于您使用哪些组件以及它们如何操作 dom（PrimeFace 组件很少进行 dom 操作，只有一些小的 css 操作）所以它们也很快（在客户端上）。跨度>
哦，要明确一点，我并不反对 javascript ui 框架，一点也不反对。
React（和任何其他类似的框架）在客户端呈现模板（又名 HTML）。在客户端渲染策略中，服务器只向客户端发送数据位（json）——而不是整个 HTML（来自传统架构）。这通常比传统的服务器端渲染更快，因为： - 你做的页面重新加载更少（由于架构） - 从服务器上卸载了一些工作 - 缓存了更多数据（因为布局和数据现在分开了，布局可以是单独缓存）

【解决方案2】：

JSF 是一个 MVC 框架，它利用服务器端渲染并利用许多标记文件。 React 是一个用于根据 SPA（单页应用程序）模型为应用程序构建图形界面的库。 React 的优势在于它能够非常快速地更新 dom，因为它有一个虚拟的。最终的应用程序可以将所有内容放在一个文件中。正如所说的 React 只是一个库，单独使用它来创建应用程序是没有生产力的。（同样 JSF 只是一个规范，没有 Rich Faces、Prime Faces、Omni Faces、Boots Faces 和 3rd 零件库，很难创建应用程序）

在 SPA 模型中，会话与用户一起存储，后端只是前端调用的一组服务。第一个身份验证调用会生成一个令牌 (JWT)，该令牌存储在客户端，然后将用于调用服务器的（无状态）REST 服务。这就是服务器如何理解它是同一个用户的方式。会话的关键信息存储在客户端，这个事实已经让你明白服务器被解除了任务将所有连接用户的会话保存在内存中。

实际上，当用户在 SPA 应用程序上进行交互时，传输的是数据，而不是标记，因为所有或大部分标记已经在客户端上，这意味着可以很好地节省数据传输。 REST 范式使用 json 来构造要与客户端交换的数据。到达客户端的一个json对象（Javascript Object Notation）是一个字符串，代表一个Javascript对象，后者提供原生函数将 Json 字符串转换为 Javascript 对象，反之亦然。 React 无非就是使用这个对象“去那个特定的点”并更新显示的数据而且速度很快。

JSF 需要在服务器端存在自己的和第三方 Java 库（配置为应用程序服务器的一部分），因此需要配置时间与仅由 javscript 文件组成的可部署的 React 应用程序相比，更高并且具有严格的可扩展性（即使一个就足够了）它只需要像 Nginx 这样的 Web 服务器即可运行。由于配置减少到零，因此很容易理解最后一个解决方案的可扩展性。要进行扩展，只需在内部创建一个包含我们的 React 应用程序的 nginx docker 映像，我们就可以从开发 PC 转移到互联网上的各种云解决方案准备在多个按需实例中复制我们的图像。

【讨论】：

【解决方案3】：

我相信性能完全取决于实现，你可以让 React 和 JSF 做同样的事情。 JSF 出现在 React 之前，而且我认为 React 无论如何都采用了 JSF 的许多概念。自 JSF 1.2 以来，React 还没有在 Web 模板引擎方面取得任何突破。 JSF 是一种模板技术，React 使用 Javascript 重新创建。

对于移动设备，最好先获取完整的 HTML 以节省电池电量... React 和 JSF 都可以使用单页应用程序 (SPA) 来使用 Ajax，并在用户交互时仅更新 DOM 的一部分与应用程序。

对于具有用户交互的页面，JSF 将发送与一个 DOM 直接交互所需的 Javascript，对于 React，它将使用其影子 DOM 和浏览器 DOM。

两者都可以定义自定义 UI 组件，JSF 更快地将渲染的 HTML 直接发送到客户端，而 React 则必须使用客户端计算机 cpu 构建它。

我们可以牺牲性能以获得更快的 UI、更快地更改 UI、软件工程师与脚本编写人员的薪水。对于任何大规模，我更喜欢 JSF，因为在微服务、人工智能、机器学习、Android 和其他具有 JVM 的事物中可重用 Java 库。对于 UI，也许我们可以让脚本编写人员在 React 中创建一个 UI，同时我们专注于更大的解决方案？

【讨论】：