>I've always agreed with you that HTML cannot stand up to the richness of a desktop app. At the same time, I looked at demos for Telerik AJAX controls this week, and I was impressed with how far they've come: http://www.telerik.com/products/aspnet-ajax.aspx. I don't know how well these work in practice though.

Looks are not the issue so much. Performance, stability and usability. THe main issue is you're still stuck with browser based text boxes or buggy HTML editing for input which is one of the big stumbling blocks IMHO.

+++ Rick ---

>
>Ultimately, I think we are headed toward a time when HTML/JS will be the promoted standard UI for everything, warts and all. Once Microsoft realizes Metro isn't for everything, I wouldn't be surprised if they bring HTML to the "desktop" as the preferred UI. WPF and Silverlight obviously haven't picked up enough steam, or MS would still be pushing them. Of course, MS won't simply add HTML support to WPF and SL. That would be too easy. They will create something totally new, which will no doubt be nice, but completely incompatible and with no migration from existing UI, once again leaving developers in the cold.
>
>>Yeah the whole local data thing is pretty pathetic at this point. But there are so many problems with that model altogether. Yeah sure I can save SqLite data to the browser - but then I come to the same site with a different browser or when I'm on the road and that local data is no longer there. So to make that work you still need to really support server sync.
>>
>>But ultimately my problem is that I can't imagine building some apps in a browser UI. For example, Help Builder needs a really rich UI to work well. I can't imagine building that kind of an application in a browser, as it needs access to system services, the file system (arbitrarily) external databases, and other files. It just doesn't fit to build an app like this in a browser with a sandboxed model.
>>
>>For business apps this isn't quite so much of an issue, but I think the same issues do crop up in many applications. If you wouldn't build it as an online app you also wouldn't want to build it as an offline browser app. To me even the most sophisticated Web UIs feel flakey and odd. Look at things like Google Maps or Google docs and all the odd behaviors and things that don't actually work the way you'd expect them to. It sort of works, but it's pretty flakey nevertheless. And that's coming from some of the best developers in the JS/HTML business. How can you/me as average developer achieve even that?
>>
>>Then there's the whole issue of JavaScript being mostly asynchronous which is gets tricky for many tasks. you can only nest closures so far before it becomes a hornet's nest to maintain. UI Layout in HTML is very time consuming to most of us especially if you want to build a really professional looking API. Some libs (like ExtJs) help there but then we're still back to the issue we discussed earlier where many of the controls look nice but functionally are no match for desktop controls. In Help Builder for example I think of all the text manipulation I do in textboxes, with drag and drop of all sorts of different content. None of that works on the Web (only basic types supported).
>>
>>There are lots of issues that have been solved in desktop environments since the early nineties that don't even work on the Web at all (yet)...
>>
>>It depends on what you're trying to buid. If you're building line of business apps that only need simple data input then a Web/Browser front end might be totally sufficient. But richer applications that integrate with OS and need to manipulate files extensively - that's a still a long ways off IMHO.
>>
>>+++ Rick ---
>>
>>>>But how do you actually 'publish' a local HTML application? Typically you still need some sort of wrapper to actually display the HTML and get it started.
>>>
>>>My hopes were on the way Chrome allows you to work with installable web apps.
>>>Have only read about the technology, so I might overlook some problems:
>>>There are 2 kinds of apps, hosted and packaged, each with a small manifest file and an icon file.
>>>With the packaged app the HTML start form is included in the downloadable zip file.
>>>
>>>>How do you deal with local data (offline storage isn't really an option for serious work).
>>>
>>>(I saw your response to JohnR - this could have been written there...)
>>>I had VERY high hopes for the HTML5 WebSQL after reading that gears would be discontinued
>>>to concetrate on the HTML5 standard. Then one Firefox engineer somehow changed directions for the
>>>API to support (because SQLite is not realy a standard) in FF
>>>and MS was only too happy not to support it in IE (personal cynic opinion).
>>>
>>>They want the browser app to be coded in ORM form and run against IndexedDB, which was hacked together
>>>building on BerkleyDB (not sure if that is true for all implementations) by an Oracle dev.
>>>IMHO it was not in the best interest of Oracle and MS to have a backend-agnostic client capable
>>>of locally caching backend data - Honi suit...
>>>
>>>Especially frustrating is the fact that FF already *uses* SQLite, but they feel it must "protect"
>>>the web developers from an SQL API first on the grounds of "not enough standardization",
>>>but also because of the better coding paradigm and "nicer aesthetics" - for me the ORM examples
>>>look worse than the WebSQL examples - even trying to adjust for the existing personal bias ;-)
>>>
>>>The above is written realizing that such local data is in greater security risk.
>>>
>>>>JavaScript and HTML 5 in the browser are seriously hobbled by the browser's security sandbox.
>>>
>>>And still open security holes...
>>>
>>>>I'm not a huge fan of WPF/Silverlight with their extremely complex UI models.
>>>
>>>Agreed that they are somewhat overengineered - but I was willing to take that in exchange
>>>for MS having done a lot of the grunt work to test and debug on the other platforms.
>>>
>>>>You can run a local Web server to make that work but then you're talking about messy config and maintenance that goes beyond the average user's tolerance IMHO - that's not a good solution either - not yet. I think that will come though and if you really try hard that can be done (in fact I've delivered an app like this with a hacked version of the Visual Studio Web Server Cassini built right into a small wrapper .NET app that that then uses a WB control to display the UI). It worked, functionally but it feels cheap to do it that way IMHO. I would not build a commercial tool that way.
>>>
>>>Agreed on all points - and when you consider that most "other" Web tools offer some internal web server for such approaches, it is conceivable more such things will land on the phones: a security nightmare as well as cruel and unusual punishment for those ARM-CPU's if a couple of web servers run for different apps...
>>>
>>>regards
>>>
>>>thomas