捍卫现代网络

我预计我的这篇帖子会惹恼每个人：反JavaScript斗士，他们对我们在现代网站上铺天盖地的东西感到震惊；人们认为，无论如何，网络是一个破碎的互动应用平台，我们应该重新开始；反应用户；老保守派，他们手工制作的JS和手工制作的HTML；以及汤姆·麦克赖特(Tom MacWright)，自从多年前我第一次知道他在Mapbox上的工作以来，我一直在远方钦佩他。但我想这就是发表意见的代价。

汤姆最近发布了对现代网络的批评，并在前端世界掀起了一场风暴。你应该读一读，或者至少读一下CliffsNotes。我在不同程度上同意很多事情：

有一个反应的甜蜜点：在适度互动的界面中…。但在这个甜蜜点的两边都有很多东西。

这绝对是一种情况，在客户端运行Reaction对于一个基本上是静态的站点来说是矫枉过正的。如果你的应用程序的交互性非常强，你必须避免REACTION，这也是事实--人们普遍认为，如果你想要60fps的动画，你很可能不得不绕过REACT更新周期，以更紧迫的方式做事情(实际上，像Reaction-Spring这样的库就是这样做的)。但是，尽管所有这些都适用于Reaction，但一般来说，组件框架就不那么适用了。

用户会话时间长得令人吃惊：有人可能会让您的网站一次在一个选项卡中打开数周。我亲眼目睹了这一切的发生。因此，如果他们打开“关于页面”，保持选项卡打开一周，然后请求“主页”，那么他们请求的主页将由他们上周下载的索引包决定。这是一种非常奇怪的情况，而且没有得到充分的讨论。

这是一个很好的观点，但并没有真正得到解决，尽管(正如汤姆承认的)它实际上只是加剧了一个一直存在的问题。我认为有解决方案-我们可以迭代索引捆绑包方法，我们可以将网站版本包含在cookie中，并在存在不匹配的情况下使用它来显示可操作的反馈-但我们确实需要在上面花费时间。

这是你的创业公司的主页，它有一个“注册”按钮，但是在JavaScript加载之前，这个按钮什么都不做。所以你需要补偿。

这确实很烦人，尽管做这类事情很容易--我们只需要足够的注意就行了：

但我不确定这与Reaction风格的框架有什么关系--无论前端采用什么形式，这个问题都存在，除非您让它在没有JS的情况下工作(您应该这样做！)。

您以前的轻量级应用程序服务器现在做了相当多的工作，运行act&；发出API请求，以便执行此预呈现。

同样，这是事实，但比任何事情都更具体。Reaction的服务器端呈现方法-构造组件树，然后序列化它-涉及的开销不是由框架分担的，例如，编译您的组件(嗨！)。到只为SSR连接字符串的函数，其速度要快得多。而且这些API请求无论如何都是必须发出的，所以尽早发出它们是有意义的，特别是如果您的应用程序服务器和API服务器彼此靠近(甚至是同一件事)。

API的梦想是拥有通用的、灵活的端点，您可以在这些端点上构建任何Web应用程序。那个想法很快就会瓦解。

撇开一些细枝末节的吹毛求疵不谈，Tom指出了Web开发中的一些现实问题。但我认为这篇文章得出了一个危险的结论。

例如，我可以保证这个博客比任何Gatsby博客都快(也非常感谢Gatsby团队)，因为没有什么比非反应静态站点更快的了。

恕我直言，我不认为盖茨比是一个特别相关的基准。Gatsby新的My-Site Starter应用程序在生产模式下对完全静态的页面执行266kb的缩小JavaScript；对于gatsbyjs.org的808kb。老实说，这些数字并不令人印象深刻。

撇开这一点不谈，我不同意这个前提。当我在Tom'；的免费网站上点击一个链接时，浏览器首先会等待确认这是点击，而不是刷子/滑动，然后提出请求，然后我们不得不等待响应。有了具有客户端路由的框架编写的站点，我们可以开始做更有趣的事情。我们可以基于对用户可能与哪些事物交互的分析做出明智的猜测，并为它们预加载逻辑和数据。我们可以在用户第一次触摸(或悬停)链接时立即启动请求，而不是等待确认点击-最坏的情况是，我们已经加载了一些内容，如果他们点击了这些内容，这些内容将在以后有用。我们可以提供更好的视觉反馈，告诉您加载正在进行并且即将发生转换。而且我们不需要加载页面的全部内容-通常，我们可以凑合使用一点JSON，因为我们已经有了页面的JavaScript。用手做这些东西会变得极其困难。

除此之外，普通的静态站点并不是一个足够雄心勃勃的目标。以过渡为例。Web开发人员目前陷入了一种思维模式，即离散的页面有不和谐的过渡-点击一个链接，看到整个页面都被替换了，无论是通过客户端路由还是页面重新加载-而本地应用程序开发人员则在另一个层面上思考：

要让网络实现这一目标，需要的不仅仅是技术进步，还需要一场文化变革。但是，如果我们放弃目前的轨道，我们肯定达不到目标。这正是汤姆似乎在暗示的。

我不知道有任何其他平台要求您使用与后续交互逻辑不同的一组技术来编写初始呈现的逻辑。这个想法本身就听起来很愚蠢。但在有着独特历史的网络上，这是多年来的规范-我们会用PHP或Rails或其他工具生成一些HTML，然后在上面撒一些jQuery。

随着Node的出现，这种情况发生了变化。事实上，我们可以使用Web本地语言进行服务器端渲染，并与数据库和诸如此类的东西进行通信，这是一个很棒的发展。

这个型号有问题。汤姆认出了其中的一些。他没有讨论的另一个主要问题是，服务器呈现的SPA模型通常会对整个初始页面进行水合处理，这需要你复制大量数据--一次在HTML中，一次在JSON blob中，然后传递到应用程序的客户端版本以产生完全相同的结果-并且可能会在用户开始与应用程序交互期间阻塞主线程。

但我们可以解决这些问题。下一步是围绕(例如)在单个应用程序中混合静态和动态页面进行令人惊叹的创新，这样您就可以获得纯静态模型的好处，而不会最终发现自己受到它的约束。Marko实现了智能组件级别的水化，我希望其他框架也能采用这一点。Sapper是Svelte的配套框架，它有一个明确的目标，即最终不向不需要的页面发送除(微型)路由器本身以外的任何JS。

我想要的未来--我看到的未来--是一种工具，它可以让最多的人(包括设计师)访问，可以在适当的时候在服务器和客户端之间智能地移动工作，让我们在UX上建立与本机竞争的体验(是的，甚至对于博客！)，并且将网站的一部分升级到交互式网站或从静态网站升级到动态网站并不涉及使用不同的不同的团队之间的沟通，而是将网站的一部分升级到交互式网站，或者从静态网站升级到动态网站，而不是使用不同的工具在不同的团队之间进行沟通(是的，甚至对于博客也是如此)，并且将网站的一部分升级到交互式网站或从静态网站升级到动态网站并不涉及跨不同团队使用不同的工具进行沟通。我们只有致力于Tom Critique范式-服务器呈现的JavaScript组件框架SPA-才能做到这一点。(欢迎使用更好的名字。)。

现代网络有缺陷，我们应该谈谈这些缺陷。但是，让我们不要放弃它。