7 ms·

Why Not document.write()?

68 points by fagnerbrack 4y ago

dmix 4y ago
> The whole reason I’m writing this post is that I have a client at the moment who is using document.write() late in the <head>. As we now know, this pushes both the fetch and the execution on the main thread. Is there any tools that you can use to help detect stuff like this? In order to do performance optmizations
- metadat 4y ago
  Google Page Speed gives actionable insights into page loading bottlenecks. https://pagespeed.web.dev/ https://pagespeed.web.dev/ Off-topic: Apparently the URL flavor this month is infected with the .dev TLD proliferation g-corp agenda (as is golang.org -> golang.dev). Do cool URLs ever really change?
- dplgk 4y ago
  Lighthouse in Chrome dev tools
metadat 4y ago
This performance conundrum reeks of excessive (incidental) complexity. I've warmed up to Javascript over the past 15 years, but forcing website authors to concern themselves with such details becomes less and less appealing and grows ever more ridiculous. I hope the future of HTML+JS will involve to a better way. I thoroughly enjoyed the spiritual essence and relative purity of HyperCard at the time in the 1990s. Edit: @ly: Apologies, I should have been more specific and clear. Referring to the complexity matrix in terms of what may or may not cause page rendering to block at any given moment. Complexity in this location all but ensures you will make a suboptimal decision during development unless you run every release candidate through Google Page Speed.
- ly 4y ago
  Nobody is forcing anyone not to use Document.write(). The author has voluntarily run a test using Lighthouse on their website, which gives this suggestion as it is not conforming to the Lighthouse "Best Practices".
  - deleted 4y ago
    [deleted]
- ipnon 4y ago
  The runtimes for Node and the browser engines is different enough that they are really different dialects. JavaScript is like Lisp in this way. It was simpler when JavaScript wasn’t supposed to be a write-once-run-anywhere language.
  - eyelidlessness 4y ago
    All of these complexities have either existed or evolved in the browser completely independent of Node. And while I have plenty of criticism for Node particularly around its dependency resolution, it didn’t introduce new complexity in this case (other than what it inflicted on itself to allow ESM/CJS to coexist, which doesn’t extend to browsers at all.) As far as write once/run anywhere, Deno has been pretty good at showing this is still limiting but could be much less painful if the server runtime shared more applicable APIs instead of ad hoc doing idiosyncratic stuff. I’ll definitely agree that JS is a bit lisp like, but not due to runtimes. It’s been a build target with build time semantics for a long while. Unfortunately it’s unlike lisp in that those semantics are part of arbitrary tooling which don’t always agree but have been forced to coexist, rather than semantics of the language itself.
- user3939382 4y ago
  Hopefully with wasm, and combined with a new DOM at some point, we can have the situation on the web as we do with native code where we’re free to use any language we want. With fair competition I expect JS would slowly fade.
  - Bellend 4y ago
    Do you see a new DOM being realistic? Not a sarky comment. I ask because I don't see the problem with a new <bellend> tag. Meaning that in 2023 browsers start having a html and a bellend tag representing an end to legacy and a line to the future.
    - user3939382 4y ago
      One silver lining of the otherwise (IMHO) mostly-bad situation we have with centralization of browsers is that it is conceivable through our standards groups that the major browser vendors agree to experiment with a replacement. From my perspective the problem is even in the name itself, the D in DOM stands for document, which is exactly the problem. The DOM was never designed as an application framework but we've shoehorned it into that role.
    - deleted 4y ago
      [deleted]
  - nightfly 4y ago
    If people didn't like JS for itself Node.js wouldn't have been the success that it is
    - user3939382 4y ago
      This is a good point, though for the sake of discussion imagine that JS didn't exist, and had no ecosystem at the time Node came on the scene. Do you assume it would have been conceived for that purpose? Arguably Node took off because it allowed an already-existing huge ecosystem of libraries, tools, and developers to be leveraged for the back end, with all of those resources in turn coming from the browser.
- wolfgang42 4y ago
  The general trend is to make new things non-blocking, and discourage use of the old blocking things. (Hence stuff like <script async> and ES 'import' declarations.) If you’re writing greenfield, you don’t really have to worry about any of this: new developers who aren’t working on legacy code could be taught about only the non-blocking way of doing things and never even know these problems exist.
- youngtaff 4y ago
  The constraints are not that complex and have (largely) always been there It’s just many people have chosen not to learn how browsers actually work
