| 22:32 | <styfle> | This is interesting https://jakearchibald.com/2025/importing-vs-fetching-json/ |
| 22:35 | <kriskowal> | It’s interesting insofaras the designers of a thing don’t always precog how the feature will be misused. Great that Jake’s getting ahead of that. |
| 22:37 | <kriskowal> | This is one of the ways that having an out-of-band mapping from import specifier to fully qualified URL is useful at deterring misuse. Using a fully qualified URL for an import is a smell, and ideally wouldn’t even be possible. |
| 22:38 | <kriskowal> | And I mean that objectively, as most applications should at least be able to endure a bundling transformation when they’re sent to production, and cross-domain reliance is always going to be runtime fragility, even if the bundler allows exits to other sites. |
| 23:11 | <guybedford> | I've also been putting some thought to if bytes imports are useful in a Wasm import context, and I think they are - the interesting thing there is if they were hypothetically supported as passive data section imports of Wasm, passive segments do support being dropped after use in initialization to allow for GC. So in theory there could be an application of import bytes for Wasm that is garbage collectable while being maximally useful due to static instantiation. Including this topic in the ESM Integration update at the Wasm CG this week, will share slides with this group after as well. |
| 23:14 | <guybedford> | (of course registry needs to be kept around, although immutable data could in theory be treated as lazy / evicted memory moved to say disk cache if that was optimized for) |
| 23:20 | <kriskowal> | Very interesting observation about import bytes being collectible. That might endure scrutiny. Assuming you’ve got Finalization for the retaining Uint8Array and immutable ArrayBuffer, there’d be no observable loss if the data had to be refetched for a subsequent import. |
| 23:22 | <guybedford> | I wonder if there's a spec enabling way to say that each importer may get their own separate instance of the array buffer object, provided the immutable contents remain the same, instead of treating it as a shared object. In theory an arrayBuffer.transfer() operation could then provide GC support too for JS. |
| 23:23 | <guybedford> | Wonder if worth considering if memory questions come up again? |
| 23:24 | <bakkot> | even with such feature, transfer would only work if these weren't immutable |
| 23:25 | <guybedford> | Ah right, so only mutable support detachment? I guess that thwarts that line of consideration then. |
| 23:28 | <bakkot> | yeah, detaching causes an observable change to the values you get when wrapping the buffer, so it can't be done for immutable buffers |