As an engineer that worked on IE, I can totally sympathize. Your story is one repeated throughout almost every enterprise of sufficient size.
That said, there's a middle-ground we should strike here. At some point, being out of date (sometimes as much as half a decade or more!) on your browser trumps the cost of keeping internal software up to date. This is not to mention the network costs of third-parties attempting to support your users browsing the public web and on browser vendors that take investment away from their latest versions to continue to support legacy software.Allowing indefinite suspension of upgrades by IT is definitively a mistake. It adds insult to injury that Google is repeating a mistake which we all learned so much about via IE and older versions of Firefox. We will all collectively pay for this if they don't course correct.
The middle ground here is providing extended support channels like what's being done for Firefox and Edge. Chrome already has Canary, Dev/Beta, and Stable channels. A slower moving, more stable channel for businesses would be a natural solution here.
This gives businesses time to test and adapt, limits the total number of versions in the wild that must be supported by browser vendors and web developers, and provides just enough paternalistic motivation to keep your internal software in a good state (upgrading to support latest browsers is a forcing function for testing, performance tuning, security tightening, etc.).
Remember that this is, in large part, a restructuring of existing orgs and investments. I wouldn't interpret this as the starting gun for AI/deep-learning investments at Microsoft. There's been heavy R&D investment for years in this space making its way into products like Cortana, Bing, PowerBI, Skype, Cognitive Services, etc. Similarly, there's a non-public side to the results at Microsoft I'm sure. So I don't think catchup is a fair analysis.
Microsoft engineer here. I would assert we want people upgraded more than anybody else on the planet. Our extended support contracts were designed to be cost prohibitive to encourage this point and were nowhere near a money-making venture. The engineering matrix (cost) for a fix across old versions was insane: IE6, 7, 8, 10, 10 touch; 32bit, 64bit, ARM; Windows XP, Vista, 7, 8, Server, Mobile, etc.; 5.5/7/8/9/10 browser document modes; etc. A "single" fix often meant weeks of porting work for engineers after the initial fix was written.
I can see value in finding a way to expose individual touch points from their new touchpad to JavaScript. We looked at doing something similar in IE, actually, but didn't get around to it in time.
If they want to do that, then they're going to have lots of compatibility problems doing it with Touch Events. Too much code out there expects the presence of Touch Events to mean a touch-only device. So if you enable TE on a laptop, suddenly sites stop working for mouse/track. :-( Pointer Events don't have this problem.
In Seattle, overnight parking does not cost. They actually have stickers on the parking meters reminding drivers of this in the case that they're planning to drink.
It was most often not the case that (a) vendor prefixed APIs matched a particular "version" of a spec nor (b) were interoperable across browsers at any point (e.g. -moz-foo didn't necessarily have the same behavior as -webkit-foo).
The issue isn't vendor versus version prefixes. The issue is sites using early versions of an API, relying on them, and then never removing/upgrading that code.
-webkit-border-radius for example doesn't necessarily match a particular version of a spec. Unprefixed, standard border-radius has been in all the browsers for several years [1]. Yet over 60% of page views (according to Chrome data [2]) still requires this property. So other browsers are forced to support the webkit version of this property for compatibility, which may not have a particular version of a spec for those browsers to reference when implementing support.
If you're interested, I gave a talk with other browsers at Mozilla HQ last week about some new ideas for how we can further improve the strategy for experimental APIs going forward. Check it out and give me feedback if you'd like (@jacobrossi on twitter).
Actually, our approach is effectively yielding the results you're looking for.
Removal of old IE legacy cruft is slimming Spartan's disk and memory footprint when compared with IE. Advances in the Chakra engine are pushing performance ahead. We're rearchitecting our DOM, which is yielding perf and security wins too. We're planning an extension platform also, with top add-ons like ad block being a clear target.
There's a bit of a catch 22 with "get users" and "watch compatibility fix itself" as broken compatibility is often cited as a top reason for users to switch browsers. It's hard to grow users without investing in compatibility.
So what we're doing is defining our "blend" of investments. Right now we have a heavy amount of interop investments in our blend as we think that's important for users. Over time (months, not years) the major interop gaps will disappear and I expect we'll see a shift in that blend to increase investments in other areas.
We're implementing ORTC (which actually gets its origins from outside Microsoft: http://ortc.org/history/). ORTC is essentially WebRTC "1.1" and there's active standardization work going on (in both WebRTC 1.0 and ORTC specs) to make them have a high level of compatibility. ORTC enables more scalable video and simplifies the way the data is exchanged by using a vanilla JS object style (eliminates SCP Offer/Answer).
Yep! We're committed to interoperability and compatibility for sure, and that includes implementing Touch Events. But, we don't see that as a blocker for moving the web forward with better models. Table layout was terrible.
For example, we've built better layout APIs (grid, flexbox, etc). Table layout still exists and is probably "here to stay". But we've nearly eradicated it from the modern web and moved the web into the future of responsive design. We can do this with input too.
It has 2 implementations (Firefox has implemented in a special branch and is working to port it to their main codebase) and a near complete test suite. Thus it's expected to reach the final Recommendation state soon.
So I don't think the standardization status will change Google's opinion here.
On the contrary! I work on the IE team and we're playing along nicely. Google just joined us on the ORTC spec, which Chrome considers to be essentially Web RTC 1.1.
I just tested it in 3.6.8 on Win 7). No crash for me. Though Firefox has a hard time rendering it (~30FPS, or about 1/2 the frame rate of Chrome, IE9 Platform Preview 4, Safari, or Opera!). Try another browser perhaps ;-)
Also, if you have a lot of add-ons/plugins it could make it even slower (some of these try to modify the page every time it changes).
If you get any error codes, I'd love to know the details! Thx
That said, there's a middle-ground we should strike here. At some point, being out of date (sometimes as much as half a decade or more!) on your browser trumps the cost of keeping internal software up to date. This is not to mention the network costs of third-parties attempting to support your users browsing the public web and on browser vendors that take investment away from their latest versions to continue to support legacy software.Allowing indefinite suspension of upgrades by IT is definitively a mistake. It adds insult to injury that Google is repeating a mistake which we all learned so much about via IE and older versions of Firefox. We will all collectively pay for this if they don't course correct.
The middle ground here is providing extended support channels like what's being done for Firefox and Edge. Chrome already has Canary, Dev/Beta, and Stable channels. A slower moving, more stable channel for businesses would be a natural solution here.
This gives businesses time to test and adapt, limits the total number of versions in the wild that must be supported by browser vendors and web developers, and provides just enough paternalistic motivation to keep your internal software in a good state (upgrading to support latest browsers is a forcing function for testing, performance tuning, security tightening, etc.).