Take the 2-minute tour ×

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. :)

share|improve this question
Awesome question, Alex ... +1 & fav'd! –  vzwick Oct 21 '11 at 13:55
Well, to illustrate, thought it's totally different of course, from Java one has access to the "execution context" for a JavaScript ScriptEngine, and it's possible to make arbitrary Java objects visible to JavaScript. The inter-language interface just bridges function calls back and forth, performing some type conversions as necessary in both directions. –  Pointy Oct 21 '11 at 14:04
add comment

3 Answers

up vote 6 down vote accepted

All of your bullet points are correct, except:


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.

share|improve this answer
great answer, thanks! –  Alex Ciminian Oct 23 '11 at 17:55
add comment

The DOM is implemented as a language-independent library pretty much in all major browser implementations, which means it's in a different library from the Javascript engine. For example in IE, the JS engine is implemented in jscript.dll while the DOM is implemented in mshtml.dll. Safari has Nitro(JS) and WebCore(DOM). Chrome has V8(JS) and WebCore(DOM), and Firefox has SpiderMonkey/TraceMonkey(JS) and Gecko(DOM).

What this means is that anytime your JS has to access the DOM, it has to reach over to the DOM library - which is inherently slow because of all the marshaling that has to take place. An analogy that has been used is 2 pieces of land connected by a toll bridge, any time you touch the DOM, you must cross over the bridge and cross back - paying a performance toll.


share|improve this answer
About reference 2, "High Performance JavaScript", see this PDF file. –  Rob W Oct 21 '11 at 16:03
Appreciate the answer, I'll check the references. –  Alex Ciminian Oct 23 '11 at 17:55
add comment

JS calls to DOM methods like getElementById cause the JS engine to call into the C++ code that implements the DOM. For example, in Firefox, the call ends up in nsDocument::GetElementById(const nsAString& aId, nsIDOMElement** aReturn).

As you can see, Firefox maintains a hashtable that maps ids to elements in C++ as an optimization in this case, so it doesn't walk the whole DOM tree looking for the id.

share|improve this answer
How do global host objects in ES translate into C++ code? –  Raynos Oct 21 '11 at 17:34
add comment

Your Answer


