Since Inbox is often brought up as a textbook example, I'll give my two cents and some history. This is my post-mortem perspective, and the opinion of my former team members may be different.<p>I worked on Inbox from inception (as a former member of the GWT team), at the time Google was moving towards 'mobile first' (notice how there's no still Web version of the new Google Calendar), so the new generation of apps prioritized architecture and design for native-mobile and material design over desktop. Inbox was mostly written in a shared Java codebase transpiled with GWT (later J2CL) and J2ObjC (for iOS), so it could run natively on mobile from a single codebase. It obtained >75% code reuse between platforms, but a result of that however was a rather large SPA on the Web.<p>Because of its design as an installable material-design mobile app, it forced bleeding edge technology on the Web version to maintain a shared codebase. So for example, because it includes an entire compiled datastore/synchronization engine that is too heavyweight to run on the browser UI thread, it made early use intensive of WebWorkers to simulate multithreading (at a time when there were lots of browser implementation bugs in Workers). For most of the time that I worked on it, Firefox Dev Tools couldn't even debug web workers well, and often Firefox dev tools would just fail with huge size of SPAs like Inbox.<p>Getting material-design style animations compositing at 60fps cross browser was also fraught with peril because the different browser renderers had very different ways they scheduled GPU texture uploads for compositing, different hazards when they fall back to software rasterization, and very poor devtools visibility into what would cause anomalous painting problems (excessive repaints, layouts, or straight up freezes waiting for the GPU). Yes, today that is all much better, but in 2012 it wasn't, and short of getting ahold of browser engineers and asking them to hook up C++ debuggers or instrumentation to tell Web engineers why rendering was failing, debugging performance jank was hard. When we ran into a rendering problem with Chrome, we'd file bugs against Blink, and when we encountered problems with Firefox, we'd contact the engineers there. Perhaps because of heavy work on Firefox OS at the time, the Blink engineers would respond with help faster, so that obviously had an effect on performance differentials and delays, especially when the problems are mystifying to a Web Dev without browser internals knowledge.<p>Even something as simple as Javascript arrays were fraught with peril. Inbox made heavy use of protobuffers. Protobuffers compiled to JS exist as sparse arrays in Javascript due to proto-number extensions having huge gaps. Well, on Firefox at the time, if you did something like var a = [], a[100000000]=1, and then Object.keys(a), it would return an array with 100 million elements IIRC, but Chrome/Safari/Edge would return an array of 1 element. When you tried to debug this, Firefox Dev Tools would just freeze. It took me a week of inserting console.logs and bisecting until I figured it out.<p>(see <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1045391" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1045391</a> <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1088189" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1088189</a>)<p>Now you could say argue one of the following:
1) Google could have held up shipping Inbox until Firefox and Edge fixed all of their bugs that were blocking it
2) They could have just shipped the Android/iOS versions and held up the Web versions
3) They could have chose a different architecture (no shared code with mobile, rewrite a custom 100% web version from scratch)
4) Avoided excessive use of WebWorkers or SPAs
5) Not required a UI design/DOM structure that would require complex layout and painting stressing rendering pipelines<p>But no where in there was any active attempt to try and disadvantage other browsers. They sat out with an ambitious design for a Web app that they wanted to be 100% in parity with native mobile versions, and then found out that the Web platform itself wasn't up to handling it. Chrome could <i>barely</i> handle Inbox in 2012.