【wasm】ブラウザでC++。Emscriptenを語ろう

L · 2019/01/15(火) 19:50:48.94

タイトル通り。

・canvas への描画が可能なことを確認。
・emscripten_sleep() でその場で停止できることを確認。
・付属の emrun や mongoose などで Local Server を作れば、local だけで
　wasm の起動が出来ることを確認。
・mongoose からは、cgi も起動でき、XmlHttpRequest()でローカルファイルを
JSから読み込め、cgi も自由に起動できることを確認。
・ローカル・ファイルアクセス、clipboard の読み書きの他、Local OS の
　全ての機能を自由にできる可能性有り。
・これを使えば、Java の JVM に変わる新たなローカル仮想環境ができる。

**デフォルトの名無しさん** · 2019/11/20(水) 09:18:48.73

Mozilla、Fastly、Intel、Red HatがWebAssemblyをターゲットに「The Bytecode Alliance」
https://news.mynavi.jp/article/20191118-925267/

**デフォルトの名無しさん** · 2019/11/20(水) 12:43:45.81

>>101
https://yutakaaoki.github.io/
ここにおいてあるものは、全部PWAに対応してみた。
Windowsならインストールできると思う。
AndroidやiPhoneなどでも出来るか試して欲しい。

**デフォルトの名無しさん** · 2019/11/20(水) 12:51:31.62

>>103
まだ本当の意味でのソースではないけど、
https://github.com/YutakaAoki/YutakaAoki.github.io
以下の
https://github.com/YutakaAoki/YutakaAoki.github.io/tree/master/demo1
などに index.htmlや、*.wasm, *.js, manifest.json などは置いてある。

wasmアプリの作り方、PWAの作り方、wasmとPWAの組み合わせ方、に興味のある人は
参考までに。

**デフォルトの名無しさん** · 2019/11/20(水) 13:48:41.27

で、これで何ができるの？

**デフォルトの名無しさん** · 2019/11/20(水) 14:49:34.93

>>105
・セキュリティーが凄く強いアプリ。信用できないようなサイトからインストール
　しても、レジストリには読み書きできないし、システムフォルダや他のアプリの
　フォルダには、人間がマウスやキーボードなどから実際に指示しない限りは書き込めないし、
　読み込むことも出来ない。変な場所にインストールされたり、スタートアップ起動などに
　勝手にされることも無い。
・アプリの体験版をインストールすることなく、普段のウェブ閲覧の延長線上に
　試せるのでユーザーは遊び半分で気軽に試すことが出来る。また、掲示板などから
　リンクを張った先がすぐにアプリとなっている。その後、デスクトップや
　ホーム画面にアイコンを追加し、単独アプリの用に振舞うことが出来る。
・なぜか全てがウェブに移行するようになっており、「いつもウェブが勝つ」。
・iPhoneやiPad用のアプリが無料で開発出来る可能性がある。今までは、
　それらをターゲットに開発するには、Mac実機がどうしても必要となり、
　かつ、AppStoreに登録しないと配布することも出来なかったが、AppStoreは
　年会費も必要で、生涯にわたってずっとコストが掛かかり続けていた。
・ブラウザが互換性を保つので、PCで試して動けば、AndroidやiPhoneでも
　近い動作になる可能性が高い。
・Chrome, FireFox, Safari, Edge, Opera なども wasm に対応している
　（ただし、ツールキット側がテストはしておく必要はある。）。

**デフォルトの名無しさん** · 2019/11/20(水) 15:00:00.13

Java Appletと何が違うの？

**デフォルトの名無しさん** · 2019/11/20(水) 15:00:41.97

>>106
【追加】
・画面が、Ctrl+ +, Ctrl+ -で好きなように拡大縮小できるので、近視や老眼などで
　目が悪い人でも好きな文字の大きさで読むことが出来る。それがWebアプリでも、
　PWAアプリ化したものでも出来る。
・ツールキットも含めてサイズがとても小さい。ブラウザさえ使える状態であれば、
　DLLやランタイムのインストールが全く不要。demo1は、*.htmlや*.js, *.wasm全て
　合わせて　150KB、demo-Mountainは、153KB。JavaランタイムもQtランタイムも
　MFCのDLLも何も要らない。

**デフォルトの名無しさん** · 2019/11/20(水) 15:11:39.18

>>107
・Java Appletは、訴訟トラブルのせいか、ChromeもFireFoxが対応しなくなって
　しまった。
・wasm は、C++ が使えるので、GC を使わないプログラムが出来、
　メモリが多く使うウェブアプリを作ろうとした場合に、体感速度が非常に
　違ってくる。Javaだと、GCが走ると一分間停止するようなことがあった。
　wasm と C++ の組み合わせだと、このようなことが起きないので、
　プログラムした通りの一定の速度が維持できる。
・Java は、逆コンパイルするとほぼ元ソースに戻せてしまう性質があった。
　それを防ぐには曖昧化などが必要であり、手間や（ツール購入の）コスト
　が掛かった。曖昧化するためにコンパイル時間が増大した。
・Javaが有料化したという話がある。これについては諸説あるのでよく分からない。

