DOM에있어 나쁜 점은 무엇입니까?

나는 사람들 (특히 Crockford)이 DOM이 끔찍한 API라고 말하고 있지만이 진술을 정당화하지는 않습니다. 브라우저 간 불일치 외에도 DOM이 그렇게 나쁜 것으로 간주되는 이유는 무엇입니까?

Crockford는 DOM에 대한 자신의 의견을 어느 정도 설명 하는 "불편한 API : 돔의 이론" 이라는 제목의 광범위한 프레젠테이션을 발표 했습니다. 그것은 길지만 (1 시간 18 분), 대부분의 Crockford의 프리젠 테이션은 꽤 즐겁고 교육적입니다.

브라우저 간 불일치가 그의 주요 관심사 인 것 같습니다. DOM에 대한 가장 성가신 일이라고 동의합니다. 그는 다음을 식별합니다.

• 독점 트랩 (브라우저 및 서버 트랩)
• 규칙 위반,
• 기업 전,
• 극한의 시간 압력

다양한 불일치의 주요 문제는 웹의 원래 비전에서 프레젠테이션, 세션 또는 상호 작용을 추가 한 적이 없었습니다. 불일치의 몇 가지 예는 다음과 같습니다.

• document.allMicrosoft 전용 기능
• 사실 name과 id사용은 교환 할 수있다.
• 노드 검색에 대한 다른 기능 :
  
  • document.getElementById(id),
  • document.getElementsByName(name),
  • *node*.getElementsByTagName(tagName))

DOM 트래버 싱, 메모리 누수, 이벤트 속임수 및 버블 링을 목표로하는 몇 가지 예가 계속 있습니다. "The Cracks of DOM"이라는 제목의 요약 슬라이드가 있습니다.

• DOM 버그 목록에는 브라우저의 모든 버그가 포함됩니다.
• DOM 버그 목록에는 지원되는 모든 브라우저의 모든 버그가 포함됩니다.
• DOM이 표준을 완전히 구현하지는 않습니다.
• 대부분의 DOM은 어떤 표준에도 기술되어 있지 않습니다.

요컨대, 지저분하고 지저분한 API입니다. nitpicking처럼 보일 수 있지만 웹을 개발할 때 고객이 사용할 브라우저를 거의 선택하지 않는다는 점을 명심해야합니다. 각 주요 브라우저의 최소 두 버전에서 모든 것을 테스트 해야하는 것은 곧 오래되었습니다. API는 일관성이 있어야하며 DOM은 브라우저 전쟁 의 희생자 이지만 점점 좋아지고 있습니다. 여전히 W3C (그리고 우리 모두)가 원하는 것처럼 플랫폼 중립적 이지는 않지만 브라우저 공급 업체는 5 ~ 10 년 전에보다 협력하기를 간절히 원합니다.

DOM에 어떤 문제가 있습니까? Java에서 영감을 얻은 구문 (Crockford가 다룬) 외에는 아무것도 없습니다.

"잘못된"내용은 브라우저 공급 업체에 부분적으로 적용됩니다. "잘못된"것은 개발자에게 적용됩니다. "잘못 된"것은 무지에 적용됩니다.

어디서부터 시작해야합니까?

토끼 구멍 아래로…

브라우저 공급 업체

첫째, 브라우저 공급 업체는 "최고", "가장 빠른", "가장 쉬운"등으로 수십 년 동안 경쟁적으로 싸워 왔습니다. Microsoft는 처음 10 년 (199x – 2000)에 휴게소를 지배했습니다. Internet Explorer는 다음과 같은 혁신적인 아이디어를 도입했습니다.

• 브라우저의 HTML 파싱 엔진을 innerHTMLand 로 노출 outerHTML;
• 쉽게 텍스트 조작 innerText및 outerText;
• *tachEventDOM 레벨 2 이벤트 ( *EventListener) 의 청사진 인 이벤트 모델 ( )

각각은 오늘날의 웹 개발 스택에 (더 나은 결과를 위해) 크게 기여했습니다. Opera는 버전 7 (2003)에서 세 가지를 모두 구현하기까지했습니다.

그러나 Netscape에는 고유 한 DOM 이벤트 모델 ( *EventListener)이있었습니다. 2000 년에는 DOM Level 2 Events 사양이되었습니다. Safari 1 (2003)은이 모델을 구현했습니다. Opera 7 (2003)도이 모델을 구현했습니다. 넷스케이프 폐허가 모질라가되면서 파이어 폭스 1 (2004)은이 모델을 물려 받았다.

