JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2015/12/07(月) 07:26:33.87

実際にJavaScriptを書いている人の情報交換所です。
プログラミング既習者専用です。初心者の方はご遠慮下さい。
玄人の方、歓迎致します。

**デフォルトの名無しさん** · 2015/12/20(日) 04:56:15.02

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

**デフォルトの名無しさん** · 2015/12/21(月) 01:11:35.42

>>33
ふむ。もう一度確認してみたがエラーにはなるようだ。
確認してから書いたのだが、どうやら間違っていたらしい。すまん。

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

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

**デフォルトの名無しさん** · 2015/12/21(月) 01:12:01.84

ある実行中の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

**デフォルトの名無しさん** · 2015/12/21(月) 01:12:28.39

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

**デフォルトの名無しさん** · 2015/12/21(月) 05:09:36.07

==='[Object Array'] では駄目で Array.isArray は良いとかではなく、
@@toStringTagを考慮してあげるか、そこまでしないかの差だというつもりで差があると言ったんだよ。
そもそもisArrayもProxyは通すからね。別にisArrayに通ったからといってそれがArrayの動作をすることまで保証されていない。
起源がArrayだという程度の意味しかない。
それで十分な場合も多いと思うが、より良い配列の判定がある場合も多いという話がしたかったのだよ。

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

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

**デフォルトの名無しさん** · 2015/12/23(水) 00:27:11.83

ここは「言って欲しい意見」を期待できるところではない。それは諦めろ。
さすがにそれだと本当に書いているのか疑問だ。
色々ツッコミどころはあるが、一つずつ行こう。

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

**デフォルトの名無しさん** · 2015/12/24(木) 07:58:45.60

>>38
「言って欲しい意見」を期待とはどういうことだ？
そちらがこちらの話した意図を正しく捉えて無かったようなので補足したまで。

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

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

**デフォルトの名無しさん** · 2015/12/24(木) 18:11:12.05

まあ自分が今回JSらしさとかtoStringTagらしさをどのように語っているのかというと、
仕様の定義に根拠を置いているんだよね。
緩いJSとは言え本当にすべきでないようなことや悪いことは仕様で禁止されている。
逆に禁止されていないのであれば、原則活用することは罪ではないと考える。

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

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

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

**デフォルトの名無しさん** · 2015/12/26(土) 19:51:45.07

「Microsoft EdgeのJavaScriptエンジンを、ChakraCoreとしてオープンソース化する」

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

**デフォルトの名無しさん** · 2016/01/10(日) 21:23:23.77

具体的なコードをもとに話を進めてくれないと、
何がやりたいのかさっぱりわからない
文字数は出来るだけ切り詰めて原則箇条書きとかね
一般論をダラダラやられても困る

**デフォルトの名無しさん** · 2016/01/12(火) 17:09:01.34

適当に例を挙げての具体的な話などしても意味は無い
具体的であればあるほど答えは誰が見ても決まってるのだから
そもそもその手の人達が一般的にどうしてそういう行動するのか共感ができないというから
その原理と一般的な信条、思考パターンを述べる展開になっている

**デフォルトの名無しさん** · 2016/02/08(月) 22:51:41.45

C言語信者な元ゲームプログラマーで今有明海の漁師です。
C言語信者なのは、スピード命！スクリプトとかCPU資源浪費しすぎだろ！
って思ってるから。
そんな私が、手持ちAndroid７インチタブレットで漁業用GPSロガーを使いたくなって
Google Maps API を触ってみた。

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

44 · 2016/02/08(月) 23:02:40.71

あ、ちなみに、表示してる緯度経度は日本測地系です。
漁業用のGPSが今もみんな日本測地系を使ってるので。
携帯もスマフォもGoogleMapも世界測地系なので変換してます。

**デフォルトの名無しさん** · 2016/02/09(火) 23:20:54.03

>>44
見た。
てか、きっちり書いてあるなあ。

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

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

**デフォルトの名無しさん** · 2016/02/10(水) 09:11:00.33

>>46
JavaScriptは今じゃ、ブラウザの言語でとどまってないからね。

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

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

**デフォルトの名無しさん** · 2016/02/11(木) 01:04:16.07

>>47
嫌いな人も多いが、俺もnodejsの便利さにいまさらびっくりしてる。
eureca.io使って、クライアントとサーバが双方まるで直接呼んでるみたいにfunction呼び出しして、あまつさえコールバックまで出来るとは、とビビるくらい。

**デフォルトの名無しさん** · 2016/02/11(木) 09:19:41.38

>>48
言語の弱点をライブラリ群がカバーしてくれてるから、助かるよね。
支持されていなかったら、そのライブラリ達もいないわけで。

