我赌 React 输了（我一点也不后悔）

返回 2018 年，我做了两个命运攸关的下定决心：优先选择选用Lit[1]再次构筑 authentik，而并非 React。

我们经常认为控制技术重大决策主要是控制技术上的，但那些重大决策的最小不良后果源自于控制技术的选用和选用形式，而并非控制技术这类。

React 是这种。

在这首诗中，我将说明为何作出那个下定决心，它造成了什么样效用，又有什么样效用不令人满意，和为何最后我并不懊悔。重点项目并非劝服你全力支持或抵制 React，也并非对 Web 架构进行争辩，而要引导探讨孵化器民营企业须要作出的优先选择。

当我提及孵化器民营企业时，我指的并非那些依然自称孵化器民营企业或是保有少于金融投资的资本金的歌星民营企业，我指的是像我这种的人：兼职开发人员，致力将两个畅销的项目打导致一间公司。

React vs. Lit：两个意味深长的发展史和这场断然的重大胜利[2]

React 首度正式发布于 2013 年，当我已经开始构筑起初的开放源码工程项目，最后正式成为 Authentik Security 时，React 是两个未知的优先选择，但并不像那时那样正式成为预设优先选择。

2015 年，Netflix 和 Airbnb 已经开始选用 React。翌年，正式发布了用作 iOS 的 Reactive Native，后又正式发布了用作 Android 的 React Native。到 2018 年，也是我作出那个下定决心的那两年，28.3%的开发人员已经开始选用 React。

(源自 2018 年的统计数据)

React 显得愈来愈受欢迎，但并并非两个显著的优先选择，不能没人即使不优先选择 React 而深感吃惊。总之，那时的情形全然相同了。

2022 年 StackOverflow 的科学研究[3]表明，44.31%的开发人员那时选用 React。

(源自 2022 年的统计数据)

为了

了解 Lit 的畅销程度，我不得不将搜索范围缩小到 JavaScript 开发人员。根据2022 年 JavaScript 状况调查[4]，Lit 仅被 6%的 JS 开发人员选用。

这并不仅仅是畅销度的差异：

我不能说那个成功是不可预测的，但它也并不显著。

那些动态遵循良性循环：React 显得愈来愈畅销，愈来愈多的开发者想要尝试它；愈来愈多的开发人员尝试它，愈来愈多的开发人员显得熟练，并用它构筑愈来愈多的东西；愈来愈多的东西选用 React 构筑，愈来愈多的公司须要 React 技能，需求上升，供应也随之增加。

那些数字在控制技术和商业环境中都造成了实际不良后果。

两个架构、工具或语言越畅销，我们就越了解如何有效选用它，和它最有可能失败的形式。

Mozilla 工程副总裁 Dan McKinley 在一篇文章[9]中写道：“在优先选择控制技术时，你既有未知的未知，也有未知的未知。”他建议优先选择无聊的控制技术（React 可以说已经正式成为这种的控制技术），即使“那些控制技术的能力是被充分理解的。但更重要的是，它们的失败模式也是被充分理解的。”

随着一种控制技术的流行度提高，选用它的民营企业从更大的人才库中获益。就像找到 Python 开发人员比找到 COBOL 开发人员更容易那样，找到有 React 经验的开发人员比找到有 Lit 经验的开发人员更容易。

具有讽刺意味的是，我对这种权衡非常了解，即使在优先选择 Python 作为 Authentik 的主要编程语言时，我基本上作出了相反的下定决心。优先选择 Python 确实使得招聘显得更容易，但同时它也带来了一些性能限制，我们不得不采取措施来缓解和解决那些问题。

孵化器公司就像是充满智慧的赌局[10]

安德里森·霍洛维茨（Andreesen Horowitz）、红杉资本（Sequoia）和阿塞尔（Accel）的博客文章都指向两个目标：减少孵化器公司成功所归功于幸运赌博的程度。

