Silverlight (and Flex), not for LOB applications?

Shawn suggests that line of business applications should not be written using Silverlight (and hence Flex), instead XBAPs (the run in browser Windows-only WPF solution).

IT shops, with trimmed budgets and staff, have little time to maintain workstations and troubleshoot interactions between various installed applications. Web applications, although they may be more challenging to write (regardless of adding complex RIA components), offer long term benefits for maintenance, updates, deployment and access control that are extremely difficult to emulate using any modern non-browser based alternative, from terminal servers to WPF XBAPs.

And no, I am not a firm believer that a user’s needs should be weighed less than the needs of the IT shop. By no means. But, I do believe that the experience and requirements of many LOB applications can be readily constructed within a web application. Moreover, many LOB applications should be web applications for portability and access reasons.

Not all LOB applications will benefit from the added functionality that would be provided by a Silverlight or Flash/Flex component. In fact, many users may needlessly suffer from a nearly pointless developer adventure into new technology explorations rather than being able to perform the same business task more efficiently with what might amount to a fully functional, yet boring LOB application.

Many applications would benefit however from added pizzazz. There’s plenty of power brewing within the likes of Silverlight and Flex. It needs to be measured and watched carefully, so that it doesn’t explode into the user’s face though.

I do take issue with suggesting that an XBAP is typically a better solution. WPF, even in its most reduced form, is heavy weight and complex. Being browser embedded, it also won’t behave like either a browser application or a fully installed application. So, neither experience is fully replicated for the end user. Eventually, it may be that every desktop has the latest and greatest version of the .NET runtime to allow for the latest XBAPs to work — but there in lies more of the problem — the desktop is making a key decision into whether an application may run, rather than the deploying machine. That stinks — and fewer companies and users want that.

Yes, a WPF application using XBAPs may, at some levels, be easier to write. It depends a lot on the developer and on the application needed. Many WPF applications are as hard to write as a web application (if not harder). It’s give and take. Some features are easier in one and vice versa. RIA code using Silverlight is easier to create than their WPF counterparts in some ways, only because the functionality is limited (and a few things simplified). But, throw in the web mix for interaction, and I agree that the complexities increase.

So much depends on the expectations and needs of the user. If you want a web experience with pages, etc., I wouldn’t consider an XBAP to be an ideal choice. If it’s mostly a single page where much of the interaction occurs, I could see XBAPs being a reasonable choice for Windows-only organizations. But, those must consider deployment, hardware requirements, .NET versioning, and more.

(Don’t get me wrong, I really like WPF — just installed as a traditional application. :) ).

Oh — and more importantly — don’t switch to either technology if there’s no business reason (sorry developers).