为什么 HTMX 远远优于 React 和 NextJs

在 Anuntech 上，我们面临创建 ERP 的挑战，对于那些已经使用过 ERP 的人来说，知道 ERP 可能是创建（和使用，上帝保佑 SAP 用户）更复杂的软件类型之一。

为了避免使用的复杂性，我们想要类似于 PlayStore 的东西：你有无限的模块可以启用，你可以选择你需要的模块或选择一个“业务模板”来满足你的需求，我们的目标是中间，来到了第一个问题：选择前端工具。

反应

所以，要创建任何网站，我们都需要一个框架，每个人都知道这个不容置疑的真理。和其他人一样，第一个出现的框架是 React，它是十亿个 JavaScript 框架中最常用、最受喜爱、最令人难以置信的框架。

React 很好，它给了我们：

• 创建组件并重用它们的能力，保持标准并避免重复

• 创建高交互式前端的能力（现在我们的表单可以进行内联验证以了解您的电子邮件是否有@！）

• 通过在客户端上运行所有内容来降低服务器成本的方法（对于每个初创公司都非常重要）

但是react本身有很多问题：

• 它将所有东西捆绑在一起，对于像 Anuntech 这样的产品，将有数百种不同的东西，捆绑包的大小将与 AAA 游戏相同。

• 它很重af，使用虚拟DOM来创建和操作东西，对于弱电脑来说有什么可怕的，你猜怎么着？我们所有的客户都有弱电脑。

所以我们必须多思考一下：如果我们不能使用 React，我们的下一个选择是什么？

下一个

当然，React 的自然进化，Next！，React 已经很完美了，但是有了 Next，它就达到了另一个完美程度！没有办法不行：

• 接下来分别捆绑每个页面，每个页面仅具有所需的依赖项，这将使捆绑包保持在可接受的大小

• 它仍然保留了 React 拥有的所有好东西：高交互前端

• 对图片、视频等有很多内置的优化

但是 Next 的问题比 React 还要多：

• 我们失去了不花钱购买服务器的优势，现在我们需要一台服务器来运行我们的前端

• 它仍然很重af，它使用 React 来构建东西，最糟糕的是，它也在服务器上构建

• 知道我们有客户端和服务器，我们必须让用户同时登录，并且它必须能够在服务器和客户端上对我们的 API 发出经过身份验证的请求，这大大增加了复杂性。

所以我们开始意识到问题不是框架，而是整个 JavaScript 生态系统。

对抗 JavaScript 的战争

JavaScript 生态系统有无数缺陷：

• 对于0经验的人来说使用JavaScript工具是极其复杂的。它们都需要 10 个其他工具才能工作，您必须学习所有这些工具才能完成基础知识。

  • 如果我们继续使用 Next，雇用前端开发人员，他们将被要求（或者我们将被要求投入时间和金钱培训他们）了解：HTML、CSS、JavaScript、TypeScript、Tailwind、React、NextJs、Hookform（或者他们从现在开始 5 分钟后将使用的任何库），React 状态管理，服务器组件，全新的很棒的 React 编写方式将在下个月改变，全新的下一步方式将在下个月改变，等等。列表永无止境，所有这些都是为了基础知识。

• 它需要大量的依赖项，并且每个依赖项都有更多的依赖项。 JavaScript 生态系统有一个严重的问题，就是想将最小的问题委托给自己以外的其他人。它带来了前所未有的安全风险，而且他们似乎没有从 PolyfillJs 和 Coa 等事件中学到任何东西。

• 使用您的自定义代码和您使用的所有库构建 1 个捆绑包，这使得无法在客户端上缓存这些库，以避免在更改自定义代码时再次下载它们。

• 除了操作 DOM 之外，JavaScript 还很糟糕，我们要不惜一切代价避免在服务器上使用它。具有糟糕的性能、糟糕的内存管理和糟糕的长期寿命。

