| 19:49 | <nicolo-ribaudo> | https://tc39.es/ecma262/multipage/additional-ecmascript-features-for-web-browsers.html#sec-web-compat-host-make-job-callback Should we remove the restriction that only web browsers can pass custom data in HostMakeJobCallback? Both Node.js and Deno already violate that restriction anyway, by implementing AsyncLocalStorage |
| 20:12 | <Michael Ficarra> | https://tc39.es/ecma262/multipage/additional-ecmascript-features-for-web-browsers.html#sec-web-compat-host-make-job-callback |
| 20:20 | <Meghan Denny> | i dont think it means only web browsers can implement it, moreso that you can not implement it and still be conforming and that web browsers are the most common use case that would need/implement those features |
| 20:23 | <Meghan Denny> | oh, i see 9.5.2 says 'must' |
| 21:22 | <ljharb> | we often have allowed browsers to do something "icky" out of necessity but intended to require non-browsers to do the better thing |
| 21:38 | <Andreu Botella> | it seems like one half of what those host hooks do is keeping track of which is the "incumbent realm", which according to littledan could be refactored to be built on top of AsyncContext |
| 21:39 | <Andreu Botella> | the other half of what they do seems to be making it so the dynamic import in Promise.resolve('import(`./example.mjs`)').then(eval); resolves relative to the script active when the promise job is enqueued |
| 21:39 | <Andreu Botella> | and I wonder what Node.js does there, and whether we would want to keep this behavior or not if there were no web compat concerns |
| 21:45 | <shu> | do you have any information on why it was originally scoped to only web browsers? because at the time, it was understood that the expressivity this hook enabled was 1) tantamount to dynamic scope, which Mark & co objected to philosophically, and 2) it described the reality of the incumbent settings object on the web so the reconcile the two, the decision was to reflect reality by speccing it, but limit it to the only implementation that needed it |
| 21:45 | <shu> | since then, i suppose those objectors have gotten over the philosophical objection that it was tantamount to unacceptabel dynamic scope, given the enthusiasm about AsyncContext |