**デフォルトの名無しさん** · 2019/11/20(水) 15:14:47.33

>>109
・Java Applet より起動が速い。

**デフォルトの名無しさん** · 2019/11/20(水) 15:18:23.10

>>110
・wasm内部からは、EM_ASM()構文などで自由にJavaScriptが使えるので、
　XHRやfetch()などを自由に使ったAjax流儀のプログラムが行える。
・簡単に HTML 要素と共存できる。
・ブラウザの画面を拡大したような場合に、JavaAppletだと追従するのが
　難しく、できないことはないがタイムラグが生じ易かった。
　Ctrl+ + での拡大も、JavaApplet 部分だけは置いていかれるようなことに
　なったので、対応したければ独自に工夫する必要があった。

**デフォルトの名無しさん** · 2019/11/20(水) 15:54:16.93

>>111
・iOSでは、もともとJavaが使えないと聞いている。
・Androidは、基本がJavaではあるが、実際には、Google独自実装となってしまって
　おり、　Sun/OracleのJavaで昔からの標準の Swingなどを使ったものは動か
　せない。これが訴訟問題になった最も大きな原因の一つらしい。

**デフォルトの名無しさん** · 2019/11/20(水) 19:15:30.47

>>108
ツールキットに用意されて無い機能を追加したい場合、JavaScript として書けば
よいのであらゆるプラットフォームへ迅速に対応できる。
他のツールキットの場合は、iOS/Andorid/Win/Mac/Linux など用にそれぞれ
書く必要がある。

**デフォルトの名無しさん** · 2019/11/21(木) 15:21:55.41

PWAは、頻繁にアップデートしたいアプリに向いている。

**デフォルトの名無しさん** · 2019/11/21(木) 16:02:31.75

PWA化後のデスクトップのアイコンが、物凄くいろいろなことをやっても古いまま
全く更新できなく立った。
どうしよう。

**デフォルトの名無しさん** · 2019/11/24(日) 12:10:37.33

Safariで動いていたよ。
ホーム画面への追加のボタンも出ていた。

**デフォルトの名無しさん** · 2019/11/26(火) 01:08:23.77

PWAだとストアの審査が要らない。通常、iPhoneのアプリは、iPhone流の
インターフェースを持って無いと審査に通らない（Appleに脅威をもたらすと
考えられるだけで審査に通らない可能性もある。YahooゲームやLINEゲームが
AppleにBANGされた歴史もある。）。PWAの場合はそんなことはなく自由
なので、PCやAndroid、iPhoneで完全に同じインターフェースにすることもできる。
そうすれば、開発も楽になる。

**デフォルトの名無しさん** · 2019/11/26(火) 01:16:04.21

PWAの場合、ブラウザとnative風アプリの操作感が統一できるのでユーザーは
安心して使える。WindowsとiPhoneで同じインターフェースのアプリになる。
今まではAppleの審査のためにそのようなことは出来なかった。Windowsに慣れて
いるが、iPhoneを使っている人にはWindows流インターフェースの方が好まれる
可能性があるにも関わらず。

AppleはiPhoneらしさを強要するが、逆にどのプラットフォームでも同じ操作感
であることには、開発者のみならずユーザーにもメリットがある。

**デフォルトの名無しさん** · 2019/11/26(火) 01:22:29.32

Appleは審査が厳しいが、自社がそのアプリが出てくると(競争に負けて)業績が
落ちそうだと判断するともっともらしい理由を付けて審査を通さなかったり、
長く時間をかけて手間をかけさせたりする可能性がある。PWAだとその心配が無い。
ただし、PWA専用のダウンロードサイトを作ろうとすると、そのサイト自体に
規制がかかったことがあるそうだ。Appleはまるで中国や北朝鮮のようだ。

**デフォルトの名無しさん** · 2019/11/26(火) 01:24:58.56

>>118
https://blogs.adobe.com/japan/web-the-death-of-the-standalone-app-and-what-comes-next/
1. より一貫したデザインを提供できます。3つの異なるデザインをiOS、Android、
　レスポンシブサイトとそれぞれ用意する代わりに、PWAの場合はすべての環境に
　対応する1つのアプリをデザインします。これはアプリ開発にかかる時間を短縮
　するだけでなく、デザインの一貫性にも繋がります。デザイナーは、1つのガイド
　ライン作成に集中でき、より有意義に時間を使うことができます。

