HTML5, XAML and Declarative User Interfaces

At the suggestion of Tim Heuerthis week, I took a break from writing my Windows Phone 7 book to delve into HTML5 a bit. I wanted to see what was different and how it would possibly impact Rich Internet Applications (RIA).

I did a couple of HTML5 tutorials which include the new tags that I think will be really cool (like <nav/>, <article/>, etc.) for traditional web design. I think the <datagrid /> and <datatemplate /> tags are interesting but unsure about how they’ll be implemented. I also very interested in the local storage story, but it feels a long way from full implementation.  But I don’t want to talk about the entire HTML5 stack as I am just scratching the surface.

My real goal was to look at the <canvas /> element as that’s what I get asked about a lot when compared with Silverlight. In looking at it I was surprised. It seems that the only way to actually draw on the canvas is to use JavaScript.  While this is useful for interactive drawing and that sort of application it leaves me a little bewildered. When I asked about this on Twitter, I got a couple of answers like “just use SVG”. But SVG is another disruptive technology thrown into the mix.  Browsers have to support it. I had expected that HTML5 was going to formalize the SVG support and make that the markup for the canvas. But it doesn’t look like that happened.  Maybe its me but if its not part of HTML5, then its another thing for the browser guys to agree on.  It starts to feel hobbled together for me. Another answer I got was that markup for Canvas didn’t matter. Canvas is for drawing and its just not necessary. But I will totally agree that I am viewing it from a XAML lens.

But for me, Markup matters. Without markup, it would be very difficult to build tools for the canvas. But this gets at a very heart of why I like XAML. Let’s start a long time ago. As we would design user interfaces and we the designs would take different forms (including binary files, generated code, etc.) The problem with this was that the designs were not easy to edit. More importantly was that the separation of business logic was particularly difficult. It became too simple to add and glue business logic to the user interfaces which of course makes it very difficult to test and extend existing systems. The typical spaghetti code problem.

As I’ve discussed before, I think there is a benefit of markup is that separation. But keeping the user interface design (look, feel, data binding, etc.) in markup, it encourages business logic to be separate from the user interface. Declarative user interfaces are a key to simplifying how we’re building applications.

Other basic idea here that is powerful in Silverlight is that the markup (e.g. XAML) represents the initial object graph that makes up the user interface. It is very common to change this as the application runs (in response to user input or other changes). This means we can build great tools to create the original look and feel and use code to make the application come alive and change the object graph as necessary.  Again, on Twitter I was cautioned against changing it too much using JavaScript. A weakness in my eyes.

That’s where I thought HTML5 was going to be doing great things. But at this point it feels like HTML5 is going to rely far too heavily on JavaScript (or any code for that matter) instead of allowing us to do more with design tools. In addition, I wish they had integrated SVG (or something similar) as a drawing/animation solution to be closer to a real, rich platform. Instead, HTML5 feels like another 1/2 measure.  But that’s my opinion with my prejudices…I am sure I’ll get an earful in reply ;)