Bugzilla

> Have you actually gotten TC39 on board with this proposal to have some realms contain a global SharedArrayBuffer property and some not?

TC39 is definitely aware, as Anne said. We got consensus for it in the March 2020 meeting.

I've understood 1JS historically to be more about going against modes within JS itself, not that the JS host environment capabilities are identical. As we started speccing closer-to-the-metal features like SABs and now WeakRefs, I think the interpretation of 1JS being "JS host environments must provide all things in specified in ecma262" is just gone. The high-order bit is how the web deals with the normative optionality, and as Anne said, you already have to zoom out a bit to see "1JS".

I think giving hosts normative optionality is probably the right thing for the web, so the web platform (and other hosts) can constraining features at the cost of developer to serve users better. [[CanBlock]] is the most obvious candidate here, but the general "make it hard to do expensive sync work on the main thread" is a pretty prevalent theme and may even affect syntactic features like top-level await in ServiceWorkers. The danger that made TC39 come up with the 1JS idea is still relevant though, and the web platform should take care to not introduce too many such "profiles" of JS features.

> Have you actually gotten TC39 on board with this proposal to have some realms contain a global SharedArrayBuffer property and some not?

TC39 is definitely aware, as Anne said. We got consensus for it in the March 2020 meeting.

I've understood 1JS historically to be more about going against modes within JS itself, not that the JS host environment capabilities are identical. As we started speccing closer-to-the-metal features like SABs and now WeakRefs, I think the interpretation of 1JS being "JS host environments must provide all things specified in ecma262" is just gone. The high-order bit is how the web deals with the normative optionality, and as Anne said, you already have to zoom out a bit to see "1JS".

I think giving hosts normative optionality is probably the right thing for the web, so the web platform (and other hosts) can constrain features at the cost of developer to serve users better. [[CanBlock]] is the most obvious candidate here, but the general "make it hard to do expensive sync work on the main thread" is a pretty prevalent theme and may even affect syntactic features like top-level await in ServiceWorkers. The danger that made TC39 come up with the 1JS idea is still relevant though, and the web platform should take care to not introduce too many such "profiles" of JS features.

Edit: For the web, pragmatically, I should say _even if_ TC39 held fast to its 1JS motto in your interpretation, it doesn't make too much of a difference for the web developer. What's "core JS language" and what's a web API is a line that only clearly exists for those of us involved in web standards. The web devs really do not know at large, judging by the studies I've seen, nor is it important for them to know. So, even if the core language was exactly the same in all hosts, the capabilities of different environments within the web (main thread, worker thread, service workers, COOP+COEP or not) are already different, and devs already treat them differently.