나는 document.write나쁜 습관으로 간주된다는 것을 안다 . 그리고 제 3 자 공급 업체에 제출하여 document.write분석 코드 구현에 사용해서는 안되는 이유에 대한 이유 목록을 작성하고 싶습니다 .

document.write아래에 잘못된 관행 이라고 주장한 이유를 포함하십시오 .

더 심각한 문제 중 몇 가지 :

• XHTML에서는 document.write (이후 DW)가 작동하지 않습니다

• DW는 DOM을 직접 수정하지 않으므로 추가 조작을 방지 할 수 있습니다 (증거를 찾으려고하지만 상황이 가장 좋습니다).

• 페이지로드가 완료된 후 실행 된 DW는 페이지를 덮어 쓰거나 새 페이지를 쓰거나 작동하지 않습니다.

• DW는 마주 친 곳에서 실행됩니다. 주어진 노드 포인트에 주입 할 수 없습니다

• DW는 직렬화 된 텍스트를 효과적으로 작성합니다. 이는 DOM이 개념적으로 작동하는 방식이 아니며 버그를 만드는 쉬운 방법입니다 (.innerHTML도 같은 문제가 있습니다)

안전하고 DOM 친화적 인 DOM 조작 방법 을 사용하는 것이 훨씬 좋습니다

실제로 document.write는 그 자체로 는 아무런 문제가 없습니다 . 문제는 오용하기가 정말 쉽다는 것입니다. 심하게도.

Google 애널리틱스와 같은 애널리틱스 코드를 제공하는 벤더 측면에서 실제로 이러한 스 니펫을 배포하는 가장 쉬운 방법입니다

1. 스크립트를 작게 유지합니다
2. 이미 설정된 onload 이벤트를 재정의하거나 onload 이벤트를 안전하게 추가하기 위해 필요한 추상화를 포함 할 것에 대해 걱정할 필요가 없습니다.
3. 매우 호환됩니다

만큼 당신이 문서가로드 된 후 그것을 사용하려고하지 않는 한 ,document.write내 소견으로, 본질적으로 악하지 않다.

또 다른 합법적 인 사용은 document.writeHTML5 Boilerplate index.html 예제 에서 비롯됩니다 .

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.6.3.min.js"><\/script>')</script>

또한 json2.js JSON 구문 분석 / stringify polyfill ( IE7 이하에서 필요) 을 사용하는 것과 동일한 기술을 보았습니다 .

<script>window.JSON || document.write('<script src="json2.js"><\/script>')</script>

페이지를 차단할 수 있습니다

document.write페이지가로드되는 동안에 만 작동합니다. 페이지로드가 완료된 후 호출하면 전체 페이지를 덮어 씁니다.

즉, 인라인 스크립트 블록에서 호출해야합니다. 그러면 브라우저가 다음 페이지의 일부를 처리하지 못합니다. 쓰기 블록이 완료 될 때까지 스크립트와 이미지는 다운로드되지 않습니다.

찬성:

• 외부 (호스트 / 도메인) 스크립트에서 인라인 컨텐츠를 포함하는 가장 쉬운 방법입니다.
• 프레임 / iframe에서 전체 내용을 덮어 쓸 수 있습니다. 더 현대적인 Ajax 기술이 널리 사용되기 전에 (1998-2002) 메뉴 / 탐색 조각에이 기술을 많이 사용했습니다.

범죄자:

• 이 스크립트는 외부 스크립트가로드 될 때까지 일시 중지되도록 렌더링 엔진을 직렬화하여 내부 스크립트보다 훨씬 오래 걸릴 수 있습니다.
• 일반적으로 스크립트가 내용 내에 배치되는 방식으로 사용되며 이는 잘못된 형식으로 간주됩니다.

여기에 두 가지 가치가 있습니다. 일반적으로 document.write무거운 물건을 들어서는 안되지만 확실히 유용한 한 가지 예가 있습니다.

http://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html

최근에 AJAX 슬라이더 갤러리를 만들려는 것을 발견했습니다. 두 개의 중첩 된 div를 만들고 JS로 width/ height및 overflow: hidden외부에 적용했습니다 <div>. 브라우저가 JS를 사용하지 않도록 설정 한 경우 div가 갤러리의 이미지를 수용 할 수 있도록 떠 오릅니다.