2. 複数チャネルの組み合わせが容易です。ユーザーは、どんなデバイスから
　アクセスしても一貫性のある体験を求めています。あるデバイスで使い始め、
　他のデバイスに切り替えて再開することは自然な動作です。帰宅途中の通勤電車で
　ショッピングカートに目に付いた商品を入れたあと、自宅のPCからきちんと商品を
　確認して購入手続きを完了できるような機能はどうでしょうか？PWAであれば
　最小限の投資で実現できるでしょう。

**デフォルトの名無しさん** · 2019/11/27(水) 01:56:02.82

独自GUIを乗せることで使い勝手で他のアプリと差別化できるかも。

**デフォルトの名無しさん** · 2019/11/27(水) 01:59:18.80

>>121
今までなら独自GUIはAppleの審査に落ちる可能性があったが、PWAなら
自由になる。それでAppleの伝統を超えた使い勝手のGUIシステムを備えた
アプリを提供できれば他のアプリと差別化できる可能性が出てくる。

**デフォルトの名無しさん** · 2019/12/06(金) 02:20:17.94

Webアプリの場合、URLのパラメータによって、プレイ中のゲーム画面
にいきなりリンクすることが出来るようになる。これで、ゲーム画面の「シェア」
が出来る。例えば、RPGで経験値、体力、魔力、所持アイテム、地図上の座標、
タワーの階層、的の位置などを全部URLのパラメータに直してしまえば、
そのシーンを他の人にシェアして、そこからプレイし始めてもらえる。これは、
native ゲームにはなかった特徴。blob や base64 による URL 化などを使えば
データをURL化することは難しくはない。URLが長くなりすぎる問題はある
かも知れないが。

**デフォルトの名無しさん** · 2019/12/06(金) 02:24:38.19

>>123
RPGなどでセーブデータが大きすぎてURL化に適さない場合は、
サーバー上にシーンを圧縮セーブしておいて、その識別番号をシェアする手もある。
ユーザーが各自で無料ストレージサービスを借りて、そこにセーブしておいて、
それをシェアする手もある。

**デフォルトの名無しさん** · 2019/12/06(金) 02:45:16.50

インストール型のゲームだと、URLを書くだけで一瞬で動いている場面を他人が
見ることはできない。しかし、ウェブゲームだとそれが出来る。ただし、
この場合、ゲームサイズを小さく作ることが重要になる。その意味で、
サイズがコンパクトになるwasmと、コンパクトなサイズのゲームライブラリが
重要となる。

**デフォルトの名無しさん** · 2019/12/06(金) 02:50:45.17

ゲーム全体のデータが巨大だとしても、1つのシーンを見るために必要なデータは
ごく少ない。その意味で、プログラム部分(コード)部分のサイズさえ小さければ、
ポリゴンやテクスチャやマップのデータは巨大でも良い。大部分のデータは
サーバー上に置いて置けばいいのだから。これで、ゲームシーンを快適に
シェアできるようになる。これが、ブラウザゲームならではの新しい価値。

**デフォルトの名無しさん** · 2019/12/06(金) 02:56:52.29

インストール型ゲームでも動いているゲーム画面をシェアすることも不可能ではないが、
それには、同じゲームをインストールすることが前提となる。
一方、ブラウザゲームでは、例えば、2ch/5ch にリンクアドレスのURLを
入れるだけで、一秒後には、そのシーンを見られて、プレイも出来る。

**デフォルトの名無しさん** · 2019/12/08(日) 12:57:08.43

テニスゲーム:
https://yutakaaoki.github.io/demo_tennis/

**デフォルトの名無しさん** · 2019/12/10(火) 08:37:25.30

WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ
https://www.publickey1.jp/blog/19/webassemblyw3cwebassembly_core_specification_webassembly_web_apiwebassembly_javascript_interface_3.html

**デフォルトの名無しさん** · 2019/12/10(火) 14:13:47.04

ブラウザの中でのwasmは、現状、ローカルファイルシステムには自由にはアクセス
できないが、その場合、mongoose.exe, Ruby, Python などでローカルサーバー
を起動すれば、ブラウザ内のwasmプログラムから cgi プログラムを起動できるので
ローカルOSのAPIは何でも利用できるようになるので、ローカルファイルシステムにも
自由に読み書きできるようになる。もし、このサーバープログラムが十分に高速なら、
DirectInput などを利用してフォースフィードバック付きのジョイスティックも
wasmゲームから使えるようになる。

**デフォルトの名無しさん** · 2019/12/10(火) 14:26:39.38

ローカルサーバーをnode.jsで書くの流行ったな

**デフォルトの名無しさん** · 2019/12/10(火) 14:28:32.93

>>130
ちなみに、mongoose.exe は、BSD/MIT 系ライセンス。
サイズは100MBを超えてしまっているが、Luaを無効にしてソースから
ビルドし直すと、すると、サイズが1MBくらいになる。

**デフォルトの名無しさん** · 2019/12/10(火) 14:36:55.20

