[OscarDC]

> Service workers are like adding extra threads when running JS in your browser. People use them in client-side web app code to get around the single-threadedmess of JavaScript. [...]

Aren't you just describing workers in general here (without the "service" part)?

To me "Service Workers" is a worker purposed especially for proxyfying requests made by the client, on the client, and act upon it (example: by returning a version cached by the js). The main use-case I've seen is implementing an offline mode.

When you just want to unlock multi-threading capabilities in JavaScript, you just rely on "WebWorkers" another worker mechanism without the proxy part, I've never seen those referred as "Service Workers".

With that written, I don't get what Service Workers have to do being on the server-side though :/

[TimTheTinker]

Thanks, that was a total brain fart on my part.

> I don't get what Service Workers have to do being on the server-side though

Yeah, this is extremely confusing. Other posts talk about running your own CloudFlare workers... but I fail to see any potential connection between service workers and code that executes on edge nodes.

EDIT: Here's an example "service worker" on wasmer: https://github.com/wasmerio/js-service-worker-example/blob/m...

I think they're calling these edge workers "service workers" which is an unfortunate name as it clashes with the name of the Service Worker web API. This is just some JS running under a reduced set of runtime APIs (vs Node or the browser).

Also I think the project's goal is to extend the Wasmer platform (which appears to have the limitation of only running WASM assemblies) with the ability to run JS workers. Hence the need for a JS interpreter and runtime compiled to WASM.