> > I have no idea how the browser works internally but I thought that if we > add > > an HTML element to the DOM by using JS the browser has to parse it > > afterward? > > I might be wrong, but I don’t think so. AFAIU, if you add elements to the > DOM via JS, it simply gets added to the DOM tree directly. It has nothing > to do with the DOM parser. Internally, the browser does not use the HTML > markup. It’s just a language that the browser needs to understand to create > the tree. Using JS bypasses the parsing step. >
OK, terminology... The HTML parsing may be 'bypassed', but not the render steps and I think those are triggered by each JS based DOM addition. Having most, if not all, nodes present at page complete would certainly minimize the number of loops, shaving off some much needed nanoseconds ;-) I really think this is not where you want to optimize, the gains are simply way too small. Browsers are incredibly smart rendering engines. I was just arguing a technical point, to increase my understanding. > > Is there a need to dive into this JS code (The part of the code that > creates > > and manipulates the DOM) if something went wrong? Or is it easy enough to > > follow what's going on? > > I find it easy to follow. The DOM structure exists in the browser once > it’s created, so the structure can be examined there. I think you can even > dump the HTML markup representation of that structure if you really want. All major browser have a 'developer tools' window that will show you the HTML markup as rendered. Not simply the source you put in, but the DOM the browser is actually displaying at that time. Which includes all additions and changes made through JS. This is actually an interesting way to debug things, and since it doesn't depend on how the DOM is create, it works for whatever framework is used. Thanks, EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
