非同期の章の改善案を募集

[azu]

• 非同期処理:コールバック/Promise/Async Function · JavaScript Primer #jsprimer

非同期処理の章は、おそらくjsprimerでも一番難易度が高い章です。
現代のJavaScriptでは非同期処理はとても重要ですが、この章がわかりにくなったりして読むのを諦めさせてしまうのは良くないので、よりわかりやすい章にしていきたいです。

jsprimerは、できるだけスムーズに読み進められるようにしたいため、ここが冗長だったり、ここがわかりにくい、またここを別のところに分けるなどの改善案を募集しています。

[yo-goto]

この章を読んだ当時、setTimeout が非同期 API だということがよく分かってなくて(というかそもそも API 自体があやふやだったのですが)後々になって混乱した記憶があります。

例えば、以下の部分だと「非同期処理が並行(concurrent)処理」である一方で「同時に複数実行している」という話を「平行処理を高速でいくつも切り替えながら走っているのか」というふうに理解できてしまい、当時は「同時に実行している」が本当に同時に実行しているのではなく、超高速で処理を切り替えているのを「同時」と言っているのだと思って誤解していました。つまり「 setTimeout の時間を測る処理と別の非同期処理を極小時間の超高速で切り替えつつ並行で処理している」という感じのイメージで考えてしまった訳です。

JavaScriptにおいて非同期処理の代表的な関数としてsetTimeout関数があります。 setTimeout関数はdelayミリ秒後に、コールバック関数を呼び出すようにタイマーへ登録する非同期処理です。

非同期処理はコードを順番に処理していきますが、ひとつの非同期処理が終わるのを待たずに次の処理を評価します。 つまり、非同期処理では同時に実行している処理が複数あります。

JavaScriptでは一部の例外を除き非同期処理が並行処理（concurrent）として扱われます。 並行処理とは、処理を一定の単位ごとに分けて処理を切り替えながら実行することです。 そのため非同期処理の実行中にとても重たい処理があると、非同期処理の切り替えが遅れるという現象を引き起こします。

提案としては、非同期 API と非同期的に実行されるコールバック関数(こっちが並行的に処理される)などを明確に分けて、非同期 API のおかげで同時に複数の処理が実行できるということを明言化した方がよいのではないかと思った次第です。

[yo-goto]

個人的には「非同期処理」という一つの単語に色々詰め込まれている上で、並列や並行が出てきてかち合ってしまっているというのが問題かなと思います。

たぶん並行や並列は説明の上では無くてもできる気はします。特に並行の概念は説明の後で出ていないの(単語検索で2回しかない)にそれによって他の説明と矛盾して引っかかるっていう感じになってしまっている気がします。

並行、並列がなくてもこんな感じで説明できます。

• 非同期 API : 同時に複数のことができる
• コールバック関数 : 非同期的に実行されたり、同期的に実行されたりする(関数を使う側に依存する)

確かに図としてあると分かりやすいとは思います。

[yumetodo]

コールバック関数そのものについてはすでに関数の章だったかで触れられているので

それまでの章で見てきたコールバック関数と非同期処理との結びつきの解説が弱いようにも思います。

と私が書いたのはまさに

関数を使う側に依存する

の部分ですね

[azu]

Async と言ったときに、その実現方法が Cunrrent と Parallel があって、
言語とか実装次第でどちらの方法を取るかが異なってしまうんですよね。
"非同期"って単語を見たときにどちらであるかと考えるかは結構人次第になるかなと思います。

そのために、JavaScriptにおける"非同期"は大体がメインスレッドで実行されるConcurrentのことだよ的なことを説明するために、最初の方に
https://jsprimer.net/basic/async/#async-and-main-thread を書いた気がしますね。
(Parallelではないよということが言いたかった気がします。Parallelで考えてしまうと変な勘違いが起きそうだし、ブロックしてパフォーマンス的にも問題あるコードを書いてしまうので)

[yo-goto]

なるほど。厳密にParallel と言い切れないけど、Parallel 的な振る舞いをする操作があるのがやっぱり引っかかってしまうところかなと。前に指摘したところとは別に「Promise.all() で複数の Promise をまとめる」の項目で「Concurrentなのに"同時"にリソース取得できて効率が良い」の「同時」がどうしても引っかかってしまった感があります。

先ほどのPromiseチェーンでリソースを取得する例では、Resource Aを取得し終わってからResource Bを取得というように逐次的でした。 しかし、Resource AとBどちらを先に取得しても問題ない場合は、Promise.allメソッドを使って複数のPromiseを1つのPromiseとしてまとめられます。 また、Resource AとBを同時に取得すればより早い時間で処理が完了します。
次のコードでは、Resource AとBを同時に取得開始しています。 両方のリソースの取得が完了すると、thenのコールバック関数にはAとBの結果が配列として渡されます。

予備知識が無い状態だとどうしても書いてある Concurrent に引きずられて「Concurrent で切り替えているのにどうして早くできるのか?」→「超高速に切り替えているから=同時に取得」という思考回路にやっぱり陥ってしまうかなと😅

例えば、dummyFetch() では内部的に setTimeout() が利用されていますが、このタイマーが同時に起動しているのが Concurrent で考えると、普段は頑張っていないコンピュータが複数起動したときはめちゃくちゃ高速に切り替えながら計算して "がんがばってくれて「勤勉」になったおかげで効率がよい"、という感じで自分は考えてしまったところがあります。

setTimeout(cb, 1000);
setTimeout(cb, 2000);
setTimeout(cb, 3000);

「並列」という言葉から直感的に想起するのが「時間的な同時」で、「並列(Parallel)」でないなら「同時」ではないぐらいの強いイメージを初学者は持ってしまうのではないかと個人的な経験では思います。でも、自分がそうだっただけで他の人はもしかしたら違うかもしれません。

[yumetodo]

コンテキストスイッチをOSの仕事という前提知識があるとより一層混乱するのかもしれないですね・・・。JSの世界でのコンテキストスイッチが何基準なのか自分も理解しきれてませんが

[yumetodo]

Promiseチェーンの話は具体的な例ですからこれをむしろ導入としてその後でPromiseの状態 について整理するほうがいいかもしれませんん。具体例から一般化していく流れにできるので

[azu]

2022-07-15のミーティング で話し合って、非同期の章をPromiseを基本(最初)にしてエラーファーストコールバックをコラム的な立ち位置にする感じで書き直してみると、もう少しすっきりするのではないという話になりました。
(関連してユースケースのCLIもエラーファーストコールバックではなく、Promiseベースに書き換える必要もあります)
#1452

Promiseが入ってから7年ぐらい経ってPromiseは新しいものではなくなってきてるので、
歴史的な経緯を順番に辿るよりも最初からPromiseを出して進めた方がわかりやすいのかもという話になったので、
その順番で読めるように書き換えてみようかなと思っています。

[azu]

Issue作りました #1453
一旦、エラーファーストコールバックとPromiseの整理してから、
並列/並行はその後にもう一度見直すのが良さそうかな(Promiseの内容の前提みたいな感じのものなので、中身を書いてから前提を合わせる)