No. That is incorrect and makes assumptions not present.
The DOM is a language agnostic tree model in memory. The DOM, or any node therein, is accessed via the DOM’s API. Accessing a single node in JavaScript generates a node object. That node object is an artifact in JavaScript language representing the DOM node at the moment of access.
A DOM node is a living mutable thing, but the JavaScript object representing that node is not. It’s a static object in JavaScript language. That is also why a node list is not an array.
The DOM is not an artifact of JavaScript. I can understand how this is confusing if you have never operated without a framework, but otherwise it’s really straightforward.
This is one of the reasons I abandoned my JavaScript career. Nobody knows what the DOM is, which is their only compile target, and yet everyone wants to an expert.
What I said in my previous comment is observably true. Try making a demo where it isn't.
> A DOM node is a living mutable thing, but the JavaScript object representing that node is not.
The JavaScript object is mutable. The first example in the article shows this.
> That is also why a node list is not an array.
Modern APIs on the web return platform arrays (eg JavaScript arrays). https://webidl.spec.whatwg.org/#js-sequence - here's where the WebIDL spec specifies how to convert a sequence to a JavaScript array.
> I can understand how this is confusing if you have never operated without a framework, but otherwise it’s really straightforward
Sighhhhhh. I've been a web developer for over 20 years, and spent a decade on the Chrome team working on web platform features. Most of my career has been on the low-level parts of the platform.
Could it be possible that people are disagreeing with you, not because they're stupid, but because you're in the wrong? Please try to be open minded. Try creating some demos that test your opinions.
The JavaScript object will be garbage collected as seen fit by the corresponding JavaScript run time irrespective of whether the associated node remains attached to its document.
That is challenging to observe when using event listeners, as opposed to assigning events directly to handlers, because listeners interfere with garbage collection. Furthermore, this almost impossible to observe when abstracted by large frameworks.
That project forms an OS like GUI in the browser without listeners and eliminates most non-locally scoped DOM node references in the event handlers. This allows for localized event handlers with localized DOM node references that are always ready for garbage collection. This also allows state restoration of greater than 10,000 DOM nodes without a large increase in load time and without increased memory consumption. So instead of normal page load with state restoration of about 80ms blowing up to 10,000 nodes could take up to 300+ms. If you want to achieve extreme performance, in any language, you must absolutely understand your compile target. The compile target of the browser is the DOM.
You could also try it on my website which has far less functionality but allows rapid experimentation of the state management. http://prettydiff.com
> The JavaScript object will be garbage collected as seen fit by the corresponding JavaScript run time irrespective of whether the associated node remains attached to its document.
Nope. In practice, the DOM node has a backpointer to the JS object that it's wrapped by which keeps it alive. This is known a "DOM wrapper" and exists in every browser engine. Here's Chrome's internal documentation about this feature, showing the property survive after a GC cycle: https://chromium.googlesource.com/chromium/src/+/master/thir...
The term "expando properties" was invented at Mozilla (or maybe even Netscape?) for exactly this reason; they needed a name for extra properties added to a JS DOM wrapper that would be kept alive as long as the DOM is. It's been part of Gecko for close to 20 years at this point.
I am not sure you understood the article you linked to as its completely outside this conversation. Here is the key bit:
As a result, we have multiple DOM wrapper storages in one isolate. The mapping of the main world is written in ScriptWrappable. If ScriptWrappable::main_world_wrapper_ has a non-empty value, it is a DOM wrapper of the C++ DOM object of the main world. The mapping of other worlds are written in DOMDataStore.
It’s not that an instance object of a DOM node in JavaScript must back port to that node in the DOM tree, but that nodes in the C++DOM architecture have wrappers to other abstractions and such wrappers always reflect the same abstractions in context to their means of access.
That is why to update the DOM an API is provided to JavaScript. Otherwise assigning values to object properties would be sufficient and faster, but nowhere in any version of the DOM specification is this specified or allowed. The DOM is intended to have a memory model separate from the memory model of a JS instance such that access to a given document may occur by unrelated technologies without interference and independent from a given JS instance.
For example SVG can be accessed in JavaScript using the DOM API which returns a JS object reflecting that DOM node. SVG has its own animation scheme unrelated to JavaScript conventions. Since SVG is an XML library all definitions are stored as child nodes as either attributes or child elements. Assigning new animation definitions as JavaScript properties does not back port to given SVG instance in the document, and yet a separate unrelated runtime can modify that animation by updating the SVGs child nodes. If there is a sufficient DOM wrapper abstraction for this case from the lower level DOM memory manager the changes to the SVG animation by that separate unrelated application should be updated in the JavaScript object instance.
So, you are assuming the article says something it doesn’t.
The DOM is a language agnostic tree model in memory. The DOM, or any node therein, is accessed via the DOM’s API. Accessing a single node in JavaScript generates a node object. That node object is an artifact in JavaScript language representing the DOM node at the moment of access.
A DOM node is a living mutable thing, but the JavaScript object representing that node is not. It’s a static object in JavaScript language. That is also why a node list is not an array.
The DOM is not an artifact of JavaScript. I can understand how this is confusing if you have never operated without a framework, but otherwise it’s really straightforward.
This is one of the reasons I abandoned my JavaScript career. Nobody knows what the DOM is, which is their only compile target, and yet everyone wants to an expert.