JavaScript 框架和元游戏

上周，我们发布了 SolidJS 1.0。这是一个 JavaScript 框架，基于很久以前被摒弃的想法，实现了一些人认为不可能实现的目标。这对我个人来说也是一项伟大的成就。多年的心血得以实现并得以展示。

你们很多人都知道这一点。自 2018 年以来，我特意选择撰写构建 JavaScript 框架的每一个细节。这已经写了几十篇文章。Solid 在很多方面都是公开构建的。即使我们发布了 1.0 版本，我也不会停止以高度内省的方式记录我的经历和所学知识。

在如此拥挤的环境中推广一个新的 JavaScript 框架并非易事，这早已不是什么秘密。1.0 版本的发布让我对此有了更深的反思。

游戏中的元游戏

我曾经是《万智牌》 （集换式卡牌游戏）的狂热玩家，玩了好几年。我主要负责卡牌设计和游戏测试。我的技术水平并非一流，但我擅长的是理解所有可能的卡牌组合是如何相互对抗的，以及如何运用一种策略来抵消另一种策略。你可以把这看作是一场大型的“石头剪刀布”游戏，只不过选项不止三种。

万智牌的有趣之处在于，每场比赛都是三局三胜制，先手的玩家通常拥有优势。但第一局的先手是随机的，你无法控制。第二局由输家先手，如果进行到第三局，则由先手的玩家再次先手。

但真正有趣的是，第一局游戏结束后，任何一方都可以交换牌堆中最多四分之一的牌。而且，根据不同的策略，玩家可以改变策略来对抗其他策略。考虑到《公主新娘》的升级机制，这其中的奥妙就显得尤为深刻了。

通过《万智牌》，我学到了博弈论的课程。它非常深奥。从那时起，我就把这种模式化的思维运用到了很多我遇到的问题上。首席设计师Mark Rosewater的演讲是我最喜欢的，他谈到了设计过程中的经验教训。

框架设计

那么这与设计 JavaScript 框架有什么关系呢？嗯，就功能而言，它与定位息息相关。如何平衡一个没有明显弱点的解决方案，同时又能提供平均水平的最佳服务。有时你在第一局就赢了，其他人根本无法追赶。有时，你只需要在决定性的第三局中占据优势即可。

虽然这听起来有些残酷，但它为我提供了一个看待平衡的框架。你无法改变你的基本身份（或者说，万智牌中的颜色）。根据你的选择，你只能使用特定的工具。你所能做的就是最大限度地发挥你的优势，并调整那些真正被争夺的决定性因素。

在框架设计中，这意味着有时解决方案并非解决已知问题，而是重新定义它，以避免陷入不适合工具集的解决方案。我不得不做大量工作来重新构想无 VDOM 的 JSX，以及如何在精细的响应式库中实现 hydration 和 SSR。这些技术建立在 Solid 所不具备的 diff 之上。

一次又一次，当我陷入困境时，我不会认输。我会重新开始，看看是否有办法重新构思这个问题。

现在换个角度来看。Solid 之所以有如此非传统的元素组合，是有原因的：它混合了响应式 + JSX，进行部分编译，但将部分编译留给运行时，采用单向流，以及在可变内部结构的情况下使用不可变模式。这些因素共同作用，在现有解决方案最薄弱的地方将其击败。众所周知，我们正在达到这种抽象的极限。

我曾听过一些框架作者说过这样的话：我很想做空白，但不值得专注于渐进式改进。他们说得对。但如果框架的实际基础配置就设置在这个空间里呢？

我并非一定认为 Solid 的权衡更好。显然，我在这方面有个人偏见，我认为至少它提供了一系列独特的优势。然而，我发现这些决策的影响远不止技术层面。

社交元游戏

社交方面我经验不多。我以前用 MySpace 推广我的乐队，后来 Facebook 出现后，我心想：“算了，我以后再也不用了。” 三年后我终于注册了。之后十多年我都没用过 Twitter。

我只有自己写的文章和工作成果。你大概也能看出我框架设计方法的缺陷。这可不是交朋友、影响别人的方法。

