Risks of premature polyfilling

[Jxck]

import { storage } from "std:async-local-storage|https://somecdn.com/async-local-storage.js";

in this case, browser shipping std:async-local-storage which is different api from fallback js polyfill,
will seems break application.

(details are in https://w3ctag.github.io/polyfills/#risks-of-premature-polyfilling as premature polyfill).

it's seems better for lapis to have some policy for updating polyfill for avoiding case with hard to change api because of old-api-polyfill.
or is there any way to avoid this risk ?

[domenic]

I'm not sure exactly what you're asking here.

In general, web platform APIs---including layered APIs---cannot change in backward-incompatible ways.

Also, I'd be surprised if a web developer chose to put a polyfill after the | which did not match the layered API they were polyfilling. In general, I'd be extraordinarily surprised if they put a polyfill there for a layered API that didn't exist yet; that doesn't really make sense.

I'm also unclear on what you mean by a policy for updating polyfill. The web developer controls the URLs after the |; we can't make a policy about what web developers do.

Can you explain the risk more clearly?

[matthewp]

I think the risk exists if someone was to create a speculative polyfill and the standards body later decided to make changes to the API. The risk is avoided if the standard simply defers giving it a name until the API is finalized.

[ojanvafai]

I think this is a real risk, but I'm not sure what we can do about it. Conceptually, it's not different from a developer feature detecting today and loading a speculative polyfill though, so hopefully it won't be too much worse of a problem than we have today.

[domenic]

The idea of not giving a LAPI a standardized name until the API is shipped in at least one browser, to avoid developers "squatting" on it in an incompatible way, is an interesting one.

[ojanvafai]

Hah...that's clever. Somehow I missed that suggestion. That's hard to do I think? But if we could do it would be great.

[domenic]

Yeah, I mean it's not really hard to guess that the identifier for a project named async local storage is going to be something like "async-local-storage". But maybe just having the spec say "IDENTIFIER NOT RELEASED YET" and all the examples say e.g. "std:als-identifier-tb" or similar would nudge things in the right direction...

[ojanvafai]

We should try it! Worst case is that it doesn't work and we stop doing it in the future.

Probably worth putting this in the LAPIs explainer if we do.

[Jxck]

Can you explain the risk more clearly?

"std:als|polyfill.js" works fine only if both API are same. if not, browser update will break the application.
so, It seems better to have some checkpoint or guideline when is best point to using polyfill syntax.
on the other side, if speculative polyfill used by tons of web apps, and standardization wanna change api, will cause wide breaking too.
(and also, speculative polyfill seems cause a naming space problem in "std:xxxx". is this really free for developer ?)

if you think "polyfill is only a polyfill, we can't go forward without backward-incompatible, currently same things happens, as is in rapis" that's ok.
but I think it's good change to think about that for future rapis(avoid smooshgate again)
identifier naming policy, announce checkpoint for using "std:xxx|polyfill" style, using origin-trials etc
actually, I don't have good idea how avoid this risk (so I'm asking)