Microsoft’s Jason Weber has posted details of the web browser story in Windows 10.
There will be two browsers and two rendering engines in Windows 10:
- Project Spartan is the “universal app” version of the browser, the successor to Metro IE.
- Internet Explorer will remain.
The two rendering engines are EdgeHTML (new) and MSHTML (old). Both engines can be used in either browser, so even the “Project Spartan” browser has a compatibility mode. Both browsers default to the new rendering engine.
However, only Internet Explorer supports features such as ActiveX controls and Browser Helper Objects, so some legacy web sites and applications will only work properly in IE.
For details of what EdgeHTML supports, see the status page.
Microsoft has been plagued by the “coded for IE” problem, where sites deliver inferior content if IE is detected – even where IE is fully capable of rendering the up-to-date content. Hence this comment:
Edge mode introduces an interoperable UA string designed to get today’s modern Web content, and to avoid old IE-only content. We’ve also spent a lot of time ensuring that the IE platform behaves like modern Web content expects.
It is unfortunate that Windows 10 will still have two web browsers, since this is a point of confusion for users. A lot will depend on presentation and defaults; if Microsoft can hide desktop IE so it is only used by those organisations that know they need it, that would be a good thing – presuming that Project Spartan offers a decent experience when used on the desktop.
There is a debate in the comments to Weber’s post about whether Microsoft should cease developing its own browser:
This looks like chrome. Please contribute to chrome if you want to make the web browser better. All this does is increase development costs by having to support another browser. Enough damage has been done by IE. Please stop development.
and the counter:
No, sane developers don’t want a single engine.
People want different engines that pushes each other forward, make things in a standard way (not like Chrome) and allows to check if the problem is their code or a bug in the browser.
My perspective on this is that Google already dominates web search and if Microsoft were to adopt its browser engine, there would be increased risk of Google dictating whatever standards suit its own purpose – just as Microsoft did in the dark days of stagnant IE development. Microsoft’s energetic development of IE is actually good for Google and for the rest of us.
“…it’s complex”:
“Complex” is also the reaction I had to this “Building Apps for Windows” post from MS:
http://blogs.windows.com/buildingapps/2015/01/22/windows-10-is-empowering-developers-to-dream-again-3/
This one post mentions:
– Universal Windows Apps in either Win JS or C#
– iOS or Android apps in C# via Xamarin or Unity
– Apache Cordova
– Android apps in native C++
That’s a lot of choices. How are they going to do a good job at all of those things?
How can I have confidence some of those options won’t be “Silverlighted” when they don’t get traction?
Vic
Vic, technology is always at risk of obsolescence. Look at what happened to Perl in the last ten years. Ruby is also flattening out.
Silverlight was a niche technology, developed by a small team within a much larger company. That small team lost a power struggle against a bigger team. The lesson is to stick with mainstream technologies that are important to the vendor. Don’t just be categorically afraid of everything.
Unity lives off its product, so it should be fine.
Cordova is open-source, so it should be fine.
Android is crucial to Google’s continuing relevance in the mobile space.
Avoid WinJS. Stick with C#.
Tom,
>…stick with mainstream technologies that are important to the vendor.
I agree with you there, in general, and I am sticking with C#, at least in part.
But MS isn’t the vendor of Unity, Cordova or Android. So I wouldn’t count on any long-term support for them by MS.
By offering support for Cordova and Android, MS is implicitly acknowledging that their own mobile platforms (like Windows Phone and “Windows Store” apps) and development technologies (like WinJS) have not gotten traction. So here are some other technologies you might like instead, which we’ll offer some support for in the next version of VS, but maybe not the one after.
Vic