私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.118 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
こうやって見るとMSが作り出した新規機能って
結構標準化されたんだな。
先進的なブラウザだったんだ。
結構標準化されたんだな。
先進的なブラウザだったんだ。
ネスケは自爆しただけだから。
MSが汚い手を使ったんだとかそういうレベルじゃなかった。
なぜなら、CSSを有効にしたらブラウザが落ちまくって
まともに使えないから、CSSはオフにすることが常識だったんだぞ。
MSが汚い手を使ったんだとかそういうレベルじゃなかった。
なぜなら、CSSを有効にしたらブラウザが落ちまくって
まともに使えないから、CSSはオフにすることが常識だったんだぞ。
DOMノードを親要素から切り離す場合は、
var dom = parent.firstChild;
parent.removeChild(dom);
→domに切り離されたのノードが入っている
とやるのでしょうか?
var dom = parent.firstChild;
parent.removeChild(dom);
→domに切り離されたのノードが入っている
とやるのでしょうか?
#testのjqueryオブジェクトを100万回生成
2920.000ms
同様のdomdashオブジェクトを100万回
406.000ms
なので、jqオブジェクトの方が高いですね
jqはIDを使った一意のオブジェクト指定でもquerySelectorを使うと思われるので遅いのかもしれません
2920.000ms
同様のdomdashオブジェクトを100万回
406.000ms
なので、jqオブジェクトの方が高いですね
jqはIDを使った一意のオブジェクト指定でもquerySelectorを使うと思われるので遅いのかもしれません
そうすると、domdashはしたければチェーンすることも出来るので、
jqueryよりもいいと言えるのではないでしょうか
軽くしたい時は関数形式、チェーンしたい時はオブジェクト形式と選べて、
しかも速いので
jqueryよりもいいと言えるのではないでしょうか
軽くしたい時は関数形式、チェーンしたい時はオブジェクト形式と選べて、
しかも速いので
ネスケが駆逐された頃ってテーブル全盛でIEはその描画が圧倒的に速かった
TRやTD閉じタグ欠けててもページレイアウト壊れなかったし
この頃はさすがMSって感じではあったんだよなあ
欧州のレイシストどもに牙を抜かれなきゃ今頃もっと危険で楽しいインターネッツになっていたろうに
TRやTD閉じタグ欠けててもページレイアウト壊れなかったし
この頃はさすがMSって感じではあったんだよなあ
欧州のレイシストどもに牙を抜かれなきゃ今頃もっと危険で楽しいインターネッツになっていたろうに
http://peace.2ch.net/test/read.cgi/hp/1408512894/41n より
> まず煽る。適当なことを言って馬鹿にする。
> そうすると相手がムキになって、正しいことを言ってくる。
> それをみて知識を吸収するのだ。
これを実践している質問者がこのスレにもいるので注意した方がいい
お礼もろくすっぽいわないし、無駄に怒らせるだけ怒らせて放置するのが常
> まず煽る。適当なことを言って馬鹿にする。
> そうすると相手がムキになって、正しいことを言ってくる。
> それをみて知識を吸収するのだ。
これを実践している質問者がこのスレにもいるので注意した方がいい
お礼もろくすっぽいわないし、無駄に怒らせるだけ怒らせて放置するのが常
>>789
eval使えばできるはず
eval使えばできるはず
>>816
> TRやTD閉じタグ欠けててもページレイアウト壊れなかったし
それが正しい仕様だからな。HTML4でもHTML5でも
http://www.w3.org/TR/1999/REC-html401-19991224/index/elements.html
ネスケはTRやTDまで正しくレンダリングできなかったんや。
> TRやTD閉じタグ欠けててもページレイアウト壊れなかったし
それが正しい仕様だからな。HTML4でもHTML5でも
http://www.w3.org/TR/1999/REC-html401-19991224/index/elements.html
ネスケはTRやTDまで正しくレンダリングできなかったんや。
対案ださずに反対のみ
こういう非生産的な人間はどこの世界にもいますね
こういう非生産的な人間はどこの世界にもいますね
対案も何も出来ないことは出来ないのだからどうしようもないだろう
出来ないことをしようとしている時点で設計を変えるべき
関数を文字列化しない設計に変更することを提案する
出来ないことをしようとしている時点で設計を変えるべき
関数を文字列化しない設計に変更することを提案する
煽れば答えが出てくると思って自分で何も考えない
こういう指示待ち人間はどこの世界にもいますね
こういう指示待ち人間はどこの世界にもいますね
オブジェクトの生成コストを気にするならどう考えてもライブラリを使用しないほうが速い
>>832
だから、ライブラリ同士で比較するのが無意味だといっているのだが?
だから、ライブラリ同士で比較するのが無意味だといっているのだが?
>>834
意味が分かりませんね
普通ライブラリは既存のライブラリとの性能比較結果を出すものですよ
既にあるものよりもあきらかに良くなっていないといけないのですから
lodashにはunderscoreとの比較結果が載っているし、
各種jquery互換ライブラリにはjqueryとの比較結果が載っています
それは当たり前のことなのです
意味が分かりませんね
普通ライブラリは既存のライブラリとの性能比較結果を出すものですよ
既にあるものよりもあきらかに良くなっていないといけないのですから
lodashにはunderscoreとの比較結果が載っているし、
各種jquery互換ライブラリにはjqueryとの比較結果が載っています
それは当たり前のことなのです
>>835
それはライブラリ作者が考えることで利用者が考えることではないだろう
それを考えるなら速度差が発生する原因を突き止めて作者にフィードバックしないと意味がない
オブジェクト生成というライブラリの根幹に関わる問題を考えるにあたって、単純な速度比較するだけというのが以下に無意味かが分からないのか?
原因をなぜ突き止めない?
そしてそこまで速度を追求する知識を有しているのなら「ライブラリを使用しない」という前提があってしかるべき
それはライブラリ作者が考えることで利用者が考えることではないだろう
それを考えるなら速度差が発生する原因を突き止めて作者にフィードバックしないと意味がない
オブジェクト生成というライブラリの根幹に関わる問題を考えるにあたって、単純な速度比較するだけというのが以下に無意味かが分からないのか?
原因をなぜ突き止めない?
そしてそこまで速度を追求する知識を有しているのなら「ライブラリを使用しない」という前提があってしかるべき
作者にフィードバックとか、何を言っているのか分かりませんね
遅いのには理由があるので、
jqueryの設計思想においてはいわば必要な遅さなんです
それに口を出すつもりはありません
DOMのちょっとした操作のためにわざわざオブジェクト生成するのっておかしくね?
関数でもオブジェクトでも使えるlodashのやり方の方が良くね?
という疑問から開発したところ、実際に良かったので報告しているまでです
この方向性にはjqueryをリプレースできる可能性があると思っています
遅いのには理由があるので、
jqueryの設計思想においてはいわば必要な遅さなんです
それに口を出すつもりはありません
DOMのちょっとした操作のためにわざわざオブジェクト生成するのっておかしくね?
関数でもオブジェクトでも使えるlodashのやり方の方が良くね?
という疑問から開発したところ、実際に良かったので報告しているまでです
この方向性にはjqueryをリプレースできる可能性があると思っています
>>837
> jqueryの設計思想においてはいわば必要な遅さなんです
それがわかっていながら
> DOMのちょっとした操作のためにわざわざオブジェクト生成するのっておかしくね?
なぜこの発想になるのか
オブジェクト生成コストを考えるほどにシビアにチューンするなら、Lo-dashのライブラリ使用コストをなぜ考えない?
というより、本当にそれは実用上問題あるのか?
実用上問題あるなら、もっと具体的な問題に言及されるはずだが?
本当に生成コストが気になるなら、ライブラリを使用しないことでコスト削減するのは自然な発想
何となく生成コストが気になる程度の問題なら無駄なコスト(時間)を消費するだけだぞ
> jqueryの設計思想においてはいわば必要な遅さなんです
それがわかっていながら
> DOMのちょっとした操作のためにわざわざオブジェクト生成するのっておかしくね?
なぜこの発想になるのか
オブジェクト生成コストを考えるほどにシビアにチューンするなら、Lo-dashのライブラリ使用コストをなぜ考えない?
というより、本当にそれは実用上問題あるのか?
実用上問題あるなら、もっと具体的な問題に言及されるはずだが?
本当に生成コストが気になるなら、ライブラリを使用しないことでコスト削減するのは自然な発想
何となく生成コストが気になる程度の問題なら無駄なコスト(時間)を消費するだけだぞ
> DOMのちょっとした操作のためにわざわざオブジェクト生成するのっておかしくね?
ちょっとした操作ならライブラリを使用する必要がない
ちょっとした操作ならライブラリを使用する必要がない
検索機能があるので、URLの最大文字制限を調べたところ、
IEは2083文字にしているという情報をネットで見ました
これはURLエンコード後の文字数だと思います
URLエンコードしてから単純に文字数制限すると、文字が化けますよね
文字が化けないように文字数制限するにはどうしたらいいですか?
IEは2083文字にしているという情報をネットで見ました
これはURLエンコード後の文字数だと思います
URLエンコードしてから単純に文字数制限すると、文字が化けますよね
文字が化けないように文字数制限するにはどうしたらいいですか?
ついでにいうと、native code な関数は文字列化できないな
上の方に合った循環参照も変数の概念がJSONにないので実現できない
元々、オブジェクトは参照型だし、プリミティブなJSONに変換しようとするのが何か間違っている気がするが
上の方に合った循環参照も変数の概念がJSONにないので実現できない
元々、オブジェクトは参照型だし、プリミティブなJSONに変換しようとするのが何か間違っている気がするが
ついでにいうと、native code な関数は文字列化できないな
上の方に合った循環参照も変数の概念がJSONにないので実現できない
元々、オブジェクトは参照型だし、プリミティブなJSONに変換しようとするのが何か間違っている気がするが
上の方に合った循環参照も変数の概念がJSONにないので実現できない
元々、オブジェクトは参照型だし、プリミティブなJSONに変換しようとするのが何か間違っている気がするが
console.log(window instanceof HTMLElement);
で確認出来ました
windowもdocumentもDOMではなく
document.documentElementからDOMが始まるのですね~
で確認出来ました
windowもdocumentもDOMではなく
document.documentElementからDOMが始まるのですね~
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.128 + (1001) - [97%] - 2016/2/26 6:45
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.108 + (1001) - [97%] - 2013/9/21 15:16
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.100 + (1001) - [95%] - 2012/6/13 22:46
- + JavaScript の質問用スレッド vol.125 + (1001) - [95%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.124 + (1001) - [95%] - 2015/7/16 1:30
トップメニューへ / →のくす牧場書庫について