mongoose.exe + CGIプログラムを配布すれば、ある種の Java仮想マシンJVMの
代替になる。JavaのSwingでGUIアプリを作る場合も JVM のインストールが必要に
なるが、それが、mongoose.exe + CGI プログラム。しかし、JVMよりサイズが
小さいのでインストールが容易。

**デフォルトの名無しさん** · 2019/12/10(火) 16:23:17.02

>>129
それとは直接関係ないけど、海外のサイトで昨日、目にしたのは、Googleは、
MicrosoftからOSの制御力を奪おう(無くそう)としているという見方。
PWAを発案したのもGoogle。
IntelやMozilla、RedHat、Fastlyも、別方向でwasmを拡大しようとしているので、
恐らく一社がコントロールしようとしてもwasmの勢力拡大は止められない
思われる。PWAに関しては微妙で Appleは渋々対応している感じでは有るが、
対応しないとむしろ不利になると経営判断している可能性もある。
分からないが。

**デフォルトの名無しさん** · 2019/12/12(木) 19:22:14.47

5chの広告に表示されている「ビビッドアーミー」などのG123なるものを
やってみたら、少なくともWebGLが、昔のPC-9801の最後期レベルよりも高速な
グラフィックをかけることがはっきり分かった。と言うか恐らく、初期のPlayStation
よりは緻密で速いと思う。

また、Fragment Shader は再帰的関数呼び出しでも何でも書けるようで、
レイトレーシングでも何でも出来ることがわかった。つまり、WebGLを
使ったブラウザゲームは、レイトレーシングやパストレーシングレベルの
3Dグラフィックを使ったものでも何でもできるようだ。

また、Chrome には、FileSystem API だけではなく、native file systema API なる
実験的拡張がある。これはデフォルトでは disable だが、enable にすれば、
本当に native のファイルシステムのディレクトリ内のファイル一覧を取得したり
自由に読み書きできるようになるらしい。

Wasmもある程度速いし、もはや、nativeアプリは要らないかも。
Webアプリは、Win/Mac/Linux/iOS/Android 全てに共通で、
「1バイナリ」で Write Once, Run Anywhere がほぼ実現しているので
ブラウザをOSとみなした場合、WindowsやiOS, Android のどれよりも
シェアが大きい。これは native アプリの時代が終焉するかもしれない。

**デフォルトの名無しさん** · 2019/12/12(木) 19:26:35.52

>>135
訂正。
使ったGPUは、エントリーモデルの(ビジネス用の)劇安 Intel CPU に内臓の
Intel HD グラフィックのもの。それでさえ、初期 PlayStation レベルを
超えたグラフィックが描けているようだった。

**デフォルトの名無しさん** · 2019/12/13(金) 00:07:05.15

PWAは自社に不利になるはずなのに何故、Appleも採用したかについて。
PWAはGoogleが推進しているものだが、Googleは、検索エンジンを
iOSのデフォルト検索エンジンにしてもらうために、毎年Appleに
一兆円を払っている。ところが、このカネの流れのために、
AppleもGoogleの意向を無視できない状況になっているのではないか
と考えられる。

**デフォルトの名無しさん** · 2019/12/13(金) 10:10:45.11

板違い
マ板池

**デフォルトの名無しさん** · 2019/12/30(月) 11:57:40.01

アップル、Mac App Store外アプリの「公証」要件を厳格化。2020年2月3日から
https://japanese.engadget.com/jp-2019-12-25-mac-app-store-2020-2-3.html

**デフォルトの名無しさん** · 2019/12/30(月) 12:16:48.85

登録済でも放置されてるものは消えるのか
胸熱

**デフォルトの名無しさん** · 2020/01/05(日) 08:50:18.44

ブラウザでゲームのマップ作れて操作するのは見たことあるよ。
もう今ブラウザ主流？
ただいちいちサイトに繋いだりサーバーにアクセスするから普通のアプリよりは不安要素あるけど。セーブもしたりできるしな。
何でブラウザでやるのかがわからない。

**デフォルトの名無しさん** · 2020/01/05(日) 16:24:57.29

>>141
ある外国の学者が言ったそうだ。
「存在する技術はぎりぎりまで使われる」
と。

典型的な例は、HDDの容量が以前では考えられないほど増大しているのに、テレビ録画など新しい使い方が見出されていつまでたっても不足していること。

ユーザー目線で考えたときのブラウザでやるメリットは、
・インストール作業が要らないこと。もし起動が十分速ければ、次々とゲームを試すことも出来る。
・理論上は、URLに状態やセーブ番号などを含ませておけば、そのURLを掲示板などに張っておくだけでプレイ場面を世界中の人に見て貰えること。
・プログラムがブラウザのサンドボックス内から外に悪さが出来ないので、たとえ野良アプリであってもマシンにあく栄起用を与える可能性が低いこと。
・iOS/Android/Windows/Mac/Linux など全く違うOSでも全く同じ使用感でゲームが出来ること。
・Appleの独自規制に引っかかることもないので開発者の自由な発想のゲームで遊ぶことが出来る。

