使用DOMContentReady被Google视为反模式

首先有一点解释:内联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问题,开发人员必须从战略上包括他们的脚本,这样就不会发生这种情况。这并不是什么大问题,也不难解决。这方面的真正问题是“大局”,如下所述。

当然,每件事都有利弊。

赞成的意见

2. 在某些情况下,Pro#1可以加快感知页面加载时间并改善用户体验。

欺骗

1. 在最坏的情况下,您混合了演示和业务逻辑,在最好的情况下,您混合了您的 script 包括整个演示文稿,这两项内容都很难管理。在我看来,这两种观点都是不可接受的,社会上大部分人也不可接受。
2. 作为 eyelidlessness 指出,如果所讨论的脚本具有外部依赖项(例如库),则必须首先加载这些依赖项,这将在解析和执行这些依赖项时锁定页面呈现。

我使用这种技术吗? </body> 标签。在几乎所有情况下,这对于效果和事件处理程序的感知和实际初始化性能来说都足够快。

其他人可以使用它吗? 开发人员将做他们想做/需要做的事情来完成工作,并让他们的客户/老板/营销部门高兴。这里有一些取舍,只要你理解并管理它们,你就应该不会有任何问题。

内联脚本的最大问题是无法正确缓存。如果您将所有脚本存储在一个缩小的js文件中(使用编译器),那么浏览器只需为整个站点缓存一次该文件。

如果你的网站比较繁忙,那么从长远来看,这会带来更好的性能。为脚本创建一个单独的文件的另一个优点是,您往往不会“重复您自己”,并尽可能多地声明可重用的函数。DOMContentReady不会导致糟糕的用户体验。至少,它为用户提供了手头上的内容,而不是让用户等待UI加载,这可能最终会让用户感到厌烦。

此外,使用内联脚本并不能确保UI的响应速度比与DOMContentReady一起使用时更快。设想一个场景,您使用内联脚本进行ajax调用。如果你有一张表格要交罚款。如果有多个表单,那么最终会重复ajax调用。。因此每次都重复相同的脚本。最后,它会导致浏览器缓存比在DOM就绪时加载的js文件中分离出来的javascript代码更多的javascript代码。

使用内联脚本的另一大缺点是需要维护两个独立的代码库:一个用于开发,另一个用于生产。您必须确保两个代码基保持同步。开发版本包含代码的非精简版本,生产版本包含精简版本。这是开发周期中的一大难题。您必须手动将隐藏在那些庞大html文件中的所有代码片段替换为缩小版本,并且最终希望没有代码中断!然而,由于在开发周期中维护一个单独的文件,您只需要在生产代码库中用编译的简化版本替换该文件。

使用外部JavaScript和CSS 因为文件是由 HTML文档中的内联 每次下载HTML文档时 请求。这减少了数量 HTTP请求的数量,但增加了 HTML文档大小。另一方面 浏览器缓存的外部文件, HTML文档大小减小

etag .

避免内联脚本的一个原因是,它要求您在文档中将任何依赖项库放在它们之前,这可能会抵消内联脚本的性能提升。我熟悉的最佳实践是将所有脚本(放在一个HTTP请求中!)在文件的最后,就在 </body>

如果没有魔杖,我们总是要做出这些取舍。谢天谢地,HTML文档本身将越来越成为所提出的资源密集度最低的请求(除非您正在做一些愚蠢的事情,比如大型应用程序) data: URL和庞大的内联SVG文档)。对我来说,等待HTML文档结束的权衡似乎是最明显的选择。

我认为这个建议并没有真正的帮助。DOMContentReady可能只是一种不好的做法,因为它目前被过度使用(可能是因为jquery易于使用的ready事件)。许多人把它作为一次“启动”活动 任何 javascript操作。尽管jQuery的ready()事件也只是用来作为DOM操作的启动点。

根据推断,页面加载上的DOM操作会导致糟糕的用户体验!!因为 它们不是必需的 ,服务器端可以完全生成初始页面。

那么,也许闭包团队成员只是试图朝相反的方向走,阻止人们对页面加载进行DOM操作?

如果您需要自己处理HTML,谷歌的方法似乎非常笨拙。他们使用编译的方法,并且可能在其他问题上浪费他们的大脑周期,考虑到他们应用程序的复杂用户界面,这是明智的。如果你想要一些要求更宽松的东西(阅读:几乎所有其他东西),可能不值得付出努力。

但遗憾的是,GWT只会说Java。

这可能是因为谷歌不在乎你是否有Javascript,他们做任何事情都需要它。如果您在已经运行的网站上使用Javascript作为补充,那么在DOMContentReady中加载脚本就可以了。关键是使用Javascript来增强用户体验,而不是在用户没有Javascript的情况下将其隔离。