+ JavaScript の質問用スレッド vol.126 +

**デフォルトの名無しさん** · 2018/06/02(土) 14:31:23.04

JavaScript を自ら学ぶ人のための質問スレッドです。

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。

前スレ
+ JavaScript の質問用スレッド vol.125 +
https://mevius.5ch.net/test/read.cgi/tech/1518940081/

（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）

**デフォルトの名無しさん** · 2018/12/03(月) 21:52:51.04

その記事内にもあるが、
> ウェブ開発者が文句をいう DOM の遅さは大半がレンダリング由来だったりする。
これは全くその通りで、レンダリングさえしなければDOMは遅くない。
(jQuery廚が居るから一応言っておくが、クエリもそれなりに遅い。
ただ、Reactとか使う人はクエリはほぼ全くしないはず。というかこの構成だと禁止かも？）
つまり、document.create等は十分速く（＝仮想DOM構築も速い）、レンダリングだけが遅いから、
どうにかしてレンダリングを止めさせよう（少なくしよう）というのが遅延描画だ。
それが必要かどうかは場合による。
描画しなくて済む範囲が多ければ、当然ぶっちぎりで速い。
jQueryは生JavaScriptよりも本質的に遅いから、遅延描画が効くようなら、

生JavaScriptで遅延描画>フレームワークで遅延描画>>>生JavaScriptで描画>jQueryで描画

となる。
ただし遅延描画の肝心要のoffsetTop等がこれまた致命的に遅いので、（レンダリングを要する為）
単純に遅延描画にすれば（体感的に）速くなる訳でもない。
jQueryを使ってて許されてるのなら、そのサイトはスピード狂ではないので、
遅延描画を要求されることもないのではないかな？

ただそもそも、遅延描画が効くサイト構成の所も少ないかも。
例えばアマゾン、商品一覧はいちいち「次のページ」を押して遷移するようになっている。
SPAでページ毎に商品表示部分を全面描画してる。
（ページ全体の全面描画ではなく、商品部分の全面描画。念のため）
ページ内商品点数は36なので、この程度では遅延描画はあまり効果がない。
（というか下手にやると余計に遅くなる。少なくともPC環境ではそう。モバイルだと違うかも）

俺はこういうのは無限スクロールでぐりぐりやってればいくらでも見える方が好きなのだけど、
そういうサイトは確かに少ない。
(とりあえず150点くらい表示出来るオプション付けてくれ、と思うが、そういうところもない)

**デフォルトの名無しさん** · 2018/12/03(月) 21:54:09.89

2つ目の記事ではサーチのサジェストが例に挙げられている。
この場合、エレメントが選択的に削除されるので、確かにVirtualDOMの出番ではある。
jQueryでよくやるように、宣言的に記述する場合、
サーチサジェスト部分,innerHTML= となるが、生DOMでは全面書き換えとなる。
VirtualDOMなら同じ記述でも自動的に選択的に描画してくれる為、（一般的には）速くなる。
なお、やれば分かるが、この場合の選択的描画を自前でやると結構ウザイコードになる。
自動でやってくれるのならその方が断然楽だ。

とはいえ、俺はVirtualDOMは流行らないと思う。理由は、
・そもそも遅延/選択的描画が効く構成の所が少ない
・遅延/選択的描画するにしても再描画区画は確定的であり、フレームワークを導入するまでもない
・APIが超絶イマイチ
仮想DOMなんてユーザーに意識させてる時点でアウト。
あれはcssプロパティ draw:lazy ならブラウザが自動的に対処してくれる、程度でなきゃ駄目なのさ。
実験としては面白いと思うし、今のJavaScriptで動かすなら今の実装で致し方ないが。

しかしまあそれを言ったら、jQueryが流行った理由は
・時代がそれを必要としていた
・馬鹿には丁度いい頃合いだった
であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
発狂するくらいならフレームワークとか見た方がいいと思うぜ。
使う必要はないが、何故そんなフレームワークが出てきたのか、には意味があるから。

**デフォルトの名無しさん** · 2018/12/04(火) 00:09:05.94

> であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。

そんなデータどこにもないですよね？

**デフォルトの名無しさん** · 2018/12/04(火) 00:10:53.45

>>611
> jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
> やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。

なんで遅延描画をしなければならないって
危機的状況に陥ってるの？w

まずそんなものは不要ですって認めるところから始めようか

**デフォルトの名無しさん** · 2018/12/04(火) 01:15:34.56

君が現実に目を瞑るのは自由だが、
jQueryは本質的に「絶対に速度面では勝てないプラットフォーム」だから、
まともな奴なら確実に移行する。それがいつか、の問題でしかない。

ただ書いたとおり、遅延/選択的描画はブラウザにやらせるべき物で、
自前でやっても下手にやると余計に遅くなるのも事実。
React等はおそらく実験的プラットフォームで、そこから標準化しようという算段だろうが、これはまだかなり遠い。
とはいえ、遅延/選択的描画は正しく使えばぶっちぎりで速くなるから、
ブラウザが勝手にやってくれるのなら使わない奴は居ないと思う。
勿論その時はjQueryを使っていても恩恵があるし、仮想DOMを使っている自覚も無いはずだが。
結果、仮想DOM自体がjQueryキラーになることはない。この辺が>>604の指摘だよ。

宣言スタイルで記述すると、選択的描画は出来ず、基本的に「ここから下は全部再構築」になる。当然遅い。
仮想DOMはこのときにも速度が低下しない、って話さ。
ただしこれは「生JSで遅延/選択的描画を自前で実装した場合」比だから、
jQueryを使った場合は(当然全構築するから)ぶっちぎりで遅い。
つまり、React等は最初からjQueryなんて比較相手にしてない。

勿論jQueyで遅延/選択的描画を自前で実装することも出来るけど、そんな奴は普通居ない。
この場合は自前で描画関連の全DOMへの参照を保持しており、queryの必要がないから。
そして内部状態管理バリバリのステートフルなコードになり、
jQueryを使わないと何も出来ないような奴らではどうにもならない。
実際、君は2つ目の例(サーチサジェスト）とか、全DOM再構築コードを書くだろ。

jQueryの利点はデタラメなHTMLでもなんとでもなることだが、これ自体が減りつつある。
というか、デタラメなHTMLになるのは手で先にHTMLを書くからで、
DBからHTMLを生成する場合、デタラメなHTMLを生成する方が面倒だから。
つまり、鯖がhtmlを直接配信しているのならjQueryがフィットするが、
鯖でPHP等でhtmlを生成するのなら、本来はjQueryなんて要らないhtmlを普通に吐ける。
(実際そうかは別として)
いずれにしても、jQueryロック状態はあまりよろしくはないと思うぜ。それもまた自由だが。

**デフォルトの名無しさん** · 2018/12/04(火) 04:16:52.76

いちいち長すぎだろ…要点まとめるぐらいできないのか

**デフォルトの名無しさん** · 2018/12/04(火) 06:15:12.11

>>616
お前うざいよ

**デフォルトの名無しさん** · 2018/12/04(火) 06:51:59.52

ブラウザにやらせるべきって言ってもブラウザ側にも限界があるし
PauseFrameとかその時その時のベストプラクティスを徹底するのも難しい
その辺りをケアしてくれるのがフレームワークのメリットなのだから

**デフォルトの名無しさん** · 2018/12/04(火) 08:59:31.22

>>619
現状のフレームワーク等はいい実験をしているとは思う。
ただ、描画に関してはブラウザの方が主管なので、本来は丸投げ出来るべきだ。
現行のAPIを組み合わせてもこれは無理だから現状は致し方ないとしても。

> PauseFrame
使いどころは、
A. ajaxで将来的に書き換えると分かっているframeを停止する
B. 画面外のframeを停止する
として、AはJS側でいいが、Bはブラウザが勝手にやるべきだ。

根本的な問題は、CSSが全く拡張不能なこと。CSSで
・pause: auto ならオフスクリーンの場合はpause『してもよい』
という拡張が出来れば、これが一番自然だ。仮想DOMについては、
・draw: lazy でオフスクリーンなら描画『しなくてもいい』
となる。ここら辺まで出来れば、
フレームワーク導入コストはほぼ０となり、もっと面白くなるのだけどね。

**デフォルトの名無しさん** · 2018/12/04(火) 13:03:13.41

>>620　俺の考えとしては
ブラウザは勿論最大限努力すべきだけど、プログラマがどんな書き方をしていても理論上最善に近いパフォーマンスをしてくれというのは明らかに無理があるし、
一方ある程度はブラウザ側がパフォーマンスのための機構を提示して、プログラマ側の努力を求める事も仕方ないと思う
また別の話として、CSSも数年前からJITが入ったり、ブラウザがよしなにやってくれる感は確かに高まっているけど、それと同時にHoudiniだったり従来よりローレベルな環境が提示されるようになってきておりプログラマの責任も高まってる

**デフォルトの名無しさん** · 2018/12/04(火) 17:16:44.38

で、結局のところ、重要なのはJavaScriptでいろいろ解決しましょうじゃなくて
根本的な設計を改善するほうがいい。

つまり静的なページで作れば問題は解決すると言うこと
JavaScriptを使って動きをつけなきゃいけないことなんてほとんどないでしょ？

**デフォルトの名無しさん** · 2018/12/04(火) 18:43:50.06

>>622
は？

**デフォルトの名無しさん** · 2018/12/04(火) 18:58:48.70

>>623
バカ？w

ほとんどのサイトは静的なページで事足りる

**デフォルトの名無しさん** · 2018/12/04(火) 19:03:04.87

>>624
は？

**デフォルトの名無しさん** · 2018/12/04(火) 19:17:23.97

>>621
考え方は間違っていないと思うけど、ちょっと混線してるかな？

自前で遅延/選択的描画を実装すると糞コードになるのは、
OOPで言うと、本来はオブジェクトA（ブラウザ）で完結する処理をオブジェクトB(JS)で無理に行っているからであって、
俺はそこを何とかして欲しいんだよね。
フレームワークに押し込んで隠蔽する、というのも一つの手ではあるけれど。

そちらのレスについては、単純には、
・馬鹿な書き方でもそこそこ速い
・チューニングしまくれば超速い
が通常目指すべきゴールだ。ここまではいいよな？
どちらを目指すべきかだが、両方追っかけているC++が若干迷走気味なので、
本当はどちらかに絞った方がいいんだよ。

Houdiniってことはゲーム畑に近いと思うけど、それなら当然後者を目指すべきと考え、
レンダリング制御関連のAPIがほぼ無いから困っているとは思う。
しかしそれは、APIさえ有れば十分に制御が出来る腕前があるからであって、
実際のWeb系はそこまで到達してない奴の方が多いと思う。

jQuery廚がよく言う「jQueryは簡単！」（＝馬鹿でも問題ない）というのは実は偉大なことであって、
これ自体は素晴らしい。
(jQuery廚の問題は、結局そこに乗っかってしまっていて、結果、馬鹿なままな点であって)
俺個人としては、手を抜けるところは抜きたいので、前者に寄って欲しいんだけどね。
実際は後者に寄っている気はする。
というか、前者を実装するにしてもAPIが必要だし、普通はまず後者を実装するしかないからね。

ゴリゴリの制御が要求されたとしても超高速化したいのなら、技術的にはC++側にコードを注入出来ればいい。
昔で言うアドオンをサイトから毎回ダウンロードして使う、というイメージだ。
アドオン自体はサンドボックス上ではなかったので排除されてしまったが、サンドボックス上にすれば行けるはず。
WebAssemblyが近いが、あれはJS側上のサンドボックスのはずだから、あれのC++側版だね。

**デフォルトの名無しさん** · 2018/12/04(火) 19:25:43.01

3DグラフィックスのHoudiniと勘違いしてない？
CSS拡張APIのHoudiniだよ？

**デフォルトの名無しさん** · 2018/12/04(火) 19:27:12.66

>>624
あのさ、お前のようなヴァカの主義なんか興味ないんだよ、クソ間抜け。

**デフォルトの名無しさん** · 2018/12/04(火) 19:38:52.76

>>622
君が静的なサイトしか作れないからといって、そうだと思いこむのはさすがに不味いと思うぞ。

>>624
というか、前から疑問なのだが、君は普段どんなサイトを見てるんだ？
純粋に静的なページって、今時、あまり見ないだろ。

例えば、動的な順で並べると以下か？
Amazon等ECサイト…大体SPA
2ch等掲示板…2chは糞だが、本来はDBに格納してPHP等でhtmlを生成して配信。
Yahoo等のニュースサイト…同上。更新頻度がやや低いだけ。
MDN/MSDN等…同上。さらに更新頻度は低い。でも更新機能があるからDBがあった方が楽。
ブログ…この辺から直接html配信でも行けるはずだが、実際はDB使っている方が多いのでは？
他に何がある？

DBも使わずhtmlを直接書いて配信してるサイトなんて、普段ほぼ見なくね？
零細サイトはほぼこれだから、サイト数（=仕事）だけは多いのかもしれんが。

**デフォルトの名無しさん** · 2018/12/04(火) 20:11:14.45

>>627
してる。というか、ググったらそれが出てきて、Web系の会社も記事を出してて、
OpenCVでキャンバスに描くぜ！なノリだったからそれだと思った。

そして改めてググり直した。
https://developers.google.com/web/updates/2016/05/houdini?hl=ja
う～ん。最初はこんなもんかもしれんが、
これは pause: auto や draw: lazy が効率よく出来るタイプの物ではないな。
初期のJavaScriptはこんな感じでちょこっと動きを付けていたのかも？
そしてそれをCSS側に移動しただけのような。

今のところCSSはプログラム出来ない（しない）で来ていて、それによる良さもあると思うのだけど。
勿論これが出来れば便利ではあるが、グダグダなのが増えて管理コストが増加してポシャる気が。
なんであれ「出来ることはいいことだ」という考え方もありだけど、
俺自身は「出来ることと出来ないことがはっきりしていて、使い分ける」方が管理が楽だと思っている。
なんというか、この中途半端に出来る感が、凄くJSっぽくはあるが。

とはいえ、JSは駄目だがCSSはあり、というサイトも多いはずなので、無駄に広まりそうだが。

**デフォルトの名無しさん** · 2018/12/04(火) 21:28:10.23

>>630
HoudiniはCSSの枠組みで標準化されているが、実際にはCSSというスタイルシートの仕様の延長上のものと捉えるのは間違っている
もちろん単純なCSSの拡張、柔軟化の仕様も含むが、それ以上に重大な仕様が含まれている
Houdiniとは、スタイルシートのパースから、レイアウト・ペイント・将来的には文字描画も含む
要するにブラウザのDOMレンダリングシステムをローレベルでほぼ丸ごと露出させるという
Extensible Webの精神に乗っ取ったけして中途半端ではない非常に深く広くしっかりとしたAPIだと捉えるのが正しい
pause: auto だの draw: lazy だのも素直に実現できる

>>グダグダなのが増えて管理コストが増加してポシャる
その考え方が本当に間違っている
Extensible Webは皆低レイヤーを触ろうと言ってるんじゃない
皆が求める機能を標準に追加していくのは難しいところがあるから
なんでも作れるAPIを提供してライブラリに任せましょう
そこで本当に便利なものができたら標準に組み込んでも良いねという精神だ

逆に新しい高レイヤーの機能入れたいねとなったときには、
必ずそれを構築できる低レイヤーのAPIを提供することになっている
それが最近よく聞くLayered APIと呼ばれる取り組みだ

つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
それ嫌だとしても、そういうことにしていきましょうということに、もうなっている

**デフォルトの名無しさん** · 2018/12/04(火) 22:12:04.80

この静的って、DOMを弄らないって意味ではないの？
昔ながらのPOSTで全画面更新で充分だって主張に読めたけど。
流石にバックエンド無しと取るのはちょっと変な気がする。

**デフォルトの名無しさん** · 2018/12/04(火) 22:34:21.67

いやでもapacheの説明書とかではjsもhtmlやcssと同じくスタティックコンテンツやけども…

**デフォルトの名無しさん** · 2018/12/04(火) 23:57:54.73

>>631
まあ言っていることは分かるし、その通りだが…

> pause: auto だの draw: lazy だのも素直に実現できる
表現は出来るが、これだと実際やるのはJSだろ。
つまり、今JSで実装しているReactのコードをCSSに持っていくだけであり、速度上のメリットは無い。
それでも外部APIが素晴らしく改善されるので効果はあるが、俺が欲しいのはコレジャナイ。

JSで実装する遅延描画がイマイチなのは、offsetTop等が糞遅いからで、
これは『正しい』offsetTopを要求するAPIしかないからだ。
だから、offsetTopの度にリフローを行い、未描画のDOMがないか全チェックする為、遅くなる。（多分）
ただ、遅延描画に必要なのは「そのページ以上の所まで描画済みか？」であり、
offsetTopの精度が悪くてもいい。（未描画DOMが残ってても問題ない）
そしてこの「精度の悪いoffsetTop」をAPIとして定義しろ、なんていちいちやっていてもキリがないから、
レンダラに介入させろ、というわけだ。
レンダラ内でラスタライズしている時、アドレスからおおよそのoffsetTopなんて一瞬で出せる。
当然高速化するし、きめ細かく制御出来るから、限界まで高速化出来る。
(ただしGPUにやらせようぜなんて話が出てたからそうなると一筋縄ではいかないが）

**デフォルトの名無しさん** · 2018/12/04(火) 23:58:28.93

>>631（続き）
> つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
言っていることは分かるし、確かにこれ以外に現実的路線はないが、果たして上手く行くかね？
今以上にフレームワークが乱立して、なんだかな、な状態になりそうな気がするが。
それも含めてWebだというのならそうだが、
今フレームワークを乱立させてる連中をどうにかして一ヶ所に集中させ、一ついい物を作る方が、
皆にとって幸せだと思うがな。
現状のフレームワークなんて全部死に体だし、あれでは浮かばれんだろ。

> 今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
これがかなり無理があるんだよ。
JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが、
実際はC++ヘビーでレンダラやDOMが実行時間の大半を占めてるだろ。
JS側には改善予算（改善しろ）がないんだよ。
かといって、C++側にAPIやフックを用意させるのもかなり無理な話ではあるが、
しかしJSがパフォーマンスの全責任を負うのはそれ以上に『原理的に』無理だ。

強いて言うなら、現状のブラウザは十分高速で、１ページ程度ならレンダリングは一瞬だ。
遅いのは無駄に10ページ分レンダリングしてたりするか、無駄に遅いJSを実行しているからであり、
ここら辺を遅延描画で改善してやれば可能だが、
今はこれを実装する為の「速い（が精度の悪い）offsetTop」がないんだよ。

> それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
現実的にはこの路線しかないからな。これは認める。

**デフォルトの名無しさん** · 2018/12/05(水) 00:18:53.86

きたないコード書いてそうだなあ

**デフォルトの名無しさん** · 2018/12/05(水) 00:27:04.77

>>632
すまん、それはちょっと俺が先走った。
普通の「静的ページ」は君の定義で正しいだろう。

俺は616に書いたとおり、jQueryが活躍するサイトはHTMLがグダグダな場合で、
それはhtmlを自動生成してない場合と認識しているから、
彼はjQuery廚なのもあり、先走ってしまった。

さて、実際yahooニュースをJS無しで確認してみると、
<noscript>が大量に使われているものの、どうでもいい場所ばかりだ。
これなら変にアドブロックするより、JSを切った方がいいのでは…とも思える。
SPAでもないし、ポップアップもない。リンクはいちいちページ遷移する。
これは「静的ページ」だ。

もうちょっとましな作りかと思っていたのだが、
確かにこれで大して問題ないのも事実だな。

もっとも、鯖側で動的にhtmlを生成する場合、
当然画一的なhtmlとなり、IDやclassをきっちり振ることも簡単だから、
jQueryを使う意味はほぼ無いと思う、という主張はそのままだが。
(yahooはjQuery使っているが)

**デフォルトの名無しさん** · 2018/12/05(水) 06:07:21.44

>>637
もう口閉じてろ

ここはお前のような馬鹿が議論する場じゃねぇんだよ。板違いって事知れや間抜け

**デフォルトの名無しさん** · 2018/12/05(水) 07:03:28.49

>>635
>>一ついい物を作る方が
君がそれができるというのならしてみると良い
Webは一度APIを入れると中々消すことができない
だけど流れは早いので慎重に進めすぎるわけにもいかない
それを両方解決できる人間はこの世にいない
今のまま標準に機能を入れ続けていったらそれこそカオスになる
だからそういったリスクはライブラリに押し付けるのが正しい

>>JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが
俺は今あるコードのことを言ってるんじゃない
これからは高レベルなAPIは低レベルなAPIをもとに作っていくことになるのだから
なにか新しい機能を求めたり、今まで難しかったことを素直に実現するため
Houdini含む低レベルAPI叩いたり、それを利用したライブラリを使うときは
その機能のパフォーマンスを含む責任はJSサイドに来ると言っているんだよ

**デフォルトの名無しさん** · 2018/12/05(水) 08:57:03.83

一般人「クライアントからの情報に応じてサーバーサイドでJavaやPHP、Rubyなどで動的にHTMLを生成して返すのが動的ページ、用意してあるHTMLをそのまま返すのが静的ページ」
キチガイ「Javascriptが動いてたら動的ページ！」

なぜキチガイはイカれた頭の中のオレオレ定義をその汚い口からひり出してしまうのか…

**デフォルトの名無しさん** · 2018/12/05(水) 09:46:02.65

>>639
> Webは一度APIを入れると中々消すことができない
> だけど流れは早いので慎重に進めすぎるわけにもいかない
これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
そしてWebが速いって言ったって、結果出来上がっているのはゴミの山であって、
進歩(＝成功したパス＝使えるものとして残った経路）だけ見ればC#の方が断然速い。
事実として今のJavaScriptはC#の後追いでしかないだろ。

> それを両方解決できる人間はこの世にいない
これは「創始者」がこれに近いものとして振る舞う、というのが他言語/OSSの習わしだ。
この点、ブレンダン・アイクが全く出てこないところがJavaScriptの不幸な点ではあるけれど。

とはいえ、現状で現実的判断をするなら、君の言っている方向性しかない。
ただ、カオスにはもうなってると思うけどな。
○○ってフレームワークはどうですか？みたいな質問ばかりなのがそれを如実に示してる。
標準さえ汚れなければいい、という考え方もありだが、
Promiseは要らない子だと俺は思うし、防波堤になりきれてない。

> 君がそれができるというのならしてみると良い
機会があればやるかもしれん。(これは君も同じだと思うが）
俺が今フレームワークとして欲しいのは遅延描画だけで、Houdiniでは無理だからすぐにはやらないね。
ただ、どっちかと言えば俺が試してみたいのはフレームワークではなくJavaScript自体の直接的拡張であり、
JSエンジンの低レベルAPIについて提供するような方向になっているか知ってれば教えて欲しい。
例えば async とか、ああいう言語拡張をする為のJSそのものの低レベルAPIだ。

**デフォルトの名無しさん** · 2018/12/05(水) 18:04:37.79

>>636
全くもって。

**デフォルトの名無しさん** · 2018/12/05(水) 20:58:57.31

>>641
>>これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
その場合でも旧バージョンは旧エンジンで動かせば良いのだから
しかしWebでは旧サイトは旧ブラウザで見れば良いとは言えない
JSもしかり、機能を非推奨としても、新しい機能との兼ね合いを定義しないといけないし
廃そうとしても10年以上かかる

>>結果出来上がっているのはゴミの山
WebAPIをゴミの山と言うのは流石に言いすぎだと思う
１つ１つ思い返してみても、ゴミだったねと言えるAPIはそう多くない

>>ブレンダン・アイクが全く出てこないところ
間違っている
彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
彼が慎重なおかげでJSはまだ「失敗」していない
勢いのまま進んでたら失敗していたであろう瞬間はいくつもあった

とは言え、今まで話してきたのはほとんどWebAPIについてだ
JSとWeb違う　彼がWebに口出す責任はない
そもそもWebとは皆の総意の中に秩序を見出す形で作られるものなのだから
皆がその時実現したいと思っていることを実現できるようにするのが正しいWebだ
だから流れは速い

それをプロプライエタリで創始者が全て管理するプラットフォームと比べて、あれが悪いこれが悪いというのは間違っている
なぜならそれは男がいて女がいるようなものだから
男が女らしくなったら男じゃないし、女が男らしくなったら女じゃない
男に女らしくないとか、女に男らしくないとか言うのは根本的に間違っていること
男らしいのが好きか、女らしいのが好きか、という話でしか無い

**デフォルトの名無しさん** · 2018/12/05(水) 21:01:06.04

>>641
>>○○ってフレームワークはどうですか？みたいな質問ばかり
いやいや、それが理想なのに、質問がまだまだ少なすぎるくらいだよ
というか、カオスになったら、モジュールの検索のしやすさや、そのためのスレを立てることが必要になるはずだ
でもまだそういった、「これを実現するためにどのライブラリが良いんだろう」という質問がなく、
具体的なライブラリばかり質問に挙がるのだから、全然まだまだってことだ

>>Promiseは要らない子
Promiseがどうして要らない子だと思うのかさっぱりわからない
Promiseとasync-awaitの関係は他と比べても無難で普通だ
Kotlinの用に中断可能なスレッドの組み合わせでやるのも面白いが、
基本的に「スクリプト言語である」はJSは、何かの対象を操作するためのものであって、
例えばWebならレンダリングスレッド上でイベントを受け取ったり操作したりすることが基本の動作であるから
今の仕組みになるのが最も自然と言える

>>言語拡張をする為のJSそのものの低レベルAPI
アイディアは昔から出てるが、これこそ正に流行り廃りが激しく未開拓な分野
安易に入れてしまうと後々公開するので、マクロ的な機能はずっと後
ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい

**デフォルトの名無しさん** · 2018/12/05(水) 23:32:43.96

>>643
> いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
これは技術的にはそうだが、実際はいきなりは壊してない。
JSと同じく、一旦obsoleteにして様子見し、衰退を待ちつつ、だ。
JS界隈ならちょうどjQueryと同じだ。
そこそこ互換性を壊しつつ、どのバージョンを使うかはユーザー選択だ。

だからこの意味で「メジャーアップデートのときに互換性を壊すことができる」を利点とするなら、
それはjQueryが素晴らしくフィットするわけだし、実際そうだから蔓延ったわけだろ。
ならずっとjQueryをポリフィルライブラリとして使えばいいだけだ。
実際そういう人もいるだろう。

> 彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
そうなのか。ならそれは正しい姿だ。

> 正しいWebだ
いややはり買いかぶりすぎだよ。
これは君だけではなく、最近の連中はみんなこんな感じだが。他言語も含めて。
自分が乗っかっているプラットフォームが正義だ、と思いこみたがっている。

実際の所、プロプライエタリにもオープンにもそれぞれの良さはある。
そしてWebは実質Google/MS/Appleによる準プロプライエタリだし、
C++仕様委員会の方が裾野も広くてオープンだ。
が、そもそもこんなのはどうでも良くて、
上位階層で「気に入らなければ使わない」という自由が保障されているから、
外部から見てどういう状況か明確に分かれば問題ない。
この意味で、ブラウザ上で動く言語がJSに限定されている現状は「プロプライエタリ」以上に大問題なわけだが、
お前らはこれを問題だとは認めないわけだろ。
まあこれもWebAssemblyで改善されそうだし、正しい方向に向かってはいるが。

**デフォルトの名無しさん** · 2018/12/05(水) 23:34:08.33

>>644
> 全然まだまだってことだ
なるほどそっちの立場か。それは理解した。
俺は「適切に制限されている方がいい」という立場だから、見方は異なるが、ここを合わせる必要はない。

Promiseについては君の立場なら「あり」だろう。
俺の立場なら、ほぼ async で間に合うのだから「要らない」し、
そもそもパクリ元のC#にpromiseなんて無いのに「要るわけがない」だろ、となる。
それ以前に、promiseが必要なのはいわゆるcallback地獄だが、
これも非同期なのに無理に同期的に書いた結果であって、
最初から非同期で書けばそんなことにはならないし。

> ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい
ASTは正直言って要らん。あれはローレベルすぎる。
俺が欲しいのはJSパーサに対してコードを注入出来るものと、Proxyの超豪華版だね。
ただまあ、全体的にそちらに向かっているとは理解した。

ちなみにdocument等、いわゆるグローバルをフック出来るようになるかは分かる？
ReactでJSXが必要になるのはdocumentに対する操作を全部VirtualDOM側にフックする為で、
documentそのものをフック（上書き）出来ればAPIの外面上の違いは極めて少なく出来る。
(jQueryのコードみたいに全部 $(document)してくれてれば$の上書きで簡単にフック出来るから、
jQueryはこの意味では逆転ホームランの可能性を秘めているわけだが。
というか、DOM操作を全て$()でフックしてくれてるjQueryとvirtualDOMは技術的にはかなり相性がいいはずだが、
全く話題になってないところを見ると、virtualDOMやってる連中もjQueryは死ね、と思ってるんだろうな）

**デフォルトの名無しさん** · 2018/12/06(木) 00:03:12.65

準プロプライエタリｗｗｗｗｗ
広義の強制連行ｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/12/06(木) 00:04:54.72

話が長い
プロプライエタリの意味が分かってないんだろうなぁとは思った

**デフォルトの名無しさん** · 2018/12/06(木) 03:08:30.00

>>879
お前みたいなヴァカに比べたら在日はみんな天才だよ
ITオンチ丸出しの恥ずかしいロートル野郎だな

**デフォルトの名無しさん** · 2018/12/06(木) 04:20:19.55

読んでる人偉いな

**デフォルトの名無しさん** · 2018/12/06(木) 12:44:28.29

パクリ元のC#だか言ってる時点で御里が知れてる
C#にTaskとasync-awaitの絡みが入る前からdojoでdefferedが使われている
つうかESがよく参考にしてるのはC#じゃない、.NETだろ

**デフォルトの名無しさん** · 2018/12/06(木) 22:44:18.59

流れぶった切って悪いが、
教えてくだしい。
↓を解読しようとしてるんだけど、DLしたら文字化けしてる？のときって
どうしらいいでしょうか？
ttps://d21agqkwgk4jud.cloudfront.net/MW-Common/RS4B/v0.1.9mw_2018-10-09/js/viewer_loader_v0.1.9mw_2018-10-09.js

**デフォルトの名無しさん** · 2018/12/07(金) 02:41:15.18

ttps://github.com/getify/LABjs
解読したいだけならこっち見れば良いんじゃないかな

**デフォルトの名無しさん** · 2018/12/07(金) 03:39:36.49

雑誌読み放題とかのシャッフル画像を元に戻したいなら、
ブラウザを改造して、キャンバスの描画情報を出力できるようにしちゃったほうが早い

**652** · 2018/12/08(土) 02:27:44.56

>>654
ネット配信の漫画の画像をコピーしようかと思ってるのですが、
ブラウザ改装って、javascriptでどうにかなるのですか？

>>653
LAB.jsを改造したのが使われるみたいです。

**デフォルトの名無しさん** · 2018/12/08(土) 12:53:03.79

JSでスクリーンキャプチャしてもいいが
OS上で動くキャプチャツール使ったほうが良いだろう

**デフォルトの名無しさん** · 2018/12/09(日) 09:32:12.46

>>654
>雑誌読み放題とかのシャッフル画像を元に戻したいなら、
シャッフル画像ってこんなやつか、
http://demon-uploader.rosepink.us/uploads/2018120909160154095.png
有料の漫画発信サービスって、大元の画像ってサーバーにあると
思ってたが、こんな感じで加工して、まるまる出回らないようにしてたのか
っで、javascriptのcanvasで描画し直してユーザーのブラウザに表示してんだな

オレの仕事、工業用機械のプログラム担当だから、
web業界は知らんが、漫画発信ってこんなことしてんだな

**デフォルトの名無しさん** · 2018/12/09(日) 22:09:22.03

画像でも、DL されたくない場合に、画像上で右クリック禁止などにするけど、
F12 開発者ツールを起動して、URL を突き止められて、直リンクされる

だから、コピーされたくない場合は、canvas に描く

**デフォルトの名無しさん** · 2018/12/09(日) 22:48:22.77

今どき違法サイトだとしても直リンクはしないだろ

**デフォルトの名無しさん** · 2018/12/09(日) 23:15:43.62

仮想DOMにはデメリットはないの？

**デフォルトの名無しさん** · 2018/12/09(日) 23:43:25.74

一旦仮想DOMを構築してからそれを実際のDOMに反映させるという手順を踏む以上、
ある程度のオーバーヘッドはある。
やりたいことがごく少量のDOM操作で済むような場合はかえって高くつく可能性がある。

**デフォルトの名無しさん** · 2018/12/10(月) 00:11:14.50

>>660
DOM APIと相性が悪い。
DOM APIを使って直接DOMをいじるのはご法度
いじりたい場合、フレームワークのやり方に合わせる必要がある

**デフォルトの名無しさん** · 2018/12/10(月) 00:24:42.59

>>661
メモリもりもり使いそうだね
あとSEO的にはどうなのかな？

>>662
ドラッグしてリスト入れ替えとか無理？

**デフォルトの名無しさん** · 2018/12/10(月) 01:15:42.73

>>661
指摘はその通りだが、実際はそこは問題にはならない。
体感100倍くらいDOMのレンダリングは遅いので、オーバーヘッドは1%だし、無視出来る。
それで10ページ分纏めてレンダリングしているのを遅延描画に出来れば、単純に10倍速くなる。
普通に考えて、『導入に手間がかからなければ』みんな使う。
（ただし実際の所はネットワークディレイの方が支配的で、
変に無理してSPA等するよりも物理鯖に金かけた方が効果があることもよくあるが）

最大の問題は、ブラウザが勝手にやってくれるのではなくて、手動でやれ、という点だ。

>>662
> DOM APIを使って直接DOMをいじるのはご法度
これは(jQuery含めて)DOMフレームワークの宿命だ。
というか、フレームワークの場合はフレームワークに合わせるのが当然であって、
それが必要なのにライブラリだと嘘ぶくjQueryは相当汚いのさ。

VirtualDOMは実験としては面白いが、手動でやらないといけない現状の仕様では、流行らせるのは厳しい。
自動でやってくれるのなら確実に流行る。
が、その場合は現状のvirtualDOMの知識なんて不要なレベルまで隠蔽される。
（はず。ただしJavaScriptの仕様委員会はかなり間抜けなのであまり期待は出来ないが）

**デフォルトの名無しさん** · 2018/12/10(月) 01:17:12.68

以上、間抜けの長文でしたｗ

**デフォルトの名無しさん** · 2018/12/10(月) 06:20:05.87

>>664
お前さ、長文うざいんだよ。
ここは質問用スレッドであって

テメエのプログラム論語る場所じゃねーんだよ。クソ野郎。

今すぐ消え失せろ

**デフォルトの名無しさん** · 2018/12/10(月) 10:52:32.91

>>663
これ質問だから何かお願いします

**デフォルトの名無しさん** · 2018/12/10(月) 12:31:44.90

>>666
jQuery語る奴にもいってやれ

**デフォルトの名無しさん** · 2018/12/10(月) 12:55:42.53

DOM をjQuery で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する

Vue.js から見たら、仮想DOMがすべての情報だから、
仮想DOM以外の情報は捉えられない

**デフォルトの名無しさん** · 2018/12/10(月) 13:19:29.74

DOMをAPIで変えた場合も同じ

**デフォルトの名無しさん** · 2018/12/10(月) 13:59:37.35

bootstrapはjQueryありきだからUIは自前でデザインしないといかんね

**デフォルトの名無しさん** · 2018/12/10(月) 18:13:52.48

>>667
DOM をDOM API で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する

**デフォルトの名無しさん** · 2018/12/10(月) 20:11:33.28

>>672
うーん
めんどくさいね
reactはDOM変更されたのを読み取れるから勝手に仮想も変更しといてほしいんだが

**デフォルトの名無しさん** · 2018/12/10(月) 20:24:16.30

それが仮想DOMの限界なんだよ
ウェブの標準との相性が悪い

**デフォルトの名無しさん** · 2018/12/10(月) 22:13:45.73

>>674
それは仮想DOMというよりは、フレームワーク全体の問題なのではなくて？

**デフォルトの名無しさん** · 2018/12/10(月) 22:53:24.37

触らずに済むように作ったら
触れないからダメって言われても

**デフォルトの名無しさん** · 2018/12/10(月) 23:15:27.01

その通りだな。
問題でも限界でもなく、当然の仕様であり、それが嫌なら使うな、でしかない。
というか直接いじったらフレームワーク導入の意味が無いし。

**デフォルトの名無しさん** · 2018/12/11(火) 13:17:30.38

Doodle2というスクリプトから画像を描画できるCOMコンポーネントを64ビットのwindows10で使うことは無理でしょうか？
古い32ビットのDLLなので難しいかとは思うもですが
XPで使っていて自分にはこれで十分な機能だったので
使えるのならコードも流用できるので使いたいのです

C:\Windows\System32\ にはレジスト出来ず、調べたところC:\Windows\SysWOW64\のほうに入れるこはできましたが
依存 .DLL ファイルに問題がある、っぽいエラーがでてダメでした
何かを持ってきたり頑張れば使えるようになるのか、どうやっても無理なのかだけでも知りたいのですが
さすがに今使ってる人はいないとｊは思うんですが

**デフォルトの名無しさん** · 2018/12/11(火) 14:12:20.06

+ JavaScript の質問用スレッド vol.126 +

**デフォルトの名無しさん** · 2018/12/11(火) 22:02:27.12

>>678
スレチだしそのDLLについては知らないが
https://soundengine.jp/wordpress/tips/try/555/
とかで調べたらワンチャンいけるかも

**678** · 2018/12/12(水) 21:56:56.08

まずスレチすいませんでした
こういうのをどこで質問していいかわからず、もし使ったことのある人がいるならこのスレかなと思いここにしてしまいました
どうにか解決したので報告だけさせてください

>>680
すごくヒントになりました
結局dllは不足なかったことがわかり不思議でよく考えてみたところ
wscriptのほうもSystem32のものではなく、SysWOW64の32ビットのものを指定して実行したところ問題なく使うことができました
わかってみたら単純なことでしたが思いこんでました
ありがとういございました

**680** · 2018/12/13(木) 03:26:42.51

>>681
よかったな
わしも今後の参考にするわ

**デフォルトの名無しさん** · 2018/12/14(金) 21:27:47.36

JavaScriptの非同期の書き方がまだおぼつかないのですが

var defarr = [];
for(x of list) {
var d = new $.Deferred();
$ajax(...)
.done(() => { d.resolve() });
defarr.push(d.promise());
});
return $.when.apply($,defarr);

みたいな感じでAPIからデータをとってきて画面に非同期で順番に表示する
みたいな処理があるときに
途中で中断したいときどこにどういうコードをはさめばいいんでしょうか

**デフォルトの名無しさん** · 2018/12/16(日) 20:50:25.64

中断の伝播とか真剣にやってるとやっぱり複雑になってきたときにバグるよ
手抜きして要素を非表示にしたりメインツリーから消したりして
表示までの処理は動いてるけど機能しない状態にするのが一番お手軽で安全

**デフォルトの名無しさん** · 2018/12/16(日) 21:00:20.73

requreを使っているfile.jsライブラリファイルをインポートできなくて困っています。
file.js内には「func」という関数が定義されていて
これをインポート先で呼び出したいとします。
ただし「file.js」内部にはrequireが使われていて
これに失敗します。
.htmlファイルから
scriptタグのsrc属性で読み出す。
普通なら「file.func()」で関数を呼び出せる
のですが、
requireが失敗するためにfile.jsをbrowserify
で変換しました。
変換後はrequireが使えるようになりますが
変換の影響でfile.js内部のコードが変なコードで
囲まれて内部で定義されている関数「func」
がインポート先から見つけられなくなってしまいます。
requireを内部で使っているファイルを
.htmlのscript src属性でファイルパスで読み込んで
内部の関数を呼び出すにはどうしたらいいでしょうか？

**デフォルトの名無しさん** · 2018/12/16(日) 21:19:05.88

ライブラリLAB.jsの質問
script src="LAB.js" で読み込んだあとで
$LAB
.script("jquery.js").wait()
.script("jquery.ui.js")
.script("jquery.lightbox.js")
.wait(function() {
$(document).ready(function() {
$('#gallary').lightbox();
});
});
とすると実行されるのですが、

htmlにscript src="LAB.js" を書かずに
下記にあるように、LABjsを動的に読み込むと
$LABが未定義ってなるのですが、
このように～.jsを動的に読み込んだ後ってどうすればコードが
動くのでしょうか？

load LABjs itself dynamically!
ttps://gist.github.com/getify/603980

**デフォルトの名無しさん** · 2018/12/16(日) 21:39:52.63

JavaScript の質問は、web制作管理板の方へ書き込んでください！
こちらのスレは、答える人が少ない

>>683
頼んでいた非同期処理を、中断・取り消すのか。
そういうのは、できるかな？

「javascript 非同期処理中断」で検索！

>>685
「javascript require commonjs」で検索！

>>686
「javascript 動的読み込み」で検索！

**デフォルトの名無しさん** · 2018/12/16(日) 22:18:46.36

>>687
document.onreadystatechange = function() {
if (document.readyState == "complete") {
$LAB (以下略)
}
}
ありがとうございました。これで動きました。

**デフォルトの名無しさん** · 2018/12/17(月) 11:44:23.10

これほど書き方が統一されていない言語あるかね？
function書くだけなのにいくつもパターンありすぎ

**デフォルトの名無しさん** · 2018/12/17(月) 11:48:12.21

python行けば？誰も止めないよ

**デフォルトの名無しさん** · 2018/12/17(月) 13:51:26.97

pythonは関数を書くときにdefとlambdaがある

**デフォルトの名無しさん** · 2018/12/17(月) 17:37:22.98

つまり未だにアロー記法を採用してくれないPHP最強ってことだな
何回function書かせるねん

**デフォルトの名無しさん** · 2018/12/17(月) 17:48:18.50

打つのが面倒でないならjavascriptでも全部functionで通してもええんやで。
所詮(function () {}).bind(this)の糖衣構文に過ぎない。

**デフォルトの名無しさん** · 2018/12/17(月) 18:28:11.97

入力補完でfunctionを打つのは楽だから、基本はfunction使う
アローより可読性高いから

ワンラインで済むときと、thisを受け継ぎたい時だけアロー使う

**デフォルトの名無しさん** · 2018/12/17(月) 18:44:46.88

mapとかfilterの引数もfunction渡すの？
複数行あるならともかく、一行で済むものにわざわざfunctionとreturn書くのは、可読性の観点だと逆効果のような

**デフォルトの名無しさん** · 2018/12/17(月) 18:58:59.52

>>695
> ワンラインで済むときと、thisを受け継ぎたい時だけアロー使う
> ワンラインで済むときと、

**デフォルトの名無しさん** · 2018/12/17(月) 21:20:06.41

> 所詮(function () {}).bind(this)の糖衣構文に過ぎない。

糖衣構文って素晴らしいよね

**デフォルトの名無しさん** · 2018/12/17(月) 22:29:47.87

念のため、素晴らしくないとは言ってないからな。
functionでも書けるから、そうしたいならどうぞご勝手に、という話。

**デフォルトの名無しさん** · 2018/12/18(火) 14:54:48.45

アロー使ったら複数行でもreturnなしにしてほしい
最後の行の値を返せばいいだけと思うけど、難しいのかな

**デフォルトの名無しさん** · 2018/12/18(火) 15:53:26.83

() => (
,
,
,
)

どうぞ。

**デフォルトの名無しさん** · 2018/12/18(火) 17:10:59.06

むしろアロー関数は1行でしか使えないようにしてほしいくらいだ

**デフォルトの名無しさん** · 2018/12/18(火) 18:43:12.10

yield 文って、generator function から呼び出された普通の関数の
中で使うとどうなる？

エラーになるか、それとも、あたかも、親の generator function
の中から yield 文が実行されたかのように動作するかどちら？

書き方は間違ってるかもしれないけど、こんな感じの事やったらどうなる？

function *func1() {
yield 1;
func2();
yield 3;
}
function func2() {
yield 2;
}

console.log( func1().next() );
console.log( func1().next() );
console.log( func1().next() );

**デフォルトの名無しさん** · 2018/12/18(火) 18:52:16.34

エラーになるかどうか知りたいの？
コンソールに張り付けろよ

**デフォルトの名無しさん** · 2018/12/18(火) 19:07:53.94

var aaa = func1;
console.log( aaa.next() );
・・・

みたいに修正してから、やってみたら func2() 内の yield でエラーが出た。

**デフォルトの名無しさん** · 2018/12/18(火) 19:08:58.50

>>703
そんな方法があったとは・・・

**デフォルトの名無しさん** · 2018/12/18(火) 19:31:11.55

function* func1() {
yield 1;
yield* func2();
yield 3;
}
function* func2() {
yield 2;
}

俺のESP能力が高ければこれが助けになるだろう。

**デフォルトの名無しさん** · 2018/12/18(火) 19:42:52.51

>>706
それだと、func2() も　generator function になるよね。

自分が思っていたのは、もし、普通の関数でも
yield が使えれば、JS でも、SetEvent() と WaitForSingleObject()
みたいな同期オブジェクトを作れるんじゃないかということだった。

そうすれば、wasm を使って、Windows プログラムも移植できるの
ではないかと思った。

**デフォルトの名無しさん** · 2018/12/18(火) 20:07:42.22

>>707
それは何の為に？
WebAssembly(wasm)なら移植の必要すらなく動かせる（はず）だろ。
それ以前にGraalVMなんてのも出てきたみたいだが。
> JavaScriptだけでなくあらゆる言語をブラウザで扱えるように、GraalVMをChromiumにリンクすることを考えた学生が1人います。
> https://www.infoq.com/jp/news/2018/05/oracle-graalvm-v1

>>705
インタプリタがある言語(≒スクリプト言語）なら通常のデバッグ方法だ。

**デフォルトの名無しさん** · 2018/12/18(火) 21:15:58.80

>>707
普通の関数でyieldが使えてもそれはジェネレータ関数ができること以上のことができるようにならないだろう
結局処理は同期的で待ち合わせには使えないのだから
async関数でというのなら分かるがそれはもうasync generatorがある

**デフォルトの名無しさん** · 2018/12/18(火) 23:58:38.14

やっぱ、数学ができない人にはわからないんだと思う。
ちなみにおいらは数学は主席。
今のwasmは、sleepはできるが、SetEventやMutex などを
待つことができないので、
>WebAssembly(wasm)なら移植の必要すらなく動かせる（はず）だろ。
これは違う。

すまんが、何度説明しても分からん人には分からん。
日本語の問題ではない。句読点の問題でもない。数学の問題なんだ。

**デフォルトの名無しさん** · 2018/12/19(水) 00:02:06.41

ああ、この前の数学君か
元気だな、頑張れ

**デフォルトの名無しさん** · 2018/12/19(水) 06:35:13.60

WASMはもう実験的にSABとAtomicsサポートしてるでしょ
何を知ったげに言ってるんだか