- cxr 4y ago
  I find both this comment and the original article super weird. Conventional wisdom has been against the use of document.write since before many of today's webdevs were even born. It's still in the browser, of course—because it has to be. But it's not as if people are being taught to use document.write and then having the rug pulled out from under them in a "sike!" moment when it's revealed that this often used fixture of the programmer's toolbox is is actually problematic. What strikes me as odd about the article is that we've reached a point where not only are people not being taught to use document.write anymore, they're not being taught not to use it anymore, either. That's how much of a non-issue this is. So what's with the article belaboring the point?
theendisney 4y ago
this seems fantastic if(condition) document.write('<!--') How else accomplish that?
- zffr 4y ago
  You can use JS to set `display: none` on the relevant HTML elements
  - johannes1234321 4y ago
    The elements then still appear in the DOM and may be affected by DOM manipulation etc.
    - arcanemachiner 4y ago
      How about slapping the outerHTML into a <template> tag? Disclaimer: I didn't read the article and am just bikeshedding.
    - lifthrasiir 4y ago
      So do comments: you can get them via `Node.childNodes` (but not via `Element.children` which only returns elements).
- xg15 4y ago
  Evaluate the condition server-side and don't transmit the HTML in the first place.
  - remram 4y ago
    Is that faster though? Can your Ruby/PHP/Python running on the server really do the conditional rendering faster than the JavaScript running in the browser?
    - notRobot 4y ago
      My experience is mostly with PHP, but the answer to your question is almost always yes.
deleted 4y ago
[deleted]
4nti3verythin9 4y ago
#story,author_
austin-cheney 4y ago
Never ever use document.write. If you execute document.write after the document has loaded it will overwrite the entirety of your document.
- Grom_PE 4y ago
  That is precisely how I use document.write() in order to replace the current page with a better one from a userscript.
move-on-by 4y ago
I’m not defending the usage of `document.write()`, but my understanding of why 3rd party scripts might like using it is to prevent element flicker on load. If you own the site, there are various tricks available to avoid element flashing, but less tools available as a 3rd party. Still, it’s not a good choice, and probably as a 3rd party you shouldn’t be trying to make those design decisions, but I think that is why it’s usage is more common in 3rd party scripts.
nayuki 4y ago
I was forced off of document.write() over 10 years ago by switching to XHTML, which doesn't support this feature (for good reason).

68 points by fagnerbrack 4y ago

dmix 4y ago

> The whole reason I’m writing this post is that I have a client at the moment who is using document.write() late in the <head>. As we now know, this pushes both the fetch and the execution on the main thread. Is there any tools that you can use to help detect stuff like this? In order to do performance optmizations

metadat 4y ago
Google Page Speed gives actionable insights into page loading bottlenecks. https://pagespeed.web.dev/ https://pagespeed.web.dev/ Off-topic: Apparently the URL flavor this month is infected with the .dev TLD proliferation g-corp agenda (as is golang.org -> golang.dev). Do cool URLs ever really change?
dplgk 4y ago
Lighthouse in Chrome dev tools

metadat 4y ago

This performance conundrum reeks of excessive (incidental) complexity. I've warmed up to Javascript over the past 15 years, but forcing website authors to concern themselves with such details becomes less and less appealing and grows ever more ridiculous. I hope the future of HTML+JS will involve to a better way. I thoroughly enjoyed the spiritual essence and relative purity of HyperCard at the time in the 1990s. Edit: @ly: Apologies, I should have been more specific and clear. Referring to the complexity matrix in terms of what may or may not cause page rendering to block at any given moment. Complexity in this location all but ensures you will make a suboptimal decision during development unless you run every release candidate through Google Page Speed.

ly 4y ago
Nobody is forcing anyone not to use Document.write(). The author has voluntarily run a test using Lighthouse on their website, which gives this suggestion as it is not conforming to the Lighthouse "Best Practices".
- deleted 4y ago
  [deleted]
ipnon 4y ago
The runtimes for Node and the browser engines is different enough that they are really different dialects. JavaScript is like Lisp in this way. It was simpler when JavaScript wasn’t supposed to be a write-once-run-anywhere language.
- eyelidlessness 4y ago
  All of these complexities have either existed or evolved in the browser completely independent of Node. And while I have plenty of criticism for Node particularly around its dependency resolution, it didn’t introduce new complexity in this case (other than what it inflicted on itself to allow ESM/CJS to coexist, which doesn’t extend to browsers at all.) As far as write once/run anywhere, Deno has been pretty good at showing this is still limiting but could be much less painful if the server runtime shared more applicable APIs instead of ad hoc doing idiosyncratic stuff. I’ll definitely agree that JS is a bit lisp like, but not due to runtimes. It’s been a build target with build time semantics for a long while. Unfortunately it’s unlike lisp in that those semantics are part of arbitrary tooling which don’t always agree but have been forced to coexist, rather than semantics of the language itself.
