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 less black and white cases. Keeping in mind the latest revisions to jQuery’s .data() methods and the HTML5 data-attribute spec, is it really so bad to stick some data in the DOM for the sake of convenience?

For example, I recently implemented a “live” calculation feature on a table full of inputs by doing something like this:

<table>
  <tr>
    <td><input type="text"></td>
  </tr>
  <tr>
    <td><input type="text"></td>
  </tr>
</table>

jQuery:

$('table').bind('calculate',function(){
  var total = 0;
  $(this).find('tr').each(function(){
    total += $(this).data('value');
  });
  // display total
});

$('table input').bind('change keyup',function(){
  $(this).closest('tr').data('value',$(this).val());
  $(this).closest('table').trigger('calculate');
});

This is an over-simplified example because I could skip the calls to .data() and go straight to the input values, but let’s imagine a slightly more complex scenario where elements other than inputs are affecting the row values.

Is it wrong to use the DOM to store simple data in this kind of situation?

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.