Microsoft refuses to comment as .NET developers fret about Windows 8
itwriting.com
itwriting.com
I see this tile-thingy more as an additional overview-shell, but the real work will remain to be done in the classic apps. This is more comparable to the Mac Dashboard widgets than to a complete UI redesign.
As such, I see no problem in doing these widgets in HTML/JS which is what we have used ever since. The "real" applications will still be done in whatever technology is available under windows.
Of course, everything is just speculation. I just know that I'm sure as hell never going to use a touch interface on my desktop PC nor drag around tiles with the mouse trying to fake enough inertia to get the scrolling to go.
In the end it's not going to be very useful for end users unless Microsoft really bites the bullet and forces developers to migrate to the tiled interface, en mass. Apple did that with iOS, basically forcing developers to create entirely new apps, because the input method of touch was so drastically different that apps requiring mouse-level precision would never work. Microsoft will never do that, so instead they need to fragment their OS into two interfaces, touch and classic.
I fear a Windows 8 tablet will be the worst of both worlds. It will need enough horsepower to run "classic mode" with all of the baggage that brings, yet most tablet users are just doing simple media consumption so they can stay in tiled mode most of the time. In the end you bring a product to market that costs $1500, has a quad core CPU and 4GB of RAM, and gets 4 hours of battery life - not to mention it weighs 3 pounds. Basically you end up with the current crop of Windows tablets. A stylus will probably be included just to make classic mode usable.
I'm not saying there isn't a market for a powerful tablet that can run Windows 8 in classic mode, but those tablets have been around for years and they haven't gotten mass market traction for a reason.
Microsoft managed to squeeze Windows 7 (albeit crippled) onto netbooks; I'm hoping they'd see the use case you're describing and make Windows 8 tablet-friendly (which at least now looks touch-friendly).
(Microsoft demoed Windows 7 on ARM, and AFAIK ARM chips aren't that powerful―there's hope yet.)
But I love being able to run Photoshop and draw in my lap, so I'm kinda biased.
For some users like my dad, the tiled interface with a touch screen should make it easier to use the computer. He doesn't use them enough to learn the whole stacks of windows metaphor and all the operations involved with it, but he can pick up an iPad and use it just fine.
The real significance I see here is that Windows mobile developers with just the skills of a web developer can now target desktop and tablet users fairly easily with the same exact code and a similar UI. If Microsoft releases their own App store for Windows 8, then that provides a unified platform for developers to sell the same product to every kind of Windows user from kids with smartphones to grandparents with a desktop PC.
And if the tiled interface takes off with the not so computer-literate, there'll be a great new demand for applications that fit into it's metaphors to prevent the jarring experience of being thrust back into a classic Windows-like environment, kind of like the demand for GUI applications after Windows supplanted MS-DOS.
Simultaneously, users are coming to the realization that full featured isn't what they need. Thanks to the drastically lower cost of distributing software over the web, instead of monolithic, multi-purpose software from giant companies, small shops are building single-purpose applications that target niche markets. User experience is better, and costs are lower. Consumers and the economy as a whole wins.
If I had built my career on client-based Windows development, I'd be getting out of that burning building as fast as possible.
I'm not so sure: amazon.com seems to fit that description fairly well.
.NET developers shouldn't fear the future. They should be happy that, for once, their ecosystem may see a growth that actually works for them.
I've done the MS HTML/JS client route for a long time - I've set up a lot of gadgets, and InfoPath(!) has an HTML/XML/JS programming model. Truth be told this model is actually really painful to work with if all you have is HTML/JS. Keep in mind that the "web" isn't just HTML. It's Perl, Rails, Json, JS, Google, Wikipedia, RSS, etc.
Now, if these tiles are something akin to mini-web browsers, where you can use the full power of the web & web technologies (is this what they are actually saying?), that is a different story.
For example, take a look at the WPF built-in controls. Those are written in very clean XAML. Easy to read, style, and modify. I'm sure they could have made it difficult, but their intent was that you'd modify the built-in controls.
If they want to do this with the UI, they could do it. The theming you could do with this could be incredible.
I doubt this is something they're going to do for V1 (if ever), but I can dream.
1. I am not comparing .NET to the web. That comparison is impossible. The web is an abstract entity that .NET is part of and .NET is a software framework.
2. I am comparing .NET to HTML5 and JavaScript.
3. The capabilities of.NET are far greater by an absurd margin than the capabilities of HTML5 and JavaScript for Windows application development.
I've read a lot of commentary that is very impressed with the tiles and just as much commentary writing it off as something that's not enough and not appropriate for Microsoft to make a step and just put a new pretty face on Windows.
To me, I see it as a thought out stepping stone to reaching the post-desktop era that reaches a pretty good compromise. I don't think many people have to be worried about this new transition, but that's my own speculation - you'd have to wait for MS's official word.
Microsoft hasn't been portraying the new shell that way. It seems to be where the first-class Windows 8 applications will reside, with the icky old legacy applications relegated to the classic desktop.
Looking into the future, a dual use tablet like the Asus tablet with a keyboard portends a new reality that execs don't like lugging laptops to meetings. Have you tried to balance an open laptop, a mouse, power supply on top of folders? There's no hand left for that cup of coffee.
The problem is that Windows has a slew of legacy API's, languages, and frameworks that you can't get rid of without undermining the existing application ecosystem that made it popular. And it seems like they're not willing to get rid of any of that for the new world of web/mobile apps, like Apple did with flying colors. Instead they're shoehorning yet another framework onto an already bloated platform.
So in the end they're trying to apply a lesson from Apple (touch, interactivity) with total disregard for why it worked (simplicity, seamlessness, usability). A recipe for failure if I ever saw one. Ballmer still doesn't get why iPhone won the mobile wars.
In my world Apple is the leader because they have the best business. If you only look at market share then nokia should have been the winner for a long time.
They did it pretty handily with WP7 development.
And Win8-on-ARM obviates the legacy issue anyway. There's going to be a clean-slate development approach put forth as the recommended way to develop for 8. There's no way around that.
It'll almost certainly look a lot like current Windows development (likely just a new iteration of Silverlight and .Net). And just as certainly, legacy apps will stick around in a sort of "XP Mode" for x86 Win8, but they're going to be phased out.
If MS isn't talking yet, it's probably just because they have a new slew of buzzwords and marketing to finish drafting before they introduce it.
I'm hoping there's more to this than meets the eye, but... Here's a test case for you. VB6 apps are supposed to be going out of support relatively soon, but there's a lot of them still out in the wild. The understanding had been to redevelop them in .Net, but based on this exactly what should the authors commit their investment to? Frankly if this doesn't get cleared up soon, for me the answer would be 'anything but Microsoft's stack' - it's just too unpredictable.
I would draw a thick, dark line between managed .Net and "legacy". When people talk about legacy Windows code, they're talking about those massive enterprise apps running front ends written in VB6/MFC-era code. Those are the ones that Microsoft has to push to the curb in Win8 [1].
That said, any number of .Net tricks to enable legacy behaviors will likely pose roadblocks for particular apps. So some .Net incompatibility will be at issue as well.
> "but based on this exactly what should the authors commit their investment to"
I'd imagine the question Microsoft is grappling with, is which versions and parts of .Net they can reasonably support. Though I'd be surprised if anything they recommended in the last five or so years that wasn't supported.
That said, anyone designing an enterprise replacement in the last five years, who did so as anything other than a web app is likely out of their gourd [2].
[1] i.e. live on in an XP-mode style ghetto only on Win8x86
[2] Sure, some of have some steep client requirements that rule out web apps. But that's a tiny minority amongst enterprise apps. The overwhelming majority are workflow/database interfaces.
Don't get carried away. MS has been very clear that you can run any Windows app here. If you're porting over old VB6 apps it seems clear that porting to VB.NET makes the most sense. .NET development isn't going away as at the very least MS's web server-side story is still all .NET.
*We put up with Windows so we can use C#,
F# and VS2010*
This is what happens when developers believe blindly in promises, instead of focusing on getting the job done with minimal friction.
Of course Microsoft was going to let go of the .NET "vision" at some point, as .NET is not applicable to everything. If you believed that by learning .NET you are going to have a unified platform to be able to use it for everything, that's your problem.
It's like believing .NET's CLR is a general-purpose VM. Well, it ain't. Yes it provides some flexibility, but you'll never have Haskell on it. Or a reasonable LUA implementation for that matter.
And in my view, basing this new UI on IE9 and Javascript/HTML is a move in the right direction for Microsoft, one of the few I've seen in years - I mean, why reinvent the wheel instead of leveraging the knowledge of lots of outside developers? Last time I checked, even Adobe AIR had better penetration than Silverlight (total, not counting the number of out-of-browser Silverlight apps or people that use such apps).
Actually, this is what happens when you rely on software someone else controls. I once worked in a company that (after I left) made a huge investment in WebClasses, as they "were the future" of web development on Microsoft platforms. "The Future", as often happens, didn't last long.
Microsoft hasn't clearly ditched neither .NET (and .NET permeates most of Microsoft's server business) nor Silverlight and the "classic" view will still be there for when it makes sense (and it really does in a lot of scenarios). I suspect, however, "modern" apps will prefer to use the cleaner tile interface. If things like Gmail and Google Docs taught us something, is that simple interfaces are a good idea. With the onslaught of fresh desktop GUI ideas like Apple's full-screen apps, Gnome's new shell, and Canonical's Unity, Microsoft had to show something.
And that's what damns them. When a competitor, any competitor, shows something, they make themselves show something like it. Frankly, this whole tile thing has "PDC 2003" written all over it.
this is what happens when you rely on software
someone else controls
For the web, you depend on the industry to evolve towards your specific needs. Client-side, you depend on whichever company controls the operating-system of the devices you're trying to target.
I wanted to mention open-source platforms when writing that comment, but in this specific context it isn't really useful, since that's not what .NET developers seek. They want Windows, Visual Studio, commercial support and a unified platform for the web, client and mobile (the promise of .NET), which is insane as there can be no such thing.
Not really. When Zope Corporation ceased to develop Zope 2 in favor of Zope 3, the Plone community and others continued development of the 2 series. It currently has a lot of features migrated from the 3 series, a lot of new features of its own, but remains compatible with the Plone CMS that runs on its top.
If, for whatever implausible reason, Oracle decides to ditch MySQL, its users already have a bunch of forks in place, perfectly functional. If, however, Oracle decides to discontinue their RDBMS, its users are royally screwed.
> and a unified platform for the web, client and mobile (the promise of .NET), which is insane as there can be no such thing.
Despite my dislike for Java (the language), I have to recognize it spans a very vast space, from dumbphones (J2ME) to fairly clever ones (CLDC, CDC) to very smart ones (Android) to desktops (Eclipse, NetBeans, several standalone development tools I use) to large distributed server solutions (Cassandra, Mule, Hadoop). And the JVM is sweet. I'd love to find a decent excuse to do something in Clojure on it.
Exactly. I write a lot of .net code for work and haven't written a UI in anything other than HTML/JS in a long time. Too many people seem to be reading HTML/JS and thinking entire apps will now have to be written in them, and I just don't that's true.
My perception is that they are worried that their existing knowledge (in .NET or any other MS dev tech) will not allow them to create applications for this new touch interface. Instead, they will be forced to use a new technology if they want to create an app for the new Windows 8 interface.
"Underlying the discussion is that developers have clients, and clients want applications that run on a platform with a future. Currently, Microsoft is promoting HTML and JavaScript as the future for Windows applications, putting every client-side .NET developer at a disadvantage in those pitches."
Remember most MS developers work in corporate environments. Either in companies or as consultants. No one wants to spend money to build a "legacy" app. So when Microsoft says HTML5 apps are the future but doesn't lay out how their APIs are going to work it freezes many .NET developers in their tracks. Because now Silverlight and WPF are legacy but you don't know how to pitch these new Windows 8 apps to a client because Microsoft hasn't specified how they'll work.
First, to be a dev using the MSFT stack, as I'm sure you know, you learn a new technology every week -- so they're not against learning new things :-)
But more importantly, most of them complaining have used HTML/JS, and many use it regularly for the web side of the house. It's not an obscure language/Fx that people haven't touched before. They maybe haven't written Angry Bird with it (which BTW, their JS looks like it was machine generated -- anyone know how it was done?), but most know the technology decent enough to comment about it.
Using HTML/JS in Internet Explorer is very different from developing on a platform where HTML/JS application development is fully supported. I have been playing for some time with WebOS development and I am quite happy with it.
Anyway, I seriously doubt .NET will be deprecated anytime soon.
This is probably true. But the tooling still leaves a bit to be desired.
I was really excited about WebOS when it first came out, but they just took too long to get the SDK out. I eventually just moved on and haven't gone back. Although I do think the new stuff they're doing looks quite nice.
http://www.computerworld.com/s/article/9134650/Palm_expects_...
If you were approved you got access, but most didn't. I think jwz ranted about this too. There were all these devs who wanted to write for it, but weren't given access. Eventually I gave the phone back.
General rule, your SDK needs to be done a month before product launch -- unless you're Apple.
For this tile UI, I'm a little surprised - if only because it's quite different from how WinPhone7 works (isn't it?).
The html apps will be the widgetty type applications, while the real working computing applications will be written in solid .NET.
My only concern is this integration of one into the other that they show. It looks like slapping a pig on top of a cow and asking for babies.
I dare say most the concern I'm seeing about this so far is that they've simply not gone far enough... Unless the tiling interface is the primary mode of use, then most people simply won't use it and it'll be relegated to the list of features the OS has, that simply no one uses. Think "Windows SideShow".
Of course, this all depends on what MS are planning on doing - and I think they've made yet another PR misstep (even if it's only to developers) in that they've simply not released enough information. I can't decide if they're teasing deliberately in an attempt to drum up interest (working, but I would argue that it's more worry than interest to their target demographic) or whether they actually don't have much more than this demo and that they don't know what their long term plans are (even more worrying?)
I think their intent is that this new UI is the Windows UI. I think they're going to push devs to use this new UI for all apps unless they need to go to the old UI. Recall that native apps will not be cross platform, so there's motivation for devs to target this new UI to run on x86 and all the ARM variants.
Why? MS has recently given talks on pretty much that topic: Giorgio Sardo: HTML 5 for Silverlight devs http://channel9.msdn.com/events/MIX/MIX11/HTM14
This is Ui layer only, sure. But that's probably what you meant by "WPF/C#"
Since WPF has a sane architecture, you have access to a huge set of high quality UI components (grids, editors, etc) that can simply be dropped into your applications. 15 years on and web developers still don't have this. The components that they do have don't follow a common object model or anything like what WPF has, so they're much harder to work with. So that is one very important quality that you simply can't have in HTML.
WPF does have lookless controls and triggers, but I'm not sure I'd make a dev platform choice based on that.
Also, keyboard acceleration is severely lacking in every HTML advanced component set that I've ever seen. The whole scene is just dismal compared to what can be had with a decent desktop kit IMO. I am thinking it will be another 5 years before the web really catches up, but that doesn't help me much because I'm lazy _right now_ (EDIT: meaning, I don't want to have to work that hard for all those little niceties, but I still want them).
Take a look at the latest JS development tools, jQuery/ExtJS/backbone. It is the future of the UI development
You don't build applications with logic and complicated function out of HTML and JS. Not today, not tomorrow.
My (and your) 10k, 100k, 200k line C# applications are not writable in JS.
Sure, there is GMail and Node.JS as examples. But thats kind of a niche compared to everything else.
HTML and JS are just going to be another way do to UI, and nothing else. You'll still need to write the C# app and use .NET to do the backend.
HTML/JS will be another option right along with XAML/WPF and SilverLight.
I don't know that this will be true for very much longer, if it's not already been disproven. Javascript isn't the greatest language out there but it's gain functionality that is removing the limitations that uses to plague it compared to other languages. Slow VM is not longer true, no multithreading is not longer true. Webworkes are a little odd for sure, but they still make it possible to build multithreaded applications. WebGL/Canvas allow for some very advanced graphical applications. You can now access local storage, a database (and in node, other databases), new ArrayBuffers and such. It's a different environment now.
Please show me examples of these 50k+ line JS applications that have no backend, or run JS on the backend, that are not a mess.
...That you can develop, debug, and tie in with the rest of the system with the same ease (or even 10% of ease) as you can with native .NET apps.
It's not 50k and it's for sure not a project with 20 devs but even this size was unthinkable earlier.
I'm working on a backend in node to take advantage of Websockets.
It's Microsoft's Office Web. It's Google Docs. It's Zoho Apps. Yeah, there are hundreds of millions of users there already.
It's YouTube and Facebook and Twitter.
These are applications with logic and complicated functionality and they're built with HTML and JS and they have hundreds of millions of users, each one of them.
If you think that the Web is "niche" you're in for a rude awakening over the next few years.
None of your examples are built with HTML and JS on the backend.
Actually, they are, and quite well. But not by the developers that Microsoft targets. Those developers need a lot of hand-holding to get used to async programming, prototypal inheritance, closures for encapsulation, etc.
So actually, I'm agreeing with you -- there's no way that's where Microsoft is heading. They'd be more like to drop all their programming languages and tell everyone to switch to Lisp.
Even if they did ditch .NET (which I don't think they will), it would take years to do; plenty of time to move to something else ;)
I would like to see a new UI framework that everyone inside Microsoft feels is good enough to use. And give third parties equal access.
Each time I report problems, they close them saying 'cannot reproduce'. So if that's the case, why do people upvote my issues?
I get the same with Microsoft Connect as well. It's a disaster zone.
I hate working with the stack.
That has been true in most every version of VS I have used...almost like Resharper itself sucks from a software engineering point...hmmmm
>Crashes every 30 mins or so. Using SP1.
Try taking off Resharper. I hate how Visual Studio is so unguarded against poorly written components / extensions, but it is. The single biggest point of slowness / crashes I have ever seen is in third party crap, they just figure you'll blame Visual Studio so they don't care.
You can probably find much ranting about R# on stackoverflow from myself.
VMware - forget it - unusable. All our infrastructure is VMware based and we have to do remote debugging on VM's via RDP. Yuck. I think when RDP is used it falls back to a GDI+ backend as HW accelerated primitives cannot be thrown down an RDP link and then uses tiles (as you state).
This is all down to the fact that RDP came before DWM. If it was the other way around we'd be throwing surfaces down the wire which would be nice.
The joke here is that on Vista to Vista RDP connections (.NET 3.0), WPF was properly remoted over the wire and rendered on the client machine instead of bitmaps being sent. This was removed in .NET 3.5. (http://www.virtualdub.org/blog/pivot/entry.php?id=216)
Anyway...from my point of view the biggest problem with the WPF design is that they didn't include the "draw it yourself GDI style" option.
Where I live I would guess that at least 90% of job postings for programmers are .NET.
I think a lot of people who develop desktop front ends for .NET (and want to develop on new projects) would have put effort into learning Silverlight and/or WPF and are afraid that the effort is going to be wasted, as they need to learn another technology.
So it is probably true that .NET jobs will not go away. But that 90% mark on job postings could very well shrink significantly.
Although now their API situation is more of a mess, with normal native APIs plus HTML5 for Windows now, then there's Silverlight for Windows Phone 7. Makes you wonder if they didn't have any foresight about this decision when choosing WP7's set of APIs.
Windows has had HTML and script based Apps in the form of HTA's for a long time (i.e. IE5). So in many ways the buzz seems more of a marketing coup than a revolutionary new approach (aimed at getting consumers to enable scripting on desktop installations). I suspect Silverlight to be deprecated as a web technology because it has many of the same issues as Flash (for which it was always intended as an alternative/replacement), but .NET is here to stay. It is .NET that facilitates the expanding ability of Windows to run on diverse architectures - since Windows Vista the Windows OS is essentially .NET for many purposes and Windows 8 and WP7 are extensions of that roadmap. A roadmap which, again, is business focused and tailored to provide stability.
http://msdn.microsoft.com/en-us/library/ms536496%28v=vs.85%2...
There's something to be said about breadth versus depth.
This is an unfortunate, and valid criticism. I've worked with senior C# and VB developers who hadn't encountered the concept of an (OO) interface, but they got along just fine with their day-to-day jobs, copy-pasting. However, I do feel sympathy for them - they were so insulated from the wider programming and CS communities, that they didn't even realize there were other things happening in the wider dev world. Their fault was one of ignorance, not arrogance (and of believing everything Microsoft told them at the developer events they attended).
So here we are left to speculate as to what happens next. I can't believe they would simply toss all the technology out - what's the alternative for true native apps, pure C++?
As far as the HTML5/Javascript thing goes - hell yeah, I switched to using html(4/5)/javascript and css(2/3) for my front-end code over a year ago. I think this is actually a pretty shrewd move and likely will be more a focus for the tablet and phone developer side allowing easier porting across all the emerging platforms. The fact that I may be able to use that same tech for Windows desktop apps is nice bonus, but like we all saw on iOS - nothing beats native for the best client experience, at least for now.
That's a recipe for fear, uncertainty and doubt within the tribe itself.
Put another way: it's hard to reconcile "Developers! Developers! Developers! Developers! Developers!" with "We're changing things radically concerning the way you develop, but we won't tell you how-- hold tight until September, 'mmm-kay?"
EDIT: formatting
I'm not worried until they shut up and ship.
Microsoft does seem to be inching away from its traditional developer base to broaden its appeal.
Lightswitch seems to be another example. I doubt that it will be as empowering for non-developers as the marketing suggests, but it should reduce the effort/expertise required in creating well-architected CRUD apps, making in-house development easier and exerting downward pressure on project costs. This will hurt some consulting shops.
But Microsoft's duty isn't to look after its loyal developers, it is to maximize shareholder value.
I had a play with Lightswitch and I liked it. It is like MS Access. I'm surprised they positioned this at the developers rather than power users though. Perhaps there is a wall between the tools division and the Office division.
On the topic of loyalty, platform companies are like the Mafioso. Loyalty or the lack of it cuts both ways. MS tech is not the easiest to learn. The reason MS got away with it for years is because Sun was even worse.
They are positioning at power users, but it does seem like more of a developer tool. I think it will appeal to less-skilled or time constrained developers more than to power users. I've turned down side projects, where Lightswitch would have been extremely helpful because of time constraints.
I have worked in consulting places where income is generated, especially during lulls, with the sort of apps that Lightswitch is supposed to generate. I expect, if Lightswitch works as advertised, to see less of those projects.
MS tech is not the easiest to learn. The reason MS got away with it for years is because Sun was even worse.
My personal hope is that Microsoft feels threatened enough to produce some silver bullets for business application development, or at least to try.
Lets say you want to write a program that extracts all links from a web page. How would you go about this? First, you look up in the documentation how to load a web page over http. This requires several lines of code, and it's complicated enough that you don't know it by heart after the first time you've done it. From there on it gets easier: you get a library and read the documentation to parse HTML and use an xpath or css selector to load all the links and then read of the href attribute. All of this probably requires around 15 lines of code, with various method calls that you have to look up.
In Ruby, I do this:
doc = Nokogiri::HTML(open('http://google.com'))
urls = doc.css('a').map{|link| link[:href]}
The guy who architected WCF needs to understand that MS developers have to be competitive against other technologies or they would start losing out because of cost. The competition isn't Java. It is Rails, Django and PHP.
>“Microsoft has first class cross-platform application framework called Silverlight and they want us to right freaking javascript.”
Yeh, because js isn't a first class, cross platform language...
I can think of very few reasons for this idiocy besides relations between OS and devtools devision having quietly deteriorated from post WWII style peace to nuclear war.
-Windows -Windows Phone -Xbox 360 (for games)
And maybe Linux if I'm feeling really charitable and want to make my stuff Mono-compatible.
JavaScript is not a first-class language on at least two of those platforms. It's not a cross-platform application development language on three of them.
Also, this video says nothing about the architecture behind this "Launcher"(because that what it looks like), there are a lot of possibilities. May be IE10 has some kind of <protected-frame> element so you can specify certain permissions like network access, file system access and stuff, maybe it requires a manifest in which you can specify what "DOM manipulation technology" do you want to use, the most obvious options are:
- A Javascript (IE9 code-name "Chakra" engine) based file. - A JScript.NET file. - Any DLR based language file. - Any .NET assembly decorated with some fashion attributes like <Windows8Launcher.TileDomBehindAttribute(typeof(MyTileHandler))> or something which you can easily compile with any .NET compiler like C#, VB.NET, C++ CLI, etc.
May be developing in HTML is completely optional and each Tile can be developed using Silverlight or Windows Presentation Foundation technologies... we don't know.
We know that Microsoft is a legacy company, they will not abandon .NET anytime soon.
MS is not stupid enough to pull another Vista and make apps that used to work not work. Even if MS were very serious about transitioning everything to HTML+JS you'd be looking at a 10-15 year timeline. The day you see Office written in HTML+JS is the day to start worrying if you're a Win32 / .NET app developer.
The crappy DOM will probably change for the better, HTML5 apps will run as local apps and tap into the native APIs of the system.
Client = HTML5 + JS , yes we dont need .NET here, where .NET/C/C# and others will be used, will be in the backend, frontend/client can be perfectly made with HTML5 + JS.
The only exception is perhaps games and apps such as Photoshop, but 90% of enterprise stuff that is simply thin clients speaking to a big backend database+etc can be perfectly made with HTML5.
HTML5 is here to stay, .NET will be the exception. (Games/Heavy backend/3D apps/Photoshop) sort of things... nothing more.
Or who knows, maybe in the future with WebGL and what not even some more complicated games can be made just with HTML5.
People have been claiming HTML and Javascript were the future of application development for about 15 years now. They also claimed it about Java and, ironically, .NET.
Also this whole "every app is going to be html + javascript" does remind me of the earlies Apple IPhone developer offerings.
If one of these were to stick - it would first need to be supported be a somewhat larger organization (ala apache foundation for java components, or google for GWT/Closure).
[1]: http://technet.microsoft.com/en-us/library/cc768176.aspx
I think the most vitriolic responses have been from people who have either been brainwashed by WebForms or never had to do anything on the web before.