Elm 0.19 让我们崩溃了💔

Elm 0.19 版本昨天发布了。在配置、工具、库、语言等各个层面都进行了大量重大更改。但这些并非本文的重点（编辑：Elm 提供了一个升级工具来自动修复许多此类问题）。对于我的团队来说，这个版本让我们心碎。

有两个变化带来了众所周知的“压垮骆驼的最后一根稻草”：移除自定义操作符和原生模块。起初我只看到了移除自定义操作符的消息，并在这里发布了我的反应。0.19的发行说明中没有提到移除原生模块，所以直到今天我才知道。我偶然想起了这件事，然后搜索了一下，找到了这篇文章。

关于本机模块的帖子早在三月份就出现了，所以我怎么不知道呢？

社区

不久前，我退出了 Elm 社区。当时我并没有过多谈论这件事，但我会分享一下原因。我热爱 Elm 平台并使用它，但觉得社区的管理方式太令人沮丧了。Elm Github 问题管理的方式就奠定了这种基调。很多问题都被锁定，要么是为了防止不愉快的反馈，要么是因为它们只是少数幸运的贡献者的个人问题，即使它们是公开的。如果你发布问题，你很可能会因为没有“正确”地做事而被打耳光。“正确”意味着要参加严格的 SSCCE 来查找 bug，或者参与公共论坛的角斗士竞技场来提出想法/请求/建议，或者，如果你为了赢得信任而付出了额外的努力，那么这两件事你都可以忘掉。我说的是角斗士竞技场，但Elm 社区总体来说真的很友好，尤其是在帮助新人方面。然而，有不少人已经准备好了“尺子”，随时准备对 Evan（Elm 的创始人）所说的或没说的话进行严厉的惩罚。因此，在论坛上发布“想法”或“反馈”很可能会招致责骂。这反过来又证明，社区对你的帖子没有“共识”，所以可以忽略。所以，“先在论坛上发帖”的规则是忽略反馈的有效方法。

显然，自从 Elm 论坛迁移到（编辑：Reddit 和）Discourse 后，那里的帖子也可以被锁定了。当管理员知道 Evan 不想听你对某个问题的不同意见时，他们可能会先发制人地锁定那些可能出现这个问题的帖子。总之，感觉 BDFL 中的 D 在那里被看得太重了。所以我很欣赏这个产品，但大部分时间都远离社区，也没能及时看到那些预示着变化的帖子。

平心而论，我自己确实有过不好的经历，这其中也存在我的错误。但作为旁观者，我在 Elm 的旧 GitHub 和 Google 群组中多次观察到这种不受欢迎的模式。而在我参与过的其他项目中，情况并非如此。

控制

移除自定义操作符表面上是为了 Elm 好。然而，在解释移除原因的文章中，估计有 5% 的用户仍在使用它们。而且，使用它们的一些原因与其他语言（任务链、解析）相同。最终，Evan 认可了某些自定义操作符，并允许它们作为例外保留。但普通 Elm 用户认为，任何适合他们用例的自定义操作符，对 Elm 来说都是“坏事”。好吧……

理论上，我仍然可以通过 0.19 版的 monkey patching 注入原生模块。（JavaScript，没错！）然而，由于死代码消除，除非关闭优化，否则 monkey patching 可能会有点困难。但真正的问题是原生模块仍然存在。它们只是为少数 Elm 贡献者保留的。我们其他人不应该使用这个专家级功能。显然，我使用的总共 40 行原生代码会彻底摧毁 Elm 社区。即使没有其他合理的方法可以实现我的需要。好吧……

虽小但具有指示性：Evan 曾多次发帖，建议用户改变谈论或思考 Elm 的方式。（说得对：他态度很好，而且观点也确实有理有据。但仍然……具有指示性。）例如：不要使用“组件”这个词。不要说“原生”，而要说“内核”。联合类型现在应该被称为“自定义类型”。但千万别回复他的帖子——帖子结尾总会提示你只有几种可接受的回复方式，或者干脆不回复。好吧……

综合以上所有情况，我们逐渐形成了这样一种印象：作为 Elm 用户，我们肯定会被过度地、事无巨细地管理。即使是像原生模块那样果断且内容丰富的反馈（好吧，是异议），也不会受到欢迎或重视。Evan 认为，他只是不喜欢 Elm 用户的一些行为（即使它在类似语言中也拥有良好的口碑，比如自定义运算符），所以在下一个版本中禁用了它。要么听我的，要么滚蛋。尽管 Elm 为我们带来了诸多惊喜，但对于一个工具链来说，这种行为实在太过激烈。而这绝不是我团队真正想要的。

现在怎么办？

在我看来，我们有几个选择。

继续使用 0.18

我在 0.18 版本中没有遇到任何重大问题。我们可以避免更新日志中指出的那些问题（例如数组）。然而，这不是一个长期策略。0.18 版本似乎不太可能再出现任何错误修复。旧版本的工具（例如 Create Elm App）最终会停止维护。与此同时，计算机科学和 Web 技术仍在不断发展。

猴子补丁 0.19

由于死代码的消除，通过猴子补丁将之前的“原生”代码引入到项目中存在一些未知数。但更深层次的问题是，即使迁移到 0.19 版本，我们仍然对工具链的未来感到不安。

等待 Elm 分叉

很多树名可能仍然可用（例如金合欢树、杨树等等）。可惜的是，我们没有足够的资源来维护一个分支。但似乎有人会得出与我们类似的结论，并想要创建一个分支。即便如此，这条道路仍然充满未知。

等待 Elm 固化

大多数项目都会进入一个固化阶段。这意味着需要付出一些努力来保持向后兼容性。如果 Elm 决定在某个时候这样做，我们可以评估最新版本。也许到那时，我们不再需要保留那些被剥夺的自由，所以这将不再是一个有争议的问题。然而，只要编码器和解码器仍然是处理 JSON 的唯一官方方法，我们可能就需要原生代码。20 行原生代码可以为我们节省数百行编码器和解码器的代码。

换成别的东西

我知道的另一个模型-视图-更新平台是 Fable-Elmish。它使用 F#，而我们已经用它来处理 API 了。可惜的是，F# 并非纯粹的语言。因此，编写纯函数需要一定的规范。Elm 最近的一些改动在纯粹性方面做得过头了，而在我看来，F# 对于前端来说还远远不够。不过，F# 非常适合 API，因为它们可以集成外部系统（例如 UI、数据库、电子邮件、文件等）。如果 F# 执行副作用需要大量的开销，那么在 API 中使用起来会更困难。根据用例找到合适的平衡点很重要。无论如何，它仍然是一个可行的选择。

将来也可能会有一个替代的 MVU 平台出现。我相信 ClojureScript 有一个类似 MVU 的库。我不太想回到基于组件的系统。（是的，纯函数 MVU 确实很棒。）

结论

团队一致认为，坚持使用 0.18 版本是我们目前的最佳选择。我们即将推出一些应用，将使用 0.18 版本开发，不会考虑 0.19 版本。我们会尝试使用 Fable 版本。我们会看看是否有其他 MVU 风格的平台。最终 0.18 版本会逐渐过时，我们需要转向其他平台。

这种情况真的令人沮丧。我们热爱 Elm，从未想过用其他任何语言。但我们开始觉得我们与 Elm 的关系变得不稳定了。💔