- Aug 31, 2010 at 11:29 PM
- Shawn Wildermuth
- 12 Comments
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.
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.
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.
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.
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.
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.
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.
FWIW, there's a pretty good explanation/breakdown of the two technologies on the WhatWG wiki. 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 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.
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.
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.
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.