Node.js や deno に Web Standard な API をなんでも取り入れるのが良いことなのかについて - from scratch

この記事は Node.js Advent Calendar の 11 日目の記事です。 qiita.com Web API と Node.js ES2015 以前の Node.js は Web Standard な API の中で足りないものを自分で補う形で進化を続けてきた。 Callback や Event 主体での非同期処理や Common JS な形でロードできる独自のモジュールの仕組みがその筆頭だと思う。ただ逆に Web Standard な API が流行ると今度はそれに追従していかないといけなくなってきた。 ES2015 以後に流行ったものといえば、 Promise 主体での非同期処理であり、 async-await での処理だと思う。また、 ES Modules の台頭もあり、今日では Node.js でも普通に呼び出すことが可能になった。 今ではどちらも Node.js で

[kako-jun]

こち亀で向かいの競合店との勝負がエスカレートして、だんだん何の店か分からなくなってく話に似てる……

[kobito19]

「漏れのある抽象化」の一形態やな

[ledsun]

fetchがなかなか入らないと思ったら、nodeに要らない機能が仕様に含まれているのか。fetchのAPIだけ覚えればよくなるかと思ってたけど、なかなかそうはならないんだなあ

[torinashisatoko]

Buffer.from(mojiretsu, "base64") したときにあれれ？と思ったので読んでみたら面白かった．atob はパッと見わからない Bad Parts かもしれないな

[takashiski]

難しい話だ

[t2wave]

“Node.js / deno が Web Standard API に追従する状況は現在でも続いている。ただし、最近は若干やりすぎなのではないかというか、本当に必要なのか？と思うようなものまで入っているし、検討されている気がする。”

[ducktoon]

atob btoa は名前からしてダメなのでブラウザからも抹消して欲しい

[otoan52]

たしかになー。fetch互換のAPIは必要だと思うけど、Originどこよと聞かれるとなやむ。localhostだと実行環境でhttpサーバが立ってたら適切じゃないし…。標準側がサーバサイドを意識するのが一番だろうけど、そこまでなぁ…

[el-condor]

nodejsとかの最大のメリットをブラウザとほぼ同等のツールセットが使えることにあると考えるなら実装すべき、というだけの話では。個人的には、それ以外の理由でnodejsを選択する理由は思いつかないのだが。

[programmablekinoko]

Node.jsはchromeのV8の成果をそのまま取り入れているので仕方ない部分があるんだろうか

[ms2sato]

個人的にはfetchは実現して欲しいので、基本仕様と拡張仕様のような形でブラウザのみに必要な機能を分離する考え方が良さそうに感じました。基本仕様に従うのは必須、拡張はオプションな感じ。

[noname774300]

"DO NOT USE THEM" って言う機能を実装するってすごいなあ。

[tacamula]

“基本的にブラウザのセキュリティモデルとサーバサイドで動くことが基本のプラットフォームとは同じ感覚で考えすぎるのは良くないと思っている”

[mizdra]

良い

[remonoil]

互換fetchはいらないんだけどfetch的な何かは欲しい

[latena]

ライブラリ作者がブラウザーも Node.js も deno もサポートしたいとき同じ API が使えるの便利。ライブラリ利用側が package.json の browser フィールドとかモジュールバンドラーの設定とかで解決しなきゃいけないのどうにかして

[pwatermark]

入れることによるメリットとデメリットを考えると、「後で発生するかもしれない苦労を受容できるなら、まあ頑張れ」としか nodeとdenoの意地の張り合いみたいな理由であれば、それはやめて欲しいね