Hacker News new | ask | show | jobs
by giaour 1553 days 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.
1 comments
bigrightmiss 1553 days ago
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.
link
giaour 1553 days ago
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)

link
bigrightmiss 1553 days ago
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

link