Backbone.js ↔ Underscore.js: Deep Comparison Compatibility in Model#set

The short answer

Because Backbone 1.4+ delegates its change detection inside Model#set directly to _.isEqual with no version check, the safest path for an existing codebase is not to wait for Backbone to embed a legacy comparator, but to control the comparison yourself — either by pinning Underscore, or by overriding set (or wrapping the equality check) in a base model your application owns. A fallback inside Backbone would be nice, but you can't ship your fix on the Backbone project's timeline.

What's confirmed vs. likely

Confirmed: Backbone's set compares each incoming attribute against the current one using _.isEqual, and fires change:attr/change only when the comparison reports inequality. Backbone performs no Underscore version check, so any semantic change in _.isEqual flows straight into your event stream.

Likely explanation for your regression: Underscore 1.9 tightened its deep-equality algorithm. Nested mutations that older versions treated as equal (or that were previously masked by reference shortcuts) are now reported as unequal, so Backbone sees a "change" where it previously saw none — producing spurious events, or in collection-sort and reset scenarios, the opposite surprise. Treat the precise per-version semantics as something to verify against the exact Underscore versions you run, not as gospel.

Trade-offs of each approach

• Backbone embeds a legacy comparator: insulates every app from upstream drift, but Backbone must forever maintain a forked copy of equality logic, and apps that want modern _.isEqual semantics lose them. Unlikely to be resolved quickly, and not something you control.
• Pin Underscore to a pre-1.9 version: zero code change, but you forfeit bug fixes and security patches, and any other library in the bundle expecting newer Underscore may break.
• Override the comparison in your own base model: project-scoped, explicit, and upgrade-safe. The cost is a maintenance point you must remember when upgrading Backbone itself.

A scoped override

Extend a base model rather than monkey-patching Backbone.Model.prototype, so third-party components keep stock behavior:

var BaseModel = Backbone.Model.extend({
  set: function(key, val, options) {
    var attrs = typeof key === 'object' ? key : (key = {}, key[key] = val, key);
    // Snapshot current values and restore reference-equal nested objects
    // only if your app truly depends on reference-only change detection.
    return Backbone.Model.prototype.set.call(this, attrs, options);
  }
});

If you genuinely need the old semantics, the cleanest variant is to pre-normalize attributes (e.g., deep-freeze or replace mutated nested objects with new references before calling set) so that any reasonable _.isEqual behaves predictably. Avoid {silent: true} as a fix — it only suppresses events for that one call while still marking attributes changed, which corrupts later hasChanged()/changedAttributes() results.

Testing for unintended change events on upgrade

1. Unit test: create a model with a nested object attribute, spy on change, mutate a nested property and call set with the same top-level reference, then assert the event count matches your intended semantics.
2. Integration diff: add a global counter on change events in a test harness, run your existing suite against the old Underscore, then against 1.9+, and diff the counts. Spikes localize the affected models.
3. Bisect the comparator: temporarily load Underscore 1.8.x side-by-side and substitute its isEqual in a test build to confirm the comparator — not your code — is the behavioral difference.

Recommendation

Pin Underscore short-term to stop the bleeding, then move to application-owned normalization of nested attributes (fresh references on real changes) so any _.isEqual version behaves correctly. Reserve a custom set override for models where that's impractical.