JSF全称 Java-Server-Faces，是一种被很多人低估的Web技术。我想知道为什么会这样。如果您仍然使用 JSF，您真的疯了吗？我不这么认为，我会分享我的一些想法。 

规范

首先，JSF 是一种规范，与通常与 JSF 进行比较的所有其他技术相比，它具有重要的优势。该规范是一个开放的过程，多年来伴随着许多开发人员为 Web 应用程序定义了一个通用的可靠标准。这个规范过程最近在 Eclipse Foundation 中进行，它制定了遵循非常高质量标准的规则。这是最大的优势之一，因为它保证您的 Web 应用程序构建在坚实的核心之上。当然，其他 Web 框架也有大型社区，但这些社区通常由一家并不总是考虑开发人员的公司代表。来自谷歌的 Angular 只是一个例子。

基于服务器的框架

但是回到 JSF。为什么 JSF 有时会被嘲笑为过时的技术？我个人是在 2001 年早期开始使用 JSF 的。所以它显然是一项古老的技术。我也是一名老开发人员 ;-)。与此同时，许多其他 Web 框架也在不断发展。其中许多基于 JavaScript，并遵循在浏览器中运行的单页范式 (SPA)。这个想法是将应用程序逻辑移动到浏览器中以更快地获得应用程序。这个想法出现的时候并不是每个人都对 JSF 感到满意，而 JavaScript 开始流行了。Java Server Faces——顾名思义——相反，是一个基于服务器的框架。这意味着应用程序逻辑在服务器上执行。这就是我们有很大不同的地方。当时，减少服务器负载是一个有效的论据。而且当然，这在今天仍然应该是一个可取的目标。但是使用它作为反对 JSF 的论点的人通常是那些对无服务器函数赞不绝口的人。因此，我认为我们今天不应该将基于服务器的框架视为愚蠢的想法。

自包含微服务

基于服务器的 Web 框架提供了一些优势。这样，应用逻辑和业务逻辑就可以很容易地耦合起来。这是在 Jakarta EE 中实现的，主要是通过 CDI、EJB 和 JPA。这些技术是 JSF 组件的后端。Jakarta EE 提供了对层分离的非常清晰的理解，而 JSF 无缝地融入了这个概念。服务器端实现还向客户端隐藏应用程序详细信息。相比之下，在 JavaScript SPA 中，大部分应用程序逻辑通常在浏览器中不受保护，这在某些情况下可能会带来安全风险。

因此，在服务器端呈现应用程序逻辑使负责后端和前端部分的开发人员更容易。这导致在许多情况下可以更快地开发应用程序。从微服务架构的角度来看，一个JSF应用对应的是Self-Contained Services的原则。这是微服务架构中常用的一种模式。

简单

由于 JSF 通常被认为是复杂和笨拙的，我最近想知道这是否真的如此。我将我的一个 Vue.js SPA 迁移到 JSF 4.0 并比较了生成代码的复杂性。所以最后，我想用一个例子来展示 JSF 的简单性。（注意：我这里不比较 JavaScript 代码和 Java）

在 JavaScript 框架中，您通常通过附加标记将 HTML 标记绑定到某些代码。

Your Website is: {{api}}

SPA 框架解析标签 (v-model) 并放置来自用 JavaScript 编写的模型的正确值。它还绑定输入字段以跟踪模型中的更改。

JSF 对应物看起来没有太大区别：

Your Website is: 

在这里，您还将模型值绑定到输入字段或输出文本。但是代码是在服务器端用Java执行的，这往往等于你的后端代码是用Java写的，对于SPA来说也是如此。

开箱即用的 JavaScript Web 框架使用 Ajax。所以你通常不需要关心它。在上面的例子中，span，当输入的值改变时，标签会自动更新。

在 JSF 中，您也可以使用 Ajax，但是您可以更好地控制它的行为方式。您可以简单地用 f:ajax 标记将页面的一部分括起来以获得相同的行为：

Your Website is: 

另一个例子是链接。在 JavaScript 框架中，您再次使用一种标记来在用户单击元素时启动渲染生命周期：

Search

在您的showSectionJavaScript 代码中实现一些业务逻辑，并负责处理数据和更改布局。

JSF 并没有太大的不同：

Search

该h:link标记从名为“search.xhtml”的后端加载一个包含新布局的新页面。所有模型绑定都在后台后台处理。对于用户来说，行为没有区别。

因此，正如您从标记中看到的那样，没有太大区别，并且编写 JSF 前端并不像在基于 JavaScript 的 Web 框架中那样复杂。

我个人的结论是，JSF 为我在框架内编写代码提供了更清晰、更一致的概念。后端逻辑和应用程序设计结合在一种技术中，形成了一种模式，也称为自包含微服务。