Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as not constructive by Yannis Rizos Mar 12 '12 at 20:46

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

7  
I'm not even sure XAML was ever advertised as a real programming language? –  stijn Dec 1 '10 at 8:03
    
@stijn It's not. –  MetalMikester Dec 1 '10 at 11:28
    
@stijn - It isn't, it's an XML based serialization format, which is used by WPF, Silverlight, WF, etc. –  Hugo Dec 1 '10 at 20:39
    
@Hugo I know what it is :], I just raised the question because to me it doesn't seem completely fair that the author is comparing XAML with a programming language, while it's merely an elevated form of xml used to describe user interfaces. –  stijn Dec 2 '10 at 11:31
1  
It's more than just a serialized GUI, but not quite a real programming language. My issue is that it exists in this in between state that doesn't work. –  Cameron MacFarland Dec 4 '10 at 0:41
show 2 more comments

9 Answers 9

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
share|improve this answer
6  
I'd argue that all those features are not features of XAML so much as WPF/Silverlight. –  Cameron MacFarland Dec 1 '10 at 23:38
add comment

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.

share|improve this answer
    
I didn't find Blend particularly useful. If you are not creating something too special (that involves animations), there is no real use for it. You might say that still a fail, but then again, creating the same complexity with HTML+CSS+JS would be equally hard (and/or require a special tool). –  Tamás Szelei Dec 1 '10 at 13:37
    
@Tamas -- agreed it might be equally hard but the separation makes it cleaner and therefore more maintainable –  Watson Dec 1 '10 at 14:10
4  
Separation is possible in XAML, too (it has styles and resources aimed right at this goal). It's not enforced, but neither it is in HTML. –  Tamás Szelei Dec 1 '10 at 21:00
    
@Tamas -- do you have any tutorials / examples of how this would be done? Thanks! –  Watson Dec 2 '10 at 12:42
    
I read Charles Petzold's Applications = Code + Markup. I didn't look for tutorials but I bet five minutes of googling will turn up something useful (search for wpf styles). –  Tamás Szelei Dec 2 '10 at 13:06
show 1 more comment

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.

share|improve this answer
add comment

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!

share|improve this answer
3  
+1 completely agree -- if feels like XML or HTML but it's definitely not -- and when you find out it's not -- it's already too late, you've already paid for dinner and you're back at your place, and you've got to pay a taxi to take him/her home ~~ wait what where we talking about? –  Watson Dec 1 '10 at 13:16
add comment

In short-

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

share|improve this answer
3  
Sorry, but I've been using XAML for 2 years now and I'm fairly certain I've learned it. And I still hate it's friggin guts! –  Cameron MacFarland Dec 1 '10 at 10:07
    
@Cameron MacFarland OK! Edited the answer. –  Gulshan Dec 1 '10 at 10:24
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.