Node.js開発者による新JavaScriptランタイムDeno 1.0がリリース、後継となるか？ 21
ストーリー by hylom
パッケージ周りの仕様は実用上どうなのだろう 部門より
パッケージ周りの仕様は実用上どうなのだろう 部門より
Anonymous Coward曰く、
やや旧聞となるが、Node.js開発者のRyan Dahl氏らがNode.jsの反省をもとに開発を進めている新たなJavaScript実行環境「Deno」バージョン1.0が5月13日にリリースされた（OSDN Magazine、CodeZine、Qiita）。
DenoはJavaScriptに加えて標準でTypeScriptやWeb Assemblyをサポートするほか、コードがサンドボックスで実行されるなどセキュリティにに配慮した設計となっている。一方で、require()によるパッケージのインポートといった構文は取り除かれ、パッケージマネージャのnpmやパッケージ管理ファイルのpackage.jsonもサポートしないなど、互換性は保持されていない。
開発開始からまだ2年ほどで、現時点ではNode.jsを置き換えることは難しいだろうが、将来的には移行が進むのだろうか？ 既に試してみたスラド諸氏が居れば感想など伺いたい。
ディーノ (スコア:1)
秋に再アニメ化するほうとはスペルが違うようだ。
denoはnodeの逆ってことなのかいな？
Re: (スコア:0)
Google Chromeのミニゲーム？
Re: (スコア:0)
odenの方がおいしそう。
npm未サポートじゃ (スコア:0)
置き換えはきつくない？
IPv4からIPv6に移行するようなもんだ。
Re:npm未サポートじゃ (スコア:4, 参考になる)
npm未サポートってか、
npmが完全に不要になる
が正しい。
Re: (スコア:0)
でも、Python3がでてからも、
Python2が残り続けたり、
Javascriptからの置き換えを目指したDartが
復旧しなかったり、
非互換という壁は高いのでは？
Re:npm未サポートじゃ (スコア:2)
置き換えを狙ってるんですかね、これ？そういう文脈の話だったのかな？
単に別の処理系ってだけだと思うけど。
開発者には利点も多そうだが、既存のnodejsアプリケーションを書き直すモチベーションはそれとは別個の話というふうに読んでます
Re: (スコア:0)
DenoはあくまでYet Another。きっと完成形はDoneですね。
Re: (スコア:0)
Dartは仕方ない。
置き換えを目指したけど、当時のJavaScript以上に時代がかった構文で、JavaScriptよりダサく見えるようなやつだったしな。
本当にChromeに標準でのっけてしまえば、少しは普及したかもしれんが、Google自身がTypeScriptに鞍替えして、Dartを捨てちゃったからな。
最近 Flutterでちょっと復活傾向にあったけど、結局Flutterごと消えさりそうだし、、、
Re: (スコア:0)
アンチMSの出番が来ましたね。
Re: (スコア:0)
npmのリポジトリの代わりにMS様がお持ちのギフハブから直接引っ張ってくるようになる気が(今のnpmでも可能)。逃れられない。
Re: (スコア:0)
https://github.blog/2020-04-15-npm-has-joined-github/ [github.blog]
そもそもnpmは現在買収されてGitHubの傘下です。
そしてGitHubはMicrosoftの傘下です。
Re: (スコア:0)
package.jsonとかコマンドでローカルに持ってくるのじゃなくて、javascript中のimport文でnpmパッケージのURLを書く方式になる。
書き方が変わるって程度で、使えなくなるわけではない。
npmの依存がずるずるってのも何も解決されない。
WebAssembly前提の環境が出てくれば (スコア:0)
あたらしい環境はBlazorみたいなのしか要らないでしょ
Re: (スコア:0)
WebAssemblyが普及するとでも思ってるのか
Re:WebAssembly前提の環境が出てくれば (スコア:1)
引き合いも着実に増えてるぜ。JavaScriptより数倍速いし、クライアントアプリのWEB化が、JavaScriptとか使うより数倍工数減らせるのが大きい。
とりあえずって程度のノリで、WASMがどういう物なのかを調べながらでも 2、3日もあればC/C++はもとより、.NET系とかでもデスクトップで動いてるクライアントアプリが、どの程度のパフォーマンス出せるのか試せるしな。
GUIと不可分な実装してるような奴だと分離が大変かもしれんけど、いまどきの普通の設計してたら気にするほどの手間はかからん。
製品レベルの作り込みが大変なのは、今と変わらんけど、ロジック部分のコードをJavaScriptで書き換えるどころか、一切手を加えずに、そのまま動くってのは大きいよ。
メモリ4GBの壁が、けっこう痛いけど。
Re: (スコア:0)
WebAssemblyって普通のWebサイトで使い所ある？例えばスラドみたいなの。
Re: (スコア:0)
コメント入力のプレビュー表示とか、閾値による表示内容の絞り込みとか、JavaScriptで出来る/JavaScriptで何か入れたいっていう部分は、全てWebAssemblyが使える箇所だよ。
どっちでやるのが楽か、速度が必要か？って話になるけど、コード量が増える/既存のコードがあるって状態だと数倍単位でWebAssemblyが楽。速度が必要ならWebAssembly一択。
まぁ、当面の一番大きい用途は、パッケージやダウンロード販売してるようなソフトをSaaS化したいときにUI以外はWEB用に作り直す必要がなくなるってことだろうね。標準的なUIなら、既存のものがそのまま使えたりするので動かすだけなら1日もかからん。
新規開発の案件でもWEB提供用とデスクトップアプリ用で区別する必要がないところも大きい。
Re: (スコア:0)
既存のコードがあるってのは、つまりJavaScriptで書かれていないものをJavaScriptに移植するよりは全然ラクという意味かね。
速度が必要ならというのは勿論同意するけど、Web上でクライアントPCにがっつりパワーを要求するケースはそう多くは無いので、
ほとんどは開発しやすさに優先度が振られると思う。
WebAssemblyというテクノロジがあるからそれを活用したサービスが設計され、利用されるというのは分かる。
気になるのは、今Web開発でJavaScriptが利用されている領域が、WebAssemblyに置き換わると何かメリットがあるのか、というところかな。
それこそコメントをプレビューするだけの話でもWebAssemblyで作る方が開発体験に貢献するのかとか。まあ齧ってみるしかないか。
Re: (スコア:0)
JavascriptやtypescriptよりもC#のほうが保守性高いと思うから、
そういう面でもいいんじゃないかな。
Blazorなら既存のjavascriptを使うことも一応できるし。
Re: (スコア:0)
> 既存のコードがあるってのは、つまりJavaScriptで書かれていないものをJavaScriptに移植するよりは全然ラクという意味かね。
もちろん、それもある。
デスクトップアプリをSaaS展開したくて、サーバーサイドとフロントエンドに分離するとかで、サーバーサイドの言語が変わらない場合でも、そもそも分離しないでいいってことになるので WebAssemblyによるSaaSは手軽に手が出せる。
> 速度が必要ならというのは勿論同意するけど、Web上でクライアントPCにがっつりパワーを要求するケースはそう多くは無いので
試してみると、なんとなくわかると思う。
重いこ