+ JavaScript の質問用スレッド vol.126 +
■ このスレッドは過去ログ倉庫に格納されています
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です） やっぱ、オレの勉強不足だな。
もっとjavascript勉強しよ。
日経ソフトウェア読んでると、javascriptに
Reactという仮想DOMとか出てきてるし
どんどん新しい技術出てきてる 仮想DOMは、なんでDOMを全部再構築するというアイデアが
出発点になってるのかわからない。
jQueryがやってるように普通に必要なところだけDOMを更新すればいいだろう 部分更新も、複数回のDOM操作がinnerHTML差し替え1回で済ませられたらメリットはあるんじゃね。 複雑になってくると毎回全部再構築した方が楽だと思うけど
昔はDOMが遅くて実現が難しいとかじゃなかったっけ 推薦書
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 VueはVue.js入門が出たから猫の方はいらんよ >>598
> 複雑になってくると毎回全部再構築した方が楽だと思うけど
> 昔はDOMが遅くて実現が難しいとかじゃなかったっけ
つまりマッチポンプってこと？
1. jQueryなどを使って必要な部分だけ構築する・・・一番速い
2. （アホな）アイデア思いついた！全部再構築したほうがいいんじゃね？・・・遅い
3. VirtualDOM使えば（jQueryほど速くないけど）全部再構築しても遅くならない！
VirtualDOMって遅くならないだけなんだよね
決してjQueryよりは速くはならない >>594
そもそも遅延描画する必要がないですよね
仮想DOM使っても結局変更部分はDOM操作をするんだから
仮想DOMを使わずに、変更部分をDOM操作すればもっと速いですよね
なんで仮想DOMは速いって嘘をつくんだろう？
遅くならないって言えばいいのに そもそも、仮想DOMの方が常にjQueryより速いと主張する奴がいるという思い込みじゃね？ 例えば>>597にも書いてますね。
> VirtualDOMの仕事ってなに？(Reactの表示速度がはやい理由)
「Reactの表示速度が遅くならない理由」と書けばいいのに
もともとDOM全部再構築なんて遅くなるような馬鹿げたことはやってないんですよ
逆にどうやってjQueryでDOM全部再構築をやれと？
めんどくさくてやってられないし遅いのでやらない
遅くなるDOM全再構築なんて馬鹿げたことをやって
遅いだろう？でもこれだと遅くないんだぜってっていうのが
マッチポンプなんですよ まぁ藁人形論法だね。
その他によく知らない初心者が勘違いしたまま質の悪いウソ情報をネットに垂れ流してるというのもある。 >>597は典型的な勘違いして垂れ流してる初心者だなｗ
こんなのよりReact登場初期の、初心者が知ったかでイキってられない時期に書かれた記事読んだ方がいい。 「今までは、基本的に受け取った情報を元にDOMを
一から作成してブラウザに描画することが多かった」
こんなことやってませんからね
サーバーを介さないクライアントだけで処理できるもの、
例えばボタンがクリックされた時に何かを行う処理は
必要最小限のDOMしか変更しないんので速い
「受け取った情報を元に」と書いてあるからAjax前提の話か
ページ遷移の時の話だろうけど、ページ全体を読み込むよりかは
一部分のほうが早いのは当然として、それはAjaxを使えばいい。
Ajaxを使って、必要最小限のところだけ書き換えるのが普通
DOMを一から作成してブラウザに描画とかしないから SPAにページ遷移という概念が存在するとは限らない
SPAはアプリケーションなのだから
ただ単純に実際のページ遷移を伴わない技術はpjaxと言ったほうが良い あれ？いつもの奴ではない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のアップデート共に改善されて最終的には限界まで端折ることになる。
この辺の、改善を外部のアップデートに期待出来ることも、フレームワーク等を導入するメリットでもあるだろ。 その記事内にもあるが、
> ウェブ開発者が文句をいう DOM の遅さは大半がレンダリング由来だったりする。
これは全くその通りで、レンダリングさえしなければDOMは遅くない。
(jQuery廚が居るから一応言っておくが、クエリもそれなりに遅い。
ただ、Reactとか使う人はクエリはほぼ全くしないはず。というかこの構成だと禁止かも？）
つまり、document.create等は十分速く（＝仮想DOM構築も速い）、レンダリングだけが遅いから、
どうにかしてレンダリングを止めさせよう（少なくしよう）というのが遅延描画だ。
それが必要かどうかは場合による。
描画しなくて済む範囲が多ければ、当然ぶっちぎりで速い。
jQueryは生JavaScriptよりも本質的に遅いから、遅延描画が効くようなら、
生JavaScriptで遅延描画>フレームワークで遅延描画>>>生JavaScriptで描画>jQueryで描画
となる。
ただし遅延描画の肝心要のoffsetTop等がこれまた致命的に遅いので、（レンダリングを要する為）
単純に遅延描画にすれば（体感的に）速くなる訳でもない。
jQueryを使ってて許されてるのなら、そのサイトはスピード狂ではないので、
遅延描画を要求されることもないのではないかな？
ただそもそも、遅延描画が効くサイト構成の所も少ないかも。
例えばアマゾン、商品一覧はいちいち「次のページ」を押して遷移するようになっている。
SPAでページ毎に商品表示部分を全面描画してる。
（ページ全体の全面描画ではなく、商品部分の全面描画。念のため）
ページ内商品点数は36なので、この程度では遅延描画はあまり効果がない。
（というか下手にやると余計に遅くなる。少なくともPC環境ではそう。モバイルだと違うかも）
俺はこういうのは無限スクロールでぐりぐりやってればいくらでも見える方が好きなのだけど、
そういうサイトは確かに少ない。
(とりあえず150点くらい表示出来るオプション付けてくれ、と思うが、そういうところもない) 2つ目の記事ではサーチのサジェストが例に挙げられている。
この場合、エレメントが選択的に削除されるので、確かにVirtualDOMの出番ではある。
jQueryでよくやるように、宣言的に記述する場合、
サーチサジェスト部分,innerHTML= となるが、生DOMでは全面書き換えとなる。
VirtualDOMなら同じ記述でも自動的に選択的に描画してくれる為、（一般的には）速くなる。
なお、やれば分かるが、この場合の選択的描画を自前でやると結構ウザイコードになる。
自動でやってくれるのならその方が断然楽だ。
とはいえ、俺はVirtualDOMは流行らないと思う。理由は、
・そもそも遅延/選択的描画が効く構成の所が少ない
・遅延/選択的描画するにしても再描画区画は確定的であり、フレームワークを導入するまでもない
・APIが超絶イマイチ
仮想DOMなんてユーザーに意識させてる時点でアウト。
あれはcssプロパティ draw:lazy ならブラウザが自動的に対処してくれる、程度でなきゃ駄目なのさ。
実験としては面白いと思うし、今のJavaScriptで動かすなら今の実装で致し方ないが。
しかしまあそれを言ったら、jQueryが流行った理由は
・時代がそれを必要としていた
・馬鹿には丁度いい頃合いだった
であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
発狂するくらいならフレームワークとか見た方がいいと思うぜ。
使う必要はないが、何故そんなフレームワークが出てきたのか、には意味があるから。 > であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
そんなデータどこにもないですよね？ >>611
> jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
> やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
なんで遅延描画をしなければならないって
危機的状況に陥ってるの？w
まずそんなものは不要ですって認めるところから始めようか 君が現実に目を瞑るのは自由だが、
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ロック状態はあまりよろしくはないと思うぜ。それもまた自由だが。 いちいち長すぎだろ…要点まとめるぐらいできないのか ブラウザにやらせるべきって言ってもブラウザ側にも限界があるし
PauseFrameとかその時その時のベストプラクティスを徹底するのも難しい
その辺りをケアしてくれるのがフレームワークのメリットなのだから >>619
現状のフレームワーク等はいい実験をしているとは思う。
ただ、描画に関してはブラウザの方が主管なので、本来は丸投げ出来るべきだ。
現行のAPIを組み合わせてもこれは無理だから現状は致し方ないとしても。
> PauseFrame
使いどころは、
A. ajaxで将来的に書き換えると分かっているframeを停止する
B. 画面外のframeを停止する
として、AはJS側でいいが、Bはブラウザが勝手にやるべきだ。
根本的な問題は、CSSが全く拡張不能なこと。CSSで
・pause: auto ならオフスクリーンの場合はpause『してもよい』
という拡張が出来れば、これが一番自然だ。仮想DOMについては、
・draw: lazy でオフスクリーンなら描画『しなくてもいい』
となる。ここら辺まで出来れば、
フレームワーク導入コストはほぼ０となり、もっと面白くなるのだけどね。 >>620 俺の考えとしては
ブラウザは勿論最大限努力すべきだけど、プログラマがどんな書き方をしていても理論上最善に近いパフォーマンスをしてくれというのは明らかに無理があるし、
一方ある程度はブラウザ側がパフォーマンスのための機構を提示して、プログラマ側の努力を求める事も仕方ないと思う
また別の話として、CSSも数年前からJITが入ったり、ブラウザがよしなにやってくれる感は確かに高まっているけど、それと同時にHoudiniだったり従来よりローレベルな環境が提示されるようになってきておりプログラマの責任も高まってる で、結局のところ、重要なのはJavaScriptでいろいろ解決しましょうじゃなくて
根本的な設計を改善するほうがいい。
つまり静的なページで作れば問題は解決すると言うこと
JavaScriptを使って動きをつけなきゃいけないことなんてほとんどないでしょ？ >>623
バカ？w
ほとんどのサイトは静的なページで事足りる >>621
考え方は間違っていないと思うけど、ちょっと混線してるかな？
自前で遅延/選択的描画を実装すると糞コードになるのは、
OOPで言うと、本来はオブジェクトA（ブラウザ）で完結する処理をオブジェクトB(JS)で無理に行っているからであって、
俺はそこを何とかして欲しいんだよね。
フレームワークに押し込んで隠蔽する、というのも一つの手ではあるけれど。
そちらのレスについては、単純には、
・馬鹿な書き方でもそこそこ速い
・チューニングしまくれば超速い
が通常目指すべきゴールだ。ここまではいいよな？
どちらを目指すべきかだが、両方追っかけているC++が若干迷走気味なので、
本当はどちらかに絞った方がいいんだよ。
Houdiniってことはゲーム畑に近いと思うけど、それなら当然後者を目指すべきと考え、
レンダリング制御関連のAPIがほぼ無いから困っているとは思う。
しかしそれは、APIさえ有れば十分に制御が出来る腕前があるからであって、
実際のWeb系はそこまで到達してない奴の方が多いと思う。
jQuery廚がよく言う「jQueryは簡単！」（＝馬鹿でも問題ない）というのは実は偉大なことであって、
これ自体は素晴らしい。
(jQuery廚の問題は、結局そこに乗っかってしまっていて、結果、馬鹿なままな点であって)
俺個人としては、手を抜けるところは抜きたいので、前者に寄って欲しいんだけどね。
実際は後者に寄っている気はする。
というか、前者を実装するにしてもAPIが必要だし、普通はまず後者を実装するしかないからね。
ゴリゴリの制御が要求されたとしても超高速化したいのなら、技術的にはC++側にコードを注入出来ればいい。
昔で言うアドオンをサイトから毎回ダウンロードして使う、というイメージだ。
アドオン自体はサンドボックス上ではなかったので排除されてしまったが、サンドボックス上にすれば行けるはず。
WebAssemblyが近いが、あれはJS側上のサンドボックスのはずだから、あれのC++側版だね。 3DグラフィックスのHoudiniと勘違いしてない？
CSS拡張APIのHoudiniだよ？ >>624
あのさ、お前のようなヴァカの主義なんか興味ないんだよ、クソ間抜け。 >>622
君が静的なサイトしか作れないからといって、そうだと思いこむのはさすがに不味いと思うぞ。
>>624
というか、前から疑問なのだが、君は普段どんなサイトを見てるんだ？
純粋に静的なページって、今時、あまり見ないだろ。
例えば、動的な順で並べると以下か？
Amazon等ECサイト…大体SPA
2ch等掲示板…2chは糞だが、本来はDBに格納してPHP等でhtmlを生成して配信。
Yahoo等のニュースサイト…同上。更新頻度がやや低いだけ。
MDN/MSDN等…同上。さらに更新頻度は低い。でも更新機能があるからDBがあった方が楽。
ブログ…この辺から直接html配信でも行けるはずだが、実際はDB使っている方が多いのでは？
他に何がある？
DBも使わずhtmlを直接書いて配信してるサイトなんて、普段ほぼ見なくね？
零細サイトはほぼこれだから、サイト数（=仕事）だけは多いのかもしれんが。 >>627
してる。というか、ググったらそれが出てきて、Web系の会社も記事を出してて、
OpenCVでキャンバスに描くぜ！なノリだったからそれだと思った。
そして改めてググり直した。
https://developers.google.com/web/updates/2016/05/houdini?hl=ja
う〜ん。最初はこんなもんかもしれんが、
これは pause: auto や draw: lazy が効率よく出来るタイプの物ではないな。
初期のJavaScriptはこんな感じでちょこっと動きを付けていたのかも？
そしてそれをCSS側に移動しただけのような。
今のところCSSはプログラム出来ない（しない）で来ていて、それによる良さもあると思うのだけど。
勿論これが出来れば便利ではあるが、グダグダなのが増えて管理コストが増加してポシャる気が。
なんであれ「出来ることはいいことだ」という考え方もありだけど、
俺自身は「出来ることと出来ないことがはっきりしていて、使い分ける」方が管理が楽だと思っている。
なんというか、この中途半端に出来る感が、凄くJSっぽくはあるが。
とはいえ、JSは駄目だがCSSはあり、というサイトも多いはずなので、無駄に広まりそうだが。 >>630
HoudiniはCSSの枠組みで標準化されているが、実際にはCSSというスタイルシートの仕様の延長上のものと捉えるのは間違っている
もちろん単純なCSSの拡張、柔軟化の仕様も含むが、それ以上に重大な仕様が含まれている
Houdiniとは、スタイルシートのパースから、レイアウト・ペイント・将来的には文字描画も含む
要するにブラウザのDOMレンダリングシステムをローレベルでほぼ丸ごと露出させるという
Extensible Webの精神に乗っ取ったけして中途半端ではない非常に深く広くしっかりとしたAPIだと捉えるのが正しい
pause: auto だの draw: lazy だのも素直に実現できる
>>グダグダなのが増えて管理コストが増加してポシャる
その考え方が本当に間違っている
Extensible Webは皆低レイヤーを触ろうと言ってるんじゃない
皆が求める機能を標準に追加していくのは難しいところがあるから
なんでも作れるAPIを提供してライブラリに任せましょう
そこで本当に便利なものができたら標準に組み込んでも良いねという精神だ
逆に新しい高レイヤーの機能入れたいねとなったときには、
必ずそれを構築できる低レイヤーのAPIを提供することになっている
それが最近よく聞くLayered APIと呼ばれる取り組みだ
つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
それ嫌だとしても、そういうことにしていきましょうということに、もうなっている この静的って、DOMを弄らないって意味ではないの？
昔ながらのPOSTで全画面更新で充分だって主張に読めたけど。
流石にバックエンド無しと取るのはちょっと変な気がする。 いやでもapacheの説明書とかではjsもhtmlやcssと同じくスタティックコンテンツやけども… >>631
まあ言っていることは分かるし、その通りだが…
> pause: auto だの draw: lazy だのも素直に実現できる
表現は出来るが、これだと実際やるのはJSだろ。
つまり、今JSで実装しているReactのコードをCSSに持っていくだけであり、速度上のメリットは無い。
それでも外部APIが素晴らしく改善されるので効果はあるが、俺が欲しいのはコレジャナイ。
JSで実装する遅延描画がイマイチなのは、offsetTop等が糞遅いからで、
これは『正しい』offsetTopを要求するAPIしかないからだ。
だから、offsetTopの度にリフローを行い、未描画のDOMがないか全チェックする為、遅くなる。（多分）
ただ、遅延描画に必要なのは「そのページ以上の所まで描画済みか？」であり、
offsetTopの精度が悪くてもいい。（未描画DOMが残ってても問題ない）
そしてこの「精度の悪いoffsetTop」をAPIとして定義しろ、なんていちいちやっていてもキリがないから、
レンダラに介入させろ、というわけだ。
レンダラ内でラスタライズしている時、アドレスからおおよそのoffsetTopなんて一瞬で出せる。
当然高速化するし、きめ細かく制御出来るから、限界まで高速化出来る。
(ただしGPUにやらせようぜなんて話が出てたからそうなると一筋縄ではいかないが） >>631（続き）
> つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
言っていることは分かるし、確かにこれ以外に現実的路線はないが、果たして上手く行くかね？
今以上にフレームワークが乱立して、なんだかな、な状態になりそうな気がするが。
それも含めてWebだというのならそうだが、
今フレームワークを乱立させてる連中をどうにかして一ヶ所に集中させ、一ついい物を作る方が、
皆にとって幸せだと思うがな。
現状のフレームワークなんて全部死に体だし、あれでは浮かばれんだろ。
> 今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
これがかなり無理があるんだよ。
JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが、
実際はC++ヘビーでレンダラやDOMが実行時間の大半を占めてるだろ。
JS側には改善予算（改善しろ）がないんだよ。
かといって、C++側にAPIやフックを用意させるのもかなり無理な話ではあるが、
しかしJSがパフォーマンスの全責任を負うのはそれ以上に『原理的に』無理だ。
強いて言うなら、現状のブラウザは十分高速で、１ページ程度ならレンダリングは一瞬だ。
遅いのは無駄に10ページ分レンダリングしてたりするか、無駄に遅いJSを実行しているからであり、
ここら辺を遅延描画で改善してやれば可能だが、
今はこれを実装する為の「速い（が精度の悪い）offsetTop」がないんだよ。
> それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
現実的にはこの路線しかないからな。これは認める。 >>632
すまん、それはちょっと俺が先走った。
普通の「静的ページ」は君の定義で正しいだろう。
俺は616に書いたとおり、jQueryが活躍するサイトはHTMLがグダグダな場合で、
それはhtmlを自動生成してない場合と認識しているから、
彼はjQuery廚なのもあり、先走ってしまった。
さて、実際yahooニュースをJS無しで確認してみると、
<noscript>が大量に使われているものの、どうでもいい場所ばかりだ。
これなら変にアドブロックするより、JSを切った方がいいのでは…とも思える。
SPAでもないし、ポップアップもない。リンクはいちいちページ遷移する。
これは「静的ページ」だ。
もうちょっとましな作りかと思っていたのだが、
確かにこれで大して問題ないのも事実だな。
もっとも、鯖側で動的にhtmlを生成する場合、
当然画一的なhtmlとなり、IDやclassをきっちり振ることも簡単だから、
jQueryを使う意味はほぼ無いと思う、という主張はそのままだが。
(yahooはjQuery使っているが) >>637
もう口閉じてろ
ここはお前のような馬鹿が議論する場じゃねぇんだよ。板違いって事知れや間抜け >>635
>>一ついい物を作る方が
君がそれができるというのならしてみると良い
Webは一度APIを入れると中々消すことができない
だけど流れは早いので慎重に進めすぎるわけにもいかない
それを両方解決できる人間はこの世にいない
今のまま標準に機能を入れ続けていったらそれこそカオスになる
だからそういったリスクはライブラリに押し付けるのが正しい
>>JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが
俺は今あるコードのことを言ってるんじゃない
これからは高レベルなAPIは低レベルなAPIをもとに作っていくことになるのだから
なにか新しい機能を求めたり、今まで難しかったことを素直に実現するため
Houdini含む低レベルAPI叩いたり、それを利用したライブラリを使うときは
その機能のパフォーマンスを含む責任はJSサイドに来ると言っているんだよ 一般人「クライアントからの情報に応じてサーバーサイドでJavaやPHP、Rubyなどで動的にHTMLを生成して返すのが動的ページ、用意してあるHTMLをそのまま返すのが静的ページ」
キチガイ「Javascriptが動いてたら動的ページ！」
なぜキチガイはイカれた頭の中のオレオレ定義をその汚い口からひり出してしまうのか… >>639
> Webは一度APIを入れると中々消すことができない
> だけど流れは早いので慎重に進めすぎるわけにもいかない
これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
そしてWebが速いって言ったって、結果出来上がっているのはゴミの山であって、
進歩(＝成功したパス＝使えるものとして残った経路）だけ見ればC#の方が断然速い。
事実として今のJavaScriptはC#の後追いでしかないだろ。
> それを両方解決できる人間はこの世にいない
これは「創始者」がこれに近いものとして振る舞う、というのが他言語/OSSの習わしだ。
この点、ブレンダン・アイクが全く出てこないところがJavaScriptの不幸な点ではあるけれど。
とはいえ、現状で現実的判断をするなら、君の言っている方向性しかない。
ただ、カオスにはもうなってると思うけどな。
○○ってフレームワークはどうですか？みたいな質問ばかりなのがそれを如実に示してる。
標準さえ汚れなければいい、という考え方もありだが、
Promiseは要らない子だと俺は思うし、防波堤になりきれてない。
> 君がそれができるというのならしてみると良い
機会があればやるかもしれん。(これは君も同じだと思うが）
俺が今フレームワークとして欲しいのは遅延描画だけで、Houdiniでは無理だからすぐにはやらないね。
ただ、どっちかと言えば俺が試してみたいのはフレームワークではなくJavaScript自体の直接的拡張であり、
JSエンジンの低レベルAPIについて提供するような方向になっているか知ってれば教えて欲しい。
例えば async とか、ああいう言語拡張をする為のJSそのものの低レベルAPIだ。 >>641
>>これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
その場合でも旧バージョンは旧エンジンで動かせば良いのだから
しかしWebでは旧サイトは旧ブラウザで見れば良いとは言えない
JSもしかり、機能を非推奨としても、新しい機能との兼ね合いを定義しないといけないし
廃そうとしても10年以上かかる
>>結果出来上がっているのはゴミの山
WebAPIをゴミの山と言うのは流石に言いすぎだと思う
１つ１つ思い返してみても、ゴミだったねと言えるAPIはそう多くない
>>ブレンダン・アイクが全く出てこないところ
間違っている
彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
彼が慎重なおかげでJSはまだ「失敗」していない
勢いのまま進んでたら失敗していたであろう瞬間はいくつもあった
とは言え、今まで話してきたのはほとんどWebAPIについてだ
JSとWeb違う 彼がWebに口出す責任はない
そもそもWebとは皆の総意の中に秩序を見出す形で作られるものなのだから
皆がその時実現したいと思っていることを実現できるようにするのが正しいWebだ
だから流れは速い
それをプロプライエタリで創始者が全て管理するプラットフォームと比べて、あれが悪いこれが悪いというのは間違っている
なぜならそれは男がいて女がいるようなものだから
男が女らしくなったら男じゃないし、女が男らしくなったら女じゃない
男に女らしくないとか、女に男らしくないとか言うのは根本的に間違っていること
男らしいのが好きか、女らしいのが好きか、という話でしか無い >>641
>>○○ってフレームワークはどうですか？みたいな質問ばかり
いやいや、それが理想なのに、質問がまだまだ少なすぎるくらいだよ
というか、カオスになったら、モジュールの検索のしやすさや、そのためのスレを立てることが必要になるはずだ
でもまだそういった、「これを実現するためにどのライブラリが良いんだろう」という質問がなく、
具体的なライブラリばかり質問に挙がるのだから、全然まだまだってことだ
>>Promiseは要らない子
Promiseがどうして要らない子だと思うのかさっぱりわからない
Promiseとasync-awaitの関係は他と比べても無難で普通だ
Kotlinの用に中断可能なスレッドの組み合わせでやるのも面白いが、
基本的に「スクリプト言語である」はJSは、何かの対象を操作するためのものであって、
例えばWebならレンダリングスレッド上でイベントを受け取ったり操作したりすることが基本の動作であるから
今の仕組みになるのが最も自然と言える
>>言語拡張をする為のJSそのものの低レベルAPI
アイディアは昔から出てるが、これこそ正に流行り廃りが激しく未開拓な分野
安易に入れてしまうと後々公開するので、マクロ的な機能はずっと後
ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい >>643
> いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
これは技術的にはそうだが、実際はいきなりは壊してない。
JSと同じく、一旦obsoleteにして様子見し、衰退を待ちつつ、だ。
JS界隈ならちょうどjQueryと同じだ。
そこそこ互換性を壊しつつ、どのバージョンを使うかはユーザー選択だ。
だからこの意味で「メジャーアップデートのときに互換性を壊すことができる」を利点とするなら、
それはjQueryが素晴らしくフィットするわけだし、実際そうだから蔓延ったわけだろ。
ならずっとjQueryをポリフィルライブラリとして使えばいいだけだ。
実際そういう人もいるだろう。
> 彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
そうなのか。ならそれは正しい姿だ。
> 正しいWebだ
いややはり買いかぶりすぎだよ。
これは君だけではなく、最近の連中はみんなこんな感じだが。他言語も含めて。
自分が乗っかっているプラットフォームが正義だ、と思いこみたがっている。
実際の所、プロプライエタリにもオープンにもそれぞれの良さはある。
そしてWebは実質Google/MS/Appleによる準プロプライエタリだし、
C++仕様委員会の方が裾野も広くてオープンだ。
が、そもそもこんなのはどうでも良くて、
上位階層で「気に入らなければ使わない」という自由が保障されているから、
外部から見てどういう状況か明確に分かれば問題ない。
この意味で、ブラウザ上で動く言語がJSに限定されている現状は「プロプライエタリ」以上に大問題なわけだが、
お前らはこれを問題だとは認めないわけだろ。
まあこれもWebAssemblyで改善されそうだし、正しい方向に向かってはいるが。 >>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は死ね、と思ってるんだろうな） 準プロプライエタリｗｗｗｗｗ
広義の強制連行ｗｗｗｗｗ 話が長い
プロプライエタリの意味が分かってないんだろうなぁとは思った >>879
お前みたいなヴァカに比べたら在日はみんな天才だよ
ITオンチ丸出しの恥ずかしいロートル野郎だな パクリ元のC#だか言ってる時点で御里が知れてる
C#にTaskとasync-awaitの絡みが入る前からdojoでdefferedが使われている
つうかESがよく参考にしてるのはC#じゃない、.NETだろ 流れぶった切って悪いが、
教えてくだしい。
↓を解読しようとしてるんだけど、DLしたら文字化けしてる？のときって
どうしらいいでしょうか？
ttps://d21agqkwgk4jud.cloudfront.net/MW-Common/RS4B/v0.1.9mw_2018-10-09/js/viewer_loader_v0.1.9mw_2018-10-09.js ttps://github.com/getify/LABjs
解読したいだけならこっち見れば良いんじゃないかな 雑誌読み放題とかのシャッフル画像を元に戻したいなら、
ブラウザを改造して、キャンバスの描画情報を出力できるようにしちゃったほうが早い >>654
ネット配信の漫画の画像をコピーしようかと思ってるのですが、
ブラウザ改装って、javascriptでどうにかなるのですか？
>>653
LAB.jsを改造したのが使われるみたいです。 JSでスクリーンキャプチャしてもいいが
OS上で動くキャプチャツール使ったほうが良いだろう >>654
>雑誌読み放題とかのシャッフル画像を元に戻したいなら、
シャッフル画像ってこんなやつか、
http://demon-uploader.rosepink.us/uploads/2018120909160154095.png
有料の漫画発信サービスって、大元の画像ってサーバーにあると
思ってたが、こんな感じで加工して、まるまる出回らないようにしてたのか
っで、javascriptのcanvasで描画し直してユーザーのブラウザに表示してんだな
オレの仕事、工業用機械のプログラム担当だから、
web業界は知らんが、漫画発信ってこんなことしてんだな 画像でも、DL されたくない場合に、画像上で右クリック禁止などにするけど、
F12 開発者ツールを起動して、URL を突き止められて、直リンクされる
だから、コピーされたくない場合は、canvas に描く 一旦仮想DOMを構築してからそれを実際のDOMに反映させるという手順を踏む以上、
ある程度のオーバーヘッドはある。
やりたいことがごく少量のDOM操作で済むような場合はかえって高くつく可能性がある。 >>660
DOM APIと相性が悪い。
DOM APIを使って直接DOMをいじるのはご法度
いじりたい場合、フレームワークのやり方に合わせる必要がある >>661
メモリもりもり使いそうだね
あとSEO的にはどうなのかな？
>>662
ドラッグしてリスト入れ替えとか無理？ >>661
指摘はその通りだが、実際はそこは問題にはならない。
体感100倍くらいDOMのレンダリングは遅いので、オーバーヘッドは1%だし、無視出来る。
それで10ページ分纏めてレンダリングしているのを遅延描画に出来れば、単純に10倍速くなる。
普通に考えて、『導入に手間がかからなければ』みんな使う。
（ただし実際の所はネットワークディレイの方が支配的で、
変に無理してSPA等するよりも物理鯖に金かけた方が効果があることもよくあるが）
最大の問題は、ブラウザが勝手にやってくれるのではなくて、手動でやれ、という点だ。
>>662
> DOM APIを使って直接DOMをいじるのはご法度
これは(jQuery含めて)DOMフレームワークの宿命だ。
というか、フレームワークの場合はフレームワークに合わせるのが当然であって、
それが必要なのにライブラリだと嘘ぶくjQueryは相当汚いのさ。
VirtualDOMは実験としては面白いが、手動でやらないといけない現状の仕様では、流行らせるのは厳しい。
自動でやってくれるのなら確実に流行る。
が、その場合は現状のvirtualDOMの知識なんて不要なレベルまで隠蔽される。
（はず。ただしJavaScriptの仕様委員会はかなり間抜けなのであまり期待は出来ないが） >>664
お前さ、長文うざいんだよ。
ここは質問用スレッドであって
テメエのプログラム論語る場所じゃねーんだよ。クソ野郎。
今すぐ消え失せろ DOM をjQuery で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する
Vue.js から見たら、仮想DOMがすべての情報だから、
仮想DOM以外の情報は捉えられない bootstrapはjQueryありきだからUIは自前でデザインしないといかんね >>667
DOM をDOM API で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する >>672
うーん
めんどくさいね
reactはDOM変更されたのを読み取れるから勝手に仮想も変更しといてほしいんだが それが仮想DOMの限界なんだよ
ウェブの標準との相性が悪い >>674
それは仮想DOMというよりは、フレームワーク全体の問題なのではなくて？ 触らずに済むように作ったら
触れないからダメって言われても その通りだな。
問題でも限界でもなく、当然の仕様であり、それが嫌なら使うな、でしかない。
というか直接いじったらフレームワーク導入の意味が無いし。 Doodle2というスクリプトから画像を描画できるCOMコンポーネントを64ビットのwindows10で使うことは無理でしょうか？
古い32ビットのDLLなので難しいかとは思うもですが
XPで使っていて自分にはこれで十分な機能だったので
使えるのならコードも流用できるので使いたいのです
C:\Windows\System32\ にはレジスト出来ず、調べたところC:\Windows\SysWOW64\のほうに入れるこはできましたが
依存 .DLL ファイルに問題がある、っぽいエラーがでてダメでした
何かを持ってきたり頑張れば使えるようになるのか、どうやっても無理なのかだけでも知りたいのですが
さすがに今使ってる人はいないとｊは思うんですが + JavaScript の質問用スレッド vol.126 + まずスレチすいませんでした
こういうのをどこで質問していいかわからず、もし使ったことのある人がいるならこのスレかなと思いここにしてしまいました
どうにか解決したので報告だけさせてください
>>680
すごくヒントになりました
結局dllは不足なかったことがわかり不思議でよく考えてみたところ
wscriptのほうもSystem32のものではなく、SysWOW64の32ビットのものを指定して実行したところ問題なく使うことができました
わかってみたら単純なことでしたが思いこんでました
ありがとういございました JavaScriptの非同期の書き方がまだおぼつかないのですが
var defarr = [];
for(x of list) {
var d = new $.Deferred();
$ajax(...)
.done(() => { d.resolve() });
defarr.push(d.promise());
});
return $.when.apply($,defarr);
みたいな感じでAPIからデータをとってきて画面に非同期で順番に表示する
みたいな処理があるときに
途中で中断したいときどこにどういうコードをはさめばいいんでしょうか 中断の伝播とか真剣にやってるとやっぱり複雑になってきたときにバグるよ
手抜きして要素を非表示にしたりメインツリーから消したりして
表示までの処理は動いてるけど機能しない状態にするのが一番お手軽で安全 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属性でファイルパスで読み込んで
内部の関数を呼び出すにはどうしたらいいでしょうか？ ライブラリ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 JavaScript の質問は、web制作管理板の方へ書き込んでください！
こちらのスレは、答える人が少ない
>>683
頼んでいた非同期処理を、中断・取り消すのか。
そういうのは、できるかな？
「javascript 非同期処理 中断」で検索！
>>685
「javascript require commonjs」で検索！
>>686
「javascript 動的 読み込み」で検索！ >>687
document.onreadystatechange = function() {
if (document.readyState == "complete") {
$LAB (以下略)
}
}
ありがとうございました。これで動きました。 これほど書き方が統一されていない言語あるかね？
function書くだけなのにいくつもパターンありすぎ pythonは関数を書くときにdefとlambdaがある つまり未だにアロー記法を採用してくれないPHP最強ってことだな
何回function書かせるねん ■ このスレッドは過去ログ倉庫に格納されています
