15/12/07 07:27:56.10 7ldc1+VM.net
↓ こちらへどうぞ
【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ52【php,py,pl,rb】 [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(tech板)
3:デフォルトの名無しさん
15/12/07 13:08:45.86 ZskqcMPL.net
JavaScript リファレンス - JavaScript | MDN
URLﾘﾝｸ(developer.mozilla.org)
4:デフォルトの名無しさん
15/12/07 21:04:06.51 Pr/O+rrT.net
(1) プログラミング既習者専用です。初心者の方はご遠慮下さい。（大事なことなのでry
ここで言う初心者とは、3,000行のプログラムを動かすのにも苦労する人達のことです。
なお、JavaScriptの習熟度は問いません。
言語を問わず、3,000行程度なら楽勝であれば問題ありません。
(2) 初心者だと思える投稿は無視してください。初心者用スレは他に沢山あります。
(3) 質問スレではありません。特に初心者からの質問はガン無視でお願いします。
(4) 長文が読めない低脳はお引き取り下さい。
【リンク集】
URLﾘﾝｸ(developer.mozilla.org)
URLﾘﾝｸ(msdn.microsoft.com) (JavaScript)
URLﾘﾝｸ(hakuhin.jp) (逆引き）
URLﾘﾝｸ(stackoverflow.com)
他仕様書等のリンクは質問スレのテンプレを参照してください。かなり整備されています。
プログラミング既習者であれば、MDNとMSDNでほとんど事足ります。
ブログ等は間違いが多すぎるので、MDNのサンプルコードから出発することを薦めます。
逆引きなら上記hakuhin.jp、困った場合はstackoverflowが秀逸です。
【初心者用スレ】
JavaScript の質問用スレッド vol.118 (ム板質問スレ)
ｽﾚﾘﾝｸ(tech板)
ECMAScript デス 5 (ム板仕様スレ)
ｽﾚﾘﾝｸ(tech板)
【超初心者用スレ】
JavaScript の質問用スレッド vol.127 (Web制作板質問スレ/頻繁に分裂中)
ｽﾚﾘﾝｸ(hp板)
テンプレは>>1と>>4
5:デフォルトの名無しさん
15/12/07 21:06:06.02 Pr/O+rrT.net
[状況]
Web制作板はIDが出ないのでアフィカス/teratailerが暴れている感がある。
「1～10まで足す」みたいな質問にも回答が付くという奇妙さだ。
また、ライブラリ厨の意味無い布教活動も嫌がられている。
個人的には低脳アフィカスが一番の癌だと思うが、
奴らは印象操作が目的なので反論されても喚きちらすだけ。
もう超初心者スレとして分離するしかない。
回答する奴も初心者なのでデタラメだらけだが、あいつらにはそれでも問題ない。
明らかに間違っている事を正しいと言い張る馬鹿共を矯正する方法は2chにはない。
ム板の質問スレはIDが出るので、逆に言えばIDが出て困る奴はいない。
ほとんど流れていないが、質問すればWeb制作板と同レベル以上の回答は付く。
まともな回答を期待するのならこちらに投稿した方がいい。ただし回答が付くまで時間がかかる。
Web制作板の方はIDが出たら困る奴が「流れているスレ」として見せるために無理矢理流している感がある。
このため、上記のように、ただ単に無視すべき投稿にもレスが付く、どうしようもないスレになっている。
また、どうでもいい一般論を投げかけ、無理矢理流そうとしているものも散見される。
やりたい放題やられているわけだが、しかしその先には何もないように思えてならない。
何がやりたいのかはかなり疑問だ。ただ、止める方法もないので、分離するしかない。
仕様について厳密に詳細を確認したければECMAScriptスレがいい。
正直、他も含めてJavaScriptスレ住民の仕様に対するこだわりは異様だと思うが、
逆に言えば、厳密に議論したければ相手はそこにいる。
ただしそいつらは仕様にはすごく詳しいが、コードは記述していないらしく、
何が本当に問題なのかを実感できていない。
だから地に足のついていない議論になってしまう。
とはいえ、詳しいことは事実だ。だから仕様について正確を期すのならそこがいい。
6:デフォルトの名無しさん
15/12/07 21:36:46.92 Pr/O+rrT.net
以上、どうしようもないスレばかりなので新しく「プログラミング既習者専用」スレを立てることにした。
現時点でまともな奴がほぼいないので、新しく訪れてくれる人を待つことになる。
気長な話になるが、やらないことには始まらないので、とにかく始めることにする。
3,000行についてだが、OAOOはもちろん徹底しているとして、
1,000行なら勢いで書いてしまえる規模だ。
ところが3,000行となると、内部構成をある程度マトモに設計していないと破綻し始める。
逆に言えば、内部設計を正しく行い、かつ実装できる人の目安として3,000行を楽々、とした。
7:デフォルトの名無しさん
15/12/07 21:39:35.47 Pr/O+rrT.net
[状況追加]
11/28に立てたスレ（同スレタイ）
ｽﾚﾘﾝｸ(tech板)
が何故か1週間で落ちたので、もう一度立て直した。
2ヶ月以上書き込みがないスレもこの板にはあるので、書き込みが無くて落ちたわけではなさそうだ。
削除依頼も確認してみたが、該当はなかった。
質問スレがvol118, vol124と完全に被っているのに放置されているため、重複削除でもない。
原因が不明のため、とりあえず再び立てて様子見することにした。
一応7日ほどは持っていた（はず）なので、4-5日程度毎に俺が話したい案件を上記前スレ
ｽﾚﾘﾝｸ(tech板:4-7番)
からコピペしてきて落とし、これでしばらく持たせる。
もちろんそれ以前に話題があれば勝手に開始してくれて構わないし、
俺の案件についてレスを付けてくれれば応じる。
このスレの狙いは、まずは人を集めることだ。だから半年以上持たせる必要がある。
あの質問スレの状況だと、まともな上級者はウザがって寄りつかない。
上級者を集めたいのなら、彼等にとって読む価値のあるスレを用意して待たなければならない。
これには時間がかかる。機能するには半年以上かかるだろう。
しかし、やらないことには始まらないので、とにかく始める。
出来るだけ落ちないように努めるが、いかんせん基準が分からないのでまた落ちるかもしれない。
その場合は再び立て直すが、それにしても落ちまくるのは問題なので、
基準を知っている人がいたら教えて欲しい。
8:デフォルトの名無しさん
15/12/08 09:13:19.90 DJ+OQKIp.net
>>7
10レス未満だと落ちるよ
9:デフォルトの名無しさん
15/12/08 09:14:10.74 DJ+OQKIp.net
保
10:デフォルトの名無しさん
15/12/08 09:14:58.16 DJ+OQKIp.net
守
11:デフォルトの名無しさん
15/12/08 21:57:28.55 lwK5Kg+O.net
>>8
ありがとう。了解した。
とはいえ予定は7の通り。
12:デフォルトの名無しさん
15/12/11 22:17:41.43 D3bPQRrf.net
>>8
EMCAスレが落ちているのを確認した。
10スレ未満は丁度1週間で落ちるようだ。
それはそうと、現実問題として上級者がJavaScriptにはいない（いにくい）のかもと思うようになった。
元々は単なるヘルパースクリプトで、質問スレ見ても分かるとおり、単発の修正とかに使われていた。(はず）
今なら「PHPでやれ」と回答すべき案件等と言えば分かりやすいか。
Ajax以降は必要となれば大型化するが、クライアント側に大型データ構造を持つ使い方は自然ではない。
MMORPG等をWebGLで実現するにしても、クライアント側は描画に徹してデータはサーバ側に送るのが普通だ。
だから内部構造にこだわるべき中級者以上が育たない（必要ない）環境なのかもしれない。
あるチームでサーバクライアント型アプリ（ゲームでもチャットでもいいが）を作るのなら、
サーバ側に実力者を振り分けなくてはならないのは自明だ。
とはいえ、出てくるかどうか待ってみることにする。
ググれば分かるとおり、奴らはQiitaが好きみたいだが、俺は匿名の方がいいと思っているので。
とはいえ、匿名掲示板はどうしても雑音が多すぎる。
彼等がQiitaのほうを好むのなら、いくら待っても空振りで終わる。
それでも俺は試してみるが、盛大に空振りするかもしれないのでそのつもりで頼む。
13:デフォルトの名無しさん
15/12/13 21:10:31.93 l4buRphf.net
JavaScript 「再」入門 - JavaScript | MDN
URLﾘﾝｸ(developer.mozilla.org)
14:デフォルトの名無しさん
15/12/15 20:58:50.84 tWI33UQV.net
ECMAスレに居た人と実際にコードを書いてる人は層が違うと思うけどな。
言語仕様を愛する人と、WebAPI技術を愛する人と、フレームワークを愛する人は違うだろうし。
15:デフォルトの名無しさん
15/12/15 22:49:00.04 Lzs/Av6i.net
>>14
ああ、あれは明らかに違う連中だ。少なくとも俺と同じ側ではない。
プログラミングなんて本来は手段、従ってプログラミング言語は包丁であって、
もちろん包丁職人やコレクターもいていいが、道具として使う料理人が一番多いのが普通。
しかし彼等は異様に細部にこだわっている。彼等は何者だと思う？
そもそも仕様仕様とうるさいのだが、仕様の細部なんて使わないのが普通だと思うのだが。
Q. String が期待される関数 function func(str) に対して Array が与えられた場合はどうするべきですか？
A1. 当然暗記している型違い時の変換規則を活用し、適切に対処します。
A2. それはただのバグです。
型付き言語だとそもそもA1はコンパイルが通らない。
俺は型付き言語出身だから、当然A2で組んでいる。使う予定のない変換規則なんてどうでもいい。
ところが彼等はこれじゃ駄目だと喚く。
でも具体的にどう活用すればメリットがあるのかは示せない。
何なんだよいったい、と思う。
ところで連中は立て直さないのかな？
16:デフォルトの名無しさん
15/12/15 23:46:05.86 bVMdPRVE.net
>>15
それはダックタイピング系のことをちょっと大げさに捉えすぎて無いかい？
それと引数の型についての選択肢としては
A1.何も気にしない
A2.極力活用するよう努力する
A3.型チェックをしてエラーとする
の３つだろう。
例えばpromptの返り値のstrに対する処理をコードにするとこう
A1. str.slice()
A2. (str||'').slice()
A3. if(typeof str!=='string')throw 'No!';str.slice()
で、
A1派は、メソッドを持っていればそれで処理をさせて問題ない。
null等は自動的にエラーになるのでちょうどいい。
A2派は、どちらにしろ空の値はpromptをやり直したり別途特別な処理するんだろうから
nullなど無効も極力エラーは出さず空の値と評価してやるくらいがちょうどいい。
A3派は、来て欲しい型でなければエラーとするのが最も安全。
というような主張だろうが、君はどんな主張で、どんな主張に納得してないの？
17:デフォルトの名無しさん
15/12/16 00:04:47.52 4ol9X0cq.net
また型が把握できる場合と、何が来るか本当にわからない場合では当然スタンスが違うと思う。
後者でいうと、Stringが期待される場面でArrayが来た場合なんてどうしようも無いだろうが、
Arrayを期待する場面なら他のArrayLikeなオブジェクトもArrayとして見てやるべきじゃないかという論になる。
そこで、また派閥が分かれるだろう。
何もしないまたはエラーとする（Array.isArray）（Arrayだけしか面倒を見ないから）、イテラブルだけ面倒見る（[...arg]）か、
多くのArrayLikeを面倒見る（Array.from(arg)）か、何もしないまたはエラーとする（例えArrayに変換できなくともArrayのメソッドを持っていればよい）
また、配列の使い道によっては@@isConcatSpreadableを考慮するかどうかも問題になってくるだろう。
18:デフォルトの名無しさん
15/12/16 00:25:57.22 bKnAvTte.net
まあ本当にそっち系の人はこんなもんじゃないか。
Object.prototype.toString.call(arg) == '[object Array]'
とArray.isArrayの違いとどちらが適切かを語るレベルまでいけば一人前か。
まあ彼らは意味に敏感なんだろう。
配列を期待するといっても、配列はいろいろあるし、期待の仕方もいろいろある。
なまじいろいろ知ってるだけに細部に拘りたくなるのだろう。
19:デフォルトの名無しさん
15/12/19 02:38:04.74 BBkFE1FJ.net
都合上、>>7の前スレの内容を先に全て落とす。
以下4投は転載。
20:前スレ4
15/12/19 02:38:56.06 BBkFE1FJ.net
とりあえず俺が話したい項目を挙げておく。
気になる物があれば勝手にレスを付けてくれ。
もちろん他の誰かが勝手に始めてくれても構わない。
俺も気になれば勝手に参加するし、どうでもよければ無視する。
使い方は基本的に他のスレと同じ、ただし初心者お断り、だ。
21:前スレ5
15/12/19 02:39:25.80 BBkFE1FJ.net
・コーディングストラテジー
ｽﾚﾘﾝｸ(hp板:550番)
ｽﾚﾘﾝｸ(hp板:562番)
JavaScriptに於けるコーディングストラテジーだが、単純には以下2つのどちらかだと思われる。
α. 安全重視、全箇所で型/値チェック。
β. 簡素化重視、最初に型チェック、以降は「型」までは確定、値については保証無し。
αは関数単位で抜き差しが可能。その点機能の追加/削除は楽だ。
各関数は型判定等を持つため複雑になるが、安全領域を管理する必要がない。
βは期待される型以外では何も考える必要がないため、その分関数の仕様が小さくなり、
デバッグが楽でバグも出にくく動作も速くなる。ただし、型チェックを既に通っているかを管理する必要がある。
ネットワークに於けるファイヤウォール内/外の管理のようなものだ。
基本的に関数毎の抜き差しはできない。型チェック部分＋動作部分のセットでやらないと駄目だ。
だから関数単位での粗結合化はできない。
俺はβでやっている。
そして現実的にはβしかないように思えるのだが、どうか？
可能であれば直接本職の方々の意見が聞きたいが、
JavaScriptはソース見放題だから、企業のサイトのソース（=本職製）からの類推でもいい。
ダックタイピングを生かすのなら多分αじゃないと駄目なのだが、
俺は型システムに慣れているというのもあって、今のところダックタイピングの利点を感じられない。
αだと各関数で様々な型を処理しなければならず、これがバグの元になるので、
最初からStringならStringと決めうちで各関数を用意、Stringしか入力されないように上位階層で対応している。
22:前スレ6
15/12/19 02:39:52.02 BBkFE1FJ.net
・プロトタイプの活用
静的クラスでは出来なくて動的プロトタイプでは出来ることを使って、何かできないか。
今思いつく中では、以下がある。
A. 動的プロトタイピング(__proto__の頻繁な変更）
B. インスタンスツリー
C. 親への透過的アクセス（親に動的に追加されたプロパティに対する透過的アクセス）
Aは変更自体はやっているが、頻繁に変更する需要がないのでそれ以上試していない。
Bは現在試しており、見にくくなる以外の弊害はない。見にくさについてはデバッグ用環境を整えて対応した。
メリットはフィールド共有によるフットプリント削減だが、
しかしこれはあらかじめ共有すると分かっていれば静的クラスでも出来る。
デタラメに共有したりしなかったりする場合も、
共有する派生クラスと共有しない派生クラスを用意すれば、静的な場合は対応可能になる。
従ってどうしてもというのならやはり動的なものに限られてしまうのだが、これは需要がない。
Cは試したいところだが需要がない。
従って、仕様としては出来るが、実際の需要がなく、活用できていない。
他の活用案もあれば是非。
23:前スレ7
15/12/19 02:40:19.96 BBkFE1FJ.net
・ダックタイピングの活用
共通基底クラスを持つ場合、当然ポリモーフィズムできるとして、
ダックタイピングの場合は、共通基底クラスを持たなくても、共通の名前のメソッドがあればポリモーフィズムできる。
だからといっても、活用案がないので、事例があれば是非。
24:デフォルトの名無しさん
15/12/19 02:41:08.31 BBkFE1FJ.net
以下、全て>>16の定義で。
>>16
こちらは基本A1で組んでいる。初段はA2もあり得る。
理由は>>21のとおり、入力段で型を確定させる方が楽だと判断しているから。
JavaScriptの場合、型が確定しないのはDOMか鯖からの入力に限られる。
だから最初の段で型を確定させ、以降は型確定で組んでいる。
この場合、型確定エリアと型不確定エリアが明確に分離されるので、型確定を忘れるとおもむろにバグる。
しかしこれは前述のように限られており、見落としたりする心配はほぼ無い。
型を不確定のまま伝搬させるのは余計に難しい。だから通常あり得ない。
となるとA2/A3が必要なのは「どこから呼ばれるか分からない」という関数だけになる。
（型不確定エリアからの直接呼び出しがあり得る）
これについてはプログラムを見てそういうことがないように確認すればいいという事にしている。
というわけなのだが、どうかね？
A2/A3は関数の機能としてはA1のスーパーセットになる。型が予想外の時の分だけ仕様が大きい。
だからA1で組んでしまうのが楽だ。問題は見落としがある可能性が残る点。ただし、これは見やすい。
A2/A3の場合は見落としは考える必要はないが、
個々の関数が全ての型について設計通り動くことが求められるので、
テスト項目が多くなり、またバグを誘発しやすいと見ている。
ちなみに、「何が来るか分からない時でも正常動作」というのは、考えていない。
というか、その時はバグっていいという判断だ。
・入力が明確に間違っている場合、再入力を求める。誤入力状態での表示はどうでもいい。
・Ajax結果が不正の場合、リロードする必要がある。このときも表示はどうでもいい。
所詮はヘルパースクリプトだから、この辺で留めている。
25:デフォルトの名無しさん
15/12/19 02:42:15.14 BBkFE1FJ.net
>>17
それはダックタイピングだと思うが、正直俺はその点に関しては気にならない。
期待通り動けば何でもいい。
気になる人は例えばtoString()の解釈について、
・ダックタイピングだ。toString()があるから使えるだけ。
・各型についてtoStringというインタフェースが実装されているのだ。
・toString()はテンプレート関数で、各型についてオーバーライドされているのだ。
と考えることが出来るかもしれないが、俺はどれでもいいと思っている。
JavaScriptはthisを関数側に持たせているため、callを使って他型のprototype等を間借りすることが出来る。
これは便利ではあるが、しかし真面目にインタフェース等で実装すれば済むことが大半だ。
だからこの方式もthisがいちいちはがれてbindしなければならない方が面倒だ。
classシステムのようにインスタンス側にthisを持たせる方が理に適っているように思う。
26:デフォルトの名無しさん
15/12/19 02:42:41.90 BBkFE1FJ.net
Array.from()を実装したとして、それがどこまでの範囲で使えるのかは「使う側が確認する必要がある」とする。
つまり、callで突っ込むのは勝手だが、ちゃんと動くかは「確認しろよ」ということだ。
その手の動作範囲を広げていくのは、YAGNIとかKISSとか言われるらしいが、大体無駄に終わる。
だからArray.fromの実装側は自分が使う最小限に留めて良く、間借り側が正常動作を保証しろと考える。
これはおそらくJavaScriptの思想とも合致している。
ArrayのメソッドはgetElementsByTagName等で返されるCollectionに対しても大体動作するが、
動作の保証はしていない。
つまり、間借り側(Collectionでcallする側）が正常動作を保証（確認）する必要がある。
クラスシステムの場合、実装してあれば確実に動作するし、実装していなければ動作はしない。（間借りも出来ない）
JavaScriptの場合は、使えそうなら使ってねといういかにも曖昧な感じで、それでいいのか？という疑問はあるが、
上記のように、「バグってたらリロードでおk」ならこの方が色々楽なのは事実だ。
結局の所、出自が（というよりも今も大半の用途でも）チョロスクリプトなので、それ向けに仕様がチューニングされている。
これで大規模なプログラムを組むのがそもそも無理がある、ということなのだとは思う。
チョロスクリプトとして使う分には、なかなか面白い仕様だと思う。
27:デフォルトの名無しさん
15/12/19 02:43:14.27 BBkFE1FJ.net
>>18
それは同じだと思うが、違うのか？
=== なら以下にポリフィルとしてそのまま記載されている。
URLﾘﾝｸ(developer.mozilla.org)
== の場合もその場合は危険性がないように思える。
ただし、これについては俺は真面目にやってないので自信はない。
ただ、そもそも「文字列との比較は === 」というのが lint で引っかかるので、常にそうすればいいだけだ。
> なまじいろいろ知ってるだけに細部に拘りたくなるのだろう。
これはあると思う。
あれだけ仕様が小さくて頭の中に入りきるサイズだから、というのはかなりあると思う。
C#やJavaなら調べながらのコーディングになるので、気にしてられない。
28:デフォルトの名無しさん
15/12/19 04:44:14.14 WePRjNql.net
>>26
問題はArrayが少し変わったオブジェクト程度であること
そしてArrayのメソッドは、ArrayLike（この場合lengthを持つもの）について保証していて最初からそのように作られている
JSにおいて配列の最も基本的な定義はlengthプロパティに要素の長さを記録しているもの程度のことでしかない
当然DOMの配列でも動くし、型付配列でも動く
それなのにわざわざArrayだけでしか動かなくする必要があるのか？
ここがミソで、わざわざArray以外にも対応する、のではなく、わざわざ対応しないようにするのかと考える
Array.isArrayは型付配列すらtrueを返さない
isArrayは配列がどうかのチェックではなく、Arrayかどうかのチェックだ
配列を扱うとする関数でArrayだけに絞るのはJSにおいて必ずしも十分ではないということだ
その関数を作る目的と使われるシチュエーションを考慮しないといけない
>>27
@@toStringTagをお忘れかな？
===の件もそうだな
どうして必要もない制限をわざわざするのか？と思ってしまう
というのは半分ウソで、実際は他の演算子と文字数が違うものを基本で使うのは気持ちが悪いから==を基本で使う
経験上==を基本で使ったからといってバグになるようなことはない
型変換のバグは予想外に同値判定で通ってしまうことよりも、予想外に通らない事のほうが圧倒的に多いのだから
29:デフォルトの名無しさん
15/12/20 00:52:32.40 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:デフォルトの名無しさん
15/12/20 00:53:42.58 wOVtY/I0.net
> 経験上==を基本で使ったからといってバグになるようなことはない
> 型変換のバグは予想外に同値判定で通ってしまうことよりも、予想外に通らない事のほうが圧倒的に多いのだから
まあ実際はそうなるはず、というかそれを目指して型変換規則が作られているはずなので。
実際のコードを見ると、==派と===派は半々という感じか。
一応googleのコーディング規約には === を使えと明記されていたはずだが、今見ると無い。
削除されたか、或いは俺の勘違いかだが、しかし日付を入れてないからどっちか分からない。
URLﾘﾝｸ(google.github.io)
この手のドキュメントのリリース日が辿れないってマジで馬鹿なのかあいつら。
というかこの辺で色々文化が違って無駄にストレスが溜まる。
俺は見た目はどうでもいい派なので、文字数の違いとかは気にならない。
俺が組んだところは基本的に === でも動くようにしてあるので、全部書き換えてもほぼ問題ないはず。
実際は歴史的経緯で混在しまくり、今更書き換えてデグレードするのは避けたいので、放置している。
ただJavaScriptの本来の設計は == なのだと思う。
（基本 == で、真に必要がある場合は === で)
31:デフォルトの名無しさん
15/12/20 00:54:09.55 wOVtY/I0.net
とはいえ、実際の所、他言語だと「潜在バグ」を嫌うので、===推奨になるのも分かる。
というか、おそらくそちらの方がプログラミングとしては正道だ。
JavaScriptの仕様は、「チャキチャキ作ってサクッとリリース」向けであり、「バグがないプログラミング」向けではない。
とはいえ、Webにはこれが正しいのも事実。
マイナーバグに対する作り込みでリリースが遅れるくらいなら、
バグがあってもクリティカルでないのならリリースした方がWebにはいい。
相手は「今欲しい機能」を求めているのだから。
逆に「バグのないプログラム」を目指すのなら、基本===ベースで行った方がいい。
相手は「将来欲しい機能」を求めていて、そこにバグがあっても困るという人だから。
ここら辺は置かれた状況の違いで文化の差異が発生していると考えている。
> わざわざArray以外にも対応する、のではなく、わざわざ対応しないようにするのかと考える
これが典型で、「100%動く保証」が必要か、「99%動けば問題ない」とするかだ。
見た目動いているからいい、を是とするか非とするかとも言える。
テストで100%網羅できることはない。
バグが無いことを目指すのなら、対応している事が確認できなければ使えない。
Array.isArrayでそれが確認できるのなら、それは使える仕様だ。
32:デフォルトの名無しさん
15/12/20 00:54:39.34 wOVtY/I0.net
@@toStringTagの件でも思ったが、まだ「ローカルプロトタイプ」は出来ないのか？
クラスシステムモドキで頑張っているようだが、元々prototypeを拡張するように設計されており、
実際の所、それの方がどう考えても使い勝手がいい。
だから、prototype.jsが流行ったというのも分かる。
問題はプロトタイプ汚染が発生することで、
逆にいえば、ローカルプロトタイプが規定できて汚染が発生しないのなら、おそらくそっちの方がいい。
とはいえ、今でも手動で __proto__ 等を使って設計できそうではある。
誰もこれをしないのはまた別の問題があるのか？
jQueryにしてもバージョン混在の問題があり、もちろん回避策もあるわけだが、
そもそもjQueryをローカル読み込み出来れば問題なくなるはず。
システム的にはスコープチェーンを辿っていく方式なので、
関数単位でのローカルプロトタイプは出来るように思えるが。
@@toStringTagについては、誰かが書き換えた影響が自分にも出る可能性があるということだと思うが、
この手のプロトタイプ汚染っぽいものを言語的に排除できるようにして、
prototypeを自由に拡張するのが本来のJavaScriptの思想だと思うのだが。
元々一人で組むチョロスクリプト用だからその機能がなかったのは仕方ないとしても、
無理矢理クラスにしようとしていて手こずっているように見える。
ローカルプロトタイプの方が多分この言語的には似合うだろう。
誰もやろうとしていなさそうなのは、何か別の問題があるのかな？
33:デフォルトの名無しさん
15/12/20 04:56:15.02 xspa4nJy.net
>>29
無理やりArray的アクセスが出来るように見せかけただけのものというより、
DOMのコレクションはそれはそれで立派なArrayとは違う配列。
そしてslice等の破壊的メソッドが通らないのは、見せかけだからではなく、
凍結された配列だから破壊的操作を受け付けないから。（エラーは返す）
>>32
プロトタイプ汚染というのはビルトインを拡張するときくらいしか問題にならない。
それすらもES6モジュールで分離すれば解決するだろう。
それと、自由に「.prototype」を拡張することではなく自由に「プロトタイプ」を定義できることこそが、
インスタンスベースと見た時のJSの思想だと思う。
34:デフォルトの名無しさん
15/12/21 01:11:35.42 RcNL5yk7.net
>>33
ふむ。もう一度確認してみたがエラーにはなるようだ。
確認してから書いたのだが、どうやら間違っていたらしい。すまん。
> それと、自由に「.prototype」を拡張することではなく自由に「プロトタイプ」を定義できることこそが、
> インスタンスベースと見た時のJSの思想だと思う。
多分これは違う。
> 自由に「.prototype」を拡張する
これでは既存のクラスシステムと同じだ。
「自分で型を作れる」または「『新規の』型を自分で作れる」だけに過ぎない。
JavaScriptのプロトタイプベースは、「既存の」型を拡張できるところが違う。
ただこれを活用できるかはまた別だ。
これはMDNでも紹介されている。
> これはとても強力です。
> JavaScript では、プログラム上でいつでもどれかのプロトタイプを変更することができます。
> ということは、実行時に既存のオブジェクトに対して追加のメソッドを加えることができるのです:
> （中略）
> これは Person オブジェクトをデバッグするときに役立ちます:
> URLﾘﾝｸ(developer.mozilla.org)
ただしデバッグ時以外に活用する方法を誰も思いついていないのだと思う。
35:デフォルトの名無しさん
15/12/21 01:12:01.84 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);
> };
> URLﾘﾝｸ(developer.mozilla.org)
36:デフォルトの名無しさん
15/12/21 01:12:28.39 RcNL5yk7.net
> プロトタイプ汚染というのはビルトインを拡張するときくらいしか問題にならない。
> それすらもES6モジュールで分離すれば解決するだろう。
しかし@@toStringTagの件はそれだろ？
俺は「そんなの書き換える奴が悪い」で終わりだが、
それが許されないから ==='[Object Array'] では駄目で Array.isArray なんだろ？
ただ import で自由にビルトインも含めて拡張できるのであれば、
上記「禁忌」とされてきて開かずの扉になっている部分を、誰かこじ開けるかもしれない。
37:デフォルトの名無しさん
15/12/21 05:09:36.07 hMKGO21d.net
==='[Object Array'] では駄目で Array.isArray は良いとかではなく、
@@toStringTagを考慮してあげるか、そこまでしないかの差だというつもりで差があると言ったんだよ。
そもそもisArrayもProxyは通すからね。別にisArrayに通ったからといってそれがArrayの動作をすることまで保証されていない。
起源がArrayだという程度の意味しかない。
それで十分な場合も多いと思うが、より良い配列の判定がある場合も多いという話がしたかったのだよ。
あと、ビルトインの@@toStringTagが書き換えられた場合というのを、良い悪いで判断するのも自分の感覚と合わない。
そういった行いを尊重しようとするか、しないかの判断ではないかな？
それとprotoypeというのはあくまでnew演算子が活用するだけのものであって、
それ以外に特別な意味はないし、プロトタイプベースの一角でしか無い。
一番大事なのはプロトタイプを変更できること。
それと動的変更は別に動いてる最中ではなく、変更をかけてから動かすという方が主だろう。
コンパイル言語ではなく、Web上で不規則かつ非同期にいくつものスクリプトが読み込まれ実行されるものなので、
何かを拡張したりするには、実際に動きながらするのが最も妥当な方法だ。
38:デフォルトの名無しさん
15/12/23 00:27:11.83 fUoT5vqI.net
ここは「言って欲しい意見」を期待できるところではない。それは諦めろ。
さすがにそれだと本当に書いているのか疑問だ。
色々ツッコミどころはあるが、一つずつ行こう。
> あと、ビルトインの@@toStringTagが書き換えられた場合というのを、良い悪いで判断するのも自分の感覚と合わない。
> そういった行いを尊重しようとするか、しないかの判断ではないかな？
ビルトインの@@toStringTagの書き換えを尊重する場合って、具体的にどんなケースがあるんだ？
俺はこれはコーディング規約で禁止にされるべき項目だと考えている。
39:デフォルトの名無しさん
15/12/24 07:58:45.60 Y5sNONvq.net
>>38
「言って欲しい意見」を期待とはどういうことだ？
そちらがこちらの話した意図を正しく捉えて無かったようなので補足したまで。
そしてコーディング規約で禁止とかいうのが考え方狭すぎだろう。
JSはハックやパッチにも使うもの。
Arrayの@@toStringTagを書き換えたのなら、それ自体がほぼ目的の
それはArrayをStringTagで判定しているところに通さなくしたいというケースも有るだろうし、
一方大規模開発でStringTagに追加でメタ情報を付与して活用しようとするケースも有るだろう。
例えばArrayのStringTagを"Array:Any"とかにして、
int8型配列のを"Array:Int8"、他の自作配列を"Array:Hoge"にし、
デバッグや補助関数で活用するということも出来るだろう。
40:デフォルトの名無しさん
15/12/24 18:11:12.05 k1/8SWkC.net
まあ自分が今回JSらしさとかtoStringTagらしさをどのように語っているのかというと、
仕様の定義に根拠を置いているんだよね。
緩いJSとは言え本当にすべきでないようなことや悪いことは仕様で禁止されている。
逆に禁止されていないのであれば、原則活用することは罪ではないと考える。
例えばtoStringTagはWritableがfalseだから通常無意識に書き換えられるようなものではないが、
Configurableはtrueなので強い意志があれば書き換えて良いものとなっている。
一方コンストラクタのprototypeプロパティはConfigurableがfalseだ。
これはJSにおいてprototypeプロパティのないコンストラクタはコンストラクタとして最低限成り立たない、
もしくはprototypeプロパティのないコンストラクタはJSらしくないからだ。
こういった改変をしようとするのは悪だと考える。
まあ互換性によって残っている良くない仕様というのもあるので、全て価値観を仕様に頼って良いわけではないが、
toStringTagなんてものはES2015において新しくよく話し合われて入れられたものであり、
その様々なシチュエーションで使えるようにしてくれた意志は尊重すべきだと思っている。
これが土台で、勿論その上に事案毎にコーディング規約やらが来る。
41:デフォルトの名無しさん
15/12/26 19:51:45.07 WET3gKUy.net
「Microsoft EdgeのJavaScriptエンジンを、ChakraCoreとしてオープンソース化する」
Windowsがオープンソース化される予兆 - 阿久津良和のWindows Weekly Report | マイナビニュース
URLﾘﾝｸ(news.mynavi.jp)
2015/12/21
42:デフォルトの名無しさん
16/01/10 21:23:23.77 TMApyOC8.net
具体的なコードをもとに話を進めてくれないと、
何がやりたいのかさっぱりわからない
文字数は出来るだけ切り詰めて原則箇条書きとかね
一般論をダラダラやられても困る
43:デフォルトの名無しさん
16/01/12 17:09:01.34 O9Go0Lwy.net
適当に例を挙げての具体的な話などしても意味は無い
具体的であればあるほど答えは誰が見ても決まってるのだから
そもそもその手の人達が一般的にどうしてそういう行動するのか共感ができないというから
その原理と一般的な信条、思考パターンを述べる展開になっている
44:デフォルトの名無しさん
16/02/08 22:51:41.45 vWC/lFUG.net
C言語信者な元ゲームプログラマーで今有明海の漁師です。
C言語信者なのは、スピード命！スクリプトとかCPU資源浪費しすぎだろ！
って思ってるから。
そんな私が、手持ちAndroid７インチタブレットで漁業用GPSロガーを使いたくなって
Google Maps API を触ってみた。
凄え。。。
Javascriptでなんでもできるじゃん・・・まじかよ・・・
Androidアプリ書こうかと思ったけどJavascriptでいいわ。
PCからも見れるしね。
まだ航跡記録とかマーカー記録とか作ってない中途半端な状態だけど
休みの日に酒飲みながら機能追加していくの楽しすぎるｗ
URLﾘﾝｸ(www13.plala.or.jp)
有明海を見てね。
長崎県と熊本県の間の内海です。
45:44
16/02/08 23:02:40.71 vWC/lFUG.net
あ、ちなみに、表示してる緯度経度は日本測地系です。
漁業用のGPSが今もみんな日本測地系を使ってるので。
携帯もスマフォもGoogleMapも世界測地系なので変換してます。
46:デフォルトの名無しさん
16/02/09 23:20:54.03 JuURpG1d.net
>>44
見た。
てか、きっちり書いてあるなあ。
Cから見ればJavaScriptなんて超大富豪プログラミングだからね。
ただ、JavaScriptのユルさはなかなか良いとは俺も感じる。
ブラウザでお気軽GUIできるのもいい。
とはいえ、その規模で収まっているうちはいいが、
これからバシバシ機能追加していくのなら、JavaScriptのアレな点が見えて嫌いになるかもw
47:デフォルトの名無しさん
16/02/10 09:11:00.33 FkM1RfeE.net
>>46
JavaScriptは今じゃ、ブラウザの言語でとどまってないからね。
１．Electronでマルチプラットフォームアプリを作成できる
２．CordovaでiOSやAndroidアプリを作成できる
３．Node.jsを使って、Raspberry Piのようなハードウェア制御ができる
４．同じくNode.jsを使って、PHPの代わりにサーバサイドの制御ができる
１粒で５度美味しいプログラミング言語です。緩いが故に大変な部分も
あるけれど、基本的にはライブラリを活用する事でその辺を軽量化でき
るしね。
48:デフォルトの名無しさん
16/02/11 01:04:16.07 3e/IE9s+.net
>>47
嫌いな人も多いが、俺もnodejsの便利さにいまさらびっくりしてる。
eureca.io使って、クライアントとサーバが双方まるで直接呼んでるみたいにfunction呼び出しして、あまつさえコールバックまで出来るとは、とビビるくらい。
49:デフォルトの名無しさん
16/02/11 09:19:41.38 pPotq0xY.net
>>48
言語の弱点をライブラリ群がカバーしてくれてるから、助かるよね。
支持されていなかったら、そのライブラリ達もいないわけで。
50:デフォルトの名無しさん
16/02/11 16:07:05.01 3e/IE9s+.net
>>49
あとは、プロトタイプベースで魔改造する余地があったのも大きいのかも。
普通の言語で、基底クラスを基底クラスのままメソッド追加するとか、上書きする、なんて今までの言語では頭おかしいって言われそうなユルさかつ、
言語仕様としてシングルスレッドじゃん→なんかコールバックさせる仕組みを外に持たないとね→実装
みたいな魔に魔を重ねた改造の結果、使いやすくなってるような気がする。
51:44
16/02/12 01:30:54.19 ZoV9Wx9d.net
>>46
距離を計算するGoogleMapsライブラリに
グローバルで保持してる中心座標を渡したらエラー。。。
new 座標（global中心座標）して渡したら通る。。。どういうこと？
っていうか、渡す時も、受け取る時もnewしないとエラーが出ることがあるんだけどなんだこれ・・・
javascriptの仕組みを理解できてないね・・・orz
newで受け取った値を代わりに使ったら、前の値はメモリに残るだろうし
ガーベージコレクションは自分でしないといけないのかなぁ。
富豪だし無視してもいいかなぁｗ
もうちょっと遊びながら勉強してみます（汗
52:デフォルトの名無しさん
16/02/12 08:43:48.25 eUWMATXs.net
>>51
new Dateと同じだろ。
日付に見えてただのテキスト型になってるとかそういう事。なので、明示的に
型変換して入れてやる事はままある。
ｎ
53:デフォルトの名無しさん
16/02/12 20:46:32.04 jzfCjOnO.net
>>51
物があるんだから具体的に何行目って言ってくれた方が分かりやすいとは思うけど、
見た目多分>>52であってる。
俺もそんなに詳しい訳じゃないし、APIの仕様も知らないけど。
ガーベッジコレクション(GC)をユーザが起動する方法はない。
参照が切れればいつか勝手に回収される。
ただ、見た目バカスカリークする可能性があるタイプのプログラムじゃないから、
多少リークしていたとしても問題ないと思うけどね。
リークが気になるなら、chromeならDeveloperTool、FFならabout:memoryで確認できる。
ちなみにそこにGCするボタンもある。
54:デフォルトの名無しさん
16/02/12 23:30:42.28 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とかあるしもう忘れることにしますｗ
きっとガーベージが増えたらGoogleChromeさんが勝手に掃除してくれますよね！
55:デフォルトの名無しさん
16/02/13 00:01:10.41 lKczJ9J0.net
>>54
currentPos={...}は、そのまんまcurrentPosに{...}を代入するだけで、
それぞれのプロパティに代入してくれるわけじゃないよ。
{...}自体が、new Object()だしね。
ガベコレが回収してくれるには参照を切ってやらなきゃならんのだから、null代入は必須。
意図的にnullを代入するとガベコレが回収する訳じゃないけど。
グローバル変数のcurrentPosはLatLngなんだから、{}でつっこむほうが間違ってる。
56:デフォルトの名無しさん
16/02/13 00:40:54.25 o8xzA50z.net
>>55
レスthxです。
プロパティに代入しちゃえ！って
currentPos.lat = pos.coords.latitude;
currentPos.lng = pos.coords.longitude;
やってみたけどできないのね。
URLﾘﾝｸ(developers.google.com)
LatLngってオブジェクトはコンスタラクタ以外では値の設定ができないのかな？
富豪過ぎるｗｗｗ
>{...}自体が、new Object()だしね。
>グローバル変数のcurrentPosはLatLngなんだから、{}でつっこむほうが間違ってる
うーん、イマイチ理解できてないですけど、
currentPos = new Object({lat: a, lng: b});
というlatとlngを持ったLatLngではない別のObjectが生成された、ってことなのかな？
型が緩いのは便利だけどデバッグ時にはわかりにくすぎるという諸刃の剣ですね。。。
勉強になりました。ありがとうございます！
＃今回javascriptで組んでみて、CSSにも苦戦してるし、CSSとjavascript上のひも付けにも苦労してます（汗
＃あぁあああなんでぇええ って腹たつけど、意図的に動いた時にはやっぱり嬉しいですよね
＃プログラミングって楽しいですよね！
57:デフォルトの名無しさん
16/02/13 01:31:30.78 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とかあるしもう忘れることにしますｗ
GCして欲しいのならnull代入するなりdeleteするなり関数で囲って関数ごと捨てるなりするしかないけど、
正直、今回のような場合の1個や2個はどうでもいいと思う。
> CSSとjavascript上のひも付けにも苦労してます（汗
基本的にclassを使えばいい。
58:デフォルトの名無しさん
16/02/13 01:57:33.47 rQhUa0HJ.net
> ＃プログラミングって楽しいですよね！
正直、ブラウザ上でのプログラミングはかなり楽しいと思う。
GUIで具しか書かなくていいのでチャキチャキ感があっていい。
ただ、他の新しいGUIは知らないから、他にもいいのがあるかもしれないけど。
59:デフォルトの名無しさん
16/02/13 03:17:29.54 o8xzA50z.net
>>58
色々教えてくださってありがとう御座います。
ブラウザ上のプログラミングも楽しいですけど、
PC8801mkII-SRからプログラミングを始めた私としては、
限られたCPU速度、メモリー、直接ハードを叩いてる感、も楽しかったんですよ
V-Sync割り込みで画像移動させるとスムーズに動くとかね。
そういうハードの限界まで頑張る、的な楽しみは今では無いでしょうけど
Google Chromeには便利なデバッガーあるし、
ネット上には情報がいっぱいあるし、
今の若い人たちはjavascriptから遊んでもいいと思いますね。
html5のcanvasでゲームも作れるし。
文法的にはCにもjavaにも似てるからどこにでも進めるでしょう。
職業：プログラマーという選択が良いか悪いかは別としてねｗ
趣味：プログラムなら一生楽しそうだけどなぁ。
60:デフォルトの名無しさん
16/02/13 03:40:04.40 o8xzA50z.net
雑談ついでに。
私はプログラムはXyzzyで書いてます。
Windows用の軽いemacs互換エディタです。
URLﾘﾝｸ(www13.plala.or.jp)
25年くらい前にX68000でTinyEmacsを使い始めてから、
もうemacsキーバインドじゃないと何も書きたくないです。
ゲーマーなんでWindowsを使ってますが、
Xkeymacsという、すべてのキーバインドをemacs風に変換するソフトが常駐してますｗ
今の環境はWindows７ですがWindows10にしたらXkeymacsが使えなさそうで怖いです。
最低Ctrl-H＝Backspaceにできないと死にます。
スレチ、失礼しました。
61:デフォルトの名無しさん
16/02/17 19:47:14.33 aoSk7bCH.net
今更ながらjs2-mode導入して色を付けてみたが、ちょっとイマイチだな。
キルリングの取り扱いが変わっていて慣れないし、
括弧閉じてもインデントが上がってくれない。
括弧の対応がハイライトされないのも謎だ。
まあもう少し使ってみるけど。
ただ、書いている最中に構文チェックするらしくて色が変わる。
これ自体は便利だと思うけど、どこまで使えるものなのかはまだよく分からない。
62:デフォルトの名無しさん
16/02/21 09:27:40.55 lDbEdv1b.net
>>57
>>GCして欲しいのならnull代入するなりdeleteするなり関数で囲って関数ごと捨てるなりするしかないけど
それらでCGされる保証はない
エンジンは一般的な場合に最適化されてる
一般的でないことはしないのが基本
63:デフォルトの名無しさん
16/02/24 01:04:57.69 idPWr2uv.net
すいません、キルリングの仕様変更はemacs23からのものらしく、
js2-modeは関係ありませんでした。
括弧の対応のハイライトはやはりおかしいままですが、
対応が間違っている場合はそもそも色が変わるので、
結果的にはあまり問題はないですね。
64:デフォルトの名無しさん
16/03/28 23:29:32.90 JoYhD075.net
nodeスレより
URLﾘﾝｸ(yosuke-furukawa.hatenablog.com)
65:デフォルトの名無しさん
16/04/13 23:34:15.51 /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:デフォルトの名無しさん
16/04/19 11:57:14.77 /d/wYc3X.net
速度も見た目も十分だよ
それを何度も実行する気なら状況によって要素や文字列をキャッシュすればいいし、
もっともっと短くしたいのならES2015を使えばいい
67:デフォルトの名無しさん
16/04/19 21:54:42.16 18lMfaYE.net
テーブルに大量の行を挿入したい時とかって普通にやると応答止まるけどプロはどうやってんの？
68:デフォルトの名無しさん
16/04/20 01:37:27.97 wi2IeNzq.net
>>66
本当は、
querySelector('a[textContent="XXX"]')
と書きたいところだ。
ただこれは出来ないので、これまでは致し方なく別関数なりベタで書いていた。
しかし call に慣れてくると実は意外と使えることに気づく。
使い道の無かった filter も便利に使えるかと思ったのだが、
配列メソッドなのでショートカットが無いのが唯一残念なところだ。
（個人的には記述量は気にならない。）
69:デフォルトの名無しさん
16/04/20 01:44:58.86 wi2IeNzq.net
>>67
大量の行の挿入くらいじゃ止まらないし、
そもそも一画面分以上挿入する必要もないだろ。
具体的に何行挿入して、どれくらいカクついたらアウトなのよ？
70:デフォルトの名無しさん
16/04/20 08:04:48.78 M3votfED.net
requestIdleCallbackで分割しながら挿入すれば良し
71:デフォルトの名無しさん
16/04/20 09:52:44.31 98a+yUuB.net
vol.119で質問すれば良いのになぜこんな場所で質問してるのか
ここで詳しく回答する気は起きないので簡単にしかいわんけど
ｽﾚﾘﾝｸ(tech板)
>>65
XPathを使えば良いと何度もいわれてる
>>67
1行ずつ何度も挿入してるんだろ
DFを使え
72:デフォルトの名無しさん
16/04/25 00:30:16.00 th/2rgKP.net
ふと思ったんだが、forEach って何で currentValue が this になるのがデフォじゃないんだ？
グローバルじゃ意味無いよな？
引数で与えられるから動作としては問題なく、見た目だけの話だけど。
> forEach に thisObject パラメータが与えられると、callback の呼び出しのたびにそのオブジェクトが this として使用されます。thisObject が与えられないか null だと、callback に結び付けられたグローバルオブジェクトが代わりに使用されます。
> URLﾘﾝｸ(developer.mozilla.org)
73:デフォルトの名無しさん
16/04/25 04:01:16.41 LMKLsb3i.net
thisに色んな意味を付けて何でもかんでも与えるなんてセンス無いから
現にアロー関数だったとき機能しないでしょ
74:デフォルトの名無しさん
16/04/25 04:10:55.58 wavxOtJH.net
>>732
currentValue が thisになるのなんて、
DOMのイベントハンドラの中でthisが要素になるぐらいのもんだろ。
そもそもDOMはJavaScriptではない。
そもそもDOMがおかしいんだよ。
75:デフォルトの名無しさん
16/04/25 08:11:57.07 th/2rgKP.net
>>73
> 現にアロー関数だったとき機能しないでしょ
あれはどっちかというと無駄な仕様変更だと思うが。
正確に言うと無駄な仕様を削除して新しく自動 .bind(this) に変更したわけだが、
その必要も無かった（と思う）
>>74
> そもそもDOMがおかしいんだよ
これはそう思う。というか、あれは this になることで無駄な手間が増えてる。
イベントハンドラを継承で与えるとき、(クラスでイベントハンドラを共有するとき）
いちいちインスタンスに bind しなくてはならないので面倒だ。
必要なら e.currentTarget でよかったのに自動 this だからこうなる。
ただここら辺も統一感がなくてイマイチではあるが、
現実的には何とかなる範囲ではあるので、（我慢できる範囲）
AltJSもイマイチ本家を殺しきれないといったところか。
76:デフォルトの名無しさん
16/04/25 17:28:53.92 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:デフォルトの名無しさん
16/04/25 17:47:23.15 6VBDo1JK.net
>>75
仕様「変更」ではない
アロー関数はより「ピュア」な新たな関数
newも出来ないし、thisやsuperも変数と同じように参照する
bindとは違う
統一感はある
DOMは関係ない、altJSでも同じこと
というかデファクトであってそれに依存するのは非推奨
78:デフォルトの名無しさん
16/04/25 19:33:42.57 th/2rgKP.net
>>76
指摘の通りDOMをイメージしていて、
これまた指摘の通り全部thisでやろうとすること自体が糞だと理解した。
> (arrayに束縛するならわからんでもないが)
確かにこちらの方が自然だね。(とはいえthisにこだわるのが間違いだったが）
> event.currentTarget === this は相互運用性の為に仕様に取り込まれたに過ぎない
見た目相互運用できるようには見えないが、
(thisに揃えても同じコードを再利用できるとは思えない。もちろん揃えないよりはマシだが）
後付けでいろいろ奇妙になっているのは理解した。
> URLﾘﾝｸ(7cc.hatenadiary.jp)
> this値に変更されて困る重要なデータを格納する
jQueryは知らないが、これはconstの代りに使うということか？
アクロバティック過ぎる。
>>77
> アロー関数はより「ピュア」な新たな関数
つまり機能限定版か。
そういう理解は出来なくもないが、導入するメリットは文字数以外に何もないだろ。
そりゃ意味無いって普通は言われるよ。
どうせ新規にするのなら、クロージャ無しとかまで踏み込んでもよかった。
(新規なら使い分けが必要/有効なところまで機能分離するべき）
79:デフォルトの名無しさん
16/04/25 22:39:46.80 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:デフォルトの名無しさん
16/04/25 22:47:27.73 wavxOtJH.net
>>76
> jQueryはthisをローカル変数でも引数でもない第三の格納倉庫として利用し、コード上でthis値が変更されることを許さない
> this値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない
そんなことしません。
そう言う用途として使うのは、DOM要素のdatasetだよ。
このdatasetっていうのは比較的最近できたもので昔はなかった。
だけどjQueryは要素ごとの情報の格納場所の必要性を昔から認識していたため
datasetが作られるよりも前からdata()メソッドと言うのを持っていた。
そしてdata()メソッドがある理由の一つとして、
thisに直接値を格納するとブラウザのバグでメモリリークになる可能性があるから
「this（DOM要素）にデータを格納してはいけない。」と言っていたぐらいだ。
事実はあんたが思っているのと正反対だよ。
81:デフォルトの名無しさん
16/04/25 22:49:10.70 wavxOtJH.net
これね。
URLﾘﾝｸ(api.jquery.com)
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:デフォルトの名無しさん
16/04/25 23:32:07.55 olQI0pZ8.net
>>76でhandleEventの話が出ているが、使った人ならわかると思うが、
handleEventはswitchでイベントを振り分ける必要があって使いづらい。
なぜこんな仕様があるかというと、そもそもDOMはJavaScript以外の言語も
考慮されて作られているという事実で説明できる。
つまり関数の引数、つまりaddEventListenerの引数に関数を渡せない言語が存在する。
具体的に言うとJava。Javaでは引数に関数を指定することができず、
オブジェクトは指定できる。
handleEventインターフェースを実装したオブジェクトを引数に取る関数と
考えるとhandleEventという仕様がなぜ存在するかがわかる。
これは便利だから追加された機能じゃない。Java等で必要だったっから
追加された仕様であって、JavaScriptでは関数をそのまま指定した方がいい。
83:76
16/04/26 00:48:49.99 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:デフォルトの名無しさん
16/04/26 00:50:01.95 6NLvX0gR.net
>>80
> jQueryは要素ごとの情報の格納場所の必要性を昔から認識していた
これは俺もすごく思うが、
実際のところはリークと速度低下が怖くてJavaScript側で持っている。
さすが実用ライブラリだけあって痒い所には手が届いているというところか。
>>82
> handleEventはswitchでイベントを振り分ける必要があって使いづらい。
これは何故？俺は使ったことは無いが、見る限りそういう感じではない。
イベントハンドラは基本的に直リンクというか、振り分け済みの関数を与えるのが基本で、
thisが効くオブジェクトを与えられるのなら、子クラスを与えればいいだけ。
当たり前だがオブジェクト指向の基本どおりだ。
また、最初からイベントハンドラ内で振り分けする気であれば、
ルートNodeにイベントつけてe.targetのclassで判定するのが自然だ。
何か別の条件ではまっただけの気がするが。
とはいえ、DOMの仕様がJavaScriptから見て中途半端なのはJavaとの相乗りが原因だとは理解した。
85:76
16/04/26 00:51:40.14 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
16/04/26 01:08:23.70 74Un+zc0.net
>>80
jQuery でも event.currentTarget で書くことは出来るが、ドキュメントのサンプルコードを読む限りでは作者が this を推奨しているように読める
「許さない」は言いすぎだったかもしれないが、this を推奨するという事は this 値が変更される事を考慮していないのではないか
this 値は実行コンテキストに入る時点で決まる不定値であり、this === event.currentTarget になる保証はない
URLﾘﾝｸ(api.jquery.com)
余談だが、jQuery#each と Array#forEach でコールバック関数の引数順序が違うのは this 束縛がある影響だと考えている
jQuery では this で各要素ノードを参照できるので第1引数に element を持っていくと index を参照する為には第2引数まで書かなくてはならない
forEach の設計としては直感的ではないが、ショートコーディングの為に index を第1引数に持ってくる歪な修正を加えたようにしか見えない
URLﾘﾝｸ(api.jquery.com)
jQuery('.hoge').each(function (i, element) { console.log(this, i, element); });
87:76
16/04/26 01:50:16.54 74Un+zc0.net
>>80
> 事実はあんたが思っているのと正反対だよ。
jQuery#data は優れた機能(ただし、data独自属性の拡張はいただけない)だし、jQuery() のセレクタエンジンは素晴らしいものだった
JSON, querySelector 等、優れたライブラリ/先行実装が標準仕様に取り込まれるのはよくある事だ
jQuery の全てを否定したいわけではなく、「jQuery の this の使い方が好ましくない」と主張している
> そう言う用途として使うのは、DOM要素のdatasetだよ。
dataset は String 型しか格納できない為、jQuery#data の代替にはならない
jQuery#data の代替として期待されたのは DOMUserData だが、この API は残念ながら廃止された
URLﾘﾝｸ(www.w3.org)
今では機能的に逆だが、WeakMap が代替となりうるだろう
URLﾘﾝｸ(www.ecma-international.org)
88:デフォルトの名無しさん
16/04/26 11:16:02.05 x636ghAj.net
つうか結局何が言いたいの？
thisはpythonのselfみたいに一定の規則はあるが
あくまで０番目の引数みたいなもんで何に使おうが勝手だし
そういうのを利用するならきちんと把握しないといけない
その程度のことに良いとか悪いとかはない
使いたいならただ受け入れればいいだけ
なんかよく分からんけど気持ち悪いみたいな
結局愚痴をダラダラと言いたいだけならもうここら辺でやめとけ
89:デフォルトの名無しさん
16/04/26 17:56:08.45 LGdk9fYg.net
C#みたいにobj.Methodでバインドしてくれれば楽で綺麗に書けるのにね
いちいちbindって書くの面倒
90:デフォルトの名無しさん
16/04/26 19:15:29.79 v8OmTco7.net
>>88
ここまで説明されて愚痴にしか読めないのなら口を出さなければ良いと思うけど
91:デフォルトの名無しさん
16/04/26 19:52:24.85 PAn5oHiy.net
>>89
引数としてメソッドを渡す際は今だと
obj.method.bind(obj)
よりもアロー関数を使って
()=>obj.method()
の方が良いかもしれない
あとバインド基本にするのは結構簡単
クラスのプロトタイプにそういうプロキシを挟めばいい
アノテーションとか使えるようになればなお綺麗に書けるね
まあバインドシンタックスobj::methodとかもあるんだけどね
そういうのを使えるトランスパイラ使うってのも悪くないと思う
92:デフォルトの名無しさん
16/04/26 23:52:32.19 6NLvX0gR.net
>>83
前半、言っていることは分かるんだが、現実的には、
this がDOMであるコードと自前のオブジェクトを this 参照するコードを
同一のコードで処理（相互運用）するためには、
自前のオブジェクトをDOMモドキにする必要があって、
（DOMと同じプロパティ等でアクセスできるように形を揃える）
これだと余計に苦労する。
だから結局、既に書かれたコードを流用することは難しく、
書き直すかラップしてしまうほうが簡単だ。
多分現実的には相互運用をしている奴は少ないのではないかと思う。
もちろんthisで共通アクセスできないとその可能性すらないからそれよりはマシだが、
現実的にはこの仕様はあっても使えない。
93:デフォルトの名無しさん
16/04/26 23:53:03.95 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:デフォルトの名無しさん
16/04/26 23:54:04.46 6NLvX0gR.net
だから「相互運用」を考えるのなら、
e.currentTargetとthisの両方を異なる意味で用いている上記のようなケースをどうするかであって、
多分これはどうにもならんだろ。
手っ取り早いのはラップ関数内でthis値をMapなりから引っ張ってきてしまうことだが、
要するに書き換えが必要なので仕様をわざわざ合わせた意味がない。
何らかのために仕様をあわせたというのなら、
そのおかげで書き換えなくても済みました！がないと意味が無い。
DOM側からすると妥協だということだが、放置でもよかった気はする。（仕様として追認の必要なし）
なお、thisかe.currentTargetの片方しか使ってないコードは自動でも書き換えできる範囲だと思う。
しかしそうなると問題の出所はブラウザの実装で、
何故e.currentTargetに統一せずにthisを渡すことにしたかだな。
正直、あれ、thisで渡されても全くメリットないよな？
> DOM4で標準化された事で既存のコードが確実に動作する事が保証された
これは多分、気にする人にとっては重要なのだろうけど、
Webサイトなんて10年後の動作を保証されたところで意味が無いし、
「当面(数年）確実に動く」であれば大半の人にとって問題ない。
それが実装主体で推移している原因にもなっていると思う。
95:デフォルトの名無しさん
16/04/26 23:55:02.00 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:デフォルトの名無しさん
16/04/26 23:55:42.51 6NLvX0gR.net
>>86
いやそのjQuery.eachのthisは意味があるぞ。
それならthisで書かれたイベントハンドラをeachで回せる。（DOMのイベント寄り）
ただe.currentTargetで書くべきだというのと、
そもそも他に代替手段がありまくるので、割とどうでもいいが。
thisを固定したことによるデメリットの方が上回るかもしれない。
ただまあ、そちらの主張どおり、
thisに対しては緩く考える（○○が来ると仮定しない）方が何かと便利なのは事実だろう。
97:デフォルトの名無しさん
16/04/27 00:28:53.55 mjPz9hpH.net
「thisは基本レシーバ」
それ以上でも以下でもない
98:デフォルトの名無しさん
16/05/01 14:45:40.12 tKi6j9CT.net
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
URLﾘﾝｸ(twitter.com)
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
「
99:デフォルトの名無しさん
16/05/03 12:04:12.37 YtCRz7OH.net
もうWebRTC利用したJS製のそういうフレームワーク何個も作られてるよ
100:デフォルトの名無しさん
16/05/03 18:27:13.57 Hru3QNWj.net
WebRTCって要するにP2Pチャットサーバ用だよな。
元々それ用だけどそれ以外に用途が無い。
もちろん発展させればWinnyやskypeみたいな事は出来るけど、それなら最初からそっちでいいし。
俺も最初知ったときは「ウッヒョー」だったけど、冷静に考えたら落ち着いた。
現実的には大半の事案は鯖立すればいいだけだからね。
技術的には面白いとは思うけど。
101:デフォルトの名無しさん
16/05/04 19:58:18.58 znxAfP3/.net
ちいと勘違いしてるが、WebRTCに鯖とのやり取りもといマッチングの仕組みは含まれていない。
WebRTCでそれをするのはちょっとハックっぽくなるが、
特にORTCなら鯖レスの固定相手P2Pも素直にできる。
現在は
・ビデオ/ボイスチャット
・MMOゲーム
・一方向型のファイル共有
によく使われてる
102:デフォルトの名無しさん
16/05/04 23:45:02.80 umoiWZhY.net
> MMOゲーム
これにはいいかもな。
それ以外は正直、「ブラウザでできる」以上の意味は無いよね。
最初からP2Pする気ならP2Pアプリを使った方がいろいろいいし。
一方向型のファイル共有ってそれただの鯖じゃん。
103:デフォルトの名無しさん
16/05/05 04:30:39.98 2KiZjc5Z.net
ブラウザでできるからこそ特大の意味があるんだよ
今著名なWebサービスはアプリも出してることが多いけど、
じゃあ皆がそっちの方を使ってWeb版はいっさい要らなくなるかというとそうではない
一時期そういう流れも起きたがやはり無理だったということで、今は流れが戻っている（Flipkartが良い例）
わざわざアプリをインストールして管理しないといけない手間が要らないのはとてつもない利点だよ
そして、ファイル共有に関しては鯖レスで実現できるところがメリット
鯖を挟むと帯域を本来の２倍取り、さらに負荷が鯖に集中してしまう
宛先の絞られているファイル等はP2Pで送る形のほうが良い
104:デフォルトの名無しさん
16/05/05 09:25:46.88 fknk/t2B.net
ブラウザのBBOM化はもう勘弁して
105:デフォルトの名無しさん
16/05/09 15:41:03.36 iKr5Nm9H.net
なんで？
106:デフォルトの名無しさん
16/05/09 22:54:55.21 Ji3tRhpw.net
BOMのことだよな？
個人的にはDOMやBOMでAPIアクセスできるのはお手軽でいいと思うぞ。
107:デフォルトの名無しさん
16/05/09 23:34:30.27 fQwtjbTF.net
もはや種類多すぎる上に増加スピードが速すぎて把握するのがしんどいわ
でも無ければ無いで何も作れないしな
108:デフォルトの名無しさん
16/05/10 10:34:10.82 AYSgFkex.net
スピードが早いというが、一年くらい前から高レベル系のAPIが熟成期に入って停滞してると思う
また来年くらいから今度は低レベル系のAPIが動き始めるんじゃないかな
109:デフォルトの名無しさん
16/05/10 23:06:42.46 vhPcYSkB.net
> 低レベル系のAPI
上の話ともリンクするが、ブラウザはお手軽さが最も重要なのであって、
ゴリゴリ書いて性能を出すのには不向きだし、流行らないと思うぞ。
結局のところ、専用ネイティブアプリには実行効率では勝てないのだから、必要なら開発される。
そこまでの必要/需要が無ければブラウザアプリのままでいけることになる。
ただ一つ思うのは、CPUとI/Oを分離し、非同期で書くことを強制するのは、実はかなり効いている。
体感、思っているよりだいぶ速いんだよね。
他言語だと普通に同期で書くし、描画でもそのまま記述する。（分離して書く習慣が無い）
これら遅い部分を明示的に分離し記述することが半強制されている結果、
結果的にCPU稼働率の高い「割と速い」コードが出来上がることとなっている。
だからちゃんと書いたJavaScriptは十分速いし、
それ以上の速度を要求するのならC/C++で書き直すしかない。(V8がC比5倍程度と十分速い為）
どんなJavaScriptでも最後にトランスパイルすれば速くなるというのなら、それはJIT側に含まれるべきだし、
何らかの記述制限をつけて「ちょっと速いJavaScript」を目指すものは、多分需要が無い。
（本来そこにはC比3倍程度というJavaアプレットがいたはずだが、完全に死んでるし）
110:デフォルトの名無しさん
16/05/11 07:45:48.20 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:デフォルトの名無しさん
16/05/11 22:18:37.29 ye4EAN+q.net
APIはポリフィルできても、言語はポリフィルできないからな。
だからBabelなどのトランスパイラが必要になる。
112:デフォルトの名無しさん
16/05/12 00:54:26.89 TctSTaTq.net
>>110
> Extensible Web Manifesto
以下を読んだ。
URLﾘﾝｸ(jxck.hatenablog.com)
言っていることは分かるが多分無理だな。
低レベルAPIのすり合わせは高レベルAPIよりも難しい。
だから高レベルAPIのすりあわせすらマトモにできなかった連中には無理だ。
> そもそも、デバッギングはコーディングよりも2倍難しい。
> 従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない。
> ブライアン・カーニハン [Brian Wilson Kernighan]
高レベルAPIの仕様策定が失敗しているケースが多々ある点についてはよくは知らないが、
JavaScript言語自体の仕様を見る限り、いろいろ迷走している点は多い。
仕様策定が失敗するのは、単純に使用策定している奴らに先見の明が無いからだ。
だから逆に言えば、先見の明が無いような奴らが仕様策定に関わってはいけない。
JavaScriptの連中はそこらへんを勘違いしている。だからゴミ仕様が山積みになる。
AppCacheがゴミであろうと、仕様として策定された以上、実装しないわけには行かない。
だから結局、ブラウザに対してゴミコードを含まなければならないという足かせが出来ただけになる。
結果的にJavaScriptの世界はゴミが増えていき、ゴミに振り回されることになる。
これを理解できていない。
とはいえ、それでも進化の速度を取っているといえばその通りだ。
C#が伽藍型仕様開発なら、JavaScriptはバザール型という訳だが、目に付く失敗も多い。
もちろん、XHR等は大成功の一例なのだろう。どちらが多いのかは、俺にはわからない。
SeviceWorkerがどうなるのかは見ものだな。
113:デフォルトの名無しさん
16/05/12 00:54:55.63 TctSTaTq.net
> ちゃんと書く
速度を問題にしているのだろう？だったらきちんと速度が出る書き方をするということだよ。
5倍というのはググれば出てくるはずだがN-body、つまり演算部分だ。
同様のベンチは他の人もやっていて、大体同じような値になっている。
ただ指摘の通り、その部分は他のもっと遅い部分に隠蔽され、結果的に見えないことが多い。
(ただしだからといって遅い部分も含めて速度比較して大差ないとか言う屁理屈はうざいだけだから止めろ。
それは速度比較とは言わない）
だからJavaScriptが通常用いられる用途に関しては、JavaScriptは十分速いし、
それ以上を望むのなら、ゴリゴリ書くしかない。
> ゲーム思考エンジン
これは環境はなんだ？
個人的には主力テキスト操作スクリプトをAWK/Perl->JavaScriptに乗り換えようかと思っているんだが、
DOS窓から操作できる使いやすい環境ってないか？
AWKやPerl同様、一行ずつ標準入力からReadline出来ればそれでいい。
nodeが一番マシか？
114:デフォルトの名無しさん
16/05/12 05:43:37.43 s4pSKHj7.net
WSHが一番マシ
115:デフォルトの名無しさん
16/05/12 08:43:22.73 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:デフォルトの名無しさん
16/05/12 08:44:46.17 pPHDojvh.net
記事リンクを貼ってなかった
URLﾘﾝｸ(blog.mozilla.org)
117:デフォルトの名無しさん
16/05/12 23:52:09.31 TctSTaTq.net
>>114
WSHか。あれ食わず嫌いだったけど、やっぱお手軽でよさそうだよな。
まあやってみることにするよ。
118:デフォルトの名無しさん
16/05/12 23:59:02.52 TctSTaTq.net
>>115
違う。
> 策定に時間がかかったり、実装者や開発者とのやり取りが十分ではなかったから。
仕様策定とは「常に」こういうものなんだよ。言語のみならず他でも全て。
有名なイラスト、見たことがあるだろ。
> ニコニコ大百科/a/顧客が本当に必要だったもの (リンクはRock54で貼れない）
だから、これを分かった上で、そうならないようにする「実力」が必要なんだよ。
具体的に言えば、どんなに時間がかかろうが、いい仕様（必要な物）ならみんな使う。
だから、時間をかけてでもいい仕様にするというのが「先見の明」作戦。
これが無理なら、古典的だが報告連絡相談（ホウレンソウ)をきっちりやるしかない。
出来なかったのなら、どちらの作戦もやりきる実力が無かっただけ。
試行錯誤で進めていくのもありだと思うけど、
それなら結果的に無意味になってしまった仕様等をばっさり捨てていく覚悟も必要。
(詳しくは知らないがRailsはこれに近いのかもしれないし、それも妥当な戦術）
後方互換も必要です、新しい仕様も必要です、
でも十分な仕様策定能力はありません、というのが今のJavaScriptの状態だね。
進化速度を捨てるわけには行かないのだから、後方互換を捨てるしかないと思うのだけどね。
この点で言えば、ポリフィルでお茶を濁しまくっているのはいい作戦ではある。
とはいえ、出来る/出来ないをここで議論する意味は無い。
結果を見ればいいだけだから。
119:デフォルトの名無しさん
16/05/13 00:04:56.39 PxVJ9U+u.net
>>115
> 自分が言った「ちゃんと書く」とは、asm.jsを（部分的に）手書きするということだ。
だからそれは屁理屈なんだよ。
言語の速度比較なら、普通に書いた、つまりそこらへんに転がっている記述同士でやらないと意味無いだろ。
Cでインラインアセンブラを使うのは無し、
JavaScriptなら普通に [], {}を使って書いたものだよ。全面 TypedArray とかは無しだよ。
というか、それならそもそもそういう言語で書けって言われるようじゃ駄目だろ。
言語の比較なら、それぞれの言語の良さを生かした状態で記述してあるものでないと。
君が言っているのは、「チューニングしたときに伸びしろがあるか」ということであって、
言語の速度比較ではないんだよ。
CならSSEやCUDAまで導入できるのだから、それも入れていいかというと違うだろ。
普通に書いて普通にコンパイルできる状態での比較じゃないと意味無いだろ。
そして、そこでいちいちムキになることも無いんだよ。
不満があれば他言語で書けばいいだけ、
その言語を使っているのなら、エコシステム含めてその言語が一番マシだから使っているだけ。
それ以上でもそれ以下でもないだろ。
120:デフォルトの名無しさん
16/05/13 09:43:39.39 1hqv3t07.net
>>118
JavaScriptと言うより、Webの宿命。ES仕様自体は元々が小さかったのも有り、
妥当で慎重な機能追加で順調に進化してきている。
そして今まで悪かったからこそそれを改善しようと言うのがEWMなのに、
なにを否定したいのかがわからん。
EWMならダメな仕様等をばっさり捨てていくことも可能。
というか結果的に皆が使い良いと認められる仕様だけが標準になるのだから。
更には公開と発展の速度まで引き上げられる。
そしてasm.jsを手書きすることが屁理屈だなんてとんでもない。
勿論emscriptenが書き出すようなのを手書きするのは変態だが、
どうせちょっと高速化を意識するとTypedArrayをメモリに見立ててあれこれするようになる。
それはasm.jsがやってることと同じなので、asm.jsパターンにちょっと直せばいいだけ。
ただのお作法みたいなものでしかなく、そっちこそ何をムキになってるんだか分からん。
別に素のJSがC++と比べてどれだけ早いなんて自慢話をしたいわけじゃないし興味はない。
JSで事実速いコードもそこそこ書くことが出来、その結果現実的に実現できることがあるということが自分にとって重要
もちろんこういうことをするのはレアケース。
だって先にも言ったようにそこら辺に転がっている実用コードの殆どのボトルネックが外部APIだし、
よくあるマイクロベンチみたいなのを意識しても仕方ないから。
一方それ以外の素の速度が重要なケースでは、どんな言語で書いてもそれなりにアルゴリズムやチューンを気にするだろうし、
asm.jsに沿って書く程度十分あり得る範囲だよ。
121:デフォルトの名無しさん
16/05/13 17:53:59.39 1hqv3t07.net
Railsとかサーバサイド言語/環境と違って
WEBは１つの実装で色んな時代に作られたデータを読まないといけないのだし
仕様の量も段違いで数十か数百かのモジュールが組み合わさって成り立っているのだから
その１つ１つのバージョンを意識したり指定したりということはできないし
原則後方互換性を守りながら拡張していくしか無い
WEBがもっとシンプルで昔のようにほぼW3Cが牛耳っていれば問題はなかったのだが
世間や環境がそうさせてくれなかった
WEBはマグロのように泳ぎ続けるしかない定め
122:デフォルトの名無しさん
16/05/13 20:51:55.08 PxVJ9U+u.net
>>114
> Microsoft Windows 98、Windows 2000、および Windows Me には、
> Microsoft JScript および VBScript の 2 つのスクリプト エンジンが用意されており、
> 通常はこのいずれかを使用してスクリプトを記述します。
> Windows Script Host では、このほか、Perl、REXX、Python などのスクリプト エンジンも使用できます。
> URLﾘﾝｸ(msdn.microsoft.com)
やべーわ完全に食わず嫌いだったわ。
見た目、.NETと同じく言語非依存のフレームワークを提供しているんだな。
標準入出力＋αで満足するから完全に十分だわ。
というか結果的にMSには先見の明があったな。
以下によると//xでデバッガが起動出来るらしいが接続してくれない。
そっちでは動いている？
> WSHはVisual Studioでデバッグを行うことが可能です。
> Visual StudioはExpressの場合にデバッグが行えないかもしれません。Professional以降が必要かもしれません。
> URLﾘﾝｸ(qiita.com)
Vista+VSExpressなんだけどね。
123:デフォルトの名無しさん
16/05/13 20:58:41.47 JdHqQx2Q.net
外部と隔離された無人島で20年過ごしてきた人なのかな？
124:デフォルトの名無しさん
16/05/13 22:06:05.08 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:デフォルトの名無しさん
16/05/13 22:06:20.89 PxVJ9U+u.net
まあいずれにしても、上手く行くかどうかは結果を見ればいい。
俺は上手く行かないと予想している。
ブラウザ側も馬鹿ではないから、俺が言っていることぐらい分かっている。
だからgoogleの「最適化としては行うが、asm.jsにべったりでは無い」というのがかなり妥当。
旗振り側のFireFoxは実装するしかないから、両方の言い分は分かる。
君の見方だけではgoogleが及び腰な理由を説明できないだろ。
126:デフォルトの名無しさん
16/05/13 22:12:02.90 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:デフォルトの名無しさん
16/05/13 22:12:42.95 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:デフォルトの名無しさん
16/05/13 22:40:16.76 PxVJ9U+u.net
>>121
> 仕様の量も段違い
とにかくこういうことにしたい奴が多いようだが、これは明らかに違う。
.NETにしてもJavaにしてもクラスライブラリの量は桁違いに多い。
文法的にも覚えることは多いし、記述的にもより細かく指定できる。
JavaScriptは軽くて簡単な言語だよ。元々そう作られたものだし。
（これは悪いことではない）
> その１つ１つのバージョンを意識したり指定したりということはできないし
> 原則後方互換性を守りながら拡張していくしか無い
Javaは知らんが.NETはバージョン管理されていて、
廃止されたメソッド等もある。（完全上位互換ではない）
ちゃんとやれば出来ることなんだよ。もちろんその実力が必要だけど。
詳しくは知らないが、DirectXはバージョンが一つ違ったら別物だったらしい。
低レベルAPIだから必然的に実装とリンクしてしまうのでこうなる。
結果的にMSはDirectXを使い捨てし続けることで乗り切っている。
Webもやれば出来るだけだよ。やってないだけ、やる実力も無いだけで。
とはいえ、試行錯誤でいくというのも一つのいい作戦だ。
その場合は、どうしてもゴミが紛れ込んでしまうので、定期的にGCしないといけない。
それが全く出来てないからおかしなことになっている。
129:デフォルトの名無しさん
16/05/14 00:17:31.72 8701OXOx.net
> 詳しくは知らないが、DirectXはバージョンが一つ違ったら別物だったらしい。
DirectXだけじゃなくて「昔は」って言ったほうがいいよ。
MSにかぎらず開発初期は変化が激しいのが普通だから
バージョンが一つ違っただけでも大幅に違いがある。
だけど、MSもそうだけど、成熟してくるとそう変わらない。
DirectXも同じ。
130:デフォルトの名無しさん
16/05/14 05:05:12.84 lm5IbmMb.net
>>124
だからその将来的にも不要にならないってのが低レベルなAPIであることは間違いないのだが。
例えばNodeはSocket APIがあったのでネイティブで対応する前からWebSocketやHTTP2にもすぐ対応できた。
低レベルってのは語弊があったかもしれないがこのSocket API程度のことをイメージして話してる。
CSSで言うと変数とかフローレベルの定義とか、その程度。
>>125
それは最初だけ。V8も去年から専用の最適化機構を入れている。
>>126
「Cの考え」とかはない。メモリに見立ててと言ったのが語弊が合ったかもしれないが、
盤面情報などを多重配列で構築する代わりに１つの型付配列に収める程度のアルゴリズムの問題。
データ配置を意識しないといけないが、実際幾つも変数やら配列データやらを用意するよりもシンプルになり、
パターンとしては別に他の選択肢と比べても奇抜ではなく、JSらしくないこともない。
>>127
実際asm.jsを使う場面が殆ど無いのは先も言ったとおり。
ただDOMがボトルネックの場面について（削減などに関する別の毛色の話は出来るだろうが）あれこれ言っても仕方がないし、
一方もちろんマイクロベンチ的なのを考えても仕方がない（本当はそうでもないこともあるが）と思っているので、
残った殆どないケースだがJSで書く必要があり、速度も必要な場面を基準に、「「ちゃんと」」書いた時の話をしたまで。
普通の場面で「「普通に」」書いた時の話はしてない。あくまでかなりニッチな話としてした。
>>128
Webは中央政権的でない（なくなった）から全てをひとまとめにしてバージョン付けはできない。
これは前提条件として話している。この前提がそもそも間違っているからと言う話題は
他のこれを前提の上どう良くしていくかの話題と分けてくれないとただの愚痴的批判でしかなくまともな話ができない。
131:デフォルトの名無しさん
16/05/14 05:07:22.52 lm5IbmMb.net
Webはそもそも誰のものでもなくオープンなものだ。これは前提以上のWebがWebであるための性質。
昔はいろいろなところがデファクトに沿いながらも自分達に都合のいい仕様を作った。
それじゃ困るからと言って標準化の動きがあって、ベンダーも自然淘汰され整理されてきたこともあり、ちょっとはまとまりがでてきた。
そこら辺で起こる、JSの高速化、スマホ等による環境の変化、中央政権的なFlash等プラグインの死。
よって今まで文章を表示するためでしか無かったWebを、アプリケーションの基盤となれるようにしようという需要・必要性が生まれた。
でもCSSの向上からBluetooth機能までありとあらゆることを一箇所で１つの仕様として定義するのは何十年かかるか分からない。
Flashのような中央政権的やり方はマズイという意識も合り、バージョニングの弊害の反省もあったので、
バージョンはむしろ廃止し、よりオープンなそれこそ誰でもGithubに書いて主張できるような仕様形態に「自然となっていった」。
さて、仕様策定のプロセスが大きく変わってきたが、（昔的な）標準機構（形・影は薄れてきてる）はこれから何をするのがよいのか。
じゃあもう低レベルなAPI群を定義して、もっとオープンに仕様を発展できるようにしよう。
というのがこれまでの歴史。
それを踏まえた上で分けて話して欲しい。
132:デフォルトの名無しさん
16/05/14 08:40:44.17 /oE1tyua.net
横から見てる者だけと、今のところはID:PxVJ9U+uの説明がしっくりくる感じ
ID:lm5IbmMb は表現が抽象的すぎてわかりづらい
「「ちゃんと」」(何をどうちゃんと？)
「「普通に」」(普通って何？)
「自然となっていった」(どの辺りが自然？)
何となくわかる気はするけど、具体的でない部分が誤解を生みやすいと思う
「ちゃんと === 速度を最上位に最適化した普通はやらないようなニッチな最適化」
こんな感じだと勝手に認識してるけど、一般的な感覚で考えても「ちゃんと」とは言い難いような
133:デフォルトの名無しさん
16/05/14 13:45:41.17 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:デフォルトの名無しさん
16/05/14 13:46:10.60 Jg6FEyPA.net
> JSらしくないこともない
要するに自分の手持ちの選択肢の中で「JSでやるのが一番マシ」と思えるのならそれでよし、
そうでないのなら、それはJSを無理に使っているだけだよ。
> 実際asm.jsを使う場面が殆ど無いのは先も言ったとおり。
ブラウザを作っている奴らも暇じゃない。無限のリソースがあるわけでもない。
奴らにとって「重要」だと認識されない限りは歯車は回らない。
そして今のところ、あるいは近未来的にもそうはならないというのが俺の見方だ。
135:デフォルトの名無しさん
16/05/14 13:46:57.24 Jg6FEyPA.net
> Webは中央政権的でない（なくなった）から全てをひとまとめにしてバージョン付けはできない。
これはそちらの認識が間違っている。
そもそも、仕様を策定するのは「困るから」であって、「支配する」為ではない。
元々W3Cがその位置にいたのだが、官僚的だったのか、とにかく仕様の決定が遅すぎた。
だから無視するのが通例になってしまっているが、本来はW3Cが機能していればよかっただけの話だ。
ただ結果を見ている限り、clientHeight/innerHeight等、
名前を決めればいいだけの部分でさえすり合わせ出来ていない点、
あるいはJavaScriptと名乗れずJScriptとなっている点等からしても、
（どちらが仕掛けたかはよく分からないが）何らかの政治的思惑が絡まっており、
W3Cは「使えない」として見切りをつけられているように見える。
（見切りをつけたこと自体は正しいが、それによって我々が不便をこうむっているのはご承知の通り）