Що такого поганого в DOM?

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

Крокфорд виступив з великою презентацією під назвою "Незручний API: Теорія Дому", де він більш-менш пояснює свою думку щодо DOM. Він довгий (1 год. 18 м.), Але, як і більшість презентацій Крокфорда, він дуже приємний та повчальний.

Невідповідності перехресних веб-браузерів, здається, є його основною проблемою, і я погоджуюся, що це найбільше дратує DOM. Він визначає:

• Власні пастки (пастки для браузера та сервера),
• Порушення правил,
• Корпоративна війна,
• Екстремальний часовий тиск

як ключові питання, що стоять за різними невідповідностями, додаючи, що презентація, сеанс чи інтерактивність ніколи не передбачалася в первісному баченні Інтернету. Деякі приклади невідповідностей включають:

• document.all, функція лише для Microsoft,
• те, що nameі idраніше було взаємозамінним.
• різні функції для отримання вузлів:
  
  • document.getElementById(id),
  • document.getElementsByName(name),
  • *node*.getElementsByTagName(tagName))

і продовжує ще кілька прикладів, в основному націлені на обхід DOM, витоку пам’яті та обдурювання подій та бурчання. Існує підсумковий слайд під назвою "Тріщини DOM", який резюмує:

• Список помилок DOM включає всі помилки в браузері.
• Список помилок DOM включає всі помилки у всіх підтримуваних браузерах.
• Жоден DOM повністю не виконує стандарти.
• Значна частина DOM не описана в жодному стандарті.

Словом, це безладний, безладний API. Це може здатися прищеплювачем, але ви повинні пам’ятати, що, коли ви розробляєте для Інтернету, ви рідко отримуєте вибір веб-переглядача, яким користуватимуться ваші клієнти. Тестування всього щонайменше у двох версіях кожного з основних браузерів старіє дуже скоро. API повинен бути послідовним, і DOM став жертвою війн браузера , але все краще. Це все ще не настільки нейтрально на платформі, як хотілося б W3C (і я думаю, що всі ми), але постачальники браузерів, схоже, бажають співпрацювати, ніж вони були п'ять-десять років тому.

Що не так з DOM? Крім синтаксису, натхненного Явою (якого він торкнувся Крокфорд), нічого.

Що "неправильно", частково стосується постачальників браузерів; що "неправильно" стосується розробників; що "неправильно" стосується незнання.

Отже, з чого почати?

Вниз по кролячій норі…

Постачальники веб-переглядачів

По-перше, постачальники браузерів протягом десятиліть конкурували в боротьбі за те, щоб бути "найкращим", "найшвидшим", "найпростішим" тощо. У першому десятилітті (199x - 2000 р.) Microsoft керувала верхом. Internet Explorer представив інноваційні ідеї, такі як:

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

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

Однак у Netscape була своя модель подій DOM ( *EventListener). У 2000 році вона стала специфікацією подій DOM рівня 2. Safari 1 (2003) реалізував цю модель; Opera 7 (2003) також реалізувала цю модель. Оскільки руїни Netscape стали Mozilla, Firefox 1 (2004) успадкував цю модель.

У першому розділі другого десятиліття (2000—2004) Microsoft панувала верховенством. Internet Explorer 6 (2001) був далеко не найкращим браузером того часу. Один з його конкурентів, Opera 6 (2001), ще не впроваджував DOM Level 1 Core ( 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. Створено рух серед постачальників браузерів. У W3C повинні бути додані нові характеристики DOM у специфікаційній формі; Ідеї ​​Microsoft залишилися в минулому. Модель подій Microsoft (*tachEvent) було виключено для моделі подій DOM рівня 2. 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 для маніпулювання деревом документів. Обхід дерева слід використовувати для складних проблем, надаючи форму проаналізованого документа. Завдяки впровадженню 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, натхненним Явою, - це сприяло великій кількості розладів.

• По-друге, DOM був розроблений для XML, і він був адаптований для HTML. Отже, у браузері у нас рівно два DOM - HTML DOM та XML DOM - і вони несумісні.

• По-третє, обхід DOM у браузері не дуже добре. У нас немає XPath для HTML DOM, тому перед двигунами для вибору CSS було дуже нудно робити обходи.

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