**デフォルトの名無しさん** · 2016/02/11(木) 16:07:05.01

>>49
あとは、プロトタイプベースで魔改造する余地があったのも大きいのかも。
普通の言語で、基底クラスを基底クラスのままメソッド追加するとか、上書きする、なんて今までの言語では頭おかしいって言われそうなユルさかつ、
言語仕様としてシングルスレッドじゃん→なんかコールバックさせる仕組みを外に持たないとね→実装
みたいな魔に魔を重ねた改造の結果、使いやすくなってるような気がする。

44 · 2016/02/12(金) 01:30:54.19

>>46
距離を計算するGoogleMapsライブラリに
グローバルで保持してる中心座標を渡したらエラー。。。
new 座標（global中心座標）して渡したら通る。。。どういうこと？

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

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

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

**デフォルトの名無しさん** · 2016/02/12(金) 08:43:48.25

>>51
new Dateと同じだろ。

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

**デフォルトの名無しさん** · 2016/02/12(金) 20:46:32.04

>>51
物があるんだから具体的に何行目って言ってくれた方が分かりやすいとは思うけど、
見た目多分>>52であってる。
俺もそんなに詳しい訳じゃないし、APIの仕様も知らないけど。

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

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

**デフォルトの名無しさん** · 2016/02/12(金) 23:30:42.28

>>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さんが勝手に掃除してくれますよね！

**デフォルトの名無しさん** · 2016/02/13(土) 00:01:10.41

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

**デフォルトの名無しさん** · 2016/02/13(土) 00:40:54.25

>>55
レスthxです。

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

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

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

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

**デフォルトの名無しさん** · 2016/02/13(土) 01:31:30.78

>>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を使えばいい。

**デフォルトの名無しさん** · 2016/02/13(土) 01:57:33.47

> ＃プログラミングって楽しいですよね！
正直、ブラウザ上でのプログラミングはかなり楽しいと思う。
GUIで具しか書かなくていいのでチャキチャキ感があっていい。
ただ、他の新しいGUIは知らないから、他にもいいのがあるかもしれないけど。

**デフォルトの名無しさん** · 2016/02/13(土) 03:17:29.54

>>58
色々教えてくださってありがとう御座います。

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

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

**デフォルトの名無しさん** · 2016/02/13(土) 03:40:04.40

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

スレチ、失礼しました。

**デフォルトの名無しさん** · 2016/02/17(水) 19:47:14.33

今更ながらjs2-mode導入して色を付けてみたが、ちょっとイマイチだな。
キルリングの取り扱いが変わっていて慣れないし、
括弧閉じてもインデントが上がってくれない。
括弧の対応がハイライトされないのも謎だ。
まあもう少し使ってみるけど。

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

**デフォルトの名無しさん** · 2016/02/21(日) 09:27:40.55

>>57
>>GCして欲しいのならnull代入するなりdeleteするなり関数で囲って関数ごと捨てるなりするしかないけど
それらでCGされる保証はない
エンジンは一般的な場合に最適化されてる
一般的でないことはしないのが基本

**デフォルトの名無しさん** · 2016/02/24(水) 01:04:57.69

すいません、キルリングの仕様変更はemacs23からのものらしく、
js2-modeは関係ありませんでした。

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

**デフォルトの名無しさん** · 2016/03/28(月) 23:29:32.90

nodeスレより
http://yosuke-furukawa.hatenablog.com/entry/2016/03/27/152500

**デフォルトの名無しさん** · 2016/04/13(水) 23:34:15.51

textContentってquerySelectorで引っかけられないよね？とりあえず

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

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

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

**デフォルトの名無しさん** · 2016/04/19(火) 11:57:14.77

速度も見た目も十分だよ
それを何度も実行する気なら状況によって要素や文字列をキャッシュすればいいし、
もっともっと短くしたいのならES2015を使えばいい

**デフォルトの名無しさん** · 2016/04/19(火) 21:54:42.16

テーブルに大量の行を挿入したい時とかって普通にやると応答止まるけどプロはどうやってんの？

**デフォルトの名無しさん** · 2016/04/20(水) 01:37:27.97

>>66
本当は、

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

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

**デフォルトの名無しさん** · 2016/04/20(水) 01:44:58.86

>>67
大量の行の挿入くらいじゃ止まらないし、
そもそも一画面分以上挿入する必要もないだろ。

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

**デフォルトの名無しさん** · 2016/04/20(水) 08:04:48.78

requestIdleCallbackで分割しながら挿入すれば良し

**デフォルトの名無しさん** · 2016/04/20(水) 09:52:44.31

vol.119で質問すれば良いのになぜこんな場所で質問してるのか
ここで詳しく回答する気は起きないので簡単にしかいわんけど
http://echo.2ch.net/test/read.cgi/tech/1457452716/

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

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

**デフォルトの名無しさん** · 2016/04/25(月) 00:30:16.00

ふと思ったんだが、forEach って何で currentValue が this になるのがデフォじゃないんだ？
グローバルじゃ意味無いよな？
引数で与えられるから動作としては問題なく、見た目だけの話だけど。

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

**デフォルトの名無しさん** · 2016/04/25(月) 04:01:16.41

thisに色んな意味を付けて何でもかんでも与えるなんてセンス無いから
現にアロー関数だったとき機能しないでしょ

**デフォルトの名無しさん** · 2016/04/25(月) 04:10:55.58

>>732
currentValue が thisになるのなんて、
DOMのイベントハンドラの中でthisが要素になるぐらいのもんだろ。
そもそもDOMはJavaScriptではない。
そもそもDOMがおかしいんだよ。

**デフォルトの名無しさん** · 2016/04/25(月) 08:11:57.07

>>73
> 現にアロー関数だったとき機能しないでしょ
あれはどっちかというと無駄な仕様変更だと思うが。
正確に言うと無駄な仕様を削除して新しく自動 .bind(this) に変更したわけだが、
その必要も無かった（と思う）

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

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

**デフォルトの名無しさん** · 2016/04/25(月) 17:28:53.92

>>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値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない

**デフォルトの名無しさん** · 2016/04/25(月) 17:47:23.15

>>75
仕様「変更」ではない
アロー関数はより「ピュア」な新たな関数
newも出来ないし、thisやsuperも変数と同じように参照する
bindとは違う
統一感はある
DOMは関係ない、altJSでも同じこと
というかデファクトであってそれに依存するのは非推奨

**デフォルトの名無しさん** · 2016/04/25(月) 19:33:42.57

>>76
指摘の通りDOMをイメージしていて、
これまた指摘の通り全部thisでやろうとすること自体が糞だと理解した。

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

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

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

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

**デフォルトの名無しさん** · 2016/04/25(月) 22:39:46.80

>>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オブジェクトの仕様と
互換性を持たせて実装されている。

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

**デフォルトの名無しさん** · 2016/04/25(月) 22:47:27.73

>>76
> jQueryはthisをローカル変数でも引数でもない第三の格納倉庫として利用し、コード上でthis値が変更されることを許さない
> this値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない

そんなことしません。

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

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

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

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

**デフォルトの名無しさん** · 2016/04/25(月) 22:49:10.70

これね。

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.

**デフォルトの名無しさん** · 2016/04/25(月) 23:32:07.55

>>76でhandleEventの話が出ているが、使った人ならわかると思うが、
handleEventはswitchでイベントを振り分ける必要があって使いづらい。

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

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

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

76 · 2016/04/26(火) 00:48:49.99

>>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 値を指定すべきではない

**デフォルトの名無しさん** · 2016/04/26(火) 00:50:01.95

>>80
> jQueryは要素ごとの情報の格納場所の必要性を昔から認識していた
これは俺もすごく思うが、
実際のところはリークと速度低下が怖くてJavaScript側で持っている。
さすが実用ライブラリだけあって痒い所には手が届いているというところか。

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

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

76 · 2016/04/26(火) 00:51:40.14

>>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 値が変動する事に価値を見出せる設計にする必要がある

76 · 2016/04/26(火) 01:08:23.70

>>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); });

76 · 2016/04/26(火) 01:50:16.54

>>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

**デフォルトの名無しさん** · 2016/04/26(火) 11:16:02.05

つうか結局何が言いたいの？
thisはpythonのselfみたいに一定の規則はあるが
あくまで０番目の引数みたいなもんで何に使おうが勝手だし
そういうのを利用するならきちんと把握しないといけない
その程度のことに良いとか悪いとかはない
使いたいならただ受け入れればいいだけ

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

**デフォルトの名無しさん** · 2016/04/26(火) 17:56:08.45

C#みたいにobj.Methodでバインドしてくれれば楽で綺麗に書けるのにね
いちいちbindって書くの面倒

**デフォルトの名無しさん** · 2016/04/26(火) 19:15:29.79

>>88
ここまで説明されて愚痴にしか読めないのなら口を出さなければ良いと思うけど

**デフォルトの名無しさん** · 2016/04/26(火) 19:52:24.85

