2011年的时候，我碰巧找到一份编写Backbone.jsapp的工作。如果你从没做过那样的工作，千万别去做。我会给那些愿意听我抱怨的人，喋喋不休地讲我遇到的各种困难。当我开始深入研究前端的替代方案时，我发现了FRP、Flapjax和ClojureScript。其中ClojureScript让我迷上了Clojure。我甚至针对 FRP 和 ClojureScript （以及Hoplon的前身hlisp）做了一场成功的演讲。

React

然后在2013年的时候，React发布了。我在我的新工作中尝试了React，并在Clojure主题的峰会（Clojure Cup 2013）期间发现CLJS和React简直是天作之合。React为什么这么好呢？对于我来说，主要的卖点是它组件化做的非常好。

当你使用之前的东西，例如jQuery、Backbone、Angular或者其它东西，只需一年的开发之后，你的代码就会是一团事件监听器和触发器。千万别让我碰那些莫名其妙的JS，jQuery根本就不存在代码封装。哪个处理器在哪里绑定，用来做什么？很难说这是一个好的基础库！

然后我开始在Kasta工作，那里的web前端完全就是一团jQuery式的玩意儿。没人想要碰那些代码，因为你会花费数小时，甚至数天，来做一些最小的改动。然后QA会发现比你想象的多得多的错误状态。然后用户会向我们的呼叫中心报告更多的错误。那糟糕程度简直超乎你的想象。

因此，在进行了一些实验、测试和检查后，我决定使用React + ClojureScript技术栈，用Clojure进行服务器端渲染。

没落

有一段时间，一切看起来都很好。我们的有这样的架构：我们的组件在后端作为Clojure执行，所以没有服务器端Node.js，太棒了！而且UX开发者通过出色的实时重新加载（多亏了CLJS），能够从编辑器连接到浏览器的REPL，并直接在编辑器试验。那简直太棒了！

长话短说，我们的前端变得越来越大。增量编译变得越来越慢——现在通常需要一到两秒以上。虽然我们做了一些尝试来保持整个app的性能，但最终我们还是失败了。这是一个痛苦的凌迟过程。应用程序变得太大，启动时间变得太长。服务端渲染只能帮助一部分，但是混合渲染会阻塞浏览器。在比较老旧的硬件或Android系统上，这变得不可接受！

2016年的时候，一个主要原因是我们在启动时间上采取了大的改动，拥有了一个没有页面加载且具有大量交互的富web应用程序。在一段时间内，这是有效的！但是启动时间越来越长，导致在谷歌的PageSpeed上被评为可耻的5/100（有时会达到25/100左右）。

除此之外，在执行下面描述的操作时，我们发现React也会导致一些有问题的实践。例如悬停用JS（而不是用CSS），下拉菜单用JS，不渲染（在悬停时）隐藏的文本（谷歌对此会不高兴），奇怪的复杂逻辑等等。你可以创建一个没有这些问题的React应用程序，但是显然，你必须比我们有更好的自控能力（人无完人！）。

而且从那之后，我们的绝大部分用户都转向了移动app。这使得web app成为新用户的主要入口。这意味着它的主要目标是为新用户快速渲染页面，因为想要更多功能的老用户现在都在移动app上了。而TTI（响应时间）在这里变得更加重要。

变革时刻

既然情况已经改变，那我们要怎么做呢？在React出现之前，我读过“我如何靠vanilla JS生存”这类的文章，但这些文章通常没有任何意义——它要么是一个关于它有多伟大的喧嚣，而无视所有问题（关注点分散、内聚性、组件化、代码封装），要么是一个（或几个）人在脑袋里想想而没有实际代码的项目。

早在二月的某个时候，我偶然发现了Intercooler.js。我不确定我以前是否见过它——也许我看过但一瞥而过——但这没关系。这一次，它引起了我的注意。

其理念是，所有的HTML都在服务器端渲染。而客户端根据元素的属性，更新部分HTML。基本上类似HTML+XHR。你不能任意妄为，但这是其重点之一：有些限制是好的，从而让你不会做一些疯狂的事情。你需要服务器的一些支持，这样你就可以渲染部分结果——虽然只是一个优化，但确实非常重要。

还有一个备选库——Unpoly。这个库围绕布局和样式有更多特性，但是在XHR上的想法比较少（例如，如果没有表单，很难完成带参数的POST请求）。而且这个库大的多。而且它是用CoffeeScript编写的，有许多类，这也有点问题。

