5 ms·

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

by aggronn 14y ago

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.

eatporktoo 14y ago
I personally like XAML. What part of it do you think was a let down?
soofaloofa 14y ago
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.
ayi 14y ago
i actually like xaml. can i ask what parts of it makes xaml let down?
- aggronn 14y ago
  from my main post edit: 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.
powertower 14y ago
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.
- candl 14y ago
  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.
- gbog 14y ago
  Please keep your ad hominem for other parts of the web.
  - powertower 14y ago
    "clue-less": without any clues about the workings and mis-workings (parts to stay away from) of XAML/WPF... Clues come from experience. And without experience, just starting out on a subject, makes you clueless about it.
    - MartinCron 14y ago
      While they may be technically correct, words like "clueless", "naive", or "ignorant" can be really aggressive and feel like ad-hominem. A more constructive phrasing might have been: The majority of people that I've heard criticize XAML are people who are just starting out with it and don't fully understand what it has to offer
- jinushaun 14y ago
  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.
deleted 14y ago
[deleted]
dharmatech 14y ago
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 https://github.com/dharmatech/FluentWpf) project on GitHub. An example: http://stackoverflow.com/questions/1347219/are-there-any-fluent-wpf-projects/10219862#10219862 http://stackoverflow.com/questions/1347219/are-there-any-flu...
- jcheng 14y ago
  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.
  - dharmatech 14y ago
    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.
x1 14y ago
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) <div class="dropDown" data="['frank','sam','larry']"/> <div class="expanderBar" data="['frank','sam','larry']"/> <div class="radioButton" data="['frank','sam','larry']"/> <class id="radioButton"> <div style="border:1px solid black"> <loop value="data" var="item"> <input type="radio" name="user" checked="condition">${item} </loop> </div> </class> ...and so on 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
dminor 14y ago
> 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.

by aggronn 14y ago

eatporktoo 14y ago

I personally like XAML. What part of it do you think was a let down?

soofaloofa 14y ago

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.

ayi 14y ago

i actually like xaml. can i ask what parts of it makes xaml let down?

aggronn 14y ago
from my main post edit: 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.

powertower 14y ago

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.

candl 14y ago
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.
gbog 14y ago
Please keep your ad hominem for other parts of the web.
- powertower 14y ago
  "clue-less": without any clues about the workings and mis-workings (parts to stay away from) of XAML/WPF... Clues come from experience. And without experience, just starting out on a subject, makes you clueless about it.
  - MartinCron 14y ago
    While they may be technically correct, words like "clueless", "naive", or "ignorant" can be really aggressive and feel like ad-hominem. A more constructive phrasing might have been: The majority of people that I've heard criticize XAML are people who are just starting out with it and don't fully understand what it has to offer
jinushaun 14y ago
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.

deleted 14y ago

[deleted]

dharmatech 14y ago

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 https://github.com/dharmatech/FluentWpf) project on GitHub. An example: http://stackoverflow.com/questions/1347219/are-there-any-fluent-wpf-projects/10219862#10219862 http://stackoverflow.com/questions/1347219/are-there-any-flu...

jcheng 14y ago
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.
- dharmatech 14y ago
  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.

x1 14y ago

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) <div class="dropDown" data="['frank','sam','larry']"/> <div class="expanderBar" data="['frank','sam','larry']"/> <div class="radioButton" data="['frank','sam','larry']"/> <class id="radioButton"> <div style="border:1px solid black"> <loop value="data" var="item"> <input type="radio" name="user" checked="condition">${item} </loop> </div> </class> ...and so on 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

dminor 14y ago

> 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.