[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

Difference between innerHTML and appendChild

bit-naughty

12/28/2015 4:54:00 PM

From what I know, both innerHTML and appendChild put stuff INTO the browser's current page - but if I appendChild(), is that *visible* straightaway? Or does it get put into the DOM tree, but is not *shown* straightaway...? Can anyone please explain?

Thanks.
8 Answers

ram

12/28/2015 5:29:00 PM

0

bit-naughty@hotmail.com writes:
>From what I know, both innerHTML and appendChild put stuff
>INTO the browser's current page - but if I appendChild(), is
>that *visible* straightaway? Or does it get put into the DOM
>tree, but is not *shown* straightaway...? Can anyone please
>explain?

The results of both »innerHTML« and »appendChild«
/are/ shown straight away.

You can create a subtree off-screen first and
then eventually insert it into the DOM, to probably
make the process faster.

That's why in a recent post, I

let e = document.createElement( 'strong' );
let t = document.createTextNode( object[ 0 ] );
e.appendChild( t );
document.getElementById( 'id201512271754350100' ).
appendChild( e );

instead of

let e = document.createElement( 'strong' );
document.getElementById( 'id201512271754350100' ).
appendChild( e );
let t = document.createTextNode( object[ 0 ] );
e.appendChild( t );

, still »document.createElement« communicates with
the DOM.

. You can use »createDocumentFragment« to, uh, create a
document fragment, which exists offscreen, then use
»appendChild« to append entries to it quickly, and then
- when it's done - insert the whole DocumentFragment with a
single access to the displayed document's DOM.
(You can't use »innerHTML« directly on the fragment though.)

Or, try whether it's faster to create the new subtree as
an HTML string offscreen and then use »innerHTML« to insert
it all with one or two DOM accesses.

ram

12/28/2015 6:00:00 PM

0

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>The results of both »innerHTML« and »appendChild«
>/are/ shown straight away.

A browser, however, might decide to cache several
changes, before a reflow and re-rendition happens.

Ram Tobolski

12/28/2015 6:55:00 PM

0

Yes, appendChild is immediately rendered.

http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_node_a...

innerHTML works with HTML i.e. code, as a string. appendChild works with objects, the entities "behind" the code.

Aleksandro

12/28/2015 8:06:00 PM

0

On 28/12/15 13:54, bit-naughty@hotmail.com wrote:
> From what I know, both innerHTML and appendChild put stuff INTO the browser's current page - but if I appendChild(), is that *visible* straightaway? Or does it get put into the DOM tree, but is not *shown* straightaway...? Can anyone please explain?

Yes.

Gregor Kofler

12/28/2015 8:21:00 PM

0

Am 2015-12-28 um 21:06 schrieb Aleksandro:
> On 28/12/15 13:54, bit-naughty@hotmail.com wrote:
>> From what I know, both innerHTML and appendChild put stuff INTO the browser's current page - but if I appendChild(), is that *visible* straightaway? Or does it get put into the DOM tree, but is not *shown* straightaway...? Can anyone please explain?
>
> Yes.
>
Great. Let's hear it. The explanation.

Tim Streater

12/28/2015 8:46:00 PM

0

In article <n5s5e3$ttt$2@dont-email.me>, Gregor Kofler
<usenet@gregorkofler.com> wrote:

>Am 2015-12-28 um 21:06 schrieb Aleksandro:
>> On 28/12/15 13:54, bit-naughty@hotmail.com wrote:
>>> From what I know, both innerHTML and appendChild put stuff INTO the
>>> browser's current page - but if I appendChild(), is that *visible*
>>> straightaway? Or does it get put into the DOM tree, but is not *shown*
>>> straightaway...? Can anyone please explain?
>>
>> Yes.
>>
>Great. Let's hear it. The explanation.

appendChild adds one element to the DOM. innerHTML will typically be
some html that will be parsed and turned into a small element tree
(depending how complex your innerHTML is). That will then be added to
the DOM. The parsing process will do its best to correct errors in the
supplied html, if any.

When these are rendered and displayed is another question altogether.

--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Gregor Kofler

12/28/2015 10:47:00 PM

0

Am 2015-12-28 um 21:45 schrieb Tim Streater:
> In article <n5s5e3$ttt$2@dont-email.me>, Gregor Kofler
> <usenet@gregorkofler.com> wrote:
>
>> Am 2015-12-28 um 21:06 schrieb Aleksandro:
>>> On 28/12/15 13:54, bit-naughty@hotmail.com wrote:
>>>> From what I know, both innerHTML and appendChild put stuff INTO the
>>>> browser's current page - but if I appendChild(), is that *visible*
>>>> straightaway? Or does it get put into the DOM tree, but is not *shown*
>>>> straightaway...? Can anyone please explain?
>>>
>>> Yes.
>>>
>> Great. Let's hear it. The explanation.
>
> appendChild adds one element to the DOM. innerHTML will typically be
> some html that will be parsed and turned into a small element tree
> (depending how complex your innerHTML is). That will then be added to
> the DOM. The parsing process will do its best to correct errors in the
> supplied html, if any.
>
> When these are rendered and displayed is another question altogether.
>

I know. I found Aleksandro's just a bit on the ...brief and confusing side.

Thomas 'PointedEars' Lahn

12/29/2015 9:18:00 PM

0

Tim Streater wrote:

> [â?¦] Gregor Kofler [â?¦] wrote:
>> Am 2015-12-28 um 21:06 schrieb Aleksandro:
>>> On 28/12/15 13:54, bit-naughty@hotmail.com wrote:
>>>> From what I know, both innerHTML and appendChild put stuff INTO the
>>>> browser's current page -

Not necessarily. They do that only if the owner element already is part of
the *rendered* document (which is something to be avoided since it causes
reflow).

>>>> but if I appendChild(), is that *visible* straightaway? Or does it get
>>>> put into the DOM tree, but is not *shown* straightaway...? Can anyone
>>>> please explain?
>>> Yes.
>> Great. Let's hear it. The explanation.
>
> [â?¦]
> When these are rendered and displayed is another question altogether.

But *that* was the OPâ??s question, the *first* question at any rate.

Neither of those questions was smart, though, since an â??orâ? question is a
bad idea to begin with, and instead of asking the OP could and should simply
have tried (and refrained from asking if anyone could explain). Therefore,
this logically correct answer :)

<http://www.catb.org/~esr/faqs/smart-question...

HTH

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.