HTML5, XAML and Declarative User Interfaces

  • Aug 31, 2010 at 11:29 PM
  • Shawn Wildermuth


At the suggestion of Tim Heuer this 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 ;)





The Luddite Developer Wednesday, September 1, 2010

Is HTML 5 is going to be the straw that beaks the camel's (in this case IE6) back and force most internet users to upgrade their browsers?

If not, developers are going to have their work cut out if they want to use HTML 5 and still have their websites viewable by 99% of web users.


Joe Wednesday, September 1, 2010

It's like HTML5 is being positioned as a runtime platform for other toolkits (like GWT) to use.
Would like to see SIlverlight/XAML added to this list of server side toolkits. A SL/XAML -> HTML5/JScript translator.


Marcelo Negrini Wednesday, September 1, 2010

I would love to see a future version of Silverlight generating great HTML5/JavaScript code as an automatic fallback for people without the plugin.

I know this is extremely hard to do, but see what Google did with GWT. It could be a degraded experience, slower or not supporting some features.

If we could control the behavior between the full and the HTML5 version we could support devices like iPhone and iPad. Obviously, ideally those devices should support Silverlight, but I don't see Apple and Microsoft coming to a deal on that.

Besides, Microsoft is doing a shitty job in porting Silverlight for other mobile platforms - the Nokia port is a joke - so it is hard to defend Silverlight as the best platform for mobile development.

I worked in Redmond, and I know they have the brainpower to solve all that. However, Redmond today has as many jerks mnaging the company as they have great developers. In many cases the first group cancels everything good that can come from the second.


Jonathan Thursday, September 2, 2010

I think you hit the nail on the head. I also did a lot of research into HTML5 before investing into Silverlight for a number of projects. I was so disappointed at HTML5 and how it will eventually just have the same issues we have struggled with for years with Javascript.

Also by adding to the mix of technologies by adding things like SVG, you are simply making it a harder learning curve for entry level people. Sometimes it is just time to step back and restart where people have no assumptions about what is going on and I feel that is what happened with Silverlight and why it is as successful as it is.

Anyways, great article Shawn.


Jon Galloway Thursday, September 2, 2010

I think of Canvas as a the equivalent of a WriteableBitmap, whereas SVG is more like your standard XAML. Canvas is for procedural graphics, and SVG is for retained mode graphics. Both have separate purposes.

I think Canvas gets way too much hype because Javascript is popular, but I hope people will get behind SVG. SVG has the advantages of markup that you point out, and is scriptable via Javascript as well.


Drew Marsh Thursday, September 2, 2010

FWIW, there's a pretty good explanation/breakdown of the two technologies on the WhatWG wiki[1]. Here's the short of it though:


SVG is a retained mode rendering pipeline, more like visual tree model of WPF/SL, which is why it has a DOM and markup.

Canvas, on the other hand, is an immediate mode rendering pipeline, much like WriteableBitmap in WPF/SL. It's all about drawing each pixel yourself using custom rendering logic. That's why there's no DOM for it and it's all script driven.


In the end, they are not competing technologies at all. We all just need to hope that all the browser vendors will support both technologies to the fullest extent of their repsective specifications. I think the three big players (WebKit, Mozilla and MSHTML9) already support the majority of it, so I think we're ok to rely on it for "HTML5" targeted web apps.

Still, for me, what makes these technologies less than ideal is that each specification was put together by different groups of people and the API design uses noticeably different conventions/patterns. Nevermind the fact that you need to bring third party libraries like jQuery into the mix to make working with the HTML DOM a richer/more dynamic experience.

Finally, my largest gripe which has been held since ~1999: there is still no standard component model for HTML. Ridiculous. Instead we have to turn to third party script frameworks to model that on top of the DOM for us. MS proposed and implemented a model[2] in IE4 that basically introduced logical vs. virtual tree that we're so familiar with in WPF now back in 1998, but nobody took it anywhere. It wasn't perfect, but it was a conceptual starting point. Instead Mozilla invented their own (XUL+XBL) and the standard has never advanced past original proposal. Real shame.




Ian Walker Thursday, September 2, 2010

We are all, including me, expecting standards to move faster than they ineviably do. Its frustrating but there you have it. At least on the plus side we have Silverlight & Flash which don't look to be going anywhere anytime soon.


Christian Heger Thursday, September 2, 2010

I think the canvas is a misfit in HTML5. Where HTML5 is really different from XAML is that XAML is the exact representation of an object graph; HTML5 is not. It is a lot more semantic, and in result, less exact. The canvas on the other hand is exact, and not semantic - I think it's useful, but basically an alien.


Bart Czernicki Friday, September 3, 2010

You hit the nail on the head with the "you still have to use JavaScript..." comment. Two problems with one really "writes" JavaScript anymore without a number of JavaScript frameworks/add-ons (i.e. jQuery). Second since these frameworks come and go and are open source, rarely are they compatible with the UI tools.

For example...say you want to use the new HTML 5 web workers (async code) and WebGL (GPU offloading)...I am sure there will be frameworks that will abstract tis for you that .NET does already. So to do a performant/multi-threaded UI in HTML 5 I will need to probably use 2-3 frameworks where in Silverlight its all in the .NET assemblies.


Justin Profaizer Friday, September 3, 2010

I was also a bit turned off seeing all of the examples of drawing on a canvas using javascript. I thought I must be missing something, but I guess not.

Leave a Comment