Quantcast
Channel: Node.jsタグが付けられた新着記事 - Qiita
Viewing all articles
Browse latest Browse all 8902

Denoの登場でNode.jsの時代は終わるのか?

$
0
0

Deno ver 1.0

5月13日、Deno v1.0の正式リリースが決定しました。
少し勉強してみましょう。

image.png

↑ かわいい

Denoってなに?

  • DenoはNode.jsの製作者であるRyan Dahlによって作られました、新しいJS/TSランタイムです
  • Denoはdefaultで安全です(許可なしではファイル・ネットワーク・環境にアクセスできません)
  • DenoはTypeScriptがビルトインで入ってます
  • 外部パッケージはurlでインポートできます(Goみたいに)
  • ディーノって読むらしい(デノではない)

Denoが作られた背景

一年前くらいにこの動画を見たことを思い出しました。
Node.jsの作者であるRyan Dahlが、Node.jsを開発した当時の仕様を後悔する旨の動画です。
image.png
https://www.youtube.com/watch?v=M3BM9TB-8yA&t=1319s

↓は要約です。(日本語がおかしいところが多々あると思いますが、ご了承ください)

後悔その1: Promiseの排除

  • 2009年、Node.jsにPromiseを足したけど、バカなことに2010年に消した
  • Promiseはasync/awaitのために必要な抽象化である
  • NodeでのPromiseの統一された使用が、最終的には標準化したasync/awaitにつながった可能性がある
  • 今日、Nodeの多くの非同期APIは、このせいでとっても古い書き方になっている

後悔その2: 安全性(Security)

  • V8それ自体は非常に優れたセキュリティサンドボックス
  • もし自分が、特定のアプリケーションでそれをどのように維持するか考慮していたなら、Nodeは他の言語より素敵なセキュリティ保証を持てたかもしれない
  • 例: linterがパソコンやネットワークに完全なアクセス権をもっている

後悔その3: ビルドシステム (GYP)

  • ビルドシステムはとても難しい・重要
  • V8 (Chrome) がGYPを使い始めたので、Nodeもそれを使うようにした
  • 後で、ChromeはGYPをGNに切り替え、Nodeは一人GYPユーザーとして残ってしまった
  • GYPも醜い内部インターフェースではない-V8にバインドしようとしている人に公開されている
  • しかし、ユーザーにとってはひどいUXである。JSONではなく、PythonのJSON Adaption
  • 継続されたGYPの使用が、Node coreの最も大きい失敗である
  • 多くの人々は早い段階でFFI(つまりCantrill)への移行を提案したが、残念ながら私はそれらを無視してしまった

後悔その4: package.json

 * NPMのIsaacが、package.jsonの大部分を作った
 * しかし、私はNodeのrequire()が "main"のpackage.jsonファイルを検査できるようにして、それを認可した
 * 最終的にNPMをNodeディストリビューションに含め、それが事実上の標準になった
 * モジュール用の集中管理されたリポジトリがあるのは残念なことだ
 * package.jsonを許可することで、ファイルのディレクトリとしての「モジュール」の概念が生まれた
 * これは厳密にいうと、必要な抽象化ではない
 * package.jsonにあらゆる種類の不要な情報が含まれることになった。License? Repository? Description?それは定型的なノイズです。
 * インポート時に相対ファイルとURLのみが使用された場合、パスがバージョンを定義するので、Dependenciesをリストする必要はない

後悔その5: node_modules

  • node_modulesはモジュール解決アルゴリズムを非常に複雑にした
  • vendored-by-defaultは良い意図を持っているが、実際には$NODE_PATHを使用するだけではそれを排除することはできなかった
  • ブラウザのセマンティクスから大きく逸脱している
  • 私のせいで、とても残念な気持ち
  • しかし、不幸にもこれをundoすることはできない

後悔その6: ".js"の拡張子なしでのrequire("module")

  • 不必要に明示的でない
  • BrowserのJavaScriptが動く方式ではない。scriptタグのsrcアトリビュートで".js"を省略することはできない
  • module loaderは、ユーザーの意図を推測するために、複数の場所でファイルシステムを照会する必要がある

後悔その7: index.js

  • index.htmlなどがあったため、かわいいと思っていた
  • module loadingシステムを不必要に複雑にしてしまった
  • requireがpackage.jsonをサポートするようになった後はより不必要になってしまった

DenoのFeature

トップレベルAwait

もうawaitを使いたいがためにasyncの関数で囲う必要はありません。

index.js
// NodeconstfetchData=async()=>awaitfetch('someapi/data');constdata=fetchData();// Denoconstdata=awaitfetch('someapi/data');

セキュリティ

上でも何回か述べてるように、Denoでは許可なしでファイル・ネットワーク・環境にアクセスできません。

TypeScriptビルトイン

TypeScriptのセットアップは不要です。

URLインポート

NPMパッケージをインストールしなくても、URLで importできます。

index.js
importstufffrom'https://package/index.js';

ES6とそれ以上

モダンなJSの書き方が可能です。

Webとの適合性

DenoのAPIはWebとの適合性があります。
image.png

Web Assembly

DenoはWASMバイナリーのサポートがあるようです。

DenoはNodeをReplaceできるのか?

遠い未来はその可能性は高いと個人的には思ってます。(製作者自身がNode.jsの欠点を認めて作り直したランタイムなので)
しかし現在のNodeプロジェクトをDenoに乗り換えることはまずないのではないかと思います。
乗り換えにそこまで大きいメリットがないのと、現状のNPMパッケージとの適合性がないためです。

すぐデファクトになることはないと思いますが、Web開発者なら少し触れてみても面白そうです。

https://deno.land/


Viewing all articles
Browse latest Browse all 8902

Trending Articles