Both of these demos show how a dedicated Worker can be used to handle requests from multiple tabs/windows, instead of a SharedWorker which may not support certain APIs (such as synchronous OPFS). The details are discussedhere.

The original implementation and demo does use a SharedWorker to set up communications to the shared Worker. This satisfies the goal of allowing the use of APIs that require a Worker. However, using SharedWorker at all, even in this much smaller role, means that it won't work on Android Chrome which still doesn't support SharedWorker. Fortunately, it turns out that the setup role can also be handled with a service worker, whichis supported on all modern browsers (including Android Chrome). So that's the difference: SharedService-sw performs setup with a service worker, eliminating the use of SharedWorker entirely.

The SharedService idea has drawn interest for use cases outside this project, but it was originally created to show how AccessHandlePoolVFS could be used from multiple tabs despite allowing only one connection at a time. There is now another example VFS, OPFSCoopSyncVFS (discussedhere), that works similarly to AccessHandlePoolVFS but supports multiple connections so it doesn't need something like SharedService. Anyone considering a SharedService approach to use AccessHandlePoolVFS from multiple tabs should check out OPFSCoopSyncVFS as an alternative.