Regardless of how you feel about XAML, you'll have a very hard job convincing me it's the best it can be.
What do I mean?
- There's not a lot of (if any) development or investment being done by Microsoft (or other companies) in new and improved tooling that can help people write and work with XAML.
- There have been no real changes in XAML and its capabilities since it came out.
- There's fractured ownership of XAML dialects and tooling within Microsoft.
- No experimentation or investigation is being done on what can make it better.
- XAML being written today looks (mostly) the same as that written 15+ years ago.
Think about writing C# code the way you did 15 years ago.
At best, I'd argue that XAML can really only be considered as being at version 2.0.
Imagine if you still had to use version 2.0 of C#. Would that be as pleasant, enjoyable, and productive as you'd like?
As things are, the "problem" with XAML has some consequences:
- Because things haven't changed, there's an expectation that things can't get better. We complain about how bad things are but don't think about improving them.
- Fear of change is common, and a lack of change helps create a self-enforcing feedback loop that means any change is feared even more.
- Because no one is asking questions, it creates an expectation that no one should.
- We get so used to seeing things the same way that it's easy to assume that anything new (or different) is automatically assumed to be wrong. Yes, this is a form of Stockholm Syndrome.
Tens (hundreds?) of thousands of companies are building applications with XAML.
There are millions of apps in existence that use XAML and they are used by even more people, but they're not as easy to write, support, maintain, and improve as they could be.
Why aren't more people talking about how things can be better?
I have ideas about how things can be improved and will share them.
However, I want to be wrong about this.
"XAML being written today looks (mostly) the same as that written 15+ years ago" This is not a valid criticism - you could say the same of HTML. View the HTML source for this very page and the html tag still has an xmlns attribute with the XHTML namespace. The fact that XAML has remained stable and is in wide use to this day for building UIs is a strength, not a weakness. Your other criticisms are more valid though.
ReplyDeleteOne thing I would like to see in XAML is improved support for basic XML-related stuff, like XInclude or XPointer (https://www.w3.org/TR/xinclude-11/) for breaking up the parsing of XAML files at compile time. In some cases, it's better to break up XAML into compile-time units, rather than using a custom or user control.
I won't argue that HTML is perfect and it can end up as "div soup", in that HTML is rarely ever used on it's own, but in combination with JS & CSS, if you look at the three together, there are big changes over the last few years.
DeleteA thing happened some 5 years ago, during the .NET Standard and .NET Core days.
ReplyDeleteThere was blog and github repo about creating XAML standard, addressing the same concerns as you did, trying the same approach as .NET standard. Create a subset and align the different dialects, so all those budgets sank into developing tooling could actually be made cross compatible.
I struggle to remember the XAML specific tooling for designers. Ligthswitch or something? It had Visual Studio branding and was MS official.
XAML Standard was intended to address some of the inconsistencies between the different "dialects" of XAML. While it did (apparently) lead to a few small changes three was too much confusion around it's purpose, not enough drive from "on high" to get a lot done, and little short-term benefit for anyone involved.
DeleteHehe, to be honest I wouldn't feel too bad if C# remained at 2.0. This is lying of course because I do enjoy most of the latest additions to the language, but ...on the other hand even now I do not trust LINQ completeley and sometimes my head explodes when using async, not to mention EntityFramework which I still believe it is the best and most beautiful bad ideea no one should really use. Nowadays I get the same feeling about C# as when I had when working in C++ using Boost and functors and all the ugly stuff that made me happily go toward C#. I would really like a new higher level .net language that would make things easier.
ReplyDeleteThere's F#!? While a new high-level language may introduce some benefits, I'm more interested in improving what we have today and the ways we can work with existing code-bases. When we hit some hard limits there, I might be interested in something new--and that could justify rewrites.
DeleteI think the bulk of this goes back to longhorn days. I remember Charles Petzold commenting on this. He thought XAML was great and suggested that features be added to make it more programming friendly. He was told that such things were not needed because no-one would hand write xaml. All xaml would be created via Blend. Your analogy is perhaps a bit off. I don't think it's that XAML hasn't progressed in the way C# has, I think it's that it was specifically designed not to progress. Imagine they had released C# but without the BCL. Instead they provided a complex hard to use GUI that let you inject BCL functionality into your code where you needed it. If that had been the case I don't think C# would have progressed much either. XAML is exceeding powerful, and it is exceedingly difficult to access most of that power. As far as MS is concerned you don't change XAML you update Blend. If you say "hey, I'm a programmer, not a graphics designer", the MS will tell you that you either need to hire a graphics designer or learn to be both. Improving/updating/evolving XAML would likely create all sorts of problems for Blend. In short XAML was designed to be the output of the Blend tool. You don't edit an excel file with vi, you can, but you don't.
ReplyDeleteHowever, MS is a big company and the VS team has always been pretty responsive to customer demands. The first XAML designer I believe was added to VS largely for debugging Blend output. However, it turned out that over time most programmers still find it easier to approach problems like programmers, rather than like graphic designers ... so VS has made the designer progressively more useful, within the constraints of how XAML was designed. Unfortunately, this has lead developers to see the XAML designer to be a sort of modern replacement for the Winforms designer ... and many developers rejected XAML because of the perceived (and actual) complexity.
I too wish that XAML was more of a rendering "language", something that would allow me to abstract things more easily. Unfortunately, that just wasn't what it was designed to be. I suspect the best approach would be to write a language that would output XAML (or BAML) as it's result. That could accommodate some of the dialect drift and provide a much easier path for feature evolution, above the level of the output format (XAML).
Yes, Blend is a big factor in this story. This blog post is a small part of a larger talk I've given and spends some time on how Blend factors into the story of how we have ended up where we are. Ultimately, when it was realized that many fewer people were using Blend, there wasn't a large enough shift away from what was expected developers would to towards helping them in the ways they are working.
Delete