20 년 (2000 ~ 2004)의 첫 번째 부분에서 Microsoft는 최고를 통치했습니다. Internet Explorer 6 (2001)은 당시 최고의 브라우저였습니다. 경쟁 업체 중 하나 인 Opera 6 (2001)은 아직 DOM Level 1 Core ( createElement등) 를 구현하지 않았으며 , 사양이 권장 사항 (1998)이되기 전에 Microsoft는 Internet Explorer 4 (1997)에서이를 구현했습니다.

그러나 두 번째 10 년 (2004—2010)의 두 번째 섹션은 Microsoft에게 비참한 것으로 판명되었습니다. 2003 년에 Apple은 Safari 1.0을 출시했습니다. 2004 년에 Mozilla는 Firefox 1.0을 완성했습니다. 마이크로 소프트는 브라우저 산 꼭대기에있는 보좌에서 잠 들었다. Internet Explorer 7은 2006 년까지 출시되지 않았습니다. Internet Explorer 6의 출시일로 5 년이 지났습니다. Internet Explorer 버전 4 ~ 6과 달리 버전 7은 거의 혁신을 이루지 못했습니다. DOM 변경은 미미했습니다. 거의 2 년 반 후에 Internet Explorer 8이 릴리스되었습니다. 마이크로 소프트는 잠에서 깨어 났고 다른 브라우저 벤더들이 수많은 웹 표준을 중심으로 결속 된 것을 보았습니다. 불행히도 Microsoft의 마지막 혁신 이후 너무 많은 시간이 지났습니다. 브라우저 공급 업체간에 움직임이 생겼습니다. 새로운 DOM 기능이 사양 형식으로 W3C에 추가되었습니다. 마이크로 소프트의 아이디어는 과거에 남아있었습니다. Microsoft의 이벤트 모델 (*tachEvent)는 DOM 레벨 2 이벤트 모델에서 제외되었습니다. Internet Explorer는 DOM 레벨 3 이벤트 모델이 된 버전 9 (2011)까지 이전 모델을 구현하지 않았습니다.

Microsoft (DOM) 어리 석음은 다음과 같이 요약 할 수 있습니다.

• Windows의 핵심 기능으로 존재하며 그에 따른 OS 수준 보안 요구 사항

• 클라이언트 측 코드에 대한 ActiveX 의존;

• 버전 6 (2001) 이후 호기심이 사라지는 혁신.

(웹) 개발자

둘째, 개발자들은 어느 정도의 책임을집니다. 웹이 계속 발전함에 따라 점점 더 많은 사람들이 웹 개발에 "더욱 덤핑"하고 있습니다. 이로 인해 인재와 직장 윤리가 희석되었습니다. 그러나 문제는 주로 태도에 있습니다. "빠른 작업 수행"이 "올바른 작업 수행"보다 우선합니다. 결과적으로 수많은 웹 페이지는 다양한 브라우저와 호환되지 않습니다. 이 비 호환성의 주요 원인 중 하나는 "사용자 에이전트 스니핑"이라는 관행입니다. 이 관행은 오늘날에도 여전히 사용되고 있지만 잘못되고 해로운 것으로 판명되었습니다. Opera는 버전 10 (2009) 이상의 "9.80"에서 사용자 에이전트 버전을 "동결"시키기까지했습니다. 이것은 잘못된 스크립트가 깨지는 것을 방지하기위한 것입니다. "라는 더 나은 연습

무지

셋째, 내가 선호하는 비난은 무지입니다. 브라우저 공급 업체가 통합 사양을 만들 정도로 충분히 협력하지 않았다는 사실에 대한 무지; Microsoft가 다른 브라우저의 사용자를 회피했다는 사실에 대한 무지; 개발자가 하나의 브라우저를 연구 귀찮게 너무 게으른 너무 근시 있다는 사실에 무지 (특히되지 않은 en 유행 .) API와 구현에 많은 차이가 있습니다. 많은 연구와 테스트와 함께 단순화 된 방어 접근 방식 (DOM 0에 의존)을 사용하면 대부분 피할 수 있습니다. 무지로 인해 Internet Explorer 6이 지구를 뒤덮고 있다는 개념이 생겼습니다 (앞서 언급 한 브라우저 왕좌에서 그 자리를 상기하십시오).

반사

