4 ポイント 投稿者 GN⁺ 2023-09-06 | 1件のコメント | WhatsAppで共有
  • Watlings は、複数の小さなプログラムを修正しながら WebAssembly Text Format を学ぶ練習プロジェクト
  • 各課題は exercises ディレクトリ内の指示に従って完了し、npm start 001_hello で解答をテストする方式
  • 解答の確認には npm run show 001_hello、解答を課題に直接適用する作業には npm run solve 001_hello コマンドを使用
  • コンパイルとテストには Node 23+ および wasm-tools を使用し、スクリプト内部で wasm-tools parse を呼び出す
  • 015番以降の課題は exception handling や GC types といった新しい WebAssembly 機能を使用し、Node.js 23 以上でのみ提供される --experimental-wasm-exnref フラグが必要
  • ブラウザで実行できる Web 版 を提供しており、エディタとしては VSCodewat-lsp 拡張の使用を推奨
  • 学習方式は、ファイルごとのコメントで作業内容と背景を示し、可能な限り説明を減らし、異なる文脈で文法に繰り返し触れられるようにする 実際に書くこと重視 のアプローチ
  • プロジェクト構成の参考例として rustlingsZiglings を明記

1件のコメント

 
GN⁺ 2023-09-06
Hacker News の意見
  • あちこちでよく見かけるけれど、ブラウザ上の WASM に欠けているのは DOM アクセスだけではなく、fetchXMLHttpRequest を含む、ほぼすべての Web API です。
    ブラウザはサポートしているが WASM はサポートしていない Web API の一覧はここにあり、DOM はその一つにすぎません: https://developer.mozilla.org/en-US/docs/Web/API
    それでも GC が確定し、ブラウザでサポートされれば、こうしたインターフェースを使える可能性はあります。GC がサポートされると、WebAssembly コードが JavaScript、DOM、通常の WebIDL 定義オブジェクトを参照・アクセスできるとされています。
    最後の段落を参照: https://webassembly.org/docs/web/

    • GC 提案は 2018 年に出ていて https://github.com/WebAssembly/proposals/issues/16、コードもあります: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
      開ける可能性を考えると、進行が あまりにも長くかかっている ように見えます。
    • それを「解決」すると、次の Java Applets になってしまうリスクもあります。
    • WebAssembly を追い続けていたわけではありませんが、かつて JS の「治療薬」と言われたものが、なぜ 基本機能 を備えるのにこれほど時間がかかったのか気になります。
  • Exercism のモデルにとても似ているように見えます。Exercism にも小さな練習問題で構成された無料の WASM コース があります: https://exercism.org/tracks/wasm
    作者がそのコースに貢献したり、共同で作業したりすることを検討したのか気になります。そうすれば、より広い読者に届き、Exercism の既存ツールも活用できそうです。

    • Exercism は本当に好きですが、あそこの練習問題モデルはずっと 自由形式 で、かなり大きなまとまりになっており、相対的に教える要素は少なめです。
      特定の文脈では良いモデルですが、このリポジトリの形式は、コード例とともに構文や機能を学ぶ rustlingsziglings により近いです。
      Exercism の Wasm モジュールが必ずしも「壊れている」わけではないので、自分の貢献が歓迎されるかはよく分かりません。
    • Exercism で気に入らない点は、人気言語を除くと練習問題が概して 体系的ではない ことです。
      言い換えると、難易度順に並んだ LeetCode 風の問題集に近いです。
      きちんとしたコースなら、言語機能ごとに練習問題を配置すべきです。Exercism はそのための優れたインターフェースをすでに作っていますが、ほとんどの言語では活用されていません: https://exercism.org/tracks/csharp/concepts
  • 新しい言語やフレームワークを学ぶときに好きな方法の一つが koans なのですが、これはそれを思い出させます: https://github.com/ahmdrefat/awesome-koans/blob/master/koans...
    基本機能から高度な機能までなめらかに進んでいき、テストが失敗するのを見て理由を理解してから直すという TDD 的な流れが学習によく合っています。「なるほど!」という瞬間のドーパミンもあります。

    • 一人で言語を学ぶには良い方法のように聞こえます。残念ながら Rust が抜けていますが、おすすめのリンクがあれば知りたいです。
  • WASM の GC のような機能 を試すなら、WABT ではなく Binaryen の wasm-opt を使うのが良いです。wasm-opt のほうが、はるかに多くの WASM 拡張をサポートしています。

  • かなり良いですね。
    WASM を直接深く扱ったことはありませんが、このガイドは一度試してみるつもりですし、登場から数年たった今、Web 開発に 大きな恩恵 をもたらしたと思っています。
    一部の人が期待していた「JavaScript キラー」ではありませんが、そもそもそういう目的でもありませんでした。その代わり、既存のエコシステムとうまく統合され、既存のユースケースを最適化し、重い計算が必要なときには新しいユースケースも可能にしています。
    すべての Web 開発者にとって純粋なプラスです。より高速なライブラリ、印象的な開発ツール、より移植性の高い Node バイナリが得られました。

    • WASM を遠目に見てきましたが、JS キラーではない理由 は、DOM や大半の DOM API に直接アクセスできないからだと理解しています。
      ほかに見落としている理由があるのか気になります。
  • WebAssembly の採用が引き続き進んでいるのはうれしいです。ここでは Microsoft は小さく取り上げられがちですが、WASM に関心があるなら Blazor WebAssembly をぜひ試してみてほしいです。
    C# と大半の .NET ライブラリ、さらに NuGet パッケージまで、ブラウザ上でコンパイル済み WASM として使えるようにする非常に強力なフレームワークです。

    • 「大半の NuGet パッケージ」と言うときの 制限 が何なのか気になります。
      ディスク上のファイルを読める必要があるパッケージなら即座に失敗するのか、それともファイル読み取りインターフェースがサーバーサイドレンダリングのような方式に処理を渡すのか知りたいです。
    • 読んだ限りでは、Go を WASM にコンパイルするときと同じ問題があるように見えます。ペイロードが大きく、圧縮後でも普通は数 MB あります。
  • 素晴らしいプロジェクトです。
    ある程度関連するリポジトリをここで管理しています: https://github.com/eliben/wasm-wat-samples/

    • 本当に役に立ちそうです。最初に wat を学んだときにこれを知っていればよかったのですが、優れた参考資料になりそうです。
  • WASM を試してみたのですが、ローカルに接続しようとしていた SQLite データベース接続 を公開するところで問題が起きました。
    似たことをした人がいるか、良い資料を教えてもらえるか気になります。

  • WebAssembly が手である程度書ける 本物の言語 のように見える点が本当に興味深いです。
    ターゲットにする際の参入障壁をかなり下げてくれそうです。

  • WebAssembly が複数のエコシステムの 共通語 になりつつある中で、その仕組みをしっかり理解するために時間を投資する価値が高まっています。