在 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 生态系统有无数缺陷：

• 使用JavaScript工具对于0经验的人来说是极其复杂的。它们都需要 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 更好的生态系统。

这就是为什么 HTMX 远远优于 React 和 有关NextJs的详细信息，请关注其他相关文章！

p