tinycoi

[jcbhmr]

I don't know if this is "library" enough for @tinylibs, but an idea that I would be willing to spearhead is a "tiny service worker to enable client-side cross-origin isolation" to let GitHub Pages and other no-header webpages use SharedArrayBuffer and friends. Basically a zero-config no-effort service worker that adds Cross-Origin-* headers to most requests

There's already an existing project https://github.com/gzuidhof/coi-serviceworker, but it seems a bit outdated. If the maintainer @gzuidhof is still maintaining the project, then it'd probably be better to just improve the existing project rather than start a new one.

In particular, these are some of mine and others' pain points with the current https://github.com/gzuidhof/coi-serviceworker version:

• Lack of "if you can, don't use this" for Vercel or Netlify or other you-have-the-server apps disclaimer
• Uncaught TypeError: Cannot read properties of null (reading 'src') gzuidhof/coi-serviceworker#12 window.document.currentScript is null error in gh-pages gzuidhof/coi-serviceworker#11
• Not really a good way to compose it with other service workers fix this for use with a vite plugin pwa gzuidhof/coi-serviceworker#10 related?
• doesn't work with esm imports, only <script> tag
• page flashes when reloading
• subsuquent code still runs so JS is run twice on first load: once with no crossOriginIsolated once with serviceworker+crossOriginIsolated.

Basically, I want to improve it 😊

Here's some ideas of what using this fictitious tinycoi lib/app/utility/helper might look like:

idea 1. pretty much same as existing, just ESM

<script type="module">
  // Uses top-level await to block until 100% sure that crossOriginIsolated is true
  // reload page once registered sw (all code in one file same as existing project?)
  // If !crossOriginIsolated, then register ./tinycoi.min.js as a SW
  // THROW ERROR if loaded from non-same-domain (can't register cdn.com/sw.js as a SW)
  // Use the same trick as https://github.com/gzuidhof/coi-serviceworker to bundle 2x code into 1x file
  import "./tinycoi.min.js"
  console.log(new SharedArrayBuffer(10));
</script>
<canvas id="canvas"></canvas>

idea 2. use <plaintext>/<template> + document.documentElement.hidden trick to hide everything behind a loading spinner until service worker registered

<!-- must be same-origin same as idea 1 -->
<script src="tinycoi.js"></script><plaintext>
<script type="module">
  console.log(new SharedArrayBuffer(10));
</script>

idea 3. insert some code via a bundler! can combine with idea 1 or 2

import { defineConfig } from "vite"
import tinycoi from "tinycoi/vite"
// or use https://github.com/unjs/unplugin or a separate vite-plugin-tinycoi idk

export default defineConfig({
  // Makes headers in dev server be Cross-Origin-* stuff
  // for build: IF NO SW from vite-plugin-pwa, then add a sw.js and <script> tag to register it
  // for build: IF YES SW then do nothing and expect user's sw.js to import "tinycoi" manually.
  plugins: [tinycoi()]
})

