The Diminishing Importance of HTML. "HTML-based Web development has dominated application development for the last six years or so and there are no signs of that changing. However, things are changing as the .NET initiative takes hold. Although Microsoft has put a lot of effort into its Web-based interfaces, which include the powerful new ASP.NET Web Forms framework, I am guessing that there will actually be a push back to desktop-driven, forms-based applications once .NET takes hold." [sellsbrothers.com: Windows Developer News]
Ahhh, the question I keep asking myself: does .NET "invalidate" the work that has been done on Zeepe or UXP? The central thrust of the above article is that HTML based UIs are primitive or less rich than a UI based upon native OS code, and then dissallows the use of Java/Flash or ActiveX to get round the 'limitations' (there's no Tree control in HTML). Associated with this line of thinking is that HTML based UIs take longer to build than traditional UIs that might be built with say VB or C++.
The reason UXP came into existance was because I was bored to tears of the long-winded machinations that had/have to be gone through to write a simple frame window with a menu bar in VC++. VB/.NET reduce the tears but, as Visual Studio currently ships, I end up with a very dull looking application. As soon as I want a "richer" UI, simply to the level of Office style menu bars I have got to find a library somewhere to do it - OK they exist but now I want some of the richness that appears in html - say a simple pop-up panel with instructional text that is rich in appearance (use of bold/italics and color) or table rows with rich content. There's a quid-quo-pro here, .NET has solved some problems associated with web based applications and enables "rich" controls like tree-view but at the loss of richness elsewhere.
IE .htc components are a non Java/Flash/ActiveX way of adding richness and code re-usability to IE DHTML - the problem is you've mostly got to write them yourself or find others work - like looking for code libraries for .NET.
Way back when, I described (D)HTML as "breadboard" programming - you wire the bits you need together. (D)HTML applications should not be limited to the forms controls provided natively by the underlying browser since it is to miss the underlying strength of the browser - that it provides a framework into which you can plug whatever components you desire and wire them together in an extremely simple fashion. A browser should be, and is, a follower of the philsophy expounded by the originators of TCL and others - the runtime provides the fundamental services that can be scripted together to provide novel solutions.
There's a whole class of programs you can't write in DHTML - a drawing program for one - but why not have a drawing component and put a rich and novel UI around it using DHTML? Similarly, enterprise database management applications, forms entry whatever. The above article describes the horror of someone using a badly written survey program - it was a badly written program that was difficult for the user to use - it could have been written that badly in any language/development system. I've lost count of the number of times I have drawn dialogs with these wonderful RAD tools at our disposal, which involves adding/removing controls as the design process continues, only to forget that you have to redo the tab ordering once you've done or it works badly.
So, the point of Zeepe/UXP is to fill in some of the gaps in the IE native control set (menu bars, perhaps TreeView) and provide a neat and clean breadboard into which you can plug your components (the source is upto you; xml, .htc, .java, .dll, .net) and wire in a simple fashion. You get all the advantages of HTML based applications (auto code install/update, anywhere availabilty, rich novel UIs, security if you want) and none of the drawbacks of .NET - sandbox that can't be got out of, complex coding once you get beyond the point and click design process, complex coding to ensure users get the latest code versions.