Используя DOMContentReady рассмотрел антишаблон Google
Член команды библиотеки Google Closure утверждает, что ожидание события DOMContentReady является плохой практикой.
Рассказ - то, что мы не хотим ожидать DOMContentReady (или хуже событие загрузки), так как это приводит к плохому пользовательскому опыту. UI не является быстро реагирующим, пока весь DOM не был загружен из сети. Таким образом, предпочтительный путь состоит в том, чтобы использовать встроенные сценарии как можно скорее.
Так как они все еще не предоставляют больше подробную информацию об этом, поэтому интересно, как они имеют дело с Операцией Прерванное диалоговое окно в IE. Это диалоговое окно является единственной критической причиной, которую я знаю для ожидания DOMContentReady (или загрузка) события.
- Вы знаете какую-либо другую причину?
- Как Вы думаете, что они занимаются той проблемой IE?
5 ответов
Сначала немного объяснения: точка с Inline 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, разработчик должен стратегически включать в себя свой скрипт, чтобы это не произошло. Это не совсем это большая проблема, и не трудно обратиться. Настоящая проблема с этим - это «большая картинка», как описано ниже.
Конечно, все имеет плюсы и минусы.
PORES
- Как только элемент DOM отображается пользователю, какую бы функциональность, которая добавляется к нему JavaScript, практически не сразу доступна (вместо того, чтобы ждать всю страницу для загрузки).
- В некоторых случаях Pro # 1 может привести к более быстрому воспринимаемую время загрузки страницы и улучшенного пользовательского опыта.
Минусы
- В худшем случае вы смешиваете презентацию и бизнес-логику, в лучшем случае вы смешиваете ваш скрипт
- Как указал век .
Я использую эту технику? Нет. Я предпочитаю загружать весь сценарий в конце страницы, непосредственно перед закрытием . Почти в каждом случае это достаточно быстро для воспринимаемой и фактической производительности инициализации эффектов и обработчиков событий.
Это нормально для других людей использовать его? Разработчики собираются делать то, что они хотят / должны получить работу и сделать своих клиентов / боссов / отдел маркетинга счастливыми. Есть компромиссы, а до тех пор, пока вы понимаете и управляете им, вы должны быть в порядке в любом случае.
Одна из причин избегать встроенных скриптов заключается в том, что для этого необходимо разместить перед ними любые библиотеки зависимостей в документе, что, вероятно, сведет на нет прирост производительности встроенных скриптов. Лучшая практика, с которой я знаком, это размещение всех скриптов (в одном запросе HTTP!) в самом конце документа, непосредственно перед