Context (why I'm interested in improving the existing solution): I want to be able to show off SharedArrayBuffer-dependent benchmarks for tinylet using tinybench in GitHub Pages and/or on my localhost:3000 server without much confiuration

TLDR: is the https://github.com/gzuidhof/coi-serviceworker still maintained? if not, is this @tinylibs org's mission a good match with this project, or should this tinycoi project live under @jcbhmr or somewhere else? Now that I actually look at the text I just wrote, I think best option is for @jcbhmr to make something and then transfer it to @tinylibs once it works? Is that the kind of workflow you want #3 ? idk

[Aslemammad]

Neat idea, if it's not maintained or you have extra ideas (I liked those ideas, good to have them all in a minimal way). then let me know so I can create the repo for you as tinycoi.

Thank you so much, I'm looking forward to this project. I'd need it in some places.

[Aslemammad]

@userquin Maybe you'd be interested in discussing this since you're working on vite-plugin-pwa.

[gzuidhof]

Hi @jcbhmr,

I don't know what gave you the impression that the library is unmaintained. I would propose to first aim to improve the existing project before forking. I am happy to accept pull requests that improve on it.

The project is definitely minimal, but that is very much on purpose: I imagine most people's usecase is to quickly add it to their HTML page in Github Pages and be done with it - it suffices for that.

On the pain points:

• The two linked issues are those using the script in unsupported ways. I left them open because perhaps there can be a better notice in the README that explains where it can be used.

As for the improvements:

• Top level await only has browser support since 2021 or so. If it can be avoided for the next few years I would. It's important to remember that some devices literally can not update their browser (older iPhones, the Safari version is tied to the OS version.
• ESM support could be added, happy to accept a PR. Maybe instead of a top level await, it could throw an exception (or return a promise). It could look like this:

      import {coi} from "coi-serviceworker"
  
      coi.promise.then( () => { /* code that uses SharedArrayBuffer */}).except(e => {console.log("not available yet") })
      // or, in async style
      (async () => {
          try{
            await coi.promise
              // Use SharedArrayBuffer
          } catch (e) {
              // Reload imminent? Or reload manually? tbd 
          }
       })()

• As for composability and hiding content: I would say it would be good to provide a way to do that yourself, but such a library should not do it itself. I imagine with the above Promise version, you could hide it in the .catch() handler

I hope that is useful feedback - I would propose to make issues in coi-serviceworker (I personally believe that should've been the first step anyhow).

[jcbhmr]

I don't know what gave you the impression that the library is unmaintained.

@gzuidhof Sorry! 🤦‍♂️ When I looked on GitHub it said "one year ago" for the last commit. I didn't dig into any of the other tabs' dates. My bad.

I would propose to first aim to improve the existing project before forking. I am happy to accept pull requests that improve on it.

That's actually why I created this Discussion! ❤️ I wanted to see if it was still maintained and also ask about a potential org-home for my fork of it if it wasn't. I'd say both those questions were answered. 👍

As for PRs to improve it, I don't know how much you're gonna like my ideas given that you state "The project is definitely minimal, but that is very much on purpose:" 🤷‍♂️ we'll see!

---

I think that TLA isn't likely to be much of an issue because it looks like the compat of SharedArrayBuffer (the main draw of cross-origin isolation) is available only if TLA is also available.

https://caniuse.com/mdn-javascript_operators_await_top_level
https://caniuse.com/sharedarraybuffer

The only exceptions where SharedArrayBuffer could be accessed with COI but without TLA are Firefox 79-89. All other spots either don't require COI to access SharedArrayBuffer or else don't require TLA. Am I reading that right? 🤔

Either way it turns out it wasn't actually that critical to have TLA! 😊 The only spot it's really useful is places like this:

import tinycoi from "tinycoi/window.js";

console.log("before", crossOriginIsolated);
await tinycoi(
  // https://vite-pwa-org.netlify.app/guide/service-worker-without-pwa-capabilities.html#registering-of-the-service-worker-in-your-app
  navigator.serviceWorker.register(
    import.meta.env.MODE === "production" ? "/sw.js" : "/dev-sw.js?dev-sw",
    { type: import.meta.env.MODE === "production" ? "classic" : "module" }
  )
);
console.log("after", crossOriginIsolated);

message.innerText = crossOriginIsolated ? "✅" : "❌";

sidenote: cool Vite plugin to enable a TLA-like shim for non-TLA browsers https://github.com/Menci/vite-plugin-top-level-await

---

The project is definitely minimal, but that is very much on purpose: I imagine most people's usecase is to quickly add it to their HTML page in Github Pages and be done with it - it suffices for that.

That's kinda my current gripe lmao 🤣 is that the code runs twice which really threw me for a loop.

As for composability and hiding content: I would say it would be good to provide a way to do that yourself, but such a library should not do it itself. I imagine with the above Promise version, you could hide it in the .catch() handler

Since this coi-serviceworker package is very obviously attempting to be a <script> tag drop in, I think it actually makes sense in the reverse to hide content by default. It's the "path of least surprise" to not double render. I think an opt-out option would be good though, yes.

For the composability, I think it's worth the complexity/effort. In essence, you're pulling out the assumptions like "the service worker file is the document.currentScript.src" and putting those in the hands of users. Particularily for combining the current coi-serviceworker package with an existing service worker, it's not very friendly. I think that could be made better.

---

I hope that is useful feedback - I would propose to make issues in coi-serviceworker (I personally believe that should've been the first step anyhow).

Regarding the "is this maintained?" question, yeah. You're right.

IDK what the etiquette is for project scope expansion requests though; that's kinda in essence what this boils down to:
I want to expand the scope of coi-serviceworkers. Should I contribute my ideas back to the original, or is the original deliberately simplistic?

[jcbhmr]

Since it seems like things are happening in https://github.com/gzuidhof/coi-serviceworker, I think my idea here has been rendered redundant! 😊 Yes! This was the best outcome: improve the existing project.