+ JavaScript & jQuery 質問用スレッド vol.7 + [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。次スレは>>950が>>2のテンプレ案(本スレで改善案があれば考慮)を元に立ててください
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。 ハローワーク求人119,389件の平均月給197,900円～269,100円
その中からJavaScriptの求人294件の平均月給219,600円～378,500円
http://goo.gl/Rhjoki
その中からjQueryの求人33件の平均月給218,700円～367,800円
http://goo.gl/wxD309
これは微妙だなあ test.htmlのjquery cycleクラス下にdiv要素で囲ったものをスライドショーしてます。
<div><img../></div>
<div><img../></div>
...
この個々にnameやh3などを付加してtest.html#1等の直リンでジャンプさせる方法ないでしょうか？ >>>4
それHTMLの話だろ？
このスレは関係ない。 あと、どこの誰が作ったのかわからん
jQueryプラグインの使い方の話はスレ違い。
そもそも使ったことがある人がまずいないのでレスはつかない。
そういうのは自分で調べてください。 っていうかテンプレが抜けてるのか。ひどいなｗ
JavaScriptで一番有名なDOM用関数型風ライブラリであるjQueryのスレです。
jQueryを使うとJavaScript単体では面倒な処理でもほんの数行で実現可能になります。
一部でもうjQueryは要らない等と言ってますが、あれはjQueryよりも導入が大変な
フレームワークを導入したらいらなくなるって話であって、従来通りHTMLにちょっと
動きをつけたい程度ならjQueryが最適です。
このスレはjQueryそのものの使い方やjQuery UIの使い方やjQueryプラグインの作り方を質問するスレです。
JavaScriptだと面倒だけどjQueryを使えばもっと簡単に書けませんか？というのもOKです。
ですが、jQueryを使って作る側のスレであって、こんなjQueryプラグインありませんか？と聞くスレではありません。
また野良jQueryプラグインの質問スレでもありません。そういうのは自分で探してください。
ろくにサポートもされてなさそうな野良jQueryプラグインの使用はおすすめしません。
前スレ
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/hp/1465566635/ Q. jQueryはどのバージョンを使えばいいのですか？
A. IE9以上であれば、jQuery 3.0を使用してください。
IE8以下にも対応するならば、jQuery 1.12を使用してください。
補足
jQuery 1.9 までは一系統しかなく、古いブラウザも含めて全て対応していました。
その後、古いブラウザを切り捨てるためにバージョンを分岐させました。
古いブラウザにも対応した1系（1.10、1.11、12）と
古いブラウザを切り捨てた2系（2.0, 2.1, 2.2）です。
1系と2系は対応ブラウザの違いだけで機能は全く一緒です。
機能が同じなのにメジャーバージョンが違っているのが分かりにくい
ということでバージョン番号の付け方を変えることになり、
新たに古いブラウザを切り捨てたjQuery 3.0、そして古いブラウザにも対応した
jQuery Compat 3.0がリリースされる予定でした。
しかしマイクロソフトが古いIEのサポートポリシーを変更し
サポート中であるOSで動く、最新のIEしかサポートしなくなったために、
2016年1月でVista上のIE8のサポートが終了しました。
そのため予定されていたjQuery Compat 3.0がなくなり、
jQueryは3.0に一本化されました。 しかも現行スレはこっちだし。
+ JavaScript & jQuery 質問用スレッド vol.6 + [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/hp/1465566635/ >>15
つうか下火だろ
アフィブログとか下らないサイトにしか使われてないイメージ強すぎ >>16
まずjQueryのシェアはずっと増え続けていることは事実なんで認めよう。
> https://w3techs.com/technologies/overview/javascript_library/all
>
> 2016/05から2017/05のjQuery使用率の推移。直近の一年でも2%増えているんだわ
> https://w3techs.com/technologies/history_overview/javascript_library/all
> 70.1% 70.2% 70.4% 70.6% 70.7% 70.9% 71.4% 71.8% 71.9% 72.0% 72.1% 72.2% 72.3% 72.5%
その上でインターネットの大半がくだらないサイトって言いたいならどうぞご勝手に >>17
糞サイトやアフィサイトばかりつかってるイメージ強すぎ >>19
ニュースサイト、ブログサイト、テレビ番組サイト、
ゲーム会社サイトの中からお前が有名だと思うサイトをいくつか書いてみ
jQuery使ってるかどうかは調べないでね >>18
vistがサポート終了したので必然的にｵﾜｺﾝだよ >>20
アレクサー・インターネットの上位サイトの利用率見れば一目瞭然だよ。
jQueryはWPで人気になっただけの駄作ライブラリーな >>22
だから言い訳がましくグチグチ言わないで
上位サイトを幾つか上げれば良いんだよ 例えばアレクサー・インターネットの上位サイトとして
Amazonの名前を上げてくれれば、
そこはjQueryを使ってますと言えるわけだ。 今頃上位サイトの中でjQueryを使ってない所を探してるのだろうか？ >>22
ほとんど使ってないですな
ぶろぐや個人規模の開発能力がないところが使ってるだけなんじゃね？ 話そらそうとしてもむーだｗ
「アレクサー・インターネットの上位サイト」
かつjQuery使ってないサイト言ってみ
アレクサー・インターネットの上位サイトでなければ
認められない。条件が変わったのは自業自得だ。 >>22
駄作ではないけど小規模サイトばかり使ってるのは間違いないかな
まあこの議論はもう何年も前に世界中で言われていることだけどwordpressの普及と密接に関係しているのは事実でアクセス数の多いサイトは依然として利用率が低いです。 アレクサー・インターネットの上位サイトで
jQuery使ってないサイトが殆どなかったから、
今度はアクセス数が多いサイトに逃げたのか？
ちなみにアクセス数が多いwikipediaは
jQueryを使っています。
んで、jQueryを使っていないアクセス数が多いサイトってどこ？
（また同じ質問されると思ってなかったか？） >>22
そりゃそうでしょ
ネイティブより重くなるだけで自前で対処できれば使う必要ないからね >>31
そんなこと聞いていない。
わかってるよね？
あんたが答えられない理由も
周りの人間はわかってるから 結局個人ブログみたいに人気サイトは使われていないってこと？ >>34
さっきからjQueryを使ってないのが当然であるような
会話を続けることによって
周りに人間にjQuery使ってないと錯覚させる手段なのは
見てすぐに分かるよｗ
まずjQueryのシェアはずっと増え続けていることは事実なんで認めよう。
https://w3techs.com/technologies/overview/javascript_library/all
2016/05から2017/05のjQuery使用率の推移。直近の一年でも2%増えているんだわ
https://w3techs.com/technologies/history_overview/javascript_library/all
70.1% 70.2% 70.4% 70.6% 70.7% 70.9% 71.4% 71.8% 71.9% 72.0% 72.1% 72.2% 72.3% 72.5% >>33
無駄な読み込みとか遅くなるから損失に繋がる じゃあ詳細を見ていこうか？
https://w3techs.com/technologies/overview/javascript_library/all
jQuery 72.5% 96.2%
Bootstrap 15.2% 20.2%
Modernizr 10.9% 14.4%
MooTools 3.0% 4.0%
ASP.NET Ajax 2.1% 2.8%
Prototype 1.7% 2.3%
Script.aculo.us 1.4% 1.9%
Moment.js 0.7% 1.0%
YUI Library 0.4% 0.6%
Lodash 0.4% 0.6%
AngularJS 0.4% 0.6%
Underscore 0.4% 0.6%
Shadowbox 0.4% 0.5%
Spry 0.3% 0.4%
GSAP 0.2% 0.3%
Backbone 0.2% 0.2%
Knockout 0.1% 0.1%
Dojo 0.1% 0.1%
Ext JS 0.1% 0.1%
Vue.js 0.1% 0.1% >>34
そういうことになるかな
アレクサーのランキング500サイト調べたらわかるけどほとんど使われてないのが証明になる。 >>41を見てわかるようにjQueryの使用率がダントツで多い
ここでReactとかリストに上がってないじゃないか？って
思うかもしれない。だけど下の方にちゃんと書いてある > The following JavaScript libraries have a market share of less than 0.1%
>
> Semantic UI
> React
> Zepto
> Sizzle
> DHTMLX
> Ember.js
> MochiKit
> p5.js
> DOMAssistant
> UIZE
> Midori
> Google Closure Library
> Webix
> SproutCore
> Glow
> JavaScriptMVC 残念ながら、リストに書いていないのは、
Reactなどの使用率が0.1%を下回るほど使われていないから >>40
>>22
糞サイトも数えたグラフ出してる奴いるけど、人気サイトは使われてないのが良くわかったわ。
ありがとう。 Historical trends in the usage of JavaScript libraries for websites
This report shows the historical trends in the usage of JavaScript libraries since June 2016.
2016
1 Jun 2016
1 Jul 2016
1 Aug 2016
1 Sep 2016
1 Oct 2016
1 Nov 2016
1 Dec 2017
1 Jan 2017
1 Feb 2017
1 Mar 2017
1 Apr 2017
1 May 2017
1 Jun 2017
7 Jun
None 27.0% 26.8% 26.6% 26.5% 26.3% 25.9% 25.5% 25.5% 25.4% 25.3% 25.2% 24.8% 24.7% 24.6%
jQuery 70.2% 70.4% 70.6% 70.7% 70.9% 71.4% 71.8% 71.9% 72.0% 72.1% 72.2% 72.3% 72.5% 72.5% おっと間違えたｗ
jQueryが2016年から毎月ごとに
どれくらいユーザー数を増やしたかが示されている
Historical trends in the usage of JavaScript libraries for websites
None 27.0% 26.8% 26.6% 26.5% 26.3% 25.9% 25.5% 25.5% 25.4% 25.3% 25.2% 24.8% 24.7% 24.6%
jQuery 70.2% 70.4% 70.6% 70.7% 70.9% 71.4% 71.8% 71.9% 72.0% 72.1% 72.2% 72.3% 72.5% 72.5% 次に四半期ごとにどれだけのユーザーがjQueryを使うようになったか
それを示してみよう
https://w3techs.com/technologies/history_overview/javascript_library/all/q
> Historical quarterly trends in the usage of JavaScript libraries for websites
>
> This report shows the historical trends in the usage of JavaScript libraries since April 2014.
> None 37.7% 36.3% 35.9% 35.0% 33.6% 32.0% 30.9% 28.7% 27.2% 26.8% 26.3% 25.5% 25.2% 24.6%
> jQuery 58.2% 59.9% 60.5% 61.5% 63.1% 64.8% 66.0% 68.3% 69.9% 70.4% 70.9% 71.9% 72.2% 72.5%
2014年4月からのデータである さて四半期が来たら次は年。毎年どれだけのユーザーがjQueryを使うようになったかを見てみよう
https://w3techs.com/technologies/history_overview/javascript_library/all/y
> None 61.8% 49.1% 39.6% 38.2% 35.0% 28.7% 25.5% 24.6%
> jQuery 28.3% 42.8% 54.5% 57.4% 61.5% 68.3% 71.9% 72.5%
最初の年は2011年。
毎年のようにjQueryユーザーはどんどん増えている。 つまりjQueryは個人向けサイトやwordpressで作られたサイトに使用されるが、人気サイトではあまり使われていない。
疑問に思うならアレクサー・インターネット上位500社のjQuery使用率を見ればわかります。 さて、まだこれだけじゃjQueryが使用されているのを
信じられない人がいるかもしれない。
そこでこの記事
https://w3techs.com/technologies/cross/javascript_library/ranking
> ランク付けしたJavaScriptライブラリの使い方
>
> この図は、ランキング別に分類されたさまざまなJavaScriptライブラリを使用しているウェブサイトの割合を示しています。
> クロステクノロジーレポートには、結果の統計的有意性を保証するために、
> 1％を超える使用率のテクノロジーのみが含まれています。 調査で使用された方法論の説明については、
> テクノロジー概要を参照してください。
>
> 図の見方：
> jQueryは、私たちが知っているJavaScriptライブラリを持つすべてのウェブサイトの96.2％が使用しています。
> jQueryは、われわれが知っているJavaScriptライブラリが上位1,000,000にランクされている
> すべてのWebサイトの96.3％が使用しています。
めんどくさいのでGoogle翻訳に任せるがこういうこと
JavaScriptライブラリを使ってる96.2%がjQueryを使っている >>55
糞サイトに大人気なのがjQuery
人気サイトはjQueryはあまり使われない。
その証明書はアレクサー・インターネットの上位サイトランキングのjQuery使用率。 そりゃそうでしょ
個人ブログやアフィサイトだらけなんだから・・ このデータからはどの文字コードででよくjQueryが使われているかが示されている
最近はUTF-8に変わってしまったがその多くがjQueryを使っている
https://w3techs.com/technologies/cross/javascript_library/character_encoding
> 文字エンコードで区切られたJavaScriptライブラリの使い方
>
> この図は、さまざまなJavaScriptライブラリを使用しているWebサイトの文字
> エンコーディング別の割合を示しています。 クロステクノロジーレポートには、
> 結果の統計的有意性を保証するために、1％を超える使用率のテクノロジーのみが含まれています。
> 調査で使用された方法論の説明については、テクノロジー概要を参照してください。
>
> 図の見方：
> jQueryは、私たちが知っているJavaScriptライブラリを持つすべてのウェブサイトの96.2％が使用しています。
> jQueryは、私たちが知っているJavaScriptライブラリを持ち、文字エンコーディング
> としてUTF-8を使用しているすべてのウェブサイトの96.5％が使用しています。 >>59
アレクサー・インターネット上位ランキングサイトのjQueryの使用率はかなり低いよ。
200件ほど調べたけど20％以下。 やっぱjQueryは糞サイトに大人気ってことなのかw https://w3techs.com/technologies/cross/javascript_library/content_management
WordPressの話がでたが他のブログ（コンテンツ管理スシステム）でも
jQueryが非常に多く使われているのがわかる
> Overall WordPress Joomla Drupal Magento Blogger Shopify TYPO3 Bitrix PrestaShop Squarespace Adobe Dreamweaver
> コンテンツ管理システムによって分解されたJavaScriptライブラリの使用
>
> この図は、コンテンツ管理システムで分類されたさまざまなJavaScriptライブラリを
> 使用しているウェブサイトの割合を示しています。 クロステクノロジーレポートには、結果の統計的有意性を保証するために、1％を超える使用率のテクノロジーのみが含まれています。 調査で使用された方法論の説明については、テクノロジー概要を参照してください。
>
> 図の見方：
> jQueryは、私たちが知っているJavaScriptライブラリを持つすべてのウェブサイトの96.2％が使用しています。
> jQueryは、私たちが知っているJavaScriptライブラリとWordPressをコンテンツ
> 管理システムとして使用しているすべてのウェブサイトの99.8％が使用しています。 >>61
決めつけることはできないけど少なくとも個人ブログやwordpressサイト管理者からは支持されていますよ。 そしてざっと調べた所以下の有名サイトでjQueryが使用されている。
Amazon
Wikipedia
rakuten
yahoo
Microsoft
というより自社でjQueryと競合するライブラリを作っている所以外は
jQueryを使っていると考えたほうが良い またこのスレではjQueryを使用していない有名なサイトを
募集しているがレスが全然つかないところかも
jQueryを使ってないサイトが少数派であることがわかる
急募 jQuery使ってない有名サイト教えて [無断転載禁止]©2ch.net
http://mevius.2ch.net/test/read.cgi/hp/1496843622/ ここまでありとあらゆる情報を調べたが
大手有名サイトであればあるほどjQueryを
使用していることが明らかとなってる アレクサー・インターネットの上位サイトランキングでのjQuery使用率が低い件 >>69
信者が必死に反論してるけどアレクサー・インターネットのランキング調べたら使われていなくてﾜﾛﾀ 「jQueryは使用されている」という事実は
客観的なデータを用いて証明されているが、
「jQueryは使用されていない」という事実は
データが一切ないところが注目大きな点である
データを出さずjQueryは使われていないと強弁する行為が、
逆にますますjQueryが使用されていることを
印象づける結果となってしまっている。 アレクサー・インターネットの上位サイトランキングでのjQuery使用率が低い
というデータがないのが何よりの証拠でもある。 jQueryは使用されているが、ただしアフィサイトや個人ブログの糞サイトばかりでアレクサー・インターネットの上位サイトランキングでのjQuery使用率が低い件 >>74
実際にみてもデータがなければ認めないとかいうような変な人なんじゃね？ >>70
自分も30件ほどランダムに調べてみたけど実際に使われていなくて驚いた。 なお、これがアレクサー・インターネットのランキング上位サイトのjQueryの使用ぐあいである
1 Google.co.jp
2 Google.com
3 Yahoo.co.jp jQuery使っている
4 Youtube.com
5 Amazon.co.jp jQuery使っている
6 Twitter.com
7 Facebook.com
8 Wikipedia.org jQuery使っている
9 Fc2.com jQuery使っている
10 Rakuten.co.jp jQuery使っている
11 Nicovideo.jp jQuery使っている
12 T.co jQuery使っている
13 Ameblo.jp jQuery使っている
14 Baidu.com jQuery使っている
15 Kakaku.com jQuery使っている
16 Naver.jp jQuery使っている
17 Livedoor.jp jQuery使っている
18 Goo.ne.jp jQuery使っている
19 Hatena.ne.jp jQuery使っている
20 Hatenablog.com jQuery使っている
21 2ch.net jQuery使っている
22 Github.com
23 Amazon.com jQuery使っている
24 Qq.com jQuery使っている
25 Microsoft.com jQuery使っている
26 Qiita.com jQuery使っている
27 Instagram.com
28 Live.com jQuery使っている
29 Weblio.jp jQuery使っている
30 Chatwork.com jQuery使っている なお>>79はサイトのトップでjQueryが使われているものであり
ここに含まれなくても、サイトの何処かで
jQueryが使われている可能性はある アレクサー・インターネットの上位サイトランキングでの
jQuery使用率が高くて驚いた！ 結論としてはjQueryは小規模向けの個人サイトやwordpressサイトのようなブログから必要とされていて、
アレクサー・インターネットの上位ランキングされるような人気サイトからは必要とされないライブラリーという認識であってる？
疑問に思うならアレクサー・インターネットの上位ランキングのサイトを調べてjQueryが使われていないかチェックしましょう。 あってなかった。
>>79を見ての通り
アレクサー・インターネットの上位サイトランキングでの
jQuery使用率が高くて驚いた！ 俺も納得した>>79のように
リスト化されてると信用せざるを得ない。
アレクサー・インターネットの上位サイトランキングで
jQueryが使われてるのは事実だ >>82
500件調べたら結果みないと何とも言えんな。 >>79のように調べ上げたのなら
信じるしかあるまい
その根性に敬礼！ アレクサー・インターネットのランキング上位サイトでも
これだけjQueryが使われているとはな！
>>79乙 ぐうの音も出ねぇ
アレクサー・インターネットのランキング上位サイトで
jQueryが使われているかどうかを一つ一つ調べてくれる人が
いるなんて（驚愕 基地外いるみたいだな・・・
アフィブログに教えておけ 永久保存版だな！
急募 jQuery使ってない有名サイト教えて [無断転載禁止]©2ch.net
http://mevius.2ch.net/test/read.cgi/hp/1496843622/
↑こっちのスレにもコピペしてきたぜ >>79がより正確な情報として
jQueryが使っていることを示してくれた。
サンプル的にAmazonとWikipediaを見てみたが確かに
jQueryが使われていた
ページのソースを見たから確か >>94
一部を切り抜いて編集する報道みたいなやり方かもな？
データないから自分で調べないとわからんわな >>97
一部を切り取ってそこにjQueryが使われていた？ >>97が面白いジョークを言ったｗ
切り抜いた一部にjQueryが使われいたら
それこそjQueryが使われてる証拠だろうｗ 基地外テレビ番組のニュース報道みたいなアレか・・
取り合えず自分で調べられないから500件のうちどのくらい使用しているか割合教えてくれ。 例としてyahoo.co.jpだとこんな感じでjQueryが使われていたよ
view-source:https://news.yahoo.co.jp/pickup/6242487
<!-- ニュース利用 -->
<script type="text/javascript" language="JavaScript" src="https://s.yimg.jp/images/jpnews/js/libs/jquery/1.10.2/jquery.min.js";></script>
<script type="text/javascript" src="https://s.yimg.jp/images/news/lib/underscore/underscore-1.4.4.min.js";></script>
<script type="text/javascript" src="https://s.yimg.jp/images/rapid/1.5.0/ult.js";></script>
<script type="text/javascript" src="https://s.yimg.jp/images/jpnews/js/libs/backbone/1.0.0/backbone.min.js";></script>
（略）
<script type="text/javascript">
<!--
(function($){
$(document).ready(function(){
// 埋め込むステッカーの種類分、記述してください。
YAHOO.JP.Follow.Sticker.init({
'stckrClass' : 'yjxTheme',
'stckrSize' : 'wide',
'isCache' : $('.modTheme').data('theme-iscache'),
'stckrType' : 'list',
'frameWidth' : '100%'
});
// 1ページ内で1回のみ、記述してください。
YAHOO.JP.Follow.Sticker.bind();
});
})(jQuery);
//-->
</script> >>79-89
ネラーならこれを見たら何をしているかわかるだろ
察してやれ <script type="text/javascript">
$(function(){
$('div.headline').each(function(){
var $div = $(this);
var $hide = $('.headlinePic',this);
var $img = $('img',this);
var $url = $img.attr('data-src');
if ($url === void 0) {
return;
}
var imgObj = new Image();
$(imgObj).one('error',function(){
$hide.remove();
$div.removeClass("hasImg");
});
$(imgObj).one('load',function(){
var w=imgObj.width,h=imgObj.height,dw=$img.attr('data-width'),dh=$img.attr('data-height');
if(w > dw || h > dh) {
if(w/dw > h/dh) $img.css('width',dw+'px');
else $img.css('height',dh+'px');
}
$img.attr('src', $url);
});
imgObj.src = $url;
}); Amazonだとminifyされてこんな感じでjQueryが使われていたよ
view-source:https://www.amazon.co.jp/
<script type='text/javascript'>
(function(){function l(a){for(var c=b.location.search.substring(1).split("&"),e=0;e<c.length;e++){var d=c[e].split("=");
if(d[0]===a)return d[1]}}window.amzn=window.amzn||{};amzn.copilot=amzn.copilot||{};var b=window,f=document,g=b.P||
b.AmazonUIPageJS,h=f.head||f.getElementsByTagName("head")[0],m=0,n=0;amzn.copilot.checkCoPilotSession=function(){
f.cookie.match("cpidv")&&("undefined"!==typeof jQuery&&k(jQuery),g&&g.when&&g.when("jQuery").execute(function(a){k(a)}),
b.amznJQ&&b.amznJQ.available&&b.amznJQ.available("jQuery",
function(){k(jQuery)}),b.jQuery||g||b.amznJQ||q())};var q=function(){m?b.ue&&"function"===typeof b.ue.count&&
b.ue.count("cpJQUnavailable",1):(m=1,f.addEventListener?f.addEventListener("DOMContentLoaded",amzn.copilot.checkCoPilotSession,!1): >>103
>>
>>79-89
ネラーならこれを見たら何をしているかわかるだろ
察してやれ WikipediaにもjQueryって文字が見えるな
view-source:https://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8
s@0bc2kh0",function($,jQuery,require,module){mw.user.options.set({"variant":"ja"});});mw.loader.implement("user.tokens@1dqfd7l",function ( $, jQuery, require, module ) { 中立派だったが、ここまでjQueryが大手サイトで使われている
証拠を示されると、jQueryは大手サイトで使われてると
認めざるをえないな >>112
>>79-89
ネラーならこれを見たら何をしているかわかるだろ HTMLはソースコード見れるから、
すぐに調べられてjQuery使ってることが
誰でもわかるんだから、ウソ付いたってしょうがない >>113
何度も同じこと書かなくていいよｗ
そういうのが「必死」だって言われるんだよ？ >>114
だな。
>>79-89
ネラーならこれを見たら何をしているかわかるだろ
察してやれ >>
>>79-89
ネラーならこれを見たら何をしているかわかるだろ
察してやれ
基地外かよw そういやプログラマ板でもこの話題のスレあったな。
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
http://medaka.2ch.net/test/read.cgi/prog/1485008061/
あっちはこっちと違って比較的まともな人がいるから
そりゃそうだろって流れになってる >>103
ネラーでなくてもわかるんだがw
>>79-89 >>79-89
言ってることはわかるが香ばし過ぎでそれどころじゃないだろw http://blog.goo.ne.jp/spoichi/e/bc415d2eff4c645cad642195c1957c38
> だからこそ荒らしに対しては無視・無反応・放置が推奨されているわけですが、
> 荒らしをするような人にはもう一つの特性として、「同じような似たり寄ったりの
> 内容を3回程度連続で書き込むことが多い」という習性もあります。
あ、3回連続・・・（察し >>114
これなんだよな。
だけど面倒くさいわな >>79-89
500件のうち何割ぐらい使用されているか折角だから全て調べてください。 >>120
ﾜﾛﾀw
>>79-89
破壊力半端ないな >>126
500件よりももっと多くを調べた結果
https://w3techs.com/technologies/overview/javascript_library/all
jQuery 72.5% 96.2%
Bootstrap 15.2% 20.2%
Modernizr 10.9% 14.4%
MooTools 3.0% 4.0%
ASP.NET Ajax 2.1% 2.8%
Prototype 1.7% 2.3%
Script.aculo.us 1.4% 1.9%
Moment.js 0.7% 1.0%
YUI Library 0.4% 0.6%
Lodash 0.4% 0.6%
AngularJS 0.4% 0.6%
Underscore 0.4% 0.6%
Shadowbox 0.4% 0.5%
Spry 0.3% 0.4%
GSAP 0.2% 0.3%
Backbone 0.2% 0.2%
Knockout 0.1% 0.1%
Dojo 0.1% 0.1%
Ext JS 0.1% 0.1%
Vue.js 0.1% 0.1% >>105
>>79-89のレス読めばわかるだろうに・・・ >>128
人気サイトランキングの使用率調べてくださいな。
アレクサー・インターネットの上位ランキング500とそのデータの比較ではっきりするんじゃね？
>>79-89
このレスどうなってるんだよw >>125
結局比べないとわからないんだから、 >>79-89 みたいに少しでも調べて比較した方が信用できるよ。 >>128
このサイトはアフィブログや個人サイトが大多数ってこと？ wordpress使いには必須ライブラリなんだけどな アレクサー・インターネットの上位ランキングだけでも
23/30 = 76.67％ で
https://w3techs.com/technologies/overview/javascript_library/all
全体の72.5%がjQueryを使っているというデータとほぼ一致するんだな × これまで毎年jQueryのシェアが増えていたんだな
○ これまで毎月jQueryのシェアが増えていたんだな 毎年のデータはこっちか
https://w3techs.com/technologies/history_overview/javascript_library/all/y
jQuery 28.3% 42.8% 54.5% 57.4% 61.5% 68.3% 71.9% 72.5%
+14.5%
+11.7%
+2.9%
+4.1%
+6.8%
+3.6%
+0.6%（半年）
一応伸びは鈍化してるね。このペースだと
今年は1.2%しかシェア増えなさそう jQueryは情報系サイトにとってバランスが良いんだよな。
全体をJavaScriptフレームワーク化するまでもなく
HTML+CSSにちょっと動きをつけるならばjQueryが適している。
ウェブの世界で情報系サイト以外って殆ど無いし
情報系以外っていうのは例えばゲームとかビジネスアプリとかそういうやつ 個人的にはAmazonがjQueryをバシバシ使ってるってのが
驚きだったな。なんとなく使ってなさそうな気がしていた。
ソースコード見ると結構jQuery使ってるコードが見つかったよ >>143
リンク付きはいつもの基地外かもしれんよ >>143
http://mevius.2ch.net/test/read.cgi/hp/1456242505/
リンク付きの輩はここにわく基地外と書き込み内容似てる
図星なら反応するかもね
>> jQueryがどれだけ使われているかわかるレス↓
>>43-48
>>51-53
>>79-89
>>136-139
ここにも酷似しているレスがありますね ピークは何年前なの？
このペースみてると減る可能性もあるんだけども他伸びてるライブラリーとかあるの？ jQueryのピークはまだ迎えていない。
未だシェアは伸び続けている。
他に伸びているライブラリはないと言ったほうが良い。
jQueryに比べれば圧倒的にシェアは少ない。
一部のアプリはjQueryを使って実装するのは複雑すぎて大変
そういった用途でjQueryに変わるものは出てきているが
それはjQueryよりも簡単にするものではない。
jQueryよりも数倍面倒な技術を導入することで、
大規模なJavaScriptアプリでも複雑にならないようにするもの。
殆どのサイトは、そもそも大規模なJavaScriptアプリを作らないので
数倍面倒になる技術を導入するだけで終わり。メリットがない。 >>147
伸び率のグラフにしたら下り坂じゃない？
いつが一番伸びたの？ 伸び率のグラフってなんだそそりゃ？
意味不明なグラフを捏造しないように。 >>148
伸び率ピークは2013年で以降は右肩下がり
バージョン使用率は9割以上のサイトが1を使用
昔と比べてクロスブラウザの問題が減ってきているにも関わらず1を使用している。
2や3はそっぽ向けられた状態でターニングポイントをむかえたときが卒業するときかもしれないな。 >>149
シェア率増加グラフのことだな
何年度に商品が一番普及したかピークを知るためのデータのこと >>152
いや、だからなんだ？と
シェアって言うのは最大100%なわけで、
今月50%増えました。今月20%増えました。
って時、30%も減った！なんて言わないぞｗ
増えてるんだから。 よくいるんだよね。Windowsだとシェア91%から
シェア90%になった時、わずか1%しか減ってないのに、
某OSは1%から2%になったら2倍だ！みたいにいうやつ。
シェア＝割合 の 割合 を言ってどうするんだとｗ jQueryの使用率、増え方が鈍化しただけで
まだ増えてるんだね。
使用率が高くなったら増えるのが鈍化するのは
jQueryにかぎらず当たり前の話だと思う。
なにせ72.5%も使われているわけだし。
それでも今年6ヶ月で0.6%も増えてるわけだしね つまり一番伸びた時期のデータは意味がないと言うこと？ >>156
シェア率増加データは、普及率のピークを知ることができる重要なデータです。
この手のデータは、シェア率増減の要因が見えてくる重要なものなのです。
シェア率増加はあらゆる業界で利用されています。
ピークを見極めて維持・新商品投入など経営判断の材料の一つにされるデータとなるからです。
シェア率増加データには、山型、谷型、右肩左肩、並行、様々なタイプがありますが、jQueryは典型的な山型データを示しています。
一般的に山型はピークを過ぎたあとは並行時期に入ります。
そして下りに入ると再上昇はなく消滅するまで下がり続けます。
勿論例外もありますがデータからわかるようにシェア率増加のピークが2013年となっており、以降は増加が鈍化・並行状態です。
そして今年に入り躊躇に現れています。 >>157
> シェア率増加データは、普及率のピークを知ることができる重要なデータです。
いや、それではわからんよ。
2000年から毎年1%ずつ増えていくというデータが有った所で
普及率のピークがいつかわからんだろ？
仮に1年で0%、全く増えなかったとしても、その次の年に増えれば
普及率のピークは次の年以降ってことになる。
もちろん下がったとしても次の年上がることもある。
な？どうやってシェア率増加データとかいう胡散臭いもので
普及率のピークがわかるのか教えてくれよ > シェア率増加データには、山型、谷型、右肩左肩、並行、様々なタイプがありますが、jQueryは典型的な山型データを示しています。
https://w3techs.com/technologies/history_overview/javascript_library/all/y
jQuery 28.3% 42.8% 54.5% 57.4% 61.5% 68.3% 71.9% 72.5%
典型的な山形データというのは、下がることがあった場合だろ？
jQueryのシェアはずっと上がり続けている。これは驚異的なことだよ >>161
型にはまるまでピークはわからんのよ。
jQueryは山型の特徴を示しているのでピークは鈍化前の2013年となるかな 書き忘れたので追記
ビジネスではシェア率系の様々なグラフがあるけど、ピークを見極めるのは重要なこと。
そしてデータをグラフ化したときの型をみれば山型のパターンにが合致するよ。
他の型に酷似するなら、それを教えてくださいな。 >>163
> jQueryは山型の特徴を示しているので
jQuery "以外" で山型の特徴をもってるグラフを出してみ。
それが本当にjQueryと似ているか比べて見るから。
典型的な山型データなんだろ？
なら簡単に出せるはずだ。
書き忘れないように言っておく
逃げんなよ？ >>158
https://w3techs.com/
このサイトの公表データでは
version1 91.6%
version2 6.8%
version3 1.6%
jQuery通常版サイズ
version1.12.4 293,430B
version2.2.4 257,551B
version3.2.1 268,039B
コードを短くし可読性を無視したjQueryの.mini版
version1.12.4 97,163B
version2.2.4 85,578B
version3.2.1 86,659B 今このスレに来たばかりで話がわからない人のために
簡単に書いておくと、
リリース後、急激にシェアが増えて、
今まで一度も下がること無く、シェアが増え
ようやくシェアが安定するものを
「山型のデータ」というらしい。
俺の知る限り、リリース後に急激にシェアが増えるのは
よくある話だし、一定の値になるとシェアが飽和状態になるのは
典型的なヒット商品のグラフだと思っている。 > コードを短くし可読性を無視したjQueryの.mini版
min版っていうのは、ソースコードとバイナリの関係と一緒で
普通バイナリを読まないしバイナリに可読性が関係ないのと同じく
min版に対して可読性とかいう言葉を使うのはアホである >>166
jQueryの1と2って機能的には
同一だったよね？ >>165
グラフは仕事で使いなれてるから割りと詳しいぞ。専門用語を使うと混乱すると思うのでイメージができそうな言葉で説明しておきます。
シェア率系のグラフの型の種類は4つに分けられる。
均一、山、U型の谷、歪曲
基本は4つ。
型にはそれぞれ特徴があり、その型の特徴が出ていれば凡そシェア率のピークが予想できる仕組みになっています。
均一
平均的な位置があり、増減しつつも山や谷のような大きな変化もなく均一の状態を維持する型。
波も均一型の一種。老舗商品やロングセラー商品に多い。
歪曲
徐々に増加して後半急激に伸びる。または、最初の失墜が激しくあとはゆっくり減り続ける。
歪曲のあとは、山やU型の谷に変化する場合が多い。
U型の谷
文字通りUの字の型。
最初は高く失墜したあとに回復するタイプ。
合併会社の商品やライバル会社からシェアを奪ったときに示されるデータ。
山
はじめは低く徐々に増え鈍化する。鈍化したところがピークで均一または減り出し、その後は失墜する。
大半の商品やサービスはこの型にはまる。
jQueryのシェア率増加では、公開されているデータを型にはめれば、鈍化したところまでが山型と合致しています。
他の型に特徴が当てはまれば、迷いは生じますが、それが無いので現時点では山型と判断できるわけです。
ようするに完全に特徴が一致しなくても、現在まで公開されているシェア率の数値データをみて、どの型に一番近いか判断できれば凡そ予想がつくということです。 >>166
1ばかり何故にこなに使われているんだ？ >>170
うん。でそれがお前が考えた
でたらめでないことを証明するのはまだかい？ >>171
いや、普通にjQueryの1と2は機能的には同じなわけで
対応ブラウザは1の方が多いからじゃないの？
ファイルサイズ12KB減らすために対応ブラウザを減らす価値はないとの判断 > 均一
> 平均的な位置があり、増減しつつも山や谷のような大きな変化もなく均一の状態を維持する型。
jQueryはまさにこれだな jQueryはこれから大きな変化もなく均一の状態を維持する型に
なりそうだね。 いつの間にかjQueryは今多く使われているという
前提の話になってんのなｗ
まあ事実なんだが。 jQueryよりも簡単に使えて同等以上の便利さが
手に入るライブラリがないってのがね
今使っている人が他に乗り換える理由がないんだよ 伸び率のピークを迎えたところまで見たら歪曲の特徴で完全一致していますが、以降の数年間は伸び率が鈍化しているので山型の特徴に変化しています。
歪曲は山型やU型に変化しやすいけど、数年で均一になることはありえません。
理由は全体的に見た場合であれば、現在シェア70％で開始時から伸び率が増え続けているからです。
現在は伸び率のピークが鈍化しており、数字でわかるようにここ数年で歪曲から山型に変化しています。
ビジネス的な考え方であれば、このタイミングで既に主力にかわる新商品が投入され伸びてなくては行けません。
または主力商品を維持させるために力を注ぐ場面です。
jQueryの場合であれば新商品は別バージョンのライブラリーにあたるんですけどね。
>>166 jQueryは減ってなくて、高い状態で止まってるのでこれに当てはまりますね
> 均一
> 平均的な位置があり、増減しつつも山や谷のような大きな変化もなく均一の状態を維持する型。
> 波も均一型の一種。老舗商品やロングセラー商品に多い。 >>182
jQueryのシェア率増加データ
https://w3techs.com/technologies/history_overview/javascript_library/all/y
2011年1月 28.3%
2012年1月 42.8%
2013年1月 54.5%
2014年1月 57.4%
2015年1月 61.5%
2016年1月 68.3%
2017年1月 71.9%
2017年6月 72.5% ※最新
このデータをグラフ化
https://w3techs.com/diagram/history_overview/javascript_library/all/y
このデータを見ると2013年まで急上昇しています。それ以降は緩やかに上昇しているのがわかります。均一であれば、2011年度・それ以前も70%付近で推移されているはずですが、過去のデータも見ても確認できません。
上昇を続けているだけです。
対象となるものにもよりますが、データといものは一定期間以上のものを見て判断されます。
4～5年以下の短命な商品であれば月別にならざるをえませんが、jQueryはそうではありませんよね。
2011年以前も上昇を続けていることから、均一型であれば開始されてから現在まで均一状態を示しているはずです。
一般的には均一と判断するにはデータの半数以上が均一状態となります。ちなみに30年、40年、50年と長いデータであれば区切りされ10年おきの区間別の型が出されることもあります。
【jQueryのシェア率増加データの特徴】
開始時からとまることなく上昇を続けている
シェア率増加のピークは2013年
以降は鈍化上昇を続ける
開始時から現在までのデータを型にはめると一番近いものは山型 >>182
>>175
学校でテストの平均点を調べるのにクラス全員ではなく一部の人達のデータだけを抜き取り判断しているようなものじゃない？
全体像を見るにはより多くのデータを調べた方が精度が増すと思うんだが・・・ >>184
近いグラフ見つけたよ。jQueryはスマートフォン契約数の推移・予測と似てるんだ
http://news.mynavi.jp/news/2014/05/03/030/
折れ線グラフのほうが比率（シェア）
一番上が100%
スマホが登場してからすぐにシェアがあがり
近年になるほどシェアの伸びは低くなっていくが下がることはない。
jQueryのシェアと完全に一致してるね。
jQueryとの違いは、jQueryよりも短い時間で70%を超えているという所
だからスマホの今の契約者比率が、そのままjQueryの未来につながるだろう。 >>184
> 開始時から現在までのデータを型にはめると一番近いものは山型
じゃあjQueryを使わない場合は、谷型なん？
いつ上がるの？上がらないよね？底なしの谷？ ChromeのシェアもjQueryに近いね
https://www.netmarketshare.com/browser-market-share.aspx?qprid=1&;qpcustomb=0&qpsp=197&qpnp=23&qptimeframe=M
毎年シェアを増やし続けて近年は伸びが緩やかになっている
だけど一度もシェアが下がったことはない。
典型的な山型グラフだ。jQueryと一緒の山型グラフだ 下がらない山型＝右肩上がりのグラフって言わねーか？ｗ >>186
> 全体像を見るにはより多くのデータを調べた方が精度が増すと思うんだが・・・
だから多くのデータを調べた精度がこれ
jQueryのシェア率増加データ
https://w3techs.com/technologies/history_overview/javascript_library/all/y
2011年1月 28.3%
2012年1月 42.8%
2013年1月 54.5%
2014年1月 57.4%
2015年1月 61.5%
2016年1月 68.3%
2017年1月 71.9%
2017年6月 72.5% ※最新
少ないデータから判断してほしい！って言ったやつのセリフが
「アレクサー・インターネットのランキング上位サイト」これｗ 統計学での分布は現時点でのデータを元に決まるものだから、山型になります。
これからのデータについては、分布型ではなく予想と言います。 >>169
ほとんど同じだね。
サポート切れのIEのために使っているようなものだろ。
>>182だけでなく↓も頭逝ってそうだ
>>175
>>176
俺みたいな素人でも右に上がっているのがわかるんだがw 196だけど勘違い。
>>176はこれからの話か
それなら可能性はあるな
気になったのでググってみたけど均一の状態とは名前通り均一みたいがらそのように判断されないかも知れない 186 データやグラフ見れない人多過ぎです。グラフ化されたデータは変化の無い部分は省略されることはあるけど特徴が出ている部分は把握しなくては判断できません。
自分に都合の良いように解釈を行い事実と異なる主張をしている人が目立ちますね。
>>187 予想するのは自由です。
>>188 自分はjQueryのグラフの話題を見つけたので参加しました。使わない場合は知りません。ご自由に予想してください。jQueryは現時点では、左の歪曲から山型に移項している状態です。
ここからさらに上昇すれば左の歪曲となり下がれば完全な山型分布です。これより数年間70％不均を推移しても一番近い型は山型分布となります。
>>189
>>ChromeのシェアもjQueryに近いね
https://www.netmarketshare.com/browser-market-share.aspx?qprid=1&;qpcustomb=0&q
psp=197&qpnp=23&qptimeframe=M
jQueryの場合途中までは左の歪曲の特徴を示しています。鈍化した状態からは緩やかな右肩上がりなので全体分布とするならば山型の特徴を示しています。
Chromeは順イールド状の右肩上がりでjQueryとは全く異なります。
これは犬と猫を見間違えるぐらい有り得えないことです。
jQueryのシェア率増加データ https://w3techs.com/technologies/history_overview/javascript_library/all/y
ブラウザのシェア率増加データ(こちらも定番サイトで見やすいですよ) http://gs.statcounter.com/browser-market-share#monthly-201101-201705
>>192 jQueryのシェア率データは均一ではありません。現在までのデータで判断するならば、山型の分布に特徴が一番近いというだけです。
>>182 >>175 この人たちの言ってることは間違いです。
197 自分は統計学で均一分布(変化なく横這い状態が続く分布)と習いましたが、一般的にグラフで均一と言えばデータの半分以上が横ばいのことを指すことが多いです。
グラフの形状は知識があれば誰にでも型の区別はできるけど未来の予想は非常に難しいです。その商品を扱っている社の者ですら予想通りの結果に中々なりません。 だからさ、山型って言ってるやつ？
問題は、その山がいつ下るのか？だろ？
jQueryは少なくとも5年はこのままの高シェアを維持するだろうさ
未だシェア増えてるわけだしjQueryに変わるものが登場してない。
5年は少なくともだ。俺の見込みでは10年は変わらないと思う 一年でシェアが10%になりました。
二年でシェアが20%になりました。
このペースで行けば15年後にはシェアは150%です。
とか思ってそう。
シェアのグラフは、同頑張っても最大100%にしかならん。
よって最も成功した商品であっても、jQueryと同じように
後半は伸びは鈍化する。というかjQueryが最も成功した商品の一つ。 > シェアのグラフは、同頑張っても最大100%にしかならん。
> 後半は伸びは鈍化する。
え？なんで？ >>201
そりゃそうだろ。例えば売上とかなら理論上は上限はないから
ヒットした商品ならどこまでも売上は上がるだろうが、
シェアという割合のグラフの場合は100%が上限と決まっている
具体的な数値で説明するが、その前に話を簡単にして
jQueryを使うか使わないかの2つしかない状態とする。
jQuery登場以前、世界中の1億サイトがjQueryを使ってないとする
この時、jQueryのシェアは0%で、使ってないサイトは100%だ
1年で1億サイト増えたとする。jQueryを使ってないサイトは依然使っていないまま
新しく増えたサイトは全てjQueryを使う。その場合2億サイト中1億がjQueryを使うので
ドカンとシェアが増える。jQueryのシェア50%、使ってないサイト50%。
ここで重要なのがjQueryのシェアが50%も増えたという事実
そして次の1年でも1億サイト増え、その全てがjQueryを使う。そうすると
3億中2億がjQuery、1億が使わない。だから66%がjQueryで33%が使わない。
どうだ？びっくりしたろ？ 1年目と増え方は何も変わってないのに
いきなり16%しか伸びなくなった。
その次は 75%:25% で9%しか伸びない
その次は 80%:20% で5%しか伸びない
その次は 83％:17% で3%しか伸びない
売上みたいな絶対的な数値と、割合という相対的な数値では
考え方が大きく違うんだよ。 >>161-162>>165>>175
統計学を理解されていない証拠の書き込み
>>199
現時点でのデータから分布を判断するのと未来予想の分布はマッタク異なるので関係問題にはしません。
最後にもう一度問います。
あなた現在までのデータをみて均一型と山型のどちらが近い状態と判断しますか？ > あなた現在までのデータをみて均一型と山型のどちらが近い状態と判断しますか？
未来予測の分布は全く当てになりません。
だからあなたの予測も当てになりません。 山型山型と言っておきながら、
未来の分布はわかりませんとか
自己否定していることに気づいていないのだろうかねｗ >>206
均一型だと主張している者がいたので説明しただけの話です。
あなた現在までのデータをみて均一型と山型のどちらが近い状態と判断されます？ > 均一型だと主張している者がいたので説明しただけの話です。
はい。だから俺は
山型だと主張している者がいたので説明しただけの話です。
今までシェアが一度も下がってないデータが、
これからシェアが下がり続けて行けば山型になるだろうし、
誤差レベルのぶれはあれど、数年間安定していれば均一型。
これが答えです。
未来の分布はわからないので、今決定することに
何の意味もありません。 >>205
回答されないんですか？
あなた現在までのデータをみて均一型と山型のどちらが近い状態と判断しますか？
そして私は予想は一切していません。分布型というのは現在までのデータをみて判断するものであって未来予想は含めません。
統計学を理解されていない証拠がまた一つ増えましたね。 > あなた現在までのデータをみて均一型と山型のどちらが近い状態と判断しますか？
回答してるじゃん？
現時点ではわからない。
わからないことを山型と決定してるから
お前は恥をかいてるんだよｗ 割合なんだから、ずっと同じペースで伸びていくわけないんだよ。
それが分かってないんだろうな。
事実としてわかってるのは、jQueryのシェアは
登場して数年、伸び続けているということ。
一度も減っていない。 定期的に貼っておこうかｗ
jQueryのシェア率増加データ
https://w3techs.com/technologies/history_overview/javascript_library/all/y
2011年1月 28.3%
2012年1月 42.8%
2013年1月 54.5%
2014年1月 57.4%
2015年1月 61.5%
2016年1月 68.3%
2017年1月 71.9%
2017年6月 72.5% ※最新 >>208
回答になっていません。
現時点までのデータがどの分布型に一番近いか聞いてるんですよ？
私は山型だと判断しています。
統計学ではこのような一部の特徴を持ったデータを判断するテストを行います。 >>210
山型と均一型の特徴を理解されてないから答えられないということですか？
jQueryのシェア率データには明らかな特徴が出ているんですが？
それでもわからないと言うんですか？ >>213
> 私は山型だと判断しています。
それがお前が統計学を分かってない証拠。
山型であるためには後半が下がってないといけない。
だけどjQueryは後半も伸び続けている。
他の山型のグラフと見て一致してないので、
現時点で山型と断定することはできない。 >>214
> jQueryのシェア率データには明らかな特徴が出ているんですが？
割合のグラフで、一度もシェアが下がってないという
明らかな特徴から、山型と判断したと？
なぜ？ シェアが下がらない＝山型なんですか？ >>211
その現時までのデータを見て現時点でどの分布型に一番近いか聞いてるのです。 >>217
現時点のデータから断定はできないから、
予想しろって話？
予想なら意味ないですよねｗ
事実のみを言ってみましょう。
言えなさそうだから代わりに言ってあげましょう
jQueryは登場してから今まで一度もシェアが下がったことがありません。 >>218
jQueryの事忘れたら？ｗ
割合のグラフで、一度もシェアが下がってないという
明らかな特徴から、あなたは山型と判断したというわけですよね？
ちょっと数学板ででもjQueryのことを伏せて聞いてみましょうかね（大爆笑） >>216
分布型について説明されているのでレス読みましょう
そして断定もしていませんし予想もしていません。
分布型というものは現在までのデータを見て型の特徴が一番多いものから判断上されます。
で、現在までのデータをみて山型と均一型のどちらが一番近いものと判断できますか？ あははｗ まじでたてられちゃったｗ
グラフから読み取る統計学の基本入門 [無断転載禁止]©2ch.net
http://rio2016.2ch.net/test/read.cgi/math/1497075809/ >>221
> で、現在までのデータをみて山型と均一型のどちらが一番近いものと判断できますか？
両方に当てはまる可能性がある。 >>223
> その特徴に一番近い型はなんですか？
今後数年でシェアが下がらなければ均一型 答えたくない理由でもあるんですかね・・・
統計学ではデータをみて分布型を答えるテストがあるですが、回答されないと君のような人はテストで点数をとれません。
困ったものです。 >>224
それだと統計学のテストだと×になりますね。 均一型といいっても、最初から均一型だったわけじゃないからな。
だってそうだろ？ 最初のうちから高いシェアになるわけない。
販売前は当然ゼロだし、販売直後から一気に安定したシェアになるわけじゃない。
均一型には必ず伸びている期間というものがあるんだよ。
均一型となるもののデータの登場直後を持ってきてみればわかる。
均一型の登場直後 = 山型の山になるまでの部分
この2つはほぼ一致する。そしてこれがjQueryのグラフ >>225
分布型は現在あるまでのデータのみを示すものです。
未来のことは気にしなくて良いんですよ。
そして特徴が完全一致しなくても一番近いものが分布型となります。 >>229
現時点というのは、シェアがこれまでずっと伸びていて
一度も下がってないデータだよね？
それをお前が認めてくれないと
話が進まないんだが？ 一言言ってくれないか？
「jQueryは今までシェアが伸び続け一度も下がってない」
↑これをコピペしてくれるだけでいいんだよ？ >>228
だから均一は稀なんです。
シェア率増加データでは大半は山型ですからね。
それで現在までのデータをみて一番近い特徴をもった型は均一なんですか？ >>230
データをみて最初から理解していますが？
誰かと間違えていませんか？
私が判断した結果は以下の通り。
jQueryは左の歪曲から山型に移項している状態です。
そしてシェア率増加のピークは2013年ということです。
よって山型分布に一番近い特徴を示しています。
君はこれを均一だと思うのですか？ グラフを見る時、一部のグラフだけ見て、
それが全体のグラフだと思ったらだめだよ。
統計学語るものとしては失格
例えば、どんなデータにだって、伸びているときと
伸びていない時がある。伸びているところだけを抜き取って
増えていると判断してはいけない。
これを見ると良いよ。
実は昔の方が圧倒的に多かった少年犯罪
goo.gl/EQem5z
よく見る少年犯罪が増加しているというグラフ
[ 平成1年から切り取った最近少年犯罪が多いとされるグラフ ]
でもこれ、実は嘘でした。少年犯罪は昔より今のほうが圧倒的に減っている
[ 昭和20年からのグラフ ]
このように一部だけを見ても正しい判断はできない >>233
認めたくないのか理解できないのかわからないけど、統計学のテストでそのような回答したら確実に×になります。 >>234
> 君はこれを均一だと思うのですか？
だから、両方に当てはまるって言っただろ
おまえ馬鹿か？ 人の話をちゃんと聞け
勝手に人の意見を捏造するな >>236
シェアが伸び続けるデータを見て、山型と判断しても×だよｗ おや？ せっかく短縮URLにしたのにリンクになってなかったｗ
グラフを見る時、一部のグラフだけ見て、
それが全体のグラフだと思ったらだめだよ。
統計学語るものとしては失格
例えば、どんなデータにだって、伸びているときと
伸びていない時がある。伸びているところだけを抜き取って
増えていると判断してはいけない。
これを見ると良いよ。
実は昔の方が圧倒的に多かった少年犯罪
https://goo.gl/EQem5z
よく見る少年犯罪が増加しているというグラフ
[ 平成1年から切り取った最近少年犯罪が多いとされるグラフ ]
でもこれ、実は嘘でした。少年犯罪は昔より今のほうが圧倒的に減っている
[ 昭和20年からのグラフ ]
このように一部だけを見ても正しい判断はできない >>238
どの型に一番近いものを聞いているのです。
統計学のテストでも良く出たんですがね・・・
あらゆるデータをみて型と理由を述べる問題の類いです。
分布型を答えるのに未来のことは気にしなくて良いです。
話をそらしてるに過ぎません。
現時点で一番多く特徴が含まれているものを聞いているんです。
ググるなりして均一を調べてみてください。 両方だとか均一の最初に似ているねとか・・・
分布の意味すら全く理解されていないと言うことですかね。 >>240
だから均一の最初の部分と、山型の伸び続けている
部分の両方に当てはまるって言ってるじゃん。
なんで自分が勝手に予想した想像上のグラフが
どれに近いかなんて話をしてるんだよ。
意味ね～じゃん
それとも「シェアが伸び続けるグラフ」に対して
均一と山型以外の当てはまるグラフがあるのか？
現時点ではどれにも当てはまっていない。 グラフの一部だけ見て判断するやつは
↓これにも騙されてる
実は昔の方が圧倒的に多かった少年犯罪
https://goo.gl/EQem5z
よく見る少年犯罪が増加しているというグラフ
[ 平成1年から切り取った最近少年犯罪が多いとされるグラフ ]
でもこれ、実は嘘でした。少年犯罪は昔より今のほうが圧倒的に減っている
[ 昭和20年からのグラフ ] >>243
一度近い分布型を聞いているのです。
答えられないということですか？ 回答は4つ。
山、均一、歪曲、U谷
>>230
データをみて最初から理解していますが？
誰かと間違えていませんか？
私が判断した結果は以下の通り。
jQueryは左の歪曲から山型に移項している状態です。
そしてシェア率増加のピークは2013年ということです。
よって山型分布に一番近い特徴を示しています。
均一であれば最初から70％付近を横這いに推移しているデータが見られるはずです。 グラフでウソをつく方法――統計リテラシーのための基礎文献
https://news.yahoo.co.jp/byline/soichiromatsutani/20150216-00043032/
ウソグラフの世界
ここ数年、統計学がブームとなっています。オープンデータやビッグデータなど、
IT化の進展とともにそれまで以上にさまざまな数字が扱われるようになっています。
そんな統計において、欠かせないものがグラフです。数値を図形化して視覚的な理解を
うながすグラフには、棒グラフ、折れ線グラフ、円グラフなどなど、さまざまな種類があります。
ただ、意図的かどうかはさておき、作為が加えられたグラフを見かけることも珍しくありません。
数値に手を加えることはもってのほかですが、それよりも目立つのは見せ方を工夫（作為）して
実際の数値以上の効果や影響を錯覚させようとするものです。そうしたものは、「ウソグラフ」あるいは「クソグラフ」などと呼ばれたりします。
それでは、こうしたウソグラフにはどういうものがあるのでしょうか？ これ読んだほうが良いよｗ
グラフを作るための基礎文献
ダレル・ハフ『統計でウソをつく法――数式を使わない統計学入門』（講談社）
ダレル・ハフ『統計でウソをつく法――数式を使わない統計学入門』（講談社）
統計を学ぶ際、基礎文献のひとつとして挙げられるものに、ダレル・ハフの
『統計でウソをつく法――数式を使わない統計学入門』（講談社ブルーバックス）という
本があります。これは、統計でウソをつくテクニックを解説しながら統計の読み方を学ぶというもので、
翻訳文体の癖はありますが読み物として楽しむことができる一冊です。
原著は半世紀以上も前の1954年に出版されたかなり古い本ですが、現在でも
増刷が続いているベストセラーです。大学の社会科学系学部では、
新入生に読ませているところも多いのではないでしょうか。
この本の最後には、それまでを踏まえて「統計のウソを見破る五つのカギ」
というテクニックがまとめられています。それを列挙すると以下です。 >>246
> 均一であれば最初から70％付近を横這いに推移しているデータが見られるはずです。
それはないよ。
全ての均一のグラフはどんなものでも最初のシェアは0%だから 均一に一番近いというなら根拠となる特徴を示してください。 >>250
お前が均一であるというグラフを持ってくればいい。
こっちその最初の方がどうなってるかを確認するだけだ。 > 均一であるというグラフ
それ、Windowsのシェアでいい？
いいなら持ってくるけど。 >>252
俺は良いと思うけど、
あのバカは認めないだろうなｗ >>249
少し考え方が違うかな。
自分も統計学を習うまでは最初は0％だと思っていました。
実際は年度や月別で区切って開始されることが多くデータが途中から開始されたりするため0％スタートではないこともあります。
話がそれましたが、jQueryのデータは何の分布型に一番近いと思いますか？ ぐぐったらワードの昔（1986-1997）のシェアがでてきたｗ
http://news.mynavi.jp/news/2014/03/26/132/
これ見て「MS Word for Windows」は
山型のグラフであると判断しそうｗ >>255
それだよな
>>254
>>256のMS Word for Windowsのグラフは
何型だと判断しますか？
ちゃんと答えてくださいね。 下り坂になるまであと10年かかる山型
と答えれば満足するんじゃねーの？ｗ >>255
一般的に右肩上がりと言われますが、分布型で回答するなら増加のピークと鈍化が確認できるため山型が一番近いものと判断されます。
>>257
jQueryのグラフから話がそれる問題には触れません。 >>258
現在までのデータをみて聞いているのです。
回答できない理由でもあるんですか？ > jQueryのグラフから話がそれる問題には触れません。
逃げたよｗ（大爆笑） >>260
> 回答できない理由でもあるんですか？
回答してますよね？
「下り坂になるまであと10年かかる山型」と
それとも現在までのデータを見て
「ずっと上り坂の山型」と言えば良いんですか？ 分布型の回答は4つです。
山、均一、歪曲、U谷
私が判断した結果はこちら。
jQueryは左の歪曲から山型に移項している状態です。
そしてシェア率増加のピークは2013年ということです。
よって山型分布に一番近い特徴を示しています。
この判断が間違いと言うならjQueryのシェア率データを元に根拠となる型の特徴を示して説明してください。 >>262
現時点でのデータからみて一番近い型を聞いているのです。
未来のことは分布型に関係ありませんので忘れてください。 ぐぐったらワードの昔（1986-1997）のシェアがでてきたｗ
http://news.mynavi.jp/news/2014/03/26/132/
jQueryのシェアはこのグラフの
「MS Word for Windows」に似ていますね。 >>264
> 現時点でのデータからみて一番近い型を聞いているのです。
一番近い型は「MS Word for Windows」のシェアだと思います。
http://news.mynavi.jp/news/2014/03/26/132/ >>263
> この判断が間違いと言うならjQueryのシェア率データを元に根拠となる型の特徴を示して説明してください。
「MS Word for Windows」のシェアの型の特徴です。
http://news.mynavi.jp/news/2014/03/26/132/ 右肩上がりに見えるけど学問上は違うと言うことなのか？ >>268
一般だと右肩上がりで正解です。
何も間違いありません。
今ここで話しているのは、根拠もなく均一だと主張している人達がいたので統計学の説明をしています。 根拠はこれだな。
「MS Word for Windows」のシェアのグラフと
jQueryのシェアのグラフは似ている。
http://news.mynavi.jp/news/2014/03/26/132/
これから均一になる可能性が高い お、もっと近いグラフがあった
http://www.utdallas.edu/~liebowit/book/wordprocessor/word.html
この<Fig 8.17>の Mac Word Processor Market Sharesが近い >>270
他のグラフに似てると言うのは根拠の説明になりませんよ。
グラフを説明するときにはそのデータにこのような特徴があるから、この分布型に近いと説明しないと根拠を示せません。
これも統計学のテストだと×をつけられます。 >>272
だから、他のグラフ見て
お前は何型だと思うんだって聞いたんだが？
お前の判断能力に問題があると指摘してるんだよ。
今度は逃げずに答えなよ。
これだけを見て（未来を考えずに）これは何型と判断するのか答えなさい
http://news.mynavi.jp/news/2014/03/26/132/ 私はjQueryのデータが根拠を示さずに均一型だと主張している人がいたから説明しているだけです。
話がそれるようなことはお断りです。 ほらまた逃げたｗ
グラフっていうのは一部を見ただけじゃ何も判断できない。
jQueryは今までずっとシェアが伸びているのだから
現時点で判断するならば間違った答えになる可能性がある。
↓例えばこういうこと。少年の犯罪率が増えたなどと
一部だけで判断することは大きな間違い。
実は昔の方が圧倒的に多かった少年犯罪
https://goo.gl/EQem5z
よく見る少年犯罪が増加しているというグラフ
[ 平成1年から切り取った最近少年犯罪が多いとされるグラフ ]
でもこれ、実は嘘でした。少年犯罪は昔より今のほうが圧倒的に減っている
[ 昭和20年からのグラフ ] 何か都合が悪いから話をそらすのですか？
それとも回答できないのですか？
回答は4つです。
山、均一、歪曲、U谷
jQueryのシェア率増加データをみて現時点で何の型に近いか聞いているのです。
私が判断した結果は以下の通り。
jQueryは左の歪曲から山型に移項している状態です。
そしてシェア率増加のピークは2013年ということです。
よって山型分布に一番近い特徴を示しています。
反論すらできないということで良いですかね？ 今度は逃げずに答えなよ。
これだけを見て（未来を考えずに）これは何型と判断するのか答えなさい
http://news.mynavi.jp/news/2014/03/26/132/ 話をそらすばかりですね。
均一と主張した根拠を示しなさい。 >>276
間違い。
jQueryのシェア率増加データ
https://w3techs.com/technologies/history_overview/javascript_library/all/y
2011年1月 28.3%
2012年1月 42.8%
2013年1月 54.5%
2014年1月 57.4%
2015年1月 61.5%
2016年1月 68.3%
2017年1月 71.9%
2017年6月 72.5% ※最新
これを見てもわかるように、jQueryのシェアは登場から
ずっと伸び続けている。シェアというのは >>203 でも説明してあるように
次第にゆっくりになるものだから、このシェアが伸びなくなったというのはまだ判断できない。
最低でも下がらなければ、山型なのか均一なのかは判断できない。
一部のグラフだけを見て判断すると、近年少年の犯罪率が増えたなどという
間違いを犯すことになる。 >>279
私は最初から一番近い型を聞いているのですよ。
完全一致しているものを聞いてはいません。 つまり回答できないと言うことですね良いですかね？
jQueryのシェア率増加データには特徴が型の特徴が含まれているのですが、それも読めないということですか。 >>280
だからシェアが伸び続けているものは
どのグラフにも当てはまらないと言ってるだろ つーか、なんでシェアが伸び続けているという
型があることを理解できないんだ？ >>282
話を反らさなくて良いです。
私は均一型だと主張しているものがいたので説明しただけですから。
あなたは現時点で一番近い分布型を見つけ出すことはできないと言うことで間違いありませんか？ >>283
この場合限定された型は大きく分けて4つだからです。
統計学を自分の解釈でねじ曲げるようなことはやめた方が良いですよ。 回答すると何か都合の悪いことでもあるのですかね？
私はjQueryのシェア率増加データをみて均一型だと主張している者がいたので説明しているだけです。
そして現時点で何の型に一番近いか聞いているのです。
この限定されたデータでは答えは4つしかありません。
山、均一、歪曲、U谷
私が判断した結果は以下の通り。
jQueryは左の歪曲から山型に移項している状態です。
そしてシェア率増加のピークは2013年ということです。
よって山型分布に一番近い特徴を示しています。
分布型の特徴を知らなければ答えようが無いので酷だとは思いますが、もしわからないようであれば簡単な説明はしているのでレスを読むなりググるなどして調べると良いですよ。
どうしても分布型の意味が分からなければ、義務教育で習う右肩上がりと言えば良いでしょう。 jQueryのシェア率増加データ
https://w3techs.com/technologies/history_overview/javascript_library/all/y
2011年1月 28.3%
2012年1月 42.8%
2013年1月 54.5%
2014年1月 57.4%
2015年1月 61.5%
2016年1月 68.3%
2017年1月 71.9%
2017年6月 72.5% ※最新 >>287
これは私が載せたレスの一部ですが何か？
>>184
こちらの書き込みです。 なんか自称統計に詳しい素人さんが
山、均一、歪曲、U谷とかオレオレ用語使ってるけど
統計学にそんなもんないからな
4種類しかないなんて嘘だし、そもそも確率分布の名称に
型なんていい方はしねぇ。分布っていうんだよ。
http://www.biwako.shiga-u.ac.jp/sensei/mnaka/ut/statdist.html
2. 連続型確率分布 (Continuous probability distributions)
多分知らないんだと思うがね。 >>289
話を反らさなくて良いです。
私は均一型だと主張しているものがいたので説明しただけですから。
あなたは現時点で一番近い分布型を見つけ出すことはできないと言うことで間違いみたいですね。 >>290
お前の言う均一型って統計学で言う何だよ？
専門用語使え >>170
グラフの読めない人がいるのがわかっていたので最初に説明済み。 >>291
話を反らさなくて良いから。
答えられない理由でもあるのかい？ >>294
話を逸らす？何を言ってるんだ？
それは別人だろ。 大前提を一つ言っておこうか？
シェアと統計学上の分布は全く当てはまらないよ。
統計学の分布っていうのは確率に対して適用する話で
シェアは確率じゃないのだから全く関係ない >>296
シェアの話なのだからそれであってる。
やつの主張はシェアの話を勝手に
確率の話にすり替えて、統計学上の分布の
どれかであるはずだという思い込みによって成り立ってる。
シェアの場合、単一の事象ではなく
別の候補が現れたなどという、想定外の事象によって
大きく影響するので、分布のパターンに当てはまらないことが多い。 >>295
失礼しました。
私は↓のような根拠も無く均一だと主張している者に説明をしていただけです。
>>175 >>182 >>299
話すり替えんな。そもそもお前の話が間違いだってことを言ってる >>300
私はjQueryのシェア率増加データが山型に一番近いと主張していること？ >>301
俺の主張はそもそも山型なんてものはないと言ってる。
右肩上がりで良い >>296
一般的に説明するなら右肩上がりで間違いないよ。 シェアの話は確率の話じゃないんだから
無理やりどれかの分布にあてはめようというのが
そもそも間違っている。 >>302
一々検索して調べてるような人がいるみたいなので意味が通じるように説明しただけです。
最初にレスして触れていることなんですけどね。
その後、私は均一だと主張している者に理由と一番近い分布を聞いてるだけです。
ちなみにあなたは、現時点でjQueryのシェア率増加データをみてどの分野に近いと思いますか？ >>305
だから分布に当てはまることが間違ってる ちなみにあなたは、現時点でjQueryのシェア率増加データをみてどの分野に近いと思いますか？
ワードプロセッサの分野における、MS Word for Windowsのグラフにそっくりですね。
http://news.mynavi.jp/news/2014/03/26/132/ >>304
特徴を含むシェア率増加データがあるならヒストグラムでも一番近い分布は決められますよ。
そう思い込むのは勝手ですが、グラフみて根拠となる特徴を見つけ出し一番近い分布を出すのは常識なんですけどね。 ちなみに「シェア率増加データ」なんていうのも>>305が独自に
編み出したオレオレ用語。そんな言葉は存在しない。近い言葉もない >>308
だから分布じゃないものを分布にあてはめることが
そもそも間違いだって言ってる。 つーかさ、シェアを分布に当てはめて
考察しているものがあるっていうのなら教えてくれよ。
全く筋違いのものを同一視しているだけ
そんなものないからさ。 >>307
他のグラフに似てると言うのは根拠の説明になりません。
グラフを説明するときにはそのデータにこのような特徴があるから、この分布に近いと説明しないと根拠を示すことはできません。
何事にも当てはまりますが、似ているからといった思い込みで直ぐに何かに関連付けさせようとするのは間違いの元です。 > 他のグラフに似てると言うのは根拠の説明になりません。
なるよ。
お前自信が、ある分布の型に似てるから
その分布だってやってるじゃんｗ 山型に似ているからと言って山型だと思わないようにしましょう。
例えばそれはU型の上り坂の部分かもしれません >>310
特徴が示されていなければ回答できませんが、jQueryの場合には明確な特徴が含まれているでしょう。
開始時から左の歪曲
増加率のピーク
鈍化状態
この特徴が一番近いものは均一ではないですよね。
山に移項している状態なので一番近いと思うのですが？
この３つの特徴より多く含むものを見つけ出せますか？ >>314
かもしれないや未来のことは、現時点で一番近いものとは言えません。 >>315
一番近いのは山型ではなくて右肩上がり型だよ
> 鈍化状態
シェアなんだからずっと同じペースで増えることはありえない
年10%増えて、それが11年後に110%になったら驚きだｗ 絶対値じゃなくて割合なんだから鈍化しないということはありえないんだよ。 https://w3techs.com/technologies/history_overview/javascript_library/all/y
にはjQueryだけじゃなくて、None（何も使わない）ってデータもあるんだよね。
2011年1月 28.3% 61.8%
2012年1月 42.8% 49.1%
2013年1月 54.5% 39.6%
2014年1月 57.4% 38.2%
2015年1月 61.5% 35.0%
2016年1月 68.3% 28.7%
2017年1月 71.9% 25.5%
2017年6月 72.5% 24.6% ※最新
おそらくこのまま、何も使わないのは0%に向かって下がっていくだろう。
これは何型？ 話をそれるのでまとめておきます。
私の主張はこれのみ。
>>175
>>182
均一と主張するなら、根拠となる特徴をjQueryのデータを使って示せということ。
グラフを見て一番近い分布は山。理由は以下の通り。
開始時から左の歪曲が続き
増加率のピークは2013年
それ以降は鈍化状態
これを均一だと主張している者がいるので説明を待っているのですが恐らくレスこないでしょうからしばらく様子をみることにします。
現時点でのjQueryのデータをみて均一に一番近いという根拠ある説明がされたら返信することにします。
わからないようであれば、一番簡単である棒グラフ・折れ線グラフ・ヒストグラムなどを検索して分布について調べてみてください。
ここで説明書していた型(分布)についてある程度は理解されるはずです。
以上 IEのシェアは最初高かった！
今は減っているだけ！
型に合わせてみればU型だから、
IEのシェアはこれから盛り返す！ 話をまとめておきます。
https://w3techs.com/technologies/history_overview/javascript_library/all/y
jQueryのシェアはずっと上がりつけています。
何も使わないシェアはずっと下がり続けています。
2011年1月 28.3% 61.8%
2012年1月 42.8% 49.1%
2013年1月 54.5% 39.6%
2014年1月 57.4% 38.2%
2015年1月 61.5% 35.0%
2016年1月 68.3% 28.7%
2017年1月 71.9% 25.5%
2017年6月 72.5% 24.6% ※最新
適当にでっち上げた型に当てはめるのは意味がありません。
jQueryのシェアが下がる要因はないので、このまま高シェアを維持し続けるでしょう >>320
> 開始時から左の歪曲が続き
> 増加率のピークは2013年
> それ以降は鈍化状態
他のグラフに似てると言うのは根拠の説明になりません。 >>322
jQueryのシェア、最終的には9割ぐらい行きそうだな jQueryのシェアが減少することってあるのだろうか？
あと10年は変わらない気がする。 シェアのグラフを見るときは、誰が誰のシェアを
奪っているか？に注目すると先を読むことができる。
https://w3techs.com/technologies/history_overview/javascript_library/all/y
グラフを見れば明らかだが、シェアを伸ばしているのはjQueryとBootstrapとModernizr
反対にシェアを減らしているのはNone（何も使っていない）と、もともと少ないがMooTools
ここから誰が誰のシェアを奪っているかがわかる。
もちろん伸ばしている方が、減らしている方から、シェアを奪っている。
この先大きな出来事がおこらない限り、この流れは変わらん。
ゆっくりになるだけで反転はありえない jQueryとBootstrapとModernizrって用途が違うから
お互いがシェアを奪い合うってことにはならない気がする。 >>328
それは正しい。そもそもBootstrapの機能の一部は
jQueryを使用している。 今更だが、アレクサー・インターネットの上位サイトでは
jQuery使われてないんだとか喚いていたヤツいたじゃん？
でもw3techsの情報ってアレクサーインターネット上位1000万の
ウェブサイトからの統計なんだねｗ
https://w3techs.com/technologies
> We include only the top 10 million websites (top 1 million before June 2013) in
> the statistics in order to limit the impact of domain spammers.
> We use website popularity rankings provided by Alexa (an Amazon.com company)
> using a 3 months average ranking. Alexa rankings are sometimes
> considered inaccurate for measuring website traffic, but we find that they
> serve our purpose of providing a representative sample of established sites very well.
Google翻訳
> ドメインスパマーの影響を制限するために、統計には上位1000万のウェブサイト
> （2013年6月以前の上位100万人）のみを掲載しています。私たちはAlexa（Amazon.comの会社）が
> 提供するウェブサイトの人気ランキングを3ヶ月間の平均ランキングで使用しています。
> アレクサのランキングは、ウェブサイトのトラフィックを測定するために不正確と
> 見なされることがありますが、それらは確立されたサイトの代表サンプルを非常にうまく提供するという目的に役立っています。 https://w3techs.com/technologies/overview/javascript_library/all
あとこっちのマーケットシェアってのがよく分かってなかった。
jQueryの使用サイトが72.5%で、マーケットシェアが96.2%の意味
よく読んだらわかったよ。
まずウェブ全体で24.7%がJavaScriptライブラリを使っていない。
まあ動的な動きが必要ないただのHTMLとかもあるからそういうのもあるだろう。
残りの75.3%が何かしらのJavaScriptライブラリを使っているということ。
その中で96.2％はjQueryを使っている（72.5% / 75.3% = 96.2%）
ということなんだね。 base64エンコードしたデータを小さくしてからAjax送信する良い方法ありませをか ファイルリーダー
readAsDataURL
ここでzipライブラリの処理
Ajax送信
phpに受け渡し
サーバーに保存
ディレクトリを確かめると全てファイルサイズが readAsDataURLで変換したものより大きかった。
考えられる原因わかりますか？ zip圧縮するデータが圧縮に不向きな場合は小さくならず逆に大きくなる場合もある。
その可能性もあるから生成されたファイルの大きさを比べてから処理変更するのが正解。 jsでまともに動くZIPライブラリないですか？
数十メガ単位になると中断とかキャンセルされてしまう。 >>337
無圧縮で良ければすぐ作ってあげるけど？ >>338
もちろん無圧縮のzip形式ですよね？
お願いします。 >>338
337、335、333です。
データベースを使って非同期に分解してから送信する方法で解決できました。
ちなみに339と私は関係ありません。 >>337
検索で直ぐに出てくるJavaScriptで動くZIPライブラリは重い処理をすると直ぐに止まるような欠陥品みたいなものだよ。
特にjQuery必須の三種は糞。 zipライブラリでjQuery？
DOMと全く関係ないな。
jQueryを間違った使い方をしているやつがいる
素晴らしいjQueryとは全く関係ない話だが >>342
そのライブラリはjQueryないと動かないんだがw >>343
しらんがな
それはそのライブラリのせいであって
jQueryのせいではないというだけの話 ちょっと調べてみたがこういうのか？
http://d.hatena.ne.jp/yatt/20110629/1309353151
> 実際にコーディングしたのはjQuery.ajaxとの統合部分で、
> 実際にzipを処理する部分はhttps://github.com/hinassan/zipjsから頂きました。
> スコープを狭めるために、定義をグローバルなthisではなくjQueryオブジェクト内に
> 定義されるように変更した程度でほぼ全て引用です。
あー、これはなぁー、zipライブラリそのものじゃなくて
zipライブラリを使って作られたjQueryプラグインだ そのライブラリーの中身をみないと判断できないが置きかえ処理や送信部分で使ってるんじゃないのかな？
気になったのでググってみたけどzip圧縮系のjsライブラリーは種類が少ない＆Githubにもあまり置いてない。
jQ必須のzip圧縮系ライブラリーも数えるだけしかない。
使う用途が限られているのか使い勝手が悪いので需要がないのかと・・ >>346
> そのライブラリーの中身をみないと判断できないが置きかえ処理や送信部分で使ってるんじゃないのかな？
だろうね。
なぜかjQueryが必須なzipライブラリ
ではなくて、
zipライブラリをjQueryのajax部分で透過的に使えるようにしたプラグイン
だったわけだ。
わざとなのかしらんけど、なんでこう
わざとらしいことするんだろうか >>341
どの三種か不明ですが結果としてはjQuery必須のzip圧縮ライブラリはどれも重くて使えないですね。
自分の環境だとどれも50Mで停止した。
使えるライブラリがあったら教えて欲しいです。
>>337
データベースを利用したzip圧縮であればGB単位でも問題なく動作します。
以前4～5GBのファイルを受信してローカルに保存する処理を記述しときにデータベースをいじってみたけど割りと簡単にできました。 擁護するわけではないけどjQueryライブラリ読まないと使えないzipライブラリが存在するのは事実なんだけどね
そしてどれも数十M単位のファイルを扱うと使えなくなる代物・・ 346だけど。
>>347さんは346レスした人？ >>348
いい加減jQuery必須のzip圧縮ライブラリとか
名前を隠すのはやめれ。
わざとらしい >>348
JavaScriptでデータベース扱う処理は流行りですかね。
自分もJavaScriptでzip化させたくてライブラリ探してみたけど全てダメでした。
Chromeの最新版で試してみたけどどれも停止するんですよ・・
特にjQuery読み込み必須のzip化ライブラリは重くて使い物にならなかったです。
37MBのファイルですら実行できなかったです。
自分で書くしか無いですかね～ 自分で書けば?
そんなに難解なフォーマットでも無いみたいだし
例えば圧縮無しのアーカイブ化だけとかなら簡単にできそうだよ
もしくは要件定義してくれたら俺が書いても良いよ >>353
どんな処理をさせるか簡単で良いので流れを説明できますか。 jQuery必須のzip化ライブラリ重いですねーｗ
jQuery必須のzip化ライブラリ重いですねーｗ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) なんでjQuery必須のzipライブラリって重いの？
jQueryが糞だから？ｗ >>354
サーバから受信したor手持ちの<File>をzip化したいんじゃないの?
ただ仕様通り並べていくだけじゃん >>357
それだとそのへんに転がってるzipライブラリと同じで50MB程度で停止してしまうよ。
jQuery必須・不必須関わらずまともに動くものがあったら教えて欲しいです。
欲しいのはGB単位でも扱えるzip化スクリプトです。 javascriptでlengthは文字数だけど文字列のバイト数を得るにはどうやればいいんですか？ なんでjQueryを使ったzipライブラリは
まともに動かないのでしょうか？
バグが有るのですか？ jQuery と、zip は何も関係がない。
jQueryは、符号化処理するモジュールではない
Node, Haxe にも、モジュールは無いのか？
それか、OS に入っている、zip コマンドを起動するとか 俺が知ってるzipライブラリはjQueryがないと動かないという証拠があるんだが >>359
UTF-8 には、1文字で、1～6バイトとか？
どの文字が何バイトかなんて、ユニコード規格を決める人しか、知らないだろ >>362
jQuery で、どこかの無料サイトにアクセスして、
そのサイトに送ったデータを、zip 化してるだけじゃないの？
そのサイトのデータ量の上限を超えているので、エラーになっているとか？ >>364
zipライブラリで圧縮されている。
そしてjQueryがないと動かない仕様になっている。
というかJavaScriptでライブラリ公開とかしたことありますか？ 俺が知ってるjQueryがないと動かない
zipライブラリについて質問してもいいですか？ 作る技術もないのに作ろうかとか言ってる人なんなの？
はよ処理内容の流れを説明してくださいよw やった完璧なjQueryが必要なzipライブラリ見つけた！ 数GBも扱いたかったらStreamを使うしか無いわな 普通のツールと違ってファイルをディスク上に置いたまま、一部を読みながらディスクに書き出すと言うことができないから
まずZIPする前の何GBも貯めていく時点で無理が生じると思う
現状ブラウザからファイルをダウンロードさせようと思うとaタグのdownload属性を使ってhrefにblobのObjectURLを指定することになるよね?
でもstreamをblobにするのは無理
となるとワンちゃんあるのはサービスワーカーからocted-stringを吐き出すこと
ローカルファイルをReadableStreamとして読んだらブラウザが空気読んで最低限のメモリ消費にしてくれないだろうか?
そしてそれを自作ReadableStreamにし、それをResponseにしてサービスワーカーから返すことでできるのかもしれないね データを丸ごと取れるのは、せいぜい数MB まで
ブラウザで動画など、数GB あるようなデータは、
ストリームと言って、受信したら端から、データを捨てていく
バッファには、直近の数MBしか、残っていない
jQuery では、こんな処理はできない。
Node などのJavaScript でも出来ない
ブラウザのように、OSのファイルAPI を使っている、言語しかできない >>372
できるっぽいよ
jQueryの$.ajaxで通信途中のresponseTextを取得する
https://abicky.net/2011/12/25/042412/ 中途半端な知識でjQueryを陥れようとするからそうなるんだよなｗ >>359
Node.js の、Buffer.byteLength で、文字列のバイトサイズがわかる。
Electron でも、できるかも
>>337
zip は、Windows だから、PowerShell とか？
Linux だと、zlib, gzip になる。
Node.js の、zlib。
Electron でも、できるかも
curl, wget のオプションにも、あるかも datepicker-ja.jsを導入すると文字化けしていしまい改善方法がわかりません。
昨日jqueryを始めたガチの初心者ですのでお手柔らかにお願いします。
datepicker-ja.jsはローカルフォルダにダウンロード済みです。
------index.html----
<head>
<title>jQuery</title>
<link rel="stylsheet" href="jquery-ui-1.12.1/jquery-ui.css">
<link rel="stylsheet" href="jquery-ui-1.12.1/jquery-ui.theme.css">
<link rel="stylsheet" href="jquery-ui-1.12.1/jquery-ui.structure.css">
<link rel="stylesheet" href="style.css">
<script src="jquery-3.2.1.js"></script>
<script src="jquery-ui-1.12.1/jquery-ui.js"></script>
<script src="datepicker-ja.js"></script>
<script src="index.js"></script>
</head>
<body>
日付: <input type="text" id="datepicker">
</body>
</html>
------index.js--------
$(document).ready(function(){
$("#datepicker").datepicker();
}); >>376
問い詰めても何もならないからやめとけ。 ページ内リンクに効かせるスムーズスクロールが
jQuery本体の1.12だと効かないようです（1.11.xまでは効く）
ここと同じ記述ですが、1.12で対応する記述方法をわかりますでしょうか？
https://techacademy.jp/magazine/9532 ちなみに記載の参考サイトは
jQuery3.系を使用してますが、ローカルにコピーしても効いてないですね・・ ・・と思ったら自己解決しました
セレクタの仕様が変更されたんですね
#→"#" >>379
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>jQuery</title>
</head>
HTMLの冒頭部分で、日本語・文字コードを指定する
それと、すべてのファイルを、BOM無し、UTF-8N で保存する
メモ帳では、BOM有りになるので、開発では使えない。
他のエディタ・IDEを使う >>385
基本的な事を忘れてました…
アドバイス通りで修正できました。
ありがとうございます！ 俺も標準厨だから特にHTML5ムーブメントが起きた頃はjQueryが大嫌いだった
それはライブラリが前提になるとより良い標準が普及するのが遅れてバッドノウハウが何時までも残ってしまうと考えてたから
でも標準の策定と実装があまりに遅すぎるし、HTML5ムーブメントの時の勢いを持った人達はどこに消えたのかと思うくらい最新仕様に興味を持って盛り上げていく人が少ない
最近は細かい事を言わずjQueryをポリフィルのような感じで使っていってもいいと思えてきた >>389
そういうデータが有れば上司を説得できます！
あるなら教えてください！ データは関係ないわな
チームにjQueryに頼らない環境ができているかどうかだから
あとはやっぱ対応ブラウザだな
徐々に切り替えるというのも面倒だから
jQの通信やスタイリング機能などなどを使わないとすると
標準でfetchやらWebComponentsなどなどが使えるEdge以降になる
そしてそこまでして開発スタイルをバッサリ変えて
意識高い人は満足かもしれないが、
jQ==JSと思ってるような末端の開発者たちが納得するかね？しないと思うわ IE8はもう普通のブログですらまともに表示されないよ >>392
jQueryに限らないけど、頼る頼らないの話じゃないでしょ？
頼らない方が偉いとかすごいってわけじゃない
適切な技術を選ぶ（頼る）ことが重要で
jQueryが適切ならjQuery使うべきなんだよ
最近どうもjQueryを使わないことが目的になってる
やつがいるけどさ、アレは単なる流行り物に流されてるだけ
どうせAngularとかReactとか使い出すとDOM APIなんて殆ど使わないので
とっくの昔にDOM APIは必須の知識ではなくなってるしね。 先祖タグを削除した際、
その子孫タグのイベントを、削除してくれるのは、jQuery だけだろ
JavaScript, Zepto.js などでは、GC されなくて、メモリリークするだろ
Backbone.js でも、子孫タグのイベントを、削除するのは難しいから、出来なかった ブックマークレットで、クリックイベント実行して画面遷移して、描画完了してから入力項目に入力させたいんですが、描画完了のイベントってどうやったら取得できるでしょうか？ 同オリジンのページを表示している状態からなら
DOMContentLoadedイベントを別タブで開いて監視する
fetchして監視を挿入して遷移もいいけど、以降オリジンを外れるから微妙 ファイル・画像などの読み込み完了は、よく聞くけど、
描画完了というのは聞かない
そもそも、YouTube みたいに、
画像が読み込まれていなくても、リンクが押せるように作るべき 画像の場合はdecode()を呼べばツリーに挿入して次のレンダリングで描画されてることが保証される セレクタの指定方法について質問です。
「クラス名.hoge1と.hoge2の両方の値が空の場合」を指定するにはどう記述したらよいでしょうか？
$('.hoge1:empty.hoge2:empty')のように書きたいのですが・・ 値とは？value属性のこと？
具体的にhtmlで書いて欲しい >>403
まず遠回りして説明するとセレクタの指定方法として質問が適切じゃない
「場合」と書いているからifの条件みたいになってる。
セレクタの話をするならば、「クラス名がhoge1で値が空の要素を選択したい」
という形で聞かなければいけない。セレクタ＝セレクトする人だから選択
ということで、何を選択したいのか？を考えてみようか？ >>405 失礼しやした。タグ内のテキストノードもしくは要素です。
<li>
<p class="hoge1">テキスト</p>
<p class="hoge2"></p>
</li>
<li>
<p class="hoge1"></p>
<p class="hoge2"></p>
</li>
<li>
<p class="hoge1"></p>
<p class="hoge2"><img src="hoge.png"></p>
</li>
>>406
例えば、上記hoge1、hoge2共にタグ内が空のliを選択 >>407
話が変わったなｗ
選択したいものは何か？liだろう？
なら最初にliを選択したいというのが来る
$('li')
そしてその後は条件と考えられる。
その条件がCSSとして書けるものであるかどうかって話だが、
残念ながら「選択したい要素（＝親要素）の"子要素がemptyである場合"（の親要素）を選択する」
というような、選択したい要素と、条件がかかっている要素が違う場合は、CSS3では実現できない。
CSS4でなら実現可能かも知れないが。
ブラウザが対応していればCSS4のセレクタが使えるかもしれないが、
jQueryはCSS3までの対応となってるので、単純なセレクタでは実現できない。
だからセレクタと条件を分けて考える必要がある。 そしてな、
クラス名.hoge1と.hoge2の両方の値が空の場合というのは
クラス名.hoge1の値が空ではない
または
クラス名.hoge2の値が空ではない
というセレクタを使って選択した結果、見つかった要素数が0である
と置き換えられる。
「クラス名.hoge1と.hoge2の両方の値が空の場合」という言葉には
セレクタと条件の２つが含まれているわけだよ jQuery("li .hoge1:empty").parent().find(".hoge2:empty").parent("li");
我ながら酷い回答だわ・・・ ということで回答はこれだな
$('li').filter(function() {
// return $(this).find('.hoge1:not(:empty), .hoge2:not(:empty)').length === 0;
// return $(this).find('.hoge1, .hoge2').filter(':not(:empty)').length === 0;
return $(this).find('.hoge1, .hoge2').not(':empty').length === 0;
});
見ての通り、単発のセレクタというものはない
セレクタと条件が組み合わせる必要がある。
CSS4を使えば、単発のセレクタにできるかもしれない
と、ここまで書いて、調べてCSS4ではhasを使えばできそうだと知った所で
jQueryにもhasはあることを思い出してシンプルに書き換えた。
もちろんこれも単発のセレクタではない。
$('li').has('.hoge1:empty').has('.hoge2:empty')
CSS4だと、$('li:has(.hoge1:empty):has(.hoge2:empty)')
こんな感じで、単発のセレクタで書けると思うが
jQuery以前にブラウザが対応していない。
http://caniuse.com/#search=%3Ahas hoge1の中身が空であることを確認したあと
hoge2の中身の確認を終えて条件の判断を行うまでの間にhoge1が空でなくなったら そもそも値が空だとか中身が空という意味がわからない
子要素は値とか中身とは言わない
あとShadowRoot下に要素があったらどうすんのよ？ そういうのは空だとかいう曖昧な基準で物を考えるべきじゃないね
そもそも仮に子要素が空白文字のテキストノードだったらそれも選択すべきかもしれないし
その場しのぎの基準と作業はやめて本質的なことをすべき :emptyって書いてるんだから曖昧じゃないだろ
自分が答えられなかっただけのくせに、いい加減にしておけ。 >>412
質問がテキトーでご迷惑おかけしやした。
.hasでしたか、いや後から考えると確かにごもっともですね。
ありがとうございやした。 >>416
何を怒ってるのか分からないんだけど
本当にそれが本質なのか?と説いてるんだよ
閉じた空間ならまあそうは言わないが
HTMLとDOMっていうの自体が曖昧性と干渉による不確か性を孕んでるからね
だからそれに対してシンプルな物で立ち向かうって言うのは逆に曖昧ということになってしまうんだよ
そういうときのJSの基本として、吸収できるように冗長に書くことを考えなければいけない
もしくは、ShadowDOMでカプセル化したりしなければ良くないよと言うこと つまりね、一番言いたいことは単純なセレクタで片付けようとするばかりでなく
時には非スマートでもいいから『自分で書こうとする気』も必要ということ
コードのスマートさを重視して暗黙的な細かい要件を変えるテクニックは重要だが難しいもの >>419
だから何がそんなに気に食わないのか？
hasっていうのはCSS4で策定予定なことからもわかるように
>>403がやりたいことっていうのは、たしかにセレクタで
やるべきことなんだよ。
jQueryはそれと同じことをメソッドとして先行実装しているだけ。
>>420
セレクタを使って簡単にquerySelectorAllで要素を取得できることを
自力で頑張れというのなら君はセレクタをJavaScriptで使わなくていいよｗ こんなイメージ？
①アメリカ人で20代の男性と日本人で30代の女性の方、
集合時間についての大事なお知らせがあります。
②今から言う対象の方、集合時間についての大事なお知らせがあります。
対象の方は、アメリカ人で20代かつ男性、もしくは日本人で30代かつ女性
それ以外の人は聞かなくて大丈夫です。 >>421
セレクタを使うのが悪いとは言っていない
セレクタくらい自分で調べろ、これはコード作成依頼に近いというのもあるが、
それよりも気に食わないのはemptyだとかそういう単純な物で物事を解決しようとする姿勢
もっというとセレクタや$()に頼りすぎてるということ
そんなことじゃ柔軟性を失って本質を見失って良いことはない CSSにもある:emptyがだめな理由を
書いてみようか？ 要件がシンプルなのが気に食わない
複雑な要件に変更するべきだ！
っていうのなら本末転倒だなｗ
気に食わないという理由で
勝手に要件を変えるな > もっというとセレクタや$()に頼りすぎてるということ
セレクタや$()に頼らないのは本質ではない。
本質とはどんな手を使ってでも素早く要件を実現することだ。 >>423
すまん、全く意味がわからんｗｗｗ
具体的にどんなコードを書けば満足なんだｗ 単にjQuery使うなって言いたいだけだろｗ
もしくは今からjQueryを使わずに問題を解いてやろうとした所で
あっさりとjQueryのhas使ってシンプルに回答されちゃったんで
悔しいとかだろうな 要するに質問者のプログラムに対する姿勢が気に食わないから謝れって事だろ
A 「GIMPで遠近の違う写真を合成したいんだがどうやるの？」
B 「は？そもそもGIMPなんかフリーソフトで安易に解決しようとする姿勢が気に食わない。
ちゃんと金払ってphotoshopCC使ってやれ」
（↑実はGIMP苦手だったりする） ぜんぜん違う
どうして書いてもないことをそう捻くれた妄想できるのか不思議
>>426とかも的外れ
頼りすぎてるとは、自分で考えてコードを書けないということを言っているのよ
セレクタでちょっと困るたびにここに聞きに来るのかと
セレクタや$()が何でも解決して「くれる」と思ってるだろと
解決するのは、「君」だ、そして手段を優先して目的を犠牲にするなというようなことを言っているのよ 簡単にまとめるとこうかな
「書いても、書かされるな」
そゆこと 念のため言うけど質問者にだけ言ってるわけじゃないよ
むしろそういう受け身な姿勢にさせる自立を阻害するような状況を作り出した
回答の流れも含めて丸っと気に食わないと批判してる
具体的な回答がどうこうというよりも、問題提起と回答までの流れに
ちょっと良くないだろうという文句を言ってる
俺の考え伝わった？ >>433
微塵もわからん
>>403は本来どういう質問が良くて、それに対する回答はどうすれば良かったんだ
セレクタ一つでアホみたいに悩むより聞いた方が早いだろとは思うんだが >>427
単なる利用率なら公開しているサイトがあるよ >>431
> セレクタや$()が何でも解決して「くれる」と思ってるだろと
まあ実際CSS4で解決してくれるわけですが？ セレクタが解決できる問題にたいして
セレクタでやる方法を教えてくださいというのが
何が問題なのか？ >>431
疑似要素セレクタで複数同時に指定する方法（手段）を聞きたかったわけで
そもそもの問題を解決したいだけならjavascriptでもphp側でもできますし、
それこそどうして質問者がjQuery以外では書けないと妄想して断定しているんですか？ >>441
それは言葉の綾で現実の質問者が実際にそうだと断定しているわけではない
質問者が悪いとも悪くないとも言わない
回答者が悪いとも悪くないとも言わない
でもこの質問からのこの解決までの流れはまるでそういうことを認めるようで悪いと言ってる
つまり展開が好ましくないと言ってる
具体的な回答や質問の１つ１つにケチを付ける気はないし、ましてはそれを書いた人を批判する気もない >>442
展開おかしいですか？
>>403の最初の質問で1行目から
"セレクタの指定方法について質問です。"って書いたんだけどな。
疑似要素セレクタで複数同時に指定する方法を聞きたかったわけで。
そもそも生js自体も所詮は手段の1つでしかないし、
手段について質問回答するスレかと思っていたが違うのか。 そうやって関係ない話題にjQuery絡ませてくるから
ガキだって言うんだよ >>431
＞頼りすぎてるとは、自分で考えてコードを書けないということを言っているのよ
これね、若いねぇ
中途半端にかじっちゃった状態の人って必ず一度は言うんだよなｗ
それ言い出すと、どこまで突き詰めんのかって話になる訳よ
「自分で考えてマシン語コードで書けよ」とか「いやいや、マイクロコードからだろ」とかね
お前らは生産性が低いんだよｗ
すでに確立され実績のあるものは積極的に使うべきで
その上にどう付加価値を付けていくのかが重要なんだよ >>444
オープンソースは下級言語として扱われてるしな。
さらにjQは誰でも使えるように簡単に書けるようにしてあるんだから不思議なことではない。 新しい物をチャらいと言って否定するアナログおっさんより
スマホでもyoutubeでも新しい文化をも受け入れて使いこなすおっさん
スタンスは自由だが、生物として優れているのは後者ではないだろうか 古いとか新しいじゃなくて適切なものを適切に使うのが優れてるって
最初から使わないが結論の人はだめ jQuery・JavaScriptは儲からないのかよ >>446
俺はそういうことを言ってるんじゃない
いい加減説明するのも疲れたけどjQを使うなと言っているのでもない
ただ2chでのJS質問スレは、自分で解決しようという気が無いと駄目
あくまでこのスレでのモラルを問うてるわけで、その他の世界や一般論を言ってるわけじゃない
俺も１５年くらいJSやってるわけだし、今更若くもないし若いこと言いたいわけでもない
ただきっちりさせておくべき所というのはある
具体的に言うと、自分でjQのセレクタ指定を調べようと思わないとまずだめ、
調べてもよく分からなかった、どういう意味ですか、から話は始まる
そして回答者もそういう自分で調べられるように誘導してあげないと駄目
答えを１つ聞いて、答えを１つ書くんじゃコード作成依頼と同じ
それは駄目 他人を駄目駄目全否定する奴ってほんとどこ行っても騒動起こすな >>453
質問スレで質問するなってわかりやすく言ったらどうだい？
それとも俺が満足する質問だけしろのほうかな？ >>454-456
質問スレだからといって何でもどんな風にでも質問して良いのとは違う
ここは自ら学ぶ人のための質問スレッド
質問場所は他にもいくらでもあるが、
ここはどちらかというと正解を探すタイプじゃなくて修行するタイプの人が集う厳しい所
良いとか悪いとかじゃなくてそういう住み分けがずっとされてきてる所なんだよ
今回の場合別に質問も回答も単体でそのしきい値を超えてるとまでは言わない
だがそれ以外のノイズも含めて全体でしきい値を超えたと判断したので警告したまで
2chでもたまに超初心者向けが立ったり、教えてもらう系の質問スレがあるように
それを変えたいのならテンプレを変えてスレを立て直さないといけない
そうしたなら俺だってうるさい面倒なことを言わないで済む
少なくともこのスレでこういうやり取りは謹んでくれということ
誰かの思想を否定する気は無いが、先祖代々から続くこのスレでのモラルに反してるということ
過疎る前だったらすぐツッコミが入った
最近は皆あまりに適当でなあなあにやり過ぎ 質問はパッと見、簡単そうに見えるけど、
実はググっても出てこない。
恐らくあなたもわからなかったのでは？ 質問スレは質問スレであって勉強スレじゃない
質問者に学習させようとか余計なお世話
答見て全体が理解できることの方が多いんだから
ここは質問と回答に徹していればいい >>460
さあ、どうだろう、調べても考えても無かったから分からないが、
確かに少なくとも最初から今回の一番スマートな回答を出せる知識、経験は持って無かった
見返してみてみると、hasだったりnotだったり、いろいろためになった
改めて良い回答や流れだっだと賞賛を送りたい
でも、何度も言うけど個別の回答の中身が悪いと言っているのではない
スレのバランスとして不足していた部分があったということ
>>461
質問者に対してや回答者に対して余計なお世話でも
このスレの本来の秩序とバランスを守ることが優先される
俺も言いたくて言ってるわけじゃない
俺がこのタイミングでこれを言い出さないとそろそろバランスが取れなくなると思ったから言ったまで
偉そうに言わせてもらうと、おせっかいだろうが皆の気を引き締めさせて貰った
だから実はこの時点で俺のノイズを含めて全体としては問題は無くなってると解釈してる わかりやすく「俺の気に食わないレスをするな」って書けよ
いちいち翻訳させるな >>462
このスレはJavaScriptとjQueryに関係することなら
なんでも書いていいんだよ。
ノイズっていうのならお前のような
JavaScriptやjQueryに関係ない個人の主張を
長々と書いているものこそがノイズだ >>463
あのね、、、それは俺の意見と正反対だ
そんな考えじゃ誰も何も発言できなくなるだろ、それはおかしいだろ
発言はどんどんすべき、文句があったらさらに発言すればいい
多様な意見をどんどん交わすべき、それが俺の考え
だから俺は今回偏った空気に無い系統の発言をしてバランスを取った
他の発言が無ければ、俺の発言もなかった、
だから他の発言を否定するなど、あり得ないこと
全てのレスを含めて作品のようなものなんだよ
>>464
君も全く分かっていない、ノイズというのは正しく俺の発言のこと
どうしてそう読めない？
そこまで捻くれた見かたしかできないなんてヤバイんじゃないか？ 議論スレでやれマジで
質問に回答してる奴のレスを議論スレに貼っつけてそこで存分に扱き下ろせ
ここでやるな 手元にある市販のjQuery解説書がget～ByIdと$(～)が不規則に混在してて気持ち悪い
get～は一部で説明してるのだからそこだけに留めて、他は統一すればいいのにと思う
jQueryで書くみなさんはどちらを使用？何か使い分けしてる？ 気持ち悪いと感じる本をなんで買って手元に置いているのかの方が気になるんだけど そもそもidで取得するのに関数を使う必要がないわな
idをもつ要素はそのid名でwindowのプロパティになることが仕様で決められてるんだから
単にidかwindow.idとするのが一番良いよ get～ByIdは最速
どれでもよくて迷ったら最速を選べ >>470
最速と言われても実行速度の意味と開発速度の意味の両方があるでしょ
最速の入力速度というのなら文字数が少ない方がいいし
メンテナンス速度とか修正速度ならこれまた文字数が少ないほうが
最速になる おや？皮肉がわからなかったのかな？
実行速度を重視する時代は終わってるんだよ
それよりも開発速度のほうが重要 毎日皮肉を言いながら生きてて大層ウザがられてるんだろうな
「○○持ってる？」
「持ってる」
「・・・（シ～ン）」 ＞最速と言われても実行速度の意味と開発速度の意味の両方がある
なるほど～と感心したオイラは初心者です 開発速度の話をするならばjQuery一択だろ
そこに議論の余地はない >>476
速度には実行速度と開発速度があるということに
気付ける人はまだましだよ。
本当に理解能力がないやつはいくら言っても
実行速度のことしか考えないからな ボクはアナタのファンです
コテハン名乗って貰っていいですか？ コテハン名乗るかどうかはお前が決めることじゃない
俺が決めること。名乗りたいと思えば名乗る。 jQueryなら開発速度も早いし、実行速度も速いし、いいことばかりだよね get～ByIdなんてそこら辺からコピペするだけ
入力や開発速度、メンテにそんな差あるか？ ID一つだけじゃなくて複数のIDに対応したくなったら
書き換えないといけないだろ。
そういうのが積み重なって開発速度に差が出てくるんだよ getなんたらは使うのやめて
全部querySelectorAllだけで開発するのが
今のトレンドだからね。
過去のやり方は捨てよう getElementByIdをquerySelectorAllに書き換えて
さらにループを使わなければいけなくなる。 わざわざIDが割り振られてるもんを複数引っ張ってきてループで同じ処理するなんて構造上ありえん
しかも速度重視ならquerySelectorAllなんて使うわけがない つかgetElementByIdとか使ったこと無いし、必要ないな
idが振られてる要素は最初からそのid名で変数アクセスが出来るんだから >>486の場面が浮かばないのだが
書き換えるとこって'_'の中くらいだよね、それは$(～)も同じこと
複数書き換えでもエディタの置き換えで済む
そもそもidはピンポイント指定に意味があるのに（>>490の通り）
複数処理するなら数にもよるが多いならclassつけるわ >>490
> わざわざIDが割り振られてるもんを複数引っ張ってきてループで同じ処理するなんて構造上ありえん
お前は馬鹿か？
一つしかない前提でIDをふったが複数必要な場合がでてきた
クラスに変更した方がいいってなった時に
コードを書き換えるって話をしてるんだろ。
最初からすべて複数（0個以上）存在するものとしてコードを書けば
その要素が動的ページで条件によっては一つも表示されない場合でも
複数表示された場合でも、コードはそれらの違いを気にする必要がなくなる。
条件分岐が減るということでそれはテストとバグを減らすことにつながるわけだ jqObj は、0 以上で、常に、複数が考慮されている。
単数でも、複数形・コンテナとして扱うから、一貫性がある
常に、jqObj を使っておけば、メソッドチェーンもできるし、
0 要素では、止まる
null エラー・No Method Error にならない。
JavaScript のエラーになる前に、jQuery 内のエラーになる
jqObj は、安全装置みたいなもの。
その代わり、メモリを食う > jqObj は、安全装置みたいなもの。
珍しい言い方だなｗ
jQueryっていうのは基本的な思想がCSSに近いんだよ。
CSSが要素に対してセレクタでスタイルを適用するものなら
jQueryは要素に対してセレクタで処理を適用するもの
CSSで .class { } と書いても #id { } 書いても
どちらも要素がなくてもエラーにならないだろ？
これと一緒なんだよ。
jQueryをDOM APIの代わりとして、要素取ってきて存在すれば～みたいな
手続き型スタイルでコードを書いているとjQueryのメリットに気づかない
.class { } みたいに、セレクタを書いてその中身を書くように
jQuery でも $('.class').css({}) みたいな感じで処理を書くのではなく
定義する感じで使うのが正しい DOM APIだとセレクタで取ってきた要素群にたいして
ループで一つ一つ回して、何かの処理を施していくけど、
jQueryだとセレクタに一致する要素群に対する
処理を適用するという感じで使う。
CSSでセレクタに一致する要素群に対して
スタイルを適用するのと同じ感じ >>493
>一つしかない前提でIDをふったが複数必要な場合がでてきたクラスに変更した方がいいってなった時にコードを書き換える
コードの記述に何使ってる？
すぐ上に書かれてるように一発でできるぞ
それに「#」を「.」に変える方が面倒
よってget～の方が開発速度は断然早いし楽
それを勧めてるわけではなく開発速度言うからその点とメンテ性についてな そもそもIDをやめてclassにしてforとかで回すことにしたんなら
それはもう「書き換え」じゃなくて「追記」だろうが
大体増減する可能性なんかないからID振るのに
馬鹿丸出しだなこいつ>>493 > それはもう「書き換え」じゃなくて「追記」だろうが
言葉遊び？ なら追記する手間が必要だっていう話
なんでいちいちループなんてしないといけないのだ？
0個以上の要素群に対して処理を書けばいいだろ
ループも条件分岐もいらない > 大体増減する可能性なんかないからID振るのに
将来のことなんか誰にも分からない >>499-500
「IDをclassに変える必要になった」なんて想定がそもそも無意味
「最初からIDはあった」んだから
そのIDをどう扱うかが最初の論点であって
「classに変更することにした」なんて条件の覆しはただの詭弁のガイドライン どこが詭弁のガイドラインなのか？
反論ではなく自分の感情をぶちまけるだけじゃ
話にはならんな > 最初からIDはあったんだから！！！
意味不明ｗ まあ最初は一つでいいと思っていたものが
複数になることなんてよくある話だよな。
汎用的なコンポーネントを作るという考え方が
ない人にはわからないかもしれないが 話の起点がこれ>>469なのに白痴化＆草で論点ずらしとか
もうとっくに言い負かされてんじゃん >>469は誰にもでもわかる理由で
window.statusとかで<div id="status"></div>を
取得するのはダメだな～ってわかるから
みんな無視していたんだが？ それに>>469が話の起点にはならないな。
>>469自体が、どれかに対するレスなのは読みば明らか 唐突に1分間隔で連投した挙句強引に結論付けようとしたのがじわる
>>502-505 痛いところ突かれるとしばらく黙り込んでるのもじわる 話の起点は>>467で
> 手元にある市販のjQuery解説書がget～ByIdと$(～)が不規則に混在してて気持ち悪い
jQueryを使っているのなら、$(～)を使って0個以上の要素群に対して
処理を適用する方式であれば、要素数が変わったとしても
コードは一切変える必要がなく、それがCSSと親和性が高い
jQueryの特徴であり思想なのだからそれに従うべきって答えになるだろう。
jQueryの特徴はセレクタが使えることじゃないんだよ。
セレクタはDOM APIでも使える（ようになった）だけど
思想が違うので、DOM APIでは要素群に対してループして
手続き型風に処理を記述しなければいけないが、
jQueryだとCSSと同じように、セレクタに対応する要素群に対して
処理を割り当てるように書くことができる。その統一性は素晴らしい >>510
だからお前はしばらく黙り込んでいたのかｗ get～ByIdの話に"0個以上の要素"とか自分に都合のいい事を言い出してる時点で
それ以降の長文は全部話の摩り替え
というか0個の間もずっと処理を走らせとくようなコードは普通に糞 > get～ByIdの話に"0個以上の要素"とか自分に都合のいい事を言い出してる時点で
メンテナンス性の話を聞かれたのだからそれを答えたまで
これからも何も変わらないという考えの方が
自分の都合のいいことでしかない
ソフトウェアはハードウェアと違って壊れることはない
ソフトウェアにおけるメンテナンスとは仕様の変化に対応することだ。
1個だけある前提のコードと0個以上（＝0個、1個、複数）のどれにでも対応できるコード
そして後者のほうがコード量が短いと無ければ、
jQueryの方がメンテナンス性が高いと結論付けるほかはない
> というか0個の間もずっと処理を走らせとくようなコードは普通に糞
0個の場合は処理は走らないのでクソではない
何も知らないんだなｗ 長文の特徴のガイドライン
１：事実に対して仮定を持ち出す
２：ごくまれな反例をとりあげる
３：自分に有利な将来像を予想する
４：主観で決め付ける
５：資料を示さず自論が支持されていると思わせる
６：一見関係ありそうで関係ない話を始める
７：陰謀であると力説する
８：知能障害を起こす
９：自分の見解を述べずに人格批判をする
10：ありえない解決策を図る
11：レッテル貼りをする
12：決着した話を経緯を無視して蒸し返す
13：勝利宣言をする
14：細かい部分のミスを指摘し相手を無知と認識させる
15：新しい概念が全て正しいのだとミスリードする さてどれがどういうふうに当てはまるのか、
今から、このガイドラインと照らし合わせて
説明してあげましょうかね jqObj を使っておけば楽
メソッドチェーンもできるし、
jqObj.length で、コンテナ中の要素数もわかる
element = document.getElementById(id);
element は、Element オブジェクトだけど、null を返すこともある
つまり、Nullable だから面倒 >>515-516
ガイドライン提示しただけかよｗ >>515
それ、「長文の特徴」とは思えないんだけど
例えば「13：勝利宣言をする」なら「はい論破ｗ」の一文で終わるし >>519
しっ相手にしちゃダメｗ
何かを引用するだけで
何かに反論した気になってるんだから
それで満足させてやれ。そうすれば消えるから 面白いなｗ こんなのもあるのか。
「詭弁の特徴のガイドライン」を論破する
https://togetter.com/li/476728
まともに知ってる人からすれば詭弁の特徴のガイドライン自体が
詭弁だって分かってるとは思うが で結局>>472↓の理由はどれ？
>メンテナンス速度とか修正速度ならこれまた文字数が少ないほうが最速になる
エディタを使う限りそうでもない、場合によってその逆も多いのだが 例えばjQuery専用にカスタマイズされたエディタがあったとして
ショートカット一つで、$('')と入力して''の間に
カーソルが移動するようにしていたとしよう。
それからそれから？ jquery-snippetsなどの入力補完プラグインを設定する。
それからそれから？ >>523
>>486がすっとぼけてるから確定できないが一般的には>>497 >>497が明らかに間違いなのは、
getElementByIdをgetElementsByClassNameに変えても動かないということだ。
例えばこれは動かない
var el = document.getElementsByClassName("hoge");
el.addEventListener("click", function() {}, false);
jQueryであればよっぽど変なことをしていない限り
$('#hoge').click(function() {}) を
$('.hoge').click(function() {}) に変えるだけで動く > それに「#」を「.」に変える方が面倒
なんでだろうか？まさか#で検索するとか？
まさかなｗ 普通は #hoge で検索するだろう。 >>527
話ややこしくするのやめてくれ
>>497はそんなこと言ってない
言うなら>>486に聞いてくれないかな >>529
俺が>>486なんだが？
俺が>>497は間違いだって言ってるわけだが？ >>486の書き換えって何だよという突っ込みに突っ込み所間違ってるのがいるな
>>486本人が話逸らすのに必死なのか？ ・・・って、本人かよｗ
ならさっさと聞かれたことに答えたほうがいいよ
ムダにスレが伸びる
>>486の１、2行目 書き換えが面倒っていうのがまさにコレのこと
> getElementByIdをgetElementsByClassNameに変えても動かないということだ。
>
> 例えばこれは動かない
> var el = document.getElementsByClassName("hoge");
> el.addEventListener("click", function() {}, false);
jQueryとは違って0と1と複数を同じように扱えないから、
それごとにコードを書き換える必要がある。
DOMは単にgetElementByIdをgetElementsByClassNameに
書き換えれば終わるってわけじゃないんだよ。
jQueryだと#を.に書き換えるだけでおしまい 複数のidに対応したくなったら、ではないよな
濁そうとしてる？ ID（1個）とクラス（複数）でコードを書き分けること？
DOM API使ってるのならいくらでもあるんじゃない？
jQuery使ってるならば、セレクタの違いだけでどちらも同じコードで
書けるから、IDとクラスの違いなんて気にせず同じコードで書けるけど >>536
そうだねｗ 複数のIDに対応してくたなったら
getElementByIdから、getElementsByClassNameに変えるのではなく
querySelectorAllに書き換えないといけなかったね。 >>515
頭の二文字を書き換えただけなのに当てはまりすぎてて哂う 中身がない文章は何にでも当てはまるようにできてる
占いであなたは悩み事がありますっていうようなものだ そりゃ話の流れでわかるでしょｗ
わからなかったらバカだよ。 あ、話の流れから推測するのか
そんな方法もあるんだな 普通にwindow.idNameを使えばいいのに
statusが～とか、自分の努力を正当化しようとするやつは馬鹿らしいな
そんなん変数名で予約語を誤って使うようなもんだし
どう考えてもgetElementsByIdがコードに並ぶのに比べたら、メリットのほうがでかい 本当にそうかぁ〜？
そこまで気にしないといけない状況ならそれこそjQuery使えばよくね?
それとも皆未だに普通にXHRするのにActiveXObjectとか、attachEventとか普通に使ってるの? >>544
HTML書く時にJavaScriptの非推奨の仕様まで考えて
IDの名前を決めるとかアホだろｗ 生産性や保守性に重点置くことは同意できるし同じくそうしてる
ただ>>534が当てはまるかは全く理解できない
が、それぞれ案件に求められるものや環境が違うからこれ以上は何も言わんよ 「getElementByIdが一番速い」はどうやったって覆しようがない
ただでさえ遅くなるjQueryなんかに最初から出る幕はない
にも関わらず、長文野郎は「jQuery最強」をただ言いたいがために
「idをclassに変更した場合は～」やら「汎用性が～」やら
ありえない仮定や論点のすり替えで「getElementByIdが一番速い」に無理矢理反論しようとしている
というのがこの流れの実態 > 「getElementByIdが一番速い」はどうやったって覆しようがない
誰も覆そうなんてしてねーよｗ
お前だけだよ。実行速度にそんなにこだわってるのは。 >>547
JavaScriptの非推奨の仕様?
そんな話はしていないし、例えばwindow.のプロパティアクセスで予約語を気にする必要はないんだが
ただ取得したいidがwindowのアクセサやメソッドと被るかもしれないという理由で避けるのは事を心配するのは、
例えば変数を使うと予約語と衝突するかもしれないから念の為ちょっと面倒なプロパティアクセスやMapを使うと言ってるのと同じくらいアホらしいと言ってるんだよ
あと１年前くらいからセレクタにもキャッシュやJITが入るようになったから必ずしも何々が早いと言うことは言えない
つうかそんなに山ほどの訳のわからんところに散らばっている要素をIDで取得しないといけない事なんてないので速度は実際どうでもいい
もしそうなら根本の設計が間違ってる >>550
たかだか一メソッドの話で「開発速度」なんて馬鹿な曲解してるのはお前だけだよ >>552
「たかが」の使い方間違ってるぞｗ
何十行、何百行ってあるなかの一メソッドなら
たかが一メソッドだが、
全一メソッドの中での一メソッドは
全部と言ってもいいぐらいの量だ これみろ
You Don't Need jQuery
http://qiita.com/tatesuke/items/b9548dd484b01b139b74
jQueryはいらないことを示そうとして
jQueryの方がコードが大幅に減ることを
明確にしてしまった自爆した記事なｗ >>553
>「たかが」の使い方間違ってるぞｗ
えっ・・・
こいつ日本語を知らない・・・？ >>551
> 例えば変数を使うと予約語と衝突するかもしれないから
じゃあ予約語リスト（windowのプロパティ）を出してくれよ
例えば非標準のhomeは、Firefoxではwindowのアクセサやメソッドと被る
だからどのブラウザでも定義されていないもので、
将来追加されることもない、windowのプロパティを教えてくれ。
予約語は将来も使うなということで今は使われていなくても
予約しているから安全なんだ。
windowのプロパティと被るから使ってはダメな名前一覧を出してくれ たかだか
意義素
程度を表す語の前について、程度が低いことを示す表現
類語
たかだか ・ たったの ・ ものの ・ ほんの >>554
玉の小せえ男だなお前
そこでの要らないっていうのは、
環境が以前と随分変わってきたから、そろそろ局所解を出て冒険しようという高貴な心意気の表してるんだよ
お前みたいな小心者はずっと生ぬるい洞穴に篭って一生を過ごせばいい たかが一メソッドだけを比較するだけじゃ
jQueryが有利なことがわからないって言いたかったんじゃね？
You Don't Need jQuery
http://qiita.com/tatesuke/items/b9548dd484b01b139b74
こっちにjQueryが有利な理由がたくさん出てるけど >>559
> お前みたいな小心者はずっと生ぬるい洞穴に篭って一生を過ごせばいい
じゃあお前はAngularやReact使ったこと有るの？
どちらもDOM APIは使わないんだが、
未だにDOM APIを直接使うほうが
生ぬるい洞穴とかなんとかじゃないかｗ
いい加減DOM APIを捨てましょう >>556
俺が言ってるのは０か１かではない
勿論、そういうのを気にする状況はあるし、そこではgetElementByIdを当然使う
逆に気にしないといけない状況で、window.を使う価値はない
どちらかと言うと全コードでそこまで気にしないでいいだろう状況の方が多いだろうという感覚で言っている
具体的には、気にしないでいいだろう状況というのは、万が一くらいの衝突は全然許容することをイメージしている
だからwindow.homeの方も許容の範囲に入る
それを言い出すと例えば広告システムや何かのフレームワークがかぶるID出すかもしれないけど、
そういうのは長期的なコスパを考える上で誤差の範囲だと思う
まあ毎月１回衝突案件があるか、１年に１回そこで嵌まるくらいなら、ギリギリメリットのほうが大きいというくらいの判断感覚
ブラウザによって違うとか、確かに心配点ではあるが、現実にそこで嵌まる可能性や期待値を考えたら
それこそ普段未だに珍しくない、ブラウザ差で嵌まる沢山の事象数に埋もれるレベルだと思う
だから結論として、俺の経験のもとで、改めて考えてみても、基本的なIDでの要素の推奨取得方法は、それだとギリギリくらいで言える なんだかんだで>>560が翻訳されたのが一年半近く前の2016年04月12日なんだよな
（元記事はいつ公開になるのかしらんが、最初のコミットが22 Nov 2015）
それから何か変わったかと言えば、何も変わってない。
それどころか3%ぐらい使用率が増えてるしな
https://w3techs.com/technologies/history_overview/javascript_library/all/q >>561
バカタレ
何をするにも殆ど常にAngularやReactを使う奴はjQueryと比較すれば皆無と言っていい
ライブラリにおいて何かをするためにそれを使う思考は問題ない、それを使って何かをするという思考になることが問題だ >>562
そいで予約語リスト（使用してはいけないIDリスト）はまだ？
予約語は危険だからちゃんとリストを用意してる。
IDもそうでないと、予約語と一緒とはいえない >>564
言葉遊び？
実行速度を速くすることは目的ではない > たかが一メソッドだけを比較するだけじゃ
取り繕おうとしてて草
日本語が不自由な奴が今までプログラミング言語を語ってたとかまさしくお笑い草だな たかが一メソッドだけを比較ってどういう意味で行ったんだろうかねｗ
一メソッドだけで作られるプログラムなんて殆ど無いし、
2ちゃんねるの例だけで判断？まさかそんなマヌケなことはしてないはずｗ 「たかが一メソッドの話」じゃないぞ
「たかだか一メソッドの話」だぞｗ
たかだか一メソッドで勝った程度でjQueryが
優位ってことにはならないって言ったんだ
その他の例を出せ あ、はい。タイトルに反してこれがjQueryが優位な例です
You Don't Need jQuery
http://qiita.com/tatesuke/items/b9548dd484b01b139b74
こっちにjQueryが有利な理由がたくさん出てるけど もしかして俺に成りすましてるつもりなのかこいつ
自分自身と会話しだすようじゃ人間おしまいだな まだ jQuery を使っている奴は例外なくショボイ。 jQueryを批判することが目的になってる愚か者がいるな スクリプト不可避な状況って、GETとPOSTしか送れないからという場合だけだな。 jQuery厨はdom-level-2-cssの存在すら知らない。マジで。 時間かかろうがかかるまいが、工夫すな、要らん工夫だから、迷惑だから。たとえば多くの2chまとめサイトなんてスクリプトオフですこぶる快適になる。 迷惑わろたｗ人様のサイト利用させて頂いておいて何様だよ
店に入って来るなり因縁つける汚客か！ jQueryはUIが便利でいい
1行でタブやアコーディオンできてしまうなんて楽すぎる
イベント処理やKB操作もできるし、記述方法も似てるから他のUIもすぐ使いこなせるし >>581
俺はそうは思わないな
jQuery自体は素晴らしいけど、jQuery UIは時代について来れていない。
例えばHTML5で大幅に増えたinput要素の属性への対応な
HTML5ではpattern属性で入力値のバリデーションを付けられるのだが、
当然ブラウザ依存。対応していないブラウザだってあるわけだ
jQueryの思想的に考えるならばブラウザ間の非互換性を解決する機能を搭載してほしかった。
jQuery UIはあまりにも開発速度が遅すぎて、すでに多くのブラウザで
pattern属性がサポートされてしまったが、jQueryブランドとしては
そういう足回りにきっちり対応すべきだろう。
もっともそれはjQuery UIの考えが俺の考えと違うのだろうけどさ。
UIのライブラリとしては一昔感があるが、可も不可もなくそんなもんだろう程度
jQuery UIもついでにjQuery Mobileも、俺からすれば単にjQueryを使ってるだけの
一フレームワークでブラウザの標準機能を置き換えるだけの力はないと思ってる。 俺が望むUIフレームワークは将来的にはWebComponentsになるだろう。
現状ではBootstrapが一番近いかな？
やってほしいのは、HTMLタグを書くだけでどのブラウザでも
同じUIになって欲しいだけなんだよ。
例えば、<input type="number"> と書けばIE6とかであっても
数値入力のフォームになってほしかった。
validationの機能も使える
細かい制御はdata-option属性とかで指定できるようにして
コードレスでどのブラウザでも全く同じフォームの機能が
使えるようにしてほしかった。
そしてデザインはCSSでユーザーが自由に決められる。
そういうものをjQueryブランドで実現してほしかったなぁ。 小規模
jQuery UI, jQuery Mobile
中規模
Backbone, Rails
大規模
AngularJS, React 連番のウェブページ(hoge.com/数字.htmlなど)を巡回したいときに疑問があります
単純に
for(){ $.ajax() }
とやると、DOS攻撃みたいになりそうなので
var ld=false;
setInterval(function(){ if(ld){return;} ld=!0; $.ajax().done(function(){ ld=!1; }); },100);
みたいに、doneできたらldをfalseにして次の$.ajaxへ
ldがtrue中はsetIntervalはスカ回し
というようにしています
そこで質問です
そもそもfor(){$.ajax()}で問題ないのか？
もしダメなら、普通はこうする、というような方法を教えてください 別にただのforでもブラウザやOSがセッション数制限するのと、
PINGがdelayの代わりになるのでDOS攻撃になることは無い >>589
考えなし測定なし に否定する癖はやめようね >>582
企業なら社内共用ライブラリの類があるからいいだろうが
個人にとっては十分 >>588は馬鹿だなー
1セッションだけでも連続してアクセスすれば負荷はかかるし、
ping？どこからでてきたらのか。プロトコルが違うから
pingが通っても通らなくても、ウェブサーバーにアセスできるかどうかとは関係ない
だからブラウザはpingなんて使ってない
本当に馬鹿だなーｗ pingって言うのは多分クライアントサーバ間のレイテンシのことだろ
つまり内容が少なくてレスポンスが速くても、１回の通信が完了するまでには100msとかある程度の下限があるということ
その上でセッション数がクライアント側で制限されてペンディングされるとしたら
上限に達した以降はレイテンシ以上の間隔でしかリクエストが発生しない
つまりせいぜい秒間10回程度だろし、仮にサーバがビジーでレスポンスが遅れている時には
リクエスト間隔も勝手に広がるから、それをDOS攻撃とは言いづらいねということじゃないか
まあそれを貧弱なサーバに対して何分も続けたら迷惑だろうから、
総数が数百を越えてくればより気を配る必要があると思う 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 車の『徐行』と同じで一秒間に何回なら『DoS』と言えるわけでもないし、どのくらいの総数なのかも分からないし意味のない議論
最低な例だと岡崎図書館事件みたいなのもあるけど、今回のAjaxの話は同オリジンで身内な訳だし
普通に考えたら秒間数十くらいでDoSになってたら、ページ内に外部リソースを沢山置いたらサイト潰れちゃうことになるしね >>597
自分で意味が無いと言っておきながら、普通に考えたら秒間数十くらいで～とか
いうなボケ
画像などの単なるファイルへのアクセスと、
何らかの処理を行うプログラムへのアクセスじゃ全然意味が違う
物によっては秒間1アクセスでもDoSになるわ >>597
「サーバが停止するほどのアクセス」があればよいので
1秒に数回でも普通にDoS扱いになりえますよ
「普通に考えたら」はもっとも危険な考え方なので
今後はその思考法は控えた方が良いと思います 君は建設的な議論をどうしても言論合戦にしたいみたいだね？
そんな極論を言い出すとそもそもAjaxなんてとてもできなくなると思うけど
別に不特定多数へ公開してどう使われるか分からないツールのコードでもあるまいしなんでそんなに微妙なラインに拘るのかね？
もはや問題をベストに解決する方法じゃなくて、相手の言葉尻を取るというか
相手の意見の反論をひねり出すことだけを考えてるよね
別に俺は言論合戦に論理的に敗北したことにしても全然構わないよ
つうかそんなの「状況による」って言うのは簡単だけど、それじゃ答えにならないんだよね
俺が意味がないと言ったのは、道路状況と同じで上を考えるのは基本的に上限があるが下はキリがないというか、
それこそ０に限りなく近いような場合で、上を仮定した意見に下を仮定して文句行ったりすること
例えば『徐行』の速度を説明するときに、「状況に合わせたすぐ止まれる速度」と言うのは容易いが、
そればかりじゃ答えとして弱いから、具体的に速度を述べるとき、普通車で平均レベルの道路状態を想定するだろう
そこで、大型車の場合とか、凍った鉄板上の人混みの中を進むことを挙げてそれを否定するのはやっぱりおかしいんだよ
何故かと言うと、もはや『徐行』云々の話ではなくなるから、そもそもそこを車が通行していいのかというレベルの話だ
もし秒間数アクセスでもサーバが停止しそうなら、それはサーバを労ることを考える以前に
そもそも幾つものリソースをAjaxで取ってきて利用するということは現実的に不可能だと言えるだろう なんだよここは>>600みたいな気違いの巣窟なのかよ
もう少し建設的な話がしたいんだが、お前邪魔だよ・・・ >>600
今の話はブラウザのJavaScriptだけでDoS攻撃は可能かという話
答は可能
>>588でいきなり間違いがでて困ったものだが
そのすぐ次の>>589で正解が出てる
というのをこのレスで明らかにしただけ
他に何も言うことはないでしょ まあ結局は道路って規制速度が決まってるんだからそれを目安にして走ればいい
Ajaxする時も同じで、サーバのスペックを予想するくらいはして適切な塩梅決めなきゃ駄目 >>602
グダグダ曖昧や冗長に言うのもアレだし、流れをぶった切る効果も狙って少し大袈裟に書いたのは事実だけど、
「なる事はない」というのはブラウザでDoS攻撃をするのが原理的に不可能だと言ってるのとは全然違うよ
質問者が注意深くコードを書かなかったせいで、実際にDoS攻撃として明らかな問題になってしまうことは想定しづらいので、
他の最適化系の問題もそうだけど、昔と比べてもっと楽に愚直に書いても良いんだよ
大袈裟に心配しすぎだよと言うことが言いたかった > 質問者が注意深くコードを書かなかったせいで、実際にDoS攻撃として明らかな問題になってしまうことは想定しづらいので
想定しづらいんじゃなくてお前が、想定してないだけだろ
んで、指摘してもそれがわからんのだろ？
クローラー＝ページを大量に取ってくるツールを作っているのなら、
ページを取ってくる間隔に関して注意深くコードを書かないとDoS攻撃になる
それが答えな。
そりゃそうだろ相手の能力が許す限り
連続でページを取ってくるんだから クローラー側の環境（回線速度や利用者のCPU）がボトルネックになる "かも" しれないが
"かも" っていうことはボトルネックにならない "かも" しれないっていうことだ
負荷をかける可能性もある。
環境がわからないからって、自分の都合が良い環境を想定するんじゃないよ
現在の与えられた情報からだとDoS攻撃になるかもしれないのはあきらか クローラーがサイトに置いてある、robot.txt に従っていない場合、
相手が訴えて、業務妨害になる、可能性が高い
robot.txt が業界標準 >>608
robots.txt だけだと思ってたわ
なんか新しく増えたん？ >>608
関係ない話はやめてくれないかね？
いちいちなんで関係ない話なのか説明せにゃいかん？めんどくせーな。
robots.txtにはアクセス頻度の制限を書く所なんてないだろ
今の話は仮に書いていたとしても、10人が同時にクロールしたら
その数値の意味がなくなるからな >>586のコードは100のとこを１秒だったり３秒だったりに変えれば
インターバル ＋ クローラーの回線速度に応じたリクエストまでの時間 ＋ 処理速度
少なくともインターバル分は確実に次のクロールをしないってことでいいの？ いいやそうじゃない
今日みたいに回線トラブルで輻輳が起きれば１分置きだろうが迷惑
きちんと専用のAPIを設計して、一つずつ叩く以外無い >>613
その話は終わってる。
>>612の質問は、インターバル分は確実に
次のクロールをしないのかってこと
>>612
その通り。setIntervalで指定した時間は必ず待つ
ただし前のリクエストが戻ってきてから一定時間後に次のリクエスト発行ではなくて
前のリクエスト発行してから戻って無くても一定時間後にリクエストを発行するから注意
仮にサーバーの処理時間よりも短い間隔でリクエストを発行すると
徐々にサーバーに未処理のリクエストが溜まっていってとDoS攻撃になる可能性がある
遅くなってもよいのならsetTimeoutを使ってリクエストが返ってきてから
次のリクエストを発行するほうがよい > きちんと専用のAPIを設計して
これは意味不明。こいつはAPIの意味をわかってないんだろうなって思う。言いたいのはそんだけ >>614
＞前のリクエスト発行してから戻って無くても一定時間後にリクエストを発行するから注意
>586のコードだとldがture中はリクエストしないような気がするけど >>616
そんな方法で逃げてたとは思わんかったわｗ
!0とか!1とか意味がわかりづらいし、変なコードだな 大人ならもし相手が分かりにくかったせいで自分が悪くないとしても
自分の発言を取り消すに当たって謝罪くらいするだろ .(::(:::(::::／￣￣￣￣＼::::::):::)::)
(::(:::(:::)／・＼ ／・＼(:::):::)::)
.(::(:::(:::) ￣￣ ￣￣ (:::):::)::)
(::(:::(:::) （||||人||||） .(:::):::)::)
.(::(:::(;;;) ＼ | .(;;;):::)::)
(::(:::(::::＼ ＼＿| ／::::):::)::) $('#hoge').append('<span class="fuga">aiu</span>');
でspanのオブジェクトで操作したいんだけど
$('#hoge').append('<span class="fuga">aiu</span>').find('.fuga').append('eo');
findじゃなくて何かもっと簡単なやつなかったっけ・・？ $('<span class="fuga">aiu</span>').appendTo('#hoge')
か？ >>624
そうだったかな・・
でもそれでもいけたわ㌧ >>623
意図がよく分からないけど、一般的にはこうだけど
var $span = $('<span class="fuga">aiu</span>').appendTo('#hoge');
$span.append('eo'); それならこれでいいだろ？
$('<span class="fuga">aiu</span>').append('eo').appendTo('#hoge');
jQueryオブジェクトを変数に入れるのは好かん >>628
$('#hoge').append('<span class="fuga">aiueo</span>');
それならこれと同じだろｗ appendTo二回やりたいときはどうすればいいの
$('<span></span>').appendTo('<div id="fuga"></div>').appendTo('#hoge').append('あ');
ってやって
<div id="#hoge"><div id="fuga"><span>あ</span></div></div>
ってなるかと思ったら結果は
<div id="#hoge"><span>あ</span></div>
#fuga要素がスルーされた >>629
.append('eo') を勝手に消すな >>630
何をどうしたいのか面倒だから読まないが
$('<div/>').append($('<span/>').append('あ'))
とかもできるから後は頑張って 外部から要素を複数取ってきて、もともとある要素にwrapしつつ挿入
さらに外部から取得した要素の下にbr要素を入れる
っていう感じ
簡易verはこんな感じで.postが外部要素だと思ってくれ
html
<div id="hoge"></div>
<span class="post">あ</span>
<span class="post">い</span>
<span class="post">う</span>
js
var $span=$('span.post');
$('<div id="fuga" />').append($span).appendTo('#hoge').after('<br>');
結果はafterが#fugaにかかってしまう
各spanの下に<br>入れたい
一行で（$span抜き、find,parent,child系なしで） ちなみに想定する結果はこう
<div id="hoge">
<div id="fuga">
<span class="post">あ</span>
<br>
<span class="post">い</span>
<br>
<span class="post">う</span>
<br>
</div> >>631
結果だけなんだからそもそも必要ないだろ？
どういう頭してんだよｗ >>635
論点は、append（appendTo）を使ってどのように
つなげて書けるかなんだから、最終結果が同じだからって
肝心のつなげて書く処理を省いたらダメ
論点がわからないってのがアスペの特徴の一つなんだろうね。 >>634
$('span.post').appendTo(
$('<div id="fuga" />').appendTo('#hoge')
).after('<br>'); 「４桁の数字」を確認するためには
str.match(/[0-9]{4}/g);
だけど、これだと例えば
var str='aa12345678bb4321cc';
こういうとき8桁の数字(12345678)を
4桁の数字２つとしてマッチしちゃうんだけどどうしたらいいですか 頭とお尻をつけて
str.match(/^[0-9]{4}$/g);
としましたがこれだと先頭からなのでヒットしないんじゃ・・？と思ったら案の定nullになりました >>640
0-9で4回以上連続だからそうなるよ
大半が規則的な文字列だからstr.match(/[0-9]{4}/g)[1]とか、
lengthでフィルタリングしたいいんじゃないの？ つまり文章中に存在する数学的な意味での「４桁の自然数」を判別することは
一行の正規表現だけではできない
ということでいいのでしょうか？
例えば、match(/[0-9]+/g)で「連続した数字の文字列」をmatchさせて
結果を全部ループ、4桁以外は弾く
みたいにワンクッション置けばいいのか、ということです var str='aa12345678bb4321cc';
str.match(/[0-9]+/g).map(n=>n.length<=4?n:null);
自分で考えてみたところの例ですが
このnullの部分を（mapの中で）無かったことにしたいのですが無理ですよね
結果が[null,4321]となるので、（map中の操作で）結果が[4321]となるようにしたい 自己解決？しました
いろいろとぐぐってみたところgrepというjquery関数があったみたいです
var str='aa12345678bb4321cc';
$.grep(str.match(/[0-9]+/g),function(n){return n.length<=4});
でできました すでに646で示しているのでその指摘はさすがに野暮ったいかと >>647
正規表現だけでできるよ
var str='aa12345678bb4321cc';
str.match(/(?<!\d)\d{1,4}(?!\d)/g); // ["4321"] >>651
VM3774:1 Uncaught SyntaxError: Invalid regular expression: /(?<!\d)\d{1,4}(?!\d)/: Invalid group
at <anonymous>:1:4 それがChromeやFirefoxで最初から使えるようになるのは年明けから年度末ってとこだろうな formをreset()したとき、ページトップにスクロールせず現状維持したいです
位置取得して再設定以外で何か方法ないでしょうか？ 普通はフォームをリセットしてもページトップにスクロールしません。 >>634
<p class="post">あ</p>
<p class="post">い</p>
<p class="post">う</p>
じゃだめなん？brに悩む必要ない >>657
pは改行するためのものではなくて段落を
作るためのものなのだから<br>を入れるのとでは
意味が変わってしまう。 var $span = $('span.post').css('display', 'block');
$('<div id="fuga" />').append($span).appendTo('#hoge'); >>659
あいうは省略した例ではないの？1行の文？
い
い
ん
だ
よ
は変だが<p>いいんだよ</p>はOK >>661
OKかどうかは別の段落にしたいかどうかできまるわけで、
文字の長さがどうとか一行とか関係ない。
段落を作りたいかどうか ajaxでPOSTするとき、gzip圧縮させない方法を教えて >>662
そうそう、だから基本>>657でいい
それ以上は実際のものを見ないと何とも言えん > そうそう、だから基本>>657でいい
改行入れたいと言ってるのに段落に分けるのは
間違いだって言ってる。
日本語ちゃんと読める？
・ （段落をわけずに）改行を入れたい
・ 段落を分ける
意味がぜんぜん違ってる <p>でも<br>でも見た目上改行されるんだから
どっち使ってもいいでしょｗｗｗ
みたいに思ってるやつまだいるんだな。
テーブルタグでレイアウト作るやつと一緒。
見た目はCSSでやるんだよ。<p>だからといって
必ずしも改行されるわけじゃない。
段落と改行は意味が違うと言ってるのに、
見た目が一緒なら変えてもいいと思ってる。
どうせどんなばあいでも改行は使わず<p>を
使うのが正解だって思い込んでるんだろうな あと後出しで聞かなきゃ何が正解かわからない
<p>が正しいかどうかもわからないって言い訳するなら、
<p>にするのが正しいって言わずに最初に聞けって話だ。
人の話を聞かないで勝手に、条件を変えた上に
俺のほうが正しい！だが実際のものを見ないと正しいか分からん！とか
迷惑でしか無いよ （段落をわけずに）と最初に条件ある？
たいていのブラウザ標準では段落と改行は見た目一緒ではなく間隔が違う。
それはCSSで変えられるとして、633が”一行で”をどう捉えてるかだ。
初心者は国語の段落をHTMLにそのまま当てはめてしまうケースが多い。
実物見ないとというのはもっとも。 >>668
あるだろ
> 外部から要素を複数取ってきて、もともとある要素にwrapしつつ挿入
> さらに外部から取得した要素の下にbr要素を入れる
> っていう感じ 要素の下にbr要素を入れるって書いてあるんだから
それをそのまま実装すれば良いんだよ。
質問者は本当はhrを入れたいのかもしれない。
そんなことわからないんだから。
そして次点のやり方が、なぜbrを入れたいのか？
pではだめなのかと質問することだな
それをしないで勝手にpに変えて、こっちが正しいと言い張るのがだめだってーの。
p使えば改行と見た目一緒だ。見た目が一緒だから
どのタグ使ってもいいんだってこれ初心者の考え方だから。
見た目はCSSで制御するもので、HTMLは文書構造をつくるというものを分かってない。
どこかで聞きかじったであろう、「brはだめなんだぜ。pをつかうんだぜ。」
って話をなにも理解せずに言ってるだけ >>666
>どうせどんなばあいでも改行は使わず<p>を
>使うのが正解だって思い込んでるんだろうな
brとpは使い分けてる
根拠のない罵りのようなことはやめてくれ > じゃだめなん？
> 基本
と書いてある（同一かは知らんが）。
なんか人物ごっちゃになってるのでは？
>>669
それは決定的理由にはならんだろうよ。 <p>に変更した決定的理由は何だ？
ないだろ。
元の条件を勝手に変えるなって言ってるだけ。
それとも思い込みで話すつもりか
俺の世界の普通ではbrはpに変えるのが正しいんだって
頭悪いぞ。 どう読んだらそうなるのか・・・すぐ上に書いてあるのに
元の条件も何も、元の人がもっと詳しく書かない限りこれ以上は無意味
もうその必要ないだろうから終了だよ だから最初に言っただろ
もっと詳しく書かない限り無意味だというのなら、
<p>が正解だと言うなってことだ。
<p>が正解だって言うことが無意味だって
自分で言って恥ずかしくないのか？ ついでにいうと>>639で>>634が望む答えは出てる。
だから質問者はもうとっくにいない。
答えが出てる問題に対して、
>>634で想定する結果と違うものを出して、
これが正しいとか人の話を聞かない態度も大概にしろと <p>が正解だとどこに書いてあるのか
なぜ先走って解釈するのか
なぜそんなにキレてるのか
なぜそんなにムキになってるのか >>664に書いてあるな
> そうそう、だから基本>>657でいい
意味を変えておきながら基本それで良いとか意味不明。
変更すべき決定的理由がない。
改行と段落は見た目が見てるから変えたとしか思えない。
見た目はCSSでやるという基本がわかってない証拠 見た目はCSSはその通りだがなぜpのデフォの状態を無視するのか
なぜ671を無視するのか
なぜ勝手に決め付けてるのか
なぜ提案と確定を同一視しているのか >>678
基本>>657でいい（だからその方法もある）
提案であって正解だの断定ではないと読めるが
見た目で<br>かますのも少なくないからそう書いただけでしょ >>679
> 見た目はCSSはその通りだがなぜpのデフォの状態を無視するのか
見た目の話はしてないから。
pとbrは同じか違うかの話しかしてない。
答は違う。
例え見た目のデフォルトが同じでも違うものは違う。
むしろなんで見た目が一緒ならbrをpに置き換えていい
思ってるのかのほうが分からん。
なんでpとbrの意味を無視するのか？
>>680
> 基本>>657でいい（だからその方法もある）
だからなんでだよ？
brを入れたいと言ってるのに、違うものに変えたらダメだろ >>679
> 見た目はCSSはその通りだがなぜpのデフォの状態を無視するのか
pのデフォルトの見た目を気にしろという意見は
やっぱりbrとpの見た目だけをみて
「見た目が一緒だからということを理由」に
意味を変えたってことなんだろな 分章構造なんて到底無視しているんだから<br />、<p>でも何でもいい
あえて改行に拘るなら<wbr>な ajaxでPOSTするとき、gzip圧縮させない方法を知りたいんだけど
だれか知らない？ >>684
何のデータを圧縮させないのかわからない >>685
POSTするデータ全部
wiresharkでみてると、POSTデータ部分が勝手に圧縮されてる >>686
POST request を送信するときに request から Content-Encoding ヘッダを削除できれば可能になりそうだが、
ブラウザが自動的に加えるものなので、制御できるかどうか調べる必要がある 一々、wireshark で見なければならないの？
F12 開発者ツールで、送受信データを見れるのでは？ >>690
じゃあヒントだけ
formはそのまま使うが、submitイベントを捉えてキャンセルする
そしてJavaScriptで内容を送信する。
HTML5を使えばファイル送信もできるはずだ。
これでスクロールはしない。
昔は隠しiframeに対してPOSTするという方法があったがな。
ただしこの方法はブラウザのページ履歴に影響を及ぼす可能性がある
その制御がうまくできたかどうかはわすれた 繰り返し作業の中で、最大値や最小値を同時進行で更新していきたいのですが
どういうやり方がベストでしょうか
例えばこんなとき
var arr=[];
for(var i=0,len=100;i<len;i++){
arr.push(((!(Math.random()*2|0)?1:-1)*Math.random()*500)|0);//-499から+499の乱数
}
// arrの中の最大値、最小値は？
処理が簡単ならforを抜けたあとに
arrをMath.max,minすればいいのでしょうが。
これをforの中で最大最小値を更新していきたいです。
・forの中が複雑でarrも数が多い
・値は上げ続けも下げ続けもしないが、する時もある（乱数はあくまで例）
・最大、最小の目安は、最後まで処理してみないとわからない
こういうとき、値の初期値部分はどう処理すればいいのでしょうか
var arr=[]
var w=null;//最大値
for(){
//arr.push以下略
w=Math.max(w,arr[i]);
}
たった1回の初期値設定のためにif(w!==null){}なんてやるのでしょうか？ 用途は、データ収集とそのグラフ化
なのでよくよく考えると結局、グラフ描画でforするのでそのときに最大最小求めればいいか
という気がしてきました・・
データ収集だけ、という作業ならデータ収集中に最大最小を取得したい
というのはメリットかもしれませんが・・ 一応念の為、希望する結果は
w=Math.max(w,arr[i]);
の部分で、「wが変な値なら、無視してarr[i]を優先してくれたらいいのに」
という感じです
nullとかundefinedとかfalseとかだと0とみなされるようです
例えばmax(w,arr1[],arr2[],,,)と
いっぱいあった場合に皆はどういうエスケープをするのかなぁ、と
と思って、書いてる途中にひらめきました
w=Math.max(w|arr[i],arr[i]);
これはどうでしょうか
エラーとかないですかね 連投すいません、arr[i]が丁度0になっちゃうとその後
arr[i]が優先されちゃうのでw部分は別のエスケープした方が良さそうですね
てかよく考えたらそれこそ＞たった1回の初期値設定のために
でしたね、、 >>693
> 繰り返し作業の中で、最大値や最小値を同時進行で更新していきたいのですが
> これをforの中で最大最小値を更新していきたいです。
それはやめた方がいい。本来別々にやれる処理を一緒にするとコードが複雑になるだけ。
forの中である処理している。そのforを別の用途に再利用する。
これを俺はforの使い回しと呼んでいるんだが、これやると
また別の処理を入れ込んでいって～、１つのforで複数のことをやって～
あとからメンテナンスする時にforの中のこの行は何のために必要な行かわからなくなる。
> arr.push(((!(Math.random()*2|0)?1:-1)*Math.random()*500)|0);//-499から+499の乱数
randomは複雑なんだから関数にすべき。コメントを書きたくなったら複雑だと思ったほうが良い。
というか変なコード過ぎて何やってるのか分からん。
randomの普通の書き方
function random(min, max) {
return Math.floor( Math.random() * (max + 1 - min) ) + min
}
またlodashにはそのための関数がある。使っったほうが楽だが、使わないなら使わないで
同じ引数を取る関数を自作すれば良い
lodash（https://lodash.com/docs/4.17.4#random）を使った書き方
var random = _.partial(_.random, -499, +499, false) // _.random関数を元に-499から+499の乱数を返す新たな関数を作る
// ↑ は function random() { return _.random(-499, +499, false) } と等価
var arr = _.times(100, random);
var min = _.min(arr)
var max = _.max(arr)
あんたがやりたいのは、たったこれだけで表現できるコードなんだよ。
lodash使わなくてもいいが、最終的にこれだけで表現できるような作りにするべき >>695
> いっぱいあった場合に皆はどういうエスケープをするのかなぁ、と
「エスケープ」という言葉の使い方が間違ってる _.partialを使ってみたが、将来 _.randomに第四引数が増えたりしたらおかしくなるから
関数またはES6のアロー関数を使ったほうが良いかもな
var random = function() { return _.random(-499, +499) }
var random = () => _.random(-499, +499) ES6でいいのならこれだけだな
const arr = _.times(100, () => _.random(-499, +499));
const min = _.min(arr)
const max = _.max(arr) >>697
例えば_.timesのとこを１０万回設定で１００セットなら
_.minで１０万回、_.maxで１０万回の処理
合計30万×100回処理させるというのが通例で
読みやすさを重視した方が良いということですか？ >>701
const startTime = new Date();
const arr = _.times(100000, () => _.random(-499, +499));
const min = _.min(arr)
const max = _.max(arr)
const endTime = new Date();
console.log(endTime - startTime + "ms");
俺の環境で、15ms なんだわ
100セットで1.5秒
これが問題になるかどうかだ 更に言うならrandom以外の部分は3～4ms。100セットで30～40ms
この中で「最大・最小値」の比較と「ループ処理」を行ってる。
１つのforの中に混ぜ込むことで「ループ処理」を減らせるだろうけど
およそ半分の100セットで15msしか減らせない。
10万回×100セットでこの程度なんだよ。forを使いまわす理由はあるかい？ >>701
> 合計30万×100回処理させるというのが通例で
この計算が適当なんだよな。
いかにも3倍になったような書き方だが
ループの部分とループ以外の部分。
ループ以外の部分の処理は変わらない。
残るループの処理は軽くて実行時間は1%しか増えていない。
一番時間がかかってる部分はrandomだろうさ。 >>702-704
なるほど
「こことここ一緒にforにまとめちゃった方が、いや、どうしよう」という
状況によくぶち当たるのですが、一緒のforじゃなきゃダメ
っていう状況以外はまずは分けてから考えた方がよさそうですね
ありがとうございました >>692
やってみましたがsubmitではトップに移動してしまいます
preventDefault / stopPropagation 両方でも return false でも同様です >>706
話の続きをしたければそのコードをアップするように 大量の乱数はcrypto.getRandomValuesを利用すると早い >>707
ご指摘願います
<form id="foo">
（inputなど画面スクロールするようにたくさん）
<button id="bar">確定</button>
</form>
$('#bar').click(function(e){
e.preventDefault();
e.stopPropagation();
$('#foo')[0].submit();
}); スマン、713は誤爆
スレどころか板も違うとこだったorz for(var i=0;;)
みたいにforの中にvarとか入れるのダサいんですけど何かカッコいい書き方ないですかね ってか、forの外から見えずに、forごとに初期化されないものは、
forの中に書くしかないだろ。どの言語でも。
forの中にかけない言語のほうがダサい 勝手にforの手前で代入しろよ
jsはifの()内で代入出来ないのがむしろ糞だが 外でlet文で宣言するとfor文内部のクロージャへの効果が変わってくるけどな >>723
素人は、でなおしてきな
for(let i = 0; i < 10; i++) { }
alert(i)
(index):46 Uncaught ReferenceError: i is not defined >>725
「forの外から見えずに、forごとに初期化されないものは、forの中に書くしかないだろ。どの言語でも。 」
varを使えばforの外から見えるのでforの中に書くしか無いってことはないよね？ 「forの外から見えずに、forごとに初期化されないもの」
varはforの外から見えるので上の条件に当てはまらない 変数名の大文字小文字はまったく別物として扱われるようですが
クラス的に使いたい時に
var Hoge=function(){};
var hoge = new Hoge();
みたいにしたいのですが何かデメリットというか
後々困るみたいな事はありますでしょうか？ >>730
うっかりhogeをHogeと書いたときにバグるんじゃね？
しかも潜っちゃって全然見つけられないタイプ それは飛行機のデメリットとして航空事故を心配するのと同じで大げさだし
letやconstかclass構文を使ってれば解決する話 constはブラウザを選ぶ
そもそも同じにするか？ 命名のうっかりミスを別の手段で補うことを話しているのに
命名規則をきちんと定める話をするアホ >>733
> constはブラウザを選ぶ
だからbebelとか使うんでしょ？
>>734
> というかこんなとこでconst使うなよ
constはvarやletよりも多く使う
変数は宣言とともに代入し、一旦代入したら
それ以降変更しないのが良い作法とされる。
俺はconst以外を使うことはめったいにない >734
その２つのリンクは古すぎるドキュメント。今は参考にならない
Googleの最新のJavaScript Style Guideはこっち
https://google.github.io/styleguide/jsguide.html
https://google.github.io/styleguide/jsguide.html#features-use-const-and-let
> 5.1.1 Use const and let
>
> Declare all local variables with either const or let. Use const by default,
> unless a variable needs to be reassigned. The var keyword must not be used.
ローカル変数はconstかletを使え。デフォルトではconstを使え。ただし再代入ない限り。
varは使うな。としっかり書いている
もう一つの有名なJavaScript Style Guide
https://github.com/airbnb/javascript
もちろんこっちでもconstを使えと書いてある
https://github.com/airbnb/javascript#references--prefer-const
> 2.1 Use const for all of your references; avoid using var
constを使え
> 2.2 If you must reassign references, use let instead of var
どうしても再代入しないといけないなら、letを使え 俺的にはその「一般論」をJSに適応するのは良いことだと思わない
例えば型チェックに拘るんなら最初からTypeScriptを使え、JSは柔軟さを活用しろというのが俺の理屈
もう一つ、世間には良い書き方が一通りであることを良しとする言語もあるが
JSのコミュニティはむしろ色々書け得る可能性と多様性を良しとしてきた
それらに関連して言えることは、JSは表現力が大切で大いに活用していくべきだということ
全てconstにしようというのは、一見慎重にみえて実はピュアJSに取ってはただの横着
letもconstも、もしかするとvarも大事に有意義に使おうと考えてこそJSが生きてくる
別の見かたをするとそれはワレモノを怖いので鋼鉄の箱に突っ込んでしまおうと言ってるようなもの
勿論鋼鉄の箱も重要だけど、それよりも大事なのは緩衝材、そしてデリケートな部分へのさらなるケア
どちらかと言うと、横着するなら布でグルグル巻きにした方がいい、それがJSなんだよ 最初から今のJavaScriptを使えばいいだけ
なにを言い訳がましく言ってるのか まあなんというか、JSは開発環境１つ取ってもメモ帳から補完の効くIDEまで幅広いし
開発者のコミュニティというのも無くてJavaristaなどが片手間で舐めて使ってた傍らで
ごく一部のJS仙人たちが個人個人試行錯誤してそれぞれの境地にたどり着いていたのがJSの文化だから
はい、今日からこういう書き方が良いことになりましたとどっかの誰かに言われても困惑するだけだろうな
つうかじゃあTC39メンバーが、生みの親Brendan Eichが、const使ってJSの議論してるのか、
色んな発表のときそれを推奨しているのかというとそうではないし、
じゃあGoogleのchromiunやV8ではどうかというと、勿論未だにvarのまま
なら直近のプロダクトはどうかというとTSが書くのが主流だが、ES6を使っているものでも勿論constに拘っているものなどない
というか関数型チックに全てを設計していない限りその変数が一度しか代入いらないものなのかどうかはわからない場合も多い
constは所謂定数で関数の戻り値を入れたりする変数はletで宣言するのがやっぱり普通じゃないか 殺伐？
質問も少ないし暇な奴らがまったりだべってるようにしか見えないが >>739
長たらしいが（失礼！）言ってることには同感
>>742
それも同感 jsに関してはどこぞでこうあるべきと言っても厳格にその通りにしてる方が少ないだろうな。
自分が後々含めて困らなけりゃいいってのも多そう。 >>741
あんたが困惑しているからって他人も同じだと思ったらいかんよ
この話はソフトウェアだけに限った話じゃない。
なんだって時が経てば常識は変わる。殆どはいい方向に変わる。
人類が登場してからずっとやってきた子育てだって
今はミルクよりも母乳が推奨されていたりと未だに変わり続けている
訂正されたならば訂正前のやり方は間違いだってことだよ
Googleや世界中の優秀な人たちが考えたことと
どっかのオッサンが考えたことじゃ説得力が大幅に違いすぎる
有名で信用できるコーディングスタイルが示された今
ここでどっちがいいかなんて議論する意味ないんだよ。
所詮おまえも俺も無名なオッサンなんだから
おとなしく信用できるものを信用しましょうや ただ言えるのは
10日でJavaScriptを生み出して
10日でMozillaのCEOを辞任させられた
Brendan Eichが考えていることは
必ずしも正しくないということだよ JSが柔軟だからと言うよりこれから学んでいく子供に規制をかけ過ぎるのは良くないと思うな
個人的には取り返しのつかないことにならないものであれば本人が色々試して時には怪我して学べという教育方針
勿論凡人が集まる会社内だとか、質問者を凡人だと思ってそういうスタイルで指導するのはとても良いことだけどさ
我が子を凡人より上と思いたいように、このスレにわざわざ来てくれた人には凡人より上になって欲しいんだよね なので仕事の成果物としてはconstを使うべきだし
（仕事の成果物に勉強結果は出してはいけません）
別にいろいろ試すのは別に構わないが、
それは仕事とは別でやれって話 >>735
駄目ではなくて使わないで済む方法あるでしょ
リファレンス除いて、サンプルや各記事など使ってるのそんなにないでしょ 仕事とは別にやれ?
なんで仕事が前提になってるんだか
2chの専門板も落ちぶれたものだな
……っていうかそんなスタイル仕事でこそ使えねえよ! >>752
何を言ってるんだ？
「仕事とは別でやれ」＝趣味や勉強でやれって
言ってるんだから仕事前提じゃないだろ
言いたいことは仕事では納得しなくても
詳しい人が良いと言ったやり方をしろということだよ。
おまえ上司がこうしろって指示出してる時、
納得しないからやりませんっていうか？
ここでは業務上の命令があるという前提には当然してないが
（だって仕事前提じゃないもの）業務上の命令がないとして
どちらが良いやり方かを判断するな、そりゃ世界中の優秀な人が
考えたことの方がいいやり方なのは当然の話だろ。
あとは仕事では納得しなくても良いやり方をしろってことだよ。
仕事前提かつ業務命令で悪いやり方をしろっていうのならそれに従うしかないが、
今は仕事前提の話じゃないらしいからねｗ 業務命令はないと解釈しましょう。 仕事では誰もが読めるコードで書かないとダメだよ。
だけどそれはコードの良し悪しじゃなくて
人間の問題だからね。
わかりやすく言うのなら、その会社の人間に欠点があるせいで
悪いコードで書かないといけない。
これをコードの問題にすり替えてはいけない 仕事の場合はお金を頂く為に配慮して書く
他は俺様仕様で勝手にどうぞ >>753
仕事の話をそこで持ってくる時点でおかしいと気づいた方がいい
話の本質や内容が変わってくるからね
そして命令があったらそれに従えって言う何に対してでも使える
意味のない理屈をなんだかんだ言って結局相手に言い返すために批判的に使ってるだけだしね
普通仕事の話を持ってくるのならそれに加えて世間一般ではこういう書き方がされている
だからそれに従っておくのが良いという理屈が付いて来る
そしてそれと全constのような奇抜な思想は完全に相反する
例えそれが良いものだとしても、
納得しなくても良いやり方をしろってことにはならないのが仕事
納得しなくても悪いやり方をさせられるか、世間一般の書き方が良いとされるのが
仕事というキーワードで語れる一般論
君の論は自己矛盾だらけで空中分解してる
挙句の果てに雲行きが怪しくなったら話を広げてポジションを半分手放して逃げる
ポジションをハッキリ決めるのは議論の基本中の基本
君のそんな態度じゃせっかく皆が話し合ったのに何の結論も導かせられない
議論に負けても君が否定されるわけじゃないんだから恐れるな
むしろそういう態度のほうが姑息だと軽蔑されるよ インスタンス生成の結果をまとめたいときがあって
これが超簡略版なのですが
https://jsfiddle.net/Lawj31fs/
これだとその度にaを計算するのが無駄な気がするので
https://jsfiddle.net/Lawj31fs/1/
としてみましたが、最終的にITEMにaの結果まで入ってしまいます
なので、ITEMに入れるときに必要なデータだけを切り貼りしました
https://jsfiddle.net/Lawj31fs/2/
ですが何か腑に落ちません
・aもdataも膨大な場合、作ったのをまた{}で再作成？しない方がいいのだろうか？や
・膨大なaの場合、a入りをITEMにそのままぶっ込むのと、aを排除したものをITEMに入れるのとでは
前者の方がaだけ分メモリを使うのでは・・？など
ITEMの取得後は、そのITEMに入っているデータであれこれしたいと思います（aは一切使わない）
こういう場合はやはり一番目のように、
Double()、triple()でその都度計算して
（例えばaの計算部分を返すprototypeを作るとか
https://jsfiddle.net/Lawj31fs/3/
）
その都度aの計算結果を破棄？する方が良いのでしょうか？
簡略版なのでDoubleもTripleも実際は中身が全然違うので
.mul(2).mul(3)みたいなパラメータで解決、という感じではありません >>756
> そしてそれと全constのような奇抜な思想は完全に相反する
それはあんた特有の話ですよね？
Googleの最新のJavaScript Style Guideはこっち
https://google.github.io/styleguide/jsguide.html
https://google.github.io/styleguide/jsguide.html#features-use-const-and-let
> 5.1.1 Use const and let
>
> Declare all local variables with either const or let. Use const by default,
> unless a variable needs to be reassigned. The var keyword must not be used.
ローカル変数はconstかletを使え。デフォルトではconstを使え。ただし再代入ない限り。
varは使うな。としっかり書いている
もう一つの有名なJavaScript Style Guide
https://github.com/airbnb/javascript
もちろんこっちでもconstを使えと書いてある
https://github.com/airbnb/javascript#references--prefer-const
> 2.1 Use const for all of your references; avoid using var
constを使え
> 2.2 If you must reassign references, use let instead of var
どうしても再代入しないといけないなら、letを使え あと、Lawj31fs/2/のはHogeのprototypeが継承できなくなってしまうので
https://jsfiddle.net/Lawj31fs/5/
こういう感じでITEMをあとからいじりたいのです 訂正
＞簡略版なのでDoubleもTripleも実際は中身が全然違うので
DoubleもTripleも実際は中身が（aの計算部分以外は）全然違うので >>758
だからそれは否定していないって
君の論が間違っていると言っているわけでもない
君の主張と理由が現実に即して噛み合ってないと言いたいのであって、
つまりは君は理想を述べているんだから理想とは程遠い現実をセットにするのはおかしいということであり、
つまり議論に負けない事を優先して、肝心な部分を疎かにしてるんじゃないと非難してるんだよ >>761
> 君の主張と理由が現実に即して噛み合ってないと言いたいのであって、
俺の主張じゃねーよｗ
Googleなどの有名な人たちが言ってる主張だ
現実をより良くするために、Googleなどは
いい方法を提案してるんだろ。
現実がよりよい方法に到達してないからってなんだっていうんだよ。
そんなの当たり前だろ。世の中はどんどん良くなるもんなんだから
現実が悪いから、これからも悪い方法で行きましょうっていうのか？
その考えがおかしいって言ってるの。 それからどうせ分かってないんだろうけど、
99%のコードはvarやletを使わず
constだけで作ることはできる。
それも無理やりconstを使ったということじゃない。
良い書き方をするとconstで十分という話 複数の要素生成し終わってから一括で$('div').click()みたいにイベント付けるのと
要素生成する度にひとつひとつイベント付けるのって何がちがうの >>763
話が少し噛み合ってないが、まあ一旦リセットしよう
それで聞きたいんだけど、君がそのスタイルを推す理由って、
君自身は何でそれこそが良いのかは考えていないけれど、
Google何かが推奨しているから良いに違いないってこと?
そうだとしたら君にはそれを推奨する権利は無い
何故かと言うと君も少し言っているようにどうすべきなのかは場合によるから
それなのに君自身がそれを推奨する効果的な理屈を持っていないのに
人に勧めるというのは悪行であり、そのスタイルへの冒涜 >>766
素直に俺にはconstを使うことのメリットが理解できませんって言えば？
理解できないなら素直に従えよ。
従いたくないなら勉強しろよ。
俺にとっては俺が考えるいいやり方とGoogleなどが考える
いいやり方が一致してるってだけでしかない。 いつもの句点長文馬鹿じゃん
お前らよく飽きもせず相手してるな http://blog.gururimichi.com/entry/2014/11/20/194231
ニコニコ動画と言えば、初期の文化としては2ちゃんねるの影響が色濃く現れておりました。
ゆえに、文章表現としても2chの存在は看過できないものかと。
で、2chにとっての句点と言えば、「使えばバカにされるもの」という印象しかないんだけど、僕だけかしら。
試しにググってみたら、案の定。検索結果のページ名が、こんな感じ。
「レスにいちいち句読点使ってる奴気持ち悪いんだが」
「2chで句点打ってる奴って地雷しか居ないよな」
「2chで句読点つける奴wwwwwwwwwww」
「なんで2chでは句読点が嫌われるのか。」
（2ch 句読点 - Google検索）
こうして見ると、Twitterでもたまに見られる「一部の住人が独自ルールを押し付けている」
ように見えなくもないんですが、句読点が嫌われる理由はよく分からない。どなたか、知っている方がいらっしゃったら教えて下さい。
ただ、「2ちゃんねる」と一口に言っても掲示板ごとに別の文化を持っていたりするので、
一概には言えないようにも思う。例えば、先日の記事で引用した2004年のスレッドなんかは、かなり句点ユーザーが多いように見えます。 >>766
> 何故かと言うと君も少し言っているようにどうすべきなのかは場合によるから
場合によるからって言いたいなら「その場合」をあんたは言わないといけない。
場合によるとわかっているなら、それを言えるはずだろう？
俺はconstがだめな理由を思いつかない。
constがなかった頃とか書き方がわからないとか
const自体の理由ではないものばかりだろう。 >>771
漫画のフキダシも普通は句点はない 一部の句点がついてる出版社の方が不自然
理由は単純で句点有りは文語、句点無しは口語だからだ
匿名掲示板は大抵はチャット感覚で口語が主体
質疑応答以外の会話中に文語で割り込むと空気読めてない異端者な感じが如実に表れるから嫌われる
でもここじゃ目印だから治さなくていいよ なぜ話が噛み合ってないかというと
「楽をしたい」という考え方に二通り有るからだよ。
１つは、もっとコードを書く量を減らして楽にしたい。
バグに遭遇してトラブルになるのを避けたい。
わかりにくいコードを読みたくない。
そのために新しいやり方を導入して行く人と、
もう一つは、勉強したくない。何もしたくない
新しいことを覚えたくない。やりた方を変えたくないという
努力をしない方向で楽をしたい。と考えてる人
後者の人は結局あとで苦労することになるんだが
先のことより目先の楽を取る >>773
> 漫画のフキダシも普通は句点はない
掲示板は漫画の吹き出しじゃないんだが？
おまえ、なんでも漫画の吹き出し感覚だったのか？
そりゃおまえが間違ってるよｗ >>773
> 匿名掲示板は大抵はチャット感覚で口語が主体
そこでおまえのの独自ルールを押し付けるなっていうんだよ。
掲示板って何か知ってるか？
町内や駅にあって、連絡や告知をする所で
会話するところじゃない 低学歴ってコメント欄と掲示板をごっちゃにしてる感あるよねｗ 独自ルールじゃなくて実態だろ
異常者ってのは往々にして客観視ってのが出来ないよな 句読点を見ると鬼のように怒り出すやつって学がないってのもあるだろうけど
あれ小学生が映画を見た感想を言ってるような感覚なんだと思う。
映画を見てどう思った？って小学生に聞いたら大抵は
「面白かった」「ドキドキした」「ワクワクした」みたいなことしか言えないだろう。
そこで映画をしっかり批評できるやつがいたら、それみて
「何あいつ気持ち悪い」って思うのだろう。この感覚。
句読点をつけるのは、読んでる人にとって読みやすくするため。
その一方人に読ませる文章を書くのではなく、ただ単に自分の言いたいことを
叫びたいだけのやつもいる。ヤンキーが大声で叫んで、何かを主張したいのだろうが
うるさすぎて何言ってんのかわかんねーよっていうのあるだろ？あれと一緒。
掲示板で自分が叫びたいだけだから、読ませようとする文章を見るのが
嫌なんだろう。だから句読点を見ると鬼のように怒り出す。
掲示板で自分が叫びたいだけだから、相手と会話をするのではなく
句読点に対して怒り出す。 >>778
実態？
「なんかデータとかあるんですか？」
「それは明らかにあなたの感想ですよね。」
「なんだろう、ウソつくのやめてもらっていいですか」
（ひろゆき） 句読点を入れまくりの長文書くやつ多いよな！
↑ならそれが実態じゃないんですか？ｗ 根本的にこいつの中では自分は多数派にカテゴライズされてんだな 読み飛ばしていいコメントなら一行程度で殴り書きでいいし
長文でちゃんとした内容を書くなら、句読点入れて読みやすくしろ
ってだけの話だよな。 「わくわくした」「ドキドキした」とか言えない自分がいて、
書き込みの中にしっかりとした回答をしているのを見ると
自分が恥ずかしくなるんじゃないかな？
まあAmazonとかで「役に立った」って言われるのは
個性のない感想じゃなくて、しっかりした文章なんだよ 最近の良い書き方はconstを使う書き方みたいですね。
これからそうしていこうと思います。
ありがとうございました。 ああ
自分の自演は誰にもバレてないから多数派に見えてるはず
って思ってんだなｗ 見えないけど自演に決まってるだろそうじゃないと困る >>788
名前を書かないやつの書き込みは全員自演だ 自演したつもりはなくても名前を書かないだけで、
こいつは他人のふりして自演してるとか言い出すやつ多いよな 困ると誤魔化しにかかるところが草
そして最終的には成りすましで逃げる定期 そこまでしてスレ違いの話題にしたいのはなんでなんだろう？ jQueryスレからの転載だけど、こっちの人は
constだけを使って書いているね。コードも無駄がない。
https://jsfiddle.net/3cnkcyjk/14/
jQuery 質問スレッド vol.7 [無断転載禁止]©2ch.net
http://mevius.2ch.net/test/read.cgi/hp/1478055094/14 同一だよ
その前からの流れと口調でわかる
ついでに言うとHTMLスレにも書いてる そうなん？でもそれならそれで
コード書ける人の方が信用できるなぁ どうせ大したコードじゃないんだろ？って思ったら
まともなコードでワロタw
質問者にお金払ってもいいぐらいと言われてるし。 クラスの中のthis.なんたらって変数宣言できないんですか？ >>800と>>801が同一人物（自作自演）ってのは見抜いた const縛りすると結局関数型チックに書くことになるじゃん？
だって
let {a,b,c} = obj
のときもしa,cに変更が無ければ
const {a,c} = obj
let {b} = obj
とするの？
それでやっぱりaは書き換えるとなったらまた変えるの？ってことになる
そういうちぐはぐ一切なくそうと思えば結局変数は使い切りの関数型チックに書くことになる
自分は バカバカしい宗教まがいなことだと思うけどね っていうか単純にルールを固く捉え過ぎているだけじゃね？
Googleもそういう形を想定してはないと思うんだけど
言ってて流石におかしいと思わないのかね？
まああえて言えば頑なに歩道を走らない自転車的な感じだな >>803
関数型チックにするのはすごく良いプログラミング習慣である
というのはおいといて、おまえ大きな勘違いしてるなぁ。
> let {a,b,c} = obj
> のときもしa,cに変更が無ければ
普通は、abcを変更することがないから
const {a,b,c} = obj でいいんだよ
で、なに？ bを変更したくなったら？
そんなもん、 const bb = b + 1 ってすりゃいいだけだろ
何がチグハグなんだ？
おまえがやり方知らないから「うわー、letにするしか思いつかねー」
って言ってるだけじゃんか。本当に情けない あっはっは、自分が出した例を逆に利用されて
bを書き換えない一番簡単な例をだされて
こりゃ屈辱だろうなぁ。関数型とか言うまでに
こんなのも思いつかないようなやつだとはな 以前constの仕様見てこれはすべき！と思ったがIE10以下アウトだったのでやめたことがある
まだいるからな
今のところ命名と名前空間で十分かな const使ってbabelなりで変換すればええやん 変数に代入した値を書き換えないっていうのは方針だから
別にvarであっても書き換えなければ良いだけ
constが使えないのは諦める原因にはならないよ。
varを使って書き換えなければそれで十分。
constは単なるチェック機構にすぎない。
力さえあればIE10以下でも、constを使うのと同じような
コードを書くことはできる。ようはconstの何が
素晴らしいかを理解してそれを実現できるか function(a){
a=a+ホゲ;
return a;
}
みたいに、aを上書きしない方がいい？ >>814
しない方がいい。
更に言うならば、引数はもっと変更しないほうが良い。 関数のargumentsを書き換えようとしたとき or 同じ関数内で同じarguments名を変数名で使おうとしたときに
エラー吐くような宣言てなかったっけ？
function sum(a){
const a=a+10;
return a;
}
console.log(sum(10));} 途中で送信しちゃった
＞同じ関数内で同じarguments名を変数名で使おうとしたときに
は816で防げそうだけど、
＞argumentsを書き換えようとしたとき
はそもそもargumentsは>>815の言うように変更しない、というのを心の中で決めておくってこと？ >>817
何を心配しているのか知らないけど、
特に心配することなんてなにもないよ。
推奨されている方法があるなら、理解できないうちは
それに素直に従っているのが良い。 >>818
例えば
https://jsfiddle.net/k9ganf4u/
同じ関数内でzという変数名を使いたいのでブロックに入れました
が、関数の引数名にzを使っていた場合
https://jsfiddle.net/k9ganf4u/1/
Uncaught ReferenceError: z is not definedというエラー文になりました
SyntaxErrorになってほしいのですが無理でしょうか no-shadowのルールを有効にするのをお忘れなく イベントを登録するときに度々疑問に思うのですが
var obj={};
$().click(function(){
var hoge=obj;
console.log(hoge);
});
こういう感じでclickのイベントを定義するときに
外から何かしらの値を代入する（したい）ときがよくあります
ですが何かモヤモヤするのですがそれで良いのでしょうか？ >>824
言ったそばから句点なしで自演を隠そうとしても無駄ｗ >>823
最初から設計とスタイルがカチッと決まっていない場合は
そういうのを受け入れないと開発が進まない >>827
問題ないんですね。ありがとうございました。 >>812
んなことしなくても注意して書いてればいいだけ
ただそれも１つの方法だから各々好きにすればいいのさ constがなくても注意して書けばconstを
使ったのと同じように良い書き方はできる
ようは注意するかどうか
注意していればミスなどしない 俺としてはconst使おうが使うまいが再代入禁止が
広まってくれればどっちでもいいよ 言っておくけどね、ただの『再代入禁止』は手枷足枷を付けるだけの行為で最悪だぞ?
あくまで『再代入する必要がない設計』に価値があるんだぞ?
関数型言語は言語仕様やAPIや環境がそれ向けに整っているから効果があるんだぞ?
JSの場合、まずその環境を整える必要がある
だから単なるスタイルの話として語るのは無理がある
例えばイベント制御にjQuery使うの辞めてRxJSにしようとか、
そういう具体的な話でなく広く推奨することはできない jQueryをちゃんと使って書けば普通に再代入する必要ないやん？ まずその環境を整える必要があるとか言うが
単に関数型で書きやすくするライブラリである
jQueryとlodashを導入すれば良い jQueryはモナドだ とかいうブログあるけどさっぱり分からん
http://blog.anatoo.jp/entry/20100305/1267801847
jQueryは関数型言語っぽいってことなんだろうけど
モナドってなんなんや？ >>823
こういう場合objを引数で渡すのは冗長かな？
$().click(function(obj){
その必要ないのはわかるが若干安全なのと
この関数はこの変数使ってるとすぐわかるので
長くなってくると特に > こういう場合objを引数で渡すのは冗長かな？
冗長だね
なぜならクロージャーっていうのは
そういう場合に引数で渡さなくて良いように
作られているから
クロージャーの「機能」はうまく使うべきだし
「機能」を捨ててまで冗長化する意味がない >>836 あえて悪い言い方で言うｗ
要するに再代入を無くそうという理念でありクロージャとか論外な関数型言語でも
結局値を保持して再利用するということが一切できないとまともなプログラミングなんて不可能だから
関数型のメンツをギリギリ保った状態でそれを出来るようにするための苦肉の策
つまり、モナド＝関数型副作用ｗ >>837
多言語やってるとわかるが値渡しで
渡した値は関数内でどうしようが勝手、元の値には影響ないよというやつだな >>829-830
注意してバグが全部防げるなら苦労は無い そもそも再代入しない設計になってるんなら
再宣言はletだって防げるんだしconstに拘る必要なくね
つうかどうせ仮にconstで再代入で引っ掛かったとしても
letに変えるか別の変数増やすだけでしょ
それが最初からletだったら本当にまずかったって場合は年に１回もないよ絶対 constはない話をしてるんだが
constが使えずletが使えない環境なんてあるのか？ >>841
そりゃそうだ
だから>>730のような1文字Shift押すか否かの違いはどうなの、って話 >>842
> そもそも再代入しない設計になってるんなら
> 再宣言はletだって防げるんだし
letで防げるのは再宣言であって
再代入ではないですよね？
自分で書いた言葉理解してますか？ constベース気になってたので便乗で質問します
どうしてもconstを使えない場合はletで
というのを初心者サイトで見たのですが
そういう場合というのは,forのvar i=0みたいなところでしょうか？ >>846
いやそうでもない
ぶっちゃけ今はfor(let i = 0; i < 10; i++) みたいな
iを+1し続けていくようなコードは書かない
大抵inやofを使う。この場合constでよい
指定した回数ループするってことがまず少ないんだが
その場合は [...Array(3).keys()] のような書き方で
配列を作って配列の数だけforEachすることで実現できる
といってもこの書き方は可読性が悪いのでlodashなどを使うのが良い
_.range(10).forEach(i => console.log(i)) みたいな感じだな こっちの書き方のほうが元のfor(var i =0～に
似ていて分かりやすかったかな？
for(const i in _.range(10)) {
console.log(i)
}
もしくは
for(const i in [...Array(10).keys()]) {
console.log(i)
} >>845
再宣言ならまだしも再代入だけを防げて本当に嬉しいケースって滅多に無いだろって意味だろ
文盲か？ >>845
let a=1;
・・・
let a=2;
を防げるって意味じゃないの？ for-const-inは流石に苦笑。。。
[...Array(10).keys()]とかハッキーなの使うくせにconstに拘るとかわかわかめ constまだやってんだ・・・
もうどっちでもよくね？そもそもIE11以上ってかなり限られない？ fo inは遅いからなるべく++（できれば--）を使うように
記事などを見るが今それは古いのか IE11以上前提てうらやましいわ
最新のCSS使えるし
もっともそうだとしてもクライアントが「やっぱり」と言いかねないから最初からそれ以前対応で書くけどね
ある程度でいいとはいえロボットもどこまで理解してくれるかわからんし >>852
たぶんあんたとは技術力に大きな差が有るんだと思うね
俺の場合、良いコード＝短くシンプルで可読性が高いコードを
書いてきたら自然とconstだけで十分だと理解した。
上から押し付けられたのではなく、自然とそうなったんだよ
たぶんあんたはまだ理解できてない段階
そういう人は技術力が高い人（俺じゃなくてGoogleとかの人）の
意見を素直に聞いたほうが良いよ。技術力が低いのに
今までこのやり方でやってきたんだ、これからもこのやり方でやる
っていうのは一番ダメなパターンだから
自分ひとりならそれでも良いけど、若い人にあんたのやり方を押し付けたらいけない
技術力が高い人のやり方とどっちを押し付けたら良いかは言うまでもない話だろう？ >>853
> もうどっちでもよくね？そもそもIE11以上ってかなり限られない？
いや？ Babel使って変換すればいいからIE6以上対応だよ
それ（Babelを使う）ができないっていう人は、できない理由を
書いてくれたら良い >>850
> 再宣言ならまだしも再代入だけを防げて本当に嬉しいケースって滅多に無いだろって意味だろ
コーディングのレベルにはいくつかの段階が有ると思うんだ
例えば、動けばいいという人
動くのは当然でわかりやすいコードでなければダメだという人
動くのは当然で短いコードでなければダメだという人
動くのは当然でテストしやすいコードでなければダメだという人
コードに品質を求めない人は動けば問題ないという扱いなのだろうが
コードに品質を求める人は動いていたとしても「こういうコードは良くない」という
レベルでも修正対象とする。
つまり高い品質を求めている会社はvarやletは品質が低いという扱いなんだよ。
品質が低いコードを書く人を吊るし上げる方法でも有るｗ
あ、冗談だよ。本当は教育対象になるだけ。教育受けてください。
>>854
> 記事などを見るが今それは古いのか
古いだろうね。その記事の日付を見ればわかると思うよ >>858
babel？ 今でもそんな化石使ってるところあるの？ そりゃあるでしょｗ IE11以上限定で羨ましいって言ってるんだから
あれあれ？それともbabelが不要なほど新しいブラウザ限定でいい
古いブラウザ対応してる所に対して化石だって
馬鹿にしてるんですかね？ｗ それ俺じゃないですね
>>853や>>856ですねｗｗｗ
>>860
おまえ馬鹿だろ？ 話の流れで古いブラウザ対応
する必要があるからbabelなんだよ。もちろんtypescriptでも良いぞ？ こうして>>861みたいなのがトレンドから遅れていくんだな・・・ constのためにbabel使えってわけじゃないよな、まさか >>862
え？ IE11未満のブラウザに対応しなきゃいけない人用の
トレンドって何？ babelを使うとダメな理由がわからない。
それはbabelを使うことで実現できなくなること？
あんたの言うトレンドとは何のことを指すのか具体的に言ってほしいな >>864
そりゃそうだよｗ
今IE11未満に対応しないといけないという要求があったとする。
過去のコードはしょうがないかもしれないけど、新しく作るものは負債にしたくないだろ？
babelを使うのはIE11未満に対応しなくて良くなった時に、古い書き方のコードを
減らすために使うんだよ。つまり古いブラウザ対応とトレンドを両立するためにbabelを使う こんなことを書くとbabelは完璧じゃないと言い出す人がいるが
俺は0か1かの話をしているんじゃなくて、どれだけ古いコードを
「減らせるか」の話をしている。なので些細な問題があったとしても
大局を見て減っていれば目的は達成 負債ってほどでもないだろ
まだまだvarで解説してるものの方が圧倒的に多い
別に後々大幅変更を伴うわけでもなし いや負債だよ。アロー関数があるのとないのでは
lodashのコードの書きやすさが違いすぎる
他にもクラスとかasync/awaitとか重要だしさ
Template Stringsとかも地味に便利だし
細かい書き方で改良がたくさん加えられてる なんか勘違いしてそうだけど
俺はconstのためにbabel使えってわけじゃないよなって
聞かれたから、babelはconstのためだけじゃなく
IE11未満対応が必要な場合にもっと多くの機能を提供してくれるから
babel使えって言ったんだ。と訂正している。 TypeScript派とEcmaScript（babel含む）派に
わかれたよな >>872
TSはCSとかと違ってESに追従しながら型周りを整備しましょうというスタンス
ESもTSを意識しつつ徐々に型周りを整備していきましょうというスタンス
両者は将来統合されることが想定されているのであって敵対する関係ではない lodashの機能全部使うかどうかわからないのでrange以外でめっちゃ使う機能だけ教えてください >>874
2系のドキュメントおすすめ。
よく使う機能から実装されやすいので2系ぐらいが
ちょうどよいと思う
https://lodash.com/docs/2.4.2
4系はあると便利なんだろうけえど、増えすぎだとも思う >>875
変更してないよ。
constを使えないブラウザがある！というならば
babelを使えば良いと言っただけなんだから。
この文章を見て「constのためにbabel使えと言ってる」と解釈するなら
俺は「const使えないブラウザのためにvarを使えってわけじゃないよな、まさか」
と言い返すよ。
だってそうだろ？ たかがconst使えないブラウザがあるってだけで
varを使う理由にはならないんだから。babel使えばいいだけ >>873
> 両者は将来統合されることが想定されているのであって敵対する関係ではない
敵対する関係なんて言ってないよ？
現時点でTypeScriptで書く人とEcmaScriptで書く人に
別れたって話をしている。
別れた分岐が将来統合するか、平行線のまま行くかの話はしてない
それに将来統合するっていうのなら、現在は別れているってことでしょ >>878
だからその分け方はおかしいと言っているんだよ
分けるんならピュアJSモダンブラウザ派と、トランスパイラ派にしないと
BabelをES派に入れちゃうのは良くない だってトランスパイル使うんなら、Babelだって未だESでない機能有効にできるわけだしね
実際ES2017が勧告される前からasync-awaitとか使ってた人も多いし
ES+を幅広い実装でという観点ではTS使いと変わらんのよ >>879
そのわけかたのほうがおかしいだろ？
例えば俺がおまえにプログラム制作を依頼して
あんたはES6でコードを書く。
あんたが作ったものES6で書いたプログラムだろ？
それを否定するのかって話だよ。 >>879
> BabelをES派に入れちゃうのは良くない
その理屈だと、将来ブラウザネイティブでTypeScriptをサポートした時
今のトランスパイラ使ったTypeScriptコードは
TypeScriptコードではないということになって意味不明だぞｗ
どの言語でコードを書いたかと
どうやってそのコードを実行するかは
別々に考えるべきこと。 まあここまで書いたけど、やっぱこの人が何を言いたいのか分からんわ。
babelはトランスパイラであって言語ではない
EcmaScriptという言語で書いたコードもってこい！
それを古いブラウザで動くようにしてやるぜ！
（ここ重要。持ってこさせる言語はEcmaScript限定）
という機能を提供しているトランスパイラというだけだろう？
それ以上でもそれ以下でもない。いや正確にはJSXにもflowにも
対応しているからそれ以上では有るんだが。 追加済みの要素をprependして並べ変えしたいときに
$('#elm2,#elm1,#elm3').prependTo($parent);
て一度にやると、どうやら#elmの取得順に追加しちゃうみたいで
現並びが<#elm1><#elm2><#elm3>のときと<#elm3><#elm2><#elm1>
のときとで実行結果が変わってしまうようです？
なのでforで$('#elm')みたいに一つずつ追加しているのですが
これは仕方ありませんかね？ 念の為補足しときますね
https://jsfiddle.net/ewqvho2w/
$('#hoge').find('.elm1,.elm2,.elm3').prependTo($('#hoge'));
$('#fuga').find('.elm1,.elm2,.elm3').prependTo($('#fuga'));
どちらもほぼ同じコードですが結果は異なってしまいます
期待していたのは$(".elm1,.elm2,.elm3")の並び順に取得して
<elm1><elm2><elm3>という順で追加されないのかな？と思ったのです
（でもよく考えるとそれだと<elm3><elm2><elm1>になりますね）
なのでforで一つずつ$(elm+i)したりソートしたりするしかなく、
何かjqueryにそういう順番を守る？みたいなオプションはないのかなと >>884
セレクタは文書の登場順に要素が取得されると決まってるよ。書いた順ではない。
例えば、<div id="hoge> みたいな要素があったとして、
$('#hoge, div')なんてセレクタだと2回取得されるのか？って
なっちゃうでしょ？ 書いた順番に取る方法はない。
ついでにいうと、addを使ってつなげたとしても文書の登場順になる。
だからといってやり方がないわけじゃなくこんな感じでできる
var elements = $.map(['.elm1','.elm2','.elm3'], function(selector) {
return $('#fuga').find(selector).toArray();
});
$(elements).prependTo('#fuga');
もしくはES6スタイルで
const elements = $.map(['.elm1','.elm2','.elm3'], s => $('#fuga').find(s).toArray());
$(elements).prependTo('#fuga');
もちろんprependToをつなげて書いても良い
また、prependToではなくprependを使うとtoArray()を消せる
var $elements = $.map(['.elm1','.elm2','.elm3'], function(selector) {
return $('#fuga').find(selector);
});
$('#fuga').prepend($elements);
ついでに$(selector, context)の書き方を使うと、ここまで短くできたよ。
$('#fuga').prepend($.map(['.elm1','.elm2','.elm3'], s => $(s, '#fuga'))); >>887
> 何かjqueryにそういう順番を守る？みたいなオプションはないのかなと
jQueryは基本的に順番を保持しないセットとして扱うからね。
順番を保持したいのであれば$([elm1, elm2, ...]) を使う必要があるわけだ
https://api.jquery.com/jQuery/#jQuery-elementArray >>889-890
どうも参考になりました、早速取り入れてみます
ありがとうございました イベント内であるノードを操作するとき、
その度に取得したらいいのかそれとも変数に格納しておくのが良いのか
よくわからないのでどちらがいいのか教えてください
$hoge=$('#hoge');
$('button#fuga').click(function(){ $hoge.text('操作'); });
//がいいのか、それとも
$('button#fuga').click(function(){ $('#hoge').text('操作') });
//がいいのか
//双方メリットデメリットがあるのか、など せっかくjQuery使ってるのにわざわざキャッシュとかする必要ないよ
できるだけ簡潔に書けばいい >>892
jQuery使っていてノードを変数に入れて
置きたくなるのは単に作り方が悪いだけのことが多い
そうでない場合はその都度取得した方がいい
何故かと言うとウェブページは動的に変更されるという
前提にしておいた方が良いから
要素は追加されたり削除されたりする。
必ず１つ有るとは限らない。ないかもしれないし複数あるかもしれない
jQueryを使わない場合は、そういう動的に変更されるという
前提で作るのは難しいが、jQueryを使えばほぼすべてを
0個以上の要素があるという前提で書くことができる。
このスタイルはCSSに似ている。CSSだって要素がなくても複数あっても
問題なく動くだろ？CSSと同じように宣言的に書くことができるのがjQueryなんだ。
話がそれたが、$('#hoge')みたいなIDを指定して取得するのは
jQueryを使っても時間はかからないので気にする必要はない。 作り方が悪いと言うか、センスがない
折角抽象化ライブラリ使ってるのに変に気を掛けるとかアホくさ
そんなに気になるんなら愚直に書いてもキャッシュしてくれるvDOM系使うか
生DOM APIで好きなだけ効率的に書けばいいよ >>896のようなのを使わないという前提で
同一関数内で数回同じ値（上でいう $('#hoge')）を使う場合
かつ同一関数内で動的変更がない設計でもその都度取得したほうがいいのだろうか
また、同一関数内で動的変更の可能性がある場合、かつ処理時間がかかる場合
一旦変数に入れた方が矛盾なく確実ではないのだろうか また、同一関数内で動的変更の可能性がある場合は
メソッドチェーンなどを使うので一旦変数に入れる必要がない。
つーかサンプルじゃなくて実際のコードを持ってきたら？
一旦変数に入れるほうが良くないって説明してあげるから メソッドチェーンは限度あるな
1行で全て処理できない場合、end()などで対応できない場合も考えられる
$('#hoge')の処理→他の処理→$('#hoge')の処理、のように >>899
> 1行で全て処理できない場合、end()などで対応できない場合も考えられる
だからサンプルじゃなくて実際のコードを持ってきたら？
なんでいっつも想像なのかな？ｗ 他の処理→$('#hoge')の処理→$('#hoge')の処理すればいいだけ <select>なんかキーボードですぐ値変わる（変えられる）からな。 >>902
それができないケース今までに経験したことない？
処理というか値参照含めて 経験したことがあったとしても、原則論は変わらんやろ
別に並行宇宙の隅々にまでそんな可能性は落ちとらん言ってるわけやないんやから >> 904
> それができないケース今までに経験したことない？
それを書けって言ってるのに、
これがサンプルも何もそのまんまじゃんって言ったんだから
このサンプルは順番入れ替えられるで終わりだろ >>904
> それができないケース今までに経験したことない？
ありませーんｗ あんたの書き方が悪いだけでーす $('#hoge').val() を100回加算は？ >>908
どういう意味？
$('#hoge').val() を100倍するってこと？ 答えてくれないので、最初のval()で1が入っていたとして
1+1 → 2
2 + 2 → 4
4 + 4 → 8
を100回繰り返すことにしたよｗ
$('#hoge').val(function() {
return _.range(100).reduce(v => v + v, parseInt(this.value))
});
// 1.2676506002282294e+30
https://jsfiddle.net/636wr4mu/
で、本題はなんだっけ？
$('#hoge')を一回で済ませる？ 済ませたが？
何ができないの？
>>909
プログラム未経験？ｗｗｗ
はぁ～、結局ちゃんとした書き方をしらねーだけじゃねーか。
はぁ～、本当に情けない。 更新 一行に修正した
https://jsfiddle.net/636wr4mu/1/
jQueryはforでループをぐるぐる処理する書き方よりも
こういう宣言的な書き方のほうが似合ってるよね。 コード載せるの忘れた
$('#hoge').val((i, value) => _.range(100).reduce(v => v + v, parseInt(value))) 面白い応用例
https://jsfiddle.net/636wr4mu/4/
CSSはセレクタに適合する要素にたいして
同じスタイルを適用するのと同じように
jQueryはセレクタに適合する要素にたいして
同じ処理を適用することができる
なので、#hogeみたいに単独のIDではなく
.hogeみたいなクラスにすると、CSSで
一行ですべての要素に色を付けるのと同様
jQueryで一行で全ての要素に処理を適用できる
<input class="hoge" value="1"><br>
<input class="hoge" value="2"><br>
<input class="hoge" value="3"><br>
.hoge { color: green }
$('.hoge').val((i, value) => _.range(100).reduce(v => v + v, value|0)) ほれ、単に function と return と {} が増えるなーぐらいの話でしかないよ
$('.hoge').val(function(i, value) {
return _.range(100).reduce(function(v) { return v + v; }, value|0);
}); >$('#hoge')の処理→他の処理→$('#hoge')の処理
ではないわな >>917
世間一般こういう書き方してるのでしょうか？
ただfor回したほうがわかりやすくないですか？ >>918
わざとか？
>$('#hoge')の処理→他の処理→$('#hoge')の処理
の例を出せと言ったら
>>908が
> $('#hoge').val() を100回加算は？
って言ったんだよ。
>>908は$('#hoge').val() を100回加算を
$('#hoge')の処理→他の処理→$('#hoge')の処理
の例として出したから、俺はそれを並び替えて
$('#hoge')の処理（の中に他の処理を含める）
として書き直してやったんだよ。
「ではないな」と言われても知らんがなｗ >>919
forで回したいなら回せばいいじゃん？
俺は変数の値を変えるのではなく宣言的に書くのが
優れているという世間一般の認識どおりに書いただけの話
例のconstで十分って話の続きよ
ほらよ。変数の値を変える方に書き換えてあげるよ。
$('.hoge').val(function(i, value) {
let v = parseInt(value);
for (let i = 0; i < 100; i++) { v += v; }
return v;
});
それが今回の$('.hoge')は一回で十分だろって話に
何の関係があるのか知らんが >>919
たかが足し算するのにそんな大げさに書くのは変人の類。
１回変数に入れるだけで、キャッシュする必要ないよは言い過ぎ。
また作り方が悪いとは言えない（多いだから全否定ではないのでそこはＯＫ）。
ちなみに>>894はワシではない。 な？これで証明できただろ？
ちゃんとしたjQueryの書き方で書いていれば、
変数に入れておきたいというシチュエーションがないってことが。
毎回取得すればいいし、取得した方が動的にページが変わっても対応できるし
結局、jQueryオブジェクトを変数に入れて置くのは作り方が悪いってことなんだよ。 ふむ。なーんとなく>>908が>>899の言う$('#hoge')の処理が二回出て来る例で
>>913とかがそれを論破するコードであることに気づいていない人がいそうだ。
解説したほうが良いかね？ template要素に最初にイベント付加しといて
importNodeでイベントもクローンしたいのですができますか？
https://jsfiddle.net/p1bnwqxz/
これですんなり行くと思ったら無理でした
なのでtemplateを諦めてしまったのです
https://jsfiddle.net/p1bnwqxz/1/ >>925
動的に生成される要素に対して
イベントを予めつけるのは無理だよ
こういうのは、document（もしくは#test）に対してイベントを付けておけばいい
といってもjQueryなら簡単。単に引数を変えるだけ
まずは最小限の修正
https://jsfiddle.net/p1bnwqxz/2/
そして余計なものを削った
https://jsfiddle.net/p1bnwqxz/4/
応用（書き方のバリエーション）
https://jsfiddle.net/p1bnwqxz/5/ ん？ jQueryのcloneメソッドにはイベントごとクローンするオプションがあるのか？
でもtemplate要素と組み合わせるとうまくいかない？
興味がある人は試してみるのも良いかも
俺としては親要素にたいしてイベントつける方をすすめるけどね
イベントハンドラを一つしか作らなくていいから軽いはず あぁ、それが
> これですんなり行くと思ったら無理でした
> なのでtemplateを諦めてしまったので
の方か >>926,927
＞動的に生成される要素に対して
＞親要素にたいして
なるほど
今まではイベントは、アクションのある要素一つ一つに（指定して）付加しないと発火しないものだと思っていました
（なので、後からappendされた要素になぜイベントが適用されてるんだろう・・と一瞬意味がわかりませんでした）
CSSみたいな感覚？で良かったのですね
今までもやもやしてた部分がスッキリしました
ありがとうございます >>923
$('#hoge')の「処理を」というより「値を」ということでは >>930
何が言いたいかわからない。
いまの話題は$('#hoge')を$hogeに入れておく必要はないよって話
DOM要素が変化する可能性を考えると、最新のDOMに追従するために
その都度取得した方がいいし、それによる速度低下も殆ど無い
なにより大抵の場合はイベントハンドラ呼び出しごとに1回の取得ですむ >>931
ケース・バイ・ケース
それはキミのローカルルールだろｗ だから入れておいた方がいいケースってのを
聞いてるんだがｗ 入れておいた方がいいというか、入れない方が自然で誰もが読める場合はすでに出てる
最新のDOMに追従はその通りだが変数使わないで無理に不自然にする必要もない
それと負けず嫌いほど論破という言葉を使うのはどの板も同じだな ローカルとかそういう問題じゃなくて
どういう時に変数に入れて2回以上使うかの
コードを書けばいいだけ 他スレにもいたがコード書いて一生懸命なのはありがたいがかなり特殊だよな。 jQuery 3.2でtemplate要素に対応していたんだな
.contents()で中の要素を参照することができる まあjQueryでWeb Compornentsをやるとか旗から見たらタダのjQuery依存症だけどな でもWeb Componentsサポートの機能も入ってるよｗ
https://github.com/jquery/jquery/wiki/Roadmap
Improve support for "Web Components" features like ShadowRoot jQuery自体が仮想DOM的な要素も持っているから相容れないよね >>942
知らない話に無理に参加する必要はないぞｗ
jQueryと仮想DOMは全く関係ないし
Shadow DOMの間違いだとしてもjQueryとは関係ない
jQuery UIの話だとしても、将来jQuery UIをShadow DOMで
実装するというアイデアは誰だって思いつくだろう >>933
var str = $('#manko').text();
$('.chinko').each(function(){
$(this).css('color', $(this).text() == str ? red : blue);
}); ↑ jQueryオブジェクトを変数に入れる必要がない例
（このようにthisを使えば良いんやで） >>944
長い
var str = $('#manko').text();
$('.chinko').css('color', function() {
return $(this).text() == str ? "red" : "blue";
}); つーか、この話題。質問者の次のレスで解決してる話なんかｗ
892 名前：Name_Not_Found[sage] 投稿日：2017/11/03(金) 04:58:11.05 ID:???
イベント内であるノードを操作するとき、
その度に取得したらいいのかそれとも変数に格納しておくのが良いのか
よくわからないのでどちらがいいのか教えてください
$hoge=$('#hoge');
$('button#fuga').click(function(){ $hoge.text('操作'); });
//がいいのか、それとも
$('button#fuga').click(function(){ $('#hoge').text('操作') });
//がいいのか
//双方メリットデメリットがあるのか、など
893 名前：Name_Not_Found[sage] 投稿日：2017/11/03(金) 08:47:53.21 ID:???
せっかくjQuery使ってるのにわざわざキャッシュとかする必要ないよ
できるだけ簡潔に書けばいい $('#fuga').on('click', function(){ $('#hoge').text('操作'); });
IDセレクタに要素名は不要
var $manko = $('#manko');
$('.chinko').each(function(){
if ($manko.text() == $(this).text()) { testが等しい場合の処理 }
else if ($manko.attr('id') == $(this).text()) { idが等しい場合の処理 }
});
こういうケースはキャッシュするべき
若干でも明らかに速度が違ってくる >>949
こっちのほうが早い（キャッシュする意味なくなりました）
var text = $('#manko').text();
var id = $('#manko').attr('id')
$('.chinko').each(function(){
var t = $(this).text();
if (text == t) {
testが等しい場合の処理
} else if (id == t) {
idが等しい場合の処理
}
}); >>950
同じセレクタで呼び出すんだから理論的には十分ある
それは屁理屈 確か句点君の言い分じゃ速さより記述量の少なさと読みやすさを優先してjQueryを使ってるんだろ
そいつにとっては速さのために量を増やすのは方針に反することだろうよ >>951
> var text = $('#manko').text();
> var id = $('#manko').attr('id')
これは無意味
var $manko = $("#manko"),
text = $manko.text(),
id = $manko.attr("id");
$(".chinko").each(function() {
var t = $(this).text();
text == t ? textが等しい場合 : id == t && idが等しい場合;
}); >>954
数マイクロ秒程度しか変わらんことにこだわる意味がない 本当に速度に拘るんならHTMLなんて捨ててWorkerとWebGLを使って
目的を達成する必要最低限な要素をレンダリングした方がいい jqueryとworkerとwebglを全部使った上で
速度と見やすさと記述量を追求すれば良いじゃん
俺はそうしてる jQueryがかぶってるのはDOM操作であって
WorkerとWebGLもDOMとは関係ないからなぁ
DOM操作で開発速度を重視するのならjQueryってのは
これからも変わらないよ >>958
まあ上の例は大げさだが過去にもフルFlashが流行したこともあったし
オーサリングツールだったりフレームワークが発達してくると
DOMを捨てたCanvasでのレンダリングっていうのも当たり前になってくると思う
というか、既にCSS HoudiniではWorkletとCanvasで自前でレンダリングするものだし
jQueryも抽象化してサポートしてくる可能性はあるよ ねーよｗ
DOMっていうのはドキュメントオブジェクトモデルの略だ
これはほとんどHTMLの構造そのまんまだ
HTMLは文書を記述するのに適した言語だ
それがなくなることはない 何をわけのわからないことを言ってるんだか
HTML5はHTMLを文書のためのものからWebアプリケーションのプラットフォームにするという体裁で
文書のためのマークアップ幾つも廃止しただろ
それから幾年か経ちそれでも十分でないから今度はHoudiniみたいなのが出てきてるんだ
そもそも文書のためのものならWeb Componentsとか要らないんだよ
それらは結局HTMLをJSONと同じ構造記述言語として利用しているだけ
そしてそれこそがHTML5が望んだプラットフォームとしてのHTMLの未来
まだ文書云々言ってるやつは最初期の科学者が論文公開しあってた頃のHTML1でも使っとけばいいよ
そっちの方が今よりよっぽど文書を記述するのに「適して」いるから >>963
HTMLは文章構造をもったをマークアップ
HTML5はマルチメディアの対応が強化されただけ
何言ってんだこいつ > 文書のためのマークアップ幾つも廃止しただろ
廃止してないよ？ｗ
廃止したのはスタイルのためのマークアップ
それはCSSに変わったからね
バカさん♪ まあ上の物言いは大げさだけど
HTMLやDOMは文書の為じゃないと示してくれたのはむしろjQueryなんだけどね
jQueryは別にDOMAPIのラッパーとしてだけでなく
Defferedとか革新的な概念も取り入れてきた Compornentsもね
それにHoudiniとかって言うのはそれで終わりじゃなくて ExtensibleWebから来てるもので
標準をどんどん増やすのは難しいから低レベルなAPIを提供して
ライブラリのレベルで自然選択してもらって良いものは新標準に取り入れようっていうものだからね
そこの役にjQueryが収まる可能性は十分にあると思うよ > HTMLやDOMは文書の為じゃないと示してくれたのはむしろjQueryなんだけどね
んなわけねーよ。jQueryが一番基本に忠実だろ。
最近のフレームワークなんかJavaScript知らなければページ表示すらできないレベル
jQueryはHTMLを書いて、そのHTMLにJavaScriptでちょっと味付けするという
基本をずっと守り続けてる。
> Defferedとか革新的な概念も取り入れてきた Compornentsもね
Defferedが「HTMLやDOMは文書の為じゃない」ことの根拠だとするなら
それはおかしい。なぜならDefferedはHTMLやDOMと全く関係ないからだ。
jQueryは基本的にDOM操作ライブラリだが、一部DOMとは関係ない
ユーティリティライブラリも含んでいる。
Defferedなどは、HTMLやDOMの使い方の新しい提案ではないのだから
それを持ち出した所で、HTMLやDOMは文書の為じゃないという話にはつながらない
それからHoudiniとか持ち出してきてるが、最近知って自分の中でブームでも来てんのか？
JavaScriptを使ってCSSを拡張しようってだけだろ。それがなんなんだっていうんだ。
HTMLとCSSの役割分担は変わってねーよ いちいち他人を全否定して波風立てないと気が済まない
お前リアルじゃ孤立してるだろ そんなことよりレスの内容にレスしてくれんか？
しっかりとコミュニケーションを取りましょう >>967
言い方が悪かったね
文章のため「だけ」のものじゃないってことならいい？
あと「HTML」や「DOM API」って言うのがそもそも世間一般的にも仕様的にも
それぞれ「マークアップ言語」や「ドキュメントモデル」を指してるだけじゃないから紛らわしいよね
自分もハッキリとは区別してなく言ってた面もあるからごめんね
自分がこれまでの話で何を感じて何を言いたかったのかというと
例えるなら昔のWebが固定電話なら今のWebはスマートフォンのようなものだということ
だからスマートフォンは電話のためのものだ、そうじゃないっていう話と同じ感じでいた 難しい議論のなか、初歩的な質問で大変申し訳ないのですが
<div id="div1">
<table class="table1"> <trとかtd略> </table>
</div>
<div id="div2">
<table class="table2"> <trとかtd略> </table>
</div>
こんな感じの外部htmlから、table2のhtmlだけ抽出する方法が知りたいです。
url: 'gaibu.html',
cache: false,
success: function(data) {
data1 = $(data).filter("#div2");
}
こんな感じでdiv2だけフィルターはできたんですが、そこから先で詰まっております。
filter().filter()ではtable2が取れず、どうすれば良いのかなぁと。 >>971
$(data).find('table.table2');
$(data).find('#div2 table');
$(data).find('#div2 table.table2');
$(data).find('#div2 > table.table2');
$(data).find('#div2').find('table.table2');
$(data).find('#div2').childlen('table.table2'); >>971ですが
ありがとうございます。>>973の一番上の
$(data).find('table.table2');
でtable2のみ抽出できました。ただ、それ以外の指定だと抽出できませんでした。
これは、本来はこの指定でもできる、ということなのでしょうか？
ちなみに
$(data).filter('#div2').find('table.table2');
は正しく抽出できました。 古いVerで使えないから○○を使えばいい
はスレの主旨違いだな
先ずはネイティブで書けるのだからそれ前提で説明したほうが親切
その上でこういう方法もあると提案するのはかまわんが >>975
誰に対してレスしてんの？
そんな話誰もしてないと思うけど。
仮にjQueryの話として古いVerで使えないなら
使えない部分だけネイティブを使えばいい
（全部書き換える必要はない）と答えるだろうし
ブラウザの話であれば古いブラウザは切り捨てればいい
そして新しいブラウザ専用に書けばいいって答えるな。
その上で、どうしても古いブラウザを切り捨てられないのであれば
babelやtypescriptで変換する方法もあると答える
それもできないというのなら古い書き方で
書き続けるしか無いなって答えるだろう。 いやいや、そういう前提がないことの方が多いでしょ
その時にわざわざ古いVerがってライブラリ持ち出すのは余計なおせっかいってことでしょ 前提がないならどのような答でも良い
どのような答でもいいのに、他人がライブラリを
持ち出すなという方がおせっかいだ 個人使用なら好きなバージョンを使えで終わるけど
公開するプログラムや、商業利用のものであれば
なぜわざわざ潮流に反して古いバージョンを使うのか
理由は求められるだろ。古いって、セキュリティ的に穴があるんだから >>978
ほんと馬鹿だな
それは道尋ねられた人にバスを案内するようなもんだっての
幾らお前がバス好きでも歩いて行ける距離なら普通は歩きの道を教える
エゴは辞めろ、周りからも不快なんだよ、ここまで言われてもまだ分からんか？ >>980
それも一理あるが全く知らない土地で距離も分からずに徒歩で行こうとしていたが
道を尋ねるとバスで行った方が速いと教えて貰い、その分の時間が有効に使えたという場合もある
本人次第だが バスやタクシーを使えば済む話なのに、
バスやタクシーの存在を伏せて人力車を勧めるようなもの もしライブラリ使いたくないんだったら質問者が新たに追加の質問すれば済む話だしな 古いブラウザは切り捨てればいいと簡単にいうがアクセス数に影響するからな スマホアプリのように締め出すんじゃなくて、通常は動作保証もサポートもしない扱いにするでしょう 別にここは業務用相談掲示板じゃないんだし
俺みたいに趣味でプログラミングしてる人だっているだろうし
そうでなくとも小中高くらいの内は理屈を知らないけど便利な公式とか制限されるし
何かの体積計算で求める際でも実際はこんな理想的な物存在しないなんてことは言わない
そういうのは専門学校に行ってからでいい 初心者用の質問スレがあっていいな
回答も不自然な回答でなく一般的な回答で
それが初心者質用質問スレなのかな？ >>980
> それは道尋ねられた人にバスを案内するようなもんだっての
どこそこにに行きたいって言ってる人に、
目的地まである程度距離があればなら、バス案内するだろ？
目的はそこに行きたいのであって手段ではない
もし「歩いていきたい」って手段まで指定しているなら
バス案内しないよ？
でも手段はどうでもいい。目的地まで行きたいというのであれば
普通は最適な方法を答えるよね。
なんでバスで行く方法を教えている所に割り込んできて
若いやつは歩いていけよなんて言われなきゃならないんだ？
それが余計なお世話だっつーの
質問内容よく読んでみろ。生JavaScriptだけを使ってと
手段を限定していたか？してね～だろ してなくても普通の人は別のコンパイラやライブラリ含めてはしないかと
それは選択肢としての話
つまりお前にとって最適でも他の人にはそうでない場合もある
自分の勧める方法が絶対間違いないというような「書き方」はどうかな 前提が示されてなくても
普通は常識的な範疇で物事を考える >>989
じゃあ自分の進める方法ではなく
一番メジャーな方法にしましょうか？ >>976
＞そんな話誰もしてないと思うけど。
ではなぜそんなに食いつくの？身に覚えあるとか？
単なる誤爆かもしれないから流しておけばいいのに 誤爆かもしれないけど
わざわざ相手にしてもらってんだろｗ 古いブラウザ切り捨てられる人はいいよね
こちとらいまだに「IE7」で動くことが条件なんだが >>994
IE8対応、IE9対応、IE10対応、IE11対応・・・って、
調査と動作確認でせこせこ金巻き上げられるのが馬鹿馬鹿しくなったんだろな。 >>994
まあそれが大半の現実だろうな
個人サイトでも最低9以上は対応したいところ
ゲームなどは別にしていちいち分けるなどやってられん このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 490日 22時間 7分 10秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