>>89
引数としてメソッドを渡す際は今だと
obj.method.bind(obj)
よりもアロー関数を使って
()=>obj.method()
の方が良いかもしれない

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

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

**デフォルトの名無しさん** · 2016/04/26(火) 23:52:32.19

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

**デフォルトの名無しさん** · 2016/04/26(火) 23:53:03.95

>>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を生かして」使うことになる。
当たり判定のグルーピングを細かく変更したいときはこのやり方が適するけど、
用途はあまり無いと思う。

**デフォルトの名無しさん** · 2016/04/26(火) 23:54:04.46

だから「相互運用」を考えるのなら、
e.currentTargetとthisの両方を異なる意味で用いている上記のようなケースをどうするかであって、
多分これはどうにもならんだろ。
手っ取り早いのはラップ関数内でthis値をMapなりから引っ張ってきてしまうことだが、
要するに書き換えが必要なので仕様をわざわざ合わせた意味がない。
何らかのために仕様をあわせたというのなら、
そのおかげで書き換えなくても済みました！がないと意味が無い。

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

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

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

**デフォルトの名無しさん** · 2016/04/26(火) 23:55:02.00

>>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){},
};

**デフォルトの名無しさん** · 2016/04/26(火) 23:55:42.51

>>86
いやそのjQuery.eachのthisは意味があるぞ。
それならthisで書かれたイベントハンドラをeachで回せる。（DOMのイベント寄り）
ただe.currentTargetで書くべきだというのと、
そもそも他に代替手段がありまくるので、割とどうでもいいが。
thisを固定したことによるデメリットの方が上回るかもしれない。

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

**デフォルトの名無しさん** · 2016/04/27(水) 00:28:53.55

「thisは基本レシーバ」
それ以上でも以下でもない

**デフォルトの名無しさん** · 2016/05/01(日) 14:45:40.12

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

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

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

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

The Covenant Project
概要

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

目的

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

特徴

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

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

**デフォルトの名無しさん** · 2016/05/03(火) 12:04:12.37

もうWebRTC利用したJS製のそういうフレームワーク何個も作られてるよ

**デフォルトの名無しさん** · 2016/05/03(火) 18:27:13.57

WebRTCって要するにP2Pチャットサーバ用だよな。
元々それ用だけどそれ以外に用途が無い。
もちろん発展させればWinnyやskypeみたいな事は出来るけど、それなら最初からそっちでいいし。

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

**デフォルトの名無しさん** · 2016/05/04(水) 19:58:18.58

ちいと勘違いしてるが、WebRTCに鯖とのやり取りもといマッチングの仕組みは含まれていない。
WebRTCでそれをするのはちょっとハックっぽくなるが、
特にORTCなら鯖レスの固定相手P2Pも素直にできる。

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

**デフォルトの名無しさん** · 2016/05/04(水) 23:45:02.80

> MMOゲーム
これにはいいかもな。

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

**デフォルトの名無しさん** · 2016/05/05(木) 04:30:39.98

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

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

**デフォルトの名無しさん** · 2016/05/05(木) 09:25:46.88

ブラウザのBBOM化はもう勘弁して

**デフォルトの名無しさん** · 2016/05/09(月) 15:41:03.36

なんで？

**デフォルトの名無しさん** · 2016/05/09(月) 22:54:55.21

BOMのことだよな？
個人的にはDOMやBOMでAPIアクセスできるのはお手軽でいいと思うぞ。

**デフォルトの名無しさん** · 2016/05/09(月) 23:34:30.27

もはや種類多すぎる上に増加スピードが速すぎて把握するのがしんどいわ
でも無ければ無いで何も作れないしな

**デフォルトの名無しさん** · 2016/05/10(火) 10:34:10.82

スピードが早いというが、一年くらい前から高レベル系のAPIが熟成期に入って停滞してると思う
また来年くらいから今度は低レベル系のAPIが動き始めるんじゃないかな

**デフォルトの名無しさん** · 2016/05/10(火) 23:06:42.46

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

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

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

**デフォルトの名無しさん** · 2016/05/11(水) 07:45:48.20

>>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は最悪中の最悪ケース。

**デフォルトの名無しさん** · 2016/05/11(水) 22:18:37.29

APIはポリフィルできても、言語はポリフィルできないからな。
だからBabelなどのトランスパイラが必要になる。

**デフォルトの名無しさん** · 2016/05/12(木) 00:54:26.89

>>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がどうなるのかは見ものだな。

**デフォルトの名無しさん** · 2016/05/12(木) 00:54:55.63

> ちゃんと書く
速度を問題にしているのだろう？だったらきちんと速度が出る書き方をするということだよ。
5倍というのはググれば出てくるはずだがN-body、つまり演算部分だ。
同様のベンチは他の人もやっていて、大体同じような値になっている。

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

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

