.NET Questions

In the context of Silverlight, I like WPF and all the neat things it can do.  Under the hood, ActiveX and Javascript are driving all of these transforms, rotations and media integration.

But why do we need an XML based language called XAML to program against the WPF API?  What's wrong with the current ASP.NET code behind model?  Why not add transform properties to ASP.NET controls and allow me to access them?  With code behind, there is still very good seperation of UI and business logic (unless someone just wants to mangle that).  What benefit is XAML at all?  ASP.NET controls are still very declarative.

'Cos Microsoft says so. End of story.

Well, OK, in the real world, there's been a move towards declarative programming for a while. XAML is in some ways a logical successor to SGML-based markup languages like HTML and XML. Although of course XAML is an XML dialect it provides a way to bind presentational data (the declarative list of UI elements) with some or all of the code used with them. Now why, you might ask, would Microsoft be so bothered about that? Simply put, Microsoft needs to find new ways to exploit the processing power of the client as well as the server, if it is to continue selling operating systems for the next few decades. If true thin-client computing ever really got started, it would eviscerate the OS market. That's what Google is aiming for, and it's exactly the thing that Microsoft fears.

XAML allows you to export processing to the client machine in a way that mere script doesn't. In effect, you can stream the interface of an application, plus a portion (or even all) of its logic, over the wire using a protocol that's open on most firewalls. You can stream XAML into the browser and get something roughly equivalent to ActiveX controls or Java applets (which exports .NET to the browser as Silverlight has done, something Microsoft has been planning for a while). Silverlight is the first fruit of this particular plan.

However, don't expect XAML-over-HTTP to stay within the browser for long. It's a perfect way to provide desktop apps without installers, software-as-a-service, all the stuff Microsoft was supposed to be planning years back when people were still talking about Windows.NET - you didn't think they just gave up on all that stuff, did you?

Add to this the bare-metal hypervisor stuff they are developing - 'Viridian' for Windows Server 2008 will be a hobbled implementation of this, but there's more coming, and it will likely be the core architecture of whatever 'Vienna' turns out to be - and you can see a model developing of (supposedly) safe, sandboxed, virtualised applications streamed from the net over fast connections, always up to date, running partially on the client and partially on the server, potentially replacing today's stateless browser-based model of internet application.

I doubt the reality will live up to the dream - it never does with Microsoft, any more than it does with anyone else - but that's the reason they want you to buy into XAML in a nutshell.

Guess I'm getting lost in the details.

"XAML allows you to export processing to the client machine in a way that mere script doesn't."

How is that any different than a rich .net winform app that still works with a remote server?

"In effect, you can stream the interface of an application, plus a portion (or even all) of its logic, over the wire using a protocol that's open on most firewalls."

I understand the firewall friendly part and those are the advantages of ASP.NET and AJAX.  Is the main point that ASP.NET and AJAX alone will never give us nice WPF (working with WPF API) based interfaces?  XAML isn't a requirement for WPF.

You shouldn't be asking why we need XAML since you don't actually need XAML (as you pointed out) to use WPF. You should instead be asking why we need WPF. The answer is that no other system currently available is capable of create rich desktop apps and Microsoft decided to start from scratch and do it right. HTML is a piss poor way to create any kind of application and was never meant for the things that it is being used for today. The web is one giant band-aid and I'm personally very glad that MS didn't try and leverage it for making desktop apps.

So why do we need WPF? Because everything else stinks when it comes to making rich content based thick client apps.

"You shouldn't be asking why we need XAML since you don't actually need XAML (as you pointed out) to use WPF."

Let's not mangle the post...and that's not the question I'm asking.  The question in the post title is the question I'm asking.  Nothing else.  Most every WPF example is done in XAML with a C# backend.  That's why I say "need".  It gives the impression that we need XAML.

Let me rephrase just to clarify things: What is the point of an extremely verbose XML dialect like XAML when I can do everything I need with WPF via C#?