所以我用Intercooler对我们的目录页做了一个概念验证式的实现，而且它成功了！除了对jQuery有依赖和其它一些令人恼火的东西外…当我纠结于对HTML片段的请求时，我明白了一件事：当我为目录页选择技术路线图时，最后的选择是“类似intercooler的小东西”。

那为什么还不行动呢？

TwinSpark

我喜欢Intercooler在处理AJAX方面的流畅方案，所以我决定用一些汽车方面的东西来命名这个库，而TwinSpark似乎是一个不错的名字。这具体是个什么东西呢？

TwinSpark是一个用于声明式HTML增强的框架：你在元素上添加额外的属性，TwinSpark对它们对一些处理。例如发起一个AJAX调用并用响应替换目标，或者增加一个样式类，或者，你们自己看看这些例子吧。

当然，它与Intercooler有些不同之处，不然它为什么会存在？最值得一提的就是，它不依赖jQuery。它只支持现代浏览器（不支持IE和Opera Mini）而抛弃掉了88kb的兼容性怪代码。

它还有以下优点：

没有继承——这点再强调也不过分！
指令有明确的扩展点
支持对服务器的批量请求
更严格的属性命名规范（这是我的观点，但ic-get和ic-post使我烦恼：别让我改变观点啊！）
负载更小（多亏了没有jQuery！）
应该更快（也多亏了没有jQuery）

老实说，最主要的原因是批处理和无继承性。继承在这里尤其痛苦。在Intercooler中，如果你在body中声明ic-target属性，其中的所有标签都会认为它们的target也是这个。这样的话，在HTML树的某个地方有一个组件，而树上更高位置的一个属性改变了这个组件的行为。我认为这是一个奇怪的动态范围，我可不想要那样！:)

有趣的是，在对TwinSpark进行了一个月的尝试之后，Intercooler的作者宣布它在做一个没有jQuery的现代版本：htmx。它有非常好的扩展点，而且可能会增加批处理…但是仍然有继承。:-(

TwinSpark为什么是一个好主意

我们需要从两个方面看待它：它是否对开发者友好以及它是否对用户友好。React对前者优化，而对于后者来说是非常讨厌的。

TwinSpark方案在大部分情况下对用户更友好：更少的JavaScript，更少的抖动，更常见的类似HTML的行为。在最差的情况下，我们将返回2.5MB简化后的（但没有gzip压缩过的）JS和700KB的目录HTML（其中一半是React的初始化数据）。JS包那么大不是因为包含的图像、css或其它一些复杂的东西，而是因为它是整个app，有很多视图和逻辑。

现在它是40KB的简化的没有gzip压缩过的JS（TwinSpark、分析埋点、一些行为代码和IntersectionObserver兼容包）和350KB的HTML。两个数量级的差距，而且HTML也更小！

在开发者方面，我认为React仍然比较好些，但是TwinSpark比用jQuery在代码封装和组件化方面要好。另外还有很多方法来提升它。

好消息是开发流程没有太大变化！我们仍然编写从站点内存存储中查询必要数据（需要的时候发起一个API调用）的组件，但他们只在服务端执行。我们在我们以前的架构中有效地利用了后端，而且这使得我们能够完美地渲染“部分”HTML——因为组件不需要等待某个“controller”来给他们所有必需的数据。这也使得我们可以同时拥有React和非React版本，进行A/B测试，而无需编写二次标签。

结论

从首次尝试到发布，我们花了4个月时间。并不是我们刚开始时预想所需的时间（“应该最多需要两三周！”），呵呵，但并不是只有我们这么做。从代码中移除React相关代码并将我们的app打造成一个服务端应用程序仍然花费了很多时间和精力。它仍然需要一些润色，但我们还是决定发布它来缩短时间。A/B测试显示我们是对的——特别是对于Android手机。

谷歌现在给我们的目录页排名75/100而不是5/100。我想，这还是很不错的吧？:)

作者介绍：
Alexander Solovyov现在是Kasta公司的首席产品官，之前是那里的CTO。我们致力于为消费者和生厂商构建一站式电子商务平台。

原文链接：
A tale of webpage speed, or throwing away React

创作场景

React 从入门到放弃，一个关于网页速度的故事