XAML vs. controls created at runtime

Question

In Windows Phone, what is better from performance point of view, to define controls in XAML or creating them dynamically at runtime? What are cons/pros for XAML and runtime controls?

Answer 1

I remember reading that Xaml loading is more efficient than the equivalent creation in code, however:

Factors that effect the speed included the number of named elements (as they get connected to code-behind members by lookups in the designer file) and the number of similar/total elements.

From a business perspective keeping it in Xaml is a far easier way to maintain a project. The whole purpose of Xaml was to allow designers to work on the look independent of the coders.

Answer 2

I think i'm right in saying that perf wise it does not matter.

From a Dev perspective, having the controls defined in the XAML allows a clear separation, and if you are using MVVM, you get all the benefits that pattern brings (unit testing, clear separation, better manageability etc)

also, if you have your controls defined in XAML, your app will lend itself better to Blend development and allow you to control the look and feel of your app visually.

I prefer to keep all UI controls in XAML, and do the nuts and bolts in code..but the framework is designed to suit all dev tastes

Answer 3

I think if you try to define animations/VisualStates using pure code, you'll realize how great Blend can be.

The Binding syntax also, doesn't feel very readable in code, but then, that's maybe a matter of taste.

Answer 4

The performance difference is negligible and shouldn't even be a factor because the maintenance and code quality difference is so large. Code-generated controls are a nightmare to maintain, are difficult to design and style, and make it harder for developers to follow the application flow. You basically are asking about the difference between using XAML which can provide design-time views, separate presentation logic from business logic, and allows tools like Blend to take over, versus a programmatic approach that negates all of the above. What if you decided down the road to port your application to Windows 8 and use the WinRT engine? With the XAML approach and a pattern like MVVM you could likely reuse the bulk of your code and simply update some of the views, whereas with a programmatic approach all of that code would have to be trashed in favor of the new runtime. So even if there was a slight performance difference between one over the other, I'd suggest it doesn't matter because the other factors are far more important to consider.