2ちゃんねる スマホ用 ■掲示板に戻る■ 全部 1- 最新50    

JavaScript情報交換所(プログラミング既習者専用)

1 :デフォルトの名無しさん:2015/12/07(月) 07:26:33.87 ID:NYLGCW0V.net
実際にJavaScriptを書いている人の情報交換所です。
プログラミング既習者専用です。初心者の方はご遠慮下さい。
玄人の方、歓迎致します。

2 :デフォルトの名無しさん:2015/12/07(月) 07:27:56.10 ID:7ldc1+VM.net
↓ こちらへどうぞ

【JavaScript】スクリプト バトルロワイヤル52【php,py,pl,rb】 [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1443578172/

3 :デフォルトの名無しさん:2015/12/07(月) 13:08:45.86 ID:ZskqcMPL.net
JavaScript リファレンス - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference

4 :デフォルトの名無しさん:2015/12/07(月) 21:04:06.51 ID:Pr/O+rrT.net
(1) プログラミング既習者専用です。初心者の方はご遠慮下さい。(大事なことなのでry
  ここで言う初心者とは、3,000行のプログラムを動かすのにも苦労する人達のことです。
  なお、JavaScriptの習熟度は問いません。
  言語を問わず、3,000行程度なら楽勝であれば問題ありません。
(2) 初心者だと思える投稿は無視してください。初心者用スレは他に沢山あります。
(3) 質問スレではありません。特に初心者からの質問はガン無視でお願いします。
(4) 長文が読めない低脳はお引き取り下さい。

【リンク集】
https://developer.mozilla.org/ja/docs/Web
https://msdn.microsoft.com/ja-jp/library/yek4tbz0.aspx (JavaScript)
http://hakuhin.jp/js.html (逆引き)
http://stackoverflow.com/

他仕様書等のリンクは質問スレのテンプレを参照してください。かなり整備されています。
プログラミング既習者であれば、MDNとMSDNでほとんど事足ります。
ブログ等は間違いが多すぎるので、MDNのサンプルコードから出発することを薦めます。
逆引きなら上記hakuhin.jp、困った場合はstackoverflowが秀逸です。

【初心者用スレ】
JavaScript の質問用スレッド vol.118 (ム板質問スレ)
http://peace.2ch.net/test/read.cgi/tech/1429634108/
ECMAScript デス 5 (ム板仕様スレ)
http://peace.2ch.net/test/read.cgi/tech/1449027632/
【超初心者用スレ】
JavaScript の質問用スレッド vol.127 (Web制作板質問スレ/頻繁に分裂中)
http://peace.2ch.net/test/read.cgi/hp/1448293871/

テンプレは>>1>>4

5 :デフォルトの名無しさん:2015/12/07(月) 21:06:06.02 ID:Pr/O+rrT.net
[状況]
Web制作板はIDが出ないのでアフィカス/teratailerが暴れている感がある。
「1〜10まで足す」みたいな質問にも回答が付くという奇妙さだ。
また、ライブラリ厨の意味無い布教活動も嫌がられている。
個人的には低脳アフィカスが一番の癌だと思うが、
奴らは印象操作が目的なので反論されても喚きちらすだけ。
もう超初心者スレとして分離するしかない。
回答する奴も初心者なのでデタラメだらけだが、あいつらにはそれでも問題ない。
明らかに間違っている事を正しいと言い張る馬鹿共を矯正する方法は2chにはない。

ム板の質問スレはIDが出るので、逆に言えばIDが出て困る奴はいない。
ほとんど流れていないが、質問すればWeb制作板と同レベル以上の回答は付く。
まともな回答を期待するのならこちらに投稿した方がいい。ただし回答が付くまで時間がかかる。

Web制作板の方はIDが出たら困る奴が「流れているスレ」として見せるために無理矢理流している感がある。
このため、上記のように、ただ単に無視すべき投稿にもレスが付く、どうしようもないスレになっている。
また、どうでもいい一般論を投げかけ、無理矢理流そうとしているものも散見される。
やりたい放題やられているわけだが、しかしその先には何もないように思えてならない。
何がやりたいのかはかなり疑問だ。ただ、止める方法もないので、分離するしかない。

仕様について厳密に詳細を確認したければECMAScriptスレがいい。
正直、他も含めてJavaScriptスレ住民の仕様に対するこだわりは異様だと思うが、
逆に言えば、厳密に議論したければ相手はそこにいる。
ただしそいつらは仕様にはすごく詳しいが、コードは記述していないらしく、
何が本当に問題なのかを実感できていない。
だから地に足のついていない議論になってしまう。
とはいえ、詳しいことは事実だ。だから仕様について正確を期すのならそこがいい。

6 :デフォルトの名無しさん:2015/12/07(月) 21:36:46.92 ID:Pr/O+rrT.net
以上、どうしようもないスレばかりなので新しく「プログラミング既習者専用」スレを立てることにした。
現時点でまともな奴がほぼいないので、新しく訪れてくれる人を待つことになる。
気長な話になるが、やらないことには始まらないので、とにかく始めることにする。

3,000行についてだが、OAOOはもちろん徹底しているとして、
1,000行なら勢いで書いてしまえる規模だ。
ところが3,000行となると、内部構成をある程度マトモに設計していないと破綻し始める。
逆に言えば、内部設計を正しく行い、かつ実装できる人の目安として3,000行を楽々、とした。

7 :デフォルトの名無しさん:2015/12/07(月) 21:39:35.47 ID:Pr/O+rrT.net
[状況追加]
11/28に立てたスレ(同スレタイ)
http://peace.2ch.net/test/read.cgi/tech/1448714123/
が何故か1週間で落ちたので、もう一度立て直した。

2ヶ月以上書き込みがないスレもこの板にはあるので、書き込みが無くて落ちたわけではなさそうだ。
削除依頼も確認してみたが、該当はなかった。
質問スレがvol118, vol124と完全に被っているのに放置されているため、重複削除でもない。
原因が不明のため、とりあえず再び立てて様子見することにした。

一応7日ほどは持っていた(はず)なので、4-5日程度毎に俺が話したい案件を上記前スレ
http://peace.2ch.net/test/read.cgi/tech/1448714123/4-7
からコピペしてきて落とし、これでしばらく持たせる。
もちろんそれ以前に話題があれば勝手に開始してくれて構わないし、
俺の案件についてレスを付けてくれれば応じる。

このスレの狙いは、まずは人を集めることだ。だから半年以上持たせる必要がある。
あの質問スレの状況だと、まともな上級者はウザがって寄りつかない。
上級者を集めたいのなら、彼等にとって読む価値のあるスレを用意して待たなければならない。
これには時間がかかる。機能するには半年以上かかるだろう。
しかし、やらないことには始まらないので、とにかく始める。

出来るだけ落ちないように努めるが、いかんせん基準が分からないのでまた落ちるかもしれない。
その場合は再び立て直すが、それにしても落ちまくるのは問題なので、
基準を知っている人がいたら教えて欲しい。

8 :デフォルトの名無しさん:2015/12/08(火) 09:13:19.90 ID:DJ+OQKIp.net
>>7
10レス未満だと落ちるよ

9 :デフォルトの名無しさん:2015/12/08(火) 09:14:10.74 ID:DJ+OQKIp.net


10 :デフォルトの名無しさん:2015/12/08(火) 09:14:58.16 ID:DJ+OQKIp.net


11 :デフォルトの名無しさん:2015/12/08(火) 21:57:28.55 ID:lwK5Kg+O.net
>>8
ありがとう。了解した。
とはいえ予定は7の通り。

12 :デフォルトの名無しさん:2015/12/11(金) 22:17:41.43 ID:D3bPQRrf.net
>>8
EMCAスレが落ちているのを確認した。
10スレ未満は丁度1週間で落ちるようだ。

それはそうと、現実問題として上級者がJavaScriptにはいない(いにくい)のかもと思うようになった。
元々は単なるヘルパースクリプトで、質問スレ見ても分かるとおり、単発の修正とかに使われていた。(はず)
今なら「PHPでやれ」と回答すべき案件等と言えば分かりやすいか。
Ajax以降は必要となれば大型化するが、クライアント側に大型データ構造を持つ使い方は自然ではない。
MMORPG等をWebGLで実現するにしても、クライアント側は描画に徹してデータはサーバ側に送るのが普通だ。
だから内部構造にこだわるべき中級者以上が育たない(必要ない)環境なのかもしれない。
あるチームでサーバクライアント型アプリ(ゲームでもチャットでもいいが)を作るのなら、
サーバ側に実力者を振り分けなくてはならないのは自明だ。

とはいえ、出てくるかどうか待ってみることにする。
ググれば分かるとおり、奴らはQiitaが好きみたいだが、俺は匿名の方がいいと思っているので。
とはいえ、匿名掲示板はどうしても雑音が多すぎる。
彼等がQiitaのほうを好むのなら、いくら待っても空振りで終わる。
それでも俺は試してみるが、盛大に空振りするかもしれないのでそのつもりで頼む。

13 :デフォルトの名無しさん:2015/12/13(日) 21:10:31.93 ID:l4buRphf.net
JavaScript 「再」入門 - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/A_re-introduction_to_JavaScript

14 :デフォルトの名無しさん:2015/12/15(火) 20:58:50.84 ID:tWI33UQV.net
ECMAスレに居た人と実際にコードを書いてる人は層が違うと思うけどな。
言語仕様を愛する人と、WebAPI技術を愛する人と、フレームワークを愛する人は違うだろうし。

15 :デフォルトの名無しさん:2015/12/15(火) 22:49:00.04 ID:Lzs/Av6i.net
>>14
ああ、あれは明らかに違う連中だ。少なくとも俺と同じ側ではない。

プログラミングなんて本来は手段、従ってプログラミング言語は包丁であって、
もちろん包丁職人やコレクターもいていいが、道具として使う料理人が一番多いのが普通。
しかし彼等は異様に細部にこだわっている。彼等は何者だと思う?

そもそも仕様仕様とうるさいのだが、仕様の細部なんて使わないのが普通だと思うのだが。

Q. String が期待される関数 function func(str) に対して Array が与えられた場合はどうするべきですか?
A1. 当然暗記している型違い時の変換規則を活用し、適切に対処します。
A2. それはただのバグです。

型付き言語だとそもそもA1はコンパイルが通らない。
俺は型付き言語出身だから、当然A2で組んでいる。使う予定のない変換規則なんてどうでもいい。
ところが彼等はこれじゃ駄目だと喚く。
でも具体的にどう活用すればメリットがあるのかは示せない。
何なんだよいったい、と思う。


ところで連中は立て直さないのかな?

16 :デフォルトの名無しさん:2015/12/15(火) 23:46:05.86 ID:bVMdPRVE.net
>>15
それはダックタイピング系のことをちょっと大げさに捉えすぎて無いかい?
それと引数の型についての選択肢としては
A1.何も気にしない
A2.極力活用するよう努力する
A3.型チェックをしてエラーとする
の3つだろう。
例えばpromptの返り値のstrに対する処理をコードにするとこう
A1. str.slice()
A2. (str||'').slice()
A3. if(typeof str!=='string')throw 'No!';str.slice()

で、
A1派は、メソッドを持っていればそれで処理をさせて問題ない。
null等は自動的にエラーになるのでちょうどいい。

A2派は、どちらにしろ空の値はpromptをやり直したり別途特別な処理するんだろうから
nullなど無効も極力エラーは出さず空の値と評価してやるくらいがちょうどいい。

A3派は、来て欲しい型でなければエラーとするのが最も安全。

というような主張だろうが、君はどんな主張で、どんな主張に納得してないの?

17 :デフォルトの名無しさん:2015/12/16(水) 00:04:47.52 ID:4ol9X0cq.net
また型が把握できる場合と、何が来るか本当にわからない場合では当然スタンスが違うと思う。
後者でいうと、Stringが期待される場面でArrayが来た場合なんてどうしようも無いだろうが、
Arrayを期待する場面なら他のArrayLikeなオブジェクトもArrayとして見てやるべきじゃないかという論になる。

そこで、また派閥が分かれるだろう。
何もしないまたはエラーとする(Array.isArray)(Arrayだけしか面倒を見ないから)、イテラブルだけ面倒見る([...arg])か、
多くのArrayLikeを面倒見る(Array.from(arg))か、何もしないまたはエラーとする(例えArrayに変換できなくともArrayのメソッドを持っていればよい)
また、配列の使い道によっては@@isConcatSpreadableを考慮するかどうかも問題になってくるだろう。

18 :デフォルトの名無しさん:2015/12/16(水) 00:25:57.22 ID:bKnAvTte.net
まあ本当にそっち系の人はこんなもんじゃないか。
Object.prototype.toString.call(arg) == '[object Array]'
とArray.isArrayの違いとどちらが適切かを語るレベルまでいけば一人前か。

まあ彼らは意味に敏感なんだろう。
配列を期待するといっても、配列はいろいろあるし、期待の仕方もいろいろある。
なまじいろいろ知ってるだけに細部に拘りたくなるのだろう。

19 :デフォルトの名無しさん:2015/12/19(土) 02:38:04.74 ID:BBkFE1FJ.net
都合上、>>7の前スレの内容を先に全て落とす。
以下4投は転載。

20 :前スレ4:2015/12/19(土) 02:38:56.06 ID:BBkFE1FJ.net
とりあえず俺が話したい項目を挙げておく。
気になる物があれば勝手にレスを付けてくれ。
もちろん他の誰かが勝手に始めてくれても構わない。
俺も気になれば勝手に参加するし、どうでもよければ無視する。

使い方は基本的に他のスレと同じ、ただし初心者お断り、だ。

21 :前スレ5:2015/12/19(土) 02:39:25.80 ID:BBkFE1FJ.net
・コーディングストラテジー
http://peace.2ch.net/test/read.cgi/hp/1444186237/550
http://peace.2ch.net/test/read.cgi/hp/1444186237/562

JavaScriptに於けるコーディングストラテジーだが、単純には以下2つのどちらかだと思われる。

α. 安全重視、全箇所で型/値チェック。
β. 簡素化重視、最初に型チェック、以降は「型」までは確定、値については保証無し。

αは関数単位で抜き差しが可能。その点機能の追加/削除は楽だ。
各関数は型判定等を持つため複雑になるが、安全領域を管理する必要がない。

βは期待される型以外では何も考える必要がないため、その分関数の仕様が小さくなり、
デバッグが楽でバグも出にくく動作も速くなる。ただし、型チェックを既に通っているかを管理する必要がある。
ネットワークに於けるファイヤウォール内/外の管理のようなものだ。
基本的に関数毎の抜き差しはできない。型チェック部分+動作部分のセットでやらないと駄目だ。
だから関数単位での粗結合化はできない。

俺はβでやっている。
そして現実的にはβしかないように思えるのだが、どうか?
可能であれば直接本職の方々の意見が聞きたいが、
JavaScriptはソース見放題だから、企業のサイトのソース(=本職製)からの類推でもいい。
ダックタイピングを生かすのなら多分αじゃないと駄目なのだが、
俺は型システムに慣れているというのもあって、今のところダックタイピングの利点を感じられない。
αだと各関数で様々な型を処理しなければならず、これがバグの元になるので、
最初からStringならStringと決めうちで各関数を用意、Stringしか入力されないように上位階層で対応している。

22 :前スレ6:2015/12/19(土) 02:39:52.02 ID:BBkFE1FJ.net
・プロトタイプの活用
静的クラスでは出来なくて動的プロトタイプでは出来ることを使って、何かできないか。
今思いつく中では、以下がある。
A. 動的プロトタイピング(__proto__の頻繁な変更)
B. インスタンスツリー
C. 親への透過的アクセス(親に動的に追加されたプロパティに対する透過的アクセス)

Aは変更自体はやっているが、頻繁に変更する需要がないのでそれ以上試していない。
Bは現在試しており、見にくくなる以外の弊害はない。見にくさについてはデバッグ用環境を整えて対応した。
メリットはフィールド共有によるフットプリント削減だが、
しかしこれはあらかじめ共有すると分かっていれば静的クラスでも出来る。
デタラメに共有したりしなかったりする場合も、
共有する派生クラスと共有しない派生クラスを用意すれば、静的な場合は対応可能になる。
従ってどうしてもというのならやはり動的なものに限られてしまうのだが、これは需要がない。
Cは試したいところだが需要がない。

従って、仕様としては出来るが、実際の需要がなく、活用できていない。
他の活用案もあれば是非。

23 :前スレ7:2015/12/19(土) 02:40:19.96 ID:BBkFE1FJ.net
・ダックタイピングの活用
共通基底クラスを持つ場合、当然ポリモーフィズムできるとして、
ダックタイピングの場合は、共通基底クラスを持たなくても、共通の名前のメソッドがあればポリモーフィズムできる。
だからといっても、活用案がないので、事例があれば是非。

24 :デフォルトの名無しさん:2015/12/19(土) 02:41:08.31 ID:BBkFE1FJ.net
以下、全て>>16の定義で。

>>16
こちらは基本A1で組んでいる。初段はA2もあり得る。
理由は>>21のとおり、入力段で型を確定させる方が楽だと判断しているから。

JavaScriptの場合、型が確定しないのはDOMか鯖からの入力に限られる。
だから最初の段で型を確定させ、以降は型確定で組んでいる。
この場合、型確定エリアと型不確定エリアが明確に分離されるので、型確定を忘れるとおもむろにバグる。
しかしこれは前述のように限られており、見落としたりする心配はほぼ無い。

型を不確定のまま伝搬させるのは余計に難しい。だから通常あり得ない。
となるとA2/A3が必要なのは「どこから呼ばれるか分からない」という関数だけになる。
(型不確定エリアからの直接呼び出しがあり得る)
これについてはプログラムを見てそういうことがないように確認すればいいという事にしている。

というわけなのだが、どうかね?
A2/A3は関数の機能としてはA1のスーパーセットになる。型が予想外の時の分だけ仕様が大きい。
だからA1で組んでしまうのが楽だ。問題は見落としがある可能性が残る点。ただし、これは見やすい。
A2/A3の場合は見落としは考える必要はないが、
個々の関数が全ての型について設計通り動くことが求められるので、
テスト項目が多くなり、またバグを誘発しやすいと見ている。

ちなみに、「何が来るか分からない時でも正常動作」というのは、考えていない。
というか、その時はバグっていいという判断だ。
・入力が明確に間違っている場合、再入力を求める。誤入力状態での表示はどうでもいい。
・Ajax結果が不正の場合、リロードする必要がある。このときも表示はどうでもいい。
所詮はヘルパースクリプトだから、この辺で留めている。

25 :デフォルトの名無しさん:2015/12/19(土) 02:42:15.14 ID:BBkFE1FJ.net
>>17
それはダックタイピングだと思うが、正直俺はその点に関しては気にならない。
期待通り動けば何でもいい。
気になる人は例えばtoString()の解釈について、
・ダックタイピングだ。toString()があるから使えるだけ。
・各型についてtoStringというインタフェースが実装されているのだ。
・toString()はテンプレート関数で、各型についてオーバーライドされているのだ。
と考えることが出来るかもしれないが、俺はどれでもいいと思っている。
JavaScriptはthisを関数側に持たせているため、callを使って他型のprototype等を間借りすることが出来る。
これは便利ではあるが、しかし真面目にインタフェース等で実装すれば済むことが大半だ。
だからこの方式もthisがいちいちはがれてbindしなければならない方が面倒だ。
classシステムのようにインスタンス側にthisを持たせる方が理に適っているように思う。

26 :デフォルトの名無しさん:2015/12/19(土) 02:42:41.90 ID:BBkFE1FJ.net
Array.from()を実装したとして、それがどこまでの範囲で使えるのかは「使う側が確認する必要がある」とする。
つまり、callで突っ込むのは勝手だが、ちゃんと動くかは「確認しろよ」ということだ。
その手の動作範囲を広げていくのは、YAGNIとかKISSとか言われるらしいが、大体無駄に終わる。
だからArray.fromの実装側は自分が使う最小限に留めて良く、間借り側が正常動作を保証しろと考える。
これはおそらくJavaScriptの思想とも合致している。
ArrayのメソッドはgetElementsByTagName等で返されるCollectionに対しても大体動作するが、
動作の保証はしていない。
つまり、間借り側(Collectionでcallする側)が正常動作を保証(確認)する必要がある。
クラスシステムの場合、実装してあれば確実に動作するし、実装していなければ動作はしない。(間借りも出来ない)
JavaScriptの場合は、使えそうなら使ってねといういかにも曖昧な感じで、それでいいのか?という疑問はあるが、
上記のように、「バグってたらリロードでおk」ならこの方が色々楽なのは事実だ。

結局の所、出自が(というよりも今も大半の用途でも)チョロスクリプトなので、それ向けに仕様がチューニングされている。
これで大規模なプログラムを組むのがそもそも無理がある、ということなのだとは思う。
チョロスクリプトとして使う分には、なかなか面白い仕様だと思う。

27 :デフォルトの名無しさん:2015/12/19(土) 02:43:14.27 ID:BBkFE1FJ.net
>>18
それは同じだと思うが、違うのか?
=== なら以下にポリフィルとしてそのまま記載されている。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray
== の場合もその場合は危険性がないように思える。
ただし、これについては俺は真面目にやってないので自信はない。
ただ、そもそも「文字列との比較は === 」というのが lint で引っかかるので、常にそうすればいいだけだ。

> なまじいろいろ知ってるだけに細部に拘りたくなるのだろう。
これはあると思う。
あれだけ仕様が小さくて頭の中に入りきるサイズだから、というのはかなりあると思う。
C#やJavaなら調べながらのコーディングになるので、気にしてられない。

28 :デフォルトの名無しさん:2015/12/19(土) 04:44:14.14 ID:WePRjNql.net
>>26
問題はArrayが少し変わったオブジェクト程度であること
そしてArrayのメソッドは、ArrayLike(この場合lengthを持つもの)について保証していて最初からそのように作られている
JSにおいて配列の最も基本的な定義はlengthプロパティに要素の長さを記録しているもの程度のことでしかない
当然DOMの配列でも動くし、型付配列でも動く
それなのにわざわざArrayだけでしか動かなくする必要があるのか?

ここがミソで、わざわざArray以外にも対応する、のではなく、わざわざ対応しないようにするのかと考える
Array.isArrayは型付配列すらtrueを返さない
isArrayは配列がどうかのチェックではなく、Arrayかどうかのチェックだ

配列を扱うとする関数でArrayだけに絞るのはJSにおいて必ずしも十分ではないということだ
その関数を作る目的と使われるシチュエーションを考慮しないといけない

>>27
@@toStringTagをお忘れかな?
===の件もそうだな
どうして必要もない制限をわざわざするのか?と思ってしまう
というのは半分ウソで、実際は他の演算子と文字数が違うものを基本で使うのは気持ちが悪いから==を基本で使う
経験上==を基本で使ったからといってバグになるようなことはない
型変換のバグは予想外に同値判定で通ってしまうことよりも、予想外に通らない事のほうが圧倒的に多いのだから

29 :デフォルトの名無しさん:2015/12/20(日) 00:52:32.40 ID:wOVtY/I0.net
>>28
> そしてArrayのメソッドは、ArrayLike(この場合lengthを持つもの)について保証していて
> isArrayは配列がどうかのチェックではなく、Arrayかどうかのチェックだ
これは「isArray は Array.prototype の動作を保証するかどうかを返す」と考えていいのか?
これならまあ使える仕様だ。

ちなみに確認したが、DOMのCollectionについては isArray は false になる。
実際の所、このCollectionは無理矢理Array的アクセスが出来るように見せかけただけのものであり、
書き換え不能にしてあるから、例えば Array.prototype.splice.call(DOMのCollection,1,1) は(エラーを返さないが)動作しない。
だから辻褄は合っている。
まあ正直、「動作しないのならエラー返せよ」と思うが。以前はまった。

> @@toStringTagをお忘れかな?
ああこれは知らなかったからだね。
これも自然な仕様だが、だとするとMDNもちょっと書き換えたほうがいい気はするが。

30 :デフォルトの名無しさん:2015/12/20(日) 00:53:42.58 ID:wOVtY/I0.net
> 経験上==を基本で使ったからといってバグになるようなことはない
> 型変換のバグは予想外に同値判定で通ってしまうことよりも、予想外に通らない事のほうが圧倒的に多いのだから
まあ実際はそうなるはず、というかそれを目指して型変換規則が作られているはずなので。
実際のコードを見ると、==派と===派は半々という感じか。
一応googleのコーディング規約には === を使えと明記されていたはずだが、今見ると無い。
削除されたか、或いは俺の勘違いかだが、しかし日付を入れてないからどっちか分からない。
https://google.github.io/styleguide/javascriptguide.xml
この手のドキュメントのリリース日が辿れないってマジで馬鹿なのかあいつら。
というかこの辺で色々文化が違って無駄にストレスが溜まる。

俺は見た目はどうでもいい派なので、文字数の違いとかは気にならない。
俺が組んだところは基本的に === でも動くようにしてあるので、全部書き換えてもほぼ問題ないはず。
実際は歴史的経緯で混在しまくり、今更書き換えてデグレードするのは避けたいので、放置している。
ただJavaScriptの本来の設計は == なのだと思う。
(基本 == で、真に必要がある場合は === で)

31 :デフォルトの名無しさん:2015/12/20(日) 00:54:09.55 ID:wOVtY/I0.net
とはいえ、実際の所、他言語だと「潜在バグ」を嫌うので、===推奨になるのも分かる。
というか、おそらくそちらの方がプログラミングとしては正道だ。
JavaScriptの仕様は、「チャキチャキ作ってサクッとリリース」向けであり、「バグがないプログラミング」向けではない。
とはいえ、Webにはこれが正しいのも事実。
マイナーバグに対する作り込みでリリースが遅れるくらいなら、
バグがあってもクリティカルでないのならリリースした方がWebにはいい。
相手は「今欲しい機能」を求めているのだから。
逆に「バグのないプログラム」を目指すのなら、基本===ベースで行った方がいい。
相手は「将来欲しい機能」を求めていて、そこにバグがあっても困るという人だから。
ここら辺は置かれた状況の違いで文化の差異が発生していると考えている。

> わざわざArray以外にも対応する、のではなく、わざわざ対応しないようにするのかと考える
これが典型で、「100%動く保証」が必要か、「99%動けば問題ない」とするかだ。
見た目動いているからいい、を是とするか非とするかとも言える。
テストで100%網羅できることはない。
バグが無いことを目指すのなら、対応している事が確認できなければ使えない。
Array.isArrayでそれが確認できるのなら、それは使える仕様だ。

32 :デフォルトの名無しさん:2015/12/20(日) 00:54:39.34 ID:wOVtY/I0.net
@@toStringTagの件でも思ったが、まだ「ローカルプロトタイプ」は出来ないのか?
クラスシステムモドキで頑張っているようだが、元々prototypeを拡張するように設計されており、
実際の所、それの方がどう考えても使い勝手がいい。
だから、prototype.jsが流行ったというのも分かる。
問題はプロトタイプ汚染が発生することで、
逆にいえば、ローカルプロトタイプが規定できて汚染が発生しないのなら、おそらくそっちの方がいい。
とはいえ、今でも手動で __proto__ 等を使って設計できそうではある。
誰もこれをしないのはまた別の問題があるのか?

jQueryにしてもバージョン混在の問題があり、もちろん回避策もあるわけだが、
そもそもjQueryをローカル読み込み出来れば問題なくなるはず。
システム的にはスコープチェーンを辿っていく方式なので、
関数単位でのローカルプロトタイプは出来るように思えるが。

@@toStringTagについては、誰かが書き換えた影響が自分にも出る可能性があるということだと思うが、
この手のプロトタイプ汚染っぽいものを言語的に排除できるようにして、
prototypeを自由に拡張するのが本来のJavaScriptの思想だと思うのだが。

元々一人で組むチョロスクリプト用だからその機能がなかったのは仕方ないとしても、
無理矢理クラスにしようとしていて手こずっているように見える。
ローカルプロトタイプの方が多分この言語的には似合うだろう。
誰もやろうとしていなさそうなのは、何か別の問題があるのかな?

33 :デフォルトの名無しさん:2015/12/20(日) 04:56:15.02 ID:xspa4nJy.net
>>29
無理やりArray的アクセスが出来るように見せかけただけのものというより、
DOMのコレクションはそれはそれで立派なArrayとは違う配列。
そしてslice等の破壊的メソッドが通らないのは、見せかけだからではなく、
凍結された配列だから破壊的操作を受け付けないから。(エラーは返す)
>>32
プロトタイプ汚染というのはビルトインを拡張するときくらいしか問題にならない。
それすらもES6モジュールで分離すれば解決するだろう。
それと、自由に「.prototype」を拡張することではなく自由に「プロトタイプ」を定義できることこそが、
インスタンスベースと見た時のJSの思想だと思う。

34 :デフォルトの名無しさん:2015/12/21(月) 01:11:35.42 ID:RcNL5yk7.net
>>33
ふむ。もう一度確認してみたがエラーにはなるようだ。
確認してから書いたのだが、どうやら間違っていたらしい。すまん。


> それと、自由に「.prototype」を拡張することではなく自由に「プロトタイプ」を定義できることこそが、
> インスタンスベースと見た時のJSの思想だと思う。
多分これは違う。
> 自由に「.prototype」を拡張する
これでは既存のクラスシステムと同じだ。
「自分で型を作れる」または「『新規の』型を自分で作れる」だけに過ぎない。

JavaScriptのプロトタイプベースは、「既存の」型を拡張できるところが違う。
ただこれを活用できるかはまた別だ。
これはMDNでも紹介されている。
> これはとても強力です。
> JavaScript では、プログラム上でいつでもどれかのプロトタイプを変更することができます。
> ということは、実行時に既存のオブジェクトに対して追加のメソッドを加えることができるのです:
> (中略)
> これは Person オブジェクトをデバッグするときに役立ちます:
> https://developer.mozilla.org/ja/docs/Web/JavaScript/A_re-introduction_to_JavaScript
ただしデバッグ時以外に活用する方法を誰も思いついていないのだと思う。

35 :デフォルトの名無しさん:2015/12/21(月) 01:12:01.84 ID:RcNL5yk7.net
ある実行中のJavaScriptがあって、それに対してevalでprototypeの変更を行えば、
仮に鯖上で実行中であってもいきなり動作を変えられる。これは他の言語では出来ない。
XenやVMWareがやっているようなライブマイグレーションを言語がサポートしている。

ただそんな機能があっても現実的には必要ない。
サーバーを一旦落としてデバッグ済みのソースに切り換えるのが今の通常の方法だ。
どうしても落とせないところは、今は上記のようにハードウェアレベルでライブマイグレーションができる。
だからソフトウェアレベルでのライブマイグレーションは必要ない。

一応文法的にもprototypeを拡張する方向で出来ている。
クラスに対して色々な書き方があるが、好みはあるとしても、
文法的/構造的に一番無理なく書けるのは prototype への直接差し込みだ。
だからMDNでもその記法で書かれている。
元々 prototype を拡張しながら使うように設計されているので、当然ではあるのだが。
> var Person = function (firstName) {
> this.firstName = firstName;
> };
>
> Person.prototype.sayHello = function() {
> console.log("Hello, I'm " + this.firstName);
> };
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Introduction_to_Object-Oriented_JavaScript

36 :デフォルトの名無しさん:2015/12/21(月) 01:12:28.39 ID:RcNL5yk7.net
> プロトタイプ汚染というのはビルトインを拡張するときくらいしか問題にならない。
> それすらもES6モジュールで分離すれば解決するだろう。
しかし@@toStringTagの件はそれだろ?
俺は「そんなの書き換える奴が悪い」で終わりだが、
それが許されないから ==='[Object Array'] では駄目で Array.isArray なんだろ?
ただ import で自由にビルトインも含めて拡張できるのであれば、
上記「禁忌」とされてきて開かずの扉になっている部分を、誰かこじ開けるかもしれない。

37 :デフォルトの名無しさん:2015/12/21(月) 05:09:36.07 ID:hMKGO21d.net
==='[Object Array'] では駄目で Array.isArray は良いとかではなく、
@@toStringTagを考慮してあげるか、そこまでしないかの差だというつもりで差があると言ったんだよ。
そもそもisArrayもProxyは通すからね。別にisArrayに通ったからといってそれがArrayの動作をすることまで保証されていない。
起源がArrayだという程度の意味しかない。
それで十分な場合も多いと思うが、より良い配列の判定がある場合も多いという話がしたかったのだよ。

あと、ビルトインの@@toStringTagが書き換えられた場合というのを、良い悪いで判断するのも自分の感覚と合わない。
そういった行いを尊重しようとするか、しないかの判断ではないかな?
それとprotoypeというのはあくまでnew演算子が活用するだけのものであって、
それ以外に特別な意味はないし、プロトタイプベースの一角でしか無い。
一番大事なのはプロトタイプを変更できること。

それと動的変更は別に動いてる最中ではなく、変更をかけてから動かすという方が主だろう。
コンパイル言語ではなく、Web上で不規則かつ非同期にいくつものスクリプトが読み込まれ実行されるものなので、
何かを拡張したりするには、実際に動きながらするのが最も妥当な方法だ。

38 :デフォルトの名無しさん:2015/12/23(水) 00:27:11.83 ID:fUoT5vqI.net
ここは「言って欲しい意見」を期待できるところではない。それは諦めろ。
さすがにそれだと本当に書いているのか疑問だ。
色々ツッコミどころはあるが、一つずつ行こう。

> あと、ビルトインの@@toStringTagが書き換えられた場合というのを、良い悪いで判断するのも自分の感覚と合わない。
> そういった行いを尊重しようとするか、しないかの判断ではないかな?
ビルトインの@@toStringTagの書き換えを尊重する場合って、具体的にどんなケースがあるんだ?
俺はこれはコーディング規約で禁止にされるべき項目だと考えている。

39 :デフォルトの名無しさん:2015/12/24(木) 07:58:45.60 ID:Y5sNONvq.net
>>38
「言って欲しい意見」を期待とはどういうことだ?
そちらがこちらの話した意図を正しく捉えて無かったようなので補足したまで。

そしてコーディング規約で禁止とかいうのが考え方狭すぎだろう。
JSはハックやパッチにも使うもの。
Arrayの@@toStringTagを書き換えたのなら、それ自体がほぼ目的の
それはArrayをStringTagで判定しているところに通さなくしたいというケースも有るだろうし、

一方大規模開発でStringTagに追加でメタ情報を付与して活用しようとするケースも有るだろう。
例えばArrayのStringTagを"Array:Any"とかにして、
int8型配列のを"Array:Int8"、他の自作配列を"Array:Hoge"にし、
デバッグや補助関数で活用するということも出来るだろう。

40 :デフォルトの名無しさん:2015/12/24(木) 18:11:12.05 ID:k1/8SWkC.net
まあ自分が今回JSらしさとかtoStringTagらしさをどのように語っているのかというと、
仕様の定義に根拠を置いているんだよね。
緩いJSとは言え本当にすべきでないようなことや悪いことは仕様で禁止されている。
逆に禁止されていないのであれば、原則活用することは罪ではないと考える。

例えばtoStringTagはWritableがfalseだから通常無意識に書き換えられるようなものではないが、
Configurableはtrueなので強い意志があれば書き換えて良いものとなっている。
一方コンストラクタのprototypeプロパティはConfigurableがfalseだ。
これはJSにおいてprototypeプロパティのないコンストラクタはコンストラクタとして最低限成り立たない、
もしくはprototypeプロパティのないコンストラクタはJSらしくないからだ。
こういった改変をしようとするのは悪だと考える。

まあ互換性によって残っている良くない仕様というのもあるので、全て価値観を仕様に頼って良いわけではないが、
toStringTagなんてものはES2015において新しくよく話し合われて入れられたものであり、
その様々なシチュエーションで使えるようにしてくれた意志は尊重すべきだと思っている。

これが土台で、勿論その上に事案毎にコーディング規約やらが来る。

41 :デフォルトの名無しさん:2015/12/26(土) 19:51:45.07 ID:WET3gKUy.net
「Microsoft EdgeのJavaScriptエンジンを、ChakraCoreとしてオープンソース化する」

Windowsがオープンソース化される予兆 - 阿久津良和のWindows Weekly Report | マイナビニュース
http://news.mynavi.jp/articles/2015/12/21/windows10report/
2015/12/21

42 :デフォルトの名無しさん:2016/01/10(日) 21:23:23.77 ID:TMApyOC8.net
具体的なコードをもとに話を進めてくれないと、
何がやりたいのかさっぱりわからない
文字数は出来るだけ切り詰めて原則箇条書きとかね
一般論をダラダラやられても困る

43 :デフォルトの名無しさん:2016/01/12(火) 17:09:01.34 ID:O9Go0Lwy.net
適当に例を挙げての具体的な話などしても意味は無い
具体的であればあるほど答えは誰が見ても決まってるのだから
そもそもその手の人達が一般的にどうしてそういう行動するのか共感ができないというから
その原理と一般的な信条、思考パターンを述べる展開になっている

44 :デフォルトの名無しさん:2016/02/08(月) 22:51:41.45 ID:vWC/lFUG.net
C言語信者な元ゲームプログラマーで今有明海の漁師です。
C言語信者なのは、スピード命!スクリプトとかCPU資源浪費しすぎだろ!
って思ってるから。
そんな私が、手持ちAndroid7インチタブレットで漁業用GPSロガーを使いたくなって
Google Maps API を触ってみた。

凄え。。。
Javascriptでなんでもできるじゃん・・・まじかよ・・・
Androidアプリ書こうかと思ったけどJavascriptでいいわ。
PCからも見れるしね。
まだ航跡記録とかマーカー記録とか作ってない中途半端な状態だけど
休みの日に酒飲みながら機能追加していくの楽しすぎるw
http://www13.plala.or.jp/tarna/maps/ariakekai/index.html
有明海を見てね。
長崎県と熊本県の間の内海です。

45 :44:2016/02/08(月) 23:02:40.71 ID:vWC/lFUG.net
あ、ちなみに、表示してる緯度経度は日本測地系です。
漁業用のGPSが今もみんな日本測地系を使ってるので。
携帯もスマフォもGoogleMapも世界測地系なので変換してます。

46 :デフォルトの名無しさん:2016/02/09(火) 23:20:54.03 ID:JuURpG1d.net
>>44
見た。
てか、きっちり書いてあるなあ。

Cから見ればJavaScriptなんて超大富豪プログラミングだからね。
ただ、JavaScriptのユルさはなかなか良いとは俺も感じる。
ブラウザでお気軽GUIできるのもいい。

とはいえ、その規模で収まっているうちはいいが、
これからバシバシ機能追加していくのなら、JavaScriptのアレな点が見えて嫌いになるかもw

47 :デフォルトの名無しさん:2016/02/10(水) 09:11:00.33 ID:FkM1RfeE.net
>>46
JavaScriptは今じゃ、ブラウザの言語でとどまってないからね。

1.Electronでマルチプラットフォームアプリを作成できる
2.CordovaでiOSやAndroidアプリを作成できる
3.Node.jsを使って、Raspberry Piのようなハードウェア制御ができる
4.同じくNode.jsを使って、PHPの代わりにサーバサイドの制御ができる

1粒で5度美味しいプログラミング言語です。緩いが故に大変な部分も
あるけれど、基本的にはライブラリを活用する事でその辺を軽量化でき
るしね。

48 :デフォルトの名無しさん:2016/02/11(木) 01:04:16.07 ID:3e/IE9s+.net
>>47
嫌いな人も多いが、俺もnodejsの便利さにいまさらびっくりしてる。
eureca.io使って、クライアントとサーバが双方まるで直接呼んでるみたいにfunction呼び出しして、あまつさえコールバックまで出来るとは、とビビるくらい。

49 :デフォルトの名無しさん:2016/02/11(木) 09:19:41.38 ID:pPotq0xY.net
>>48
言語の弱点をライブラリ群がカバーしてくれてるから、助かるよね。
支持されていなかったら、そのライブラリ達もいないわけで。

50 :デフォルトの名無しさん:2016/02/11(木) 16:07:05.01 ID:3e/IE9s+.net
>>49
あとは、プロトタイプベースで魔改造する余地があったのも大きいのかも。
普通の言語で、基底クラスを基底クラスのままメソッド追加するとか、上書きする、なんて今までの言語では頭おかしいって言われそうなユルさかつ、
言語仕様としてシングルスレッドじゃん→なんかコールバックさせる仕組みを外に持たないとね→実装
みたいな魔に魔を重ねた改造の結果、使いやすくなってるような気がする。

51 :44:2016/02/12(金) 01:30:54.19 ID:ZoV9Wx9d.net
>>46
距離を計算するGoogleMapsライブラリに
グローバルで保持してる中心座標を渡したらエラー。。。
new 座標(global中心座標)して渡したら通る。。。どういうこと?

っていうか、渡す時も、受け取る時もnewしないとエラーが出ることがあるんだけどなんだこれ・・・
javascriptの仕組みを理解できてないね・・・orz

newで受け取った値を代わりに使ったら、前の値はメモリに残るだろうし
ガーベージコレクションは自分でしないといけないのかなぁ。
富豪だし無視してもいいかなぁw

もうちょっと遊びながら勉強してみます(汗

52 :デフォルトの名無しさん:2016/02/12(金) 08:43:48.25 ID:eUWMATXs.net
>>51
new Dateと同じだろ。

日付に見えてただのテキスト型になってるとかそういう事。なので、明示的に
型変換して入れてやる事はままある。


53 :デフォルトの名無しさん:2016/02/12(金) 20:46:32.04 ID:jzfCjOnO.net
>>51
物があるんだから具体的に何行目って言ってくれた方が分かりやすいとは思うけど、
見た目多分>>52であってる。
俺もそんなに詳しい訳じゃないし、APIの仕様も知らないけど。

ガーベッジコレクション(GC)をユーザが起動する方法はない。
参照が切れればいつか勝手に回収される。
ただ、見た目バカスカリークする可能性があるタイプのプログラムじゃないから、
多少リークしていたとしても問題ないと思うけどね。

リークが気になるなら、chromeならDeveloperTool、FFならabout:memoryで確認できる。
ちなみにそこにGCするボタンもある。

54 :デフォルトの名無しさん:2016/02/12(金) 23:30:42.28 ID:ZoV9Wx9d.net
>>53
// グローバル変数
var currentPos = new google.maps.LatLng({lat: 32.xxx, lng: 130.xxx});

//---------------------------------------------------------------------
// watchPositionSuccessCallback() 現在位置取得Success
//---------------------------------------------------------------------
function watchPositionSuccessCallback(pos) {
 currentPos = {lat: pos.coords.latitude, lng: pos.coords.longitude}; // あ、これがダメなのか?ここでnewしろと?
 var from = new google.maps.LatLng(currentPos); // ここで from に new しないで
 var to = google.maps.geometry.spherical.computeOffset(from, 350, heading); // 直に currentPos を使うとエラーが出ます

currentPos = {lat: a, lng: b};
って構文は
currentPos変数が保持してるLatLngオブジェクトのlatにaを代入、lngにbを代入する、
って思ってたんだけど違うのかなぁ?

ガベコレに関しては、ググると、
意図的にnullを代入すればメモリから消される、的なことを見たのだけどめんどくさいですよね。
上の例だと、
currentPos = null;
currentPos = new google.maps.LatLng({lat: 32, lng: 130});
最近のPCやスマフォはメモリ数GBとかあるしもう忘れることにしますw
きっとガーベージが増えたらGoogleChromeさんが勝手に掃除してくれますよね!

55 :デフォルトの名無しさん:2016/02/13(土) 00:01:10.41 ID:lKczJ9J0.net
>>54
currentPos={...}は、そのまんまcurrentPosに{...}を代入するだけで、
それぞれのプロパティに代入してくれるわけじゃないよ。
{...}自体が、new Object()だしね。
ガベコレが回収してくれるには参照を切ってやらなきゃならんのだから、null代入は必須。
意図的にnullを代入するとガベコレが回収する訳じゃないけど。
グローバル変数のcurrentPosはLatLngなんだから、{}でつっこむほうが間違ってる。

56 :デフォルトの名無しさん:2016/02/13(土) 00:40:54.25 ID:o8xzA50z.net
>>55
レスthxです。

プロパティに代入しちゃえ!って
currentPos.lat = pos.coords.latitude;
currentPos.lng = pos.coords.longitude;
やってみたけどできないのね。
https://developers.google.com/maps/documentation/javascript/reference?hl=ja#LatLng
LatLngってオブジェクトはコンスタラクタ以外では値の設定ができないのかな?
富豪過ぎるwww

>{...}自体が、new Object()だしね。
>グローバル変数のcurrentPosはLatLngなんだから、{}でつっこむほうが間違ってる
うーん、イマイチ理解できてないですけど、
currentPos = new Object({lat: a, lng: b});
というlatとlngを持ったLatLngではない別のObjectが生成された、ってことなのかな?

型が緩いのは便利だけどデバッグ時にはわかりにくすぎるという諸刃の剣ですね。。。
勉強になりました。ありがとうございます!

#今回javascriptで組んでみて、CSSにも苦戦してるし、CSSとjavascript上のひも付けにも苦労してます(汗
#あぁあああなんでぇええ  って腹たつけど、意図的に動いた時にはやっぱり嬉しいですよね
#プログラミングって楽しいですよね!

57 :デフォルトの名無しさん:2016/02/13(土) 01:31:30.78 ID:rQhUa0HJ.net
>>54,56
既に指摘されているとおりだけど、

> currentPos = {lat: pos.coords.latitude, lng: pos.coords.longitude};

> currentPos = new Object({lat: a, lng: b});
> というlatとlngを持ったLatLngではない別のObjectが生成された、ってことなのかな?
これで理解はあってます。

> currentPos = {lat: a, lng: b};
> って構文は
> currentPos変数が保持してるLatLngオブジェクトのlatにaを代入、lngにbを代入する、
> って思ってたんだけど違うのかなぁ?
これは違う。分割代入の構文はまた別にある。
この構文だと新しく lat と lng を持ったオブジェクトが作られる。currentPosに入っていた物は捨てられる。
(正確に言うと参照が切れる。全てから参照が切れていればいつかGCされる)

型は無いようで有るというか、C的に言えば全部ただのオブジェクトでしかないのだけれど、
new するとコンストラクタが呼ばれ、結果的に初期値等が設定され、
さらにプロトタイプも設定される。
また、getter/setterやProxyとかで色々細かいことも出来てしまうので、
API で new しろと言われている以上 new しないと駄目。
(Webの場合はURLで引っ張っているので、対象が書き換えられたらいきなり更新される。
そのリンクだと多分バージョン固定だからこの点は大丈夫だと思うけど、
APIはAPI通り使わないと危険。)

> 最近のPCやスマフォはメモリ数GBとかあるしもう忘れることにしますw
GCして欲しいのならnull代入するなりdeleteするなり関数で囲って関数ごと捨てるなりするしかないけど、
正直、今回のような場合の1個や2個はどうでもいいと思う。

> CSSとjavascript上のひも付けにも苦労してます(汗
基本的にclassを使えばいい。

58 :デフォルトの名無しさん:2016/02/13(土) 01:57:33.47 ID:rQhUa0HJ.net
> #プログラミングって楽しいですよね!
正直、ブラウザ上でのプログラミングはかなり楽しいと思う。
GUIで具しか書かなくていいのでチャキチャキ感があっていい。
ただ、他の新しいGUIは知らないから、他にもいいのがあるかもしれないけど。

59 :デフォルトの名無しさん:2016/02/13(土) 03:17:29.54 ID:o8xzA50z.net
>>58
色々教えてくださってありがとう御座います。

ブラウザ上のプログラミングも楽しいですけど、
PC8801mkII-SRからプログラミングを始めた私としては、
限られたCPU速度、メモリー、直接ハードを叩いてる感、も楽しかったんですよ
V-Sync割り込みで画像移動させるとスムーズに動くとかね。

そういうハードの限界まで頑張る、的な楽しみは今では無いでしょうけど
Google Chromeには便利なデバッガーあるし、
ネット上には情報がいっぱいあるし、
今の若い人たちはjavascriptから遊んでもいいと思いますね。
html5のcanvasでゲームも作れるし。
文法的にはCにもjavaにも似てるからどこにでも進めるでしょう。
職業:プログラマーという選択が良いか悪いかは別としてねw
趣味:プログラムなら一生楽しそうだけどなぁ。

60 :デフォルトの名無しさん:2016/02/13(土) 03:40:04.40 ID:o8xzA50z.net
雑談ついでに。
私はプログラムはXyzzyで書いてます。
Windows用の軽いemacs互換エディタです。
http://www13.plala.or.jp/tarna/maps/ariakekai/icon/xyzzy.png
25年くらい前にX68000でTinyEmacsを使い始めてから、
もうemacsキーバインドじゃないと何も書きたくないです。
ゲーマーなんでWindowsを使ってますが、
Xkeymacsという、すべてのキーバインドをemacs風に変換するソフトが常駐してますw
今の環境はWindows7ですがWindows10にしたらXkeymacsが使えなさそうで怖いです。
最低Ctrl-H=Backspaceにできないと死にます。

スレチ、失礼しました。

61 :デフォルトの名無しさん:2016/02/17(水) 19:47:14.33 ID:aoSk7bCH.net
今更ながらjs2-mode導入して色を付けてみたが、ちょっとイマイチだな。
キルリングの取り扱いが変わっていて慣れないし、
括弧閉じてもインデントが上がってくれない。
括弧の対応がハイライトされないのも謎だ。
まあもう少し使ってみるけど。

ただ、書いている最中に構文チェックするらしくて色が変わる。
これ自体は便利だと思うけど、どこまで使えるものなのかはまだよく分からない。

62 :デフォルトの名無しさん:2016/02/21(日) 09:27:40.55 ID:lDbEdv1b.net
>>57
>>GCして欲しいのならnull代入するなりdeleteするなり関数で囲って関数ごと捨てるなりするしかないけど
それらでCGされる保証はない
エンジンは一般的な場合に最適化されてる
一般的でないことはしないのが基本

63 :デフォルトの名無しさん:2016/02/24(水) 01:04:57.69 ID:idPWr2uv.net
すいません、キルリングの仕様変更はemacs23からのものらしく、
js2-modeは関係ありませんでした。

括弧の対応のハイライトはやはりおかしいままですが、
対応が間違っている場合はそもそも色が変わるので、
結果的にはあまり問題はないですね。

64 :デフォルトの名無しさん:2016/03/28(月) 23:29:32.90 ID:JoYhD075.net
nodeスレより
http://yosuke-furukawa.hatenablog.com/entry/2016/03/27/152500

65 :デフォルトの名無しさん:2016/04/13(水) 23:34:15.51 ID:/QwzOlsU.net
textContentってquerySelectorで引っかけられないよね?とりあえず

Array.prototype.filter.call(src.getElementsByTagName('a'),function(dom){return dom.textContent==='XXX';})[0];

で取り出せるんだけど、もう少しましな方法って無いかね?(速度および見た目的に)
条件は、

1. <a>は10個くらいで、5〜6番目が引っかかるので、そこでショートカットしたい。
2. 取り出すのは最初の1個でいい。

66 :デフォルトの名無しさん:2016/04/19(火) 11:57:14.77 ID:/d/wYc3X.net
速度も見た目も十分だよ
それを何度も実行する気なら状況によって要素や文字列をキャッシュすればいいし、
もっともっと短くしたいのならES2015を使えばいい

67 :デフォルトの名無しさん:2016/04/19(火) 21:54:42.16 ID:18lMfaYE.net
テーブルに大量の行を挿入したい時とかって普通にやると応答止まるけどプロはどうやってんの?

68 :デフォルトの名無しさん:2016/04/20(水) 01:37:27.97 ID:wi2IeNzq.net
>>66
本当は、

querySelector('a[textContent="XXX"]')

と書きたいところだ。
ただこれは出来ないので、これまでは致し方なく別関数なりベタで書いていた。
しかし call に慣れてくると実は意外と使えることに気づく。
使い道の無かった filter も便利に使えるかと思ったのだが、
配列メソッドなのでショートカットが無いのが唯一残念なところだ。
(個人的には記述量は気にならない。)

69 :デフォルトの名無しさん:2016/04/20(水) 01:44:58.86 ID:wi2IeNzq.net
>>67
大量の行の挿入くらいじゃ止まらないし、
そもそも一画面分以上挿入する必要もないだろ。

具体的に何行挿入して、どれくらいカクついたらアウトなのよ?

70 :デフォルトの名無しさん:2016/04/20(水) 08:04:48.78 ID:M3votfED.net
requestIdleCallbackで分割しながら挿入すれば良し

71 :デフォルトの名無しさん:2016/04/20(水) 09:52:44.31 ID:98a+yUuB.net
vol.119で質問すれば良いのになぜこんな場所で質問してるのか
ここで詳しく回答する気は起きないので簡単にしかいわんけど
http://echo.2ch.net/test/read.cgi/tech/1457452716/

>>65
XPathを使えば良いと何度もいわれてる

>>67
1行ずつ何度も挿入してるんだろ
DFを使え

72 :デフォルトの名無しさん:2016/04/25(月) 00:30:16.00 ID:th/2rgKP.net
ふと思ったんだが、forEach って何で currentValue が this になるのがデフォじゃないんだ?
グローバルじゃ意味無いよな?
引数で与えられるから動作としては問題なく、見た目だけの話だけど。

> forEach に thisObject パラメータが与えられると、callback の呼び出しのたびにそのオブジェクトが this として使用されます。thisObject が与えられないか null だと、callback に結び付けられたグローバルオブジェクトが代わりに使用されます。
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach

73 :デフォルトの名無しさん:2016/04/25(月) 04:01:16.41 ID:LMKLsb3i.net
thisに色んな意味を付けて何でもかんでも与えるなんてセンス無いから
現にアロー関数だったとき機能しないでしょ

74 :デフォルトの名無しさん:2016/04/25(月) 04:10:55.58 ID:wavxOtJH.net
>>732
currentValue が thisになるのなんて、
DOMのイベントハンドラの中でthisが要素になるぐらいのもんだろ。
そもそもDOMはJavaScriptではない。
そもそもDOMがおかしいんだよ。

75 :デフォルトの名無しさん:2016/04/25(月) 08:11:57.07 ID:th/2rgKP.net
>>73
> 現にアロー関数だったとき機能しないでしょ
あれはどっちかというと無駄な仕様変更だと思うが。
正確に言うと無駄な仕様を削除して新しく自動 .bind(this) に変更したわけだが、
その必要も無かった(と思う)

>>74
> そもそもDOMがおかしいんだよ
これはそう思う。というか、あれは this になることで無駄な手間が増えてる。
イベントハンドラを継承で与えるとき、(クラスでイベントハンドラを共有するとき)
いちいちインスタンスに bind しなくてはならないので面倒だ。
必要なら e.currentTarget でよかったのに自動 this だからこうなる。

ただここら辺も統一感がなくてイマイチではあるが、
現実的には何とかなる範囲ではあるので、(我慢できる範囲)
AltJSもイマイチ本家を殺しきれないといったところか。

76 :デフォルトの名無しさん:2016/04/25(月) 17:28:53.92 ID:q4sdOoqx.net
>>72
Array#forEachのコールバック関数にcurrentValueをthis値束縛する動作が自然ではなく、それによるメリットもないからだ
prototype上のメソッドでもないただのコールバック関数がなぜarrayでもグローバルオブジェクトでもなく、cirtentValueに束縛するのだ?
Function#bindでthis値を1に変更した場合、全ての要素値が1と扱う実装に利便性があるとは思えない
(arrayに束縛するならわからんでもないが)
forEachは第3引数でコールバック関数のthis値を指定できるが、これは異なるスコープからデータを渡すのに便利だ
(jQuery#eachにはこの機能はない)

イベントハンドラ関数のcutrentTargetへのthis値束縛もDOM3までは存在せず、DOM4で実装から逆輸入して規定されたものだ
addEventListenerには元々、handleEventでthis値を束縛する機能があり、thisをcurrentTargetとして扱うコードはhandleEventを利用した途端に修正を迫られる
event.currentTarget === this は相互運用性の為に仕様に取り込まれたに過ぎない
ちなみに、jQueryではhandleEventを利用出来ない

jQueryがthisを多用するのは仮引数を書く手間を減らす為だけに定められた歪なものだ
ECMAScriptでは関数呼び出しされるまでthis値が定まらない不定値だが、jQueryはthisをローカル変数でも引数でもない第三の格納倉庫として利用し、コード上でthis値が変更されることを許さない
this値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない

77 :デフォルトの名無しさん:2016/04/25(月) 17:47:23.15 ID:6VBDo1JK.net
>>75
仕様「変更」ではない
アロー関数はより「ピュア」な新たな関数
newも出来ないし、thisやsuperも変数と同じように参照する
bindとは違う
統一感はある
DOMは関係ない、altJSでも同じこと
というかデファクトであってそれに依存するのは非推奨

78 :デフォルトの名無しさん:2016/04/25(月) 19:33:42.57 ID:th/2rgKP.net
>>76
指摘の通りDOMをイメージしていて、
これまた指摘の通り全部thisでやろうとすること自体が糞だと理解した。

> (arrayに束縛するならわからんでもないが)
確かにこちらの方が自然だね。(とはいえthisにこだわるのが間違いだったが)

> event.currentTarget === this は相互運用性の為に仕様に取り込まれたに過ぎない
見た目相互運用できるようには見えないが、
(thisに揃えても同じコードを再利用できるとは思えない。もちろん揃えないよりはマシだが)
後付けでいろいろ奇妙になっているのは理解した。
> http://7cc.hatenadiary.jp/entry/eventlistener-handleevent

> this値に変更されて困る重要なデータを格納する
jQueryは知らないが、これはconstの代りに使うということか?
アクロバティック過ぎる。


>>77
> アロー関数はより「ピュア」な新たな関数
つまり機能限定版か。
そういう理解は出来なくもないが、導入するメリットは文字数以外に何もないだろ。
そりゃ意味無いって普通は言われるよ。
どうせ新規にするのなら、クロージャ無しとかまで踏み込んでもよかった。
(新規なら使い分けが必要/有効なところまで機能分離するべき)

79 :デフォルトの名無しさん:2016/04/25(月) 22:39:46.80 ID:wavxOtJH.net
>>76
> jQueryがthisを多用するのは仮引数を書く手間を減らす為だけに定められた歪なものだ

違うよ。DOMの仕様に合わせただけ。

jQueryのイベントハンドラは、DOMのイベントハンドラと
互換性を考慮されて作られている。

例えば、この2つは同じように動く

$('#btn').on('click', function(event) {
 alert(this.id + event.currentTarget.id)
});

document.getElementById('btn').addEventListener('click', function(event) {
 alert(this.id + event.currentTarget.id)
});

どちらのイベントハンドラもthisは同じものを指しており、
またjQueryのeventオブジェクトはDOMのeventオブジェクトの仕様と
互換性を持たせて実装されている。

高い互換性ではないが、それでも程度はあるから移行が楽になる。

80 :デフォルトの名無しさん:2016/04/25(月) 22:47:27.73 ID:wavxOtJH.net
>>76
> jQueryはthisをローカル変数でも引数でもない第三の格納倉庫として利用し、コード上でthis値が変更されることを許さない
> this値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない

そんなことしません。

そう言う用途として使うのは、DOM要素のdatasetだよ。
このdatasetっていうのは比較的最近できたもので昔はなかった。

だけどjQueryは要素ごとの情報の格納場所の必要性を昔から認識していたため
datasetが作られるよりも前からdata()メソッドと言うのを持っていた。

そしてdata()メソッドがある理由の一つとして、
thisに直接値を格納するとブラウザのバグでメモリリークになる可能性があるから
「this(DOM要素)にデータを格納してはいけない。」と言っていたぐらいだ。

事実はあんたが思っているのと正反対だよ。

81 :デフォルトの名無しさん:2016/04/25(月) 22:49:10.70 ID:wavxOtJH.net
これね。

https://api.jquery.com/data/

The .data() method allows us to attach data of any type to DOM elements in a way that is safe from circular references and therefore from memory leaks.

82 :デフォルトの名無しさん:2016/04/25(月) 23:32:07.55 ID:olQI0pZ8.net
>>76でhandleEventの話が出ているが、使った人ならわかると思うが、
handleEventはswitchでイベントを振り分ける必要があって使いづらい。

なぜこんな仕様があるかというと、そもそもDOMはJavaScript以外の言語も
考慮されて作られているという事実で説明できる。

つまり関数の引数、つまりaddEventListenerの引数に関数を渡せない言語が存在する。
具体的に言うとJava。Javaでは引数に関数を指定することができず、
オブジェクトは指定できる。

handleEventインターフェースを実装したオブジェクトを引数に取る関数と
考えるとhandleEventという仕様がなぜ存在するかがわかる。
これは便利だから追加された機能じゃない。Java等で必要だったっから
追加された仕様であって、JavaScriptでは関数をそのまま指定した方がいい。

83 :76:2016/04/26(火) 00:48:49.99 ID:74Un+zc0.net
>>78
> > event.currentTarget === this は相互運用性の為に仕様に取り込まれたに過ぎない
> 見た目相互運用できるようには見えないが、
document.all が標準化されたのと同じ理由だが、既存の資産(this で event.currentTarget を参照するコード)を生かす為だ
DOM3当時はデファクトスタンダードとして this 値が event.currentTarget を参照していたが、標準化されていなかったので確実に動作する保証がなかった
DOM4で標準化された事で既存のコードが確実に動作する事が保証された
単純に相互運用性を考えるなら event.currentTarget を使ったほうが良いのはいうまでもないが、
IE6の影響でXHTMLへの移行が進まなかった教訓を得てバッドノウハウでも積極的に取り入れて互換性を確保する方向にシフトした

> > this値に変更されて困る重要なデータを格納する
> jQueryは知らないが、これはconstの代りに使うということか?
これは言葉足らずだった、すまん
先述の jQuery.each と同じだ

// bad
jQuery.each([1, 2, 3], function (i, value) {
console.log(this); // Strict Mode なら Number型、sloppy mode なら Object 型 (Function#bind で変更される可変値)
});

// good
jQuery.each([1, 2, 3], function (i, value) {
console.log(value); // 常に Number 型 (Function#bind で変更されない固定値)
});

繰り返し処理をする上で要素の値は固定値でなければならないので this 値を指定すべきではない

84 :デフォルトの名無しさん:2016/04/26(火) 00:50:01.95 ID:6NLvX0gR.net
>>80
> jQueryは要素ごとの情報の格納場所の必要性を昔から認識していた
これは俺もすごく思うが、
実際のところはリークと速度低下が怖くてJavaScript側で持っている。
さすが実用ライブラリだけあって痒い所には手が届いているというところか。

>>82
> handleEventはswitchでイベントを振り分ける必要があって使いづらい。
これは何故?俺は使ったことは無いが、見る限りそういう感じではない。
イベントハンドラは基本的に直リンクというか、振り分け済みの関数を与えるのが基本で、
thisが効くオブジェクトを与えられるのなら、子クラスを与えればいいだけ。
当たり前だがオブジェクト指向の基本どおりだ。
また、最初からイベントハンドラ内で振り分けする気であれば、
ルートNodeにイベントつけてe.targetのclassで判定するのが自然だ。
何か別の条件ではまっただけの気がするが。

とはいえ、DOMの仕様がJavaScriptから見て中途半端なのはJavaとの相乗りが原因だとは理解した。

85 :76:2016/04/26(火) 00:51:40.14 ID:74Un+zc0.net
>>83の続き

// bad
function fn1 (event) {
this.classList.add('hoge');
}

// good
function fn2 (event) {
event.currentTarget.classList.add('hoge');
}

element.addEventListener('click', fn1); // OK
element.addEventListener('click', fn2); // OK
element.addEventListener('click', {handleEvent: fn1}); // NG
element.addEventListener('click', {handleEvent: fn2}); // OK

handleEventを拡張した場合、this値を指定したコードは動作しなくなる
ようするに、this は可変値なので固定値をとりたい場合に使用するべきではないという事だ

---
this が可変値である事を上手く利用した例に Array.prototype.forEach がある

Array.prototype.forEach.call(document.querySelectorAll('.test'), function (element) {
element.classList.add('foo');
});

これが動作するのは Array.prototype.forEach が this 値が配列でなくとも動作するように設計されているからだ
this 値は変動するから Function#call や Function#bind が生きる
だからこそ、this 値が変動する事に価値を見出せる設計にする必要がある

86 :76:2016/04/26(火) 01:08:23.70 ID:74Un+zc0.net
>>80
jQuery でも event.currentTarget で書くことは出来るが、ドキュメントのサンプルコードを読む限りでは作者が this を推奨しているように読める
「許さない」は言いすぎだったかもしれないが、this を推奨するという事は this 値が変更される事を考慮していないのではないか
this 値は実行コンテキストに入る時点で決まる不定値であり、this === event.currentTarget になる保証はない
https://api.jquery.com/on/

余談だが、jQuery#each と Array#forEach でコールバック関数の引数順序が違うのは this 束縛がある影響だと考えている
jQuery では this で各要素ノードを参照できるので第1引数に element を持っていくと index を参照する為には第2引数まで書かなくてはならない
forEach の設計としては直感的ではないが、ショートコーディングの為に index を第1引数に持ってくる歪な修正を加えたようにしか見えない
https://api.jquery.com/each/

jQuery('.hoge').each(function (i, element) { console.log(this, i, element); });

87 :76:2016/04/26(火) 01:50:16.54 ID:74Un+zc0.net
>>80
> 事実はあんたが思っているのと正反対だよ。
jQuery#data は優れた機能(ただし、data独自属性の拡張はいただけない)だし、jQuery() のセレクタエンジンは素晴らしいものだった
JSON, querySelector 等、優れたライブラリ/先行実装が標準仕様に取り込まれるのはよくある事だ
jQuery の全てを否定したいわけではなく、「jQuery の this の使い方が好ましくない」と主張している

> そう言う用途として使うのは、DOM要素のdatasetだよ。
dataset は String 型しか格納できない為、jQuery#data の代替にはならない
jQuery#data の代替として期待されたのは DOMUserData だが、この API は残念ながら廃止された
https://www.w3.org/TR/2004/PR-DOM-Level-3-Core-20040205/core.html#DOMUserData
今では機能的に逆だが、WeakMap が代替となりうるだろう
http://www.ecma-international.org/ecma-262/6.0/#sec-weakmap-iterable

88 :デフォルトの名無しさん:2016/04/26(火) 11:16:02.05 ID:x636ghAj.net
つうか結局何が言いたいの?
thisはpythonのselfみたいに一定の規則はあるが
あくまで0番目の引数みたいなもんで何に使おうが勝手だし
そういうのを利用するならきちんと把握しないといけない
その程度のことに良いとか悪いとかはない
使いたいならただ受け入れればいいだけ

なんかよく分からんけど気持ち悪いみたいな
結局愚痴をダラダラと言いたいだけならもうここら辺でやめとけ

89 :デフォルトの名無しさん:2016/04/26(火) 17:56:08.45 ID:LGdk9fYg.net
C#みたいにobj.Methodでバインドしてくれれば楽で綺麗に書けるのにね
いちいちbindって書くの面倒

90 :デフォルトの名無しさん:2016/04/26(火) 19:15:29.79 ID:v8OmTco7.net
>>88
ここまで説明されて愚痴にしか読めないのなら口を出さなければ良いと思うけど

91 :デフォルトの名無しさん:2016/04/26(火) 19:52:24.85 ID:PAn5oHiy.net
>>89
引数としてメソッドを渡す際は今だと
obj.method.bind(obj)
よりもアロー関数を使って
()=>obj.method()
の方が良いかもしれない

あとバインド基本にするのは結構簡単
クラスのプロトタイプにそういうプロキシを挟めばいい
アノテーションとか使えるようになればなお綺麗に書けるね
まあバインドシンタックスobj::methodとかもあるんだけどね

そういうのを使えるトランスパイラ使うってのも悪くないと思う

92 :デフォルトの名無しさん:2016/04/26(火) 23:52:32.19 ID:6NLvX0gR.net
>>83
前半、言っていることは分かるんだが、現実的には、
this がDOMであるコードと自前のオブジェクトを this 参照するコードを
同一のコードで処理(相互運用)するためには、
自前のオブジェクトをDOMモドキにする必要があって、
(DOMと同じプロパティ等でアクセスできるように形を揃える)
これだと余計に苦労する。
だから結局、既に書かれたコードを流用することは難しく、
書き直すかラップしてしまうほうが簡単だ。
多分現実的には相互運用をしている奴は少ないのではないかと思う。
もちろんthisで共通アクセスできないとその可能性すらないからそれよりはマシだが、
現実的にはこの仕様はあっても使えない。

93 :デフォルトの名無しさん:2016/04/26(火) 23:53:03.95 ID:6NLvX0gR.net
>>82の話の通りなら、handleEventはJava用であって、JavaScript用ではないことになる。
実際、>>85ではメリットが無いだろ。
JavaScriptでわざわざ使うのならメリットがある以下の記述になる。

var hit_list = new Set();
var EventHalndler = function(){
this.status = 'waiting';
}
EventHandler.prototype = {
handleEvent: function (e) {
e.currentTarget.classList.add('hoge'); // class で管理
this.status = 'hit'; // 個別オブジェクトで管理
hit_list.add(e.currentTarget); // Set で管理
}
};
var ehandler = new EventHander();
element.addEventListener('click', ehandler);

DOM側で管理するならclass、JavaScript側で一括管理でよければSetでいい。
どうしても個別のオブジェクトに格納したければ 「thisを生かして」 使うことになる。
当たり判定のグルーピングを細かく変更したいときはこのやり方が適するけど、
用途はあまり無いと思う。

94 :デフォルトの名無しさん:2016/04/26(火) 23:54:04.46 ID:6NLvX0gR.net
だから「相互運用」を考えるのなら、
e.currentTargetとthisの両方を異なる意味で用いている上記のようなケースをどうするかであって、
多分これはどうにもならんだろ。
手っ取り早いのはラップ関数内でthis値をMapなりから引っ張ってきてしまうことだが、
要するに書き換えが必要なので仕様をわざわざ合わせた意味がない。
何らかのために仕様をあわせたというのなら、
そのおかげで書き換えなくても済みました!がないと意味が無い。

DOM側からすると妥協だということだが、放置でもよかった気はする。(仕様として追認の必要なし)
なお、thisかe.currentTargetの片方しか使ってないコードは自動でも書き換えできる範囲だと思う。

しかしそうなると問題の出所はブラウザの実装で、
何故e.currentTargetに統一せずにthisを渡すことにしたかだな。
正直、あれ、thisで渡されても全くメリットないよな?

> DOM4で標準化された事で既存のコードが確実に動作する事が保証された
これは多分、気にする人にとっては重要なのだろうけど、
Webサイトなんて10年後の動作を保証されたところで意味が無いし、
「当面(数年)確実に動く」であれば大半の人にとって問題ない。
それが実装主体で推移している原因にもなっていると思う。

95 :デフォルトの名無しさん:2016/04/26(火) 23:55:02.00 ID:6NLvX0gR.net
>>82
とここまで書いて気づいたが、switch は e.target ではなく e.type か。
確かにこれでは使いにくいな。JavaScriptなら以下で逃げられるが、
これが出来ないからオブジェクトで与えているのだと思われ、Javaでは壮絶な糞コードになりそうだな。

EventHandler.prototype = {
handleEvent: function (e) {
this[e.type].call(this,e);
},
click: function(e){},
mouseover: function(e){},
mouseout: function(e){},
};

96 :デフォルトの名無しさん:2016/04/26(火) 23:55:42.51 ID:6NLvX0gR.net
>>86
いやそのjQuery.eachのthisは意味があるぞ。
それならthisで書かれたイベントハンドラをeachで回せる。(DOMのイベント寄り)
ただe.currentTargetで書くべきだというのと、
そもそも他に代替手段がありまくるので、割とどうでもいいが。
thisを固定したことによるデメリットの方が上回るかもしれない。

ただまあ、そちらの主張どおり、
thisに対しては緩く考える(○○が来ると仮定しない)方が何かと便利なのは事実だろう。

97 :デフォルトの名無しさん:2016/04/27(水) 00:28:53.55 ID:mjPz9hpH.net
「thisは基本レシーバ」
それ以上でも以下でもない

98 :デフォルトの名無しさん:2016/05/01(日) 14:45:40.12 ID:tKi6j9CT.net
匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?

Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません


99 :デフォルトの名無しさん:2016/05/03(火) 12:04:12.37 ID:YtCRz7OH.net
もうWebRTC利用したJS製のそういうフレームワーク何個も作られてるよ

100 :デフォルトの名無しさん:2016/05/03(火) 18:27:13.57 ID:Hru3QNWj.net
WebRTCって要するにP2Pチャットサーバ用だよな。
元々それ用だけどそれ以外に用途が無い。
もちろん発展させればWinnyやskypeみたいな事は出来るけど、それなら最初からそっちでいいし。

俺も最初知ったときは「ウッヒョー」だったけど、冷静に考えたら落ち着いた。
現実的には大半の事案は鯖立すればいいだけだからね。
技術的には面白いとは思うけど。

101 :デフォルトの名無しさん:2016/05/04(水) 19:58:18.58 ID:znxAfP3/.net
ちいと勘違いしてるが、WebRTCに鯖とのやり取りもといマッチングの仕組みは含まれていない。
WebRTCでそれをするのはちょっとハックっぽくなるが、
特にORTCなら鯖レスの固定相手P2Pも素直にできる。

現在は
・ビデオ/ボイスチャット
・MMOゲーム
・一方向型のファイル共有
によく使われてる

102 :デフォルトの名無しさん:2016/05/04(水) 23:45:02.80 ID:umoiWZhY.net
> MMOゲーム
これにはいいかもな。

それ以外は正直、「ブラウザでできる」以上の意味は無いよね。
最初からP2Pする気ならP2Pアプリを使った方がいろいろいいし。
一方向型のファイル共有ってそれただの鯖じゃん。

103 :デフォルトの名無しさん:2016/05/05(木) 04:30:39.98 ID:2KiZjc5Z.net
ブラウザでできるからこそ特大の意味があるんだよ
今著名なWebサービスはアプリも出してることが多いけど、
じゃあ皆がそっちの方を使ってWeb版はいっさい要らなくなるかというとそうではない
一時期そういう流れも起きたがやはり無理だったということで、今は流れが戻っている(Flipkartが良い例)
わざわざアプリをインストールして管理しないといけない手間が要らないのはとてつもない利点だよ

そして、ファイル共有に関しては鯖レスで実現できるところがメリット
鯖を挟むと帯域を本来の2倍取り、さらに負荷が鯖に集中してしまう
宛先の絞られているファイル等はP2Pで送る形のほうが良い

104 :デフォルトの名無しさん:2016/05/05(木) 09:25:46.88 ID:fknk/t2B.net
ブラウザのBBOM化はもう勘弁して

105 :デフォルトの名無しさん:2016/05/09(月) 15:41:03.36 ID:iKr5Nm9H.net
なんで?

106 :デフォルトの名無しさん:2016/05/09(月) 22:54:55.21 ID:Ji3tRhpw.net
BOMのことだよな?
個人的にはDOMやBOMでAPIアクセスできるのはお手軽でいいと思うぞ。

107 :デフォルトの名無しさん:2016/05/09(月) 23:34:30.27 ID:fQwtjbTF.net
もはや種類多すぎる上に増加スピードが速すぎて把握するのがしんどいわ
でも無ければ無いで何も作れないしな

108 :デフォルトの名無しさん:2016/05/10(火) 10:34:10.82 ID:AYSgFkex.net
スピードが早いというが、一年くらい前から高レベル系のAPIが熟成期に入って停滞してると思う
また来年くらいから今度は低レベル系のAPIが動き始めるんじゃないかな

109 :デフォルトの名無しさん:2016/05/10(火) 23:06:42.46 ID:vhPcYSkB.net
> 低レベル系のAPI
上の話ともリンクするが、ブラウザはお手軽さが最も重要なのであって、
ゴリゴリ書いて性能を出すのには不向きだし、流行らないと思うぞ。
結局のところ、専用ネイティブアプリには実行効率では勝てないのだから、必要なら開発される。
そこまでの必要/需要が無ければブラウザアプリのままでいけることになる。

ただ一つ思うのは、CPUとI/Oを分離し、非同期で書くことを強制するのは、実はかなり効いている。
体感、思っているよりだいぶ速いんだよね。
他言語だと普通に同期で書くし、描画でもそのまま記述する。(分離して書く習慣が無い)
これら遅い部分を明示的に分離し記述することが半強制されている結果、
結果的にCPU稼働率の高い「割と速い」コードが出来上がることとなっている。

だからちゃんと書いたJavaScriptは十分速いし、
それ以上の速度を要求するのならC/C++で書き直すしかない。(V8がC比5倍程度と十分速い為)
どんなJavaScriptでも最後にトランスパイルすれば速くなるというのなら、それはJIT側に含まれるべきだし、
何らかの記述制限をつけて「ちょっと速いJavaScript」を目指すものは、多分需要が無い。
(本来そこにはC比3倍程度というJavaアプレットがいたはずだが、完全に死んでるし)

110 :デフォルトの名無しさん:2016/05/11(水) 07:45:48.20 ID:XhqmdNgU.net
>>109
考え方が全く違う。低レベルAPIは、高レベルAPIを作るために必要なの。
高レベルAPIを標準仕様として策定してたら互換性などを強く考慮する必要があり、
メジャーブラウザが一通り実装して使えるようになるまで極めて時間が掛かる。

そしてその時に本当に必要とされるものに出来なかったという失敗も数多くしてきた。
実装にも時間が掛かるが、古いAPIを削除するにはそれ以上の時間がかかってしまう。

でも低レベルAPIを提供するようにすれば、ライブラリやポリフィル程度の気軽さと速度で
その時代に必要とされる高レベルAPIが作られていくようになるし、
そこで持て囃されデファクトを築いた仕様を改めて標準に持って来ればいい。

ポリフィルだらけになるということさえなんとかすれば、他の様々な問題が解決される。
それが低レベルAPIの道入。「Extensible Web Manifesto」だよ。

>>109
また、何をもってちゃんと書くと言っているのかわからない。
結局スクリプト言語であるJSの大部分のコストかかる場所は大抵DOMなんかの外部APIを叩いた部分だからね。
でもそうでないゲーム思考エンジンなどを作ったりするけど、「ちゃんと書けば」
単純演算系ロジックのパフォーマンスが1/5倍なんて最悪の見積もりだよ。
1/5くらいのケースもあるけど、10%程度しか分からないケースもあり、アベレージで大体1/2位になる。

まだSIMDやらパラレルやらの最適化が完了してないのでそこが大きく絡むともう1/2くらいにはなるが、
1/5は最悪中の最悪ケース。

111 :デフォルトの名無しさん:2016/05/11(水) 22:18:37.29 ID:ye4EAN+q.net
APIはポリフィルできても、言語はポリフィルできないからな。
だからBabelなどのトランスパイラが必要になる。

112 :デフォルトの名無しさん:2016/05/12(木) 00:54:26.89 ID:TctSTaTq.net
>>110
> Extensible Web Manifesto
以下を読んだ。
http://jxck.hatenablog.com/entry/extendthewebforward
言っていることは分かるが多分無理だな。

低レベルAPIのすり合わせは高レベルAPIよりも難しい。
だから高レベルAPIのすりあわせすらマトモにできなかった連中には無理だ。

> そもそも、デバッギングはコーディングよりも2倍難しい。
> 従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない。
> ブライアン・カーニハン [Brian Wilson Kernighan]

高レベルAPIの仕様策定が失敗しているケースが多々ある点についてはよくは知らないが、
JavaScript言語自体の仕様を見る限り、いろいろ迷走している点は多い。

仕様策定が失敗するのは、単純に使用策定している奴らに先見の明が無いからだ。
だから逆に言えば、先見の明が無いような奴らが仕様策定に関わってはいけない。
JavaScriptの連中はそこらへんを勘違いしている。だからゴミ仕様が山積みになる。
AppCacheがゴミであろうと、仕様として策定された以上、実装しないわけには行かない。
だから結局、ブラウザに対してゴミコードを含まなければならないという足かせが出来ただけになる。
結果的にJavaScriptの世界はゴミが増えていき、ゴミに振り回されることになる。
これを理解できていない。

とはいえ、それでも進化の速度を取っているといえばその通りだ。
C#が伽藍型仕様開発なら、JavaScriptはバザール型という訳だが、目に付く失敗も多い。
もちろん、XHR等は大成功の一例なのだろう。どちらが多いのかは、俺にはわからない。
SeviceWorkerがどうなるのかは見ものだな。

113 :デフォルトの名無しさん:2016/05/12(木) 00:54:55.63 ID:TctSTaTq.net
> ちゃんと書く
速度を問題にしているのだろう?だったらきちんと速度が出る書き方をするということだよ。
5倍というのはググれば出てくるはずだがN-body、つまり演算部分だ。
同様のベンチは他の人もやっていて、大体同じような値になっている。

ただ指摘の通り、その部分は他のもっと遅い部分に隠蔽され、結果的に見えないことが多い。
(ただしだからといって遅い部分も含めて速度比較して大差ないとか言う屁理屈はうざいだけだから止めろ。
それは速度比較とは言わない)
だからJavaScriptが通常用いられる用途に関しては、JavaScriptは十分速いし、
それ以上を望むのなら、ゴリゴリ書くしかない。

> ゲーム思考エンジン
これは環境はなんだ?
個人的には主力テキスト操作スクリプトをAWK/Perl->JavaScriptに乗り換えようかと思っているんだが、
DOS窓から操作できる使いやすい環境ってないか?
AWKやPerl同様、一行ずつ標準入力からReadline出来ればそれでいい。
nodeが一番マシか?

114 :デフォルトの名無しさん:2016/05/12(木) 05:43:37.43 ID:s4pSKHj7.net
WSHが一番マシ

115 :デフォルトの名無しさん:2016/05/12(木) 08:43:22.73 ID:pPHDojvh.net
>>112
無理では無いと思う。
基本的にセキュリティや機能制限の面が一番難しいだけで、
そこさえクリアできれば、低レベルAPIの仕様自体は一意に決まりやすいものだから。
まあ高レベルAPIと同じくらいの難しさだろう。

そして求めてるのを作れなかったというのは、
策定に時間がかかったり、実装者や開発者とのやり取りが十分ではなかったから。
先見の明が無いと言えばそうかもしれないが、
今まで無かった様々な機能が必要とされる中でいきなり完璧を目指すのは無理というものだ。
そして今でさえ策定が遅いのにこれ以上慎重になるわけにもいかないのだよ。

それを反省し、よりフットワークの軽いだろうライブラリ界に高レベルAPIを練る役目を託し、
フィールドバックを十分にした上で標準仕様として改めて定義し直そうというのがEWM。
これにより発展速度も安定性も上がると思っている。

>>113
自分が言った「ちゃんと書く」とは、asm.jsを(部分的に)手書きするということだ。
例えばこの記事の時点ではN-bodyもasm.jsならネイティブの約1/2(今はもう少し速くなってる)
自分の考えるこういう時のネイティブってのイメージはLLVM+Clangなんだが、
いずれにしろ記事見ても分かるように、syscallsが絡んだりするとasm.jsの方がパッと出早い場合も有るくらいなのだ。

まあ手書きしやすいように手書きするとやはり静的言語からコンパイルするよりは落ちることが多いが、
それでもアベレージで1/2のイメージで良いと思う。
自分はNodeを使ってる。V8はC++モジュールとの連携が楽なので、JSがどうしても苦手な部分はC++で書いたりもしやすい。

116 :デフォルトの名無しさん:2016/05/12(木) 08:44:46.17 ID:pPHDojvh.net
記事リンクを貼ってなかった
https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/

117 :デフォルトの名無しさん:2016/05/12(木) 23:52:09.31 ID:TctSTaTq.net
>>114
WSHか。あれ食わず嫌いだったけど、やっぱお手軽でよさそうだよな。
まあやってみることにするよ。

118 :デフォルトの名無しさん:2016/05/12(木) 23:59:02.52 ID:TctSTaTq.net
>>115
違う。
> 策定に時間がかかったり、実装者や開発者とのやり取りが十分ではなかったから。
仕様策定とは「常に」こういうものなんだよ。言語のみならず他でも全て。
有名なイラスト、見たことがあるだろ。
> ニコニコ大百科/a/顧客が本当に必要だったもの (リンクはRock54で貼れない)
だから、これを分かった上で、そうならないようにする「実力」が必要なんだよ。

具体的に言えば、どんなに時間がかかろうが、いい仕様(必要な物)ならみんな使う。
だから、時間をかけてでもいい仕様にするというのが「先見の明」作戦。
これが無理なら、古典的だが報告連絡相談(ホウレンソウ)をきっちりやるしかない。
出来なかったのなら、どちらの作戦もやりきる実力が無かっただけ。

試行錯誤で進めていくのもありだと思うけど、
それなら結果的に無意味になってしまった仕様等をばっさり捨てていく覚悟も必要。
(詳しくは知らないがRailsはこれに近いのかもしれないし、それも妥当な戦術)
後方互換も必要です、新しい仕様も必要です、
でも十分な仕様策定能力はありません、というのが今のJavaScriptの状態だね。
進化速度を捨てるわけには行かないのだから、後方互換を捨てるしかないと思うのだけどね。
この点で言えば、ポリフィルでお茶を濁しまくっているのはいい作戦ではある。

とはいえ、出来る/出来ないをここで議論する意味は無い。
結果を見ればいいだけだから。

119 :デフォルトの名無しさん:2016/05/13(金) 00:04:56.39 ID:PxVJ9U+u.net
>>115
> 自分が言った「ちゃんと書く」とは、asm.jsを(部分的に)手書きするということだ。
だからそれは屁理屈なんだよ。
言語の速度比較なら、普通に書いた、つまりそこらへんに転がっている記述同士でやらないと意味無いだろ。
Cでインラインアセンブラを使うのは無し、
JavaScriptなら普通に [], {}を使って書いたものだよ。全面 TypedArray とかは無しだよ。
というか、それならそもそもそういう言語で書けって言われるようじゃ駄目だろ。
言語の比較なら、それぞれの言語の良さを生かした状態で記述してあるものでないと。

君が言っているのは、「チューニングしたときに伸びしろがあるか」ということであって、
言語の速度比較ではないんだよ。
CならSSEやCUDAまで導入できるのだから、それも入れていいかというと違うだろ。
普通に書いて普通にコンパイルできる状態での比較じゃないと意味無いだろ。

そして、そこでいちいちムキになることも無いんだよ。
不満があれば他言語で書けばいいだけ、
その言語を使っているのなら、エコシステム含めてその言語が一番マシだから使っているだけ。
それ以上でもそれ以下でもないだろ。

120 :デフォルトの名無しさん:2016/05/13(金) 09:43:39.39 ID:1hqv3t07.net
>>118
JavaScriptと言うより、Webの宿命。ES仕様自体は元々が小さかったのも有り、
妥当で慎重な機能追加で順調に進化してきている。

そして今まで悪かったからこそそれを改善しようと言うのがEWMなのに、
なにを否定したいのかがわからん。
EWMならダメな仕様等をばっさり捨てていくことも可能。
というか結果的に皆が使い良いと認められる仕様だけが標準になるのだから。
更には公開と発展の速度まで引き上げられる。

そしてasm.jsを手書きすることが屁理屈だなんてとんでもない。
勿論emscriptenが書き出すようなのを手書きするのは変態だが、
どうせちょっと高速化を意識するとTypedArrayをメモリに見立ててあれこれするようになる。
それはasm.jsがやってることと同じなので、asm.jsパターンにちょっと直せばいいだけ。
ただのお作法みたいなものでしかなく、そっちこそ何をムキになってるんだか分からん。

別に素のJSがC++と比べてどれだけ早いなんて自慢話をしたいわけじゃないし興味はない。
JSで事実速いコードもそこそこ書くことが出来、その結果現実的に実現できることがあるということが自分にとって重要

もちろんこういうことをするのはレアケース。
だって先にも言ったようにそこら辺に転がっている実用コードの殆どのボトルネックが外部APIだし、
よくあるマイクロベンチみたいなのを意識しても仕方ないから。

一方それ以外の素の速度が重要なケースでは、どんな言語で書いてもそれなりにアルゴリズムやチューンを気にするだろうし、
asm.jsに沿って書く程度十分あり得る範囲だよ。

121 :デフォルトの名無しさん:2016/05/13(金) 17:53:59.39 ID:1hqv3t07.net
Railsとかサーバサイド言語/環境と違って
WEBは1つの実装で色んな時代に作られたデータを読まないといけないのだし
仕様の量も段違いで数十か数百かのモジュールが組み合わさって成り立っているのだから
その1つ1つのバージョンを意識したり指定したりということはできないし
原則後方互換性を守りながら拡張していくしか無い

WEBがもっとシンプルで昔のようにほぼW3Cが牛耳っていれば問題はなかったのだが
世間や環境がそうさせてくれなかった
WEBはマグロのように泳ぎ続けるしかない定め

122 :デフォルトの名無しさん:2016/05/13(金) 20:51:55.08 ID:PxVJ9U+u.net
>>114
> Microsoft Windows 98、Windows 2000、および Windows Me には、
> Microsoft JScript および VBScript の 2 つのスクリプト エンジンが用意されており、
> 通常はこのいずれかを使用してスクリプトを記述します。
> Windows Script Host では、このほか、Perl、REXX、Python などのスクリプト エンジンも使用できます。
> https://msdn.microsoft.com/ja-jp/library/cc392505.aspx
やべーわ完全に食わず嫌いだったわ。
見た目、.NETと同じく言語非依存のフレームワークを提供しているんだな。
標準入出力+αで満足するから完全に十分だわ。
というか結果的にMSには先見の明があったな。

以下によると//xでデバッガが起動出来るらしいが接続してくれない。
そっちでは動いている?
> WSHはVisual Studioでデバッグを行うことが可能です。
> Visual StudioはExpressの場合にデバッグが行えないかもしれません。Professional以降が必要かもしれません。
> http://qiita.com/mima_ita/items/127e171db67aaee6ef30
Vista+VSExpressなんだけどね。

123 :デフォルトの名無しさん:2016/05/13(金) 20:58:41.47 ID:JdHqQx2Q.net
外部と隔離された無人島で20年過ごしてきた人なのかな?

124 :デフォルトの名無しさん:2016/05/13(金) 22:06:05.08 ID:PxVJ9U+u.net
>>120
> EWM
否定したいわけではないが、君が言っているような「打ち出の小槌」なんてどこにもないんだよ。

低レベルAPIを規定して高レベルAPIを柔軟に構築というのは確かに出来る。
ただ、その高レベルAPIを「仕様として」リリースしたら、一般的にはもう削除は出来ないんだよ。
だから不要になった場合は、エミュレーションモードとして、動きはするがそれだけのもの(速くはない)として残すことになる。
VGAとかがまさにそう。今時のグラボもVGAは表示できないといけないので、この方法で残している。

ただエミュをするのなら、低レベルAPIによってではなく、実装側で高レベルAPIだけをエミュしたほうが簡単なんだよ。
それを低レベルAPIでエミュしろ、そうじゃないと駄目だ、ということになると、性能が引き出しづらくなる。
だから結局、低レベルAPIで高レベルAPIを構築というのは効率が悪くなる。多分頓挫する。
そのやり方はAPIではなく、ライブラリの粒度でやるべきなんだよ。
ライブラリってのは標準JavaScriptを低レベルAPIとして、中レベルAPIを構築しているわけだから。

例えばAppCache、もういらないとして、ブラウザ側で高レベルAPIだけをエミュするだけならまあ簡単だろう。
他の似た機能があれば、それと中身は差し替えて見た目だけエミュすることも可能だ。
(WebSQL->IndexedDBの場合とか)
しかしそれを構築するために使用した低レベルAPI群があるとして、これらも不要になるわけだが、
それらを全部エミュしたままで残せということになると、結局手がつけられず、そのまま残すしかなくなる。
結果、ブラウザ側に「開かずの扉」的コードが累積していき、長期的に進化を妨げることになる。
こうならないためには、「将来的にも」不要にならないAPIだけを規定していくことが肝要。
これは低レベルAPIの方が難しいんだよ。

125 :デフォルトの名無しさん:2016/05/13(金) 22:06:20.89 ID:PxVJ9U+u.net
まあいずれにしても、上手く行くかどうかは結果を見ればいい。
俺は上手く行かないと予想している。
ブラウザ側も馬鹿ではないから、俺が言っていることぐらい分かっている。
だからgoogleの「最適化としては行うが、asm.jsにべったりでは無い」というのがかなり妥当。
旗振り側のFireFoxは実装するしかないから、両方の言い分は分かる。
君の見方だけではgoogleが及び腰な理由を説明できないだろ。

126 :デフォルトの名無しさん:2016/05/13(金) 22:12:02.90 ID:PxVJ9U+u.net
> どうせちょっと高速化を意識するとTypedArrayをメモリに見立ててあれこれするようになる。
それはCの考え方だ。そして君はC/C++と連携するためにNodeを使っているのだから、君としてはそれで正しい。
ただ、「メモリ」を意識するのはJavaScriptじゃないんだよ。
だから、君はおそらくCの考え方に束縛されている。

というか、それだと君はJavaScriptを使えていない。
君だと、Rubyでは何故ただの数値ですらオブジェクトなのか説明できないだろ?

例えばサーバーのログを解析するとして、grepで済むならそれでいいけど、
それ以上なら通常はPerl等が用いられる。
もちろんこれをCでやることは出来るけど、普通はやらない。
理由は簡単、Perlの方が楽だからだ。
それをどうしてもCでやれ、Perlはインストールしてねーとなると、ふざけるな!となるだろ。

JavaScriptも同じで、クライアントスクリプトという政治的要因が無ければ、
当たり前だがその言語を使うのが一番楽(適している)ところで使われる。
その状態においては、
> どうせちょっと高速化を意識するとTypedArrayをメモリに見立ててあれこれするようになる。
これが要求されることはほぼ無い。
というか、メモリアクセス速度が要求されるのなら、最初からC/C++で書け、でしかない。
実際にこれで高速化するのなら、本来Cで書けばいいだけのものをJavaScriptで書いてるだけだよ。 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)


127 :デフォルトの名無しさん:2016/05/13(金) 22:12:42.95 ID:PxVJ9U+u.net
PerlやRubyと同様、JavaScriptにもいい点はあって、
それを生かす書き方をしていると、仮にCがブラウザで動いたとしても、Cじゃつれーわ、となる。
君にはそれが無いだろ?それはJavaScriptを使っているだけで、使えていない。

クライアントスクリプトでの高速化は、今の俺の結論としては「後回し」、これに尽きる。
1画面分しかDOM操作はしない。出来れば内部データも用意しない。
これだけで見た目はものすごく速くなる。

クライアントサイドでどうしても演算が必要な場合は、ゲームか非標準の強力な暗号化くらいだよ。
速度が重要なガチゲーやる奴は「サクサク専用アプリ」があれば必ずインストールする。
だから結局用途が無いんだよ。

速いことは重要なのだけど、JavaScriptに求められているのは演算やメモリアクセス速度ではない。
演算が10倍速になるより、DOM操作が2倍速になる方が効く。
asm.js っぽくコーディングするよりも、DOM操作を1つでも減らすようにした方が効く。
だから asm.js は悪くは無いけど、いい筋ではないんだよ。
そして一般のクライアントスクリプトで asm.js 流の書き方をすることも無いよ。
だって読みにくくなるだけで効果ないから。つまり、流行る理由が見当たらない。

君はasm.jsがブラウザに必要とされていると本当に思っているのかい?
asm.jsが実装されるより、ブラウザでのDOM操作速度が2倍になる方が普通はうれしいだろ。

128 :デフォルトの名無しさん:2016/05/13(金) 22:40:16.76 ID:PxVJ9U+u.net
>>121
> 仕様の量も段違い
とにかくこういうことにしたい奴が多いようだが、これは明らかに違う。
.NETにしてもJavaにしてもクラスライブラリの量は桁違いに多い。
文法的にも覚えることは多いし、記述的にもより細かく指定できる。
JavaScriptは軽くて簡単な言語だよ。元々そう作られたものだし。
(これは悪いことではない)

> その1つ1つのバージョンを意識したり指定したりということはできないし
> 原則後方互換性を守りながら拡張していくしか無い
Javaは知らんが.NETはバージョン管理されていて、
廃止されたメソッド等もある。(完全上位互換ではない)
ちゃんとやれば出来ることなんだよ。もちろんその実力が必要だけど。

詳しくは知らないが、DirectXはバージョンが一つ違ったら別物だったらしい。
低レベルAPIだから必然的に実装とリンクしてしまうのでこうなる。
結果的にMSはDirectXを使い捨てし続けることで乗り切っている。
Webもやれば出来るだけだよ。やってないだけ、やる実力も無いだけで。

とはいえ、試行錯誤でいくというのも一つのいい作戦だ。
その場合は、どうしてもゴミが紛れ込んでしまうので、定期的にGCしないといけない。
それが全く出来てないからおかしなことになっている。

129 :デフォルトの名無しさん:2016/05/14(土) 00:17:31.72 ID:8701OXOx.net
> 詳しくは知らないが、DirectXはバージョンが一つ違ったら別物だったらしい。
DirectXだけじゃなくて「昔は」って言ったほうがいいよ。

MSにかぎらず開発初期は変化が激しいのが普通だから
バージョンが一つ違っただけでも大幅に違いがある。

だけど、MSもそうだけど、成熟してくるとそう変わらない。
DirectXも同じ。

130 :デフォルトの名無しさん:2016/05/14(土) 05:05:12.84 ID:lm5IbmMb.net
>>124
だからその将来的にも不要にならないってのが低レベルなAPIであることは間違いないのだが。
例えばNodeはSocket APIがあったのでネイティブで対応する前からWebSocketやHTTP2にもすぐ対応できた。
低レベルってのは語弊があったかもしれないがこのSocket API程度のことをイメージして話してる。
CSSで言うと変数とかフローレベルの定義とか、その程度。
>>125
それは最初だけ。V8も去年から専用の最適化機構を入れている。
>>126
「Cの考え」とかはない。メモリに見立ててと言ったのが語弊が合ったかもしれないが、
盤面情報などを多重配列で構築する代わりに1つの型付配列に収める程度のアルゴリズムの問題。
データ配置を意識しないといけないが、実際幾つも変数やら配列データやらを用意するよりもシンプルになり、
パターンとしては別に他の選択肢と比べても奇抜ではなく、JSらしくないこともない。
>>127
実際asm.jsを使う場面が殆ど無いのは先も言ったとおり。
ただDOMがボトルネックの場面について(削減などに関する別の毛色の話は出来るだろうが)あれこれ言っても仕方がないし、
一方もちろんマイクロベンチ的なのを考えても仕方がない(本当はそうでもないこともあるが)と思っているので、
残った殆どないケースだがJSで書く必要があり、速度も必要な場面を基準に、「「ちゃんと」」書いた時の話をしたまで。
普通の場面で「「普通に」」書いた時の話はしてない。あくまでかなりニッチな話としてした。
>>128
Webは中央政権的でない(なくなった)から全てをひとまとめにしてバージョン付けはできない。
これは前提条件として話している。この前提がそもそも間違っているからと言う話題は
他のこれを前提の上どう良くしていくかの話題と分けてくれないとただの愚痴的批判でしかなくまともな話ができない。

131 :デフォルトの名無しさん:2016/05/14(土) 05:07:22.52 ID:lm5IbmMb.net
Webはそもそも誰のものでもなくオープンなものだ。これは前提以上のWebがWebであるための性質。
昔はいろいろなところがデファクトに沿いながらも自分達に都合のいい仕様を作った。
それじゃ困るからと言って標準化の動きがあって、ベンダーも自然淘汰され整理されてきたこともあり、ちょっとはまとまりがでてきた。
そこら辺で起こる、JSの高速化、スマホ等による環境の変化、中央政権的なFlash等プラグインの死。
よって今まで文章を表示するためでしか無かったWebを、アプリケーションの基盤となれるようにしようという需要・必要性が生まれた。
でもCSSの向上からBluetooth機能までありとあらゆることを一箇所で1つの仕様として定義するのは何十年かかるか分からない。
Flashのような中央政権的やり方はマズイという意識も合り、バージョニングの弊害の反省もあったので、
バージョンはむしろ廃止し、よりオープンなそれこそ誰でもGithubに書いて主張できるような仕様形態に「自然となっていった」。
さて、仕様策定のプロセスが大きく変わってきたが、(昔的な)標準機構(形・影は薄れてきてる)はこれから何をするのがよいのか。
じゃあもう低レベルなAPI群を定義して、もっとオープンに仕様を発展できるようにしよう。
というのがこれまでの歴史。
それを踏まえた上で分けて話して欲しい。

132 :デフォルトの名無しさん:2016/05/14(土) 08:40:44.17 ID:/oE1tyua.net
横から見てる者だけと、今のところはID:PxVJ9U+uの説明がしっくりくる感じ
ID:lm5IbmMb は表現が抽象的すぎてわかりづらい
「「ちゃんと」」(何をどうちゃんと?)
「「普通に」」(普通って何?)
「自然となっていった」(どの辺りが自然?)
何となくわかる気はするけど、具体的でない部分が誤解を生みやすいと思う
「ちゃんと === 速度を最上位に最適化した普通はやらないようなニッチな最適化」
こんな感じだと勝手に認識してるけど、一般的な感覚で考えても「ちゃんと」とは言い難いような

133 :デフォルトの名無しさん:2016/05/14(土) 13:45:41.17 ID:Jg6FEyPA.net
>>130
レベルに関わらず、「将来的に必要」なAPIだけ規定できれば全く問題ないのだが、
それが難しいんだよ。
AppCacheにしても、WebSQLにしても、その当時は「それが必要」だと思っていたはずなんだよ。
WebSQLの方は政治的横槍で、AppCacheの方は担当者の実力不足でゴミ化したわけだが。

いずれにしても、「今」そう思っているものが「将来も」正しいとは限らないんだ。
君が言っているものは「もう既にあって」「今必要」なものだろう。(Socketは1983年製)
それを仕様化するのも重要な仕事だけど、それは凡人でも出来る。
本来仕様化しなければならないものは、「今無くて」「将来およびその後もずっと必要」なものなんだよ。

AppCacheは後者をやろうとして頓挫した。これは実力不足だ。
WebSQLの方は前者、つまり既にあるものをWeb用に焼きなおそうとした。これは凡人でも出来る。
ただし政治的要因で頓挫した。
NodeのSocketは、前者でしかない。20年以上実績のあるものの導入であって、凡人でも出来るものだよ。

Webがもたらした「先進的」仕様は、例えばHTMLとCSSの分離とかだよ。
(当時はレイアウトと文書を分離しないのが一般的だった)
これが効いてて、スマホでも見れる画面になっている。(対応しやすい)
一方、基本的にピクセル指定する従来アプリ(.NET)とかをスマホで見ると悲惨だと聞く。
だから.NETはUIの焼き直しを迫られている。

AppCacheについては実は俺も使おうかと検討したことがあるが、止めた。
理由は、俺が対象としているサイトはリバースプロキシが普及していて、
変にキャッシュするより読み直したほうがサクサクだからだ。(304が速攻返ってくる)
これが他のケースでも当てはまるとしたら、仮にAppCacheの仕様がいいものだったとしても、誰も使わない。
この場合の正解は、「AppCacheなんてじきにリバースプロキシが普及するから必要ありません」だ。
あるいは、「オフライン?ナローバンド?そんなものはありえない時代がすぐに来ますよ」だ。
これを当時言い切れるかどうかが「先見の明」ということになる。

134 :デフォルトの名無しさん:2016/05/14(土) 13:46:10.60 ID:Jg6FEyPA.net
> JSらしくないこともない
要するに自分の手持ちの選択肢の中で「JSでやるのが一番マシ」と思えるのならそれでよし、
そうでないのなら、それはJSを無理に使っているだけだよ。

> 実際asm.jsを使う場面が殆ど無いのは先も言ったとおり。
ブラウザを作っている奴らも暇じゃない。無限のリソースがあるわけでもない。
奴らにとって「重要」だと認識されない限りは歯車は回らない。
そして今のところ、あるいは近未来的にもそうはならないというのが俺の見方だ。

135 :デフォルトの名無しさん:2016/05/14(土) 13:46:57.24 ID:Jg6FEyPA.net
> Webは中央政権的でない(なくなった)から全てをひとまとめにしてバージョン付けはできない。
これはそちらの認識が間違っている。
そもそも、仕様を策定するのは「困るから」であって、「支配する」為ではない。
元々W3Cがその位置にいたのだが、官僚的だったのか、とにかく仕様の決定が遅すぎた。
だから無視するのが通例になってしまっているが、本来はW3Cが機能していればよかっただけの話だ。

ただ結果を見ている限り、clientHeight/innerHeight等、
名前を決めればいいだけの部分でさえすり合わせ出来ていない点、
あるいはJavaScriptと名乗れずJScriptとなっている点等からしても、
(どちらが仕掛けたかはよく分からないが)何らかの政治的思惑が絡まっており、
W3Cは「使えない」として見切りをつけられているように見える。
(見切りをつけたこと自体は正しいが、それによって我々が不便をこうむっているのはご承知の通り)

136 :デフォルトの名無しさん:2016/05/14(土) 13:48:07.29 ID:Jg6FEyPA.net
> 中央政権的なFlash等プラグインの死
以下を読んだ。
> http://uxmilk.jp/5784
まあ俺も筆者と同意、Flashは死ぬべくして死んだだけ、
ジョブスが引導を渡した形になったのは、ジョブスに先見の明があっただけ、と思える。
実際、今Flashが欲しいって思うことは無いだろ?要らなくなったんだよ。

だから君の
> Webは中央政権的でない
というところが大前提として間違っている。
そもそも、何であっても「中央政権的」ではないんだよ。それが資本主義だから。

例えば、iPhoneが中央政権的であるとしよう。
ではiPhoneがその機能を「搭載」あるいは「削除」したら、他が「必ず」付いてくるか?
答えはNoだ。Flashが必要なら他サイトは対応し続けるだろうし、iPhone側も搭載を余儀なくされる。

例えば初期のiPhoneは「コピペ」機能が無かった。これはジョブスが「不要」と判断したかららしいが、
さすがにこれは3代目くらいで「復活」した。(これについてはなぜいらないと思ったのか謎)
Windows8はスタートボタンを「廃止」したが、誰も望んでいないこの変更は修正を余儀なくされた。
かつてRIMMという先進的DRAMがあったのだが、特許料を取るだけのものだと判明したため、
各社は旧来のDDRをDDR2/3/4と進化させるほうを選択し、RIMMは死んだ。
何かを中央政権的に仕掛けることは出来るが、それを追認するかどうかは市場が決める。
結果的に、無理な仕掛けは頓挫するようになっている。これは資本主義のいいところだよ。

君の世界観が中央政権的なものを肯定するのは、
一般に中央政権的なことが出来る規模のトップにいる奴はかなり優秀で、
そいつらのやったことが正しくて追認されることが比較的多いからだよ。
ただし上記のように、探せば結構間抜けなこともやっている。

137 :デフォルトの名無しさん:2016/05/14(土) 13:49:00.26 ID:Jg6FEyPA.net
だから、それが大多数の人にとって正解と思えるのなら、自然と
> じゃあもう低レベルなAPI群を定義して、もっとオープンに仕様を発展できるようにしよう。
ということになっていく。それは君や俺がどう思おうが関係ない。
ただ、そうなっていないのなら、それはそう認識されてないということだよ。
つまり君の認識が間違っているということ。

asm.jsもServeceWorkerももう数年になるが、これらは君的には普及したと思えるのかい?
あるいは、これらの流れを受けて、低レベルAPIを規定していくことが主流になったと思えるのかい?
俺にはそうは見えないけど。

138 :デフォルトの名無しさん:2016/05/14(土) 13:49:22.05 ID:8701OXOx.net
将来においても絶対に変わることがなくて、
ブラウザの実装者の負担にならない最低限の共通の機能をもったAPI
そしてその共通APIを使ってより便利なことをするライブラリ。

この2つを「標準化」するべきなんだよ。

今現在は、最低限のAPI部分しか標準化されてないから
jQueryやlodashなどがでてきてしまっている。

最低限の機能だけじゃ開発は楽にならないので、
他の別の何かは絶対に必要になる。

139 :デフォルトの名無しさん:2016/05/14(土) 13:49:51.20 ID:Jg6FEyPA.net
> よりオープンなそれこそ誰でもGithubに書いて主張できるような仕様形態に「自然となっていった」。
これは事実としてそうなっているね。
つまり大多数の人にとって、これが「現状一番マシなやり方」と認識されているということ。

ただし、
> バージョニングの弊害の反省
これはjQueryか?
一般的にバージョニングで問題が発生するのは使い方が悪いだけ。
つまり、「仕様」に関わってはいけないレベルの馬鹿な奴らがバージョンを規定するからだよ。
そして必要な機能を「中央政権的」に落としたりするから混乱する。
あるいは変更の必然性が無い(延期できる)部分をバージョンを変えたからといって無駄に変更してみたり。

バージョニングで成功している例は、例えばWindowsだよ。
外面バージョンは、95, 98, Me, 2000, XP, Vista, 7, 8, 10 となっている。
これらまとめて全部 Windows という名詞しかなく、
明示的に分離することが出来なかったら、会話するのに困るだろ。(Linuxがそれに近い状態)

正しくバージョニングが出来ない連中ばかりだからといって、
バージョン自体をつけないのはさすがに間違いだよ。
実際、ES5,6,7, HTML4,5, CSS3,4ってのがバージョンだし、バージョンが付いてない案件はさすがに無いと思うが。
(バージョンが廃止された案件は無いはず。機能していない案件は多々あるとしても)
そして「このブラウザでは、HTML5, ES5, CSS3 まで対応しています」と言い切るためのもの。

140 :デフォルトの名無しさん:2016/05/14(土) 13:50:45.96 ID:Jg6FEyPA.net
ところで、
> Bluetooth機能
これは何?と思って調べたら、本当にあるんだな。
> https://developer.mozilla.org/ja/docs/Web/API/Web_Bluetooth_API
仕様としてはまあ妥当だな。
正直、bluetoothまでWeb側で面倒を見る必要があるとは思えないが、
OSのシステムコールを直接やらせることは出来ないという縛りによって、
OSのシステムコールの再発明を迫られるという間抜けな事態に陥っている。
とはいえ、これについては今後とも再発明し続けるという解しか思いつかないな。
IEEE側の仕様を上手いこと流用する手はあるはずだが、あちらは低レベル過ぎるだろうし。

141 :デフォルトの名無しさん:2016/05/14(土) 16:17:29.52 ID:ciGNYqZA.net
だいぶ意見の摺り合わせがなされた。殆ど言葉の定義的なことやニュアンスの行き違いで
多分経験と立場からくる「常識」などの差を考えれば、根本的な部分の意見の出し方の相違はあまりないと思う。
もうこれ以上は無理だろうけど、明らかに違う部分と、自分の中で強い意見を持ってる部分だけ言っとく。

まずバージョニングについて。
もちろんバージョンが付いてる仕様(ほぼW3Cが中心で策定)も未だ多くあるが、Living Standard版(ほぼW3C以外が中心で策定)の仕様も多くある
HTMLのように両方ある場合、『ブラウザベンダーが見るのは、LS版の方』で、こっちhttps://html.spec.whatwg.org/multipage/introduction.html
(ここの1.6までを読めば多少感覚がわかると思う)

バージョンが付いてる方は、バージョンが付いていないと困ること(例えば製品の対応状況の表明、例えばある時期においての仕様参照)のために、
LS版の方から重要な部分を定期的に抜き出してまとめてるだけのものであって、実際我々開発者にとっては意味のないと言っていいくらいのもの。

まあバージョン=悪いとは言わない。仕様開発においてバージョンにとらわれ過ぎることの弊害というべきか。
そしてLS版はある意味で更新日付がバージョンとも言える。ようは異質な存在というより、もっと回転を早くしていきましょう的なものとも言える。

142 :デフォルトの名無しさん:2016/05/14(土) 16:20:23.84 ID:ciGNYqZA.net
そしてJSらしさについて
そもそもJSらしさとは何なのか?例えばクラスっぽいものを作ろうとした時、
functionと.prototypeを使うのがそうなのか?
それでもって継承っぽいものを実現したいときは、ハックに近い方法で言語の底のプロトタイプ性に干渉し為すのがJSらしいということなのか?
それとも今となってはclass構文と、extendsで実現するのが素直にJSらしいということなのだろうか?

自分はというと、どっちも使う。さらに、__proto__を使ったピュアなプロトタイプベースでクラスシステムを作ったり、mixinもやる。
そしてその全てがJSらしいと思っている。汚い部分も、何でもかんでもやろとする部分もJSらしさだ。
型付配列だってそう。JSに存在しているのだから、それを活用することは当然JSらしいと思っている。

自分はJSに関しては、仕様、策定プロセス、実装(特にV8)も含めて愛していて、自分にとってJSとはその世界全体だ。
いい加減に書けるのもJSだが、「こう書けば速くなります」と言った書き方もJSだと思う。
なぜならエンジンはJS(ES)仕様を実装しているわけだが、実装されたものがJSとも言えるからだ。

昨今標準仕様として策定が完了するためには、最低2つのメジャーなエンジンに実装されることが必要とされているが、
逆に言えば複数のエンジンがきちんとした意思を持って実装したものは仕様と近しいと思っている。
また重要なこととして、各エンジンの最適化は、なにも適当に出来そうなニッチなケースからしているわけではなくて、
世間で使われているコードが速くなるような最適化がなされているのだ。

つまり何がいいたいかというと、曖昧なJSにおいて、比較的きちっと最適化パターンに沿って書くのは、
テクニカルというより、『お行儀が良い』行為なのだ。

そして、asm.jsについても似たことが言える。TypedArrayを使うのは『良いアルゴリズム』だし、
asm.jsに沿って書くからといって、別にJS道を外れるというわけでもないのだ。
人それぞれ好きなように書けるのがJSだ、と考えてる。

143 :デフォルトの名無しさん:2016/05/14(土) 16:39:37.40 ID:ciGNYqZA.net
>>132
チョット違うな
「ちゃんと」ってのは「ちゃんと」だ。
ただ、「(そういう)ニッチなケース」における、「ちゃんと」だってだけ。
ただ自分がニッチなケースをわざわざ挙げたわけではなく、必然的にそこに行き着くということ。『必然』
「言語」で対比して話しているようだったからDOM周りの外部APIを活用するような、Webにおいて普通のものついては除いて考えざるを得なかった。
ただ1+1を何億回やるみたいなのの延長のマイクロベンチで語ってもあまり仕方ないと思った。
先方がN-Bodyを例に出していたので先にそちらにも触れたが、もうちょい大きな実用物でもそう言えるということを書いた。

そしてそのもうちょい大きな計算主体な実用物ってのは、自分が思い浮かんで良く作ってる中だと、
ゲームの先読みAIか、エンコーダ的なものかしか思い浮かばなかった。
だから前者のようなものでは1/2、後者ではまだSIMDとパラレリズムの実装が不十分な段階だから、もう1/2にはなるよと説明した。

別にそれはJSで書かなくてもいいと言われれば、勿論そのとおり。
でもJSで書くとなったとき、これらをJSで書こうとする微変態が「ちゃんと」書くとは、
当然最低でもボトルネック部分はasm.jsスタイル、そしてSIMD、SAB、AtomicsみたいなAPIも使いたいと思うだろう
(実際に対象の互換性を考えて使えないこともあるとかはおいといてね)という前提や思考の流れで書いた。

144 :デフォルトの名無しさん:2016/05/14(土) 17:31:31.31 ID:ciGNYqZA.net
ここまでの流れ、ちょっと狐につままれているような感じだ。
自分としては歴史や試した経験事実に沿って、淡々とお話した部分が多い。
別にこの宇宙において何が善悪かを語ったつもりもなく、一例を挙げたりしながら部分部分に対して必然的な事柄を語っただけだ。
だからバザール型云々の話も意図的にスルーしている。

本来は何が正しいのか、歴史のどこが間違っていたのか、を語りたいのではなく、
今はどういう状況で、それに沿って今からどういう心構えでいればいいのかを把握し、
一緒にWebを良くしていこうねということがしたかったからだ。

もしかすると例えば自分はその低レベルAPIが大成功すると考えてると思われてるのかもしれないが、べつにそうは思っていない。
策定に関しても、難しさは高レベルAPIと同じくらいだろう、と書いたように別に現状と大きく変わるとは思っていない。
ただ、そーゆーじだいなのよー、いーものつくってほしーね、ってだけ。

まあ、そういうわけなので、そもそもダメ、とか言うのは今回の話においてタブー視していた。
そもそもダメ、それも代わりにこっちの方がいいという案も出してくれてはいるものの、過ぎたことだったり、現実そうはならないことばかりだった。
今の流れに沿った上で、こういう風に改善していく道があるんじゃないかと具体的で現実的に示して欲しかった。
(現実的というのは、今からメーリングリストで発言すれば多少は風向きを変えられそうなくらいな意見をイメージしている)

まあできれば、APIレベルの改善点を挙げて欲しかった。
こういうAPIが良いんじゃないか、だから抽象的一般的にこういうことが言えるんじゃないか、
だから今のWebのこの流れは間違ってるんじゃないか、とね。

そうじゃないと、Webはそもそもがダメ、それを素直に直すのは無理、じゃあWeb捨ててネイティブ行くか!ネイティブ最高!
くらいしか考える事、言うこと無いよね、って思った。

145 :デフォルトの名無しさん:2016/05/14(土) 19:38:06.23 ID:8701OXOx.net
三行でまとめろ

146 :デフォルトの名無しさん:2016/05/14(土) 19:41:36.67 ID:8701OXOx.net
> そうじゃないと、Webはそもそもがダメ、それを素直に直すのは無理、じゃあWeb捨ててネイティブ行くか!ネイティブ最高!
> くらいしか考える事、言うこと無いよね、って思った。

ウェブ技術でネイティブ開発すれば良い。
そうすればネイティブのものをウェブに以降することもし易いし
その逆も簡単になる。

今はネイティブの方が機能も多く速度が早いが、その問題も
ハードウェアとソフトウェアの進化によって次第に解決しつつある。
JavaScriptに新しいAPIが生まれているのは、ネイティブにしかない機能を無くすためだし、
asm.jsとかも速度を早くするため。

最終的にウェブ技術さえあればどちらの開発もできるようになる。
その時ネイティブアプリの終焉が訪れる。

147 :デフォルトの名無しさん:2016/05/14(土) 22:08:17.97 ID:Jg6FEyPA.net
>>141
1.6まで読んだ。なるほどWHATWG側の見解は分かった。
しかし、ある意味ありがちな展開だ。
仕様を決めている奴は仕様を決めるのが目的で、使うためではないからな。(手段の目的化)
これは決裂して当然、とはいえもうちょっとマシな展開は無かったのかとも思うが。
そしてECMAscriptの仕様書が他言語と比べて異様な理由も理解した。

LS版が日付=バージョンなのはそれでいいが、
LSってのは「永遠に追いつかない目標仕様」であることを意味する。
実際そうなのかもしれないが。

本来は「仕様」がまずあって、それに沿って各所が部品を用意し、一気に組み上げるものだ。
プレハブの家とかいい例だ。
H264だって、仕様が確定してからでないとハードウェアデコーダは実装できない。
(仕様が少しでも変わるとゴミになる恐れがあるから)
LSってのはWebみたいに、いつでもダウンロードできて最新版が提供できるという前提でしか使えない。
LSでいけること自体がWebの強みかもしれんね。

148 :デフォルトの名無しさん:2016/05/14(土) 22:09:49.21 ID:Jg6FEyPA.net
> JSらしさ
ユルい所だよ。だから君の理解も間違いではない。

言語を比較するのなら、便利機能はどんどん追加されるから、裸の状態で比較した方がいい。
JSについては、型無し、動的確保、全ての関数にクロージャ、
お手軽匿名関数、正規表現、といったところだろう。(なお全て既存でありJSの発明ではない)
これらはCには無い。だからこれらを活用したいのならCよりJSということになる。
一方Cなら、ポインタ、最高速のメモリアクセス、ほぼアセンブラの低レベル記述となる。
だからメモリアクセスで勝負が決まったり、あるいはゴリゴリにチューニングしたいのなら、それはC向きだ。

例えばあるDOMのクリック回数をカウントしたいとして、JSなら
var count = 0;
dom.onclick = funciton(){count++;};
で終わりだ。一方、Cなら、
1. グローバルに配列またはハッシュを用意し、(遠くに記述される)
2. 各DOMに通し番号またはハッシュキーを用意し、(管理項目が増える)
上記と同様のコードとなる。
つまり、同じことを実現するのに、考えないといけないことが増える。要するに、面倒なんだよ。

JS含めてLL言語に求められるのは、チャキチャキ書いてサクッと実行、そして結果を得ることだ。
デバッグ時間も含めて結果を得るまでの最速が求められる。実行時の最高性能ではない。
だからお手軽に結果を得たければLLで、実行時の性能が第一ならCで書けということになる。

149 :デフォルトの名無しさん:2016/05/14(土) 22:10:30.57 ID:Jg6FEyPA.net
JSの特徴はユルさだ。だから君みたいに好きなように混ぜこぜで書くのならそれはJS向きだ。
ただ、TypedArray「しか」使う気が無く、またそれがそのアプリにとって重要なら、それはC向き案件だ。
それはメモリアクセス速度が重要だということだから。

N-bodyにこだわる必要は無くて、他のベンチでもおおむね同じだ。
「素のJS」を「素のC」と比べた場合、普通のコードなら5倍程度遅いということなんだよ。
当たり前だが添字範囲チェックはあるし、ハッシュキーも引くし、2重ポインタな訳だから、メモリアクセスは遅い。
TypedArrayでもこれらは変わらない。あれはこれ以前の型チェックが抜かれただけだから。

この状態で、5倍は見過ごせないというのなら、それはCで書くべきだし、
5倍程度で済むんだったら上等、それならイージーにやりたいと思うのならJSということだよ。
スクリプト言語で5倍程度なら、それは異様なほど速いので、俺は十分満足している。

TypedArrayは固定長配列だろ。それはユルさをひとつ消してしまう。
例えば、FIFOキューを作るとして、可変長なら shift(), push() だけで長さのことを考える必要もない。
それが固定長だと考える必要が出てくる。あふれないように追加のコードも必要だ。
もちろん固定長としてしか使わないのならTypedArrayでもいいし、
逆に固定長であることをTypedArrayで明記するというコーディングルールもありだろう。
しかし、こんなところを気にする奴が使うべき言語では無いんだよ。元々ね。それがLLというものだ。

150 :デフォルトの名無しさん:2016/05/14(土) 22:12:06.50 ID:Jg6FEyPA.net
多分な、Web系の奴らが勘違いしているのは、「Webは特別だ」と思っていることなんだよ。君も若干そんな感じ。
ただ、Webは特に難しいわけでもなく、移り変わりが激しいわけでもなく、また逆に、言われているほど馬鹿でもない。
関わっている普通の人たちが普通にがんばってきた結果が今であり、それはどの時代も大して変わらない。

> APIレベルの改善点
Bluetoothはあんなもんだろう。Promiseを返すのがいいのかは若干疑問だが。
DOMみたいにgetterが設定されまくったオブジェクトを返すほうが親和性があると思う。

AppCacheは要らないのなら廃止すべき。少なくとも「10年後に廃止する」というアナウンスを出すだけでもぜんぜん違う。
WebSQLも廃止するのなら廃止で、IndexedDBに統合するのなら廃止予定をアナウンスすべきだろう。
これらも放置すればブラウザの足を引っ張ることになる。廃止は10年後でいいから、その種まきを今やるべきだ。

asm.jsは基本的に意味の無い演算をすることになっていて、それで型情報を補完しているだろ。
だったら実演算部分に突っ込むのではなくて、コメントでもよかったんだよ。例えば、
function someFunc(start) {
start = start | 0;
ではなくて、
function someFunc(start) { // "use asm: int32 start"
とか。//で始まった一行コメントの最初に "use asm:がある場合に有効となる。
これだとasm.js非対応時に速度が落ちるという間抜けな事態は発生しない。
ただしコメントがバグっている場合は asm.js 対応環境でのみ動作しないということが発生する。(非対応環境では動作)
しかしこのコメントをつける奴らは当然対応環境でデバッグするのだから、これでいい。

151 :デフォルトの名無しさん:2016/05/14(土) 22:13:45.30 ID:Jg6FEyPA.net
XHRは304が見えるようにしたほうがいい。
XHLHttpRequest.canSee304 = true で status に 304 が見えるみたいなのでいい。もちろんデフォはfalseで。
あとリクエストの優先順位付けが出来た方がいい。
大量にXHRを発行するとブラウザ側の<img>レンダリングと取り合いになって、どちらかが待たされる。
優先XHR > 画面内img > 基本XHR > 画面外img > 劣後XHR
で3レベルあれば十分だと思うが、これはもう少し検討した方がいい。
今はchromeだと「先にリクエスト打ったもの勝ち」になっている。

DOMはレンダリングを一時停止するAPIがあったほうがいい。
DocumentFragmentはひとかたまりでしか使えない。
ばらばらの場所に一度に大量挿入するときにレンダリングをとめる手段が無い。
具体的に言えば、今画面に表示されているDOMをソートしなおすときとかに使う。

Array.createはやっぱり欲しいときがある。

ぱっと思いつくのはこんな感じか。
君の手柄にしてくれていいからよろしく頼むわ。

ところで君はNodeをコンソールでも使っているかもしれないようだが、デバッグ環境はどうなっている?
俺は>>122のとおりWSH+VSには失敗している。
NodeがChromeDevToolsでデバッグできるのならそれも相当魅力的なので。

152 :デフォルトの名無しさん:2016/05/14(土) 22:17:11.45 ID:8701OXOx.net
>>150

> 多分な、Web系の奴らが勘違いしているのは、「Webは特別だ」と思っていることなんだよ。君も若干そんな感じ。

Web系じゃないやつが勘違いしているのは、
「Web系の奴らがWebは特別だと思っている」はずだと
思っていることだよ。

誰も特別だと思っちゃいない。
お前には特別に見えるのか?
ならお前が特別だと思ってるんだろ。

153 :144:2016/05/15(日) 05:38:37.51 ID:79V1eiQO.net
>>146-
まあAppCacheは(一応JSへのAPIもあるがそんなに使われていない)
あくまでキャッシュなのでいきなり削除しても問題になることが少なく
特例的に極めて廃止しやすい方だ。(廃止される)
他のAPIも、LSが広まりだしてから非推奨を設定しやすくなった。

しかし、ブラウザがその実装を取りやめるのは、各ブラウザが収集している
ユーザーが閲覧しているページでのAPIの利用頻度が実際にほぼ無視できるレベルまで落ちた時だから
開発者やそのための解説情報作者のモラルを高めないことには難しい。

とは言え、10年も経てば流石にどんな仕様でも削除出来ると思うよ。
ただ、EWMの夢物語でさえ東京オリンピックのころかなというイメージだ。
10年は自分にとってWebにおいて永遠と等しいように感じる。

154 :デフォルトの名無しさん:2016/05/15(日) 09:04:33.00 ID:u/cc/woI.net
>>153
> 10年は自分にとってWebにおいて永遠と等しいように感じる。
これでいいんだよ。逆に有限で廃止すると混乱する。

> 10年も経てば流石にどんな仕様でも削除出来ると思うよ。
どんな糞仕様であっても放置しているだけでは削除できない。
typeof(null) が object なのを削除できてないだろ?
あるいはthisがグローバルになるという糞仕様も削除出来てないだろ。
この2つなんて、ただのバグの温床であって、活用できるものではない。
ではデフォで"use strict"にできているかというと、これも出来てないだろ。
そういうものなんだよ。

Webの仕様で、ただの案ではなく、完全に「正式仕様」として認識されたもので、
「正式に廃止」されたものがあるかい?
上記を見る限り、使われなくなったものは多々あっても、「正式に廃止」されたものは無いんだと思うよ。

> しかし、ブラウザがその実装を取りやめるのは、各ブラウザが収集している
> ユーザーが閲覧しているページでのAPIの利用頻度が実際にほぼ無視できるレベルまで落ちた時だから
まあこれは一概には言えないけどね。chromeはJavaを切ったろ。無視できるレベルではなかったと思うよ。
実際に、俺は偶に遭遇するしね。
これも「正式に廃止」したのではなく、勝手にサポートを止めただけだ。
事実上の廃止勧告であったとしても、仕様から「正式に廃止」することは無いのだと思うよ。

本来、仕様策定とは、こういった混乱を防ぐためのものだ。W3Cは全く機能していない。
この点については、
>>131
> (昔的な)標準機構(形・影は薄れてきてる)はこれから何をするのがよいのか。
WHATWGは新仕様の採用には積極的なのだから、もうそっちは完全に任せて、
W3Cは旧仕様の削除に専念するのもありだと思うよ。
後者は要するに利害関係者間の調整であって、WHATWGの連中がやりたがる仕事ではないし、
本来の「仕様策定」側の仕事でもあるから。

155 :デフォルトの名無しさん:2016/05/15(日) 12:44:09.17 ID:mCzE/lrH.net
何で削除出来てないかって、単純に
破壊的仕様変更は許さないだけでしょ。
言語仕様を変えるのもまずありえないけど、デフォルトを変えるって実運用では禁じ手じゃん。
だから、これはvいくつですよ、って宣言書いて、非対応であればハネる仕組みを充実させるしかないし、ポリフィルが要らなくなることは無い。

156 :デフォルトの名無しさん:2016/05/15(日) 13:47:01.97 ID:e+kzQGE7.net
ブラウザのJavaScriptの特殊性を分かってないんじゃないだろうか?

開発した時のJavaScript実行環境と
違うバージョンの実行環境で動かすことだってあるのが
ブラウザのJavaScriptなんだが?

実行環境は互換性を保っていなければいけない。
当たり前の話なんだがな。

コンパイル言語で言えば、ある機械語の動作を
変えてしまうってことだよ。

157 :144:2016/05/15(日) 16:58:58.26 ID:79V1eiQO.net
>>151,154
昔は知らないが今のバージョンのXHRは試したが304が最初から見えるはずだ。
優先度については自分もこの間も悩んだばかりだ。
XHRの進化は終わっているが、Fetchの方などでそこの部分は議論されているので見込みはあるかもしれない。
Fetchでは一応今のところリクエストには優先度というパラメータがある。(ユーザーエージェントが決める)
というとこまで決まっている。
まあ、みかけ上帯域制限するだけならStreamAPI使えば今でも出来るんだが、
帯域制限することも考えたAPIでないから、このAPI上でストリームを絞ったところで
実際ブラウザやOSがそれに従うという保証がないのが残念なところ。

DOMの一部分のレンダリングを止めるというのはちょっと難しいかも知れないが、
一旦スタイル指定で隠すというのが今のブラウザに対するそう言ったメッセージで、
そうしておくと無駄な処理は省略してくれる。
もしくは、DOM及びそれにアクセスするJSのプロセスを分けるという試みが為されているので
その延長上で期待するような状態が作れるかもしれない。

そして機能の正式な廃止だが、HTML5以前は独自実装およびデファクト仕様の山で、
HTML5になってから多少は整理したが未だ漏れてるものも数多くあるので、
廃止されるとなっても、それは機能の廃止というより独自実装の取りやめ、標準への追従に見えるということ。
実際にはshowModalDialogとかそこそこメジャーでも各ベンダーが一生懸命廃止させた仕様は幾つもあるし、
人知れず消えてったマイナーな仕様、挙動は沢山ある。

158 :デフォルトの名無しさん:2016/05/15(日) 17:01:58.55 ID:79V1eiQO.net
>>154
'use strict'強制は、ES2015のclass構文内やモジュール内で達成されている。
typeof nullの挙動は2年前治そうという案の盛り上がりが頂点に達したのだが互換性のために断念した。
が、将来的な演算子オーバーロードの仕様が入ると共に直す策を入れようと言う案は出てる。
もしくは、V8が画策している型付厳格JSの方向性が成ればそちらでも更生は可能。

でも自分としては、動的言語で型を一生懸命「事前にチェックする」のは良くないという持論を持っている。
その代わり、せっかく備わっている暗黙の型変換を利用して、型を「揃えて」おくのが良いと思う。
例えば自然数入力を期待してpromptを出し続けるのであれば、
do{
n = prompt('自然数') | 0
}while(n <= 0)
で良い事が多いし、良いとするようにする。
この場合入力がキャンセルされた際のnullも、空入力の""も+演算子で0になる。
そういうパターンを活用し、そういうパターンが活用できるようなロジック・仕様を組み立てるのが、
JSをスクリプト言語として上手く活用していく上での1つの答えと思っている。

そういう感じで、nullに関して重要なのは、もっとよく扱えるようにする事かもしれない。
例えば昔から案があって、直近はそろそろ仕様に入りそうなくらい盛り上がってきたこれ
https://esdiscuss.org/topic/existential-operator-null-propagation-operator
こういう演算子が入ったりすれば、ますます「事前にチェックする」必要性がなくなる。

159 :デフォルトの名無しさん:2016/05/15(日) 17:04:24.78 ID:79V1eiQO.net
誤字脱字や凡ミスは良いように解釈してくれ。スマヌ。

160 :デフォルトの名無しさん:2016/05/15(日) 17:51:57.74 ID:u/cc/woI.net
そういえば asm.js については、本当にこれが必要だと思っているのなら、本格的に型を導入したほうがいい。
someVariable = someVariable | 0;
の代りに
function(int32 someVariable){
また、
var someVariable;
の代りに
int32 someVariable;
double64 someVariable2;
だ。というか、asm.jsはかなり中途半端な仕様で、本格的に型が導入されてたら完全にゴミになるだろ。

この記法だと、当然JIT側の対応が必要となるので、
周知徹底、つまり「仕様として正式通達」が必要だし、浸透する時間も必要だ。
ただ、JITの改変自体は、宣言部は functionDecSrc.replace(/int32|double64/g,'');
中身は functionSrc.replace(/int32|double64/g,'var');
を頭につけるだけだから、やる気だけの問題だ。
政治的に問題なく、大手の協力さえ得られれば、1年でいける。
本来はこういう「関係者間の折衝」含めていい仕様を策定するのがW3C等の仕事だ。

161 :デフォルトの名無しさん:2016/05/15(日) 18:16:01.44 ID:gfIC+EQb.net
>>160
アホか。パーサ書いて文脈見ずにreplaceなんかで解決できねえよ。

162 :デフォルトの名無しさん:2016/05/15(日) 19:03:27.04 ID:u/cc/woI.net
>>157
> 昔は知らないが今のバージョンのXHRは試したが304が最初から見えるはずだ。
いや、見えんぞ。Vistaなんでアレなんだが、
chrome 50.0.2630.1 canary SyzyASan と FireFox 45.0.2 だ。
もしそちらで確認できるのなら、環境を教えてくれれば助かる。
Flags等の設定をしているか?俺は全くしていない。

一応確認だが、DevToolsやFireBugで 304 になっているリクエスト結果に対し、
JavaScript側から XMLHttpRequest.status で確認すると 200 になっているということだ。
アップデーターを実装したとき、304ならその時点で処理を止めたいのだが、
全部200に化けているからこれができない。

163 :デフォルトの名無しさん:2016/05/15(日) 19:54:18.43 ID:79V1eiQO.net
>>162
http://httpstat.us/304
に対して試してるんだけどそれらの環境で304取得できるよ。
こういうコードで。
xhr = new XMLHttpRequest
xhr.open('get', '304')
xhr.onload = () => console.log('status', xhr.status)
xhr.send()

164 :デフォルトの名無しさん:2016/05/15(日) 19:55:03.02 ID:79V1eiQO.net
おっと、
xhr.open('GET', 'http://httpstat.us/304')
にしとくか

165 :デフォルトの名無しさん:2016/05/15(日) 20:00:25.76 ID:u/cc/woI.net
> Fetch
見てみたがよく分からん。
ただ、帯域制限したいのではなく、本当に必要なものを順に取得したいだけなんだよ。以下とも絡むが、
> 一旦スタイル指定で隠すというのが今のブラウザに対するそう言ったメッセージで、
これは display = 'none'; だよな?これだと確かにレンダリングはされないのだろうが、
その中に<img src='XXX'>があると src をとりにいくんだよ。
結果、この明らかに表示に関係ないリクエストでXHRが待たされてしまう。
また逆に、表示する<img>のsrc取得も、大量にXHRを打ち込んだ後だと待たされてしまう。
これはモロに表示が遅れるので丸見えになる。
自動でやってくれるのが一番いいのだけど、多分それは無理なので、(XHRが表示に関係するか判定できない)
少なくともユーザー側で「今欲しいかどうか」を指定する必要がある。

> DOMの一部分のレンダリングを止めるというのはちょっと難しいかも知れないが
いや、一部分ではなく全体を止めていい。
アップデータで更新部分を差し込む際、結果的にばらばらの位置に差し込まれるときがあるんだよ。
ただ、差込自体は一度に行われるし、全部差し込んでからレンダリングでいいので、全体停止でいい。
多分ダブルバッファ的なものをやりたがる奴も出てくるはずなので、どの道必要になるとは思うのだが。
今のDOMはレンダリング制御用のAPIが全く無いんだ。
(とはいえ、速度にこだわらなければ無くてもいいんだが)

> Null Propagation Operator
これは好みだろうな。
if (a && a.b) a.b.c = d;

if (a?.b?.c) a.b.c = d;
と書けるという事だろうけど、こんなところでタイプ量をケチってもしょうがないし、
バグってても見た瞬間修正できるので、正直どうでもいい。

166 :デフォルトの名無しさん:2016/05/15(日) 20:08:28.09 ID:u/cc/woI.net
>>163-164
サンクス。こちらもそのコードで304を確認した。
ただし俺のスクリプトでは確かに304が200に化けている。
原因究明には少し時間がかかりそうだ。

167 :デフォルトの名無しさん:2016/05/15(日) 20:45:26.55 ID:u/cc/woI.net
>>158
> 動的言語で型を一生懸命「事前にチェックする」のは良くないという持論を持っている。
流儀があるのなら好きなようにすればいいし、コーディングルールに引っかからなければいいとは思うが、
それは一般的にはトリッキーだと言われると思うぞ。

null と '' を弾きたいのなら、普通はチェック部分に纏めて以下にする。
do{
n = prompt('自然数');
} while(!n || n <= 0)
知ってないといけないことは、null は偽(常識), '' は偽(JavaScript特有)だ。
前者は他言語でもそうなので、後者だけ知っていれば済む。

それに対して、君のコードは
1. null | 0 の結果がどうなるか(JavaScript特有)
2. '' | 0 の結果がどうなるか(JavaScript特有)
を知っていなければならない。自動型変換後のビット演算だ。かなり仕様の隅っこ。
そしてそれは制御論理とは本質的に関係ない。
つまり「JavaScript知ってる俺カッケー」でしかないんだよ。

しかも、論理構造に無駄があるだろ。
俺のコードは、弾く部分で弾いているだけ。
弾かれる対象を確認するためには、whileの1行を見れば済む。
君のコードは、不正入力は後で弾かれる入力に変換して、結果的に後から弾く構造になっている。
だから弾かれる対象を確認するためには、2行見ないといけない。
記述が分散している分、バグも含みやすい。

だから無駄に難しいコードになっているんだよ。
それで速度等のメリットがあればいいんだけど、今回については無いと思う。したがって、糞コード扱いされる。

君は無駄に3倍難しいコードを書いている。
それは、俺のような単純明快なコードを書くように勤めれば、同じ労力で3倍の規模のコードを扱えることを意味する。
君のやり方だと能力の2/3をみすみす捨てているようなものなんだよ。勿体無いだろ?

168 :デフォルトの名無しさん:2016/05/15(日) 20:52:38.61 ID:u/cc/woI.net
>>158
> 'use strict'強制は、ES2015のclass構文内やモジュール内で達成されている。
確認した。現実的にはこれで問題なさそうだな。
http://stackoverflow.com/questions/31685262/not-recommended-to-write-out-use-strict-with-es6

169 :デフォルトの名無しさん:2016/05/15(日) 22:01:03.99 ID:u/cc/woI.net
>>163-164
どうやら 強いEtag + nginx + gzip の場合に駄目らしいと分かった。
俺のスクリプトで化けているサイトも該当している。
> https://github.com/rtomayko/rack-cache/issues/111
しかしこれはこちらではどうにもならんな、、、、

とりあえず、XHRの問題ではないことは確かなようだ。

170 :デフォルトの名無しさん:2016/05/15(日) 22:04:49.13 ID:WWQ4vbR2.net
>>165
優先順位を粗方決めたいだけならServiceWorkerを使えば可能そう。


>>167
つまり何が言いたいかというと、
n = prompt('自然数')

(この型は何だ!??)
という状態のまま処理を出来る限り進めないということ。
もっと言うと、「n」なのに数値じゃないかもしれない可能性を作らないこと。

このnをあちこちのサブルーチンに配ればあちこちで型に対するチェックや配慮が必要になってしまう。
そうではなく、もうなるべく早く、できればもう変数に最初に入れる前くらいに取りうる値を出来る限り狭めておく。
そうして置けば以降そのnについて心配しなくていいし、そういうのを徹底しとけば
いろんなサブルーチンを書いたり使うときも、引数の扱いで心配することが減る。

JSにおいて型周りで一番多く、かつデバッグが困難なのは、
数値と文字列、そしてそれにパターンマッチが絡んだりする場合だと思ってるので、
特にDOM APIにおいては明示的に数値や文字列にまず揃えることがお作法だと思っている。

どうでもいいが、変数や引数の型が一定になることはエンジンにとっても優しい。

だがそれで長々とやってたら動的型付け使ってるのが馬鹿みたいなので、
自分は暗黙の型変換(''+、+、|0、のようなもの)を活用する。
まあ「Number(str)」でもいいが、「parseFloat(str)」は嫌いだ。

171 :デフォルトの名無しさん:2016/05/15(日) 23:44:52.60 ID:9x+kn/QP.net
>>143
こいつダメだ

172 :デフォルトの名無しさん:2016/05/15(日) 23:55:13.32 ID:u/cc/woI.net
>>170
> ServiceWorker
とりあえずhttps限定の時点で使えない。
気持ちは分かるがそこはユーザに選択させろよなと。

ただchromeが勝手に読みにいく<img>に対して優先かそうでないかを指定できないと意味が無い。
自分が打ち込むXHR内での優先順位ではないんだ。
ただそれ以前に優先順位のつけ方が見当たらないが、どれ?
https://developer.mozilla.org/ja/docs/Web/API/Request

173 :デフォルトの名無しさん:2016/05/16(月) 00:26:42.96 ID:GmJz87Lv.net
>>170
主張は分かるがそれは完全に「型あり」の考え方だからな。
そうしたいのなら、「型」を導入してキャストするのが一番いい。
つまり、

Int32 n = (Int32) prompt('自然数');

となる。どう見ても Int32 にしかなり得ないと、一目で分かる。

ああ、だからそういった意味で言えば、 asm.js はキャストでもよかったのかも。
彼らは value | 0; で Int32 にキャストしているつもりなのかもしれないが、
それはビット演算を絶対にしない人の感覚であって、
実際にビット演算を使用する人の場合、あの記述だと混ざってしまうのでよろしくないんだよ。
とはいえ、JavaScriptの通常の使い方でビット演算が必要なことはかなり稀なのだけど。

> 特にDOM APIにおいては明示的に数値や文字列にまず揃えることがお作法だと思っている。
いやこの必要なくね?APIは期待した型を返してくるし、そこで引っかかった覚えは無い。
'px'が付いている連中は若干うざいけど、バグったらすぐ分かるし。

ただやっぱ君は「型あり」向きだと思うよ。俺もだが。
var 禁止で全部 Int32, double64, string のどれかに差し替えろといわれても大して不満無いだろ。

174 :デフォルトの名無しさん:2016/05/16(月) 05:31:59.61 ID:3fs8uQMw.net
>>172
HTTPS必須は、「Let's Encrypt」が一般的に広まって、もっと道入が楽になることに期待する。

SWはXHRに限らず、あらゆる通信をプロキシできる、そしてその種類(image等)が分かるので、
例えばページが開かれてから200msの間全てを保留して、
その間に溜まって、その後も溜まっていくものから優先度の高いと思うのから捌いていけばいい。

ただこれではimg間での優先度が付けられないのでそこは工夫する。
一番簡単なのはhashを使ったりURLに情報を入れる事だろう。(src='〜.jpg#high')
もしくはページ自体の取得もSWを通じて行われるので、もっとアグレッシブにHTMLを解析してリクエストが来る前に読み込んだり、
初回開いたときにリストを作っておいて、次回から利用するとかいろいろ考えられる。

175 :デフォルトの名無しさん:2016/05/16(月) 08:47:49.06 ID:Pz1/eYkg.net
横から口を出すが

>>173
結局、>>167の主張はスルーして「ToInt32(null) === 0 を知っていなければならない」の前提でいいのか
俺としてはES6の標準関数も型変換されているから「型変換ルールは知っていなければならない」で当然だと思うが

Math.min(null, 1); // 0 (「ToNumber(null) の結果がどうなるか」を知っていなければならない)
Math.min('', 1); // 0 (「ToNumber(null) の結果がどうなるか」を知っていなければならない)

それから>>158は型付を否定しているわけではなく、「事前にチェックするのが良くない」とする考え方だ

function hoge (int32 n) {} // 事前にチェックするので bad
 ↓
function hoge (i) { var i32 = ToInt32(i)); } // 事前チェックは通過するが、後で型変換する
function hoge (i) { int32 i32 = ToInt32(i); } // 同上(型付でも考え方は変わらない)

長すぎる云々は>>158がES6範囲内で動くコードを書いているのに対してあなたがこうあるべき新仕様と対比しているので当たり前
短くしたいのなら

function hoge (toint32 i) {}

でも作り上げればいくらでも短くなるだろう(自分で短い仕様を構想すれば良いんだから)

176 :175:2016/05/16(月) 09:11:44.49 ID:Pz1/eYkg.net
>>154
HTML5でかなりの要素が廃止された
http://momdo.github.io/html51/obsolete.html#non-conforming-features
CSS2.1ではかなりの仕様変更がなされた(削除ではないが、変更でも現行CSSには影響力があるものだ)
http://www.d-toybox.com/spec/CSS2.1/appendixC/index.html

削除ではないが、追加する事で影響を受けたのがtypeof演算子
ES6でSymbol型が増えた事でObject型のチェックが面倒になった
Object (host and does not implement [[Call]])は規定文字列以外の全ての文字列値をとり得るが、"symbol"が追加された事でtypeof arg === "symbol"がObject型ではなく、Symbol型となった
実際、ES6でもType()に相当する機能がないんだよな...
http://ecma-international.org/ecma-262/5.1/#sec-11.4.3
http://www.ecma-international.org/ecma-262/6.0/#sec-typeof-operator

177 :デフォルトの名無しさん:2016/05/16(月) 12:29:46.57 ID:8sje1dNr.net
そういえば、lodashのisObjectは未だに"object", "function"しかチェックしないな
https://raw.githubusercontent.com/lodash/lodash/4.12.0/dist/lodash.core.js

function isObject(value) {
var type = typeof value;
return !!value && (type == 'object' || type == 'function');
}

178 :デフォルトの名無しさん:2016/05/16(月) 15:12:30.62 ID:x27HpYqy.net
なんでそういう実装になってるんだろう?
function isObject(value) {
return value === Object(value)
}
の方が素朴で良い実装じゃね?

179 :デフォルトの名無しさん:2016/05/16(月) 15:16:43.42 ID:x27HpYqy.net
まあはやくReflect.isCallableとか追加されて欲しい、
ダックタイピングぽく、型より機能としてチェックするほうがいいと思う。

180 :デフォルトの名無しさん:2016/05/16(月) 23:16:06.67 ID:GmJz87Lv.net
>>174
それはやれば出来るかもしれないが、「制御のための制御」になるので駄目だ。
別の言い方だと、それにかかる労力の割りに得られる結果がショボ過ぎて駄目だ。

そこらへんもやはり君はCの感覚なんだよ。「やりきれば出来る」というのがそう。
LL言語だと、「面倒なことは事はやらない」なんだよ。その分動作は遅いけど、手抜きが出来る。
そしてこの手抜きが出来る分、大規模なプログラムを扱うことが出来、
結果的にもっと大掛かりなこともできるという利点につながるんだよ。

分かるか?
勝負するところが違うんだ。
Cのような行単位でチューニング済みの最速コードを目指すのではなくて、
積極的に手を抜いて、結果的に規模の限界を突破することを目指すんだよ。
Cで10k行のコードを扱えるのなら、LL言語では30k行のコードを扱える。
当然やれる範囲が広がるだろ。
JavaScriptは簡単だから馬鹿でも扱えるというのは事実だけど、そこで留まるのではなくて、
それを達人が使ったら何が出来るのか?を目指すんだよ。
普通は「早く仕上げる」ためにLL言語なんだが、それだけではないんだよ。

181 :デフォルトの名無しさん:2016/05/16(月) 23:32:06.76 ID:GmJz87Lv.net
>>175
> 長すぎる云々
まず文盲で無いことを示してもらおう。これは具体的にどこのことだ?
俺は長さについては問題にしていない。

文盲を相手にしてもどうせ読み間違えまくってくるので議論はどうやっても空回りする。
これはもう既に学んだ。

182 :デフォルトの名無しさん:2016/05/16(月) 23:37:53.21 ID:oaJCE3x/.net
>>181
>>167の下記だろう

俺のコードは、弾く部分で弾いているだけ。
弾かれる対象を確認するためには、whileの1行を見れば済む。
君のコードは、不正入力は後で弾かれる入力に変換して、結果的に後から弾く構造になっている。
だから弾かれる対象を確認するためには、2行見ないといけない。
記述が分散している分、バグも含みやすい。

183 :デフォルトの名無しさん:2016/05/17(火) 02:50:45.73 ID:rVqZFYUE.net
> 弾かれる対象を確認するためには、whileの1行を見れば済む。

一行で書けば同じでしょ?

弾かれる対象を確認するためには、どこかの1行を見れば済む。

184 :デフォルトの名無しさん:2016/05/17(火) 03:25:50.15 ID:rVqZFYUE.net
それに一行に複数の意味を込めたらだめだよw

185 :デフォルトの名無しさん:2016/05/17(火) 09:05:07.26 ID:sIex+koZ.net
>>180
確かに個人的にはそういうコードを毎回書いても楽しいから苦にならないのだが、
何もそうしろと言いたかったわけではなく、一般的に利用するときは
ただそういうフレームワークを読み込んで、各リソースURLに「#priority」を付けるだけ
ってのは十分労力の割に結果がデカイと思うよ。

WebやJSの歴史見ても、「面倒なことは事はやらない」ってより、
「面倒なこと、汚いことは事はライブラリやフレームワークがやる」だった。

186 :デフォルトの名無しさん:2016/05/17(火) 13:34:21.32 ID:3yAYzGW4.net
>>167は null, '' しか考慮していない時点でダメ
"123hoge" を撥ねない時点で期待通りに動かない(自然数以外も代入されうる)

187 :デフォルトの名無しさん:2016/05/17(火) 14:54:21.35 ID:bcEq7422.net
一番ヤバイのはnが文字列であることだろう
後々必ず問題を引き起こす

188 :デフォルトの名無しさん:2016/05/17(火) 17:31:09.24 ID:ZRrmZHfn.net
>>167は仕様理解者に恨みでもあるのか
「JavaScript知ってる俺カッケー」とか偏見にしても度が過ぎていると思うが

189 :デフォルトの名無しさん:2016/05/17(火) 19:36:20.35 ID:lpSSxhpK.net
分からんな
演算子による暗黙の型変換を一通り覚えるのは
中級者への登竜門でそれほどハッキーなこととは思えん
Dateのインスタンスだけはプリミティブ化されるとき、
valueOfよりもtoStringの方が先に呼ばれるみたいなことを
前提なコーディングは流石に万人向けではないと思うが

190 :デフォルトの名無しさん:2016/05/17(火) 22:07:15.55 ID:XBBLWA5H.net
暗黙の型変換は標準メソッドでも行われている事だし、それを覚えずしてJavaScriptを使うっていうのはなあ..
>>158の問題点は ToInt32 されるから 9007199254740991"|0 === -1 になる事だが、>>167の問題に比べたら些細な問題だ
これは Math.floor を使えば解決できる

do {
var n = Math.floor(pronpt('自然数'));
} while (n >= 0)

Math.floor() の暗黙の型変換(ToNumber)が「JavaScript特有」な論理をふりまくなら Math.floor(Number(pronpt('自然数'))) としてもいいが、正直冗長だと思う

191 :デフォルトの名無しさん:2016/05/17(火) 23:41:38.85 ID:q3gkuA0r.net
>>185
> 「面倒なこと、汚いことは事はライブラリやフレームワークがやる」だった。
正確に言えば、「やるとなると面倒だが、普通はたいていの人が必要とすることは、ライブラリやフレームワークがやる」だ。
これはWebに関わらずプログラミング一般だ。それがライブラリ/フレームワークの存在意義だし。

> 各リソースURLに「#priority」を付けるだけ
になっているライブラリ等が既にあるのかい?それなら確かに導入する意味がある。
それはどれだか教えてくれないか?
(ただ、多分俺の環境では実際に導入することは出来ないが)

いずれにしても、「がんばってまでやりきる」為の言語ではなく、「がんばらずにやれる範囲でサクッとやる」なんだよ。
既にライブラリやフレームワークがあるのなら、「がんばらずにやれる」のでサクッといただきだ。
そういう奴らが多い+プロプライエタリには極度にしにくいから結果的にいろいろ乱立することになるが、
それはある意味正しい姿といえる。
少し無駄や気に入らない部分があっても、自前で作り直すのではなく、面倒だからそのまま使う、だ。
その1メソッドの中での最適化で勝負するのではなく、
もっと大きい範囲での最適化(サクッと結果が出せるか)で勝負するんだよ。

あと追加。
https://developer.mozilla.org/en-US/docs/Web/Events/scroll
scroll の e に delta がない。
だから糞遅い scrollTop の問い合わせがいちいち必要になる。
.NETだと e.delta でどっち向きにどれだけスクロールしたかが取れる。
同様のことはmousemoveにも言えるのだけど、
あっちは clientX とかがあるから、DOMクエリしなくても追跡できる。
scrollはDOMクエリを強要されるのが辛い。
サンプルも window.scrollYを取っているけど、アレは実は結構重い。
そしてそれがサンプルにあるように、大抵の場合はスクロール位置の確認が必要になる。

192 :デフォルトの名無しさん:2016/05/17(火) 23:42:45.65 ID:3NFQlF5/.net
Math.floorを使ってもdoubleで扱える範囲でないと仕方ないのは変わりない。
入力が適切に処理できる範囲に収まっているか確認し、大きすぎます等の案内を出す必要がある

193 :デフォルトの名無しさん:2016/05/18(水) 00:08:03.84 ID:jjsucSg3.net
>>185
あと、ついでならMDNもお願いしていい?

1. https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Date
内のメソッド parse について、
× > JavaScript で日付を表す文字列を解釈して、地方時で 1970 年 1 月 1 日 00:00:00 から経過したミリ秒を表す数値を返します。
○ UTCで

194 :デフォルトの名無しさん:2016/05/18(水) 00:09:05.81 ID:jjsucSg3.net
>>185
2. https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/RegExp/test
test がさも search や exec の代りの高速メソッドとして使えるように書いてある。
これは半分事実なのだが、実際はtestはexecを1回やるだけなので、RegExpをバッファするとバグる。
具体的には以下。2回の同じ入力の呼び出しに対し、出力が異なる。
(testinputはそのページの使用例の出力先をconsole.logに書き換えただけの物)

function testinput(re, str) {
var midstring;

if ( re.test(str) ) {
midstring = " contains ";
} else {
midstring = " does not contain ";
}

console.log(str + midstring + re.source);
}

var rexp = /a/g;
var str = 'abc';
testinput(rexp,str); // abc contains a

testinput(rexp,str); // abc does not contain a

これは完全に落とし穴掘っているだけで、MDNだけ読んでいても気づかない。
だから「testは実際はexecを1回起動するだけです。詳細はexecを確認してください。」みたいな誘導が必要。
testに渡す正規表現に g つけんな!ってのはあるけど、
管理上、同じ正規表現を使いまわししたいときがあって、(その正規表現はプログラム内で1箇所にしたい)
そのときに g が付いているやつがあってバグった。
だから、「gつけないでください」という誘導でも実質的にはいいのだけど、多分MDNの雰囲気とは合わない。

195 :デフォルトの名無しさん:2016/05/18(水) 00:33:18.17 ID:OcMV4DaZ.net
>>192
そりゃそうだが、随分面倒な処理を要求するんだな
Number 型全体が IEEE 754 の制約を受けるわけだが、制約外の数値を正しく検出するようにしろという事か
対処療法的には入力文字列を正しくパースして数値比較する
根本的には ECMAScript のビルトインオブジェクト全体を書き換える必要があるわけだが、そこまでやる必要あるのかね

196 :デフォルトの名無しさん:2016/05/18(水) 01:11:57.83 ID:r9bj4L60.net
>>195
君の言う問題点とやらを解消するためにはそこまでやる必要があるというお話さ
そしてそんなに難しく考えなくともdoubleとして受け取るのならNumber.MAX_SAFE_INTEGERを超えてないかどうかチェックすればいいだけ

197 :デフォルトの名無しさん:2016/05/18(水) 22:06:18.60 ID:Y5c0aQW+.net
>>196
なるほど、理解した

198 :デフォルトの名無しさん:2016/05/18(水) 22:43:30.32 ID:Y5c0aQW+.net
修正版

do {
 var n = Math.floor(prompt(Number.MAX_SAFE_INTEGER + '以下の自然数を入力してください'));

 if (!n) {
  alert('数値となる自然数を入力してください');
 } else if (n < 0) {
  alert('負の数は指定できません');
 } else if (n > Number.MAX_SAFE_INTEGER) {
  alert(Number.MAX_SAFE_INTEGER + '以上の数は指定できません');
 }
} while (!n || n < 0 || n > Number.MAX_SAFE_INTEGER);

199 :デフォルトの名無しさん:2016/05/18(水) 22:49:59.30 ID:JiGf9hjC.net
誰が完璧な自然数受け付けのロジックを長々と書けといった……
そこまでするなら多長倍数ライブラリ使ったら?

200 :デフォルトの名無しさん:2016/05/18(水) 23:38:34.48 ID:Y5c0aQW+.net
>>199
初めは while 条件だけで終わらせる予定だったが、
>>192が「大きすぎます等の案内を出す必要がある」と指摘したからエラーメッセージを追加したが、MAX_SAFE_INTEGER だけエラーメッセージを追加するのはおかしいので他のメッセージも追加したら結果的にこうなっただけ
この程度のコードでライブラリを使う必要は感じないが、最近のコーダーはライブラリ使用の見極めが速いんだな

201 :デフォルトの名無しさん:2016/05/19(木) 03:19:33.36 ID:tfaQOE9Q.net
ってか、キャストしてる時点で型がどうのではなく、型変換してるからな。
普通に、/^[1-9][0-9]*$/するのがいいんじゃねーの?入力は文字列なんだから。
どう考えても、Math.floorに文字列を渡す理由にならん。先頭か末尾に空白あるときはどうなるんだっけ?とか悩むじゃん。
integer.Parse通さないと数字にならないどころか、例外すら発生するのがまともな型のある言語。

202 :デフォルトの名無しさん:2016/05/19(木) 04:45:29.52 ID:3i7lekC+.net
>>201
JavaScriptは型違いをTypeErrorとせず、暗黙の型変換をする言語なんだから型変換で正しいんだよ

203 :デフォルトの名無しさん:2016/05/19(木) 05:59:57.75 ID:tfaQOE9Q.net
>>202
知ってるよ…だから、型のアノテーションがどうだとか、型を定義すべきだって話が眉唾と言うか、良い所全部殺すなって思うんよね。

204 :デフォルトの名無しさん:2016/05/19(木) 07:31:01.14 ID:l0qmM6vP.net
>>203
> 型のアノテーションがどうだとか、型を定義すべきだって話が眉唾と言うか、良い所全部殺すなって思うんよね。
文脈を読めてないんじゃない?
型付き言語にこだわっていた人と>>198は別人

205 :デフォルトの名無しさん:2016/05/19(木) 08:30:40.64 ID:F9dbx1t6.net
JavaScriptは型付き言語でないわけで、そこに型付きな考え方を付加させても、各々のポリシーでいかようにでもスタイルが変化するって事をわかってない感じ
また、型付き言語であっても変数に代入されるまでは型が確定されないわけで経過処理で型変換を挟んではいけないわけではない

206 :デフォルトの名無しさん:2016/05/19(木) 13:24:53.83 ID:qyR8CUMd.net
入力は限られてるし、取り扱いを間違っても原則ブラウザがクラッシュしたりすることはない。
それどころか不意に関数エラーが出ても、こういったイベントドリブンな場合は、何も問題なく復帰できることも多い。
最悪詰まっても、文章は読める。そこが所謂低レベル言語との違い。

207 :デフォルトの名無しさん:2016/05/19(木) 13:36:54.99 ID:Gndv5tvj.net
LLマンセー

208 :デフォルトの名無しさん:2016/05/19(木) 14:55:40.45 ID:XceO64sZ.net
何も自慢できない男の人って可哀想(;;)

209 :デフォルトの名無しさん:2016/06/09(木) 09:39:33.79 ID:FTTkP1ld.net
arrow function の引数の丸括弧を省略する記法嫌いな人って多くないのかな

const fn = arg => { console.log(arg); };

const fn = (arg)=>{ console.log(arg); };

210 :デフォルトの名無しさん:2016/06/09(木) 13:20:53.39 ID:bsniAtVU.net
時と場合によるだろう。
この場合は、あった方が良い

211 :デフォルトの名無しさん:2016/06/09(木) 13:43:16.42 ID:QTm6YzLa.net
>>209
省略記法全般が嫌い
{} の省略の方が嫌だな

しかし、このアンケートに意味があるとは思えんのだけど、ただ雑談したかっただけ
多いか少ないかなんてどうでもいいと思うが

212 :デフォルトの名無しさん:2016/06/09(木) 13:43:46.11 ID:QTm6YzLa.net
ただ雑談したかっただけ?

213 :デフォルトの名無しさん:2016/06/09(木) 14:51:10.11 ID:eWu1TzV4.net
>>209
省略できるものは原則省略したほうがいい。セミコロンも含む。
短く書けるとき、あえてそうしないというのは、
何らかの特別な意味を表す必要がなければしない方がいい。

214 :デフォルトの名無しさん:2016/06/09(木) 16:09:58.83 ID:bsniAtVU.net
>>213

そういうのは、ミニファイツールでOKでしょう。
コーディング中は、原則省略すべきじゃない。
GitHubで公開するソースも省略するべきじゃない。
可読性を下げてはいけない。

省略した方が読み易いとか云う奴は、独りよがりの変態なだけ

215 :デフォルトの名無しさん:2016/06/09(木) 20:35:01.66 ID:ziShIi0x.net
>>213
釣りはウザイから止めろ。
ガチで勘違いしているのなら google のコーディングルール読め。駄目な例まで挙げてある。
http://cou929.nu/data/google_javascript_style_guide/

>>209
一般にどうなのかは分からんな。
しかし所詮は慣れだろうし、世間がそう書くなら慣れるしかないのでは。
なおそのケースなら俺は function と書くが。
sortの引数のような最初から function であることが確定している部分はいいけど、
それ以外の所(何が書かれるか分からないところ)には function と書いた方が見やすいと思うから。

216 :デフォルトの名無しさん:2016/06/11(土) 16:34:28.13 ID:tWgkOxEq.net
>>214
いいや、無駄なものが付いてるほうが可読性が落ちる。
特にGitHubではセミコロン省略が推奨されてるでしょ。
https://github.com/feross/standard/blob/master/RULES.md#semicolons
それなのに付けろというのはそれこそ独りよがりだよ。
でも君が独りよがりだから悪いとは言わないよ。
JSは独りよがりで自由であるべきだからね。

217 :デフォルトの名無しさん:2016/06/11(土) 16:40:46.73 ID:tWgkOxEq.net
>>215
釣りではない。
GitHubやnpmなど、セミコロンフリーのスタイルは確立されている。
自分も様々なスタイルを試した結果、今はこれに賛同しているだけ。
ただし、この2つは同じく原則省略でも細部の取り回しが異なる上、自分もそれらとは微妙に異なる。
ルールセットの他の部分は当然違う。結構細かくいろんなスタイルが存在する。
そのどれもが考えられてるのだから悪いとかフザケてるとか思うようなことでないと思う。
それなのに人の信念というか、正義を釣り呼ばわりするのはかなり独りよがりだと思う。
でも落ち込まないで、そんな君も好きだよ。

218 :デフォルトの名無しさん:2016/06/11(土) 17:39:28.29 ID:ZhHlBSFM.net
>>217
キモいわ。

個人が作った勝手ルールだろ。それに従いたければ勝手にしろよ。
googleの方は「こういう問題があるから、こういうルールにしました」という、極めて実用的なものだ。
俺がgoogle側のルールを妥当とするのはこの点からだ。
コーディングルールは、見やすさではなく、バグを含まないためにある。
セミコロン程度の見やすさなんて、所詮慣れでしかない。
付いている方が無駄バグが発生しにくいのなら、当然それがルールで、見にくいのなら慣れろ、という立場だ。

お前はこのスレに来るべきではない。テンプレ読めよ。
お前は3,000行のコード、書けないだろ。

219 :デフォルトの名無しさん:2016/06/11(土) 19:12:42.34 ID:ZhHlBSFM.net
>>217
つうかおめー、マジで頭おかしいぞ。
有名どころは全部「セミコロン付けろ」だぞ。
個人レベルでの勝手ルール持ち出すとか、キチガイだと分からないか?
それともGitHubを勘違いしているか?あれは誰でもアカウントを作れる。もちろん君でも。

> JavaScriptのスタイルガイドまとめ(おすすめ4選)
> google
> jQuery JavaScript Style Guide
> Airbnb JavaScript Style Guide
> > https://github.com/airbnb/javascript (star 36,207、対して feross は 5,886)
> Node
> http://qiita.com/takeharu/items/dee0972e5f39bfd4d7c8

220 :デフォルトの名無しさん:2016/06/11(土) 19:13:01.99 ID:ZhHlBSFM.net
> npm
> https://www.npmjs.com/package/standard
npmだけは確かに「省けるセミコロンは省け」と言っている。
ざっくり見た感じは、「JavaScriptについてよく知れば、それが出来る」ということらしい。
つまり、どういうケースでAutomaticSemicolonInsertionが動くか理解して、
常にそれを考えながらコーディングしろ、ということなのだが、
そんなことやってるからJavaScriptの連中は上達してないんだと思うけどね。

本来のプログラミングの「技能」は、言語をまたいで汎用的なものだ。
その言語でしか使えない知識は、「文法」でしかない。
俺たちはJavaScriptのおかしな文法を極めたいわけでもない。JavaScriptを使いたいだけだ。
君の論理なら、使いたいだけのために勉強を強いるのもまた「独りよがり」でしかないだろ。

不思議なのは、JavaScriptの連中にはこの主張をする輩が多い事だ。
npmが震源だったということなのか?
C++で「テンプレートを極めてから来い」
C#やJavaで「クラスライブラリを極めてから来い」
なんていう奴はいない。それはどだい無理だからだ。
だから知っている範囲でコーディングを開始していく。そして「そんな機能あったのか!」ってのも割とよくある。
JavaScriptはギリギリ極められるくらいの軽量言語ではある。
しかしだからといって、それを極めたところで益はない。せいぜいセミコロンが省けるだけだ。
そんなことに時間をかける価値なんてないだろ?
全部セミコロン付けてリントで落とし、さっさと本題に行こうというのが普通だ。

221 :デフォルトの名無しさん:2016/06/12(日) 00:32:26.03 ID:npk74fIw.net
詳細確認したが、
> セミコロンフリー (>>217)
ではないぞ。

> // ok
> ;(function () {
> window.alert('ok')
> }())
>
> // avoid
> (function () {
> window.alert('ok')
> }())
> https://github.com/feross/standard/blob/master/RULES.md#semicolons

必要な時には行頭に付けろという、一周回った発想だ。

222 :デフォルトの名無しさん:2016/06/12(日) 00:33:54.14 ID:npk74fIw.net
npmの所にある3者のうち、(全部読んではないが、videoは全部見た)
1つ目は教条的な理由、
> “They’re required because ASI is unreliable.” Seriously!?
> These rules date back to the early days of JavaScript, in the late 90s.
> They’re not new, and in my opinion there is no excuse for someone calling themselves a professional JavaScripter and not understanding statement termination.
> It is blatantly irresponsible of the thought leaders in the JavaScript community to continue to spread uncertainty rather than understanding.
> http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
2つ目はどのみち必要だという理由、
> Even if you use semicolons at the end of every statement, some constructs parse in non-obvious ways. Regardless of your preferences in semicolon usage, you must know the rules to write JavaScript professionally.
> http://inimino.org/~inimino/blog/javascript_semicolons
3つ目は「関数には要らなくて関数式には付けろとか『初心者には』分かりにくい」ということだった。
> https://www.youtube.com/watch?v=gsfbh17Ax9I

よく見るとなるほどこのnpmのコーディングルールの作者がferossか。
ならばそれは「GitHubで確立されている」とは言わない。それは君がGitHubを勘違いしているだけだ。
GitHubはただの置き場であって、誰でも何でも置けるんだよ。プログラムである必要すらない。
とはいえnpmではある程度の評価を得ていることは事実だな。ただ明らかに主流ではないが。

セミコロン無しの有名言語はRubyとPythonだと思うが、そっち出身でなければ大人しく付けておいて、それに慣れた方がいい。
Ruby/Pythonとの相互運用なら可能性はありだが、
俺はRubyもPythonも知らないのでどちらがマシかの判断は付かない。

223 :デフォルトの名無しさん:2016/06/12(日) 05:22:59.97 ID:Q2nOr0zy.net
>>222
大人しく付けておいて慣れたほうがいい。ね。
興味深い考え方だね。
でも自分はどんな作業にしろ常に思考し改善しようと努力する質だから。
大人しく常識に沿って手を動かすだけというのは好きじゃない。
少しでもそういう意識があればむしろ書かれているように、
Note: If you're often writing code like this, you may be trying to be too clever.
Clever short-hands are discouraged, in favor of clear and readable expressions, whenever possible.
というのに「気づく」と思う。
キモい?当たり前。
俺も散々吐き気をこらえていろいろなスタイルや概念を試してきた。
何度も行ったり来たりした。
キモいのは上等!その先に必ず改善があるのだから。
そして多くを見れば本当に「キモい」ものが何かがわかってくる。
class構文やプロトタイプ的継承術に慣れた後では
JSのデフォの継承システムが一番「存在的にキモい」ことに気づくのと同じ。
でも分かった。そういうのを他人に求めるのはエゴなんだと。
すまなかった。。。。。。。

224 :デフォルトの名無しさん:2016/06/12(日) 05:36:18.79 ID:Q2nOr0zy.net
>>220
極める必要なんてない。
例えば暗黙の型変換周りと比べると非常に明快。
ただ、「括弧で始まる前に付ける」。
これさえ守ればいい。
細かいこと言えば『接続させたくない』接続可能な他の演算子の前にも付ける必要などあるが、
まずそうであることはありえない。

そして「括弧で始まる」ようなものを書くようになるのは入門終了後だから、
その程度の「決め事」と一緒にそれらの書き方を学ぶのが特に負荷になるとは思わない。

225 :デフォルトの名無しさん:2016/06/12(日) 05:49:08.10 ID:GMtpRE4O.net
>他人に求めるのはエゴ
はいこれで決着ね

226 :デフォルトの名無しさん:2016/06/12(日) 11:40:13.85 ID:npk74fIw.net
>>223
いや悪いが「キモイ」ってのは君の投稿内容のことであって、JavaScriptの記法の事ではなかった。
ここは馴れ合う場所ではない。

ただやはりそれは努力の方向を間違っていると思うよ。
先に書いたように、「文法」を覚える努力をいくらやったところでプログラミングの「技能」は上達しない。
勉強する前に鉛筆の削り方に異常にこだわるようなものだ。さっさと勉強を始めた方がいい。

> class構文やプロトタイプ的継承術に慣れた後では
> JSのデフォの継承システムが一番「存在的にキモい」ことに気づくのと同じ。
釣りか?JSのデフォの継承システム=プロトタイプ的継承だが。

> その程度の「決め事」と一緒にそれらの書き方を学ぶのが特に負荷になるとは思わない。
「とりあえず全部セミコロンつけとけ」の方が楽だ。何も学ぶ必要はない。(JSなら余分も問題にならない)
なお、JSの場合はセミコロンは「必要な場所に無ければ挿入される」であって、「不必要」ではない。
そして return の場合は改行でいきなり終端されるとか、動作に一貫性がない点もある。
たぶんRubyやPythonは最初から「不必要」で設計されている。この点が違う。

227 :デフォルトの名無しさん:2016/06/12(日) 11:40:36.40 ID:npk74fIw.net
インターネット上で自分と同じ意見を探すのは、使い方を間違っている。
最近「ブサヨ」「パヨク」とか言われているだろ。あそこまで見事に「裸の王様」になるのかとも呆れるが、
君は彼等と同じインターネットの使い方をしている。
どんなマイナーな意見でも、世界中を探せば同意見の奴は大概見つかる。自分が世界一マイナーな確率なんてほぼゼロだから。
だから、検索でヒットしても安心したら駄目だ。それはどれくらい支持された意見なのか確認する必要がある。
大勢が採用した物には、それなりの理由がある。マイナーならばそれにも理由がある。

君にはJavaScriptの技術力もないし、
マイナーな意見をGitHubの大勢だと勘違いしてしまう程、インターネットのリテラシーもない。
もちろん何故大勢が「セミコロン付けろ」なのかも分からないだろ。
余分な苦労をせずに上達したいのなら、「普通に」色々やった方がいい。もちろんそれも含めて君の自由だが。

そしてやはり君はここに来るべきではない。邪魔でしかない。
この手の「議論以前の常識」についてグダグダ言いたくないから別スレを作ったんだ。
君は「質問スレ」でいいはずだ。彼等はこの題目なら嬉々としてレスしてくるだろうし。

228 :デフォルトの名無しさん:2016/06/12(日) 11:50:23.91 ID:k/2WgB7H.net
ここまで静観して見てたけどその例えはどうなのよ
Web板での政治社会的なレッテル貼りや質問スレの〜行以下のコード云々の煽りはともかく
このスレでだけはまともに議論や情報交換をするものだと思っていたのに心底残念だよ

229 :デフォルトの名無しさん:2016/06/12(日) 12:18:41.79 ID:bynAnAmH.net
セミコロンは付けるか付けないかではない。付けさせるか付けさせないかだ。
そう考えれば付けさせるしかないだろ。

230 :デフォルトの名無しさん:2016/06/12(日) 12:24:25.95 ID:npk74fIw.net
>>228
では出ていくなり、他スレを立てるなり、好きにすればいい。それも自由だ。
ここは言いたいことを言い合う場所であって、言って欲しいことを言ってもらえる場所ではない。

どこについて怒っているのか若干謎だが、
「ブサヨ」「パヨク」については適切な例えだと思うぞ。実際そうだし。
ただ彼等について嘲笑するだけなのは、それもまた駄目なんだよ。
自分もそこに陥ってしまう危険性に気づき、他山の石としなければならない。
実際、彼もその罠に嵌っているわけだし。

マイナーな状態で旗印があれば信者はそこに飛びつく。
そして周りが自分と同じ意見であることに安心してしまうのだが、それでは駄目なんだ。
セミコロン無し派がnpmに集結しているのは正直驚きだった。だから詳細を確認した。
結果、「宗教」だった。対してgoogle/jQuery/Node/Airbnbは「実利」だ。俺はノータイムで「実利」を取る。
とはいえ、いずれにしても「宗教」の時点で議論する意味はない。
どうあがいても平行線だからね。

だから結局好きにするしかないのだが、セミコロン付ける派にも「宗教」の奴はいるはずで、
人口が C/C++/Java >> Ruby/Python な以上、「宗教」としてもひっくり返らない。
だから変にこだわるのではなく、「セミコロンあり」に慣れるしかないだろ、というのが至極妥当な見解だと思うが。

231 :デフォルトの名無しさん:2016/06/12(日) 12:26:16.47 ID:3NjnbAB7.net
>>228
ここで議論したことあるけど、高確率で煽る方向に絡まれるから有意義な議論は期待できないと思うよ
議論中に軌道修正しようとしたけど、ほとんどが無駄だった

232 :デフォルトの名無しさん:2016/06/12(日) 12:33:31.15 ID:npk74fIw.net
>>229
そうなんだけど、セミコロン無し派も結構ガチなんだよ。
リンターも整形ツールも既に提供している。
あのferossって奴もGitHubの垢見る限りそこそこ大物だ。

ただ正直、そこまでこだわる理由もよくわからんのだが、、、

233 :224:2016/06/12(日) 16:06:44.39 ID:gONGsgja.net
>>227
俺はここはJSを愛する者達のスレ、と認識していた。
今は亡きECMAスレの面影を重ねているのかもしれない。
要するに、より良いJSを目指す者質の意見だ。
ただの常識とやらにそった意見の飛ばし合いならばそれこそそこらの質問スレですればいい。
こういう議論をするためこそにこのスレが有るのだし、
現にこういう議論が出て初めてスレが伸びたんだからそういうことに違いないだろう。
ともかく、こういう議論をすること自体は良い。としてもらいたい。

>>229
彼に少しでも良いJSを目指したいという精神が感じられなければ、またこういうスレでなければ俺も「あえて」付けるなとは言わない。
この場所、このタイミングで質問した彼には真実に繋がるヒントを伝え、そこへ目指して欲しかった。

>>230
>>「慣れるしかない」
どうして?いや、仮に「セミコロンを原則付けること」に慣れる必要があるとしても、
「セミコロンを原則付けないこと」にも慣れてはいけない理由なんてないし、
そっちを普段自分の中でメインで使って良くない理由なんてないよな。

>>232
俺がこだわっているのは、「セミコロンを付けないほうがいい」ということよりもむしろ、
そういうことを教えたり教わったり考えたり、もっと自由な研究をしようよということだな。
た だ し、『プログラマー』『スクリプター』『JSer』になりたいのならね。
そうでないのならどうでもいいが、俺はそうなってほしい、JSを愛して欲しいと考えるからこうした立場をとっている。
JSを教えるとき、JSって、スクリプト言語って、プログラミングって楽しいんだよ、深いんだよ、広いんだよ
ということを感じてほしくはないかい?俺は欲しい。
一緒にJSを味わい尽くし、発展に協力してもらい、共に夢を見る関係になりたい。
そう思うことはそんなに変かな。
このスレでは許されると思ったんだけどね。寂しい。。

234 :224:2016/06/12(日) 19:04:38.68 ID:gONGsgja.net
あー、それとここまでの流れをちゃんと見てみたら混乱を招いてるようなので
一つ断っておきたいんだが、俺はバランスタイプなんだ。
俺が「セミコロンを付けないほうがいい」などと言ってるのは、
あくまで彼に対するレスが偏り過ぎないよう、不足分を埋める立場になっただけで、
その瞬間ではあくまで彼のためだけの、彼の方向に向いたレスでしかない。
他のレスとは補完関係であって、互いに影響を及ぼしたり対立したりするつもりはない。

もし他の人が「セミコロンを付けないほうがいい」といったならば、
俺は逆の立場から言っていた。
あくまで俺の目的は、広く深い心と知見と情熱を持った『JSer』育成にあるからだ。
何か1つのそれっぽい答えを貰うだけで満足してほしくはない。
いろんな案を受け入れ、自ら試行錯誤してより良いJSを追求していって欲しい。

235 :デフォルトの名無しさん:2016/06/12(日) 23:59:15.39 ID:NYt/6ntu.net
自転車置き場の議論てやつだな
あほだな

236 :デフォルトの名無しさん:2016/06/13(月) 00:25:03.07 ID:AxmCg6hy.net
>>235
ほう、名詞があるんだね。
色々考えたんだけど、JavaScriptの連中が上達してない原因は多分そこだと思うんだよ。

C初心者「for文、while文、if文…」
JavaScript初心者「for文、while文、if文…」

C初心者「ポインタ…」
JavaScript初心者「セミコロンはどこに打つべきか議論しよう(キリッ」

C初心者「ポインタ…ポインタ…構造体…」
JavaScript初心者「暗黙変換の活用について(キリッ」

多分、本質的でないところにトラップされてるんだ。
Cはこの点、寄り道無しで初ボスかつラスボスのポインタがいきなり出てきて勇者は死ぬ。
そして何度も復活の呪文を唱えつつ、そこを抜ければいきなり中級者になってる。
JavaScriptの連中は完全にここで空回りしてしまってる。
セミコロンを打つ場所なんてマジでどうでもいいのに、さも重要なことのように言うのは詐欺だよな。

237 :デフォルトの名無しさん:2016/06/13(月) 06:36:45.25 ID:o3uO7eJP.net
>>236
実際には、セミコロンを打つ位置ではなくて、なぜセミコロンが省略でき、その場所では省略してはいけないのかが問題なんだけど、題目的にしか議論してないからな。
ポインタだって、参照と実体とかにフォーカスした方がいいんだろうけど、その辺スルーだし。

238 :デフォルトの名無しさん:2016/06/14(火) 10:56:42.92 ID:ScASA3Ww.net
>>236
一番重要で本質的なことは、
長く複雑なコードをいかにスマートに書けるか、
いかに問題を短く簡潔なコードで早く書けるか、
ってことだと思うよ。
各機能がどうのこうのは、それこそどうでも良いというか、
基礎という意味では重大だけれど、レベルが低いことだと思う。

セミコロンを打つ場所なんてマジでどうでもいいというのは、
それは初心者にとってそれよりも先にやるべきことがあるからその通り。
しかし中級者以降生産性やコードの質を上げていこうと思えば
この手の物事の重要性は増していき、最後には信念やら宗教やらと言われる問題に行き着くと思うよ。

ここは既習者スレなんだから、そういうことこそを話し合うべきだと思うけどな。

そして空回りしているというのは、ある見方ではそうだと思う。
JSは仕様の内も外も具体的な実装について殆ど意識されていないからね。
でもそれは逆に、具体的な実装に囚われず概念を学べると言えると思う。
その概念を習得すれば、例えば他言語に移ったとしても柔軟に対応できる。

他にもJSはマルチパラダイムと強く意識されて作られたわけではないが、その真似事ができる。
むしろJSこそ最も様々なプログラミングにおける本質的な物事を学べる言語だと思う。

239 :デフォルトの名無しさん:2016/06/14(火) 18:26:48.94 ID:TG3hSyiU.net
検索用にセミコロンを 2 個3 個続けるのもありかな

240 :デフォルトの名無しさん:2016/06/15(水) 01:26:31.98 ID:Iz/1ukPU.net
検索用にセミコロンを 2 個3 個続けるのもあり
と君が判断したのなら君の中ではありなんだろう

241 :デフォルトの名無しさん:2016/06/15(水) 20:32:12.77 ID:AdfPujMx.net
マンセーが異様に多いのもJavaScripterのおかしな所だよな

242 :デフォルトの名無しさん:2016/06/16(木) 07:55:44.05 ID:oMjTOMdB.net
そうか?
むしろスクリプト言語の中じゃ代表コミュニティもないし、そういうのは少ないほうだと思うが。

243 :デフォルトの名無しさん:2016/06/16(木) 08:00:04.44 ID:88N1/vwg.net
利用人口ぱねえからな。変なの目にする機会も多かろう。

244 :デフォルトの名無しさん:2016/06/16(木) 15:16:35.80 ID:oMjTOMdB.net
他人を理解できないってのは悲しいね

245 :デフォルトの名無しさん:2016/06/18(土) 01:00:30.57 ID:HfDVf1Az.net
>>243
人数自体はそんなに大したことはない。
おかしな奴の割合が異常に高いんだよ。
Webがホームということもあり、未熟な奴が平気で情報発信()している感もあるが。
http://www.tiobe.com/tiobe_index
http://spectrum.ieee.org/computing/software/the-2015-top-ten-programming-languages
http://pypl.github.io/PYPL.html

246 :デフォルトの名無しさん:2016/06/18(土) 05:23:04.56 ID:bYpIs91z.net
マンセーしたら未熟者扱い?
エキスパートな俺様は苦しんでるのに許せない間違っているってことだろうか
それとも辛い経験豊富で批判的な俺様カッケーって勘違いアピール?
傍から見るとひねくれ者の妬みにしか見えないが……

247 :デフォルトの名無しさん:2016/06/18(土) 14:06:50.57 ID:P96CWXJR.net
観測範囲の問題
JavaScriptに限らず、おかしな人はどこにでもいる
このスレの>>1は相当な変わり者だったようだが

248 :デフォルトの名無しさん:2016/06/19(日) 04:58:43.41 ID:pwKRdbbJ.net
おかしくない人って何よ

249 :デフォルトの名無しさん:2016/06/19(日) 10:12:00.06 ID:0NV3J/pF.net
>>245
Google で検索されたキーワード辺りで指標作った方が良さげな気がする。

250 :デフォルトの名無しさん:2016/06/19(日) 12:28:35.73 ID:XPavHURr.net
ここは>>1を含めて俺様主義の人が常駐してるのでまともな意見交換は出来んよ
始めは冷静でも、少し意見の食い違う人が現れただけでただの「主張の押しつけ合い」に発展する
意見交換するなら「そんな考え方もあるのか」ぐらいに自分の立場を引いて見つめる客観性が必要だが、彼は否定にかかるだけで相手をやりこめないと満足しないからな

251 :デフォルトの名無しさん:2016/06/19(日) 15:16:34.64 ID:pwKRdbbJ.net
俺もお前も仙人や神様じゃなく凡人なのだから、性質に割り振れる度合いは限られてる。
結局思考停止の傲慢くんも、視野無限の優柔不断くんも、同じくらい悪い議論しかできない。
その中間であっても、両者の悪いところを半々持つので、同じくらい悪い議論しかできない。
つまり無理難題夢物語ということ。「こんな議論もあるのか」ぐらい許容的になってもよかでは?

252 :デフォルトの名無しさん:2016/06/19(日) 17:29:39.15 ID:+1vne4gn.net
そうやって他人の人格否定する辺りがまともな議論が成立しない理由なんだよな
http://d.hatena.ne.jp/takerunba/touch/20081028/p1

253 :デフォルトの名無しさん:2016/06/19(日) 19:27:30.52 ID:fmRoj+h3.net
そこで言う「まともな議論」とやらをここでする必要が有るのかい?
仕事でもあるまいし、自己主張のたまり場でもええんやないの?

254 :デフォルトの名無しさん:2016/06/19(日) 19:36:59.62 ID:J/2rkjpj.net
ここは電波を黙らせる方法がないのだから基本は自己主張のたまり場にしかならんよ
その状態で有益な議論に出来るかは当事者次第でしかない

255 :デフォルトの名無しさん:2016/06/19(日) 20:13:29.92 ID:fmRoj+h3.net
まあぶっちゃけ単純に「聞き手」不足なだけなんだけどね

256 :デフォルトの名無しさん:2016/06/19(日) 20:36:57.86 ID:J/2rkjpj.net
そうか?なら語って、どうぞ。
なおセミコロンについて語られても困りますので悪しからず。

257 :デフォルトの名無しさん:2016/06/19(日) 22:34:40.11 ID:YTnkZ+TT.net
自己主張の溜まり場なら「情報交換所」なんてタイトルを付けなければいいのにな
次スレは「JavaScript自己主張の溜まり場」に改名すればいい

258 :デフォルトの名無しさん:2016/06/19(日) 22:50:20.08 ID:J/2rkjpj.net
単発にはキチガイしかいないことの再証明乙

259 :デフォルトの名無しさん:2016/06/19(日) 22:55:12.64 ID:YTnkZ+TT.net
ID:J/2rkjpj
自己主張の溜まり場で有益な議論が出来る訳なかろう
キチガイといっている時点でおまえにはその気が全くないのだろうが

260 :デフォルトの名無しさん:2016/06/19(日) 23:05:07.79 ID:YTnkZ+TT.net
>>251のよつな相手の非を盾に自分の非を正当化する行為も議論には邪魔だな
自己勝手の押しつけが横行するようなら「JavaScript自己主張の溜まり場」がこのスレに相応しい名前だと思うぞ

261 :デフォルトの名無しさん:2016/06/19(日) 23:09:03.89 ID:J/2rkjpj.net
やりたきゃ自分から始めればいいし、それに誰も食いつかなければその程度だったってだけだろ。
誰も池沼を相手にしたくないし、する義務もないんだよ。
何かあるのならさっさと始めろよ。

262 :デフォルトの名無しさん:2016/06/20(月) 12:16:18.08 ID:GHIZIB85.net
スレタイ詐欺だな

263 :デフォルトの名無しさん:2016/06/20(月) 23:23:32.99 ID:ismdVjCJ.net
基本的にこのスレは>>1しかいないからこうなるわな
賛同者がいないことを盾に本題への言及を避けてるだけ

264 :デフォルトの名無しさん:2016/06/20(月) 23:45:23.34 ID:hAl2oYmp.net
「本題」って何?

265 :デフォルトの名無しさん:2016/06/21(火) 11:22:12.62 ID:papOtBqK.net
>>257

266 :デフォルトの名無しさん:2016/06/21(火) 13:37:07.53 ID:NcocGzZA.net
つまりかつてのECMAスレみたいに、いろんな新情報を挙げていけばいいんでしょ?
でもそれから派生した議論は別問題だよ。
匿名掲示板なんだから、自己主張の溜まり場になって当然。
逆にそうでなくすことなんて無理無理。道理に反してる。
俺は質問スレ10くらいの時から100スレ間に渡っていろんな案を出して直そうとしてきたが、
まあ様々なところで一定の収穫はあったが、議論が暴走することだけはどうしようもならなかった。
なら逆に受け取る方が考え方・気持ちを切り替えていくしかないんだよ。

267 :デフォルトの名無しさん:2016/06/21(火) 16:31:29.25 ID:wNHblGP/.net
新情報っていってもねぇw

268 :デフォルトの名無しさん:2016/06/27(月) 00:33:14.94 ID:n3Kagte5.net
TypedArrayとasm.jsの状況について詳しい人居る?

現在アプリにもっさり感がある。それであちこち修正したのだが、
ChromeDevTools/Profiles/CPU PROFILESで(program)が70-90%なのでJS側での速度改善はほぼ頭打ちだ。
そこで無理やり使用メモリを減らして速度向上させようとしている。
なお、評価はchromeで行っている。

JSのArrayは例えば [0,0,0] なら 16(header)+8*4(contents) = 48 Bytes になるようだ。
一つ中身が多いのは多分length分だろう。
元々オブジェクトだった物(26+88=116Byte)を強引にArrayに変えてこれを実現した。(項目も減らした)
ただ実際は struct { Int32, Int32, Int64 } なので本当は 16 + 4+4+8 = 32 になって欲しい。

そこで質問なのだが、
・asm.js 的記述(代入時に全部 |0 )したらメモリ確保も32bitになるかどうか
・TypedArrayの状況
を知りたい。

通常asm.jsは速度面ばかり話に出ていて、メモリ面の話が無い。
とはいえJITだと普通は無理だと思ので、
他の含めて何らかの方法でメモリ確保量を減らす方法を知っていればよろしく。
以下を見る限り、そういう用途向けではなさそうだが。
http://www.h2.dion.ne.jp/~defghi/asmjs/asmjs.htm

TypedArrayは使用メモリ自体は確実に減らせるはずだが、速度が異常に遅いのが気になっている。
以下で俺の環境だとざっくり7/7/100+/300+(以降全部)とかだ。
http://jsdo.it/sapphire_al2o3/sPa5
余計もっさりするようでは意味無い。試したことがある人は居るかい?
ググッたが、TypedArrayについては軒並み記事が古く、しかもやはり「遅い」という物が多い。

269 :デフォルトの名無しさん:2016/06/27(月) 00:37:31.51 ID:rG4NGWrk.net
生成が重いだけだろ
使い方を間違えてる

270 :デフォルトの名無しさん:2016/06/27(月) 01:40:09.28 ID:n3Kagte5.net
一応全体的に遅いということなのでそうだと勝手に思っていた。古いが以下。
http://blog.livedoor.jp/abars/archives/52103965.html

とりあえず確かめてみた結果、読み書きは1.5倍程度遅い。
許容範囲かといわれれば微妙だな、、、、
なおデータがなかなか安定しなかったので、若干怪しい。
サイズは俺が使う予定の1000にした。
このサイズなら確保との差が見えないが、オリジナルのサイズ(1.6M)だと見えていた。

function testArray(data, n, iter, start) {
var time_enter = Date.now();
for(var j=0;j<iter;j++)
for(var i = 0; i < n; i++) data[i] = i & 0xFFFFFFFF;
var now = Date.now();
return [now-time_enter, now-start];
}

function check(iter){
var start = Date.now()
console.log('array: '+testArray(new Array(count), count, iter, start));
start = Date.now();
console.log('Int32Array: '+testArray(new Int32Array(count), count, iter, start));
}

var count = 1000;
for (var i=100;i<100000000;i*=10) check(i);

271 :デフォルトの名無しさん:2016/06/27(月) 01:40:47.25 ID:n3Kagte5.net
array: 1,2
Int32Array: 2,2
array: 2,2
Int32Array: 4,4
array: 22,22
Int32Array: 35,35
array: 235,235
Int32Array: 369,369
array: 2544,2544
Int32Array: 3665,3665
array: 24831,24831
Int32Array: 36757,36757

272 :デフォルトの名無しさん:2016/06/27(月) 02:01:59.30 ID:n3Kagte5.net
しかしどうやっても Int64 を生成できないのが問題だ。
実装としてはInt64を使わずにdouble64なのかな?
だったら変換が毎回発生せずに済むからいいけど。

273 :デフォルトの名無しさん:2016/06/27(月) 02:43:48.33 ID:Krh8v6Tl.net
> しかしどうやっても Int64 を生成できないのが問題だ。

はぁ?

274 :デフォルトの名無しさん:2016/06/27(月) 02:59:51.93 ID:rG4NGWrk.net
Chromeで試したけどInt32Arrayが全て上回った

275 :デフォルトの名無しさん:2016/06/27(月) 03:37:44.60 ID:1KZKLXAx.net
>>268
> 他の含めて何らかの方法でメモリ確保量を減らす方法を知っていればよろしく。
オブジェクトプール使え

276 :デフォルトの名無しさん:2016/06/27(月) 04:57:14.28 ID:Hl6kI6LE.net
>>270
古いが、じゃない。あまりにもあまりにも古すぎる。
例えばV8は1年前はasm.js用の特別な最適化はしないと言っていたのが、
今では実装がほぼ完了している。
時代の流れというのはとてつもなく早いのだよ。
半年以内の記事でないと評価に値しない。

>>268
通常配列の最適化はエンジンによりまちまちだが、共通して言える分としては
全要素がSMI(≒Int32)かDouble時の最適化のみ。
SMIの要素にDoubleが交じるとそれはDouble配列として最適化される。

そして確かにasm.jsベースで書けば理論的には最大パフォーマンスに近いものが作れるだろう。
でもそれは例えば変数は同時にレジストリに乗る程度の数個に厳選して、
他は全て型付配列のアクセスに置き換えるテクから始まり、
メモリ上のデータの配置にまで気を使って初めて実現できること。

勿論大本のアルゴリズムは言うまでもなく最適でないといけない。
それが昨日今日asm.js始めたばかりの人間にできるかといえば否。
昔アセンブリで最適化してた経験でもないと人力では限界がある。

>>272
もし本当にInt64を効率よく扱いたいのなら時代が追いついていない。
丁度今議論中。3年後にどうぞ。

277 :デフォルトの名無しさん:2016/06/27(月) 17:22:50.14 ID:PSQIpa+S.net
Int64はなんでないのかねえ

278 :デフォルトの名無しさん:2016/06/27(月) 18:12:51.74 ID:8aVYS4Ar.net
逆に考えればすぐ答えは出るよ
何故Float64Arrayはあるんだろうと

279 :デフォルトの名無しさん:2016/06/27(月) 23:12:26.18 ID:n3Kagte5.net
>>275
今回は保存用(内部保持データ)なのでそれは使えない。

>>276
> 半年以内の記事でないと評価に値しない。
それはそうだが実際に遅い。
FF(47.0)でも試したが、上記ほどの差はなく、ほぼ1倍だった。
絶対値としては両方ともchrome(50.0.2630.1 canary SyzyASan)のInt32Arrayとほぼ同じで、
chromeのarrayが速いだけのようだ。
なお古いchrome(49.0.2623.112 beta-m)でも試したが傾向は同じ。(ただし全体的になぜか5倍ほど遅い)

とりあえず環境によるのかもしれないので、>>270の結果(>>271)を環境とともに貼ってくれれば助かる。
コピペすればそのまま実行できる。当たり前だが数字が大きい方が遅い。
なお>>271はchrome(50.0.2630.1 canary SyzyASan) + Vista だ。

> そして確かにasm.jsベースで書けば理論的には最大パフォーマンスに近いものが作れるだろう
いや、だからそれは「局所的」速度の話だろ。
俺は「全体的」速度を上げようとしている。
不要なオブジェクト生成はしていないので、メモリ攪拌はない。
ただし、どうしてもキャッシュミスは多いはずなので、これを改善しようとしている。
アクセスは150個単位で行われるため、TypedArrayにまとめてしまえばキャッシュヒットするようになる。(はず)
https://sites.google.com/site/shunichisnote/translations/data-oriented-design
ただ、今はそれ以前の段階で、全体的なメモリ使用量を削減しようとしている。

280 :デフォルトの名無しさん:2016/06/28(火) 15:51:09.22 ID:+n63MTqJ.net
あのねぇ、銀の弾なんてないのよ。
JIT用最適化ってのはね、理論が正しくても1つ書き間違えただけで台無しになったりするし、
小さなベンチの結果では大きなコードの結果が予測できないこともある。
それこそ最も確実なのはAOTで予測しやすいasm.jsに出来るだけ落としこむことなのよ。
JITの範囲で君の書いたどんな代物か分からないコードが、
どうすれば良くなるかなんて最早一般的な話ではできないのよ。

もうどんな見るに耐えなくなっても良いのでとにかく速さだけを追求したいということなら、
それはもう人が書くようなJSでなくなることは確か。
そこまで行かずとも、今よりいくらか無難に改善したいということなら、
それこそそのコードに依存するとても細かな話で難しい。

というか君もそういう密接な協力をして欲しそうな態度を取ってないし、
結局はただ自分がやってることの進歩を見て欲しいとか、
寂しくないよう日記のつもりでここに書きたいだけでしょ?
そういうのが悪いとは思わないけど、ただ返信してくれた相手を否定する病を発症しちゃあオシマイよ。
そこは君の弱さだよ。

281 :デフォルトの名無しさん:2016/06/28(火) 20:52:20.95 ID:A7Bg25Ta.net
そう思いたければそれでいい。
ただ、その姿勢がお前らが全く上達してない原因だと思う。
俺は間違った指摘に対して間違っていると言っただけだ。

Cの奴らがあくまで「技術的」なのとは対照的に、お前らは「精神的」な物言いばかりだ。
ある意味、やっていることが「Web的」だ。言ったもの勝ちみたいな馬鹿が多い。
とはいえ、間違っていることをいくら主張しても正しくはならない。

そもそもオブジェクトプールはインミュータブルの世界ではほぼ意味がない。
http://www.html5rocks.com/ja/tutorials/speed/static-mem-pools/

そして俺はJIT向けの最適化をしようとはしていない。
事実、メモリをケチるとか、一度にアクセスするデータを纏めるとか、どの言語でも高速化する。
実際、>>279内URLも言語には言及されてない。

もちろんそれ以前に他の改修点も多い。今はそこを整理中だ。
とはいえ、その先の「将来的改修方法」まで見据える必要があるので確認中ということになる。

>>280
ところで、何でお前はそんなに認めて君なんだ?
俺の質問は「asm.jsでフットプリント削減/メモリ配置決めうちは出来るか」であって、
「asm.jsで局所的高速化が出来るか」ではない。
つまり、脱線しているだけだから素っ気ない回答になっているだけだ。
俺がやろうとしているのは、君が思っているasm.jsの使い方ではない。

282 :デフォルトの名無しさん:2016/06/29(水) 20:10:31.16 ID:oxwc/50g.net
自分の話なのに他人を非難し始めた!?
こりゃ重病や〜

283 :デフォルトの名無しさん:2016/06/29(水) 20:14:07.66 ID:oxwc/50g.net
こいつの親はなんで
「相手がどう思うかが大事」
「自分が伝えたつもりでも相手に伝わってなかったら意味が無い」
って教えてやらなかったのかな……
むごいね。

284 :デフォルトの名無しさん:2016/06/30(木) 01:34:38.72 ID:YtNZP2Mq.net
ちなみに、当面の問題は解決した。
実はもっさりというよりはカクカクに近かったのだが、原因はキャッシュによるHDDアクセスの過剰だった。
ヘッダに cache-control: no-store を追加したところ、完全に治った。
ただそれでも(program)が70-90%であることには変わりないのだが、
スクレイピング中でも(idle)は80%以上なので、キビキビ感はある。

前にも書いたが、(>>109)
CPUだけで動く部分は実は相当速くて、UIが主なJavaScriptではCPUを使い切ることはないのかもしれない。
俺の場合はスクレイピングが律速過程なので、サーバの速度が上がらない限りここで頭打ちだ。
数値計算のように完全にCPUだけで回るのなら限界が見えるが、そういう用途はないし。
遅延描画は制御がやや面倒だが、実現してしまえばDOMは1画面分しか扱う必要がなく、一瞬で処理される。

俺のアプリに関して言えば、階層スクレイピングを行っているので、
下位階層を参照する時は更新されていることが確定している。
だから no-store で全く問題ないし、あと5倍の余裕があるので、残るは美学的問題だけになった。
ここを修正するかはしばらく様子見になる。
情報をくれた人はありがとう。

285 :デフォルトの名無しさん:2016/06/30(木) 06:40:45.54 ID:K37QNM6P.net
こういう自分用語多用・技術文書風自分語り・後出し情報でドヤ顔・他言語へのコンプレックスを持つ>>284
スルーできないことこそ、お前らwが上達できない理由wだと思うよ

286 :デフォルトの名無しさん:2016/06/30(木) 14:59:19.41 ID:YdAxXmxA.net
普段スルーするようなキチガイでも無人島じゃコミュニケーション取るしかないのと同じ。

287 :デフォルトの名無しさん:2016/07/17(日) 18:00:55.04 ID:UzC9Qtsn.net
http://echo.2ch.net/test/read.cgi/tech/1468158373/213
質問スレ>>213
自己紹介乙。
てかお前はどうしてそこにこだわるのか全く謎なのだが。

普通に考えれば、引き算が出来るのならMDNで、
> var elapsed = end.getTime() - start.getTime(); // 時間をミリ秒で表す
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Date
これは明らかにおかしくて、
var elapsed = end - start; // 時間をミリ秒で表す
となるべきだろ。お前が言う「経験のある」奴ならここに地雷臭をかぎ取るわけ。
何らかの理由で getTime() しないといけないんだよ。
とはいえ、今1stEdition(1997)見ても abstruct operator という単語自体は使ってないが、
他は同じなので、最初から出来たのではないかとも思うのだが、、、まあよく分からん。
http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf

実際、彼がググって来た例でも直接引き算してないだろ。
俺が(当時)ググッた限りでも出てこなかったから、何かしら理由があるのだと思う。
というわけで俺は「使えない」判定を下していた。

で、これは多分「既に他言語を知っている奴」の普通のやり方なんだよ。
俺がお前に「経験がない」と断定しているのはこういうのが全く通じてないから。

何度も言っているが、お前はもっと書いた方がいい。
ここに質問に来る奴の大半は、「MDNを読め」で済む。
ただお前はもう教科書的な知識は十分にあるんだよ。
だから仕様書をいくら読んでもそれ以上にはならない。
お前が上達するには、書くしかないんだよ。

288 :デフォルトの名無しさん:2016/07/17(日) 18:23:29.08 ID:UzC9Qtsn.net
一応俺の疑問としては、
ToPrimitive(Number) は 無変換で Number そのものを返す。(9.1)
ToNumber(Number) は 無変換で Number そのものを返す。(9.3)
GetValue(V)はVが参照でなければ V そのものを返す。(8.7.1)
+ は ToPrimitive(GetValue(target))の型がStringならString連結、
そうでないなら ToNumber(ToPrimitive(GetValue(target))) で数値の和を返す。(11.6.1)
Date型は内部に time values を持ち、abstruct operationはこれを対象とする。(15.9.1)

だったら足し算も出来ないと駄目じゃね?ってことね。
厳密に言えばGetValueはabstruct operation ではないので、
仕様と実装に矛盾が無い為には、 GetValue(time values) がStringを返す必要がある。
こうなんだっけ?

289 :デフォルトの名無しさん:2016/07/17(日) 18:30:48.46 ID:PyzTEoPA.net
まだ43cmの深淵にはたどり着けないようだなw

290 :デフォルトの名無しさん:2016/07/17(日) 18:40:03.90 ID:UzC9Qtsn.net
>>289
いやそれ何の事よ?
誤爆かと思いきや、そうではないのなら、
とりあえずブラウザバグっているからリロードしとけ。

291 :デフォルトの名無しさん:2016/07/17(日) 18:50:05.41 ID:UzC9Qtsn.net
ああ、引き算を確認するの忘れてた。

- は ToNumber(GetValue(target)) を引いて差を返す (11.6.2)
ToNumber(String) は 9.3.1 に従いパースする (9.3)

9.3.1内にはDate.toString()出力をパースする仕様はない。
だからGetValue(time values)はNumberを返さないと引き算は出来ない。
となると足し算も出来ないと仕様外のように思える。

なお確認している仕様はECMA5.1
http://www.ecma-international.org/ecma-262/5.1/#sec-11.6.1

292 :デフォルトの名無しさん:2016/07/17(日) 18:54:57.34 ID:PyzTEoPA.net
>>290
> いやそれ何の事よ?
布石だよw

俺は最初から正しいことを
言っていたと示すためのな。

293 :デフォルトの名無しさん:2016/07/17(日) 18:55:32.09 ID:PyzTEoPA.net
>>291
だから仕様通り(笑)

294 :デフォルトの名無しさん:2016/07/17(日) 19:13:09.85 ID:UzC9Qtsn.net
>>292
まあ何か思惑があるのならそれでいい。
ただ俺が見る限り今のところはAddが出来てもおかしくない仕様のように見える。
もちろん俺は仕様書なんてほぼ見てないから、先のように単語を変更されていると気づけないが。

まあいいや、とりあえず新着情報があるまではどうにもならんし。
現実的にDateが揃いも揃って仕様違反って事もないだろうし、
先の例のように俺が仕様書を読み慣れていないせいで見落としている部分があるのだろう。

295 :デフォルトの名無しさん:2016/07/17(日) 19:23:49.21 ID:UzC9Qtsn.net
> (今回で言えば日付型同士の減算が可能!?) (質問スレ>>213)
あと一応言っておくと、日付型ってのは普通は減算出来るんだよ。
だから質問者もいきなり減算しているし、
俺も逆にそれが出来ない!ってことでMDNに奇妙さを感じるわけでね。

だからこの点についても、この反応、もう一度書くと、

> (今回で言えば日付型同士の減算が可能!?) (質問スレ>>213)

これは経験豊富ならあり得ないんだよ。
で、そういうのは明らかにバレバレだから、
普通に考えてお前が経験豊富だと思う奴はいないと思うんだよね。
何でそこにこだわるのか全く分からないんだけど。
匿名掲示板で虚勢を張る意味無くね? 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)


296 :デフォルトの名無しさん:2016/07/17(日) 21:11:43.34 ID:PyzTEoPA.net
>>295
何いってんのお前w

MDNに日付の減算が出来ないなんて書いてないし
それなりにJavaScript使ってりゃ、
日付同士の引き算とかやるだろ。
ベンチマークとかでさ。

当たり前の知っていることなんだが?
お前にとっては当たり前じゃないんだろ?w

297 :デフォルトの名無しさん:2016/07/17(日) 21:12:34.25 ID:PyzTEoPA.net
> 現実的にDateが揃いも揃って仕様違反って事もないだろうし、
だから最初から仕様通りって言ってる

298 :デフォルトの名無しさん:2016/07/17(日) 22:11:41.91 ID:UzC9Qtsn.net
つか相変わらずお前は都合が悪いところは読まない主義なのなw

MSDNでもやっぱりgetTime()してるんだよ。
https://msdn.microsoft.com/ja-jp/library/ee532932(v=vs.94).aspx

既に言ったがMDNも。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Date

ついでにStackOverflowでも軒並み。
http://stackoverflow.com/questions/10931288/how-to-add-subtract-dates-with-javascript
http://stackoverflow.com/questions/1296358/subtract-days-from-a-date-in-javascript
http://stackoverflow.com/questions/7687884/add-10-seconds-to-a-javascript-date-object-timeobject

基本的にDateオブジェクトの直接操作は誰もやってないから、何か理由はあるとは思うんだけどね。
それが何かは俺には分からない。
考えられるのは、オブジェクト指向的な「メソッド越しに全てやれ」なのか、
実装ありきで来ている為、実は「仕様的裏付けがない」のか。(将来的に使える保証がない)
いずれにしても、サンプルコードにそう記述しない理由があるのは確かなんだよ。

どっちにしたってここまで地雷臭だと公開するコードなら直接操作は止めたほうがいいとは思うが。
質問者は今動けばいい個人レベルのコードだろうから別に構わないとは思うけど。

299 :デフォルトの名無しさん:2016/07/17(日) 23:04:02.72 ID:PyzTEoPA.net
だからgetTime使ってるからって
そのまま使えないってことにはならないんだが。
馬鹿なのかな?

300 :デフォルトの名無しさん:2016/07/17(日) 23:28:43.23 ID:UzC9Qtsn.net
まあどう思うかは自由だが、状況証拠からの推測なら、

1. 引き算は出来ているだけで、仕様として認められているわけではない
2. 多分俺の既投稿の解釈も間違いがあり、addの方は「仕様」で、subの方は「仕様外」

じゃないかな。以下でもgetTime()で引き算だ。
> delta *= date2.getTime() - date1.getTime();
> https://github.com/phiggins42/bloody-jquery-plugins/blob/master/date.js

とにかく確実に言えるのは、みんな引き算する前に getTime() してるんだよ。
オブジェクト同士を直で引き算している人は誰もいない。

で、もし君が「経験豊富」なら、
実はこういう「動くけど仕様外」のケースも結構あることを知っているはずなのだが。
だからマジでウザイしバレバレだから、いい加減にやめい。
いずれにしても、本当に経験豊富な奴は、誰も君のことを経験豊富だとは思わないよ。
虚勢を張るのも自由ではあるけど、意味無いと思うが。

301 :デフォルトの名無しさん:2016/07/17(日) 23:30:23.23 ID:PyzTEoPA.net
× 1. 引き算は出来ているだけで、仕様として認められているわけではない
○ 1. 引き算は出来ているし、仕様として認められている

302 :デフォルトの名無しさん:2016/07/17(日) 23:31:41.37 ID:PyzTEoPA.net
× 2. 多分俺の既投稿の解釈も間違いがあり、addの方は「仕様」で、subの方は「仕様外」
○ 2. addの方は「仕様」で、subの方も「仕様」

http://www.ecma-international.org/ecma-262/5.1/#sec-11.6.1
ここにもしっかり書いてある。

303 :デフォルトの名無しさん:2016/07/17(日) 23:33:08.55 ID:PyzTEoPA.net
しっかり書いてあるのに、それがわからないってことは
英語が読めないか、読めても意味がわからないんだろうな。

自覚して諦めて日本語でぐぐったら?w

304 :デフォルトの名無しさん:2016/07/18(月) 00:12:28.04 ID:CK8ZYmxh.net
>>302
Note1だろ?
> Date objects handle the absence of a hint as if the hint String were given.

辿ってみたが、なるほど[[DefaultValue]](8.12.8)の所でデフォがDateに関してはStringというのは分かった。
そしてValueOf()が返してくるのはこれだから、Add側がString連結になっているのはこれでいい。
ただこれだとsub側が都合が悪い。つまり、もう一度書くと、以下になっているわけだが、

> - は ToNumber(GetValue(target)) を引いて差を返す (11.6.2) (>>291)

GetValue(target)がデフォでStringを返してくるのでデフォのままでは引き算は出来ない。
一応GetValueにはPreferredTypeを指定することが出来て、
Numberを指定していれば数値が返ってくる。
だから仕様としてsubを定義する為には、subの時はNumber指定しないといけない。
で、それはどこに書いてあるんだ?

なおお前が大好きなmoment.jsも確認したが、同様に直ではなく、こちらはvalueOfを使っていた。
> mom._d.setTime(mom._d.valueOf() + milliseconds * isAdding);
> http://momentjs.com/downloads/moment.js
つってもMDNには同じだと明記されているが。
> This method is functionally equivalent to the Date.prototype.getTime() method.
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/valueOf

いずれにしても、何かしら理由があったんだと思うが。
とりあえず5.1で確認出来たらその記載が旧仕様にあるかどうかを確認すればいい。

つかこの際英語は関係ないだろ。そういうのもコンプレックス出まくりだから止めたほうがいい。
英語は日本語より下手なのを自覚した上で、ヒット件数と内容をとるか、言語をとるかでしょ。

305 :デフォルトの名無しさん:2016/07/18(月) 00:17:12.76 ID:CK8ZYmxh.net
しかし話はそれるが、この仕様だと + と - なら - の方がToPrimitive()がない分処理が軽いな。
ベンチマークに現れるかは謎だが。

306 :デフォルトの名無しさん:2016/07/18(月) 00:30:21.22 ID:UhcVRSnP.net
>>304
> だから仕様としてsubを定義する為には、subの時はNumber指定しないといけない。
> で、それはどこに書いてあるんだ?

お前は本当に馬鹿だなぁw

リンクは http://www.ecma-international.org/ecma-262/5.1/#sec-11.6.1 だろ
sec-11.6.1 だろ。
The Addition operator ( + ) だろ。

次の sec-11.6.2 になんて書いてあるのかも読めないのか?

307 :デフォルトの名無しさん:2016/07/18(月) 00:31:42.75 ID:UhcVRSnP.net
>>304
> つかこの際英語は関係ないだろ。そういうのもコンプレックス出まくりだから止めたほうがいい。

お前が英語読めないんだろ?
だから自分で持ってきたリンクも読んでないんだろ。

それともなにか?自分が持ってきたものを
読めるのに、読んでないのか?

308 :デフォルトの名無しさん:2016/07/18(月) 01:13:38.23 ID:CK8ZYmxh.net
ああ、なるほど分かった。
String変換はToPrimitiveの時であって、GetValue時ではないんだな。
この点を>>304では間違えていた。

Add: ToPrimitive(GetValue(target))でStringになって、それを連結。
Sub: ToNumber(GetValue(target))でNumberになって、引き算。
SubではToPrimitiveがないのがミソだ。

となるとそちらの主張通り、
> ○ 2. addの方は「仕様」で、subの方も「仕様」 (>>302)
のように見える。

さて、記載されている箇所は分かったので初期仕様(1997)版を確認したが、
http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf
11.6.1 The addition operator(+)
11.6.2 The subtraction operator(-)
9.1 ToPrimitive
9.3 ToNumber
15.9 Date Object
に本質的な違いがあるようには見えない。
つまり、最初から仕様としてaddもsubも使えた(今と同じ動作だった)ように見える。
しかし誰もsubを使っていない。となると結論としては、

仕様には最初から盛り込まれていたが、
A. 実装が追いつかず、動かない環境が多かった。(あった)
B. バグっていて使える状況ではなかった。

のどちらかだね。
今後については、自分が対象とするブラウザで動作を確認出来れば使えばいいということになる。
はい、お疲れさまでした。

309 :デフォルトの名無しさん:2016/07/18(月) 01:26:28.55 ID:UhcVRSnP.net
> しかし誰もsubを使っていない。となると結論としては、
お前が見た限りの話だろw
使ってないだけで、使えない理由にはならない。

C. たまたま検索した所が使ってないところだけだった

昔うんぬんかんぬんが事実だとしても
今使えない理由にはならないからな。

事実として、今問題なく使えると判明しているものを使ってないだけ。
故に使ってないからと言って問題があるという事にはならない。

310 :デフォルトの名無しさん:2016/07/18(月) 01:28:24.23 ID:UhcVRSnP.net
で最終的な結論は俺が最初から言っていたとおり、
addも仕様、subも仕様。

こんなこと理解するまでに何時間費やしてるの?
センス無いんじゃね?w

311 :デフォルトの名無しさん:2016/07/18(月) 01:44:14.47 ID:CK8ZYmxh.net
>>309
まあどう思おうが勝手だが、
基本的にはライブラリ開発者もMDN執筆者も俺よりJavaScriptの経験は明らかに豊富で、
その彼等が回避している事を俺がわざわざ試す意味はないよ。
君のアプリは君が好きなようにすればいい。

俺がセンス無いと思うのならそれでいい。
ただ、そんな無駄吠えしている限り、君は上達しないよ。

312 :デフォルトの名無しさん:2016/07/18(月) 01:55:05.46 ID:UhcVRSnP.net
使ってない=回避と考えてるのが
お笑い種だw

自分で持ってきた仕様書に俺が何度も
書いてあるって言ってようやく読んだくせにな。
理解遅すぎるんだよw

313 :デフォルトの名無しさん:2016/07/18(月) 01:57:21.33 ID:UhcVRSnP.net
きっとこの程度の理解能力じゃ
なんで+がこういう仕様になっているかも
まだ気づいてないんだろうな。
俺が指摘してようやく考え出すぐらいだろうw

314 :デフォルトの名無しさん:2016/07/18(月) 02:02:36.39 ID:CK8ZYmxh.net
>>313
+は文字列内埋め込みにはこの方がいいからだろ。あれはあの仕様でも良いんだよ。
ただいちいち toString() する仕様でも良いんだよ。

てかお前は異様に「仕様」談義が好きみたいだが、マジで何か書いた方がいいぞ。
そしてその中で素晴らしいライブラリの使い方を披露すれば、布教も出来るだろ。

ついでに言っておくと、今回の質問者の「ライブラリは…」ってのはかなり妥当な状況だよ。
いちいちあの程度でライブラリを導入する方が手間なんだよ。

315 :デフォルトの名無しさん:2016/07/18(月) 02:06:50.86 ID:CK8ZYmxh.net
あーそういえば43cmってなに?
厨二病だとは思うが聞いておいてやるよw

316 :デフォルトの名無しさん:2016/07/18(月) 02:07:17.57 ID:UhcVRSnP.net
はっはっは、仕様を持ち出してきたのはお前だし、
俺は、そこに書いてあるから読めといっただけだ。
俺は談義なんてなんもしてねーぞw

317 :デフォルトの名無しさん:2016/07/18(月) 02:08:12.29 ID:UhcVRSnP.net
>>315
ぐぐれかすw
俺が最初からこの程度のことを知っていたことを
証明するためのサイトだ。

318 :デフォルトの名無しさん:2016/07/18(月) 02:16:59.61 ID:CK8ZYmxh.net
あーまあ確かに今回は結局の所ほぼ自力で辿り着いているから、
確かに談義もしてないし、協力も大してしてもらってないわな。
とはいえ、getTime()については俺は前から疑問を持っていたからついでに調べたんだ。

>>317
これか?
http://d.hatena.ne.jp/sandai/20100916/p1
んー、まあこれを読んでも今回の結論には至らないけどな。
ちなみに俺は仕様書を断片的にしか読んでないから、多分
ToPrimitive(Number)がvalueOfを呼び、
ToPrimitive(String)がtoStringを呼ぶのは予想出来るが、
それがどこに書いてあるかまでは確認してない。まあもういいが。

319 :デフォルトの名無しさん:2016/07/18(月) 02:31:49.78 ID:UhcVRSnP.net
>>318
そこも少しあるが、そこのリンク先だw

おめでとう、ようやく俺に追いついたなw

320 :デフォルトの名無しさん:2016/07/18(月) 02:33:00.01 ID:CK8ZYmxh.net
>>313
ああちなみに一応コメントしておくとな、

11.6.1のNOTE1で例外規定を書いているだろ?これは結局の所 if 文が必要になるんだよ。
だから仕様としては、「文字列として連結したいなら常に toString() 」の方が綺麗になる。
そうすれば+だけあるToPrimitiveが除去可能で、+と-を同じ関数で処理する目が出てくるだろ。
現実にはこれだけでは駄目だけど、そうやって無駄な関数を増やさないのが良い設計なんだよ。

本来腕前ってのはこういう「如何に無駄をなくすか」で勝負すべきであって、
お前らがやっているみたいな
「1行のチューニング」「俺の方が仕様に詳しい」「俺の方が短い」ではないんだよ。

321 :デフォルトの名無しさん:2016/07/18(月) 02:38:48.12 ID:UhcVRSnP.net
無駄をなくすなっていうのは、
一行の無駄もなくすって意味だし、
(コンピュータにやらせる)

仕様を出してきたのはお前だし、

短いっていうのが無駄をなくすってことだし。

わかってねぇなぁ。
今時アセンブラで書くとか言う話をするのかねぇ。

一番の無駄は人間が作業することなんだがw

322 :デフォルトの名無しさん:2016/07/18(月) 02:42:22.09 ID:CK8ZYmxh.net
>>319
これか。確かに俺が確認したのと同じ事だな。
http://os0x.hatenablog.com/entry/20100916/1284650917

323 :デフォルトの名無しさん:2016/07/18(月) 02:45:40.64 ID:UhcVRSnP.net
>>322
読めば一瞬で終わってた内容。
おつかれさんwww

324 :デフォルトの名無しさん:2016/07/18(月) 02:47:05.64 ID:CK8ZYmxh.net
>>321
まあ今のお前にいくら言っても分からないとは思うが、必要なのは、
「構造的」簡潔さなんだよ。
「記述的」簡潔さではない。
もちろん記述も簡潔な方がいいんだけどね。
とはいえ、構造が簡潔なら記述が複雑になることもないんだよ。

とにかくお前は大きいのをまずは書いてみることだよ。
そうすれば色々と至らなさが分かると思うよ。

325 :デフォルトの名無しさん:2016/07/18(月) 02:49:44.99 ID:CK8ZYmxh.net
>>323
それはない。
俺の疑問はgetTime()が何故いるのか?であって、
add/subについてではないから。

まあこの際どうでもいいが。

326 :デフォルトの名無しさん:2016/07/18(月) 03:01:24.39 ID:vbFE3yAk.net
また殺人くん呼ばわりのあのアホかな。

あのな、DateTimeというのは、日付と時間だよな。ある一点を指し示す値だ。もっと詳しく言えば、ある内部値を、日付と時間として扱えるようにしたオブジェクトだ。

その、「ある一点を指し示す日付と時間同士を、四則演算する」って凄くナンセンスだと思わない?

ある一点と、ある一点の間の距離は、numberか?
違うよな。
.net見てみろよ。TimeSpan型がある。

例外とかそういう馬鹿な話じゃない。

頭の中を整理して、できて良いかできてはいけないのか精査せえ。

何故getTimeしてるかわからんのか?
エポックとして、一点の情報ではなくなり、原点からの長さとして値を返してると考えるとことができる秒に変換しとるよな。要はベクトルに。

お前高校数学からやり直してこいよ。

327 :デフォルトの名無しさん:2016/07/18(月) 03:02:19.26 ID:vbFE3yAk.net
>>326
言い忘れ。
「ベクトルなら加減乗除自在だよね」とダメ押ししとくわ。

328 :デフォルトの名無しさん:2016/07/18(月) 03:11:07.49 ID:UhcVRSnP.net
>>325
> 俺の疑問はgetTime()が何故いるのか?であって、

日付に +1 するときだろw

329 :デフォルトの名無しさん:2016/07/18(月) 03:13:48.33 ID:UhcVRSnP.net
いま普及している言語で、完璧な
構造的簡潔さとやらを備えてる言語ってなんだろうねw

重要なのは道具として使えることだよ。
道具として使えるならば簡潔でなくても良かった。

そうやって、制限のある中で今まで
実現してきたんだって。

330 :デフォルトの名無しさん:2016/07/18(月) 05:04:13.15 ID:FfTrxk2L.net
>>325
ES.nextでvalue-objectやらvalue-proxy、もしくは演算子オーバーロードが議論されてるよ。
まあとは言え今のDateをそのまま対応させるのはナンセンスだし、いろいろ問題あるから、
サフィックスで数値型を拡張できる優秀な案を使って、
1s -> <time>(1s)
2016Y+7M+18D -> <time>(1468767600000s)
3s - 1s -> <time>(2s)
date - 1s -> <date>
の用にできる。

まあその場合もgetTimeが要らなくなるわけじゃない、
勿論今でも単項+演算子使えば要らないので、要らないの定義によるが、
君は結局もっといい形があるじゃん、と言いたいのか、なんなのかよくわからないな。

331 :デフォルトの名無しさん:2016/07/18(月) 23:56:44.27 ID:CK8ZYmxh.net
>>330
基本的には
・getTime要らないなら何故いちいち付いているのか?(全員付けているのか)
・今確かに動いているが本当に引き算は出来るのか?(仕様内なのか)
の確認だから。

今の仕様でもそんなに悪くないけど、直交してないから実装に負担がかかる。
とはいえ今更変更することは無理だし、
新仕様を検討している連中はこの辺全て分かっているだろうから、見守るしかないね。
なおgetTimeが要らないといっているのは引き算時限定であって、(これは経緯を見れば分かるはずだが)
やっぱりlodash君は「前との関連で」の会話が出来ないんだな。
多分ガチのアスペなんだと思う。

とはいえここは匿名掲示板なんだから、俺たちがアスペに対して気を使う必要はない。
(個人を特定して気を使う必要はない)
過去の発言は全部読めるのだから、ちゃんと読み直して付いてこいとしか言えんね。
lodash君の会話の組み立て方では普通は荒らし扱いされる。
それは読み直すことによって多少は改善するから、まずはそれを心がけることだ。

という書き方だと伝わらないのかな?
まあしかしこれ以上面倒見れんが。

332 :デフォルトの名無しさん:2016/07/19(火) 00:27:47.65 ID:gHzhdyCj.net
> ・getTime要らないなら何故いちいち付いているのか?(全員付けているのか)
たまたま

> ・今確かに動いているが本当に引き算は出来るのか?(仕様内なのか)
仕様に書いているのだから、仕様通り

333 :デフォルトの名無しさん:2016/07/19(火) 00:39:36.64 ID:gHzhdyCj.net
> なおgetTimeが要らないといっているのは引き算時限定であって、(これは経緯を見れば分かるはずだが)

他にどんな演算子があるかぐらい調べろよw

new Date() / 1
new Date() * 1
new Date() % 10
new Date() ** 1
+new Date()
-new Date()
~new Date()
new Date() > 0 (< <= >= も同様)
new Date() << 1 (>> >>> も同様)
new Date() & 1
new Date() | 1
new Date() ^ 1

これらも仕様通りgetTime()はいらない。

というか逆に+のときだけgetTime()が必要と思ったほうが良いぐらい。
+は文字列結合と数値の加算の二つの意味があるから、仕方なくこうなってしまったという話。
(それ以外は二つの意味はない)

334 :デフォルトの名無しさん:2016/07/19(火) 00:48:15.24 ID:gHzhdyCj.net
> 今の仕様でもそんなに悪くないけど、直交してないから実装に負担がかかる。
> とはいえ今更変更することは無理だし、

直すならばDateの仕様ではなく、+オペレーターの方。
Perlみたく、+ は数値演算、 . で文字列結合 とするしかない。

335 :デフォルトの名無しさん:2016/07/19(火) 01:05:34.97 ID:gHzhdyCj.net
どうやら俺の発言が気に食わないようだが
俺に比べて技術と知識も劣ってるから、
getTimeがいらないのは引き算限定とかいう
発言で反論しようとするんだよなw

一般論として技術力が高い人ほど多くのことを
知っているんだよ。知ってるからこそ技術力も高くなる。
関数型プログラミングはいいよ。コードがシンプルになる。
lodashやjQueryは便利なライブラリ。

336 :デフォルトの名無しさん:2016/07/19(火) 02:25:00.57 ID:9Xihfq37.net
相変わらずアスペ全開だな。

まあついでに言っておくと、JavaScriptの連中は仕様書を書いている連中すらゴミだってことだ。
オブジェクト指向を理解出来てない。

Type固有の案件は全部15章に突っ込まないと駄目だ。
11章の演算子(+)に書くとか、親クラスのメソッドに子クラス毎にif文入れているようなものだ。
あの仕様書では頭からお尻まで全部読まないと理解できない。典型的な駄目コードだ。
だから俺も読み込むまでに余分に時間がかかった。

var Object = {
operator+: funciton() {
if (typeof(this)==='Date') // 11.6.1 NOTE1 // 現行仕様書
}};

var Date = {
operator+: function() { // 15.9.X // こっちに書くべき
}};

Type固有の例外規定が15章に書いてない時点で仕様書の構造がゴミ。
但し書きはダブって良いので、15章にも書き、そっちがオリジナルであるべき。
上記上側みたいに、Dateオブジェクトの特別扱いを、子クラスでメソッドをオーバライドせず、
親クラスのメソッドにいちいちif文入れてこられたらキレるだろ?
上記下側のように、子クラスでオーバライドした上で、
親クラスのメソッドに「Date型ではオーバライドされています」とコメントを付けておくべき。

337 :デフォルトの名無しさん:2016/07/19(火) 02:25:35.18 ID:9Xihfq37.net
お前らの大半はこれにすら気づけないと見ている。
正直、JavaScriptの連中が上達してないのはかなり根が深い問題だと認識し始めてる。
仕様書すらこれだ。
多分君らの大半は何が良いコードなのかも理解出来ていない。
それはまともな構成の仕様書/コードを見たことがないからだ。
これについては、丁度OOPのスレでそれを問う勇者がいたから見てくるといい。(今は死にスレだが)
http://echo.2ch.net/test/read.cgi/tech/1467992113/10
http://echo.2ch.net/test/read.cgi/tech/1467992113/65

例えば仕様書だけでもまともであれば、
無意識的にオブジェクト指向を学習出来たはずなのだが、そうなっていない。
この酷い仕様書を読むまでは気づかなかったが、
当たり前だが他言語の仕様書は達人が書いているので、こうはなっていない。
だから仕様書を読んでいれば無意識的に
オブジェクト指向(正確には著者のプログラミングスタイル)も学習していける。
JavaScriptにはこれがない。つまるところ、教科書が悪いから上達しにくい。
それでも、他人のコードをほぼ全て見える状況は、おつりが来るほど有利だとも思うのだが。

338 :デフォルトの名無しさん:2016/07/19(火) 03:43:57.22 ID:pXKjqsL9.net
上達くんはトリップ付けてくれよ

339 :デフォルトの名無しさん:2016/07/19(火) 04:38:03.16 ID:gHzhdyCj.net
自分の能力不足を仕様のせいにまでしてきたねw

340 :デフォルトの名無しさん:2016/07/19(火) 04:50:08.67 ID:gHzhdyCj.net
Dateにオペレータ+を書くとかさ間抜けすぎるっていうかw
世の中にはいろんな言語があるってことを知らないんじゃないかねぇ。
そして最高の言語があるとか思ってるんじゃないかねぇ。

JavaScriptにおいて演算子はクラスのメソッド(相当)ではない。
演算子のオーバーロードがないのもクラスのメソッドじゃないからだ。
だから演算子が特定のクラスにつくことはない。

もし+演算子がクラスのメソッドであれば、それはクラスごとに変更可能であるはずだ。
また戻り値も好きに変えられるはずだ。(例えばComplex型+Complex型の結果をComplex型にする等)

だけどJavaScriptではそれは出来ない。といったらJavaScriptは劣ってるとか言うんだろうな(苦笑)
これは言語のコンセプトの違いでしか無い。スクリプト言語としてそういう設計になってる。

JavaScriptにおいて演算の結果は文字列か数値にしかならない。(厳密に言えばNaNとかもあるが)
演算子はクラスメソッドではなく、演算子が使われた段階でオブジェクトはプリミティブ型に変換される。
Date型に対して+メソッドが呼ばれるのではなく、プリミティブ型への変換メソッド(valueOf)が呼ばれる。
その後に演算子の効果が働く。

な? 能力が低いんだよこいつは。
自分の知ってる○○の言語の常識でしか考えることが出来ない。

341 :デフォルトの名無しさん:2016/07/19(火) 04:57:24.04 ID:gHzhdyCj.net
Dateにoperator+を書くべきじゃないと言ったが、
もちろんObjectにも書くべきじゃない。

>>336はさも、Objectにoperator+があるのが
現行の仕様だと言っているが、現行の仕様は
Objectにoperator+なんてものは存在しない。
ObjectにあるのはvalueOfメソッドだ。

そしてObjectのvalueOfメソッドに if Dateなら?みたいなコードはない。
Operator+解釈のアルゴリズムの結果、Date型のvalueOfメソッドが呼ばれるだけだ。
Operator+の処理が実行されるのは、Object(やDate)のメソッドが呼び出される前だ。
それは仕様を読めばわかること。

だからこそ15章 Native ECMAScript objects ではなく、
11章 Expressions に分離して書かれているのだ。

342 :デフォルトの名無しさん:2016/07/19(火) 09:44:05.11 ID:Lmd4i1Ew.net
>>336
仕様書が変に構造化されてて読みにくいのは非常にその通り。
でもES2015以降徐々に改善されて行ってるよ。
そういう意味でも最新の仕様書を読んだほうが良い。

で、確かに@@toPrimitiveはビルトインではDateとSymbolくらいにしかついていないので特有だが、
別にこれは外したり自由に付けたりもできるし、処理の流れの中で例外というわけでもない。

343 :デフォルトの名無しさん:2016/07/19(火) 17:59:10.43 ID:Ll9Tyf8R.net
頭おかしいのかな。
オブジェクト指向でも、クラス指向ではない。
型は無いに等しい。アヒルの様に鳴き、アヒルの様に歩けば、それはアヒルである、という「見做し」を代わりに使用する。
この2つだけで、何故演算子がその時と場合で意味が変わるか、理解出来るんじゃなかろうか。

知能低すぎなのは、その程度で関数型とか言っちゃってる脳味噌じゃねえの?
valueOfは、見做しの典型だろ。
どんなオブジェクトであれ、どんな経緯でプロトタイプがチェーンされていても、それを辿って一番最初に見つかったvalueOfが使われるんだから。

344 :デフォルトの名無しさん:2016/07/19(火) 19:56:18.15 ID:Lmd4i1Ew.net
まあそういう挙動が変だ、嫌だって言うなら
delete Date.prototype[Symbol.toPrimitive]
すれば変えられる。
誰かは言わないけど世の中には
delete Object.prototype.__proto__
とか嫌いで許せない物をまず削ってから始める派の人も居るみたいだしね。

345 :デフォルトの名無しさん:2016/07/20(水) 00:55:34.54 ID:uzXTbo4C.net
>>344
そー。
if Dateとかナンセンスすぎんのよ。
とりあえずvalueOf呼んで、その実装が誰のものかどのインスタンスのものかなんか気にせず、帰ってきたのが値で、
それ以上でもそれ以下でも無い。

クラスのメソッドとか脳味噌の代わりにウニ詰まってるレベル。
オブジェクトか、オブジェクトのプロトタイプのプロパティに
functionが入ってるだけであって、クラス()のメソッド()でも何でも無い。
関数を一級市民とみなす関数型言語erが、まさかの関数をメソッドと特別扱いするとは。

演算子は演算子であって、それ以上でもそれ以下でもない。その後に効果が働くも何も、それ以外の役には立たんから演算子として、言語として定義されとんのだ。

346 :デフォルトの名無しさん:2016/07/20(水) 02:05:37.37 ID:eZynd/Sj.net
>>342
> 処理の流れの中で例外というわけでもない
俺が言っているのは、ToPrimitiveを呼ぶことではなくて、
ToPrimitiveのデフォルト値がTypeによって異なっていることだ。
ただしこれについては俺も>>336内では間違っていた。正確には以下。

var Object = {
ToPrimitive: funciton(hint) { // 9.1
if (typeof(this)==='Date') // 11.6.1 NOTE1 // ES5.1仕様書
}};

つまり、15.9 に書くべき内容が、次点の 9.1 にも書いてなくて、 11.6.1 に書いてある。
二重に落とし穴になっている。
そして、当たり前だがNOTE1が例外だと言っている。
というか例外じゃなければNOTEの意味無いだろ。

仕様書のおかしな構造は、おそらく仕様書それ自体を書いたわけではなくて、実装から起こしたからだ。
だから仕様書として妥当な場所ではなく、それが実装してある場所に記述があるのだろう。
とはいえその場合でもこのNOTE1の内容なら 9.1 にあるべきであって、
いずれにしても 11.6.1 にあるのはかなり謎なのだが。
そして、実装から起こすにしても、まともな実装ならそのまま仕様書に焼き直しても上手く行く。
いずれにしてもアレなんだろうさ。

NOTE1(仮): Dateの場合はhintにStringを与えて呼び出す // 11.6.1 にあっても不思議ではない、
 // 336の俺の勘違いはこれ、11.6.1にある点と整合させる為に脳内変換してしまった
NOTE1(ES5.1仕様書): ToPrimitiveはhint無しの場合、
 Date以外はNumberが、
 DateはStringがhintに与えられたものと見なす
 // ToPrimitiveの動作説明を(+)の説明内に配置?意味不明
 // しかもToPrimitiveの場所(9.1)にはこの説明は無しかよ!マジで頭おかしい

347 :デフォルトの名無しさん:2016/07/20(水) 02:06:29.35 ID:eZynd/Sj.net
さてES7仕様書を確認してみた。確かに大幅改訂されている。
7.1.1のToPrimitiveの所にNOTEがある。(改善あり)
12.8.3の + の所にはこれまでどおりのNOTE記述、まあこれはあった方がいい。
20.3.4.45にはDate.prototype[@@toPrimitive](hint)が追加されている。(改善あり)
結果、俺が問題だと思った点は全て改善され、妥当な配置になっている。

> そういう意味でも最新の仕様書を読んだほうが良い
ああその通りだ。今後俺はそうするよ。少なくともES5.1仕様書はゴミだ。

> 別にこれは外したり自由に付けたりもできるし、処理の流れの中で例外というわけでもない
それは完全に後付だよ。とはいえ妥当な解決策ではあるが。
最初からNumberならこの部分自体が丸々要らない。
無駄仕様で無駄に膨らむ駄目パターンの典型だ。

とはいえ、ES7には今のところ問題点はないね。
俺もこの解決策を採るだろうし、仕様書としても今現在俺が検出した問題点は全て解決済みだ。
徐々に改善されているのは事実だね。

ただまあ、20年も経とうとしているのにこのレベルの改善を未だにやっていること自体が問題だが。
他言語の仕様/仕様書なら、最初からこんな問題は存在しない。
というか、ブレンダン・アイクは何で仕様書を書かなかったんだろう?
彼が第1版を書けばこんな事にはならなかったはずなんだよ。

>>344
ググったらヒットした。で、試してみた。
が、効果あるか?特に何も変わらない気がするが。
ES6フラグとか指定必要?

348 :デフォルトの名無しさん:2016/07/20(水) 02:09:56.99 ID:eZynd/Sj.net
あ、ちなみに試したのは後者、間違いないようにもう一度書いておくと、以下ね。

> delete Object.prototype.__proto__

とりあえず期待した効果がない(気がする)

349 :デフォルトの名無しさん:2016/07/20(水) 02:15:43.13 ID:E+SEwayU.net
> 他言語の仕様/仕様書なら、最初からこんな問題は存在しない。

そんなわけねーだろw
どんな言語でも最初は汚いし
完璧な言語はない。

なによりお前、他の言語と言ってるが、
じゃあ具体的にどの言語だよ?
どうせしらんだろ

350 :デフォルトの名無しさん:2016/07/20(水) 02:31:38.89 ID:eZynd/Sj.net
>>344
いじってみると、動作の差異を検出出来た。
delete以降は__proto__指定でのプロトタイプ切り替えは出来なくなる。
ただし、リテラルとしてオブジェクト全体を生成する場合は指定が効くという、
極めて中途半端?な状態になっている。

果たしてこれが仕様なのか、もちろん動作自体ももっと確認しないと怖くて使えないが、
これが仕様であれば、意図は分かるし、最初からこうならこっちの方がいい。
ただ、今現在の動作しているコードの中でこれをやるのは無理だね。副作用が怖すぎる。
(つまり、結論としては、仕様だと確認出来ても使わない)

351 :デフォルトの名無しさん:2016/07/20(水) 02:40:40.72 ID:xVzG2GNh.net
>>350
それがなぜかが判れば、自分がどれだけ間抜けな事言ってるかかわかると思うよ。
アスペならダックタイピングとか、関連用語を詰めてこい。

352 :デフォルトの名無しさん:2016/07/20(水) 03:30:00.35 ID:eZynd/Sj.net
B.2.2だろ?
他を見てもアクセサとして実装するところまでは仕様のようだから、
deleteに関しても仕様通りの実装になっていれば同じ動作だろう。
しかしObject.definePropertyを使えば同じ事が副作用無しで出来るのに
わざわざdeleteする意味は何?

353 :デフォルトの名無しさん:2016/07/20(水) 07:46:36.40 ID:2oUQ3wZY.net
>>350
まあ多分Object.prototype.__proto__が嫌いな人は
Object.prototypeに余計で醜いの生やすな!って言いたいのもあるだろうから
それで良いんじゃないのかな。

あとまあES仕様は基本的に一箇所に最小限しかかかれていなくて、
慣れていないうちはあっち行ったりこっち行ったりする必要があるが、
逆に言うと基本処理を覚えてパターンに慣れるほどに読みこなしてしまえば、
短い一部を読むだけで理解できるからむしろ楽という事もある。
仕様書いてる人もそうだから、初めて読む人の読みづらさがなかなかわからないんじゃないかな。

354 :デフォルトの名無しさん:2016/07/20(水) 09:31:33.55 ID:E+SEwayU.net
このようにJavaScriptの仕様書っていうのは
よく読まれやすい。読んでいるからこそ苦情も出てくる。

それに対して、他の言語の仕様書は読む気すらおきない

355 :デフォルトの名無しさん:2016/07/20(水) 13:30:34.45 ID:2oUQ3wZY.net
処理系と仕様が完全に分離されてるのもどちらかと言うと珍しいのもあるかもな。
RubyやPythonだったら言語学者でもない限りメインの処理系の動き=仕様ということで納得する部分があるが
JSだと沢山の処理系で動くように作らないといけないからね。

各処理系の対応度合いもまちまちだし、1つの処理系だけ取っても変化が早い。
だから言語仕様書を頼ることが多くなるのかもね。
でも言語仕様書はあくまで言語仕様書であり、リファレンスとは違うので誰にでも分り易いものではないね、

356 :デフォルトの名無しさん:2016/07/20(水) 23:30:45.27 ID:E+SEwayU.net
JavaScriptの標準APIがRubyのそれとは違って
大幅に機能が少ないからのは標準化のせいなのかな?
他言語を見習って一気にメソッド増やしてほしいものなんだが。

http://ruby-doc.org/core-2.3.1/Enumerable.html

これらのメソッドの多くがないから、lodashなどに
頼る必要が出てくる。

他言語で標準化されてるならば、JavaScriptに取り入れるかなんて
議論する必要はないと思うんだけどな。

357 :デフォルトの名無しさん:2016/07/21(木) 07:48:11.60 ID:3EZYXG7o.net
Rubyやらより遥かに後方互換性を切るのが難しいからね。
Rubyやらはなんだかんだ言ってメジャーバージョンアップの時には思い切って互換性を切ることができる。
そこでの一番の問題はユーザーがついてきてくれるかとか、そんなところ。

でもJSは後方互換性を切るとなったら、それが受け入れられるかなんてむしろどうでもよくて、
今あるコンテンツのほぼ全てに影響がないかが大事になる。
それは同等の力を持ったエンジンが複数あり、ユーザーコミュニティではなくエンジン開発陣主体だから。

目線が違うので、便利だから入れようという盛り上がりが起こることは少なく、
今ある特にパフォーマンスや技術的問題を、具体的に解決できる提案が取り入れられやすい。

358 :デフォルトの名無しさん:2016/08/21(日) 21:25:32.47 ID:u7v77FIA.net
IndexedDBでdeleteObjectStoreする時にトランザクションが(仕様上)取れなくて、
そのままdb.close()するとエラーになる時があるんだが、これってどうすればいいのだ?
e.target.errorは以下。e.target.transacsionはnull(IDBFactory.openで呼んだ直後)

target:IDBOpenDBRequest
error:DOMException: The connection was closed.
code:20
message:"The connection was closed."
name:"AbortError"

createObjectStoreはtransactionプロパティがあるのでそれでoncompleteを待てるのだが、
deleteObjectStoreは何故かvoidを返す仕様で、待ちようがない。
ならばそのままクローズで良いのかと思いきや、エラーになる。
https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase/deleteObjectStore

普通ならIDBDatabase.transactionがプロパティでそこから辿れるはずなのだが、メソッドだし。
deleteの時にトランザクションがないわけがないし、
それにアクセス出来ないのは仕様上の欠陥だと思うが。
createObjectStoreがobjectStoreを返すのは便利で良いが、本来はTransactionを返すべき。
だったら空オブジェクトにtransactionプロパティだけでも付けておいてくれないと対応出来ない。

なおヒット状況は、
1. あらかじめIndexedDBに500個ほどオブジェクトストアを作っておく。
2. open直後にそのうち3つほどを連続して消す。
3. クローズ。
この3のタイミングの取り方が分からない。

IndexDBは初めて使うので、使い方が間違っていたり、
或いは大幅に勘違いしてるかもしれないけど、その辺も含めてよろしく。
なおアプリとしてはもう一度削除されるだけなのでクリティカルな問題ではない。

359 :デフォルトの名無しさん:2016/08/21(日) 22:46:27.65 ID:Dn9vwW86.net
>>358
createもdeleteもversionchangeでしか使えんだろう。

360 :デフォルトの名無しさん:2016/08/21(日) 23:07:56.19 ID:u7v77FIA.net
createObjectStoreも単発で作るだけなら同じかもしれないが、それは試していない。
こちらの使い方では以下サンプルの通り、
createObjectStore直後にobjectStore.transaction.completeで書き込みを行っているので、
書き込み側では今のところ問題はない。

> 「データベースを構築する」からの抜粋
> var objectStore = db.createObjectStore("customers", { keyPath: "ssn" });
> objectStore.transaction.oncomplete = function(event) {
> }
> https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Using_IndexedDB#Opening_a_database

ちなみにcreateObjectStoreのtransactionは複数作成しても同一なので
(oncompleteは最後に1回呼ばれるだけ)
おそらくdeleteObjectStoreのトランザクションとも同一。
だからこれが見えれば問題は解決出来るはずなのだが、辿り方が分からない。
(というか仕様上抜けているように見える)

361 :デフォルトの名無しさん:2016/08/21(日) 23:34:58.54 ID:u7v77FIA.net
ちなみにcreateObjectStore/deleteObjectStoreを常用しようとしている。
APIを見る限り、確かにこれは通常想定されている使い方ではないようだが、
versionカウンタが64bit整数だから出来ない使い方でもない。

管理上最適な階層にすると、今回はcreate/deleteを常用する事になる。
だからそれが出来るかどうか試している。(実用に耐えるかどうか)

362 :デフォルトの名無しさん:2016/08/21(日) 23:35:23.04 ID:sjfW/TwQ.net
トランザクションはversionchange全体で1つ

363 :デフォルトの名無しさん:2016/08/21(日) 23:45:38.76 ID:Dn9vwW86.net
>>360
ハンドラに代入したらそりゃ一回だけじゃねえの?
addEventListener使わないのはどうして?

複数作成しても同一、ってなんで複数作成する必要があるの?
トランザクションと同じ、の根拠何なの?
onupgradeneededでしか使えないんじゃなかったっけ?
消す意味がわからんのだけど、なんで消したいの?
消さなきゃいけないなら保存なんかしなけりゃ良いと思うんだが。

createObjectStoreがなんでtransaction帰すべきなの?
ObjectStoreをcreateしたのに。
一つのストアから、2つ以上のトランザクション作りたい場合に詰むんじゃねえの?

なんか根本的に間違ってない?

364 :デフォルトの名無しさん:2016/08/21(日) 23:48:10.59 ID:ZqmshKaM.net
なぜ、ストアごと消す必要があるんだろう。
中身だけ消せばいいんじゃねえの?clear一発っしょ。

365 :デフォルトの名無しさん:2016/08/22(月) 00:02:44.22 ID:m1LOPf7I.net
中身だけ消す使い方も出来るが、それだと名前対応の辞書引きが必要になる。
管理上「最下層の名前=最下層のobjectStoreの名前」が一番簡単だからそうしている。
アクセス/追加/廃棄単位もこれと同一だから、管理上はそこにobjectStore階層を置きたい。
もちろんキーに全部含めてフラットに扱うことも出来るが、
元々階層オブジェクトなのをフラットにしてDBに負荷をかけるのは本末転倒だ。
それでコードが楽になるならメリットもあるが、今回はそうではないし。

今回は完全に階層オブジェクト(末端はファイル)だからIndexedDBの必要はないのだけど、
FileSystemAPIだとChromeしか使えない。
これについてはFireFoxはIndexedDBを使えという主張らしく、
確かに機能的には上位互換だから、動作が十分に軽ければ問題ない。だからそれを試している。
https://dev.mozilla.jp/2012/07/why-no-filesystem-api-in-firefox/
http://www.html5rocks.com/ja/tutorials/file/filesystem/

366 :デフォルトの名無しさん:2016/08/22(月) 00:09:17.75 ID:bLWZhaRu.net
ファイルって何に使ってるの?
最悪消えても良いのならCacheStorageもあるが。

367 :デフォルトの名無しさん:2016/08/22(月) 00:15:46.53 ID:m1LOPf7I.net
>>362
確認した。おそらくそのようだ。
> Transactions of this mode cannot run concurrently with other transactions. Transactions in this mode are known as "upgrade transactions."
> https://developer.mozilla.org/ja/docs/Web/API/IDBTransaction
そしてこの"upgrade transactions."がどこのプロパティに現れるのか知りたい。
つか、一つならdb.transactionにぶら下げといてくれよなと。
createObjectStoreの後にもここにはぶら下がってないね。

368 :デフォルトの名無しさん:2016/08/22(月) 00:23:12.68 ID:m1LOPf7I.net
>>366
Web上のファイルの保存用途に使う。(アーカイブ)
だからファイルが保存出来れば何でも良い。
(まだFileSystemAPIは試していない)

URLは最初から階層になっているし、それを保つのが管理上一番楽だからそうする。
したがって、DBアクセスの必要はない。
ユーザがライフタイムを完全に管理出来なければならない。
(Web上から削除された時、ユーザ側で削除するか保存するか決める)

CacheStorageはあとで見てみるが、チラ見では新しすぎる感じ。

369 :デフォルトの名無しさん:2016/08/22(月) 00:32:40.08 ID:utwn7AiT.net
>>365
頭おかしくなければ、もともと階層オブジェクトなのをフラットに、とか変な事考えなくていいんじゃねえの?
/hoge..../a.php?aaa/bbb
/hoge.../a/aaa/bbb
が同じとかあんじゃん。

url:{
content:Blob,
schema:xxx,
host:xxxx,
port:xxxxx,
path:[aaa,bbb,ccc]
}
とでもオブジェクト作って、pathにインデックス貼れば?
なんの負担でも無いよ。indexで引くDBだからindexedDBなんだし。
階層構造を保存するためにハードディスクが階段の形してるなら寝言続けて。

370 :デフォルトの名無しさん:2016/08/22(月) 00:36:42.04 ID:m1LOPf7I.net
>>366
CacheAPI見てみたがライフタイムの管理がよく分からん。
「ユーザ側からの削除無しなら永久保存」(つまりファイルと同じ)に出来る物なの?
https://developer.mozilla.org/ja/docs/Web/API/Cache

あとIndexedDBはFireFoxがそういっているから試してみているだけであって、
FileSystemAPIだとWindowsから直接コピーとか出来るはずなので、
結果的にアーカイブの管理が楽にはなるから、そっちを使うかも。

いずれにしても今は試している段階だ。
何か情報あればよろしく。

371 :デフォルトの名無しさん:2016/08/22(月) 00:42:53.49 ID:utwn7AiT.net
自分はすごく考えた結果、こうする他がない、でもわからん。不自然な答えになる。そのやり方は不自然なやり方だからどこにも載ってないから教えてってときに、情報出し渋るなよ。
どう考えても自分の発想が間違ってる以外の結論出ないんだから。

>>370
しかしなんでパスをインデックスに出来ないの?
限界サイズは一番でかいか無限だよ。IndexedDBは。

372 :デフォルトの名無しさん:2016/08/22(月) 00:43:11.87 ID:m1LOPf7I.net
>>369
それも何の負担もないが、
元のURLもクエリを含まないからそのままでも全く負担無いんだよ。
だからその方法ではコードは楽にならない。

仮にFileSystemAPIを使ったとして、
Windowsから直接ファイルをアクセス出来れば、
アーカイブが要らなくなった時にエクスプローラから削除出来るでしょ。
直感的に一番簡単。

それを意味無くフラットなDBにしてしまったら、
そのアプリいちいち起動しないとあれこれ出来ないでしょ。
バグってて削除出来ないとかもあり得るわけでね。そういうこと。
他アプリとインタフェースが揃っているのは重要なんだよ。
仮にIndexedDBも結果的にWindowsファイルの階層として見える形で
objectStoreを置いてくれていれば、同様のことが期待出来るわけだし。

373 :デフォルトの名無しさん:2016/08/22(月) 00:49:08.43 ID:m1LOPf7I.net
>>371
出し渋るも糞もアーカイブだと言ってるだろ。
パスはインデックスにするよ。ただしフラットにはしない。
限界サイズはndexedDBよりも多分FileSystemAPIの方が上だ。

374 :デフォルトの名無しさん:2016/08/22(月) 00:56:03.75 ID:m1LOPf7I.net
IndexedDBの容量制限は実質1/10*HDDね。
https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria

多分FileSystemAPIには上限がない(HDDの上限だと信じている)

繰り返すが、今回は元々アーカイブ用途だからそもそもDBアクセスの必要はない。
(横断的クエリとか検索とかは全く必要ない)
ただ、機能的には上位互換だから動作に問題なければそれでもいい。それだけ。

375 :デフォルトの名無しさん:2016/08/22(月) 01:07:03.73 ID:utwn7AiT.net
>>372
は?消すのはエクスプローラーなの?

意味なくフラットなぁ。
十分に意味のあるフラットだと思うけど。
バグって削除できないから、だから最初の発想では毎回ストアを作って破棄します、なんて考え方だったの?あきれた。
upgradeはなんなのか。

dir /S/Bした結果だから余程見慣れてると思うけどね。
WindowsWindowsって気持ち悪いけど。
べつに、どのフォルダ以下、って、キーの先頭xxxxxx文字が指定のもの、なんだし、特に変わらんと思うんだけど、
お前の中で違うならそうなんだろう。

フラットに見えるものが、フラットではないと思うのがよくわからなすぎて悩むわ。
indexedDBには文字列しか保存できないと思ってんのかな。

フラットにはしない!って、じゃあどうやってWindowsってフォルダの構造保存してるんだろう。
って考えたら、
フラットなものに保存されてる事気づくと思うんだけど。

>>374
だから、実際のサイズ調べてこいよ。
クォータまでだよ。
それに、残念だけど、フォルダとして見られる物じゃないよ。

376 :デフォルトの名無しさん:2016/08/22(月) 01:09:42.35 ID:utwn7AiT.net
まさかディレクトリ掘るのに再起使ってるから、平たくする方法がわからんのかな。
そんなに階層階層言うなら、階層構造渡したらそのまんま保存してくれるラッパ作るか、
バイナリの保存はちょっと考えなきゃならんがブラウザ版nedbでも使えばいいのに。

377 :デフォルトの名無しさん:2016/08/22(月) 01:16:58.93 ID:bLWZhaRu.net
>>370
保証はされていないが、一般的な環境ではまず問題ない。
というかIDBも実際は永続性は保証されていない。
Fxだと保証されているのは非標準のオプションを指定した時のみで、
他のブラウザでも基本的に一時的なものでディスクが埋まった時は利用頻度の少ないものから削除される。
トランザクションだって完璧でない。実際はパフォーマンス向上のためにディスクの書き込み完了を待たない。

378 :デフォルトの名無しさん:2016/08/22(月) 01:19:31.86 ID:m1LOPf7I.net
>>375
> それに、残念だけど、フォルダとして見られる物じゃないよ。
そうか、これは残念だ。

だったらやっぱりFileSystemAPIかな。
削除機能は内部にも付けるけど、
エクスプローラでも追加/移動/削除出来た方がいいのは自明だろ。
他アプリとの連携もし易くなるし。

まあお前が色々勘違いしているのは分かるけど、
既に言っていることばかりだから読み返してくれ。

379 :デフォルトの名無しさん:2016/08/22(月) 01:25:17.05 ID:utwn7AiT.net
>>378
だから、FileSystemApiがだよ。
フォルダとしては見られないか、超掘り返さないと見れないよ。
更にいうと、エクスプローラでなんなりするべきものじゃない。

それはもう、Electronかなんかで作れ。な?

お前が勘違いしてるのは、多分indexedDBへの保存の方法だとの思うけど。
そのために必要な階層構造を保ったまま、indexdDBに十分入れれるからな。

380 :デフォルトの名無しさん:2016/08/22(月) 01:25:40.46 ID:utwn7AiT.net
まぁ、インスペクタでは表にしかならんだろうけど。

381 :デフォルトの名無しさん:2016/08/22(月) 01:30:27.67 ID:m1LOPf7I.net
>>377
了解。ありがとう。

アーカイブ用途なのでトランザクションに関しては問題ない。
再ダウンロードして保存すればいいだけだから。
機能は、Web上で削除されたファイルをまだ削除されていないように見せかけるもの。
それが永久だとアーカイブということになる。

CacheAPIは多分この用途に作られているから、
それが使えるのならそっちを使った方が色々すんなり行くのだろうね。
プロキシとして機能してくれるなら、いちいちObjectURLに張り替える必要もなくなるし。
全体として楽になる。

ただ永久保証無しなら、何らかの形で抽出機構が必要になる。
これがちと面倒か。
多分CacheAPIの区画を「永久」「一時」とユーザー側で指定出来れば一番良いのだけど、
無理だよね?

382 :デフォルトの名無しさん:2016/08/22(月) 01:33:03.22 ID:m1LOPf7I.net
>>379
JavaScriptオブジェクトそのまま突っ込めるって話だろ。
もう試したが、今回の用途にはメリットがないんだよ。

383 :デフォルトの名無しさん:2016/08/22(月) 01:34:46.91 ID:m1LOPf7I.net
>>379
> だから、FileSystemApiがだよ。
え、マジで?

384 :デフォルトの名無しさん:2016/08/22(月) 01:38:12.92 ID:utwn7AiT.net
>>382
そのままじゃなくて、書き加えて保存できるし、
その任意のプロパティをインデックスに出来るよ。

お前の言うフォルダ名も、そのままでも、セパレータで分割しても、両方でもインデックスとして保存できる。

このフォルダ以下、これと同じ階層のもの、ファイル、全部綺麗に管理できるんだけどね。

これをフラットだからダメ、って言うなら、
一つのオブジェクト入れるオブジェクトに好きなだけツリー構造こしらえれば良いのかもしれん()が。

ノータリンに説明した時間が無駄だったな。

385 :デフォルトの名無しさん:2016/08/22(月) 01:44:52.41 ID:m1LOPf7I.net
>>384
とりあえず384に書いていることは全部知っているぞ。
ただそんなことせずともURLそのままで保存すれば良いだけなんだよ。
サーバ側でそれなりに考えて階層化されているわけでね。

386 :デフォルトの名無しさん:2016/08/22(月) 01:53:36.82 ID:utwn7AiT.net
>>385
はぁ。そうですか。
それでidb程度が使えないというか、わけわからん仕様出してくるとは、「それなりに考えて」階層化してるものが、表型DBに落ちてりゃ最高に面白いけど、フォルダ()なんだろうな。
好きに悩んでバギーなもの作ればよろし。

387 :デフォルトの名無しさん:2016/08/22(月) 01:59:36.01 ID:utwn7AiT.net
ブラウザの枠越えてフォルダがどうとか言うなら普通にWindowsアプリ組めばいいんじゃないのかな。
ブラウザはブラウザでサンドボックスになってるから良いのに。

388 :デフォルトの名無しさん:2016/08/22(月) 02:02:44.31 ID:m1LOPf7I.net
>>386
いや何を勘違いしているのか知らんが、コードはもう動いているし今はテスト中だぞ。

まあそれはさておき、FileSystemAPIが異なるファイルシステムを使っているのは
確定ではないがどうやらそのようだ。
というかこれだとWeb屋は言葉を間違っている。

サンドボックス:その内部で何をやっても外部に影響はない
ブラックボックス:その内部がどうなっているか外部からは見えない

ブラウザストレージはサンドボックスである必要はあるが、
ブラックボックスである必要はない。というかFileSystemAPIならなおさら。
てかマジでブラックボックスならFileSystemAPIの存在価値無いよ。
これだとFireFoxの言うとおりだと言うことになる。

何で意味無くブラックボックス化してんだ?

389 :デフォルトの名無しさん:2016/08/22(月) 02:14:19.68 ID:utwn7AiT.net
>>388
サンドボックスだ、としか言ってないし、
ブラックボックスではない、とは言ってないからいいんじゃねーの?
動いててテストフェーズなのに未実装機能あるなんて面白いのか面白くないのかわからんな。

だから言ってんじゃん。
それゴミ。idbの方がはるかにマシ。
要はクロームアプリ同士で、ファイルが筒抜けにならんように隔離してみました、って感じ。

390 :デフォルトの名無しさん:2016/08/22(月) 02:22:51.64 ID:m1LOPf7I.net
>>389
いやFileSystemAPIと言うからにはエクスプローラで操作出来ないと駄目だろ。
機能としてはIndexedDBの方が上位互換なんだから、
独自ファイルシステムなら存在価値がない。

> 要はクロームアプリ同士で、ファイルが筒抜けにならんように隔離してみました
この必要あるの?
具体的に言えばアプリのシグネチャ?でも混ぜ込んであるって事?
ローカルストレージが共通なのが多少問題だったから仕切ったってわけか?

391 :デフォルトの名無しさん:2016/08/22(月) 02:50:07.77 ID:m1LOPf7I.net
あー、つかお前らがよく使う言葉思い出したわ。

IndexedDBでもFileSystemAPIでも、
内部データを「追加/移動/削除」する為の機能を自分で作るのは、
「エクスプローラーの再開発」(車輪の再開発)なんだよ。

Windows上のエクスプローラーが使えたらそれが一番良いだろ。
ドラッグアンドドロップやプレビューの機能は全部持っているし、バグもないし。
つか何故いちいち「マイエクスプローラー」を開発しなければならんのよ?

これが>>379の勘違いに対するお前らの言葉での答えね。
そしてChromeは「マイエクスプローラー」の開発を強制するわけだ。
アホかねと。

392 :デフォルトの名無しさん:2016/08/22(月) 07:34:32.01 ID:utwn7AiT.net
>>390
ブラウザってパソコン以外にも乗るじゃん。
その時、ファイルシステムなんて存在しないかもしれないよ。
って話。

>>390
例えば、なんかのアプリで保存したパスワードなんかを、別のアプリから覗き見出来ないようになってる。

>>391
世界中の人がWindowsのエクスプローラやマックのFinder使ってるから訳じゃないんだよw
内部データを追加、移動、削除するってのは、つきつめたらそれが機能なんだから。
お前が使いたいのがたまたまエクスプローラなだけだから、そう思うんだろうけど。
マイエクスプローラーではなくて、自分が使いやすいUI作れよ。
それか、どっかポート開けてwebDAVででも晒してローカルでマウントさせろ。

393 :デフォルトの名無しさん:2016/08/22(月) 10:56:09.85 ID:uzkoNVx4.net
どうしてこういう人は、ライブラリを作ろうとはしないんだろう。
ディレクトリ一覧を帰す関数、あるディレクトリのディレクトリとファイル一覧を帰す関数、ファイルを新規、取得、更新、削除する関数を作っときゃ、それらの下回りがindexedDBだろうがサーバ関数だろうが関係無く透過的に扱えんじゃねえの?
それこそ、内部実装無視してindexedDBに行ごとに入れようが、クソでかいオブジェクトとして入れようが、はたまたサーバに入れようが、ご希望の動きがすぐ書けると思うんだけど。

394 :デフォルトの名無しさん:2016/08/22(月) 21:30:14.52 ID:m1LOPf7I.net
すまぬ、>>358は間違い。
upgradeのときはe.target.transactionが最初から入っている。
昨日も確認したのだが、どうやら間違えたようだ。
これで修正出来たかは確認中。

これとは別に、createObjectStoreのoncompleteが少し早いタイミングで返ってくるらしく、
oncomplete直後にput等をせずに終了するとエラーになる。
これはupgradeのtransactionが並列出来ないということなので、
一旦closeして開きなおして並列性を高めようとしたが、失敗した。

395 :デフォルトの名無しさん:2016/08/22(月) 21:40:34.14 ID:m1LOPf7I.net
>>392
未来のストレージがどうなるかは別の話だ。
FileSystemAPIはオレオレエクスプローラの再開発をしなくて良いのが利点であって、
それがないのならゴミでしかない。
お前が色々再開発をするのは勝手だけど、大多数の人にとっては、
普段使っている物がそのまま使えるのが一番分かりやすいUIだ。

Webアプリ間での相互アクセスを禁止するのはいいとして、
OSからの透過アクセスを禁止する意味はない。
ブラウザアプリからは常にブラウザ経由になるのだから、
アクセス権限、unixで言う644とか755とかを管理するのが一番簡単。
何でそんな糞仕様にしたのか意味不明。

ていうかChromeではBlobをIndexedDBにいれれないのか。使えねえ。
IndexedDBで両対応という作戦は頓挫した。根本的に練り直しだ。
てかマジでこの辺統一しろよな。
> While Firefox supports blob storage for IndexedDB,
> Chrome currently does not (Chrome is still implementing support for blob storage in IndexedDB).
> If you are targeting Chrome for your app and you want to store blobs,
> the File System API and App Cache are your only choices.
> However, AppCache storage isn't locally mutable,
> and doesn't allow for fine-grained client-side management.
> https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Introduction

396 :デフォルトの名無しさん:2016/08/22(月) 21:41:45.37 ID:m1LOPf7I.net
>>393
それはお前が無能だからお前の周りも無能しかいないだけ。

397 :デフォルトの名無しさん:2016/08/23(火) 00:24:48.05 ID:ua608nki.net
>>395
なら、エクスプローラーで管理しろよもう。
文句ばっか言って鬱陶しいわ。
electronでざっくり作るか、いっそcsで書けば?Windows()だけでしか動かないクソアプリを。

>>396
お前の事言ってるの。
俺はライブラリ作ってるよ。
オフラインアプリ用のスクリプトも画像も、ServiceWorkerとindexedDBで全部賄ってるから、「出来るのに技術的な問題だと思いこんでカスだなこいつ」って思ってんじゃん。

398 :デフォルトの名無しさん:2016/08/23(火) 00:49:53.34 ID:fTj2N0cj.net
今のところはそのつもりだ。cscriptと併用する。
Unix使いならcron位自分で書けということでいい。
もちろん他にいい方法が見つかったら変更する。

長期的運用を考えた場合、
ブラウザがクラッシュした時に破損する可能性がある場所はアーカイブとしては使えない。
また他アーカイバも既にあるので、それらとの相互運用を考えた場合も、
生ファイルシステムでないと駄目だ。

格好は悪いがこれが運用上は一番マシだ。
まあもうちょっと考えるが。

399 :デフォルトの名無しさん:2016/08/23(火) 01:04:54.52 ID:ua608nki.net
>>398
生ファイルシステムほど不安定な場所もないと思うけど。
サーバ側mongo,クライアント側nedbで適当に同期すれば?

400 :デフォルトの名無しさん:2016/08/23(火) 01:17:30.72 ID:fTj2N0cj.net
インストールが必要な時点でアウト。
というかお前は無駄にシステムをでかくする病気にかかっていると思うぞ。

401 :デフォルトの名無しさん:2016/08/23(火) 01:47:37.85 ID:ua608nki.net
>>400
はぁ。
思い描くものがあれば説明してみ。
大体な、それは不可能と応えていくわ。

402 :デフォルトの名無しさん:2016/08/23(火) 08:05:29.74 ID:ZcVGgUHo.net
システムをでかくする病気って言われても、要件が見えなさすぎるんだししゃーなくない?
サーバ側ではデータベースに入ってんだろ?じゃあリプレイスすりゃいいじゃん。
むしろ、サーバのデータベースは何者かわからん。
アーカイブってなんだそりゃ。何のどんなアーカイブかわからんし、さらにそれが階層構造とか、階層構造はデータベースに入れられない()とか不思議発言過ぎるんじゃねえか?

403 :デフォルトの名無しさん:2016/08/23(火) 08:18:51.01 ID:exF8NocQ.net
>>395
お前一体何時の記事見てんだよ。
MDNに頼るにしても最低でもLast updatedくらい見ろ。
もう何年も前にサポートされてるわ。
この手の情報は半年経つともう古い。
そして最終的にはブラウザのissuesやcommitsやソースコードを読まないと確かなことは言えない。
独自実装・勝手解釈・消費期限切れの塊であるMDNに1から10まで頼るのは危険。

404 :デフォルトの名無しさん:2016/08/23(火) 11:20:47.03 ID:ZcVGgUHo.net
というかね、ミニマムなコード片書いてくれればいいと思うんだが。
書いて、あ、Blob入るじゃんって気づくから。
入らなければbase64なりにして突っ込みゃ良いだけだし。
そのまんま、自分のライブラリになると思うけど。

405 :デフォルトの名無しさん:2016/08/23(火) 11:32:18.33 ID:ZcVGgUHo.net
ファイルが保存できればそれでいい、って言う割には、階層が、とか、自分の実装に凝り固まり過ぎだろ。

ただのrdbでもindexedDBでも
フルパス|[パス,,]|ファイル名|拡張子|中身|更新日などの情報|
って形で保存すりゃなんとでもなるだろ、常識的に考えて。
パスは、
file://
file://home
file://home/xxxxx
file://home/xxxxx/yyyyy
の配列で持っといて。
あるパス以下の物→パスで絞れば一撃
あるファイル→ファイル名で一撃
あるパスのあるファイル名→フルパスで一撃
でカーソル取れんじゃん。
あとはよしなに処理すりゃいいんじゃねえの?その為のトランザクションなんだし。
ディレクトリごとにストア分けて、ディレクトリを削除するのに、トランザクション何個も張る羽目になるっしょ。

406 :デフォルトの名無しさん:2016/08/23(火) 21:49:08.63 ID:fTj2N0cj.net
>>403
おおありがとう。Blobサポート済みか。
となるとボツではなくなった。
記事は古いとは思ったが、政治的案件は時間では解決しないから、どうせ駄目だと思っていた。

>>401
いやcscript併用案はもう既に動いている。
考え方は簡単で、ブラウザで出来ないのはローカルファイルのサポートだから、
それをcscriptにやらせるということ。
とはいえ読み出しには手動で指定が必要だから、それとどっちがマシかということになる。

俺が勘違いしていたFileSystemAPIは
・ブラウザ側で「あるディレクトリ」を指定。これはブラウザ側で手動でしか出来ない。
(指定方法の取り扱いは「ダウンロード」フォルダと同じ)
・そのディレクトリ以下は読み書き自由。
だった。
もちろん生ファイルシステムでOS側からは直接読み書き変更可能。
ブラウザ側からのアクセスはWebアプリ毎にアクセス権が設定されている。

というかこれ以外のFileSystemAPIなんてゴミだろ。
あの糞仕様なら誰も使わない。使う意味無いし。

JavaScript界隈で思うのは、「使ってない奴」「三流プログラマ」が仕様を策定しているということ。
だから「使えない」「使いにくい」仕様が溢れかえっている。FileSystemAPIがゴミなのもこのため。
従来は仕様策定に関われる時点でそれなりの実力者しかいないからこういう事はなかったが、
良くも悪しくもJavaScriptはWebだって事だね。

>>405
つ薬

407 :デフォルトの名無しさん:2016/08/23(火) 22:55:54.15 ID:exF8NocQ.net
exeみたいな実行形式やそのOSで特別な意味を表すシステムファイル等として書き出されちゃまずいので実態は偽装される様になってる。
ゴミというか、実験的で気まぐれな機能。もう何年も更新されていない。
誰も使わない、でもブラウザ内部では使われている。別に広く使われることを期待されていない。
IndexedDBやCacheDBの存在で意義をなくしつつある。
柔軟に検索したいなら前者、そうでないのなら後者をどうぞ。

君が望むようなファイルシステムAPIなどがなかなか策定されないのは幾つか理由がある。
でも技術的要因は取り除かれてきた(例えばPermissions API、Web App Manifest)ので、
あとは需要と雛形とブラウザベンダーのやる気次第。

とはいえ今はCSSや他の比較的低レベルなAPIが盛り上がっていて注力してるから後回しだろう。
W3CのMLを見ても「いくつか議論の余地がある」レベルの関心だ。
今はまだアイディアを貯めている段階だろう。

408 :デフォルトの名無しさん:2016/08/23(火) 23:01:47.75 ID:exF8NocQ.net
あーでもやっぱりそろそろ動き出すかもな。
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_6Euwqv366U
これが落ち着けば足回りが揃うから。

409 :デフォルトの名無しさん:2016/08/23(火) 23:50:21.90 ID:fTj2N0cj.net
>>407
> exeみたいな実行形式
Webアプリから起動出来なければこれは問題無いだろ。
> OSで特別な意味を表すシステムファイル等
要するにシンボリックリンク等で全部筒抜けになる場合だろ。
これも結局Webアプリ側はブラウザを通しての作成しか出来ないので、それを止めればいいだけ。

OS側からシンボリックリンクを貼ったり、exeを置くのは自由でいい。
Webアプリ側でexeを起動出来ず、シンボリックリンク等を作成出来なければいいだけ。
つまりファイルは「データ」としてしか扱えないという、実装するにも至極簡単な制限でしかない。
FileSystemAPIははっきり言って使う気がない仕様を策定してる。だったら策定しない方がマシ。
まあ策定してから捨てるというのがJavaScript流ではあるようだが。

> IndexedDBやCacheDBの存在で意義をなくしつつある。
結局の所、「勝手に削除される可能性がある」時点でアーカイブとしては使えない。
見たところここを保証する気はなさそうなので、
今回俺がこれらをメインに据えることは出来ないし、
どのみち「削除されない」ストレージも必要になると思う。

410 :デフォルトの名無しさん:2016/08/23(火) 23:50:56.04 ID:fTj2N0cj.net
> Both Microsoft Edge and Mozilla Firefox are implementing the subsets documented in "File and Directory Entries API" for compatibility with Chrome in supporting Directory Upload.
正直これさっさと実装しろというのはある。
ディレクトリ指定出来ればUIが全然簡単になるから。

あとIndexedDBも全然こなれてない。
createObjectStore.oncompleteのタイミングがおかしいのは既に言ったが、(>>394)
それとは別にキューの実装もおかしい。
トランザクションがロールバック単位なので、
当初は各リクエストそのままで500トランザクションとか送ったら
「多すぎてキューに入りきりません」とエラーになった。
普通はキューは動的に確保すればいいので、500程度でオーバーフローとかアホかと思ったが、
そんなことを言っていても仕方ないので数珠繋ぎ方式に変更、トランザクションは数個に絞った。
ただそれでもごく偶に、しかも一つ目のトランザクションで同じエラーがでる。
つまり、IndexedDBのキューの実装はバグってる。
なおChrome50。Vistaなのでこれ以上更新出来ないし。

結局の所、大多数が使っている機能じゃないとバグ報告が上がってなくてバグが残っている。
IndexedDBもまだその程度だよ。安心しては使えない。
ただ従来方式の「ダウンロードリンク」を使うにしても、
1日10万ダウンロードとかになるので大丈夫なのか?という疑問はあるが、これも試すしかない。
(ダウンロードは履歴が残るようになっているので、手動ではあり得ないほどの数になると、
履歴がオーバフローするバグが残っているのではないかと恐れている。
これも知ってたら教えて欲しいが。)

411 :デフォルトの名無しさん:2016/08/24(水) 00:44:52.82 ID:dKh15413.net
>>406
お前のコードこそ、特定のプラットフォームか外出てるじゃん。
どう使いにくいのかが分かれば良いんだが。
もう老人であたらしいこと覚えられないならご愁傷様。

412 :デフォルトの名無しさん:2016/08/24(水) 00:48:32.19 ID:1m5/CfUP.net
>>410
トランザクションがROLLBACK単位とか言うか
適宜コミットして、setTimeoutで遅延させてつかえよ。
ボンクラすぎるだろ。

タイミングも合ってるよ。

脳みそ腐ってないならば、ぜんコード上げてみろよ。見てやるから。

413 :デフォルトの名無しさん:2016/08/24(水) 00:52:22.97 ID:7vNot/FK.net
IndexedDBが小慣れていないと言われてるのは周知の事実。
が、機能は揃っているので上で言われてるように
大抵皆ライブラリを書いたり、使ったりして問題なく過ごしている。

君のここまでの書き込みは全然建設的じゃないし、
ほんとにバグがあるのか、もしくは君の方がが小慣れていないのかが分からない。
結果、ただの愚痴にしか聞こえずそれに対して何も言えることはない。
せめて再現するための最低限のコードを載せてくれ。

あと10万ダウンロードはやめとけ。ZIPなどに圧縮すればいい。
もしくはもう一般WebAPIだけで作るの諦めろ。
一般公開するかは知らんが、それだけの機能なら
拡張機能もしくはブラウザアプリにしてインストール必須にしても構わないだろう。

414 :デフォルトの名無しさん:2016/08/24(水) 02:09:31.50 ID:fG60fvYz.net
>>413
> ほんとにバグがあるのか、もしくは君の方がが小慣れていないのかが分からない。
これはその通り。当初の>>358は間違いだったからね。
ただ仕様は大体理解したので、多分>>394>>410はバグだ。

とはいえ切り分けはしない。
最新版が使えない状況で切り分けて報告する意味はないので無駄だから。
(最新版では既に治っているかもしれない)
俺については「バグがある」という認識で使うか、使うのを止めるかでしかない。
つまり他の方法も試して一番マシな方法を使うだけ。
ちなみにchromiumに対してバグ報告もしたことあるし、受け付けられてもいるよ。
ただそれをやるにしてもここでやる意味はない。直接報告すればいいだけ。

コードはここには上げない。
コピペすればいいだけのコードすら協力してくれないお前らに対して期待はしていないし、(>>270,279)
話を聞く限りお前らの腕前/デバッグ出来る範囲を完全に超えている。
コードを上げてもお前らでは何も出来ないよ。
いずれにしても既に公開はしているから、勝手に探せばいい。

100kダウンロードはその話だと試したわけではないんだろ?だったら俺が試すだけだよ。
ZIP化してもいいが取り扱いが面倒になるだけだから、いければ生ファイルで行く。

> 拡張機能もしくはブラウザアプリにしてインストール必須にしても構わないだろう。
これは何が違うんだ?調べた限りでは大差ないようだったが、違うのか?
なお今回欲しい機能は以下。
・ローカルファイルからのユーザ指定無しでの読み込み
・ダウンロード時のフォルダ指定(階層化したフォルダに対してのダウンロード先指定)
これらが出来るのなら乗り換えを検討する。
ちなみに今のところGreaseMonkeyで不自由していない。
ただ、GM専用機能も使ってないので、乗り換えは出来る。

415 :デフォルトの名無しさん:2016/08/24(水) 02:10:28.07 ID:fG60fvYz.net
> 君のここまでの書き込みは全然建設的じゃないし、(中略)
> 結果、ただの愚痴にしか聞こえずそれに対して何も言えることはない。
上記の通り、俺は相談以上の期待をお前らに対してはしていない。
だから気に入らなければレスくれなくていい。
(上記経験により俺もそういう距離感で行くことにしたから)
そちらも分かるように、どこまでの情報があれば何を回答出来るかはこちらも分かっている。
その上で書いているのだから、それについては無理という件については無視でいい。
馬鹿共は置き去りにしないとスレのレベルが上がらない。

その上でバグ確認に協力してくれるというのなら、
それは申し訳ないが今回はそこに踏み込む気はない。
理由は上記どおり、最新版でないと意味無いから。
そちらが既にバグに当たらない記述のライブラリなりを持っているのならそれで問題ないわけだし。

心配せずともchromeなんてバグだらけだぞ。
こなれていないところに踏み込んだらすぐに遭遇する。
それはそちらも知っていると思うが。

君らは気に入らないかもしれないが、俺は情報をくれた奴には感謝している。
ただ君らが「持ちつ持たれつ」という感覚を持ち合わせていないことも学習したから、
君らに大して期待もしていない。だから再度言うが、気に入らなければ無視でいい。
(というかこれまでの俺が甘かっただけで、本来は君らのスタンスの方がここには向いている)

416 :デフォルトの名無しさん:2016/08/24(水) 02:47:00.24 ID:fG60fvYz.net
>>413
> IndexedDBが小慣れていないと言われてるのは周知の事実。
ちなみに俺はJavaScript屋ではないから、
こういう、「周知の事実」ってのは知らない情報だ。
だから君にとっては大したことなくても、俺にとっては助かっている。

その「周知の事実」にアクセス出来る人に対してこちらから提供出来る情報はほぼ無い。
せいぜい遭遇した事実/外部目線で見た感想を垂れ流すことくらいだ。
で、これを既にやっているわけだが、
結果、愚痴にしか見えないというのなら、それはそれで仕方ない。
残念ながら、こちらが「情報交換」として提供出来るのはこの程度でしかないんだよ。
何が君らにとって有意義な情報かもこちらには分からない。
だからとりあえず垂れ流すのみ。

417 :デフォルトの名無しさん:2016/08/24(水) 07:24:26.62 ID:dKh15413.net
何様かわからんな。
出せる情報もなく、教えてくれって虫が良すぎるだろ。
Qiitaにでも行ってくれば?

418 :デフォルトの名無しさん:2016/08/24(水) 08:19:51.08 ID:u65p5RKL.net
俺はindexedDBを商用製品に普通に使ってる(しかも、ローカルへのキャッシュとして)から、ぶっちゃけどんなドヤされても、こいつの書いた実装が悪いんだろうなとしか思えん。
トランザクションで500件を超えるって、そんなデカいアトミックな操作が思いつかんレベル。
ファイルの取得であれば、保存できればそれでワントランザクションだろ。
関数越えてトランザクション持って回って、どっかで非同期な呼び出しがあってカーソル見失った瞬間にトランザクション失敗してるんじゃねえの?
とかそんな感想。
ある一定バージョンのファイルセットが取得できるまでをトランザクションと見なすなら、バージョンごとに仮データとして保存するトランザクションと、
古いセットを削除して、仮データを有効データに更新するトランザクションの二本で充分でしょ。

なんで、自分より相手方の方が馬鹿に違いない、と思えるのかわからん。
俺もコミッタだけど、その発想でプルリク投げた事は無いわ。

419 :デフォルトの名無しさん:2016/08/24(水) 08:36:10.31 ID:u65p5RKL.net
ダウンロードリンク、の代わりにindexedDB使う発想がわからん。
何がどこにどうダウンロードされるんだろう。
それはローカルに持ってたらどう便利なんだろう≒ローカルにあれば二度と押さないボタンなんだろうか?

なんか(アーカイブってのが何のアーカイブかはわからんが)ウェブから取得させるときに、二回目以降はそのクライアントのデータを使わせて、ダウンロードしたフリすれば良いの?

サービスワーカーで書いちゃだめなの?その処理。

420 :デフォルトの名無しさん:2016/08/24(水) 08:45:06.93 ID:7vNot/FK.net
>>416
おいおい、はぶてんなってw
建設的でないどころではなくなってるぞ。
これだけ皆が比較的長文で沢山レスして構ってくれてるんだから
あとは君の態度次第で強力な仲間となるだろうよ。

答えをもらう代わりに問題をきちんと問題として認識できる形であげれば
それで十分「交換」になる。
あとDLに関しては500くらいで試してみて。
確かpermissionの取り方によるのか知らんが50か100毎に確認出たはずだから。
ファイルごとにオーバーヘッドもかかるだろうしアーカイブ化した方がいい。

421 :デフォルトの名無しさん:2016/08/25(木) 00:05:19.06 ID:eAOsu6G6.net
>>420
1日500DLなら現在味見中で、既に2週間ほど動作して問題は発生していない。
確認は一度も出ていない。ただ、出る環境の場合はこれは使えないのも確かだ。
まあ500DLなら人力でも十分あり得る範囲、さすがにこれでバグ遭遇はない。

ローレベルでのファイルのオーバーヘッドはない。
そもそも自動アーカイブはほぼ書き込みばかりだから投げ捨てだ。
また、データの大半はjpg等の圧縮済みファイルだ。
(個数としてはテキストの方が多いがjpg一枚でおつりが来る)
だからzipというよりtarなんだが、それもしない方がいいだろうという読みだ。
まあここら辺はこちらで試す。

> あとは君の態度次第で強力な仲間となるだろうよ。
セミコロンの位置でドヤア()、文法でドヤア()する奴がいくら居たって邪魔なだけ。
俺について助けになるのは、プログラミング上級者(10k行のコードを平気でメンテ出来る)か、
俺以上にJavaScriptの仕様に詳しい連中だけだ。

後者については俺がJavaScripterではないのでここの連中でも当てはまるケースも多い。
それが俺がここにいる理由。
前者について当てはまるのはここには居ても数人だ。
だから内部構成についての指摘は大半が俺から見ればデタラメに過ぎなく、ウザイだけ。
よって、そっちに流れないように上位アーキテクチャの話に絞っているわけでね。

422 :デフォルトの名無しさん:2016/08/25(木) 07:26:33.09 ID:kFTapBTb.net
なーんだ
自分の手足となってくれる素直で言うこと聞いて優秀な部下もしくは奴隷がフリーで欲しいってことだったのか

サイコパスにちょっとでも強力しようと思った俺がバカだったわ

423 :デフォルトの名無しさん:2016/08/25(木) 08:20:27.91 ID:99xpDjOR.net
それにどうindexedDB使うのか全然わからん。
圧縮済みデータはそれ以上圧縮かからないから、圧縮しない、は
圧縮済みデータが一つのときだけじゃない?
エントロピーが偏れば圧縮は効くんだから、いくつか混ぜるとちゃんと圧縮は効くと思うけど。
そういう意味ではtarでアーカイブした上で、積極的な圧縮はせずに、Webサーバのgzip任せていいんでないの?
無駄な作り込みはバグ生むよ。

正直、普通に職業マやってたら、そんなステップ数のメンテは逆にしない。
逆に、しないように、スクラッチの時点でちゃんと切り分ける。

別に上級者気取りでも気にはしないけど、どう考えてもアーキが浮かばん。
アーキ屋何してんの?

何か情報を出すと俺のすごいシステムがパクられそうで怖い、みたいに聞こえるけど、そういうのって大体みんな通り過ぎて、王道はなるほど王道なんだな、って「そうしないだけ」だから、
気にせんで良いんじゃないの?
ホントに凄いかも!と思ったら、先にアイディアだけどっかに書いとけばいいよ。

424 :デフォルトの名無しさん:2016/08/26(金) 18:32:39.75 ID:wJ1YpBkQ.net
ID:fTj2N0cj
ID:m1LOPf7I
ID:fG60fvYz
ここって他者を見下して優越感に浸る人が多いよな
>>1からしてそんな感じだったからなるべくしてなったのかもしれんが

425 :デフォルトの名無しさん:2016/08/26(金) 18:53:36.65 ID:4RusDDpB.net
もし本当に他者を見下してるように見えるんなら精神病院行ったほうが良い。
本当に見下してれば相手と会話したりしない。

426 :デフォルトの名無しさん:2016/08/26(金) 23:31:04.14 ID:LTYwvQxl.net
バカほど人を見くびるもんだよ。
そして見くびれるからバカで居られる。
会話するメリットなんかいくらでもあるよ。ぬいぐるみは反抗しない「から。
反抗反論されると言うことは、自分の発言は反抗反論される程度の意味があんだ、むしろ相手が理解できない馬鹿なんだ」と思うことすらでき、一人で気持ちよくなれる。

427 :デフォルトの名無しさん:2016/08/27(土) 05:01:58.71 ID:T1cpNbqY.net
反抗しないぬいぐるみなんてここには居ないが?
後半は今回で言うと間違いなく ID:eAOsu6G6 の方だな
早く気付けよ

428 :デフォルトの名無しさん:2016/08/27(土) 05:49:03.76 ID:eRYPSeFa.net

Slot
🍜🍜👻
💣💯🎴
💯🌸🍜
(LA: 0.55, 0.58, 0.53)


429 :デフォルトの名無しさん:2016/08/27(土) 09:23:29.57 ID:4zJIWaih.net
>>427
反抗するぬいぐるみが居るから、書きに来てるんだろ、って文書のつもりだったけど、眠くて誤字でわけわからん感じだな。すまん。

430 :デフォルトの名無しさん:2016/08/27(土) 21:50:54.70 ID:T1cpNbqY.net
よく分からんが反抗する側がバカにやり込められるのなら、
それはやり込められた側の方がもっと酷いんじゃないのか?

431 :デフォルトの名無しさん:2016/09/25(日) 17:50:33.44 ID:Fmi0n6Ll.net
Flashの仕組み全く知らないんだけどさ、Flashって高速再生出来るようにならないのかね?
以下知恵袋では「プレイヤーも自作」となっているので、
逆に言えばJavaScriptで高速プレイヤーを作成して入れ替えてしまえば可能なのか?
認証とかはさておき。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10160742165

具体的にはGyaoの動画を1.5-2倍速で再生したい。要求スペックは以下。
・個人的に使えればいい。つまりコマンド手打ちが必要でもいい。
・再生速度は固定でいい。つまり最初から1.5xか2xで固定、再生中の変更は必要ない。
・最悪バッファでもいい。つまり30分の動画なら15分バッファした後の2x再生でいい。
・ダウンロードすれば出来るのか?しかし面倒なので出来ればダイレクトで。

432 :デフォルトの名無しさん:2016/09/25(日) 19:27:04.48 ID:r4NaSC4t.net
スクリプトでURI解析→ネットワークに対応した外部プレーヤで再生

433 :デフォルトの名無しさん:2016/09/25(日) 21:06:19.30 ID:Fmi0n6Ll.net
確かにそんなに難しく考える必要はないのかもね。
で、試してみたんだが、今のところ駄目だ。

データ取得先は当然あっさり分かる。
それをGOMプレイヤーに食わせてみた。
曰く、「ストリーミングサーバーが見つかりません」

ただGOMプレーヤー自体も滅多に使わないから、使い方が間違っているかも。
URLもこれでいいのかは謎だし。
なおAlquadeLiteも試したが、こちらは起動するもののFlashPlayerがクラッシュして駄目だった。

まあ何かあればよろしく。

434 :デフォルトの名無しさん:2016/09/25(日) 23:14:29.89 ID:Fmi0n6Ll.net
結局「GYAO動画ダウンローダJava」を使って高速再生は出来た。
ただし事前DLが必要だが、10倍速くらいでDL出来るので問題はない。

ただ正直ちょっと複雑だ。
こんなに簡単に出来るのなら公式で用意してくれよというのと、
意外に高速再生も快適ではないのでやっぱり用意する意味もないのかとも。

いずれにしても情報をくれた人はありがとう。

435 :デフォルトの名無しさん:2016/10/16(日) 16:56:27.94 ID:u0ZoFejP.net
・「クライアントサイド」のJavaScriptでは、innerHTMLをエスケープ(サニタイズ)する必要ないのか?

サイトのJSON_APIがスクリプトタグを含む文字列を送ってきていて、
こちらのGreaseMonkeyスクリプトは今はそれをそのまま表示してしまっている。(見た目は消える)
これはXSS的に問題だと思っていたのだが、以下を見ると、またこちらでも試した限り、
divタグの中身等としてappendChild/insertBeforeする分には実行されないようだ。

> が!残念ながらこの場合はscriptは動きません。
> http://tech-blog.tsukaby.com/archives/894

とはいえ、見た目消えてしまうのでどのみち修正は必要なのだが、
XSSの脆弱性という意味での対策は必要ないということでいいのだろうか?

俺はJavaScriptの専門家ではない。
したがって情報は基本的に全てWebなのだが、例えば以下のように、

> 例えば、DOM Based XSSを発生させる典型的なコードの例として、
> 以下のようなinnerHTMLの使用があったとします。
> // ★★★脆弱なコードの例★★★
> var div = document.getElementById( "msg" );
> div.innerHTML = some_text; // 外部からコントロール可能な文字列
> http://www.atmarkit.co.jp/ait/articles/1312/17/news010_2.html

とあって、その後「ブラウザー上で」エスケープするなりcreateTextNodeをしているわけだが、
これって全くの間違いで、必要ないのだろうか?
(サーバーサイドならもちろん必要として、クライアントサイドなら問題なしでいいのか?
今のところ、筆者もこれらを混同しているように見える。
記事は2013/12と古いのだが、これ以降に仕様変更されたのか?
なお上記一つ目(動かないと書いている方)のブログは2015/04)

なお念のため再度言うが、「クライアントサイド」で「innerHTML」の場合。
「サーバーサイド」でもなく、「outerHTML」でもない。

436 :デフォルトの名無しさん:2016/10/17(月) 00:31:40.71 ID:B8wMv80N.net
>>435
script タグでなくとも イベントハンドラ( onxxxx = )で動作するコードを注入されたら危険だろう

437 :デフォルトの名無しさん:2016/10/17(月) 01:16:39.60 ID:XzUmA52N.net
>>436
ああ、確かにその通りだ。<img onload>とかね。
ではやはりエスケープしないといけないね。
なるほど、ありがとう。

438 :デフォルトの名無しさん:2016/10/18(火) 13:06:11.48 ID:GiAjO0tK.net
ぶっちゃけいかなる脆弱性があったとしても、お金が関わるようなサイトでなければ関係ない
例えばある種のURLで飛ばされた時にXSS脆弱性があったとしても、
それは悪意のあるサイトから遷移したユーザーの責任。
それにCookieが抜かれようと変な表示がされようと何か致命的な問題になることはない。
いたずらレベル。

439 :デフォルトの名無しさん:2016/10/18(火) 22:14:37.24 ID:8mVkPqez.net
それはその通りだし、神経質にやる気はない。
逆にそのためのブラウザの制限に辟易している状況だし。
とはいえ、JSON_APIの中身がtextなのかHTML文字列なのかは気にしておかないといけない。
その上で、どこまでやるかを各プロジェクト毎に決めればいいこと。

440 :デフォルトの名無しさん:2016/10/19(水) 08:20:38.16 ID:pQsxuliv.net
そういうとこを気にするのは愚か
CSPを使い、それが通るように書けば良いだけ

441 :デフォルトの名無しさん:2016/11/21(月) 01:56:59.51 ID:jF13U7nK.net
IndexedDBのスループットが全く出ないんだが、誰か高速実装サンプルコードを知らないか?
URLくれると有り難い。

こちらの実装では、スクレイプ結果の9000ファイルを書き込むのに15-20分かかっている。
全体の容量は、IndexedDB格納済みで20MB程度、tarファイルだと30MB弱といったところ。
キャッシュ済みの状態なら再スクレイプには2-3分しかかからない。
これを<a download=xxx>でtarファイルにするのには数秒しかかからないが、(最後のダウンロードに数秒)
IndexedDBに全て書き込むには15-20分かかる。
この場合はスクレイプと同時に内部的にtarファイルを作成しており、
大半は再スクレイプの時間なので比較としては不適だが、5-10倍程度遅い。(A)
なおtarファイルの展開には2-3分かかるので、これとの比較でも5-10倍程度遅い。(B)

現状、ファイルに落とす場合はスクレイプの方が明らかに遅いので全く問題ないのだが、
IDBに格納する場合はスクレイプよりも遅いのでそこで詰まる。
といっても2倍も遅くはなく、またスクレイプ側は通常は90%以上idle状態なので
現実的には問題は発生しないはずだが、それにしても遅すぎる。

トランザクション等の機能は所詮CPU時間なので、何をやってもここまで遅くはならない。
(chromeの実装が酷くても、また俺の実装が酷くても)
上記ファイル時間(B)でも5-10倍遅いのは何かおかしい。

とはいえ使い方が悪い可能性も多々ある訳なのだが、
とりあえず高速実装サンプルコードがあれば比較出来るので助かります。

実装/実験の詳細は、上記の通り、9000ファイルをIDBに格納、全体で20MB程度、
objectStoreは多めで150個程度、その中に30-150個くらいのファイルがそれぞれ格納される。
トランザクションはオブジェクトストア毎に纏めており、
実際のトランザクションは40-80個程度で、大半は平行可能。(仕様としては)
一つのトランザクション内には20個ずつputを入れている。
(トランザクション単位でのロールバックなので今回は20個くらいが適当かと思っている)
ただしいかんせん書き込んでくれない。
何かヒントあればよろしく。

442 :デフォルトの名無しさん:2016/11/21(月) 02:24:13.88 ID:xTCFhIWI.net
またお前か。
なぜそんな事をブラウザでやるか、それもindexedDBになぜ入れるかわからんが、
インデックス貼り過ぎではないか、
WebWorkerやServiceWorker使わずに表スレッドでやってないか
くらいかな。
スクレイプの方がはやい、DBの方が遅い、と言っても、同時に走るわけでは無いよ、ネイティブの機能でない限り。

443 :デフォルトの名無しさん:2016/11/21(月) 02:56:54.44 ID:jF13U7nK.net
いや、表スレッドでやっているぞ。

ただそれは実際には問題になっているようには見えないが。
もちろん同期APIは使ってない。
つまり当然非同期だし、表スレッドで待つことはない。

> 同時に走るわけでは無い
あまりにスループットが低いのが気になっているわけだが、
確かにこの意味では「詰まる」事はあり得ないのも事実だな。

> インデックス貼り過ぎではないか
こちらはインデックスは使っていない。
インデックス使わないと超遅いとかいうのも見かけたが、
(覚えでは)3-4年前の記事だったし、取り下げていたのであてにならないと見たが、使わないと駄目か?
こちらはキーパス無し、キージェネ無し。外部キーを自前で供給している。
(要するにlocalStorageの容量増加版として使用している。ただし非同期だからどうにも使いにくいが。)
> データベースを構築する
> キーパス キージェネレータ
> https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Using_IndexedDB

> なぜそんな事をブラウザでやるか
一番手軽だからだよ。ブラウズする時にはブラウザは必ず使う。
アーカイブ勝手に取れてれば楽でしょ。
別ソフト起動するのが面倒でない人はそうすればいい。

> indexedDB
ブラウザ側から「消せる」方が使い勝手がいいから。
なおファイルに落とす機能はもう完成済みで、サイトのミラーが勝手に構築出来るようになっている。
もちろん外部スクリプトでtarファイルを展開しなければならないが、これは仕様的に仕方ない。
IndexedDBはボロすぎて諦めていたんだが、微妙に使えそうになってきたので色気を出している。

というか俺はGreaseMonkeyだからね。サイトのスクリプトではないからあしからず。

444 :デフォルトの名無しさん:2016/11/21(月) 04:59:18.67 ID:+MgjqZsm.net
愚直に1つずつ保存しようとするから愚直なパフォーマンスしかでない。
DBには圧縮ファイル1つしか保存しない。
利用するときは解凍してメモリ上で1つずつ読み書きする。
最後に圧縮して保存する。これで問題ない。
もしくはキャッシュ用に設計されたCacheStorageを使う。

445 :デフォルトの名無しさん:2016/11/21(月) 08:17:47.88 ID:xTCFhIWI.net
>>443
だから、表スレッドでやるから遅いんよ。
同期APIでなくとも、常に一本しか走らん。

インデックス使わないと中身探すのに全舐めだよ。
もし、挿入でなくupdateしてるなら絶対に必要。これはライブラリとか使ってなくて手で書いてたら気づいてると思うけど。

アーカイブは普通、拡張書いてそこからDOM舐めて、http通信でサーバに送ったりindexedDBに保存したりファイルにしたりする。
グリモンのスクリプトでもあんま変わらん。

446 :デフォルトの名無しさん:2016/11/21(月) 15:43:00.92 ID:LVMdN4w/.net
とりあえず必要最小限のコードを全部提示しろ

447 :デフォルトの名無しさん:2016/11/21(月) 23:45:11.05 ID:jF13U7nK.net
すまん解決したかも。

詳細を投稿しようとしたが何故かNGワード規制なので細切れで試す。

448 :デフォルトの名無しさん:2016/11/21(月) 23:46:56.58 ID:jF13U7nK.net
俺はIDBTransaction.oncomplete内でdb.close()していたのだが、
以下ではIDBRequest.onsuccess内でやっており、
//nparashuram.com/IndexedDB/perf/#Transaction based on Write
それってありか?ということでMDNを確認した結果、MDNでもそうなので
https://developer.mozilla.org/ja/docs/Web/API/IDBDatabase/close
パッチして味見した結果、とりあえず倍くらいにはなった。

それでもまだ遅いが、今は安定して動く状態ではないので詳細は確認出来ない。
本修正して安定動作させ、まだ遅いようならもう一度投稿する。
ちなみにコード自体は上記上側と似たようなもの。ただしoncompleteを使っていた。

449 :デフォルトの名無しさん:2016/11/21(月) 23:47:37.28 ID:jF13U7nK.net
上記一つ目、httpが引っかかったようだ。脳内補完よろしく。

450 :デフォルトの名無しさん:2016/11/22(火) 01:12:38.73 ID:62WBcce4.net
>>448
あのさあ。
なんで強引にそうむりやり解決するのかわからん。
db.close使うことなんかほとんど無くねえか?
当たり前のようにonsuccessでトランザクションcommitするだけじゃねえの?

ずーっと偉そうだけど、脳筋が知恵の輪を強引にバラしてドヤ顔してるように見えて仕方ない。
ラグビー部員かゴリラレベルだよ、それ。

451 :デフォルトの名無しさん:2016/11/22(火) 23:13:11.58 ID:bRc12BV/.net
oncomplete->onsuccessについては失敗した。
これは積み込みが早くなる(見た目終わったように見える)だけであって、
スループットは変わってない。
db.open->db.close間の時間を計測していたので間違えた。

意味としては並行トランザクションの数を増やせば同じだし、実際そんな感じだ。
onsuccessでやると他情報のライフタイムがずれるので、話が面倒になっただけだった。

452 :デフォルトの名無しさん:2016/11/22(火) 23:23:12.59 ID:bRc12BV/.net
>>444
いや愚直なパフォーマンスでいいんだが、それすら出てないから問題視しているわけで。
ファイルと等速かやや遅いくらいなら十分なんだが。

圧縮展開を自前でやるのはさすがに面倒だ。
というかそれが常に成り立つならその機能ごと組み込んでおけという話だし、
実際そうなっている感触だ。
だからバグ対策でなければ自前でわざわざやる意味はないはず。

IndexedDBに関しては、基本的には「キー」となるものを「全体を一覧」出来る場所に保存して、
「本体」への参照をそれに持たせればよいだけだから、
ちゃんと実装してあれば大型ファイルへのアクセスはほぼファイルと等速になる。
だからFireFoxがFileSystemAPIを実装しない理由も妥当なのだが、
全然そうなってないからあれ?ってことで。(まだchromeでしか試してないが)
キャッシュ用に設計されている場合も
大型ファイル本体へのアクセス速度は上記の通り大して変わらないはず。
ただIndexedDBのようなインデックス検索が必要ないからその分速いが、
今はそこが見えるほどの状況になっていない。

ちなみに後述するが読み出しは速い。
(絶対的に速いかは未確認だが、書き込みと比べて50倍速い)

453 :デフォルトの名無しさん:2016/11/22(火) 23:24:53.24 ID:bRc12BV/.net
>>445
いやIndexedDBは基本的に別スレッドで実行される。
いちいち "in a separate thread" って書いてあるだろ。
俺は使ったこと無いが多分Nodeと同じ。
> https://developer.mozilla.org/ja/docs/Web/API/IDBObjectStore

ちなみにプロファイラーで確認したが、表スレッドは完全に遊んでいる。
60秒間で100ms程度動いていて、他はアイドル。
OS上のCPUメーターでも遊んでいるし、いずれにしてもCPUがらみで引っかかっている感じではない。
ただ、I/Oで引っかかるなら普通のファイルと同速になるはずなのだが、これがないから不思議に思っている。

> インデックス使わないと中身探すのに全舐めだよ。
> もし、挿入でなくupdateしてるなら絶対に必要。これはライブラリとか使ってなくて手で書いてたら気づいてると思うけど。
これはないよ。
普通にIndexedDBを実装する場合、外部キーもインデックスとして実装するでしょ。
今は更地(データベースそのものの構築、onupgradeneeded でバージョン1)から始めて9000ファイル書いている。
全舐めの問題なら1000個目のファイルと9000個目のファイルで9倍速度が落ちるはずだけど、それは全くない。
先にも言ったがインデックス検索はCPU時間(usオーダー)の話だ。
実際にそこも遅いのかも知れないが、今はそこが遅くても見えないほど他が遅い。

なおリードと勘違いしているのなら、今問題になっているのはライトだけ。
後述するが、リードはとりあえず十分な速度が出ている。
ちなみにIDBCursor.update()は使っていない。俺が使っているのはIDBObjectStore.put()。

454 :デフォルトの名無しさん:2016/11/22(火) 23:34:52.08 ID:bRc12BV/.net
一応パラメータ振ってみたが、
トランザクションの数を絞る(40->2)と目に見えて遅くなるので、並列はしているっぽい。
ただし増やしても速度は上がらない。
一つのトランザクション内のput数を増やしても明確な速度変化は見られない。(20->20-200)

問題点を整理すると、
・I/O律速ならファイルと同等程度になるはずだが、5-10倍遅い。(ライトだけ)
・CPU律速ではないように見える。CPUは空きまくり、スレッドもほぼ全てアイドル時間。
で、何が引っかかってこんなに遅いの?という話。
ちなみに読み出しは十分速く、IndexedDBの中身を丸ごとtarファイルにして出力するのに10秒程度。
格納に20分かかるのに、読み出しには10秒しかかからない。
(読み出しに10秒=中身を読みだしてtarファイルをblobとして作成するまでに10秒、
その後ダウンロードする時にさらに10秒かかる)
このtarファイルを7-Zipで更地に展開するには25秒。
cygwinで既にあるファイルシステムに上書き展開するのには2-3分かかった。(これが前の話)
格納だけ異常に遅いんだが、これって何?
単純比較するとリードと比べてライトが45-120倍遅い。

ただまあwriteが遅いのは事実のようだが、ここにあるように50k records for 10 sec ならいいんだが。
ttp://stackoverflow.com/questions/22577199/indexeddb-access-speed-and-efficiency

記事は古いがここ見る限り駄目なことはやってなさそう。
ttp://blog.nparashuram.com/2013/04/indexeddb-performance-comparisons-part-2.html

既に書いたとおり、コードはここと似たようなものだが、oncompleteを使っている。
ttp://nparashuram.com/IndexedDB/perf/#Transaction based on Write

とはいえライトだけ50倍遅いのは俺の使い方に問題があるのだろう。
実装が如何にボロくてもここまでにはならないし。
というわけで高速書き込みのサンプルコードがあればURLよろしく。

455 :デフォルトの名無しさん:2016/11/23(水) 00:39:24.04 ID:Bkme+Kby.net
もう出来てる、だがなんだか知らんが、それ捨てたほうが良いとおもうわ。
普通はこう言うのオフラインモード持ったプロキシとして作る。

456 :デフォルトの名無しさん:2016/11/23(水) 23:07:06.62 ID:V62ycJbx.net
とりあえず自力で辿り着けそうな雰囲気になってきた。
速いコードを見つけた、というかMDNのそのままをコピペしてコンソールで試したら十分速かった。
確実にこちらのコードに何か原因があるのだろう。
もし調べてくれてたらありがとう。

457 :デフォルトの名無しさん:2016/11/24(木) 15:10:21.36 ID:Mx4OpUDM.net
この白痴
IDBを使うな、使うにしてもそう使うなと言われてるのに聞かないんだもんな
救いようがない

458 :デフォルトの名無しさん:2016/11/24(木) 16:54:40.99 ID:HdRBGkCM.net
なんともならんよなぁ。
何故クローム拡張を作らんか(jsで書けるし、妥当な保存方法だし、クロスドメインで苦労しなくても良いし、もし配布を気にしてるならzipでも蒔ける)
色んな疑問が湧く。

要は、ロスカット出来ない類の奴なんだと思うよ。
今まで掛けた工数が惜しいとか、自分が未熟だと認めるのが悔しい、とか、
自分は一番良い方法を考えてて、その中で「ちょっとだけドキュメントが未熟だから」実現方法が分からない事を聞いてるだけなのになんだこいつら、とか。
ベンチャーか中小企業の社長に居そうな奴。
5年目か10年目に破産する類の。

459 :デフォルトの名無しさん:2016/11/25(金) 00:21:37.68 ID:9S7zID8/.net
こちらは解決しつつある。今はテスト中だ。前と同様にとちっているかもしれないが。
とはいえ、俺はお前らが何でそこまで自信過剰なのかさっぱり分からない。

5-10年目に破産したベンチャーの社長を笑えるのは、
ベンチャーを起こして10年以上持たせた奴だけだぞ。
お前らがそうだとは到底思えない。
そんなんだからゆとりは意識高い系()とか言われるんだよ。
意識高いだけで中身がないからウザイだけ。
まあお前らに付ける薬もないのも事実だが。
俺に付ける薬もないのと同様にね。

お前ら、OSSに参加もしてないだろ。
よくもまあそれで、としか思えないけどね。

460 :デフォルトの名無しさん:2016/11/25(金) 00:52:34.50 ID:SsHeBd9H.net
>>459
メンテナしてるけどそれが何か、って話な位で、得意になるもんでも無いんじゃ?
参加とやらの程度にもよるけど、ある程度やってりゃ、プルリクくらい普通に出せるだろ。
コミッタって関わるにあたって特別な事なんもしてないと思うけど。
リポジトリ晒せと言われたら色んなものが傷つくからやらんが。

「お前らがそうとは到底思えない」
「してないだろ」
「よくもまあそれで」
ってまぁ意識たけえなぁ。
ベンチャー起こして10年も持たさんで良いだろ。
まともな会社でそれなりに勤めて、何度か転職して、それなりの立場にいる方が余程視野が広がるよ。
少なくとも金の算段を必要以上にせんで良いからな。

大→中堅→ベンチャー→大と転職して色んな良いところ悪いところ見てきたからわかるが、お前は悪いところの総和みたいな姿しとるよ。

461 :デフォルトの名無しさん:2016/11/25(金) 01:07:59.74 ID:bE83eHTG.net
一人が自信満々なのを否定するのと大多数が自信満々なのを否定するのは意味が違うからな

462 :デフォルトの名無しさん:2016/11/25(金) 01:21:08.20 ID:9S7zID8/.net
>>460
お前がそれならそれでいいよとしか言いようがない。
それがWeb系といわれる所以だろうし。
別に俺はお前に評価される必要なんてないし。

OSS云々ってのは、明らかにお前らは距離感がおかしいからだ。
OSSやってる連中は、限られたリソース(時間と金)の中でやりくりしている。
各自が今現在の状況で最大の効果が出るように考えている。
もちろん制約条件がそれぞれ異なるので、
君にとっての今の最適解が俺にとっての今の最適解でないこともよくある。逆も然り。
だけどそれはそういうものだから、いちいち文句は言わないし、言われない。
文句があるならお前がやれ、方針が違うならフォークしろ、の世界であるし。

だからお前らみたいな「俺の提案が神だからそれ以外は認めない」はないんだよ。
君は参加しているつもりになっているだけで、実際は観戦しているだけだよ。
参戦していない。

463 :デフォルトの名無しさん:2016/11/25(金) 01:22:21.94 ID:9S7zID8/.net
ただまあそれ以前に俺はお前らの提案がいいとも思わないけどね。
いちいち反論した方がいいのか?ならば言ってみてもいいが、
余りこんなのをやってもお互いに意味はないんだよ。
どうにもお前らはこういうのが好きなようだが。

>>458
CacheStorageはhttps縛りだから使えない。
クローム拡張にしない理由は、FireFoxもサポート対象だから。
並行して2つのソースを管理するほどリソースはない。GreaseMonkeyなら一つのソースで済む。
ここら辺は要するに楽な方をとっているだけ。
クロスドメインについてはGreaseMonkeyは独自拡張を持っていてスルー出来る。
配布なら苦労してない。
GreaseMonkey導入後の環境ならuser.jsリンクをクリックすればインストールされる。
zipすら要らない。リンク一つで済む。
掛けた工数云々は関係ない。
未来の工数も踏まえた上で、今現在の最善手を選んでいるだけ。
これは俺以外のOSSに関わる連中全員そのはずだが。
上記の通り、今現在何も問題ないし、移行のメリットもないのにするわけないだろ。
IndexedDBと同様、chrome拡張にもどんな落とし穴があるかも分からないわけだし。

これで満足か?
何でお前らがこんな点ばかりににこだわるのか俺はよく分からないが。

464 :デフォルトの名無しさん:2016/11/25(金) 08:31:00.71 ID:QZ3DaKSR.net
>>462
評価される必要はないのに、相手を下げて自分を高めようとえらく必死だな。

限られたリソースは現実であって、目指すべきものはそのリソースに縛られたものにすべきじゃない。
俺には手一杯だからとか、この部分俺あんまり強くないから、とかは、放置するんじゃなくて、明言する。
どんどんマサカリ投げて、どんどんプルリク投げて欲しくて、画像貼らせてほしい。
誰かのリソースが足りないのなら、そう書いて、他の誰かのリソースの援助を求めるべきなんよ。
リソースが足りてないから制約条件になります、はおかしいし、ここまで物言いがついたら、最適条件がなぜ最適条件なのか、くらいからもう一回ゆっくり考えるべき。
ソクラテスのいじめまがいの問答をもってでもやるべき。

「俺の提案が神だからそれ以外は認めない」?
俺はそんな事は言ってないが。
むしろ、お前がずーっと言ってる事じゃねえの?

>>463
httpsなんかなんとでもなるだろ。letsencryptもあるし、イントラなら証明書配れば良い。
並行して管理するのは画面周りで良いので、実際の管理工数は1.3倍程度になる。きっちり画面とロジックの設計をしてれば。
なら、むしろグリモン縛りなら、グリモンでプロキシ書いたらいかんのか?
あと、データは普通に、indexedDB使わんと、ファイルに書けんじゃん。
そのアーカイブとやらをBase64にして、前後にvar tmp=""つけてjsとして書き出して、選んで@requireで読み込むだけで良いんだが、なんかindexedDBの出番ある?
それこそインデックスだと思うけどね。

465 :デフォルトの名無しさん:2016/11/25(金) 08:34:29.54 ID:PtU3UTK5.net
いつも思うが、ここの質問者は複雑な背景がある質問をソースコードを出さずに質問するのは何故だ?
代替案が提案されるのは情報が出そろってないから
初めから全ての情報を出せばこんなことにはならない
アドバイスした人や否定意見を「お前等は分かってない」で一蹴してさんざん馬鹿にした上で去るのが常
お前が情報を出さないのが全ての原因

466 :デフォルトの名無しさん:2016/11/25(金) 08:47:16.69 ID:QZ3DaKSR.net
>>465
賢いつもりで、文句言ってくるやつは愚鈍だと言いたいんだろう。
そもそも相手を愚鈍にしておきたいから、ソース出さないんだと思うけどね。
俺なら早めに自分のリポジトリの上げて、声出して、便利そうだけどここで使い物にならんので、置いとく、とかやる。
個人の持ち物なら。
仕事や金儲けでやってたら、人の話聞かないと大怪我するのはわかってるしな。

467 :デフォルトの名無しさん:2016/11/25(金) 09:05:01.87 ID:cmXQyT89.net
いいんだよもう。
本当に心底困ってて、礼儀正しく質問してくる奴なんて幻なのだから。
俺すげーしたいやつ、ただここでアピールすることで興奮し、
不安を取り除いてやる気を出そうとするやつの話を聞いてやるのもこのスレの役目。

468 :デフォルトの名無しさん:2016/11/25(金) 12:43:41.42 ID:QZ3DaKSR.net
まぁ、拡張もクリック一つなんだけどね。
それが現状ベスト、ではなくて、それしか使えない、って白状すりゃいいのに、プライドの高いやつだなぁ。

469 :デフォルトの名無しさん:2016/11/25(金) 13:19:56.25 ID:1PQbLaAu.net
自分は万全に良く知ってて良く考えてると思ってるけど、
技術が圧倒的に足りないのもあってうまいこと行かず、
もやもやしたフラストレーションが溜まってるんでしょう。

要するに何か具体的に解決したいのではなくスッキリしたいだけ。
まあそれは結局自らの問題だから他人に言っても仕方ないんだけどね。

470 :デフォルトの名無しさん:2016/11/25(金) 22:05:14.23 ID:9S7zID8/.net
お前らがそういうことにしたいのならそれでいいけども、
お前らのレベルの低さは他言語スレ見たらすぐ分かると思うんだが。

とはいえWeb系()に付ける薬はないのは分かった。
そしてこの言葉が広まっているのはつまり皆が同感するからであり、
それを俺が何とかしようとしても、所詮俺如きではどうにもならないのも分かった。

まあせいぜいポストゆとりに殺されてくれ。

471 :デフォルトの名無しさん:2016/11/25(金) 22:06:17.97 ID:9S7zID8/.net
>>465
ここでのこういうやりとりは無駄であって、
その時間をソースコード開発に回すべきだと思っているから。
ここに晒したらいちいち反応しなければならなくなるだろ。
それは時間の無駄だ。結局今回も自力で辿り着いてしまったし。

俺も結局は最善手を選んでいるだけ。
ここでコードを晒して時間を浪費するよりは、
何か情報があればラッキー程度として、基本的に自力で解決することに賭けた。
これまでのやりとりを見る限り、君達には俺のコードは読めないし、解決する能力もない。
だからせいぜいサンプルコード発掘くらいだと思ってそうした。
書き込み速度のオーダーを知っていればその点の即答もあるかと思ったが、それもないし。
おそらく君らは俺がやっているほど負荷掛けた使い方をしていない。だから何も知らない。
オススメのCacheStorageのスループットも知らないだろ?要するに君らはその程度なんだよ。
それで何でそこまで自信過剰なのか俺には分からないのだが。
(俺もそれを知らないから俺が大したこと無いのももちろん事実だが、
君らも大したことはないんだよ、それを自覚しないといけない)

そもそも代替案なんて必要なかった。
もう対策は出来ていて、十分な速度は出ている。(以前と比べて50倍速以上)
本来あるべき回答は「その書き込み速度は明らかに遅すぎるから、お前のコードに問題がある」だった。
ただ君らは本来の書き込み速度自体を知らないから、これに答えられず、
「遅いのなら違う方法を試せ」という間違った回答をよこし、それを正解にしようとしている。
色々明らかにずれているんだよ。

472 :デフォルトの名無しさん:2016/11/25(金) 22:07:04.84 ID:9S7zID8/.net
とはいえここら辺のずれもこれまでどおりだから、
俺は君らからでも有効回答が得られる可能性を残しつつ、
無駄に巻き込まれないように出す情報も絞ってある。
それだけ。
ただ、やっぱり難癖付けられて巻き込まれてはいるが。
前も言ったが、こっちもどこまで出せばどれくらいの精度が期待出来るかは分かるから、
こちらが出していない部分については当然回答がないということで全く問題ないんだよ。
出している範囲で明らかにおかしければ指摘して欲しいし、問題ないならスルーでいい。
ただ今回は出している範囲でも明らかにおかしいのに誰も指摘出来てないだろ。
そしてさらにおかしな回答をよこしてそれを正しいと主張している。
お前らがそれで仕事しているらしいからWeb系()って怖いわ。

なお君は465=444か?
だったら俺は君の回答には不満はない。知っている範囲で答えた良い回答だ。
知らない奴が間違った主張をするからおかしな事になるわけであってね。
ただなんか知らんがJavaScriptの連中はこういうのが多いが。

473 :デフォルトの名無しさん:2016/11/25(金) 22:36:44.21 ID:TwCdHdIi.net
うーん、やっぱり、何かおかしいわ。

開発って長くやってりゃわかるけど、コード睨んでるより、飯食って風呂入って嫁とゴロゴロしてる時くらいに謎の天啓で解けるようなもんで、
ソースコード自体は「こう書く」と決めてから、ガーッと書いて半日位で終わるんだよなぁ。

ゴリラの知恵の輪見て、「お、解けてる、ゴールに辿り着いたな」と思うのは仏くらいだろ。

そのスループット、は背景がわからないと答えられないんよね。
グリモンでもバージョンによって違うし。
遅いなら違う方法試せ、は要は、「情報が足りなすぎてわからん。自分でやってみろよ」の糖衣文だろ。

やってるほど負荷をかけてない、って当たり前よ。
密航船の奴隷でもあるまいし。
普通は人数と航路に対して適切な船を選ぶか、船に対して適切な航路と人数を選ぶもんだ。

絞ったものには、絞ったなりの答えしか来ないよ。

WebはWeb屋、俺はイントラ屋と思ってるおっさんでも思うんだから、お前が馬鹿にしてる新進気鋭のWeb屋さんならもっとキツめに思うと思うよ。

少なくとも俺はそれはブラウザではやらん。

474 :デフォルトの名無しさん:2016/11/25(金) 23:59:05.15 ID:9S7zID8/.net
お前も話をすり替えるのな。それもWeb系()の悪い癖だわ。
多分すぐに「ポストゆとりの新進気鋭のWeb屋」に駆逐されるよ。
俺の知ったことではないが。

475 :デフォルトの名無しさん:2016/11/26(土) 00:52:43.95 ID:9lTBiZ7O.net
すり替えられた、何か攻撃されてる、それはWeb系()だからだ、と保身で揶揄してるままだと、それこそ新進気鋭に駆逐されるよ。
合理的だからね、彼らは。
最後から二つ目の段落に書いてあることも読めないくらいだから仕方ないけど。

476 :デフォルトの名無しさん:2016/11/26(土) 01:30:19.73 ID:S6y++TVv.net
もしかして理解できない事はどれだけ喩えて言われてもすり替えられてると思ってるのかな

477 :デフォルトの名無しさん:2016/11/26(土) 02:26:09.31 ID:bM77xh/N.net
>>471
お前が自分の都合しか考えない自己中な奴だという事が分かっただけだな
お前が情報を開示しない事で、他人がお前の状況を正確に把握できず、お前の求める答えが無ければ情報を後出しして非難するわけだ

お前と同じ環境を揃えなければ再現する事は不可能だ
仮に俺の環境で検証したとしても後出しでいろいろと情報を付け足して否定するのは目に見えている
再現性が限りなく低いと分かっている問題に時間をかける奴はいない
「君達には俺のコードは読めないし、解決する能力もない」といってるが、実際にはお前の説明能力の問題

478 :デフォルトの名無しさん:2016/11/26(土) 05:01:06.08 ID:RLAnsqoN.net
そもそも解決して頂こう、その努力をしようと思っていないしな。
こいつは人様を一体何だと思ってるんだ?
技術者として以前に人間として下手くそな奴だな。

479 :デフォルトの名無しさん:2016/11/26(土) 11:38:59.71 ID:EHtLgt8W.net
相変わらずゆとりの言い訳ばかり。本当にお前らどうしようもないな。
そうやって自己正当化ばかりしているからゆとりのままなんだよ。
まあそれをやり続けて数年後に死ねばいいと思うよ。

情報は後出ししてない。
最初の投稿>>441の時点で異常に遅いと分かるし、指摘出来る。
もちろん俺も異常に遅いと感じたから色々確かめていた。
とはいえコード自体は特に問題なさそうだったし、
そもそも俺はIndexedDBを初めて使うから速度のオーダーが分かってなかった。
だから聞いた。結果、誰も知らず、50倍遅いのを誰も見抜けなかっただけ。

結局お前らの実力ってその程度って事だよ。これは事実だよ。
他言語で50倍も遅いのに気づかないようだと殺される。
もちろん初心者ならいいけど、お前ら初心者じゃないつもりなんでしょ。
俺はそこら辺の勘違いを直せと言ってるんだよ。

とはいえ全く聞く耳持たないようだし、多分Web系()と言われる理由はそこなのだろう。
おそらく俺も他言語の技術者が既にやってきた指摘を繰り返しているだけ。
お前らがムキになって俺を悪者に仕立てるのもよく分からんが、そうしたければそうすればいい。
そんなことをしてもお前らの実力があることにはならない。

数年後にポストゆとりに殺されるか、
JavaScriptがもっとメジャーになって他言語の上級者が流入してきてお前らのゴミっぷりがばれて殺されるか。
あるいはWeb系()は今のままで低空飛行を続けられるか。
まあ俺の知ったことではないが。

480 :デフォルトの名無しさん:2016/11/26(土) 19:29:29.83 ID:RLAnsqoN.net
言ってることが無茶苦茶
ユーザースクリプトがワンクリックなんちゃらとか
拡張機能でもワンクリックで更新できますが?
そういった事が山ほどある
もう働きたくないでござる!働きたくないでござる!と言ってるようにしか見えない。

それとなんか、自分の正当性をペラペラ喋りまくることが正義だと思ってみたいだけど大間違い。
この世の正義とは、可愛げ・真摯さ・悪どさであって、
本当にひたむきに取り組むかは別にして、相手の意見を組んだことを示さなきゃ、
あれも嫌、これも嫌、じゃ最悪

お母ちゃんに駄々をこねる思春期少年のような態度を示されても困る
情報の後出し云々以前の問題
人間としてまともにコミュニケーション取れるようになってから来いよな
ほんと

481 :デフォルトの名無しさん:2016/11/26(土) 20:26:02.31 ID:9lTBiZ7O.net
説明力0だしな。
でかいファイルの更新、は、遅いよ。
levelDBの実装見りゃわかる。

482 :デフォルトの名無しさん:2016/11/26(土) 22:27:36.04 ID:EHtLgt8W.net
JavaScriptの環境にも色々問題があるのだけど、
お前らが上達してない最大の原因はお前らの人格だよ。
しかもそれを認めないと来てる。ゆとりは嫌われて当然だよ。
技術的なことは技術的に判断しないといけない。

>>473
一応言っておくけどお前もWeb系()以外の何者でもないよ。
50倍遅いコードを擁護するなんて他言語ではあり得ないから。
それを見抜けない奴を擁護することもね。

いや、正確に言えば、Web系ではサーバーサイドの連中も含まれてしまうので申し訳ない。
駄目なのは「ゆとりJavaScripter」と「その取り巻き」だね。

サーバーサイドでは処理性能が鯖コストに直結する為、50倍なんて当然認められない。
俺が遭遇したケースだと、Goの奴に「そんなところでString.replace使ってんじゃねーよ。
forで回して変換しろ」と言われたことがある。まあ正直、勘弁してくれよと思ったが。
フルスタック()とか言っているらしいけど、
俺が見る限りPHPの連中はお前らよりマシっぽいし、上記の通り環境もキツいので鍛えられる。
ポストゆとりを待つまでもなく、PHPerがフルスタック化すればお前らは殺されるよ。
まあPHPerには別の問題があるのかもしれないし、それも含めて俺の知ったことではないが。

483 :デフォルトの名無しさん:2016/11/26(土) 23:21:05.86 ID:9lTBiZ7O.net
>>482
なんだそりゃ。
鯖とかフルスタックの話するとなると、はっきり言って、

「使うべきでないものは最初から使わない」
に行き着くべきなんだが。

そんな事をするぐらいなら、札束でAWSのインスタンスをガンガン起こすSIerの発想の方がまだ正しいよ。
万能ナイフでビーフシチューは、作れないことも無いけど、作るべきじゃない。
その程度の次元の話。
あと、これはすり替えではなくて、無能に説明してる比喩表現だからね。

484 :デフォルトの名無しさん:2016/11/26(土) 23:42:25.47 ID:EHtLgt8W.net
>>483
お前は文脈が読めてないな。
JavaScriptの前に日本語を勉強した方がいい。

それと、
> 「使うべきでないものは最初から使わない」
に関しては俺も同意だが、そんなに議論したいのなら、>>464の馬鹿を何とかしろ。
CacheStorageを無理に使いたいからletesencryptを使ってサーバ絡ませて@require?
GreaseMonkeyでIndexedDBを直接扱えばそれで終わる話で、何でそんなことになるわけよ?
としか思えなかったが、人格に至らない点があるらしい俺からでは説得は無理だ。
素晴らしい人格と説明能力の持ち主である君から是非彼を説得してくれ。

485 :デフォルトの名無しさん:2016/11/27(日) 01:20:07.95 ID:bBkWJjxZ.net
>>484
あのさぁ。抗う言葉が無くなってきたからといって、それはなかろう。
全然同意してないじゃん。
してるならそのソース捨てなよ…。

文脈を読ませるのはお前の仕事だ。
逆に、書いてあることを書いてある通りに読み、書いてない事を読まないのもお前の仕事だ。

IndexedDBなんか使うな、と言っとろうが。464でも。CacheStroageを使えとも言ってない。

適当にファイルに落とせば?って言ってんの。
それしたいなら、拡張で書くか、プロキシとして実装しろ、と。

何で相手がお前以下だと、お前の発想を単に否定しているだけだと思いこむの?
モヒカンなの?

486 :デフォルトの名無しさん:2016/11/27(日) 01:52:00.72 ID:sEFEgE7T.net
>>485
ファイルに落とす機能はもう既にあって、動いていると>>443で言ってるだろ。
お前は本当に日本語が不自由な奴だな。

大体IndexedDBなんてただのストレージなんだし、どう使おうが問題ないだろ。
お前ら何で駄目だと思いこんでるんだ?

487 :デフォルトの名無しさん:2016/11/27(日) 02:10:05.21 ID:F1aOp1KR.net
ID:EHtLgt8W
この人、「お前ら」と一括りにして反論する癖があるのね
選民意識の強い人と言うべきか
この人の場合は「自分」と「自分以外」で選民している感が強い
全能感も強くてコミュニケーション能力に問題がある感じ

488 :デフォルトの名無しさん:2016/11/27(日) 02:17:18.52 ID:bBkWJjxZ.net
>>486
日本語が不自由とか自己紹介良いよほんと。

外部スクリプトで展開、とかアホな事言ってんじゃん。
なんでそれ直接読めるような鯖かかんの?って疑問。
そうすりゃ解決すんのに。

ただのストレージではないし、どう使っても問題ないものでは無い。
indexでアクセス出来る、indexが昇順で並んでいる、サブインデックスも張れる、本来はバイナリを入れるためのものでは無いものだよ。
だから、万能ナイフとかそういう喩えで話してんじゃん。
やろうと思ったら出来るけど、それやるくらいなら別のやり方するって言ってんの。

>>487
きれいな言葉で包んでやらんでも良かろう。
ただの自己愛性人格障害でしょ。

489 :デフォルトの名無しさん:2016/11/27(日) 02:53:05.25 ID:fRnX9irD.net
誇大性(空想または行動における)、賛美されたい欲求、共感の欠如の広範な様式で、成人期早期までに始まり、種々の状況で明らかになる。以下のうち5つ(またはそれ以上)によって示される。

自分が重要であるという誇大な感覚(例:業績や才能を誇張する、十分な業績がないにもかかわらず優れていると認められることを期待する)
>>全レス
限りない成功、権力、才気、美しさ、あるいは理想的な愛の空想にとらわれている。
>>概ね全レス
自分が “特別” であり、独特であり、他の特別なまたは地位の高い人達(または団体)だけが理解しうる、または関係があるべきだ、と信じている。
>>459 OSS発言、
過剰な賛美を求める。

特権意識(つまり、特別有利な取り計らい、または自分が期待すれば相手が自動的に従うことを理由もなく期待する)
>>471-472
対人関係で相手を不当に利用する(すなわち、自分自身の目的を達成するために他人を利用する)。
>>471-472
共感の欠如:他人の気持ちおよび欲求を認識しようとしない、またはそれに気としない。
>>全レス
しばしば他人に嫉妬する、または他人が自分に嫉妬していると思い込む。
>>459 意識高いだけ云々
尊大で傲慢な行動、または態度
>>全レス

フルビットで通院案件

490 :デフォルトの名無しさん:2016/11/27(日) 05:35:11.63 ID:mveO+vV3.net
人にケチ付ける前に自分のレスを見直した方がいい。
「IDBで一般的にこういうコードのケースで思ったようにパフォーマンスが出ないんだが」
この一言で済む話。
他は全て、私は怠惰です、短気です、プライドが高いです、とアピールしているようなもの。

もし一生懸命自分の中でやり尽くしたと思うのなら、
尚更一般的な話に落とし込んで問題提起しなくちゃ。

自尊心は、そういう前向きな回転を生み出すことで保つべきで、
自己肯定や他者否定に縋っちゃ駄目。
もっと頑張らなくちゃ。

491 :デフォルトの名無しさん:2016/11/27(日) 10:33:33.02 ID:sEFEgE7T.net
>>488
いやただのストレージだよ。
FireFoxは「FileSystemAPIなんて要らない。だってIndexedDBで事足りる」という立場だ。
当たり前だがこれは「FileSystemAPIの代わりにIndexedDBを使うことに何の問題もない」という意味だよ。
少なくとも彼等はそう思っている。
(俺はOSから透過のFileSystemAPIがあった方がいいと思っている)
Blobの格納も出来るようになってるだろ。
もっとも、駄目ならBase64使う奴もいただろうし、それも選択肢だよ。
インデックスも貼れるけど、使わなくても何も問題ない。
とはいえこれらには合意する必要はない。
俺のプロジェクトは俺が方針を決めるし、君のプロジェクトでは君が方針を決めるだけのことだ。

次の質問に移ろう。
何故君はそんなに教科書的使い方にこだわるのか?

IndexedDBはインデックスを使ってアスキーを入れないといけない?何故?
俺は装備を見比べて使えそうな物を使っているだけ。具体的には
IndexedDB, CacheStorage, FileSystemAPIの中で一番マシなIndexedDBを使おうとしているだけ。

> なんでそれ直接読めるような鯖かかんの?って疑問。
サーバに関しては完全に俺の管轄外だ。
ガチの勝手スクリプトだから、こちらの要求は基本的に通らない。

492 :デフォルトの名無しさん:2016/11/27(日) 12:34:58.81 ID:bBkWJjxZ.net
>>491
彼らって誰?
Blobが格納できるようになったのは、中期以降。
しかも、そんな一つあたりが大きいデータの為じゃない。
これは、LevelDB見てくりゃわかること。

貼らなくても問題ないことはないよ。キーっていうインデックスは出てくるわけだし、sortedなので、そのキーに長くてソートが不要なものは使うべきじゃない。

俺のプロジェクトだから、俺が決める、なんて言っちゃうなら、OSS発言は取り消しといてね。
対極の発想だから。それ。

教科書的な使い方にこだわってるんじゃないよ。
実装見て、それは遣い方が悪いってものに対して、おかしいよって言ってる。

管轄外ってなんだそりゃ。フルスタックじゃねえの?(笑)
は、置いといて。

単純に、Clientで動かすプロキシ書けばいいんだよ。
特定のURLの場合、ネットワークで取得せずファイルから見るような。

493 :デフォルトの名無しさん:2016/11/27(日) 12:45:45.17 ID:bBkWJjxZ.net
もしかして、鯖って書いたらサーバー側で動かすもの想像してたのかな。
こいつのフルスタックって何なんだ。

494 :デフォルトの名無しさん:2016/11/27(日) 12:54:03.05 ID:x2gPA/Jh.net
無知と怠慢。救いようがない

495 :デフォルトの名無しさん:2016/11/27(日) 12:54:44.21 ID:bBkWJjxZ.net
なんでこんな事言ってるかと言うと、テレホの時代に、同じような物沢山観たんだよね。
metagetaしかり、Vectorにいっぱいあるレベル。
自分が一番イケてると思ってるんだろうが、単に轍に乗ってるだけ。

496 :デフォルトの名無しさん:2016/11/27(日) 13:12:59.65 ID:bBkWJjxZ.net
ちなみに、IndexedDBで事足りる、とは言ってないんよね、Mozillaは。
ローカルファイルを使いたいなら今API策定してる、とも言ってるし。

割りと無難なブラウザオンリーな対応何は、ダウンロードしたそのアーカイブをドラッグアンドドロップやなんかでjsで受けてjsで開く事だと思うけど。すでにファイルとして出せるなら。

怠慢の方がマシ。
馬鹿な働き者は撃ち殺すしかないという典型例。

497 :デフォルトの名無しさん:2016/11/27(日) 13:18:28.75 ID:HGJqeK8l.net
もういいからROMって?

498 :デフォルトの名無しさん:2016/11/27(日) 13:31:22.83 ID:sEFEgE7T.net
>>496
お前はやはり日本語にどうにも問題がある。議論は無理だ。
とはいえお前にも分かる範囲の所は答えておく。

> 割りと無難なブラウザオンリーな対応何は、ダウンロードしたそのアーカイブをドラッグアンドドロップやなんかでjsで受けてjsで開く事だと思うけど。すでにファイルとして出せるなら。
その通りだ。そしてこれはもう実装出来ている。
そして別オプションとしてIndexedDBにも格納出来るようにしようとしている。

> 俺のプロジェクトだから、俺が決める、なんて言っちゃうなら、OSS発言は取り消しといてね。
> 対極の発想だから。それ。
違うんだな。お前はOSSに「参戦」していないからそれが分からない。
>>464なんて典型的な勘違いだぞ。
ただまあとにかく「参戦」してみろ。それだけでいろいろ分かるはずだから。

499 :デフォルトの名無しさん:2016/11/27(日) 13:35:35.02 ID:bBkWJjxZ.net
ムダそうだからROMるわ。すまんな。

>>498
メンテナじゃアホ。

500 :デフォルトの名無しさん:2016/11/28(月) 05:41:09.72 ID:sKwraRFT.net
一つ言えることは、この件についてやってみる価値がありそうなこと沢山あるのに、
めんどくさがって手を動かさないで口だけで反論するのでは前に進みようがないということだね

501 :デフォルトの名無しさん:2016/11/29(火) 03:20:41.76 ID:MuupHWfc.net
別オプションとしてindexedDBに…保存する意味がわからん

502 :デフォルトの名無しさん:2016/11/29(火) 23:05:21.60 ID:BntnGE9d.net
「FileSystemAPI が不要」なのは、ファイルの書き込み機能は
blob URL リンクにしてダウンロードで事足りるから、ではないのかな?

503 :デフォルトの名無しさん:2016/11/30(水) 10:48:28.24 ID:Sk/SQjO5.net
超初心者です。
PHPとJavaScriptでホームページ作っていますがJavaScriptの変数名の使い方で質問です

phpの場合
変数名 hoge1fuga hoge2fuga ……を使用する時変数iを使って
 → if(hoge'.$i.'fuga == 'abcd')

→ $h = 'hoge'
$f = 'fuga'
if($h$i$f == 'abcd')
のような書き方ができますがjavascriptの場合どう書けば良いのでしょうか。

var hoge = fuga1.checked
の時に var hoge = fuga + i + .checked の記述にするとエラーになってしいまい、変数名の使い方そのものに疑問が湧きました。

504 :デフォルトの名無しさん:2016/11/30(水) 10:49:26.04 ID:Sk/SQjO5.net
>>1読んでませんでした
上の質問無視してください
失礼しました

505 :デフォルトの名無しさん:2016/11/30(水) 16:00:04.29 ID:1swyBgvf.net
>>503
できないことはないが、行儀が極めて悪いことだとされるのでしない。
そういうときは、配列を使う。 つまり、
var fuga1, fuga2 ではなく、
var fuga = [] とする。 利用するときは、
var hoge = fuga[i].checked となる。

506 :デフォルトの名無しさん:2016/12/31(土) 15:44:33.33 ID:nUjD4DbZ.net
JavaScript死亡www

「WebAssembly」がITの未来に変革もたらす|Google、Apple、Microsoft、Mozillaが共同で開発した新概念

「WebAssembly」がWebブラウザに変革をもたらします。
Webブラウザは、もともとただテキストを表示するだけのところから始まりました。その出発点から、現在ではコミュニケーションやゲームまで幅広い表現を可能にしています。
そして今回、「Webブラウザ」に新しい概念が加わわることになりました。
それをもたらしたのが、ブラウザに関わりの深い世界規模の4社「Google」「Apple」「Microsoft」「Mozilla」が共同開発した、Webのためのバイナリーフォーマット「WebAssembly」です。
今回はその「WebAssembly」について、「スゴイところって何?」「何が起きるの?」をご紹介していきます。
WebAssemblyは「JS不要。コンパイラ言語だけで動的アプリが作れる」「どの言語でもWebブラウザ上にアプリを作ることができる」

WebAssemblyによってもたらされるスゴイところは次の4つ。
コンパイラ言語だけで、Webブラウザ上に動的なアプリが作れる
ほぼ機械言語にコンパイルされるからヌルヌル動く
OSを一切気にする必要がなくなる。気にするのはブラウザのみ
C,C 以外の言語でもWebAssemblyにコンパイルされる「クロスコンパイラ」の可能性が高まった

これまでWebブラウザで、ユーザからの入力情報を元に、動的なアプリケーションを実現するためには「JavaScript」が必須でした。

「インタプリター言語」であるJavaScriptは、その都度ソースコードを機械語に翻訳する必要があるため、予め機械語に近くコンパイルされる「コンパイラ言語」と比較すると動作が遅いという特徴があります(※)。

もしコンパイル後の機械語に近い形で、Webブラウザ上でコードが実行されたら。
JavaScript以上にヌルヌルに動き、しかもJavaScriptを気にする必要がなくなります。

それを実現したのがこの「WebAssembly」です。

https://mayonez.jp/1690

507 :デフォルトの名無しさん:2017/01/01(日) 00:42:27.84 ID:k8/wNRO9.net
あちこちに落としているようだが、誰一人として肯定して無くてワロタw
つかマジでJavaScript界隈の馬鹿共はこんなデタラメ記事書くのをいい加減止めた方がいいと思うのだが。
自浄作用が無いのは、お前らが叩かないからでもあるんだぜ。
嘘は叩かれるべき。

Cに関しては昔は間違い叩きがすごかったと聞くが、
結果的にWeb上での間違いは皆無となり、お互いの利益になってる。
JavaScriptに間違い記事が氾濫しているのは、第一義には書く奴が悪いんだが、放置されていることも問題だよ。
とはいえ、この記事には投稿欄が無いため、#mayonez編集部=馬鹿と覚えておくしかないが。
この点はQiitaのほうがかなりマシだな。

508 :デフォルトの名無しさん:2017/01/01(日) 08:00:47.18 ID:FrNRDqOE.net
>>507
素晴らしい指摘をしているであろうあなたの投稿を見たいからQiitaで使っているアカウントを教えてくれ

509 :デフォルトの名無しさん:2017/01/01(日) 08:49:58.30 ID:k8/wNRO9.net
>>508
ゆとり死ね

ツーかお前ら本当に池沼なのな。俺は「ゆとりBot」作れそうな気がしてきたよ。

510 :デフォルトの名無しさん:2017/01/01(日) 08:55:22.46 ID:2Xf0vibn.net
ID:k8/wNRO9 のような他人のダメ出ししか出来ない奴がまともな指摘をするとは思えないのでどうでもいい

511 :デフォルトの名無しさん:2017/01/01(日) 08:59:00.51 ID:k8/wNRO9.net
>>510
その通りだ。お前は正しい。
それが分からないからゆとりは池沼なのだし、嫌われる。

512 :デフォルトの名無しさん:2017/01/01(日) 13:57:14.12 ID:fINgyq7S.net
何かと理由を付けてQiitaアカウントを隠すとは思っていたが、意外とあっさり自分の非を認めるんだな

513 :デフォルトの名無しさん:2017/01/01(日) 16:36:12.10 ID:30cN+tVf.net
HTML+JavaScript+WebAPIの構成で認証処理したい場合ってこれでいいの?

ログイン画面
-- ユーザー名/パスワードを送信
-- パスワードが合ってればデータベースにユーザー名と認証トークンを保存
-- レスポンスヘッダーに認証トークンを書き込み

他の画面
-- リクエストヘッダーに認証トークンを書き込み
-- データベースの認証トークンを照会して合ってれば更新
-- レスポンスヘッダーに新しい認証トークンを書き込み

WebAPI
-- ajaxヘッダーに認証トークンを書き込み
-- データベースの認証トークンを照会して合ってたらapiを実行

514 :デフォルトの名無しさん:2017/01/01(日) 17:38:52.36 ID:QliWG2cV.net
>>513
トークンって何?
JWTみたいな署名したものの類?
であれば、ログイン画面以外はサーバ側の何も更新する必要無いのでは?
新しいものを発行しまくる必要が無いと言うか、どこでもそんな事すべきでは無い。
ログイン画面に当たるものと、トークン更新のAPIがあればそれで良い。

セッションキーならまた話は別だけど。
トークンの定義が適当すぎて答えられん。

515 :デフォルトの名無しさん:2017/01/01(日) 17:39:50.17 ID:k8/wNRO9.net
>>512
違うぞ。

> 何かと理由を付けてQiitaアカウントを隠す
隠してねえ。そもそも持ってねえ。
> 意外とあっさり自分の非を認めるんだな
そもそも俺に非はない。

506がデタラメだと分からない馬鹿はこのスレにはお呼びじゃない。
理由が分からないのなら、必死チェッカーで調べてみろ。
JavaScript/Java/C#(Xamarin)のいずれのスレでもそれぞれ別の理由で駄目出しされてる。
もちろんそれ以外にも駄目出し出来る。

508はコミュ症過ぎて受けようがない。それを咎めている。
もっともお前もコミュ症過ぎて分からないようだが。

508は反射レスだ。俺のレスが気に入らないから定型的に返してみただけ。
だけどそういうのがお前らの状況をより悪くしている。そのことにいい加減気づけ。

516 :デフォルトの名無しさん:2017/01/01(日) 17:40:34.08 ID:k8/wNRO9.net
506は明確に間違いを含んでいる。それが分からないような馬鹿とは俺は話したいとは思わない。
そして真面目に話したいのなら、いちいち無駄に煽る意味は無い。
あれでは他の誰かがQiitaアカウント持ってても、508みたいなゴミに教えようとは思わないだろ。
つまり、508は俺を叩くためだけの作用しかない。プラス作用は期待できないレスだ。

では俺が叩かれる理由があるか?それはお前らが考えるべきことだが、
俺は意図的に、

#mayonez編集部=馬鹿、つまり、
#mayonezはゴミサイトだ

と言っている。これは再度強調しておく。
俺はゴミ潰しをしているんだよ。俺が507で言ったとおりにね。

506の意図は不明だが、通常はこれだけ投下するのなら関係者が宣伝しているとかだ。
あんなデタラメを宣伝されても迷惑でしかないだろ。
だから俺は奴らが書き込む度に叩くことにより、書き込みを防ぐことを期待している。
分かるか?
書き込みを強制的に止めさせることはできない。
でも、「宣伝したい」のなら、カウンター「だって#mayonezって嘘ばかりのゴミじゃん」を合わせることによって、
相手に書き込みを止めさせることを期待している。

これを理解したうえで批判するのはお前の自由。
理解できずに反射レスしているような奴は馬鹿で、かつ加害者でもあることを自覚しろ。
お前らみたいな奴がいるから平気で506みたいな奴が沸くんだよ。
俺みたいな奴しかいなければ奴らはすぐ死滅する。他言語スレがそうだ。
JavaScriptのスレが糞なのは、お前らみたいなゆとりが馬鹿丸出しで口出ししてるからだよ。
スレの流れが読めないのなら自重しろ。

517 :デフォルトの名無しさん:2017/01/01(日) 18:08:54.61 ID:QliWG2cV.net
クソ長い説明はだいたいが間違ってる。
どっかのトランスパイル馬鹿と同じ。

518 :デフォルトの名無しさん:2017/01/01(日) 18:42:12.80 ID:8rzMeR7x.net
ID:k8/wNRO9 は自分の書き込みが参考にならない事を正しいと認めたのだからスルーしてあげるのが優しさだよ

519 :デフォルトの名無しさん:2017/01/01(日) 18:49:08.37 ID:QliWG2cV.net
なるほど、役には立たんことを逆説的に役に立つと言ってるから、
これが訳に立てば役に立たなくて、役に立てば役に立っていないのか。
難しい書き込みするなぁ。

520 :デフォルトの名無しさん:2017/01/01(日) 18:50:49.14 ID:QliWG2cV.net
>>519
二段落目が、表現上意味が繋がらんな。
書き込みが役に立てばスレの役に立たなくて、スレの役に立てば役に立たない書き込み、だな。

521 :デフォルトの名無しさん:2017/01/01(日) 19:00:23.75 ID:UZp8Mxmv.net
>>510を認めておいて何を小難しい解釈してるんだ?
読解力が足りない文盲はこれだから…

522 :デフォルトの名無しさん:2017/01/02(月) 00:16:58.11 ID:OVlW98VI.net
>>521
いや、お前が馬鹿すぎるから、矛盾する2つ以上の状況が出てくるだけ。
それに気づいていない時点でちょっと引くレベルでバカじゃん。
さらに指摘されても気づいてないとか。
頭の中のおがくず一回入れ替えてきたら?クワガタの幼虫程度の知能にはなれるんじゃない?

523 :デフォルトの名無しさん:2017/01/03(火) 08:27:03.92 ID:m68UQ04g.net
>>513
WebAPIじゃなくてRESTと言って。
WebAPIはJSから触れるAPIを指す言葉。

524 :デフォルトの名無しさん:2017/01/19(木) 22:43:27.75 ID:OV8X1StJ.net
クエリパラメータでURLを受けとってクエリパラメータを追加してそこの遷移するって危険?
画面Aで検索ボタン押す→画面Aのアドレスをクエリパラメータに追加して画面Bに遷移する
画面Bで検索を行い1つ選択して戻るボタンを押す→検索結果をパラメータにして画面Aに遷移する
こういう感じの入力支援機能を作りたいんだけど

525 :デフォルトの名無しさん:2017/01/20(金) 00:35:32.81 ID:H+FrkUCG.net
一つのページで上手く完結させたほうがきっと良い

526 :デフォルトの名無しさん:2017/01/20(金) 01:04:21.61 ID:vNxVJ868.net
俺もそう思う。

527 :デフォルトの名無しさん:2017/01/29(日) 15:36:11.92 ID:CHlx9RpS.net
JavaScript ベスト・オブ・ザ・イヤー 2016
https://risingstars2016.js.org/ja/

JavaScriptコミュニティは日々進化しています。今日のトレンドも数か月後には陳腐化しているなんてことは日常茶飯事です。

2016年は終わってしまいましたが、何か重要なことを見逃したのではないかと感じているそこのあなた! 2016年の主要なトレンドをおさらいして、そんな不安を払拭しちゃいましょう。

過去12か月に獲得された Github のスター数を比較して、2016年に支持を集めたプロジェクトを数値に基づいて評価していきます。

2015年はなんといっても React でした。そして、Flux 実装を席巻したのは Redux でしたね。 2016年、JavaScript の人気プロジェクトはどのようなものだったのでしょうか?

528 :デフォルトの名無しさん:2017/01/29(日) 18:44:38.75 ID:M0HgmB1M.net
スタートアップで作ってるメンバーは気楽でいいよね
10年後か20年後かに腐りきったフレームワークに依存した数多のシステムを保守する人が憐れ

529 :デフォルトの名無しさん:2017/03/25(土) 00:53:22.16 ID:is8OgtpR.net
switch caseは嫌いだから
javascriptの時は配列で代用してるわ

switch (weather){
 case "快晴":
  return "f.png";
 case "晴れ":
  return "f.png";
 case "くもり":
  return "c.png";
 case "雨":
  return "r.png";

これより

Select =[
 "快晴" : f.png,
 "晴れ" : f.png,
 "くもり" : c.png,
 "雨" : r.png
]
Select(weather);

の方が見やすいやん

530 :デフォルトの名無しさん:2017/03/25(土) 00:54:36.43 ID:is8OgtpR.net
switchなんて所詮はif文の連続の糖衣構文だからな
javascript連想配列でデフオルト値設定する時は
if(hoge[x]===undefined)一文を付け加えるだでオケ


あと、普通はswitch case文でやりそうな

hoge = [
 "快晴" : function(){ 処理1 },
 "晴れ" : function(){ 処理2 },
 "くもり" : function(){ 処理3 },
 "雨" : function(){ 処理4 }
]

hoge[weather]();

みたいのもよくやるわ
それくらいswitch case使いたくない

531 :デフォルトの名無しさん:2017/03/25(土) 01:04:50.07 ID:U4euK7G2.net
突然マルチポスト?
http://echo.2ch.net/test/read.cgi/tech/1472426483/783-784

532 :デフォルトの名無しさん:2017/10/29(日) 07:37:41.42 ID:Heo7FnD+.net
>switchなんて所詮はif文の連続の糖衣構文だからな
mjd!?

むしろ>>529式の配列の糖衣構文だと思ってたわ
caseの記述順序がパホーマンスに影響するのかdクス、

533 :デフォルトの名無しさん:2017/10/29(日) 11:02:46.12 ID:Heo7FnD+.net
質問なのですが、HTML5のcanvas要素が1ページ内に1000個あり、
それらに対してgetImageData()とputImageData()を周期的に行わねばならないとして、
 (1) 「canvas iを処理するタイマイベントi」を1000個起こす
 (2) タイマイベント1個の中でcanvas 1〜1000を処理する
という2種類の実装方法の間でブラウザのレンダリング回数に違いは生じますか?
やっぱ(2)の方がパホーマンス上目に見えて有利?

534 :デフォルトの名無しさん:2017/10/29(日) 12:15:24.08 ID:EyB63P4N.net
>>533
(2)の方が効率的だと思うが、掲示されてない条件もありそうだし、速度は実装依存なので、実測するのが原則
複数のブラウザで実測するといい

535 :デフォルトの名無しさん:2017/10/29(日) 12:35:01.00 ID:WeryM17b.net
requestIdleCallback内で可能な個数だけを処理するのがいいと思うよ

536 :デフォルトの名無しさん:2017/10/29(日) 12:48:10.75 ID:tz+cuQEW.net
タイマイベント自体はどの程度の周期で発生するんだろ
短ければ短い程良いって感じなのかな

537 :デフォルトの名無しさん:2017/10/29(日) 18:50:15.75 ID:Heo7FnD+.net
1000個、というのが疑念(更新が間に合わない場合を含んでいるのでは等)を呼んでしまったようなので
質問を修正させていただきまする

Q1. canvas要素の書き換えは即座にブラウザの再レンダリングを招く?
   それともハンドラが終了してからまとめて再レンダリングされるもの?
   あるいはその他?(何か別のトリガーがある?)

Q2. ブラウザの再レンダリングがいつ起きたか直接的に確認する手段があればキボン

なおハンドラ内で行うのはcanvas内容の参照と書き換えのみとします。
(明白に再レンダリングを招くoffsetTop/Left/Width/Height等、要素の配置座標に関わる参照や書き換えは含まない。)

538 :デフォルトの名無しさん:2017/10/29(日) 19:36:44.29 ID:Oszg+7NJ.net
デバッガを使えば確認できる。基本的にディスプレイのリフレッシュ毎に一回。

539 :デフォルトの名無しさん:2017/10/29(日) 21:04:51.00 ID:EMf9PiJ4.net
(2)の方法なら終了するまでレンダリングが起きようがない

540 :デフォルトの名無しさん:2018/02/16(金) 06:16:17.56 ID:W1XJdyx1.net
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

541 :デフォルトの名無しさん:2018/05/23(水) 21:23:56.11 ID:Au5e7VGg.net
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

5PLLK

542 :デフォルトの名無しさん:2018/07/05(木) 00:34:01.49 ID:RfoszcD2.net
4HA

543 :デフォルトの名無しさん:2019/03/09(土) 13:19:47.50 ID:jxJql+xc.net
受託の人たちでPWA対応って結構ある?

544 :デフォルトの名無しさん:2020/04/04(土) 22:16:23.06 ID:chSF5SQRn
【与沢翼】悪いですけど一流大学に行っても会社の「歯車」ですよ。成功者には中卒が多いですし
学歴なんて関係ないですよ。今を全力で生きれば必ず人生変えられます
https://www.youtube.com/watch?v=zt09bVq1f5w
【与沢翼】金稼げなきゃ意味ないんですよ。周りの人達はただ足を引っ張ってくるだけです。
迷ってる暇があったら決断し行動しろ!稼げない奴は明確な目標がないんですよ
https://www.youtube.com/watch?v=2XK_xg4n-I8
【与沢翼】会社を作るのチョー簡単だから!25万くらいあれば誰でもできますよ。
個人だと舐められるし搾取されたくないならコレするしかない
https://www.youtube.com/watch?v=vUDGR_Qb7KY
【与沢翼】起業するよりサラリーマンで成功する方が難しいですよ。
年収3000万くらいなら会社作って自分でやっちゃった方が早いです
https://www.youtube.com/watch?v=iTW0HuG8Wf4
【堀江貴文】サラリーマンの無駄な仕組みと人生の消耗…もう辞めれば?
https://www.youtube.com/watch?v=f6JJZwJilDQ
【落合陽一&ホリエモン】会社に全てを奪われる!特別なメリットがない限り
組織に自分の手柄を全て取られてしまうだけ
https://www.youtube.com/watch?v=XEhyfiSV_kk
【与沢翼】起業は怖いとか言うバカに伝えたい「サラリーマンの方がリスクあります」
https://www.youtube.com/watch?v=BRdKMhuMOtc

545 :デフォルトの名無しさん:2020/05/04(月) 16:17:26 ID:A6B6l9Um.net
「Objectオブジェクトは、すべてのオブジェクトの基本オブジェクトである」

↑これJavaScriptのある本に書いてあったのだけど、どういうこと?(ワラ

546 :デフォルトの名無しさん:2020/05/04(月) 22:21:44 ID:D5tu2Ze6.net
>>545
そのまんまだろ
基本→基底でもいいが
C#のObjectと同じ立ち位置ということ

それで分からないのなら、無視でいい
アップキャストとか考える必要のある言語でもないし、どうせ使わない
他の静的型あり言語同様、全ての型は別物、と考えていても特段問題はない
プログラミング言語なんて「知識」よりも「技能」に近いから、分からないなら分からないなりに進めばいいだけ

元の書き方でも十分分かりやすい
それで分からないのは君がオブジェクト指向を理解出来てないからだが、
どのみち無視でいい

547 :デフォルトの名無しさん:2020/05/04(月) 22:38:13 ID:Zdi/ARyL.net
いやJavaはひととおりマスターしたから
オブジェクト指向はバッチリ理解している。

JavaScriptは気持ち悪いことが多すぎる。関数が変数に代入できることとか。
まるで物理で光が粒でもあるし波でもあるという二重性のことを習ったときのように頭が混乱する。

このへんの考え方について詳しくコツを教えていただけませんか?

548 :デフォルトの名無しさん:2020/05/04(月) 22:39:31 ID:Zdi/ARyL.net
Javaは体系的にスッキリしてるから実に分かりやすい。
この気持ち悪いJavaScriptは何なの?

549 :デフォルトの名無しさん:2020/05/04(月) 22:52:19 ID:eA9rrZ8d.net
オブジェクト指向の理解とは関係ないJavaScript固有の話だと思うがな。
前半部分は"Object"という名前のオブジェクトがグローバルに存在するということに
想像が及ばないと理解しづらいだろうし、後半は「基本オブジェクト」というwell-definedでない
言葉で説明しているが、これもオブジェクトが他のオブジェクトのプロパティを継承する
prototype継承を知らなければこの文章だけからは理解しにくいだろう。

550 :デフォルトの名無しさん:2020/05/05(火) 00:28:49 ID:esp/1iza.net
>>547
> 関数が変数に代入できることとか。
Javaも出来るようになっただろ
というかメジャー言語で出来なかったのはJavaだけで、それ以外の言語は全部出来てる
Cでもだ
コツ?そりゃお前が何も知らない馬鹿だとちゃんと自覚することだよ
他言語少しでもかじってれば、そんなところで引っかかることはない
(ただしJavaの連中はこのタイプ=他言語なんて全く知らない馬鹿も多いとは聞くが)


>>549
そうか?こいつは分かったつもりの馬鹿だと思うぞ
確認したが、JavaもObjectクラスあるし、使い方としてはJavaのObjectとも同じ立ち位置だ
> クラス ArrayList<E>
> java.lang.Object
> java.util.AbstractCollection<E>
> java.util.AbstractList<E>
> java.util.ArrayList<E>
> https://docs.oracle.com/javase/jp/7/api/java/util/ArrayList.html
これを
> 「Objectオブジェクトは、すべてのオブジェクトの基本オブジェクトである」
と表現されて理解出来てないのだから、Javaもオブジェクト指向も分かってない馬鹿だよ
この部分はまだプロトタイプベースがどうとか以前の問題だ

まあ正直俺はプロトタイプベースに大して戸惑わなかったし、
今でもプロトタイプベースの方がクラスベースより表現範囲が広いので良いと思ってる
そしてこいつはいわゆる「クラス脳」で永遠とプロトタイプベースを理解出来ないのだろう
といっても実際にプロトタイプベースでないと組めないような事をするのは希だし、
クラス脳の為にクラス構文も入ったので、別段問題でもないけど

551 :デフォルトの名無しさん:2020/05/05(火) 02:37:44 ID:rwJ86+M0.net
class Abc
end

多くの言語では、このように継承元を書かずに、クラスを定義した場合は、
Object クラスから直接継承したとみなされる

普通は、継承チェーンを遡ると、Object クラスに突き当たる。
すべてのクラスの祖先

この板のJavaScript のスレは、荒らし対策で緊急避難用に作られたもの。
web 制作管理板のスレへ書き込んだ方がよい

こちらには、荒らししかいない

荒らしは必ず、2回書き込む。
自分のレスに、リンクを付けて「そうだよな」みたいに自演する

多くの人が言ってるように見せかける。
午前、3時とかでも、同時に2つのレスを書くw

552 :デフォルトの名無しさん:2020/05/05(火) 02:42:45 ID:rwJ86+M0.net
ほとんどの言語で、関数も変数に代入できる。
別名みたいなもの。Functor

変数 = f
変数 = f( )

上は、関数の代入で、
下は、関数の呼び出し

( ) が、関数呼び出し演算子

553 :デフォルトの名無しさん:2020/05/05(火) 10:37:45.75 ID:esp/1iza.net
>>551
Web制作板確認したが、相変わらずだな
まあ俺はこのレベルの馬鹿を引き取ってくれることには大賛成だから、どうぞよろしく、でしかないが

554 :549:2020/05/05(火) 10:39:12.27 ID:esp/1iza.net
>>549
お前もprototype継承を特別視過ぎ

> 前半部分は"Object"という名前のオブジェクトがグローバルに存在するということに想像が及ばないと理解しづらいだろうし、
Javaにも全く同じ立ち位置のObjectが存在してる
Javaを知らないか、知っててピンと来ない=単なる馬鹿か

> 後半は「基本オブジェクト」というwell-definedでない言葉で説明しているが
C#でも全く同じ表現だ
> Object クラス
> これは、全 .NET クラスの基本クラスであり、型階層のルートです。
> https://docs.microsoft.com/ja-jp/dotnet/api/system.object?view=netcore-3.1
prototypeベースだからクラスではなくオブジェクトとなっている
だからこの表現で正しいんだよ

> オブジェクト指向の理解とは関係ないJavaScript固有の話だと思うがな。
これもダウト
> 多くの言語では、このように継承元を書かずに、クラスを定義した場合は、Object クラスから直接継承したとみなされる (550)
ホントかよ、と思ったが、少なくともJavaとC#ではそうなるようだ(JavaScriptもだが)
これは本来は言語ではなくフレームワークの仕様であり、C++はそうなのだが、
少なくともJavaとC#は最初からオブジェクト指向大前提(のフレームワークを使う前提)でしか使えない仕様らしい
が、それはさておき、全ての型のルートを持ってボックス化出来るようになっており、それを利用する、というのは、
典型的なオブジェクト指向の使い方であって、JavaScript固有の話でも何でもない
というか、むしろ、JavaScript固有の話なんて何もない
prototypeも別にJavaScriptが発明したものでもない
初見だとそれなりに戸惑う、というだけ
ただしJavaScriptのオブジェクト指向なんてJava/C#のオブジェクト指向からすると全く使い物にならない物だし、
実際にボックス化やアップ/ダウンキャスト等を考える必要なんてほぼ無いだろ

お前自身もオブジェクト指向を正しく理解出来てないのだと思うぜ

555 :デフォルトの名無しさん:2020/05/05(火) 10:56:56 ID:ZXlt5r8n.net
「Objectオブジェクト」といきなり言われて、それがJavaのObjectクラスのようなものと
想像できなくても別に不思議はないかと。

556 :デフォルトの名無しさん:2020/05/05(火) 11:16:54.06 ID:esp/1iza.net
>>555
ねえよ
俺はそれは単なる馬鹿だとしか認識しない
少なくともこの馬鹿はJavaもオブジェクト指向もマスターしてるつもりなんだぜ

自分が何も知らないことを自覚できず、
> (ワラ
とかやってるから馬鹿のままなんだよ
こいつは既に老害化してる
JavaですらJava8(2014)から関数ポインタを使えるようになってる
こいつはこのことすら知らない
といっても実際Java界隈なんてその程度だとは思うが

オブジェクト指向を利用してコードを共通化しようとすると、どうしても
C++のように型消去するか、
JavaやC#やJavaScriptのObjectのような型階層のルートが必要になってくる
これらの言語で全てそれが「Object」という名前で統一されているのは偶然ではない
オブジェクト指向(=ObjectOriented)のルートだからObjectなんだよ
今時のメジャー言語は全てオブジェクト指向出来るようになってるし、
逆に、「Object」とかいう物が出てきたら、これか!とピンと来ない方がおかしい

つっても重ねて言うが、Javaの連中なんてその程度なのも事実だが

557 :デフォルトの名無しさん:2020/05/05(火) 11:26:22.49 ID:GGtHBQ+v.net
>>556
関数ポインタと参照は違うって知ってる?

558 :デフォルトの名無しさん:2020/05/05(火) 11:39:37 ID:esp/1iza.net
>>557
勿論知ってるぞ

Javaのが「関数ポインタ」ではなく「関数参照」だというのならそうなのだろう
見て分かるとおり、俺はJavaは使ってないからその辺は正確ではない

ただぶっちゃけ、ポインタと参照はほぼ等価だし、
C++のようにそれらが別物だと明示的な言語以外では混同してても全く問題ないと思うが
実際、JavaScriptにおいて「参照」を「ポインタ」と言い換えても何ら問題ないだろ

どう見ても俺の揚げ足取りをしようとしているように見えるが、
それが価値あると思うなら頑張ってどうぞ
ただし俺は馬鹿と話す意味はないと見たらすぐ降りる
その場合はお前の勝ちでいい


んで、関数ポインタと参照の違いを知っているお前は、どんな素晴らしい知見を披露してくれるの?
是非よろしく

559 :デフォルトの名無しさん:2020/05/05(火) 11:48:55 ID:n32zrCmj.net
> 実際、JavaScriptにおいて「参照」を「ポインタ」と言い換えても何ら問題ないだろ

だめ。ポインタは数値で置き換えられるアドレスであり
ポインタはアドレス加算などの演算ができるもの
アドレス加算ができない以上それは参照であってポインタではない
そしてJavaで参照はずっと前からできる

560 :デフォルトの名無しさん:2020/05/05(火) 12:10:13 ID:esp/1iza.net
>>559
> そしてJavaで参照はずっと前からできる
Java8で新しく出来るようになったのは、『関数』参照な
話をずらすな
そして>>547が理解出来てないのはこれだ

> ポインタはアドレス加算などの演算ができるもの
> アドレス加算ができない以上それは参照であってポインタではない
それはC++での定義な
RustやGoも「ポインタ」を扱えるが、こちらは最初から加算なんて出来ないようになっている(確か)
少なくともRustやGoの定義する「ポインタ」はそう

というか、C++の参照自体が「ポインタは危険なのでコンパイラ側で対策して『参照』と命名しました」でしかないし、
JavaやC#で言う参照も全くこれと同じなのだが、当然実体は「ポインタ」でしかなく、
当然関数呼び出しの引数にはまんま「ポインタ」が積まれる

というかそこら辺理解出来てないのはやっぱりJavaしか知らない馬鹿だからだ
ポインタと参照が実体は同じだ、ということを理解出来ないのも
(論理的な意味が違うだけで、物理的な意味や値は同じ)


いずれにしてもJavaってのはかなり簡素化された言語で、
コンピューターの実体(物理構造)を知らなくてもいいように出来ている
これ自体はいいことなのだが、
その程度の知識なのに「ポインタと参照は違う(キリッ」とかやるのは間違ってる
自分の知識が全く足りてないことを認めて、きちんと学んだ方がいい
ポインタはCの鬼門だとされているが、現実として、ポインタを扱った方が動作効率が圧倒的によく、
結果的にJavaでもJavaScriptでも、或いは他言語でも、内部動作はポインタで作られているので、
どうしてこういう動きをするのか、どうしてこういう仕様なのか、を理解するのは、ポインタの理解が不可欠だ
ある程度以上のプログラマになる為には、ポインタの理解から逃げているようでは無理だ
これが逆にJavaプログラマが相変わらず糞な遠因でもある

561 :デフォルトの名無しさん:2020/05/07(木) 13:23:56.11 ID:fANici3H.net
>>547
> いやJavaはひととおりマスターしたから
> オブジェクト指向はバッチリ理解している。

>548
> Javaは体系的にスッキリしてるから実に分かりやすい。

プログラミング言語をJavaしか使ったことないJavaおじさんか?

562 :デフォルトの名無しさん:2020/05/07(木) 22:35:41 ID:U9K3TqbR.net
>>561
この話題を続ける意味もないと思うが

Javaおじさんですらないはず
多分Java若者馬鹿老害

Java8で関数ポインタが導入された為、
それ以前に完全にJava7をマスターしている「Javaおじさん」なら導入するかどうかの大議論をしているはず
少なくともJavaの一線で働いている奴が知識を6年間もupdateしてないとは考えづらい
使ったことが無くても、また、(コーディングルール上)職場で使えないとしても、全く知らないというのはない(と思いたい)
そしてオブジェクト指向への理解も皆無だ、これは「Javaおじさん」ならあり得ない

最近の若者はプログラミング言語の選択肢が多く、若干戸惑っているように思える
ぶっちゃけ最初の最初の言語なんてどれでも大差ないのだが、「僕が選んで学んだ言語すごい=僕すごい」をやる奴が多すぎる
こいつも何らかの理由でJavaを選択し、「Javaすごい」とポジショントークをしているだけ
おそらく年齢は20代、プログラミング言語はJavaしか知らず、Java7の本でJavaを勉強した人だ
ただこの時点でこの老害っぷりは酷い
一応言っておくが、年齢ではなく、自分の考え方が絶対に正しいと固執し始めると老害になる
546はもうちょっと真摯にプログラミングをした方がいい

ただしJavaがスッキリ、というか、簡単なのは事実だ
だから大受けした
そしてPythonの方がもっと簡単だから、もっと大受けしつつあるだけ


ただ現実問題として、JavaScriptのオブジェクト指向なんてどうせ使い物にならないから、無視でいい
しかしまた現実として、今現在のシェアはJavaScript>Javaなのだから、
どうしてそうなったのかが理解出来ないうちは「Javaすごい=僕すごい」みたいな幼稚な考え方は止めた方がいい
Java自体が凄かったのも事実だが、それも過去になりつつある

563 :デフォルトの名無しさん:2020/05/12(火) 13:08:44 ID:4J1vnKbM.net
'(シングルクウォーテーション)と"(ダブルクウォーテーション)の使い分けに悩みます。
悩みを消しこれだと自信を持って使う考え方はありますか?
どっちを使ってもいい場合とどちらか限定の使い方があるので気持ち悪いですw

564 :デフォルトの名無しさん:2020/05/12(火) 13:33:40 ID:01D/nxpT.net
>>563
シェルスクリプトだと、'と"とは、展開の有無等であきらかに異なるから、
それにしたがって使い分ける。

どちらも同じって場合は、文字列に空白が含まれる場合や入れ子になる場合に"を使って、
その他、基本的には'でくくってる。
jsやpythonなんかがこれに該当。

"しか使えないバッチファイルは文句なしに"。
ただし、*nix由来のプログラムの場合、オプション内部で'を入れ子で使うことがある。

こんな感じ?

565 :デフォルトの名無しさん:2020/05/13(水) 06:16:03.92 ID:VSt/R8YQ.net
VSCode のデフォルトが、Beautify だろ。
拡張機能のPrettier とか

'・" かどうかは、これらの設定で変わる

HTML の属性が、" で囲むから、それらの文字列をさらに囲むには、' を使う

JavaScript の話は、web 制作管理板の方で聞いてください!
この板には、あまり人がいないから

566 :質問者:2020/05/13(水) 13:14:18.33 ID:5xfr/P29.net
こちらで良いかわかりませんが、
・web上でモニタリングをしたい
・10秒ごとに自動更新
・固定htmlに要素を用意。javascriptで変数を持ち、値によって要素の画像を切り替える。
getElementById(*).src=****
setTimeout(this,10000)
これをサーバーに置いて10人くらいがアクセスしたら、サーバーの負荷はどうでしょうか?
画像切り替えるときにサーバーにアクセスするので、やはりだめでしょうか?
わかる方いましたらお願いいたします。

567 :デフォルトの名無しさん:2020/05/13(水) 13:59:35.07 ID:VSt/R8YQ.net
数枚程度なら、すべての画像を送ってしまって、
ブラウザ側で、スライダーなどで切り替える

Google map みたいに、無数の画像があるなら、
ajax でサーバー側にアクセスして、必要な画像を送ってもらう

JavaScript の話は、web 制作管理板の方で聞いてください!
この板には、あまり人がいないから

568 :デフォルトの名無しさん:2020/05/13(水) 14:02:19.06 ID:WBibu7Ic.net
>>566
いろいろイミフ

>・web上でモニタリングをしたい
誰が何をどうやってモニタリングするの?

>・10秒ごとに自動更新
何を更新するの?

>これをサーバーに置いて10人くらいがアクセスしたら、サーバーの負荷はどうでしょうか?
クライアント側JavaScriptの話でサーバー負荷とどう関係があるの?

569 :デフォルトの名無しさん:2020/05/13(水) 14:12:08.64 ID:shZVwRy5.net
>>564
そうざますかありがとう
どっちみち慣れないうちは混乱しますね
JSだけのエンジニアなら当然その人の哲学や宗教により迷わず判断してると思うけど
こっちはJSは片手間でやっててさわるのが数年ぶりということがあるから混乱しますわ

570 :デフォルトの名無しさん:2020/05/13(水) 14:14:46.69 ID:URUm4HTQ.net
何の要素か知らんが、
「cssで作るスライドショー」とかでググったら答えが落ちてそう

571 :デフォルトの名無しさん:2020/05/13(水) 14:21:07.89 ID:WBibu7Ic.net
>>569
自分で決められないならとりあえずビッグネームのstyle guideに従っとけばいい

JavaScript =>single quote
HTML => double quote
CSS => single quote
https://google.github.io/styleguide/jsguide.html#features-strings-use-single-quotes
https://google.github.io/styleguide/htmlcssguide.html#HTML_Quotation_Marks
https://google.github.io/styleguide/htmlcssguide.html#CSS_Quotation_Marks

572 :質問者:2020/05/13(水) 15:12:19.72 ID:5xfr/P29.net
>>567
ありがとうございます。

>>568

>>・web上でモニタリングをしたい
>誰が何をどうやってモニタリングするの?

やりたい事は、100個のセンサや機械の情報をブラウザ上にリアルタイムで表示して、異常ならば、ブラウザを見てる人に通知したいということです。

>・10秒ごとに自動更新
センサーや機械の情報です。


>>これをサーバーに置いて10人くらいがアクセスしたら、サーバーの負荷はどうでしょうか?
>クライアント側JavaScriptの話でサーバー負荷とどう関係があるの?

javascriptで動的にイメージ画像を切り替えたら、結局サーバーにアクセスすることになってしまうのではと思ったのです。
画像イメージはサーバー上に置かれているので。一回アクセスしたらキャッシュされるかもしれませんが。

>>570
ありがとうございます。

573 :デフォルトの名無しさん:2020/05/13(水) 15:52:15 ID:WBibu7Ic.net
>>572
なるほど

サーバー側のセンサーや機械の状態更新を
クライアントからのアクセスによってトリガーする仕組みだと不味いけど
そうじゃなくてサーバー側ですでに存在してるデータに対して
10人くらいが数秒に1回アクセスするんなら
その負荷は微々たるものだよ

各状態に応じた画像は
最初にモニタリング用画面にアクセスした時に全部ダウンロードさせておいて
数秒に1回AJAXでサーバー側の状態のみ取得してその値によって画面表示を切り替えればいい

574 :質問者:2020/05/13(水) 16:03:47.03 ID:5xfr/P29.net
>>573
そうです。

>最初にモニタリング用画面にアクセスした時に全部ダウンロードさせておいて

この技術がわかりません。何をキーワードにして調べれば良いのでしょうか、すみませんが、お願いいたします。

575 :質問者:2020/05/13(水) 16:51:28.10 ID:5xfr/P29.net
すみません。解決しました。
最初にリロードしたときに正常な画像だけでなく、異常な画像もリンク(表示しない)しておけばよいのですね。
そうしておけばブラウザ側にキャッシュされるので。

576 :デフォルトの名無しさん:2020/05/13(水) 17:25:36.80 ID:WBibu7Ic.net
>>575
いろいろ方法あるけど一番堅いのはCSSスプライト
https://developer.mozilla.org/ja/docs/Web/CSS/CSS_Images/Implementing_image_sprites_in_CSS

他には
- visibility: hidden
- JavaScriptでページロード時に画像を読み込む
- 凡例として異常時の画像も一つ表示しておく
など

この辺の話はJSのプログラミングの話じゃないので
誰か書いてたけどweb制作板で聞いたほうがいいかも

577 :質問者:2020/05/13(水) 17:50:05 ID:5xfr/P29.net
>>576

本当にいろいろとありがとうございました。

578 :564:2020/05/13(水) 18:01:05 ID:VSt/R8YQ.net
>>569

>>565
にも書いたけど、

VSCode のデフォルトが、Beautify で、拡張機能のPrettier が有名

Ruby on Rails で有名な、Airbnb などのStyle Guide だろ

579 :デフォルトの名無しさん:2020/05/13(水) 18:09:08 ID:VSt/R8YQ.net
>>572
>画像イメージはサーバー上に置かれているので。一回アクセスしたらキャッシュされるかもしれません
確かに、同じファイルパスなら、キャッシュを使う

データは、ajax で、JSON でやりとりすることが定番

580 :質問者:2020/05/14(木) 00:27:54.68 ID:XcM6moP2.net
>>579

はい、ありがとうございます。

581 :デフォルトの名無しさん:2020/06/20(土) 11:09:53 ID:iiFnSxTf.net
できる訳ないだろうなと思いつつ聞くんだけど、javascriptでローカルのファイルを別のディレクトリに移動させたりすることってできる?

582 :デフォルトの名無しさん:2020/06/20(土) 13:24:24 ID:hfA4Ec7B.net
つNode

583 :デフォルトの名無しさん:2020/06/20(土) 13:27:05 ID:hfA4Ec7B.net
つcscript/wscript

584 :デフォルトの名無しさん:2020/06/20(土) 20:45:20.50 ID:iiFnSxTf.net
>>582
これはサーバサイドでjs書いたときの話だもんね

ユーザーがブラウザ操作してる時に動くブラウザ上のjsでファイル操作がしたいんだよなあ
そんなこと出来たらやべーからまあ無理なんだろうけど、なんか代わりの手段ないものか

585 :デフォルトの名無しさん:2020/06/20(土) 21:17:03.49 ID:hfA4Ec7B.net
>>584
プラットフォームとしてブラウザが欲しいのなら electron = chromium + node がそれだろ。
代表アプリはatomとVSCode。
サイトのJSでユーザーのローカルファイルを弄りたいというのなら、それが出来るようなら困るだろ。

586 :デフォルトの名無しさん:2020/06/20(土) 21:21:46.31 ID:hfA4Ec7B.net
>>584
あと、今現在使っていいか、使えるか、というのはあるが、技術的にはActiveX。
wiki読めば大体分かるはず。

587 :デフォルトの名無しさん:2020/06/29(月) 12:03:45.83 ID:Na3g7Gku.net
うんち

588 :デフォルトの名無しさん:2020/06/29(月) 12:04:05.78 ID:Na3g7Gku.net
htmlタグに書くonclick=の中には
JSの処理を直接書くこともfunction(){}と書いてその中に処理を書くことも、どちらもokですか?その違いはありますか?

589 :デフォルトの名無しさん:2020/06/29(月) 12:07:23.28 ID:Na3g7Gku.net
onclick=のあと関数名(関数が入った変数)を書く場合は()は書かないほうがいいですか?書くべきですか?


<button onclick='unko'> or <button onclick='unko()'>

unko=function(){
alert('unko!');
}

みたいなときです。

590 :デフォルトの名無しさん:2020/06/29(月) 12:51:41.62 ID:I7ZZ3pdS.net
最初に喧嘩売ってきてわろた

591 :デフォルトの名無しさん:2020/06/29(月) 12:54:40.10 ID:ze6DZkOI.net
>>588
こういう感じで、直接内容も書けるみたい

on@click='con@sole.log("abc")'

注意! 書き込めないため、@ を入れました

>>589
on@click='unko()'

みたいに、すべて( ) が付いている

それと、JavaScript の質問は、web制作管理板の方へ書き込んでください!

こちらの板は、web制作管理板が荒らしに荒らされた時に、
緊急避難的に立てられたものだから、今は使われていない

592 :デフォルトの名無しさん:2020/06/29(月) 21:14:29 ID:WKcpUWSm.net
>>587-589
オムツがまだ取れてなくてウンコ臭い初心者はWeb板へ
何度も言われていることだが

それ以前にお前レベルの超超超超初心者はそもそもここ(5ch)に来るべきではない
各自が勝手に意見を言ってるだけだから、それなりの確率で間違いや勘違いはどうしても発生する
それを自分で修正する能力がないうちは、5chを使うのは止めた方がいい
超超超超初心者なら、少なくとも間違っていたら訂正してもらえる場所、
つまり本か信頼出来るWebサイトを参考にするべきだ

なお俺はお前みたいなウンコお漏らし初心者用の本やサイトは知らない
というか、そんな、始めて3時間で通過するレベルの事柄を、ネットで質問しようとすること自体、かなり頭がおかしい
少なくともお前はプログラマには向いてないし、間違って就職しても浮きまくって仲間に入れず不幸な人生になるから止めとけ
それを教えてもらいたければ、「1週間の集中講座ででWebページ開設出来ます!」みたいなセミナーとかに行け
JavaScriptの部を始めて10分後にはそれについて教えてくれるだろう

593 :デフォルトの名無しさん:2020/06/30(火) 01:12:09.33 ID:l6PnVpoX.net
>>552
通りすがりだけどソレみて長年のモヤモヤがはれました、ありがとう。

594 :デフォルトの名無しさん:2020/07/23(木) 00:01:42.43 ID:qAfVnVsp.net
$("div").click(function())

595 :デフォルトの名無しさん:2020/07/23(木) 00:02:03.83 ID:qAfVnVsp.net
$("div").click(function(){
})

596 :デフォルトの名無しさん:2020/07/23(木) 00:05:54.40 ID:qAfVnVsp.net
$("div").click(function(){
$(this).css('background','red');
})

のこの$(this)が$("div")を指す理由はなんですか?
Javaではthisというのはそれを定義したクラスのインスタンスを指すと習いましたが。

597 :デフォルトの名無しさん:2020/07/23(木) 00:38:57.14 ID:cGFBf2BV.net
jQuery, Haxe のthis は、JavaScript/TypeScript のthis とは異なる。
this がwindow を指したり、おかしな部分があるので、それを変えている

それと、JavaScript の質問は、web制作管理板の方へ書き込んでください!

こちらの板は、web制作管理板が荒らしに荒らされた時に、
緊急避難的に立てられたものだから、今は使われていない

598 :デフォルトの名無しさん:2020/07/23(木) 07:12:59.16 ID:qAfVnVsp.net
>>597
「おかしな部分があるので、それを変えている」とは?

599 :デフォルトの名無しさん:2020/07/23(木) 07:13:47.98 ID:qAfVnVsp.net
thisの正体を見分けるコツはないですか?

600 :デフォルトの名無しさん:2020/07/23(木) 07:32:15.26 ID:/b5pS+w+.net
>>596
> のこの$(this)が$("div")を指す理由はなんですか?

DOM APIとの互換性

例えば、これのイベントハンドラの中身を書き換えるならば
$("div").click(function(){
  $(this).css('background','red');
})

このようになる。(おまけで引数のjQuery eventを追加)
$("div").click(function(event){
  this.style.background = 'red';
})

このイベントハンドラ(function)はDOM APIと互換性があるので全く同じように使える。
(引数のeventはjQuery eventではなくDOM APIの eventだがある程度の互換性がある)
divElement.addEventListener('click', unction(event){
  this.style.background = 'red';
})

つまりイベントハンドラをDOM APIのものと互換性があるようにしているのが理由
そうすることで、コードを相互に変換しやすくなる。
例えば後からjQuery化するときなど少しずつ移植できる。

601 :デフォルトの名無しさん:2020/07/23(木) 07:36:27.79 ID:/b5pS+w+.net
>>599
thisは実行時に変わるからコードを見てもわからない
つまり呼び出されているコードを見てもわからない。
「誰が呼び出しているか?」を知る必要がある。

同じthisであっても「あれ」に登録して「あれ」から
呼び出されれば「それ」とは違うthisの場合がある。

だからthisが何かは仕様を調べるしかない
関数の引数にobjが入ってる場合、このobjの正体はなんですか?と
言ってるのと同じ質問だよ

602 :デフォルトの名無しさん:2020/07/23(木) 07:39:49 ID:/b5pS+w+.net
>596
Javaではthisを変えられることができないが
JavaScriptはthisは呼び出し側で与えるオブジェクト
JavaScriptだけではなくRubyやPerlなどいくつかの言語は呼び出し側でthisを変更できる

603 :デフォルトの名無しさん:2020/07/23(木) 08:18:34.22 ID:qAfVnVsp.net
>>600-602
ありがとうございます。
深いですね。
まだちゃんと理解できてないですが
ゆっくり吟味して考えてみます。

604 :デフォルトの名無しさん:2020/07/23(木) 08:20:56.24 ID:qAfVnVsp.net
this=eventとなっているということかな?

605 :デフォルトの名無しさん:2020/07/23(木) 08:24:35.38 ID:/b5pS+w+.net
>>604
違うぞ。eventはおまけ。thisの話とは直接関係ない

606 :デフォルトの名無しさん:2020/07/23(木) 08:25:10.27 ID:/b5pS+w+.net
ようするにjQueryはブラウザ標準のDOM APIと
互換性をもたせて作られているということ

607 :デフォルトの名無しさん:2020/07/23(木) 20:38:07.50 ID:QHkNbR5l.net
>>599
ID:/b5pS+w+ の言っていることは全面的に正しいが、補足すると、
> thisの正体を見分けるコツはないですか?
こんな事を言っている時点で糞サイト(或いはゴミ本)に騙されているから止めとけ。
見分ける必然性も意味もない。単なる暗黙の引数程度でしかなく、
実際にそれなりに組織的にコーディングするとcallはそれなりに使う。

DOM APIのthisがe.currentTargetを指すのはそもそもJava用の仕様、
つまりJavaでもクライアントスクリプトを書けるようにする為の仕様らしい。(とここ5chで聞いた)
しかし現在はJavaで書く奴なんて一人もいないし、JavaScriptにおいてはe.targetを全面的に使うのが正しい。
理由は、
1. thisにはe.currentTargetが入っているが、マトモなサイトなら通常はbubbleを利用する為、e.target主体で書くことになる。
 つまりこの仕様のthisでは使い物にならない。
2. e.currentTragetで役に立つ場合は、Elementに直接onXXXかaddEventListenerした場合だが、
 こんな事をやっているのはjQueryを使っている程度の簡単なサイトだけ。
 やれば分かるがbubbleを利用した方が実行効率もよく、コードも綺麗になるから、マトモなサイトは全部そうしてる。
 ただし、Elementに直接貼った方が直感的で分かりやすいので、jQueryのような簡単/初心者向けの場合には活用される。
 (なおjQueryでもbubble主体で書くことは可能ではあるが、それをやるとjQueryの意味がほぼ無くなるので普通はやってないと思う)

608 :デフォルトの名無しさん:2020/07/23(木) 20:39:00.72 ID:QHkNbR5l.net
3. それなりに組織的にコーディングすると、どうしてもイベントハンドラで共通の関数を使いたい要求が出てくる。
 しかしイベントハンドラだとthisがe.currentTargetによって潰されているので、共通関数をクロージャ(最終段はグローバル)で掴むしかないが、
 クロージャはクローズ(追加不能だしコード配置が限定される=C++で言うクラスはクローズ、namespaceはオープンと同じ意味のクローズ)ので、
 現実的には使いにくく、俺はイベントハンドラを集めたオブジェクト(その中に共通関数も入っている)をthisとしてcallし直して、
 イベントハンドラ内ではthis.my_sub_function()で共通関数を呼べるようにしている。
 この場合、thisは単なるオブジェクトなので、継承出来るのがいい。(共通関数の共通関数を__proto__側に追い出せる)
 どうせthisが使い物にならない仕様なので他の連中も同様にやっているとは思う。

なお俺はjQuery不要派だがjQuery自体は初心者には分かりやすく偉大だと思っている。
実際にjQueryを使っていて問題ないのなら使うこと自体も悪いことではない。
ただしそれは世の中のマトモなサイト≒ガチのプログラマーが本気で書いたサイトではほぼ使われていない手法だということも理解しておいた方がいい。
といっても今の君には分からないだろうが、イベントハンドラ内でthisをe.currentTargetとして利用することはガチのサイトではほぼ無い、ということ。
今はどうせ何も分かってない状態なんだろうから、それならイベントハンドラ内ではthisを使わずe.currentTargetを使う癖を付けた方が多分いい。
それ以前にbubbleを使うようにした方がいいが。

609 :デフォルトの名無しさん:2020/07/23(木) 20:41:48.09 ID:QHkNbR5l.net
といっても多分さっぱり何がなにやら、だと思うが、そういうものだと思っておいてくれ。
質問の質問を受けていたら話が進まないのでそれは断る。

610 :デフォルトの名無しさん:2020/07/23(木) 21:58:10.24 ID:k24nyzXR.net
>>607
>  (なおjQueryでもbubble主体で書くことは可能ではあるが、それをやるとjQueryの意味がほぼ無くなるので普通はやってないと思う)

イベントのキャプチャフェーズとバブリングフェーズの話をしてるなら
jQueryはバブリングフェーズしか対応してません
jQueryの意味がなくなる?なぜですか?

そもそもIE8以前がキャプチャフェーズに対応してないので
それ以前からあるjQueryでは実装が不可能です。
(jQuery 4.0では実装されるらしい)


間違ったことを書かないでください

611 :デフォルトの名無しさん:2020/07/23(木) 22:00:14.35 ID:k24nyzXR.net
>>608
> 現実的には使いにくく、俺はイベントハンドラを集めたオブジェクト(その中に共通関数も入っている)をthisとしてcallし直して、
> イベントハンドラ内ではthis.my_sub_function()で共通関数を呼べるようにしている。
> この場合、thisは単なるオブジェクトなので、継承出来るのがいい。(共通関数の共通関数を__proto__側に追い出せる)

やめましょう。無関係のイベントハンドラをまとめることは
単一責任の原則に違反しています。

612 :デフォルトの名無しさん:2020/07/23(木) 22:01:00.61 ID:k24nyzXR.net
>>608
> イベントハンドラ内でthisをe.currentTargetとして利用することはガチのサイトではほぼ無い、ということ。
いいえ。殆どがthisを使っています。e.currentTargetは冗長なだけです。

613 :デフォルトの名無しさん:2020/07/23(木) 22:41:43.25 ID:k24nyzXR.net
>>607
> DOM APIのthisがe.currentTargetを指すのはそもそもJava用の仕様、
> つまりJavaでもクライアントスクリプトを書けるようにする為の仕様らしい。(とここ5chで聞いた)

逆です。Javaではe.currentTargetを使い、thisは使えません。
(当時の)Javaでは言語仕様上の制限でイベントハンドラとして関数を使用することはできません。
イベントハンドラはオブジェクトである必要があります。

イベントハンドラ自体がオブジェクトであるため、thisはイベントハンドラオブジェクトになります。
そのためJavaでthisは使えません。

また昔のIEはaddEventListnerがなくattachEventを使いますが。
attachEventの場合thisはwindowでありe.currentTargetではありません。
つまり初期のIEのDOM APIはもちろんJavaでも使えますが
event.srcElement(e.currentTarget相当)しか実装されてないということです。
thisがe.currentTargetなのはJavaScriptのために作られた仕様です。

614 :デフォルトの名無しさん:2020/07/23(木) 22:44:12.81 ID:k24nyzXR.net
>>607
> JavaScriptにおいてはe.targetを全面的に使うのが正しい。
いいえ。e.targetは廃止されてます。
https://developer.mozilla.org/ja/docs/Web/API/Event/target

わざと正反対のことを書いてるんですかね?

615 :デフォルトの名無しさん:2020/07/23(木) 22:47:04.66 ID:QHkNbR5l.net
>>610
キャプチャフェーズの話はしてない。
なお俺の判断では、キャプチャフェーズは余程のパッチ当て以外では使うべきではない。
あれは使わないでも十分組めるし、そもそもキャプチャフェーズを使わなければならないシチュエーションがまるでない。
だから俺は何であの仕様が入れられたのか不明なのだが、君はそれが分かるか?
具体的に、キャプチャフェーズのユースケースを知りたい。

> jQueryの意味がなくなる?なぜですか?
jQueryは基本的に
queryしたElementに何か(この場合はイベント追加)するのを宣言スタイルで短く分かりやすく書けるのが売りだろ。
バブル主体で書くとそもそもqueryしないから、jQueryを使う意味がないんだよ。
それはやれば分かる。分からないのはやってないからでしかない。

> やめましょう。無関係のイベントハンドラをまとめることは
> 単一責任の原則に違反しています。
無関係ではないんだよ。
そしてその考え方がJava的オブジェクト指向の限界であり、JavaでGUIを誰もやらない理由だよ。
いずれにしても、JavaのGUIなんてキングオブゴミだし、GUIに関してはJava的オブジェクト指向は一旦捨てた方がいい。
実際、.NETにしても、データはバインディングでグローバルストア方式になってるだろ。
(末端のオブジェクトにデータを持たせている風に見せているが、
現実問題としてそれだと状態のセーブが出来なくて(やりにくくて)いきなり詰むから、実際はバインディングでゴニョゴニョ出来るようにしている)
だからJava的な、末端のオブジェクトにデータもイベント関数も全部持たせる、というのがGUIに絶望的に向いてないんだよ。
だからJavaではろくなGUIが作れない、というよりは無駄に苦労するので誰もやらない。その結果が今だ。

> いいえ。殆どがthisを使っています。e.currentTargetは冗長なだけです。
それは君がbubbleを使ってないから。jQueryもだがフレームワーク等は仕様はDOMAPIに合わせているだろうけど、
実際にbubbleの場合はe.currentTargetなんて使い物にならないから当然thisも使わない。
これもやれば分かるだけのこと。君はやってないだけ。

616 :デフォルトの名無しさん:2020/07/23(木) 22:49:01.44 ID:k24nyzXR.net
>>615
> バブル主体で書くとそもそもqueryしないから

そういう意味ですか?
意味不明なので他のわかりやすいサイトを
探し出してください

617 :デフォルトの名無しさん:2020/07/23(木) 22:49:21.91 ID:k24nyzXR.net
×そういう意味ですか?
○どういう意味ですか?

618 :デフォルトの名無しさん:2020/07/23(木) 22:50:10.57 ID:k24nyzXR.net
>それは君がbubbleを使ってないから。

bubbleを使うとやらのコードを書いてください

619 :デフォルトの名無しさん:2020/07/23(木) 22:53:40.02 ID:k24nyzXR.net
Description: The current DOM element within the event 「bubbling」 phase.
https://api.jquery.com/event.currentTarget/

620 :デフォルトの名無しさん:2020/07/23(木) 22:53:41.19 ID:QHkNbR5l.net
>>613
いや俺はthisがオブジェクトそのものだと聞いたが、
まあJavaの仕様については俺は詳しくないし、いずれにしてもスレチだし、この話は止めよう。

>>614
それは初耳だが、
LS見た限り当然載っているから移動されただけではないか?
そのページのLSの所押すと割と丁度いい場所に飛ぶから見てみればいい。

やれば分かるが、バブルで組んだ場合にe.target無しでは組めない。
廃止されるにしても、名前が変わって何かが定義されるとかであって、丸々捨てられることはないよ。
そしてbubbleを使わずに一々全Elementにイベントを付けていくのは完全に旧式であって、
マトモなサイトでは誰もそんなことやってない。
それも確認してみればいい。

621 :デフォルトの名無しさん:2020/07/23(木) 22:54:31.55 ID:k24nyzXR.net
jQuery event.currentTarget
日本語訳 説明:イベントバブリングフェーズ内の現在のDOM要素。

622 :デフォルトの名無しさん:2020/07/23(木) 22:55:20.17 ID:k24nyzXR.net
>>620
だからjQueryはバブルしかサポートしてないし、
jQueryのevent.currentTargetは(DOM APIと同じで)
イベントバブリングフェーズ内の現在のDOM要素。

623 :デフォルトの名無しさん:2020/07/23(木) 22:57:37.04 ID:k24nyzXR.net
>>620
> そしてbubbleを使わずに一々全Elementにイベントを付けていくのは完全に旧式であって、

jQueryでは全Elementにイベントハンドラを使えずに、
ocumentエレメントにイベントハンドラを付ける場合このように書きます。

$(document).on('click', 'a', function() {
 $(this).css("background": "red");
});

知ってましたか?w

624 :デフォルトの名無しさん:2020/07/23(木) 23:16:41.69 ID:k24nyzXR.net
https://jsfiddle.net/m8q15376/

例えばこの2つのコードはイベントハンドラをつけてるところは違いますが
同じよう動作をします。thisが使えない?何の話でしょうかねw

$("#id1").on('click', 'a', function() {
 $(this).css("background", "red");
});

$("#id2 a").on('click', function() {
 $(this).css("background", "red");
});

625 :デフォルトの名無しさん:2020/07/23(木) 23:18:15.34 ID:QHkNbR5l.net
>>622
君と話が通じないのは君がbubble主体で組んだことがないからだよ。
ただし、bubbleの重要性に触れた『初心者向け』サイトは皆無で、俺が知ってるのはuhyohyoだけ。
気になるならそこでも読むんだね。
或いはそこら辺のまともなサイト、ガチの商用サイトだとbubbleを使ってない方が珍しい(と思いたい)から、見てみるとか。
ただし日本のサイトは割とまじで糞で、20年前と同じですねー、ってのも普通にあるからそういうところは駄目だが。
(ここ5chもそうだし)

ちなみに2度目だが、フェースの話はしてない。
イベントがバブルするのを「イベントバブル」と言うんだよ。
これはWPF等でも使われているからJavaScriptのローカル用語ではなくてプログラミング用語だ。
(といっても俺が知っている限りイベントバブルを最初に実装したフレームワークはHTMLで、
それらをWPF等も採り入れたから当然同じ用語になっているだけだが)
そしてそれをbubbleと(短く短くとうるさいお前ら用に)略して言っているだけ。
もう一度言うが、フェーズの話はしてないし、そもそも既に書いたように俺はキャプチャフェーズの存在価値が分からない。
今のところの見方では、あれは不要な仕様だと思う。
jQueryでも対応してないのなら、実際それで困ることはないからだろ。


>>623
知ってる。そしてそれだとjQueryを使う意味が無い=生のDOMAPIでも同様に書けるだろ
だからみんなjQueryを捨て始めてるだけ。
勿論君のようにjQueryが無いと死んじゃう人がそれに抗っているのも知ってる。

626 :デフォルトの名無しさん:2020/07/23(木) 23:21:08.33 ID:k24nyzXR.net
もうわかりましたね? ID:QHkNbR5l はイベントデリゲーションのことを
バブルなんて言ってるわけです(笑)

https://developer.mozilla.org/ja/docs/Web/API/Event/target
> event.target プロパティは、イベントデリゲーションを実装するために使用できます。

所詮オレオレ用語を使うレベルなんですよ

627 :デフォルトの名無しさん:2020/07/23(木) 23:22:10.11 ID:QHkNbR5l.net
>>624
だからそれ明らかにイベントバブル使ってないじゃん。
それを>>623形式で書いた時にe.targetが無いとどうしようもないでしょ。
それを言ってるんだよ。

628 :デフォルトの名無しさん:2020/07/23(木) 23:22:48.51 ID:k24nyzXR.net
>>625
> 知ってる。そしてそれだとjQueryを使う意味が無い=生のDOMAPIでも同様に書けるだろ

では生のDOM APIを使ってe.targetなしで書いてみてください。
できますか? jQueryはe.targetなしで書きました。

629 :デフォルトの名無しさん:2020/07/23(木) 23:23:26.39 ID:k24nyzXR.net
>>627
> だからそれ明らかにイベントバブル使ってないじゃん。]

最初に言ったよね?イベントバブル使うコードかけって
なんでお前かけないの?

630 :デフォルトの名無しさん:2020/07/23(木) 23:24:31.81 ID:k24nyzXR.net
>>627
1. jQueryのコードはイベントバブルしか使わない(使えない)
2. >>623のコードはe.targetを使ってない

ここまではいいですかねぇ(呆れ)

631 :デフォルトの名無しさん:2020/07/23(木) 23:28:46.58 ID:QHkNbR5l.net
>>626
まあ君との話はもうする価値がないから終わりにするけど、
イベントバブルはオレオレ用語ではないと思うよ。
イベントデリゲーションってのは確かにそこにあるが、初めて聞いたが。

e.targetについては、
> 複数の要素に同じイベントハンドラを割り当てて、どれかでイベントがあったときに何かさせたいような場合、e.target はとてつもなく有用なものです。
> 複数の要素に同じイベントハンドラーを割り当てて、どれかでイベントがあったときに何かさせたいような場合、e.target はとてつもなく有用なものです。
と、重要だからか?まじで2回書いてあるし、それが廃止とか使用禁止とかにはならないよ。
https://developer.mozilla.org/ja/docs/Learn/JavaScript/Building_blocks/Events

632 :デフォルトの名無しさん:2020/07/23(木) 23:28:53.91 ID:k24nyzXR.net
> イベントバブルを最初に実装したフレームワークはHTMLで、

笑うしかないわw HTMLがフレームワークとかw

633 :デフォルトの名無しさん:2020/07/23(木) 23:29:21.73 ID:k24nyzXR.net
> イベントデリゲーションってのは確かにそこにあるが、初めて聞いたが。

はい、初めて聞くレベル

634 :デフォルトの名無しさん:2020/07/23(木) 23:29:24.10 ID:HWiYfbuZ.net
>>614
そのMDNの廃止されたって言うのは以前の仕様書が廃止って意味じゃないの?

635 :デフォルトの名無しさん:2020/07/23(木) 23:30:10.44 ID:k24nyzXR.net
> e.targetについては、
> 複数の要素に同じイベントハンドラを割り当てて、どれかでイベントがあったときに何かさせたいような場合、e.target はとてつもなく有用なものです。

↓このコードが複数の要素に同じイベントハンドラを割り当てて、どれかでイベントがあったときに何かさせているコード

https://jsfiddle.net/m8q15376/

$("#id1").on('click', 'a', function() {
 $(this).css("background", "red");
});

636 :デフォルトの名無しさん:2020/07/23(木) 23:56:14.14 ID:k24nyzXR.net
まとめ

こいつはイベントデリゲーション(複数の要素に同じイベントハンドラを割り当てるコード)を
jQueryで書いているコードを見たことがない、もしくは見たことあっても気づかないで
jQueryでもDOM APIと同じように書くしかないはずだ!だからjQueryを使う意味がない!と考えていたようだが
そのイベントデリゲーションこそjQueryでシンプルに書けるコードの一つだったという話です。

637 :デフォルトの名無しさん:2020/07/24(金) 00:01:31.32 ID:2LubhzPR.net
>>633
というかね、「イベントバブル」をオレオレ用語だと噛みついてくる時点でお前はどうかしてる。
JavaScript使ってて今まで聞いたことがないってのは本当に酷い。

MDNにも「イベントのバブリング」とは書いてある。
> https://developer.mozilla.org/ja/docs/Web/Guide/Events/Creating_and_triggering_events
uhyohyoでも「イベントバブリング」って言ってる。
> https://uhyohyo.net/javascript/3_3.html
-ing形だから通じないって事も無いだろうし、そもそもbubbleフェーズを表すと勘違いしても大体通じる内容でしかない。
そこで噛みついてくる意味が分からん。

JavaScriptが世のGUIを席巻しつつあるのは、イベントバブルの功績が大きい。
これがあるのと無いのとでは、GUIの組みやすさの次元が違うんだよ。
だから.NETもWPFで、GTKでもGTK+3から採用されてる。(Qtは知らん)

それを全く使わずにJavaScriptのGUIを語るのは完全に間違ってる。
そこら辺がjQueryしか出来ない人(つまり君とか)の問題だと思うよ。
jQueryしか出来ない人が馬鹿にされているのは君も知っているだろ?そういうことだよ。

638 :デフォルトの名無しさん:2020/07/24(金) 00:22:53.71 ID:fMjVnhWI.net
お前のオレオレ用語っていうのは「バブル主体」だアホめ
なんだよバブル主体って(笑)

639 :デフォルトの名無しさん:2020/07/24(金) 00:24:19.77 ID:fMjVnhWI.net
>>637
> JavaScriptが世のGUIを席巻しつつあるのは、イベントバブルの功績が大きい。

だから、イベントバブルじゃなくてイベントデリゲーションな(笑)
何がオレオレ用語なのかわかってない。
用語の使い方を間違ってんだよお前は。

jQueryはイベントバブルを使ってる

640 :デフォルトの名無しさん:2020/07/24(金) 00:25:21.34 ID:fMjVnhWI.net
何度も言うがjQueryを使うということは
イベントバブルを使ってるということだ

641 :デフォルトの名無しさん:2020/07/24(金) 00:28:52.61 ID:fMjVnhWI.net
ちなみにイベントデリゲーションという用語は
MDNでも使われているが、jQueryが最初に使った用語なんじゃないかと思ってる。

もともとはjQueryでイベントデリゲーションを使う時
delegateというメソッドを使っていたから。それが廃止になりonに統一された。

onに統一された結果、jQueryでイベントデレゲーションを使ったコードと
使ってないコードの差異が減って、e.targetを使わずにthisでコードが書けるようになった。

jQueryでイベントデレゲーションを使うのは、DOM APIを使うよりも
格段にシンプルに書けるようになっている
無関係のイベントハンドラを統合するという単一責任の原則に反するコードを書くことなく
イベントデレゲーションを使うことが可能になっている。

642 :デフォルトの名無しさん:2020/07/24(金) 00:33:37.06 ID:2LubhzPR.net
>>638-640
半島に帰れ

643 :デフォルトの名無しさん:2020/07/24(金) 01:22:11.42 ID:2LubhzPR.net
>>627
訂正、>>624でもバブルを利用しているようだ。

jQueryはこの形式だとDelegated event handlers として扱われ、
on時点でサブクエリして一致した子要素に付けるのではなく、
内部的にバブルしてきたイベントを使い、実行時にクエリして一致を確かめるようだ。(後半部は予想、実装依存)
https://api.jquery.com/on/

だから確かにバブルを利用してはいるが、これだともっさり遅くはなる。(とはいえGUIの場合は大抵問題にはならない)
jQueryは使ってないし今後も使う予定もないので仕様には詳しくなく、見た目で判断してしまった。
なるほど何だかんだで上手く出来てはいる。

が、まあ、いずれにしてもこれをDOMAPIだけで書くのも別段苦労しないし、
jQuery内部でe.targetを使っているだけで、e.targetが無ければjQuery自体が組めないだけでしかない。


>>641
イベントデリゲーションの方がかなりオレオレ用語だと思うが。
確かにMDNには書いてあるが、俺は今まで聞いたこともなかったし、そもそもそれを「デリゲーション(キリッ」とかいうのもどうかしてると思うが。
OOPで言う委譲に当たるから「デリゲーション」なんだろうが、それはOOPで言う「継承か委譲か」、という話とは全然違っていて、
単に親要素でしかなく、子要素とは何の関わりもない。(一応包含してはいるが)
だから無理やりOOP的な解釈をすれば「デリゲート」しかないのだろうけど、
それは、世の中の全てを無理矢理OOPで解釈するJava脳みたいな感覚を受け、
Java以外で普通にOOPを分かっている奴からしたら相当気持ち悪い使い方だし、実際に流行ってもないだろ。
これが気持ち悪いと思わないのは君がOOPを理解してないからだよ。
ただし俺はGUI自体がOOPにフィットしないと思っているから、GUIしかやらないのなら理解している必要はないとも思うけども。

そして君は都合の悪い>>634は無視なのか?
既に言ったが、現在の状況でe.targetが無くなることはない。
ただ、あの辺デタラメに拡張して仕様がグダグダなので、整理しろよな、とは思うが。

644 :デフォルトの名無しさん:2020/07/24(金) 01:48:12.97 ID:2LubhzPR.net
ちなみにgoogle、

イベントバブル 約 22,500,000 件 (0.43 秒)
イベントデリゲーション 約 23,600 件 (0.28 秒)

645 :デフォルトの名無しさん:2020/07/24(金) 06:57:14 ID:9v9Epd9J.net
バブリングフェーズとイベントデリゲーションはバスタブとミカンくらい意味が違うがおんなじもんだと思ってたわけ?w

バブリングフェーズはイベント伝搬のステージのことで、
div
a
a
という構造ならhtmlからdiv→aと伝搬してくるのがキャプチヤリングフェーズ。
その後a→divとhtmlまで戻っていくのがバブリングフェーズ。

イベントデリゲーションは2つのaにイベントパンドラ設定するよりdiv1つに設定してaのイベントまとめてハンドルしてもらいましょうというやり方。

a(子)のイベントハンドリングをdiv(親または祖先)に委譲(delegate)するからイベントデリゲーション。

ちんちんとマンチェスターユナイテッドくらい意味が違うけどおんなじもんだと思ってたわけ?w

646 :デフォルトの名無しさん:2020/07/24(金) 07:07:22.97 ID:fMjVnhWI.net
>>643
イベントバブルっていうのはイベントがバブルのように上に上がっていくってだけで
一つのイベントハンドラで処理を行うって意味じゃねーんだよw
あーほ

647 :デフォルトの名無しさん:2020/07/24(金) 07:07:57.79 ID:fMjVnhWI.net
>>643
> だから確かにバブルを利用してはいるが、これだともっさり遅くはなる。(とはいえGUIの場合は大抵問題にはならない)
遅くなるの理由が何もないwww

648 :デフォルトの名無しさん:2020/07/24(金) 07:09:14.13 ID:fMjVnhWI.net
>>643
> 確かにMDNには書いてあるが、俺は今まで聞いたこともなかったし、

それがすべて。お前が無知なだけ

649 :デフォルトの名無しさん:2020/07/24(金) 07:10:55.78 ID:fMjVnhWI.net
結局の所 >>636 の まとめで書いたとおり

こいつはイベントデリゲーション(複数の要素に同じイベントハンドラを割り当てるコード)を
jQueryで書いているコードを見たことがない、もしくは見たことあっても気づかないで
jQueryでもDOM APIと同じように書くしかないはずだ!だからjQueryを使う意味がない!と考えていたようだが
そのイベントデリゲーションこそjQueryでシンプルに書けるコードの一つだったという話です。


そのイベントデリゲーションこそjQueryでシンプルに書けるコードの一つだったという話です。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

650 :デフォルトの名無しさん:2020/07/24(金) 07:27:42.03 ID:fMjVnhWI.net
>>643
> が、まあ、いずれにしてもこれをDOMAPIだけで書くのも別段苦労しないし、

だから最初に書けと言ってる。なんで書かないのか?

651 :デフォルトの名無しさん:2020/07/24(金) 08:10:38.59 ID:2LubhzPR.net
>>645
お前が日本語が出来なくていろいろ勘違いしてるだけだろ。

まず示したように、「イベントデリゲーション」なんて言葉は誰も使ってないから止めとけ。
イベントバブルの説明に必ず出てくる言葉なら、使用頻度=ヒットページ数も1:1になるはずであって、
約1000:1ってのは誰も使ってないって事でしかない。

> バブリングフェーズとイベントデリゲーションはバスタブとミカンくらい意味が違うがおんなじもんだと思ってたわけ?w
俺は同じ物だとは一言も言ってない。それを勝手に誤解しているのはお前の日本語が韓国人レベルだからだ。
ただ、これらは表裏一体であって、イベントがバブルしなければ纏めるも何もないので、
お前が思っているほど区別する意味もない。
お前みたいな文系馬鹿はやたら細かく区別して意味無くドヤる傾向があるが、プログラミングってのはそもそもそういうものではない。

実際問題として、イベントバブルを説明する際に、
確かに「バブルしてくるイベントを親で捕らえて纏めて処理する」事を示す名詞が欲しい、というのはあるだろう。
ただ、誰もそこで「イベントデリゲーション」なんて言葉を使ってないから1000:1の使用頻度になってる。
実際は、「バブルしてくるイベントを親で捕らえて」とそのまま言っているのだと思う。
ただそもそもバブルさせる=親で捕らえて纏めて処理する大前提だから、それ含めてイベントバブルでも大して問題ないんだよ。

652 :デフォルトの名無しさん:2020/07/24(金) 08:10:58.84 ID:2LubhzPR.net
同様にお前が無駄に拘っているのが以下だが、
> > イベントバブルを最初に実装したフレームワークはHTMLで、
> 笑うしかないわw HTMLがフレームワークとかw (>>632)
HTML/CSS/JavaScriptはほぼ常にセットで使われていて、どれだと区別する意味はないし、
確かに厳密にはどれでもないからWebAPIとか別括りにされてるが、そこに拘る意味もない。
俺は「イベントバブルを最初に実装した『フレームワークが』がHTMLだと言った。
お前的には「プラットフォーム」か、または別用語が適切なのかもしれんが、
いずれにしても言葉というのはコミュニケーションの手段であって、つまり通じるかどうかが最重要であって、
明らかに通じているのに揚げ足取りしているつもり?でドヤって来るのも頭おかしいとしか思えないが。
(オレオレ用語を使うなってのは「通じないから使うな」ということであって、オレオレ用語を使うこと自体が悪いというわけではない)

お前いつものjQuery厨か?
ならお前はここ2〜3年、まるで成長してないな。


>>650
むしろお前がそれを書けないと言っているに近いが、それをお前は認めるか?
日本語が通じない馬鹿なお前の為に敢えて言い直すと、
お前が「僕は書けませんから書いてみてください」と言うのなら書くが、
あまりに簡単すぎてお前の馬鹿さが際だつだけだぞ。


いずれにしても、脱jQueryなんてのが出てくるのはjQueryを使う意味がなくなりつつあるからであって、
お前がそれを気に入らなくても、それは事実として認めるしかないし、
実際にjQueryから輸入された仕様もあるのだからjQuery自体が糞だったわけでもないんだよ。
ただ、役割を終えつつある、というだけの話であってさ。

653 :デフォルトの名無しさん:2020/07/24(金) 08:42:13.69 ID:9v9Epd9J.net
バブリングフェーズとイベントデリゲーションはバスタブとミカンくらい意味が違うがおんなじもんだと思ってたわけ?w

654 :デフォルトの名無しさん:2020/07/24(金) 08:55:46.07 ID:fMjVnhWI.net
> まず示したように、「イベントデリゲーション」なんて言葉は誰も使ってないから止めとけ。



https://developer.mozilla.org/ja/docs/Web/API/Event/target
event.target プロパティは、イベントデリゲーションを実装するために使用できます。

https://developer.mozilla.org/en-US/docs/Web/API/Event/target
The event.target property can be used in order to implement event delegation.

655 :デフォルトの名無しさん:2020/07/24(金) 08:56:14 ID:9v9Epd9J.net
> まず示したように、「イベントデリゲーション」なんて言葉は誰も使ってないから止めとけ。

えーっと、ボクチン英語が分かりませーんという話かな?www
英語
https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events#Event_delegation
日本語
https://developer.mozilla.org/docs/Learn/JavaScript/Building_blocks/Events#Event_delegation

656 :デフォルトの名無しさん:2020/07/24(金) 08:58:29.43 ID:L9K/ZYyg.net
URLからしてイベントデリゲーション使ってるなw
誰も使ってない用語とは…?w

657 :デフォルトの名無しさん:2020/07/24(金) 08:58:39.33 ID:fMjVnhWI.net
>>651
> イベントバブルの説明に必ず出てくる言葉なら、

でてくるわけねーだろw
イベントバブル=イベントデリゲーションじゃねーんだから

DOM APIのイベントモデルではイベントバブルがデフォルトで使われる
イベントモデルの説明でバブルフェーズとキャプチャフェーズの話は出る
だがイベントデリゲーションはかならず使うものではない

お前が、イベントバブル=イベントデリゲーション (つまり同じ意味)だと
勘違いしてるから、使用頻度=ヒットページ数も1:1になるという間違った結論になってる

イベントデリゲーションはかならず使うものじゃないんだから
イベントデリゲーションの方が数は少なくなるのは当たり前

658 :デフォルトの名無しさん:2020/07/24(金) 09:03:00.98 ID:9v9Epd9J.net
プッチンプリンとにんにく卵黄は同じものだ!
その証拠に、卵黄にんにくのほうが検索ヒット数が少ない!!

にんにく卵黄なんて用語は誰も使ってない!
プッチンプリンが正しい!!


???wwwww

659 :デフォルトの名無しさん:2020/07/24(金) 09:08:11.32 ID:fMjVnhWI.net
>>652
> 俺は「イベントバブルを最初に実装した『フレームワークが』がHTMLだと言った。

HTMLの仕様にイベントバブルなんてものはない
DOM APIの仕様だ

「イベントバブルを最初に実装した」というのはどういう意味か言ってみ
上の要素でイベントを捕まえて処理することではないのはもう理解してるよな

お前は「イベントがDOM要素の下位から上位へバブルのように登っていくこと」を実装した。
と言ってるわけだが、自分で理解してるのか?

660 :デフォルトの名無しさん:2020/07/24(金) 09:09:27.92 ID:fMjVnhWI.net
>>652
> むしろお前がそれを書けないと言っているに近いが、それをお前は認めるか?

だからさっさと書けよ。お前をテストしてやってるに決まってるだろw
最初からコード書けと言ってるのになんで書けないのは
お前がそれを書けないと言っているに近いが、それをお前は認めるか?

661 :デフォルトの名無しさん:2020/07/24(金) 09:21:46.61 ID:fMjVnhWI.net
脱jQueryなんて言葉が出てきても、脱jQueryが進んでいないのは事実だろ

https://w3techs.com/technologies/history_overview/javascript_library/all/y

jQuery
2017年1月 71.9%
2018年1月 73.1% (+0.1%/月)
2019年1月 73.6% (+0.05%/月)
2020年1月 74.2%
同年2月 74.4% (+0.2%/月)※1ヶ月経過時点
同年6月 75.5% (+0.26%/月))※5ヶ月経過時点
同年7月 76.0% (+0.3%/月)※6ヶ月経過時点

今年はなぜかjQueryのシェアの増加が加速してきてるんだわ。
最初の1ヶ月で0.2%しか増えてなかったのに、
6ヶ月後は1.2%増ではなく1.8%増、増加スピードが上がってる

後半さらに増加スピードが上がるとは思えないが、
このペースだと今年は1年で4%も増える可能性だってある。
ここ数年1%程度しか増えていなかったのに不思議だ

脱jQueryなんて所詮言葉だけだったということだ

662 :デフォルトの名無しさん:2020/07/24(金) 09:24:24.50 ID:2LubhzPR.net
>>657
> イベントデリゲーションはかならず使うものじゃないんだから
> イベントデリゲーションの方が数は少なくなるのは当たり前
ここが違う。
バブルを利用する時点で「親で纏めて処理する」大前提なんだよ。これも既に言ったが。
逆に、バブルだけしても親で処理しないのなら意味無いだろ。
(まあバブル自体は勝手にするのだが)

だからイベントバブルの説明の際には必ず「親で処理する」事が含まれるんだよ。
これもお前みたいな文系馬鹿は「知識」としてそれぞれを別々にインストールしているから分からないのだろうが、
イベントバブルの説明=イベントバブル自体とその使い方の説明=当然親でイベントを纏めて処理する=「イベントデリゲーション」も説明される
なんだよ。イベントバブルをお前はJavaScriptの「知識」として捕らえ、
「バブルフェーズとキャプチャフェーズ」もまた別の知識であり、
「イベントデリゲーション」も全く別の手法として「別知識」としているから駄目なんだ。

イベントバブルだけ理解しても、普通は、「ほ〜ん、で?何が嬉しいの?」となるから、どうやって使うか、何が美味しいかまで説明されてる。
だけどそこでは誰も「イベントデリゲーション」と言ってないから1000:1の使用頻度になってる。
ただし実際にイベントバブルを活用するにはそれなりの知識と設計が必要であり、
初心者には無理だから初心者用サイトでの説明は皆無で、既に言ったとおり俺が知っているのはuhyohyoだけ。
そしてここら辺が有機的に繋がっているのを理解出来ないのは君が「イベントバブルを活用するのは難しい初心者」レベルだから。

お前は相変わらず初心者のままなんだよ。

663 :デフォルトの名無しさん:2020/07/24(金) 09:30:06.20 ID:fMjVnhWI.net
> バブルを利用する時点で「親で纏めて処理する」大前提なんだよ。これも既に言ったが。

誰が言ってるんですか?
そうであってほしいという願望ですよねw

664 :デフォルトの名無しさん:2020/07/24(金) 09:35:52.90 ID:2LubhzPR.net
>>659
> DOM APIの仕様だ
まあ厳密にはあれはDOMに入れるべき物でもないんだよ。
だから今も「For web developers(non-nomative)」という中途半端な扱いになってる。
あれはDOMと言うよりはプログラミングモデルであって、本来は別仕様を起こすべきなのだが、
それを言いだしたらきりがないから現状はDOMに突っ込まれているだけでさ。

> 「イベントバブルを最初に実装した」というのはどういう意味か言ってみ
> お前は「イベントがDOM要素の下位から上位へバブルのように登っていくこと」を実装した。
そうだぞ。俺はそう言ったんだ。
イベントがバブルするGUIフレームワークというのは、俺が知ってる中ではHTML/CSS/JavaScriptが初だよ。
それ以前の、XやMFC、.NET(Forms)ではバブルしない。

むしろお前は何をどう勘違いして俺に突っかかってきてるんだ?


>>660
お前が簡単に書けるのなら書かないよ。書く意味もないし。
それってconsoleログ知ってる俺スゲー的なレベルであって、そんなもん一々コード書いてても時間の無駄だろ。


>>661
そう思うのならそれでいいと思うが。
必死にjQueryにすがるからおかしくなるだけで。
必要ない人はjQueryを使わないし、実際必要なくなりつつあるだけの話で、必要だと思えば使い続ければいいし、それだけだろ。

665 :デフォルトの名無しさん:2020/07/24(金) 09:39:24.99 ID:2LubhzPR.net
>>663
なら逆に、「イベントバブルを利用するが親ではイベントを処理しない」方式で何か有効活用出来るか?
それがあれば「大前提」ってのは俺の勘違いだと認めるが。

666 :デフォルトの名無しさん:2020/07/24(金) 09:39:35.00 ID:fMjVnhWI.net
さて、どこに親で処理すると書いてあるのでしょうか?w
https://en.wikipedia.org/wiki/Event_bubbling

Use of Event Bubbling
To handle cases where one event has more than one handler,
event bubbling concept can be implemented. The major use of
event bubbling is the registration of default functions present in the program.
In recent times, not many developers use event capturing or bubbling in particular.
It is not necessary to implement event bubbling; it may become complicated for
the users to keep track of the actions getting executed because of an event.[1]

英語は読めるけど(あんたために、でも面倒なので)Google翻訳しますねw

イベントバブリングの使用
1つのイベントに複数のハンドラーがある場合を処理するために、イベントバブリングの概念を実装できます。
イベントバブリングの主な用途は、プログラムに存在するデフォルト関数の登録です。
最近では、特にイベントキャプチャやバブリングを使用する開発者は多くありません。
イベントバブリングを実装する必要はありません。イベントのために実行されるアクションを
ユーザーが追跡するのは複雑になる場合があります。[1]



「1つのイベントに複数のハンドラーがある場合を処理するため」というのは
要素をクリックしたときに、クリックした要素→それが含まれた親要素→さらにそれらが含まれた親要素と
複数の要素(の複数のクリックイベントハンドラ)が実行されるわけです。
これがイベントバブリングの例として上げられています。

そして主な用途はデフォルト関数(デフォルト処理)の登録です。
またイベントキャプチャやバブリングを使用する開発者は多くないとまで書いてあります。
親でまとめて処理する話はでてきていません。

面白いですね(笑)

667 :デフォルトの名無しさん:2020/07/24(金) 09:41:46.92 ID:fMjVnhWI.net
>>664
> むしろお前は何をどう勘違いして俺に突っかかってきてるんだ?

何をどうって、jQueryはイベントバブリングしかサポートしてないのに
jQueryでイベントバブルを使うと意味がないと言っただろw

どういう意味ですか?jQueryはイベントバブルしか使いませんよ?
イベントバブルを使うということは親で処理するって意味じゃありませんよ?
わかってますかw

668 :デフォルトの名無しさん:2020/07/24(金) 09:42:35.90 ID:fMjVnhWI.net
>>665
> なら逆に、「イベントバブルを利用するが親ではイベントを処理しない」方式で何か有効活用出来るか?
英語のwikipediaにかいてある。

> それがあれば「大前提」ってのは俺の勘違いだと認めるが。
それがあったのでお前の勘違いだと認めるようにw

669 :デフォルトの名無しさん:2020/07/24(金) 09:43:33.55 ID:fMjVnhWI.net
>>664
> イベントがバブルするGUIフレームワークというのは、俺が知ってる中ではHTML/CSS/JavaScriptが初だよ。

HTML/CSS/JavaScriptのいずれの仕様でもありません。

DOMの仕様です。DOMです。Javaでも使えるDOMです。
何度言えば理解できるんだ?

670 :デフォルトの名無しさん:2020/07/24(金) 09:48:58.90 ID:2LubhzPR.net
>>666
wikiじゃねーかよ!そりゃ書いた奴が分かってねえんだよ。
既に言ったが、世の中のGUIフレームワークはイベントバブルをこぞって採用してる。
.NETはWPFから、GTKは3から。Qtは知らんが間違いなく採用はされるかその方向の筈。
理由も既に言ったとおり、バブルが出来れば非常に効率よくGUIを実装出来るから、
それに慣れると、バブルが出来ないフレームワークなんてゴミにしか見えなくなるから。


>>667-669
どうにもお前とは話が噛み合わないからこの辺で終わりにしておこう。
色々既に言ったとおりだ。気になるなら読み返してみてくれ。

671 :デフォルトの名無しさん:2020/07/24(金) 09:49:55.44 ID:fMjVnhWI.net
>>670
> wikiじゃねーかよ!そりゃ書いた奴が分かってねえんだよ。

お前はwikipedia以外のなにか信用できるものを持ってきたか?
お前の意見はwikipedia以下だってことは理解してるか?

672 :デフォルトの名無しさん:2020/07/24(金) 09:52:19.09 ID:fMjVnhWI.net
>>670
jQueryは最初からイベントバブルを採用してるのを知らないで
イベントバブルだとjQueryの意味がなくなる!

といった話はどうなったの?w

別の話に逃げたねw

673 :デフォルトの名無しさん:2020/07/24(金) 10:00:24.59 ID:fMjVnhWI.net
まとめ更新

こいつはイベントバブルの用途をイベントデリゲーション(複数の要素に同じイベントハンドラを割り当てるコード)しかしらず
イベントバブル=イベントデリゲーションのことだ!と思い込んでオレオレ用語で「イベントバブルを実装!」と言っていた
こいつは自分にしか理解できない間違った用語の使い方を指定ながら、コミュニケーションがどうとか語っていた

こいつはMDNにかかれているイベントデリゲーションのページを見せても
世の中で使われてない!と強弁した。

こいつはHTML/CSS/JavaScriptがイベントバブルを実装した最初のフレームワークだと言った。
(当たり前がHTMLはマークアップ言語、CSSはスタイルシート、JavaScriptは言語で
どれにもイベントバブルに関する実装など存在しない。イベントバブルはDOMで規定されている)

こいつはjQueryは最初からイベントバブルに対応していたことも知らず、
(というか古いIEがイベントバブルしか実装されていなかったのでキャプチャフェーズに対応するのは不可能)
イベントバブルを使うとjQueryを使う意味がないと言った。

そしてjQueryで書いているコードを見たことがない、もしくは見たことあっても気づかないで
jQueryでもDOM APIと同じように書くしかないはずだ!だからjQueryを使う意味がない!と言っていた。
jQueryで(イベントバブルではなくw)イベントデリゲーションで実装してるコードを見せても
イベントバブルを使ってない!とか意味のわからないことを言った。

イベントデリゲーションこそjQueryだとDOM APIよりもシンプルに書けるコードの一つだった

こいつは脱jQueryが進んでいない現状を示しても、その事実を受け入れることができなかった

674 :デフォルトの名無しさん:2020/07/24(金) 10:01:50.66 ID:fMjVnhWI.net
jQueryおじさん完全勝利(笑)

675 :デフォルトの名無しさん:2020/07/24(金) 10:12:17.88 ID:2LubhzPR.net
>>671
一応読んだぞ。

まあそう思うのは自由だが、それは最初に書いてあるとおり、
> To handle cases where one event has more than one handler, event bubbling concept can be implemented. The major use of event bubbling is the registration of default functions present in the program.
つまり一つのElementに複数のイベントハンドラを付けたい時にバブルを活用出来るとか、
或いはrootにデフォルトのイベントfunctionを付けておけばそれを「上書き」する際に活用出来る、みたいなわけだが、
そんな使い方してるサイトなんて無いぞ。というかそんなことしたら怒られると思うが。
複数付けたければ普通にaddEventListenerすればいいだけだし、
サイトのスクリプトがユーザースクリプトその他によって「上書き」される前提で書いているサイトなんてほぼ無い。
あるにしてもこんな邪道なやり方ではなく、「サイトのスクリプトをオフにする」という、公式な無効化機能が付いてる。
というか、そうじゃないとお互いに困るだろ。お前はそれも分からないレベルなのだろうけど。


>>672
逃げたって何の事よ?
jQueryが採用しているとかそういう話ではなくて、
そもそもバブルは(お前が拘っている『DOMの仕様』なのだから)jQueryとは関係なく、勝手にする物だ。
そしてバブルを利用した書き方=親で纏めて処理する方式なら、
jQueryの得意とするqueryをすることがないからjQueryを使う意味がない、と言ったんだよ。
それはお前が本当に『書ける』というのならすぐに分かる話だろ。
お前はやっぱり書けないのだと思うよ。

676 :デフォルトの名無しさん:2020/07/24(金) 10:13:31.15 ID:fMjVnhWI.net
もう負け逃げしたようだが、
イベントバブルの一番のユースケースはこれなんだよ

<a href="link">link<span>test<span></a>

1. aのクリックイベントハンドラ
2. spanのクリックイベントハンドラ

両方のイベントハンドラを設定することができ
両方のイベントハンドラが発動する
これがwikipediaに書いてあったことの具体的な意味

そのイベント発動を行うフェーズがバブリングフェーズとキャプチャフェーズの二種類あり
バブリングフェーズにおいて下位の要素から上位の要素に伝搬することを
イベントバブリング(イベントバブル動作)という
(イベントバブルだけでは意味が不明確)

677 :デフォルトの名無しさん:2020/07/24(金) 10:15:13.60 ID:fMjVnhWI.net
>>675
まだ繰り返すのかw

> jQueryの得意とするqueryをすることがないからjQueryを使う意味がない、と言ったんだよ。

めんどくさいから突っ込まなかったことろを再掲するとかアホやなぁ
「queryをすること」ってなんだよ。どういう意味なのか言ってみ
queryしているコードを書いてみろって

678 :デフォルトの名無しさん:2020/07/24(金) 10:17:09.02 ID:fMjVnhWI.net
先に書いてやるか
jQueryでqueryすること(意味がよくわからんが)と言われれば
普通に思いつくのは、$('#id1"') とかなわけだが

>>624で「イベントデリゲーション」を使ったコードでも
このようにqueryしてますがなにか?


https://jsfiddle.net/m8q15376/
$("#id1").on('click', 'a', function() {
 $(this).css("background", "red");
});

679 :デフォルトの名無しさん:2020/07/24(金) 10:18:57.42 ID:fMjVnhWI.net
>>675
> つまり一つのElementに複数のイベントハンドラを付けたい時にバブルを活用出来るとか、

そんなことは英語に書いてない

> To handle cases where one event(一つのイベントが) has more than one handler (一つ以上のハンドラを持っている場合), event bubbling concept can be implemented.

「一つのElementに複数のイベントハンドラを付けたい」などとは書いていない。

680 :デフォルトの名無しさん:2020/07/24(金) 10:20:19.73 ID:fMjVnhWI.net
せっかくGoogle翻訳もしてやったのに
英語読めないなら、ちゃんと日本語も読めよ(笑)

681 :デフォルトの名無しさん:2020/07/24(金) 10:23:00.47 ID:fMjVnhWI.net
>>675
> そもそもバブルは(お前が拘っている『DOMの仕様』なのだから)jQueryとは関係なく、勝手にする物だ。

お前最初に、バブルは勝手にするものじゃなくて
親でまとめてイベント処理することだって言ってたじゃんwww

自分が使っていた用語が間違っていましたって認めたの?

682 :デフォルトの名無しさん:2020/07/24(金) 10:42:49.37 ID:2LubhzPR.net
>>677
> queryしているコードを書いてみろって
それはお前が>>623,624で既に書いてるだろ。
jQueryが美味しいのは、getElementByIdとか長たらしいこと書かずに$('#id')と書けるとか、
HTMLCollectionなのに単発のDOMみたいに扱えてforやforEach等のループを自前で書く必要がないとか、そういうところだろ。

そして俺が言ってるのは、親にeventhandlerを付けるのならその辺のおいしさが全くなくなる、ということだよ。

ただまあ、jQueryがそこまで好きならjQueryで一生書けばいいとも思うけど。
俺は必要ないから今後とも使わないだけであって。

683 :デフォルトの名無しさん:2020/07/24(金) 10:44:01.60 ID:2LubhzPR.net
>>681
> 親でまとめてイベント処理することだって言ってたじゃんwww
そうだぞ。イベントバブルを活用する=親で纏めて処理する、だ。
それ以外のまともな使い方は俺は知らん。(以下に続く)

>>679
おお、確かに読み間違えてる。
一つのイベントが複数のイベントハンドラを持ちたい場合か。
しかし何だそりゃ?て話だがな。
一つのイベントに複数のハンドラを持たせたい為にバブルさせてそれぞれの階層で処理させて結果的に複数処理するってのは、
実際の動きを説明していると言えばそうだが、これの為にバブルを活用するのは間違いだと思うが。

ただまあ、wikiはこの辺デタラメに書く奴が居るからそこまでは信用しない方がいい。
Cの日本語wikiとかも結構デタラメだったりするし。

逆に、本当にこのケース「一つのイベントに複数のハンドラを持たせたい為」にバブルを利用して、
それ以外の方法では美しく実装出来ないケースがあれば確かに俺の勘違いだと認めるが、あるか?
何度も言ってるが、俺はそれがないから「バブルを利用する=親で纏めて処理」だと思っているわけでさ。

或いはこの記述、ユーザ目線ではなくブラウザ目線で書かれている?
mouseleave/outの違いとか、
確かにmouseoutは一つのイベントを複数階層で処理して結果的に複数のハンドラを一つのイベントに与えている、とは言えるけども。
https://developer.mozilla.org/en-US/docs/Web/API/Element/mouseleave_event

684 :デフォルトの名無しさん:2020/07/24(金) 10:44:43.06 ID:fMjVnhWI.net
>>682
> そして俺が言ってるのは、親にeventhandlerを付けるのならその辺のおいしさが全くなくなる、ということだよ。

だからその親にeventhandlerを付けるコード書けって言ってるんだが?
俺はそれがすごく読みづらくなって、jQueryで書いたらシンプルになると知ってるわけ
さっさと書けよ。ここまで言って書かないのは、
お前がそれを書けないと言っているに近いが、それをお前は認めるか?

685 :デフォルトの名無しさん:2020/07/24(金) 10:45:17.15 ID:fMjVnhWI.net
>>683
> 一つのイベントが複数のイベントハンドラを持ちたい場合か。
> しかし何だそりゃ?て話だがな。

知らんのね(笑)

686 :デフォルトの名無しさん:2020/07/24(金) 10:46:32.32 ID:fMjVnhWI.net
>>683
> 逆に、本当にこのケース「一つのイベントに複数のハンドラを持たせたい為」にバブルを利用して、
> それ以外の方法では美しく実装出来ないケースがあれば確かに俺の勘違いだと認めるが、あるか?

俺の勘違いだと認めるがと言っておきながら、
wikipediaの例を出したら認めなかっただろ
嘘つきだよなw

687 :デフォルトの名無しさん:2020/07/24(金) 10:48:00.94 ID:fMjVnhWI.net
> 何度も言ってるが、俺はそれがないから「バブルを利用する=親で纏めて処理」だと思っているわけでさ。

jQueryはイベントバブルにしか対応してないから、
すべてがイベントバブルを利用してるの
親でまとめて処理してなくてもイベントバブルを利用してるの

688 :デフォルトの名無しさん:2020/07/24(金) 10:52:08.90 ID:fMjVnhWI.net
> 逆に、本当にこのケース「一つのイベントに複数のハンドラを持たせたい為」にバブルを利用して、
> それ以外の方法では美しく実装出来ないケースがあれば確かに俺の勘違いだと認めるが、あるか?

一つのイベント・・・click
それ以外の方法では美しく実装出来ないケース・・・google map

お前の勘違いだって認めようねw

689 :デフォルトの名無しさん:2020/07/24(金) 11:03:32.54 ID:9v9Epd9J.net
プッチンプリンとにんにく卵黄は同じものだ!
その証拠に、にんにく卵黄のほうが検索ヒット数が少ない!!

にんにく卵黄なんて用語は誰も使ってない!
プッチンプリンが正しい!!


???wwwww

690 :デフォルトの名無しさん:2020/07/24(金) 11:09:00.66 ID:2LubhzPR.net
>>684-687
まあやはり堂々巡りか。

wikiに書いてる使い方で活用出来るかについては考えてはみるよ。
ただし、既に言ったが、今のところ俺はそんなの見たこと無いが。

お前が勘違いしているのは、デタラメな使い方でもちゃんとした使い方だ!と思っていること。
それは文系初心者プログラマにも多い、全ての文法を使える人が上級者だ!と勘違いしていたりするのにも近い。

実際はそうじゃない。
例えばキャプチャフェーズとかも実装されているから確かに使えるが、俺はそれを上手く使っている例を見たことがない。
正確に言えば、まともに設計すればキャプチャフェーズなんて必要な事がないから、誰も使ってないだけだが。
バブルにしても、邪道な使い方はいくらでも出来るが、そうではなくて、
正しい使い方=それ以外の方法ではそれ以上に美しく実装出来ない使い方なのか、ということだよ。
「一つのイベントに複数のハンドラ」も、addEventListerを複数行えば普通に実装出来る。
バブルさせる意味はないし、実際、バブルしない.NET(Forms)等でもこれは普通に可能だ。

だからまあ、君にも分かる書き方をするなら、
・バブルしないX、MFC、.NET(Forms)、GTK2等でも書ける事=バブルを活用しているわけではない
・バブルしないX、MFC、.NET(Forms)、GTK2等では出来ない書き方=バブルを活用している
なんだよ。そして複数のイベントをサブスクライブするのは.NET(Forms)は出来るから、
それはバブル必須ということにも、バブルを活用していることにもならない。
そしてその場合にはJavaScriptでも「バブル」ではなくaddEventListerを複数行うのが正道だよ。

691 :デフォルトの名無しさん:2020/07/24(金) 11:10:04.24 ID:2LubhzPR.net
>>688
> 一つのイベント・・・click
> それ以外の方法では美しく実装出来ないケース・・・google map
うむ、これについて詳しくよろしく。

692 :デフォルトの名無しさん:2020/07/24(金) 11:12:00.44 ID:fMjVnhWI.net
>>690
堂々巡りなのはお前が間違いを認めないからだろ

jQueryの話をなかったことにするな。

お前がレスするのを逃げてるのはこれだな

先に書いてやるか
jQueryでqueryすること(意味がよくわからんが)と言われれば
普通に思いつくのは、$('#id1"') とかなわけだが

>>624で「イベントデリゲーション」を使ったコードでも
このようにqueryしてますがなにか?


https://jsfiddle.net/m8q15376/
$("#id1").on('click', 'a', function() {
 $(this).css("background", "red");
});

693 :デフォルトの名無しさん:2020/07/24(金) 11:12:45.73 ID:fMjVnhWI.net
>>691
> うむ、これについて詳しくよろしく。

すでにお前は逃げてるからなw
先にお前の勘違いだったって認めろ。

先に認める文章をお前が書け
そうしたら説明してやるから

694 :デフォルトの名無しさん:2020/07/24(金) 11:17:44.62 ID:2LubhzPR.net
>>693
逃げてるも何も、そのやり方が正道でなければそりゃ認めないよ。
既に言っているし、君も知っているはずだが、プログラミングなんて糞な書き方は無限に出来るわけでさ。

ふと考えたが、eをもしかしてmutable扱いか?
これは若干邪道だけども、そうしないと無理(それ以外での実装では大量なコードが必要)ならそれもありではあるが。

695 :デフォルトの名無しさん:2020/07/24(金) 11:19:41.76 ID:fMjVnhWI.net
>>694
言い訳はいいからさ、>>692のコードをお前がいうコードで書き直してみろって
ここまで言って書かないのは、
お前がそれを書けないと言っているに近いが、それをお前は認めるか?

まだこれ認めてないよな?

696 :デフォルトの名無しさん:2020/07/24(金) 11:20:24.05 ID:fMjVnhWI.net
こいつは何一つコードを書かない
俺はすでに書いている

697 :デフォルトの名無しさん:2020/07/24(金) 11:21:33.78 ID:2LubhzPR.net
>>694 訂正
693と思ったが、見る限りほぼ「読みとり専用」だから無理だな。
https://developer.mozilla.org/ja/docs/Web/API/Event

698 :デフォルトの名無しさん:2020/07/26(日) 04:16:24.04 ID:GfAtypzY.net
誰かjsで書ける珍しいコードのせてくれや

699 :デフォルトの名無しさん:2020/07/26(日) 21:49:52.62 ID:f+jrD57t.net
>>698
ど素人かど初心者ほど訳の分からないコードを書くから、そういうの探せば?
Web板で聞いた方が受けると思うけど。実際その程度の連中で埋め尽くされてるし。

700 :デフォルトの名無しさん:2020/07/27(月) 17:27:45.80 ID:2I3xUck9.net
>>699
なるほど 納得

701 :デフォルトの名無しさん:2020/07/27(月) 18:00:07.01 ID:2I3xUck9.net
javascript玄人もいったんこの解説みろ
http://re-file.com/18k/1677/

702 :デフォルトの名無しさん:2020/07/27(月) 19:33:11 ID:SDAq9vDF.net
>>701のリンク先
俺以外もう見なくていいぞw

【メキシコ】麻薬カルテル、ライバル組織の女を拘束、手足を縛り生きたまま解体 - 18禁グロ

▼カテゴリ - 18禁グロには一部、異様・奇怪・猟奇的・暴力シーン・グロテスクな表現が含まれていますので、閲覧制限をしています。

1. 18歳未満は閲覧禁止です。
2. 耐性が無い方は閲覧しないでください。
3. 閲覧は自己責任でお願い致します。

※上記、18歳以上で同意できる方は入室してください。
PASS:7777

703 :デフォルトの名無しさん:2020/07/27(月) 21:36:02 ID:2I3xUck9.net
例えばパスワードとかで、エンター押したら実行するよーにするにはどーしたらいんかね?

704 :デフォルトの名無しさん:2020/07/27(月) 21:45:23.89 ID:GH3PnKGv.net
<form action="〜" method="post">
<input type="password" name="pass">
<input type="submit">
</form>

705 :デフォルトの名無しさん:2020/07/27(月) 22:05:10.71 ID:P2Gsimd7.net
HTML, CSS, JavaScript の質問は、web制作管理板で聞いてください!

この板のスレは、荒らしが出た時に、緊急避難用に一時的に立てたものなので

706 :デフォルトの名無しさん:2020/07/27(月) 22:09:15.60 ID:2I3xUck9.net
>>705
ごめんなちゃい

707 :デフォルトの名無しさん:2020/07/27(月) 22:11:54.64 ID:fnBRfBHK.net
いいってことよ

708 :デフォルトの名無しさん:2020/07/27(月) 23:32:47.58 ID:QhcinMDB.net
そういやあっちどうなってんのかな?って思って見てみたが、
>>596ってマルチポストをこっちに収斂したのかよ!
https://mevius.5ch.net/test/read.cgi/hp/1568714120/471

thisが何か分からないレベルの奴は永久にWeb板に引きこもってろ。
というか、お前ら何がやりたいんだ?
全部初心者スレにするから、お前らも完全に知ってるくだらない話題につき合わないといけないわけであって、
そんなスレばかりではお前らにとってもメリットが無いだろ。
他人の手助けをするのはいいが、手助けばかりして自身が成長できないようなら意味無いだろ。
今回のは完全にjQuery廚が悪いようだが。

jQuery厨も結局全く成長しておらず、俺の最初の話が全く通じてないのもかなり酷い。
それで向こうでブッ叩かれたからってこっちに来るのは迷惑でしかないから止めてくれ。
お前(jQuery厨)の問題は、前から言ってるが、書いてるコードの規模が小さすぎる事だ。
少し大きなのを書けば、俺が言ってるように、イベントハンドラが単発の単純な関数で終わることはなくなって、
共通変数/関数をどこに配置すべきかを考えるようになるんだよ。
お前はそこにすら至ってないから俺が何を言っているのかさっぱり理解出来ない。
そして一行で書ける関数に異様に拘るわけだ。

709 :デフォルトの名無しさん:2020/07/27(月) 23:33:18.10 ID:QhcinMDB.net
俺はその上の「構成」について現在の俺なりの考えを述べた。
食いついてくるかどうかは君らの勝手だが、俺が思うに、今の君らに必要なのはここだと思うんだよ。
だから先鞭を付けてみたわけだ。

俺的区分で
初心者:一通り分かってなくて苦労してるレベル
中級者:一通り抑えているから、動けばいいのなら何とでも出来るレベル
上級者:最初からほぼ最適な構造で構成出来るレベル
として、Web板の連中にも中級者はそこそこ居るからおそらく中級者スレは回せる。
だとすればお前らが今やるべきは『中級者スレを建設して回すこと』であって、そこでは、

1. 文法事項の質問は初心者スレでやれ
2. 妥当な実装方法が複数ある場合、どう使い分けるべきかを議論
3. オレオレ的カッコイイ構成を披露、どうだカッコイイだろ!とやって糞ならブッ叩かれて改修点を回収

とかなんだよ。今回で言えば、イベントの捕捉方法には代表して2つのやり方があるが、
1. Elementに直接onXXX または addEventListener で捕捉
2. bubbleしてきたイベントを親で捕捉
このどちらをどう使い分けるか、ということ。
そして俺はもう「bubble主体で組む方が断然いい」と結論を出してしまっているからそれを書いた。
そんなん当たり前、と思っているのなら無視でいいが、「そうじゃない!」と思ってるのなら食いついてくるべきだし、
それ以前の「どう使い分ければいいの?」と思っているのなら、『中級者スレ』を建設して、
その中で君ら同士で喧々諤々やるべきなんだよ。
勿論リアルでやれてればそれが一番いいんだけど、リアルでは言いにくかったりするんだろ?
だったらそれが君らが上達する一つの真っ当な方策だよ。
そしてそこでは一通りも書けないレベル、つまり文法事項を一通り抑えてない奴は別スレで、でいいんだよ。
そんな奴混じっても邪魔でしかないだろ。

710 :デフォルトの名無しさん:2020/07/27(月) 23:34:59.54 ID:QhcinMDB.net
で、ここで問題になるのがいわゆる「意識高い系」という言い方で、最近これについてネットでも反省してる奴が散見されるが、
正直俺はどちらの意見もイマイチ賛同出来ないのだな。
多分上記のように「一定以下の奴は切り捨てる」を公言すると「意識高い系ガー」と無駄に攻撃される。
これは、人は誰でも置いて行かれるのは不快なものだし、人数も初心者>>>中級者なのは常だから、
「初心者が中級者を攻撃する便利なキーワード」として『意識高い系』が出来たからそれを使う奴は一定の割合で出てくる。
それで結果的に芽を摘み(=集団を上に引っ張れる奴を挫き)、結果的に糞しかなくなってる、というのが反省の中身だ。
ただ俺はこれもイマイチしっくり来ない。ぶっちゃけ両方ゴミだな、と思っている。つまり、
ゆとり文化で「意識高い系ガー」と言って集団を下に引っ張るのも糞だが、
そもそも「意識高い系」の連中も「俺達は高い=お前らは低い」という、
無駄に見下す事をしてきた(正確にはそういう奴が多い)から嫌われてると思う。

そもそもネット以前のオタク(プログラマ含む)は基本的に一人でやってて、
「俺スゲーだろ!」と自慢する場所も無かったから、完全に自己完結してた。
だから見下すとか、そういうのは基本的になかった。
ところが昨今は無駄に見栄を張れるようになって、食べログでも食べてもないのにレビューを書き、インスタではリア充を装ってもう疲れた、
みたいなのが沢山居るから、「スゲープログラマを装っている糞プログラマ」も多々居て、
そいつらは他人を見下す事によって己の凄さを担保するようなメンタルだから、
そんな奴等に対して「意識高いだけの糞」と言いたくなるのも分かる。
というわけでどっちも糞だな、というのが俺の見解ではある。

が、現実問題として、お前らの大学に幼稚園児が乱入してきて走りまわられても、邪魔でしかないだろ。
同様に、君らが前に進む為の場所にとって初心者が邪魔なら、普通に排除していいんだよ。
初心者の為のスレは別にあり、初心者はそこで問題ないのだから。
というのをだな、どうせ見えた展開になるだろうから、先に言っておく。
つまり、妥当ではない批判にくじけずに前に進め、ということ。

711 :デフォルトの名無しさん:2020/07/27(月) 23:35:38.29 ID:QhcinMDB.net
ちなみに君らはこんなスレでも多少沸いてくるように、周りを見ている、という点は素晴らしい。
いや、JSはそういう状況だから仕方ないのかもしれんが、
Javaは>>547のような奴が普通に居るし、これは最近はC#の連中も同様になりつつある。

で、今の君らに必要なのは、文法ではもう問題がない人同士で、
「何をどう記述すべきか」を議論することだよ。それは良い中級者スレになる。
JavaScriptは構造に対しても非常に柔軟で、それは他の型あり言語、例えばC++で同じ構造で書くのと比べて段違いに楽に書ける。
逆に言えば、いろんな構造をお試し的に書いても、他言語より同じ時間で沢山の構造を試せるから、
中級者から上級者にステップアップするには有利な言語だと思う。
問題は、JS的糞、例えばセミコロンガーに嵌ってしまう馬鹿が多い、という点であって。

712 :デフォルトの名無しさん:2020/07/28(火) 00:26:55.97 ID:nl0WhoWH.net
一言で言えば糖質

713 :デフォルトの名無しさん:2020/08/28(金) 00:01:02.51 ID:6GH+yyLXR
ブログは最初の1円稼ぐまでが地獄【初心者が挫折しない3つのコツ】
https://www.youtube.com/watch?v=X0j5njcpRms&t=42s
ブログで稼げない人の”致命的な勘違い”
https://www.youtube.com/watch?v=C2JrYuumLOM
【ブログvsYouTube】どっちが稼げる?集客しやすい?
https://www.youtube.com/watch?v=gsu9LxA6Cto
【収益10倍】全ブロガーはWEBマーケターになるべし
https://www.youtube.com/watch?v=PQ6Fk2nKBM4
大学生がやるべきことは「社会の理不尽を知ること」。
https://www.youtube.com/watch?v=zNvj3eN2W2c
Webライターvsブログ!今稼ぐならどっち?【僕ならこうする】
https://www.youtube.com/watch?v=GVjYRrGI5mQ
ブログや副業が辛い人は大チャンスです。
https://www.youtube.com/watch?v=_VUrR9Y1470
一生稼げない敗者のマインド3選【過去の失敗談から語る】
https://www.youtube.com/watch?v=U2htO9B2YGU
有料noteやBrainで継続的に稼ぐ3つの方法【コンテンツ販売】
https://www.youtube.com/watch?v=d31w1Q5UtA4
アフィリエイトの始め方と稼ぐための基礎知識【超初心者向け】
https://www.youtube.com/watch?v=n1cCjSMnG_E

714 :デフォルトの名無しさん:2020/09/12(土) 21:45:44.66 ID:ybxdKypc.net
webpackについて伺いたいんですけど、webpackは将来的には不要になるライブラリって認識は間違ってないですか?
あとbabelとかも

715 :デフォルトの名無しさん:2020/09/22(火) 15:57:49.10 ID:uSjSk1xMZ
70億円調達のネットショップ作成サービスhey、「我の弱い人同士の組織力」武器にEC市場シェア拡大目指す
https://www.businessinsider.jp/post-219205
【劇団ノーミーツ1】役者も客も会わないオンライン演劇で7000人動員。制作チームは全員20代、半分は会社員
https://www.businessinsider.jp/post-219184
「ガーナのゴミ」がなぜ1点500万円の作品に変わるのか
https://www.businessinsider.jp/post-208314?itm_source=article_link&itm_campaign=/post-219184&itm_content=https://www.businessinsider.jp/post-208314
利用、無料。日本版衛星データプラットフォーム「Tellus」がすごい理由…“宇宙の視点”でビジネスはこう変わる
https://www.businessinsider.jp/post-219279
「起業ブーム」が新たなフェーズに 大学発ベンチャーへの想い
https://forbesjapan.com/articles/detail/35527
かつて学者がやっていたことを、今は起業家がやっている
https://diamond.jp/articles/-/232874
番号やアドレス不要の無料通話アプリRe-mo登場 ドワンゴが配信開始
https://japanese.engadget.com/ios-dwango-re-mo-072853620.html
10年間使い続けた WordPress を辞めた理由  a-blog cms を選んだユーザーのお話
https://webtan.impress.co.jp/u/2020/09/14/37485
「KFC創業者は65歳で起業した」遅咲き経営者4人の成功法則
https://president.jp/articles/-/38719

716 :デフォルトの名無しさん:2020/10/02(金) 10:09:07.53 ID:EkM/KECH.net
WEB Components のラッパーを書きました。
公式:https://strnote.com/static/CompElem.html

ライセンスはMIT
Veu.js, React.js などより大幅に低水準なラッパーなので、そのぶん改造は楽です

717 :デフォルトの名無しさん:2020/10/13(火) 01:31:02.46 ID:dvOlOvK/.net
JavaScriptの実装について知りたいんですがChromiumのソース読めばいいんでしょうか?

718 :デフォルトの名無しさん:2020/10/17(土) 08:56:08.19 ID:N1gX0TwH.net
>>717
https://v8.dev/docs/source-code

719 :デフォルトの名無しさん:2020/10/17(土) 08:59:43.06 ID:syR+vJZ+.net
>>718
ありがとうございますm(_ _)m

720 :デフォルトの名無しさん:2020/11/04(水) 11:18:33.79 ID:/5L/Dxz6.net
パラッパラッパー

721 :デフォルトの名無しさん:2020/11/12(木) 01:41:53.08 ID:ZurnA+Eap
デキる人ほどフリーランス化する?★働き方改革
https://www.youtube.com/watch?v=ALflcwYOJtQ
年収890万円以下は社会のお荷物★騙される労働者
https://www.youtube.com/watch?v=CAp-ZrJpF54
騙されたくなかったら勉強しろ★他人のルールは損をする
https://www.youtube.com/watch?v=s176O6qKuPw
底辺の99%は一生底辺★10年後が見えない同僚たち
https://www.youtube.com/watch?v=4Mfiwn2sPD8
稼ぎたければ働くな★4千万円ぽっちも稼げないのはなぜ?
https://www.youtube.com/watch?v=Fi7bILN4wes
サラリーマン思考では儲からない理由
https://www.youtube.com/watch?v=iW6oAo0q0ZI

722 :デフォルトの名無しさん:2021/03/07(日) 23:11:04.14 ID:bNghcsY5.net
ゲームのコアライブラリ書いてるけど
async/await のお世話に頼らないと無茶だと痛感
不定個のPromise配列をパイプライン処理すんの無理だわな

723 :デフォルトの名無しさん:2021/03/07(日) 23:24:25.00 ID:bNghcsY5.net
書けなくもないけど、書いてるうちにゲシュタルト崩壊起こしかけるぅ orz

724 :デフォルトの名無しさん:2021/06/12(土) 15:43:59.92 ID:TONJAMor.net
プロならLPIのHTML5レベル2は持ってて当たり前なのでしょうか?

725 :デフォルトの名無しさん:2021/06/12(土) 21:20:44.77 ID:uQ7TEz17.net
>>724
俺はWeb系ではないが、採用条件として明示してあるのでなければ、無視でいいと思う。

一般にIT系では採用時に資格は重視されない。理由は簡単で、
・進化が早く、資格として整備された時(数年後)には既に陳腐化している。
・精々数時間で50-100問(数分/問)を課すテストで計れるのは、「知識」であって、「実力」ではない。
だから逆に言えば、ほぼ進化がなく、それなりに知識が必要だとされる分野は、資格も話題にはなってる。
これは他スレ読めば分かると思うけど、JAVA/オラクル/MS位だね。その他は全部ゴミだと思っていい。
進化も早く、知識も浅くて済むJSでは、今後とも資格は主流にはならないよ。

なおみんな「実力」は計りたがっており、テストで計れれば画期的だから、資格ビジネスも乱立するわけだが、
実際はこれは出来ない。理由はこれまた非常に簡単で、タイムスパンが全然違うから。
現代のプロのIT現場では通常の「テスト」のように、数分で完了するような仕事はない。
(その程度だとアマチュアでも問題なく出来てしまうため、今のプロには回ってこない)
人を採用するような規模の企業での実際の仕事は、数ヶ月〜1年くらいのスパンになるから、
テストで計れる「知識量」よりも、分からないことをWeb等で調べる「検索力」「応用力」、
或いは同僚に聞いたり教えたり仲良くやっていける「コミュ力」、
そしてプログラミングの本質である「設計力」が問われ、テストに比べれば時間制限なんて無いに等しい。
だから「テスト」で計ること自体がそもそも無理なんだ。

726 :デフォルトの名無しさん:2021/06/12(土) 21:21:07.32 ID:uQ7TEz17.net
ちなみに、何でそんな勘違いをしているのか知らんが、
・採用の際に言われたのなら、それはやるしかない。
 それは最低限の知識としてそこで線を引く、ということだから。
・そうでないのなら、学んだことを学んだとおりにグダグダ言わずにやる能力=学歴だから、
 勉強してマシな学歴を目指した方がいい。
勉強すれば何とかなる事柄なら、勉強が得意な奴=学歴で採用した方がいいし、
実際、企業の採用で学歴を重視されるのはこれだから。

もう学歴とかいう年齢ではないのなら、変に資格に拘るよりは、
・自分でサイトを作ってそこのコードも自分で書いて、それを見せた方がいい。
資格で計れるのは一定の知識があるかどうかだけだが、実際のサイトとコードでは、実力を示せる。
だから、採用側もやる気があれば必ず見る。(実際にWeb系の奴等もこれは言ってる)
まあ少なくとも、テストや資格で実力が計れる、なんて思ってるIT系の奴は一人もいないから、
IT系の資格ゴテゴテの奴が来たりすると逆に引かれると思うから、それは止めとけ。

727 :デフォルトの名無しさん:2021/06/12(土) 23:41:34.70 ID:TONJAMor.net
返信ありがとうございます。

728 :デフォルトの名無しさん:2021/06/13(日) 11:51:30.32 ID:DaJnimMO.net
>>724
そんなもんうちの会社の連中はほとんど持ってる。
あの程度が取れない奴はヤバい。

729 :721:2021/06/13(日) 13:42:06.32 ID:dsZW3Lb4.net
嘘くせー。

こう言うとキレられるのだろうけど、敢えて言っとく。
資格ビジネスでは受験者数が利益に直結するので、胴元連中は当然「すばらしい」と吹聴してるが、全部嘘だ。
実際は、「会社の連中はほとんど持ってる」のなら、その資格を持っていたところで「引く手あまた」なんて事にはならない。
むしろ「足切り」に使われるべきであるが、正直、これもない。
同様に「会社の連中は殆ど持ってる」のなら、現状どおりの採用活動でその程度の連中は十分に確保出来てる、ということだから。

そもそもそんな簡単に取れる資格で「引く手あまた」なんて事にはなり得ないし、
ググったところ360時間程度と書いてる奴が居るが、なら「半年も実務すれば余裕」って事だから、わざわざ取る価値もない。
(誰でも取れるような資格なんて意味がない)

それ以前に、会社の連中なんてそんな真面目じゃない。
もっとまともなTOEICですら自前で受ける奴なんて皆無で、昇進時に最低○○点が必要だからとか、社員は全員一律に、だから受けてるのであって、
わざわざ誰でも取れるような資格を取りに行くような連中はただの資格コレクターであり、ヤベェ連中だよ。
だから逆に言えば、この手の資格でも取らせないと勉強しない連中が多いから、報奨金を出す会社もあるようだ。
まあこれは人事戦略としては正しいのだが、そもそもWeb系って人事すら居ない規模の会社が多いだろ。

730 :721:2021/06/13(日) 13:42:40.11 ID:dsZW3Lb4.net
だからまあ、>>728が本当だとすると、
「あの程度が取れない奴はヤバい」ってことで、入社1年目の目標、2年目では義務、という雰囲気にして、
結果的に全員受験させて底上げ(最低限度の知識の確保)を目指すのは、人事戦略としては一見ありのように見えるが、
しかし実際に落ちた奴が居たとして、クビも切れないのなら虐めるネタにしかならないだろ。
だから、全員受かるか、落ちた奴をいびり倒して辞めさせるか出来ないと、余計に悲惨なことになる。
だからあんまりこれもないと思うんだよね。

まあいずれにしても、資格ビジネスをやってる奴は居るし、連中は都合のいいブログとかもデタラメに書きまくってるから、そういうのに騙されないように。
ドラッグストアの薬剤師のように、その資格がないとHTML5を取り扱ってはいけないのならみんな取るけど、
そうじゃないのだから取得するモチベーションも普通はないんだよ。

731 :721:2021/06/13(日) 15:18:32.08 ID:dsZW3Lb4.net
が、まあ、見ずに文句ばかり言うのもアレなんで、一応サンプル問題もチラッと見てみたが、糞だな。
これ知っててどうする?とか、こんなの覚えてる意味無いだろ、とか、そういうのばっかりだ。

ただまあ、IT系の資格って、どれもこれもこの手の糞なのも事実。
それは政府がやってるのも全部含めてだから、そもそもプログラミングが試験に向いてないんだよ。
勿論問題を作ってる馬鹿共が実はプログラマじゃないってのも大きいにしても。


実際は、新しい仕様はガンガン追加されるから、勉強してた頃には存在してなかった物に普通に遭遇することになる。
だから、覚えていることよりは、調べて正しく判断出来るかの方が重要で、
このテスト自体はCBTだからMDNを読みながら回答するのもありなのだろうけど、
実際はそれでは間に合わないのだろうし、やはり、よろしくはないね。

とはいえ、テストでプログラミングの実力を計りたいってのは需要はあるし、永遠の課題でもある。
俺はプログラミングはcraft(工芸、手技)に近く、テストしたければ絵と同様「実技」(絵ならデッサン)でやるしかないと思うけど、
これはプログラミングはknowledge(知識)であると考える奴(=この手のテストを作るような奴)には受け入れがたい思想なんだよ。
だからこんな感じに、昔からなってる。


ああそういえばgoogleは入社テストに実技を課すらしいぜ。
> 一次面接は電話で技術的質問をされました。二次面接は電話で会話をしながら、オンライン共有されたドキュメントにいくつかコードを書きました。
> https://note.com/neko_chan0214/n/n3a64bc1e1412
つまり電話品質の英語を聞き取れるかどうか、そこで「○○を修正してくれ」と指示出して的確にコードが修正されるか、を見てるわけだが、
極めて妥当だよね。これに問題なければリモートワークの下っ端としては十分なんだから、雇う分に問題はない。
(googleの場合は要らなくなったら簡単にクビも切れるし。なお就職後の本人は「思ってたのと違う」と萎えてたらしいが、よくは知らん)

732 :721:2021/06/13(日) 20:17:57.82 ID:dsZW3Lb4.net
>>724
駄目押しで言っておくと、こんな過疎っているところでそんなアンケートなんてやらないことだよ。
そんなことを聞く=自分で判断する能力がないって事だから、
デタラメなら突っ込まれる程度の人数が居る場所でないと嘘を吹き込まれてしまう。
(どうしても5chでやりたければマ板か嫌儲かな?)

俺は競プロや今回のプログラミング資格のような、
「ちょっと勉強して○○を取得するだけで人生バラ色」を吹聴している連中は基本的に詐欺師だと見てる。
だから我慢がならない。これがグダグダ言ってる理由。
>>728 が胴元の自演の可能性すらあるわけだし。


ただ、普通に考えれば分かる筈なんだけどね。
ITドカタがブラックだと言われて久しい。
(5ch発の例の「ブラック会社に勤めてるんだが、もう俺は限界かもしれない」もそれ)
だからそんな、精々数百時間の勉強で抜け出せる方法があるのなら、みんなやってるよ。
それ以前からある基本情報技術者とかでも、そんな都合のいい話は無いだろ。
学歴にしたって、3-6年間頑張って勉強してもままならないからこそ、それなりの価値があるわけであって。

現在、SESとかプログラミングスクールも乱立してて、
彼等は「プログラミングスクールに通って資格を取ってSESに入ればバラ色」と言うわけだけど、全部嘘だから。
だからどこでそんな資格のことを聞いたのかは知らんが、とにかく止めとけ。
既にプログラマとしてやってて、趣味で資格を集めてるのならどうぞ御勝手にだが、
わざわざ尋ねる=現在はプログラマではないのであれば、
技術レベルの保証にもならず、勉強したところで実力にもならない資格に対して、エネルギーを注ぐべきではない。
問題も、サイトを作って動かしてみれば普通に分かるだろ、程度の物でしかないから、
実際に手を動かしてサイトを作って、それを示した方がいい。
(ただしゆとりは絶対にこれをやらず、
「手を動かさずに効率的に学ぶのだ!」みたいな妙な信仰があるのも事実だし、
ぞれ以前に、ゆとりは上記の「普通に考える」を全くやらないのが問題なわけだが)

733 :デフォルトの名無しさん:2021/06/13(日) 21:58:17.40 ID:dsZW3Lb4.net
ちなみにどれだけ酷いかを一応言っておくとだな、サイトは以下で
https://www.html5exam.jp/measures/sample.html
https://www.html5exam.jp/measures/lv2_1.html

第一問:
obj.key-sampleってのが最悪で、そもそもチェインケースはJSというかプログラミング言語一般で使わない。(使えない)
だから最初何が言いたいのか分からなかった。
ただしHTMLには入ってしまっているのでそこはキャメルケース、つまりkeySampleにすることになってる。
だから普通ではあり得ない状況をわざわざ作ってるんだよこれは。
文法の細かい隅を付く為だけど、そもそもそういう使い方はしないようにコーディングルールが制定されてるはず。

マジで、JSでチェインケースを常用してる馬鹿なんて見たことがない。


第二問:
console.log(typeof [1, 2] + typeof null); もおかしくて、普通は
console.log(a, b); とか、コンマ区切りで出力させた方が断然いいから、こんなの知っておく意味はない。

typeof [] === 'object' と
typeof null === 'object' 、特に後者はJSでの実装ミス(仕様バグ)だから知っておく必要はあるけど、だから何?程度。
本当はtypeofを多用すること自体がプログラミング理論的には間違いだとされつつあるので、
Rustみたいに「型スイッチ撲滅しようぜ」ってノリの方が正しい。この場合こんなもん知らなくてもいいし。


とまあ、こんな問題出してて出題者は誰々です!っていわれてる方がヤベーんじゃねえの?と思うレベル。
その他もざっくり見たけど同様だよ。
ただしまあ、初心者あるある集ではあるのかもしれんが。

734 :デフォルトの名無しさん:2021/06/16(水) 17:15:31.15 ID:V9AslF47.net
>>724
こんなもんすぐに取れるはwwwwwwwwwwwwwwwwwwwwww
引っ掛け問題以外は、プロだったら誰でも知ってることばっかり。

735 :デフォルトの名無しさん:2021/12/28(火) 16:40:18.70 ID:ChI3TD7z.net
JavaScript classes are still the same as before,
except that the super keyword has been added internally.

Therefore, what you couldn't do before, you still can't do now.

Some people say that class definitions can be used to create code that is easy
to understand, but
However, I am not sure if it is easy
to understand for anyone.
I also feel that hiding the prototype makes it harder
for beginners to understand the essence of JavaScript.

You have to understand what kind of replacement the class syntax is internally
before you can learn it.
It's not a good way to learn.
But once you understand it,
I don't think there's any need to bother using classes.


Translated with www.DeepL.com/Translator (free version)

736 :デフォルトの名無しさん:2021/12/28(火) 18:47:52.24 ID:JyRJ6HRN.net
それだけの長文を連投する情熱ってどこから発生するの?

737 :デフォルトの名無しさん:2022/09/04(日) 10:45:48.62 ID:gMMLSyjY.net
JavaScriptの正規表現後読みのブラウザ対応表が(ずいぶん前から)MDNから落ちているのだけど、
何処かに有れば教えてくれ。(下記ページ内、ブラウザサポート部分)
https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Regular_Expressions/Assertions

これchrome以外は全然駄目で見捨てられてるのか?

738 :デフォルトの名無しさん:2022/09/04(日) 12:37:49.60 ID:FTTWPGH/.net
>>737
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/RegExp
のlookbehind assertions。safariが未対応

739 :デフォルトの名無しさん:2022/09/04(日) 13:19:42.31 ID:gMMLSyjY.net
>>738
ありがとう。助かりました。てかそっちに纏めてるのか。

740 :デフォルトの名無しさん:2022/11/30(水) 14:57:54.07 ID:puhqr6nn.net
ぼやき
MDN見て、セレクトボックスで beforeinput イベントを使おうとして、試してみたら発火しない
なんでだーと思ったら英語版には beforeinput イベントは input と textarea だと書いてあった
日本語訳の select が誤記載だったというオチ

登録してまで指摘投げる気はないので、編集できる人がここ見たらそのうち修正されるかなあと書き込み

741 :デフォルトの名無しさん:2022/11/30(水) 15:16:11.94 ID:G0TyVVXA.net
>>724
っていうか応用以上の情報処理試験でも言えるけど
落ちるような人にプロ名乗って欲しくない

742 :デフォルトの名無しさん:2022/11/30(水) 15:25:02.52 ID:G0TyVVXA.net
>>731
>俺はプログラミングはcraft(工芸、手技)に近く、テストしたければ絵と同様「実技」(絵ならデッサン)でやるしかないと思うけど

ここは賛成

743 :デフォルトの名無しさん:2022/11/30(水) 15:34:48.91 ID:G0TyVVXA.net
>>736
他人と少しでも仕事したことあるなら言いたくなることもあるだろう

744 :デフォルトの名無しさん:2022/12/21(水) 19:56:54.56 ID:ZLSsY0as.net
ブラウザ上で
別タブでページ開く→開いたページ操作→ページ全体あるいはDOMツリーの一部をスクショ
って可能ですかね?
素直にパペッター使った方がいいかな?

745 :デフォルトの名無しさん:2022/12/21(水) 20:53:36.23 ID:YF8SK8D8.net
>>744
今ググって知ったレベルだが、html2canvas使えば出来るらしい。
ただ、別タブを操作するには、そのページ内でJSを動かすかブラウザ拡張とかにしないといけない。
意味不明なら、意味が分かる方(=Puppeteer)を使う方が早いのではないかと。
自分がスクショ取りたいだけなら何でもいいし。

ユーザーにそのページのスクショ採らせて送らせる、というのならJSだが、
html2canvasはブラウザのレンダリングと異なることもあるらしいので。
(と言うほど問題ないのだろうし、見れば差異は分かるからデバッグ用途には十分だが)

746 :デフォルトの名無しさん:2022/12/21(水) 22:22:38.47 ID:TTkvZ9O6.net
>>745
サンガツ
要件的にパペッターが正解っぽいのでこっちで頑張るます

747 :デフォルトの名無しさん:2022/12/24(土) 18:22:53.96 ID:DZHz5J2C.net
高精度タイマ(performance.now())の精度を上げる(落とさない)オプションを知ってたら教えてくれ。

他のスレ見ててCORS回避のオプションがあることを初めて知った。
https://mevius.5ch.net/test/read.cgi/tech/1659855460/472
なら高精度タイマの精度を落とさないオプションも多分あると思って探したが、辿り着けない。
今見つけた限りで、一番多い一覧があったサイトは以下。
https://peter.sh/experiments/chromium-command-line-switches/

748 :デフォルトの名無しさん:2022/12/26(月) 03:08:30.89 ID:qg5Yi6nt.net
>>738-739
4年半以上かけてsafariでもようやく今月実装された
bugs.webkit.org/show_bug.cgi?id=174931

749 :デフォルトの名無しさん:2023/03/04(土) 11:08:58.95 ID:BmFTVnYF.net
JSの条件式はifを使わなくても色々書けて楽しい。

750 :デフォルトの名無しさん:2024/03/03(日) 21:51:15.73 ID:BcWORH9H.net
>>737-739と同じだが、
また正規表現先読み/後読みのブラウザ対応表が行方不明になってる。
どこにあるか知ってる人がいたら教えてよろしく。

751 :デフォルトの名無しさん:2024/03/03(日) 23:23:16.95 ID:7fNlciS5.net
>>750
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Regular_expressions

752 :デフォルトの名無しさん:2024/03/03(日) 23:42:51.53 ID:BcWORH9H.net
>>751
早速ありがとう。助かります。
つか、RegExp等のページ先頭でアナウンスしてる「正規表現について…」が"Guide"行きで、
この"Reference"に繋がってるリンクがないんだな。だから俺はGuide側で迷子になってた。

753 :デフォルトの名無しさん:2024/03/19(火) 11:12:20.58 ID:N0+FD4yc.net
if () {}やfor () {}など}の後に;をつける人ってどれくらいいるんだろう?
ESLintの警告でやったほうがいいのかなぁと思ったり思わなかったり

754 :デフォルトの名無しさん:2024/03/19(火) 13:05:44.14 ID:d3TWJjaW.net
>>753
> }の後に;をつける人
C/C++/C#/Java等、セミコロン省略禁止の言語でもそこに付ける奴はいない。
つかお前根本的に勘違いしてるからきちんと確認しろ。

そしてその程度ならどっちでもいいからさっさと次に進め。
セミコロンを打つ打たないに拘り始めたら無駄に足踏みして上達しなくなる。
絵を描くのが目的なのに、鉛筆の削り方に拘りすぎて絵を描かなくなるようなものだ。
コードも同様、書いて動かしての反復で上達するのであって、書かないのではどうにもならない。
(書く前に考えろ、というのはあるが、今のお前はそのレベルに達してない)

通常はリンターの警告を全部無くすようにする。
これはリンター製作者がお前よりJSに詳しいという仮定だ。
少なくとも分かるようになってリンター製作者の思惑も見えてきてウザくなるまではそうするべき。
そもそも警告が出てる箇所を間違ってると思うから、まずお前は全部リンターに従うべきだろうよ。

755 :デフォルトの名無しさん:2024/03/19(火) 13:35:59.75 ID:d3TWJjaW.net
>>753
と思ったが、もしかしてPythonやRuby等、セミコロン書かない言語の出身か?
ならJSの文法がユルイ所は全部無視して、さっさと進めばいい。

一応セミコロン書かない派閥もあるし、そのコーディングルールもある。
(ESLintもno-unexpected-multiline指定でセミコロン無しルールで動くらしい)
リンターを通すのが目的ではなく、アプリケーション開発の生産性を上げる為にリンターを通すのだから、
自分が書き慣れたスタイルで行くべき。
(ただそこに引っかかる程度ならお前はまずセミコロン必須言語で修行すべきとも思うが)

466 KB
新着レスの表示

掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :

read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★