+ JavaScript の質問用スレッド vol.126 +

■ このスレッドは過去ログ倉庫に格納されています
2018/06/02(土) 14:31:23.04ID:B1JKBGEy
JavaScript を自ら学ぶ人のための質問スレッドです。

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。


前スレ
+ JavaScript の質問用スレッド vol.125 +
https://mevius.5ch.net/test/read.cgi/tech/1518940081/

（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）
2018/11/09(金) 07:45:53.68ID:UVRb8J0Z
WebAssemblyとか語るやつは、新しく何ができるかしか言わない。
何がどう楽になるのかをけっして言わない。

なぜか？それを言ってしまうと「あぁうちには関係ありませんね」って
言われるのが目に見えてるからだ

WebAssemblyで楽にならないわけがない。では何が楽になるのか？
マルチプラットフォームのアプリをウェブアプリにするのが楽になるんだよ。
いまウェブの大半を占めるウェブサイトの制作が楽になることはない

新しいことができるようになったら、みんな新しいことをするはずだとか
思ってるのかもしれないが、大半は新しいことなんてしようと思っていない
今の仕事が楽にしようと思っている。

だからWebAssemblyもそうだし、JavaScriptフレームワークの導入も大変だし、
jQuery捨ててDOM APIを使うのも、大変になるだけなので使おうと思わない。

そしてjQueryのスピードにも全く困っていないというのも重要な所だな
2018/11/09(金) 07:53:41.77ID:UVRb8J0Z
>>331
> それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。

いつまで待てばいいの？ｗ

このスレ立ててからもうすぐ2年になる

2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/

You-Dont-Need-jQueryができてからは3年ぐらい立つか？

もうそろそろ結論出たってことでいいと思うんだけど？
あと3年？ 5年？ 10年？ まだまだかかりそうだねぇｗ
2018/11/09(金) 08:05:03.76ID:J9ZYW49D
jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな
そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
だから新規で作るものはjQueryを見送ってるし
保守してる人間たちはこれから廃れていくjQueryにしがみつくしかない
JAVAと同じだな
2018/11/09(金) 08:11:32.70ID:UVRb8J0Z
> jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな

1.7（2011年11月）ぐらいから殆ど変わってないんだが？
もう7年も前だぜ・・・

> そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
ESとは対象分野が違う、ESにDOM操作の命令はない

そういう基本的なところを分ってないやつが
> だから新規で作るものはjQueryを見送ってるし
とかいっても、説得力ゼロだよｗ
2018/11/09(金) 08:14:08.68ID:J9ZYW49D
老害
2018/11/09(金) 08:55:33.36ID:UVRb8J0Z
俺が老害かどうかじゃなくて、現実を見たほうが良くね？ｗ
老害と言われた俺が言ってることが、現実となってるとしたら、
それはどういうことなんだろうね

React、0.6%から0.1%にシェア減っちゃいましたよ？
2018/11/09(金) 09:11:07.67ID:Ijfza7/E
>>303
ありがとう
意外と単純な探し方でびっくりした
宗教論よりこういう書き込みが増えてほしいな
2018/11/09(金) 10:08:49.86ID:OgIaPmrY
>>336
意図的におかしな引用をしたつもりはないが、そう取れたのならすまんかった。
現状認識において、俺と君には大差ない。再度確認するなら、

> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」
そうだ。正確に言えば、そうだった。これが変わりつつある。

> いまウェブの大半を占めるウェブサイトの制作が楽になることはない
これが違う。静的HP用のフレームワークを使えば、楽になる。
本来はWordPress等もここを目指しているはずだが、
JavaScriptをいちいち書かないといけないのなら、それは上手く行ってないだけだね。

> そしてjQueryのスピードにも全く困っていないというのも重要な所だな
これはそうだとも言えるが、そうでも無いとも言える。

そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
それがJQueryかどうかは別だが、
フレームワークもjQueryも無しなら（いろんな意味で）遅いサイトになりにくいのも事実だ。
結果、素で書け、と言われるのもまた然り。
2018/11/09(金) 10:09:17.53ID:OgIaPmrY
が、話が広がりすぎるので絞ると、

・デザイナ（またはその下請けが）JavaScriptを書かなくてよくなったときにjQueryは終わる

というのは俺も君も共通見解だ。これはいいな？なら、逆説的に、君も

・プログラマにはもう既にjQueryは無用の長物となっている

事を認めることになるが、ここまでもいいよな？
そしてデザイナがいつJavaScriptを書かなくて良くなるかは、

