The documentation for this property has this to say: “Determines whether or not binding should automatically set the ID of an element. This property should be set to true in apps that use Windows Library for JavaScript (WinJS) binding.”

This is rather enigmatic, and the remarks section doesn’t make it much clearer when it says, “Set this property to true to avoid setting the ID of an element automatically.”

This flag was added late in the developer of Windows 8 to get around a memory leak. What was happening before is that WinJS was automatically creating an ID property for all elements involved in data binding, due to the implementation of its binding engine. However, this introduced the leak because the table in which the wwahost.exe process stores such IDs never gets cleaned up.

Generally speaking, apps didn’t depend on these IDs being created, so the WinJS team could have just made the change internally and no one would’ve noticed. However, it did constitute a breaking change so the optimizeBindingReferences flag was added such that an app that did have that dependency could turn it off.

The bottom line is that apps should set this flag to true and leave it set, thereby reducing the app’s memory footprint.



  1. philk
    Posted May 8, 2013 at 9:39 am | Permalink

    Still I wonder why it was not set to true by default. Is that also the reason why we should not bind to an id property?

    • kraigb
      Posted May 9, 2013 at 3:26 am | Permalink

      When there are changes like this that *might* break some app, the choice is usually to make it available but leave the existing behavior in place unless you specifically say otherwise. Otherwise it would have made sense to default to true. And I would guess that the same reason applies to binding an id like you suggest.