Thoughts on globalThis vs window?

[bpevs]

Wondering if it makes sense to use globalThis for adapters (maybe like (window || globalThis).localStorage) kind of situation? My specific use case is that window global is not available in Deno 2, but afaik this is also applicable to a few other non-browser js contexts.

Not sure if usage of window here is primarily because of better legacy support, or if you are specifically trying to signal that usage should be in a browser context (since I guess the opening to more environments could also open adapters to more compat confusion).

[getify]

thanks for raising this question.

I hadn't even considered this library being used in non-browsers, since those environments almost always have their own facilities for storage in the filesystem. I'm not at all familiar with how many of the browser-style storage mechanisms have been added to these environments? Which of these adapters would work, in say Deno 2?

as to whether it's worth extending support to those environments, I'd say it's a function of how much effort it is to work around any differences, versus the use-case benefits. can you say more about how you're intending to use it, and why this library is beneficial over deno's filesystem APIs?

[bpevs]

So of the adapters, I think Deno only supports localStorage and sessionStorage (but, frankly... didn't know it supported sessionStorage. I have no idea what a session even is in this context).

I think the only difference is window.xxx vs globalThis.xxx, so change is minimal.

However, use-case benefits is a bit more sketchy 😂, since I think fs is pretty much always the "correct" solution. But there's basically 2 things I'd reach for localStorage for in that context:

1. I tend to use Deno for scripts, where my mood is best described as "can't be bothered", and these browser apis are great for that.
2. Building state machines that are intended to be used in scripts, but also in web-apps.

BYOJS is mainly attractive for the 2nd. I can build around the api you've defined, and pop-in other custom adapters in the future (Deno fs, or Tauri fs, or chrome.storage, etc). localStorage just happens to be the easiest thing to prototype on / do basic unit testing, since it's supported in both Deno and browser. But for example, I'm have a flashcard scheduling app, and this can let me easily run it in my cli with localStorage, while also using idb for the pwa, with no extra work. And then I can procrastinate a little longer on the fs solution. 😂

But if you were to push me on it, I'd admit it's definitely more convenient than important. Since other solutions are certainly more proper. Mostly just made an issue because of the minimal surface area, and I'm not sure if there are other contexts with some kind of storage that may find globalThis useful (do web-workers have any of these mechanisms?).

[getify]

I wouldn't mind switching to globalThis if it allows the library to work in those other environments. I'm not trying to actively discourage that type of usage.

OTOH, I am not wild about extending any "official" support of those environments, as it significantly increases the testing surface area. So I'd be slightly worried that opening this up sorta implies support. Perhaps that's as easy to "fix" as adding a note to the README to explicitly disclaim any support beyond the browser.

would you care to add a PR here for switching to globalThis and a note in the README?