Что такого плохого в DOM?

Я продолжаю слышать, как люди (в частности, Крокфорд) говорят, что DOM - ужасный API, но на самом деле не оправдывают это утверждение. Помимо кросс-браузерных несоответствий, по каким причинам DOM считается настолько плохим?

Крокфорд выступил с обширной презентацией под названием «Неудобный API: теория дома», где он более или менее объясняет свое мнение о DOM. Это длинновато (1ч 18м), но, как и большинство презентаций Крокфорда, оно довольно приятное и познавательное.

Несоответствия между браузерами, кажется, являются его главной заботой, и я согласен, что это самая раздражающая вещь в DOM. Он определяет:

• Запатентованные ловушки (ловушки браузера и сервера),
• Нарушение правил,
• Корпоративная война,
• Чрезвычайное давление времени

поскольку ключевые проблемы, стоящие за различными несоответствиями, никогда не предполагали добавления этой презентации, сеанса или интерактивности в первоначальное видение сети. Вот некоторые примеры несоответствий:

• document.all, только функция Microsoft,
• Дело в том, что nameи idраньше были взаимозаменяемыми.
• различные функции по извлечению узлов:
  
  • document.getElementById(id),
  • document.getElementsByName(name),
  • *node*.getElementsByTagName(tagName))

и продолжаем еще несколькими примерами, в основном нацеленными на обход DOM, утечки памяти, а также накапливание и всплытие событий. Существует краткий слайд под названием «The Cracks of DOM», который резюмирует:

• Список ошибок DOM включает в себя все ошибки в браузере.
• Список ошибок DOM включает в себя все ошибки во всех поддерживаемых браузерах.
• Ни один DOM полностью не реализует стандарты.
• Большая часть DOM не описана ни в одном стандарте.

Короче говоря, это грязный, грязный API. Это может показаться придиркой, но вы должны иметь в виду, что когда вы разрабатываете для Интернета, вы редко выбираете браузер, который будут использовать ваши клиенты. Необходимость проверить все как минимум в двух версиях каждого из основных браузеров очень скоро устареет. Предполагается, что API должен быть согласованным, а DOM стал жертвой войн браузеров , но становится все лучше. Он по-прежнему не так независим от платформы, как хотелось бы W3C (и я думаю, что все мы), но производители браузеров, похоже, гораздо охотнее сотрудничают, чем пять или десять лет назад.

Что не так с DOM? Кроме вдохновенного Java-синтаксиса (который Крокфорд затронул), ничего.

Что «не так» относится частично к поставщикам браузеров; что «не так» относится к разработчикам; что «неправильно» относится к невежеству.

Итак, с чего начать?

Вниз по кроличьей норе…

Поставщики браузеров

Во-первых, производители браузеров на протяжении десятилетий боролись за то, чтобы стать «лучшими», «самыми быстрыми», «самыми простыми» и т. Д. В течение первого десятилетия (199–2000) корпорация Microsoft владела насестом. Internet Explorer представил инновационные идеи, такие как:

• разоблачение HTML-движка браузера как innerHTMLи outerHTML;
• легкая текстовая манипуляция с innerTextи outerText;
• модель событий ( *tachEvent), которая была образцом для событий DOM уровня 2 ( *EventListener).

Каждый из них (как в лучшую, так и в худшую сторону) внес значительный вклад в сегодняшний стек веб-разработки. Opera даже зашла так далеко, что реализовала все три в версии 7 (2003).

Однако у Netscape была своя собственная модель событий DOM ( *EventListener). В 2000 году он стал спецификацией DOM Level 2 Events. Safari 1 (2003) реализовал эту модель; Opera 7 (2003) также реализовала эту модель. Когда руины Netscape стали Mozilla, Firefox 1 (2004) унаследовал модель.

В первом разделе второго десятилетия (2000—2004) Microsoft безраздельно властвовала. Internet Explorer 6 (2001) был лучшим браузером того времени. Один из ее конкурентов, Opera 6 (2001), еще не внедрил ядро ​​DOM Level 1 ( createElementи др.). Microsoft внедрила его в Internet Explorer 4 (1997), прежде чем спецификация стала рекомендацией (1998).

Тем не менее, второй раздел второго десятилетия (2004—2010) может оказаться катастрофическим для Microsoft. В 2003 году Apple выпустила Safari 1.0; в 2004 году Mozilla завершила Firefox 1.0. Microsoft, казалось бы, спала на своем троне на вершине горы браузера. Internet Explorer 7 не был выпущен до 2006 года: промежуток в пять лет со дня выпуска Internet Explorer 6. В отличие от версий Internet Explorer с 4 по 6, в версии 7 мало что изменилось; Изменения DOM были минутными. Спустя почти два с половиной года Internet Explorer 8 был выпущен. Microsoft проснулась от своего дремоты и заметила слияние других производителей браузеров вокруг многочисленных веб-стандартов. К сожалению, прошло слишком много времени с момента последнего настоящего нововведения Microsoft. Движение было создано среди поставщиков браузеров. Новые функции DOM должны были быть добавлены в виде спецификации к W3C; Идеи Microsoft остались в прошлом. Модель событий Microsoft (*tachEvent) был исключен для модели DOM Level 2 Events. Internet Explorer не реализовывал предыдущую модель до версии 9 (2011), которая стала моделью событий DOM уровня 3.

