Question

I was thinking about this today and I realized I don’t have a clear picture here.

Here are some statements I think to be true (please correct me if I’m wrong):

• the DOM is a collection of interfaces specified by W3C.
• when parsing HTML source code, the browser creates a DOM tree which has nodes that implement DOM interfaces.
• the ECMAScript spec has no reference of browser host objects (DOM, BOM, HTML5 APIs etc.).
• how the DOM is actually implemented depends on browser internals and is probably different among most of them.
• modern JS interpreters use JIT to improve the code performance and translate it to bytecode

I am curious about what happens behind the scenes when I call document.getElementById('foo'). Does the call get delegated to browser native code by the interpreter or does the browser have JS implementations of all host objects? Do you know about any optimizations they do in regard to this?

I read this overview of browser internals but it didn’t mention anything about this. I will look through the Chrome and FF source when I have time, but I thought about asking here first. 🙂

Answer 1

All of your bullet points are correct, except:

modern JS interpreters use JIT to improve the code performance and translate it to bytecode

should be “…and translate it to native code”. SpiderMonkey (the JS engine in Firefox) worked as a bytecode interpreter for a long time before the current JS speed arms race.

On Mozilla’s JS-to-DOM bridge:

The host objects are typically implemented in C++, though there is an experiment underway to implement DOM in JS. So when a web page calls document.getElementById('foo'), the actual work of retrieving the element by its ID is done in a C++ method, as hsivonen noted.

The specific way the underlying C++ implementation gets called depends on the API and also changed over time (note that I’m not involved in the development, so might be wrong about some details, here’s a blog post by jst, who was actually involved in creating much of this code):

• At the lowest level every JS engine provides APIs to define host objects. For example, the browser can call JS_DefineFunctions (as demonstrated in the SpiderMonkey User Guide) to let the engine know that whenever script calls a function with the specified name, a provided C callback should be called. Same for other aspects of the host objects (e.g. enumeration, property getters/setters, etc.)
• For the core ECMAScript functionality and in some tricky DOM cases the JS engine/the browser uses these APIs directly to define host objects and their behaviors, but it requires a lot of common boilerplate code for e.g. checking parameter types, converting them to the appropriate C++ types, error handling etc.
• For reasons I won’t go into, let’s say historically, Mozilla made heavy use of XPCOM for many of its objects, including much of the DOM. One feature of XPCOM is its binding to JS called XPConnect. Among other things, XPConnect can take an interface definition in IDL (such as nsIDOMDocument; or more precisely its compiled representation), expose an object with the specified properties to the script, and later, when a script calls getElementById, perform the necessary parameter checks/conversions and route the call directly to a C++ method (nsDocument::GetElementById(const nsAString& aId, nsIDOMElement** aReturn))
• The way XPConnect worked was quite inefficient: it registered generic functions as callbacks to be executed when a script accesses a host object, and these generic functions figured out what they needed to do in every particular case dynamically. This post about quickstubs walks you through one example.
• “Quick stubs” mentioned in the previous link is a way to optimize JS->C++ calls time by trading some code size for it: instead of always using generic C++ functions that know how to make any kind of call, the specialized code is automatically generated at the Firefox build time for a pre-defined list of “hot” calls.
• Later on the JIT (tracemonkey at that time) was taught to generate the code calling C++ methods as part of the native code generated for “hot” paths in JS. I’m not sure how the newer JITs (jaegermonkey) work in this regard.
• With “paris bindings” the objects are exposed to webpage JS without any reliance on XPConnect, instead generating all the necessary glue JSClass code based on WebIDL (instead of XPCOM-era IDL). See also posts by developers who worked on this: jst and khuey. Also see How is the web-exposed DOM implemented?

I’m fuzzy on details of the three last points in particular, so take it with a grain of salt.

The most recent improvements are listed as dependencies of bug 622298, but I don’t follow them closely.