I agree totally that native CSS3/HTML5 doesn't cut it. However, there are decent libraries, and those libraries (e.g., GTW, ExtJS4, at least, perhaps others) are getting better at approaching native display speeds. The first versions of these libraries did exhibit the slowness and clunkiness you mention. It's clear enough now that the condition isn't permanent. I wouldn't describe what GWT did to speed things up a hack, any more than I would call what VFP did (painting vs. real windows objects) a hack. Finding a way for the Javascript engine to use it's strengths rather than its weaknesses (essentially what GWT V2.x did) is good programming, I would think. And I am sure there are hacks to be found. Anyway, the proof is in the pudding: there are a lot of apps in the app stores that are wrapped in PhoneGap, e.g., which is just a webview native control running HTML etc.

Whether one needs to be on the iPad, or Android tablets, or non-MS smartphones, is a business decision, of course. The enterprise feedback I've gotten is that when user number gets above a certain level, they want flexibility and low TCO. And, of course, they're big enough to have an experienced IT team that can handle *nix.

I stopped considering the Linux desktop 4 or 5 years ago, except for very specialized situations (there's a county in Florida that went entirely Linux for all areas of government, with exceptions of course, and it's worked out great for them -- but how many County IT teams could do it?).

Put down your money and take your chances: that's what everyone is doing now, only there are an awful lot of horses in the race. I hope we all win.

Hank

>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.
>
>It's possible that an all HTML/JavaScript world will arrive sometime but currently it's not even a contender IMHO. Html5 is pretty weak when it comes to providing real value. There's nothing there that changes anything drastically. All that stuff's been doable for years with add-ons, and now that HTML5 is on the horizon even the standards stuff is completely fragmented due to the wishy washy standards wording. Every vendor supports a different set of features. What makes good Web apps isn't HTML 5 but the use of the right thrird party libraries (or app specific wizards) that implement the UI properly (with all sorts of hacks).
>
>I don't see that changing anytime soon.
>
>And as I mentioned on the desktop Linux - besides all the noise the handful of users are making - is really a non-contender at the moment. Apple is more of a contender there, but given their insane Objective C focus and Apple toolset I don't see that as a contender either - and talk about lock-in there!
>
>So where are we? Same as it's always been: Lots of choices for different platforms and no real panacea for one language to rule them all. But I'll take my chances with .NET because it runs on the widest range of stuff that I work with which is all Windows platforms from phone, to desktop, to server to the Web. I'm not even counting Mono because that's a fringe and one that I wouldn't invest in. If you're going to build to other platforms you gotta bite the bullet and learn to do it natively.
>
>Still for .NET that's a pretty damn good range. Granted that leaves you out of the server room when *nix is asked for, but that's a choice I've made long ago...
>
>+++ Rick ---
>
>>.Net covers more bases if I include Mono and MonoTouch and MonoDroid. But even there, Moonlight is not a focus for Xamarin (according to Miguel's blog), for commercial reasons. So that leaves us on the CSS3/HTML5 playing field, on which there are many contenders.
>>
>>As JR notes, a browser-based app on a desktop can (with the right controls, which are available from a number of UI frameworks) provide all the functionality needed by typical business applications and, I would add, users won't experience a difference in the quality of experience of the application. For that (CSS3/HTML5 UI framework), does .Net offer anything special?
>>
>>At this point the desktop would run in Javascript, as would the mobile devices. Whether this is display only (FoxInCloud, Lianja) or has the capacity for client-side processing (e.g., Sencha/ExtJS, Pyjamas) and data syncing that would allow disconnected operation, depends on one's needs: the options are there. (I have to say I was very disappointed to hear Soma say at the Build conference interview on Channel 9 that there would be no disconnected operation -- he fumbled around during the answer, which suggests to me that he knew his answer was inadequate to the reality of many application's realities.)
>>
>>On the server side, that's another matter. Denali or whatever it will be called has solved a lot of problems, as does Microsoft Server 8 or whatever that will be called. I love that stuff. And yet, when an Enterprise tells me they want Oracle on Unix and want to use Apache on Linux, I have to be able to play in that space, with the same program.
>>
>>Everyone has different requirements. Those happen to be mine.
>>
>>So to answer your first question, re: a Python desktop app. So, although it may end up being Pyjamas, written in Python and able to run on the desktop in Python, it will run on the desktop in a browser in Javascript (if Pyjamas with the Python converted to Javascript). Until Pypy gets a sandbox (in development), I don't see a way to do desktop applications in Python (running in the browser) that would meet the security considerations need to run there (without an install).
>>
>>Hank
>>
>>>Interesting. You're going to build a Python desktop app? :-)
>>>
>>>For Web alone there are many choices. But once you're talking about Web, desktop, services and system code, .NET makes more sense than anything else IMHO because it covers way more bases with a common skillset.
>>>
>>>+++ Rick ---
>>>
>>>>I read this week that C# developers are in high demand on Dice.com, so if that's your direction, there's support for your conclusion.
>>>>
>>>>Job markets, by their nature, reflect that past: a company that adopted .Net 3 or 4 years ago will be seeking .Net developers today.
>>>>
>>>>Ask a different question, e.g., what application platform is growing today, and shows no signs of diminishing tomorrow, and you might get a different answer.
>>>>
>>>>One interpretation of MS's shift in emphasis to Web 2.5 as a UI platform is that .Net adoption has peaked. I haven't seen numbers to support that, even from the blogs who favor that interpretation, so who knows (Microsoft isn't saying, to my knowledge). But the biggest reasons (at least for me) for developing in .Net (tight integration with a managed code OS and write once, run everywhere) never happened and aren't going to happen. The infrastructure is good; but the parts of the infrastructure I would actually use in a business app are available everywhere, and often (e.g., in Python) in much easier-to-use form, and with greater variety.
>>>>
>>>>>>>Oh just go with C#. Why fight it?
>>>>>>
>>>>>>Yep, just drop pants and bend over. It's only Microsoft, and they never screwed developers up.
>>>>>
>>>>>Well, MS screws developers over with some technologies, I agree- Silverlight, WebForms, windows phone, vb, vfp. But it's probably good to grab the best parts from the mess - C#, SQL Server, MVC, etc are the good parts imho. After all they did spend a billion dollars on R&D - some of it is bound to be pretty good if for no other reason than the high level of minds working on some projects.