WPF versus WPF/E

I sat down to look at WPF/E this evening. WPF/E is Microsoft's cross-platform XAML engine that runs in a web browser. The technology is currently in a community preview stage.

I thought a good first step would be to port my "Game of Life" WPF application to WPF/E and see the game run in a browser. A quick look at the documentation revealed that WPF/E doesn't support data binding, resources, or layout controls (like the Grid). 

A good contrast will be to compare the following snippet of WPF code to my hacked up WPF/E equivalent. This C# code dynamically creates a "life" indicator in each cell of a grid control.

With no data binding, no resources, and no Grid control, the JavaScript code for WPF/E has to take an alternate route.

WPF/E has some clever solutions to tough problems. There is no Ellipse constructor function as you might expect. That approach would require a massive JavaScript file with functions defined for all the WPF/E objects. Instead, we create objects graphs using XAML fragments. The code merely needs to pass these fragments to the WPF/E ActiveX control's createFromXaml method and receive an object in return. Also, notice the syntax for attached properties in WPF/E (ellipse["Canvas.Left"]).

If I had $100 to spend on WPF/E features, I'd spend the whole lot on adding data binding and layout controls. Overall, WPF/E is a bit different from what I expected before I started this evening. At this stage, the technology is good for performing animations, and playing media. No small feat, really, but anything the team can add that will facilitate day-to-day business requirements (build a dashboard of key performance indicators, fill out an insurance claim form) would make the technology terrific.