4 ms·

> Deno has much higher browser compat. Is this a fact or a personal feeling? Any links to back up this statement?

lucacasonato 5y ago
This is a fact. Import maps, fetch, ESM + web import semantics, localstorage, WebGPU, WHATWG streams, WebCrypto. Deno runs the shared web platform test suite: https://deno.co/wptfyi https://deno.co/wptfyi. You can also just look on MDN now and see which APIs are implemented in Deno compared to Node :-)
- timdaub 5y ago
  Is import maps considered an accepted proposal [1]? What's the point of implementing APIs like WebGPU and localstorage in a non-browser environment? I get WHATWG streams, esm, fetch and WebCrypro though. - 1: https://github.com/WICG/import-maps https://github.com/WICG/import-maps
  - vorticalbox 5y ago
    Local storage let's you save state across process restarts and session storage let's you share data across worker threads You could save the state of a discord bot across restarts for example.
  - norman784 5y ago
    About webgpu > The WebGPU API gives developers a low level, high performance, cross architecture way to program GPU hardware from JavaScript. > GPUs allow programmers to make some numerical algorithms highly parallel. This is useful beyond rendering graphics and games. Effective use of GPUs in Machine Learning has enabled more complex neural networks - https://deno.com/blog/v1.8#experimental-support-for-the-webgpu-api https://deno.com/blog/v1.8#experimental-support-for-the-webg...
  - tehbeard 5y ago
    Implementing WebGPU allows you to make use of GPU resources on the server (from rendering to more compute focused) Localstorage is admittedly a bit niche, but works well as a way to bypass the need to get generic read/write permissions for the filesystem for a config file. (Deno implements a permission model similar to the web where you start with nothing and must request / have pre-granted access to resources like files/network/env/subprocess, and this access can be granular to specific files/directories/host+port combos)
lucideer 5y ago
The sibling commenter covered the list well. To go into a little extra context on the reasoning: fetch: Browser fetch didn't exist when NodeJS introduced its http built-ins. Many NodeJS libs are built on top of http built-ins, so replacing them would be a nightmare. Adding browser fetch on top of the existing http built-ins would similarly just give NodeJS a massive API surface area with cconfusingly duplicated functionality. ESM + web import semantics: NodeJS was part of the "commonjs" movement that invented Javascript module importing. Module imports are an incredibly complex problem and hard to get right. Browsers took the hard-learned lessons from commonjs & nodejs and redesigned better modern APIs. NodeJS has been slowly trying to add support for the much improved browser web import semantics, but doing so while maintaining backward compatibility with their radically different commonjs APIs is a nightmarish challenge (they're working on it though, progress is good). WHATWG streams: similar story to the import/commonjs situation. NodeJS basically "invented" streams in JS, and the WHATWG API is a newer design based on NodeJS lessons. WebCrypto: Sibling comment is incorrect here actually: NodeJS & Deno both support this[0] [0] https://developer.mozilla.org/en-US/docs/Web/API/Crypto https://developer.mozilla.org/en-US/docs/Web/API/Crypto
- timdaub 5y ago
  I use esm in nodejs >= 14 since roughly 6 months and I'm almost back to where I was with CommonJS. Problems that I have: - ESM modules are challenging to mock or monkeypatch - I feel like the ESM implementation is more "magic" than require. I definitely would say I understood require better. - Many esm features are still behind flags e.g. importing a .json file. I'd guess that by the time Deno gets really good, Nodejs achieved same level of compatibility.
  - lucideer 5y ago
    > ESM modules are challenging to mock > I definitely would say I understood require better ESM modules are in many ways "harder" to use than commonjs, but I think this comes down to something slightly intangible but very similar to the static-typing -vs- duck-typing discussion (duck-typing is more obviously intuitive and quick-to-do-what-you want, but static-typing has more wide-reaching architectural benefits for scaling projects). CommonJS is a more "intuitive" design: what you might expect someone to design first-time-around. ESM is a more thought-through design: the initial "hurdles" to its use bring long-term benefits. > ESM modules are challenging to [...] monkeypatch This seems like a feature though > I feel like the ESM implementation is more "magic" than require How so? I'd say I feel the opposite. > importing a .json file Is this supported by browsers or is it a NodeJS extension?

