我倾向于直言不讳地谈论客户端 JavaScript 从性能角度带来的问题。我们向用户设备发送的 JavaScript 比以往任何时候都多，结果导致体验越来越脆弱且资源密集。这……不太好。
但这并不意味着我不喜欢 JavaScript。相反，我非常享受使用 JavaScript。我只是希望我们能够更具选择性地决定在哪里使用它。
让我感到兴奋的是，JavaScript 开始触及以前从未涉足的技术栈部分。服务器端编程和构建工具流程并非完全对前端开发人员关闭，但在 Node.js 和 Grunt、Gulp、webpack 和 Parcel 等工具出现之前，它们需要使用不同的语言。有很多改进（资产优化、测试运行、为改进前端性能而必要的服务器端调整等）需要服务器端语言，这意味着大多数前端开发人员往往不会去碰这些。现在，由于这些工具由 JavaScript 驱动，前端开发人员更有可能自己进行这些更改。
无论何时我们获取技术栈的一部分并使其更容易被更广泛的受众所接受，我们都会看到创造力和创新的爆发。这正是构建流程和打包程序发生的事情。创新的大爆发在很大程度上要归功于扩展了前端开发人员可以触及的范围。
这就是我为什么对边缘计算解决方案感到非常兴奋的原因。
使用 CDN 是您可以做的最有价值的事情之一，可以提高性能并扩展您的覆盖范围。但是，配置该 CDN 并获得最大价值一直超出大多数前端团队的范围。
这种情况正在改变。
Cloudflare 有Cloudflare Workers，由 JavaScript 驱动。Akamai 有EdgeWorkers，由 JavaScript 驱动。亚马逊有Lambda@Edge，由 JavaScript 驱动。Fastly 刚刚宣布了Compute@Edge，它由 WebAssembly 驱动。目前您无法为 Compute@Edge 编写 JavaScript（如果您喜欢，可以编写 TypeScript），但我怀疑这只是时间问题，这种情况很快就会改变。
每个工具都在您的 CDN 和访问您网站的用户之间提供了一个可编程层，使您能够在内容到达用户之前对其进行边缘转换。至关重要的是，所有这些工具都使前端开发人员更容易执行这些操作。
例如，您可以使用任何一个工具在 CDN 上处理所有逻辑，而不是让客户端执行 A/B 测试的所有工作，从而帮助使客户端 A/B 测试（每个注重性能的工程师的烦恼）成为过去。Optimizely 已经在使用这项技术来实现他们自己的 A/B 测试解决方案。
使用第三方资源？边缘计算使通过您自己的 CDN 代理这些请求变得更加容易，从而节省了额外的连接成本并帮助消除单点故障。
自定义错误消息？当然。用户身份验证？没问题。个性化？没问题。由于边缘计算，甚至还出现了一些非常有创意的技术 SEO 工作。
其中一些工作以前是可以实现的，但通常需要深入挖掘过时的用户界面才能找到正确的设置，或者使用完全不同的语言和工具（如 ESI 或 Varnish），这些工具实际上并不存在于它们操作的这个小空间之外。
使任何具有少量 JavaScript 知识的人都能轻松使用这些功能，有可能成为一种释放阀，使人们更容易将一些繁重的工作从客户端设备转移回技术栈中更可预测和可靠的部分。像 Node.js 和 JavaScript 驱动的构建工具一样，它们进一步扩展了前端开发人员的触及范围。
我迫不及待地想看看所有实验的结果。