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.
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)
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
giaour|4 years ago
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|4 years ago
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