+ JavaScript & jQuery 質問用スレッド vol.8 +
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。次スレは>>950が>>2のテンプレ案(本スレで改善案があれば考慮)を元に立ててください
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
+ JavaScript & jQuery 質問用スレッド vol.7 + [無断転載禁止]©2ch.net
http://mevius.2ch.net/test/read.cgi/hp/1467906819/ >>115
おっしゃお気に入り追加ボタンをa要素で実装してる
inoreaderに説教してこい ねぇ? >>115に 反論はしないの?
大手だって間違えてるぞ!って言われても
はい、大手でも間違えますとしか言いようがないんだが
クレームつけるのは自分でやってくれって話 ここで説教はしますけど大手は怖いから説教しませんw じゃあここに大手読んできたら?
なんで自分で反論せずに、大手様に反論して貰おうとしてるのさw 自分で反論する能力がないからに決まってるだろがー! そもそも反論する必要あんのか?
何と戦ってるのこの長文マンは
頭大丈夫か?統合失調症ちゃうか なのに反論してみろって喧嘩ふっかけてて怖いな
被害妄想過ごそう 「大手もやってるから俺も正しい」しか主張出来んのだろ
大手だからこそバリデーションくらいして欲しいわ 顔真っ赤な奴ばっかだな
なんでこう誰でもできるような低賃金言語ってこうもすぐ荒れるかな
もっと他のことにプライドもてよクソ共 誰でも日本語書けますが、プロは日本語を書いて大金を稼いでいます 一番js書いてんのがgoogle
オフィススイート全部jsで書くとか悪夢だ…
しかもtypescript無い時代に… え? Google はGWTとか使ってるんでしょ?
Javaで作ればJavaScriptも作ってくれるとか?
もしかしてもうオワコン?
ゴミをたくさん作ってるのもGoogleだなw 685Name_Not_Found2018/03/28(水) 22:28:13.59ID:???
>>682
いや、そんなにないと思う
どちらかと言えばそれは当てはまるもの全てに処理したいから、class使ってねということだろう
そういう場合はカスタムエレメントでも使ったほうが良い
そうすれば要素が作られた時、挿入されたときに即座に適宜処理ができるんだから
あとから要素をclassで検索して機能を付与するとか、
スマートな解決策のように見えるかもしれないけど、それって実際はただのハックだからね?
どっかの誰かが作った物があって、それに対してハックしたいなら非常に便利が良いと思うよ
でも今どき、オマケでJSによってページを補正するみたいな開発や考え方はしないからね
HTML5の勧告に纏わる公式文書にも書いてあったけど、
HTMLっていうのはアプリケーションプラットフォームになってるんだよ
つまり土台であって、その上にJSとか乗っかって1つのものができるわけ
それが横並びだとか、化粧程度だとか、もしくはJSはHTMLを改造するためのドリルみたいに
捉えてるのだとしたら、その考え方は古臭いと思うよ
686Name_Not_Found2018/03/28(水) 23:31:40.90ID:???
> そういう場合はカスタムエレメントでも使ったほうが良い
そのカスタムエレメント作る用途で使えるって話でしょ?
っていうか、どうやってそれ作るの
ちょっとサンプル書いてみてよ
687Name_Not_Found2018/03/28(水) 23:32:38.83ID:???
> HTMLっていうのはアプリケーションプラットフォームになってるんだよ
それは一部の話ね。
ブログ、ニュース、企業サイト、情報掲載と、
これらウェブの大半はアプリケーションじゃない jq関係ないけど
HTMLがアプリケーションプラットフォームって考え方は
ぶっちゃけ危険極まりないよね・・・ >>136
俺もそう思う。
HTMLで文書じゃなくてアプリケーションを作るっていうのは
ごく一部だよ
大抵はHTMLとCSS、そしてJavaScriptでちょっと味付け
これから変えていこう!なんて波は来てない 素のJS のremove では、動かないブラウザがあるから、
素のJSでは、661 のように書く
だから互換性が高い、jQuery のremoveを使った方がよい
一々、各ブラウザの機能を調べて、素のJSで対応するのが面倒くさい。
古いブラウザを使っている奴もいるし classに対して処理振るのが最善なケースってどんなのがある?
同じ処理つけたい要素を不定数生成しなきゃいけないときは
createElementの時listenerつけたりhandlerの内側でやらせる手がある
classで処理振ると他の場所でclassを
使いまわしされたら想定外のバグが出そう
個人レベルの小規模なら問題にならないかもだけど >>139
それ単にクラスの名前つけルールが無いと困るって言ってるだけだよ。
CSSでも発生する問題
.enabledというクラス名を付けていたら、
他の場所で使い回されて困った。
これと何も変わらん >>140
デザイナはcss変えたために自分の領域で問題が出ればすぐ把握できる
けどjavascript側で問題が出てもわからない
だから切り分けが大事 カスタムエレメントどうやって作るの?という質問の意味が分からない
好きな要素をextendsしてregisterElementするだけじゃないか
そこにjQueryを使う?好きにしたら良いと思うが、
やっぱりjQueryありきの考え方だねと言わざるを得ないね
でも他のライブラリとかも使うかもしれないし、
jQueryで処理しちゃあ生要素に戻して他で処理するみたいなクソコードになると思うよ
それなら最初からjQUeryで完結させたほうが良い
jQueryはそういう他との相容れなさが欠点だからね
remove()が使えない? 使いたい機能があって使えない環境があるなら
ポリフィル書くなり用意するなりすればいいじゃないか
そんな100も200も要るようなことなんて無いしね
それが面倒だからjQuery使うというのはOK
だけど最初から使ったほうが良いという考え方はNG
この違いが分かるか?
結局jQueryありきの価値観の人達って、他と相容れないjQueryを使いすぎて
例えばちょっとポリフィルを作って数個の素朴なライブラリを組み合わせて使うとか、
他のフレームワークを使った方が今回は良いんじゃないかとか考える能が無くなってるんだよ
jQueryだってやり方によっちゃ組み合わせて使える力も持ってるけど
上のカスタムエレメントの件で分かるように使いこなせてないしね
要するに考え方がいつまで経っても超古臭くて閉鎖的なんだよね
とりあえずjQuery使っとけばいいだろうみたいなのはやっぱり良くないよ
物は1つ1つ考えて良く使わないと 他と相容れないってw
JavaScriptに取り込まれてること自体が
jQueryの多大な貢献を示していると思うけど >>143
> カスタムエレメントどうやって作るの?という質問の意味が分からない
> 好きな要素をextendsしてregisterElementするだけじゃないか
だから、このスレか、jsfiddleなどに
実際に動くコードを一つ書くだけですよ。 通常四行必要なところが三行になります!とか
一行で書けます!とか
そんなせせこましい次元じゃなくて
100行必要なところが1行になります!とか
一般に実装されてなくて個人で実装するには難易度が高い関数が使えます!
とか、そういうのないの jQueryを否定できるのは生JavaScriptではなくて
jQueryを超克したライブラリだと思います
そういうライブラリないんですか? ちゃんと安価先を修正してコピペしてて草というか感心した >>147
例えば今は必要性薄くなってきたけどsha512使うためのライブラリとか
zip/unzipするためのライブラリとか
自分で書くには行数すごくなるしいろいろと問題もある
むしろライブラリってこういうのが基本で
jQueryみたいなのは今やどっちかっていうと
「ショートカット集&ポリフィル集」じゃないの? 悔しかったらjQueryに勝るシンプルなsource書いてね jQueryの代替を提供してるのはフレームワークばかりの感じがします
置き換えたらDOM操作以外の余計なものまで付いてくるので困りますね なにせjQuery君によるとDOM操作用のライブラリでは無いらしいからな。 >>146
> 通常四行必要なところが三行になります!とか
> 一行で書けます!とか
> そんなせせこましい次元じゃなくて
四行必要なところが一行になったら1/4
1000行が250行になるんだが >>151
> むしろライブラリってこういうのが基本で
> jQueryみたいなのは今やどっちかっていうと
> 「ショートカット集&ポリフィル集」じゃないの?
数式だよ
「変数Xに5を加えたものを三倍する」
冗長だね
(X + 5) * 3
短い
jQueryは冗長な表現を短くすることができる
これにより可読性が高くなりレビューしやすくなるしバグも少なくなる。
簡潔な表現方法を知っていれば、あえて冗長に書く理由がない
jQueryがライブラリじゃないというのなら
もっと基本な文法に相当するものだと言うよ。 それでjQueryちゃんは
○文字節約できます!
以外にどんな機能を提供してくれるの >>159
関数型風のプログラミング機能
あと機能じゃないが開発工数の削減と
バグを減らしてくれる 開発工数の削減って○文字節約できますを言い換えただけだろw
開発工数の削減ってそんなに重要なことなのかって話だよ >>143
横から申し訳ない
カスタムエレメントってどういうときに使うもの?
いまいち理解できんのでよかったら教えてくれ カスタムエレメントがほしいって思ったことがない
つまりHTMLパーツのコンポーネント化っていう
概念がなくて行き当たりばったりでCSSでデザインしてるだけ
こういうやつもいるからjQueryでクラス使って
コンポーネントに対して処理をする便利さが理解できないんだろうな >>153
それな
jQueryの代替のフレームワークはJavaScriptのフレームワークで
HTML+CSSメインの作り方からJavaScriptメインに
代わってしまう。
わかりやすく言えばプログラミングできなきゃ
HTMLも表示できない。jQueryの利用者が今も増え続けてる理由だよ https://w3techs.com/technologies/history_overview/javascript_library/all
ここ二ヶ月の間73.2%から増えてないから
とうとう上げ止まったか?と思ったら今月73.3%になった
よかった。jQueryの利用者はまだ増え続けてたんだ。 >>164
要素をカスタムしたい場合、という回答では不十分か?
今回の件に限らないけど、どうして何かしら例を出した程度の場合に
そいつにその物事についての説明やサンプルを求めるのかがさっぽり理解できない
俺の考えを知りたいのか?、それとも俺を試してるつもりなのか?
そんなの適当にググって出てくるサイトの筆者の方がよっぽど詳しいし
よっぽどためになる事書いてあるに決まってるだろう
俺はカスタムエレメントの申し子じゃないんだからさ
でもとりあえず上のclassの話で回答しておくと、
要素に何かしらの機能や性質を持たせる、という考え方と違うものとして
何かしらの機能や性質を持った要素が定義してあって、それを使うという考え方を挙げた
例えば一部で幾つか配列操作メソッドがほしいときに、
Array.prortotype、もしくはArrayのインスタンスにメソッドがを定義するのではなく、
Arrayをextendsしたクラスを用意しておいて、必要なときではそちらでインスタンスを作るということ、
このたとえならjQueryはlodashを使うことに近いのかもしれない
ただし、そのlodashは入出力がArrayではなく、独自のArrayLikeオブジェクトになってるって感じ
そこがちょっと無視できないポイント
つまり基本的にlodash世界内で完結するように書くものであって、
lodashに一旦通して配列を加工して、lodash空間はそこで一旦終わらせて、
次に別のものに通していくってことが、ロジック上難しいのではないけれど、概念上困難ということになる 俺が変わりに答えてあげるけど
jQueryならサクッとできることが
カスタムエレメントだとすごく大変 custom components は、React とかだろ
JS は、Ruby, Python みたいに、
バッテリー同梱(batteries included)じゃないから、
標準ライブラリ・フレームワークが無く、自分で探さないといけない
各ブラウザ・スマホの実行環境を考慮した結果、標準にしない方がよい。
標準にすると、性能などで困るメーカーが出てくる >>170
>>685でズバリ具体例を言ってるだろ、コードが欲しいってことか?
具体的に何の具体例をどういう目的で欲してるのかも分からんし
そんなん比較で色々書いてたら俺が書いてきた長文以上の量になるだろう
複数の要素を扱うってことで例を考えるとHTMLだけでもそれなりになるし
書く意味も分からんし書く気は無いよ >>171
Reactは1ミリもweb component/custom elementと関係ありません。
知ったかするな!
しいていうならPolymerだバカ Railsにincludedされてるバッテリー風情がイキがっててワロタwwwww Web Componentsが各ブラウザでネイティブに実装されたら
今のAngularやReactなどのフレームワークは死滅する
一番の問題はフレームワークと共存できないということ
フレームワーク側もシェア維持のためにWeb Componentsに対応するのだろうが
今と作り方がまったく変わってしまう
だけどjQueryはただのライブラリなので、Web Componentsと共存できる
部分的にjQuery、部分的にWeb Componentsを使と言うことが可能
またWeb Components時代になってもコンポーネントとコンポーネントをつなぐ
必要がある。ここにjQueryは使うことができる。
コンポーネントが見つからない場合、今までどおりjQueryを使うこともできる
混ぜて使うことが可能。これがjQueryの大きなメリット >>181
<honoka></honoka>
とかやっておくとかわいい女の子が表示される
みたいなものw じゃあ、bodyに<all></all>と書くだけで
ページ全部が作れるのか カスタムタグとかカスタムエレメントとかウェブコンポーネントとか
正直全部どうでもいい
そんなのより
全部のブラウザでasync/await使えるようにしてくれよ
いつだよ >>167
「jQueryは死んだ」というのが流行ってただけで
実際はむしろ成長中だったのですね urlにおもいっきりJavascriptライブラリって書いてあるやんけ。
しいていうならJavascriptは永久に100%
Javascriptはお釈迦さま。てのひらの上で一番うまく踊れるのが誰か競ってるのがライブラリ。 >>191
ブラウザがお釈迦様。手のひらの上で踊らされてるのがフロントエンドエンジニア。 >>191
リンク先には各ライブラリのシェアだけではなく
ライブラリを使わないというNoneもはいってるよ
だから正確には、どのライブラリ or ライブラリを使わないで競ってることになる
ライブラリを使わないっていうのは素のJavaScriptを使うという意味だ
お前が言うJavaScriptはライブラリを使わないという意味じゃなかったのか?
それともjQueryを使っていてもJavaScript100%に含まれる
(だからこのスレの話題としてOKってことか)
Noneの割合は年々減っている。現在は23.7%。
最近は一年で1%減るぐらいのペース
jQueryはその逆で一年で1%増えるぐらいのペース 正直手のひらの上で踊らされてるのは、
流行りものに流されっぱなしの
JavaScripterだけな気がするw
jQuery使いはストイックだよ
もう10年も踊ってない ライブラリは言語に足りない部分を実現して
言語の未来の形を先取りしているものなので、お釈迦様というのは言い過ぎではないでしょうか?
ライブラリに先導されてJavaScriptはその後をヨチヨチと付いてきているのですから
むしろライブラリの方がお釈迦様的です ライブラリはjavascriptで実現可能なことしか実現できない。
javascriptで書かれてるからなw 高級言語はアセンブラで実現可能なことしか実現できない。
できることと言ったら実現可能なことを、早く安く作れるだけだ
ライブラリもそれと同じ
こればっかりはアセンブラでは実現できないw >>193
その None にはスクリプトすら使わないというのは入っているのかな? Noneの中にJavaScriptすら使わないのがはいっていたら
生JavaScriptを使ってる人はもっと少なくなるな どうせサイト全体でロード記述がどっかにあるかどうかでしょ
機能単位で見たら生jsクソほどありそう >>200
調査方法載ってないんだよな
調査方法載ってないデータはクソ サイトの一覧ないと再検証できないじゃん
この手の調査はだいたいそんなもん >あなたの主張からすると調査方法載ってるので
>クソではないということになりました。
具体的な調査方法が一切無い時点でクソ
たとえばあるサイトにwordpressがどっかにあればそのサイトは各種ライブラリを使っている!と判断されるかもしれない
少なくとも「新たな開発に○○を使っているかどうか」の実証にはなりえない
> 彼らが望むのであれば、ウェブサイトはほとんどの技術を隠すことができるため、
> このタイプの調査は100%正確であることは不可能です。
Webサイトのサーバ側で使ってる言語なんかはともかく
ライブラリも含めて難読化でもしない限りフロント側はかなりわかるはずだよね w3techsっていう怪しいコンサル会社がやってる怪しいリポートしか出すものが無いという事実
良くわからん計算で勝手にこのドメインのアクセス数はいくつ、時価は何ドル、ってやってるクソサイトと同列
sites infoで自家鯖ドメインがNTTのクラウド使ってるとか診断されてて草 > >あなたの主張からすると調査方法載ってるので
> >クソではないということになりました。
>
> 具体的な調査方法が一切無い時点でクソ
こっちに具体的な調査方法が書いてあるよ。
+ JavaScript の質問用スレッド vol.132 +
https://mevius.5ch.net/test/read.cgi/hp/1520329583/742 >>202
> サイトの一覧ないと再検証できないじゃん
それは、自分で複数のサイト(少なくとも数千レベル)を調べて
こうだったって言えば良いのでは?
再検証はできなくても反論はできるでしょ?
再検証できないじゃんというだけじゃ反論にはならないので
相手のデータを否定したことにはならない。 証拠なし根拠なしだから論証にすらなっていないので反論の必要がない
データを否定するもなにも
w3techsのはデータじゃなくて妄想
それを根拠に語るお前も妄想 あぁ、こっちのスレでは調査方法書いてないから
こっちでやろうとしてるのか。卑怯だなw
むこうのスレからコピペするね。
調査方法は以下に書いてますね
https://w3techs.com/faq
> 調査方法載ってないデータはクソ
あなたの主張からすると調査方法載ってるので
クソではないということになりました。
英語わからないならGoogle翻訳使うといいですよ。
> どの技術がサイトで使用されているかをどのように知っていますか?
>
> 主に、Webページのダウンロード時にサイト自体が提供する情報を使用します。
> 言い換えれば、私たちは検索エンジンのようなWebページを取得し、その結果を分析します。
> さらに、Alexa、Google、Microsoft、ipinfo.ioなどのソースから公に入手可能な情報を使用しています 。 英語がわからなくてgoogle翻訳使ってんの自分じゃん?w 英語のまま貼ってもいいけど、読まないやつは読み飛ばすだろうからね
かと言って俺が翻訳するのは面倒 >>209
主にトップページしか検索の対象にしてないってかいてるやんw
クソデータ決定だなw ほらな。だから日本語に翻訳してコピペする必要があるんだよ(苦笑)
しっかり書いてある。英語を読まないから見つけられない
> あなたはホームページだけ、あるいは内部のページだけを分析しますか?
>
> それはサイトについて既に知っているものに依存します。
> しばしばそれはホームページでしかありません。
> 多くの場合、我々はより深くクロールします。 ■ このスレッドは過去ログ倉庫に格納されています