**デフォルトの名無しさん** · 2020/01/05(日) 18:19:27.95

https://www.businessinsider.jp/post-187542

*アップルは、国境を超えて表現を規制する力を持っている。

アップルのガイドラインでは、性的な表現について、次のような記載がある。

｢Webster辞書で『美的または情緒的な感覚ではなく、性的興奮を引き起こすような、性器または性行為の明確な記述または表示』と定義される、あからさまに性的またはわいせつなコンテンツ｣

欧米や日本、イスラム教徒の多い中東など、国、地域ごとに｢わいせつ｣の考え方には違いがある。

しかし、デベロッパーに対しては、アメリカのアップルが決めたガイドラインが一律に適用されるため、｢ローカルルールは存在しない｣と言われる。

6〜7年ほど前、ゲームの世界でも、ガラケーからスマホに一気に移行する波が訪れた。そのころには、アップルの基準に合わせるため、露出度の高い女性キャラクターの服装を描き直す作業に追われたという。

ゲーム会社の幹部のひとりは｢アップルは、国境を超えて表現を規制する力まで持った。しかし本来は、国や企業がそれぞれの文化や戦略に合わせて考えるべきことなのでは。現状では、毒っけのあるコンテンツはつくれない｣と話す。

**デフォルトの名無しさん** · 2020/01/07(火) 18:36:15.80

昔の chip8 という CPU エミュレータが一瞬で起動しちゃう:

https://blog.scottlogic.com/2017/12/13/chip8-emulator-webassembly-rust.html
https://colineberhardt.github.io/wasm-rust-chip8/web/

二番目のリンク先で、start というボタンをマウスでクリック後、wキーを押すとブロック崩しの様なゲームが動き出す。
キーボードのqで左、eで右にラケットが動く。

**デフォルトの名無しさん** · 2020/03/11(水) 16:21:40.05

https://yutakaaoki.github.io/demo1/index.html
MessageBox が出せるようになった。
C++のプログラム中で
nexMessageBox("タイトル文字列","メッセージ文字列", MB_OKCANCEL);
などとすると、ボタンが押されるまでその場で停止する。
JSやブラウザ、Wasmでは、本来、「その場で待機」することは出来ないので、
nwsc の bsync, bwait, bresume 機構を用いている。

**デフォルトの名無しさん** · 2020/03/11(水) 16:24:14.20

>>145
なお、JSとC++の組み合わせる際に、ちょっとした問題があって、今のところ、トータル200個以上のWindowを生成すると異常を来たすので、決して、ダイアログを何度も生成しないでね・・・。
理論上は直せるけれど、まだ直せてない。

**デフォルトの名無しさん** · 2020/03/11(水) 19:28:39.62

STLが使いたい。

**デフォルトの名無しさん** · 2020/03/11(水) 20:30:36.35

>>147
以下は他のコンパイラを使う場合は関係ない話だけど。
コンテナ類は、C++ nexでも本家C++以上に便利になるように独断と偏見で独自サポートしている。
STLは、templateをかなり深く使用していると思われるので、C++ nex側のそれに追いつけなければ、そのままではSTLのコンパイルは難しい。
なお、今のところtemplateを簡単に使えるようにしたtemplなるものを C++ nexでもサポートしているが、本家C++のtemplateも徐々にサポートしていく予定。

**デフォルトの名無しさん** · 2020/03/27(金) 04:03:07.14

Wasmアプリは次のようなことで需要がありそうだ：
・nativeアプリの場合、ストレージの容量制限でインストールできない事があるが、
　Wasmならブラウザ内で動くのでその心配は少ない。
・nativeアプリの場合、インストールするのに新しいVersionのOSを要求されること
　があるが、Wasmなら、余り関係ない。

**デフォルトの名無しさん** · 2020/03/27(金) 04:06:39.29

>>149
nativeアプリの場合、Win7で動いていたものがWin10で動かなかったり、逆に、Win10を要求されたり
する。
Androidアプリの場合も、バージョン○○以上が必要条件などとあったりする。

ところが、Wasmアプリの場合、余りそういうことは無い。
ブラウザのバージョンが有る一定以上のものでありさえすれば、OSの種類やバージョンに関係なく動く可能性が高い。

**デフォルトの名無しさん** · 2020/03/27(金) 04:51:51.87

アプリストアにはアプリが多すぎて、まみれてしまう。
ウェブアプリなら、検索エンジンからダイレクトに探せるのでアプリストアよりは、まみれる度合いがましになる。

**デフォルトの名無しさん** · 2020/03/27(金) 05:08:06.41

