I know its bad to store data in the DOM, but why?

Question

I\'ve heard over and over again that it is bad practice to \"use the DOM as a database.\"

While I mostly agree with that sentiment, this question is more about the l

Answer 1

It's fine to store data in DOM objects. And since your question is specific to jQuery's data API, it's important to understand how the data API works. I wrote an answer explaining its inner workings a while back. The data API only keeps a reference to the DOM objects along with the data, and doesn't store anything inside the DOM objects themselves. All data is stored in plain old JavaScript objects.

The issue of whether that is a good or a bad approach is a matter of personal taste. John Resig, the creator of jQuery, gave a talk at Tech4Africa in 2010 where he talks about this exact issue, and proposes to do away with a separate storage area and link everything with the DOM using the data API. You can see the talk on YouTube (thanks to @tine2k for providing the link). If you listen to the entire talk, you'll find some good examples of why this approach makes sense and keeps things simple.

I believe similar arguments can be made for the other end of the spectrum - to have your data in neatly tucked away objects, and classes, and be separate from the view itself. That sort of thinking comes from traditional architectures such as MVC.

I say it's fine to go with either approach - using the DOM to store data, or using a classical approach. Just don't mix the two, cause then you application model is sprinkled everywhere.

Answer 2

Having developed a few single page apps for CE devices that have limited browser power, I have adopted a few extra personal standards about these things. The main thing is that just because JQuery supports scanning through the DOM, that does not suggest it as a performant approach. If I need to know which LI has focus, I could use .index() or .find() or even .each(), but keeping that value in a separate model object is better for the following reasons:

1. MVC is a real thing, despite the rampant abuse through doing things like using the DOM as a state holder. Keeping state in the model as a rule makes MVC make sense.
2. Scanning through the LI tags is more expensive than using listItems.focussed in code.
3. The DOM is busy being manipulated and your queries on it may be delayed or cause delays.

According to Matt @ https://github.com/Matt-Esch/virtual-dom, "Reading some DOM node properties even causes side effects." I tend to agree with that point, but i will admit I am in search for more evidence on that point, as the guy appointed to chase down our biggest apps performance issues that I am personally convinced are tied mostly to DOM dependent code.

Answer 3

I don't think there is anything wrong with storing data in the DOM, but I think the issue lies with storing a lot of data in the DOM. The browser does have to muddle through the DOM to output the pages we see, and the more data that is in there the more crap it has to sort out.

I'm sure there are also other reasons as well, this is just my deduction.

Answer 4

There are some fundamental arguments against using the DOM to store data:

1. The DOM is supposed to be a view of data. The properties of DOM elements should be metadata for the elements themselves, not data from the model.

2. You should not add random properties to host objects as you have no idea what they might do with them.

3. You have the same issue as global variables - if it becomes common practice, you will have to adopt a scheme to avoid name collisions.

There is also the argument that the DOM is a pretty ordinary data store and that object structure with indexes will be much more efficient for anything other than trivial data needs.

If you only have small amounts of data and have full control over your pages, then go ahead and put data in data- attributes and properties. But do not store large chunks or complex structures.

Oh, and I don't think there are any performance issues - accessing an element and its properties in the DOM is likely no faster or slower than accessing some part of an object structure, though I'm sure there are faster and slower ways of doing both.