Re: [w3c/ServiceWorker] Mixed feelings about ServiceWorker for module loader (#1203)

@GrosSacASac I haven't tried that, but I'm not sure where that would leave the actual fetch response. I guess I could have the response be empty with a no-cache header? Because otherwise, it would still arrive in the main thread and arrive twice.

I'm also not sure whether there is a performance overhead in sending all that data across threads.

Also, I was hoping that any solution involving ServiceWorker would also involve an improvement (not a regression) in debug-ability. E.g. where each logical resource would get its own entry in the Network panel. That would be an improvement. Right now I can sort-of get it by adding `//#sourceURL=` to the end of the eval string, but that only works if I eval each script separately, which I found to be significantly slower than running them all at once.

Ideally there'd be a way to both combine chunks (or otherwise avoid the performance penalty), but also stop executing when it takes too long. E.g. a way of combining a batch-eval with requestIdleCallback deadline, or some such. I was hoping that if I leave eval behind me and give control back to the browser through normal HTTP responses (via SW), that it would "Do the right thing". It would certainly allow the browser to start parsing the JavaScript code off-thread as soon as it has it, because it would know what its purpose would be before I trigger execution.

Although I don't know of any browser actually does that. And also, I suppose in a way it might not be certain of it because until I stitch the responses together, it could end up being used for something else, or the header changed to `text/plain`. And also, technically, combing responses can change the meaning of the script, so that won't be re-used either.

I suppose for the parse optimisation, it would need to be separate requests from the main thread, not just separate requests in SW.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1203#issuecomment-347620485

Received on Tuesday, 28 November 2017 18:35:33 UTC