denoを仕事で新規に採用するのはまだやめたほうが良いよという話

最初に言っておきますが、私は個々の会社の状況を知っているわけではありません。
denoを採用してもほとんどnodejsと比べて変わらないと感じるならdenoを採用してもいいです。

しかし、あまりにも最近無責任にdenoを仕事で進める人が増えてきたので、ちょっとなぁ...
と思うことができたので書きます。

現時点でほとんどの会社はnodejsを蹴ってDenoを仕事で採用するメリットは無いです。

採用するうえで下記の問題を解決できるかよく考えてから採用してください。

エコシステムができ切っていない

バイナリをどうするか？

denoの標準ライブラリを組み合わせてライブラリを作るならいいです。
しかし、使いたいor作りたいライブラリはosのapiや共有ライブラリを使用しないといけない作りならどうでしょうか？

denoのモジュール、ライブラリの作り的に今はスクリプトファイルのことしか考えていないので、
共有ライブラリを使うには今現在はplugを使って、
インターネットから共有ライブラリをダウンロードして使うか、
何らかの手段であらかじめ手動で共有ライブラリをシステムにダウンロード、インストールして、
それをプログラムから使うということになります。

この自分でビルドした共有ライブラリを使う場合はこれが本当に開発者経験が悪い...
この共有ライブラリはdenoのモジュールからすると完全に異物なので、
管理できません。

共有ライブラリのバージョンをどうやって管理しますか？
また、その共有ライブラリに問題があった場合は？どうやって、この共有ライブラリだけをアップデートしますか？

バックエンドからするとこれらが大きな課題になります。

denoになくてもnpmやnodejsにある！

それなら最初からnodejs使いましょう。
作るときに最初から他のエコシステムに頼るのはわけわかりません。
あくまで奥の手です。

denoからnodejsの機能使うのと、
nodejsからnodejsの機能使うのとでは
どっちのほうがバグがある可能性あるのかは考えるまでもありません。

デフォルトでtypescriptの罠

denoやbunはデフォルトでtypescriptです。
なので、先進的だ！という人が言います。

...ではところでそのtypescriptのソースコードは誰が面倒見ていますか？
これはdenoはtypescriptのソースコードをフォークしてdeno公式が自前で面倒を見ています。

今現在はdenoの標準ライブラリはtypescriptですが、denoのcoreな部分はjavascriptです。

これはあまりよろしく無い作りで、typescriptのブームが過ぎ去ったら、
denoの標準ライブラリは一気にレガシー化します。

denoのcoreな部分、標準ライブラリまでjsで、typescript公式がdenoをサポートしない以上、
deno公式がtypescript化の部分を別のプロジェクトでサポートしておいて、
deno compileみたいにtypescriptからjsにしろ、実行ファイルにするにせよ楽に使えるように
している作りになっているのが丸いかなと。
つまり、typescript自体はいつでも捨てられるようにしておく。

これが一番よい作りかと。
typescriptがバズワードなので、マーケティングのためにtypescriptを組み込む作りにした感がちょっと否めません。

昔、twitterでtypescriptをレガシーと発言して炎上しましたが、typescriptはメインストリームには確実にならないと思っています。

nodejs, deno, bun、各ブラウザ公式ががtypescriptをパースして
v8エンジンを直接動作させる実装にしない限り、typescriptがメインストリームになる未来は来ません。
そのためにはいろいろと決めないといけないことがあるはずですが、それが現時点では現実的ではない。

よってtypescriptがデフォルトは技術的に大したメリットではありません。

それでもdeno使いたい！

チャレンジャーですね！
会社、個人として、denoやそのエコシステムに貢献するし、自分で全部作る意思があるならそれも良いと思います。

では、どのようなライブラリが欲しくなるか？無いのか？
調べてみましょう。

この基準の一つとして、deno公式にあるwanted_modulesを見てみましょう。
issueが廃れていっていますが、これはこのモジュールが欲しいというissueを書いていくレポジトリです。

これと今現在あるサードパーティのモジュールを検索してみましょう。

仕事をするうえで無くて困るものが結構出ると思いますが、自分たちで作れなさそうならあきらめましょう。

どうやったらdenoがメジャーになるか

とりあえず共有ライブラリの問題がなんとかなってください。
ここが一番大きな懸念点です。

denoのモジュールのエコシステム的に共有ライブラリなんてものは無いもののように見えます。

まとめ

フロントエンドエンジニアが技術方針決めることが多くなった弊害な気がする。

フロントエンド的にはあんま困らないのよね。
フロントエンド的には標準ライブラリの組み合わせだけで解決できることが多いから。
Webブラウザゲームとか、フロントエンドの出来で
売上ある程度決まるようなプロダクト開発しているならこれでも良いかも。

ざっと見た感じ、サードパーティに自分でビルドした共有ライブラリ+denoのスクリプトという構成で
それなりに使われているものが無いのなぁ...