The Web-Interoperable Runtimes Community Group
deno.com
deno.com
What's your plan for handling this in cases where there's existing divergence? Is there general enthusiasm for breaking changes in server-side frameworks to fix that and create consistency? It is much easier to do on the server than in the browser, but still painful...
a) Divergence in implementation on the same API surface (e.g setTimeout in Node) b) Divergence in API surface for a similar implementation (e.g WHATWG streams vs Node streams)
The former is obviously much harder to change than the latter, as the latter can be resolved by adding additional API surface. I assume you are talking about the former.
This sort of divergence where implementation differs, but API surface is the same is luckily pretty rare. The most prolific example is setTimeout in Node. It's unclear how exactly the Node project intends to deal with situations like these. It's possible that this is something which can just never be solved in Node, and it just sticks around as a "wart" forever. The solution to compatible APIs for cases like this would likely need to be a new API then. For async timers this could be a promise based API like `Promise.delay()`.
There is unfortunately no "one size fits all" solution for these problems though, which is why this CG exists. We're going to try to categorize and come up with solutions to these problems.
Happy to answer any questions you may have !
@jgrahamc would you consider merging/rebasing Workers on Deno or another runtime once these APIs converge?