・WasmやPWAが、TwitterやLineなどでshareし易いことは、
　企業にとってはのどから手が出るくらい価値がある。
　nativeアプリだと気に入ったアプリを友達にシェアしにくいが、
　WasmアプリだとURLだけですぐにシェアできる。これはアプリの普及や
　宣伝にとって意義は大きい。
・PC/Mac/iPhone/Androidで見た目や使い勝手が同じであることは、
　アプリのブランド価値を高める。
　これは、コンビニが全国で同じレイアウトと品揃えであることで
　安心感と利便性を高めることで勝ち残ってきたことと通じるものがある。

**デフォルトの名無しさん** · 2020/03/27(金) 05:14:54.39

企業にとっては、プラットフォームごとにビルドし直さないでよいことだけでも
価値は大きい。
マルチプラットフォーム対応なのに最終プログラムが1種類だけで済むことは
メンテナンス性は劇的に向上する。
nativeアプリをマルチプラットフォームに対応させる場合、OSごとにビルドされた
最終プログラムのバックアップだけでも慎重を要し、生産性が下がる。
開発時にはいちいち、各プラットフォームごとにビルドする時間と手間、
テストが必要で、その時にトラブルも出易かった。例えば、
新しいバージョンのAndroidが出てきたら、新しいAndroidSDKをインストール
しなくてはならないが、それでツールキット側のバージョンが合わなくてトラブル
が発生し、その解決のために一週間以上も無駄になることもあっただろう。
Wasmなら、最終プログラムは一度ビルドするだけで済むのでそのようなトラブルが
生じないし、テスト工数も激減する。

**デフォルトの名無しさん** · 2020/04/13(月) 18:12:02.53

MDI Child Window に対応 :
https://yutakaaoki.github.io/demo1/index.html

◆QZaw55cn4c · 2020/04/13(月) 21:47:32.08

>>153
で、ブラウザごとにデバッグするわけですか…

**デフォルトの名無しさん** · 2020/04/13(月) 23:46:07.73

>>155
HTML5は他企業も含めた共通規格なので、一度決まった仕様は比較的安定して動作するため、ツールキット側が一度デバッグしてあれば、そので動くアプリは1つのブラウザで動作チェックしさえすれば、ツールキットがサポートしているどのブラウザでも動作し易い。

**デフォルトの名無しさん** · 2020/04/14(火) 00:37:46.92

HTML5はGoogleの規格なので、Googleの都合でいかようにも変わると思います。

**デフォルトの名無しさん** · 2020/04/14(火) 01:07:56.72

>>157
確かにFireFoxのMozillaもGoogle傘下にあるようなものだし。
でも、SafariやEdgeもあるので、今まで動いていた古い仕様が動かなくなる可能性は割と低そうという希望的観測がある。

**デフォルトの名無しさん** · 2020/04/14(火) 01:12:20.23

でも、実行プログラムがindex.htmlとmain.wasmなどの1種類で、
プラットフォームごとにビルドし直さなくて良いというのは安心感はある。

◆QZaw55cn4c · 2020/04/14(火) 19:22:31.95

>>156
write once, run anywhere といわれていた Java JVM も、蓋を開けてみれば write once, debug anywhere となってしまった現実をご存知ですか？

◆QZaw55cn4c · 2020/04/14(火) 19:23:13.73

>>159
でもデバッグは各ブラウザ毎にしないといけませんね…

**デフォルトの名無しさん** · 2020/04/15(水) 14:42:27.93

>>161
やはり、「XX OS対応」と書くためには、XX OSでテストする必要はあるでしょう。
ただ、ビルド回数が少なくて済むことは時間の節約になりますし、
他の事で手一杯の忙しいときに、あるプラットフォーム向けのビルドだけ
(起きるはずも無い)エラーが起きてその対応に追われる心配も無いです。

**デフォルトの名無しさん** · 2020/04/15(水) 14:46:20.72

>>162
1. Win/Android/iOS/Mac/Linuxで最終テストは必要。
2. しかし、ソース修正後、ビルドは一度だけでよい。
3. 2.により、仕上げの段階で1箇所修正するだけで5つのプラットフォームごとに
　5回ビルドして5回テストする、という効率の悪い事態は起きない。

**デフォルトの名無しさん** · 2020/05/25(月) 03:25:23.82

あがれ

**デフォルトの名無しさん** · 2020/05/28(木) 17:15:51.05

懸念事項だったローカルファイルシステムへのファイル保存について、
今後の Edge Browser では何か進展が有るらしい。

Native file system access
Up until now websites were not allowed to save files in a specific location on the user device.
This meant that online photo editors required users to upload the photo they wanted to edit and then download it to their device, while a native one would have just given the option to replace the existing one.
Starting from Edge 86 (version 83 is the latest one at the time of writing) developers will be able to replace all files the user selects in a session, thus enabling productivity apps on the web to even more useful.

**デフォルトの名無しさん** · 2020/05/28(木) 17:47:36.62

>>165
どうやら、PWAアプリを起動時に指定したファイル群に、ユーザーにファイルダイアログで毎回選択させること無くいつでもアプリがプログラム的に書きこめるようになるらしい。

**デフォルトの名無しさん** · 2020/07/14(火) 00:20:51.75

age

**デフォルトの名無しさん** · 2021/03/11(木) 04:16:55.67

wasmからGPU使うにはWebGL呼び出しになりますか？

**デフォルトの名無しさん** · 2021/03/20(土) 23:25:10.94

>>168
WebGPU は使ったことは無いが、WebGL 以外に WebGPU もある。
Wasmはそれ自体では副作用や入出力は行えないので、やりたいときはJSを
使うことになるので、GPUを使いたい場合は、JSでGPUを使う方法を調べる
ことになる。Wasmは、EM_ASM 文などの中に書いた JS コードを呼び出す
ことで副作用や入出力を行う。

**デフォルトの名無しさん** · 2021/07/10(土) 01:15:43.14

Wasm ならどんな言語でも同じだろ

**デフォルトの名無しさん** · 2021/09/14(火) 18:18:01.42

age

**デフォルトの名無しさん** · 2022/02/04(金) 02:46:38.22

age

**デフォルトの名無しさん** · 2022/06/21(火) 12:20:06.79

WebAssemblyを普及させたい

☆WebAssembly総合
・Wasmer - The Universal WebAssembly Runtime
https://wasmer.io/
-> WASI（WebAssembly System Interface）とEmscriptenに準拠したWASMを実行できるランタイム

・WAPM - WebAssembly Package Manager
https://wapm.io/
-> WebAssembly製ツール/ライブラリのパッケージマネージャー

☆C/C++
・wasi-sdk - WASI-enabled WebAssembly C/C++ toolchain
https://github.com/WebAssembly/wasi-sdk
-> WebAssemblyのLLVM、clangコンパイルサポート
Emscriptenとは異なりWASMバイナリのみ生成する

☆Rust
・wasm-pack - your favorite rust -> wasm workflow tool!
https://github.com/rustwasm/wasm-pack
-> WebAssemblyのrustcコンパイルサポート

Yew - Rust / Wasm framework for building client web apps
https://yew.rs/ja/
-> WebAssembly によってマルチスレッドな Web アプリのフロントエンドを作ることができる、モダンな Rust のフレームワーク

**デフォルトの名無しさん** · 2022/06/21(火) 12:28:27.45

最近のWebAssemblyのニュース

Publickey － Enterprise IT × Cloud Computing × Web Technology / Blog より
https://www.publickey1.jp/programming-lang/webassembly/

**デフォルトの名無しさん** · 2022/06/23(木) 17:39:28.38

WebAssemblyが気になるので調べてみた - Qiita
https://qiita.com/t_katsumura/items/ff379aaaba6931aad1c4

**デフォルトの名無しさん** · 2022/06/23(木) 18:38:00.25

WebAssembly活用プロジェクト
https://madewithwebassembly.com/

**デフォルトの名無しさん** · 2022/06/23(木) 21:37:11.74

WebAssembly Powered Augmented Reality Sudoku

This project makes use of the WebAssembly build of OpenCV (a C++ computer vision library), Tensorflow (a machine learning library) and a solver written in Rust. It neatly demonstrates how WebAssembly allows you to write performance-critical web-based applications in a wide range of languages.

https://github.com/ColinEberhardt/wasm-sudoku-solver
Solverhttps://raw.githubusercontent.com/ColinEberhardt/wasm-sudoku-solver/master/sudoku-solver.gif

**デフォルトの名無しさん** · 2022/06/24(金) 00:36:37.46

WASMとRustはVue.js/React.jsを打倒するのか？ - JSへの侵略の歴史
https://zenn.dev/koduki/articles/c07db4179bb7b86086a1

**デフォルトの名無しさん** · 2022/06/24(金) 00:38:27.46

Typescriptの次はRustかもしれない
https://zenn.dev/akfm/articles/81713d4c1275ac64a75c

**デフォルトの名無しさん** · 2022/07/03(日) 14:38:54.59

WASMのビルド作業はやたら面倒臭いが、何かビルド用ツールが出てるのかな
Linux環境じゃないとconfigureが生成できないから、プロジェクトのビルドなんてやってられないだろ
ところでWASMに64bitメモリが実装されれば可能性が大きく広がる予感

**デフォルトの名無しさん** · 2022/07/03(日) 15:41:32.49

>>180
Linuxの話題は、あわしろを召喚しちまうから、やめとけ。

**デフォルトの名無しさん** · 2022/07/03(日) 16:58:00.23

あわしろって誰？ｗ
WASMのroadmapを見ると、Firefoxが一番進んでるみたいだ
何だかんだFirefoxは開発者向けとしては最先端を走り続けているんだな

