Pitfalls using DOM-Javascript VS pure Javascript objects?

Question

Background

First of, I would like to mention, that a SO-search for figuring out differences of

(host objects) DOM-Javascript Objects (var domJSobj = document.createElement("div")) and
(native objects) pure Javascript Objects (var pureJSobj = {})

has been done, but still I cannot claim that I found very much (great is, that there is this question-answers: what-is-the-difference-between-native-objects-and-host-objects). Maybe I overlooked something here, then a comment is very appreciated.

I also read MDN Mozillas Docu on DOM and Javascript to get some idea before asking here.

Question

Being a little "glueless" I started playing in the Javascript Console and I encountered some first pitfall (arising from expectations I have regarding the behaviour of (native objects) which are not true for (host objects)). To be clear many things -at first sight- seem similar:

var nativeObject = {}; //create new object
nativeObject.someAttribute = "something"; //set some attribute
nativeObject.someMethod = function() { return this.someAttribute; } // define some method 

console.log(nativeObject.someAttribute); // "something"
console.log(nativeObject.someMethod());  // "something"

var hostObject = document.createElement("div"); //create a "div" one type of host object
hostObject.someAttribute = "something"; //set some attribute
hostObject.someMethod = function() { return this.someAttribute; } // define some method

console.log(hostObject.someAttribute); // "something"
console.log(hostObject.someMethod());  // "something"

For me it seems at first sigth that a (host object) is just as usable as a (native object) and has already more:

console.log(nativeObject.tagName);  // undefined
console.log(hostObject.tagName);  // "DIV"

as it has the all the nice DOM-attributes already there.

My Question is about a list of pitfalls (possible troubles) that can arrise if I decide to (mis)use a (host object) instead of simple (native object)?

already I am aware of this:

speed considerations (I assume that native objects are created more quickly)
memory usage consideratoins (native objects might be better here too)

Anyways I cannot see much trouble (if those considerations are not very important in a case) yet? This is the reason for the question.

I think answers to this question would be best showing/telling one potential pitfall, that is a case or situation in which it is bad or impossible to use a (host object) over a (native object). In this way this question should adhere to the SO-quality requirement of being passed on real facts and not provoking mere opinion-based-discussion.

You are trying to compare Apples with Oranges. DOM objects have influence on the browser. Native ones do not. — Ed Heal, Nov 09 '13 at 08:54
If I understand you correctly - DOM objects are for the browser output whereas native objects are for data. — , Nov 09 '13 at 08:55
@EdHeal It is because I understand that it is not the "same" but similiar i ask this question. One can eat Apples and Oranges (assuming no specific allergies :). If the DOM object is not yet appended to the DOM structure I do not consider the influence very big. Also I wonder if (host objects) are having all that (native objects) have. In "Apples(native) and Orange(host)" terms, is an Orange just as good an Apple. Or are there cases it fails (pitfalls) — humanityANDpeace, Nov 09 '13 at 09:03
@jeff Thanks for the input. I want ot affirm that I take your point and I think I indicated that I already know some implications. Assuming the "orginal purpose" being not the point here: the question tagets to What would happen (pitfalls) if I anyways use a host object mainly for the things a native object would suffice? ....(By the way there is even some application for this, thanks to IE7-8 being crap [see here](http://stackoverflow.com/questions/1077106/javascript-getters-setters-in-ie) ) — humanityANDpeace, Nov 09 '13 at 09:07
@humanityANDpeace - You state they are different. How does one measure goodness? When I want a slice of bread I get the bread knife out - the right tool for the job. But a bread knife is useless for drilling a hole in the wall. So a DOM object acts like any other Javascript object BUT it does influence the browser. But a Javascript object does not process that ability. So the question is pointless as you chose the right thing to get the job done. Where is the bread knife as I want a sandwich - cannot make one with the drill — Ed Heal, Nov 09 '13 at 09:15
@EdHeal When asking the question, the point is surely not to defend that using a DOM for a JS Object is the "best idea". It is rather sometimes [http://stackoverflow.com/questions/1077106/javascript-getters-setters-in-ie](http://stackoverflow.com/questions/1077106/javascript-getters-setters-in-ie) it might be necessary. This made me wonder more general what are things to care about DOMvsJS objects. I do not wanna make a case and suggest to substitute JS Objects with DOMs. I also think that would be unwise. I simply am interested to know what could happen? — humanityANDpeace, Nov 09 '13 at 09:21
@humanityANDpeace - DOM objects have hooks into the browser. That is it. JS objects do not. And they cannot obtain that luxury. If you want to change the web page then use a DOM object otherwise do not.Use the KISS principle — Ed Heal, Nov 09 '13 at 09:29
@EdHeal Right! and I hope I can say: I understand. Again, I do not advocate to disregard KISS. I wished there was no need (i.e. no IE<9) to even start wondering about using a DOM for what a mere JS native object should suffice. — humanityANDpeace, Nov 09 '13 at 09:33
@humanityANDpeace - If a JS object floats the boat they why wonder/worry about having to make things more compilcated — Ed Heal, Nov 09 '13 at 09:38
@EdHeal I just seen that the link in the comment above is not working. A reason to employ a DOM Object when actually you would be fine with a native JS object is, that you have to care for IE<9 browser incompatibility. IE sucks and does not support getters and setters. A way to simulate this behaviour would be to use a DOM object instead of a JS object. see [here](http://stackoverflow.com/questions/1077106/javascript-getters-setters-in-ie) — humanityANDpeace, Nov 09 '13 at 09:49

score 0 · Answer 1 · answered Nov 26 '13 at 03:42

For me, the pitfall of using a DOM-based object is that from the moment it's created it already has dozens of properties. Your document.createElement("div") object has an id property and a title property and a style property that is an object of its own, etc. If you want to use a DOM-based object to store arbitrary data, you need to be careful not to name your property something that already exists or you may get unexpected results; for example in my tests in Chrome, the code hostObject.id = null would actually cause hostObject.id to be "" rather than true null; or hostObject.id = false would cause it to be "false" (i.e. the string, not true false) for the hostObject variable defined in your code.

Try adding this to your code:

for (property in document.createElement("div"))
  console.log(property);

In Chrome, I see 134 properties listed. That's a lot of landmines to potentially avoid. And beyond that, the properties differ between browsers. The same code in Firefox lists 192 properties.

I would only create a DOM object if you actually intend to use it as a DOM object. Then the properties have some purpose; otherwise they're just potential bugs in your code. Like the comments say, KISS; I mean, sure, I could decide to save the integer value 123456789 within a Date object:

myInt = new Date(123456789);
myInt.getTime(); // returns 123456789

But what's the point of that? Why not just do myInt = 123456789? Just as I wouldn't use a Date object to store integer data, don't use a DOM object to store arbitrary data.

Pitfalls using DOM-Javascript VS pure Javascript objects?

Background

Question

1 Answers1