What aged in jQuery · 4 of 8

Data in the wrong place

Where you keep data about elements decides whether it leaks. jQuery's answer improved over the years; JavaScript now has a built-in one.

Why it made sense

With no way to attach arbitrary data to DOM nodes safely, early jQuery kept a central cache keyed by an ID stamped on each element. It worked — as long as every removal went through jQuery.

What changed

In older versions, removing nodes with native APIs (or another library) could leave their entries — data and event handlers — behind in that cache. Modern jQuery keeps data on a property of the element itself, which fixed most leaks, but it still writes an expando property onto your nodes, and teardown habits such as "always call .remove()" linger in codebases.

What jsKjs does instead

jsKjs stores per-element data and handler records in WeakMaps keyed by the element. A WeakMap entry cannot keep its key alive, so when an element is gone — however it was removed — its data goes too. Nothing is written onto your DOM nodes.

jQuery

JavaScript

$('#chart').data('series', hugeArray);
document.getElementById('chart').remove();   // older jQuery: the cache entry could outlive the node

jsKjs

JavaScript

$('#chart').data('series', hugeArray);        // stored in a WeakMap
document.getElementById('chart').remove();   // node and data are collected together

Sources

MDN — WeakMap