So if HTML & JS are (at least partly) displacing the CLR as the strategic client runtime ...

... and yet, all of MSFT's great dev tools, frameworks, etc. are still primarily C#/VB/F#-based ...

... shouldn't there be a way to use one with the other? Where the heck is Volta, anyway?

HTML and Java are NOT replacing the CLR as the strategic client runtime. Even if that's what Microsoft meant to say, and I'm more than willing to bet very big money that people are misinterpreting what was said, it's still not going to happen.

Note word choice: "displacing". Something can be displaced by a little ways without being completely replaced. 

8 hours ago, contextfree wrote

... and yet, all of MSFT's great dev tools, frameworks, etc. are still primarily C#/VB/F#-based ...

... shouldn't there be a way to use one with the other? Where the heck is Volta, anyway?

I want to see "ASP.NET for the Desktop", I think that would be the best way forward; where we can leverage existing skills to develop first-class desktop applications; a kind of "HTA on Steroids", especially as many of the traditional use-cases of Silverlight-for-desktop can be done with ASP.NET and HTML5's improved input widgets support helps too. As a bonus, this system could allow us to develop our own widgets.

It would be nice if Microsoft could just drop Win32 and adopt a Web-based UI API for some new version of Windows, but being able to run legacy Windows applications is something Microsoft cannot sacrifice to make that happen.

IBM had a similar dilemma with mainframe applications, and even though mainframe applications are not sexy or innovative, they're still making money for IBM and others involved in the care and maintenance of such software.

20 years from now, Google may have the same dilemma with Web applications when the "next big thing" displaces them.

@W3bbo: but the whole problem is having to deal with the impedance mismatch between CLR and HTML/JS (and SQL too), which ASP.NET doesn't solve

wkempf said: "HTML and Java are NOT replacing the ...",

Java is not an acceptable short form of JavaScript, you surly know that, don't you?

@fanbaby: acceptable to whom?

I agree that it's misleading, but actually I think I'm going to start using it myself just because it annoys you. Love those popular Java libraries like JavaQuery!

Anyone's who's ever used Java and JavaScript and knows they're nothing alike?

ok, my last post was a pretty lame attempt at trolling I'll admit.

@fanbaby:Yes, it's called a typo.

@W3bbo: You're crazy. HTML/CSS/JavaScript are awful tech for applications. I find it disheartening that people actually think we're moving to web applications for everything, but that makes a whole lot more sense than writing "desktop" applications using these. I know, I've written a large and complex application using XUL (Mozilla's application framework based around these three). It's terrible. Very, very bad. You are NOT going to see folks that write desktop applications move to that sort of thing, ever.

@wkempf:

Agree. I have done HTML/CSS/Javascript, and it is extremely terrible. Hack, just try do a browser close event handler to log people out right away, sorry, there is no such event. Document leave (change page) is not browser close, in case reader has no idea what I really mean. I can fake browser close by capturing mouse location in IE, but, all other browsers are out of luck.

Not to mention JavaScript has no REAL class. Fake class hacks != real class, and yes, you will run into limitation because of that.

21 minutes ago, magicalclick wrote

@wkempf:

Agree. I have done HTML/CSS/Javascript, and it is extremely terrible. Hack, just try do a browser close event handler to log people out right away, sorry, there is no such event. Document leave (change page) is not browser close, in case reader has no idea what I really mean. I can fake browser close by capturing mouse location in IE, but, all other browsers are out of luck.

Not to mention JavaScript has no REAL class. Fake class hacks != real class, and yes, you will run into limitation because of that.

You are trying to solve the problem with the wrong tool. Just store a temporary cookie that expires when the browser is closed. That's how pretty much everyone else on earth does it.

@W3bbo: You're crazy. HTML/CSS/JavaScript are awful tech for applications. I find it disheartening that people actually think we're moving to web applications for everything, but that makes a whole lot more sense than writing "desktop" applications using these. I know, I've written a large and complex application using XUL (Mozilla's application framework based around these three). It's terrible. Very, very bad. You are NOT going to see folks that write desktop applications move to that sort of thing, ever.

I'm more referring to the principle of simple data-management applications written in a web-like framework and paradigm running on a desktop; technical difficulties like you describe are easy to circumvent.

To an extent WPF solves this with XAML, but to me XAML is "impure" in that it mixes appearance, structure, and layout all together in the same document.

I have grand ideas for a simplification of WinForms, to reduce repetitive tasks and make it more web-like in how many tasks are done; and in particular I like the CSS visual formatting model as a basis for desktop application GUI development.

To an extent WPF solves this with XAML, but to me XAML is "impure" in that it mixes appearance, structure, and layout all together in the same document.

You can mix them in the same document, but you don't have to. Just like in HTML.

@Bass:

If I don't have expiration date, it is session cookie. But what we want is both. Both expire on browser close and inactive viewing page for 20 minutes to log out. Is that possible?

1 hour ago, Bas wrote

You can mix them in the same document, but you don't have to. Just like in HTML.

Indeed. And I'd argue that it's considerably easier to seperate presentation from content in XAML than in HTML/CSS.

I can somewhat sympathize with W3bbo. As much as I love WPF, I will admit there's some elegance to the way HTML/CSS work. Having worked with XUL, I can't agree at all with AndyC that it's easier to seperate presentation from content in XAML. No, it's really JavaScript that causes application development to fail miserably here. Don't get me wrong, I like JavaScript. It's just not suited to writing large and complex applications.

In any event, WPF/SL are not going to be replaced by HTML/CSS/JavaScript, even with HTML5 and CSS3. Certain applications may move that route, but they are a niche, and there's a class of applications that will never move that route.