위의 기사와 마찬가지로 CSS의 JS 하이재킹은 페이지가로드 될 때까지 시작되지 않아 div 가로 드 될 때 순간적으로 플래시가 발생했습니다. 따라서 페이지가로드 될 때 CSS 규칙을 작성하거나 시트를 포함해야했습니다.

분명히 이것은 XHTML에서 작동하지 않지만 XHTML은 죽은 오리의 것으로 보이므로 IE에서 태그 수프로 렌더링되므로 DOCTYPE 선택을 다시 평가할 가치가 있습니다 ...

가장 명백한 이유 인 페이지의 내용을 덮어 쓰지만 "나쁜"것으로 부르지는 않습니다.

JavaScript를 사용하여 전체 문서를 작성하지 않으면 document.write로 시작할 수 없다면 많이 사용하지 않습니다.

그럼에도 불구하고 document.write를 사용할 때 DOM을 실제로 활용하지는 않습니다. 문서에 텍스트 덩어리를 덤핑하여 형식이 잘못되었다고 말할 수 있습니다.

XHTML 페이지와 같은 XML 렌더링을 사용하여 페이지를 분할합니다.

최고 : 일부 브라우저는 HTML 렌더링으로 다시 전환되며 모든 것이 잘 작동합니다.

가능성 : 일부 브라우저는 XML 렌더링 모드에서 document.write () 함수를 비활성화합니다.

최악 : 일부 브라우저는 document.write () 함수를 사용할 때마다 XML 오류를 발생시킵니다.

내 머리 꼭대기에서 :

1. document.write페이지로드 또는 본문로드에 사용해야합니다. 따라서 다른 시간에 스크립트를 사용하여 페이지 내용을 업데이트하려는 경우 document.write는 거의 쓸모가 없습니다.

2. 기술적으로 document.write XHTML / XML이 아닌 HTML 페이지 만 업데이트합니다. IE는이 사실을 꽤 용서하는 것처럼 보이지만 다른 브라우저는 그렇지 않습니다.

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

document.write경우에 따라 스크립트를 삽입하는 Chrome이 차단 될 수 있습니다 . 이 경우 콘솔에 다음 경고가 표시됩니다.

파서 차단, 교차 출처 스크립트 ...는 document.write를 통해 호출됩니다. 장치의 네트워크 연결 상태가 좋지 않으면 브라우저에 의해 차단 될 수 있습니다.

참고 문헌 :

• developers.google.com에 대한이 기사 는 더 자세히 설명합니다.
• https://www.chromestatus.com/feature/5718547946799104

브라우저 위반

.write파서가 페이지를 렌더링하지 못하도록 브라우저 위반으로 간주됩니다. 파서는 문서가 수정되고 있다는 메시지를받습니다. 따라서 JS가 프로세스를 완료 할 때까지 차단됩니다. 이때에만 파서가 재개됩니다.

공연

이러한 방법을 사용하면 가장 큰 결과로 성능이 저하됩니다. 브라우저는 페이지 내용을로드하는 데 시간이 더 걸립니다. 로드 시간에 대한 부작용은 문서에 기록되는 내용에 따라 다릅니다. 추가하면 큰 차이가 보이지 않습니다.<p>JavaScript 라이브러리에 50-some 참조 배열을 전달하는 것과 반대로 DOM에 태그를 물론 하드웨어에 따라 다릅니다).

도움이 될 수 있다면이 방법을 피하는 것이 가장 좋습니다.

자세한 내용은 document.write ()에 대한 개입을 참조하십시오.

Google-Chrome Dev Tools의 Lighthouse Audit 에서 수행 한 분석을 기반으로 ,

연결 속도가 느린 사용자의 경우 동적으로 삽입 된 외부 스크립트 document.write()는 페이지로드를 수십 초 지연시킬 수 있습니다.

• document.write나쁜 습관이 있는 간단한 이유 는 더 나은 대안을 찾을 수없는 시나리오를 만들 수 없기 때문입니다.
• 또 다른 이유는 객체 대신 문자열을 다루기 때문입니다 (매우 원시적입니다).
• 문서에만 추가됩니다.
• 예를 들어 MVC (Model-View-Controller) 패턴 의 아름다움은 없습니다 .
• ajax + jQuery 또는 angularJS로 동적 컨텐츠를 표시하는 것이 훨씬 강력합니다 .