• 生态系统比边缘障碍者的幽默更不稳定，JavaScript 开发者无法忍受拥有一个；他们不喜欢，或者他们会从头开始创建自己的东西，你猜怎么着？它将成为新标准，天知道为什么。每隔几个月，编写 React 的方式就会发生变化，或者编写 Next 的方式会发生变化，或者管理状态的方式会发生变化，或者管理表单，或者进行样式设置，总是有一些东西在变化，没有什么永远不会有最低限度的稳定性或标准。它迫使开发人员总是以不同的方式学习相同的东西，而你的代码库在你写完的那一刻就会过时。

对于我们的具体案例，我们还遇到了更多问题：

• 在我们的例子中，由于我们有 API 的微服务，因此使用 Next/React 我们必须维护 gRPC（用于服务器-服务器通信）和 REST（用于客户端-服务器通信），这使得后端团队维护 2 个交付系统，2 API 文档（.proto 和 openapi 规范），并使服务在互联网上可用，以便客户端直接访问它们，这也使得我们必须验证每个服务的用户身份验证和授权。

由于我们住所遇到的所有问题，我们决定采取彻底的措施。我们没有寻找单一的解决方案并尝试使其发挥作用，对其进行一些更改以查看是否能够将正方形装入三角形，而是选择 180° 转向并寻找极端的替代方案，从而避免所有这些问题的根源: JavaScript.

HTMX

可能和许多了解 HTMX 的人一样，我首先是从 Primeagen 听说它的。起初，我讨厌它。我的第一反应是“很好，又回到了 PHP”，但在对解决方案进行了一些审查并了解了更多关于这个想法之后，我发现 HTMX 正是我们正在寻找的东西。

HTMX 解决了我们所有的问题，并给了我们更多的力量：

• 就是SSR，解决了bundle-size的问题。

• 它为最重要的部分（部分页面重新加载）提供交互，并允许我们为它无法执行的操作（例如验证表单字段）创建自己的自定义基本脚本。

• 允许我们选择我们想要运行它的语言，我们不再停留在 JavaScript 上。

• 有 0 个依赖项。

• 只有 1 个 JavaScript 文件，非常容易理解并且有详细的文档。如果维护者决定不再维护它，我们可以自己维护它，这与 React / Next 相反，我们被他们困住了，他们决定去哪里。

最终的解决方案

因此，由于我们已经在 Golang 中编写后端服务，因此我们选择用 Golang + HTMX + Templ 编写前端，并使用 Tailwind 和 DaisyUI 进行样式设计。主要原因如下：

• 由于后端团队已经必须在服务之间进行通信，因此他们已经为每个公开“API 路由”的服务维护了一个库，这使得前端与服务集成变得更加容易：只需使用库而不是从头开始构建集成。

• “服务器上的 JavaScript”的卖点也可以用在这里：前端和后端使用一种语言可以让您的开发人员成为全栈人员，并且在系统的两个部分上工作时遇到的麻烦更少（这是一个天大的谎言使用 TypeScript，顺便说一句）

• 拥有一种语言的好处也会影响 DevOps 团队：使用 1 种语言，只需配置 1 个开发环境（以及 1 个文档来编写如何配置所需的一切）、1 个需要维护的管道、1 种需要配置的机器运行服务器等等。

• 仅使用 SSR，几乎为零的 JavaScript，并且客户端没有状态管理，自动化测试变得更容易编写和可靠：只需调用路由并检查返回的文本（HTML）是否正确。

• Golang 比 NextJs 服务器更快、更轻量。它允许开发人员拥有较弱的电脑而不损失性能并且必须等待 5 分钟才能启动服务器并渲染单个页面，这使得公司可以购买更便宜的电脑并节省很多钱。

• HTMX 允许我们在 lambda 中运行东西，这是我们目前不做的事情，但是，嘿，在使用 NextJs 时，当用混凝土和 3 英寸钢材密封时，打开这扇门真是太好了。

我们可以预见的挑战：

• 古老的 ID 重复：太多的组件可以生成具有相同 ID 的组件，这使得它很容易更改不应该更改的内容。我们计划避免这种情况，为 ID 定义一个好的命名模式。

结论

我们在这里探索一个新事物：使用 HTMX 的生产应用程序并不多，而且可能没有一个像我们想要的那么大。我不确定我们在这里做出的决定是否正确，但我确信这比使用 NextJs 或处理 JavaScript 生态系统更好。