如今，框架作者们正亲身经历这些问题。他们认真思考了其中的利弊。他们选择了自己的立场，并持续努力理解这些利弊以及他们决策的影响。尤雨溪就此话题制作了一段精彩的视频：

这段视频确立了比较我们项目的轴心，并清晰地说明了从左到右移动刻度盘会产生不同的影响。这里不会讲得太深，但一张幻灯片上的决策会直接影响到下一张幻灯片上的选项。

这就是有影响力的人可以传达并向大众传播的简单信息。虽然这听起来可能过于简化，但确实达到了目的。但如果争论的焦点正是我们进行比较的基准呢？如果现有模型的规则被打破了呢？

人们已经疲惫不堪。“JavaScript 疲劳”这个词已经被广泛使用。有一种观点认为，随着 JavaScript 生态系统的成熟，它应该趋于稳定，并在后端更像 Ruby 或 Java。我们应该建立一些成熟的工具和实践，并在此基础上进行逐步改进。

任何有影响力的人最不想做的就是给粉丝们带来更多不确定性。人们信任他们是因为他们能带来清晰的思路。所有事情都清晰地归类。打破这些壁垒的想法是没有立足之地的。

我并不指望人们会放下手头的工作去换框架，但我却屡次发现自己在思维空间里遇到了巨大的障碍。没人希望 JSX 可分析。没人想听到一个编写良好的 VDOM 比大多数其他解决方案扩展性更好。见鬼，考虑到所有前端框架都如此相似，也没人想听到 React 也应该被认为是响应式的。或者说，我当时是这么想的……

回顾 1.0 版本

我已经习惯了人们看到Solid就对它不屑一顾。毕竟，它就是故意设计成一个“沉睡者”的。但我看到的是 React 社区成员的积极评价。他们看到了它的发布，看了之后，说：“你知道吗，这真是太棒了。”

Solid 难道不是某种 React 杀手/替代品吗？为什么 React 社区会欢迎它，而其他社区却不会？

很简单。这重申了他们的价值观。他们不认为 Solid 是竞争对手。或许只是他们最喜欢的框架的重新构想。尽管表面上渲染了 React 与 Solid 的对立，但实际上他们并不会因此感到威胁。

从愤世嫉俗者的角度来看，Solid 的存在给了他们一份礼物。Solid 正是那些框架讨论中的陪衬。在谈到与其他框架在编译、模板、响应性方面的比较时，他们只需指出 Solid 就足以证明，无需费尽心思就能获得所有好处。

人们甚至可以争辩说，Solid 再次强调了为什么你应该使用 React。

下一步该怎么做

好吧，为了不让任何人失望，React 不会走这条路。一些批评人士说：“React 是一个想法，而 VDOM 只是一个实现细节。” 好吧，我有充分的理由相信，这是一个他们目前既不想也无法逃避的实现细节。这可不是 Vue/AlpineJS 那种大公司只需灵活变通的局面。

我们在一些曾经难以获得认可的地方获得了许多新的曝光。他们或许不会全都给予我们正面的评价，但这份认可是朝着正确方向迈出的一步。这才是最重要的。

以我的经验来看，那些维护者和贡献者们对不同想法有着最深刻的理解和包容。我仍在学习如何与那些有影响力的人合作，避免总是“嗯，实际上”地对他们指手画脚。我有很多工作可能与他们一直以来告诉人们的观点相矛盾。而我目前的情况是，在这件事上我别无选择。

Solid 的发展已经超出了我一个人所能专注的范围。所以我会继续努力做好力所能及的事情，并相信那些继续与我分享对这个伟大的小框架的热情的人，这样我们才能继续成长。我注意到，国际社区正在涌现，并且已经有了将文档本地化为不同语言的需求。这真是太棒了。

我看到人们重新燃起了对响应式状态库的兴趣，并尝试跳过框架，看看它们能做什么。这就是一切的开始。一路走来，我学到了很多。看到人们采取同样的步骤，并做出与我多年前相同的发现，是我所能期待的最大的肯定。

说实话，这一切都太神奇了。感谢大家陪伴我走过这段旅程。