"Interested Implementers"

[mnot]

In https://github.com/whatwg/fetch/issues/671, @kentonv asks for a change to Fetch, and the response from @annevk is that "We basically want at least two browsers to also support it to ensure long term success."

This is an excellent example of a place where a WHATWG API has applicability beyond browsers. Lots of people are looking at Fetch for "serverless" applications, and arguably Fetch (and ServiceWorker) could benefit a lot from the experience and input of these folks (since SW is arguably an in-browser intermediary, and lots of intermediary folks are interested in serverless).

However, if the decision-making process is that browsers have the final say in everything, that's something that non-browser folks are going to have to take into account when deciding whether they want to adopt APIs like Fetch or come up with something separate (possibly forking).

I know that the WHATWG is excellent at collecting feedback and engaging with the developer community, which somewhat mitigates, but the underlying concern remains; having browsers in complete control over APIs that are used in non-browser situations creates concerns about their adoption, since the browsers might not care about the use cases driving any particular change down the road.

We've all discussed this many many times, but I'd like to have another go at it. Would the WHATWG be amenable to a change here -- e.g., considering a non-browser implementation as counting for the purpose of gauging interest for an API like Fetch?

[annevk]

This is probably a question for the @whatwg/sg, but it seems quite tricky as these server-side implementations are effectively forks that roughly match the API, but not quite. There's less of a need for them to use CORS, for instance.

For APIs where it's not a fork, e.g., new URL(), that could be interesting, provided the additions are as universally applicable as the original API is.

[michaelchampion]

@mnot wrote

considering a non-browser implementation as counting for the purpose of gauging interest for an API like Fetch?

I'm in favor of exploring this idea. I don't think WHATWG should get into the business of defining specs that are NOT implemented in browsers at all, but it seems preferable to have server/cloud scenarios covered conditionally in the standard rather than motivating those communities to fork the spec. That implies that implementation experience and commitments from non-browsers should in some way be taken into consideration in assessing whether a feature can be successful.

[domenic]

My general take is that we need to produce useful specs for the core constituency, which I would define (at least for the implementer segment) as browsers or software that wants to be compatible with browsers. If other software, e.g. servers, wants a feature, but there is no multi-browser-implementer interest, then adding that feature to the spec would do a disservice to that core implementer constituency. E.g., any server software that wanted to be compatible with browsers could be misled by the presence of such features.

So such features would make more sense to me in extension specs, or maybe idea.spec.whatwg.org.

[mnot]

@domenic if another community (like people doing serverless) is able to achieve what they want as separate extension specs, that makes total sense. Of course that means that specs need a good extensibility story, but generally we're not TOO bad at that.

It gets harder where there's a need to change "core" functionality. If browsers are against the change, it's not surprising for the request to get rejected. However, if browsers are neutral, all other things being equal I'd hope that non-browser implementer preferences would carry some weight.

[othermaciej]

We definitely wouldn't want a change in a core spec if browsers would refuse to implement. It does seem that in this case, extension specs would be the right way to go. Having a spec that applies to browsers specify something that browsers won't implement would be unhelpful.

If browsers were willing to implement something, but only reluctantly, then we might have a tricky case, whether it's worth adding something primarily for non-browser use. I don't think we know whether that applies here, yet, since browser engine implementors have not yet weighed in (affect). I suggest we get that input before addressing the meta point.

My expectation is that, for this specific change at least, if it is valuable at all, then it is valuable in browser contexts as well. Request rewriting seems just as applicable to in-browser use of ServiceWorkers as to the alternate scenario described there. So it's a straight tradeoff of developer convenience for this use case vs API complexity (and possibly design challenge if we have multiple levels of immutable objects involved).

If we actually end up in the case where browsers are all very mildly against, but reluctantly willing, then we can decide what to do in that case. I am not sure it's helpful to play out that scenario prospectively.

[mnot]

@othermaciej that makes sense.

It seems like this is going to drive non-browser folks to decide to adopt a WHATWG API only if it's very close to what they need (or can extend to), and to either fork or start fresh if they anticipate having to make many changes. That's probably OK.

[othermaciej]

Or if they have a strong goal to simulate a browser-like environment to the point of being compatible with actual browsers; in some cases that goal may trump wanting things to work a certain way.

If someone really want to be compatible with browsers to the point of using a spec they are intended to implement, but has a fundamental need for a change that isn't going to happen in browsers, then they have incompatible goals.

Not sure that is the case here though or if any real such case would come up.

[kentonv]

For our (Cloudflare's) part, we don't have a strong need for perfect compatibility with browsers. Developers target server-side Cloudflare Workers for different use cases from browser-side Service Workers, hence they're generally writing code specifically for our platform, making perfect compatibility less of a concern.

However, we benefit from compatibility to the extent that it allows reuse of common JavaScript libraries, documentation, community resources, knowledge, etc. based on those APIs.

My biggest fear is that we develop an API extension for our needs and then, some time later, WHATWG develops a different way to do the same thing or, worse, an incompatible API.

To that end, what I'd most like is a way to get feedback on our API extensions such that we can feel reasonably confident that WHATWG won't go down an incompatible path later.