Silverlight XAML vs. Code-behind

You are not likely to see much of a performance difference between the two, as XAML is ultimately translated into code and compiled anyway. By putting all of your UI into pure code, you lose the benefits that XAML has to offer as a UI-centric domain specific language. It is important to maintain a separation of concerns, and keeping your UI layout and styling separated from the the code that drives your UI (and further, keeping both of those separate from your business logic), you produce a more maintainable application.

XAML is an excellent UI construction tool...much better suited for the job than pure code. I recommend keeping your UI layout and styling in XAML form.

If you wish to learn more about how XAML is built, I recommend reading the following:

Building a WPF Application (WPF)

With WPF, you get two generated files as a result of compiling your XAML: a .g.cs file representing the behavior of the UI, and a .baml file which is a compact binary representation of the XAML node hierarchy. With Silverlight, you get the generated code in a .g.cs (or .g.vb) file, but you do not get the BAML. While the ultimate end result is that any behavior IS compiled, with Silverlight you are still stuck with an XML file that contains your UI node hierarchy rather than a more compact binary representation. (Not really sure why this is, limitation of the Silverlight browser control or perhaps the limited .NET framework at its disposal.)

Thanks for the details, especially on the `.g.vb` file - I didn't know about that at all. I'm automatically generating the XAML with code, so I could just as easily generate the code-behind (*well, none of it is easy!*), that's why I was asking. If code-behind was faster, then I would do that, but if the XAML is converted to code-behind, it's probably converted in an efficient manner so I could probably stick with the auto-XAML generation.

Otaku 2010-07-15 05:00:06

@Otaku: Do really have such an intensive need to be loading new components? Don't do it in code. Do it as it should be done then take a view as whether you really need to speed it up. What are you going to do about things like `DataTemplate` which are used frequently in many Silverlight applications anyway. The contents of these need to be defined initially with Xaml. I really can't see this as being something you need worry about. In fact if it is you would be better of considering intensive use of `DataTemplate`.

AnthonyWJones 2010-07-15 08:33:38

@AnthonyWJones: Not sure about **intensive need**. I'll be adding anywhere from 10 to 100 items on a page (shapes, paths, grids, textboxes, custom fonts, images, etc.) and with each one of those, potentially multiple manipulations (e.g. not just a rectangle, but a rectangle with a shader, and imagebrush fill, a transform on the imagebrush, etc.). I'm just trying to get a feel for what may be fastest. If you're saying that based on what I just described, XAML and code-behind are the same/similar, that's cool, I just don't know myself.

Otaku 2010-07-15 08:57:26

Otaku: It would be better to get a feel for what actually works and get something software actually written first. __Then__ consider if its fast enough. Seriously the amount of time you will spend working out how to fight the system because you aren't doing things in the nominal way is going to hurt more than finding you need to re-write some Xaml as code (which is an easy handle turning exercise anyway). Even __IF__ you know upfront that it needed to be code not Xaml I'd still do it in Xaml first, get it working __THEN__ port the Xaml bit to code. BTW 10 - 100 items is peanuts.

AnthonyWJones 2010-07-15 11:45:57

@AnthonyWJones: Good insight, especially on the 10-100 items not being significant. I have the auto-write to XAML stuff working and it seems to perform well, I just wasn't sure if I was missing out on a big opportunity. The XAML is very comfortable, it's the code-behind that feels wonky in my hands, but I'm exploring a variety of options right now because in some cases (e.g. `<storyboard/>`) I'll still need some code-behind.

Otaku 2010-07-16 02:28:53

Wow, that's very interesting! How do you test the difference in speed?

Otaku 2010-07-15 05:05:56

@Otaku: Other than the way I did in my simple test, I can't really say anything more on how to test the difference.In my test I have a loop and I calculate the ellapsed time between the start and end.For the most part the only difference in speed happens at instantiation time. The interaction with the objects is not affected.If you have lots of objects and dynamic animation/effects being generated it's probably valid to look at instantiating them in code.

Klinger 2010-07-15 05:31:04

@Klinger: I don't agree. Only look at using code to do things normally achieved in Xaml, if and __when__ its been established that using Xaml is too slow __and__ you can defend the reason for such intensive creation of components __and__ you using a `DataTemplate` to instantiate a set of objects is slower than code.

AnthonyWJones 2010-07-15 08:38:44

@AnthonyWJones: I don't think I said anything different than that. I said it's valid to look at using code, I didn't say using code is always the way to go. It's valid to consider using code in those situations and I cannot pass judment if I don't know the real requirements and what solutions where considered. Maybe the word "look" should be replaced by the word "consider".

Klinger 2010-07-15 15:28:38

ansaurus

tags:

views:

answers:

Silverlight XAML vs. Code-behind

related questions