这很有道理：如果创立和建设孵化器公司更像是一门可重复的科学，金融投资基金就会更安全。但我们并不总是从逻辑上深入思考那个观点。

广义上讲，孵化器公司经常因为对控制技术和消费趋势的准确（事后看来如此）的赌注而成功，但孵化器公司还有许多其他赌注——人员、编程语言、商业模式，总之还有架构。

然而，回顾过去时，我们往往过多地将功劳归于那些作出正确赌注的人。我并并非要剥夺任何人的功绩，而要再次界定人们已经开始作出的重大决策类型，以免让当下和未来的创业者深感困惑：那些优先选择总是带有一定的赌注成分。

为何我优先选择了 Lit[11]

那个重大决策的最重要背景在于：Authentik Security 那时已经是两个团队和一间公司了，但在 2018 年，Authentik Security 只有我，而 Authentik Security 是那个名为 authentik 的开放源码工程项目。

我当时是把 authentik 作为一项爱好进行开发的，所有的工作都是在我兼职工作之外完成的。在那个时期，一些限制问题凸显出来：

当时，雇佣潜力并并非我考虑的因素：我只想构筑和正式发布产品。

一已经开始，该工程项目全然依赖服务器端渲染。选用 Django，我有一些工具可用作构筑提交和表明统计数据的表单，和添加分页、表格和排序功能。

但随后路线图上出现了一些功能，

这让这种设置显得复杂起来。例如，我希望用户能够通过按钮按下刷新统计数据，无需再次加载页面进行搜索。

2020 年末，我已经开始迁移到 Lit，已经意识到前方有很多工作要做。那时候经常出现这种的情形，当引入新功能时，它们会在用户界面中，但在 API 中却没有，这往往是即使疏忽而导致的。这使得在不知道最后需求的情形下，保持 API 更新正式成为了这场不断进行的猫捉老鼠游戏。

然后，在 2022 年底，得到了 Open Core Ventures[12] 的全力支持，authentik 正式成为了 Authentik Security[13]。而且，产品路线图再次提出了一些要求。

灵活性是 authentik 的两个早期缺陷。即使我们依赖于服务器端渲染，我们也依赖于浏览器，也使我们的用户依赖于浏览器。但我们一直想要超越这一点儿，实现客户端和服务器之间的动态交互。

因此，灵活性正式成为了主要目标，也是我评估当时可用的库和架构的主要标准。

优先选择 Lit 而非 React 的三个原因[14]

我优先选择 Lit 的原因有三个，所有那些因素都强调了灵活性那个目标。

Lit 和 React 是相同的东西[17]

到目前为止，我一直避免探讨 Lit 和 React 最重要的比较形式——Lit 是用作构筑网页组件的一套工具，而 React 是两个网页架构。

随着 React 和网页架构的普及，这种比较往往被低估。如果你只将架构与其他架构进行比较，你就会陷入两个假设你真的须要两个架构的思维模式中。在比较利弊时，你可能会错过一整个由相同方法提供的利弊世界。

上面我描述的优势并并非 Lit 比 React 更好的结果，而要即使 Lit 提供的方法比 React 更适合满足我的需求（至少在当时如此）。

通过 Lit，我们可以在服务器端呈现主页，但服务器呈现的 HTML 将包含具有相同功能的网页组件。这为我们提供了一条非常相同的迁移路径，允许我们逐步进行迁移。

举例来说，如果我们想要为表格添加两个新组件，我们可以让服务器在不太改变服务器端的情形下返回它。但在客户端，我们可以逐步添加逻辑、分页和其他功能。在我们选用 Lit 之前，这是不可行的，而 Lit 则使这种迁移路径比 React 更加可行。

权衡总是存在的[18]

在 HackerNews 上浏览，你会发现许多关于架构的探讨，其中有些讨论是紧张或激烈的。有些人会认真权衡成本和收益，但很多人会忠诚于某个品牌，为一种架构辩护并贬低其他所有架构。

