使用DOMContentReady被Google视为反模式 [英] Using DOMContentReady considered anti-pattern by Google

问题描述

Google Closure图书馆团队成员断言等待DOMContentReady事件是一种不好的做法。

A Google Closure library team member asserts that waiting for DOMContentReady event is a bad practice.

短篇小说是我们不希望
等待DOMContentReady（或更糟糕的是
加载事件），因为它会导致糟糕的
用户体验。在所有DOM都是从网络加载的
之前，UI不是
响应。因此，
首选方式是尽快使用内联脚本
。

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 对话框。这个对话框是我知道等待DOMContentReady（或load）事件的唯一重要原因。

Since they still don't provide more details on this, so I wonder how they deal with Operation Aborted dialog in IE. This dialog is the only critical reason I know to wait for DOMContentReady (or load) event.

1. 您知道其他原因吗？


2. 您认为他们如何处理IE问题？ ？

推荐答案

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

A little explanation first: The point with inline JavaScript is to include it as soon as possible. However, that "possible" is dependent on the DOM nodes that that script requires being declared. For example, if you have some navigation menu that requires JavaScript, you would include the script immediately after the menu is defined in the 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问题，开发人员必须战略性地包含他们的脚本，以便不会发生这种情况。这不是一个很大的问题，也不是很难解决。真正的问题是大局，如下所述。

As long as you only address DOM nodes that you know have been declared, you wont run into DOM unavailability problems. As for the IE issue, the developer must strategically include their script so that this doesn't happen. It's not really that big of a concern, nor is it difficult to address. The real problem with this is the "big picture", as described below.

当然，一切都有利有弊。

1. 只要向用户显示DOM元素，无论其功能如何通过JavaScript添加它几乎立即可用（而不是等待整个页面加载）。


2. 在某些情况下，Pro＃1可以加快感知页面加载时间和/或改进的用户体验。

缺点

Cons

1. 最糟糕的是，你混合了演示和业务逻辑，最好在整个演示文稿中混合使用脚本，这两者都很难管理。在我看来，以及社区的大部分人都不能接受。


2. 作为 eyelidlessness 指出，如果有问题的脚本有外部依赖项（例如一个库），那么必须先加载那些依赖项，这将锁定页面在解析和执行它们时进行渲染。

1. At worst, you're mixing presentation and business logic, at best you're mixing your script includes throughout your presentation, both of which can be difficult to manage. Neither are acceptable in my opinion as well as by a large portion of the community.
2. As eyelidlessness pointed out, if the script's in question have external dependencies (a library for example), then those dependencies must be loaded first, which will lock page rendering while they are parsed and executed.

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

Do I use this technique? No. I prefer to load all script at the end of the page, just before the closing </body> tag. In almost every case, this is sufficiently fast for perceived and actual initialization performance of effects and event handlers.

其他人可以使用吗？开发人员将按照他们想要/需要的方式完成工作并制作他们的客户/老板/营销部门很高兴。有权衡，只要你理解和管理它们，你应该没办法。

Is it okay for other people to use it? Developers are going to do what they want/need to get the job done and to make their clients/bosses/marketing department happy. There are trade-offs, and as long as you understand and manage them, you should be okay either way.

这篇关于使用DOMContentReady被Google视为反模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！