top | item 30704855

(no title)

treyhuffine | 4 years ago

A lot of the time that pattern is written, it's because the APIs from the web and Node are different and will break if you call something that's not isomorphic. Perhaps Deno fixes that as well and the pattern isn't needed in the first place. Obviously not every case though.

discuss

order

deckard1|4 years ago

In my experience, I've never seen that used just because the API is different. There are polyfills for fetch and other things, to align node and the browser. When I've seen that check, it's been entirely because the DOM API was needed. Or fetching was required on the client-side only.

mediumdeviation|4 years ago

I'm surprised nobody else has called this out - implementing browser APIs in a non-browser runtime seems like a really bad idea. Take a look at https://developer.mozilla.org/en-US/docs/Web/API/Window - the submitted article seem to have demonstrated literally the only APIs that make sense to implement in a terminal. What would happen when a library tries to call window.location or window.history? Almost none of these map neatly to any possible implementation on the server or in a scripting environment.

sjnu|4 years ago

Do you have a reasonable example of why a library that would call location or history?

All I can think of is "using query string as getenv() for random debug hacks" or "using history as a hack to synchronously reach the structured clone algorithm", neither of which a library should do (but both easily emulatable).

giaour|4 years ago

window.location could be repurposed as a way to get or change the current working directory? Though the idiom of "window.location = <other path>" as a navigation mechanism would not really be portable.

That said, there are other browser APIs that I would love to see available elsewhere:

- window.crypto as an interface over libcrypto

- window.localStorage and window.sessionStorage as an abstraction over temporary files and an in-memory key/value store, respectively

- window.indexedDb for an in-runtime DB à la Erlang Term Storage or MUMPS

- window.opener, window.parent, window.open(), window.postMessage() for inter-process communication

There's a lot to work with here if you get creative.