・Web componentsが完成して、使えるコンポーネントが "出揃った時" （君）
・静的HP用フレームワークが整備され、普及したとき(俺）

と詳細な意見は異なるが、まあこれは誤差の範囲だろ。

> いつまで待てばいいの？ｗ
「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
なら、10年後くらいではないかな。
今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
そしてその彼等が主力、具体的には30代前半にさしかかり、
「jQueryなんて要りません」派が現場での主流派になったときに牙をむくってだけの話さ。

が、正直なところ、俺と君には議論になるほどの意見の相違はないぞ。
別段、君の現状認識に間違いがあるとも思えないし、jQueryが死ぬにしても時間はかかるよ。
もし頓死する可能性があるとしたら、WebAssemblyの出現によって次の次元のスピード競争に巻き込まれたら、って話さ。
ただ、正直、俺にはWebAssemblyがどこを目指しているのかよく分からんし、そもそも立ち上がるかも微妙だとは思う。
だからって、jQueryが安泰で未来永劫使われる、ってことも無いよ。繰り返すが、
今から始める人にとっては、「重複機能ばっかり…」なのも事実だろ。
2018/11/09(金) 10:41:19.41ID:UVRb8J0Z
>>344
> そうだ。正確に言えば、そうだった。これが変わりつつある。

ねーよｗ

少なくともウェブデザイナがJavaScriptを書くことはない。そうだろう？
2018/11/09(金) 10:43:55.06ID:UVRb8J0Z
>>345
> そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
> それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
> それがJQueryかどうかは別だが、
> フレームワークもjQueryも無しなら（いろんな意味で）遅いサイトになりにくいのも事実だ。
> 結果、素で書け、と言われるのもまた然り。

やっぱり、実行速度しか目に入ってないんだなｗ
かわいそうに。

ほとんどの人は、楽になる方法しか求めてないよ
jQueryをやめて楽になるか？ 何一つ楽にならない

速いとか遅いとか言ってる限り、現状のjQueryのシェアが
落ちてない事実は理解できないだろうよ
2018/11/09(金) 10:44:48.91ID:UVRb8J0Z
> 今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。

同じことをこんなに簡単にできるなんて！
としか思わないよｗ

楽になるかどうかだからね。
2018/11/09(金) 10:46:26.82ID:UVRb8J0Z
document.querySelectorAll() を
$() とかけるだけで、素晴らしいって思うだろうねｗ
2018/11/09(金) 10:53:28.88ID:UVRb8J0Z
>>345
> 「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
> なら、10年後くらいではないかな。

「staticおじさん」なる言葉が発生したときには、staticばかり使ってる人はすでにいなかったわけだが、
jQueryの場合、使っている所が大半を締めてる。状況はぜんぜん違うんだが何と何を比べてるんだ？
2018/11/09(金) 11:16:21.71ID:9aipcx/m
>>343
NGしとくといいよ。
2018/11/09(金) 12:31:06.18ID:ZgQBCm2t
まあ、適材適所っしょ。
React信者は自分のスキルセットを至高で唯一の物だと思いがち。
jQueryで十分なものもあれば、Vueで十分なものもあるし、Reactが適してるものもある。
2018/11/09(金) 14:21:08.83ID:OgIaPmrY
>>349
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねｗ
なるほど君はデザイナ側か。
なら話は平行線だろうし、君はjQueryと心中して問題ないと思うよ。

プログラマにとってはそれはコストではないんだよ。
タイピングも速いし、それ以前に「デバッグ」のコストが大半だから。
色を付けるだけならスモークテスト＝最終テストで、君はその発想しか出来てない。

実際、DOMクエリは100倍くらい遅くて、地道に削除するだけでもかなり高速化する。
だから、 document.getElementsByClassName みたいな糞長ったらしいメソッドで、
書きたくなくさせるのも、効果があるといえばあるのさ。
「高価な操作はソースコード上でもそう見えるようにしろ、そうしないとメンテの時に障害になる」
ってのはC++の思想だが、これも一理あるわけでさ。
(デザイナにとっては色が付けば良しなのだろうが、プログラマにとっては実行速度も管理対象であって）

jQueryが不味いのは、その手の操作がお手軽にできるから、そういった書き方になってしまいがちなこと。
これはjQueryそのものが遅いのではなくて、使う人が悪いのだけど、
これも含めてjQueryが悪いことにされてて、君のようにムキになる人が出てくるのも自然な成り行きではある。

ただ、既に書いたように、jQueryはHTMLベースになる点（なりがちな点）が本質的に筋が悪いんだよ。
ただそれは上記の通り、使う人の問題だが、
CSSクラスベースに移行したらクエリそのものが単純になる/必要なくなるのも事実でさ。
結果、CSSにすら移行出来ないサイトだけがjQueryを使い続けることになり、それは馬鹿にされるのも当然だよ。
そして今の君のような人に対する反動として、10年後に噴出する、というわけさ。

>>350
『今から』10年後な。
jQueryが必要ではなくなってから15年後、ってことだよ。
「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
2018/11/09(金) 15:32:39.21ID:YLhQ0tUv
いちいちなげーんだよ
ここ質問スレだよな？よそ行ってやってくれんか
2018/11/09(金) 18:34:41.79ID:ya9Twat2
>>349
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねｗ

document.querySelectorAll()を$()と書けるようにする方法

方法１：
var $ = document.querySelectorAll.bind(document)
（48文字、minifyで46文字）

方法２：
jQueryのロード
（minify + gzipで約30,000文字ｗ）
ブラウザがgzip解凍後の約85,000文字のjsで書かれたjQueryコードをパース、コンパイルｗｗｗ
結構な時間です
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization/#parsecompile
2018/11/09(金) 19:52:57.84ID:UVRb8J0Z
>>353
やっぱり、実行速度しか頭にないのなｗ
視野狭過ぎでワロタｗ

実行速度も何が何でも速いと思ってる。
そんなに実行速度が重要ならブラウザ使うの止めたほうが良い

速度は許容範囲かどうかで決めるものだ
今jQueryを使ってるサイトは、jQueryの速度が許容範囲ってことだ
なにせ一回読み込めばキャッシュが効くからな
遅いのは最初の一回だけという

> ただ、既に書いたように、jQueryはHTMLベースになる点（なりがちな点）が本質的に筋が悪いんだよ。
ウェブはHTMLベースで書くのだから仕方ないな。むしろHTMLベースで使いにくいものはだめだろう

> 『今から』10年後な。
「jQueryはオワコン（10年後にな！）」
もうこれ完全に不安煽ってるもの以外の何物でしか無いわｗ

> 「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
暗記済みの状態で楽なのはjQuery。覚えるのが嫌いな人っているよね

覚える苦労をして、後の開発を楽にする
VS
覚えるのが嫌だから、開発で大変な思いをしてまで、今楽をしたい

> 君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
切れないが？ ソフトウェア開発において覚えることこそが技術力だし。そうやって覚えてしまうことで
読まなくて良いコードを増やしていくことで、開発速度はあげられる。
もっとも何でも覚えられるわけがないので、より汎用性があって世間でよく使われてるものに限ったほうが良い
つまり、オレオレライブラリなんか覚える価値がないってことな
2018/11/09(金) 19:54:07.17ID:UVRb8J0Z
>>355
> 結構な時間です

誰も速度の違いに気づかないレベルでした
2018/11/09(金) 20:07:12.39ID:62z6ttwQ
実行速度と通信量は重要な要素なわけだよ
昨今は多言語対応も要求されるだけに余計にな
359デフォルトの名無しさん
垢版 |
2018/11/09(金) 20:25:53.76ID:ya9Twat2
>>349
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js";></script>
jQueryおじさん「ワアッ！短い！たった88文字！どーだ参ったか！」





var $=document.querySelectorAll.bind(document)
（46文字）

document.querySelectorAll() を
$() と書けるようにしたいだけで88文字かけて85,000文字のコードをロード、パース、コンパイルさせるjQueryおじさん仕事できなさそうｗｗｗｗｗ
ゴキブリ倒すのに戦車持ってくるみたいなｗｗｗｗｗ
2018/11/09(金) 20:45:00.11ID:OgIaPmrY
>>356
> ソフトウェア開発において覚えることこそが技術力だし。
これは違う。やはり君はプログラマではない。だから分かる必要もないんだが、
ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。

ただ、HTMLベースでやると、君みたいに暗記主体の積み上げ方式で出来るのも事実なんだよ。
だから、君のタイプは今後ともjQueryを使い続けた方が効率はいいし、おそらく君はそうするだろう。

一方、ある程度の能力を備えたプログラマにとっては、抽象化が使えるCSSベースの方が効率がいい。
そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、
強烈に嫌う奴も出てくるわけでさ。

同様のことはPHPにも言える。
PHPも仕様が糞すぎて、いちいち場合分けが必要になり、プログラミング上級者でも綺麗に書けなかったりする。
だから、上級者こそPHPを目の敵にする。
ところが、初心者〜中級者成り立ての程度なら、あれくらいのベタさ加減が丁度いい。
そして、自分達よりも綺麗に書ける上級者が存在しないから、彼等にとってはそれなりに快適な状況になってる。
ただ、上質なコードがその世界に存在しないことは本当に問題で、
結果、上質なコードを見たことがないから、PHPerは自分達のコードがトンデモだ、ということに気づけないでいる。
それがPHPerがやたら叩かれている理由だよ。
彼等の自己評価と、外部から見た客観評価に、ズレが有りすぎるのさ。
ま、これは正直、俺はJavaScripterにも当てはまると思っているけどね。

分かるか？両者が矛盾しているわけではないんだよ。
jQueryを使った方が効率がいいタイプもいれば、jQueryを捨てた方が効率がいいタイプもいる。
暗記ベースなら前者で、抽象化ベースなら後者だ。そして一般のプログラマは後者なんだよ。
だから今後ともjQuery不要論はずっと水掛け論になるんだよ。
言ってしまえばお互いポジショントークをしているにすぎないから。

ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、
CSSで行ける奴、或いは両方とも出来る奴は、CSSベースを選択することになる。
結果、HTMLベースの奴は取り残され、馬鹿にされるポジションになる、というのが俺の見立てであってさ。
2018/11/09(金) 21:09:46.39ID:UVRb8J0Z
>>360
> ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。

お前、論理的な思考が出来てないなｗ

俺は覚えることが重要だと言ったが、抽象化能力とその応用力が不要などとは一言も言ってない
また暗記とは言ってない。細かい違いだが、どんな機能があるか覚えていればいいだけ
暗記（何も見ないでかけるようにしろ）とまでは言ってない

覚えることが重要だと言ったが、お前は覚えることは重要ではないと言うわけか？
少ない語群だと、文章を適切に伝えられないぞ

数学で数式を使うのは、短い文章（数式）で正確に意味を伝えるためだ。
数式を覚えてないなら、長い文章を読み書きしなければいけなくなる

それをソフトウェアでは「冗長」という。
「冗長」はバグを増やしテスト時間を増やすことにつながる

jQueryはその「冗長」を減らしてくれる。
2018/11/09(金) 21:13:01.24ID:UVRb8J0Z
> ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、

HTMLベース VS CSSベースの話をしてるのは
お前だけだけどなｗ

意味がさっぱりわからんし。

適切な構造でHTMLを書いて、それに合うようにCSSでデザインするだけの話
最後にCSSでもできないことがあれば、JavaScriptを使う
アニメーションとか昔に比べてCSSでできることも多くなったしね。

それがウェブサイトの基本だよ。
基本なのでこれは変わることがない
2018/11/09(金) 21:15:44.51ID:UVRb8J0Z
> そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、

あ、コレ言うやつよくいるよなｗ
糖衣構文"でしかない" というやつ

俺は、糖衣構文という素晴らしいもの という立場だからな

なぜ他のやり方でもできることなのに、わざわざ糖衣構文があるのか？
それは、糖衣構文があれば簡潔に正確に意味と意図を表現できるから
数式と一緒
2018/11/09(金) 21:19:21.42ID:UVRb8J0Z
あとPHPのはないウザい。関係ない話だろ。
自分が嫌いなものは嫌いって言って全部一緒くたにしてる証拠
客観的に物事を見れてない
2018/11/09(金) 21:28:50.89ID:LcYc+UJI
あとjQueryのはないウザい。関係ない話だろ。
言語(Javascript)とその言語で書かれたライブラリ(jQuery)一緒くたにしてる証拠
客観的に物事を見れてない
2018/11/09(金) 22:20:39.53ID:UVRb8J0Z
jQueryはJavaScript用のライブラリなので関係あり
2018/11/09(金) 22:33:34.25ID:iK3se0MC
jQueryはJavaScript用のライブラリなので、jQueryの質問はjQueryの仕様による。JavaScriptの仕様から求まるものではない。
↓の専用スレに行け。なんで行かないの？
+ JavaScript & jQuery 質問用スレッド vol.8 +
https://mevius.5ch.net/test/read.cgi/hp/1510321470/
2018/11/09(金) 22:49:20.88ID:UVRb8J0Z
>>367

（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）
2018/11/09(金) 23:23:33.64ID:OgIaPmrY
>>362
> 適切な構造でHTMLを書いて、それに合うようにCSSでデザインするだけの話
> 最後にCSSでもできないことがあれば、JavaScriptを使う
これが違うんだよ。

君が言っているのはHTMLベースだ。(HTMLがマスタデータ)
それだと、どうしても開発効率が上がらないんだよ。
理由は簡単で、変更の多いHTMLおよびCSSが上流に来ているから。
HTML/CSSを変更するたびにJavaScriptまで変更/検証する必要があり、ループが大きいんだよ。

CSSベースってのは、CSSクラスをまず設計して(マスタはCSSクラス)、それに対してJavaScriptを書き、
そこに合うようにHTMLを書いて、最後に再びCSSで装飾を付けるんだよ。
まともなサイトはほぼ全てこれだから、見てみればいい。

君は旧式の開発方式しか知らないんだよ。だから俺が何を言っているか理解出来ないだけ。

ただ、旧方式が一概に悪いってわけではない。
アプリや毎日更新のサイトとかだとHTMLベースはかなり無理だが、
年に一度しか更新せず、ちょろっと動きを付けるだけ、ならいけるんだよ。
デタラメなHTMLでも何とでも出来るし、開発者のスキルが比較的不必要というメリットもある。
だからそういうところはHTMLベースにこだわり続けるだろう。今の君のように。
とはいえ、それは馬鹿にされるだろうなあ、ってだけの話で。（現時点でもそういう奴が散見されるだろ）

まあとにかく、君がjQueryを使い続けるのは君の自由だし、
jQueryが死ぬかどうかは待ってれば結果は出るんだし、それでいいだろ。
君の予想は「jQueryは永遠に不滅です」で、
俺の予想は「jQueryは次第に（10年かけて）衰退する」だね。
2018/11/10(土) 00:16:23.59ID:8OkJCHKT
> 君が言っているのはHTMLベースだ。(HTMLがマスタデータ)
> それだと、どうしても開発効率が上がらないんだよ。

？？？

え、なんで？

例えばHTMLに「こんにちは」って書く場合
HTML以外の何を使ったら、どう開発効率が上がるんだ？

もう少し、○○という理由で、開発効率が上がるって書いてくんない？
根拠が待った書いてないからさ
2018/11/10(土) 00:17:12.68ID:8OkJCHKT
> 理由は簡単で、変更の多いHTMLおよびCSSが上流に来ているから。
> HTML/CSSを変更するたびにJavaScriptまで変更/検証する必要があり、ループが大きいんだよ。

おまえ、下手なんじゃね？

JavaScriptはHTMLの変更に影響をつけないように作れよ

ほんと、下手
2018/11/10(土) 00:17:32.18ID:8OkJCHKT
訂正　影響をうけないように作れよ
2018/11/10(土) 00:21:25.82ID:8OkJCHKT
HTMLは文章は変わるが、HTMLの構造は一旦決めたら変わらないんだぜ

トップページ、一覧ページ、詳細ページ
これぐらいの区別があるだけ、ページごとにHTMLの
構造が変わっていたら、見づらいだろ

そしてJavaScriptは、特定のクラスに対して処理しますって書くだけ
ウェブデザイナさんに、こういうクラスつけておいてくださいね。
そのクラスつけておいたところは、こうなりますから〜って伝えるだけ

クラス設計？そんな大げさなものじゃない。
１つ（ないし数個）クラスを作って伝えるだけ
2018/11/10(土) 00:23:17.53ID:8OkJCHKT
> CSSベースってのは、CSSクラスをまず設計して(マスタはCSSクラス)、それに対してJavaScriptを書き、
> そこに合うようにHTMLを書いて、最後に再びCSSで装飾を付けるんだよ。
> まともなサイトはほぼ全てこれだから、見てみればいい。

つまりCSSクラスを最初に設計して、JavaScriptを書くから、
jQueryが適してるって話にしかなってないんだが？
2018/11/10(土) 00:28:38.34ID:8OkJCHKT
jQueryとCSSは非常に相性がいい。

.foo { color: red }
$('.foo').css({ color: 'red' })

書き方が違う程度で非常に近い書き方ができる。
セレクタに対して何かを適用するという考え、
セレクタベースだからだ

querySelectorAllだとこうは書けない。
単にセレクタで検索するだけだから、
その後ループして処理するという発想になる


CSSベースの開発ではjQueryを使うのが相性がいいし
そこがDOM APIでは越えられない壁。

あとどうも俺をHTMLベースとか言ってるようだが、
HTMLベースとCSSベースを分けて考えるなら、
俺はCSSベースだなｗ

繰り返すがCSSベースはjQueryと非常に相性がいい
2018/11/10(土) 00:30:27.85ID:8OkJCHKT
>>329を見ればわかるが

> 世界の大半を占めるウェブサイトは
> 「まず最初にHTML+CSSを書く」ということを
> しっかりと認識するようにな


最初に書くのは「HTML+CSS」だ
俺はHTMLを書いて、それに対してjQueryで処理しろとかいう話はしてない
何故か勝手に俺がHTMLベースだと決めつけられたｗ

jQueryはCSSベースになるし、CSSベースはjQueryと相性がいい
2018/11/10(土) 00:58:59.92ID:VOHXjVDU
まあ、君は、他のサイトをよく見て学べばいいと思うよ。多分それで解決する。
今のままなら、「jQueryおじさん」だな。
2018/11/10(土) 01:01:02.16ID:nSd/jMeD
バカかなこいつ。jsで書かれたライブラリなんだからjsでできることをまとめた関数以上でも以下でもない。
jQuery内部ではquerySelectorを使える環境ではquerySelectorを使うようになっている。
わざわざSizzleというセレクタライブラリを内包しているのになぜ？
それは遅いからｗｗｗｗｗ
2018/11/10(土) 01:12:03.37ID:liG2pvs9
自分が依存してるホスト言語様にケンカ売るとかｗｗｗ何様のつもりだよ替えのきくライブラリのクセにｗｗｗｗ
2018/11/10(土) 01:17:01.24ID:8OkJCHKT
>>378

> わざわざSizzleというセレクタライブラリを内包しているのになぜ？

1. 昔はブラウザにquerySelectorが搭載されていなかった
2. ブラウザ間で対応しているセレクタの違いに対応するため
3: :has擬似クラスのような今のブラウザ使えないが、標準化される見通しのセレクタに対応している
4. :inputセレクタのようなjQueryによって拡張された便利なセレクタが使える
5. セレクタの拡張機能を使って独自のセレクタを作成可能
6. 特定ブラウザのセレクタバグの回避

こんなところかな
2018/11/10(土) 01:17:36.71ID:8OkJCHKT
>>378
> jsでできることをまとめた関数以上でも以下でもない。

焦点は同じことをいかに楽にできるかどうかだよ
2018/11/10(土) 01:18:08.03ID:8OkJCHKT
>>377
> まあ、君は、他のサイトをよく見て学べばいいと思うよ。多分それで解決する。

どのサイトでもjQueryが使われてる
それを見てよく学んだｗ
383デフォルトの名無しさん
垢版 |
2018/11/10(土) 01:23:38.77ID:NL2nbxgf
JQueryはWeb業界のCOBOLとして残るやろ
どんなに新しくて思想が素晴らし技術でもも土方が使いこなして
コピペ量産できるレベルじゃないのと流行らず終わってしまう
2018/11/10(土) 01:35:42.00ID:8OkJCHKT
COBOLとの違いはDOMよりも優れているってことかな

jQueryはDOM APIと違ってCSSベースだからね
2018/11/10(土) 01:48:58.01ID:QAct5bTi
>>383
COBOLは神格化しすぎだろw
2018/11/10(土) 01:51:41.18ID:z7ZsqvtS
jqueryはEventEmitter的なやつが入ってるも便利なんだよなあ
2018/11/10(土) 03:31:41.00ID:1Rgn5iVr
ブラウザ非互換の対応をしようとすると結局ライブラリ作る羽目になるんじゃないの。
おれも極力素のJSで軽量に済ませるようにしてるけど、やっぱそういう下らない作業からは解放されたいな。
2018/11/10(土) 03:54:33.43ID:z7ZsqvtS
.ready()みたいなやつを自分で書くのが地味に面倒
2018/11/10(土) 07:01:00.07ID:3aLGJBed
自分とこはもう全部type=moduleでやってて
どうしても必要なとこではnomodule使うけど
基本的にIEとかではJS働かせてないな
もう確認もしてないし
あとはCanvasを積極的に使うのが互換性対処の肝かな
そうすればあってもちょっとした条件分岐くらいで
ライブラリ規模のをつくることはまず無くなる
2018/11/10(土) 07:28:09.30ID:8OkJCHKT
とまあ、ウェブサイトではまず使わないCanvasとか言ってる時点で
ウェブでは例外にあたるサイトの話なわけでｗ
どうせゲームだろうな
2018/11/10(土) 10:21:30.06ID:VOHXjVDU
>>383
COBOLは基幹システムに入っているから、更新間隔が標準で10年、実情は10-20年だからだよ。
Webの場合はもっと更新されるから、世代交代は早いよ。


>>384
だからお前はHTMLベースだし、大半のjQuery使用者もHTMLベースなんだよ。
HTMLに対して何かをする、という書き方でしかやってないだろ。
とにかくお前は他サイトを見て学べ。お前とは違うclassの使い方をしてるから。

そりゃjQueryを使っているサイトを見れば、当然お前と同じ程度の奴が同じ事をやってるだろう。
ただ、そんなの見ても意味無いだろ。
脱jQueryをやったサイトを確認して、(最近ならGitubか？）
何故彼等はそういう判断をしたのか、結果、どう変わったのか、
或いはそもそもjQuery使ってないサイトを見て、
お前にとって不可欠なjQueryをどうして彼等は使わないで出来るのか、それを見ないと。
その上で、自分がどうするかを判断する話であって。

お前はjQueryを使っている人がいる限りjQueryに引きこもるタイプだろうよ。(ラガード)
そういうのも一定数居るし、それが悪いことでもないが、
布教ってのは通常は新しい方向に対して行うべき物であって、
「旧来のままでいろ」ってのは普通はデフォだから必要ないんだよ。
布教に対するカウンターだってのは一理あるが、
現実として、でかいところも脱jQueryしてるんだから、脱jQuery派にも一定の妥当性はある。
そこは認めないと。


https://marketingis.jp/wiki/イノベーター理論
現実は、イノベーター共は最初からjQueryを使ってないから、
アーリーアダプターが脱jQueryを初めて、まだキャズムを越えてないから大騒ぎしてる、ってとこか？
2018/11/10(土) 10:30:19.15ID:omLk2QsU
ゲームだけでは無いよ
vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
まあそれがjQueryの代わりっちゃ代わりのようなもんか
イベントバブリングやアニメーションも対応してるし、
操作対象をDOMにしたり、混合させて利用する事もできる
普通じゃないって言うけど、HTML5以降Webって言うのは
アプリケーションプラットフォームになったという認識で作ってる
2018/11/10(土) 10:38:12.43ID:8OkJCHKT
>>391
> だからお前はHTMLベースだし、大半のjQuery使用者もHTMLベースなんだよ。

CSSベースだってｗ
jQueryがCSSと相性がいいのわかってるだろ？

それにDOM APIはHTMLベースってことになるのわかっていってるのか？
2018/11/10(土) 10:39:14.50ID:8OkJCHKT
>>391
> 脱jQueryをやったサイトを確認して、(最近ならGitubか？）
> 何故彼等はそういう判断をしたのか、結果、どう変わったのか、

どう変わったのか言ってみ？
俺、変わった所、全然わからない。
2018/11/10(土) 10:41:54.49ID:8OkJCHKT
>>392

> アプリケーションプラットフォームになったという認識で作ってる

アプリケーションプラットフォームとしても使えるようになったからって
俺もアプリ作るぞーってなると思う？ｗ

上の方でも言ったけど、ウェブがアプリケーションプラットフォームとなって
変わるのは、ウェブサイトじゃない。

デスクトップや家庭用ゲーム機やスマホアプリの世界から
人が去っていくことになるだけだよ。変わるのはそこ
2018/11/10(土) 10:44:33.37ID:8OkJCHKT
ウェブサイトは今のままウェブサイト
ウェブサイトがアプリになるわけがない

だからWebAssemblyとか、jQueryの代替じゃないんだよ。
jQueryをやめて使うものじゃない。

WebAssemblyとかは.NET FrameworkやDirectXや
OpenGLやUnityをやめて使うものなんだよ
2018/11/10(土) 11:24:42.68ID:VOHXjVDU
>>393
その意図的な誤用は止めろ。
「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。

HTMLベース：HTMLがマスタ
CSSベース：CSSクラスがマスタ

> それにDOM APIはHTMLベースってことになるのわかっていってるのか？
そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。

とにかくお前は他人がどういう作りにしているか、学んだ方がいいと思うぞ。


>>394
GitHubについてはスゲー変わったけどな。
分からないのなら、それでいいと思うよ。

ただ、変わった原因はjQueryでもないとも思うが。
GitHubは元々がポンコツすぎた。
2018/11/10(土) 11:25:42.07ID:1Rgn5iVr
いい加減誰が何主張してるのか追う気も無くなってきたけど、結局どうしろと言ってるの。
自分の書いたサイトのURL貼って説明してみてよ。
2018/11/10(土) 11:26:22.74ID:8OkJCHKT
> 「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。

そうじゃない理由をいうかと言えば、何も言えないｗｗｗ


> GitHubについてはスゲー変わったけどな。

変わった点を言うかと思えば何も言わないｗｗｗ


ホント説得力皆無やでｗ

> そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。
jQueryはセレクタを書くだけでクエリはやりませんねｗ
2018/11/10(土) 11:26:53.09ID:VOHXjVDU
>>392
> vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
これだよね。
フレームワークが流行らない一つの原因は、自前で用意しても出来てしまうこと。

> アプリケーションプラットフォームになったという認識で作ってる
プログラマはその認識で正しいと思うぜ。

ある意味、ドキュメントも、
・マークダウン等でHTMLを直接記述（少なくともHTML生成までは面倒を見る）…旧来手法
・テキストだけ書いて、ドキュメントアプリに流し込めばWebページ完成…アプリ的手法
があって、後者はブログなり静的HPフレームワークになるわけだが、
記事書きたい奴はhtmlを書きたいわけではないから、自然と後者によってくると俺は見ている。
とはいえ、そういう時代になっても、
とりあえず1回書けばいいだけなら、HTMLじか打ちの方が楽だし、旧来手法もある程度は残るだろうね。
2018/11/10(土) 11:30:27.31ID:8OkJCHKT
jQueryはCSSベースなのでCSSと相性がいい。

例えば、jQueryでCSSと同じように色を付ける場合、
CSSで書いたのと同じように "セレクタ" に "色を指定" する
まあCSSの範囲はCSSでやればいいんだが、

jQueryはデザインじゃなくて、イベントに関しても
CSSと似たような形で、 "セレクタ" に "イベントをバインド" する

CSSは要素がなくてもエラーにならないが、jQueryも同じように
要素がなくてもエラーにならない。CSSと非常によく似ている。
2018/11/10(土) 11:30:35.49ID:1Rgn5iVr
HTMLベースとかCSSベースってのもどういった概念を指してるのかわからないけど、セレクタで抽出したエレメントを操作するのがHTMLベースで、CSSクラスの定義を操作するのがCSSベースってこと？
2018/11/10(土) 11:32:04.04ID:8OkJCHKT
アプリケーション開発のプラットフォームは
jQueryの代替にはなりえない。

重要な点の一つだね。

みんながみんなアプリケーションを開発しているわけじゃない
ウェブの殆どはサイト

みんなが見てるのは、ウェブサイト
2018/11/10(土) 11:32:59.22ID:8OkJCHKT
>>402
jQueryはCSSでも使われるセレクタに対して処理を適用する

だから最初にCSSのクラス設計を行う必要がある。

だからCSSベースらしいｗ
2018/11/10(土) 11:43:58.85ID:VOHXjVDU
>>399
jQueryおじさんは、違いの分からない男であったか…
（もっとも、このスレにはこれが分かるおっさんの方が少数派の気もするが)

つか、あれで分からないのなら、感度がないんだよ。
こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。
2018/11/10(土) 11:45:15.02ID:8OkJCHKT
>>405
いや、お前がやるべきはぐちじゃなくて
俺が言っていることへの指摘だろう？

結局何も言えない。

githubもjQueryやめた効果を何も書いていないｗ
2018/11/10(土) 11:45:37.39ID:1Rgn5iVr
>>404
セレクタに対して処理をするんじゃなく、セレクタでセレクトされたエレメントを操作するんだよね。
んで >>397 で言ってるクエリ自体をやらないってことは、セレクタでエレメントを抽出せず操作するってことじゃないのかな。
とするとDOMは操作せずスタイルだけをいじるって趣旨なんじゃないのかな。
早い話、セレクタで操作対象のDOMエレメントを抽出した時点でHTMLベースだという主張ではないのかね。
2018/11/10(土) 11:46:24.46ID:8OkJCHKT
> こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。
なんの話？

jQueryは今も世界中で動いていますね
世界の7割を超えるサイトで使われてるので
普通にサイト見てるだけでjQueryが問題なく動くことが証明できてる
2018/11/10(土) 11:54:10.09ID:8OkJCHKT
>>407
> セレクタに対して処理をするんじゃなく、セレクタでセレクトされたエレメントを操作するんだよね。

いや、jQueryはそういう風に考えなくて良いんだよ。
考えないほうが正しいと思ったほうが良い

CSSは宣言的な言語
https://developer.mozilla.org/ja/docs/Glossary/CSS
> CSS (Cascading StyleSheets) は ブラウザー で Web ページの見た目を調整する宣言型の言語です。

宣言型とはどういうことかってのはまあ検索してもらえばいろいろわかると思うが
http://www.geocities.jp/mickindex/database/db_laws.html
> セルコが正しく言い当てたように、SQLの考え方を習得するときに最大の障壁となるのが、
> 私たちが慣れ親しんだ手続き型言語の考え方です。具体的に言えば、代入・分岐・ループを
> 基本的な処理単位として、システム全体をこの基本的な処理へ分割する発想です。
>
> 　SQL の考え方は、ある意味でその対極を行きます。SQL には代入やループなどの手続きは一切現れませんし、
>データもレコードではなく、もっと複合的な集合の単位で扱われます。

その特性の一つとしてループや分岐がない

CSSにはループや分岐はないだろう？
.foo { color: red }

それと同じでjQueryも宣言的なライブラリになってるんだよ
$('.foo').css({ color: 'red' })

内部的にループしているかどうかって言う話じゃなく（それを言い出したらSQLだってループしてる）
それを使って書くプログラマが、ループや分岐を書かなくてすむ

もちろんjQueryは生JavaScriptもかけるから、下手なやつがjQueryの中でループとかしてるやつがいるが
jQuery自体は宣言型で設計されてるんだよ。
2018/11/10(土) 12:14:11.57ID:VOHXjVDU
>>407
その解釈であってるが、詳細は以下。

>>402
ああ、それは俺がここで使っている用語だからな。
ただ、一般解釈できる呼称にしているつもりだ。
要は、マスタデータをどこに持つか、ということ。

HTMLベース：HTMLがマスタ
CSSベース：CSSクラスがマスタ（この呼称が良いかはさておき、他よりは誤解がないはず）

jQueryの典型的コードは、「クエリして、その結果のDOMに○○」というものだ。
ここで毎回クエリが必要なのは、HTMLがマスタデータだからだ。
そしてそのクエリが遅いから、動作がもっさりする。

一方、マスタデータがHTMLではない場合、クエリは当然必要ない。
アプリでは内部データがマスタであり、そこから一方的にHTMLを吐き出す。
PHP鯖も、DBからマスタデータを取り寄せ、一方的にHTMLを生成するだけで、DOMクエリなんてやらない。
「DOMクエリが必要なのは、DOMがマスタデータだから」だ。
で、彼はこの抽象化能力がないから、ここが通じずに話が空回りしてる。

DOMクエリが遅いのだから、高速化にはこれを『必要ない』構造にするのが一番いい。
そして、大半のマトモなサイトはそれを既にやっていて、「いちいち何かをする前にDOMクエリ」はしない。
結果、クエリ自体しないのだから、jQueryの利点もない、というだけの話。
彼は知らないから話が通じないだけ。

ただ、これを「CSSベース」というのが分かりやすいかは微妙で、そこが君の疑問点なのは妥当だが、
では、この場合何が「マスタデータ」に当たるかといわれれば、JavaScriptでもないしHTMLではないし、
敢えていうならCSSクラスかな、というところ。

なお、HTMLベースには「マスタデータが直接見える為、ものすごくデバッグし易い」という大きな利点があって、
つまりはこれが蔓延る原因となっている。
2018/11/10(土) 12:15:14.62ID:omLk2QsU
>>395
ちょっと考え方が違うんじゃない?
WebやHTMLは文書のための規格として始まったけど、
今ではそうじゃないじゃん?
Web3.0っていう言葉もあるけど、
まだ「インタラクティブな文書表示」とも言えたWeb2.0の段階を
だんだん超えてきてるとは思わない？

別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、
いつの間にか作ってるものが「文書」を越えたアプリケーションになっていくって言うのが
ある意味自然な流れだと思うよ

Webサイトって言うのがもう「文書を提供する為の場所」だけではどんどんなくなってると思うけどな
別にゲーム的なものに限らなくてもね
2018/11/10(土) 12:18:08.67ID:1Rgn5iVr
>>409
集合に対する処理系なのか自前でループするとかそんな話じゃなく、そのコードで言えば $('.foo') でセレクトされたエレメント（達）に対して .css({ color: 'red' }) という操作をしてるんでしょ？
それを HTMLベースと言っていて、foo のスタイルそのものを変更するアプローチが CSSベースと言ってるんじゃないのか、という確認だよ。
2018/11/10(土) 12:24:49.10ID:8OkJCHKT
>>411
> WebやHTMLは文書のための規格として始まったけど、
> 今ではそうじゃないじゃん?

なんで技術主導で考えてるんだよｗ
一番最初に来るのは「要求」何をしたいかだ。
いくら何かができるようになったとしても、
それを使ってなにかしたいという「要求」がなければ使わない

新しいことができるようになったからって
誰もが新しいことするわけじゃないんだよ。

スマホができたからって、誰もがスマホアプリ作ったりしないだろうが？

ウェブをアプリプラットフォームとして使いたいと思ってるのは
今アプリを作っている所で、ウェブサイトの世界からすればよそ者
2018/11/10(土) 12:26:14.66ID:8OkJCHKT
> 別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
> 表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、

起きてない。mozillaのウェブサイトだって、殆どが静的コンテンツ
ページ開くたびに音楽流すとか、アニメーション流すとか
3Dでキャラクターがグリグリとか、やらないからさｗ
2018/11/10(土) 12:28:12.32ID:VOHXjVDU
>>412
言う必要なさそうだが、その解釈であってる。

HTMLがマスタデータだから、更新時にはHTMLを更新しなければならない。
CSSクラスがマスタなら、更新時にはCSSクラスを更新(add/removeまたはスタイルリスト操作）することになる。

まあこの「CSSベース」が分かりやすい呼称かはさておき、
マスタデータが○○なら、○○ベース、と呼んでる。（今ここでは）
2018/11/10(土) 12:28:25.73ID:8OkJCHKT
>>412
> そのコードで言えば $('.foo') でセレクトされたエレメント（達）に対して .css({ color: 'red' }) という操作をしてるんでしょ？

だからjQueryはそういう発想で使うものじゃないってこと
間違った発想で使ってるやつが非常に多いのは事実だがね
だからjQueryはHTMLベースとか言い出すアホがでてくる

内部はそうなっていても、jQueryは宣言型として考えることができるようになってる。
ループも条件分岐も書かなくて良いようになってる
だから同じ宣言型のCSSと非常に相性が良い
2018/11/10(土) 12:31:22.88ID:8OkJCHKT
jQueryはCSSベースなので、具体的なHTMLタグのことは考慮しない。
できるかどうかは置いといて、jQueryはクラスベースでプログラミングする

特定の名前のクラスの要素（それがHTMLのどのタグかは意識しない）を
どのようにするかという宣言で書いていく

CSSのクラスベースなのでHTMLがどのように変わっても問題ない。
jQueryではCSSを直接変えるのは基本的にしないでCSSクラスの更新を行う
jQueryでやるのはCSSクラスの更新＝状態の変化だけだ
2018/11/10(土) 12:35:11.86ID:1Rgn5iVr
>>410
CSSベースのアプローチの真髄が分からんのだけど、HTML の構造に縛られなくなっても CSS の構造に縛られるようになるんじゃないの？
改修する時にはどのみちどちらかには手が入るからJS側の調整も無くなるわけじゃないだろうし、やりたいことの全部が CSS だけでできるわけでもないだろうし。
まあエレメント抽出なんてする必要が無いと言ってるわけじゃなく、基本をどっちに置くか程度の話だと思うけど。
まあおれも何するにも $('.foo') で始めるのはどうかと思うよ。コスト的に。
でも操作対象は明確だから、書き方としては悪くないと思う。
2018/11/10(土) 12:40:02.46ID:1Rgn5iVr
>>416
なんか書き方で言ってるのか動きで言ってるのかの違いっぽいのかな。
おれは書き方は結構スマートだと思うが動きを考えると使う所を選びたいといった感覚だけど。
2018/11/10(土) 12:40:21.64ID:8OkJCHKT
もう少し具体的に書くと、例えばA要素に対してhoverしたときに色を変えたい
というのをCSSで書くと

a:hover { color: red } となる

ループ的なものはなく、このように宣言するだけで、
全てのa要素に対してこの処理が適用される

これをjQueryでシミュレートするならば、まず
a.hover { color: red } とクラスに変えておいてjQueryでは以下のようにする

$('a').hover(function(event) {
　$(this).toggleClass('hover', event.type == 'mouseenter')
});

ループ的なものはなく、このように宣言するだけで、
全てのa要素に対してこの処理が適用される

条件分岐も不要で、クラスを変えることでデザインを適用する
2018/11/10(土) 12:43:20.01ID:VOHXjVDU
>>406
>>408
お前はまず全部読んでから、整理して回答する癖を付けろ

> なんの話？
GitHubの話に決まってるだろ


>>409
なるほど君は典型的なjQuery廚か。まあ、この点は分かりやすくていいね。

そうだ。それがjQueryの典型的な書き方で、結果、ものすごくもっさりするのも事実だ。
そしてjQuery厨は君のようにそれを「大正義」だと思っているらしく、
どんなにもっさりしていてもその書き方を止めない。
「宣言型」だからこの書き方の方が素晴らしい！と本気で勘違いしてる。

ただ、プログラミングってのは手段であって、目的ではない。
ユーザーは、そのサイトが快適かどうかは気にするが、中身のソースコードなんて気にしない。

宣言型の方がソースコードの管理は楽だし、HTMLベースの方がデバッグしやすいのも事実だが、
ユーザーエクスペリエンスを損ねるようでは意味がない。
ただ、CSSベースでも宣言型ではあるし、実際そんなに難しくもならないから、まともなところは既に移行済みだ。
そしてjQuery廚だけが取り残されつつある、というのが今だね。
2018/11/10(土) 12:45:37.73ID:8OkJCHKT
そういや、仮想DOMは最終的に遅いっていう話があったな
仮想lDOMはDOM全部入れ替えよりも速いというだけで
そもそもDOM全部入れ替えなんてしねーよという話
2018/11/10(土) 12:46:04.24ID:8OkJCHKT
>>421
> そうだ。それがjQueryの典型的な書き方で、結果、ものすごくもっさりするのも事実だ。

もっさいりしているという証拠は？

結局いつも出せないんだよねｗ
2018/11/10(土) 12:46:39.27ID:8OkJCHKT
> ユーザーエクスペリエンスを損ねるようでは意味がない。

はい、宣言型のjQuery使って
ユーザーエクスペリエンスを損ないません。
2018/11/10(土) 13:27:52.51ID:VOHXjVDU
>>418
指摘はその通り。一応いちいち確認しておくと、以下。

> HTML の構造に縛られなくなっても CSS の構造に縛られるようになるんじゃないの？
なる。
ただし、HTMLよりはCSSクラスの方がだいぶまし、という話。
MVCの利点は、「変更されやすいVを、変更されないMと変更に大きなコストがかかるCから分離した」事だ。
この場合、MはCSSクラス、CはJavaScript、VはHTMLとCSSデザインだ。
だから、JavaScript自体がCSSクラスに「だけ」依存するようにしておけば、
HTMLとCSSデザインの変更の影響は受けずに済む、という話。

何にも依存しないというのは無理だから、「変更され難いもの」に依存するようにしていくのが常道。
HTMLよりもCSSのクラス構成の方が本質的だから、変更されにくい。
単品のサイトだと分かりにくいから、複数サイトを同一JavaScriptでカバーすることを想定してみればいい。

> 基本をどっちに置くか程度の話だと思うけど。
そうとも言えるが、現実的にはコード構成ががらりと変わる。

各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
だから個別データはノードから動的に取得する必要があり、
単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。

結果、イベント起動部分のコードは全書き換えに近くなる。

> まあおれも何するにも $('.foo') で始めるのはどうかと思うよ。コスト的に。
> でも操作対象は明確だから、書き方としては悪くないと思う。
分かりやすいのは事実なんだよ。
その結果、もっさりするのもまた事実な訳でさ。
そしてCSSベースにしても、特段分かりにくくなるわけでもないのも事実で、
実際に軽くなるんだからまともな奴はみんなそうしてる、ってだけでさ。
2018/11/10(土) 13:29:27.38ID:1Rgn5iVr
id="css1" の style の一件目が .foo { color: red; } だったとして、

$('.foo').css({ color: 'blue' }) とやったら HTMLベースと言ってるのは合ってると思うが、

document.getElementById('css1').sheet.cssRules[0].style['color'] = 'blue'; とやったら CSSベースで合ってる？

つかそれはそれとしてルールへのスマートなアクセスのやり方教えて。
2018/11/10(土) 13:48:22.57ID:VOHXjVDU
>>426
> document.getElementById('css1').sheet.cssRules[0].style['color'] = 'blue'; とやったら CSSベースで合ってる？
いや、そこは普通にクラスを足す。具体的には、

e.target.classList.add('highlight') とか。
.foo.highlight {color:blue;} は当然最初から書いておく。

つかここら辺は普通のサイトはこうしてるから、見ればいいと思うよ。
絶対にHTMLをいじらない、というわけではない。ましな方を適宜選択するだけ。

スタイルルールをいちいち書き換えるコードは、あまり使っている奴は居ないと思うぞ。
それよりは、スタイルリストごと全部入れ替えてると思う。
2018/11/10(土) 13:59:17.38ID:1Rgn5iVr
>>427
となるとエレメントに対してクラスを追加するという操作をしてるんだから、HTMLベースと言ってるところと一緒に思えるが、
またCSSベースが指す概念がよくわからなくなってきたよ。
CSSの定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。
2018/11/10(土) 14:36:49.62ID:VOHXjVDU
>>428
そこは説明用の言葉を考えただけだから、過度に拘る必要はないが、
CSSがマスタなのは変わらないし、DOMクエリが必要ないのも変わらないだろ。

CSSは最初から .foo.highlight を持っていて、HTMLが変化しただけ。

俺がCSS「クラス」と言っているのが不味かったか？
CSSでは文法上分離してないが、あれは「構造クラス」と「デザインクラス」と分けて考えるべきで、
.foo は「構造クラス」で不変、.highlightは「デザインクラス」で適宜追加/削除するもの。
「構造クラス」はJavaScriptの「クラス」と同じで、またOOPの「クラス」とも同じ。変わることはない。
そして最初に設計されるべき物。
「デザインクラス」はただの追加アトリビュートだ。見た目を変える為に動的に追加/削除/変更される。

上記の通り、CSSクラスの使い方はOOPと同じだから、OOPを理解している奴は普通に適切に使える。
ところがJavaScripterにはOOPを理解してない奴も多いから、
（というよりはその上流のデザイナのせいか？
もっとも、上流にデザイナが居る時点で間違いだというのが俺の見解だが）
CSSもグチャグチャになってたりする。
CSSも本来は、

.構造クラス {}
.構造クラス.デザインクラス {}

の2種類だけで構成されるべきなんだよ。（基本的には）

> CSSの定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。
ああ、これは違う。これをやるには大量にクラスを定義しまくる必要があるだろ。
実際、何個くらいまで実用に耐えられるのかは興味はあるにしても、
他にそんなコードを見たことがないので、採用はしないね。
2018/11/10(土) 14:44:43.10ID:VOHXjVDU
>>428
というか、俺はオレオレ流の先進性がある(ｷﾘｯな方法を宣伝しているのではなく、
割とみんなやってる方法を言ってるだけだから、新しい手法か？という期待をされても無理だ。
そんなもん知ってるわ！でしか無いと思う。
2018/11/10(土) 19:55:52.70ID:3aLGJBed
DOMを縦横無尽に弄ろうとするから複雑になる
機能が小さく閉じたコンポーネントを組み合わせて設計すればいいだけ
直接CSSを弄ろうなど、愚の骨頂
2018/11/10(土) 20:28:54.94ID:8OkJCHKT
>>431
それな。jQueryの使い方として、まずトップのクラスを一つ作る
正確には最初にCSSの設計を行って、CSSの構造でコンポーネントを定義する
この時sassを使うとネストができるのでHTMLの構造をCSSで定義しやすい
そしてjQueryはそのコンポーネントに対して処理を記述する

CSSで構造を作って、その構造通りにHTMLを書く
そしてCSSでは不可能なことが出てくればJavaScript（jQuery）の出番ってわけ
jQueryはCSSと相性がいい
2018/11/10(土) 20:33:34.38ID:8OkJCHKT
>>425
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。

jQueryはこのイベントを親で受けるっていうのがすごく書きやすい

$('.foo').on('click', ・・・) とあったら
$(document).on('click', '.foo', ・・・) と書き換えるだけ
documentでなくても、.fooの親である任意の要素でよい

ここでも「分離して動作」という処理がなくなって宣言的になる
bodyにonしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
それどころか、e.target.classList.contains を使って分離して動作させることもいらない

それでいて、共通イベントハンドラとか使わなくていいし、クロージャでそのノード個別のデータを渡すこともできる。

DOM APIを使ったときに発生する問題が全て解決されるってわけ

どや？ｗ
2018/11/10(土) 20:36:59.04ID:8OkJCHKT
DOM APIの問題をあげたようだが、
それがjQueryによって解決されてるのを見ると、
やっぱりjQuery使ったほうが良いなってなるよなｗ
2018/11/10(土) 20:42:53.84ID:3aLGJBed
>>432
それはjQueryの使い方でも使われ方でもないな
jQueryに限らないけど君みたいな大好きマンが語ることって、
もちろんそれは君の好きにしたら良いし否定はしないけど、やっぱり例外的なんだよ
コンポーネントで組むならそれ専用のライブラリを使うほうが絶対にいいし
一部に使うにしろShadowDOM然り相性が良いとは消して言えない

気軽で便利さが取り柄のjQueryのようなライブラリで、
考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
jQueryは正に比較的小規模なサイトでパッチを当てるような勢いで
縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ
2018/11/10(土) 20:47:26.06ID:8OkJCHKT
> 気軽で便利さが取り柄のjQueryのようなライブラリで、
> 考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ

はっはっは。
つまりお前は、jQueryは気軽に使うもんだ。気軽に使うから問題出るやろ
って言ってるわけか。
全てお前の使い方が悪いんじゃないか



見ての通り、お前が上げたDOM APIの問題がすべてjQueryで解決していることを示した。

>>425で（DOM APIの場合は）

> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、
〜略〜
> 結果、イベント起動部分のコードは全書き換えに近くなる。

といっているが、jQueryならたったこれだけだ。

> $('.foo').on('click', ・・・) とあったら
> $(document).on('click', '.foo', ・・・) と書き換えるだけ

イベントハンドラのコードは全く変更がいらない
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況