67

What to use in UWP, Binding or x:Bind and what is the difference between them?

Because I see a lot of posts where people use Binding and I only Bind with x:Bind in UWP.

At the MSDN Homepage it only says that "the binding objects created by {x:Bind} and {Binding} are largely functionally equivalent." and that x:Bind is faster.

But what is the difference between them?

Because "largely functionally equivalent" does not mean equivalent.

The Link from my Quote: MSDN

So my Question is:

What is the difference in using Binding or x:Bind in UWP?

FoldFence
  • 2,674
  • 4
  • 33
  • 57
  • 3
    Arguably, the most significant difference is (as stated in [{x:Bind} markup extension](https://msdn.microsoft.com/en-us/windows/uwp/xaml-platform/x-bind-markup-extension)): *"Compiled bindings are strongly typed, and will resolve the type of each step in a path. If the type returned doesn’t have the member, **it will fail at compile time**."* – IInspectable May 25 '16 at 21:33
  • 1
    I would like to know just how much faster x:Bind is than Binding. Can I expect it to be 1.5x, 2x, 10x, etc. faster? Since this all happens in XAML, I'm not aware of a way to measure it. – grimus May 19 '21 at 21:01

2 Answers2

75

The following is probably not complete, but some of the major differences are

  • Old style {Binding }

    • binds to the DataContext
    • binds to a Property Name, flexible about the actual source type

  • New style {x:Bind }

    • binds to the Framework element (code-behind class)
    • needs all types fixed at compile time
    • defaults to the more frugal OneTime mode

And starting with build 14393, {x:Bind } supports:

  • direct BooleanToVisibility binding, without a ValueConverter
  • expanded Function binding
  • casting
  • dictionary indexers

The newer {x:Bind } is a little faster at runtime but just as important it will give compiler errors for erroneous bindings. With {Binding } you would just see an empty Control in most cases.

For in-depth comparison checkout: {x:Bind} and {Binding} feature comparison

H H
  • 263,252
  • 30
  • 330
  • 514
  • 2
    I would add examples explaining the meaning of each statement. In my particular case **{Binding Data.Name, Mode=OneWay}** didn't work for updates (although both Data and Name were implementing _INotifyPropertyChanged_), but **{x:Bind Data.Name, Mode=OneWay}** did the job. – Borzh Jul 26 '18 at 21:27
17

{x:Bind} executes special-purpose code, which it generates at compile-time. {Binding} uses general-purpose runtime object inspection. Consequently, {x:Bind} has great performance and provides compile-time validation of your binding expressions. It supports debugging by enabling you to set breakpoints in the code files that are generated as the partial class for your page.

Because {x:Bind} uses generated code to achieve its benefits, it requires type information at compile time. This means that you cannot bind to properties where you do not know the type ahead of time. Because of this, you cannot use {x:Bind} with the DataContext property which is of type Object, and is also subject to change at run time. The {x:Bind} markup extension—new for Windows 10—is an alternative to {Binding}. {x:Bind} lacks some of the features of {Binding}, but it runs in less time and less memory than {Binding} and supports better debugging.

FoldFence
  • 2,674
  • 4
  • 33
  • 57
navin rathore
  • 171
  • 1
  • 2
  • 6
    Could you add the source you are citing from please? – Axel Meier Mar 16 '17 at 09:24
  • 1
    @AxelMeier The answer has citings from [x:Bind markup extension](https://learn.microsoft.com/en-us/windows/uwp/xaml-platform/x-bind-markup-extension) To be precise **first para** is from the **introduction of this page** and **second para** is from **[Remarks](https://learn.microsoft.com/en-us/windows/uwp/xaml-platform/x-bind-markup-extension#remarks) section of this page** – Shantanu Methikar Nov 15 '20 at 11:36