user3939382 4y ago
Hopefully with wasm, and combined with a new DOM at some point, we can have the situation on the web as we do with native code where we’re free to use any language we want. With fair competition I expect JS would slowly fade.
- Bellend 4y ago
  Do you see a new DOM being realistic? Not a sarky comment. I ask because I don't see the problem with a new <bellend> tag. Meaning that in 2023 browsers start having a html and a bellend tag representing an end to legacy and a line to the future.
  - user3939382 4y ago
    One silver lining of the otherwise (IMHO) mostly-bad situation we have with centralization of browsers is that it is conceivable through our standards groups that the major browser vendors agree to experiment with a replacement. From my perspective the problem is even in the name itself, the D in DOM stands for document, which is exactly the problem. The DOM was never designed as an application framework but we've shoehorned it into that role.
  - deleted 4y ago
    [deleted]
- nightfly 4y ago
  If people didn't like JS for itself Node.js wouldn't have been the success that it is
  - user3939382 4y ago
    This is a good point, though for the sake of discussion imagine that JS didn't exist, and had no ecosystem at the time Node came on the scene. Do you assume it would have been conceived for that purpose? Arguably Node took off because it allowed an already-existing huge ecosystem of libraries, tools, and developers to be leveraged for the back end, with all of those resources in turn coming from the browser.
wolfgang42 4y ago
The general trend is to make new things non-blocking, and discourage use of the old blocking things. (Hence stuff like <script async> and ES 'import' declarations.) If you’re writing greenfield, you don’t really have to worry about any of this: new developers who aren’t working on legacy code could be taught about only the non-blocking way of doing things and never even know these problems exist.
youngtaff 4y ago
The constraints are not that complex and have (largely) always been there It’s just many people have chosen not to learn how browsers actually work
cxr 4y ago
I find both this comment and the original article super weird. Conventional wisdom has been against the use of document.write since before many of today's webdevs were even born. It's still in the browser, of course—because it has to be. But it's not as if people are being taught to use document.write and then having the rug pulled out from under them in a "sike!" moment when it's revealed that this often used fixture of the programmer's toolbox is is actually problematic. What strikes me as odd about the article is that we've reached a point where not only are people not being taught to use document.write anymore, they're not being taught not to use it anymore, either. That's how much of a non-issue this is. So what's with the article belaboring the point?

theendisney 4y ago

this seems fantastic if(condition) document.write('<!--') How else accomplish that?

zffr 4y ago
You can use JS to set `display: none` on the relevant HTML elements
- johannes1234321 4y ago
  The elements then still appear in the DOM and may be affected by DOM manipulation etc.
  - arcanemachiner 4y ago
    How about slapping the outerHTML into a <template> tag? Disclaimer: I didn't read the article and am just bikeshedding.
  - lifthrasiir 4y ago
    So do comments: you can get them via `Node.childNodes` (but not via `Element.children` which only returns elements).
xg15 4y ago
Evaluate the condition server-side and don't transmit the HTML in the first place.
- remram 4y ago
  Is that faster though? Can your Ruby/PHP/Python running on the server really do the conditional rendering faster than the JavaScript running in the browser?
  - notRobot 4y ago
    My experience is mostly with PHP, but the answer to your question is almost always yes.

deleted 4y ago

[deleted]

4nti3verythin9 4y ago

#story,author_

austin-cheney 4y ago

Never ever use document.write. If you execute document.write after the document has loaded it will overwrite the entirety of your document.

Grom_PE 4y ago
That is precisely how I use document.write() in order to replace the current page with a better one from a userscript.

move-on-by 4y ago

I’m not defending the usage of `document.write()`, but my understanding of why 3rd party scripts might like using it is to prevent element flicker on load. If you own the site, there are various tricks available to avoid element flashing, but less tools available as a 3rd party. Still, it’s not a good choice, and probably as a 3rd party you shouldn’t be trying to make those design decisions, but I think that is why it’s usage is more common in 3rd party scripts.

nayuki 4y ago

I was forced off of document.write() over 10 years ago by switching to XHTML, which doesn't support this feature (for good reason).