网站是否应该在没有 JavaScript 的情况下运行？

JS Party 播客刚刚发布了 一个有趣的剧集，他们在剧集中将听众分成两组，并就这个经典问题进行了辩论。 每组被分配到辩论的“一方”，然后自由地进行辩论。 我认为没有人能像这样听完一场节目而不被各种想法所淹没！ 这些是我的想法。

• 这是一个已经持续了多年的“圣战”辩论。 也许是因为人们正在寻找一个适用于整个网络的答案，而网络太大了，无法将如此广泛的答案固定到它身上。
• 这个问题本身值得一看。 为什么我们谈论以这种特殊的方式削弱我们的网站？ 我们的网站是否应该在没有 HTML 的情况下运行？ 我们的网站是否应该在没有数据库的情况下运行？ 也许我们最关注 JavaScript，因为 JavaScript 已经成为 网络性能的最大瓶颈（甚至超过网络！），而且我们体验到 JavaScript 失败的次数比任何其他类型的网络故障都要多（除了，也许，整个网站无法加载）(或 图标字体，天哪)。
• 我喜欢围绕“网络应用”和“网站”(网络事物！) 的术语进行的所有磕磕绊绊。 这是一个奇怪的问题。 在你的脑海中很容易想象出它们之间的区别：就像 Facebook 和博客！ 但是，当你开始尝试准确地定义它时，它会很快变得非常模糊，区别也会失去任何价值，即使它一开始有任何价值。 更多信息请点击此处。
• 辅助技术肯定参与了所有关于网络的对话，但它可能无法在这里广泛应用。 有人认为辅助技术不会运行 JavaScript——因此，一个需要 JavaScript 才能使用的网站对于这些用户来说是 100% 的失败。 就我所知，情况已不再如此。 我们可以无休止地争论 JavaScript 在辅助技术问题中的作用，但仅仅因为一个特定网站需要 JavaScript 才能运行并不意味着该网站本身无法访问。
• 关闭 JavaScript，在网络上浏览，找到损坏的内容，并因这种明显的故障而嘲讽它们，这很容易。 这种故障是，该网站或网站上的某个功能本可以被设计成在没有 JavaScript 的情况下运行。 最小权限原则。 这是一个棘手的问题。 很容易不关心一个故意禁用部分网络浏览器但仍然希望一切正常工作的人。 我完全不关心那个人。 但是弹性部分更有趣。 如果您确实构建了一个可以在没有 JavaScript 的情况下运行的网站部分，那么它将在 JavaScript 执行之前和之后都能够运行，这非常棒。
• 在没有 JavaScript 的情况下构建功能性内容和功能，然后用 JavaScript 增强体验的概念称为渐进增强。 我既是它的粉丝，又谨慎地不强求地球上的一切都以这种方式构建（参见上面的要点）。 有些情况下，渐进增强会增加和减少技术债务。 我唯一要广泛使用的东西就是说，直到债务过高之前，它都是值得做的。
• 渐进增强有一个中间时刻。 如果一个功能在没有 JavaScript 的情况下是可用的，那么这意味着您可能是在推迟 JavaScript 的加载以获得性能优势。 但是它最终需要下载并执行。 那段时间会发生什么？ 这里存在性能和 UX 成本。 最好情况下，它可以忽略不计。 最坏情况下，您会在这段过渡时间内破坏该功能。
• 我认为在逐个网站和逐个功能的基础上讨论这种问题更有意思。 应用原型 可能是对它进行范围界定的一个有趣方法。 他们经常以 Slack 作为例子，这是一个完美的选择。 你将如何构建一个有 20 位作者的电影评论网站？ 你将如何架构一个像 Dribbble 这样注重社交和媒体的网站？ 你如何构建下拉导航？ 如何构建一个客户想要视差效果的单页宣传册网站？ 如何构建一个也需要原生移动应用的航空公司应用？ 当然，它也会让你思考你自己正在使用的网站。 CodePen 是否运行在正确的技术集上？ CSS-Tricks 呢？
• 如果一个网站是“客户端渲染”(CSR)，那么这意味着 JavaScript 正在执行数据获取和创建 DOM 等操作。 如果我们谈论网站在有或没有 JavaScript 的情况下“运行”与否，那么一个客户端渲染的网站在没有 JavaScript 的情况下将 100% 失败。 它有点像“服务器端渲染”(SSR) 的反面，其中文档直接从服务器作为 HTML 下载。 SSR 几乎肯定对于首次加载体验更快。 CSR 通常在加载后更容易在网站上移动（想想“单页应用”或 SPA)。
• 不仅仅是 SSR 与 CSR——存在一个完整的频谱。 越来越多的网站试图利用两者的最佳优势。 例如，Next/Nuxt/Gatsby 或 Ember 的 fastboot。
• 服务工作者是 JavaScript。 Web 工作者是 JavaScript。 网络的一些花哨的弹性和性能功能是由导致我们辩论的悲伤的同一技术驱动的。