[mediumdeviation]

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]

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]

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.

[bigrightmiss]

if i have to think about what the browser-equivalent operation would be when i'm working with a server-side API, i'm going to use a different language entirely.

[giaour]

Sure, but then why would you use Javascript in the first place? The situation deno is trying to address is that JS developers need to memorize two standard libraries, one for browsers and one for node. You should be able to work with one standard library like you can in most other languages.

The first attempt at this was to port the node standard library to the browser via browserify and the like. This tended to create gigantic JS build artifacts and frequently led to runtime errors when developers used an abstraction that just had no equivalent in the browser (like saving something to disk or opening a separate process). The browser is definitely the lowest common denominator of JS runtimes, even if there are a few browser APIs that just don't make sense in a server environment (like window.history)

[bigrightmiss]

im all for standardizing overlapping functionality, but not standardizing just for the sake of it.

node 17 is bringing the fetch api to core which to me makes perfect sense. theres definitely no point in node creating their own version of fetch. and fetch is useful on both the browser and server, given that fetch is an easy way to facilitate a client-server connection over http/s. perhaps the same applies to window.crypto.

i think you start to lose the benefit of standardization when: 1. half the api gets repurposed to try to fit a (in some cases, completely subjective) counterpart 2. functionality isn't 1:1