WebForms, Winforms, XUL, XAML?

I was recently following a thread on Chris Sells' WIN_TECH_OFFTOPIC.  The original request was for a good rich edit text box for a WebForms App.  After much discussion, Rob Nimmo came back with the following remark:

"Mind you it got me thinking - I had a chat with one of our devs
as to what the advantages or disadvantages to doing an in house
app as Winforms over Webforms... To tell the truth, I hadn't given
it an awful lot of thought..."

Hopefully, in the future, none of us will have to give it any thought.  Eventually Web Applications and "Thick" applications will merge, and there will really be no choice.  All applications will provide rich user experience with the convenience of readily available updates and all the other advantages that come with Webforms.  One-Click Updates, XUL (and Microsoft's copy of XUL, XAML) are merely steps in this journey.

2 Comments

  • I thought that would inspire some feedback ;-)

  • I think its very doable to define the majority of most applications with just meta-data -- and then have an engine create the appropriate rendering, which may be WinForm for rich clients, WebForms for web clients, and of course the future may be XAML or XUL. But the rendering itself will always be different for these different clients -- and I'm not sure from your post if you are referring to the same type of approach as I am -- or if you mistakenly think that the clients themselves will someday require just one rendering. If you buy the meta-data definition and engine theory, then hopefully XAML will fulfill the promise of having just one markup and engine -- but I doubt it personally. In the meantime, you certainly can create custom solutions to do this today -- in fact many teams do a large percentage of their apps with such meta-data and code gen. For me personally, I'm not a big fan of code gen, so I'm building a "UI Mapper" that hooks with my OR Mapper -- just define the UI meta-data one time, along with the OR meta-data, and I dynamically create the appropriate UI rendering at run-time, along with the persistence logic. Of course it will never be good enough for the most complex screens in most apps, but the huge majority of screens are always pretty basic and quite easy to do this way.

Comments have been disabled for this content.