我的工程师同伴们，别再问“那个流程好还是不好？”，而要问 “它是否适合我的情形？” – Jocelyn Goldfein[19]（前 Facebook 和 VMware 工程主管）

从我在优先选择 Lit 和 React 之间作出重大决策并接受不良后果的经验中，我得出了两个结论：那些重大决策始终是权衡的结果。

那个问题的棘手之处在于确定你的情形比看起来更加困难。成长型民营企业和大型民营企业可以依靠更好的模式匹配比真正的孵化器民营企业更加可靠。每个孵化器民营企业，就像不幸的家庭[20]，都有自己相同的不幸之处。

当我定义我们的情形时，有三个因素显得最为重要：

记住，在起初的时候，我独自一人在工作之余的时间里开发两个开放源码爱好工程项目。特别是考虑到我已经完成的工作和我缺乏前端工程技能，构筑和正式发布比再次已经开始更重要。

在这种情形下，权衡是我能够更快地构筑和交付 authentik，并使其更快地交给用户选用，但那时我错过了与 React 这种两个充满活力的社区合作所带来的好处。

对于 Lit，我们可以更轻松、更实际地进行迁移，逐步迁移更多内容，而并非再次构筑或一次性全然迁移。回顾过去，我不知道自己是否能够完成这种一次重大的呈现形式转变，如果我能够完成，我也不知道那时是否已经完成。

因此，是的，寻找和雇佣具有 Lit 经验的开发人员比寻找和雇佣具有 React 经验的开发人员更加困难。雇佣开发人员本来是众所周知的困难事情，而我们却使它更加困难。然而，由于 Lit 用户群体较小的优势在于，即使在罕见的情形下我们找到了两个 Lit 开发人员，他们往往对我们优先选择 Lit 的原因非常热情。

然而，即使在这种权衡中，依然存在着另两个权衡：React 如此畅销且易于上手，以至于您必须小心优先选择真正优秀的开发人员。而由于 Lit 较不流行，因此其信噪比更好。

由于灵活性是我们最重要的优先事项，因此架构的主要优势对我们来说反而正式成为了劣势。架构的好处在于它能够帮助简化开发过程，但缺点也在于它能够帮助简化开发过程。

对于某些情形，让架构为您作出重大决策可能会让一切显得更加容易。但对于其他情形，包括我们的情形，更好的做法是承担更多的工作，以便获得我们知道用户想要的灵活性。

然而，从意识到那些权衡的程度中获得的主要启示是，作为创始人和开发人员，我们最后不可避免地会意识到重大决策具有我们没有预料到的权衡。我们会错误地认为，如果一已经开始我们只是知道一切，那么我们可能会作出另两个优先选择。这可能会诱使我们等待、计划和畏缩，但实际上，它应该推动我们去构筑、正式发布和迭代。

早在 2009 年，Jeff Atwood 发现了完美的措辞[21]，而那些话至今依然适用：“在开发周期的结束时，你最后得到的软件只是你在已经开始时设想的辉煌、光辉的软件工程纪念碑的两个苍白倒影。”

不完美是不可避免的，而冒险则是必要的，这意味着我们将始终面临重大胜利与失败、利与弊、收益与成本——权衡的过程将无处不在。

剧情反转：我们实际上依然是 React 用户

这首诗的另两个版本可能是一篇煽动性的文章，它说：“嘿，你知道过去五年最畅销的 Web 架构吗？实际上它很糟糕。”但这是不正确的，也并非我想做的。

我描述了很多我在 2018 年优先选择不选用 React 的原因，但即使那时，坦率地说，我对 Web 架构的主导地位持怀疑态度。即便如此，中立性依然应该是核心。

Authentik 在我们的文档网站上选用了两个选用 React 的架构。如果在其他地方须要，我并不抵制选用 React，只要它最适合我们的需求。每个优先选择都伴随着权衡，而每个事物都有其适应的位置。

原文 https://goauthentik.io/blog/2023-05-04-i-gambled-against-react-and-lost

翻译润色：ssh

参考资料