Wiem, że document.writejest uważane za złą praktykę; i mam nadzieję, że opracuję listę powodów, aby przesłać do zewnętrznego dostawcy, dlaczego nie powinni używać document.writew implementacjach swojego kodu analitycznego.

Podaj document.writeponiżej powód zgłoszenia złej praktyki.

Kilka poważniejszych problemów:

• document.write (odtąd DW) nie działa w XHTML

• DW nie modyfikuje bezpośrednio DOM, zapobiegając dalszej manipulacji (próbując znaleźć dowody na to, ale w najlepszym wypadku jest sytuacyjna)

• DW wykonane po zakończeniu ładowania strony nadpisze stronę, napisze nową stronę lub nie będzie działać

• DW wykonuje się tam, gdzie napotkano: nie może wstrzykiwać w danym punkcie węzła

• DW skutecznie pisze serializowany tekst, który nie jest taki, jak DOM działa koncepcyjnie, i jest łatwym sposobem na tworzenie błędów (.innerHTML ma ten sam problem)

Zdecydowanie lepiej jest korzystać z bezpiecznych i przyjaznych DOM metod manipulacji DOM

Właściwie nie ma w tym nic złego document.write. Problem polega na tym, że naprawdę łatwo go niewłaściwie użyć. Nawet rażąco.

Jeśli chodzi o dostawców dostarczających kod analityczny (np. Google Analytics), jest to w rzeczywistości najłatwiejszy sposób na rozpowszechnianie takich fragmentów

1. Dzięki temu skrypty są małe
2. Nie muszą się martwić o zastąpienie już ustanowionych zdarzeń onload lub dołączenie niezbędnej abstrakcji, aby bezpiecznie dodać zdarzenia onload
3. Jest niezwykle kompatybilny

Tak długo, jak długo nie próbujesz go używać po załadowaniu dokumentu ,document.writenie jest on z natury zły, moim skromnym zdaniem.

Kolejne uzasadnione użycie document.writepochodzi z przykładu HTML5 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>

Widziałem również tę samą technikę korzystania z wypełniania JSON json2.js funkcji parsowania / łączenia w polifill ( potrzebne dla IE7 i niższych ).

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

Może zablokować twoją stronę

document.writedziała tylko podczas ładowania strony; Jeśli zadzwonisz po załadowaniu strony, zastąpi ona całą stronę.

Oznacza to, że musisz wywołać go z wbudowanego bloku skryptu - a to uniemożliwi przeglądarce przetwarzanie części następnej strony. Skrypty i obrazy nie zostaną pobrane, dopóki blok zapisu nie zostanie ukończony.

Zawodowiec:

• Jest to najprostszy sposób na osadzenie treści wbudowanej ze skryptu zewnętrznego (do hosta / domeny).
• Możesz zastąpić całą treść ramką / ramką iframe. Często używałem tej techniki do tworzenia menu / elementów nawigacyjnych, zanim bardziej nowoczesne techniki Ajax były szeroko dostępne (1998-2002).

Kon:

• Serializuje silnik renderujący, aby wstrzymać się do momentu załadowania wspomnianego skryptu zewnętrznego, co może potrwać znacznie dłużej niż skrypt wewnętrzny.
• Zwykle jest używany w taki sposób, że skrypt jest umieszczony w treści, co jest uważane za niewłaściwe.

Oto moja wartość podwójna, na ogół nie powinieneś używać document.writedo podnoszenia ciężkich przedmiotów, ale jest jeden przypadek, w którym jest to zdecydowanie przydatne:

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

Odkryłem to niedawno próbując stworzyć galerię suwaków AJAX. Stworzyłem dwa zagnieżdżone div i zastosowałem width/ heighti overflow: hiddenna zewnętrz<div> pomocą JS. Było tak, że w przypadku, gdy przeglądarka wyłączyła JS, div będzie unosić się, aby pomieścić obrazy w galerii - trochę miłej wdzięcznej degradacji.

Chodzi o to, jak w powyższym artykule, to przejęcie CSS przez JS nie rozpoczęło się, dopóki strona się nie załadowała, powodując chwilowe flashowanie podczas ładowania div. Musiałem więc napisać regułę CSS lub dołączyć arkusz podczas ładowania strony.

