>Hi Rick,
>
>>When's the last time you've used a browser app for the desktop with local data to date? Reality is that if you run a local app you're expecting something better than the browser. Online apps are one thing, but if you use an offline app the expectations tend to be different IMHO. If I go down the desktop path I want an app that integrates with the OS not some hacky Web view that's offline.
>
>I think there a two ways to think/ask for a browser app with local data:
>First is the point you mention above, where there is :
>more/better controls, better user support, better interaction, graphic tricks,
>in general more hand-coded functionality in C and added user exp in not code-free V
>which I agree is still MUCH easier to implement in .Net compared to fwk-enhanced JS.
>
>The second way is the possibility of a not too eye-candy heavy application,
>where still every field has oodles of DD-based help/user info/hints/client side "standard" validation,
>local lookup values and so on working on once-loaded client data.
>Speed IS a feature, caching a part of it.
>Also when only a phone connection is available, having an option to work offline and resync later
>when WLAN or cable-LAN is available again for some road warrior scenarios is heaven sent.
>
>my 0.02€
>
>Thomas

At which point you can offer a WPF/WCF app using the Sync Framework with SQL server. Fast. Pretty. SQL based (reliable, secure and scalable), recognizable current technology (read MARKETABLE), and supportable by any of hundreds of thousands of .NET developers.