3 ms·

> I wouldn't put "document.write" in there. innerHTML isn't awesome either, but that's from today's point of view. It's good that we moved on, even though at t

by Udo 11y ago

> I wouldn't put "document.write" in there. innerHTML isn't awesome either, but that's from today's point of view. It's good that we moved on, even though at the time it was important they existed.

iopq 11y ago
this is what makes a fast browser hard to write - scripts can mess up your document so in fact browsers kind of assume nobody is crazy enough to do document.write and then when it gets called they redo all the work rendering the page
- coldtea 11y ago
  Obviously that train has left the station ages ago. We now have dynamic documents were scripts are MEANT to mess with the page constantly, and even create it's contents from scratch in some cases.
  - iopq 11y ago
    No, you don't understand. What you're talking about is after the page loaded scripts execute and modify the page. That's completely fine. I'm talking about page load time. A script potentially can force you to reparse the page. A script can insert something like </div><div class="something"> into the page in a random spot, completely wrecking the layout you just made. Adding a new div at runtime on top of the other parts of the page is easy. Something that can actually make all the positioning on the page completely change is much more evil. So in fact, browsers usually get the HTML, parse it, get the CSS, position/style things while getting the JS (hopefully you have optimized it so the CSS loads before your scripts). Now if the JS file has document.write you have to reparse the HTML because the current tags could be a lie! The document.write could have closed a tag and opened a new tag. Compared to that, just setting the innerHTML of a tag is much less expensive. You just need to potentially reflow its size and its parents. The rest of the page may not be affected. document.write may force you to tear everything down and start all over again

by Udo 11y ago

> I wouldn't put "document.write" in there. innerHTML isn't awesome either, but that's from today's point of view. It's good that we moved on, even though at the time it was important they existed.

iopq 11y ago

this is what makes a fast browser hard to write - scripts can mess up your document so in fact browsers kind of assume nobody is crazy enough to do document.write and then when it gets called they redo all the work rendering the page

coldtea 11y ago
Obviously that train has left the station ages ago. We now have dynamic documents were scripts are MEANT to mess with the page constantly, and even create it's contents from scratch in some cases.
- iopq 11y ago
  No, you don't understand. What you're talking about is after the page loaded scripts execute and modify the page. That's completely fine. I'm talking about page load time. A script potentially can force you to reparse the page. A script can insert something like </div><div class="something"> into the page in a random spot, completely wrecking the layout you just made. Adding a new div at runtime on top of the other parts of the page is easy. Something that can actually make all the positioning on the page completely change is much more evil. So in fact, browsers usually get the HTML, parse it, get the CSS, position/style things while getting the JS (hopefully you have optimized it so the CSS loads before your scripts). Now if the JS file has document.write you have to reparse the HTML because the current tags could be a lie! The document.write could have closed a tag and opened a new tag. Compared to that, just setting the innerHTML of a tag is much less expensive. You just need to potentially reflow its size and its parents. The rest of the page may not be affected. document.write may force you to tear everything down and start all over again