Microsoft should replace IE with a CoreCLR-based browser

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)

The third front which was I was going to lead into is the runtime front where .NET/Silverlight competes with the Flash/Flex platform and Java.  This, I believe is the most important and exciting front and the unnamed third competitor is, of course, Adobe.  And in fact, since then a fourth platform is slowly emerging as credible challenger going forward – JIT-compiled Javascript plus HTML 5’s Canvas and Canvas3D (WebGL).

( 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. )

The browser platform, with JITing VMs for Javascript and the incorporation of Canvas/Canvas3D/WebGL will give us most of what RIAs have to offer (performance + rich graphics) but preserve the URL-based REST nature of the Web.  The only problem with this is that we are still limited to just one language – Javascript – for creating such applications. Flash, which is Actionscript (the statically typed Javascript which resembles Java more than browser Javascript 🙄 ) only, has the same limitation.

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 System.Windows.Browser API.  All that would be needed would be to ensure that the CoreCLR-based Javascript running in this browser emulates traditional Javascript perfectly (down to the DOM API) – and since it’s a new non-IE browser, you can also throw away all the old IE4 era DHTML stuff and ActiveX support (also increasingly irrelevant except the IE development team probably still doesn’t want to acknowledge this yet) and just concentrate on supporting true web standards.  The point here is that while Silverlight / XAML in particular enables some truly awesome capabilities that HTML tags, even with Canvas, are going to take a long time to match, the RIA model breaks REST and this is a huge liability in the eyes of many people.

If Microsoft wisely chooses such a move, it could potentially do an IE4 all over again.  IE4-6 dominated by partly embracing some web standards and extending it with its own rich DHTML object model (now dead in favor of W3C DOM).  This new CLR-based browser can embrace Javascript, JITing VMs and then extend it by allowing people to directly script DOM with IronPython, Boo, VB.NET etc…  <SCRIPT> tags already support specifying the language and presumably, you would want to extend it with attributes that specify loading of CLR assemblies, for example.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *