>>391
>377と>>378は前提条件が違うだけでどちらも間違ってはいない

>>377 逐次処理の方が「ダウンロード処理 + ダウンロード後の処理」の実行速度が速い
>>378 一括処理の方が「ダウンロード後の処理」の実行処理が速い

だが、>>378の「実行速度は一気に実行の方が速いでしょ」はその前提を伏せて、一方的に377を間違いと断言しているので、新たな誤解の種を生んでいる
初心者は前提の違いに気がつかず、強い否定があれば「そうかもしれない」と思ってしまう
誤解をなくすには、お互いの主張が正しくなるよう、前提付きで2つの意見を列挙するのがベスト
補足するのは良いが、表現が適切ではなかった

>>394
平たく言えばそうなるが……HTML側のダウンロードはJavaScriptの実行速度ではないからそこが少し不明瞭になるのも、それはそれでよろしくないのでは

というか「実行速度は～」って表現は直後に、「JS処理を開始するタイミングが早まって全体の処理が終了するタイミングが早く見込める」という表現を推してる
前提を伏せたんじゃなく、前提と結果を噛み砕いたと思う

>>385
「javascript activexobject mediaplayer」で検索！

>>393
そうだね
特性が違うから使い分けるのもそうだし、内容によって分けて併用するのも十分あり


元レス見ると、関数の書き順ってのは関数定義の順番だよね？
そのご飯の例の場合は入れ子にはしないだろうから、そもそもその順番で書く意味がないと思う……だから慣れてても読み辛いだろうね

入れ子、例えば「炊き出しする・配膳する・献立を料理する・お米を炊く・おかずを作る・お米を盛る・おかずを盛る」の場合
お米を炊く = (){}　　//定義
おかずを作る = (){}　　//定義
献立を料理する = (){お米を炊く(); おかずを作る();}　　//定義
お米を盛る = (){}　　//定義
おかずを盛る = (){}　　//定義
配膳する = (){お米を盛る(); おかずを盛る();}　　//定義
炊き出しする = (){献立を料理する(); 配膳する();}　　//定義
炊き出しする();　　//呼び出し
みたいに書いても、慣れてると読みやすいと思う
実際には「炊き出し」→「献立」→「米炊く」→「おかず作る」→⋯⋯→「おかずを盛る」って順番で呼び出されるけどね

>>397 の場合入れ子構造はこんな感じ
炊き出し
　┣ 献立作る
　┃　┣ 米炊く
　┃　┗ おかず作る
　┗ 配膳する
　　　┣ 米盛る
　　　┗ おかず盛る

流行り廃りというものがあるからな
例えば一昔前はプリロードがプリレンダがベストとされてたけど、セキュリティ上の懸念がある事がわかって今じゃブラウザ皆力入れるの辞めちゃったし
そういうのを追って先を読む力が最も重要

>>397
>>398
すっごいわかりやすく説明してくださり、ありがとうございます。
定義した関数を処理項目？ごとにまとめて呼び出すと読みやすいですね！
こちらを参考にして、組みなおしてみます。

正解が見えず手が止まってしまってましたので、本当に助かりました。

IndexedDBに似たものでいいなら好きなように軽くラップすればいいだけじゃん
機能が過剰で煩雑と思うのであればstd:kv-storage使えばいい

>>395
>>378の一行目は余計だったと思う

>>400
初めのうちは処理を書き連ねたり1つの関数が大きくなったりなりがちだよね
でも今後もっと大きいプログラム書いていくと、それじゃどんどん肥大化して読み辛くなっちゃう

関数はどんどん部品に小分けしていくと良いから少しずつ慣れていこ

>>403
1行目無いと2行目の内容が1つ前のレスと競合して意味分からんレスになるぞ

>>405
1行目が前提無視の誤解の元だからね

>>406
〉 「実行速度は～」って表現は直後に、「JS処理を開始するタイミングが早まって全体の処理が終了するタイミングが早く見込める」という表現を推してる

前提無視じゃなくて前提を明確に区別したと思うんだけど……
対で全体になる前提の、片方だけ抜き取っちゃったらもう片方の前提が内包されないのは当たり前
そうじゃなくて、同じレスの中には全体に言及してる部分があるんだから併読するべきじゃ？

はじめてのフロントエンド開発って本でReact入門始めたんだがfirebaseの設定という全く関係ないところで躓いた・・・
npx firebase serve --only functionsを実行すると
gyp ERR! node -v v10.16.3
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
node-pre-gyp ERR! build error
〜中略〜
node-pre-gyp ERR! node -v v10.16.3
node-pre-gyp ERR! node-pre-gyp -v v0.13.0
node-pre-gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! grpc@1.24.1 install: `node-pre-gyp install --fallback-to-build --library=static_library`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the grpc@1.24.1 install script.

って１つのエラーが消えない・・・
エスパーさん助けて！！！

gypは鬼門。
これのせいでネイティブモジュールが大嫌いだった。
今はgypも問題ない環境になってるが、どうやって構築したのか分からん。
ブログにでも書いておくんだった。
ま、検索したら出てくるやろ。

>>407
JSをよく知らないみたいだけど、
イベントドリブンだから始まりと終わりは明確とは限らないんだよ

>>410
あやふや過ぎ、適当な否定なんてするんじゃないですよ
イベント駆動なのも記述したもの全てが漏れなく実行される時機が明確じゃないのも知ってるから、そのあやふやな指摘さえ間違い

そしてDOM読み込み以外のイベントで呼び出されるコールバックは今回の話には関係ない
複数のレスで想定されてるレンダリングブロックのような差異に影響しないんだから

むしろ本当に今回の話題の状況についてJSを理解できてないのはあなたじゃ？

そもそもイベント駆動部分を考慮したら始まりと終わりの差異なんて考察できないだろうに……
文脈を読まなくても今回の話題は（DOM読み込み類を除いて）イベントハンドラは関係ないと判るはず

うーん、かなり無理がある反論だね
自分の非は素直に認めたほうが印象いいよ
これでもう貴方の話は誰も信頼できなくなった

>>394で結論は出てるからなあ
その後の反論は見苦しいとしか思わない

俺は知ってる、そういうつもりで言ったんじゃない、俺の心を感じろ
後付の言い訳ばかり

>>415
本筋じゃない話を後からされたんだから後付けになるのは当然では？
その方向性なら後付けで元の方針を変えた時は叩くべきだけど、今回は当初から主張変えてない

>>414 >>413
反論じゃなくて一部の表現を否定してる
完全に同意しない意見は漏れなく全否定の反論だ、ってのは違うしそんなつもりもない

勘違いしてるからはっきりさせる
>>394 全体を否定する意見じゃなく、むしろその主張に従ってますよって方向性
>>394 の"結論・本筋の是非に影響しない"、「前提を無視して」という表現のみを否定してる

もし「反論じゃないのか？じゃあ意見の本筋に文句が無いならややこしいから物申すな」って感じたなら、二元論になりかねない

正反対ではない意見なら、対立だけじゃなくて共存してる可能性も気に留めてもらえたら良いなとか思う

>>416
意固地になって軌道修正しなくとも
そうだねで話は終わるんだよ

そんなつもりはないでは済まないのが現代の社会
受けてファーストだからよく覚えとき

>>418
そうだね、よく思えとくよ

ただネット社会の書き込みでは
行間読んでそこに書いてる以上の先読みをするのも適切な事じゃない

業務系システムで使うJavaScriptに関するオススメ本を教えて頂けないでしょうか

プロゲート、パイザとか一通り終わりましたがこの後どう勉強していけばいいでしょうか

>>419
ネット社会でどのような発言や対応が炎上して
どのような立ち振舞がうまくいくかは
先人の例から分かってるでしょ

君が自分の好き放題行動するのは勝手だけど
それで最善の結果が帰ってくると思ってるのならお花畑

>>421
何かを作れ

HTML, SASS/CSS, jQuery, Bootstrap などを学ぶ

自分のPC に、VSCode, Node.js を入れる

>>422
炎上しないで話をするのが目的のスレじゃない
だからあのレスもそんな目的のレスじゃない
初めから言ってるけど、右も左も分からないような初心者であっても、偏った情報を背負い込むことにならないようにという目的。まあ釣り合いをとっただけ

だから何故「噛みつかれたくないなら当たり障りのないレスを心掛けろ」って方向の説教をされてるのか疑問だし、それで非難される義理もない

他者を否定するコメントで釣り合いがとれると思う理由がわからないけど、彼の中では納得出来る理由があるんだろうなあ

何いってんだかね
当たり障りのないレスを心掛けるのは他者への最低限のマナーなのにね
上手く会話する気がないのならチラ裏にでも書いてろってね

文字列しか入れられんからじゃ？
構造化データJSONで入れても全体ロードしてパースだろ

形態素解析のキモはデータにあるとして
そのデータは10MB以上あるが
それをクライアントにダウンロードさせるのか？

Webアプリなんだから10MBや100MBくらい問題無いでしょ
ちゃんとキャッシュするっていう心づかいさえ守れば

あったと思うけどパッと出てこない
家帰って見つかったら貼っとく

>>430
http://github.com/takuyaa/kuromoji.js/blob/master/README.md

演算子で　!*　ってどこかでみた記憶があるんだけどどんな意味だっけ
ためしにやったらシンタックスエラーでた・・

>>435
記憶違い

kuromoji.jsのほかにrakuten MAってのもあるけど何年も更新されてないな…

イベントについて質問があります。
ロード後とスクロールをイベントとして利用する場合
スクロールをしてからにリロードをすると、ロードとスクロールの
イベントが2重で発火してしまっています。

そこで、ページトップとページの途中を判別したいのですが
何かヨサゲな方法はありますか？

特定の要素からの、スクロール位置だろ

「javascript scroll 位置」で検索！

表示画面をフルスクリーンかつ半透明にして、その下のデスクトップアプリを
そのまま操作できるようにさせることって可能でしょうか?
Web ブラウザ上での画面シェア機能作ろうとしてるんですけど、それができないと
画面シェアしながら他のアプリが操作できないんですよね。

ラジオボタンのchangeイベント監視したいんだけど
選択状態を変えるとchangeイベントが二回発生するようで原因がわからない
なんで?

forEach内でvar宣言すると、無闇に宣言が繰り返されてしまうので
よくないのかなと思い、外で宣言するようにしているのですが意味はありますか？

↓の例の以外にも変数やら配列やら、モロモロ外で宣言するようにしています。
その場合、スコープの関係で変数が親スコープ？に大量に並んでしまい
少しわかり辛い気がしています。
なので、意味がないのであれば、forEach内で宣言するようにしたいと思っています。

①forEach内で宣言
test..forEach(function(value, index, array) {
　var func() {...};
　func();
}
②
var func() {...};
test..forEach(function(value, index, array) {
　func();
}