Windows 8, HTML, .NET

You probably heard about Win8 today.

The short story is that they showed a touch-centric shell on top of Win7. Microsoft want us to start building touch-centric apps for that shell using HTML5.

I don’t have any doubts that existing apps will still run with no changes in the old shell.

The main question from a developer point of view is if the only way to write apps for the  new shell will be HTML5 or not. IE will keep supporting Silverlight/WPF/Flash, but those won’t be apps in the new shell but apps inside IE.

For me it’s hard to believe that they won’t support a Silverlight flavor for the shell, but I don’t know the answer.

In any case, it’s clear that with this strategy Microsoft is accepting that they’ve lost the war for the developers’ mind with .NET for client applications. They are still fighting it in the server, but not in the client. Silverlight was the last proprietary technology MS used to try to achieve that, and they failed when “multiplatform” changed from Windows-OSX to Windows-OSX-iOS-Android-AndMarketPlaceRulesThatTheyCannotControl.

They need developers writing apps for Windows. Most of client-side developers today are building HTML apps, another big number are writing iOS and Android apps. Learning XAML technologies is difficult and unappealing for them. As they are losing the battle with iOS/Android, going HTML could be their only option if they want to regain the developer’s love.

The tablets with Windows 8 will be very attractive for Windows users, and it’s the OS with more users on Earth. It wouldn’t be surprising if some developers start targeting that as the main platform, in particular if building those apps is easy. I don’t know if there will be a good story for sharing code between web and native apps, but I guess it will. This means it will be much cheaper for developers to support both platforms (tablet win apps and web).

If Microsoft is successful, it would end up killing native development for Android and iOS, because it could force Apple and Google to come up with similar solutions. They won’t own their developer platform as they used to, but at least nobody will own it.

Of course, if they succeed in making HTML5 the main technology for native client-side apps in all Operating Systems, it will also mean we’ll be able to use that technology for building native apps for Windows Phones…

Does all of this means client .NET is ‘dead’? Depending on your definition of ‘dead’.

9 Comments

  • This is not a totally new idea... Chrome OS is basically doing the same when it comes to UI. Difference with Windows 8 is that it is cloud centric.

    As a developer I'm not so happy about this, if it means we have to go JavaScript/HTML5 and lose a lot of the Visual Studio programming sweetness.

    But to use a chess metaphor, Microsoft lost all it's pawn/knights/etc and is now bringing in it's queen to war. Very risky.

  • "Depending on your definition of ‘dead’."

    Only if you define 'dead' as 'alive and well'.

    Just because they've added "web-powered apps" to Windows doesn't mean that client .NET development is dead, any more that the addition of .NET meant that C++ was dead.

  • This is just ridiculous. The existing not-small majority of Windows-centric developers do not want this.

    Web devs use HTML/CSS/JS ducktape because they're forced to and that's the only reason.

    If .Net (WPF/Silverlight) apps are not first class apps on this net platform, then either nobody is going to develop for the new interface or devs are just going to start jumping ship faster than they already are.

  • Look at it this way:

    Microsoft Office is one of MS's flagship products. It's written in C++, and that's not likely to change any time soon.

    The Windows team are unlikely to provide a new UI without giving the Office team any way to integrate with it.

    Therefore, there will almost certainly be unmanaged APIs to integrate with the new shell. Where there's unmanaged APIs, there will be managed wrappers.

    We might end up with an external wrapper assembly at first, like the Windows API code pack. This will probably be incorporated into a future version of the BCL, much like the Win7 Taskbar integration in WPF 4.

  • I'd particularly love the (easy) ability to use a native app with an HTML+CSS(+JS?) frontend. That's a much more attractive option than WPF today, which isn't portable, tends to be slow, and is much less well put together.

    Generally, the back end code is much easier to port than front end code; and if it's HTML, you can virtually transparently get cloud+based and client-side apps to share much of the implementation and look very similar: great!

  • Microsoft is making the same mistake that musicians make all the time trying have a hit. Instead of doing what they do best, they start writing sound-a-like music they hear on the radio and the rewards are short lived. They lose the real dedicated fans. They get a bunch of new fans that are will only stay as long as the music is the flavor of the moment. Then, those fans leave to another band as quickly as they came. In the end, the musician loses and regrets not taking care of the original fans. This is the path Microsoft is taking. I just spen $10,000 on a 2 year education focusing on .NET and feel like drinking a bottle of Vodka fearing I just made a huge mistake in my choice of schooling.....

  • @Greg: If you really wanna start drinking a bottle of Vodka because you fear you've made a big mistake just because:
    1) one guy
    2) who has no knowledge at all about what Microsofts plans are
    3) draws a personal conlusion
    4) based on a youtube movie

    You indeed might have been better of spending your money on something else. Development is all about using your own common sense, and not about following/trusting shouters who do not know what they are talking about.

    Cheers,

    Wesley

  • I'm primarily a .Net / C# developer, and I applaud Microsoft for this move. With iOS and Android dominating the mobile & tablet world, Silverlight has become irrelevant (even more so than Flash, which at least works on Android). All that work spent on creating a cool XAML UI has to be done again for each platform. It's a huge waste of time and money.

    Give me native support for the only standards-based client app framework that plays on all platforms (HTML 5 + JS), and I'll be delighted.

    .Net's future resides on servers and Azure. MS has an awesome offering there, with outstanding tool support.

    Finally to those .Net developers who see this as the end of the world: just learn the new stack. It's part of your job description anyway. Sticking to one language / technology stack for your entire career has been a dead end for a while now. Software engineering today requires adaptive people who can apply their abstract thinking whatever the platform. Had I stuck to Lingo and Coldfusion, I'd be selling magazines door to door by now.

  • im a C#/.Net developer and never used silverlight and only a little XAML and WPF.

    C# is way more productive then C++, CLR performance is very good. VS is a top IDE and WCF is powerful.

    .NET is not dead.. nothing will change for applications that only use thin clients.

Comments have been disabled for this content.