@ledsun blog

無味の味は佳境に入らざればすなわち知れず

ruby.wasmに対する思いとか、企んでいることとか

ruby.wasmについて、現時点で僕が思っていることを記録しておきます。

思っていること

主にonブラウザ

僕がruby.wasmに興味があるのは、ブラウザで動かす方です。 エッジワーカーで動かす方は今のところあまり興味がありません。

また、ruby.wasmがプロダクションで使えることは期待していません。 つまり「Reactをひっぺがして、ruby.wasm + Railsで大統一Ruby Webアプリケーション開発だ!」みたいな線はあんまり考えていません。 というか次の2点で大統一理論に勝ち目はないと思っています。

  1. 言語を統一したところで、ブラウザとサーバーはプログラミングモデルが違いすぎる
  2. JavaScriptエコシステムの規模はRubyエコシステムの規模を圧倒している

わざわざJavaScriptの資産を捨てて、イベントプログラミングに向いているわけでもないRubyを選択するメリットはないですよね。

FlashRubyが置き換えること

一方で、ブラウザでRubyが動くのは楽しいです。 wordle-searchという小さなアプリケーションを作った経験上、謎の楽しさがあります。 アプリケーションでシンプルで小さいから楽しいという面もあるのかもしれません。 Rubyという言語が楽しいのかもしれません。 その辺は未知です。

とはいえ、ブラウザでRubyが動くと、Rubyのプログラミング入門言語としての価値が上がるんじゃないかと思います。 よく「初心者が最初に学ぶとよいプログラミング言語は?」という問いに対して、「Rubyが比較的お約束が少なくプログラムを書ける」ので向いているという回答や、「JavaScriptはブラウザで実行できるので、短期間でGUIをあつかったプログラムが書ける」ので向いているという回答を見受けます。 これはつまりRubyがブラウザで動けば、入門プログラミング言語No.1になります。 まあ、実際はPythonなんかもwasmで動かせば良いだけなので、同じように競争相手になってくると思います。またruby.wasmを使うためのお約束も増えると思います。

勝算はともかく、Rubyが「Flashのような入門的なプログラミング環境」の位置を目指せるということに夢を感じます。Flashはアニメーションが作りやすかった点が大きいし、コンパイル言語だし、ruby.wasmとあんまり対応しないだろうという気はします。 まあまあ、それは置いておきます。 大事なのは夢やロマンを僕が感じるかどうかです。

企んでいること

ruby.wasmがFlashになるためには、Gemの資産が生かせないのは難しいんじゃないかと思います。 少なくともRubyGems.orgでGemを公開したり、公開されているGemをつかうエコシステムがないと厳しそうです。 この辺はnpmを意識しています。 プログラミング初心者が、ブラウザネイティブで動くJavaScriptを選択せずにRubyを選択するときに、公開したり再利用したりするエコシステムがないのは厳しいと思います。

require_relative

まずはreqire_relativeをruby.wasm上で動かそうと思っています。 本命はrequireなのですが、これは難しいので最初にreqiure_relativeを対象にします。 作戦としてはファイルシステムをURLにそのまま置き換えます。 require_relativeはファイルシステム上の相対パスで読み込むRubyスクリプトを指定します。 これをURL上の相対パスで置き換えるのは実現できそうです。

require

つぎにrequireをruby.wasm上で動かそうと思います。 問題はrequireで指定する名前とファイルシステム上の位置が対応していないことです。 この問題はすでにESモジュールがぶつかった問題です。 そしてimportmapsを使うという1つの回答がでています。 僕もこれにならってimportmapsを使うつもりです。 サーバーでは例えばvende/bundleディレクトリにGemをインストールします。 このパスをimportmapsに記述すれば、requireで指定する名前と実際のファイルのURLを解決できるはずです。

これが実現できればimportmap-railsと連携して、Railsアプリケーションでruby.wasmを動かす敷居がさげれるんじゃなかろうかと期待しています。 前述のように、これはプロダクションで使えるものではないと思います。 が、「importmap-railsruby.wasmが動く」ってメッセージはインパクトが強そうです。

UNPKG

サーバーに配置したGemをrequire出来れば、RubyGem.orgのGemを一定のルールで配置した静的なHTTPサーバーがあれば、ruby.wasmアプリケーションの開発者は、サーバーを用意しなくてもGemが使えるようになるはずです。 npmの世界でUNPKGとして実現されているものです。 ここまでくるとどうやって実現するのかは検討がついていません。

ですが、これが実現できるとruby.wasmアプリケーションの開発者は作ったアプリケーションを静的なホームページで公開できるようになります。 例えばGitHub Pageをつくればそれだけでアプリケーションが公開できます。 Herokuのような、PaaSを使うハードルを取り除くことが出来ます。 これはちょっとFlashっぽいんじゃないかな?って ワクワクしています。

打算

Rubyコミュニティにはブラウザからのモジュールローディングに興味を持っている人がすくないようです。 DHHがimportmap-railsを打ち出したときの、反応の低さから僕は思いました。 本当にそうであれば、僕がいまからちまちま作っていっても、Rubyコミュニティに一定以上のインパクトを与えられるんじゃないかな?と予想しています。 で、RubyKaigi 2023のCFPに応募したら、通るんじゃなかろうか?と期待しています。

RubyKaigi 2023までに出来るのはせいぜいrequireまでだろうと思っています。 requrie_relativeですら、想定外に苦戦して2ヶ月掛かっています。 requireが作れれば、UNPKGの要件が詰められるようになるはずです。 本当にいけそうならRuby Association Grantに応募するのが良さそうだと思っています。 Ruby Association Grantは所属企業で応募できるので「通れば業務時間で開発できるじゃん。」という打算です。