パスワードを忘れた? アカウント作成
14197580 story
プログラミング

Node.js開発者による新JavaScriptランタイムDeno 1.0がリリース、後継となるか? 21

ストーリー by hylom
パッケージ周りの仕様は実用上どうなのだろう 部門より

Anonymous Coward曰く、

やや旧聞となるが、Node.js開発者のRyan Dahl氏らがNode.jsの反省をもとに開発を進めている新たなJavaScript実行環境「Deno」バージョン1.0が5月13日にリリースされたOSDN MagazineCodeZineQiita)。

DenoはJavaScriptに加えて標準でTypeScriptやWeb Assemblyをサポートするほか、コードがサンドボックスで実行されるなどセキュリティにに配慮した設計となっている。一方で、require()によるパッケージのインポートといった構文は取り除かれ、パッケージマネージャのnpmやパッケージ管理ファイルのpackage.jsonもサポートしないなど、互換性は保持されていない。

開発開始からまだ2年ほどで、現時点ではNode.jsを置き換えることは難しいだろうが、将来的には移行が進むのだろうか? 既に試してみたスラド諸氏が居れば感想など伺いたい。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2020年05月29日 16時08分 (#3824076)

    秋に再アニメ化するほうとはスペルが違うようだ。
    denoはnodeの逆ってことなのかいな?

    • by Anonymous Coward

      Google Chromeのミニゲーム?

    • by Anonymous Coward

      odenの方がおいしそう。

  • by Anonymous Coward on 2020年05月29日 15時10分 (#3824031)

    置き換えはきつくない?
      IPv4からIPv6に移行するようなもんだ。

    • by Meth610 (31617) on 2020年05月29日 15時26分 (#3824046)

      npm未サポートってか、
      npmが完全に不要になる
      が正しい。

      親コメント
      • by Anonymous Coward

        でも、Python3がでてからも、
        Python2が残り続けたり、

        Javascriptからの置き換えを目指したDartが
        復旧しなかったり、

        非互換という壁は高いのでは?

        • by Meth610 (31617) on 2020年05月29日 19時36分 (#3824252)

          置き換えを狙ってるんですかね、これ?そういう文脈の話だったのかな?
          単に別の処理系ってだけだと思うけど。

          開発者には利点も多そうだが、既存のnodejsアプリケーションを書き直すモチベーションはそれとは別個の話というふうに読んでます

          親コメント
          • by Anonymous Coward

            DenoはあくまでYet Another。きっと完成形はDoneですね。

        • by Anonymous Coward

          Dartは仕方ない。
          置き換えを目指したけど、当時のJavaScript以上に時代がかった構文で、JavaScriptよりダサく見えるようなやつだったしな。
          本当にChromeに標準でのっけてしまえば、少しは普及したかもしれんが、Google自身がTypeScriptに鞍替えして、Dartを捨てちゃったからな。

          最近 Flutterでちょっと復活傾向にあったけど、結局Flutterごと消えさりそうだし、、、

    • by Anonymous Coward

      アンチMSの出番が来ましたね。

      • by Anonymous Coward

        npmのリポジトリの代わりにMS様がお持ちのギフハブから直接引っ張ってくるようになる気が(今のnpmでも可能)。逃れられない。

    • by Anonymous Coward

      package.jsonとかコマンドでローカルに持ってくるのじゃなくて、javascript中のimport文でnpmパッケージのURLを書く方式になる。
      書き方が変わるって程度で、使えなくなるわけではない。
      npmの依存がずるずるってのも何も解決されない。

  • by Anonymous Coward on 2020年05月29日 23時00分 (#3824357)

    あたらしい環境はBlazorみたいなのしか要らないでしょ

    • by Anonymous Coward

      WebAssemblyが普及するとでも思ってるのか

      • by Anonymous Coward on 2020年05月30日 1時09分 (#3824404)

        引き合いも着実に増えてるぜ。JavaScriptより数倍速いし、クライアントアプリのWEB化が、JavaScriptとか使うより数倍工数減らせるのが大きい。

        とりあえずって程度のノリで、WASMがどういう物なのかを調べながらでも 2、3日もあればC/C++はもとより、.NET系とかでもデスクトップで動いてるクライアントアプリが、どの程度のパフォーマンス出せるのか試せるしな。
        GUIと不可分な実装してるような奴だと分離が大変かもしれんけど、いまどきの普通の設計してたら気にするほどの手間はかからん。
        製品レベルの作り込みが大変なのは、今と変わらんけど、ロジック部分のコードをJavaScriptで書き換えるどころか、一切手を加えずに、そのまま動くってのは大きいよ。

        メモリ4GBの壁が、けっこう痛いけど。

        親コメント
        • by Anonymous Coward

          WebAssemblyって普通のWebサイトで使い所ある?例えばスラドみたいなの。

          • by Anonymous Coward

            コメント入力のプレビュー表示とか、閾値による表示内容の絞り込みとか、JavaScriptで出来る/JavaScriptで何か入れたいっていう部分は、全てWebAssemblyが使える箇所だよ。
            どっちでやるのが楽か、速度が必要か?って話になるけど、コード量が増える/既存のコードがあるって状態だと数倍単位でWebAssemblyが楽。速度が必要ならWebAssembly一択。

            まぁ、当面の一番大きい用途は、パッケージやダウンロード販売してるようなソフトをSaaS化したいときにUI以外はWEB用に作り直す必要がなくなるってことだろうね。標準的なUIなら、既存のものがそのまま使えたりするので動かすだけなら1日もかからん。
            新規開発の案件でもWEB提供用とデスクトップアプリ用で区別する必要がないところも大きい。

            • by Anonymous Coward

              既存のコードがあるってのは、つまりJavaScriptで書かれていないものをJavaScriptに移植するよりは全然ラクという意味かね。
              速度が必要ならというのは勿論同意するけど、Web上でクライアントPCにがっつりパワーを要求するケースはそう多くは無いので、
              ほとんどは開発しやすさに優先度が振られると思う。
              WebAssemblyというテクノロジがあるからそれを活用したサービスが設計され、利用されるというのは分かる。

              気になるのは、今Web開発でJavaScriptが利用されている領域が、WebAssemblyに置き換わると何かメリットがあるのか、というところかな。
              それこそコメントをプレビューするだけの話でもWebAssemblyで作る方が開発体験に貢献するのかとか。まあ齧ってみるしかないか。

              • by Anonymous Coward

                JavascriptやtypescriptよりもC#のほうが保守性高いと思うから、
                そういう面でもいいんじゃないかな。
                Blazorなら既存のjavascriptを使うことも一応できるし。

              • by Anonymous Coward

                > 既存のコードがあるってのは、つまりJavaScriptで書かれていないものをJavaScriptに移植するよりは全然ラクという意味かね。

                もちろん、それもある。
                デスクトップアプリをSaaS展開したくて、サーバーサイドとフロントエンドに分離するとかで、サーバーサイドの言語が変わらない場合でも、そもそも分離しないでいいってことになるので WebAssemblyによるSaaSは手軽に手が出せる。

                > 速度が必要ならというのは勿論同意するけど、Web上でクライアントPCにがっつりパワーを要求するケースはそう多くは無いので

                試してみると、なんとなくわかると思う。
                重いこ

typodupeerror

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

読み込み中...