This is a fact. Import maps, fetch, ESM + web import semantics, localstorage, WebGPU, WHATWG streams, WebCrypto. Deno runs the shared web platform test suite: https://deno.co/wptfyi https://deno.co/wptfyi. You can also just look on MDN now and see which APIs are implemented in Deno compared to Node :-)

timdaub 5y ago
Is import maps considered an accepted proposal [1]? What's the point of implementing APIs like WebGPU and localstorage in a non-browser environment? I get WHATWG streams, esm, fetch and WebCrypro though. - 1: https://github.com/WICG/import-maps https://github.com/WICG/import-maps
- vorticalbox 5y ago
  Local storage let's you save state across process restarts and session storage let's you share data across worker threads You could save the state of a discord bot across restarts for example.
- norman784 5y ago
  About webgpu > The WebGPU API gives developers a low level, high performance, cross architecture way to program GPU hardware from JavaScript. > GPUs allow programmers to make some numerical algorithms highly parallel. This is useful beyond rendering graphics and games. Effective use of GPUs in Machine Learning has enabled more complex neural networks - https://deno.com/blog/v1.8#experimental-support-for-the-webgpu-api https://deno.com/blog/v1.8#experimental-support-for-the-webg...
- tehbeard 5y ago
  Implementing WebGPU allows you to make use of GPU resources on the server (from rendering to more compute focused) Localstorage is admittedly a bit niche, but works well as a way to bypass the need to get generic read/write permissions for the filesystem for a config file. (Deno implements a permission model similar to the web where you start with nothing and must request / have pre-granted access to resources like files/network/env/subprocess, and this access can be granular to specific files/directories/host+port combos)

lucideer 5y ago

The sibling commenter covered the list well. To go into a little extra context on the reasoning: fetch: Browser fetch didn't exist when NodeJS introduced its http built-ins. Many NodeJS libs are built on top of http built-ins, so replacing them would be a nightmare. Adding browser fetch on top of the existing http built-ins would similarly just give NodeJS a massive API surface area with cconfusingly duplicated functionality. ESM + web import semantics: NodeJS was part of the "commonjs" movement that invented Javascript module importing. Module imports are an incredibly complex problem and hard to get right. Browsers took the hard-learned lessons from commonjs & nodejs and redesigned better modern APIs. NodeJS has been slowly trying to add support for the much improved browser web import semantics, but doing so while maintaining backward compatibility with their radically different commonjs APIs is a nightmarish challenge (they're working on it though, progress is good). WHATWG streams: similar story to the import/commonjs situation. NodeJS basically "invented" streams in JS, and the WHATWG API is a newer design based on NodeJS lessons. WebCrypto: Sibling comment is incorrect here actually: NodeJS & Deno both support this[0] [0] https://developer.mozilla.org/en-US/docs/Web/API/Crypto https://developer.mozilla.org/en-US/docs/Web/API/Crypto

timdaub 5y ago
I use esm in nodejs >= 14 since roughly 6 months and I'm almost back to where I was with CommonJS. Problems that I have: - ESM modules are challenging to mock or monkeypatch - I feel like the ESM implementation is more "magic" than require. I definitely would say I understood require better. - Many esm features are still behind flags e.g. importing a .json file. I'd guess that by the time Deno gets really good, Nodejs achieved same level of compatibility.
- lucideer 5y ago
  > ESM modules are challenging to mock > I definitely would say I understood require better ESM modules are in many ways "harder" to use than commonjs, but I think this comes down to something slightly intangible but very similar to the static-typing -vs- duck-typing discussion (duck-typing is more obviously intuitive and quick-to-do-what-you want, but static-typing has more wide-reaching architectural benefits for scaling projects). CommonJS is a more "intuitive" design: what you might expect someone to design first-time-around. ESM is a more thought-through design: the initial "hurdles" to its use bring long-term benefits. > ESM modules are challenging to [...] monkeypatch This seems like a feature though > I feel like the ESM implementation is more "magic" than require How so? I'd say I feel the opposite. > importing a .json file Is this supported by browsers or is it a NodeJS extension?