CODEWITHSUNDEEP
xamldata-bindingwin-universal-appuwp
FoldFence
FoldFence

Reputation: 2802

Difference between Binding and x:Bind

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?

Upvotes: 72

Views: 22817

Answers (3)

navin rathore
navin rathore

Reputation: 191

From the {x:Bind} markup extension docs:

The {x:Bind} markup extension—new for Windows 10—is an alternative to {Binding}. {x:Bind} runs in less time and less memory than {Binding} and supports better debugging.

...

{x:Bind} executes special-purpose code, which it generates at compile-time, and {Binding} uses general-purpose runtime object inspection. Consequently, {x:Bind} bindings (often referred-to as compiled bindings) have great performance, provide compile-time validation of your binding expressions, and support 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.

Upvotes: 19

Emperor Eto
Emperor Eto

Reputation: 3520

Other answers are right, but adding some background (and a little unapologetic color).

WPF is almost entirely written in managed code; the binding system makes heavy use of .NET reflection which, while slower than direct code, isn't nearly as bad as some people make it out to be when used smartly. WPF was running on 2006 hardware, after all, and doing so quite well.

Enter the debacle of Windows 8, Windows RT, and Metro, when it was time to build a new XAML based UI framework. For reasons which MS now no doubt regrets but for which we're all still suffering, that framework was required to run on 2014 ARM hardware, i.e., the Surface RT. Apparently having too much of the framework implemented in managed code was deemed (rightly or not, I don't know) not to be viable given the minimum hardware requirements.

Thus, rather than start from the WPF codebase and modernize it, they forked the Silverlight codebase, which was already mostly C++ since it was a browser extension. For cross-language support, they invented IInspectable which is the foundation of what's now known as WinRT, and created a mostly incomprehensible - and by all accounts highly inefficient - system for "projecting" native classes to .NET and other languages. (You know, because vanilla COM on the C++ side and code generators for the C# interfaces and object wrappers would've been too easy).

Projecting native code to C# is one thing, but to support dynamic binding to view models and the like, native code needs to reflect and invoke managed objects/code, which is a lot more complicated. Consequently, dependency property and data binding performance in Metro/UWP/WinUI is terrible compared to WPF.

So x:Bind is a workaround for bad architecture. It pushes as much of the heavy lifting for dynamic binding as possible back into managed code (where it belonged in the first place), generated at compile time, to reduce the amount of marshalling/reflection needed between the native and managed sides.

As a sidenote, this explains many of the other limitations and omissions from WinUI, such as no MultiBinding, no binding in style setters, no ancestor type RelativeSource binding, the essential absence of triggers, the absence of default BindingMode's for DependencyProperty's, and more. They really, really want you data binding as little as possible, because they broke its performance, all to support a product that led to a $1 billion write-off.

Upvotes: 2

Henk Holterman
Henk Holterman

Reputation: 273169

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

Upvotes: 78

Related Questions