Dev.to 完美地展示了如何开发基于内容的 Web 应用程序

我一直想把我的文章从 Medium 上撤下来，虽然还没开始动手把旧帖撤掉，但我至少开始探索其他平台了。现在大家都在推荐 Dev.to，所以我注册了，开始尝试在这里写文章。

我仍然想写那篇文章（下次我会发布它），但它必须等待——我必须先写关于 Dev.to 以及它对我自己产生的启发。

Dev.to 速度很快

简直太疯狂了。Dev.to 真是快到爆！它快到感觉就像一个本地 Web 应用，而不是互联网上的应用。我很久以前就接触过 Dev.to，但一直都是一次性发布文章，所以速度没那么明显；但当我真正去注册账户、编辑个人资料等等的时候，才发现它快得惊人。

我立刻想到，Dev.to 到底做对了什么，而现在互联网上几乎所有其他网站都做错了？他们怎么能这么快？相比之下，即使是互联网巨头（Reddit、Github，甚至 Hacker News！）的网站也感觉像乌龟一样。而且 Dev.to 规模并不小——Alexa 显示它的全球排名在 8000 名左右（相比之下，HackerNoon 在 4000 名左右，npmjs 在 6000 名左右），而且内容非常丰富！

深入研究一下，这是一个使用 InstantClick 的传统 Rails 网站

我首先查看了源代码并打开了 Chrome 开发者工具；然后发现每个页面都渲染了完整的 HTML，所以看起来不像是一个 React（或任何其他前端框架）的网站。然后我注意到，每当我鼠标悬停在任何链接上时，它都会发送一个预加载页面的请求。我知道一个叫Turbolinks的 JS 库可以实现这个功能，所以我想可能就是这个原因。

后来我注意到 Dev.to 网站的代码是开源的，于是我查看了一下，找到了它的技术栈页面，发现InstantClick正是它的秘密武器。它的工作原理和我观察到的完全一致——当你将鼠标悬停在超链接上时，它会预加载超链接的 HTML 输出；当你点击超链接时，它会替换当前页面的 HTML，并history.pushState()额外添加一些内容。

这是基于内容的 Web 应用应该努力追求的模型

说实话，那些管理着基于内容的网站，功能/业务逻辑不多的大型组织/初创公司几乎总是默认使用 React 作为前端框架。从组织结构上来说，这很合理，因为你有一个庞大的开发团队在开发产品，而基于组件的前端架构是在一个庞大的前端代码库上协同工作最明智的方式。

但这真的是最佳用户体验吗？你不需要远离那些典型的热门媒体网站（Techcrunch、ESPN 等），就能看到它们使用 React 或类似 React 的行为——典型的服务器端渲染首页，加载 JS 包，在客户端 JS 框架上进行 hydrating，然后通过 API 调用加载下一页，等等。

相比之下，Dev.to 只是在每个服务器端点打印来自服务器的页面输出 HTML，只有在鼠标悬停在链接上时，InstantClick 才会预加载页面，从而提升页面加载速度（随后新的 HTML 会替换当前的 HTML，从而避免完整的浏览器页面导航）。我认为这才是基于内容的网站和基于内容的 Web 应用（包括博客、电商网站等）在开发中应该采用的模式。

这为什么有意义呢？

我们整个科技行业花了十年时间（大约从 2007 年到 2017 年左右）优化 Web 应用程序服务器端的每个部分 - 从数据库性能（读取副本、分片等技术以及新一代的 DB 引擎）、缓存（memcache、Redis、本地 Web 服务器缓存）、用于写入数据的异步工作队列、负载均衡器和无限扩展的 Web 服务器（随着 AWS 的出现）、区域/可用区域和边缘 CDN，以更贴近用户。

一旦我们拥有了一切，我们便开始通过在客户端放置像 React 这样的重量级前端框架来与这些服务器协同工作，从而真正抵消了在服务器端性能优化方面的所有投资。现在要加载一个网站，您需要加载一个 1mb 的 JS 包，在网站或 Web 应用程序的首页加载时放置一个旋转器，并让 React 处理整个虚拟 DOM 并计算在任何状态发生变化时如何渲染所有内容。我们又回到了 21 世纪初网站/Web 应用程序速度慢的时代，当时是因为我们还没有那些服务器端技术，而且消费者的互联网连接速度很慢。现在网站的加载时间与 2007 年一样，只需几秒钟；但原因完全不同。对于最终用户来说，这难道不令人难过吗？随着技术的进步，用户体验却大致保持不变（甚至更糟）？

但是，基于组件的前端开发！

说实话，作为一个并非 React 粉丝的人，我唯一同意使用 React 前端的理由（而且这个理由很重要）就是组织层面的原因。在我 15 年的软件团队工作经验中，基于组件的前端确实是大型团队协同开发前端代码库并实现代码扩展的最明智方式；没有其他方法可以绕过它。

传统的 MVC 框架采用模板视图，这使得前端代码的合理复用变得异常困难，除非它变得过于复杂；而扩展 jQuery 前端则不可避免地会导致代码混乱。我相信这正是 React 在科技初创公司中取得成功的主要原因之一；它是培养一支认真对待前端开发的开发团队的最佳途径。

也许需要一种新的发展模式？

我们如何在 Web 应用中充分利用服务器端生成的 HTML 输出，同时又能充分利用基于组件的前端开发？这是我今晚突然想到的点子，或许能启发你尝试类似的方法？

• 前端团队在基于组件的框架（React、Vue、Svelte 等）中进行开发。
• 前端工具链基于组件构建每个页面的静态 HTML（此构建在开发期间本地进行，也在 CI 工具上进行）——可以继续使用 Webpack、Rollup 或任何人们喜欢的东西。
• 每个构建的页面都包含一组变量（类似于传统 MVC Web 应用程序中模板视图的工作方式）。
• 前端可以模拟后端提供的数据，类似于在开发过程中模拟 React 前端的 API 响应的方式。
• 后端采用传统的 MVC 架构，可选择任意语言（Ruby、PHP、Python、Nodejs）和框架（Rails、Laravel、Django、CodeIgniter）。
• 后端通过按页面名称加载预先构建的静态 HTML 来呈现视图，并像模板视图一样传递变量。
• 功能开发工作流程：后端和前端团队成员在同一个功能分支上工作，各自独立检查他们的更改，当前端检查组件源代码时，CI 工具运行构建工具链，然后将每个视图生成的静态 HTML 提交到 repo 中。
• 前端可以继续在类似 React monorepo 中组织代码，就像现在一样，具有可重复使用的组件和所有内容。
• 别误会，你的 React 组件仍然可以对点击、移动等操作做出响应，并在本地更改状态，你仍然可以在许多有效的用例中自由地发出 AJAX 请求。所有这些都不会改变。但是，<a href>当页面发生整个更改时，页面导航应该留给 InstantClick 和服务器来生成下一页。

你的想法？

我还没有对这个工作流程进行过多的思考，只是把它全部写下来，所以很想听听其他人的意见。