"Seems to work" is not the same thing as "Working As Intended". I work on Gmail/Inbox (previously GWT). When we released Inbox, it started out as Chrome only, p

"Seems to work" is not the same thing as "Working As Intended". I work on Gmail/Inbox (previously GWT). When we released Inbox, it started out as Chrome only, people discovered they could get it to load and seemingly work on Firefox by spoofing, but the reality was, it was still broken, and would eventually consume all memory, because Inbox relies on sparse Javascript array behavior for protobufs, and something like a[300000000]=1, for(x in a)/Object.keys(a) would cause the JS engine to allocate a giant array. Inbox also was a the first web property to adopt a form of Material Design, and had hard design requirements for 60fps on the Web Animation. Unfortunately, due to the way browsers upload GPU textures when doing compositing, animation timing was broke. (Do they count time spent uploading in the interpolation?) My coworkers spent a huge amount of time fixing it, and then finally making Edge work. There was no ill will or evil plan, just finite engineering resources. I don't know the details around Google Docs, but my guess (speculation) would be it probably had to do with Content-Editable. Docs was a Google acquisition of Writely. Back in those days, many online editing apps on the bleeding edge (ab)used Content Editable. Those of you who are Web developers know that Content Editable varies wildly across platform, has no real spec stating a deterministic expectation of what it should do. If the original Writely was based on this, they probably didn't want to fix it, instead Writely was rewritten and the new Google Docs basically avoids Content-Editable and implemented their own complete layout/editing engine in JS. Getting that to work correctly across many fonts, languages, BiDi support, etc was probably a hellish amount of work, but the end result was probably to make it more resilient against across browser issues. We've now reached a stage where every time something breaks or someone gets deranked, they immediately start jumping to conspiracy theories about how they were specified targeted for nefarious reasons, no one seems to understand Hanlon's Razor. Google only recently retired IE8 support. I wanted it dead for a long time. Am I evil? Our code base is littered with horrific code smell in our JS due to Microsoft's bad garbage collection implementation in prior browsers. In order to reduce memory leaks in our Closure Library code base, it's full of C++-like destructors/retain-release like constructs, which increases codesize, decreases performance. Google Web Toolkit's whole widget system was constructed around the needs of IE6/8, which ultimately bloated and doomed its UI system from adapting to the modern web. Web programming is still fraught with issues, issues you don't encounter on iOS, and to a lesser extent, Android, because of a single implementation. The combinatorial explosion of browsers, browser versions, form factors, means testing on everything and everywhere, and even with the resources of Google this creates significant impacts on productivity and maintenance. That means you can't expect a modern, bleeding edge web app, to come out of the gate working perfectly everywhere, especially if it is adopting only recently shipped APIs as a core requirement. So you have only a few choices: hold up your release until everyone catches up, ship everyone the same lowest common denominator triaging out the advanced stuff, shipping an app with all kinds of workarounds and fallbacks, or shipping a native mobile one instead. It's the threat of the latter which is the real problem these days, because with mobile first, engineering wise, it looks cheaper and more predictable with better user experience.