document.write () (및 .innerHTML)를 소스 코드 문자열을 평가하는 것으로 생각할 수 있습니다. 많은 응용 프로그램에 매우 유용 할 수 있습니다. 예를 들어 어떤 소스에서 HTML 코드를 문자열로 얻는다면 그냥 "평가"하는 것이 편리합니다.

Lisp와 관련하여 DOM 조작은 목록 구조를 조작하는 것과 같습니다 (예 : 다음을 수행하여 목록 (주황색) 작성).

(cons 'orange '())

그리고 document.write ()는 문자열을 평가하는 것과 같습니다. 예를 들어 다음과 같이 소스 코드 문자열을 평가하여 목록을 만듭니다.

(eval-string "(cons 'orange '())")

또한 Lisp에는 목록 조작을 사용하여 코드를 작성하는 데 매우 유용한 기능이 있습니다 (예 : "DOM 스타일"을 사용하여 JS 구문 분석 트리 작성). 즉, "문자열 스타일"대신 "DOM 스타일"을 사용하여 목록 구조를 작성한 다음 해당 코드를 실행할 수 있습니다 (예 : 다음과 같이).

(eval '(cons 'orange '()))

간단한 라이브 편집기와 같은 코딩 도구를 구현하는 경우 예를 들어 document.write () 또는 .innerHTML을 사용하여 문자열을 빠르게 평가할 수있는 기능이 매우 편리합니다. Lisp는 이런 의미에서 이상적이지만 JS에서도 매우 멋진 작업을 수행 할 수 있으며 http://jsbin.com/ 과 같이 많은 사람들이 그렇게하고 있습니다.

document.write의 단점은 주로 다음 세 가지 요소에 따라 다릅니다.

a) 구현

document.write ()는 내용이 필요한 즉시 내용을 화면에 쓰는 데 주로 사용됩니다. 이는 JavaScript 파일 또는 HTML 파일 내의 스크립트 태그 내에서 발생합니다. 스크립트 태그가 이러한 HTML 파일의 어느 곳에 나 배치되면 웹 페이지 내의 HTML과 얽힌 스크립트 블록 내에 document.write () 문을 갖는 것이 좋지 않습니다.

b) 렌더링

잘 설계된 코드는 일반적으로 동적으로 생성 된 컨텐츠를 가져 와서 메모리에 저장하며, 코드가 화면에 튀어 나오기 전에 코드를 통과 할 때 계속 조작합니다. 따라서 이전 섹션의 마지막 요점을 되풀이하기 위해 적절한 위치에 컨텐츠를 렌더링하면 신뢰할 수있는 다른 컨텐츠보다 더 빠르게 렌더링 할 수 있지만 처리를 위해 컨텐츠를 렌더링해야하는 다른 코드에서는 사용할 수 없습니다. 이 딜레마를 해결하려면 document.write ()를 제거하고 올바른 방법으로 구현해야합니다.

c) 불가능한 조작

일단 작성되면 끝났습니다. DOM을 두드리지 않고는 다시 조작 할 수 없습니다.

나는 document.write를 사용하는 것이 나쁜 습관이라고 생각하지 않습니다. 간단히 말해서 그것은 경험이없는 사람들에게는 고전압과 같습니다. 잘못 사용하면 요리됩니다. 이 방법과 다른 위험한 방법을 한 번 이상 사용한 많은 개발자가 있으며 실제로는 절대 실패하지 않습니다. 대신, 무언가 잘못되면, 그들은 구제되고 더 안전한 것을 사용합니다. 이들은 "나쁜 습관"으로 간주되는 것에 대해 그러한 진술을하는 사람들입니다.

파일을 몇 개만 삭제 한 다음 "드라이브 포맷팅은 좋지 않습니다"라고 말하면 하드 드라이브를 포맷하는 것과 같습니다.

가장 큰 문제는 document.write를 통해 작성된 요소가 페이지 요소 끝에 추가된다는 것입니다. 현대적인 페이지 레이아웃과 AJAX에서 원하는 효과는 거의 없습니다. (DOM의 요소는 일시적이며 스크립트가 실행될 때 동작에 영향을 줄 수 있음을 명심해야합니다.)

페이지에 자리 표시 자 요소를 설정 한 다음 innerHTML을 조작하는 것이 훨씬 좋습니다.