15/06/27 06:24:12.08 .net
嵐がいなくなったというか、ライブラリの話題が禁止されて
単にこのスレが過疎化しただけというｗ
質問自体が無いしね。雑談ばっかり。
834:Name_Not_Found
15/06/27 07:24:04.90 .net
もうすぐlodash 3.10リリース
lodash v3.10.0
URLﾘﾝｸ(github.com)
まだChangelogには書かれてないみたい
URLﾘﾝｸ(github.com)
835:Name_Not_Found
15/06/27 07:25:30.22 .net
jQuery 3.0 はまだまだかねぇ。
URLﾘﾝｸ(github.com)
836:Name_Not_Found
15/06/27 08:24:54.38 .net
久しぶりに1年前のスレを見てみたが、こんなに正常なスレだったんだな
vol115からライブラリ嵐の異様さがよくわかる
ｽﾚﾘﾝｸ(hp板)
837:Name_Not_Found
15/06/27 09:21:59.24 .net
その時点で大分正常から遠ざかってるように見えるが
838:Name_Not_Found
15/06/27 10:07:04.29 .net
そしてすっかり過疎化してしまった。
839:Name_Not_Found
15/06/27 11:26:12.65 .net
jsでファイルを複数に分けた場合、
それぞれのファイルでc言語で言うところの関数の外で宣言したstatic変数的な変数定義は出来ますか?
つまりそのファイルの中だけでグローバル変数になる。
840:Name_Not_Found
15/06/27 11:45:56.62 .net
nodejs
841:Name_Not_Found
15/06/27 12:43:47.62 .net
>>825
できない気がするけどファイル内全体を即時関数で囲っておいてその中で変数定義すればいいんじゃないかな
そうすれば変数も関数もローカルになるし
普通にグローバル定義したいものはwindow.xxx=function (){}みたいな感じで定義すればできるんじゃないかな
842:Name_Not_Found
15/06/27 13:32:35.12 .net
>>827
＞できない気がするけどファイル内全体を即時関数で囲って
レスありがとうございます。
ファイル全体を即時関数で囲った場合、
その中にある関数myfunc(){......}はどうやって呼び出せば良いのでしょうか？
囲う前なら普通に
myfunc();
で実行出来ていたわけですよね。囲った場合の呼び出し方が分かりません。
843:Name_Not_Found
15/06/27 13:48:42.32 .net
>>828
外から呼び出したいものだけは
window.myfunc=function(){}
みたいなで定義しておけば
普通にmyfunc()でいける
844:Name_Not_Found
15/06/27 13:50:12.13 .net
>>828
>その中にある関数myfunc
その関数を外から（他の js ファイルなどから）呼びたい場合は
その即時関数の中で、
即時関数の外で定義された変数にその関数を代入するしかないだろう
845:Name_Not_Found
15/06/27 15:37:02.43 .net
>>828
var globalVar = (function () {
return 'hoge';
}());
(function () {
this.globalVar = 'hoge';
}.call(this));
846:Name_Not_Found
15/06/27 18:37:14.03 .net
普通にブロックスコープとletとvarを使えばいいだけのこと
847:Name_Not_Found
15/06/27 18:38:40.84 .net
>>832
じゃあそれらを使った解決方法を書けよ。
意味もわからず適当な事を言って、自己満足するのはやめなさい。
848:Name_Not_Found
15/06/27 18:53:22.88 .net
(function(global){
global.myfunc=function (){}//グローバルな関数
function myXXX(){}//ローカルな関数
var xyz=200;//ローカル変数
global.abc=5000;//グローバル変数
}(window))
849:Name_Not_Found
15/06/27 19:17:00.47 .net
グローバル変数をなるべく減らすって
考え方は間違っちゃいないけど、
そこまで来たならRequreJSとかを使うべきだろうな。
開発時は細かくファイルを分けて、
リリース時はファイルを結合して
1つにするとか出来るよ。
850:Name_Not_Found
15/06/27 19:32:37.65 .net
>>833
自分が理解できないっていうんなら下手にお伺いを建てるのが普通
他人に回答してほしくないのなら自分が完璧な回答してあげればいいのに
えらく自分勝手だねキミ
851:Name_Not_Found
15/06/27 19:34:48.11 .net
>>836
ほらね。詳細書けと言われたら書けないんだよ。こいつ。
自分が適当な事を書いてるってわかってるんだろうねｗ
852:Name_Not_Found
15/06/27 19:41:37.54 .net
>>828
素直にRequireJSを使った方がいい。
軽くサンプルを書くと、
[module.js]
define(function() {
var value = 1;
function foo() { alert(value) }
return {
foo: foo
}
});
[main.js]
require(['modules'], function(Module) {
Module.foo()
});
こんな感じで、ファイル内でグローバル相当なvalueを作ったり、
別のファイルからfoo()を呼び出したりできる。
853:Name_Not_Found
15/06/27 19:45:45.14 .net
一応俺がRequreJSを使ってるから、RequireJSといったけど、
Webpackとか言うのもあるらしい。
こっちのほうが優れているように見えるが、普及したのかな？
854:825
15/06/27 20:28:02.21 .net
皆さん、詳しいレスありがとうございます。
いろんな方法を教えて頂いたので一個ずつ試して、自分に合う方法を
見つけたいと思います。
855:Name_Not_Found
15/06/27 20:36:44.85 .net
この板もとりあえずID出すべきだな。
856:Name_Not_Found
15/06/27 21:13:34.87 .net
Browserifyとか
857:Name_Not_Found
15/06/27 21:42:05.40 .net
Browserifyっていうのもあるのか。
RequireJSは、RequireJSとして完成しまくってて
成長してないから、新しいのがほしいんだけど、
将来性がないのも困る。
858:Name_Not_Found
15/06/27 23:30:22.55 .net
webサイトに自分のfacebookページに投稿した内容を取得、
jqueryにて表示したいです。
新着情報のところにfacebookの投稿を取得、表示する感じです。
以前はrssやatomを取得できましたが現在はできず、
graphを利用するしか無いと思うのですが、
feedの取得にはアクセストークンが必要となります。
実際表示させるまではできているのですが、
アクセストークンをそのままコードに書き込むのは
セキュリティ的に問題ある気がするのですが問題ないのでしょうか？
ご指摘と、他によい方法があればご教示ください。
もし質問するのに他に適切な場所があれば誘導をお願いします。
859:Name_Not_Found
15/06/27 23:48:15.31 .net
>>844
アクセストークンの中にはシークレットキーとかいうのも含まれるんだよね？
だれでも見れるJavaScriptの中に埋め込んだらだめじゃないのかな？
サーバー側のアプリ（PHPなど）の中に埋め込んで
取得したものを、動的にHTML生成するって感じだと思う。
そもそも、あなたの情報をあなたが勝手に公開するのは構わないけど、
あなたの情報にアクセスできる方法を、あなた以外に渡す必要はないわけだし。
860:Name_Not_Found
15/06/28 13:59:37.20 .net
URLﾘﾝｸ(stackoverflow.com)
の
//----------------------------
function Person(){
this.name = "Peter";
Person.counter++;
alert(Person.counter);
}
Person.counter = 0;
var p1 = new Person();
var p2 = new Person();
//----------------------------
なんですが、
this.name
Person.counter
が良く分かりません。
newで作ったp1では p1.name で取り出せますが、
Person.nameは見つかりませんでした。
一方、
Person.counterはありますが、
p1.counterは見つかりませんでした。
こういう理解で良いでしょうか？
newで作成したインスタンスp1ではthis.xxxメンバ変数が作られ、p1.xxxで使える。
newしなくてもPersonという実体は一個作られる。
そのメンバ変数はPerson.xxxで扱える。
Person.counterのcounterっていう変数の宣言は、Person.counter = 0;で初期化と一緒にやっている。
で良いですか？
861:Name_Not_Found
15/06/28 17:16:30.17 .net
>>837
詳細も何も
{
let filelocal_var = hoge
var global_var = fuga
}
ということなだけなんだが
>>832以上に説明することあるか？
862:Name_Not_Found
15/06/28 17:35:20.22 .net
>>847
古い話題より846もお願いします。よろしく。
863:Name_Not_Found
15/06/28 18:05:38.34 .net
>>847
>その中にある関数myfunc
はどうなりましたか？ｗ
その例だけの話しなら即時関数使ってできるんですよ。
そんな答えは求めていません。一周遅れですか。
var global_var = fuga
(function () {
var filelocal_var = hoge
})()
864:Name_Not_Found
15/06/28 18:22:37.22 .net
edinetのxbrlデータを自動取得しようと考えているのですが、
何か良い方法はありませんでしょうか？
抽象的な質問で申し訳ありませんが、お答えいただけますと幸甚です。
865:Name_Not_Found
15/06/28 18:41:15.11 .net
自動的にedinetのxbrlデータを
取得すればいいのでは？
866:Name_Not_Found
15/06/28 21:48:45.30 .net
javascriptって、簡易言語って書いてあるが、全然簡単じゃないよな
javascriptを勉強して5年だが、やっと、日経ソフトウェアに載ってるJavascriptの
記事を読んで理解できるようになった。ここまでくるのに、時間食いすぎた。
867:Name_Not_Found
15/06/28 22:04:54.88 .net
プロが使うものに簡易なものなんてあるわけなかろう？
プロが欲しい機能が搭載されてるってことなんだから。
簡易言語っていうのがあるとすればプロは使わない言語だよ。
あと日経ソフトウェアは初心者向けだからな。
がんばれよ。
868:Name_Not_Found
15/06/28 23:36:29.44 .net
JavaScriptは取っ組みやすいが、奥が深すぎる言語であると思ってる
869:Name_Not_Found
15/06/28 23:38:41.81 .net
それはどんな言語でもそうだ。
奥が浅いのはCOBOLぐらいなもんだろ。
870:Name_Not_Found
15/06/29 04:07:12.16 .net
５年経ってやっとわかってくるのは、JSが奥深いからではない。
日経の記事でそこまで奥深い所を扱ったものはない。むしろJSerなら抑えておきたい基本の部類だ。
良い入門資料が少なく、それまでなんとなくやとりあえずの理解を積み重ねて来た結果そうなるだけ。
オブジェクトは参照型だと説明する、プロトタイプベースを放っておいて継承に突っ込む、
暗黙の型変換について（==からDateのことまで）まとめて説明しない、その他諸々。
結局はECMA仕様書を読むしかない。
871:Name_Not_Found
15/06/29 07:46:08.02 .net
仕様書よんだって、言語仕様に詳しくなるだけ。
それだけじゃ 実用的なアプリは作れない。
872:Name_Not_Found
15/06/29 08:17:50.73 .net
>>852は「作れるようになった」ではなく「理解できるようになった」
理解するために仕様書を勧めるのは間違いではないだろう
5年もかけて理解したのなら勉強法が誤っているとしか思えない
873:Name_Not_Found
15/06/29 11:08:07.76 .net
明らかにネタだからｗ
874:852
15/06/29 18:41:40.26 .net
現在作って公開してる、webアプリケーションは1つあって201X年から公開してます
uploaderを作りました。使ったのは、
javascript、html5、php、mysqlを使いました。
作った当時は継承やクロージャが理解でなかったので、継承もクロージャ
も使ってなく、自分でもコードが読めず、バグだらけで、今思えば酷い出来してた
2chで晒したときは、「～スレの住民なら3日で作れる」など言われました。
875:Name_Not_Found
15/06/29 18:59:10.86 .net
>>858
ある程度理解したら仕様書読むしか無くね
あのサイ本だって仕様書の内容噛み砕いたようなもんだし
876:Name_Not_Found
15/06/29 19:19:57.34 .net
なんだかんだ言ってここはJSerのたまり場だから安心する
他の質問サイトに行くとJava厨だかC厨だかがクラスだprivateだ
JSはオブジェクト指向言語ではないだなんだと全くJSを理解してない発言が並んで嫌になる
ほんとおまいら最高だわ
誇っていいぞ
877:Name_Not_Found
15/06/29 19:36:09.72 .net
msのtranslater apiを使ってテキストを英語にしたいんですがJavaScriptだけで実装している簡単なサンプルを見つける事が出来ません。どこかに有りませんか?
翻訳さえ出来ればms以外でも構いません。
878:844
15/06/29 19:39:13.03 .net
>>845
遅くなりましたが、ありがとうございました。
phpで表示できるようにしてみます。
879:858
15/06/29 20:15:07.27 YIb7Husk.net
>>861
>858から変わらず、仕様書を勧めているのだが…
880:Name_Not_Found
15/06/29 20:28:04.68 .net
中級者に仕様書を読んで重要な点を１から１０まで理解しろというのは無理があるが
５位までは読み取れるはずだ。
881:Name_Not_Found
15/06/29 21:28:40.44 .net
仮に仕様書の内容を100%理解したとして
それはアプリを作るための知識の50%にも満たない。
882:Name_Not_Found
15/06/29 21:39:09.44 .net
>>856は作る以前に理解してない段階だと思うなあ
理解するだけでは作れないけど、理解しなければ作れない
理解は必要条件だよ
883:Name_Not_Found
15/06/29 21:46:03.47 .net
作るために必要な知識は、仕様書に書いてあることじゃない。
仕様書なんて1割程度、ほんの基本さえ知っていれば十分。
884:Name_Not_Found
15/06/29 22:34:04.74 .net
理解できない人に作り方を教える無意味さ
885:Name_Not_Found
15/06/29 23:39:38.01 .net
for内にスクロールイベント置いた場合正常に処理してくれますか？
また、置ける場合forの処理ってどうなるんですか？
886:Name_Not_Found
15/06/30 01:24:02.01 .net
JavaScriptが使えないクライアントは何％ぐらいいるのでしょうか？
・パソコン～％
・ガラケー～％
・スマートフォン～％
って風に答えてくれると嬉しいです。
887:８７２
15/06/30 02:21:47.93 .net
つか、読者参加型のサイトで、
読者に情報を投稿してもらおうと思っています。
その場合、投稿フォームをJavaScriptだけで作っちゃっていいものなのでしょうか？
たとえば、アマゾンで商品購入のさいにJavaScriptを使ってるけど、
JavaScriptが使えない人用のページも用意されているのでしょうか？
888:Name_Not_Found
15/06/30 03:33:02.35 .net
ブラウザのJavaScriptの機能を、オフにして、
そのサイトを見てみれば？
889:Name_Not_Found
15/06/30 05:10:22.30 .net
情報投稿サイトでX-Requested-With無しなんて俺ならディプロイしない。特にその情報が画像や動画ならJSオフを拾ってあげるなんてあり得ない。
要するにJSオンリーは最低限の必須事項だと思う。もうとっくにそんな時代だと断言できる。
890:Name_Not_Found
15/06/30 05:15:21.47 .net
>>863
おもむろに検索したら本家にコピペしてすぐ動きそうな例があっさりごろごろ見つかった。だから何が疑問なのか分からない。丸投げ？
891:８７２
15/06/30 05:36:23.12 .net
>>874
了解しました。
>>875
おお、ありがとうございます。
> 要するにJSオンリーは最低限の必須事項だと思う。もうとっくにそんな時代だと断言できる。
この言葉をまってました。
892:Name_Not_Found
15/06/30 05:38:32.20 .net
>>876
本家のサンプルってC＃じゃあないの？
JavaScriptのサンプルって本家に無いだろ。
893:Name_Not_Found
15/06/30 07:53:26.81 .net
今やJavaScriptが動かない環境は気にしなくていい。
何故ならそれはデメリットを理解した上で何らかの理由によりあえてOFFにしてる人だから。
勿論あえてJSがOFFだと機能しないように作ることはない。
だがそんなことよりも動くけれど機能が限定されている環境をどう相手するかを考えたほうが有意義。
例えばau以外のフィーチャーフォンは昔からJSが利用可能だが、ES3相当なのと、Canvas等のHTML5周りのAPIは皆使えない。
まあこれは最低レベルの部分を見た話だが、そこまで行かなくとも考慮事項はたくさんある。
なんとかPEで頑張りたいところではある。
894:Name_Not_Found
15/06/30 11:57:17.37 .net
あんまり良い例ではないかも知れませんが、
var obj = {
data1: [
{ sub11: [1, 2], sub12: [3, 4], },
{ sub21: [5, 6], sub22: [7, 8], },
]
}
みたいなobjectが有った時に、
var data1 = obj['data1'];
var sub2X = data1[1];
var sub22 = sub2X['sub22'];
var num8a = sub22[1]; // a
var num8b = obj['data1'][1]['sub22'][1]; // b
aみたいに、変数varを何個も使うのと、bみたいにするのとで、
処理速度に違いなどありますか？
895:Name_Not_Found
15/06/30 12:04:11.64 .net
>>880
同じ階層のプロパティを何度も呼び出すなら変数にキャッシュした a の方が速い
プロパティアクセス演算子はプロトタイプチェーンを辿るので基本的に遅い
896:Name_Not_Found
15/06/30 12:20:28.44 .net
何度も繰り返されてきた議論だが、結論としては最適化が十分に効くと仮定した場合速度差は生じない
897:Name_Not_Found
15/06/30 12:29:54.80 .net
そもそも、速度は実装依存だから実際に計測してみたいとわからない
仕様上は遅い、実装上なら計測するしかない
最適化なんて実装依存だからな
898:Name_Not_Found
15/06/30 12:31:47.68 .net
最近のCPUはアグレッシブに投機やキャッシングするから、
コンパイラが多少違うコードを吐いてもどっちが速いかはわからん。
899:Name_Not_Found
15/06/30 13:19:23.43 .net
CPUもそうだが、ブラウザによって違うし、同じブラウザでもバージョンが異なれば速度も変わる
900:Name_Not_Found
15/06/30 20:22:23.88 .net
CPUレベルで考えたそれこそFirefoxのようなシングルプロセス環境だと、
コンテキストスイッチが発生しない限りで別サイトのコードを巻き込んで最適化が発生する余地もある。
ベンチマークも信頼できなくなる。
901:Name_Not_Found
15/06/30 20:48:25.16 .net
複数のブラウザと異なるバージョンのブラウザを用意して一つ一つ検証するのが面倒だから仕様上、速くなることがわかっているコードは積極的に使うようにしてる
ブラウザがアップデートされる度に検証し直すのは面倒くさくてかなわん
902:Name_Not_Found
15/06/30 21:24:24.42 .net
そういう場面が存在することは分かるが、
少なくとも上の質問はそういうクリティカルな物ではないだろう。
ゲームとかで本当にデータアクセスを高速化しようと思ったら、
最終的に変数やオブジェクトを極力使わずasm.jsのようにArrayBufferをメモリに見立てて
903:利用する形になる。 そういう段階まで行けば確かにエンジンのバージョンによる様々な最適化のかかり具合も重要になってくる。 まあswitch vs if-else程度がギリギリ一般的にどちらがどういう時に高速かを調べられる限界だが。
904:Name_Not_Found
15/07/01 00:03:00.64 .net
質問です
CSSファイル内にjavascriptの記述を書きたい場合、方法ありますか？
905:Name_Not_Found
15/07/01 00:05:35.22 .net
ないし、やったらだめ
906:Name_Not_Found
15/07/01 00:18:57.86 .net
>>889
そういう案もあったが今はCSSで定義した変数をJSからオーバーラップする方向性で進んでる
URLﾘﾝｸ(dev.w3.org)
907:Name_Not_Found
15/07/01 08:25:09.97 .net
lodashの3.10がでてるね。
URLﾘﾝｸ(lodash.com)
908:Name_Not_Found
15/07/01 10:22:05.63 .net
この頻度で更新されるたびに話題にされたらたまったもんじゃないな
URLﾘﾝｸ(github.com)
909:Name_Not_Found
15/07/01 14:26:16.50 .net
lodashの最大の欠点はlodash（_）であるということ。
本来はES7のAbstract Referencesとライブラリのインポートでしたいことである。
910:Name_Not_Found
15/07/01 19:09:52.00 .net
java scriptファイルってwebサーバーに置いたら中身丸見えですよね。
プログラムの中身を盗まれないようにする対策って有りますか？難読化とか出来るのかな？
911:Name_Not_Found
15/07/01 20:05:36.62 .net
サーバサイドで処理しろよ
jsにこだわる必要もない
912:Name_Not_Found
15/07/01 21:11:58.74 .net
>>896
忍者HPの無料サーバーで自作のJSのアプリ作っているのですが、
サーバーサイドっていうのは、この忍者HPでも可能でしょうか？
たぶんダメですよね。
913:Name_Not_Found
15/07/01 21:30:19.30 .net
駄目です
914:Name_Not_Found
15/07/01 21:36:29.37 .net
>>894
> 本来はES7のAbstract Referencesとライブラリのインポートでしたいことである。
まったくもってその通り。
なんでさっさと標準化してしまわないのか？
仕様なんて誰が考えても大差ないようなものなんだから、
github上で一関数ごとにIssue作ってささっと仕様を決めてしまえば、
一ヶ月程度でできあがるはずだろう。
ES7の問題点は仕様が固まるまでに数年もの時間がかかるってことだ
915:Name_Not_Found
15/07/01 21:58:30.48 .net
>>898
やっぱりダメですよね。
無料サーバーでサーバーサイド出来るなんて無いですよね。残念。
916:Name_Not_Found
15/07/01 23:58:17.72 .net
>>895
昔どっかのサイトがjsをわざわざエンティティ化しているの見たことあるけど、
どうせすぐ変換できるから無駄。
Googleのソースみたいに圧縮すれば読む気は失せるけど
917:Name_Not_Found
15/07/02 00:34:35.96 .net
>>901
エンティティ化って何ですか？
918:Name_Not_Found
15/07/02 14:59:47.32 .net
圧縮してあっても殆ど変数名の短縮で
メソッド名とかは割りかし残るから慣れればさほど問題ない
919:Name_Not_Found
15/07/02 23:46:53.92 .net
慣れちゃったのか…
920:Name_Not_Found
15/07/03 09:31:47.36 .net
>>900
いたるところにある
921:Name_Not_Found
15/07/03 12:39:44.91 .net
コード整形ツールを使えばインデント整形できるからな
変数名の短縮は読みづらくなるが、読めなくはない(必要であれば読む)
922:Name_Not_Found
15/07/07 10:44:19.38 .net
スクリプト専門スレなのにすいません。
301リダイレクトで質問なのですが、他に目ぼしいスレがなくて、ここで質問させてください。
トップページは
URLﾘﾝｸ(old-site.com)
を
URLﾘﾝｸ(new-site.com)
に301リダイレクトをする方法は分かったけど、例えば旧サイトでcategory1にあった物を新サイトで、サイトURL移転と同時にドメイン以下の名称を変えて301で一気に飛ばせないのかな？
こんな感じ↓
URLﾘﾝｸ(old-site.com)
を
URLﾘﾝｸ(new-site.com)
教えてくれた人にアマゾンギフト券（e-mail)1,000円分を差し上げます。
アマゾンに登録してある事と、先着１名なので、２人目以降はすいません。
このメールに下さい
riengl@00mails.com
923:Name_Not_Found
15/07/07 11:43:23.38 qlgurl5N.net
昨今のブラウザだと循環参照してもリークしないの？
前スレみると決着ついてないんだけど
924:Name_Not_Found
15/07/07 11:45:42.12 7Cb6g2mZ.net
JavaScriptも使って以下のような仕様のページを作りたいです。
①ユーザーがページに来ると、モーダルウィンドウAが出る。
②モーダルウィンドウA上のボタンを押すとウインドウが消え、音楽がループで流れ始める。同時にカウントがはじまる。
③ページ上のボタンを押すと、流れていた音楽が消え、別の短い音楽（チャイム音）が一度流れ、カウントが止まり、モーダルウィンドウBが表示される。
④モーダルウィンドウB上のボタンを押すと、カウントした秒数とそのページのURLの文字列をふくむツイートができる。
このような仕様です。
HTMLとCSSでデザインはできようになったので、今度はJavaScriptを勉強してこのような事ができるページを1枚つくって公開するつもりです。プログラムの学習は初めてではないです。
JavaScriptをひと通りざっと勉強してから作業に入るつもりですが、特にどの部分を勉強すればこのようなページを作れるか、簡単なヒント等をもらえたら嬉しいです。
よろしくお願いします。
925:Name_Not_Found
15/07/07 11:56:42.69 .net
>>909
ウインドウの出し方はいろんな方法が有るのでその辺から試せば？
926:Name_Not_Found
15/07/07 14:01:35.84 7Cb6g2mZ.net
>>910
レスありがとうございます。
Bootstrapを利用するのでモーダルウィンドウはそれを利用するつもりでいますが、
他のウィンドウの出し方も試して検討してみます。
927:Name_Not_Found
15/07/07 20:54:08.81 .net
>>909
それはどこまで行っても「物による」から決着はつかない。
一応ネイティブCGシステムと-JSシステム間のバインディングや、
弱参照ハックによりレガシーなDOM API周りではリークは無くなっているが、
新しいAPIが出る度に例えばAudioBufferがリークしたりというようなことがままある。
928:Name_Not_Found
15/07/07 20:54:35.98 .net
×909
○908
929:Name_Not_Found
15/07/07 22:39:47.08 .net
>>911
> Bootstrapを利用するので
死ね。ここはライブラリの話題は禁止だといっただろ
930:Name_Not_Found
15/07/07 22:41:30.72 .net
>>908
> 昨今のブラウザだと循環参照してもリークしないの？
jQueryを使っている限り、昔のブラウザも含めて問題無いという結論だったはず
931:Name_Not_Found
15/07/07 22:42:25.57 .net
>>914
と童貞がほざいてます。
932:Name_Not_Found
15/07/07 22:54:07.87 .net
angularjs.org 1.4.2リリース
URLﾘﾝｸ(angularjs.org)
933:Name_Not_Found
15/07/08 06:26:38.23 S3u9jPpK.net
>>912
なるほど
メモリ効率的にも使わないほうがいいみたいですね
>>915
jqueryは毎回nullぶち込んでるから当たり前じゃ？
934:Name_Not_Found
15/07/08 18:08:05.18 e8Mh7Wfi.net
>>914
たかがCSSフレームワークに何いってんだこの気違い童貞
935:Name_Not_Found
15/07/08 22:31:28.44 .net
>>918
nullを入れてるからじゃなくて（別の理由で入れている所はもちろんあるが）
クロージャーを使った部分で JavaScriptの外の世界との循環参照にならないように
間に一層かまして、断ち切ってるからだよ。
つまりDOM（JavaScriptの外）とクロージャー（JavaScript）が循環参照にならないように
DOM（JavaScript）とjQuery（DOMの参照にクロージャー使っていない）＝問題ない
jQuery（JavaScript）とクロージャー（JavaScript）＝問題ない
このようにjQueryが問題になる循環参照を断ち切ってる。
936:Name_Not_Found
15/07/08 22:32:05.44 .net
ここってCSSフレームワークの話題オッケーなんですね。
937:Name_Not_Found
15/07/08 22:38:02.17 .net
オッケーですよ
回答する人がいるかは分かりませんが
938:Name_Not_Found
15/07/09 00:37:16.24 .net
>>920
jQueryもJavaScriptの世界なんだが……
939:Name_Not_Found
15/07/09 00:41:54.13 .net
>>923
はい。だからjQueryは「安全な方法」で実装しているから
問題ないのです。
940:Name_Not_Found
15/07/09 00:45:14.38 .net
なぜ常に安全とわかるのですか？
941:Name_Not_Found
15/07/09 00:46:20.77 .net
>>921
>>1の1行目を読めばおっけーではない事は明らかだけどな
942:Name_Not_Found
15/07/09 01:02:12.48 .net
>>925
横から口出すが、jQueryの循環参照対策は過去ログ参照
ｽﾚﾘﾝｸ(hp板:550-番)
明らかにスレ違いの話題だから以降はライブラリスレでやってくれ
ｽﾚﾘﾝｸ(hp板)
943:Name_Not_Found
15/07/09 01:16:05.60 .net
>>921
単語が出ただけでOKだと信じる短絡的バカ
944:Name_Not_Found
15/07/09 01:25:10.09 .net
>>921は>>919の間抜けな回答をあぶりだす為に答えのわかった質問してるんだろう
945:Name_Not_Found
15/07/09 01:31:12.85 .net
こりゃ次スレも禁止でケテーイだね
946:Name_Not_Found
15/07/09 01:33:34.71 .net
そういうのもいいから、もう仲良く行こうぜ
数年前と違ってどうせいつも決まったメンバーしか来ない過疎スレなんだから
947:Name_Not_Found
15/07/09 02:47:15.09 .net
>>929
自演までするなんて、本当ここ痛い奴多すぎだろ
948:Name_Not_Found
15/07/10 08:29:48.72 .net
また、荒らしが新スレを立ててるね
ｽﾚﾘﾝｸ(hp板)
949:Name_Not_Found
15/07/10 20:06:05.70 .net
このページの3つ目のリークモデル（クロスページリーク/DOM挿入順序リーク)で
何がリークするのかいまいち分からないのですが、どなたか分かる人居ますか？
URLﾘﾝｸ(msdn.microsoft.com)(v=vs.85).aspx
それから、このドキュメントは古い(2006.02)のですが、今もこれはリークするのでしょうか？
対象はchromeとFFの最新版だけでいいです。
こちらで試したところ、chromeでは小修正で動かせましたが、リークはしていないように見えました。
ただし docmuent.create("<div onClick='foo()'>") が出来ず、
document.create('div');parentDiv.onclick= と分解したため、
> スクリプトがアタッチされた状態で DOM 要素が作成されることです。
に該当せず、無効化してしまっている可能性があります。
MSDNなのでIEでも試してみましたが、私がIEに不慣れなため、動かせませんでした。
見たところ、子DOM要素が親DOM要素のスコープを保持する必要がある時に起こるようですが、
これが必要となる仕様なんてありましたでしょうか？
950:Name_Not_Found
15/07/10 20:30:19.87 .net
> 私がIEに不慣れなため、動かせませんでした。
え？ なんで？
951:Name_Not_Found
15/07/11 04:33:24.52 .net
>>見たところ、子DOM要素が親DOM要素のスコープを保持する必要がある時に起こる
記事とこのスレを100億回読み直せ
子DOM要素が親DOM要素の参照を持つのは当たり前だし、そこに書いてあるのはこのスレの上で議論されたことに過ぎない
952:Name_Not_Found
15/07/11 20:21:31.83 .net
MSDNだろうが個人ブログだろうが、ことJSに関して10年前に書かれた記事の内容が今も通用することなんてほぼない
953:934
15/07/11 23:05:41.24 .net
しかし未だに循環参照はリークするんだろ？
勘違いしている奴が多いと思うが、あれはCから見ればブラウザのバグでしかない。
ルートから辿れないノードに対してDOMとJSHeapを同時にGCすれば済むだけの話だ。
むしろJavaScriptをやるようになってブラウザのポンコツ加減に驚いた。
removeEventListenerだって本来はGCできるがしていない。これも手抜きでしかない。
実装上、自分でremoveした方が速く動く。
だからユーザー側にタイミングを委ねる仕様を残すのはいい。
しかしブラウザが落ちるようなところまで来たら、
低速でも完全性のあるGCを動作させて落ちるのを回避しないとプラットフォームとしては使えない。
JavaScriptを書く連中もそうだが、ブラウザを開発する側も「再起動すればいい」という甘えがある。
954:Name_Not_Found
15/07/12 00:21:36.83 .net
そうですか。
質問どうぞ。
955:Name_Not_Found
15/07/12 00:36:44.61 .net
>>938
今はもうしないって何度も言われてるだろ
しつこい
956:934
15/07/12 01:10:18.52 .net
>>940
それ本当か？
循環参照の話はググレば山ほど出てくるし、記事も最近のも多いから、実際にリークするんだと思うぞ。
JSHeapだけの循環参照は最初からリークしない。
DOMとJSHeap間の循環参照がリークする。(これはGCを別々にやっているから。だから同時にやれば直る。)
よくあるBadCaseとして書かれているごく単純なのは無駄なクロージャを作らなくなったからリークしなくなったらしい。
removeEventListenerなんて最初から要らない仕様にするべき。(DOMをGCしたときに同時にGCすればいいだけ）
ただ、確かに対策は簡単なので、対策されているかもしれないが。
まあいいや、俺の本筋はそこではないので。
957:934
15/07/12 01:11:06.00 .net
934の質問は以下ね。
・DOM挿入順が速度最適（ツリーを完成させてから最後に挿入）の場合は今でもリークするのか？
・親DOMのスコープを子DOMが保持することが仕様として必要なのか？
(仕様としてこれが必要である場合は、今でもリークするし、回避する手段も実装側にはない。
ただ、これはよく知られた速度最適化に反するので、実装だけの問題なら既に修正されている可能性が高い。)
答えられる人が居たらよろしく。
あとついでに、
・chromeのタスクマネージャのJavaScriptメモリも増えず（ずっと20MB(ライブ10MB)程度）、
・chromeのDevToolのProfilesでSnapShotを取っても大して増えず(5MB-10MB程度）、
・外部のProcessExplorerで見たVirtualSizeも800MB程度でほぼ一定なのに、
chromeが落ちるのだが、何かピンと来ることがあれば。
なおOSの仮想メモリは十分に余っている状態。
ある程度の時間は確実に動き、その後のある程度の時間のうちに落ちるので、リークだと見ていたが、
Virtualが800MB程度だから、何かのリソース枯渇かとも思えてきた。ただ、いずれにしてもよく分からない。
これも気長に待つので、答えられる人がいればよろしく。
958:Name_Not_Found
15/07/12 01:39:09.96 .net
オブジェクトをnewして配列に入れていく
処理をするとメモリ使用量がどんどん増えていきます。
やっぱりメモリリークは有るようですね。
959:934
15/07/12 01:52:35.48 .net
>>943
それはGCしてないだけ。
chromeのDevToolのTimelineにあるゴミ箱ボタンを押せば手動でGCを起動できる。
押せば減ると思う。
減らないようなら、ここにソースを晒せば誰かが原因を指摘するかも。
960:Name_Not_Found
15/07/12 01:57:55.26 .net
ちなみにFFなら about:memory でメモリプロファイルが見える。
verboseにすれば1バイト単位で計上してくれる。
そこにGCボタンもある。
IEは使ってないので知らない。
961:Name_Not_Found
15/07/12 02:36:12.87 .net
>>944
こんな感じで再現するよ
var a = [];
while(true) {
a.push({})
}
すごい勢いでメモリがリークしていく。
962:Name_Not_Found
15/07/12 06:45:33.62 .net
>>946
それはリークではなくて、実際に使っているだけ。
リークというのは934の例を見てくれれば分かるが、
どこからもどうやっても参照できないのにメモリが解放されない場合のことを言う。
てか申し訳ないが、今の君が僕の質問に答えるのは無理だ。
僕の質問に付随する内容として僕が積極的に回答するのはここまでにしておく。
君自身の質問としてなら続ければいいけど、さすがにそれだと無視されると思う。
963:Name_Not_Found
15/07/12 08:02:18.24 .net
>>946
まさかこんなコードじゃないだろうよと思っていたコードがそのまま出てきて、どこから突っ込んでいいのやら…
964:Name_Not_Found
15/07/12 17:25:44.77 .net
>>942
結論から言うとしない。
URLﾘﾝｸ(steps.dodgson.org)
965:Name_Not_Found
15/07/12 19:13:24.98 .net
>>949
ありがとう。
循環参照は全て対策されているということについては了解した。
(ただそれは>>938,941に対する回答だ。>>942に対しての回答もあればよろしく)
一応コメントを残しておく。
> GC つき言語 (JavaScript) のコードと C++ で書かれたコードとの連携は最たる面倒の１つ。 たとえば WebKit の DOM は C++ で実装されており、 C++ のオブジェクトは JavaScript 処理系の GC に追跡されていない。
この部分が擁護的で間違っているが、V8はC++で書かれているので、実際はJavaScript側もC++で扱っている。
言語間で連携する必要なんてない。最初から全部C++だ。
一般的にヒープ内部構造まで仕様で規定することはないので、JavaScriptもそうだとするなら、
コードは全てC++でJavaScriptHeapも好きな構造に出来るので、それが扱いづらいのなら実装が悪いだけ。
> 世代をまたぐだけでも大変なのに、更に言語をまたげなんて無理難題にも程がある。
ここからも筆者が勘違いしている事が分かる。言語は跨がない。
しかし構造からしてV8はDOM以外用にチューニングされている。ブラウザ用ではない。
DOMが最初からあるのなら、DOMとJSHeapは混ぜてしまったほうが実装しやすいはず。
ここら辺は
> ふつうの解決
に書いてあるとおり。
966:Name_Not_Found
15/07/12 19:23:40.14 .net
> V8はC++で書かれているので、実際はJavaScript側もC++で扱っている。
そんなわけないｗ
例えばRuby実行エンジンはC++で書かれているが
Rubyは当然Rubyだ
967:Name_Not_Found
15/07/12 19:32:59.43 .net
>>950
DOMとES5は別々に仕様が策定されているわけで仕様を実装する立場からしたら、ScriptエンジンとDOMエンジンを分けたくなる気持ちはわかるけどな
あなたのいう理想を実現するなら JavaScript API 関連仕様全てをひっくるめて一つの仕様を策定するところから始めないといけない
ある一つの仕様に変更が加えられるたびに「たった一つの仕様」を全て見直して仕様化し直すコストがかかる
> ここからも筆者が勘違いしている事が分かる。言語は跨がない。
あなたのいう理想は「自分で一から仕様を作って自由に実装できるコード」に限定されているように見える
分化された仕様から実装する場合には効率が悪すぎると思うんだけど、どうだろうね
968:Name_Not_Found
15/07/12 20:02:54.30 .net
>>951
お前は付いて来れていない。
JavaScriptからはJavaScriptHeapを直接扱えない。set/get等ができるだけだ。
当たり前だが一般的にGCが出来る言語はGC部分の直接操作はできない。
オブジェクト志向的説明の方が分かりやすいかもしれない。
JSHeapはJSインタプリタから見るとオブジェクトだ。
つまり、JSHeap内部構造はJSインタプリタからは完全に隠蔽されており、set/get等のメソッドが提供されているだけだ。
JSHeapオブジェクトはC++で記述されており、内部構造も動作も自由に書ける。
これで分からない奴にここで説明しきるのは無理なので、この件についてもここで打ち切る。
969:Name_Not_Found
15/07/12 20:37:54.28 .net
>>952
> DOMとES5は別々に仕様が策定されている
なるほど、そういうことか。了解した。
> 分化された仕様から実装する場合には効率が悪すぎると思うんだけど、どうだろうね
これはその通りだ。
DOMとECMA、ついでにCSSの仕様が非同期で更新されるのなら、
それぞれのコードが干渉しないようにしておかないと面倒になる。
ただ、V8を書く時には最初からDOMもJavaScriptもある程度仕様が固まっていたはず。
そこでDOMを付け足すような構造にするのは、DOMを最初から捨てているように見える。
(Nodeとかだとそれでもいいのだが）
というか、JSオブジェクトはツリー構造を取れるから、DOMも普通にJSHeapに載せられるはず。
逆に、JSHeapも構造を規定されていないし、V8のケースならそれぞれ単品で浮いている感じだから、
C++のヒープ構造をJSHeap側が踏襲する手もあったはず。
なぜわざわざ難しくなるようなアプローチをするのかがよく分からん。（歴史的経緯があるのだろうけど）
コードが混ざるのはまずいが、実行時のHeapは共有で一つでも問題ないと思うのだが。
GCに関しては、「ルートから辿る、遅いけど完全なGC」は今のV8の物より断然簡単に実装できる。
だから実装されていないのが謎だったのだが、
参照カウンタ方式の「速いけど完全にするには難しいGC」を実装しきる方向でやっているというのは分かった。
しかし落ちる間際位は「遅いけど完全なGC」を実行してくれよというのが俺の気持ち。
970:Name_Not_Found
15/07/12 23:34:34.49 .net
昔のIE+ActiveXのメモリリークを不完全に理解した気になったやつらがいまだにC++とjavascriptがーとかいってるのはひどく残念
971:Name_Not_Found
15/07/13 00:34:33.35 .net
>>949
質問者ではござらぬが、このブログがあまりにも凄いのでつい。これたいへんな文章量だすな。分かりやすい上に例示が秀逸。書かれたこのお方を尊敬しますし見つけたあなたにも敬服いたしました
972:Name_Not_Found
15/07/13 00:57:56.91 .net
それは誠でござるか
我もとくと拝見するでござる
973:Name_Not_Found
15/07/13 04:28:19.94 .net
>>950
言語云々というよりV8はあくまでV8内の閉じられた世界だけを管理するもので、
当然組み込み先の他のGCシステムまで介入することはなかった。
汎用的なエンジンだからあまりBlinkに特化するわけにもいかないから、
汎用的な連携APIを用意してマシになったということだ。
また、DOMで子が親を参照するのは当然必要で、parentNodeがまさにそうだ。
974:Name_Not_Found
15/07/13 04:31:42.82 .net
DOMはJSのためだけのものではないし、逆も�
975:ﾜた然り。 V8もBlinkのためだけのものではないし、Blinkも当然Dartなど 今後他のものとも連携が取れないといけないかもしれないのであまりに密結合にすることはできない。
976:Name_Not_Found
15/07/13 19:49:41.40 .net
>>954
あなたのいうJSHeapとは何？
- オブジェクトのツリー構造
- ブロトタイプチェーン
- スコープチェーン
- DOMのツリー構造
>>958もいってるけど、オブジェクトとDOMでは親を辿るAPIが違う
そもそも、DOM要素ノードはオブジェクトでもあるわけだから同時に2つのheapが発生することは避けられない
ESにはその他にも様々な参照構造があり、それぞれにheapが存在するものと想像する(実際は知らないけど、上記全てを一つのheapで管理するのはどう考えても現実的じゃない)
>>952の指摘でも感じたけど、あなたは実装面には強いけど仕様に明るい方ではないよね
もう少し、仕様についても勉強した方がいいかと
977:Name_Not_Found
15/07/13 21:25:35.32 .net
まあ全部JSでブラウザを作ろうというプロジェクトもあるし～
最近のモダンブラウザはBlink-in-JS構想とかで徐々にDOMをJS化してきてるし～
今日のことが明日通用しない業界だし～
どうでもいいよね～
978:Name_Not_Found
15/07/13 23:51:58.78 .net
>>958
> また、DOMで子が親を参照するのは当然必要で、parentNodeがまさにそうだ。
だから最初から何度も言っているが、
・子DOM要素が親DOM要素の『スコープ』を保持する必要
・スコープ
・スコープ
・スコープ
子DOMが子DOMのスコープ内に親DOMをもつのはparentNodeが有るからこれは必要。
しかし子DOMが親DOMのスコープを保持する（親DOMから何が見えるかを直接知っている）必要があるのか？ということ。
普通は一旦親DOMを参照した後に、その親DOMのスコープを見ればいい。だから直接もつ必要はない。
しかしMSDNでは、
> 動的に作成された 2 つのオブジェクトどうしを一時的にアタッチして子要素から親要素へのスコープを作成するのが基本的なパターンです。
> 後でこの 2 要素のツリーをプライマリ ツリーにアタッチすると、その両方がドキュメントのスコープを継承し、一時オブジェクトがリークします。
つまり、DOMに親子関係が発生した時にそれぞれスコープを作成して、---(A)
プライマリツリーにアタッチした時にこれらは両方とも変更され、---(B)
結果、(A)がリークすると言っている。
これが起きるのは、
・（A）内部に循環参照がある＝子DOMのスコープと親DOMのスコープに循環参照がある---(α)
・（B）で差し替えられるのは親DOMのスコープのみ＝子DOMが親DOMのスコープを直接保持したままでこれがリーク---(β)
のどちらか。俺は後者だと思っていたからこの質問になっていた。ただ、今から考えれば前者かもしれない。
繰り返しておくが、
○ 子DOMと親DOMに循環参照がある。(parentNode, childNode)
？ 子DOMのスコープと親DOMのスコープに循環参照がある。
？ 子DOMが親DOMのスコープを保持している。
○ 子DOMが子DOMのスコープ内に親DOMを保持している。(parentNode)
これらは全く別物だ。スコープは「スコープオブジェクト」として別に作った方が実装が楽だから、多分そうなっている。
そしてここでリークすると言っているのはその「スコープオブジェクト」であって、「DOMオブジェクト」ではない。
対策は「一時的なアタッチをなくす＝（A）の作成をしない」となっている。
結果的にリークするオブジェクト(A)そのものを作成しないのだから、当然対策できることになる。
979:Name_Not_Found
15/07/13 23:52:34.90 .net
(α）のpatch対策は簡単で、DOMをアタッチする時にそのDOM以下のツリーのスコープオブジェクトを全部GCすればいいだけだ。
ただ、循環参照の対策が出来ているのなら通常のGCで回収できることになるから無駄patchになる。
だから循環参照の対策が根本対策で、こちらを急ぐのが開発方針として妥当で、おそらくこれだろう。
ただ（α）だと書き換えるスコープオブジェクトの数が多く、遅い。
最小限に絞って高速化すると（β）になる。だからこちらを仮定していたのだが、
IEは実際遅いし、循環参照の対策も出来ているのなら、（α）なのかもしれない。
（β）の実装で無理があるともあまり思えないのだが。
もう一度繰り返すと、(>>942)
> ・DOM挿入順が速度最適（ツリーを完成させてから最後に挿入）の場合は今でもリークするのか？
> ・親DOMのスコープを子DOMが保持することが仕様として必要なのか？
俺は後者の仕様はないと思っているし、従って前者も対策されており、リークはないと見ている。
だから、これが間違っていそうなら指摘よろしく。
対象はchromeとFFの共に最新版だけでいい。
980:Name_Not_Found
15/07/13 23:57:19.86 .net
>>958,959
見る限りV8のDOMはおまけだ。ただ、そういう用途があるのかはよく分からない。
ブラウザから離れるのなら、最初からnative(exe)が使える。サーバーサイドは基本的にこれだ。
スクリプトの方が運用が楽だし、スレッド起動できるから今は速いわけだが、
exeをスレッド起動できる仕組みが出来ればスクリプトエンジンは全部抹殺されても不思議ではない。
(DLLの動的『指定』とか)
もちろん速いスクリプトエンジン自体は需要はあるし、JITならさほど遅くもないから、こちらに賭けるという選択だとも見える。
しかしNodeはC->JavaScriptは呼べるが、逆はできない。つまり本体はCで、JavaScriptをブラウザ/WEB用APIとして使う方向だ。
nativeが使える状況で速度至上主義なら、C系以外の選択肢は事実上無い。だからNodeの選択は妥当だ。
もちろんNode自体を動かすためにV8が必要だとしても、若干ここら辺に違和感を感じるのは事実だ。（統一感がない）
そもそも速い共通バイナリならJavaでよかったのだが、chromeはそれも外した。(NPAPIの廃止）
Javaについては他に問題がありすぎるようではあるが。
なお、密結合にはならない。
元々1つの物(DOM)を、2箇所(Blink/V8)から管理するからおかしいことになっている。
見る限りDOMとJSのオブジェクトは相似形だから、同じHeapで同居できるはず。
だから、Blink/V8/JSHeapと分離し、BlinkとV8内部には個別のHeapを持たず、全部JSHeapに突っ込めばいい。
wrapperというコピーが無くなるので、メモリ使用量は減る。
GCはすべてJSHeapに任せられる。単一で内部的にツリーを構成できているから、
「GCされないために云々」という無駄コードを全て捨てられ、プログラムとしては綺麗になる。
ただ、各エンジンとHeapが粗結合になるので、どうしても動作が遅くなる。
(Readはpublic（というか直接ポインタアクセスで動的保護無し）、
Writeはprivateという指定が出来ればいいのだが、これができる言語は多分無い）
だから高速エンジン制作者には不評だろうけど。
とはいえ、Mozillaがやろうとして失敗したようだから、何か他にも問題があるのだとは思う。
981:Name_Not_Found
15/07/13 23:59:43.55 .net
>>960
> あなたのいうJSHeapとは何？
JavaScriptのHeapと書くと長いから、JSHeapと書いているだけ。
ただこの質問は君にはプログラミングセンスがないことを示している。
君には理解不能だろうけど。
> DOM要素ノードはオブジェクトでもあるわけだから同時に2つのheapが発生することは避けられない
何故？そんなことはあり得ない。例えばPCのデータはHDDで全てまかなえている。
やり方次第だ。無理に纏めるのは効率が悪いが、同じ型、同じ物を別々に扱うのはもっと効率が悪い。
localStrageだってkey/value型しかないが、やり方次第でどうとでもなる。そういうものだ。
実際にDOM.jsは動いているんだろ？だったら少なくともJSHeapに突っ込んでもなんとかなるんだよ。
> あなたは実装面には強いけど仕様に明るい方ではないよね
これはその通り。JavaScript歴は半年だからね。
ただそれ以上に君にはプログラマーとしてのスキルがないよね。
> もう少し、仕様についても勉強した方がいいかと
何故？俺はGM使いで、だからJavaScriptを使っているだけだ。
今現在で一通り、やりたいことは書けるようになった。
俺がブラウザを作るのなら仕様を一通り読む必要があるが、その予定はない。
その程度でグダグダ言うなと言うのなら、無視してくれて構わない。
982:Name_Not_Found
15/07/14 00:03:30.93 .net
>>960
君は何のために俺に対してレスを付けているのだ？
俺に対して文句を言いたいだけか？それならいくらでも言えばいいが、無駄だから今後は無視させてもらう。
俺は今、chromeが勝手に落ちる現象に遭遇して困っている。
>>942に書いたとおり、DevToolには現れないが、確かに安定して落ちるので何か原因がある。
だからそれに関する手がかりになりそうな奴にはレスを付ける。
958,959に関しては、俺に対して何かしら情報をくれようとしているのだから、こちらもそれなりに返す。
960に関してはどう返せばこちらの実になるか分からないし、それ以前にどう返して欲しいかも分からない。
仕様を勉強してない奴は黙れというのなら、
仕様を与えられても実装できない君みたいなエセプログラマはもっと黙るべきだ。
仕様は聞けば済む話だが、スキル/センスがないのはここでいくらやりとりしても解決できる話ではない。
君は俺より実装面で弱いという自覚があるようだが、ならば何故その実装面の話に低レベルな横槍を入れるのだ？
質問案件に対し、知っている奴が分かる範囲で気が向いたら答えるのが質問スレの普通のやり方だ。
君のレスは誰のためにも何のためにもならない。
初心者用スレとして維持したいのであれば、俺は「ECMAScriptデス4」に移動してもいい。
俺にレスをくれている奴らの多数決でいい。
> DOM要素ノードはオブジェクトでもあるわけだから同時に2つのheapが発生することは避けられない
Dom.jsでも読めよドアホ。
もう少し、自分が至らないことについて自覚した方がいいかと
983:Name_Not_Found
15/07/14 01:52:01.76 .net
／⌒ヽ
/ ´_ゝ`）すいません、ちょっと通りますよ・・・
| /
| /| |
// | |
Ｕ .Ｕ
984:Name_Not_Found
15/07/14 10:30:45.85 .net
>>962
おそらくページ遷移時のCG順序か機構に問題があって、特定の場合に中間構造がリークするのだろう。
中間構造はドキュメントに接続された際にもう捨てていいはずだが、
JSとの絡みで必ずしも捨てられないケースがあるのか、バグでそうなっていたのだろう。
>>963
今はしない。
>>964
DOMの管理含めて丸ごとJSで組み立てられればラップなんて仕組み必要無いが、
実際にはDOMはレンダリングともつながっているわけで
ブラウザネイティブの世界から大きく切り出すことは出来ない。
985:Name_Not_Found
15/07/14 11:11:23.28 iGbd+ivb.net
URLﾘﾝｸ(blog.jquery.com)
jQuery 3.0 and jQuery Compat 3.0 Alpha Versions Released
jQuery 3.0きた！ アルファだがな。
Major changes
* Simplified .show() and .hide() methods
* Special case with .data() names
* jQuery.Deferred is now Promises/A+ compatible
* Removed special-case Deferred methods in jQuery.ajax
* Error cases don’t silently fail
* .width(), .height(), .css(“width”), and .css(“height”) to return decimal values (whenever the browser does)
* Removed deprecated event aliases
* jQuery.swap, jQuery.buildFragment, and jQuery.domManip are no longer accessible on the jQuery object
* Animations now use requestAnimationFrame
* .unwrap( selector )
* Massive speedups for some jQuery custom selectors
基本的に互換性は保たれているらしい。
個人的にはDeferredがPromises/A+互換になったことが嬉しい
986:Name_Not_Found
15/07/14 11:45:53.25 .net
相変わらずの信者脳だな
987:Name_Not_Found
15/07/14 13:33:39.65 .net
> As an added bonus, both jQuery and jQuery Compat will
> include support for Yandex.Browser, a freeware browser released in 2012.
なんだ？ Yandex.Browserって
988:Name_Not_Found
15/07/14 13:36:04.50 .net
へー
URLﾘﾝｸ(weekly.ascii.jp)
> ロシアの検索市場でグーグルを圧倒するYandex、次にGoogle Playを狙うワケ
URLﾘﾝｸ(www.itmedia.co.jp)
> ロシア検索最大手のYandexが、Chromiumベースでミニマルデザインの
> 新ブラウザ「Yandex.Browser alpha version」をリリースした。
989:Name_Not_Found
15/07/14 16:24:28.23 .net
宣伝うざい
990:Name_Not_Found
15/07/14 16:31:11.58 .net
宣伝をわざわざ貼るくらいこのスレには価値があるということだよ
991:Name_Not_Found
15/07/14 16:37:36.30 .net
別に宣伝じゃなくて、Yandexってなんだ？って思っただけ？
992:Name_Not_Found
15/07/14 17:01:51.96 .net
宣伝云々は荒らしに対してじゃないの
993:Name_Not_Found
15/07/14 17:28:47.88 .net
>>975
ここで質問する必要ないだろ
994:Name_Not_Found
15/07/14 17:35:48.85 .net
俺は別に質問などしてないけど？
995:Name_Not_Found
15/07/14 17:59:13.18 .net
> なんだ？ Yandex.Browserって
996:Name_Not_Found
15/07/14 20:06:29.40 .net
それは俺じゃない
997:Name_Not_Found
15/07/14 20:33:58.02 .net
>>980
>>972だって同じ
ライブラリの話題禁止と書いてあるだろ
998:Name_Not_Found
15/07/14 20:39:10.88 .net
ライブラリの話題じゃないだろｗ
999:Name_Not_Found
15/07/14 20:40:15.07 .net
ブラウザの話題だ
1000:Name_Not_Found
15/07/14 20:43:36.59 .net
>>982-983
ブラウザの話題はもっと関係ないだろ
ブラウザスレでやれ
1001:Name_Not_Found
15/07/14 20:45:43.99 .net
雑談ぐらいいいだろｗ
1002:Name_Not_Found
15/07/14 21:15:40.37 .net
スレ違いの話題に便乗してスレ違いの話題を広げると他の人に迷惑がかかるだろ
常識で考えろ
1003:Name_Not_Found
15/07/14 22:31:18.37 .net
>>968
ブラウザネイティブ＝HTMLレンダラじゃないのか？他の用途は特になさそうだが。
Wikiを見る限り、レンダラとJSエンジンが別なのは歴史的経緯だ。
1998 KDE(KHTML/KJS)
2002 WebKit(WebCore/JavaScriptCore)
2013 Blink(Blink/V8)
切り出すのは出来ないのではなく、今更やるのは大変であり、意味がないからだ。
今ゼロからソースを書くのであれば、
共通のデータストアを用意し、そこに入れさえすれば後は全自動の方が楽だ。
ただ、別Heap方式で実装しきってしまっているようなので、今更切り出す意味はない。
リークに関しては、こちらと同じ見解だということで了解した。ありがとう。
個人的にはMSの技術力は認めているので、何故そんな実装になったかが引っかかるが、
IEはAjax以前からあったから致し方なく、ドキュメントも古いからそんなもんだということにしている。
1004:Name_Not_Found
15/07/14 23:26:32.79 .net
>>987
いいかげんスレ違いの話はやめろ
1005:Name_Not_Found
15/07/15 02:22:48.35 .net
>>987
JSエンジンとレンダラだけについてではなく、
JSエンジンとレンダラ（ブラウザ本体）とDOM管理について話している。
例えばDOMが変更されたら再描画しないといけない。
DOMツリーとレンダリングツリーは密接に繋がっているので、
DOM管理をJS側に持っていくほうが普通に考えると非効率だ。
1006:Name_Not_Found
15/07/15 09:28:12.98 .net
なんかスレチに過敏な方が約一名おられるようで
誰も困らないから多少は見逃せば？
あまりにも続くようだと注意すればいいが何でもかんでも言ってるとスレの雰囲気悪くなる
1007:Name_Not_Found
15/07/15 10:41:13.35 .net
jQueryとlodash以外のスレチは絶対許さない人がいるんだよ
1008:Name_Not_Found
15/07/15 11:22:36.01 .net
アホか、いつjQueryとlodashを認めた？
jQueryとlodashを含めてスレ違いは禁止に決まってるだろ
1009:Name_Not_Found
15/07/15 12:27:16.00 .net
どうでもいい
荒らす気がないのならいい
一度決めたことが未来永劫通用する業界じゃないし
例えばこれからはWASMの範囲だってサポートしていかなきゃならんだろ
1010:Name_Not_Found
15/07/15 12:43:25.99 .net
Web業界の常識とスレのローカルルールの違いも理解出来ない人がいるのね
1011:Name_Not_Found
15/07/15 13:16:00.86 .net
スレチを叩く自治うざい！ じゃあjQueryとlodashを許容しよう！
とはなりませんでした～
1012:Name_Not_Found
15/07/15 13:26:50.02 .net
次スレ誘導
お好きなスレにどうぞ
+ JavaScript の質問用スレッド vol.121 +
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.122 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.123 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.123 +(c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.123 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.124 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.125 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.125 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
1013:Name_Not_Found
15/07/15 13:51:29.57 .net
>>996
乙
1014:Name_Not_Found
15/07/15 22:48:23.38 .net
>>994,995
正直言ってスレのルールなんて関係ない。
1015:Name_Not_Found
15/07/15 23:10:37.85 .net
>>989
多分、そういう議論を繰り返して平行線で今があるのだと思う。
実際、DOMを変更するにしてもHTMLではなくJavaScript側からしかできないだろ？
どっちにも密接なんだよ。
経緯から推測すると、googleはV8でDOMを管理しようとして、これを要求したが、
既にWebCoreで管理していたWebKitからするとウザいだけで、APIの提供で終わった。
googleはこれ以上の高速化にはV8で管理するのが不可欠と見てBlinkにフォークした。
WebKitはV8用のコードをすべて捨てるつもりらしいから、
逆に言えばV8専用のコードがそれなりの量あるということ。
つまりJavaScriptCoreはWebCore内のDOMを直接参照に近い方法で見ていることになる。
Blink： レンダラ+（DOM+V8)
WebKit： (WebCore+DOM)+JavaScriptCore
俺： レンダラ+DOM+JavaScriptエンジン
ということ。どの実装も出来る。上2つは実際にブラウザになっているので、結果は出るだろう。
1016:Name_Not_Found
15/07/15 23:14:37.85 .net
梅
1017:１００１
Over 1000 Thread.net
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
1018:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています