Single Page ApplicationならService Worker待たなくてもWeb Workerで代替できるんじゃないの問題
- 題名の通りです
- 「別にService Workers待たなくても、現状のWeb Workersだけでモデル層の別スレッド追放が可能なのではないか?」という問題
- 対応ブラウザについては考えない
- Transferable Objectサポートしてなくても、どうせサーバーに問い合わせてた分はテキストメッセージが大半だし敢えて気にしない
- 「WokerからDOMに触れない」ということを未だに問題にする人はスレッドセーフを理解してから出直してこい
結論
- Service Worker待つのが幸せなのは変わらない
思考推移
- Web Worker上にリモートのサーバを抽象化させるプロキシサービスを構築して、そこで通信だのやらせればモデルだのをキャッシュすれば良いんじゃないの、どうせメッセージパッシングでやりとりするのは一緒なんだし
- 具体的にこう言う設計のこと何て言うんだっけ
- グローバルな状態を可能な限り作らないようにするとオブザーバパターンなり何なりでインスタンス間でメッセージ通信させざるをえないケースが出てくるし
- Service Workerはまさにそれだけど、そんなの待ってられないよね
- でもWeb Workersはページ遷移すると初期化させた分がパーになるんじゃない?
- コスト的にペイしないのでは
Single Page Applicationならhistory APIでアドレスバー誤摩化すことはあるけど静的ページ遷移発生しないはずだから、Worker立ち上げコストとペイするのではないか
- たぶんペイする
- タブを閉じたりページ遷移されるとコスト的に釣り合わないので、長期間ページを開きっぱなしにしてもらえるようなアプリの方がペイする率が高い
- 設計面の複雑さは
- MVCにしろ何にしろデータロジックを分離するのが基本なんだからなんとかなるでしょ
- メッセージパッシングだ
- Web Worker自体を利用する面倒臭さの割に、ページ閉じられるとアウトなのではないか
- どうせ分離するんだから(ry
- フレームワークとか便利ライブラリが無さそう
- なんとかなる
- なんとかしろ
Worker使いにくい
- 使いにくいというよりもセットアップ手順が面倒くさいと言うのが正確な表現だと思う
- とはいえ、軽量スレッドとして設計されているわけではないので、ある種の面倒臭さはやむなしだと思う