<分区>
最近，我的公司决定重建一个企业门户网站，全局各地的人们都可以使用该门户网站来注册产品以延长保修期。他们提出了 J2EE(spring MVC)和 Oracle 作为业务层的技术堆栈，并决定使用 JSF(java server faces)来设计前端的东西(用户界面)我是前端工程师，想要appose JSF 因为它会减少我对生成的标记的控制，而且 JSF 会在页面中注入(inject)/生成不必要的标记，这将成为浏览器的不健康食物。此外，实现浏览器兼容性也将变得困难，因为我无法控制生成的标记很难应用正确的 CSS 行为。也不可能使用像流体布局、无表格布局这样的概念。
所有这些都会导致糟糕的用户体验。我的想法是使用手工编码的 HTML 开发 UI，然后将这些 .html 文件转换为 JSP，并将这些 JSP 插入 Spring MVC 架构。
说了这么多，我需要提出一个提案，证明在 UI 层用 HTML 替换 JSF 是合理的，您的输入/想法和建议将很有值(value)，请回信。
此外，我不认为 XHTML 是其他选项，它必须是 HTML？让我知道您的想法以及是什么让您这样想？
感谢您的光临。如果阅读所有这些占用了您很多时间，我深表歉意。
当您使用具有“纯”JSF 组件的老式 JSF 1.0/1.1 API 时，您所说的是正确的。没有可以用来表示 HTML 的内置组件 <div>元素(以便您可以以语义方式完成一般页面布局)。此外，在 JSF 页面中嵌入“纯”HTML 很痛苦，因为它在 JSF 组件树之外和之前呈现。您必须将纯 HTML 放入 <f:verbatim>到处都是标签。纯粹主义者和无意识者或多或少被迫使用 <h:panelGrid> (它呈现一个 <table> )来定位页面中的元素。
除此之外，在早期的 JSF 时代，Netbeans 附带了一个内置的可视化 JSF 编辑器，使您能够可视化地拖放和绑定(bind) JSF 组件，而无需编写任何代码行。这显然会生成很多乍一看不必要且无法维护的代码，并且元素的像素精确定位是通过 <h:panelGrid> 实现的“幕后”。 .考虑到可维护性和 Web 语义，这些类型的 JSF 应用程序完全是一场灾难。
在前端开发方面，您会听到的关于 JSF 的大多数负面故事都与此相关。从那时起，大多数 JSF 用户/观察者/咆哮者目前仍然盲目地关注这个，因为他们有过糟糕的体验和/或他们认为 JSF 如今仍然是一样的和/或他们将可视化编辑器视为 JSF 的一部分，而它“只是”另一个(坏的)工具。此外，大多数说“JSF 糟透了”的人通常是那些开始使用可视化/拖放式编辑器的人，他们对幕后发生的事情(尤其是 Servlet API!)没有任何扎实的背景知识。
自从 JSF 1.2(已经 4 年多以前发布)以来，<h:panelGroup>组件有一个额外的属性:layout="block"这将让它(最终)呈现一个完全有值(value)的 HTML <div>元素，这样您就可以仅使用 JSF 组件带来更语义化的布局。但不仅如此，JSF 1.2 还带有一个改进的 View 处理程序，它可以将纯 HTML 嵌入到其他 JSF 组件中，而无需麻烦 <f:verbatim>。标签。你可以很好地把 <div>在不增加冗长的情况下围绕您想要的元素。
尽管这是一项重大改进，但标准 JSF 实现仍然存在另外两个主要(但不直接与 UI 相关)问题:1) 请求之间的状态管理很难在不获取 session 范围的情况下进行(考虑保留相同的范围)表格和下拉列表中的数据以及例如 rendered 属性的条件)； 2) 一切都通过 POST，你不能很好地通过 GET 调用 JSFish 操作。
自从 JSF 2.0 以来，几乎已经 1 岁了，这些问题被一个新的范围、 View 范围和一组新的 GET 操作组件所覆盖。此外，JSP 被 Facelets 取代为默认 View 技术。 Facelets 极大地简化了模板化和创建复合组件，而无需求助于原始 Java 代码和/或自定义组件/渲染器。即使它是基于 XHTML 的，它也可以完美地呈现 HTML5 有效响应，只需 <!DOCTYPE html> . XHTML 就在那里，因为 Facelets 在幕后使用基于 XML 的工具来生成 (X)HTML 输出。基于 XHTML 的模板并不意味着它只能发出 XHTML/XML。
总而言之，当您使用 JSF 1.2 或更新版本时，您的标记问题不是问题，而且 XHTML (Facelets) 也不应该成为问题，因为它可以完美呈现 HTML5 有效标记。