I wrote a blog article a few months back, Microsoft’s 3-front war, Part 1 where I was going to explain each of the 3 fronts Microsoft is competing on in a separate blog article and conclude with the recommendation in this article. But I’m going to skip all these and just jump straight more or less to the conclusion.
The first front is the desktop OS where Windows competes with Linux and OS X.
The second front if I recall correctly is the mobile devices / mobile OS front where Microsoft competes with iPhone OS X, Symbian, Android, etc… (and not doing a very good job of it by the way)
( In this blog post, the author clearly spells out a future where browser-centric standards – and NOT RIA plugins – serve as both the delivery and execution platform for just about all applications. )
This is where I believe Microsoft should be setting their strategic sights on. While .NET is an awesome environment, by going the RIA route with Silverlight, Microsoft has shown it still hasn’t gotten the Web yet. It has to do a far far better job of embracing web standards if it wants to dominate the future rather than Google.
( In this other blog post, the author explains why RIAs, among other things, destroy some of what is good about the web – in particular, the REST principle. )
With IE becoming more irrelevant and Google pumping up Chrome aggressively, we are going to see people increasingly have the option to use the above as a runtime platform instead of RIA-oriented technologies like Flash or Silverlight. However, Microsoft currently has the very important Ace up its sleeve which is the fact that neither Google nor Adobe have a CLR that can run multiple languages.
The solution seems clear. Side-by-side with Silverlight, Microsoft should start offering a browser – (probably) not IE – with the CoreCLR as its JITting VM engine plus proper Canvas/Canvas 3D/HTML5/CSS support (heck, just dump Trident and use WebKit). The browser DOM would then be programmable using any CLR language and in fact integration with Silverlight could potentially be even more seamless. Most of the infrastructure for this is actually already in place since the browser DOM seems already fully (?) exposed in the
Because the CLR is an open standard, such enhancements to the <SCRIPT> tag to support assembly loading wouldn’t (shouldn’t) be considered proprietary and such extensions would (should) be embraced by the standards bodies.
If ever I find myself wishing for Embrace and Extend, THIS is it.