+ 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/11/14(水) 19:32:52.05

>>557
なんやこれ便利すぎるｗｗｗ
jQuery糖質キチガイに辟易しながらもこのスレ覗いてて良かったｗｗｗｗ

**デフォルトの名無しさん** · 2018/11/14(水) 20:52:38.60

>>544
問題あるかないかの話はしてないよ
そりゃ問題ないように作るということは幾らでもできるから
でもNodeListというクラスのメソッドとしては性質上「不自然」だって言ってるの
適当にコーディングするためのjQueryでは許されても標準では許されないよ

**デフォルトの名無しさん** · 2018/11/14(水) 21:58:20.23

jQueryが受けているのは「初心者にとって丁度いいから」というのもある。
PHPがそうだが、上級者から見ると「なんでこうした？」というのが多いが、
初心者にとってはそれくらいベタの方が使いやすい。
だからPHPも初心者受けは良い。同様に、jQueryも初心者受けは良い。ベタだからだ。
(フレームワークは初心者にとっては何をどう使えばいいかさっぱり分からない。
これがjQueryにはない、ということ。）

ただ、jQueryは低レベルすぎて、短く書けるだけで、やること/管理することが減るわけではないから、
上級者にとっては導入のメリットがない。
むしろ、依存関係が増え、記述が冗長になる（複数の書き方が混在する）という意味で悪だ。
だから、腕前を上げるに従い脱jQueryを目指すのも自然なことで、「自転車の補助輪だ」というのも当たってる。
タイピング量なんて全くどうでもいいし。

ただこれらは「上級者」に近くなってこないと理解出来ないし、
当然デザイナと話をしてても水掛け論にしかならず、話は堂々巡りだ。
ある意味、デザイナがプログラミングまで出張ってきているJavaScriptの世界が特殊なのだろう。
アプリを組めるレベルになってくるとjQueryの問題点は自明として、
それ以下だと認識出来ないから、意外にずっと使われるのかもね。ある意味PHPもそうだし。

あれは、「サイトの数」で比較するからjQueryのシェアが高く見えるんだろうな。
実際の「Web閲覧時間」での比較が出来れば一番良いのだけど、これは直接的には無理だから、
現実的には「サイト数をPVで加重平均」したものが妥当かな？
これだと実際に見られているシェアとなり、感覚的にも一致するはずだし。

>>544
> jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ
それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。

ま、NodeListについては、DOM自体がいまいちOOPに乗り切れてないことの問題ではあるが。

**デフォルトの名無しさん** · 2018/11/14(水) 22:50:55.26

> それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。

また、それがどこか答えない。
同じことの繰り返しだな。

通じない？当たり前だ
お前が何も言ってないんだから

**デフォルトの名無しさん** · 2018/11/14(水) 23:02:21.85

>>561
いやモロに書いてるがな。

マジな話、お前英語も読めないよな？語学の問題ではなくて、知能の問題で。
日本語だけ2行ずつしか読めない、ってのもあり得ないし。

それともお前の頭の中ではスコープ外で話題を追跡出来てないのか？
俺が言ってるのは当然>>525内URLの事だぞ。

**デフォルトの名無しさん** · 2018/11/14(水) 23:08:02.36

> いやモロに書いてるがな。

いつもどおり。リンクを示せば良いものを
書いていると書くだけでおしまい。
やり口がかわらんなぁｗ

**デフォルトの名無しさん** · 2018/11/14(水) 23:09:10.35

訂正
× リンクを示せば良いものを
○ 引用するなどして、具体的な箇所を示せば良いものを

**デフォルトの名無しさん** · 2018/11/14(水) 23:16:47.50

>>563
お前もいつも通り連呼リアンだよな。
普通は562は「リンクを示した」と言うぜ。

お前、煽り抜きで頭おかしいと思うぜ。マジで池沼。
同様の奴が他に2人いると書いたが、お前が一番程度が酷い。
さすがにそれだとリアルの普通の会話も成立しないだろ。

**デフォルトの名無しさん** · 2018/11/14(水) 23:22:14.41

>>564
英語読めるつもりなんだろ？自分で読めよ。
というか、あれ、脱jQueryが気になる奴は、読む価値はあると思うぜ。

お前は読んでも全部読むうちに忘れちゃうんだろうけどさ。
それでもお前の頭は交換不可能で、お前自身で鍛えるしかないんだから、
無い頭使って一生懸命読めよ。
それを繰り返してたら、お前のその頭も少しはましになるよ。

**デフォルトの名無しさん** · 2018/11/14(水) 23:27:59.81

なお、GitHubの公式声明の内容は割と普通のことなので、
普通に脱jQueryを実行出来る人は特に読む意味はありません。

何故脱jQueryなのか？に疑問を持つ人は、読む価値があると思います。

**デフォルトの名無しさん** · 2018/11/14(水) 23:32:34.35

だから、GitHubの声明には本来書いてあるはずのjQueryをなくして
その結果、何が得られたかが「書いてない」ってのが、注目する点なんだってばｗ

**デフォルトの名無しさん** · 2018/11/14(水) 23:49:27.00

>>568
お前はそれを連呼しているが、実際そうじゃない。

やっぱりお前、英語も読めないよな。まあ、当然か。
語学以前に論理/記憶がお前の頭にはないからな。

まあ、そういう池沼レベルの奴でも使える、というのはjQueryの利点ではあるよ。
お前も>>409で指摘している点だ。
Excelだって数式までは宣言型で逐次処理無し（順序の概念無し）なのでアホでも使えるし。

**デフォルトの名無しさん** · 2018/11/15(木) 00:17:06.64

はい、想定通りのレスきました

**デフォルトの名無しさん** · 2018/11/15(木) 00:22:47.33

>>552
なるほど、childNodesか
https://dom.spec.whatwg.org/#dom-node-childnodes

**デフォルトの名無しさん** · 2018/11/15(木) 00:29:18.03

>>550
昔のIEが対応外になっている時点で関係ない
そして、俺はDOM API不要論者(>>540)に反論しただけなので、あなたのは論点がずれてる

**デフォルトの名無しさん** · 2018/11/15(木) 00:47:30.01

いつものインタビュー貼っておきますね
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

**デフォルトの名無しさん** · 2018/11/15(木) 00:58:36.39

>>553-557
自分のPC にサーバーを立てて、サーバー経由でアクセスしないと、
ブラウザからでは、CORS でアクセスできない

例えば、自分のPC 内のHTML ファイルを、ブラウザで起動して、
そのページから、5ch へアクセスできない。
iframe 内に読み込んでも、iframe 内外が、別ドメインだからアクセスできない

ruby -run -e httpd . -p 8080

1-liner で、Web サーバーを起動して、そのindex.html からは、別ドメインにもアクセスできる

**デフォルトの名無しさん** · 2018/11/15(木) 01:02:00.51

>>572
そして、俺はDOM API不要論者(>>540)に反論しただけなので、あなたのは論点がずれてる

そうだね。俺のレスへの返信じゃなかったわｗ
俺はDOM API不要論者じゃないので。

俺は >>550にも書いてあるように混ぜて使って良い派
むしろ普段から混ぜて使っているんだよ派か
（jQueryで出てくるthisはDOM要素だから）

**デフォルトの名無しさん** · 2018/11/15(木) 01:03:57.60

>>574
オリジンが違うんだから出来ねーよ

**デフォルトの名無しさん** · 2018/11/15(木) 15:35:01.66

オリジンが違ってもアクセスはできるだろ
取得した中身が読み取れないだけ

**デフォルトの名無しさん** · 2018/11/15(木) 17:42:32.99

アクセス拒否されるし取得できない。
何いってんだコイツ

**デフォルトの名無しさん** · 2018/11/15(木) 20:16:01.66

何いってんだコイツはお前だアホ
await fetch('https://developer.mozilla.org/',{mode:'no-cors'})
アクセスしてるだろうが
もし拒否されるのならServiceWorker導入ページでどうやって
外部リソースをリクエストしたりキャッシュしたりするつもりなんだ？
人様にケチ付ける前に自分が無知であることを知れよ

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

元々の文脈考えたらアクセスできない、で良くね？
オリジン違えば非同期通信でAPIのレスポンスは取ってこれない
jsonp対応してれば行けるだろうがそれはまた別の話だ

**デフォルトの名無しさん** · 2018/11/16(金) 01:36:26.11

>>579
そもそも文法エラーだなそれ。
出直してこいｗ

**デフォルトの名無しさん** · 2018/11/16(金) 03:07:01.97

> 人様にケチ付ける前に自分が無知であることを知れよ
で自分を人様って言ってるのも色々アレ

**デフォルトの名無しさん** · 2018/11/16(金) 03:15:01.26

まあそれは煽りでよく見る

**デフォルトの名無しさん** · 2018/11/16(金) 05:29:59.60

>>580
元の文脈的にサムネイルとかのメディアデータへのリンクが分かるのなら
それはimgやvideoタグで表示されられるかも

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

JAVAscriptと書くのは普通ですか？
ネットで見たのですが

**デフォルトの名無しさん** · 2018/11/18(日) 23:02:17.55

好きに書けばいいんです

**デフォルトの名無しさん** · 2018/11/19(月) 08:23:17.32

JaVa$cRiPt

**デフォルトの名無しさん** · 2018/11/29(木) 23:02:47.57

勉強にのためにライブラリのjplayerを解読しようとしてるが
難しすぎる。
おまえら、javascript勉強してるってこは
ライブリとかもすらすら読んでわかるの？

**デフォルトの名無しさん** · 2018/11/29(木) 23:33:09.60

>>588
前提でJQueryとかの知識がいるからじゃない？
こういうやつとか初心者が試行錯誤でやったやつの方がわけわからん
https://qiita.com/ryuichi1208/items/f9e6ac2b99bbe4fc82d3

**デフォルトの名無しさん** · 2018/11/29(木) 23:41:56.52

jQuery使わなかったらもっと難解になるんだよな

**デフォルトの名無しさん** · 2018/11/30(金) 00:00:53.52

>>588
覚えればすむものは楽なんだよ。
単に覚えればいいだけ理解すればそれで終わりなんだから。

大変なのは>>589みたいなもの。ありえないほど短いコードで
実現しているから凄いといわれるけど一般的にはクソコードと言われる類。

なぜかというと、コードというのは簡単に読めるものじゃないといけない
もちろん知識をつけたもの、能力がある人にとってね。

知識があって能力がある人でも読むのに時間がかかるような
無駄な処理ばかりで何をやってるか分からないようなものは大変
それが「解読」という作業。これはコードに問題がある。

知識がなくてわからないのは解読じゃなくて単に読めないだけ
読んでる人に問題がある

**デフォルトの名無しさん** · 2018/11/30(金) 08:44:57.62

7行テトリスは、まるで暗号

jQuery のCSS セレクターを学べば？
基本的には、# . > など、Emmet と同じ

Ruby のNokogiri でもよい

**デフォルトの名無しさん** · 2018/12/02(日) 13:56:14.24

やっぱ、オレの勉強不足だな。
もっとjavascript勉強しよ。
日経ソフトウェア読んでると、javascriptに
Reactという仮想DOMとか出てきてるし
どんどん新しい技術出てきてる

**デフォルトの名無しさん** · 2018/12/02(日) 16:53:20.50

仮想DOMは、なんでDOMを全部再構築するというアイデアが
出発点になってるのかわからない。
jQueryがやってるように普通に必要なところだけDOMを更新すればいいだろう

**デフォルトの名無しさん** · 2018/12/02(日) 16:55:13.96

なるだけ参照透明にしたいからじゃない？

**デフォルトの名無しさん** · 2018/12/02(日) 17:19:20.90

部分更新も、複数回のDOM操作がinnerHTML差し替え1回で済ませられたらメリットはあるんじゃね。

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

>>594
遅延描画したいからだよ。以下参照。
https://qiita.com/risagon/items/019942c60e9c3e6c05a5

**デフォルトの名無しさん** · 2018/12/02(日) 17:53:11.92

複雑になってくると毎回全部再構築した方が楽だと思うけど
昔はDOMが遅くて実現が難しいとかじゃなかったっけ

**デフォルトの名無しさん** · 2018/12/02(日) 17:59:05.26

>>598
jQuery死ね

**デフォルトの名無しさん** · 2018/12/02(日) 20:39:03.60

推薦書

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発、
花谷拓磨、2018/10/17

基礎から学ぶ Vue.js、mio、2018/5/29

Node.js超入門、掌田津耶乃、2017

Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう
野口将人・倉見洋輔、2017

入門 React ――コンポーネントベースのWebフロントエンド開発、2015

Reactビギナーズガイド ――コンポーネントベースのフロントエンド開発入門
Stoyan Stefanov, 2017
https://github.com/stoyan/reactbook

初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017

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

VueはVue.js入門が出たから猫の方はいらんよ

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

>>598
> 複雑になってくると毎回全部再構築した方が楽だと思うけど
> 昔はDOMが遅くて実現が難しいとかじゃなかったっけ

つまりマッチポンプってこと？

1. jQueryなどを使って必要な部分だけ構築する・・・一番速い
2. （アホな）アイデア思いついた！全部再構築したほうがいいんじゃね？・・・遅い
3. VirtualDOM使えば（jQueryほど速くないけど）全部再構築しても遅くならない！

VirtualDOMって遅くならないだけなんだよね
決してjQueryよりは速くはならない

**デフォルトの名無しさん** · 2018/12/03(月) 08:40:10.65

>>594
そもそも遅延描画する必要がないですよね
仮想DOM使っても結局変更部分はDOM操作をするんだから
仮想DOMを使わずに、変更部分をDOM操作すればもっと速いですよね

なんで仮想DOMは速いって嘘をつくんだろう？
遅くならないって言えばいいのに

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

そもそも、仮想DOMの方が常にjQueryより速いと主張する奴がいるという思い込みじゃね？

**デフォルトの名無しさん** · 2018/12/03(月) 09:07:38.44

例えば>>597にも書いてますね。

> VirtualDOMの仕事ってなに？(Reactの表示速度がはやい理由)

「Reactの表示速度が遅くならない理由」と書けばいいのに

もともとDOM全部再構築なんて遅くなるような馬鹿げたことはやってないんですよ
逆にどうやってjQueryでDOM全部再構築をやれと？
めんどくさくてやってられないし遅いのでやらない

遅くなるDOM全再構築なんて馬鹿げたことをやって
遅いだろう？でもこれだと遅くないんだぜってっていうのが
マッチポンプなんですよ

**デフォルトの名無しさん** · 2018/12/03(月) 09:08:21.84

まぁ藁人形論法だね。
その他によく知らない初心者が勘違いしたまま質の悪いウソ情報をネットに垂れ流してるというのもある。

**デフォルトの名無しさん** · 2018/12/03(月) 09:11:08.96

>>597は典型的な勘違いして垂れ流してる初心者だなｗ
こんなのよりReact登場初期の、初心者が知ったかでイキってられない時期に書かれた記事読んだ方がいい。

**デフォルトの名無しさん** · 2018/12/03(月) 09:19:09.58

「今までは、基本的に受け取った情報を元にDOMを
一から作成してブラウザに描画することが多かった」

こんなことやってませんからね

サーバーを介さないクライアントだけで処理できるもの、
例えばボタンがクリックされた時に何かを行う処理は
必要最小限のDOMしか変更しないんので速い

「受け取った情報を元に」と書いてあるからAjax前提の話か
ページ遷移の時の話だろうけど、ページ全体を読み込むよりかは
一部分のほうが早いのは当然として、それはAjaxを使えばいい。
Ajaxを使って、必要最小限のところだけ書き換えるのが普通

DOMを一から作成してブラウザに描画とかしないから

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

SPAだと自前でページ遷移作ることになるやろ

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

SPAにページ遷移という概念が存在するとは限らない
SPAはアプリケーションなのだから
ただ単純に実際のページ遷移を伴わない技術はpjaxと言ったほうが良い

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

あれ？いつもの奴ではないjQuery廚が沸いている？

が、まあいい。
そもそも素人向けの解説は当然色々端折るので厳密にはそれなりに間違いを含む。
これは至極当然だ。それに対して発狂しても意味がない。
それらは、「このレベル向けの解説ならこの程度で妥当か？」で判定されるべきだ。
この点、俺は597はまあまあだと思うが。

そもそも詳しく分かるんなら、もっと詳しい解説をググればいいだけだ。以下とか。
http://steps.dodgson.org/b/2014/12/11/why-is-real-dom-slow/
https://postd.cc/the-inner-workings-of-virtual-dom/

jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
だったらフレームワークにしちゃおうぜ、という話であってさ。

俺はReactが実際どこまで端折っているのかは知らんが、(使ってないし、使う予定もない）
上記2つの記事が正しければ、限界まで端折っている。
> React は処理を省いたコンポーネントの render() を呼びださない。 (1つ目のリンク）
> フローチャート内、renderはど頭の処理 (2つ目のリンク）
仮に現状では限界まで端折れていないとしても、
Reactのアップデート共に改善されて最終的には限界まで端折ることになる。
この辺の、改善を外部のアップデートに期待出来ることも、フレームワーク等を導入するメリットでもあるだろ。

**デフォルトの名無しさん** · 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業界は知らんが、漫画発信ってこんなことしてんだな