- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
133 ：デフォルトの名無しさん[sage]：2016/05/14(土) 13:45:41.17 ID:Jg6FEyPA - >>130
レベルに関わらず、「将来的に必要」なAPIだけ規定できれば全く問題ないのだが、
それが難しいんだよ。
AppCacheにしても、WebSQLにしても、その当時は「それが必要」だと思っていたはずなんだよ。
WebSQLの方は政治的横槍で、AppCacheの方は担当者の実力不足でゴミ化したわけだが。
いずれにしても、「今」そう思っているものが「将来も」正しいとは限らないんだ。
君が言っているものは「もう既にあって」「今必要」なものだろう。(Socketは1983年製）
それを仕様化するのも重要な仕事だけど、それは凡人でも出来る。
本来仕様化しなければならないものは、「今無くて」「将来およびその後もずっと必要」なものなんだよ。
AppCacheは後者をやろうとして頓挫した。これは実力不足だ。
WebSQLの方は前者、つまり既にあるものをWeb用に焼きなおそうとした。これは凡人でも出来る。
ただし政治的要因で頓挫した。
NodeのSocketは、前者でしかない。20年以上実績のあるものの導入であって、凡人でも出来るものだよ。
Webがもたらした「先進的」仕様は、例えばHTMLとCSSの分離とかだよ。
（当時はレイアウトと文書を分離しないのが一般的だった）
これが効いてて、スマホでも見れる画面になっている。(対応しやすい）
一方、基本的にピクセル指定する従来アプリ(.NET)とかをスマホで見ると悲惨だと聞く。
だから.NETはUIの焼き直しを迫られている。
AppCacheについては実は俺も使おうかと検討したことがあるが、止めた。
理由は、俺が対象としているサイトはリバースプロキシが普及していて、
変にキャッシュするより読み直したほうがサクサクだからだ。(304が速攻返ってくる）
これが他のケースでも当てはまるとしたら、仮にAppCacheの仕様がいいものだったとしても、誰も使わない。
この場合の正解は、「AppCacheなんてじきにリバースプロキシが普及するから必要ありません」だ。
あるいは、「オフライン？ナローバンド？そんなものはありえない時代がすぐに来ますよ」だ。
これを当時言い切れるかどうかが「先見の明」ということになる。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
134 ：デフォルトの名無しさん[sage]：2016/05/14(土) 13:46:10.60 ID:Jg6FEyPA - > JSらしくないこともない
要するに自分の手持ちの選択肢の中で「JSでやるのが一番マシ」と思えるのならそれでよし、
そうでないのなら、それはJSを無理に使っているだけだよ。
> 実際asm.jsを使う場面が殆ど無いのは先も言ったとおり。
ブラウザを作っている奴らも暇じゃない。無限のリソースがあるわけでもない。
奴らにとって「重要」だと認識されない限りは歯車は回らない。
そして今のところ、あるいは近未来的にもそうはならないというのが俺の見方だ。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
135 ：デフォルトの名無しさん[sage]：2016/05/14(土) 13:46:57.24 ID:Jg6FEyPA - > Webは中央政権的でない（なくなった）から全てをひとまとめにしてバージョン付けはできない。
これはそちらの認識が間違っている。
そもそも、仕様を策定するのは「困るから」であって、「支配する」為ではない。
元々W3Cがその位置にいたのだが、官僚的だったのか、とにかく仕様の決定が遅すぎた。
だから無視するのが通例になってしまっているが、本来はW3Cが機能していればよかっただけの話だ。
ただ結果を見ている限り、clientHeight/innerHeight等、
名前を決めればいいだけの部分でさえすり合わせ出来ていない点、
あるいはJavaScriptと名乗れずJScriptとなっている点等からしても、
（どちらが仕掛けたかはよく分からないが）何らかの政治的思惑が絡まっており、
W3Cは「使えない」として見切りをつけられているように見える。
（見切りをつけたこと自体は正しいが、それによって我々が不便をこうむっているのはご承知の通り）
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
136 ：デフォルトの名無しさん[sage]：2016/05/14(土) 13:48:07.29 ID:Jg6FEyPA - > 中央政権的なFlash等プラグインの死
以下を読んだ。
> http://uxmilk.jp/5784
まあ俺も筆者と同意、Flashは死ぬべくして死んだだけ、
ジョブスが引導を渡した形になったのは、ジョブスに先見の明があっただけ、と思える。
実際、今Flashが欲しいって思うことは無いだろ？要らなくなったんだよ。
だから君の
> Webは中央政権的でない
というところが大前提として間違っている。
そもそも、何であっても「中央政権的」ではないんだよ。それが資本主義だから。
例えば、iPhoneが中央政権的であるとしよう。
ではiPhoneがその機能を「搭載」あるいは「削除」したら、他が「必ず」付いてくるか？
答えはNoだ。Flashが必要なら他サイトは対応し続けるだろうし、iPhone側も搭載を余儀なくされる。
例えば初期のiPhoneは「コピペ」機能が無かった。これはジョブスが「不要」と判断したかららしいが、
さすがにこれは3代目くらいで「復活」した。（これについてはなぜいらないと思ったのか謎）
Windows8はスタートボタンを「廃止」したが、誰も望んでいないこの変更は修正を余儀なくされた。
かつてRIMMという先進的DRAMがあったのだが、特許料を取るだけのものだと判明したため、
各社は旧来のDDRをDDR2/3/4と進化させるほうを選択し、RIMMは死んだ。
何かを中央政権的に仕掛けることは出来るが、それを追認するかどうかは市場が決める。
結果的に、無理な仕掛けは頓挫するようになっている。これは資本主義のいいところだよ。
君の世界観が中央政権的なものを肯定するのは、
一般に中央政権的なことが出来る規模のトップにいる奴はかなり優秀で、
そいつらのやったことが正しくて追認されることが比較的多いからだよ。
ただし上記のように、探せば結構間抜けなこともやっている。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
137 ：デフォルトの名無しさん[sage]：2016/05/14(土) 13:49:00.26 ID:Jg6FEyPA - だから、それが大多数の人にとって正解と思えるのなら、自然と
> じゃあもう低レベルなAPI群を定義して、もっとオープンに仕様を発展できるようにしよう。
ということになっていく。それは君や俺がどう思おうが関係ない。
ただ、そうなっていないのなら、それはそう認識されてないということだよ。
つまり君の認識が間違っているということ。
asm.jsもServeceWorkerももう数年になるが、これらは君的には普及したと思えるのかい？
あるいは、これらの流れを受けて、低レベルAPIを規定していくことが主流になったと思えるのかい？
俺にはそうは見えないけど。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
139 ：デフォルトの名無しさん[sage]：2016/05/14(土) 13:49:51.20 ID:Jg6FEyPA - > よりオープンなそれこそ誰でもGithubに書いて主張できるような仕様形態に「自然となっていった」。
これは事実としてそうなっているね。
つまり大多数の人にとって、これが「現状一番マシなやり方」と認識されているということ。
ただし、
> バージョニングの弊害の反省
これはjQueryか？
一般的にバージョニングで問題が発生するのは使い方が悪いだけ。
つまり、「仕様」に関わってはいけないレベルの馬鹿な奴らがバージョンを規定するからだよ。
そして必要な機能を「中央政権的」に落としたりするから混乱する。
あるいは変更の必然性が無い（延期できる）部分をバージョンを変えたからといって無駄に変更してみたり。
バージョニングで成功している例は、例えばWindowsだよ。
外面バージョンは、95, 98, Me, 2000, XP, Vista, 7, 8, 10 となっている。
これらまとめて全部 Windows という名詞しかなく、
明示的に分離することが出来なかったら、会話するのに困るだろ。(Linuxがそれに近い状態）
正しくバージョニングが出来ない連中ばかりだからといって、
バージョン自体をつけないのはさすがに間違いだよ。
実際、ES5,6,7, HTML4,5, CSS3,4ってのがバージョンだし、バージョンが付いてない案件はさすがに無いと思うが。
（バージョンが廃止された案件は無いはず。機能していない案件は多々あるとしても）
そして「このブラウザでは、HTML5, ES5, CSS3 まで対応しています」と言い切るためのもの。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
140 ：デフォルトの名無しさん[sage]：2016/05/14(土) 13:50:45.96 ID:Jg6FEyPA - ところで、
> Bluetooth機能
これは何？と思って調べたら、本当にあるんだな。
> https://developer.mozilla.org/ja/docs/Web/API/Web_Bluetooth_API
仕様としてはまあ妥当だな。
正直、bluetoothまでWeb側で面倒を見る必要があるとは思えないが、
OSのシステムコールを直接やらせることは出来ないという縛りによって、
OSのシステムコールの再発明を迫られるという間抜けな事態に陥っている。
とはいえ、これについては今後とも再発明し続けるという解しか思いつかないな。
IEEE側の仕様を上手いこと流用する手はあるはずだが、あちらは低レベル過ぎるだろうし。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
147 ：デフォルトの名無しさん[sage]：2016/05/14(土) 22:08:17.97 ID:Jg6FEyPA - >>141
1.6まで読んだ。なるほどWHATWG側の見解は分かった。
しかし、ある意味ありがちな展開だ。
仕様を決めている奴は仕様を決めるのが目的で、使うためではないからな。（手段の目的化）
これは決裂して当然、とはいえもうちょっとマシな展開は無かったのかとも思うが。
そしてECMAscriptの仕様書が他言語と比べて異様な理由も理解した。
LS版が日付＝バージョンなのはそれでいいが、
LSってのは「永遠に追いつかない目標仕様」であることを意味する。
実際そうなのかもしれないが。
本来は「仕様」がまずあって、それに沿って各所が部品を用意し、一気に組み上げるものだ。
プレハブの家とかいい例だ。
H264だって、仕様が確定してからでないとハードウェアデコーダは実装できない。
（仕様が少しでも変わるとゴミになる恐れがあるから）
LSってのはWebみたいに、いつでもダウンロードできて最新版が提供できるという前提でしか使えない。
LSでいけること自体がWebの強みかもしれんね。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
148 ：デフォルトの名無しさん[sage]：2016/05/14(土) 22:09:49.21 ID:Jg6FEyPA - > 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で書けということになる。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
149 ：デフォルトの名無しさん[sage]：2016/05/14(土) 22:10:30.57 ID:Jg6FEyPA - JSの特徴はユルさだ。だから君みたいに好きなように混ぜこぜで書くのならそれはJS向きだ。
ただ、TypedArray「しか」使う気が無く、またそれがそのアプリにとって重要なら、それはC向き案件だ。
それはメモリアクセス速度が重要だということだから。
N-bodyにこだわる必要は無くて、他のベンチでもおおむね同じだ。
「素のJS」を「素のC」と比べた場合、普通のコードなら5倍程度遅いということなんだよ。
当たり前だが添字範囲チェックはあるし、ハッシュキーも引くし、2重ポインタな訳だから、メモリアクセスは遅い。
TypedArrayでもこれらは変わらない。あれはこれ以前の型チェックが抜かれただけだから。
この状態で、5倍は見過ごせないというのなら、それはCで書くべきだし、
5倍程度で済むんだったら上等、それならイージーにやりたいと思うのならJSということだよ。
スクリプト言語で5倍程度なら、それは異様なほど速いので、俺は十分満足している。
TypedArrayは固定長配列だろ。それはユルさをひとつ消してしまう。
例えば、FIFOキューを作るとして、可変長なら shift(), push() だけで長さのことを考える必要もない。
それが固定長だと考える必要が出てくる。あふれないように追加のコードも必要だ。
もちろん固定長としてしか使わないのならTypedArrayでもいいし、
逆に固定長であることをTypedArrayで明記するというコーディングルールもありだろう。
しかし、こんなところを気にする奴が使うべき言語では無いんだよ。元々ね。それがLLというものだ。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
150 ：デフォルトの名無しさん[sage]：2016/05/14(土) 22:12:06.50 ID:Jg6FEyPA - 多分な、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 対応環境でのみ動作しないということが発生する。（非対応環境では動作）
しかしこのコメントをつける奴らは当然対応環境でデバッグするのだから、これでいい。
|
- JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net
151 ：デフォルトの名無しさん[sage]：2016/05/14(土) 22:13:45.30 ID:Jg6FEyPA - 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でデバッグできるのならそれも相当魅力的なので。
|