[polshaw]

Ehh.. i'm making one (depending on your definition of 'serious'.. it's no office or photoshop of course).

It is responsive, so it is not the 'same' UI, but with a convergence of laptops and tablets coming from both sides (android and windows), the separations make decreasing sense (eg denying desktop users touch functionality, or android users high-res/mouse/keyboard). Yes, there have been lots of pains.. but using something like this so that you only have to target (known version of) webkit at least removes some of the issue. The jury is still out on whether it was a wise decision (I would have had to learn obj-c/java/at least one desktop UI framework, as well as develop and maintain at least 2/3 code-bases, so it likely would have been a similar nightmare), but i'm far enough down the line that the likelihood is it will stay that way (concern re: code theft is the only reason i don't say definitely).

There are quite a few apps that could be made that require not much more than a sophisticated todo-list UI though. A calendar app might be one off the top of my head that would benefit from a responsive UI.

[WayneDB]

The separation makes sense to me because of screen real-estate. On a tiny screen, there's only so much functionality that I want to offer in one single view. To your other point, Eto and Xwt ride on top of .NET/Mono which is stable and current, so you only need to learn one language and then you can address native widgets, even a WebBrowser component. Think of the possibilities...the whole embedding a browser in a native window has been done many times, but how many of those kits let you render native elements too?

Neither of these kits have a complete mobile story yet (I don't even think Xwt team is working on one). So, I'm not saying that any of this is useful for anyone with a same-view-code-for-mobile requirement, but I think it could be really soon. The Eto guys are working on the iOS backing and they already have some impressive demos running on each of the major target desktop platforms from a single code-base. Anyway, I just like them sorry for hijacking :)

[polshaw]

No hijacking, it's good to hear others' opinions. Tend to learn a lot from (software) discussions here. The thread is dead effectively for a while anyway now.

The way i see it, a minimum expectation (for 'universal' coverage scenarios) is: windows, iOS, android. Perhaps OSX too. There are cross platform solutions for the desktop, but that would still require 2 extra versions to cover the minimum standard. Soon you might be able to do iOS with Eto, but until it gets android support that would mean you still need to implement the mobile UI twice and port the backend code at least once (a feat that i thought was harder when i started than i do now; but maintenance would still be hell).

So you might lead to the idea of doing a cross-desktop app and a webapp with phonegap etc for mobile. This allows you to support more platforms (WP7/8, FFOS, BBx, ubuntuPhone?). Tablets are going to want a more in-depth UI than a phone, so then you have 2 layouts.

By the time you have a flexible layout system, adding a third may even sound preferable to porting everything to .NET, even if you are familiar with it! Yes you want extra features such as keyboard/mouse support, and more in-depth editing etc, but you do get the nice bonus that your android app will have those too (benefiting stuff like the transformer prime), as well as keeping all touch function on the desktop where touchscreens are taking off-- that probably wouldn't seem worth adding if it were a separate desktop app (same for smaller window-sizes). It's very reassuring to know that almost any feature implemented should work across all platforms. You could even extend a basic version for PS3, wii, TVs, chromeOS etc without too much trouble.

There are definitely shortfalls; lack of code privacy, still some browser issues on the mobile side (scrolling?), the DOM sucks, localStorage is tiny, etc! Phone processing improvements are fast whittling away at performance as an issue for many types of basic app though. IMO neither method (HTML vs 'native') are there yet, and different apps will suit each approach. To me cross-mobile/desktop apps are the future, although i concede that it isn't practical (or possible) for a lot of use cases today.