Hacker News Reader

Comment by stepbeek | Hacker News Reader

This is really cool! Can anyone explain why deno has made it to MDN but node.js has not?

Node is on a number of MDN pages (e.g: [0]). I think it's just APIs that Deno supports and Node doesn't (e.g: fetch) that are linked here, which is why it's not in their support matrices.

0: https://developer.mozilla.org/en-US/docs/Web/API/console/log

setTimeout is linked here, https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWor..., and shows partial support (with explanations) for Node.js.

Also see TextEncoder or WebAssembly which shows the version support of Node.js and others

https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder...

https://developer.mozilla.org/en-US/docs/WebAssembly#browser...

node is on MDN for all browser APIs it implememts, there's just not many of them. Deno has much higher browser compat.

It's worth noting this isn't Node's fault: most Node APIs existed before there were browser equivalents and adding browser compat now is much harder for Node than for Deno which is starting from scratch.

> Deno has much higher browser compat.

Is this a fact or a personal feeling? Any links to back up this statement?

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. You can also just look on MDN now and see which APIs are implemented in Deno compared to Node :-)

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

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.

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-webg...

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)

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

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.

> 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?

> Is this supported by browsers or is it a NodeJS extension?

This is a node extension. It is coming to browsers in form of import assertions. See https://github.com/tc39/proposal-import-assertions

Oh, good to know! I hadn't heard this.

Just for anyone tracking progress, the actual feature proposal is here: https://github.com/tc39/proposal-json-modules - the assertions proposal is just a security check on top of such modules.

nodejs is there as well, ie. [0]. Maybe it's missing for apis they don't provide? ie. fetch [1] does not list nodejs.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

Because Node is the new IE.

I believe it's because Node.js has never made an effort to implement web APIs nor has it been a goal of the project.

Edit: as others have pointed out, APIs that are implemented in Node.js are listed on MDN.

Worth noting, informationally, it is a goal of the Node.js project to implement web APIs. Deno is just way ahead as it doesn't have to worry about backward compat: it's a much tougher challenge for the Node.js guys, but they are working on it.

Reply on news.ycombinator.com