I Bet That *Almost* Works

Recently, I've noticed a pattern. When I present a problem that I'm having with a platform, I am often told "you can already do that with <some API that wasn't intended for this>."

An old example:

Me: I really wish it was possible to get native-like acceleration when scrolling on mobile devices.

Them: You can already do that with touch events!

More and more, I find myself saying "I bet that almost works."

What I mean is that while the API in question looks like it'll do what I need, it almost certainly has some impedance mismatches with the problem I'm trying to solve.

The most likely practical mismatches are composition issues (once I've reimplemented scrolling, other code that interacts with the browser's scrolling system stops working) or performance issues (the overhead of the emulation is too high at scale).

Can HTTP/2 be used to fully replace bundling? I bet that's almost true.

Can scroll handlers be use to implement occlusion rendering (only render what's actually on the screen)? I bet that's almost true.

Can you implement Shadow DOM by replacing all of the DOM APIs? I bet that's almost true.

In general, the solution is to start with the mismatched API and try to identify the exact sources of mismatch, and then iterate towards something without the mismatch.

Today at TC39, I was talking with Domenic Denicola about dynamically triggering a <link rel="preload">, which allows applications to instruct the browser to preload an asset, but not do anything with it until it's demanded.

The spec says that you can do it dynamically this way:

<script>
var res = document.createElement("link");
res.rel = "preload";
res.as = "style";
res.href = "styles/other.css";
document.head.appendChild(res);
</script>

My immediate reaction was "I bet that almost works." Thinking about it further, I realized that a major limitation of this approach is that it requires access to the DOM, which is not available in workers.

The second idea Domenic had was to use the fetch API directly, and again I (way too glibly, I'll admit) said "I bet that almost works."

That opened up a discussion about my desire to control the priority of the request (from the spec: "preload is a mandatory and high-priority fetch for a resource that is necessary for the current navigation") and whether or not the fetch spec's concept of priority is sufficient as currently implemented (and whether it could be retrofitted for this purpose if necessary).

Pointing out these mismatches is often perceived as an attack on the proposed solution. I've learned that it's instead an opportunity to tweak existing "almost right" APIs to close the gap.

It's pretty cool, actually, how quickly you can make progress on a difficult problem once you realize that "it's impossible" is really "it's almost possible."