The Old Joel on Software Forum: Part 3 (of 5)

XAML... what's it good for?

I've been reading up on the Longhorn features, and particularly XAML. There's a good article here:

http://msdn.microsoft.com/longhorn/default.aspx?pull=/msdnmag/issues/04/01/Avalon/default.aspx

However, I can't seem to grasp the benefit of using XAML over a traditional declarative language like VB.Net or C#, at least for traditional Windows forms applications.

In many ways it looks basically like a matter of syntax. For example, these two code snippets (from the article) are functionally the same:

<Button Background="LightSeaGreen" FontSize="24pt">
Calculate
</Button>

Button btn = new Button();
btn.Background = Brushes.LightSeaGreen;
btn.FontSize = new FontSize(24, FontSizeType.Point);
btn.Content = "Calculate";

Both express the same idea -- draw a button called "Calculate" using the specified parameters. Although the XAML code is slightly shorter, it doesn't provide any functional benefit over the C# code.

Further, for producing any code that actually useful, you'll have to embed "real" code (C# or some other language) within the XAML, which then has to be compiled into intermediate language code. I'm wary about the need to mix-and-match two different languages (e.g., XAML and C#) to produce usable code when one language (C#) can do the job perfectly well by itself.

The only obvious benefit is that the XAML code is arguably easier to read than comparable VB.Net or C# code. However, few people actually code their GUI elements by hand -- most people just use the Visual Studio forms designer and use the autogenerated code. (Even with XAML, there should hopefully be an equivalent forms designer -- writing the XAML by hand will be tedious.)

I can see how XAML could potentially be a benefit for ASP-style applications -- but Microsoft is apparently positioning this as the new paradigm for desktop applications as well. What am I missing -- how is XAML preferable to ordinary declarative languages?

Robert Jacobson
Saturday, November 1, 2003

Chris Anderson says ... http://blog.simplegeek.com/PermaLink.aspx/100aec62-3352-4c35-b471-f3f2fa5fac5a

EastIndian
Saturday, November 1, 2003

Probably because VB has too much syntax to be a knowledge representation language? Hard to manipulate and syntax details can quickly become obsolete whenever the VB team chooses.

There is one class of languages out there that blurs the distinction between code and data, but its fatal flaw is its most popular dialects use the wrong kind of bracket. (sarcasm :off)

Tayssir John Gabbour
Saturday, November 1, 2003

Just a quick terminology note, FYI and to avoid confusing people in future...

"However, I can't seem to grasp the benefit of using XAML over a traditional declarative language like VB.Net or C#, at least for traditional Windows forms applications."

As I understand the term, declarative languages are things like SQL, HTML, and to an extent, Prolog. I wouldn't call VB, C# etc declarative - perhaps procedural or imperative or something similar :-)

Regards,
Christo

Christo Fogelberg
Saturday, November 1, 2003

> As I understand the term, declarative languages are things like SQL, HTML, and to an extent, Prolog. I wouldn't call VB, C# etc declarative - perhaps procedural or imperative or something similar :-) <

Very true -- sorry about that.

Robert Jacobson
Saturday, November 1, 2003

One thing to note is that a declarative description of a GUI like the XAML one is working at the level of specification, whereas the more traditional VB description of the GUI is working at the level of implementation. This has some implications about where and how the GUI is eventually realized. There are some similarities to designing a system of interfaces versus designing the system with abstract classes.

swanson
Saturday, November 1, 2003

I think the idea is that XAML will be used to deploy rich-GUI over the web (assuming of course, that the client machine is running Windows Longhorn and IE 7+).

Instead of using the applet strategy of transmitting bulky class files over the Internet, to be interpreted by a slothy JVM, they can just transmit an XAML file which is no larger than a typical HTML file, and native OS libraries will read the tags and render the screens and widgets for the application.

T. Norman
Saturday, November 1, 2003

And of course, an important "side effect" is that they'll be able to exert control over the Internet, once XAML's use becomes widespread enough.

T. Norman
Saturday, November 1, 2003

If I understand it correctly, XAML is Microsoft's version of Mozilla's XUL. If XUL was popular, they'd probably have embraced and extended it. But XUL isn't popular, so they start out something new.

XUL's (lack of) popularity is not based on merit, btw. It's not perfect, not bad either -- but that's not the issue. It's just that it is -- relatively-- unknown to the world at large.

Most of the benefits that XAML promises to deliever have been delievered by XUL two or three years ago or so.

Ori Berger
Saturday, November 1, 2003

This is a dupe of an earlier post. Lot's of analysis and clarification here.

Some XUL/XAML analysis here:
http://www.xulplanet.com/ndeakin/

And Don XML on XAML/SVG-RCC:
http://weblogs.asp.net/donxml/posts/32121.aspx

And more informed analysis:
http://www.joehewitt.com/

http://weblog.infoworld.com/udell/

fool for python
Saturday, November 1, 2003

XAML is a last grasp attempt at forestalling the shift to web development. Working in several large corporations, I have witnessed an absolutely seismic shift in the majority of application development - From Win32 Visual Basic/Delphi/C++ work, to DHTML/XML/XSL style development served through a web server. In that scenario, the client operating system basically is wide open given that a modern standards compliant browser is accessible (which is virtually all platforms with a project like Mozilla).

Of course most corporate workers still use PowerPoint for their presentations, and Word for their documents, but the scary thing for Microsoft is that the underlying pressures forcing a continued use of the Microsoft platform have been greatly diminished. XForms will be yet another step in the direction of an irrelevant client platform. XAML is a "look, it's declarative like HTML, but with extra widgets and gizmos".

Dennis Forbes
Saturday, November 1, 2003

Well, thanks to everyone for the thoughts. I understand that this could be highly desirable for Web applications. However, I still don't understand how this offers a superior model for "old fashioned" Windows GUI applications. I hope I'm not being dense -- but as a Windows app developer, I'm still rather underwhelmed by this.

Robert Jacobson
Saturday, November 1, 2003

I helped implement a gui system based on xml a while ago, and it was basically a forced choice because we needed multiple platforms (language, os) to create reasonably similar guis. Xml wasn't forced, just abstracting it out to an i/o format was. Microsoft appears to be in the same bind with .net.

Also, there are random advantages for maintaining a nice design where you separate computation and data. When you localize to foreign cultures, you almost certainly have the details in some file or other storage already. Accessibility to the handicapped and stylesheets are also helped, if the design is done right.

Maybe there are deeper advantages than I've thought of. For example, I'd really like a designer be able to spit out a few gui mockups, pass it to a programmer who annotates them with events and control functions, and somewhere there's a usability honcho using a tool to tweak them while the first two watch and consider.

When I learned common lisp this year, this style became more natural to me; it's not strange anymore for code and data to mingle. Someone mentioned blog.simplegeek.com earlier, and there he mentions namespace difficulties that probably have something to do with the traditionbound segregation between code and data. In most languages, this probably looks like "effort" to get done, which is usually the sign of a bad design; but this instinct can lead us astray when a new thing comes along.

Tayssir John Gabbour
Saturday, November 1, 2003

I'm with Robert on this one. These changes are horrible for people writing applications. They lend themselves better to automation controlled by someone else though. Part of the trend to dumbing down programming, I think.

I've see applications built like this and they were interesting, but not enough that I would want to write logic using a text format. They had the theoretical benefit that the UI could be updated by sending a new text file, and so theoretically business rules could be changed anytime and complete new application sent out.

In practice, the app was an absolute dog to start, because it had to compile itself on startup. The theoretical benefits of having a dynamically updatable UI were not achieved because the text format was just too loose to accommodate any but the most trivial changes. I was not involved, by the way.

Saturday, November 1, 2003

Cocoa (Apple's current reccomended dev environment) apps are pretty much built this way. don't know if nib (NeXT Interface Builder) files are text or binary, but they do separate out UI from code.

mb
Sunday, November 2, 2003

Nib files in Mac OS X Cocoa - just like in NEXTSTEP before it - are serialized object archives. They're in a binary representation by default, but as of Panther it's trivial to turn on a text representation instead. (It's not that useful a text representation, but it exists.)

There's a big difference though, between what is used in Cocoa and what's used in XAML. With XAML, you lay out your interface. Then you compile this XAML file, generating C# (or maybe IL) that actually builds the interface. Then you write the code that implements the actions invoked from the interface. Then you link these together, and you have an application.

With Cocoa, you lay out your interface visually as a nib file. Then you write the code that implements the actions invoked from the interface. You include the nib file in your application. To use it, you load it at run time and *all of the linking of interface objects to properties* and *all of the linking of actions* happens *at run time*. There's no "compile your interface to the code that instantiates it" step.

What's frustrating reading about XAML is that NEXTSTEP has worked this way for 15 years, and gets it more right than XAML does. Why does XAML need the compilation phase at all, why isn't it purely declarative and entirely instantiable at run time like nib fiels? That wasn't even a hard problem in the 1980s, it's certainly not one now.

I've been talking a bit more about this stuff on my weblog at http://www.livejournal.com/users/chanson/

Chris Hanson
Sunday, November 2, 2003

Borland Delphi works in a similar way. The form is stored in a .DFM file. For a form containing a button, the .DFM code reads:

object Form1: TForm1
Left = 192
Top = 150
Width = 696
Height = 480
Caption = 'Form1'
Color = clBtnFace
Font.Charset = DEFAULT_CHARSET
Font.Color = clWindowText
Font.Height = -11
Font.Name = 'MS Sans Serif'
Font.Style = []
OldCreateOrder = False
PixelsPerInch = 96
TextHeight = 13
object Button1: TButton
Left = 104
Top = 64
Width = 177
Height = 65
Caption = 'Button1'
TabOrder = 0
end
end

Jammer
Sunday, November 2, 2003

Linux is threatening the Microsoft dominance of the OS.

In order for MS to continue dominating the OS market, they need to apply the same pressure they applied to OS/2: the fact that Windows has a lot more application than any competitive OS.

And, in order to enhance that pressure, they need as many developers as possible to develop for Windows.

So, they improve their Windows development tools.

There is a huge number of web programmers who know HTML and maybe a scripting language such as PHP or ASP.

By inventing XAML, Microsoft makes Windows application programming a lot more accessible to the web programmers.

XAML is a model that web programmers know and understand very well.

This is bad news for people already doing Windows programming - our work space is going to be flooded with web programmers wanting to write Windows apps.

MM
Sunday, November 2, 2003

btw MS should change the moniker XAML. It's ugly.
Maybe XPL (P for programming). Or they should dismiss the X part, because you can't go any cooler than 'XML'.

Marketing guy
Sunday, November 2, 2003

> btw MS should change the moniker XAML. It's ugly.
Maybe XPL (P for programming). Or they should dismiss the X part, because you can't go any cooler than 'XML'. <

On that note, what is the official pronunciation of XAML? Is it X-A-M-L (a mouthful), or "zamel" (like "camel")?

Robert Jacobson
Sunday, November 2, 2003

i am a bit confused:
declarative GUI' is a fancy word for resource files.

is XAML a thing that is on top of windows HWND's or .NET Windows Forms ?

For windows you have resource files - perfectly adequate for dialogues (i.e. forms).

Windows forms has .resx

So what's the big deal about another resource file syntax?

Michael Moser
Monday, November 3, 2003

XAML files are the next generation of resource files. The exciting thing about them isn't that they're resource files reformatted as XML. It's that they offer much more functionality than resource files have typically presented in the past -- for example, smarter flow control, fancier styles, and hierarchical layout. Some of these things have existed in resource files for specific development environments but this makes the functionality available to all Windows development environments.

I'm pretty sure that XAML is pronounced "zamel". I've watched a few videos of XAML presentations and that seems to be how the Microsoft guys pronounce it.

SomeBody
Monday, November 3, 2003

The separation of user interface programming from the logic of a problem is a big win. I teach a lot of Java programming to beginning students and their struggles with insane number of possible ways to create a GUI is disheartening (listening in this, anonymous inner class listeners, named innerclass listeners, subclassing, action objects, ...). The typical beginning student program is 90% GUI and 10% logic, generally not cleanly separated.

I tried out Thinlets (similar to XAML for Java) and was astounded at how easy and short the code was that produced a typical student problem interface. If something like this was standard, it would give student programming a big boost. And this is no ad for Thinlets -- they are designed for handhelds, are being rewritten, controlled pretty much by one person, ... There are lots of other similar projects, but this is the only one I got running effortlessly. It made me a strong believer in this approach.

Fred Swartz
Sunday, January 25, 2004