在 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 生态系统有无数缺陷:
对于0经验的人来说使用JavaScript工具是极其复杂的。它们都需要 10 个其他工具才能工作,您必须学习所有这些工具才能完成基础知识。
它需要大量的依赖项,并且每个依赖项都有更多的依赖项。 JavaScript 生态系统有一个严重的问题,就是想将最小的问题委托给自己以外的其他人。它带来了前所未有的安全风险,而且他们似乎没有从 PolyfillJs 和 Coa 等事件中学到任何东西。
使用您的自定义代码和您使用的所有库构建 1 个捆绑包,这使得无法在客户端上缓存这些库,以避免在更改自定义代码时再次下载它们。
除了操作 DOM 之外,JavaScript 还很糟糕,我们要不惜一切代价避免在服务器上使用它。具有糟糕的性能、糟糕的内存管理和糟糕的长期寿命。
生态系统比边缘障碍者的幽默更不稳定,JavaScript 开发者无法忍受拥有一个;他们不喜欢,或者他们会从头开始创建自己的东西,你猜怎么着?它将成为新标准,天知道为什么。每隔几个月,编写 React 的方式就会发生变化,或者编写 Next 的方式会发生变化,或者管理状态的方式会发生变化,或者管理表单,或者进行样式设置,总是有一些东西在变化,没有什么永远不会有最低限度的稳定性或标准。它迫使开发人员总是以不同的方式学习相同的东西,而你的代码库在你写完的那一刻就会过时。
对于我们的具体案例,我们还遇到了更多问题:
由于我们住所遇到的所有问题,我们决定采取彻底的措施。我们没有寻找单一的解决方案并尝试使其发挥作用,对其进行一些更改以查看是否能够将正方形装入三角形,而是选择 180° 转向并寻找极端的替代方案,从而避免所有这些问题的根源: JavaScript.
可能和许多了解 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 英寸钢材密封时,打开这扇门真是太好了。
我们可以预见的挑战:
我们在这里探索一个新事物:使用 HTMX 的生产应用程序并不多,而且可能没有一个像我们想要的那么大。我不确定我们在这里做出的决定是否正确,但我确信这比使用 NextJs 或处理 JavaScript 生态系统更好。