안타깝게도 DOM은 오해 된 API 일뿐입니다. 많은 사람들은 (FUD를 통해) 돌을 던지기를 원하지만, 그 복잡한 점을 배우고 싶어하는 사람은 거의 없습니다. 이 무지의 결과는 DOM "선택기"의 도입입니다. 핵심 DOM은 문서 트리를 조작하는 API입니다. 구문 분석 된 문서의 형식이 주어지면 복잡한 문제에 대해 트리 순회를 사용해야합니다. DOM 선택기 API가 도입되면서 개발자는 이제 브라우저의 CSS 순회 엔진을 활용할 수 있습니다. 이것은 매우 편리하지만 문서 트리의 실제 형태를 숨 깁니다. "선택기"를 사용하면 요소 노드 검색이 기본입니다. 그러나 DOM에는 11 개의 다른 노드 유형이 지정되어 있습니다. 텍스트 노드는 무엇입니까? 댓글 노드? 문서 노드? 이들은 또한 DOM과 상호 작용하는 동안 종종 필요한 노드입니다.

결론

요컨대, 시간을 내서 다양한 DOM 사양을 읽으십시오. 가능한 많은 브라우저에서 코드를 테스트하십시오. Internet Explorer가 이상하게 작동한다고 인식되면 MSDN에 문의하십시오. 대부분의 경우 동작이 문서화됩니다.

(역사적 일화는 부정확 할 수 있으며 부정확 할 수 있습니다. 부정확 한 부분은 언제든지 제기 할 수 있습니다.)

-매트

DOM은 끔찍한 API입니다

그게 잘못 입니다. DOM은 끔찍한 API가 아닙니다.

• 먼저 DOM은 언어에 구애받지 않습니다. 모든 주요 언어는 API를 구현했습니다. 브라우저에서 사용하지 않고 XML을 다루어야하는 모든 곳에서 사용하기 때문입니다.

• 둘째, DOM은 클래스가 아니라 인터페이스를 정의합니다. 이것은 매우 중요한 의미를 갖습니다. 언어는 구성과 철학에 맞는 방식으로 언어를 구현할 수 있습니다. 이를 통해 모든 언어가 다른 언어와 일관성있게 구현되지 않아도됩니다.

• 셋째, DOM은 XML (다른 SAX)을 구문 분석하는 두 가지 주요 방법 중 하나이며, 상황에 따라 DOM이 매우 효율적일 수 있습니다.

당신이 말하는 것은 브라우저 DOM입니다. 그리고 나는 DOM이 브라우저에서 "느낀다"는 것에 동의합니다. 이유는 브라우저 비 호환성 때문입니다. 그러나 나는 이것이 브라우저에서 DOM의 나쁜 평판에 대한 유일한 이유라는 것에 동의하지 않습니다.

• 먼저, DOM을 생각해 보면 DOM은 이러한 비 호환성을 비교적 쉽게 극복 할 수있는 영역 중 하나입니다. 이에 비해 예를 들어 이벤트는 정규화하기가 까다 롭고 성가신 일입니다.

• 둘째, DOM 기능에 대한 기능 감지는 다른 영역보다 간단합니다.

• 셋째, DOM 3이 훨씬 우수합니다. 오늘날 모든 브라우저가 대부분을 지원합니다.

확실히, 비 호환성은 성가시다. 그러나 당신이 그것들에 접근하면 DOM은 훨씬 덜 자극적이다.

나는 또한 독점적 함정, 기업 전쟁 등의 이유에 동의하지 않습니다.

• JavaScript가 가벼운 언어라는 철학과 Java에서 영감을 얻은 DOM 구현 사이의 분리 점이라고 생각합니다. 이는 많은 좌절에 기여했습니다.

• 둘째, DOM은 XML 용으로 설계되었으며 HTML에 맞게 조정되었습니다. 따라서 브라우저에는 정확히 두 개의 DOM (HTML DOM과 XML DOM)이 있으며 호환되지 않습니다.

• 셋째, 브라우저의 DOM 순회가 좋지 않습니다. HTML DOM 용 XPath가 없으므로 CSS 선택기 엔진 이전에는 순회를 수행하는 것이 정말 지루했습니다.

마지막으로, 오늘 은 현대 브라우저에서 (그리고 오래된 브라우저는 천천히 사라짐) DOM을 나쁜 것으로 불러야 할 이유가 없다고 생각합니다. API와 구현 모두 브라우저에서 더 나아질 것입니다.