Oczywiście nie będzie to działać w XHTML, ale ponieważ XHTML wydaje się być czymś w rodzaju martwej kaczki (i renderuje się jako zupa tag w IE), warto ponownie rozważyć wybór DOCTYPE ...

Zastępuje treść na stronie, co jest najbardziej oczywistym powodem, ale nie nazwałbym tego „złym”.

Po prostu nie ma większego zastosowania, chyba że tworzysz cały dokument za pomocą JavaScript, w takim przypadku możesz zacząć od document.write.

Mimo to, tak naprawdę nie używasz DOM, gdy używasz document.write - po prostu zrzucasz kroplę tekstu do dokumentu, więc powiedziałbym, że to zła forma.

Łamie strony przy użyciu renderowania XML (podobnie jak strony XHTML).

Najlepsze : niektóre przeglądarki przełączają się z powrotem na renderowanie HTML i wszystko działa dobrze.

Prawdopodobne : niektóre przeglądarki wyłączają funkcję document.write () w trybie renderowania XML.

Najgorsze : niektóre przeglądarki wywołują błąd XML przy każdym użyciu funkcji document.write ().

Z czubka mojej głowy:

1. document.writemusi być używany do ładowania strony lub treści. Więc jeśli chcesz użyć skryptu w dowolnym momencie, aby zaktualizować zawartość strony document.write jest prawie bezużyteczne.

2. Technicznie document.writezaktualizuje tylko strony HTML, a nie XHTML / XML. IE wydaje się dość wybaczać temu faktowi, ale inne przeglądarki tak nie będą.

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

document.writeW niektórych przypadkach Chrome może blokować wstawianie skryptu. Gdy tak się stanie, wyświetli to ostrzeżenie w konsoli:

Skrypt blokujący parser, pochodzący z różnych źródeł, ..., jest wywoływany przez document.write. Może to zostać zablokowane przez przeglądarkę, jeśli urządzenie ma słabą łączność sieciową.

Bibliografia:

• Ten artykuł na developers.google.com zawiera bardziej szczegółowe informacje.
• https://www.chromestatus.com/feature/5718547946799104

Naruszenie przeglądarki

.writejest uważane za naruszenie przeglądarki, ponieważ powstrzymuje parser przed renderowaniem strony. Analizator składni otrzymuje komunikat, że dokument jest modyfikowany; dlatego zostaje zablokowany, dopóki JS nie zakończy procesu. Tylko w tym momencie parser zostanie wznowiony.

Wydajność

Największą konsekwencją zastosowania takiej metody jest obniżona wydajność. Wczytywanie zawartości strony potrwa dłużej. Niekorzystna reakcja na czas ładowania zależy od tego, co jest zapisywane w dokumencie. Nie zobaczysz dużej różnicy, jeśli dodasz <p>znacznik do DOM w przeciwieństwie do przekazywania tablicy 50-niektórych odniesień do bibliotek JavaScript (coś, co widziałem w działającym kodzie i spowodowało 11-sekundowe opóźnienie - oczywiście zależy to również od sprzętu).

Podsumowując, najlepiej jest unikać tej metody, jeśli możesz jej pomóc.

Aby uzyskać więcej informacji, zobacz interweniowanie przeciwko document.write ()

Na podstawie analizy przeprowadzonej przez Google-Chrome Dev Tools Audit Lighthouse Audit ,

W przypadku użytkowników korzystających z wolnych połączeń zewnętrzne skrypty dynamicznie wprowadzane za pośrednictwem document.write()mogą opóźnić ładowanie strony o kilkadziesiąt sekund.

• Prosty powód dlaczego document.write złej praktyki jest to, że nie można wymyślić scenariusza, w którym nie można znaleźć lepszej alternatywy.
• Innym powodem jest to, że masz do czynienia z łańcuchami zamiast z obiektami (jest to bardzo prymitywne).
• Dotyczy tylko dokumentów.
• Nie ma w tym nic pięknego, na przykład wzór MVC (Model-View-Controller) .
• O wiele bardziej wydajne jest przedstawianie zawartości dynamicznej za pomocą ajax + jQuery lub angularJS .

