XAML - Like/Dislike? [closed]

Question

After bashing my head against the brick wall that is XAML, I've decided to come here and ask other people if they are as frustrated as I am.

So,

• Do you like XAML? Please justify.
• Is XAML the problem, or the lack of good tools? My issue could be resolved if the binding system gave me a file-line number location of the binding that's failing. This isn't a XAML issue so-much-as a debugger issue.

Apart from the issues with tooling, I find that XML does not make a suitable programming language, and that XAML has workarounds to fix things that wouldn't have been a problem in any other "real" programming language. For example, string formatting on a binding.

XAML also breaks when you need to step outside the hierarchical structure for things like context menus. Because they are defined within the xaml hierarchy people assume that they are part of the visual hierarchy too, which is not the case. This can lead to subtle binding issues, which are difficult to debug etc.

As a comparison, HTML-CSS-Javascript works well because each part handles a specific part of displaying a web page. HTML for data and layout, CSS for style, and Javascript for execution. In contrast, XAML is trying to do everything and fails.

Please note, I love WPF, so don't take this as a critisism of WPF, Silverlight or any particular WPF/Silverlight control. I'm only interested in a discussion about the XAML language.

Answer 1

I feel your pain brother -- I had the privilege of working on a small WPF/XAML application and coming from a ASP.NET/C# web application developer it was torture. The separation between CSS and HTML and code extremely simple yet extremely powerful at the same time. In my mind XAML mashes this all up together again -- and although it is powerful it is also ugly and confusing as sin, and therefore unmaintainable (similar to any Perl script not created by yourself).

After talking to a friend about it, and trying to describing the beauty that is all my style in a CSS file, the structure in HTML, and C# controlling the codebehind -- he suggested I try Blend. In my mind that is a red flag -- if I need an IDE to work (not just work better) with your language, if it can't stand on its own well, then it is an epic fail.

Answer 2

XAML falls short on many things, however it could be worse.

Some things I do like about XAML are:

• Binding System - Very cool, I like having my UI elements able to find and reference each other

• DataTemplates - It's awesome to be able to build your own templates for a custom class

• ControlTemplates - It's so easy to overwrite a control's template to get it to feel/act the way you want it to

• Merged Dictionaries - Very useful for keeping XAML files organized. For example, I have one with all my static converters, colors, etc. Another contains generic control templates, and other files contain controls specific to a particular part of the program.

• Attached Properties - Nice to be able to just attach another control's property onto something to get it to act the way you want instead of having to rebuild the control. Or just being able to build your own properties that can be attached to anything (For example, I have a CanResize property that if applied and set to True, allows the user to grab a side and resize the element)

• Custom Dependency Properties

Some things I'd like to see are:

• #region directives
• Allowing multiple BasedOn styles without custom workarounds
• Context Menus being part of the visual tree (Agree with you there!)
• Being allowed to specify Grid.Rows = X and Grid.Columns = Y without building Definitions all the time
• A "Go To Definition" shortcut for StaticResources

Answer 3

You have to separate XAML from WPF. WPF is awesome. The binding is really powerful, etc. XAML, on the other hand, inherits all the problems of XML. I don't like that it uses string literals a lot, and it's missing a lot of compile time checking. I've been using it for a while, and I still find it ugly and hard to read.

What I would prefer is something like a FluentWPF. There have been some people asking for such a thing, but not enough to get something going. It would make a great open source library.

Answer 4

Yes It can be very Frustrating.

I'm learning new things about XAML everyday.

I think the problem lies in the fact that XAML reminds us of existing platforms (eg XML, and HTML), but does not act like either of them!

Answer 5

In short-

XAML has a steep learning curve.
But once you have learnt it, I think you'll love it.

Answer 6

Like, but tooling support is bad right now. Also it feels wordy.

On the other hand the alternative (writing WPF in C#) is a lot worse.

Answer 7

XAML, at its core, is a declarative UI markup language. WPF and Silverlight are simply the two most popular rendering engines for XAML. The benefit of having an XML-based markup for your UI is that it can be serialized/persisted/deserialized easily with today's technologies and it can be rendered into other technologies (think HTML/CSS/JavaScript or WinForms) if you're up to writing that particular rendering engine. Also, being XML, it's a lot easier to morph into whatever future technology replaces XAML. Try that with ol' Windows Resource files!

At a prior job, one of our architects saw an extremely early version of XAML while at Microsoft and based on the idea, created something similar for us to use long before XAML made it to market. Once XAML did, we had a fairly easy time converting our implementation to it. All that being said - at the time (I don't know about today) it only rendered to HTML/CSS/JavaScript in our run-time.

All that being said, it's a bit cumbersome for me as I learned my UI back on Delphi and C# WinForms - something I need to get over more than anything.

Answer 8

Perhaps your issue really is more one of tooling than of technology. The important thing to remember is that XAML isn't a programming language, it's a form of serialization of various elements.

WPF and Silverlight use XAML for their visuals and resources, but at the same time, Workflow (WF) 4.0 uses XAML as well, though you typically use the designer if you're using the designer method. However, any control and functionality you add and specify within the XAML file can also be done directly in .Net code, including creating UI elements, transforms and binding.

Answer 9

I like XAML, but it would be better if support Generics.

You can easily create control, assign its properties, apply static and dynamic resources (such as styles, templates), even declaratively program simple logic via triggers (things like "if the mouse is over then change the color to red"). Plus, the automatic layout makes it is really easy to create complex visual interfaces of composed controls.

However... when defining a new control, it lacks the ability to define generic type parameters in order to make specific logic for constrained logic scenarios. For example, you could define a "FancyList" control, but (at XAML level) not a "FancyList" as good old C# code would.