Save or destroy data/DOM elements? Which takes more resources?

Question

I've been getting more and more into high-level application development with JavaScript/jQuery. I've been trying to learn more about the JavaScript language and dive into some of the more advanced features. I was just reading an article on memory leaks when i read this section of the article.

JavaScript is a garbage collected language, meaning that memory is allocated to objects upon their creation and reclaimed by the browser when there are no more references to them. While there is nothing wrong with JavaScript's garbage collection mechanism, it is at odds with the way some browsers handle the allocation and recovery of memory for DOM objects.

This got me thinking about some of my coding habits. For some time now I have been very focused on minimizing the number of requests I send to the server, which I feel is just a good practice. But I'm wondering if sometimes I don't go too far. I am very unaware of any kind of efficiency issues/bottlenecks that come with the JavaScript language.

Example

I recently built an impound management application for a towing company. I used the jQuery UI dialog widget and populated a datagrid with specific ticket data. Now, this sounds very simple at the surface... but their is a LOT of data being passed around here.

(and now for the question... drumroll please...)

I'm wondering what the pros/cons are for each of the following options.

1) Make only one request for a given ticket and store it permanently in the DOM. Simply showing/hiding the modal window, this means only one request is sent out per ticket.

2) Make a request every time a ticket is open and destroy it when it's closed.

---

My natural inclination was to store the tickets in the DOM - but i'm concerned that this will eventually start to hog a ton of memory if the application goes a long time without being reset (which it will be).

I'm really just looking for pros/cons for both of those two options (or something neat I haven't even heard of =P).

Answer 1

The solution here depends on the specifics of your problem, as the 'right' answer will vary based on length of time the page is left open, size of DOM elements, and request latency. Here are a few more things to consider:

• Keep only the newest n items in the cache. This works well if you are only likely to redisplay items in a short period of time.
• Store the data for each element instead of the DOM element, and reconstruct the DOM on each display.
• Use HTML5 Storage to store the data instead of DOM or variable storage. This has the added advantage that data can be stored across page requests.

Any caching strategy will need to consider when to invalidate the cache and re-request updated data. Depending on your strategy, you will need to handle conflicts that result from multiple editors.

The best way is to get started using the simplest method, and add complexity to improve speed only where necessary.

Answer 2

The third path would be to store the data associated with a ticket in JS, and create and destroy DOM nodes as the modal window is summoned/dismissed (jQuery templates might be a natural solution here.)

That said, the primary reason you avoid network traffic seems to be user experience (the network is slower than RAM, always). But that experience might not actually be degraded by making a request every time, if it's something the user intuits involves loading data.

Answer 3

I would say number 2 would be best. Because that way if the ticket changes after you open it, that change will appear the second time the ticket is opened.

Answer 4

One important factor in the number of redraws/reflows that are triggered for DOM manipulation. It's much more efficient to build up your content changes and insert them in one go than do do it incrementally, since each increment causes a redraw/reflow.

See: http://www.youtube.com/watch?v=AKZ2fj8155I to better understand this.