使用DOMContentReady被Google视为反模式

Question

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

简短的故事是我们不想等待DOMContentReady(或更糟糕的加载事件),因为它会导致糟糕的用户体验.在从网络加载所有DOM之前,UI不响应.因此,首选方法是尽快使用内联脚本.

由于他们仍然没有提供更多关于此的细节,所以我想知道他们如何处理IE中的Operation Aborted对话框.这个对话框是我知道等待DOMContentReady(或load)事件的唯一关键原因.

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>标记之前加载页面末尾的所有脚本.几乎在所有情况下,这对于效果和事件处理程序的感知和实际初始化性能来说足够快.

其他人可以使用它吗？开发商会做他们想要的东西/需要完成的工作,使他们的客户/老板/市场营销部门开心.有一些权衡,只要你理解和管理它们,你应该没办法.