| 18 Jul 2024 |
 Andreu Botella | In reply to @mhofman:matrix.org
Are we really debating whether observable global mutable state is a good idea or not in a language? Whether or not it's a good idea, there are use cases (in the web platform) that apparently can't be solved without some kind of observable global mutation. If you're arguing that HTML shouldn't use global mutable state, you're arguing that the web platform should stop existing because the DOM is globally mutable, and that can't change because it's part of web reality | 21:19:37 |
 ljharb | that's not the same thing. arguing that HTML "should have" been designed differently is not an argument that it should stop existing. | 21:26:41 |
| ljharb | in practice it's a huge mess that the DOM is globally mutable. | 21:27:00 |
| ljharb | that doesn't mean a better alternative currently exists, nor that the DOM should be summarily scrapped | 21:27:15 |
 Ashley Claymore | In reply to @stephenbelanger:matrix.org
Ah, I don't have the full context on the scheduler part of the conversation, but async context on its own is certainly not global. Definitely agreed global state is not great. There is a 4 part series of ses analyzing AsyncContext on YouTube. The final conclusion is that it's OK 😀 | 21:29:05 |
| Ashley Claymore | Also 👋🏻 welcome! | 21:29:29 |
 Stephen Belanger | Okay in the state it is today...which has some problems for tracing purposes. 😅 | 21:29:54 |
| Stephen Belanger | But that's a whole can of worms I've already opened in the AsyncContext channel. | 21:30:32 |
| Stephen Belanger | Would you happen to have the link to those videos though? I've seen what I presume is the corresponding github repo where some analysis happened, but could use more context on exactly what their analysis was of the model. Context management has basically been my entire job for half a decade now, so I have a whole lot of...context...in my head about the problem. 😅 | 21:34:23 |
| Stephen Belanger | Ah, is this the first? https://www.youtube.com/watch?v=vECr5IDJzpg | 21:35:29 |
 Mathieu Hofman | The Web has indeed a few design flaws. What seems unfortunate is that it seems acceptable to justify the addition of similar flaws just because of these historical ones. JS on its own however does not have any problems of observable internal mutable state today. "internal" is specifically there to address the fact that the global properties and other language intrinsics are not frozen. | 21:36:33 |
| Andreu Botella | The W3C has a concept called priority of constituencies, used for designing APIs and determining how to solve problems, and it puts the needs of users (of the web) at the top, followed by the needs of authors (i.e. web developers)... with ideological purity being at the bottom. And I see the principle of avoiding observable global mutable state as an ideological purity concern, way below the use cases authors might have. | 21:41:26 |
| Andreu Botella | That said, I can see how global mutable state can affect authors. But then we'd have to see how a particular API that adds global mutable state might make things harder for authors, and whether it might outweigh the needs for the API itself. That is a discussion I don't have enough context for, but it has to be discussed in those terms, not in terms of ideological purity. | 21:41:36 |
| Andreu Botella | * That said, I can see how global mutable state can affect authors. But then we'd have to see how a particular API that adds global mutable state might make things harder for authors, and whether it might outweigh the needs for the API itself. For scheduler.yield, that is a discussion I don't have enough context for, but IMO it'd have to be discussed in those terms, not in terms of ideological purity. | 21:43:55 |
 bakkot |
And I see the principle of avoiding observable global mutable state as an ideological purity concern, way below the use cases authors might have.
I think this attitude from web platform people is part of the reason that so much of the web is such a painful experience. it's not an ideological purity concern. it's a reasoning about code concern: the point is that it makes it easier to avoid bugs, which is directly to the benefit of users.
| 21:45:26 |
| bakkot | now, in any particular case it may or may not be warranted, depending on the details. but when discussing API design, dismissing "code should be easy to reason about" as being at the bottom of the hierarchy of constituencies does real and direct harm to users. people should stop that. | 21:47:50 |
| bakkot | * now, in any particular case it may or may not be warranted, depending on the details. but when discussing API design, dismissing "code should be easy to reason about" as being at the bottom of the priority of constituencies does real and direct harm to users. people should stop that. | 21:48:16 |
| Andreu Botella | Anyway, I'm not trying to defend how scheduler.yield works, I'm just trying to see how/if the behavior it has (at least in Chrome behind a flag) could be specable and implementable based on AsyncContext, because if it's not, V8's odds of okaying AsyncContext might drop significantly | 21:52:03 |
 snek | maybe i misunderstood the concern. how would access to the ambient runtime scheduler not be a global | 23:11:50 |
| snek | oh that was meant to be a reply... Mathieu Hofman | 23:13:20 |
| Mathieu Hofman | this is a loaded question. Pushing a task on a scheduling queue does not allow independent tasks to observe each other. After all we allow that at a lower level through Promise.prototype.then. So there is global mutable state (the scheduling queue), but it's not observable. The problem is with making some of that state observable. An obvious case would be letting user code ask the question "is there anything remaining on the global queue?". But there are more subtle cases: letting the spawner of the task ambiently communicate with the running task is effectively global mutable state being observed too. One way to make that explicit would be to require a shared reference between the spawner and the task, for example an instance of Scheduler, or simply letting the code plumb the abort signal on its own through an AsyncContext variable it creates. The latter would actually let it retrieve the signal and propagate it to other API calls such as fetch. | 23:28:40 |
| snek | hmm. all web code is kind of within a shared goal though i think... like there's a webpage with a viewport, and the browser wants to render it effectively, and all the code for the webpage presumably also wants the page to be rendered effectively. if you require all code to explicitly pass this info around, its less effective. and if you imagine every bit of code 100% proactively updated to support an explicit scheduler argument, isn't that just equiv to a global? | 23:33:25 |
| snek | well, if you're trying to defend against malevolent code, i can understand how its not equiv to a global. but the discussion above didn't seem like it was about that | 23:35:14 |
| snek | * well, if you're trying to defend against malevolent code, i can understand how its not equiv to a global. but the discussion above didn't seem like it was about that, but rather avoiding bugs. | 23:35:42 |
| 19 Jul 2024 |
|  littledan invited  modderme123. | 17:45:46 |
| 20 Jul 2024 |
| modderme123 joined the room. | 01:04:56 |
| 24 Jul 2024 |
|  jasew joined the room. | 21:23:57 |
| 26 Jul 2024 |
 sirisian | When do you think import attributes for type: "text" will be supported? | 16:42:57 |
 ptomato | I'm not aware of any existing proposal for a type: 'text' import attribute, only type: 'json' | 21:31:06 |
| sirisian | yeah I noticed that. I can see references to it in discussions, but no follow-up. Not sure if it's contentious as json was added quickly. Perhaps the encoding complicated it. | 22:36:01 |