Można myśleć o document.write () (i .innerHTML) jako o ocenie ciągu kodu źródłowego. Może to być bardzo przydatne w wielu aplikacjach. Na przykład, jeśli otrzymujesz kod HTML jako ciąg znaków z jakiegoś źródła, dobrze jest po prostu go „ocenić”.

W kontekście Lisp manipulowanie DOM byłoby jak manipulowanie strukturą listy, np. Tworzenie listy (pomarańczowy) poprzez:

(cons 'orange '())

A document.write () byłoby jak ocena łańcucha, np. Utwórz listę, oceniając łańcuch kodu źródłowego w następujący sposób:

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

Lisp ma również bardzo przydatną zdolność do tworzenia kodu przy użyciu manipulacji listami (np. Przy użyciu „stylu DOM” do utworzenia drzewa parsowania JS). Oznacza to, że możesz zbudować strukturę listy za pomocą „stylu DOM”, a nie „stylu ciągu”, a następnie uruchomić ten kod, np. W następujący sposób:

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

Jeśli zaimplementujesz narzędzia do kodowania, takie jak proste edytory na żywo, bardzo przydatna jest możliwość szybkiej oceny ciągu, na przykład za pomocą document.write () lub .innerHTML. Lisp jest w tym sensie idealny, ale możesz robić bardzo fajne rzeczy również w JS, a wiele osób to robi, np. Http://jsbin.com/

Wady document.write zależą głównie od 3 czynników:

a) Wdrożenie

Document.write () jest najczęściej używany do zapisywania zawartości na ekranie, gdy tylko ta zawartość jest potrzebna. Oznacza to, że dzieje się to w dowolnym miejscu, w pliku JavaScript lub w znaczniku skryptu w pliku HTML. Umieszczenie znacznika skryptu w dowolnym miejscu takiego pliku HTML jest złym pomysłem, aby mieć instrukcje document.write () w blokach skryptu, które są powiązane z HTML wewnątrz strony internetowej.

b) Rendering

Dobrze zaprojektowany kod ogólnie bierze każdą dynamicznie generowaną zawartość, przechowuje ją w pamięci, ciągle manipuluje nią, gdy przechodzi przez kod, zanim w końcu zostanie wyrzucony na ekran. Aby powtórzyć ostatni punkt w poprzedniej sekcji, renderowanie zawartości w miejscu może być renderowane szybciej niż w przypadku innych treści, na których można polegać, ale może nie być dostępne dla innego kodu, który z kolei wymaga renderowania treści do przetworzenia. Aby rozwiązać ten dylemat, musimy pozbyć się document.write () i zaimplementować go we właściwy sposób.

c) Niemożliwa manipulacja

Po napisaniu jest skończone. Nie możemy wrócić, aby nim manipulować bez dotykania DOM.

Nie sądzę, aby korzystanie z document.write w ogóle było złą praktyką. Krótko mówiąc, jest to wysokie napięcie dla niedoświadczonych ludzi. Jeśli użyjesz go w niewłaściwy sposób, zostaniesz ugotowany. Jest wielu programistów, którzy przynajmniej raz zastosowali tę i inne niebezpieczne metody i nigdy tak naprawdę nie zagłębili się w swoje niepowodzenia. Zamiast tego, gdy coś pójdzie nie tak, po prostu ratują i używają czegoś bezpieczniejszego. To oni wypowiadają się na temat tego, co uważa się za „złą praktykę”.

To jak formatowanie dysku twardego, kiedy trzeba usunąć tylko kilka plików, a następnie powiedzieć „formatowanie dysku to zła praktyka”.

Myślę, że największym problemem jest to, że wszelkie elementy napisane przez document.write są dodawane na końcu elementów strony. Rzadko jest to pożądany efekt w przypadku nowoczesnych układów stron i AJAX. (należy pamiętać, że elementy w DOM są tymczasowe, a uruchomienie skryptu może wpłynąć na jego zachowanie).

O wiele lepiej jest ustawić element zastępczy na stronie, a następnie manipulować jego innerHTML.