textContent is standardized and doesn't trigger a reflow on
read (since unlike innerText, it doesn't exclude "hidden"
elements):
https://developer.mozilla.org/en-US/docs/Web/API/Node/textContenthttps://kellegous.com/j/2013/02/27/innertext-vs-textcontent/
As far as I can tell, none of my code cares about the
difference in behavior, so use the faster one.
https://stackoverflow.com/q/17199958 (2013) warns that
textContent may be slower when setting, but textContent
now seems to be almost 4 times faster (Chrome 118):
https://www.measurethat.net/Benchmarks/ShowResult/486502
same value, innerText 1,737,885 ops/sec
same value, textContent 6,775,336 ops/sec
same value, nodeValue 4,942,868 ops/sec
same value if changed, innerText 1,107,992 ops/sec
same value if changed, textContent 7,485,101 ops/sec
same value if changed, nodeValue 10,595,588 ops/sec
different value, innerText 1,731,098 ops/sec
different value, textContext 6,572,991 ops/sec
different value, nodeValue 3,845,782 ops/sec
different value if changed, innerText 1,029,156 ops/sec
different value if changed, textContent 7,739,438 ops/sec
different value if changed, nodeValue 10,500,733 ops/sec
I'm not using the nodeValue approach since I suspect it
won't work if I'm trying to update a div that doesn't
already have a text node child.
I'll probably keep the "if changed" checks that I have in
various position-updating code since it apparently doesn't
cost anything and seems like it might still help prevent
paints (I have no idea how it could be faster in the
"different value case, though).