Does javascript process run using elastic racetrack algorithm

Question

I am trying to develop an efficient algorithm for changing many classes on a heap of nodes, and I found that I have a big big hole in my understanding of how javascript goes through the DOM.

Do browsers / javascript use an elastic track like flash? or is it more events when the entire screen is redrawn every time a change occurs?

“Elastic race track” is a flash paradigm where you imagine a big big loop that flares up around. When changing the processing time for user settings and while processing flash memory, the flash moves around and applies all the changes - again and again.

An alternative would be a case model where every time an attribute changes, the entire screen is redrawn - this is probably what browsers do, but I'm not sure.

And I can think of hybrid algorithms, where if there are no changes, nothing happens, but if there is, they can be created - sort of like plates on my sink.

Does anyone have a quick description of the algorithm used to handle changes to attributes and DOM attachments.

Answer 1

Flash "elastic track" was inherited from the browser. Of course, in the browser we do not call this an event loop.

The history of the javascript event loop began with progressive GIFs and JPEG rendering on Netscape. Progressive rendering — drawing partially loaded content — required Netscape to implement an asynchronous loading rendering mechanism. When Brendan H. implemented javascript, this asynchronous event loop was already there. Therefore, it was a fairly simple task to add another layer to it.

The browser event loop thus looks something like this:

Event loop ┌──────────┐ │ │ │ │ │ ▼ │ check if there any new ───────▶ parse data │ data on the network │ │ │ │ │ ▼ │ │ check if we need to execute ◀─────────┘ │ any javascript ──────────────────▶ execute │ │ javascript │ ▼ │ │ check if we need to ◀────────────────┘ │ redraw the page ──────────────▶ redraw page │ │ │ │ │ │ └────◀─────┴─────────────────◀─────────────────┘ 

The rest, as they say, is history. When Microsoft copied javascript, they had to duplicate the event loop in order to remain compatible with Netscape. Thus, the form then for all had to do the same in order to remain compatible with Netscape and IE.

Note that javascript does not have any functions for recursing manually in the event loop (for example, some languages, for example tcl, can do this), so the browser MUST wait until there is more javascript to execute before redrawing the page. The reprogramming of the page cannot be enforced until the end of the script.

For this reason, calculated values, such as element width or height, sometimes return the wrong value when you try to read them immediately after creation - the browser has not drawn them yet. If you really need to execute the code after the page is redrawn, you need to use setTimeout with a timeout value of 0 so that the browser can start one cycle of the event loop.

---

Additional Information:

It seems that there is one exceptional condition that causes costly recounts. Please note that redevelopment is a calculation of the layout of the browser page. It usually starts if the browser needs to draw a modified page.

When something on the page changes, the calculation of the translation is put in the queue - it is not performed immediately. As in the description above, reflow will only be executed at the end of javascript execution. But there is one case where the browser immediately performs reflow calculations: if you try to read any of the calculated values, such as width and height.

See this related question for more information: When does DOM overflow occur?