This is the first time I've heard raving reviews about XAML from people familiar with HTML.
XAML has just been total let down since I've had to learn it for an ongoing Silverlight project.
edit: Some people have asked why I didn't like XAML. My pragmatic concern has to do with the workflow and design of UI elements. You shouldn't need blend to edit validation styles efficiently. I know you don't need blend, but you can't just go in and add a single line to change the color of an invalid toolbox border--the alternative to blend is to (afaik) copy the entire style resource that the element uses from MSDN, dig into it to find the appropriate 10 lines of useless markup that surround one word property.
CSS is infinitely more simple than XAML style resources.
I'm also very partial to the pseudo separation of concerns where HTML is for semantics, and CSS is for style, and JS is for effects. Tying all of those things into one XML based language just doesn't make sense.
That said, the whole MS C# stack has really been great to work with outside of XAML and its default elements.
> but you can't just go in and add a single line to change the color of an invalid toolbox border--the alternative to blend is to (afaik) copy the entire style resource that the element uses from MSDN, dig into it to find the appropriate 10 lines of useless markup that surround one word property.
This is spot on. The point of a declarative markup language is to make hand editing easy, but XAML fails hard on the simplest of tweaks.
Personally I've always found XAML and C# to be an incredibly productive programming environment. I wish I could work with the MS tool chain more often.
I disagree. I haven't worked in XAML for a few years and I wouldn't recommend it on almost any application (unless a windows specific desktop). But the only reasons I don't recommend it is because it is windows specific.
Aside from that the true power of xaml is it allows you to change anything. For example, A radio button group, checkbox list, drop down, expandable list or searchable list could all derive from the same basic component AND same set of data. In html that would be like saying this (warning, lots of fake code below)
That is COOOL and it has been around since XAML was created. We've tried to get to the same place with jquery templates but they have always been hackish approaches to templating/styling
The majority of people that I've heard criticize XAML are people who are just starting out with it (and hence are clueless, literally).
Everyone else, including myself, see it for what it is, one of the best ways to build up, iterate/change, and maintain a UI.
Nothing else even comes close.
edit: I write XAML mostly manually, not via a designer. I also don't subscribe to any particular rule-set about using or not-using code-behind, particular ways of databinding, etc.
I've been working with XAML for years on a regular basis. It sucked in 2009, and it still sucks now.
It quickly progresses past hand editing on any project of any significant complexity. (Read: a real app) So Blend is required, especially if you're doing animations. VS is only slightly better than notepad for XAML.
XAML parsing is consistently broken in Blend and VS, so bad markup breaks the entire file without any meaningful error message. On a related note, it is very difficult to make "Blendable" XAML files. Wiring up data-binding kills blendability. You end up opening a lot of "blank" files in the designer.
MVVM is a pattern to avoid having to deal with XAML.
XAML is more of a human-readable file format than a presentation markup language. You have a lot of information about the app/state mixed in with the UI markup. You need to have a solid understanding of the C# underneath to use XAML properly.
Designers should NEVER be allowed to produce their own XAML, especially in Blend. It's worse than Frontpage. The cake is a lie. Designers still live in Photoshop and Illustrator. Programmers are actually the main users of Blend. The root problem is that you can't produce usable XAML without also knowing C# and the .NET Framework. In other words, you have to be a programmer to generate XAML in Blend. Fail.
The root problem is that you can't produce usable XAML without also knowing C# and the .NET Framework. In other words, you have to be a programmer to generate XAML in Blend. Fail.
That's like complaining about gravity or friction or taxes. Give me an example of a software tool that non-programmers can use to generate working software and I'll eat my hat.
> Give me an example of a software tool that non-programmers can use to generate working software
XAML isn't working software. It's markup. UI.
For an example, I've seen designers generate great HTML+CSS (and then leave the data queries and ajax post to coders who don't have the same design sense).
Designers use tools, and they edit the resulting textual markup by hand. Because understanding that markup and having an aesthetic sense about when it "looks good", has low repetition etc is part of their skillset.
It does have it's bad spots, but I really don't see how something can "suck" when 1) it works and 2) every single other alternative is light-years behind.
If you are coding and not working with designers or using Blend, sticking with plain-old C# is better. WPF/WinRT/Silverlight are just great APIs, that they are somehow associated with XAML is orthogonal (my personal opinion, not speaking for my employer).
I agree. I was exposed to C#/XAML a few months ago by building a WP7 Application. It takes some getting used to, but when you get the basics it's great. I'd kill to have something similar instead of HTML/CSS (which is just awful in comparison) for the web.
My beef with XAML is it's a whole other language aside from C# into which the semantics of C# and WPF had to be mapped. Worse, the constraints of XAML affected the design of WPF itself. I.e. the tail wagged the dog.
If C# had hygienic macros, I think the syntax of C# could have been extended for WPF specific needs, without having to resort to an XML based solution.
With a few extension methods, C# can come close and sometimes exceed XAML in its concision. I've been collecting these in a FluentWpf (https://github.com/dharmatech/FluentWpf) project on GitHub.
But XAML was intended from the start to play well with visual design-time tools, and C#-with-macros would probably have been too expressive to be roundtripped reliably through Blend and the VS designer.
C# with an ordained set of macro based extensions intended for use with WPF would work fine with a visual designer like Blend and the VS one. The visual designers would be the ones generating this code, so they'd know how to parse it.
edit: Some people have asked why I didn't like XAML. My pragmatic concern has to do with the workflow and design of UI elements. You shouldn't need blend to edit validation styles efficiently. I know you don't need blend, but you can't just go in and add a single line to change the color of a border--the alternative to blend is to (afaik) copy the entire style resource that the element uses from MSDN, dig into it to find the appropriate 10 lines of useless markup that surround one word property.
CSS is infinitely more simple than XAML style resources.
I'm also very partial to the pseudo separation of concerns where HTML is for semantics, and CSS is for style, and JS is for effects. Tying all of those things into one XML based language just doesn't make sense.
That said, the whole MS C# stack has really been great to work with outside of XAML and its default elements.
XAML has just been total let down since I've had to learn it for an ongoing Silverlight project.
edit: Some people have asked why I didn't like XAML. My pragmatic concern has to do with the workflow and design of UI elements. You shouldn't need blend to edit validation styles efficiently. I know you don't need blend, but you can't just go in and add a single line to change the color of an invalid toolbox border--the alternative to blend is to (afaik) copy the entire style resource that the element uses from MSDN, dig into it to find the appropriate 10 lines of useless markup that surround one word property.
CSS is infinitely more simple than XAML style resources.
I'm also very partial to the pseudo separation of concerns where HTML is for semantics, and CSS is for style, and JS is for effects. Tying all of those things into one XML based language just doesn't make sense.
That said, the whole MS C# stack has really been great to work with outside of XAML and its default elements.