**デフォルトの名無しさん** · 2016/05/12(木) 05:43:37.43

WSHが一番マシ

**デフォルトの名無しさん** · 2016/05/12(木) 08:43:22.73

>>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++で書いたりもしやすい。

**デフォルトの名無しさん** · 2016/05/12(木) 08:44:46.17

記事リンクを貼ってなかった
https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/

**デフォルトの名無しさん** · 2016/05/12(木) 23:52:09.31

>>114
WSHか。あれ食わず嫌いだったけど、やっぱお手軽でよさそうだよな。
まあやってみることにするよ。

**デフォルトの名無しさん** · 2016/05/12(木) 23:59:02.52

>>115
違う。
> 策定に時間がかかったり、実装者や開発者とのやり取りが十分ではなかったから。
仕様策定とは「常に」こういうものなんだよ。言語のみならず他でも全て。
有名なイラスト、見たことがあるだろ。
> ニコニコ大百科/a/顧客が本当に必要だったもの (リンクはRock54で貼れない）
だから、これを分かった上で、そうならないようにする「実力」が必要なんだよ。

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

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

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

**デフォルトの名無しさん** · 2016/05/13(金) 00:04:56.39

>>115
> 自分が言った「ちゃんと書く」とは、asm.jsを（部分的に）手書きするということだ。
だからそれは屁理屈なんだよ。
言語の速度比較なら、普通に書いた、つまりそこらへんに転がっている記述同士でやらないと意味無いだろ。
Cでインラインアセンブラを使うのは無し、
JavaScriptなら普通に [], {}を使って書いたものだよ。全面 TypedArray とかは無しだよ。
というか、それならそもそもそういう言語で書けって言われるようじゃ駄目だろ。
言語の比較なら、それぞれの言語の良さを生かした状態で記述してあるものでないと。

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

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

**デフォルトの名無しさん** · 2016/05/13(金) 09:43:39.39

>>118
JavaScriptと言うより、Webの宿命。ES仕様自体は元々が小さかったのも有り、
妥当で慎重な機能追加で順調に進化してきている。

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

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

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

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

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

**デフォルトの名無しさん** · 2016/05/13(金) 17:53:59.39

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

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

**デフォルトの名無しさん** · 2016/05/13(金) 20:51:55.08

>>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なんだけどね。

**デフォルトの名無しさん** · 2016/05/13(金) 20:58:41.47

外部と隔離された無人島で20年過ごしてきた人なのかな？

**デフォルトの名無しさん** · 2016/05/13(金) 22:06:05.08

>>120
> EWM
否定したいわけではないが、君が言っているような「打ち出の小槌」なんてどこにもないんだよ。

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

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

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

**デフォルトの名無しさん** · 2016/05/13(金) 22:06:20.89

まあいずれにしても、上手く行くかどうかは結果を見ればいい。
俺は上手く行かないと予想している。
ブラウザ側も馬鹿ではないから、俺が言っていることぐらい分かっている。
だからgoogleの「最適化としては行うが、asm.jsにべったりでは無い」というのがかなり妥当。
旗振り側のFireFoxは実装するしかないから、両方の言い分は分かる。
君の見方だけではgoogleが及び腰な理由を説明できないだろ。

**デフォルトの名無しさん** · 2016/05/13(金) 22:12:02.90

> どうせちょっと高速化を意識すると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)

**デフォルトの名無しさん** · 2016/05/13(金) 22:12:42.95

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倍になる方が普通はうれしいだろ。

**デフォルトの名無しさん** · 2016/05/13(金) 22:40:16.76

>>121
> 仕様の量も段違い
とにかくこういうことにしたい奴が多いようだが、これは明らかに違う。
.NETにしてもJavaにしてもクラスライブラリの量は桁違いに多い。
文法的にも覚えることは多いし、記述的にもより細かく指定できる。
JavaScriptは軽くて簡単な言語だよ。元々そう作られたものだし。
（これは悪いことではない）

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

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

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

**デフォルトの名無しさん** · 2016/05/14(土) 00:17:31.72

> 詳しくは知らないが、DirectXはバージョンが一つ違ったら別物だったらしい。
DirectXだけじゃなくて「昔は」って言ったほうがいいよ。

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

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

**デフォルトの名無しさん** · 2016/05/14(土) 05:05:12.84

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

**デフォルトの名無しさん** · 2016/05/14(土) 05:07:22.52

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

**デフォルトの名無しさん** · 2016/05/14(土) 08:40:44.17

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