javascript - 使用 DOMContentReady 被 Google 视为反模式

Question

Google Closure 库团队成员 asserts等待 DOMContentReady 事件是一种不好的做法。

The short story is that we don't want to wait for DOMContentReady (or worse the load event) since it leads to bad user experience. The UI is not responsive until all the DOM has been loaded from the network. So the preferred way is to use inline scripts as soon as possible.

由于他们仍然没有提供更多详细信息，所以我想知道他们如何处理Operation Aborted IE 中的对话框。该对话框是我所知道的等待 DOMContentReady(或加载)事件的唯一关键原因。

1. 您还知道其他原因吗？
2. 您认为他们如何处理 IE 问题？

Answer 1

首先解释一下:内联 JavaScript 的要点是尽快包含它。然而，这个“可能”取决于该脚本需要声明的 DOM 节点。例如，如果您有一些需要 JavaScript 的导航菜单，您可以在 HTML 中定义菜单后立即包含该脚本。

<ul id="some-nav-menu">
    <li>...</li>
    <li>...</li>
    <li>...</li>
</ul>
<script type="text/javascript">
    // Initialize menu behaviors and events
    magicMenuOfWonder( document.getElementById("some-nav-menu") );
</script>

只要您只处理已知已声明的 DOM 节点，就不会遇到 DOM 不可用问题。至于 IE 问题，开发人员必须策略性地包含他们的脚本，这样就不会发生这种情况。这其实并不是一个大问题，也不难解决。真正的问题是“大局”，如下所述。

当然，凡事有利有弊。

优点

1. 一旦向用户显示 DOM 元素，JavaScript 添加到其中的任何功能几乎都可以立即使用(而不是等待整个页面加载)。
2. 在某些情况下，Pro #1 可以加快感知页面加载时间并改善用户体验。

缺点

1. 在最坏的情况下，您会混合演示和业务逻辑，在最好的情况下，您会混合script包括整个演示文稿，两者都可能很难管理。在我看来，以及社区的大部分人都无法接受。
2. 如eyelidlessness指出，如果相关脚本具有外部依赖项(例如库)，则必须首先加载这些依赖项，这将在解析和执行它们时锁定页面渲染。

我使用这种技术吗？不。我更喜欢在页面末尾加载所有脚本，就在结束 </body> 之前。标签。几乎在每种情况下，对于效果和事件处理程序的感知和实际初始化性能来说，这都足够快。

其他人可以使用它吗？开发人员将做他们想要/需要的事情来完成工作并让他们的客户/老板/营销部门满意。权衡是存在的，只要您理解并管理它们，无论哪种方式都应该没问题。