**デフォルトの名無しさん** · 2022/07/03(日) 17:11:46.18

Linuxの掟とか唱えてる人じゃなかったっけ？

**デフォルトの名無しさん** · 2022/07/03(日) 20:06:52.80

age

**デフォルトの名無しさん** · 2022/07/03(日) 20:29:55.44

>>182
あわしろ氏って誰？QZ より頭いいの？

**デフォルトの名無しさん** · 2022/07/03(日) 23:33:33.23

あわしろは、Linux 総帥

よく雑誌に記事を書いている

**デフォルトの名無しさん** · 2022/07/04(月) 01:35:21.33

マナーにうるさい
おまえはLinuxを使う資格がないが口癖

**デフォルトの名無しさん** · 2022/07/04(月) 02:35:19.54

>>177
えぐ

**デフォルトの名無しさん** · 2022/07/04(月) 07:02:36.02

>>173
＞wasi-sdk
GLESやSDL2の対応はどうなんだろ
誰かちゃちゃっと準公式サイトを作ってくれないかなw

**デフォルトの名無しさん** · 2022/07/05(火) 08:37:06.79

WASMではまだ並列処理が弱いのが悲しい所だな
Web Worker使えるけど、window配下オブジェクトが共有できないからな

**デフォルトの名無しさん** · 2022/08/05(金) 10:52:36.47

>>189
対応してないはず。

**デフォルトの名無しさん** · 2022/08/27(土) 20:19:41.17

wasm

**デフォルトの名無しさん** · 2022/09/08(木) 11:41:23.34

現在、Rubykaigi で、Ruby の Wasm 対応についての話しになっているらしい。
Ruby3.2から正式にブラウザでRubyが使えるようになる予定なので、
Rubyのインストールが難しい初心者にとっても楽になるとの事。
また、irb(インタラクティブRuby?)がブラウザでも動いて、対話的に計算
できるらしい。
Rubykaigiは、9/8から9/10の三日間の予定らしい。

**デフォルトの名無しさん** · 2022/09/08(木) 14:13:55.50

Rubyは、おわこん
とKENYAも言っている

**デフォルトの名無しさん** · 2022/09/08(木) 21:16:10.23

Ruby on Rails 7 で、Rubyの検索数が増えているらしい。
新しい変更があると、検索数が増えるみたい

JavaScript(JS), Python の検索数が多いのは、素人が多く、難しいからかも。
逆に、Rubyの検索数が増えないのは、プロが多く、簡単だからかも

Rails 7では、Hotwire などの新機能が出たので、プロも検索したのかも

米国年収では、JSが6万ドル、Railsが9万ドルと、かなりの差がある。
素人とプロの開発者の違いかも

JSは素人や個人開発が多く、
Railsは小企業から大企業まで、プロが多いのかも

**デフォルトの名無しさん** · 2022/09/09(金) 01:00:16.49

rubyのwasmに需要があるかどうかは置いといて、新技術を積極的に取り入れる姿勢は評価できる
これでもっとwasmが普及するといいな

**デフォルトの名無しさん** · 2022/09/09(金) 01:26:40.60

ブラウザ上でWasmを使うサービスやアプリならばRuby利用は遅くて重くて大きくて不利だね
だからどうしてもRubyをブラウザ上で動かしたい遊び目的だけかな
Wasm使ってプログラミングしたいならC++かRustのどちらか

**デフォルトの名無しさん** · 2022/09/09(金) 02:28:27.53

Ruby は遅くても、可読性が高くバグらないから、高品質でプログラミングしやすい。
C++, Rust などは難しさが桁違い

ビジネスでは、Rubyよりもかなり遅れる。
他社に市場シェアを取られてしまう

例えば、SASS がそう。
Rubyで作られて、C++ で作られるまで数年以上遅れた。
次に、C++で保守出来なくなって、Dart へ移った

Rubyは可読性が高いから保守できるが、
他の言語は無理で、最終的に放置されるだけ

**デフォルトの名無しさん** · 2022/09/14(水) 08:03:14.57

>>198
ところがRustはRubyに似ていて可読性が高いよ
RustはRubyとクロージャ引数の記述方法も |x| で同じだし
RustはRubyと同じようにイテレーターのメソッドチェーンを多用できるし
もちろん遅延評価されるし
Rubyよりも改善されてる点も多いからRustはRubyよりも可読性が高いよ

**デフォルトの名無しさん** · 2022/09/26(月) 11:00:46.19

>>199
Rustは俺が知ってる言語の中で、実用的な言語の中では最も可読性が低い
部類に入る。

**デフォルトの名無しさん** · 2022/09/26(月) 13:14:00.63

>>200
Rustは可読性の高さで気に入っている
ほとんどの言語と比べてイーブンか上

Wasm記述で現実的な言語の中だと更に
可読性の低いC++は論外だから
調査研究でもRustが最も使われている