You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's worth thinking a bit about how we could extend the JS APIs in the future to work in workers. Obviously they don't work as-is because we don't have Node and friends.
What would be ideal here is convincing ourselves either that:
The current API is basically compatible with being put in workers, if we solve the underlying issues around DOM trees. (For example, if we had an opaque WorkerNode type which could only be used via a worker version of DOMWritable.)
A worker-based API is so different that it doesn't impact this API much at all. For example, it would be primarily string-based.
I'm not sure how much closure we'll get here, but it's worth considering and giving a good think.
The text was updated successfully, but these errors were encountered:
We could replace Node with { tagName: string, attrs: Map }. The tricky bit is how to reference nodes which appear in the stream twice. One way would be to make the object ===, but you'd lose that if you transfer the stream, which might be a gotcha.
It's worth thinking a bit about how we could extend the JS APIs in the future to work in workers. Obviously they don't work as-is because we don't have
Node
and friends.What would be ideal here is convincing ourselves either that:
The current API is basically compatible with being put in workers, if we solve the underlying issues around DOM trees. (For example, if we had an opaque
WorkerNode
type which could only be used via a worker version ofDOMWritable
.)A worker-based API is so different that it doesn't impact this API much at all. For example, it would be primarily string-based.
I'm not sure how much closure we'll get here, but it's worth considering and giving a good think.
The text was updated successfully, but these errors were encountered: