元スレ+ JavaScript & jQuery 質問用スレッド vol.7 +
JavaScript覧 / PC版 / みんなの評価 :
551 = :
>>547
JavaScriptの非推奨の仕様?
そんな話はしていないし、例えばwindow.のプロパティアクセスで予約語を気にする必要はないんだが
ただ取得したいidがwindowのアクセサやメソッドと被るかもしれないという理由で避けるのは事を心配するのは、
例えば変数を使うと予約語と衝突するかもしれないから念の為ちょっと面倒なプロパティアクセスやMapを使うと言ってるのと同じくらいアホらしいと言ってるんだよ
あと１年前くらいからセレクタにもキャッシュやJITが入るようになったから必ずしも何々が早いと言うことは言えない
つうかそんなに山ほどの訳のわからんところに散らばっている要素をIDで取得しないといけない事なんてないので速度は実際どうでもいい
もしそうなら根本の設計が間違ってる
552 = :
>>550
たかだか一メソッドの話で「開発速度」なんて馬鹿な曲解してるのはお前だけだよ
553 = :
>>552
「たかが」の使い方間違ってるぞｗ
何十行、何百行ってあるなかの一メソッドなら
たかが一メソッドだが、
全一メソッドの中での一メソッドは
全部と言ってもいいぐらいの量だ
554 = :
これみろ
You Don't Need jQuery
http://qiita.com/tatesuke/items/b9548dd484b01b139b74
jQueryはいらないことを示そうとして
jQueryの方がコードが大幅に減ることを
明確にしてしまった自爆した記事なｗ
555 = :
>>553
>「たかが」の使い方間違ってるぞｗ
えっ・・・
こいつ日本語を知らない・・・？
556 = :
>>551
> 例えば変数を使うと予約語と衝突するかもしれないから
じゃあ予約語リスト（windowのプロパティ）を出してくれよ
例えば非標準のhomeは、Firefoxではwindowのアクセサやメソッドと被る
だからどのブラウザでも定義されていないもので、
将来追加されることもない、windowのプロパティを教えてくれ。
予約語は将来も使うなということで今は使われていなくても
予約しているから安全なんだ。
windowのプロパティと被るから使ってはダメな名前一覧を出してくれ
557 = :
>>554
jQueryの方が大幅にコード短いな
558 = :
たかだか
意義素
程度を表す語の前について、程度が低いことを示す表現
類語
たかだか ・ たったの ・ ものの ・ ほんの
559 = :
>>554
玉の小せえ男だなお前
そこでの要らないっていうのは、
環境が以前と随分変わってきたから、そろそろ局所解を出て冒険しようという高貴な心意気の表してるんだよ
お前みたいな小心者はずっと生ぬるい洞穴に篭って一生を過ごせばいい
560 = :
たかが一メソッドだけを比較するだけじゃ
jQueryが有利なことがわからないって言いたかったんじゃね？
You Don't Need jQuery
http://qiita.com/tatesuke/items/b9548dd484b01b139b74
こっちにjQueryが有利な理由がたくさん出てるけど
561 = :
>>559
> お前みたいな小心者はずっと生ぬるい洞穴に篭って一生を過ごせばいい
じゃあお前はAngularやReact使ったこと有るの？
どちらもDOM APIは使わないんだが、
未だにDOM APIを直接使うほうが
生ぬるい洞穴とかなんとかじゃないかｗ
いい加減DOM APIを捨てましょう
562 = :
>>556
俺が言ってるのは０か１かではない
勿論、そういうのを気にする状況はあるし、そこではgetElementByIdを当然使う
逆に気にしないといけない状況で、window.を使う価値はない
どちらかと言うと全コードでそこまで気にしないでいいだろう状況の方が多いだろうという感覚で言っている
具体的には、気にしないでいいだろう状況というのは、万が一くらいの衝突は全然許容することをイメージしている
だからwindow.homeの方も許容の範囲に入る
それを言い出すと例えば広告システムや何かのフレームワークがかぶるID出すかもしれないけど、
そういうのは長期的なコスパを考える上で誤差の範囲だと思う
まあ毎月１回衝突案件があるか、１年に１回そこで嵌まるくらいなら、ギリギリメリットのほうが大きいというくらいの判断感覚
ブラウザによって違うとか、確かに心配点ではあるが、現実にそこで嵌まる可能性や期待値を考えたら
それこそ普段未だに珍しくない、ブラウザ差で嵌まる沢山の事象数に埋もれるレベルだと思う
だから結論として、俺の経験のもとで、改めて考えてみても、基本的なIDでの要素の推奨取得方法は、それだとギリギリくらいで言える
564 = :
>>561
バカタレ
何をするにも殆ど常にAngularやReactを使う奴はjQueryと比較すれば皆無と言っていい
ライブラリにおいて何かをするためにそれを使う思考は問題ない、それを使って何かをするという思考になることが問題だ
565 = :
>>562
そいで予約語リスト（使用してはいけないIDリスト）はまだ？
予約語は危険だからちゃんとリストを用意してる。
IDもそうでないと、予約語と一緒とはいえない
566 = :
>>564
言葉遊び？
実行速度を速くすることは目的ではない
567 = :
> たかが一メソッドだけを比較するだけじゃ
取り繕おうとしてて草
日本語が不自由な奴が今までプログラミング言語を語ってたとかまさしくお笑い草だな
568 = :
たかが一メソッドだけを比較ってどういう意味で行ったんだろうかねｗ
一メソッドだけで作られるプログラムなんて殆ど無いし、
2ちゃんねるの例だけで判断？まさかそんなマヌケなことはしてないはずｗ
569 = :
「たかが一メソッドの話」じゃないぞ
「たかだか一メソッドの話」だぞｗ
たかだか一メソッドで勝った程度でjQueryが
優位ってことにはならないって言ったんだ
その他の例を出せ
571 = :
もしかして俺に成りすましてるつもりなのかこいつ
自分自身と会話しだすようじゃ人間おしまいだな
573 = :
大部分のサイトがjQuery使ってるだろうにｗ
575 = :
jQueryを批判することが目的になってる愚か者がいるな
578 = :
時間がかかって良いのならなんでも自作できるよ
579 = :
時間かかろうがかかるまいが、工夫すな、要らん工夫だから、迷惑だから。たとえば多くの2chまとめサイトなんてスクリプトオフですこぶる快適になる。
580 = :
迷惑わろたｗ人様のサイト利用させて頂いておいて何様だよ
店に入って来るなり因縁つける汚客か！
581 = :
jQueryはUIが便利でいい
1行でタブやアコーディオンできてしまうなんて楽すぎる
イベント処理やKB操作もできるし、記述方法も似てるから他のUIもすぐ使いこなせるし
582 = :
>>581
俺はそうは思わないな
jQuery自体は素晴らしいけど、jQuery UIは時代について来れていない。
例えばHTML5で大幅に増えたinput要素の属性への対応な
HTML5ではpattern属性で入力値のバリデーションを付けられるのだが、
当然ブラウザ依存。対応していないブラウザだってあるわけだ
jQueryの思想的に考えるならばブラウザ間の非互換性を解決する機能を搭載してほしかった。
jQuery UIはあまりにも開発速度が遅すぎて、すでに多くのブラウザで
pattern属性がサポートされてしまったが、jQueryブランドとしては
そういう足回りにきっちり対応すべきだろう。
もっともそれはjQuery UIの考えが俺の考えと違うのだろうけどさ。
UIのライブラリとしては一昔感があるが、可も不可もなくそんなもんだろう程度
jQuery UIもついでにjQuery Mobileも、俺からすれば単にjQueryを使ってるだけの
一フレームワークでブラウザの標準機能を置き換えるだけの力はないと思ってる。
583 = :
俺が望むUIフレームワークは将来的にはWebComponentsになるだろう。
現状ではBootstrapが一番近いかな？
やってほしいのは、HTMLタグを書くだけでどのブラウザでも
同じUIになって欲しいだけなんだよ。
例えば、<input type="number"> と書けばIE6とかであっても
数値入力のフォームになってほしかった。
validationの機能も使える
細かい制御はdata-option属性とかで指定できるようにして
コードレスでどのブラウザでも全く同じフォームの機能が
使えるようにしてほしかった。
そしてデザインはCSSでユーザーが自由に決められる。
そういうものをjQueryブランドで実現してほしかったなぁ。
584 = :
小規模
jQuery UI, jQuery Mobile
中規模
Backbone, Rails
大規模
AngularJS, React
585 = :
>>584
分け方がおかしいぞｗ
587 = :
Underscore, Lodash のFunction にある。
delay, throttle, debounce
http://github.com/enja-oss/Underscore/blob/master/docs/Function.md
588 = :
別にただのforでもブラウザやOSがセッション数制限するのと、
PINGがdelayの代わりになるのでDOS攻撃になることは無い
589 = :
>>588
なるだろ。適当なこと言うな
590 = :
>>589
考えなし測定なし に否定する癖はやめようね
591 = :
測定した結果なりました
592 = :
>>582
企業なら社内共用ライブラリの類があるからいいだろうが
個人にとっては十分
593 = :
>>588は馬鹿だなー
1セッションだけでも連続してアクセスすれば負荷はかかるし、
ping？どこからでてきたらのか。プロトコルが違うから
pingが通っても通らなくても、ウェブサーバーにアセスできるかどうかとは関係ない
だからブラウザはpingなんて使ってない
本当に馬鹿だなーｗ
594 = :
pingって言うのは多分クライアントサーバ間のレイテンシのことだろ
つまり内容が少なくてレスポンスが速くても、１回の通信が完了するまでには100msとかある程度の下限があるということ
その上でセッション数がクライアント側で制限されてペンディングされるとしたら
上限に達した以降はレイテンシ以上の間隔でしかリクエストが発生しない
つまりせいぜい秒間10回程度だろし、仮にサーバがビジーでレスポンスが遅れている時には
リクエスト間隔も勝手に広がるから、それをDOS攻撃とは言いづらいねということじゃないか
まあそれを貧弱なサーバに対して何分も続けたら迷惑だろうから、
総数が数百を越えてくればより気を配る必要があると思う
595 = :
pingがレイテンシってオンラインゲーマーかよｗ
まあいい、レイテンシの話題でありえない遅さを出されても困るからな
古いデータだが単に見やすかったってだけの参考資料
レイテンシは10msとしよう。
そうすると単純計算で1秒間に100回アクセスできる
十分DoS攻撃のレベルなわけだ
http://d.hatena.ne.jp/rx7/20110302/p1
> EC2インスタンスから、国内(にありそうな)サイトへのRTT
> それぞれping数回のRTT平均値を取りました。
>
> www.yahoo.co.jp 12.948msec
> www.ocn.ne.jp 14.872msec
> www.u-tokyo.ac.jp 9.187msec
> www.hatena.ne.jp 3.015msec
> ameblo.jp 2.726msec
596 = :
ドラクエなんて、1秒間に、2回だよ
597 = :
車の『徐行』と同じで一秒間に何回なら『DoS』と言えるわけでもないし、どのくらいの総数なのかも分からないし意味のない議論
最低な例だと岡崎図書館事件みたいなのもあるけど、今回のAjaxの話は同オリジンで身内な訳だし
普通に考えたら秒間数十くらいでDoSになってたら、ページ内に外部リソースを沢山置いたらサイト潰れちゃうことになるしね
598 = :
>>597
自分で意味が無いと言っておきながら、普通に考えたら秒間数十くらいで～とか
いうなボケ
画像などの単なるファイルへのアクセスと、
何らかの処理を行うプログラムへのアクセスじゃ全然意味が違う
物によっては秒間1アクセスでもDoSになるわ
599 = :
>>597
「サーバが停止するほどのアクセス」があればよいので
1秒に数回でも普通にDoS扱いになりえますよ
「普通に考えたら」はもっとも危険な考え方なので
今後はその思考法は控えた方が良いと思います
600 = :
君は建設的な議論をどうしても言論合戦にしたいみたいだね？
そんな極論を言い出すとそもそもAjaxなんてとてもできなくなると思うけど
別に不特定多数へ公開してどう使われるか分からないツールのコードでもあるまいしなんでそんなに微妙なラインに拘るのかね？
もはや問題をベストに解決する方法じゃなくて、相手の言葉尻を取るというか
相手の意見の反論をひねり出すことだけを考えてるよね
別に俺は言論合戦に論理的に敗北したことにしても全然構わないよ
つうかそんなの「状況による」って言うのは簡単だけど、それじゃ答えにならないんだよね
俺が意味がないと言ったのは、道路状況と同じで上を考えるのは基本的に上限があるが下はキリがないというか、
それこそ０に限りなく近いような場合で、上を仮定した意見に下を仮定して文句行ったりすること
例えば『徐行』の速度を説明するときに、「状況に合わせたすぐ止まれる速度」と言うのは容易いが、
そればかりじゃ答えとして弱いから、具体的に速度を述べるとき、普通車で平均レベルの道路状態を想定するだろう
そこで、大型車の場合とか、凍った鉄板上の人混みの中を進むことを挙げてそれを否定するのはやっぱりおかしいんだよ
何故かと言うと、もはや『徐行』云々の話ではなくなるから、そもそもそこを車が通行していいのかというレベルの話だ
もし秒間数アクセスでもサーバが停止しそうなら、それはサーバを労ることを考える以前に
そもそも幾つものリソースをAjaxで取ってきて利用するということは現実的に不可能だと言えるだろう
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript一覧へ類似してるかもしれないスレッド
- + JavaScript & jQuery 質問用スレッド vol.7 + (701) - [100%] - 2022/12/19 17:15
- + JavaScript & jQuery 質問用スレッド vol.8 + (1001) - [98%] - 2019/2/9 14:00
- + JavaScript & jQuery 質問用スレッド vol.6 + (980) - [98%] - 2016/11/20 14:31
- + JavaScript & jQuery 質問用スレッド vol.5 + (993) - [98%] - 2016/6/11 14:30
- + JavaScript の質問用スレッド vol.76 + (1001) - [72%] - 2010/3/10 4:02
- + JavaScript の質問用スレッド vol.87 + (1001) - [72%] - 2011/6/21 6:33
- + JavaScript の質問用スレッド vol.78 + (1001) - [72%] - 2010/6/25 3:53
- + JavaScript の質問用スレッド vol.79 + (1001) - [72%] - 2010/9/11 6:50
- + JavaScript の質問用スレッド vol.77 + (1001) - [72%] - 2010/5/8 19:06
- + JavaScript の質問用スレッド vol.97 + (1001) - [72%] - 2012/3/1 3:31
- + JavaScript の質問用スレッド vol.74 + (1001) - [72%] - 2009/12/1 6:08 ○
- + JavaScript の質問用スレッド vol.75 + (1001) - [72%] - 2010/1/23 1:07 ○
トップメニューへ / →のくす牧場書庫について