ambientimpact.comAmbient.Impact

Skip to main content Main navigation Web dev Services Snippets Resources Components Tags Portfolio Gaming About Contact Hi there. My name is Matei Stanca and I make websites and stuff. Featured project Neurocracy Project images Neurocracy is a joint project between myself and my good friend Joannes . It aims to be equal parts interactive fiction and cautionary tale about the intersection of surveillance capitalism, big data, and authoritarianism. View portfolio Latest snippets What is the Value of Browser Diversity? In May 2019 I attended a talk by Mike Taylor who works on webcompat at Mozilla. Mike told the sordid story of window.event , a non-standard IE invention that was replicated in Konqueror, which showed up in Webkit, which stuck around in Blink, and was now Mike’s problem in Firefox. It was a good story fraught with ups and downs and literal “Breaking the Web” level changes for a tiny feature rollout. At the end of the talk Mike threw out a pretty prescient question (Edge had just released its Chromium beta) and I’ve been mulling over it ever since: What is the value of browser diversity? If Firefox switched to Chromium tomorrow, what would we lose? – Mike Taylor, a traitor (apparently) Mike made it clear that the question was purely theoretical and no serious talk about this was happening at Mozilla at the time. Nonetheless, it was a challenging thought. Throwing away all sunk costs, what is the value of the colossal expense required to employ engineering teams to chase Chrome’s tail? I’ve thought about these questions for over a year and narrowed my feelings of browser diversity down to two major value propositions: Browser diversity keeps the Web deliberately slow Browser diversity fosters consensus and cooperation over corporate rule They are similar, but slightly different concepts for me. Slow, like brisket. I think the Web platform’s most frustrating aspect is also its greatest asset: it’s slow . It’s not just slow, it’s “it took 10 years to ship the <main> element which is just a spicy <div> ” kind of slow. It’s glacial. This can be agonizing while you wait for a much needed feature to roll out in all browsers, only to find out five years in the process one browser refuses the entire premise of the feature (RIP HTML Imports). The big tradeoff is that web platform features have to run the gauntlet and more thinking is applied over time: robustness, naming, internationalization, accessibility, security, etc. all have proper time for consideration and aren’t rushed through like it’s a product sprint. […] Cooperation, not corporation. Browser diversity means browser vendors are hindered from shipping features that only benefit themselves (e.g. ActiveX in IE, -webkit-box-reflect , etc). Good ideas have to be open and meet a pseudo-requirement of ubiquitous utility. To make good platform features requires consensus, not competition, and the web’s potential is born out of cooperation, not a single corporation. It’s hard to quantify this, but if all aspects of the Web (development, browsing, searching, hosting) are ceded to a single corporation , all it takes is one heavy-handed manager or executive hellbent on hitting some OKRs to push their thumb on the scale of the Web. If the Web is governed by a single corporation, it will start looking like that corporation’s vision of the Web, ultimately limiting its own potential. Trading short term gain on new shiny features for long term vision. Deep dive into how IntersectionObserver works This is a delightfully nerdy exploration of how IntersectionObserver works, its quirks and caveats, and how it can be used to create a JavaScript position: sticky event as a bonus. Why browser diversity matters: Chrome unilaterally creates de facto standards Yet another great example of why browser diversity matters and why Chrome’s overwhelming presence in both mobile and desktop use is harmful to the open web: some developers mistake Chrome’s adoption of an API as a web standard, when both Mozilla and Apple have serious concerns about the security of said API: In issue #509 of JavaScript Weekly , Chrome’s new File System Access API was mistakenly referred to as an “ open standard .” The author probably assumed that a feature with a specification and an implementation in Chrome must therefore be a web standard, but that is not necessarily the case. The API in question is currently hosted by the Web Incubator Community Group (WICG), a place where browser vendors can propose, discuss, and develop new web platform features, and receive feedback from the wider community. […] Google has been developing the File System Access API for at least the past two years and decided to ship it in Chrome in October (last month). As part of this process, Google asked both Apple and Mozilla for their official positions on the API. So far, their responses have not been positive ( Apple , Mozilla ). It seems that Google decided to ship the File System Access API in Chrome without endorsement from Apple or Mozilla because it believes that this feature “ moves the web platform forward ”: Interoperability risk is the risk that browsers will not eventually converge on an interoperable implementation of the proposed feature. … If a change has high interop/compat risk but is expected to significantly move the web forward , Chromium will sometimes welcome it. Standardization and support from Apple or Mozilla is not a requirement for shipping a web platform feature in Chrome. However, because of Chrome’s large market share, there is a risk of such a feature becoming a de facto standard : Changes to Chrome’s functionality create de facto standards . Market participants must adhere to these standards or risk their technology no longer being compatible with most websites. View all snippets Follow me on GitHub Follow me on GitLab Follow me on Steam Follow me on YouTube Follow me on Twitter Follow me on Facebook...