All the emphasis on market research makes me worry that they are going to end up with a Homer Car name like “Microsoft Visual Internet Suite 2016 Premium”. I am rooting for them, but Microsoft is its own worst enemy sometimes.
I’m more interested in whether they’ll be willing to fix bugs that might in some way that might be backwards-incompatible to scripts that might rely on those bugs. I know it’s a major part of Microsoft’s decades-long culture that has been a valuable part of their business success (and if you don’t believe, it start reading Raymond Chen’s blog The Old New Thing until you get it…). But that practice is only valuable when they’re the sole maintainer of the platform. Web pages and servers don’t interact solely with Microsoft’s software. Everyone else is willing to fix bugs, so the code quickly turns into “this works everywhere, except where you need this IE workaround”. I regularly, even last week, encounter IE-only bugs that I expect to never be fixed.
This shared ecosystem of the Internet requires a fundamentally different practice to succeed. Either Microsoft recognizes this in Project Spartan and it can succeed, or they don’t and it only serves as a one-time release of tension in the ratchet of the ever-declining experience of developing against their Internet software.
In the coming months, swathes of IE legacy were deleted from the new engine. Gone were document modes. Removed was the subsystem responsible for emulating IE8 layout quirks. VBScript eliminated. Remnants like attachEvent, X-UA-Compatible, currentStyle were all purged from the new engine. The codebase looks little like Trident anymore (far more diverged already than even Blink is from WebKit).
What remained was a clean slate. A modern web platform built with interoperability and standards at its core. From there, we began a major investment in interoperability with other modern browsers to ensure that developers don’t have to deal with cross-browser inconsistencies. To date, we’ve fixed over 3000 interoperability issues (some dating back to code written in the 90’s) on top of the over 40 new web standards we’re working on. For example, longstanding innerHTML issues are now fixed.
What you quote sounds like the one-time release I feared. And looking farther in the article:
In order to ensure that we also retain backwards compatibility, we will not be getting rid of Trident. Instead, we designed and implemented a dual-engine approach, where either the new modern rendering engine or Trident can be loaded.
This is… I think maybe the third or fourth time they have executed this strategy of “yes we have a great new engine - and yes, we’re not breaking backwards compatibility!” What I’m saying is needed with the new engine is not perfect interop today, but a willingness to break backwards compatibility for better interop as issues arise.
To give a specific example: in most versions of IE (probably all the way to current; I haven’t checked in ages), in JavaScript [1,2,3,] !== [1,2,3] because IE adds a null on the end of the version with the trailing comma. But because some script somewhere might have relied on that behavior, Microsoft will not fix the bug, period. Maybe it’ll be fixed in Project Spartan, and that’s nice, but I care more that they’ll be willing to fix new bugs as they arise and I don’t see them commiting to that in this article or anywhere else.
What you quote sounds like the one-time release I feared.
I’m not sure how you square that with this:
Furthermore, we’ll treat Windows 10 as a service—keeping users up to date and delivering features when they are ready (“auto-update”), not waiting for the next major release. This means the new rendering engine will always be truly evergreen.
It’s anything but a one time release. They are switching to the same autoupdate strategy used by Chrome and FireFox.
This is… I think maybe the third or fourth time they have executed this strategy of “yes we have a great new engine - and yes, we’re not breaking backwards compatibility!”
I understand your concern, but the specific way that this is managed seems significantly different than previous approaches that put engine switching in the hands of web developers. Based on what they are saying, this engine switcher will be:
Turned off by default
Configured by a “compatibility mode list”
Enabled on a case by case basis by corporate IT
That’s vastly different than an individual developer sending down a series of arcane flags (doctype, x-ua-compatible, etc.) to trigger engine switching.
I think this should be tagged “browsers”.
All the emphasis on market research makes me worry that they are going to end up with a Homer Car name like “Microsoft Visual Internet Suite 2016 Premium”. I am rooting for them, but Microsoft is its own worst enemy sometimes.
I’m hoping that they actually name it Spartan, especially since they are including Cortana.
<snark> Are they going to officially change the name to “Microsoft Chrome Downloader?” </snark>
I wonder how standards-compliant project spartan plans to be…
I’m more interested in whether they’ll be willing to fix bugs that might in some way that might be backwards-incompatible to scripts that might rely on those bugs. I know it’s a major part of Microsoft’s decades-long culture that has been a valuable part of their business success (and if you don’t believe, it start reading Raymond Chen’s blog The Old New Thing until you get it…). But that practice is only valuable when they’re the sole maintainer of the platform. Web pages and servers don’t interact solely with Microsoft’s software. Everyone else is willing to fix bugs, so the code quickly turns into “this works everywhere, except where you need this IE workaround”. I regularly, even last week, encounter IE-only bugs that I expect to never be fixed.
This shared ecosystem of the Internet requires a fundamentally different practice to succeed. Either Microsoft recognizes this in Project Spartan and it can succeed, or they don’t and it only serves as a one-time release of tension in the ratchet of the ever-declining experience of developing against their Internet software.
I’m pretty optimistic given this article.
What you quote sounds like the one-time release I feared. And looking farther in the article:
This is… I think maybe the third or fourth time they have executed this strategy of “yes we have a great new engine - and yes, we’re not breaking backwards compatibility!” What I’m saying is needed with the new engine is not perfect interop today, but a willingness to break backwards compatibility for better interop as issues arise.
To give a specific example: in most versions of IE (probably all the way to current; I haven’t checked in ages), in JavaScript
[1,2,3,] !== [1,2,3]because IE adds a null on the end of the version with the trailing comma. But because some script somewhere might have relied on that behavior, Microsoft will not fix the bug, period. Maybe it’ll be fixed in Project Spartan, and that’s nice, but I care more that they’ll be willing to fix new bugs as they arise and I don’t see them commiting to that in this article or anywhere else.I’m not sure how you square that with this:
It’s anything but a one time release. They are switching to the same autoupdate strategy used by Chrome and FireFox.
I understand your concern, but the specific way that this is managed seems significantly different than previous approaches that put engine switching in the hands of web developers. Based on what they are saying, this engine switcher will be:
That’s vastly different than an individual developer sending down a series of arcane flags (doctype, x-ua-compatible, etc.) to trigger engine switching.