TodG

I develop a products that require both web and desktop versions and it was my hope that WPF/E would finally provide me with a model where I could share a whole lot more of my code base between these two environments. As much as possible, I'd like to have my designers generating XAML without any concern for whether the interface they design will be running in a browser or as a desktop application.  Of course, I need to achieve all of this without requiring my web clients to install the full .NET run-time (otherwise I'd just do XBAP and this wouldn't be a problem).

Based on the feedback I'm seeing, I'm not sure whether this goal is consistent with the long-term vision for WPF/E. I see lots of threads where this idea seems to get treated as if it "out of the scope" of what's envisioned for WPF/E. In fact, some seem to suggest it's entirely impractical given the size and other constraints that are also part of the WPF/E mission.

At the same time, I think there's a relatively large population of developers out here who really want WPF/E to be a tool that we can use to build information systems. That means supporting text alignment, grids, buttons, combos, user controls, custom controls, and all the staples I have available to me with WinForms/WebForms. Now, what I'm hearing is that it may be unrealistic to expect WPF/E to take on this functionality without becoming too large. Ultimately, I could imagine someone saying: "by the time we add all that functionality, the download would be as large as footprint of the entire framework." And, if that's the case, I'll undertand and I'll re-adjust my expectations for WPF/E.

We're all out here just trying to figure out how much functionality WPF/E will ultimately support to determine how--or if--we should leverage it for our solutions. For me, I'm looking at Flex and some of the other RIA frameworks that provide all the elements I need, while still holding out hope that WPF/E might add the funtionality I'm looking for. I don't really want to have separate frameworks from separate vendors for my desktop and web solutions, but I'm also not sure I'll have a choice if WPF/E isn't expected to bite off this broader set of features. Either that, or I'm back to ASP.NET and trying to weave together some combination of elements that still give me the "snappy" user experience I'm after.

Is there any chance that someone at MS will make a more definitive statement about the long-term plans for WPF/E Will it take on the broader role Will it be allowed to grow enough in size to give us all the building blocks we need to start assembling complete applications Is it meant to be more of a companion to WebForms or could it ultimately be used as a complete replacement for WebForms Any insight that helps clarify this would be appreciated.

Tod



Re: Silverlight (formerly WPF/E) General Discussion Roadmap for WPF/E?

mcbsys

Excellent question. I'm also at a decision point on what platform to use for new web applications. In addition to the reasons you mention, I'm also interested in WPF/E for its Macintosh capabilities.

In the official Architecture Overview, if you look at the "Microsoft UX continuum" illustration, it seems clear that WPF/E, in the form of XAML and the .NET CLR, is meant to overlap and go beyond the traditional webforms approach. However, if you scroll down to the "Scenarios for using WPF/E" section, only three applications are suggested:

  • Web media°™Branded playback with events, video and marketing mix, dynamic videos with ads, audio playback, and so forth
  • Rich islands on a page (mini apps)°™Casual games and gadgets
  • Web visualization elements°™Navigation properties, data visualization, and ads

There is no mention of any plan to support text-based web applications, which of course comprise the majority of all business applications.

The official FAQ says that "Microsoft plans to deliver a customer-deployable release in the first half of 2007." That's about 11 weeks from now. Considering that the current (Feb 2007) CTP doesn't even have an input box, it's hard to imagine that we will see a fully tested release with combo boxes, grids, data binding, etc. by June 30. (Granted, some things may be possible through custom "wiring," but I need a full design environment.)

Based on the applications listed above, my impression is that WPF/E is starting off primarily as an answer to Flash. That's fine--Flash has certainly had great success in making web sites more "jazzy." Adobe Flex, which runs in a Flash player, wasn't added until much later. Perhaps a future version of WPF/E will also support building text-oriented, data-driven web applications. For now, I'm coming to the conclusion that I need to look elsewhere.

Have I summarized the general intention and direction correctly Can anyone confirm or correct my conclusions

Thanks,

Mark