Глупости Microsoft (DOM) можно суммировать по следующим пунктам:

• присутствие в качестве основной функции Windows и вытекающие из этого требования безопасности на уровне ОС;

• использование ActiveX для клиентского кода;

• новшество, которое с любопытством кончилось после версии 6 (2001).

(Веб) Разработчики

Во-вторых, разработчики несут определенное количество вины. Поскольку сеть продолжает развиваться, все больше и больше людей «зацикливаются» на веб-разработке. Это привело к разбавлению таланта и трудовой этики. Проблема, однако, в основном связана с отношением. «Сделай это быстро» имеет приоритет над «Сделай это правильно». В результате, бесчисленные веб-страницы несовместимы с различными браузерами. Одной из основных причин этой несовместимости является практика, называемая «анализ кода пользовательского агента». Хотя практика все еще используется сегодня, она была доказана как ошибочная и вредная. Opera даже зашла так далеко, что «заморозила» версию пользовательского агента на уровне «9.80» в версии 10 (2009) и выше. Это было сделано для предотвращения взлома ошибочных скриптов. Гораздо лучшая практика называется

Невежество

В-третьих, я предпочитаю обвинять в невежестве; незнание того факта, что производители браузеров не работали вместе достаточно для создания унифицированных спецификаций; незнание того факта, что Microsoft избегает пользователей других браузеров; игнорирование того факта, что разработчики либо слишком ленивы, либо слишком близки к тому, чтобы беспокоиться о поиске браузеров (особенно тех, которые не в моде ). Существует много различий в API и реализациях. Многого можно избежать с помощью упрощенного, но все же оборонительного подхода (опоры на DOM 0), а также большого количества исследований и испытаний. Незнание привело к мысли, что Internet Explorer 6 - упадок на Земле (вспомните его место на троне браузера, упомянутом ранее).

отражение

К сожалению, DOM - это просто неправильно понятый API. Многие хотят бросать камни (через FUD), но немногие хотят изучать его тонкости. Одним из результатов этого невежества является введение DOM "селекторов". DOM в основе - это API для управления деревом документов. Обход дерева должен использоваться для сложных задач, принимая форму проанализированного документа. С появлением DOM Selectors API разработчик теперь может использовать механизм обхода CSS браузера. Это довольно удобно, но оно скрывает истинную форму дерева документов. С «селекторами» поиск узла элемента является элементарным. Тем не менее, DOM имеет одиннадцать других указанных типов узлов. Что из текстовых узлов? Узлы комментариев? Узлы документа? Это также узлы, которые часто требуются при взаимодействии с DOM.

Вывод

Короче, не торопитесь и читайте различные спецификации DOM. Протестируйте код в максимально возможном количестве браузеров. Если Internet Explorer ведет себя странно, обратитесь в MSDN. Чаще всего поведение документируется.

(Исторические анекдоты могут быть и могут быть неточными; любые неточности приветствуются.)

Матф

DOM - ужасный API

Это НЕПРАВИЛЬНО . DOM НЕ ужасный API.

• Во-первых, помните, что DOM не зависит от языка. Все основные языки реализовали API. Это потому, что вы просто не используете его в браузере, но везде вам нужно иметь дело с XML.

• Во-вторых, обратите внимание, что DOM определяет не классы, а интерфейсы. Это имеет очень важное значение: языки могут реализовывать его так, как это соответствует их конструкциям и философии. Это освобождает все языки от необходимости быть последовательными в реализации с другими.

• В-третьих, DOM - это один из двух основных способов анализа XML (другим является SAX), и, в зависимости от вашего контекста, DOM может быть очень эффективным.

То, что вы имеете в виду, это браузер DOM. И я согласен, что DOM "плохо себя чувствует" в браузере. Часть причины - несовместимость браузера. Но я не согласен с тем, что они являются единственной причиной плохой репутации DOM в браузере.

• Во-первых, если подумать, DOM является одной из тех областей, где эти несовместимости относительно легче преодолеть. Для сравнения, события, например, намного сложнее и раздражают, чтобы нормализовать.

• Во-вторых, обнаружение функций для функций DOM проще, чем для других областей.

• В-третьих, DOM 3 намного лучше - и сегодня все браузеры поддерживают большинство из них.

Конечно, несовместимости раздражают, но когда вы к ним обращаетесь, DOM гораздо меньше раздражает.

Я также не согласен с причинами, такими как проприетарные ловушки, корпоративные войны и т. Д.

• Я думаю, что это несоответствие между философией JavaScript, являющейся облегченным языком, и реализацией DOM, вдохновленной Java - это во многом способствовало разочарованию.

• Во-вторых, DOM был разработан для XML, и он был адаптирован для HTML. Следовательно, в браузере у нас есть ровно две DOM - HTML DOM и XML DOM - и они несовместимы.

• В-третьих, обход DOM в браузере не очень хорош. У нас нет XPath для HTML DOM, поэтому до движков CSS-селекторов было очень утомительно проходить обходы.

Наконец, я думаю, что сегодня , когда современные браузеры (и старые браузеры постепенно исчезают), нет причин, по которым DOM нужно называть плохим. В браузере, безусловно, будет лучше - и API, и реализация.