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

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

実際に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 は表現が抽象的すぎてわかりづらい
「「ちゃんと」」(何をどうちゃんと？)
「「普通に」」(普通って何？)
「自然となっていった」(どの辺りが自然？)
何となくわかる気はするけど、具体的でない部分が誤解を生みやすいと思う
「ちゃんと === 速度を最上位に最適化した普通はやらないようなニッチな最適化」
こんな感じだと勝手に認識してるけど、一般的な感覚で考えても「ちゃんと」とは言い難いような

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

>>130
レベルに関わらず、「将来的に必要」なAPIだけ規定できれば全く問題ないのだが、
それが難しいんだよ。
AppCacheにしても、WebSQLにしても、その当時は「それが必要」だと思っていたはずなんだよ。
WebSQLの方は政治的横槍で、AppCacheの方は担当者の実力不足でゴミ化したわけだが。

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

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

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

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

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

> JSらしくないこともない
要するに自分の手持ちの選択肢の中で「JSでやるのが一番マシ」と思えるのならそれでよし、
そうでないのなら、それはJSを無理に使っているだけだよ。

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

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

> Webは中央政権的でない（なくなった）から全てをひとまとめにしてバージョン付けはできない。
これはそちらの認識が間違っている。
そもそも、仕様を策定するのは「困るから」であって、「支配する」為ではない。
元々W3Cがその位置にいたのだが、官僚的だったのか、とにかく仕様の決定が遅すぎた。
だから無視するのが通例になってしまっているが、本来はW3Cが機能していればよかっただけの話だ。

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

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

> 中央政権的なFlash等プラグインの死
以下を読んだ。
> http://uxmilk.jp/5784
まあ俺も筆者と同意、Flashは死ぬべくして死んだだけ、
ジョブスが引導を渡した形になったのは、ジョブスに先見の明があっただけ、と思える。
実際、今Flashが欲しいって思うことは無いだろ？要らなくなったんだよ。

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

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

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

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

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

だから、それが大多数の人にとって正解と思えるのなら、自然と
> じゃあもう低レベルなAPI群を定義して、もっとオープンに仕様を発展できるようにしよう。
ということになっていく。それは君や俺がどう思おうが関係ない。
ただ、そうなっていないのなら、それはそう認識されてないということだよ。
つまり君の認識が間違っているということ。

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

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

将来においても絶対に変わることがなくて、
ブラウザの実装者の負担にならない最低限の共通の機能をもったAPI
そしてその共通APIを使ってより便利なことをするライブラリ。

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

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

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

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

> よりオープンなそれこそ誰でもGithubに書いて主張できるような仕様形態に「自然となっていった」。
これは事実としてそうなっているね。
つまり大多数の人にとって、これが「現状一番マシなやり方」と認識されているということ。

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

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

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

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

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

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

だいぶ意見の摺り合わせがなされた。殆ど言葉の定義的なことやニュアンスの行き違いで
多分経験と立場からくる「常識」などの差を考えれば、根本的な部分の意見の出し方の相違はあまりないと思う。
もうこれ以上は無理だろうけど、明らかに違う部分と、自分の中で強い意見を持ってる部分だけ言っとく。

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

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

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

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

そしてJSらしさについて
そもそもJSらしさとは何なのか？例えばクラスっぽいものを作ろうとした時、
functionと.prototypeを使うのがそうなのか？
それでもって継承っぽいものを実現したいときは、ハックに近い方法で言語の底のプロトタイプ性に干渉し為すのがJSらしいということなのか？
それとも今となってはclass構文と、extendsで実現するのが素直にJSらしいということなのだろうか？

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

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

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

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

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

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

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

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

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

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

ここまでの流れ、ちょっと狐につままれているような感じだ。
自分としては歴史や試した経験事実に沿って、淡々とお話した部分が多い。
別にこの宇宙において何が善悪かを語ったつもりもなく、一例を挙げたりしながら部分部分に対して必然的な事柄を語っただけだ。
だからバザール型云々の話も意図的にスルーしている。

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

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

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

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

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

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

三行でまとめろ

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

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

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

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

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

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

>>141
1.6まで読んだ。なるほどWHATWG側の見解は分かった。
しかし、ある意味ありがちな展開だ。
仕様を決めている奴は仕様を決めるのが目的で、使うためではないからな。（手段の目的化）
これは決裂して当然、とはいえもうちょっとマシな展開は無かったのかとも思うが。
そしてECMAscriptの仕様書が他言語と比べて異様な理由も理解した。

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

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

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

> 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で書けということになる。

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

JSの特徴はユルさだ。だから君みたいに好きなように混ぜこぜで書くのならそれはJS向きだ。
ただ、TypedArray「しか」使う気が無く、またそれがそのアプリにとって重要なら、それはC向き案件だ。
それはメモリアクセス速度が重要だということだから。

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

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

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

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

多分な、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 対応環境でのみ動作しないということが発生する。（非対応環境では動作）
しかしこのコメントをつける奴らは当然対応環境でデバッグするのだから、これでいい。

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

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でデバッグできるのならそれも相当魅力的なので。

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

>>150

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

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

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

**144** · 2016/05/15(日) 05:38:37.51

>>146-
まあAppCacheは（一応JSへのAPIもあるがそんなに使われていない）
あくまでキャッシュなのでいきなり削除しても問題になることが少なく
特例的に極めて廃止しやすい方だ。（廃止される）
他のAPIも、LSが広まりだしてから非推奨を設定しやすくなった。

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

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

**デフォルトの名無しさん** · 2016/05/15(日) 09:04:33.00

>>153
> １０年は自分にとってWebにおいて永遠と等しいように感じる。
これでいいんだよ。逆に有限で廃止すると混乱する。

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

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

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

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

**デフォルトの名無しさん** · 2016/05/15(日) 12:44:09.17

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

**デフォルトの名無しさん** · 2016/05/15(日) 13:47:01.97

ブラウザのJavaScriptの特殊性を分かってないんじゃないだろうか？

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

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

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

**144** · 2016/05/15(日) 16:58:58.26

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

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

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

**デフォルトの名無しさん** · 2016/05/15(日) 17:01:58.55

>>154
'use strict'強制は、ES2015のclass構文内やモジュール内で達成されている。
typeof nullの挙動は２年前治そうという案の盛り上がりが頂点に達したのだが互換性のために断念した。
が、将来的な演算子オーバーロードの仕様が入ると共に直す策を入れようと言う案は出てる。
もしくは、V8が画策している型付厳格JSの方向性が成ればそちらでも更生は可能。

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

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

**デフォルトの名無しさん** · 2016/05/15(日) 17:04:24.78

誤字脱字や凡ミスは良いように解釈してくれ。スマヌ。

**デフォルトの名無しさん** · 2016/05/15(日) 17:51:57.74

そういえば 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等の仕事だ。

**デフォルトの名無しさん** · 2016/05/15(日) 18:16:01.44

>>160
アホか。パーサ書いて文脈見ずにreplaceなんかで解決できねえよ。

**デフォルトの名無しさん** · 2016/05/15(日) 19:03:27.04

>>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に化けているからこれができない。

**デフォルトの名無しさん** · 2016/05/15(日) 19:54:18.43

>>162
http://httpstat.us/304
に対して試してるんだけどそれらの環境で304取得できるよ。
こういうコードで。
xhr = new XMLHttpRequest
xhr.open('get', '304')
xhr.onload = () => console.log('status', xhr.status)
xhr.send()

**デフォルトの名無しさん** · 2016/05/15(日) 19:55:03.02

おっと、
xhr.open('GET', 'http://httpstat.us/304')
にしとくか

**デフォルトの名無しさん** · 2016/05/15(日) 20:00:25.76

> 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;
と書けるという事だろうけど、こんなところでタイプ量をケチってもしょうがないし、
バグってても見た瞬間修正できるので、正直どうでもいい。

**デフォルトの名無しさん** · 2016/05/15(日) 20:08:28.09

>>163-164
サンクス。こちらもそのコードで304を確認した。
ただし俺のスクリプトでは確かに304が200に化けている。
原因究明には少し時間がかかりそうだ。

**デフォルトの名無しさん** · 2016/05/15(日) 20:45:26.55

>>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をみすみす捨てているようなものなんだよ。勿体無いだろ？

**デフォルトの名無しさん** · 2016/05/15(日) 20:52:38.61

>>158
> 'use strict'強制は、ES2015のclass構文内やモジュール内で達成されている。
確認した。現実的にはこれで問題なさそうだな。
http://stackoverflow.com/questions/31685262/not-recommended-to-write-out-use-strict-with-es6

**デフォルトの名無しさん** · 2016/05/15(日) 22:01:03.99

>>163-164
どうやら強いEtag + nginx + gzip の場合に駄目らしいと分かった。
俺のスクリプトで化けているサイトも該当している。
> https://github.com/rtomayko/rack-cache/issues/111
しかしこれはこちらではどうにもならんな、、、、

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

**デフォルトの名無しさん** · 2016/05/15(日) 22:04:49.13

>>165
優先順位を粗方決めたいだけならServiceWorkerを使えば可能そう。

>>167
つまり何が言いたいかというと、
n = prompt('自然数')
↑
（この型は何だ！？？）
という状態のまま処理を出来る限り進めないということ。
もっと言うと、「n」なのに数値じゃないかもしれない可能性を作らないこと。

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

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

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

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

**デフォルトの名無しさん** · 2016/05/15(日) 23:44:52.60

>>143
こいつダメだ

**デフォルトの名無しさん** · 2016/05/15(日) 23:55:13.32

>>170
> ServiceWorker
とりあえずhttps限定の時点で使えない。
気持ちは分かるがそこはユーザに選択させろよなと。

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

**デフォルトの名無しさん** · 2016/05/16(月) 00:26:42.96

>>170
主張は分かるがそれは完全に「型あり」の考え方だからな。
そうしたいのなら、「型」を導入してキャストするのが一番いい。
つまり、

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

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

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

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

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

**デフォルトの名無しさん** · 2016/05/16(月) 05:31:59.61

>>172
HTTPS必須は、「Let's Encrypt」が一般的に広まって、もっと道入が楽になることに期待する。

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

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

**デフォルトの名無しさん** · 2016/05/16(月) 08:47:49.06

横から口を出すが

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

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

**175** · 2016/05/16(月) 09:11:44.49

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

**デフォルトの名無しさん** · 2016/05/16(月) 12:29:46.57

そういえば、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');
}

**デフォルトの名無しさん** · 2016/05/16(月) 15:12:30.62

なんでそういう実装になってるんだろう？
function isObject(value) {
return value === Object(value)
}
の方が素朴で良い実装じゃね？

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

まあはやくReflect.isCallableとか追加されて欲しい、
ダックタイピングぽく、型より機能としてチェックするほうがいいと思う。

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

>>174
それはやれば出来るかもしれないが、「制御のための制御」になるので駄目だ。
別の言い方だと、それにかかる労力の割りに得られる結果がショボ過ぎて駄目だ。

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

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

**デフォルトの名無しさん** · 2016/05/16(月) 23:32:06.76

>>175
> 長すぎる云々
まず文盲で無いことを示してもらおう。これは具体的にどこのことだ？
俺は長さについては問題にしていない。

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

**デフォルトの名無しさん** · 2016/05/16(月) 23:37:53.21

>>181
>>167の下記だろう

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