10 ms·
Very cool! I wonder how they get around all of the “window” related APIs. I imagine you can pollyfill some of them but I would expect some random bugs here and
by todd3834 4y ago
Very cool! I wonder how they get around all of the “window” related APIs. I imagine you can pollyfill some of them but I would expect some random bugs here and there? I hope I’m wrong because this is otherwise great.
This should also be something that providers of 3rd party scripts should take notice of when developing. Why not design to be in a web worker from the start if you can…
- kevincox 4y agoMy impression is that the "default" approach is not to pollyfill but proxy the calls to the main thread. They have a post about how they are (ab)using synchronous XMLHttpRequest calls to block the worker while proxying the request to the main process with postMessage https://dev.to/adamdbradley/how-partytown-s-sync-communication-works-4244 https://dev.to/adamdbradley/how-partytown-s-sync-communicati.... I suspect that you may want to pollyfill APIs for performance but I think for many use cases just that shim to the true API should work well enough.
- earthboundkid 4y agoIt’s a truly evil genius hack. XHR has a legacy synchronous API. So what they do is make a fake window object and any time something touches it, they do an async call out to the real window, but they make it look synchronous by doing the call via XHR to itself. Such a crazy hack!