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.
Interesting thought, I'm not sure if PointerEvents would be handled correctly with a trackpad that would have traditionally used as Mouse input either. Seems like the developer would have to know how the trackpad is being used more than anything else since mouse/touch are very different behaviors.
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.
I strongly hope that there will be a drive among the major browser makers to do what it takes to make the future Web as powerful a platform as possible, even at the expense of delegating support for some old websites to legacy-support plug-ins. I personally would not have a problem with a dual-path approach to the Web: one set of browsers that specify a "current standards" Web platform with maximum capabilities, strict rules, and no legacy baggage, and an optional set of browser plug-ins, to which older, non-conforming sites are delegated.
This would allow the Web platform on small-capacity devices such as watches or headsets to grow in capability like an iOS device with its frequent OS upgrades and deprecation of older code, but would make the whole Web back to the earliest websites still accessible to somewhat larger and more capable devices (desktops, laptops) that could afford to include plug-ins for any old crazy code from the past.
I really don't want the Web to be the "we'll keep hanging on to the past" platform, while the native APIs are the "we'll keep bringing you the future" platforms.
I think you got downvoted for asking a foolish question. If there were linux builds in the plans, they would have announced it. If open sourcing the whole thing was planned... well, you get the idea.
I don't see what is foolish about the question (and was taught [and believe] that there are no foolish questions).
MS has opened up their flagship development platform (.NET) and even has it building on Linux. MS will also rent you Linux virtual machines.
The post also talks about interoperability and running across many kinds of devices, including "try out RemoteIE which will stream our latest browser from the Azure cloud to Windows, iOS or Android devices."
First of all, the team who open-sourced .NET is a different one from that that is building IE. DevDiv has been very open-source-friendly for a few years by now.
Then there is the fact that .NET is far less tied to the platform than IE is. .NET is nothing more than a VM, runtime and GC. That's fairly easy to get cross-platform, compared to a GUI application that makes use of platform libraries for hw-accelerated drawing and text rendering.
So when your browser doesn't work on modern web sites that make up 90% of what people visit, people will site "broken compatibility" and then move to Chrome or Firefox. You'll then reiterate your focus on the few outdated sites that no one visits stating that "broken compatibility" is the cause.
I think you may be mistaking broken compatibility with backwards compatibility. I don't use IE because it doesn't work with modern web sites.
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).
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.).