Perhaps XMAL is a little less code than using C# for the same thing.  Fine.  That's no reason for me to switch over to something so awkward and difficult to read (consider nested, nested, nested, ad infinitum tags).

I hope no one throws in anything about platform indenpence or something like that.  That decision is strictly up to the CLR, not XAML.

Not "XMAL" but XAML.

"How is that any different than a rich .net winform app that still works with a remote server?"

It isn't. Except that with an actual app you have the hassles of installation, maintenance and updating. Sure, you can have nice automated tools that make all that easy-peasy, but it's not quite as seamless an experience as actually downloading the code every time you use it. Of course, ultra-fast connections are a prerequisite for this kind of thing. I don't think most of the world is quite there yet. Maybe Korea.

Thing is, you can do some awfully clever things with AJAX and Web apps. We've also done a good job of getting the user used to a Web UI and automatically forgiving of the drawbacks. We use so many Web apps and crappy desktop apps that we've forgotten what a well-designed UI looks like. Google is king of the Web app. Microsoft sees that, and wants to change the game.

You can probably forget XAML for a couple of years at least. It's a sleeper technology. People will end up using WPF but they're more like to end up using it via VB or C# directly. Silverlight is the only place where you'll see any interest, and I'm not sure how quickly it'll catch on anyway.

Stick to ASP.NET for now and you won't go wrong. But keep one eye on what Microsoft is doing and you won't get caught out either.

That was a good synopsis of the current state of affairs on XAML.

By the way, I should have said XBAP app instead of winforms.

>> Perhaps XAML is a little less code than using C# for the same thing.  Fine.  That's no reason for me to switch over to something so awkward and difficult to read (consider nested, nested, nested, ad infinitum tags).

That, I believe, is one reason why you see most examples in XAML.

Another reason is that going forward, user interfaces may be designed using specific purpose (and not so developer-friendly) tools such as Expression. As an XML grammar, XAML is easier for such tools to generate and manipulate, and the end result can be handed over to developers using Visual Studio to complete the code part. This last could be done in the programming language of the developer's choice.

Hmm... how is this any different than the Java Applet of old?  Well, it's more advanced (and will overcome the limitations that killed the Applet - IMO it was a great concept), but it sounds like the "future" will be a rehash of the past.

Xaml can be useful for a number of scenarios, splitting the design and behavior into separate files is always a good thing, asp.net benefited tremendously from this.

Given Microsoft's release of tools such as Expression Blend allows UI design artists to work on the design while the behavior is implemented separately.

You don't *need* XAML, as technically you can still do everything with code.  In fact, under the hood, that's what happens: Even if you declare your UI with XAML, it gets converted into code; the compiler takes your "Window1.xaml" and creates a hidden "Window1.g.cs" with the same kind of Designer code as previous versions of .NET.

When I started with XAML, it could be kind of a pain, and I still think the databinding syntax is more confusing than it needs to be.  But I've found that XAML is actually a very cool way to make an interface.  In .NET 1.0/1.1 I found myself using an add-in to see a control outline, and in .NET 2.0 I often use the Document Outline to see the nesting of controls.  But with WPF and XAML, the nesting is declarative.  If I want a border around a textbox, I just nest the <TextBox> tag inside a <Border> tag.  Very simple and intuitive.

The VS 2005 designer for XAML is definitely not that good, though.  You have to know how to code the stuff by hand to get anywhere with it.

XAML is easier for tools to export that non-developers use. Take Expression Blend for example. It exports XAML. If it had to export actual code then it would be more difficult. After all, which type of code should it export? C#, VB.NET, Fortran.NET,....? You get the point. It would also have to compile so you would end up with loads of different ways that these tools could possibly declare variables and such and it would just be really messy.

Also, the code required to create many of the more complex layouts is absolutely ridiculous. XAML is much easier and reduces the amount of confusion significantly.

When I first started with WPF I created everything in code and scoffed at XAML. Now I like XAML much better.