在 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 生态系统更好。
以上就是为什么 HTMX 远远优于 React 和 NextJs的详细内容，更多请关注【创想鸟】其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至253000106@qq.com举报，一经查实，本站将立刻删除。
发布者：PHP中文网，转转请注明出处：https://www.chuangxiangniao.com/p/2673683.html
