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です)
探検
+ JavaScript の質問用スレッド vol.126 +
レス数が1000を超えています。これ以上書き込みはできません。
2018/06/02(土) 14:31:23.04ID:B1JKBGEy
2018/06/02(土) 19:57:34.11ID:XIvhMjpN
(10) ライブラリ関連の質問は禁止です。関連スレにあるライブラリ質問スレで質問して下さい。
3デフォルトの名無しさん
2018/07/04(水) 22:36:56.65ID:gFgZc5FG BSC
4デフォルトの名無しさん
2018/08/14(火) 21:41:12.61ID:MYKilrFy 超ド素人です。スレ汚しをお詫びします。
D3.jsを使ってグラフを描画するhtmlがあり、そのグラフのデータが.tsvで読み込まれるようになっている場合、どこに.tsvファイルを置けば良いのでしょうか?
というか、そもそもtsvもhtml?javascript?コードに含めるのでしょうか?
さっぱり見当違いなことを言っていたらすみません。
よろしくお願いします。
D3.jsを使ってグラフを描画するhtmlがあり、そのグラフのデータが.tsvで読み込まれるようになっている場合、どこに.tsvファイルを置けば良いのでしょうか?
というか、そもそもtsvもhtml?javascript?コードに含めるのでしょうか?
さっぱり見当違いなことを言っていたらすみません。
よろしくお願いします。
2018/08/14(火) 22:54:21.84ID:xdeQCNo5
同一ドメイン内なら何処に置いたっていいと思うけど
2018/08/14(火) 23:30:00.67ID:6NKcX7Ow
「d3.js tsv」で検索!
HTML ファイル
<script src="js/sample.js"></script>
sample.js ファイル
d3.tsv("data/data.tsv", function(error, data){
data/data.tsv は、sample.jsからの相対パスか?
または、HTMLファイルからの相対パスか?
または、プロジェクトルートからの相対パスか?
または、カレントディレクトリからの相対パスか?
HTML ファイル
<script src="js/sample.js"></script>
sample.js ファイル
d3.tsv("data/data.tsv", function(error, data){
data/data.tsv は、sample.jsからの相対パスか?
または、HTMLファイルからの相対パスか?
または、プロジェクトルートからの相対パスか?
または、カレントディレクトリからの相対パスか?
2018/08/14(火) 23:34:16.41ID:TcckKRoR
>>4
ggrks
ggrks
8デフォルトの名無しさん
2018/08/18(土) 10:48:15.65ID:k5A8heiz <input type='submit' value='送信'>
をクリックしたとき送信する前に、何かしてから
送信するにはどうしたらよいですか?
をクリックしたとき送信する前に、何かしてから
送信するにはどうしたらよいですか?
2018/08/18(土) 11:01:57.73ID:5gN61dbI
なにかするってお願いでもするの?
ちゃんと合格できますようにって
何をするかによって、何処にお参りに行けばいいか変わる
ちゃんと合格できますようにって
何をするかによって、何処にお参りに行けばいいか変わる
2018/08/19(日) 18:51:53.60ID:69xH6R/y
onclickとかonsubmitで検索する
2018/08/22(水) 01:19:58.39ID:5vGBawXp
==と===はどうちがうんですか?
2018/08/22(水) 01:35:30.51ID:gDXxyo9q
== はなるべく型を合わせようとしてから比較する
=== はそのまま比較する
詳しくは MDN の演算子のページとか
あとは「JavaScript 暗黙の型変換」でググれ
=== はそのまま比較する
詳しくは MDN の演算子のページとか
あとは「JavaScript 暗黙の型変換」でググれ
2018/08/22(水) 06:56:11.02ID:5vGBawXp
2018/08/23(木) 06:31:49.50ID:jSKCCuPN
実行と評価の違いがわからないです
2018/08/26(日) 13:45:10.99ID:iVRDt0pz
>>14
何が分からないのか分からない
何が分からないのか分からない
16デフォルトの名無しさん
2018/09/03(月) 21:37:00.45ID:j2ZKOITT 直接javascriptの事ではないと思いますが、すみませんこちらで…
Googlechrome右クリックメニューをjavascirptを勉強して簡単なものを作成してみました。
右クリックメニューはショートカットキーを割り当てることもできると思うのですが、
右クリック、ショートカットキーを押す、という流れでなく、
chromeを開いた状態で
最初から「Ctrl+何か」 などで 右クリック→ショートカットキー
となるプログラムは、どの言語あたりなら作成できそうでしょうか・・
ショートカットキーを押すだけで右クリック開く→選択
というものを省くのが狙いですがすみません。
なんとか開発したくすみません・・
Googlechrome右クリックメニューをjavascirptを勉強して簡単なものを作成してみました。
右クリックメニューはショートカットキーを割り当てることもできると思うのですが、
右クリック、ショートカットキーを押す、という流れでなく、
chromeを開いた状態で
最初から「Ctrl+何か」 などで 右クリック→ショートカットキー
となるプログラムは、どの言語あたりなら作成できそうでしょうか・・
ショートカットキーを押すだけで右クリック開く→選択
というものを省くのが狙いですがすみません。
なんとか開発したくすみません・・
17デフォルトの名無しさん
2018/09/03(月) 22:14:12.93ID:E2St7m4+2018/09/03(月) 22:30:52.82ID:A0klmjXn
19デフォルトの名無しさん
2018/09/04(火) 13:48:37.40ID:R4rr/j552018/09/04(火) 15:07:15.64ID:JkSql3w1
>>14
ショートサーキット(短絡)評価とかだろ。
AND, OR, ||, && など
例えば、A AND Bという論理式があった場合、
Aがfalseなら、その時点で式全体の結果は、falseで確定するため、
Bがどうであるかについてはチェックしない
この場合、式B が評価(実行)されないから、
B に関数呼び出しとか、変数を更新するなど副作用があると、
if, else 文で書くよりも、可読性が低い
「javascript 短絡評価」で検索!
ショートサーキット(短絡)評価とかだろ。
AND, OR, ||, && など
例えば、A AND Bという論理式があった場合、
Aがfalseなら、その時点で式全体の結果は、falseで確定するため、
Bがどうであるかについてはチェックしない
この場合、式B が評価(実行)されないから、
B に関数呼び出しとか、変数を更新するなど副作用があると、
if, else 文で書くよりも、可読性が低い
「javascript 短絡評価」で検索!
2018/09/04(火) 15:12:28.45ID:ROt4XEkp
2018/09/05(水) 18:49:07.37ID:Vic/5rK1
ファイルリーダーについての質問です。ここのソースを使ってます
https://www.sejuku.net/blog/32532
ファイルを読み込んだ後
var a=reader.result;
var b=a.split(',');
とやるとb[]の変数がsubstringなどが使えなくなります
aの段階では文字列として認識されてますがbになると変になります
readerを使わずに文字列でsplitすると普通にsubstringが使えます
いろいろ試しましたが原因がわかりません
https://www.sejuku.net/blog/32532
ファイルを読み込んだ後
var a=reader.result;
var b=a.split(',');
とやるとb[]の変数がsubstringなどが使えなくなります
aの段階では文字列として認識されてますがbになると変になります
readerを使わずに文字列でsplitすると普通にsubstringが使えます
いろいろ試しましたが原因がわかりません
2018/09/05(水) 18:59:25.53ID:WaT1iqeJ
そんなもん読むよりちゃんとしたドキュメントを調べる癖をつけろ
https://developer.mozilla.org/ja/docs/Web/API/FileReader
https://developer.mozilla.org/ja/docs/Web/API/FileReader
2018/09/05(水) 19:34:21.13ID:Vic/5rK1
読んだけどわかりません
終了後の result プロパティには、ファイルの内容をテキストとして読み取った文字列が格納されます。
と書いてます
終了後の result プロパティには、ファイルの内容をテキストとして読み取った文字列が格納されます。
と書いてます
2018/09/05(水) 19:40:54.77ID:sP+OmdD3
b[]ではなくbを参照してるってオチだろうなぁ
2018/09/05(水) 20:06:14.26ID:Mk6ELM5E
なんでこういう連中は再現する最小コード書かないかなぁ
そういう発想がないからバグの原因特定が出来ないんやで
そういう発想がないからバグの原因特定が出来ないんやで
2018/09/05(水) 20:09:20.81ID:Vic/5rK1
さすがにそんな凡ミスではないです
2018/09/05(水) 20:23:53.45ID:PklssQfn
どう見ても凡ミス
2018/09/05(水) 20:40:06.05ID:Vic/5rK1
どうやらVisual studio Codeの仕様のせいだったみたいです
変換候補に出ないのでどこかに文法の間違いがあると思ってました
コード自体にエラーはなかったようです
変換候補に出ないのでどこかに文法の間違いがあると思ってました
コード自体にエラーはなかったようです
2018/09/05(水) 20:47:44.87ID:PklssQfn
仮にそうだとしても人はそれを凡ミスと呼ぶ
どうでもいいことで1時間潰したんだし
どうでもいいことで1時間潰したんだし
2018/09/05(水) 20:50:57.82ID:Mk6ELM5E
仕様のせいにする割に結局コード書かないしお察し
2018/09/05(水) 21:43:32.66ID:ymqGMHGu
2018/09/05(水) 21:43:56.97ID:PklssQfn
そのレベルでインテリセンスが機能しないのなら既に遭遇して知っているはずだし、
今回初めて遭遇したのなら何らかの問題がコード側にあるだろ。
動的型だから何に対して substring を使っても文法エラーにはならない。
これで通ったと勘違いしているだけだね。多分。
今回初めて遭遇したのなら何らかの問題がコード側にあるだろ。
動的型だから何に対して substring を使っても文法エラーにはならない。
これで通ったと勘違いしているだけだね。多分。
2018/09/05(水) 23:25:19.78ID:Vic/5rK1
VSCの仕様です
var a=reader.result.tostring();
にすればできるようになったのでそれで原因解決かとおもったけど
他の関係ない箇所でもsubstringの予測がでてこないのでおかしいと思って
調べると var が原因らしいとわかった
var a=reader.result;
var b=a.split(',');
という書き方ではVSCではbの型が確定しないので予測候補にでてこない
最初にvar a="";と入れてやると候補にでてくるようになる
ただし候補でないからといってエラーになるわけではない
var a=reader.result.tostring();
にすればできるようになったのでそれで原因解決かとおもったけど
他の関係ない箇所でもsubstringの予測がでてこないのでおかしいと思って
調べると var が原因らしいとわかった
var a=reader.result;
var b=a.split(',');
という書き方ではVSCではbの型が確定しないので予測候補にでてこない
最初にvar a="";と入れてやると候補にでてくるようになる
ただし候補でないからといってエラーになるわけではない
2018/09/05(水) 23:37:04.75ID:Mk6ELM5E
VSCの仕様でもなんでもないやん>>23のドキュメントにFileReader.resultの型はstring|ArrayBufferだって書いてあるのを読めなかっただけやんけ無能
2018/09/05(水) 23:48:59.21ID:PklssQfn
「俺ではなく他の問題だ」と主張するのは初心者の典型的パターンだな。
そして100%「お前の問題だ」となるお約束展開。
昔はこのタイプは居なかったと思うのだが、何でこうなるかな?
そして100%「お前の問題だ」となるお約束展開。
昔はこのタイプは居なかったと思うのだが、何でこうなるかな?
2018/09/05(水) 23:50:57.88ID:Vic/5rK1
2018/09/06(木) 00:01:10.33ID:K6tuSvr0
結果は文字列かも知れないしそうじゃないかも知れない
これじゃあ予測候補出せるわけ無いよね
以上
これじゃあ予測候補出せるわけ無いよね
以上
2018/09/06(木) 00:03:23.05ID:/8o/0CpY
2018/09/06(木) 00:13:01.18ID:ZRGsnqPQ
でも結局誰も答えられなかったわけですし
2018/09/06(木) 00:14:03.30ID:/8o/0CpY
答える気があった奴の方が少ないと思うがな
2018/09/06(木) 00:23:33.63ID:ZRGsnqPQ
原因がわかった後に答えを言うのは誰でもできますよ
2018/09/06(木) 02:27:07.08ID:YF3YUgQO
2018/09/06(木) 07:30:40.95ID:ZRGsnqPQ
そういうことは自分が守ってから言いましょう
2018/09/06(木) 08:47:30.70ID:4ASt4deq
ってかaにカーソル当てたら型が出るだろ。VSCでは。
2018/09/06(木) 12:18:22.14ID:jnrXdp3N
2018/09/06(木) 17:01:47.10ID:ZRGsnqPQ
じゃ質問はもうとっくに終わってるので関係ないですね
それに必要な情報は書いていたはずです
最初から型の問題だと限定して問題なのはたった2行ですし
リファレンス読めばわかるというなら誰でもresultの仕様みれば答えられるはずですよね
それなのに後出しでイキってくる人ばかり
それに必要な情報は書いていたはずです
最初から型の問題だと限定して問題なのはたった2行ですし
リファレンス読めばわかるというなら誰でもresultの仕様みれば答えられるはずですよね
それなのに後出しでイキってくる人ばかり
2018/09/06(木) 18:27:44.87ID:YF3YUgQO
日本語も英語も読めないんだろうなぁ
2018/09/06(木) 18:48:29.66ID:ZRGsnqPQ
煽るのはちゃんと回答してからにしてくださいね 無能
2018/09/06(木) 18:57:38.11ID:4aYwdhCB
>>47
問題なのはその二行じゃない。
その二行に気づかないお前と、その二行で正しいと思ってる今の理解力と、
それでもなおまだ自分に非がないと思ってるお前の人格だ。
/** @type String[] */なり、/** @type string*/で解決するだろ。無理に型変換したり初期値入れたりしなくても。
無理に推論させるためにソース自体に無駄なコードを書くな。
インテリセンスは万能じゃないし、インテリセンスが出ないから使えないと思うのも頭おかしい。
実際にエラーになってから言え。
原因はみんなある程度わかってて、その原因についてお前が切り分けられるかを問題にしてて、案の定お前は切り分けできなかった。
それでお前は、回答者が答えを教えない事を批判してるようだが、そのへんがそもそも噛み合ってない。
誰も答えがわからなかったんじゃない。
皆のヒントでお前が答えがわからなかったんだ。
問題なのはその二行じゃない。
その二行に気づかないお前と、その二行で正しいと思ってる今の理解力と、
それでもなおまだ自分に非がないと思ってるお前の人格だ。
/** @type String[] */なり、/** @type string*/で解決するだろ。無理に型変換したり初期値入れたりしなくても。
無理に推論させるためにソース自体に無駄なコードを書くな。
インテリセンスは万能じゃないし、インテリセンスが出ないから使えないと思うのも頭おかしい。
実際にエラーになってから言え。
原因はみんなある程度わかってて、その原因についてお前が切り分けられるかを問題にしてて、案の定お前は切り分けできなかった。
それでお前は、回答者が答えを教えない事を批判してるようだが、そのへんがそもそも噛み合ってない。
誰も答えがわからなかったんじゃない。
皆のヒントでお前が答えがわからなかったんだ。
2018/09/06(木) 18:59:30.79ID:4aYwdhCB
そもそも余計な代入して、それで解決したと思うほうが頭おかしいだろ。
何が起こってるかぐらい把握しろよ。
何が起こってるかぐらい把握しろよ。
2018/09/06(木) 19:08:26.97ID:ZRGsnqPQ
人格云々っていつからここは人生相談板になったんですか?
2018/09/06(木) 19:12:11.44ID:ZRGsnqPQ
人が事細かく詳細説明した後ならなんとでもいえますよね
あきらかにわかってる人いなかったっぽいし
あきらかにわかってる人いなかったっぽいし
2018/09/06(木) 19:17:29.62ID:4aYwdhCB
2018/09/06(木) 19:18:20.61ID:Wz0pb6Ha
2018/09/06(木) 19:18:34.10ID:4aYwdhCB
お前以外はとっくに気づいててそれ以上言わなかっただけ。
お前はその上間違った解法が正しいと思ってる。
致命的。
お前はその上間違った解法が正しいと思ってる。
致命的。
2018/09/06(木) 19:18:55.12ID:4aYwdhCB
>>55
仕様読んだらわかるべ。
仕様読んだらわかるべ。
2018/09/06(木) 19:19:22.89ID:ZRGsnqPQ
これが答えわかってる人のレスですか?>>31>>33
2018/09/06(木) 19:19:50.97ID:4aYwdhCB
インテリセンスに出ないから間違ってるに違いない、と言う思い込みも異常だけど、インテリセンスに頼るならインテリセンスに対してちゃんと情報を提示するのは当然だし、
それは無駄な代入で行われるべきではない。
それは無駄な代入で行われるべきではない。
2018/09/06(木) 19:20:06.05ID:4aYwdhCB
>>58
33は嫌味だろ。わかってての。
33は嫌味だろ。わかってての。
2018/09/06(木) 19:23:21.13ID:ZRGsnqPQ
2018/09/06(木) 19:32:42.30ID:ZRGsnqPQ
2018/09/06(木) 19:35:43.48ID:YF3YUgQO
まぁ可愛い無能だけどもう来るなよ
2018/09/06(木) 19:37:10.17ID:4aYwdhCB
2018/09/06(木) 19:38:15.88ID:4aYwdhCB
2018/09/06(木) 19:39:24.89ID:4aYwdhCB
人には偉そうに言ってたみたいだけど、いきがるのもいい加減にして無知を認めろ。
それが質問者だ。
それが質問者だ。
2018/09/06(木) 19:41:54.28ID:ZRGsnqPQ
無知でなければ質問スレにはきませんよ
エスパーしないと無理といってるし他の人はわかってなかったですね
エスパーしないと無理といってるし他の人はわかってなかったですね
2018/09/06(木) 19:46:34.66ID:YF3YUgQO
無知じゃなくて無能なのが問題なんだよなぁ
2018/09/06(木) 20:06:23.27ID:/8o/0CpY
2018/09/06(木) 20:20:52.28ID:4aYwdhCB
>>67
多分お前がまだ良く分かってないから、大多数が分かってるのが理解できないんだと思うけどな。
無知を認めるなら、間違った解決法に対して「これでいい」「これで問題ない」「これがVSCodeの仕様」と思い込むな。
無知すぎてその解決法も間違ってて依然無知だと言うことにすら気づいてない。
ちゃんと真摯に聞け。
多分お前がまだ良く分かってないから、大多数が分かってるのが理解できないんだと思うけどな。
無知を認めるなら、間違った解決法に対して「これでいい」「これで問題ない」「これがVSCodeの仕様」と思い込むな。
無知すぎてその解決法も間違ってて依然無知だと言うことにすら気づいてない。
ちゃんと真摯に聞け。
2018/09/06(木) 20:40:13.28ID:ZRGsnqPQ
いじってくるから返してるだけですが
もう解決済みの問題ですよ
コードも思った通り動きますし
どこかに認識不足があったとしても後は自力でどうにでもなります
もう解決済みの問題ですよ
コードも思った通り動きますし
どこかに認識不足があったとしても後は自力でどうにでもなります
2018/09/06(木) 20:56:23.16ID:4aYwdhCB
解決済みだと思いこんでる問題だろ。
認識不足ではなくて勘違いどころか、壁に釘を打ち込む為に金槌使わずにレンガ使ってるのを「これで解決しました。もう問題ありません」って主張してるようなもんだぞ。
自力でどうにもなってないから、間違ってる、型ヒント使えと言ってるんだよ。
自力でどうにかなってるという勘違いをまず改めろよ。
なんの為の質問と耳の痛いレスなんだよ。
釘は金槌で打つもので、レンガでも打てるけどそれは根本的に間違ってる。
それぐらい認識しろ。
認識不足ではなくて勘違いどころか、壁に釘を打ち込む為に金槌使わずにレンガ使ってるのを「これで解決しました。もう問題ありません」って主張してるようなもんだぞ。
自力でどうにもなってないから、間違ってる、型ヒント使えと言ってるんだよ。
自力でどうにかなってるという勘違いをまず改めろよ。
なんの為の質問と耳の痛いレスなんだよ。
釘は金槌で打つもので、レンガでも打てるけどそれは根本的に間違ってる。
それぐらい認識しろ。
2018/09/06(木) 21:02:58.82ID:YF3YUgQO
まぁ別に無能さん本人が苦労するだけだし
2018/09/06(木) 21:14:28.43ID:4aYwdhCB
確かにあとから苦労するだろうな。中途半端で理解した気になって、あまつさえ人につっかかる人間性だと。
2018/09/06(木) 21:18:49.68ID:4aYwdhCB
まぁ、いよいよ言うに困ったら「いじってくるから返してるだけ」なんて言うレベルだし仕方ねえかな。
無駄な時間使ったわ。
いじられてんじゃなくて良くなるように指摘されてると理解できないとか、よっぽどプライドと意識の高い人なんだろう。
他人に無能と言う割に、無能と言われるとムキになるところからもわかるけど。
無駄な時間使ったわ。
いじられてんじゃなくて良くなるように指摘されてると理解できないとか、よっぽどプライドと意識の高い人なんだろう。
他人に無能と言う割に、無能と言われるとムキになるところからもわかるけど。
2018/09/06(木) 21:38:27.78ID:ZRGsnqPQ
プログラムを動かすことが目的なのであって完璧で無駄のないプログラム
を目指すのが目的ではないので問題ないですよ
あと教えたいのか教えたくないのかはっきりしましょうね
1レスで済む問題です
人格攻撃挟んだり説教はさんだりそれこそ無駄ですよ
自分が答えるときは手本のコード貼るだけですけどね
を目指すのが目的ではないので問題ないですよ
あと教えたいのか教えたくないのかはっきりしましょうね
1レスで済む問題です
人格攻撃挟んだり説教はさんだりそれこそ無駄ですよ
自分が答えるときは手本のコード貼るだけですけどね
2018/09/06(木) 21:52:51.80ID:/8o/0CpY
>>76
> 自分が答えるときは手本のコード貼るだけですけどね
君が答えられるようになるまでに何年かかるかだね。
君みたいな「完璧超人な俺が間違うはずがない」って勘違いは、
昨日プログミングを始めました、みたいな奴に多いのだが。
> 自分が答えるときは手本のコード貼るだけですけどね
君が答えられるようになるまでに何年かかるかだね。
君みたいな「完璧超人な俺が間違うはずがない」って勘違いは、
昨日プログミングを始めました、みたいな奴に多いのだが。
2018/09/06(木) 22:13:41.83ID:ZRGsnqPQ
2018/09/07(金) 00:21:07.69ID:hkBW1/hd
2018/09/07(金) 07:48:35.79ID:6E8Xbbh2
2018/09/07(金) 09:46:09.34ID:LPuBQhPk
2018/09/07(金) 19:06:38.66ID:6E8Xbbh2
2018/09/07(金) 19:34:04.35ID:LPuBQhPk
こっちは配列文字列に入りゃそれでいいんだよw
プライド高いだの苦労するだのもっとよくしてやろうとか大げさなんだよw
なんだよそのたとえ話はw禅問答かよw
プライド高いだの苦労するだのもっとよくしてやろうとか大げさなんだよw
なんだよそのたとえ話はw禅問答かよw
2018/09/07(金) 20:35:16.19ID:6E8Xbbh2
そういう意味では最初から文字列の配列に入ってる。
ただインテリセンスが判断しきらないだけ。
だからJSDoc書くんだよ。
大げさも何もw
言い方やら何かしらをやりだまにあげて、本当に言いたい事をごまかすの辞めたら?
言っていいよ。惨めだから辞めてくれって。
ただインテリセンスが判断しきらないだけ。
だからJSDoc書くんだよ。
大げさも何もw
言い方やら何かしらをやりだまにあげて、本当に言いたい事をごまかすの辞めたら?
言っていいよ。惨めだから辞めてくれって。
2018/09/07(金) 21:07:56.41ID:vUsanene
node.jsスレでも暴れてなかったかw
2018/09/07(金) 21:32:36.73ID:LPuBQhPk
最初からエラーじゃなかったと言ってるだろうがw
だからおまえの解決法は間違ってるとかこいつなに言ってんだろうとw
まぁそんなことは放っといてどんどんプログラム書き進めて完成したところだ
だからおまえの解決法は間違ってるとかこいつなに言ってんだろうとw
まぁそんなことは放っといてどんどんプログラム書き進めて完成したところだ
2018/09/08(土) 02:03:40.06ID:wl85Zjtc
わかんなかったら良いよ。
88デフォルトの名無しさん
2018/09/08(土) 22:21:19.25ID:ddYbzdu2 [63,61,59,57,55].forEach((v,i)=>{
})
[63,61,59,57,55].forEach((v,i)=>{
})
二つ目がエラーになる
なぜなのか... 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)
})
[63,61,59,57,55].forEach((v,i)=>{
})
二つ目がエラーになる
なぜなのか... 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)
2018/09/08(土) 22:46:32.30ID:OKOnzFKW
セミコロンは書く習慣を付けよ
2018/09/08(土) 22:56:30.05ID:OKOnzFKW
ついでに
TypeError: Cannot read property '55' of undefined
からundefinedの55番目を参照しようとしているのは分かるわけだから3行目の[]がインデクサとして解釈されていることも明らか
TypeError: Cannot read property '55' of undefined
からundefinedの55番目を参照しようとしているのは分かるわけだから3行目の[]がインデクサとして解釈されていることも明らか
2018/09/09(日) 15:56:13.70ID:Qg0vuvcZ
node.jsのhttpモジュールでapiからjson取得してそれを使ってゴニョゴニョしたいんですが
レスポンスが終わった際jsonを返すにはどうしたらよいのでしょう?
promise使って返す事は出来たのですが他の方法があればご教授ください
レスポンスが終わった際jsonを返すにはどうしたらよいのでしょう?
promise使って返す事は出来たのですが他の方法があればご教授ください
2018/09/12(水) 06:23:42.72ID:Qysc30q7
オライリーのサイ本の新版はまだですかね?
2018/09/12(水) 08:31:30.81ID:UguErVzZ
セミコロン要らなくね?
なんでつけなきゃいけんの
なんでつけなきゃいけんの
2018/09/12(水) 08:57:59.62ID:ggdtqqXv
>>88みたいなことにならないなら好きにすればいいと思うよ
2018/09/12(水) 09:03:15.84ID:ZA2SnA8s
think49に粘着してる奴、過去にthink49と何かあったの?(あるいは、マルチポスト晒された質問者が逆恨みしてるの?)
反論してる人を全てthink49と思いこんでるようだけど、スレ違いの話題を延々と続けられて迷惑してる人が大勢いることにまだ気が付かないわけ?
質問者の為を思うなら、質問者がクローズしたここで苦情を申し立てるより、質問継続しているteratailで回答してくるべきでしょ
反論してる人を全てthink49と思いこんでるようだけど、スレ違いの話題を延々と続けられて迷惑してる人が大勢いることにまだ気が付かないわけ?
質問者の為を思うなら、質問者がクローズしたここで苦情を申し立てるより、質問継続しているteratailで回答してくるべきでしょ
9795
2018/09/12(水) 09:04:03.48ID:ZA2SnA8s ごめん、スレ違い
2018/09/12(水) 11:14:35.86ID:AqE8/xq/
2018/09/12(水) 18:16:28.94ID:yjQ+UVp3
ご質問です。
当方デザイナー兼コーダーとして、自社サイトの制作に携わることになりました。
その際サーバー側を担当するエンジニアからjqueryはもう古いから、他のライブラリを使うかせめてjavascriptで実装するようにと言われました。
大手のサイト等拝見しても、jqueryは現役ですし、特に陳腐化するような懸念は感じられなかったのですが何か理由があるのでしょうか。よろしくお願いします。
当方デザイナー兼コーダーとして、自社サイトの制作に携わることになりました。
その際サーバー側を担当するエンジニアからjqueryはもう古いから、他のライブラリを使うかせめてjavascriptで実装するようにと言われました。
大手のサイト等拝見しても、jqueryは現役ですし、特に陳腐化するような懸念は感じられなかったのですが何か理由があるのでしょうか。よろしくお願いします。
100デフォルトの名無しさん
2018/09/12(水) 19:01:28.13ID:ju4xLwYY jquery大嫌いな人間だけど
古いからは何の理由にもなってないと思う
古いからは何の理由にもなってないと思う
101デフォルトの名無しさん
2018/09/12(水) 19:01:38.69ID:Jy3sklaz >>99
言った人に聞けばいいじゃん。
理由は「もう古いから」って言われたんだろ?
それしか理由が言えないやつならそれまでってことだよ
代替案が提示できないか提示してもメリットを言えなければ
そのエンジニアはただの園児ってことだよw
このスレでも何度も話題になったが、いずれも代替案を
言えないか、言ったとしてもメリットが無かった。
言った人に聞けばいいじゃん。
理由は「もう古いから」って言われたんだろ?
それしか理由が言えないやつならそれまでってことだよ
代替案が提示できないか提示してもメリットを言えなければ
そのエンジニアはただの園児ってことだよw
このスレでも何度も話題になったが、いずれも代替案を
言えないか、言ったとしてもメリットが無かった。
102デフォルトの名無しさん
2018/09/12(水) 19:06:35.30ID:Jy3sklaz 2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
https://w3techs.com/technologies/history_overview/javascript_library
ウェブサイトのうち、jQueryの毎月の使用率(2017/9/1 〜 2018/9/12)
72.8% 72.9% 72.9% 73.0% 73.1% 73.2% 73.2% 73.4% 73.3% 73.2% 73.3% 73.3% 73.4% 73.3%
JavaScriptを使っているサイトの中でのjQueryの使用率
96.3% 96.2% 96.2% 96.2% 96.2% 96.2% 96.2% 96.1% 96.2% 96.9% 97.0% 97.1% 97.1% 97.1%
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
https://w3techs.com/technologies/history_overview/javascript_library
ウェブサイトのうち、jQueryの毎月の使用率(2017/9/1 〜 2018/9/12)
72.8% 72.9% 72.9% 73.0% 73.1% 73.2% 73.2% 73.4% 73.3% 73.2% 73.3% 73.3% 73.4% 73.3%
JavaScriptを使っているサイトの中でのjQueryの使用率
96.3% 96.2% 96.2% 96.2% 96.2% 96.2% 96.2% 96.1% 96.2% 96.9% 97.0% 97.1% 97.1% 97.1%
103デフォルトの名無しさん
2018/09/12(水) 20:23:57.25ID:A4EXsm7N >>102
嘘乙。
間違えただけだろうけど、重要なところなので。
× > JavaScriptを使っているサイトの中でのjQueryの使用率 97.1%
○ JavaScript『ライブラリ』を使っているサイトの中でのjQueryの使用率 97.1%
クライアントサイドでのJavaScriptの使用率は 94.9%
> https://w3techs.com/technologies/overview/client_side_language/all
JavaScriptを使っているサイトの内、生JavaScriptは 24.5% (jQueryは 73.3%)
> https://w3techs.com/technologies/overview/javascript_library/all
嘘乙。
間違えただけだろうけど、重要なところなので。
× > JavaScriptを使っているサイトの中でのjQueryの使用率 97.1%
○ JavaScript『ライブラリ』を使っているサイトの中でのjQueryの使用率 97.1%
クライアントサイドでのJavaScriptの使用率は 94.9%
> https://w3techs.com/technologies/overview/client_side_language/all
JavaScriptを使っているサイトの内、生JavaScriptは 24.5% (jQueryは 73.3%)
> https://w3techs.com/technologies/overview/javascript_library/all
104デフォルトの名無しさん
2018/09/12(水) 21:35:59.89ID:Q4wfRw6c105デフォルトの名無しさん
2018/09/12(水) 23:41:36.77ID:Jy3sklaz106デフォルトの名無しさん
2018/09/13(木) 10:17:54.66ID:wYw7g9y8 macのsafari用にbookmarkletで
選択範囲のリンクを取得したいのですが
alert prompt 共に2000文字以上表示出来なくて
リンク全てを得ることが出来ません
こういう場合どんな方法を使えばいいですか?
よろしくお願いします
選択範囲のリンクを取得したいのですが
alert prompt 共に2000文字以上表示出来なくて
リンク全てを得ることが出来ません
こういう場合どんな方法を使えばいいですか?
よろしくお願いします
107デフォルトの名無しさん
2018/09/13(木) 12:18:24.15ID:pJH+KOs1 >>106
document.bodyにtextarea要素をappendChild
document.bodyにtextarea要素をappendChild
108デフォルトの名無しさん
2018/09/13(木) 13:21:50.59ID:MDnJtYdX109デフォルトの名無しさん
2018/09/13(木) 14:05:41.93ID:q7iUBK5M > es2015で十分じゃん。なんであえてjquery使う必要があるの?といいたいのでは?
esなんちゃらの対応範囲はJavaScriptという言語であって
JavaScriptの範囲外のDOM操作は何も変わらない
DOM APIっていうのはブラウザが提供してるAPIだから
JavaScriptではない。本来はこのスレの対象外
jQueryはDOM APIをシンプルにするものだから
esなんちゃらを使ってもjQueryは必要
esなんちゃらの対応範囲はJavaScriptという言語であって
JavaScriptの範囲外のDOM操作は何も変わらない
DOM APIっていうのはブラウザが提供してるAPIだから
JavaScriptではない。本来はこのスレの対象外
jQueryはDOM APIをシンプルにするものだから
esなんちゃらを使ってもjQueryは必要
110デフォルトの名無しさん
2018/09/13(木) 14:12:07.49ID:gMXNp99s JQueryが古いからダメと言うのは、ちょっと語弊があるけど細かく説明するのが面倒くさいからが半分、今流行ってるライブラリ使いたい/JQueryと食い合わせが悪いってのが半分な気がするな。
まあvanillaでできない事も減ったし。
まあvanillaでできない事も減ったし。
111デフォルトの名無しさん
2018/09/13(木) 15:02:21.70ID:q7iUBK5M 流行りだから使うって考えがアホ
それにjQuery以外に流行ってるものなんかあるかいw
https://w3techs.com/technologies/history_overview/javascript_library
jQueryの次に使われてるのは、Bootstrap(jQueryとの併用) 23.6%、
Modernizer 15.1%、Undsersore 3.3%だぞ。これらはjQueryの代替ライブラリじゃない
MooTools? 2016年から更新されてない
ASP.NET Ajax?ASP.NETを使うなら良いのでは?
Prototype? 2015年から更新されていない
Moment.js これは日付用ライブラリ
最近出てきて有名なのは、Angular、Reactだけど
https://w3techs.com/technologies/history_overview/javascript_library/ms/q
Reactシェア下がってんなw 0.8%だったものが0.2%に落ちてる
Angularは6年かけてやっと0.1%から0.6%よ。それも最近はペースが落ちてる
0.4%台は6ヶ月、0.5%台は9ヶ月、0.6%台は18ヶ月超えてもまだ伸びない
一方jQueryは最近は97.1%と上げ止まり状況だが、それでも3ヶ月で0.1%伸びてるしな
それにjQuery以外に流行ってるものなんかあるかいw
https://w3techs.com/technologies/history_overview/javascript_library
jQueryの次に使われてるのは、Bootstrap(jQueryとの併用) 23.6%、
Modernizer 15.1%、Undsersore 3.3%だぞ。これらはjQueryの代替ライブラリじゃない
MooTools? 2016年から更新されてない
ASP.NET Ajax?ASP.NETを使うなら良いのでは?
Prototype? 2015年から更新されていない
Moment.js これは日付用ライブラリ
最近出てきて有名なのは、Angular、Reactだけど
https://w3techs.com/technologies/history_overview/javascript_library/ms/q
Reactシェア下がってんなw 0.8%だったものが0.2%に落ちてる
Angularは6年かけてやっと0.1%から0.6%よ。それも最近はペースが落ちてる
0.4%台は6ヶ月、0.5%台は9ヶ月、0.6%台は18ヶ月超えてもまだ伸びない
一方jQueryは最近は97.1%と上げ止まり状況だが、それでも3ヶ月で0.1%伸びてるしな
112デフォルトの名無しさん
2018/09/13(木) 15:04:29.98ID:q7iUBK5M >>110
> まあvanillaでできない事も減ったし。
jQueryはvanillaを使って作られてるのだから
jQueryでできることはvanillaでできるのは当たり前。
「できないこと」ではなくて「面倒なこと」という方が正しい
vanillaで面倒なことは減っては来たが、それでもjQueryの方が簡単
https://github.com/nefe/You-Dont-Need-jQuery を見れば
jQueryがほんの僅かのコードで書けているものが
vanillaだと何行も書かないといけないのがよく分かるよw
> まあvanillaでできない事も減ったし。
jQueryはvanillaを使って作られてるのだから
jQueryでできることはvanillaでできるのは当たり前。
「できないこと」ではなくて「面倒なこと」という方が正しい
vanillaで面倒なことは減っては来たが、それでもjQueryの方が簡単
https://github.com/nefe/You-Dont-Need-jQuery を見れば
jQueryがほんの僅かのコードで書けているものが
vanillaだと何行も書かないといけないのがよく分かるよw
113デフォルトの名無しさん
2018/09/13(木) 18:39:51.86ID:gMXNp99s >>112
ああ、vanillaでブラウザ互換を気にしないでできない事も減ったし、と言い直すわ。
ああ、vanillaでブラウザ互換を気にしないでできない事も減ったし、と言い直すわ。
114デフォルトの名無しさん
2018/09/13(木) 22:45:10.28ID:WZkmmoq7 >>107さん、ありがとうございます!
115デフォルトの名無しさん
2018/09/29(土) 16:00:25.20ID:EY+8Y7mF JQuery でテーブルの各行の高さを求めるにはどうしたらいいですか。
たとえば最初の行の高さを求めるのに
$('table > tbody > tr').eq(0).height()
などとやると height() がないと怒られます。
実際には、最初の行の高さを求めたいのではなく、最初から特定の行までの行の高さの総和を求めたいのですが。
たとえば最初の行の高さを求めるのに
$('table > tbody > tr').eq(0).height()
などとやると height() がないと怒られます。
実際には、最初の行の高さを求めたいのではなく、最初から特定の行までの行の高さの総和を求めたいのですが。
116デフォルトの名無しさん
2018/09/30(日) 19:29:37.69ID:OEZEh+vL 互換性が機能の違いを吸収するライブラリのことを
英語でなんて言いましたっけね?
Polyfillは標準があって、その標準に準拠させるためのライブラリ
ShimもShamも似たような意味で
単に違いを吸収するだけとは違う気がします。
英語でなんて言いましたっけね?
Polyfillは標準があって、その標準に準拠させるためのライブラリ
ShimもShamも似たような意味で
単に違いを吸収するだけとは違う気がします。
117デフォルトの名無しさん
2018/10/01(月) 08:20:05.69ID:f53L+AZf > 互換性が機能の違いを吸収する
日本語でおk
日本語でおk
118デフォルトの名無しさん
2018/10/02(火) 12:48:48.76ID:ePLk0Avk119デフォルトの名無しさん
2018/10/02(火) 12:54:31.59ID:RHsXQ8hR >>118
日本語でおk
日本語でおk
120デフォルトの名無しさん
2018/10/02(火) 14:56:41.74ID:65V1o4VA 日本語の桶
121デフォルトの名無しさん
2018/10/02(火) 15:45:10.09ID:6qOrAQgQ 桶はざまぁの戦い
122デフォルトの名無しさん
2018/10/08(月) 21:19:13.44ID:CA37Z1fG JavaScript初心者です
JavaScriptの中で別のJavaScriptを読み込んで、その中のclassを使いたいのですが、やり方を教えていただけませんか?
html5とJavaScript(enchant.js)でゲームを作っていて、main.jsの記述を減らすためにファイルを分けようとしたのですが、どうにも上手く読み込んでくれません…
JavaScriptの中で別のJavaScriptを読み込んで、その中のclassを使いたいのですが、やり方を教えていただけませんか?
html5とJavaScript(enchant.js)でゲームを作っていて、main.jsの記述を減らすためにファイルを分けようとしたのですが、どうにも上手く読み込んでくれません…
123デフォルトの名無しさん
2018/10/08(月) 21:21:07.03ID:IMi/szTI124デフォルトの名無しさん
2018/10/08(月) 21:53:33.10ID:l3K5ZkX8 普通にモジュールにすれば?
125デフォルトの名無しさん
2018/10/08(月) 21:57:40.61ID:IMi/szTI ブラウザがモジュールに対応してないからビルドが必要になるということ
126デフォルトの名無しさん
2018/10/09(火) 00:47:20.38ID:ag2UDSq0 モダンブラウザは対応してるでしょ
シェアの8割〜9割は対応してることになる
非サポート組はnomoduleで最低限の機能提供するか
JS切ってるのと同等に扱ったほうが良いだろうね
シェアの8割〜9割は対応してることになる
非サポート組はnomoduleで最低限の機能提供するか
JS切ってるのと同等に扱ったほうが良いだろうね
127デフォルトの名無しさん
2018/10/09(火) 05:31:49.77ID:0K1bBeTL 小さく始める isomorphic module pattern
https://qiita.com/Jxck_/items/14bbb49d1fd657f03343
【JavaScript】モジュールパターンについて知る
https://qiita.com/kenju/items/a8a1009f5872a8b12568
原始的なモジュール定義は、即時関数で囲めばプライベートになり、外から内部にアクセスできない。
公開する属性だけ、return で返せばよい。
下のサイトの、モジュールパターン4 を参照
本格的な開発では、Node.js, webpack, ES6 などを使う
モジュールシステムは、AMD, commonjs 方式の2つあり、
そのゲームエンジンが採用している方を使えばよい
https://qiita.com/Jxck_/items/14bbb49d1fd657f03343
【JavaScript】モジュールパターンについて知る
https://qiita.com/kenju/items/a8a1009f5872a8b12568
原始的なモジュール定義は、即時関数で囲めばプライベートになり、外から内部にアクセスできない。
公開する属性だけ、return で返せばよい。
下のサイトの、モジュールパターン4 を参照
本格的な開発では、Node.js, webpack, ES6 などを使う
モジュールシステムは、AMD, commonjs 方式の2つあり、
そのゲームエンジンが採用している方を使えばよい
128デフォルトの名無しさん
2018/10/09(火) 07:43:45.77ID:UgeI4/Dm129デフォルトの名無しさん
2018/10/09(火) 13:01:09.86ID:WbCvYqZw それとは結構違うな
レガシーブラウザを使い続けてるって言うのは特殊な部分があるし、
ブラウザもその下のハードウェアも性能に期待できないから
ポリフィルという重しを課してまでモダンブラウザと同等に働かせるべきかと言うと
自分はハテナを浮かべるな
レガシーブラウザを使い続けてるって言うのは特殊な部分があるし、
ブラウザもその下のハードウェアも性能に期待できないから
ポリフィルという重しを課してまでモダンブラウザと同等に働かせるべきかと言うと
自分はハテナを浮かべるな
130デフォルトの名無しさん
2018/10/09(火) 15:30:06.33ID:5rulySP1 class言ってるんだからモダンブラウザで良いでしょ
131デフォルトの名無しさん
2018/10/09(火) 16:36:00.49ID:nSYMPMxp >>128
シェアの8割〜9割の意味をもう少し考えたらどうだ
シェアの8割〜9割の意味をもう少し考えたらどうだ
132デフォルトの名無しさん
2018/10/09(火) 16:58:59.78ID:UgeI4/Dm133デフォルトの名無しさん
2018/10/09(火) 20:41:59.88ID:nSYMPMxp >>132
それでなんでFirefoxで動かなくていいやってことになるんだ?
それでなんでFirefoxで動かなくていいやってことになるんだ?
134デフォルトの名無しさん
2018/10/09(火) 22:33:02.61ID:UgeI4/Dm Firefox使ってる人なんて1割もいないからね
135デフォルトの名無しさん
2018/10/10(水) 07:19:30.36ID:sen6MTwy 動画ダウンロードで使わない?
136デフォルトの名無しさん
2018/10/10(水) 08:45:51.61ID:az2ldVPt そもそも動画ダウンロードなんてしないからね
137デフォルトの名無しさん
2018/10/10(水) 12:20:48.13ID:AVL6Qil2 またーw
138デフォルトの名無しさん
2018/10/10(水) 14:19:23.42ID:okGPgjBf JavaScriptを理解するのってどのくらいの期間かかるものなの?
ドットインストールの有料コース3週くらいやってんだけど未だ難しい
ドットインストールの有料コース3週くらいやってんだけど未だ難しい
139デフォルトの名無しさん
2018/10/10(水) 14:38:22.99ID:B6RiIKZG >>134
まだ理解できてないのか・・
まだ理解できてないのか・・
140デフォルトの名無しさん
2018/10/10(水) 14:46:23.62ID:9JBgxA14141デフォルトの名無しさん
2018/10/10(水) 18:21:03.46ID:dFZubxbw IEしか使えないってのは要するに企業ユーザーであって
それは案件ごとに要望に沿うだけの話だけど
宗教的理由によりIEしか使えない奴らはそれこそ知らんと言っても良いと思う
それは案件ごとに要望に沿うだけの話だけど
宗教的理由によりIEしか使えない奴らはそれこそ知らんと言っても良いと思う
142デフォルトの名無しさん
2018/10/10(水) 18:33:02.65ID:iLk33V8J 日立の証明書はIEでしか使えないらしいな
143デフォルトの名無しさん
2018/10/10(水) 21:16:48.63ID:mFBZKYqD なんだそりゃ
バカバカしい
バカバカしい
144デフォルトの名無しさん
2018/10/10(水) 21:37:01.50ID:Br1ENpxp 認証基盤のセキュリティもボロボロでヤバイらしいな
145デフォルトの名無しさん
2018/10/11(木) 08:56:59.50ID:3Bdkvxy9 >>138
たのしいRuby 第5版、2016
これを読んで半年、オブジェクト指向・関数型で、Ruby をいじくりまわしてから、JavaScript に戻ればよい。
CSS セレクターを使う、jQuery と、Ruby のNokogiri が、ほぼ同じ
Progate のサイトでも、やってみれば?
プロレベルでは以下の2冊だから、数年は掛かる
JavaScript 第6版、2012、David Flanagan
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017
たのしいRuby 第5版、2016
これを読んで半年、オブジェクト指向・関数型で、Ruby をいじくりまわしてから、JavaScript に戻ればよい。
CSS セレクターを使う、jQuery と、Ruby のNokogiri が、ほぼ同じ
Progate のサイトでも、やってみれば?
プロレベルでは以下の2冊だから、数年は掛かる
JavaScript 第6版、2012、David Flanagan
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017
146デフォルトの名無しさん
2018/10/11(木) 09:40:30.66ID:gME2ocRG Pyキチ君のマッチポンプは本当にしつこいな
147デフォルトの名無しさん
2018/10/11(木) 13:13:36.95ID:bLRRmr2D インタラクティブ・データビジュアライゼーション
――D3.jsによるデータの可視化
原書は第2版が去年出てるみたいです。
日本語版の第2版の出版予定はありませんか?
――D3.jsによるデータの可視化
原書は第2版が去年出てるみたいです。
日本語版の第2版の出版予定はありませんか?
148デフォルトの名無しさん
2018/10/11(木) 14:58:24.35ID:U1kKB/4M >>145
> CSS セレクターを使う、jQuery と、Ruby のNokogiri が、ほぼ同じ
ぜんぜん違う。NokogiriはjQueryに比べたら洗練されていない
通称jQueryオブジェクト呼ばれている、いちばん重要な
オブジェクトがNokogiriには搭載されていない
そのせいでCSSで取得した複数のオブジェクトをeachで繰り返して
操作するというjQuery以前のやり方をしないといけなくなってる。
NokogiriでjQueryを学んだ気になると、jQueryとしては
悪いコードになってしまう。
> CSS セレクターを使う、jQuery と、Ruby のNokogiri が、ほぼ同じ
ぜんぜん違う。NokogiriはjQueryに比べたら洗練されていない
通称jQueryオブジェクト呼ばれている、いちばん重要な
オブジェクトがNokogiriには搭載されていない
そのせいでCSSで取得した複数のオブジェクトをeachで繰り返して
操作するというjQuery以前のやり方をしないといけなくなってる。
NokogiriでjQueryを学んだ気になると、jQueryとしては
悪いコードになってしまう。
149145
2018/10/11(木) 15:19:32.84ID:3Bdkvxy9 そりゃ、jQuery の方が洗練されてる。
Nokogiri では、単数と複数(配列)の戻り値を返す、2つの関数に分かれているから面倒
jQueryでは、単数・複数・該当要素なしでも、統一的に扱えるし、メソッドチェーンできる
Nokogiri では、単数と複数(配列)の戻り値を返す、2つの関数に分かれているから面倒
jQueryでは、単数・複数・該当要素なしでも、統一的に扱えるし、メソッドチェーンできる
150デフォルトの名無しさん
2018/10/11(木) 23:35:01.60ID:mM6EaaqO151デフォルトの名無しさん
2018/10/12(金) 13:03:40.32ID:9N5F64KF JSを理解するとは仕様書のどこを読んでも、うんうんそうだよね、と言える状況のこと
型変換、スコープチェーン、プロトタイプチェーンのようにイメージの積み重ねでの閃きのような物が必要な概念もあるけど
一方共有渡しの原理とかは仕様書を読まないと絶対に納得できない
型変換、スコープチェーン、プロトタイプチェーンのようにイメージの積み重ねでの閃きのような物が必要な概念もあるけど
一方共有渡しの原理とかは仕様書を読まないと絶対に納得できない
152デフォルトの名無しさん
2018/10/12(金) 17:20:44.39ID:vWnsmRfa >>151
お前ん中ではな
お前ん中ではな
153デフォルトの名無しさん
2018/10/12(金) 17:36:26.39ID:fvSpqiCp >>152
お前どこ中よ
お前どこ中よ
154デフォルトの名無しさん
2018/10/13(土) 16:34:13.35ID:SiZRzIIf むしろ自分の中の話でなかったら何なんだ?
お前の中では>>151が世界の代弁者のつもりにでも見えるのか?
お前の中では>>151が世界の代弁者のつもりにでも見えるのか?
155デフォルトの名無しさん
2018/10/16(火) 18:57:47.86ID:gqm4/+eQ すみません、以下のコードが読めません。分解して教えてくださいませんか?
1 function presetDiary(dateStr){};
2 htmlStr += "<a onclick='presetDiary(\"" +dateStr + "\");'>"+cellStr+"</a></td>";
2行目はダブルクォーテーションとシングルクオーテーションが入り乱れていて
何が書かれているかわからなくなってます。
普通にHTMLタグで書くと
<a onclick="presetDiary(dateStr)">cellStr</a></td>
となると考えていいのでしょうか?
1 function presetDiary(dateStr){};
2 htmlStr += "<a onclick='presetDiary(\"" +dateStr + "\");'>"+cellStr+"</a></td>";
2行目はダブルクォーテーションとシングルクオーテーションが入り乱れていて
何が書かれているかわからなくなってます。
普通にHTMLタグで書くと
<a onclick="presetDiary(dateStr)">cellStr</a></td>
となると考えていいのでしょうか?
156デフォルトの名無しさん
2018/10/16(火) 19:35:14.13ID:JHQMnpCL > 2行目はダブルクォーテーションとシングルクオーテーションが入り乱れていて
> 何が書かれているかわからなくなってます。
わかるだろ?
お前が本当に言いたいことは、
どこがどう対応しているのか調べるのが
「面倒です」ってだけだろ
嘘つくなや。そして怠けるな
> 何が書かれているかわからなくなってます。
わかるだろ?
お前が本当に言いたいことは、
どこがどう対応しているのか調べるのが
「面倒です」ってだけだろ
嘘つくなや。そして怠けるな
157デフォルトの名無しさん
2018/10/16(火) 21:44:10.31ID:Fb63Sgww >>155
色が付くエディタ使え
色が付くエディタ使え
158デフォルトの名無しさん
2018/10/17(水) 15:22:11.32ID:RzUo3BE1 1. は単なる関数定義。
入門書を読むか、検索でもすれば?
2.
><a onclick="presetDiary(dateStr)">cellStr</a></td>
こうだろ
<a onclick='presetDiary("dateStr");'>cellStr</a></td>
でも変数、dateStr を、" " で囲むのは、おかしい。
この文は、間違い
入門書を読むか、検索でもすれば?
2.
><a onclick="presetDiary(dateStr)">cellStr</a></td>
こうだろ
<a onclick='presetDiary("dateStr");'>cellStr</a></td>
でも変数、dateStr を、" " で囲むのは、おかしい。
この文は、間違い
159デフォルトの名無しさん
2018/10/17(水) 16:35:37.59ID:e5Vejsh/ onclickとイベントリスナーclickの違いって何があるんでしょうか?
160デフォルトの名無しさん
2018/10/17(水) 16:40:16.32ID:t+3zMNmx onclickの方が古く、問題があるので
解決策として出てきたのがイベントリスナー
解決策として出てきたのがイベントリスナー
161デフォルトの名無しさん
2018/10/17(水) 16:46:48.92ID:RzUo3BE1 HTML 内に書くと、グローバル関数になってしまうから、良くない
また、addEventListener() は、ブラウザによっては使えないから、
jQuery を使う方が、互換性が高い
web 関連の質問は、web制作管理板へ書き込んでください。
そこの方が、知っている人が多い
また、addEventListener() は、ブラウザによっては使えないから、
jQuery を使う方が、互換性が高い
web 関連の質問は、web制作管理板へ書き込んでください。
そこの方が、知っている人が多い
162デフォルトの名無しさん
2018/10/17(水) 17:34:22.61ID:e5Vejsh/163デフォルトの名無しさん
2018/10/17(水) 20:22:09.27ID:jwV5Qww9164デフォルトの名無しさん
2018/10/21(日) 12:16:46.62ID:LRWHxwNR WEB広告の内容ってJavaScriptで取得できますか?
他社サービスの広告を埋め込み配置して表示させる(hiddenでもかまわない)
JavaScriptで広告の内容を取得してユーザーIDと合わせてサーバーに送信して保存する
保存したデータから個々のユーザーが興味を持っている事がわかるのでマーケティングに利用する
ということができるのではないかと考えています
他社サービスの広告を埋め込み配置して表示させる(hiddenでもかまわない)
JavaScriptで広告の内容を取得してユーザーIDと合わせてサーバーに送信して保存する
保存したデータから個々のユーザーが興味を持っている事がわかるのでマーケティングに利用する
ということができるのではないかと考えています
165デフォルトの名無しさん
2018/10/21(日) 17:52:02.24ID:dQhyPQp/ >>164
不可能。そういう悪用ができないようになってる
不可能。そういう悪用ができないようになってる
166デフォルトの名無しさん
2018/10/22(月) 02:12:50.84ID:Lpu88jHm >>164
スクレイピング?
スクレイピング?
167デフォルトの名無しさん
2018/10/24(水) 11:22:21.43ID:xs2ZRvHz キャンバス上に描く図形の色を変数から指定したいのですが変数名を入れる時にただの文字列と区別させて認識させるにはどうしたらいいでしょうか?
var str=フォーム.色.value;
con.fillStyle = 'str';
としているのですがどうしても黒のままなのです
var str=フォーム.色.value;
con.fillStyle = 'str';
としているのですがどうしても黒のままなのです
168デフォルトの名無しさん
2018/10/24(水) 18:34:08.20ID:E7uk8Rlh ただの文字列でいいんだよ
169デフォルトの名無しさん
2018/10/26(金) 00:09:36.43ID:PFgc5eHH ダウンロードにプログレスつけるのって簡単にできる?
手元にとどいてるファイルのサイズってJSでみれる?
手元にとどいてるファイルのサイズってJSでみれる?
170デフォルトの名無しさん
2018/10/26(金) 07:42:18.47ID:/Mzux3k9 >>169
XHRやFetchなら
XHRやFetchなら
171デフォルトの名無しさん
2018/10/26(金) 09:22:51.60ID:PFgc5eHH Fetchって使ったことないので調べてみます
ありがとうございます
ありがとうございます
172デフォルトの名無しさん
2018/10/27(土) 12:43:23.69ID:y64ULql5 >>164
できる、getUserMediaでスクリーンをキャプチャできる
できる、getUserMediaでスクリーンをキャプチャできる
173デフォルトの名無しさん
2018/10/27(土) 13:05:40.33ID:4RrrP6U6174デフォルトの名無しさん
2018/10/27(土) 13:27:35.65ID:8fc2vBvs >>172-173
> カメラやスクリーンシェアリング、マイクのようなビデオやオーディオ入力装置の使用許可をユーザーに要求します。
> スクリーンシェアリング
> https://developer.mozilla.org/ja/docs/Web/API/MediaDevices/getUserMedia
そのための機能なのだから、出来るのだろうね
> カメラやスクリーンシェアリング、マイクのようなビデオやオーディオ入力装置の使用許可をユーザーに要求します。
> スクリーンシェアリング
> https://developer.mozilla.org/ja/docs/Web/API/MediaDevices/getUserMedia
そのための機能なのだから、出来るのだろうね
175デフォルトの名無しさん
2018/10/27(土) 13:43:11.21ID:4RrrP6U6 > 使用許可をユーザーに要求します。
だめじゃんw
WEB広告表示されたら、画面をキャプチャして送信していいか?って聞くんだろ?
だめじゃんw
WEB広告表示されたら、画面をキャプチャして送信していいか?って聞くんだろ?
176デフォルトの名無しさん
2018/10/27(土) 13:57:01.80ID:8fc2vBvs >>175
ユーザ許可が要るのは当たり前だろ
ユーザ許可が要るのは当たり前だろ
177デフォルトの名無しさん
2018/10/27(土) 18:29:12.79ID:io741/EL これでなんで入替えできるの?
b = [a, a = b][0];
b = [a, a = b][0];
178デフォルトの名無しさん
2018/10/27(土) 18:41:50.38ID:8fc2vBvs >>177
それを分からない奴が、そんな書き方のプログラムを読む意味はない
それを分からない奴が、そんな書き方のプログラムを読む意味はない
179デフォルトの名無しさん
2018/10/27(土) 18:56:44.50ID:QlllhdpS 訳:「わからないので説明できない。俺が分からないのだからお前もわかる必要はない」
180デフォルトの名無しさん
2018/10/27(土) 19:10:24.25ID:8fc2vBvs181デフォルトの名無しさん
2018/10/27(土) 19:20:24.19ID:8fc2vBvs >>179
つーか、ググったらヒットしたわ。ちょっと違うけど。
> a = [b][b = a,0];
> https://stackoverflow.com/questions/9864420/how-does-bb-a-0-swap-between-a-and-b
後ろ側は配列として解釈されないのか?という心配はあるが。
サイトのコード読んでいるのなら、minifyするときにそうなった可能性がある。
(良いやり方だとも思わないし、具体的に何を使えばそうなるのかも知らんが)
手でそんなのを書く奴は居ないので、
もし君がそこに引っかかっている(=文法も十分に分からない初心者)なら、今は別のコードを読むべきだ。
つーか、ググったらヒットしたわ。ちょっと違うけど。
> a = [b][b = a,0];
> https://stackoverflow.com/questions/9864420/how-does-bb-a-0-swap-between-a-and-b
後ろ側は配列として解釈されないのか?という心配はあるが。
サイトのコード読んでいるのなら、minifyするときにそうなった可能性がある。
(良いやり方だとも思わないし、具体的に何を使えばそうなるのかも知らんが)
手でそんなのを書く奴は居ないので、
もし君がそこに引っかかっている(=文法も十分に分からない初心者)なら、今は別のコードを読むべきだ。
182デフォルトの名無しさん
2018/10/27(土) 19:53:15.55ID:61pv23m7 a = 1, b = 2のとき
b = [ a, a = b ][ 0 ]
b = [ 1, a = b ][ 0 ]
b = [ 1, a = 2 ][ 0 ]
a = 2; b = [ 1, 2 ][ 0 ]
a = 2; b = 1
b = [ a ][ a = b, 0 ]
b = [ 1 ][ a = b, 0 ]
b = [ 1 ][ a = 2, 0 ]
a = 2; b = [ 1 ][ 2, 0 ] //カンマ演算子
a = 2; b = [ 1 ][ 0 ]
a = 2; b = 1
段階は全然多くない、このくらいなら手で書かれることは十分にある
このくらいは理解できないとJS中級者にはなれない
ただ超基本的な処理の順番や構文を知っていてそれを慎重に追っていけるかの問題
因みに同じことをするのは今どきはこうする
[ a, b ] = [ b, a ]
b = [ a, a = b ][ 0 ]
b = [ 1, a = b ][ 0 ]
b = [ 1, a = 2 ][ 0 ]
a = 2; b = [ 1, 2 ][ 0 ]
a = 2; b = 1
b = [ a ][ a = b, 0 ]
b = [ 1 ][ a = b, 0 ]
b = [ 1 ][ a = 2, 0 ]
a = 2; b = [ 1 ][ 2, 0 ] //カンマ演算子
a = 2; b = [ 1 ][ 0 ]
a = 2; b = 1
段階は全然多くない、このくらいなら手で書かれることは十分にある
このくらいは理解できないとJS中級者にはなれない
ただ超基本的な処理の順番や構文を知っていてそれを慎重に追っていけるかの問題
因みに同じことをするのは今どきはこうする
[ a, b ] = [ b, a ]
183デフォルトの名無しさん
2018/10/27(土) 19:56:42.96ID:8fc2vBvs184デフォルトの名無しさん
2018/10/27(土) 20:00:32.27ID:io741/EL185デフォルトの名無しさん
2018/10/27(土) 20:22:17.29ID:61pv23m7 >>183
このくらいの複雑度
つまり五段回くらいの評価が一行に書かれることって
アロー関数とかが入った今ますます書かれるようになってると俺は思うが
特にreduceとか使うとこの例と似た状況にもなりがち
このくらいの複雑度
つまり五段回くらいの評価が一行に書かれることって
アロー関数とかが入った今ますます書かれるようになってると俺は思うが
特にreduceとか使うとこの例と似た状況にもなりがち
186デフォルトの名無しさん
2018/10/27(土) 20:34:06.02ID:E6wydZtk コード圧縮とか難読化は人間がやる作業じゃなかろう
187デフォルトの名無しさん
2018/10/27(土) 20:52:55.30ID:8fc2vBvs >>185
俺の意見は、「変数の入れ替えをその書き方でする奴は居ない」だが、これで理解出来るか?
その程度の「複雑度」なら、大したことはないし、普通の人なら頭の中で読めるでしょ。
> reduce
reduceってのは数値演算をするときに多用するのであって、
通常のJavaScript(=DOM操作等)ではほぼ使わない。
そもそも変数の入れ替えも『初心者用の教材の』ソート等では使うが、実用では皆無でしょ。
お前、前から居るズレてる奴で、相変わらずズレてるよな。
俺の意見は、「変数の入れ替えをその書き方でする奴は居ない」だが、これで理解出来るか?
その程度の「複雑度」なら、大したことはないし、普通の人なら頭の中で読めるでしょ。
> reduce
reduceってのは数値演算をするときに多用するのであって、
通常のJavaScript(=DOM操作等)ではほぼ使わない。
そもそも変数の入れ替えも『初心者用の教材の』ソート等では使うが、実用では皆無でしょ。
お前、前から居るズレてる奴で、相変わらずズレてるよな。
188デフォルトの名無しさん
2018/10/27(土) 20:59:52.02ID:8fc2vBvs189デフォルトの名無しさん
2018/10/27(土) 21:00:16.78ID:4RrrP6U6 おい複雑度っていうのを俺俺で使うんじゃない。
コードメトリクス用語の「複雑度」とごっちゃになって紛らわしい
>>177のようなものは「複雑度」はあがらない。
上から下に単純に読み下せばいいからだ
こういうのは単に知らない命令があったってだけで複雑なのではない
「複雑度」というのは、コード自体は読めるが絡まっていて読みづらいということを指す。
具体的にはループ、条件分岐が増えることで「複雑度」が増えていく
コードメトリクス用語の「複雑度」とごっちゃになって紛らわしい
>>177のようなものは「複雑度」はあがらない。
上から下に単純に読み下せばいいからだ
こういうのは単に知らない命令があったってだけで複雑なのではない
「複雑度」というのは、コード自体は読めるが絡まっていて読みづらいということを指す。
具体的にはループ、条件分岐が増えることで「複雑度」が増えていく
190デフォルトの名無しさん
2018/10/27(土) 21:02:12.37ID:4RrrP6U6 ちなみにコードが複雑というのは、コードの問題だが、
コードが読めないっていうのは、人間側の問題だからな
人間側の問題なのに「これ複雑っすよー」っていうやつが多い
(単にそいつが読めないだけ)
コードが読めないっていうのは、人間側の問題だからな
人間側の問題なのに「これ複雑っすよー」っていうやつが多い
(単にそいつが読めないだけ)
191デフォルトの名無しさん
2018/10/27(土) 21:08:11.95ID:61pv23m7 reduceは数値演算で多様?
[1,2,3,4,5].reduce((o,n)=>{o[`n${n}`]=n;return o},{})
みたいに第二引数にオブジェクト渡して繰り返し操作したりもよくあることだと思うけど
君が全然JSを知らない・知ろうとしない。使って来てない・使おうとしないから
本当に解説書の一番上に乗っている形でしか構文やAPIの使い方を思い浮かばないのは勝手だけど
人のことをズレてるとか言うもんじゃないよ。ただ単に君の応用力が矮小なだけだからね
[1,2,3,4,5].reduce((o,n)=>{o[`n${n}`]=n;return o},{})
みたいに第二引数にオブジェクト渡して繰り返し操作したりもよくあることだと思うけど
君が全然JSを知らない・知ろうとしない。使って来てない・使おうとしないから
本当に解説書の一番上に乗っている形でしか構文やAPIの使い方を思い浮かばないのは勝手だけど
人のことをズレてるとか言うもんじゃないよ。ただ単に君の応用力が矮小なだけだからね
192デフォルトの名無しさん
2018/10/27(土) 21:17:42.56ID:8fc2vBvs >>189
言いたいことは分かるが、
var tmp=a;a=b;b=tmp;
と比べたら複雑なのは事実だろ。
ただし、これにより「コードが読めなくなる」事はあり得ないので、
『大規模コードの長期的メンテナンス』を前提とした
コードメトリクス用語の「複雑度」なら全く上がらないのも事実だ。
ただ、JavaScripterの話を聞いている限り、
こいつらは「どういうコードが読めなくなるか」については知らないし、
それで何とかなる世界なのだと思う。
これ自体は俺はありだと思っているし、このやり方は他言語の連中も学ぶべきだと思う。
つまり、四角四面で「絶対にメンテナンスしきる」のではなく、
ある程度の集積度や規模に留め、コードをある程度使い捨てにしていく、という方法だ。
長期メンテナンス前提で書くと色々面倒だったりするだろ。そのコストが省ける。
言いたいことは分かるが、
var tmp=a;a=b;b=tmp;
と比べたら複雑なのは事実だろ。
ただし、これにより「コードが読めなくなる」事はあり得ないので、
『大規模コードの長期的メンテナンス』を前提とした
コードメトリクス用語の「複雑度」なら全く上がらないのも事実だ。
ただ、JavaScripterの話を聞いている限り、
こいつらは「どういうコードが読めなくなるか」については知らないし、
それで何とかなる世界なのだと思う。
これ自体は俺はありだと思っているし、このやり方は他言語の連中も学ぶべきだと思う。
つまり、四角四面で「絶対にメンテナンスしきる」のではなく、
ある程度の集積度や規模に留め、コードをある程度使い捨てにしていく、という方法だ。
長期メンテナンス前提で書くと色々面倒だったりするだろ。そのコストが省ける。
193デフォルトの名無しさん
2018/10/27(土) 21:26:22.84ID:61pv23m7 「コードをある程度使い捨てにしていく」っていうのはまた面白い話だけど
あの十数文字のコードがそんなに大げさな話に繋がるものかぁ?
どちらにせよ自分としてはちょっと話が違う気がする
コードを捨ててもいいから適当にああいう書き方をするっていうことになるならね
やっぱり幾らかテクニカルなコードっていうのは「どうにでもなれ!」って感じよりはむしろ
書いた本人は効率的で読みやすいと思ってる場合が多いのだろうから
もし読めない人がチームメンバーにいるのならそう書くべきじゃないだろうよ
だって「スマート」という目的が果たされてないのだから
ただ自分が言ってるのは、だからといって一般的に読めないままでいいということではないということ
あの程度は普通に読めるようになっとこうよ、中級者くらいを名乗るなら、と言いたいだけ
あの十数文字のコードがそんなに大げさな話に繋がるものかぁ?
どちらにせよ自分としてはちょっと話が違う気がする
コードを捨ててもいいから適当にああいう書き方をするっていうことになるならね
やっぱり幾らかテクニカルなコードっていうのは「どうにでもなれ!」って感じよりはむしろ
書いた本人は効率的で読みやすいと思ってる場合が多いのだろうから
もし読めない人がチームメンバーにいるのならそう書くべきじゃないだろうよ
だって「スマート」という目的が果たされてないのだから
ただ自分が言ってるのは、だからといって一般的に読めないままでいいということではないということ
あの程度は普通に読めるようになっとこうよ、中級者くらいを名乗るなら、と言いたいだけ
194デフォルトの名無しさん
2018/10/27(土) 21:30:15.09ID:8fc2vBvs195デフォルトの名無しさん
2018/10/27(土) 21:33:21.44ID:8fc2vBvs >>193
前提が全然違う。
あの程度は普通に読めるのは、当たり前なんだ。
そして、あの手の「1行の範囲にとどまる複雑さ」なんて、長期的には全く問題にならない、といってるんだよ。
まあ君には通じないとも思うけど。
前提が全然違う。
あの程度は普通に読めるのは、当たり前なんだ。
そして、あの手の「1行の範囲にとどまる複雑さ」なんて、長期的には全く問題にならない、といってるんだよ。
まあ君には通じないとも思うけど。
196デフォルトの名無しさん
2018/10/27(土) 21:38:46.33ID:QlllhdpS reduceは汎用だよ。誰が数値計算にしか使っちゃいけないって言ったんだろw
サイトからダウンロードURLリスト作ってファイルダウンロードするとき一度に多ストリーム開くと問題なときreduceの中でfetchのプロミスをthenで繋げるようにして一時に1ダウンロードしか走らないように制限したり、
i(h(g(f(e(d(c(b(a(データ。数値に限らないぞ?)))))))))みたいに無数の関数を次々適用したいとき
let fns = [a,b,c,d,e,f,g,h,i]
fns.reduce(((acc,fn) => fn(acc)), データ。数値に限らない)
ってやったり…
宗教で数値計算にしか使わないのは勝手だが布教はよそでしろよな。
てかID:8fc2vBvs程度が低すぎるわ。質問に答えるでもなく程度が低いのに突っかかってばかり。糖質かな?
死ねばいいのに。
サイトからダウンロードURLリスト作ってファイルダウンロードするとき一度に多ストリーム開くと問題なときreduceの中でfetchのプロミスをthenで繋げるようにして一時に1ダウンロードしか走らないように制限したり、
i(h(g(f(e(d(c(b(a(データ。数値に限らないぞ?)))))))))みたいに無数の関数を次々適用したいとき
let fns = [a,b,c,d,e,f,g,h,i]
fns.reduce(((acc,fn) => fn(acc)), データ。数値に限らない)
ってやったり…
宗教で数値計算にしか使わないのは勝手だが布教はよそでしろよな。
てかID:8fc2vBvs程度が低すぎるわ。質問に答えるでもなく程度が低いのに突っかかってばかり。糖質かな?
死ねばいいのに。
197デフォルトの名無しさん
2018/10/27(土) 21:50:21.09ID:8fc2vBvs >>193
あと、多分、中級者の基準がおかしい。
君のはJavaScript『文法』の中級者なんだよ。
JavaScriptはプログラミング言語であり、プログラミング言語は実装の道具だ。
だから、本来の『JavaScript中級者』ってのは、何を実装出来るかで測られるべきなんだよ。
俺の定義なら、以下だね。
・初級者:一通りも出来ない。
・中級者:一通りやりたいことは出来る。
つまり、「ポップアップを作りたい」「ここをクリックしたらこう動かしたい」等、
やりたいことがあれば、とりあえず動く物は作れる。
・上級者:最初から最適な構造を考えて実装出来る。
勿論、新文法が便利なら使えばいいのだけど、最適な構造かどうかと新文法はほぼ関係ない。
(むしろ本質的に必要な物は先に取り入れられるから、新文法は基本的にオマケでしかないし)
それよりも、コード構造の方が何倍も重要なんだよ。
あと、多分、中級者の基準がおかしい。
君のはJavaScript『文法』の中級者なんだよ。
JavaScriptはプログラミング言語であり、プログラミング言語は実装の道具だ。
だから、本来の『JavaScript中級者』ってのは、何を実装出来るかで測られるべきなんだよ。
俺の定義なら、以下だね。
・初級者:一通りも出来ない。
・中級者:一通りやりたいことは出来る。
つまり、「ポップアップを作りたい」「ここをクリックしたらこう動かしたい」等、
やりたいことがあれば、とりあえず動く物は作れる。
・上級者:最初から最適な構造を考えて実装出来る。
勿論、新文法が便利なら使えばいいのだけど、最適な構造かどうかと新文法はほぼ関係ない。
(むしろ本質的に必要な物は先に取り入れられるから、新文法は基本的にオマケでしかないし)
それよりも、コード構造の方が何倍も重要なんだよ。
198デフォルトの名無しさん
2018/10/27(土) 21:55:57.05ID:8fc2vBvs >>196
> reduceの中でfetchのプロミスをthenで繋げるようにして一時に1ダウンロードしか走らないように制限したり、
> 無数の関数を次々適用したいとき
やるのは自由だが、それ、普通に配列をforで回しても実装出来るだろ。
新文法を使う=上級者、というのは完全に間違いだって事だよ。
君らは文法にしか目が行かないからそういうことしか言えない。
それは初心者にありがちなパターンでもあるけど。
(初心者は文法から入るしかないから、どうしてもそこに目が行く)
> reduceの中でfetchのプロミスをthenで繋げるようにして一時に1ダウンロードしか走らないように制限したり、
> 無数の関数を次々適用したいとき
やるのは自由だが、それ、普通に配列をforで回しても実装出来るだろ。
新文法を使う=上級者、というのは完全に間違いだって事だよ。
君らは文法にしか目が行かないからそういうことしか言えない。
それは初心者にありがちなパターンでもあるけど。
(初心者は文法から入るしかないから、どうしてもそこに目が行く)
199デフォルトの名無しさん
2018/10/27(土) 21:56:14.73ID:61pv23m7 >>194
「思っているのだろうけど」とか止めてくれない?
自分はこういう構文が良いものだとも、ああ書くべきだとも言っていないよね?
こういう使い方もできる、こうも書かれることもある
そのくらい思いついて、すんなり読めるようになろうと言ってるだけ
無理に使う?君が無理かどうかなんて知ったことじゃない
>>195
長期的って言うのがそういう期間を指しているのか知らんけど
デバッグも完璧に終わってリリースしてしばらくたった後、大型アップデート時に
ってことならまだ分かるけど、今どきは毎日小変更デプロイでしょ
そういう体制だと将来的に困ったら丸ごとすげ替えればいいっていうのは通用しない
複雑なものを放置しとくと、実際困ること必至
それがJSerの考え方の面白い特徴だとか、古すぎぃ
「思っているのだろうけど」とか止めてくれない?
自分はこういう構文が良いものだとも、ああ書くべきだとも言っていないよね?
こういう使い方もできる、こうも書かれることもある
そのくらい思いついて、すんなり読めるようになろうと言ってるだけ
無理に使う?君が無理かどうかなんて知ったことじゃない
>>195
長期的って言うのがそういう期間を指しているのか知らんけど
デバッグも完璧に終わってリリースしてしばらくたった後、大型アップデート時に
ってことならまだ分かるけど、今どきは毎日小変更デプロイでしょ
そういう体制だと将来的に困ったら丸ごとすげ替えればいいっていうのは通用しない
複雑なものを放置しとくと、実際困ること必至
それがJSerの考え方の面白い特徴だとか、古すぎぃ
200デフォルトの名無しさん
2018/10/27(土) 22:03:11.76ID:QlllhdpS >>198
それ、reduceでできるよね。わざわざforを使って本質的でない一時変数をいじくりたい理由とは?w
reduceなんて何年も前から使える。es2015ですらない。
文法にしか目に行ってないのは君自身のことだね。悪いけど一緒にしないでもらえる?
君はどこまでも自分本意な考えで、自分の知らない文法=新文法、自分の知らない文法を他人が使うのがとにかく気に入らない、これに尽きる。これに後付けで理屈をくっつけているだけ。
それ、reduceでできるよね。わざわざforを使って本質的でない一時変数をいじくりたい理由とは?w
reduceなんて何年も前から使える。es2015ですらない。
文法にしか目に行ってないのは君自身のことだね。悪いけど一緒にしないでもらえる?
君はどこまでも自分本意な考えで、自分の知らない文法=新文法、自分の知らない文法を他人が使うのがとにかく気に入らない、これに尽きる。これに後付けで理屈をくっつけているだけ。
201デフォルトの名無しさん
2018/10/27(土) 22:06:02.65ID:8fc2vBvs >>199
> こういう使い方もできる、こうも書かれることもある
この必要がないんだよ。むしろ、してはいけない。
それが分からないのは君が『長期的』メンテナンスしたことがないからだね。
> 長期的って言うのがそういう期間を指しているのか知らんけど
CやJavaの世界では20〜30年以上だね。
そして「コードメトリクス」はそれを前提としてるから、JavaScriptにそれを適用するのも無理がある。
> こういう使い方もできる、こうも書かれることもある
この必要がないんだよ。むしろ、してはいけない。
それが分からないのは君が『長期的』メンテナンスしたことがないからだね。
> 長期的って言うのがそういう期間を指しているのか知らんけど
CやJavaの世界では20〜30年以上だね。
そして「コードメトリクス」はそれを前提としてるから、JavaScriptにそれを適用するのも無理がある。
202デフォルトの名無しさん
2018/10/27(土) 22:11:25.90ID:61pv23m7 >>197
君は本当によくわかってる。正に君の言う通り。
自分はJavaScriptを道具だとは思っていない。
もちろん君の定義も分かる
でも曖昧で幅広すぎるでしょ?
ここはWeb制作板じゃないというのもあるし
なんだかんだ言ってもやっぱり今回は文法の問題だったので
文法レベルで言わせてもらった
ってわけでもない
自分が中級者と言って想定したのは「右も左も分からない段階を抜けてそこそこ使えてきた段階」
つまり、とにかく基準は何にせよ俺は初級者は抜けられたぞ!って思ってるような人に
そこで満足してほしくないからちょっと意地悪で大げさに発破かけただけ
皆どちらかと言うと君の基準だろうから、そこはわかった上であえて文法面をぶつけてみただけ
すまんね、自分バランス取るのが好きなひねくれ者だから
君は本当によくわかってる。正に君の言う通り。
自分はJavaScriptを道具だとは思っていない。
もちろん君の定義も分かる
でも曖昧で幅広すぎるでしょ?
ここはWeb制作板じゃないというのもあるし
なんだかんだ言ってもやっぱり今回は文法の問題だったので
文法レベルで言わせてもらった
ってわけでもない
自分が中級者と言って想定したのは「右も左も分からない段階を抜けてそこそこ使えてきた段階」
つまり、とにかく基準は何にせよ俺は初級者は抜けられたぞ!って思ってるような人に
そこで満足してほしくないからちょっと意地悪で大げさに発破かけただけ
皆どちらかと言うと君の基準だろうから、そこはわかった上であえて文法面をぶつけてみただけ
すまんね、自分バランス取るのが好きなひねくれ者だから
203デフォルトの名無しさん
2018/10/27(土) 22:12:49.28ID:8fc2vBvs >>200
> 本質的でない一時変数をいじくりたい理由とは?w
ああ、そっちの宗教の人か。
まあ、流儀があってやっているのならいい。
それで君にとって「読みやすくなる」のならそれもありだ。
ただ、reduceを知らないってことは無いし、それで読みやすくなるって事もないけどね。
関数型()の奴は1行にこだわるが、
関数間のいわゆるコードメトリクス上の「複雑さ」には無頓着なんだよ。君もね。
まあいいけど。
> 本質的でない一時変数をいじくりたい理由とは?w
ああ、そっちの宗教の人か。
まあ、流儀があってやっているのならいい。
それで君にとって「読みやすくなる」のならそれもありだ。
ただ、reduceを知らないってことは無いし、それで読みやすくなるって事もないけどね。
関数型()の奴は1行にこだわるが、
関数間のいわゆるコードメトリクス上の「複雑さ」には無頓着なんだよ。君もね。
まあいいけど。
204デフォルトの名無しさん
2018/10/27(土) 22:14:46.14ID:61pv23m7 すまんな
自分、盛り上げるのは好きだけど盛り上がってくるとどうでも良くなるんだ
もう寝るね
自分、盛り上げるのは好きだけど盛り上がってくるとどうでも良くなるんだ
もう寝るね
205デフォルトの名無しさん
2018/10/27(土) 22:35:14.88ID:j3pB/rFq206デフォルトの名無しさん
2018/10/27(土) 23:01:58.85ID:8fc2vBvs >>205
そう思うのは自由だが、実際に関数型()の連中はかなり宗教だぞ。
そして関数型()が成果を出せなかったのも事実だろ。
俺はforにこだわっているのではなく、単に見た目そのままの書き方にするだけ。
つまり、これまでの話なら、以下だね。
> var tmp=a;a=b;b=tmp;
> var o = {n1: 1, n2: 2, n3: 3, n4: 4, n5: 5};
当然、ループ回したいだけならforで回す。
無理にreduce使う意味はないんだよ。reduce使ってる俺カッケーがしたいだけ。
それもしたければすればいいのだけど、問題は、
オブジェクト指向的には「1ヶ所に集める」ことが必要なのだが、連中は、それを理解しておらず、
「1行で書ける!」と言ってそれをコード全体に散りばめてしまうこと。
それは仮に1行で書けたとしても関数として切り出さないと不味いんだよ。
(だからそれが仮に一時変数を使って3-5行必要だとしても、関係なくなる)
「長くなるから関数に切り出す」で、短いのだからそこに書いてしまえ、になってしまっている。
これは明確な間違いだ。
ここら辺は長期的メンテナンスをすれば分かるはずなのだが、
話が通じないところを見ると、彼等にはその経験がないんだよ。君もね。
まあいい、とにかく何でもいいから長期的にメンテナンスしてみろ。色々分かるから。
reduceはそもそも筋が悪いんだ。
配列を縮退させるメソッドなのだが、そもそも縮退させるような物は最初から配列にしない。
だから一時配列で便利に初期化、みたいな例ばかりな訳でさ。
なんであんな糞使えないメソッドが導入されたのかが俺には謎だ。
そう思うのは自由だが、実際に関数型()の連中はかなり宗教だぞ。
そして関数型()が成果を出せなかったのも事実だろ。
俺はforにこだわっているのではなく、単に見た目そのままの書き方にするだけ。
つまり、これまでの話なら、以下だね。
> var tmp=a;a=b;b=tmp;
> var o = {n1: 1, n2: 2, n3: 3, n4: 4, n5: 5};
当然、ループ回したいだけならforで回す。
無理にreduce使う意味はないんだよ。reduce使ってる俺カッケーがしたいだけ。
それもしたければすればいいのだけど、問題は、
オブジェクト指向的には「1ヶ所に集める」ことが必要なのだが、連中は、それを理解しておらず、
「1行で書ける!」と言ってそれをコード全体に散りばめてしまうこと。
それは仮に1行で書けたとしても関数として切り出さないと不味いんだよ。
(だからそれが仮に一時変数を使って3-5行必要だとしても、関係なくなる)
「長くなるから関数に切り出す」で、短いのだからそこに書いてしまえ、になってしまっている。
これは明確な間違いだ。
ここら辺は長期的メンテナンスをすれば分かるはずなのだが、
話が通じないところを見ると、彼等にはその経験がないんだよ。君もね。
まあいい、とにかく何でもいいから長期的にメンテナンスしてみろ。色々分かるから。
reduceはそもそも筋が悪いんだ。
配列を縮退させるメソッドなのだが、そもそも縮退させるような物は最初から配列にしない。
だから一時配列で便利に初期化、みたいな例ばかりな訳でさ。
なんであんな糞使えないメソッドが導入されたのかが俺には謎だ。
207デフォルトの名無しさん
2018/10/28(日) 00:03:50.77ID:iGBoWmbY >>206
やっぱ藁人形w
誰も一行で書けるからreduceがいいなどとは言ってない。
ましてや関数型至上主義者ならなおさらそのようなことは言わないだろう。
> なんであんな糞使えないメソッドが導入されたのかが俺には謎だ。
つまり、「俺に分からないreduceなんてみんなも使うべきじゃないんだ!」
ガキか。
やっぱ藁人形w
誰も一行で書けるからreduceがいいなどとは言ってない。
ましてや関数型至上主義者ならなおさらそのようなことは言わないだろう。
> なんであんな糞使えないメソッドが導入されたのかが俺には謎だ。
つまり、「俺に分からないreduceなんてみんなも使うべきじゃないんだ!」
ガキか。
208デフォルトの名無しさん
2018/10/28(日) 00:56:43.71ID:0+vzkOx8209デフォルトの名無しさん
2018/10/28(日) 01:27:41.86ID:iGBoWmbY 図星突いてなんかすまんなw
210デフォルトの名無しさん
2018/10/28(日) 01:42:20.06ID:0+vzkOx8211デフォルトの名無しさん
2018/10/28(日) 02:58:24.46ID:86INTnoC > 君にとって reduce が難しいからそう思えるのだろうけど、
自己紹介乙w
> reduceが分からない奴なんて居ない。使いどころがないだけだ。
はいはい。じゃ更新しといてやるよ。
「ボクが使いどころが分からないreduceなんて、みんなも使うべきじゃないんだ!」
ガキか。
使いどころで使ってんだよ。テメーが分からないからって強制してくんじゃねーぞクズ。
自己紹介乙w
> reduceが分からない奴なんて居ない。使いどころがないだけだ。
はいはい。じゃ更新しといてやるよ。
「ボクが使いどころが分からないreduceなんて、みんなも使うべきじゃないんだ!」
ガキか。
使いどころで使ってんだよ。テメーが分からないからって強制してくんじゃねーぞクズ。
212デフォルトの名無しさん
2018/10/28(日) 03:25:23.25ID:PnJQ4LJT213デフォルトの名無しさん
2018/10/28(日) 08:10:05.59ID:0+vzkOx8 >>211
だから、何度も言っているが、
× 使いどころが分からない
○ 使いどころがない
なんだよ。
結局、>>196も、『一時的に』配列として持たせてreduceしただけだろ。
最初からいきなり縮退させれば済むだけの話。
reduceは『配列として意味がある』(≒配列として『持つしかない』)物を縮退させるメソッドであって、
そもそもそのケースがJavaScriptの用途においてはほぼ無いんだよ。
そして他言語でもこのメソッド持ってないだろ。大して使えないからだよ。
>>212
俺の立場をはっきりさせた方がいいのか?なら、そちらと同じで、
・reduceを使ってもコードメトリクス的な「複雑度」については上がらない。(これが原因で『長期的に』読めなくなることはない)
・reduceは難しくはない。(これが原因で『短期的に』読めなくなることもない)
・使っているコードに遭遇しないのは、そもそも使いどころがないから。
・>>196はイキった馬鹿が無理に使う例だが、まあ、やりたければやればいい。大局的な問題にはならない。
だから、何度も言っているが、
× 使いどころが分からない
○ 使いどころがない
なんだよ。
結局、>>196も、『一時的に』配列として持たせてreduceしただけだろ。
最初からいきなり縮退させれば済むだけの話。
reduceは『配列として意味がある』(≒配列として『持つしかない』)物を縮退させるメソッドであって、
そもそもそのケースがJavaScriptの用途においてはほぼ無いんだよ。
そして他言語でもこのメソッド持ってないだろ。大して使えないからだよ。
>>212
俺の立場をはっきりさせた方がいいのか?なら、そちらと同じで、
・reduceを使ってもコードメトリクス的な「複雑度」については上がらない。(これが原因で『長期的に』読めなくなることはない)
・reduceは難しくはない。(これが原因で『短期的に』読めなくなることもない)
・使っているコードに遭遇しないのは、そもそも使いどころがないから。
・>>196はイキった馬鹿が無理に使う例だが、まあ、やりたければやればいい。大局的な問題にはならない。
214デフォルトの名無しさん
2018/10/28(日) 10:30:34.50ID:PnJQ4LJT > ○ 使いどころがない
使い所はあるだろう?
いや、開発効率とか考えずに、可能不可能だけの話をしたいなら
アセンブラでもできるから高級言語の使い所はないって話になるけど
使い所はあるだろう?
いや、開発効率とか考えずに、可能不可能だけの話をしたいなら
アセンブラでもできるから高級言語の使い所はないって話になるけど
215デフォルトの名無しさん
2018/10/28(日) 10:31:32.69ID:PnJQ4LJT > ・reduceを使ってもコードメトリクス的な「複雑度」については上がらない。(これが原因で『長期的に』読めなくなることはない)
条件分岐、ループが減るので、reduceを使うと複雑度は下がる
当然のことながら僕新人なんですみたいな
人間の問題の話はしない
条件分岐、ループが減るので、reduceを使うと複雑度は下がる
当然のことながら僕新人なんですみたいな
人間の問題の話はしない
216デフォルトの名無しさん
2018/10/28(日) 10:34:55.05ID:PnJQ4LJT reduceは初期状態があって、データの数だけ
状態を変更していくというパターンにすべて使える
例えば、初期状態が0で、配列の数値を加算していくとか
もちろん加算だけじゃなくて任意の計算ができるし
初期状態も数値ではなくて配列などでも良い
状態を変更していくというパターンにすべて使える
例えば、初期状態が0で、配列の数値を加算していくとか
もちろん加算だけじゃなくて任意の計算ができるし
初期状態も数値ではなくて配列などでも良い
217デフォルトの名無しさん
2018/10/28(日) 10:41:06.94ID:3WoixC+I reduceの問題は、reduceをしたくてreduceを使うのではなく
reduceを使って何かをする、というところにあると思う
後から又は他人がコードを読んだときに
何をしているのか、何のためにreduceを使用しているのかを
一旦考えないといけない
利便性はあると思うが
やりたいことそのものズバリを表している名前や動作ではない
というところが難点なのではなかろうか
reduceを使って何かをする、というところにあると思う
後から又は他人がコードを読んだときに
何をしているのか、何のためにreduceを使用しているのかを
一旦考えないといけない
利便性はあると思うが
やりたいことそのものズバリを表している名前や動作ではない
というところが難点なのではなかろうか
218デフォルトの名無しさん
2018/10/28(日) 10:45:25.52ID:PnJQ4LJT > 何をしているのか、何のためにreduceを使用しているのかを
> 一旦考えないといけない
forでも同じ。なんのためにループしているのか
一旦考えてる
> 一旦考えないといけない
forでも同じ。なんのためにループしているのか
一旦考えてる
219デフォルトの名無しさん
2018/10/28(日) 10:48:16.01ID:PnJQ4LJT reduceの場合(人間に問題がない場合)
その名前から「初期値になにかの計算を計上していってる」ってことまで
単語一つで分る
同じことをforでやろうとすると、forは繰り返しているだけ(何をしたいの?)
変数を見つける。その変数になにかの処理を行って、同じ変数に入れている
ここまでコードを読んで、あぁreduce相当の事をやっているんですねとわかる
reduceという単語一つでわかるのと、
コードを読んでいかないとわからない
この違いがある
その名前から「初期値になにかの計算を計上していってる」ってことまで
単語一つで分る
同じことをforでやろうとすると、forは繰り返しているだけ(何をしたいの?)
変数を見つける。その変数になにかの処理を行って、同じ変数に入れている
ここまでコードを読んで、あぁreduce相当の事をやっているんですねとわかる
reduceという単語一つでわかるのと、
コードを読んでいかないとわからない
この違いがある
220デフォルトの名無しさん
2018/10/28(日) 12:50:26.40ID:txWR8pSk クロームで見たとき5chで書き込むボタンを押したとき
ボタンを押す処理をする前に自分の考えた処理を付け加えたい場合
どのようなコードを書けばよろしいでしょうか?
もしよろしければ教えてくださいませ。
ボタンを押す処理をする前に自分の考えた処理を付け加えたい場合
どのようなコードを書けばよろしいでしょうか?
もしよろしければ教えてくださいませ。
221デフォルトの名無しさん
2018/10/28(日) 13:22:50.15ID:0+vzkOx8 >>217
同意だ。
>>216その他
言いたいことは分かるが、forの代わりにreduceを用いたところで大差ない。
reduceの場合も中身(関数)を読まなくてはならず、
そこが単純な関数なら、forで書いても単純だからだ。
結局は、
> reduceは初期状態があって、データの数だけ
> 状態を変更していくというパターンにすべて使える(216)
この汎用性を取った為、
> やりたいことそのものズバリを表している名前や動作ではない(217)
この問題が発生した、ということだ。
数値計算では average/sum/max/min 等のメソッドがarrayに欲しくなるが、
これらは reduce を用いて作れる。
ただ、これらを上位で reduce を用いて書くのは間違いで、
ラップしたメソッド array.average()等を使うべきだ。
だから直接使うのではなく、下位メソッドとして用意した、というのなら分かる。
問題は、JavaScriptで数値計算をすることはないので、この手の中位メソッドが思いつけないことと、
中位メソッド average() として分離した場合、中身がreduceでもforでもどうでもよくなることだ。
これらは所詮数行の関数であり、どっちでも大差ない。
よって、数値計算をする場合にも reduce 自体はあっても現実的にはほとんど意味がない。
そこでしか使わない特殊な縮退を書くときに便利、という程度だ。
reduceを使ってる俺カッケー馬鹿の問題は、reduceを使う為に、
average()を呼ぶべき所をreduceを使ってaverageを取ったりしてしまうことだ。
結果、余計に読むコードが増え、重複したコードが分散してしまう。
これはコードを書く側の問題だが、実際、この問題の方が大きいと思う。
同意だ。
>>216その他
言いたいことは分かるが、forの代わりにreduceを用いたところで大差ない。
reduceの場合も中身(関数)を読まなくてはならず、
そこが単純な関数なら、forで書いても単純だからだ。
結局は、
> reduceは初期状態があって、データの数だけ
> 状態を変更していくというパターンにすべて使える(216)
この汎用性を取った為、
> やりたいことそのものズバリを表している名前や動作ではない(217)
この問題が発生した、ということだ。
数値計算では average/sum/max/min 等のメソッドがarrayに欲しくなるが、
これらは reduce を用いて作れる。
ただ、これらを上位で reduce を用いて書くのは間違いで、
ラップしたメソッド array.average()等を使うべきだ。
だから直接使うのではなく、下位メソッドとして用意した、というのなら分かる。
問題は、JavaScriptで数値計算をすることはないので、この手の中位メソッドが思いつけないことと、
中位メソッド average() として分離した場合、中身がreduceでもforでもどうでもよくなることだ。
これらは所詮数行の関数であり、どっちでも大差ない。
よって、数値計算をする場合にも reduce 自体はあっても現実的にはほとんど意味がない。
そこでしか使わない特殊な縮退を書くときに便利、という程度だ。
reduceを使ってる俺カッケー馬鹿の問題は、reduceを使う為に、
average()を呼ぶべき所をreduceを使ってaverageを取ったりしてしまうことだ。
結果、余計に読むコードが増え、重複したコードが分散してしまう。
これはコードを書く側の問題だが、実際、この問題の方が大きいと思う。
222デフォルトの名無しさん
2018/10/28(日) 13:28:18.39ID:0+vzkOx8 >>220
onsubmit で間に合わなければ mousedown か mouseover とかで
onsubmit で間に合わなければ mousedown か mouseover とかで
223デフォルトの名無しさん
2018/10/28(日) 13:35:44.53ID:86INTnoC224デフォルトの名無しさん
2018/10/28(日) 13:48:12.72ID:0+vzkOx8225デフォルトの名無しさん
2018/10/28(日) 14:37:14.50ID:oeyLhtKk reduce禁止くん、「reduceは『配列として意味がある』物を縮退させるメソッドであって、そのケースがJavaScriptの用途においてはほぼ無い」って言ってるけど、これわざわざ配列使わずにやるの?w
フィルターの順番変えたり途中位置に追加したり削除したりクソめんどくさそうw
reduce禁止くんについてく人は配列も禁止だそうだけど頑張ってねw
でもJavaScriptの用途においてそんなケースほぼ無いそうだから大丈夫だよね!w
フィルターの順番変えたり途中位置に追加したり削除したりクソめんどくさそうw
reduce禁止くんについてく人は配列も禁止だそうだけど頑張ってねw
でもJavaScriptの用途においてそんなケースほぼ無いそうだから大丈夫だよね!w
226デフォルトの名無しさん
2018/10/28(日) 14:54:16.69ID:0+vzkOx8227デフォルトの名無しさん
2018/10/28(日) 15:17:49.97ID:WORMx28e >>220-222
「jquery event」「jquery preventdefault vs stoppropagation」で検索!
click は、要素をクリックする。
submit は、フォーム送信する
preventdefault は、イベントの既定の動作を、キャンセルする。
stoppropagation は、イベントの伝播を止める
JavaScript, jQuery の質問は、この板ではなく、web制作管理板へ書き込んで!
「jquery event」「jquery preventdefault vs stoppropagation」で検索!
click は、要素をクリックする。
submit は、フォーム送信する
preventdefault は、イベントの既定の動作を、キャンセルする。
stoppropagation は、イベントの伝播を止める
JavaScript, jQuery の質問は、この板ではなく、web制作管理板へ書き込んで!
228デフォルトの名無しさん
2018/10/28(日) 15:33:47.14ID:m8lElpnG 一番新しいプロジェクトでreduce何かに使ってたかなと思ったら
一つは空配列に必要なら追加していく形、
要は例えばmapだと同じ数の要素の配列しか返せないからその代わりにreduceを使っていたのと
もう一つは空オブジェクトを取って文字列の配列からオブジェクトにシンボルプロパティを生やしていく
っていうのに使ってた
一つは空配列に必要なら追加していく形、
要は例えばmapだと同じ数の要素の配列しか返せないからその代わりにreduceを使っていたのと
もう一つは空オブジェクトを取って文字列の配列からオブジェクトにシンボルプロパティを生やしていく
っていうのに使ってた
229デフォルトの名無しさん
2018/10/28(日) 16:11:54.33ID:0+vzkOx8230デフォルトの名無しさん
2018/10/28(日) 17:30:33.07ID:m8lElpnG filter+mapの方が良いとも限らないと思うよ
例えばAの場合はvalue.a、Bの場合はvalue.b、Cの場合はvalue.c、そうでなければ追加しないとすると
まずfilterで、AかBかCかというチェックを書いて
またmapでも篩分けしないといけないもの
reduceだといっぺんで済むでしょ
それと何箇所も使わないものをわざわざ関数に切り出しても何にも変わらないよ
例えばAの場合はvalue.a、Bの場合はvalue.b、Cの場合はvalue.c、そうでなければ追加しないとすると
まずfilterで、AかBかCかというチェックを書いて
またmapでも篩分けしないといけないもの
reduceだといっぺんで済むでしょ
それと何箇所も使わないものをわざわざ関数に切り出しても何にも変わらないよ
231デフォルトの名無しさん
2018/10/28(日) 17:35:32.63ID:m8lElpnG あとはDの場合はvalue.d1とvalued2の両方を追加するとかもできるね
というかそもそもfilter+mapの方が良かったら最初からそう書いてると思うけど
というかそもそもfilter+mapの方が良かったら最初からそう書いてると思うけど
232デフォルトの名無しさん
2018/10/28(日) 18:54:29.84ID:0+vzkOx8 >>230-231
reduceが効果的に使われているというのならそのURLを紹介してくれ。
reduceが効果的に使われているというのならそのURLを紹介してくれ。
233デフォルトの名無しさん
2018/10/28(日) 19:08:09.06ID:XoYPKH7l >>221
> reduceの場合も中身(関数)を読まなくてはならず、
> そこが単純な関数なら、forで書いても単純だからだ。
reduceはコードを読まなくても、初期状態から状態を変えていってるっていうのがわかる
forはただのループでしかなので、それがわからない
理解できた?
> reduceの場合も中身(関数)を読まなくてはならず、
> そこが単純な関数なら、forで書いても単純だからだ。
reduceはコードを読まなくても、初期状態から状態を変えていってるっていうのがわかる
forはただのループでしかなので、それがわからない
理解できた?
234デフォルトの名無しさん
2018/10/30(火) 23:54:50.26ID:3PWXbmS6 java
235デフォルトの名無しさん
2018/10/31(水) 00:48:19.13ID:6MB62ZHP ttp://black-flag.net/jquery/20131119-4881.html
このもっと見るボタンを押した時にだけ.jsonを読み込むサンプルなんだけど
.json形式で外部ファイル読み込むようにするんじゃなく本体のhtmlに組み込むにはどうやんの
このもっと見るボタンを押した時にだけ.jsonを読み込むサンプルなんだけど
.json形式で外部ファイル読み込むようにするんじゃなく本体のhtmlに組み込むにはどうやんの
236デフォルトの名無しさん
2018/10/31(水) 01:09:10.31ID:f1tmQgGe ググレカス
237デフォルトの名無しさん
2018/10/31(水) 02:59:19.61ID:QZT9zuHU このページには、やり方が書いてないだろ。
要素の挿入かな?
$("#parent").append("<p>あいう:<b>abc</b></p>");
jQuery などの質問は、この板よりも、web制作管理板へ書き込んで!
要素の挿入かな?
$("#parent").append("<p>あいう:<b>abc</b></p>");
jQuery などの質問は、この板よりも、web制作管理板へ書き込んで!
238デフォルトの名無しさん
2018/10/31(水) 15:10:14.27ID:PW3C3AfV239237
2018/11/01(木) 00:45:15.87ID:PBz6MbCm jQuery も知らんの?
$( ) は、jQuery関数
#parent の# は、id を表す。
<div id="parent"></div>
HTML, CSS, JavaScript, jQueryの、初心者用の本でも読んで、勉強して
$( ) は、jQuery関数
#parent の# は、id を表す。
<div id="parent"></div>
HTML, CSS, JavaScript, jQueryの、初心者用の本でも読んで、勉強して
240デフォルトの名無しさん
2018/11/01(木) 03:20:19.15ID:1A1KjHiV jQuery は読まなくていいよ
241デフォルトの名無しさん
2018/11/01(木) 08:31:05.31ID:gbrxGQSq Electornってブラウザで動くのにnode.jsなんですか?
初心者すぎてその辺よくわからん
初心者すぎてその辺よくわからん
242デフォルトの名無しさん
2018/11/01(木) 08:52:13.83ID:+p1vRE32 いいえV8です
243デフォルトの名無しさん
2018/11/01(木) 09:04:59.81ID:PBz6MbCm node.js は、普通のプログラム言語と同じで、ローカルPC のファイルにアクセスできる。
だから、node.js を使っているElectron は、VSCode を作った
VSCodeは、普通のIDE と同じ。
ただ、JavaScript で作られただけ
だから、node.js を使っているElectron は、VSCode を作った
VSCodeは、普通のIDE と同じ。
ただ、JavaScript で作られただけ
244デフォルトの名無しさん
2018/11/01(木) 13:23:12.38ID:7uO+0a7Q じゃあnodeはローカルにもブラウザにもアクセスできるってこと?
245デフォルトの名無しさん
2018/11/01(木) 20:22:01.79ID:PBz6MbCm VSCode は、Electron で作られている普通のIDE。
ローカルPC のファイルにアクセスできる
Electron は、node.js + ブラウザのChromium。
画面は、HTML, CSS, JavaScript で作って、ブラウザで表示している
ほとんどの言語の開発で、VSCode を使う
漏れは、Ruby から、Selenium WebDriver を使って、ブラウザを自動操作している
Rubyで、ローカルPCの画像ファイルにアクセスして、
HTML, CSS, JavaScript で画面を作って、画像をブラウザで表示している
言語が異なっても、基本的な仕組みは同じ
ローカルPC のファイルにアクセスできる
Electron は、node.js + ブラウザのChromium。
画面は、HTML, CSS, JavaScript で作って、ブラウザで表示している
ほとんどの言語の開発で、VSCode を使う
漏れは、Ruby から、Selenium WebDriver を使って、ブラウザを自動操作している
Rubyで、ローカルPCの画像ファイルにアクセスして、
HTML, CSS, JavaScript で画面を作って、画像をブラウザで表示している
言語が異なっても、基本的な仕組みは同じ
246デフォルトの名無しさん
2018/11/02(金) 12:33:09.51ID:cO1fXqzs ブラウザの拡張機能やアプリと同じだよ
普通のUIはChromiumで普通のWebページ側のメインプロセス、
それとNodeのバックグラウンドプロセスが通信でやり取りする形
ただその通信が幾らか隠蔽されてるのでメインプロセスからでも特権的なAPIが自然と使える
普通のUIはChromiumで普通のWebページ側のメインプロセス、
それとNodeのバックグラウンドプロセスが通信でやり取りする形
ただその通信が幾らか隠蔽されてるのでメインプロセスからでも特権的なAPIが自然と使える
247デフォルトの名無しさん
2018/11/04(日) 21:51:54.73ID:OZGwMP5b 7..toString(2)の..って何ですか?
248デフォルトの名無しさん
2018/11/04(日) 22:10:06.82ID:8k2w1dNt >>247
小数点とプロパティアクセサ
小数点とプロパティアクセサ
249デフォルトの名無しさん
2018/11/04(日) 22:22:36.06ID:eCImE5iu >>248
なるほど
7.toString()だと
SyntaxError: identifier starts immediately after numeric literal
7が数字から始まる不正な変数名だと認識されるという理解でよろしいか?
なるほど
7.toString()だと
SyntaxError: identifier starts immediately after numeric literal
7が数字から始まる不正な変数名だと認識されるという理解でよろしいか?
250デフォルトの名無しさん
2018/11/04(日) 22:32:31.49ID:Yqdp3OyY 中学英語も出来ないのかよ…
識別子が数値リテラルの直後から始まってます
識別子が数値リテラルの直後から始まってます
251デフォルトの名無しさん
2018/11/04(日) 22:34:19.63ID:Yqdp3OyY 7は数値リテラルと認識されてるんで変数名と認識されてるわけではない
252デフォルトの名無しさん
2018/11/04(日) 22:35:32.03ID:omq6KmHr253デフォルトの名無しさん
2018/11/04(日) 22:44:48.73ID:Nn4ZdlZB >>250
identifierは中学で習う英単語には出てこないが?
http://www.eigo-duke.com/tango/tangoindex.html
高2でようやくidentifyがでてくる
immediatelyは高1。numericもliteralも高校でも出てこない
identifierは中学で習う英単語には出てこないが?
http://www.eigo-duke.com/tango/tangoindex.html
高2でようやくidentifyがでてくる
immediatelyは高1。numericもliteralも高校でも出てこない
254デフォルトの名無しさん
2018/11/04(日) 22:47:52.87ID:ILD/0n4M 7..toString(2)
(7.).toString(2)
(7.0).toString(2)
どれでも文字列の、'111' と表示される
(7.0)
(7.)
7.
どれでも数値型の、7 と表示される
(7.).toString(2)
(7.0).toString(2)
どれでも文字列の、'111' と表示される
(7.0)
(7.)
7.
どれでも数値型の、7 と表示される
255デフォルトの名無しさん
2018/11/04(日) 23:00:03.48ID:Nn4ZdlZB な、なな、なんと!?
256デフォルトの名無しさん
2018/11/05(月) 06:30:57.02ID:Q73fn8MU 7.0toString()
とできないように
7.toString()
とできないということ
とできないように
7.toString()
とできないということ
257デフォルトの名無しさん
2018/11/05(月) 11:56:57.88ID:R68h5DCa name="form1" の form を参照するのに document.form1 って書き方があるけど、これがうまくいかないケースがあったので理由が知りたい。
自分のページは mydomain にあり、外のドメイン extdomain のJSライブラリを使ってる。
そのJSライブラリはAJAXを使って extdomain の中で処理を行ない、完了後にコールバックしてくれる。
mydomain のページ中 form1 が submit されるイベントでこんな感じでライブラリを呼び出し、コールバックまで処理が来てる。
function smtForm1()
{
:
外部ライブラリ(smtForm1Callback);
return false;
}
function smtForm1Callback()
{
var f = document.form1;
:
}
このコールバックの中で form1 を参照したいんだけど、上記のコードだと f は undefined になる。
form1 に id="form1" も加えて document.getEementById("form1") とやると参照できたものの、document.form1 じゃダメな理由が分からない。
実は同じコードが同じ外部ライブラリ使って同じブラウザで動く環境もあるから、サーバのセキュリティがらみの設定の問題のような気がしながらもよく分からずにいる。
原因とかチェックポイントとかアドバイスください。
自分のページは mydomain にあり、外のドメイン extdomain のJSライブラリを使ってる。
そのJSライブラリはAJAXを使って extdomain の中で処理を行ない、完了後にコールバックしてくれる。
mydomain のページ中 form1 が submit されるイベントでこんな感じでライブラリを呼び出し、コールバックまで処理が来てる。
function smtForm1()
{
:
外部ライブラリ(smtForm1Callback);
return false;
}
function smtForm1Callback()
{
var f = document.form1;
:
}
このコールバックの中で form1 を参照したいんだけど、上記のコードだと f は undefined になる。
form1 に id="form1" も加えて document.getEementById("form1") とやると参照できたものの、document.form1 じゃダメな理由が分からない。
実は同じコードが同じ外部ライブラリ使って同じブラウザで動く環境もあるから、サーバのセキュリティがらみの設定の問題のような気がしながらもよく分からずにいる。
原因とかチェックポイントとかアドバイスください。
258デフォルトの名無しさん
2018/11/05(月) 12:10:08.11ID:9r10P92V 呼び出し元はどう本体呼び出してんの?
スタックトレース見てみたら?
スタックトレース見てみたら?
259デフォルトの名無しさん
2018/11/05(月) 13:12:30.96ID:A6aiMvMs もしかして
document.forms.form1
document.forms.form1
260デフォルトの名無しさん
2018/11/05(月) 22:57:46.85ID:i/g7f+lV 「js document」で検索!
Document
https://developer.mozilla.org/ja/docs/Web/API/document
document は、DOM ツリー のエントリーポイント。
document.write などが有名
自作のフォーム名などが、document のメソッド名になる事はない。
document のメソッド名は、あらかじめ決まっているから
Document
https://developer.mozilla.org/ja/docs/Web/API/document
document は、DOM ツリー のエントリーポイント。
document.write などが有名
自作のフォーム名などが、document のメソッド名になる事はない。
document のメソッド名は、あらかじめ決まっているから
261257
2018/11/05(月) 23:16:36.71ID:R68h5DCa >>258
どうやら外部ライブラリは body の中に scriptタグを作り出し、そこでロードされるスクリプトにコールバックを呼び出すだけのコードが書かれてるらしい。
だからグローバルスコープからのコールバック呼び出しかな。
この scriptタグの生成によって document の再構築でも起こって、まだ form1 が取り込まれてない状態になってるとかかな?
>>259
いや、普通は document.form1 で参照できてる。
>>260
メソッドじゃなくプロパティじゃないかな。
document 直下にフォームの name のプロパティが出来上がる。
という動作はブラウザでJavaScriptが盛り込まれた頃からの仕様だと思ってたけど、非推薦かなんかになってたりする?
どうやら外部ライブラリは body の中に scriptタグを作り出し、そこでロードされるスクリプトにコールバックを呼び出すだけのコードが書かれてるらしい。
だからグローバルスコープからのコールバック呼び出しかな。
この scriptタグの生成によって document の再構築でも起こって、まだ form1 が取り込まれてない状態になってるとかかな?
>>259
いや、普通は document.form1 で参照できてる。
>>260
メソッドじゃなくプロパティじゃないかな。
document 直下にフォームの name のプロパティが出来上がる。
という動作はブラウザでJavaScriptが盛り込まれた頃からの仕様だと思ってたけど、非推薦かなんかになってたりする?
262デフォルトの名無しさん
2018/11/06(火) 01:27:51.27ID:bRR/Nar/ >>261
仕様ならMDNなり仕様書なりに載ってるはずだから、とりあえず探してみれば?
それ以前にまともな奴ならそんな物使わないが。
nameは重複許可だから、それは仕様バグであり、使い物にならない。
仮に仕様であったとしても、削除/変更されるのは時間の問題だ。地雷臭が酷すぎる。
お前も含めてJavaScripterは全員馬鹿だからここら辺を理解出来ないようだけど。
仕様ならMDNなり仕様書なりに載ってるはずだから、とりあえず探してみれば?
それ以前にまともな奴ならそんな物使わないが。
nameは重複許可だから、それは仕様バグであり、使い物にならない。
仮に仕様であったとしても、削除/変更されるのは時間の問題だ。地雷臭が酷すぎる。
お前も含めてJavaScripterは全員馬鹿だからここら辺を理解出来ないようだけど。
263デフォルトの名無しさん
2018/11/06(火) 07:04:44.97ID:A8Uqo2gA nameが何にためにあるのかを知っていれば
重複可なのが当たり前でそのformを1つだけ参照するものがあっても
常識の範囲で有意義に使えることが分かる
まあ馬鹿にはわからないだろうが
重複可なのが当たり前でそのformを1つだけ参照するものがあっても
常識の範囲で有意義に使えることが分かる
まあ馬鹿にはわからないだろうが
264デフォルトの名無しさん
2018/11/06(火) 09:04:41.69ID:9jHKU1L0 同じ名前の人が二人いるとかおかしいじゃないですか
265デフォルトの名無しさん
2018/11/06(火) 09:46:57.23ID:bRR/Nar/ >>263
唯一性をユーザー側で保証出来るのならid使え、ってことになってるだろ。
旧API(のつもり?)を使用し続けるのなら、それが今どういう状況になっているのか、自分で把握しておく必要がある。
そんな質問している時点でアウトでしょ。
とりあえず仕様書やMDNを漁って、「今でも使えるものか」確認しないと駄目だと思うよ。
ただそれ以前に、それが仕様であったとしても、動かないんなら意味無いけど。
(お前が「仕様だ!俺は悪くない!」とごねたところでコードが動くようにはならない)
大体、document.forms.xxx ならさておき、ドキュメント直下 document.xxx は不味いとすぐ分かるだろ。
それが仕様であったなら、早々に非推奨になって削除されるべきだし、実際多分そうなんだろ。
仕様がどんどん改訂されるプラットフォームなのだから、良くも悪くもトレンドに沿ってないと駄目なんだよ。
それだって、idで参照するようにしていれば、最初からそんな疑問すらわかないわけでさ。
仕様だから使える!と思ってる時点で馬鹿確定なんだよ。
お前も含めて、JavaSripterはコードを書き捨てばかりしているから、大局観が全く育ってない。
動かないから書き直す、ではなく、
何故書き直す羽目になったのか、どう書いていれば書き直さずに済んだのか、それを考える癖を付けた方がいい。
繰り返すが、それ、id/classで参照する今風のコードなら、問題すら発生しなかったわけでしょ。
お前ら、マッチポンプをしていることにすら気づいてないだろ。
唯一性をユーザー側で保証出来るのならid使え、ってことになってるだろ。
旧API(のつもり?)を使用し続けるのなら、それが今どういう状況になっているのか、自分で把握しておく必要がある。
そんな質問している時点でアウトでしょ。
とりあえず仕様書やMDNを漁って、「今でも使えるものか」確認しないと駄目だと思うよ。
ただそれ以前に、それが仕様であったとしても、動かないんなら意味無いけど。
(お前が「仕様だ!俺は悪くない!」とごねたところでコードが動くようにはならない)
大体、document.forms.xxx ならさておき、ドキュメント直下 document.xxx は不味いとすぐ分かるだろ。
それが仕様であったなら、早々に非推奨になって削除されるべきだし、実際多分そうなんだろ。
仕様がどんどん改訂されるプラットフォームなのだから、良くも悪くもトレンドに沿ってないと駄目なんだよ。
それだって、idで参照するようにしていれば、最初からそんな疑問すらわかないわけでさ。
仕様だから使える!と思ってる時点で馬鹿確定なんだよ。
お前も含めて、JavaSripterはコードを書き捨てばかりしているから、大局観が全く育ってない。
動かないから書き直す、ではなく、
何故書き直す羽目になったのか、どう書いていれば書き直さずに済んだのか、それを考える癖を付けた方がいい。
繰り返すが、それ、id/classで参照する今風のコードなら、問題すら発生しなかったわけでしょ。
お前ら、マッチポンプをしていることにすら気づいてないだろ。
266デフォルトの名無しさん
2018/11/06(火) 09:47:16.32ID:WbDKfplt267257
2018/11/06(火) 10:49:05.82ID:2Hp5KyS3 >>266
英語読みきれてなかったらスマンだけど、それはアプリケーションサーバの設定の問題でローカル開発環境では form の name が出力されてなかったってことかな?
であればちょっと違うかも。
>>265
言わんとしてることはよく分かるよ。
でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
どうやってもその書き方じゃ動かないという話なら、機能として削除されたんだろうとも思うわけ。
>>257 の例だと、コールバックじゃないところでの例えば smtForm1内での document.form1 は問題無いし、それどころか同じものを別サーバへ設置するとコールバックの中でも動いたりする。
同じブラウザで。サーバはどっちも同じ apache で。ブラウザに渡ってる HTML も全く同一で。
しかしブラウザ依存でもないようで、動かない時はどのブラウザでも同じように動かない。
だからクロスドメイン周りの設定に差があるのかとサーバからの HTTPヘッダを比較してもこれと言った差も無いようで、よくわからんって話さ。
ただこのページに仕込んである他のJSの挙動が置くサーバによって違ってるのかもしれない。ページが安定した後の document に影響があるようなことは無いだろうと思って言わなくて悪かったけど。
ちなみに他のJSってアクセス解析の類い。
んじゃそれ外して試せばいいじゃんとなるだろうけど、いつか確かめるけど事情により今すぐは難しい。
といった感じで実用面では他のより良い手段でやればいいことなので問題があるわけじゃないんだけど、理由は知っておきたいという話。
どこでハマるか分からんし。
英語読みきれてなかったらスマンだけど、それはアプリケーションサーバの設定の問題でローカル開発環境では form の name が出力されてなかったってことかな?
であればちょっと違うかも。
>>265
言わんとしてることはよく分かるよ。
でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
どうやってもその書き方じゃ動かないという話なら、機能として削除されたんだろうとも思うわけ。
>>257 の例だと、コールバックじゃないところでの例えば smtForm1内での document.form1 は問題無いし、それどころか同じものを別サーバへ設置するとコールバックの中でも動いたりする。
同じブラウザで。サーバはどっちも同じ apache で。ブラウザに渡ってる HTML も全く同一で。
しかしブラウザ依存でもないようで、動かない時はどのブラウザでも同じように動かない。
だからクロスドメイン周りの設定に差があるのかとサーバからの HTTPヘッダを比較してもこれと言った差も無いようで、よくわからんって話さ。
ただこのページに仕込んである他のJSの挙動が置くサーバによって違ってるのかもしれない。ページが安定した後の document に影響があるようなことは無いだろうと思って言わなくて悪かったけど。
ちなみに他のJSってアクセス解析の類い。
んじゃそれ外して試せばいいじゃんとなるだろうけど、いつか確かめるけど事情により今すぐは難しい。
といった感じで実用面では他のより良い手段でやればいいことなので問題があるわけじゃないんだけど、理由は知っておきたいという話。
どこでハマるか分からんし。
268デフォルトの名無しさん
2018/11/06(火) 11:11:11.71ID:9jHKU1L0 > どこでハマるか分からんし。
だからみんなjQuery使うんだよ
だからみんなjQuery使うんだよ
269デフォルトの名無しさん
2018/11/06(火) 11:21:39.49ID:4sD8op2P もう誰もjQueryなんて使ってない
270デフォルトの名無しさん
2018/11/06(火) 11:53:23.90ID:bRR/Nar/ >>267
> 同じコードが動いたり動かなかったりするからなんでって聞いてるの
それはそうだから、でしかないだろ。
まず、今現在「仕様」かどうか確認しろよ。
それで「仕様」でないのなら、それは偶々動いていただけであって、それだけでしかない。
ブラウザは大幅に更新されてる。
元々それを動かすコードをブラウザが持っていたとして、
仕様から外れた時点でそれをどこで落とすかはブラウザ開発者の自由だし、
結果的に一部残っていて動いたり動かなかったりするのも問題なしだ。
そしてそうなってるだけだろ。
「仕様」でなければ何の不思議もないし、「仕様」であればバグ報告すればいいだけだろ。
そしてその範囲を知る意味もない。
ありがちなパターンとしては、「古いコードもある程度までは動くようにする」為に、
初期構築(最初の構築)だけはそのコードを通し(つまり旧来方法でのアクセスも可能)、
追加で動的構築したDOMについては追跡してない(つまり旧来方法でのアクセスは不可能)といったところか。
ただこれを知ったところで、いつ変更されるかも分からんし、意味無いだろ。
> どこでハマるか分からんし。
「仕様」かどうかはさておき、「みんな」が「今」使ってない方法を使ったら駄目、ってことでしかないだろ。
そういったコードは、必要に応じて書き換えて「今」のトレンドに乗るようにするか、
jQueryみたいに「バージョン○○では…」と自前で管理しきるしかない。
どっちもする気がないのなら、それはお前の問題だ。
初心者にありがちな、全て「仕様」で確定している、という勘違いなら、頭を切り換えた方がいい。
厳密に仕様準拠なら、「必ずundefinedが返る」のが正しいが、
JavaScript界隈はそういう厳密さより、上記のように旧来コードも動くような曖昧さを残した方が好まれる。
結果、今の君のように、「ある日突然コードが動かなくなって???、環境依存???」な事も発生し、
それが長期的に生産性を下げる要因になっているのも事実だが。
> 同じコードが動いたり動かなかったりするからなんでって聞いてるの
それはそうだから、でしかないだろ。
まず、今現在「仕様」かどうか確認しろよ。
それで「仕様」でないのなら、それは偶々動いていただけであって、それだけでしかない。
ブラウザは大幅に更新されてる。
元々それを動かすコードをブラウザが持っていたとして、
仕様から外れた時点でそれをどこで落とすかはブラウザ開発者の自由だし、
結果的に一部残っていて動いたり動かなかったりするのも問題なしだ。
そしてそうなってるだけだろ。
「仕様」でなければ何の不思議もないし、「仕様」であればバグ報告すればいいだけだろ。
そしてその範囲を知る意味もない。
ありがちなパターンとしては、「古いコードもある程度までは動くようにする」為に、
初期構築(最初の構築)だけはそのコードを通し(つまり旧来方法でのアクセスも可能)、
追加で動的構築したDOMについては追跡してない(つまり旧来方法でのアクセスは不可能)といったところか。
ただこれを知ったところで、いつ変更されるかも分からんし、意味無いだろ。
> どこでハマるか分からんし。
「仕様」かどうかはさておき、「みんな」が「今」使ってない方法を使ったら駄目、ってことでしかないだろ。
そういったコードは、必要に応じて書き換えて「今」のトレンドに乗るようにするか、
jQueryみたいに「バージョン○○では…」と自前で管理しきるしかない。
どっちもする気がないのなら、それはお前の問題だ。
初心者にありがちな、全て「仕様」で確定している、という勘違いなら、頭を切り換えた方がいい。
厳密に仕様準拠なら、「必ずundefinedが返る」のが正しいが、
JavaScript界隈はそういう厳密さより、上記のように旧来コードも動くような曖昧さを残した方が好まれる。
結果、今の君のように、「ある日突然コードが動かなくなって???、環境依存???」な事も発生し、
それが長期的に生産性を下げる要因になっているのも事実だが。
271デフォルトの名無しさん
2018/11/06(火) 12:09:12.29ID:5TKL1Nze >>267
> でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
グローバル変数に関する規定はあるが、documentは分からん
納得できるまで、自分で調べてくれ
https://momdo.github.io/html/window-object.html#named-access-on-the-window-object
https://momdo.github.io/html/dom.html#the-document-object
あと、それを使うと決めたあなたの判断基準が分からん
> でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
グローバル変数に関する規定はあるが、documentは分からん
納得できるまで、自分で調べてくれ
https://momdo.github.io/html/window-object.html#named-access-on-the-window-object
https://momdo.github.io/html/dom.html#the-document-object
あと、それを使うと決めたあなたの判断基準が分からん
272デフォルトの名無しさん
2018/11/06(火) 13:49:56.96ID:9jHKU1L0 >>269
> もう誰もjQueryなんて使ってない
いちいち嘘つくなよ。どうせ俺がバラすんだから逆効果にしかならんぞw
https://w3techs.com/technologies/overview/javascript_library/all
w3techsによると2017年1月の時点で71.9%のサイトがJavaScriptのライブラリとして
jQueryを使用していることが判明し、それ以降もシェアの増加が続いていたが、
2018年4月〜2018年10月の約半年間で変化が見られず、ようやく73.3%〜73.4%で
増加が停止したようである。
しかしながら、減少の傾向は見られず、マーケットシェア(JavaScriptを使用しているサイトでの使用率)
https://w3techs.com/technologies/history_overview/javascript_library は97.2%を
示していることから、jQueryからの移行が始まったと言うより、上げ止まりであると考えられる
jQuery以外では、この1年でBootstrapが2%程度、Underscoreが1%程度増加している以外は
ほとんど変動はなく、期待されていたAngularは過去最高の0.5%から0.1%減少した0.4%に、
Reactは過去最高の0.6%から0.5%と大きく減少し、0.1%に下がっていることが判明した。
またいずれのライブラリも使用していないサイトは24.5%で
2017年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか?この先の動向が注目される
> もう誰もjQueryなんて使ってない
いちいち嘘つくなよ。どうせ俺がバラすんだから逆効果にしかならんぞw
https://w3techs.com/technologies/overview/javascript_library/all
w3techsによると2017年1月の時点で71.9%のサイトがJavaScriptのライブラリとして
jQueryを使用していることが判明し、それ以降もシェアの増加が続いていたが、
2018年4月〜2018年10月の約半年間で変化が見られず、ようやく73.3%〜73.4%で
増加が停止したようである。
しかしながら、減少の傾向は見られず、マーケットシェア(JavaScriptを使用しているサイトでの使用率)
https://w3techs.com/technologies/history_overview/javascript_library は97.2%を
示していることから、jQueryからの移行が始まったと言うより、上げ止まりであると考えられる
jQuery以外では、この1年でBootstrapが2%程度、Underscoreが1%程度増加している以外は
ほとんど変動はなく、期待されていたAngularは過去最高の0.5%から0.1%減少した0.4%に、
Reactは過去最高の0.6%から0.5%と大きく減少し、0.1%に下がっていることが判明した。
またいずれのライブラリも使用していないサイトは24.5%で
2017年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか?この先の動向が注目される
273デフォルトの名無しさん
2018/11/06(火) 14:36:25.99ID:Fd8yf0Li 前線の開発者が新規にwebアプリ作る時はもう使わんというだけで
全体から見たらそんなのごくごく希少さね
全体から見たらそんなのごくごく希少さね
274デフォルトの名無しさん
2018/11/06(火) 14:42:55.62ID:9jHKU1L0 Angularが減ったのはまだ誤差の範囲内だと思うけど
Reactがこんなに減ったのはなんでだろうな
Reactがこんなに減ったのはなんでだろうな
275デフォルトの名無しさん
2018/11/06(火) 14:44:59.13ID:4sD8op2P 保守ではjQueryあるけど新規は全くない
俺なところはほぼAngular
最近はJAVA有料化の流れのおかげでnodejsも上げてきてる
俺なところはほぼAngular
最近はJAVA有料化の流れのおかげでnodejsも上げてきてる
276デフォルトの名無しさん
2018/11/06(火) 14:56:30.64ID:9jHKU1L0 そもそも新規の仕事ってのがないってだけなので、
jQueryがまったくないという言い方はおかしい
同様にAngularやReactを使うこともないんだから
新規の仕事が無いのでね
たいていは過去やったことの続きか、
別の客に同じようなものを提供するので
そこで使われてるjQueryがそのまま使われる
jQueryがまったくないという言い方はおかしい
同様にAngularやReactを使うこともないんだから
新規の仕事が無いのでね
たいていは過去やったことの続きか、
別の客に同じようなものを提供するので
そこで使われてるjQueryがそのまま使われる
277デフォルトの名無しさん
2018/11/06(火) 20:15:00.55ID:ObpCKggA >>264
全国の鈴木一郎に謝れ!
全国の鈴木一郎に謝れ!
278デフォルトの名無しさん
2018/11/06(火) 20:34:37.04ID:A8Uqo2gA ここまで探せば1分で見つかる仕様提示 無し
https://html.spec.whatwg.org/multipage/dom.html#dom-document-nameditem
https://html.spec.whatwg.org/multipage/dom.html#dom-document-nameditem
279デフォルトの名無しさん
2018/11/06(火) 22:25:14.22ID:8rUvp8iU280デフォルトの名無しさん
2018/11/06(火) 22:53:30.78ID:9jHKU1L0 とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
281デフォルトの名無しさん
2018/11/06(火) 23:01:46.77ID:bRR/Nar/282デフォルトの名無しさん
2018/11/06(火) 23:08:25.32ID:9jHKU1L0 自演ではないね。
そういう事がありましたってことだよ
起こったことはちゃんと書かないとw
そういう事がありましたってことだよ
起こったことはちゃんと書かないとw
283デフォルトの名無しさん
2018/11/06(火) 23:13:35.68ID:bRR/Nar/284デフォルトの名無しさん
2018/11/06(火) 23:29:44.69ID:9jHKU1L0285デフォルトの名無しさん
2018/11/06(火) 23:44:03.25ID:bRR/Nar/286デフォルトの名無しさん
2018/11/07(水) 00:45:22.01ID:UCphLCxy >>285
流行り通じてねぇw
「
とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
」
ということが、起こったんですよ。彼の現場ではね!
って話だろうがw
流行り通じてねぇw
「
とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
」
ということが、起こったんですよ。彼の現場ではね!
って話だろうがw
287デフォルトの名無しさん
2018/11/07(水) 00:45:39.54ID:UCphLCxy × 流行り通じてねぇw
○ はやり通じてねぇw
○ はやり通じてねぇw
288デフォルトの名無しさん
2018/11/07(水) 05:11:53.04ID:tcZfPZ7D +new Date()の+って何ですか?
289デフォルトの名無しさん
2018/11/07(水) 06:48:51.19ID:2P8ub5kW >>280
ブラウザはOSやグラフィックドライバなどのバグにきちんと対処してるぞ
ブラウザはOSやグラフィックドライバなどのバグにきちんと対処してるぞ
290デフォルトの名無しさん
2018/11/07(水) 06:50:32.64ID:2P8ub5kW >>288
+-のプラス 単項演算子
+-のプラス 単項演算子
291デフォルトの名無しさん
2018/11/07(水) 07:32:08.33ID:+978RLDn >>267
>別サーバへ設置するとコールバックの中でも動いたりする
実行環境が異なると、使っているライブラリも変わる
それと一般的には、動いたり動かなかったりするのは、非同期処理を勘違いしているとか。
promise とかで、ちゃんと解決してない
処理A, B の順番では動くけど、B, A の順番では動かないとか
1回目は、ファイルの読み込みに時間が掛かるから、エラーになっても、
2回目は、キャッシュから読み込むから、エラーにならないとか
ちゃんと非同期処理をやっていないのに、タイミング次第で動いているアプリは多い。
その特徴はエラーになったり、動いたりすること
ログを見れば、わかる
>別サーバへ設置するとコールバックの中でも動いたりする
実行環境が異なると、使っているライブラリも変わる
それと一般的には、動いたり動かなかったりするのは、非同期処理を勘違いしているとか。
promise とかで、ちゃんと解決してない
処理A, B の順番では動くけど、B, A の順番では動かないとか
1回目は、ファイルの読み込みに時間が掛かるから、エラーになっても、
2回目は、キャッシュから読み込むから、エラーにならないとか
ちゃんと非同期処理をやっていないのに、タイミング次第で動いているアプリは多い。
その特徴はエラーになったり、動いたりすること
ログを見れば、わかる
292デフォルトの名無しさん
2018/11/07(水) 07:44:13.90ID:Ahw1ICjC293デフォルトの名無しさん
2018/11/07(水) 09:25:05.22ID:avMw4Nf2 >>291
概ね同意だ。
善し悪しはさておき、WHATWGにあるのなら、今現在も仕様としてブラウザ開発者側に認識されているだろう。
なら、既に実装されて十分動いていたコードが意図的に落とされることはない。となると、
1. そもそも257のコードに問題があって、それが何らかの理由で顕在化しただけ
2. 元々ブラウザにバグがあって、それが検出されずにずっと残っていただけ
3. ブラウザのコードの更新時に、レグレッションテストに引っかからずバグを挿入してしまっただけ
のどれかだが、可能性が一番高いのは 1. だね。
俺自身はブラウザなんてバグだらけで全く信用ならないプラットフォームだと認識しているから、
こなれてない書き方は出来るだけしないようにしている。
そこではまっても本当に時間の無駄でしかないから。
だからそんなコードはさっさと書き直せ、という立場だ。
ただ、ブラウザのバグだという立場なら、バグ報告をするにしてもコードを切り分けていかないといけないし、
仮に 1. なら、idで書き直しても動かないケースが発生するはずだから、
どのみちそのコードに関しては詳細検討が必要になってしまったね。まあ頑張れ。
ある意味、「仕様外」だったほうが楽だったのではないかな?
もっとも、バグ報告したとしても、直すのも開発者側の自由だから、このまま放置される可能性もあるが。
JavaScripterは全般的にそうだが、最近の初心者は、仕様の隅を使いたがる傾向がある。
仕様を隅々まで知って、それを『使い切る』事がいいことだ/上級テクニックだと勘違いしている。
そういうところでしか差別化出来ないから、そういう小手先テクニックに異常にこだわるわけだ。
ただ、それが仕様内でも、それを動かすのは人間が作ったソフトウェアであって、
そこにバグがある可能性があり、実際、ブラウザなんてバグだらけだ。
こなれてない書き方をするのなら、それなりの覚悟と能力が必要だって事だ。
勿論それをやるのも自由だけど。
(もっとも、257がこなれてないか、と言われれば、こなれているが古い書き方、かな?)
概ね同意だ。
善し悪しはさておき、WHATWGにあるのなら、今現在も仕様としてブラウザ開発者側に認識されているだろう。
なら、既に実装されて十分動いていたコードが意図的に落とされることはない。となると、
1. そもそも257のコードに問題があって、それが何らかの理由で顕在化しただけ
2. 元々ブラウザにバグがあって、それが検出されずにずっと残っていただけ
3. ブラウザのコードの更新時に、レグレッションテストに引っかからずバグを挿入してしまっただけ
のどれかだが、可能性が一番高いのは 1. だね。
俺自身はブラウザなんてバグだらけで全く信用ならないプラットフォームだと認識しているから、
こなれてない書き方は出来るだけしないようにしている。
そこではまっても本当に時間の無駄でしかないから。
だからそんなコードはさっさと書き直せ、という立場だ。
ただ、ブラウザのバグだという立場なら、バグ報告をするにしてもコードを切り分けていかないといけないし、
仮に 1. なら、idで書き直しても動かないケースが発生するはずだから、
どのみちそのコードに関しては詳細検討が必要になってしまったね。まあ頑張れ。
ある意味、「仕様外」だったほうが楽だったのではないかな?
もっとも、バグ報告したとしても、直すのも開発者側の自由だから、このまま放置される可能性もあるが。
JavaScripterは全般的にそうだが、最近の初心者は、仕様の隅を使いたがる傾向がある。
仕様を隅々まで知って、それを『使い切る』事がいいことだ/上級テクニックだと勘違いしている。
そういうところでしか差別化出来ないから、そういう小手先テクニックに異常にこだわるわけだ。
ただ、それが仕様内でも、それを動かすのは人間が作ったソフトウェアであって、
そこにバグがある可能性があり、実際、ブラウザなんてバグだらけだ。
こなれてない書き方をするのなら、それなりの覚悟と能力が必要だって事だ。
勿論それをやるのも自由だけど。
(もっとも、257がこなれてないか、と言われれば、こなれているが古い書き方、かな?)
294デフォルトの名無しさん
2018/11/07(水) 11:04:13.33ID:PR5Ic2pS 最近の初心者が仕様の隅まで知りたがる?w嘘つけwww
仕様の隅まで知りたがるのはCおじさんとか古い人たちだろ。あの年代はCの仕様を勘違いしてたことがバレようものなら翌日から同僚に蔑まれてえんがちょされるような世代。
最近の特にWeb系のやつらなんか、必要になったらググって出てきたコードコピペする世代じゃんwwwww
仕様の隅まで知りたがるのはCおじさんとか古い人たちだろ。あの年代はCの仕様を勘違いしてたことがバレようものなら翌日から同僚に蔑まれてえんがちょされるような世代。
最近の特にWeb系のやつらなんか、必要になったらググって出てきたコードコピペする世代じゃんwwwww
295257
2018/11/07(水) 11:27:49.74ID:9inYuNmK いろいろありがとう。
>>267 で言ったアクセス解析のJS(これまた別のドメイン extdomain2 にある)を外したら動くようになった。
このJSはページロード初期に動いて終わりだと思ったら、タイマーで定期的に動き続けてるようだ。
ビーコン的に外と通信してるわけでもなさそうだから何やってるのかは分からないし、>>257 の smtFrom1 と smtForm1Callback の間でその JS の処理は割り込んでないようだけど、
少なくとも初期に DOM をいじってるようだからその影響なんだと思う。
それでも smtForm1 では document.form1 を参照できてるから、関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど、現状の詳細を伏せたままここで話を深められるほど単純なことでもなさそうだから、ちょっと引きこもります。
ありがとう。
>>267 で言ったアクセス解析のJS(これまた別のドメイン extdomain2 にある)を外したら動くようになった。
このJSはページロード初期に動いて終わりだと思ったら、タイマーで定期的に動き続けてるようだ。
ビーコン的に外と通信してるわけでもなさそうだから何やってるのかは分からないし、>>257 の smtFrom1 と smtForm1Callback の間でその JS の処理は割り込んでないようだけど、
少なくとも初期に DOM をいじってるようだからその影響なんだと思う。
それでも smtForm1 では document.form1 を参照できてるから、関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど、現状の詳細を伏せたままここで話を深められるほど単純なことでもなさそうだから、ちょっと引きこもります。
ありがとう。
296デフォルトの名無しさん
2018/11/07(水) 12:50:29.23ID:avMw4Nf2 >>295
> 具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど
そのスタンスなら君は君なりに整合性が取れていると思うよ。まあ頑張れ。
言うなれば俺はそういうのから逃げてる。
俺は思うように動かしたいだけであって、
JavaScript自身や環境のデバッグをしたいわけではない、というスタンスだからだ。
> 関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
知っているような気がするが、仕様上は document は複数存在しえる。
ただし、通常はそのようにコードが作られておらず、結果、まともに動かないから妥協されてる。
以下から辿れる。
> Node.ownerDocument 問題の詳細については W3C DOM FAQ を参照してください。
>
> Firefox では現在このルールを強制していません。
> Firefox 3 の開発中には強制していた時期もありましたが、
> このルールを強制すると多くのサイトが機能しなくなってしまうため取りやめになりました。
> 将来的な互換性を高めるため、Web 開発者にはこのルールに従ってコードを修正することを推奨します。
https://developer.mozilla.org/ja/docs/Web/API/Document/importNode
なにか、2-3年前にJavaScriptのスレ(ここだったかWeb板だったかは不明)で
同じようなことを言っていた奴が居たような気もしたが…。(あまり自信ない)
一応複数 document については、実装はされてるっぽい。
例えば、ChromeのDevTools(F12の奴)のTimelineでJSHeapの使用量グラフを出せるが、
そこに document が何個かのグラフも出る。
ただし俺にはあの document の数が何に一致するのかいまいち分からないが。
(具体的に外部documentを取り込むときに増えるのは分かるが、よく分からん時に増えるときもある)
> 具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど
そのスタンスなら君は君なりに整合性が取れていると思うよ。まあ頑張れ。
言うなれば俺はそういうのから逃げてる。
俺は思うように動かしたいだけであって、
JavaScript自身や環境のデバッグをしたいわけではない、というスタンスだからだ。
> 関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
知っているような気がするが、仕様上は document は複数存在しえる。
ただし、通常はそのようにコードが作られておらず、結果、まともに動かないから妥協されてる。
以下から辿れる。
> Node.ownerDocument 問題の詳細については W3C DOM FAQ を参照してください。
>
> Firefox では現在このルールを強制していません。
> Firefox 3 の開発中には強制していた時期もありましたが、
> このルールを強制すると多くのサイトが機能しなくなってしまうため取りやめになりました。
> 将来的な互換性を高めるため、Web 開発者にはこのルールに従ってコードを修正することを推奨します。
https://developer.mozilla.org/ja/docs/Web/API/Document/importNode
なにか、2-3年前にJavaScriptのスレ(ここだったかWeb板だったかは不明)で
同じようなことを言っていた奴が居たような気もしたが…。(あまり自信ない)
一応複数 document については、実装はされてるっぽい。
例えば、ChromeのDevTools(F12の奴)のTimelineでJSHeapの使用量グラフを出せるが、
そこに document が何個かのグラフも出る。
ただし俺にはあの document の数が何に一致するのかいまいち分からないが。
(具体的に外部documentを取り込むときに増えるのは分かるが、よく分からん時に増えるときもある)
297デフォルトの名無しさん
2018/11/07(水) 12:52:09.02ID:lrycyXQF 仕様の隅とかカッコつけなくて良いから
ただ「俺はそんな仕様知らないし勉強する気もない」だけでしょ
自分の意見を表明するだけで良いところを
ひたすら他人を絡めようとする奴は程度が知れてる
ただ「俺はそんな仕様知らないし勉強する気もない」だけでしょ
自分の意見を表明するだけで良いところを
ひたすら他人を絡めようとする奴は程度が知れてる
298デフォルトの名無しさん
2018/11/07(水) 12:55:39.20ID:oTVd6hn3 防衛機制の一種だろうな。
誰でも自分が無能と認めるわけにはいかないのさ。
誰でも自分が無能と認めるわけにはいかないのさ。
299デフォルトの名無しさん
2018/11/07(水) 13:32:20.41ID:avMw4Nf2 >>297-298
それが俺の自説を補強することにしかなってないことに気づけないのが、
お前らが馬鹿たる所以だよ。
マジでJavaScripterは馬鹿しかいない。これは断言出来る。
他言語と比べても相当酷い。
それが俺の自説を補強することにしかなってないことに気づけないのが、
お前らが馬鹿たる所以だよ。
マジでJavaScripterは馬鹿しかいない。これは断言出来る。
他言語と比べても相当酷い。
300デフォルトの名無しさん
2018/11/07(水) 15:22:39.79ID:PR5Ic2pS \__________________/
V
___ _
/ ____ヽ /  ̄  ̄ \
| | /, −、, -、l /、 ヽ きみ頭だいじょうぶ?
| _| -|○ | ○|| |・ |―-、 |
, ―-、 (6 _ー つ-´、} q -´ 二 ヽ |
| -⊂) \ ヽ_  ̄ ̄ノノ ノ_ ー | |
| ̄ ̄|/ (_ ∪ ̄ / 、 \ \. ̄` | /
ヽ ` ,.|  ̄ | | O===== |
`− ´ | | _| / |
V
___ _
/ ____ヽ /  ̄  ̄ \
| | /, −、, -、l /、 ヽ きみ頭だいじょうぶ?
| _| -|○ | ○|| |・ |―-、 |
, ―-、 (6 _ー つ-´、} q -´ 二 ヽ |
| -⊂) \ ヽ_  ̄ ̄ノノ ノ_ ー | |
| ̄ ̄|/ (_ ∪ ̄ / 、 \ \. ̄` | /
ヽ ` ,.|  ̄ | | O===== |
`− ´ | | _| / |
301デフォルトの名無しさん
2018/11/07(水) 18:00:52.56ID:avMw4Nf2 >>295
あと、実は、2.もあるかもね。
まともな奴(=バグ報告出来るレベルの奴)はそんな設計しないから、
バグ報告すら上がってきてない可能性もある。
1a. id
1b. document.forms[name]
1c. document[name]
でどれも動くとしても、まともな奴ならaかbだ。
「非推奨」なんて言われなくとも、推奨はaに決まっている。
そして、
2a. ノードそのものを渡す
2b. 名前を渡して、document[name]でアクセスしてもらう
ここもおかしいだろ。普通はaだ。
(決め打ち出来る状況だからだろうが、普通はその手の場合は決め打ちは無理だし)
おかしなコードが何故動かないか調査するのに精を出すよりも、
おかしなコードを修正する方に精を出す方が有意義だと思うが、まあこれは個人の自由だ。
ただ、俺は「仕様内」でもブラウザで動くかは信用ならんと実感しているから、
俺ならさっさと修正して終わりにするが。
(ブラウザのバグだとか言いだしたら長くcloseしない案件になってしまう。
ブラウザのバグ取りが目的ではないし)
あと、実は、2.もあるかもね。
まともな奴(=バグ報告出来るレベルの奴)はそんな設計しないから、
バグ報告すら上がってきてない可能性もある。
1a. id
1b. document.forms[name]
1c. document[name]
でどれも動くとしても、まともな奴ならaかbだ。
「非推奨」なんて言われなくとも、推奨はaに決まっている。
そして、
2a. ノードそのものを渡す
2b. 名前を渡して、document[name]でアクセスしてもらう
ここもおかしいだろ。普通はaだ。
(決め打ち出来る状況だからだろうが、普通はその手の場合は決め打ちは無理だし)
おかしなコードが何故動かないか調査するのに精を出すよりも、
おかしなコードを修正する方に精を出す方が有意義だと思うが、まあこれは個人の自由だ。
ただ、俺は「仕様内」でもブラウザで動くかは信用ならんと実感しているから、
俺ならさっさと修正して終わりにするが。
(ブラウザのバグだとか言いだしたら長くcloseしない案件になってしまう。
ブラウザのバグ取りが目的ではないし)
302デフォルトの名無しさん
2018/11/07(水) 19:49:33.17ID:qlBNSZgc303デフォルトの名無しさん
2018/11/07(水) 21:46:32.86ID:2P8ub5kW >>302
まずDocumentクラスの仕様を見るでしょ?
https://html.spec.whatwg.org/multipage/dom.html#the-document-object
// DOM tree accessors の getter object (DOMString name); を見つけるでしょ
その説明を見て終わり
まずDocumentクラスの仕様を見るでしょ?
https://html.spec.whatwg.org/multipage/dom.html#the-document-object
// DOM tree accessors の getter object (DOMString name); を見つけるでしょ
その説明を見て終わり
304デフォルトの名無しさん
2018/11/07(水) 22:16:45.82ID:+978RLDn VSCode の拡張機能、ESLint には、package manager のyarn の、インストールが必要。
yarnには、node.js のインストールが必要
yarnは、npm でインストールしなかった。
Windows10 に直接インストールした
yarnは、数MB のJavaScript で作られているのか。
Ruby のBundler, npm の影響を受けている
where node
C:\Program Files\nodejs\node.exe
where yarn
C:\Program Files (x86)\Yarn\bin\yarn
C:\Program Files (x86)\Yarn\bin\yarn.cmd
C:\Program Files (x86)\Yarn\bin\yarn.js
yarnには、node.js のインストールが必要
yarnは、npm でインストールしなかった。
Windows10 に直接インストールした
yarnは、数MB のJavaScript で作られているのか。
Ruby のBundler, npm の影響を受けている
where node
C:\Program Files\nodejs\node.exe
where yarn
C:\Program Files (x86)\Yarn\bin\yarn
C:\Program Files (x86)\Yarn\bin\yarn.cmd
C:\Program Files (x86)\Yarn\bin\yarn.js
305デフォルトの名無しさん
2018/11/07(水) 22:29:07.63ID:/kHK9X1+ 「Ruby」でNG登録するのがお手軽・簡単です。
306デフォルトの名無しさん
2018/11/07(水) 23:00:35.11ID:avMw4Nf2 >>294
コピペプログラマが無自覚で結果的に仕様の隅をつついたコードになっていることはあり得る。
彼等は書かないのだから、どういうコードが標準なのか当然知らないから。
ただ、本質的な問題はそこじゃない。
コピペプログラマがコピペしてきた元コードが糞だって事なんだよ。
コピペ自体が褒められるべき事ではないにしても、元コードがまともなら局所的にはまともなコードになる。
今回で言えば、誰かが最初に
document.name
の糞コードを書いた、ということなんだよ。
これがコピペであれば、どこかの馬鹿がドヤ顔で「こんな書き方も出来る(キリッ」した結果、ということだ。
正直、JavaScript界隈はこれが多すぎる。
糞コードが糞コードを再生産してて、しかもみんなそれに気づいてない。
JavaScript界隈はバージョン管理を止めてしまった。
結果、猶予期間中にアップデートして新しい書き方に変更していかないといけない状況になってる。
旧来の、バージョン○○では動きます、みたいな管理方法が出来なくなっている。
だからそもそも257流の管理方法は不適だ。
古い書き方のままでどこまで動かせるか厳密に言える状況ではなく、適宜書き換えていくしかなくなってる。
だから、本来は古いwebサイトは閉鎖されるべきなんだよ。
今 document.name なんて書いているまともなサイトがあるとは思えないから、
おそらくはかなり古いサイトを参考にしたか、どこかの馬鹿がドヤ顔したかだが、
正直、前者もかなりある。
コピペプログラマが無自覚で結果的に仕様の隅をつついたコードになっていることはあり得る。
彼等は書かないのだから、どういうコードが標準なのか当然知らないから。
ただ、本質的な問題はそこじゃない。
コピペプログラマがコピペしてきた元コードが糞だって事なんだよ。
コピペ自体が褒められるべき事ではないにしても、元コードがまともなら局所的にはまともなコードになる。
今回で言えば、誰かが最初に
document.name
の糞コードを書いた、ということなんだよ。
これがコピペであれば、どこかの馬鹿がドヤ顔で「こんな書き方も出来る(キリッ」した結果、ということだ。
正直、JavaScript界隈はこれが多すぎる。
糞コードが糞コードを再生産してて、しかもみんなそれに気づいてない。
JavaScript界隈はバージョン管理を止めてしまった。
結果、猶予期間中にアップデートして新しい書き方に変更していかないといけない状況になってる。
旧来の、バージョン○○では動きます、みたいな管理方法が出来なくなっている。
だからそもそも257流の管理方法は不適だ。
古い書き方のままでどこまで動かせるか厳密に言える状況ではなく、適宜書き換えていくしかなくなってる。
だから、本来は古いwebサイトは閉鎖されるべきなんだよ。
今 document.name なんて書いているまともなサイトがあるとは思えないから、
おそらくはかなり古いサイトを参考にしたか、どこかの馬鹿がドヤ顔したかだが、
正直、前者もかなりある。
307デフォルトの名無しさん
2018/11/07(水) 23:16:45.49ID:TSvBneKa ダラダラ長い。仕事できなさそう。
308デフォルトの名無しさん
2018/11/08(木) 06:09:34.45ID:+uMbCCJQ 質問です。
Parentを親に持つクラス Child には、自身のインスタンスを生成する関数があります。
(この書き方で良いのかは分かりませんが)
//基本クラス
class Parent{
}
//派生クラス
class Child extends Parent{
//自身のインスタンスを生成する
static CreateInstance(){ return new Child(); }
}
このとき、CreateInstance関数を
Parent側で用意するにはどう書くのが良いでしょうか。
Parentを親に持つクラス Child には、自身のインスタンスを生成する関数があります。
(この書き方で良いのかは分かりませんが)
//基本クラス
class Parent{
}
//派生クラス
class Child extends Parent{
//自身のインスタンスを生成する
static CreateInstance(){ return new Child(); }
}
このとき、CreateInstance関数を
Parent側で用意するにはどう書くのが良いでしょうか。
309デフォルトの名無しさん
2018/11/08(木) 06:35:07.12ID:RRHAcNkK new this()
310デフォルトの名無しさん
2018/11/08(木) 07:23:26.56ID:QHwNiY6E グローバルスコープの変数は、id だけの方がよい
311デフォルトの名無しさん
2018/11/08(木) 08:28:22.04ID:+uMbCCJQ312デフォルトの名無しさん
2018/11/08(木) 12:26:51.19ID:P9fHG5v1 まずWebの仕様とJSを一括にするのは違和感あるけど、まあそれはいいとして
今はWHATWGなどに立派な仕様があるんだからさ
それが元々どこかのブラウザの独自実装だろうが、デファクトだろうが、
ブラウザのお偉いさんが話し合って決めたことだろうが、
メーリングリストで決まったことだろうが、
なにがどうだって仕様は仕様なんだからさ、それを素直に参照すればいいじゃん
まあ色々言いたいことあるけど長くなるから取り敢えず1つだけにすると
Webって言うのは皆の合意、というより総意で決まって来たものだからさ
中央集権的な所が丸ごと決めきってから出す物と比べたら、
そりゃ良いところもあるし、同じだけ悪いところもある
でもその悪いとこだけを引き合いに出すのはおかしいと思うね
それはWebがWebの道を選んだ時点でどうしても付いてくる「特徴」だもの
それを改めようと思ったらWebがWebじゃ無くなっちゃう
WebはWebらしくて、他は他らしい、で良いじゃん
別にWebの特徴が嫌いなら他所へ行けばいいじゃん?
それをせずにそんな批判ばかりしたって、俺からすると、
「WebやWebの人間はこんな悪いとこがあるのに注目されて盛り上がっちゃって俺まで付き合わされておかしいだろ!」っていう妬みにしか聞こえないよ
でもたまたまラッキーでWebが発展できたわけじゃないからね
Webやコミュニティがこの形だったからこのよう発展できたわけ
それは事実として認めないとね
今はWHATWGなどに立派な仕様があるんだからさ
それが元々どこかのブラウザの独自実装だろうが、デファクトだろうが、
ブラウザのお偉いさんが話し合って決めたことだろうが、
メーリングリストで決まったことだろうが、
なにがどうだって仕様は仕様なんだからさ、それを素直に参照すればいいじゃん
まあ色々言いたいことあるけど長くなるから取り敢えず1つだけにすると
Webって言うのは皆の合意、というより総意で決まって来たものだからさ
中央集権的な所が丸ごと決めきってから出す物と比べたら、
そりゃ良いところもあるし、同じだけ悪いところもある
でもその悪いとこだけを引き合いに出すのはおかしいと思うね
それはWebがWebの道を選んだ時点でどうしても付いてくる「特徴」だもの
それを改めようと思ったらWebがWebじゃ無くなっちゃう
WebはWebらしくて、他は他らしい、で良いじゃん
別にWebの特徴が嫌いなら他所へ行けばいいじゃん?
それをせずにそんな批判ばかりしたって、俺からすると、
「WebやWebの人間はこんな悪いとこがあるのに注目されて盛り上がっちゃって俺まで付き合わされておかしいだろ!」っていう妬みにしか聞こえないよ
でもたまたまラッキーでWebが発展できたわけじゃないからね
Webやコミュニティがこの形だったからこのよう発展できたわけ
それは事実として認めないとね
313デフォルトの名無しさん
2018/11/08(木) 14:39:53.97ID:L3KEyImk > まあ色々言いたいことあるけど長くなるから取り敢えず1つだけにすると
うんとっても短いね棒
うんとっても短いね棒
314デフォルトの名無しさん
2018/11/08(木) 17:24:06.77ID:MPerk9aH >>312
コピペか?ポエムか?
意味不明すぎ。
流れ上俺への批判だろうが、該当する箇所がどこだかさっぱり分からない。
お前も「JavaScripterは馬鹿しかいない」という俺の自説を補強したいのか?
他言語スレでは馬鹿が噛みついて来るにしても、少なくともどこに噛みつかれたかは分かるぜ。
お前らではまともに会話が成立しないではないか。
コピペか?ポエムか?
意味不明すぎ。
流れ上俺への批判だろうが、該当する箇所がどこだかさっぱり分からない。
お前も「JavaScripterは馬鹿しかいない」という俺の自説を補強したいのか?
他言語スレでは馬鹿が噛みついて来るにしても、少なくともどこに噛みつかれたかは分かるぜ。
お前らではまともに会話が成立しないではないか。
315デフォルトの名無しさん
2018/11/08(木) 19:25:14.84ID:Kp/pDH8+ 下記のjsonをJavaScriptの多元連想配列に格納する方法を教えてください。
{
"name1": {
"key1": "value1",
"key2": "value2"
}
}
$.getJSON(url) で取得はできますが、
どのようなアクセスでvalue1等に辿れますでしょうか?
json['name1']['key1'] == 'value1' を期待していますが違うようです。
{
"name1": {
"key1": "value1",
"key2": "value2"
}
}
$.getJSON(url) で取得はできますが、
どのようなアクセスでvalue1等に辿れますでしょうか?
json['name1']['key1'] == 'value1' を期待していますが違うようです。
316デフォルトの名無しさん
2018/11/08(木) 20:03:52.85ID:dNW1RU/q >>315
$.getJSON( url, function( json ) {
console.log( json['name1']['key1'] );
});
俺ならawait fetch使うがjQueryがいいってんだからしょうがないね
$.getJSON( url, function( json ) {
console.log( json['name1']['key1'] );
});
俺ならawait fetch使うがjQueryがいいってんだからしょうがないね
317デフォルトの名無しさん
2018/11/08(木) 20:07:48.28ID:Kp/pDH8+ ありがとうございました。死ね。
318デフォルトの名無しさん
2018/11/08(木) 20:14:54.95ID:dNW1RU/q お前が死ね
319デフォルトの名無しさん
2018/11/08(木) 20:21:16.21ID:Kp/pDH8+ 人間のクズw
320デフォルトの名無しさん
2018/11/08(木) 20:34:29.34ID:IPM45bBP ここはひどいインターネットですね
321デフォルトの名無しさん
2018/11/08(木) 21:03:58.59ID:hMdcDcbr322デフォルトの名無しさん
2018/11/08(木) 22:52:35.10ID:EWHrduHm 今どきjQueryでって頭が湧いてるとしか思えんな
323デフォルトの名無しさん
2018/11/08(木) 23:00:42.87ID:QHwNiY6E 荒らしと会話するな。質問に答えるな。
荒らしと会話するものも、荒らしと同じ
このスレで質問しないように!
JavaScript, jQuery のスレは、web制作管理板にあるので、そこへ書き込め
この板には、荒らしが多いから、書き込まないように!
他の質問スレにも、よくいる。
質問に答えると、お前に聞いていないとか、馬鹿とか、荒らしてくる奴が多い
荒らしと会話するものも、荒らしと同じ
このスレで質問しないように!
JavaScript, jQuery のスレは、web制作管理板にあるので、そこへ書き込め
この板には、荒らしが多いから、書き込まないように!
他の質問スレにも、よくいる。
質問に答えると、お前に聞いていないとか、馬鹿とか、荒らしてくる奴が多い
324デフォルトの名無しさん
2018/11/08(木) 23:09:47.02ID:MPerk9aH325デフォルトの名無しさん
2018/11/08(木) 23:36:30.84ID:rJTiWJ81 ほんと、jQueryの話題がでると、頭フットーするやつがいるなぁw
>>322
> 今どきjQueryでって頭が湧いてるとしか思えんな
https://w3techs.com/technologies/overview/javascript_library/all
w3techsによると2017年1月の時点で71.9%のサイトがJavaScriptのライブラリとして
jQueryを使用していることが判明し、それ以降もシェアの増加が続いていたが、
2018年4月〜2018年10月の約半年間で変化が見られず、ようやく73.3%〜73.4%で
増加が停止したようである。
しかしながら、減少の傾向は見られず、マーケットシェア(JavaScriptを使用しているサイトでの使用率)
https://w3techs.com/technologies/history_overview/javascript_library は97.2%を
示していることから、jQueryからの移行が始まったと言うより、上げ止まりであると考えられる
jQuery以外では、この1年でBootstrapが2%程度、Underscoreが1%程度増加している以外は
ほとんど変動はなく、期待されていたAngularは過去最高の0.5%から0.1%減少した0.4%に、
Reactは過去最高の0.6%から0.5%と大きく減少し、0.1%に下がっていることが判明した。
またいずれのライブラリも使用していないサイトは24.5%で
2017年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか?この先の動向が注目される
>>322
> 今どきjQueryでって頭が湧いてるとしか思えんな
https://w3techs.com/technologies/overview/javascript_library/all
w3techsによると2017年1月の時点で71.9%のサイトがJavaScriptのライブラリとして
jQueryを使用していることが判明し、それ以降もシェアの増加が続いていたが、
2018年4月〜2018年10月の約半年間で変化が見られず、ようやく73.3%〜73.4%で
増加が停止したようである。
しかしながら、減少の傾向は見られず、マーケットシェア(JavaScriptを使用しているサイトでの使用率)
https://w3techs.com/technologies/history_overview/javascript_library は97.2%を
示していることから、jQueryからの移行が始まったと言うより、上げ止まりであると考えられる
jQuery以外では、この1年でBootstrapが2%程度、Underscoreが1%程度増加している以外は
ほとんど変動はなく、期待されていたAngularは過去最高の0.5%から0.1%減少した0.4%に、
Reactは過去最高の0.6%から0.5%と大きく減少し、0.1%に下がっていることが判明した。
またいずれのライブラリも使用していないサイトは24.5%で
2017年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか?この先の動向が注目される
326デフォルトの名無しさん
2018/11/08(木) 23:51:10.14ID:a5prroZo 近年jQueryは余計な機能減らしてきててDOM操作ライブラリへの回帰を目指している。
jQuery.slimには$.ajaxや$.getJSONは入っていない。
jQuery.slimには$.ajaxや$.getJSONは入っていない。
327デフォルトの名無しさん
2018/11/08(木) 23:54:50.59ID:MPerk9aH >>325
> jQueryの話題がでると、頭フットーするやつがいるなぁw
お前もな。
好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
急速に衰退するかは微妙だが、引き金になるとしたらWebAssemblyが成功したら、かな?
そう簡単に行くとも思えんが、あれはゲームチェンジャーになり得る。
> jQueryの話題がでると、頭フットーするやつがいるなぁw
お前もな。
好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
急速に衰退するかは微妙だが、引き金になるとしたらWebAssemblyが成功したら、かな?
そう簡単に行くとも思えんが、あれはゲームチェンジャーになり得る。
328デフォルトの名無しさん
2018/11/09(金) 01:16:54.01ID:UVRb8J0Z >>327
> 好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
> それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
逆逆w 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どう考えても終わりません。不安を煽って間違ってる方向へ変えようと、
明らかにずれてる方向が正しいんだと、布教してるやつがいるから事実を伝えてるだけ
jQueryの代替なんてまだ登場してないんだよ。React?Angular? WebAssembly?
それらはjQueryの代替ではなく大規模なウェブアプリを作るためのもの。
ウェブサイトに適してるのは昔も今もjQueryだ。
jQueryが終わるとしたらWeb componentsが完成して、
使えるコンポーネントが "出揃った時" だろう
つまりウェブサイトを作ってる連中が「JavaScriptなんて全く使わねぇ。
誰かが作ったコンポーネントを使ったHTMLを書くだけで終わり」と
言い出すまでってことだ
そうなれば本来あるべき完全分業の世界に行くことができる。
HTMLのパーツを作るのはプログラマ。それを使うのはウェブデザイナー。
今はウェブデザイナーが書いたHTMLにJavaScript(jQuery)で動きをつけるという形で分業している。
jQueryを使うのはJavaScriptよりも圧倒的に楽だから。セレクタを使うからウェブデザインとの相性も良い。
React、Angular、WebAssembly などはウェブデザイナーの仕事であるデザインの作成を
プログラマの領域に吸収するやり方なので、世界の大半を占めるウェブサイトには全く適していない
> 好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
> それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
逆逆w 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どう考えても終わりません。不安を煽って間違ってる方向へ変えようと、
明らかにずれてる方向が正しいんだと、布教してるやつがいるから事実を伝えてるだけ
jQueryの代替なんてまだ登場してないんだよ。React?Angular? WebAssembly?
それらはjQueryの代替ではなく大規模なウェブアプリを作るためのもの。
ウェブサイトに適してるのは昔も今もjQueryだ。
jQueryが終わるとしたらWeb componentsが完成して、
使えるコンポーネントが "出揃った時" だろう
つまりウェブサイトを作ってる連中が「JavaScriptなんて全く使わねぇ。
誰かが作ったコンポーネントを使ったHTMLを書くだけで終わり」と
言い出すまでってことだ
そうなれば本来あるべき完全分業の世界に行くことができる。
HTMLのパーツを作るのはプログラマ。それを使うのはウェブデザイナー。
今はウェブデザイナーが書いたHTMLにJavaScript(jQuery)で動きをつけるという形で分業している。
jQueryを使うのはJavaScriptよりも圧倒的に楽だから。セレクタを使うからウェブデザインとの相性も良い。
React、Angular、WebAssembly などはウェブデザイナーの仕事であるデザインの作成を
プログラマの領域に吸収するやり方なので、世界の大半を占めるウェブサイトには全く適していない
329デフォルトの名無しさん
2018/11/09(金) 01:18:44.17ID:UVRb8J0Z 世界の大半を占めるウェブサイトは
「まず最初にHTML+CSSを書く」ということを
しっかりと認識するようにな
まず最初にビルド環境を整えましょうじゃないんだよw
「まず最初にHTML+CSSを書く」ということを
しっかりと認識するようにな
まず最初にビルド環境を整えましょうじゃないんだよw
330デフォルトの名無しさん
2018/11/09(金) 01:31:54.32ID:aKlbQf3w IE11のことを考えないコードを指摘するのは人間のクズ
JQの時点でお察ししろクソ野郎
ちなみに、あたしはクソ女だからな!
女の言う事は従えよ?
JQの時点でお察ししろクソ野郎
ちなみに、あたしはクソ女だからな!
女の言う事は従えよ?
331デフォルトの名無しさん
2018/11/09(金) 03:02:19.99ID:OgIaPmrY >>328
> 逆逆w 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どっちが先とかはどうでもよくて、お前も必死過ぎなのは事実だよ。
どうしても、jQueryは不滅です、ってことにしたいんだろ。それもまた、不安だからだよ。
> 今はウェブデザイナーが書いたHTMLにJavaScript(jQuery)で動きをつけるという形で分業している。
> ウェブデザイナーの仕事であるデザインの作成を
> プログラマの領域に吸収するやり方なので
この、君の現状認識については同意出来る。
> 「まず最初にHTML+CSSを書く」ということを
これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
CSSの恩恵を正しく受ける為にはクラス設計が必要となる。
そしてそれは工程が逆転する、つまりプログラマが上流、デザイナが下流になるから、
Webデザイナが牛耳っている職場ではかなり無理がある。変化するにしても時間はかかるだろう。
それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
どっちに賭けるかも含めて、個人の自由だ。
> jQueryの代替なんてまだ登場してないんだよ。
jQueryの売りはCSSセレクタで、それは標準に入ってしまった。
大体それ以前に、まともにクラス設計されてたら getElementsByClassName だけで済んでしまって、
querySelectorすら必要ない。(アプリならqueryすらしないし)
その他諸々jQueryが色々便利に出来ていることは認めるが、
最早、無ければ無いでいいや、程度でしか無いと思うが?
まあこれについては水掛け論だからもういいが、
少なくとも、俺と同じ「もう要らないんじゃね?」と思う奴が一定数居るからこそ「不要論」が出るわけで、
そこは君も認めないと駄目だと思うぜ。
> 逆逆w 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どっちが先とかはどうでもよくて、お前も必死過ぎなのは事実だよ。
どうしても、jQueryは不滅です、ってことにしたいんだろ。それもまた、不安だからだよ。
> 今はウェブデザイナーが書いたHTMLにJavaScript(jQuery)で動きをつけるという形で分業している。
> ウェブデザイナーの仕事であるデザインの作成を
> プログラマの領域に吸収するやり方なので
この、君の現状認識については同意出来る。
> 「まず最初にHTML+CSSを書く」ということを
これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
CSSの恩恵を正しく受ける為にはクラス設計が必要となる。
そしてそれは工程が逆転する、つまりプログラマが上流、デザイナが下流になるから、
Webデザイナが牛耳っている職場ではかなり無理がある。変化するにしても時間はかかるだろう。
それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
どっちに賭けるかも含めて、個人の自由だ。
> jQueryの代替なんてまだ登場してないんだよ。
jQueryの売りはCSSセレクタで、それは標準に入ってしまった。
大体それ以前に、まともにクラス設計されてたら getElementsByClassName だけで済んでしまって、
querySelectorすら必要ない。(アプリならqueryすらしないし)
その他諸々jQueryが色々便利に出来ていることは認めるが、
最早、無ければ無いでいいや、程度でしか無いと思うが?
まあこれについては水掛け論だからもういいが、
少なくとも、俺と同じ「もう要らないんじゃね?」と思う奴が一定数居るからこそ「不要論」が出るわけで、
そこは君も認めないと駄目だと思うぜ。
332デフォルトの名無しさん
2018/11/09(金) 03:02:58.94ID:OgIaPmrY jQueryはHTMLベースになる点が本質的に筋が悪いんだよ。(逆に、それが取っつきやすい点でもあるが)
だから頻繁にリニューアルするサイトならCSSベースの方が効率がいい。
文書を流し込んで出来上がり、だからだ。
(そしてその場合は、CSSクラスをがっちり組んでしまう為、jQueryの恩恵がない)
その点、おそらくWordPress等もそこを目指しているはずだが、
いまいちjQueryが死にきってないところをみると、
WordPressではJavaScriptをある程度書かないと駄目なのかな?
まあそれはさておき、
> 世界の大半を占めるウェブサイト
はつまりほぼ静的なサイトであり、お約束的動きしか必要ないのだから、(ハンバーガーメニューとか)
最終的には静的ページ用のフレームワークで全て終了するようになるはずだが。
Hugoとか、どこまで出来るのか知らんが、出てきてるだろ。
他サイトでやってない動きが必要なら自前で書くしかないけど、ほぼ静的サイトでそれは不要だろ。
デザイナがJavaScriptを書かなければならないのは、環境が整備されてないからだよ。
そしてプログラマにとってはjQueryはもうどっちでもいい存在になってる。
或いはここは君も同意してくれるのかな?
> jQueryが終わるとしたらWeb componentsが完成して、
> 使えるコンポーネントが "出揃った時" だろう
確認してみたが、この意見にも同意出来る。
ただ、若干大がかりすぎるとは思うが。俺は静的HP用フレームワークでいいと思うぜ。
shadowDOMなんてここで持ち出す必要なんて無いと思うのだが。
あと、デザイナはどうしても独自の動きを付けたいのかね?
だとすると、永久に「出揃う」事はないが。
とまあ、つらつら書いてみたが、俺と君の認識は似ている、というかほぼ同じだろう。
WebAssemblyについては、俺は「プログラマがjQuery禁止にされる理由」になり得ると見ている。
今現在jQueryを使って悪い点は、第一に速度面だろ。だから。
だから頻繁にリニューアルするサイトならCSSベースの方が効率がいい。
文書を流し込んで出来上がり、だからだ。
(そしてその場合は、CSSクラスをがっちり組んでしまう為、jQueryの恩恵がない)
その点、おそらくWordPress等もそこを目指しているはずだが、
いまいちjQueryが死にきってないところをみると、
WordPressではJavaScriptをある程度書かないと駄目なのかな?
まあそれはさておき、
> 世界の大半を占めるウェブサイト
はつまりほぼ静的なサイトであり、お約束的動きしか必要ないのだから、(ハンバーガーメニューとか)
最終的には静的ページ用のフレームワークで全て終了するようになるはずだが。
Hugoとか、どこまで出来るのか知らんが、出てきてるだろ。
他サイトでやってない動きが必要なら自前で書くしかないけど、ほぼ静的サイトでそれは不要だろ。
デザイナがJavaScriptを書かなければならないのは、環境が整備されてないからだよ。
そしてプログラマにとってはjQueryはもうどっちでもいい存在になってる。
或いはここは君も同意してくれるのかな?
> jQueryが終わるとしたらWeb componentsが完成して、
> 使えるコンポーネントが "出揃った時" だろう
確認してみたが、この意見にも同意出来る。
ただ、若干大がかりすぎるとは思うが。俺は静的HP用フレームワークでいいと思うぜ。
shadowDOMなんてここで持ち出す必要なんて無いと思うのだが。
あと、デザイナはどうしても独自の動きを付けたいのかね?
だとすると、永久に「出揃う」事はないが。
とまあ、つらつら書いてみたが、俺と君の認識は似ている、というかほぼ同じだろう。
WebAssemblyについては、俺は「プログラマがjQuery禁止にされる理由」になり得ると見ている。
今現在jQueryを使って悪い点は、第一に速度面だろ。だから。
333デフォルトの名無しさん
2018/11/09(金) 03:17:04.51ID:ToatAuO8 馬鹿って変なところにこだわって前へ進めないままなんだよなあ
そういうの捨てれば楽になるのに
そういうの捨てれば楽になるのに
334デフォルトの名無しさん
2018/11/09(金) 06:28:59.39ID:n9QnyFxx jQueryの遅さは機能性から来るそのDOMAPI利用の冗長さにあって
WebAssemblyでDOMAPIを叩ける用になっても同じことをすれば速度は変わらないだろ
こいつホント中身スッカスカの思考しかできない、文字通りのカス
WebAssemblyでDOMAPIを叩ける用になっても同じことをすれば速度は変わらないだろ
こいつホント中身スッカスカの思考しかできない、文字通りのカス
335デフォルトの名無しさん
2018/11/09(金) 07:09:53.79ID:yToTdWux ブラウザもPCもどんどこ高性能になってるよ。
そんなに言うほど遅くない。
慣れている物で素早く開発し、ちゃんと制御することも大事じゃん。
そんなに言うほど遅くない。
慣れている物で素早く開発し、ちゃんと制御することも大事じゃん。
336デフォルトの名無しさん
2018/11/09(金) 07:39:35.28ID:UVRb8J0Z >>331
> > 「まず最初にHTML+CSSを書く」ということを
> これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
中途半端に引用するな
ほんとな。わざと1行で書いて、都合よく引用させないように
徹底しないといけないよな
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」ということを
ってかいただろ
プログラマ的に間違ってるとか、大半を占めるウェブサイトになんの関係があるんですか?
上で、ゲームチェンジャーになりうるとか言ったが、なんのゲームを変えるのかを
明確に言ったらどうだ?それは「プログラマ的なゲーム」だろう
チェンジするのはウェブサイトの世界じゃない。デスクトップやスマホアプリ・ゲームの世界だ
デスクトップやスマホと言ったウェブでない世界を壊してウェブに来るだけの話
その場合になくなるのはjQueryじゃなくて.NET FrameworkやUnityだよ
> > 「まず最初にHTML+CSSを書く」ということを
> これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
中途半端に引用するな
ほんとな。わざと1行で書いて、都合よく引用させないように
徹底しないといけないよな
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」ということを
ってかいただろ
プログラマ的に間違ってるとか、大半を占めるウェブサイトになんの関係があるんですか?
上で、ゲームチェンジャーになりうるとか言ったが、なんのゲームを変えるのかを
明確に言ったらどうだ?それは「プログラマ的なゲーム」だろう
チェンジするのはウェブサイトの世界じゃない。デスクトップやスマホアプリ・ゲームの世界だ
デスクトップやスマホと言ったウェブでない世界を壊してウェブに来るだけの話
その場合になくなるのはjQueryじゃなくて.NET FrameworkやUnityだよ
337デフォルトの名無しさん
2018/11/09(金) 07:45:53.68ID:UVRb8J0Z WebAssemblyとか語るやつは、新しく何ができるかしか言わない。
何がどう楽になるのかをけっして言わない。
なぜか?それを言ってしまうと「あぁうちには関係ありませんね」って
言われるのが目に見えてるからだ
WebAssemblyで楽にならないわけがない。では何が楽になるのか?
マルチプラットフォームのアプリをウェブアプリにするのが楽になるんだよ。
いまウェブの大半を占めるウェブサイトの制作が楽になることはない
新しいことができるようになったら、みんな新しいことをするはずだとか
思ってるのかもしれないが、大半は新しいことなんてしようと思っていない
今の仕事が楽にしようと思っている。
だからWebAssemblyもそうだし、JavaScriptフレームワークの導入も大変だし、
jQuery捨ててDOM APIを使うのも、大変になるだけなので使おうと思わない。
そしてjQueryのスピードにも全く困っていないというのも重要な所だな
何がどう楽になるのかをけっして言わない。
なぜか?それを言ってしまうと「あぁうちには関係ありませんね」って
言われるのが目に見えてるからだ
WebAssemblyで楽にならないわけがない。では何が楽になるのか?
マルチプラットフォームのアプリをウェブアプリにするのが楽になるんだよ。
いまウェブの大半を占めるウェブサイトの制作が楽になることはない
新しいことができるようになったら、みんな新しいことをするはずだとか
思ってるのかもしれないが、大半は新しいことなんてしようと思っていない
今の仕事が楽にしようと思っている。
だからWebAssemblyもそうだし、JavaScriptフレームワークの導入も大変だし、
jQuery捨ててDOM APIを使うのも、大変になるだけなので使おうと思わない。
そしてjQueryのスピードにも全く困っていないというのも重要な所だな
338デフォルトの名無しさん
2018/11/09(金) 07:53:41.77ID:UVRb8J0Z >>331
> それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
いつまで待てばいいの?w
このスレ立ててからもうすぐ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年? まだまだかかりそうだねぇw
> それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
いつまで待てばいいの?w
このスレ立ててからもうすぐ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年? まだまだかかりそうだねぇw
339デフォルトの名無しさん
2018/11/09(金) 08:05:03.76ID:J9ZYW49D jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな
そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
だから新規で作るものはjQueryを見送ってるし
保守してる人間たちはこれから廃れていくjQueryにしがみつくしかない
JAVAと同じだな
そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
だから新規で作るものはjQueryを見送ってるし
保守してる人間たちはこれから廃れていくjQueryにしがみつくしかない
JAVAと同じだな
340デフォルトの名無しさん
2018/11/09(金) 08:11:32.70ID:UVRb8J0Z > jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな
1.7(2011年11月)ぐらいから殆ど変わってないんだが?
もう7年も前だぜ・・・
> そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
ESとは対象分野が違う、ESにDOM操作の命令はない
そういう基本的なところを分ってないやつが
> だから新規で作るものはjQueryを見送ってるし
とかいっても、説得力ゼロだよw
1.7(2011年11月)ぐらいから殆ど変わってないんだが?
もう7年も前だぜ・・・
> そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
ESとは対象分野が違う、ESにDOM操作の命令はない
そういう基本的なところを分ってないやつが
> だから新規で作るものはjQueryを見送ってるし
とかいっても、説得力ゼロだよw
341デフォルトの名無しさん
2018/11/09(金) 08:14:08.68ID:J9ZYW49D 老害
342デフォルトの名無しさん
2018/11/09(金) 08:55:33.36ID:UVRb8J0Z 俺が老害かどうかじゃなくて、現実を見たほうが良くね?w
老害と言われた俺が言ってることが、現実となってるとしたら、
それはどういうことなんだろうね
React、0.6%から0.1%にシェア減っちゃいましたよ?
老害と言われた俺が言ってることが、現実となってるとしたら、
それはどういうことなんだろうね
React、0.6%から0.1%にシェア減っちゃいましたよ?
343デフォルトの名無しさん
2018/11/09(金) 09:11:07.67ID:Ijfza7/E344デフォルトの名無しさん
2018/11/09(金) 10:08:49.86ID:OgIaPmrY >>336
意図的におかしな引用をしたつもりはないが、そう取れたのならすまんかった。
現状認識において、俺と君には大差ない。再度確認するなら、
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」
そうだ。正確に言えば、そうだった。これが変わりつつある。
> いまウェブの大半を占めるウェブサイトの制作が楽になることはない
これが違う。静的HP用のフレームワークを使えば、楽になる。
本来はWordPress等もここを目指しているはずだが、
JavaScriptをいちいち書かないといけないのなら、それは上手く行ってないだけだね。
> そしてjQueryのスピードにも全く困っていないというのも重要な所だな
これはそうだとも言えるが、そうでも無いとも言える。
そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
それがJQueryかどうかは別だが、
フレームワークもjQueryも無しなら(いろんな意味で)遅いサイトになりにくいのも事実だ。
結果、素で書け、と言われるのもまた然り。
意図的におかしな引用をしたつもりはないが、そう取れたのならすまんかった。
現状認識において、俺と君には大差ない。再度確認するなら、
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」
そうだ。正確に言えば、そうだった。これが変わりつつある。
> いまウェブの大半を占めるウェブサイトの制作が楽になることはない
これが違う。静的HP用のフレームワークを使えば、楽になる。
本来はWordPress等もここを目指しているはずだが、
JavaScriptをいちいち書かないといけないのなら、それは上手く行ってないだけだね。
> そしてjQueryのスピードにも全く困っていないというのも重要な所だな
これはそうだとも言えるが、そうでも無いとも言える。
そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
それがJQueryかどうかは別だが、
フレームワークもjQueryも無しなら(いろんな意味で)遅いサイトになりにくいのも事実だ。
結果、素で書け、と言われるのもまた然り。
345デフォルトの名無しさん
2018/11/09(金) 10:09:17.53ID:OgIaPmrY が、話が広がりすぎるので絞ると、
・デザイナ(またはその下請けが)JavaScriptを書かなくてよくなったときにjQueryは終わる
というのは俺も君も共通見解だ。これはいいな?なら、逆説的に、君も
・プログラマにはもう既にjQueryは無用の長物となっている
事を認めることになるが、ここまでもいいよな?
そしてデザイナがいつJavaScriptを書かなくて良くなるかは、
・Web componentsが完成して、使えるコンポーネントが "出揃った時" (君)
・静的HP用フレームワークが整備され、普及したとき(俺)
と詳細な意見は異なるが、まあこれは誤差の範囲だろ。
> いつまで待てばいいの?w
「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
なら、10年後くらいではないかな。
今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
そしてその彼等が主力、具体的には30代前半にさしかかり、
「jQueryなんて要りません」派が現場での主流派になったときに牙をむくってだけの話さ。
が、正直なところ、俺と君には議論になるほどの意見の相違はないぞ。
別段、君の現状認識に間違いがあるとも思えないし、jQueryが死ぬにしても時間はかかるよ。
もし頓死する可能性があるとしたら、WebAssemblyの出現によって次の次元のスピード競争に巻き込まれたら、って話さ。
ただ、正直、俺にはWebAssemblyがどこを目指しているのかよく分からんし、そもそも立ち上がるかも微妙だとは思う。
だからって、jQueryが安泰で未来永劫使われる、ってことも無いよ。繰り返すが、
今から始める人にとっては、「重複機能ばっかり…」なのも事実だろ。
・デザイナ(またはその下請けが)JavaScriptを書かなくてよくなったときにjQueryは終わる
というのは俺も君も共通見解だ。これはいいな?なら、逆説的に、君も
・プログラマにはもう既にjQueryは無用の長物となっている
事を認めることになるが、ここまでもいいよな?
そしてデザイナがいつJavaScriptを書かなくて良くなるかは、
・Web componentsが完成して、使えるコンポーネントが "出揃った時" (君)
・静的HP用フレームワークが整備され、普及したとき(俺)
と詳細な意見は異なるが、まあこれは誤差の範囲だろ。
> いつまで待てばいいの?w
「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
なら、10年後くらいではないかな。
今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
そしてその彼等が主力、具体的には30代前半にさしかかり、
「jQueryなんて要りません」派が現場での主流派になったときに牙をむくってだけの話さ。
が、正直なところ、俺と君には議論になるほどの意見の相違はないぞ。
別段、君の現状認識に間違いがあるとも思えないし、jQueryが死ぬにしても時間はかかるよ。
もし頓死する可能性があるとしたら、WebAssemblyの出現によって次の次元のスピード競争に巻き込まれたら、って話さ。
ただ、正直、俺にはWebAssemblyがどこを目指しているのかよく分からんし、そもそも立ち上がるかも微妙だとは思う。
だからって、jQueryが安泰で未来永劫使われる、ってことも無いよ。繰り返すが、
今から始める人にとっては、「重複機能ばっかり…」なのも事実だろ。
346デフォルトの名無しさん
2018/11/09(金) 10:41:19.41ID:UVRb8J0Z347デフォルトの名無しさん
2018/11/09(金) 10:43:55.06ID:UVRb8J0Z >>345
> そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
> それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
> それがJQueryかどうかは別だが、
> フレームワークもjQueryも無しなら(いろんな意味で)遅いサイトになりにくいのも事実だ。
> 結果、素で書け、と言われるのもまた然り。
やっぱり、実行速度しか目に入ってないんだなw
かわいそうに。
ほとんどの人は、楽になる方法しか求めてないよ
jQueryをやめて楽になるか? 何一つ楽にならない
速いとか遅いとか言ってる限り、現状のjQueryのシェアが
落ちてない事実は理解できないだろうよ
> そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
> それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
> それがJQueryかどうかは別だが、
> フレームワークもjQueryも無しなら(いろんな意味で)遅いサイトになりにくいのも事実だ。
> 結果、素で書け、と言われるのもまた然り。
やっぱり、実行速度しか目に入ってないんだなw
かわいそうに。
ほとんどの人は、楽になる方法しか求めてないよ
jQueryをやめて楽になるか? 何一つ楽にならない
速いとか遅いとか言ってる限り、現状のjQueryのシェアが
落ちてない事実は理解できないだろうよ
348デフォルトの名無しさん
2018/11/09(金) 10:44:48.91ID:UVRb8J0Z > 今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
同じことをこんなに簡単にできるなんて!
としか思わないよw
楽になるかどうかだからね。
同じことをこんなに簡単にできるなんて!
としか思わないよw
楽になるかどうかだからね。
349デフォルトの名無しさん
2018/11/09(金) 10:46:26.82ID:UVRb8J0Z document.querySelectorAll() を
$() とかけるだけで、素晴らしいって思うだろうねw
$() とかけるだけで、素晴らしいって思うだろうねw
350デフォルトの名無しさん
2018/11/09(金) 10:53:28.88ID:UVRb8J0Z >>345
> 「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
> なら、10年後くらいではないかな。
「staticおじさん」なる言葉が発生したときには、staticばかり使ってる人はすでにいなかったわけだが、
jQueryの場合、使っている所が大半を締めてる。状況はぜんぜん違うんだが何と何を比べてるんだ?
> 「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
> なら、10年後くらいではないかな。
「staticおじさん」なる言葉が発生したときには、staticばかり使ってる人はすでにいなかったわけだが、
jQueryの場合、使っている所が大半を締めてる。状況はぜんぜん違うんだが何と何を比べてるんだ?
351デフォルトの名無しさん
2018/11/09(金) 11:16:21.71ID:9aipcx/m >>343
NGしとくといいよ。
NGしとくといいよ。
352デフォルトの名無しさん
2018/11/09(金) 12:31:06.18ID:ZgQBCm2t まあ、適材適所っしょ。
React信者は自分のスキルセットを至高で唯一の物だと思いがち。
jQueryで十分なものもあれば、Vueで十分なものもあるし、Reactが適してるものもある。
React信者は自分のスキルセットを至高で唯一の物だと思いがち。
jQueryで十分なものもあれば、Vueで十分なものもあるし、Reactが適してるものもある。
353デフォルトの名無しさん
2018/11/09(金) 14:21:08.83ID:OgIaPmrY >>349
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねw
なるほど君はデザイナ側か。
なら話は平行線だろうし、君はjQueryと心中して問題ないと思うよ。
プログラマにとってはそれはコストではないんだよ。
タイピングも速いし、それ以前に「デバッグ」のコストが大半だから。
色を付けるだけならスモークテスト=最終テストで、君はその発想しか出来てない。
実際、DOMクエリは100倍くらい遅くて、地道に削除するだけでもかなり高速化する。
だから、 document.getElementsByClassName みたいな糞長ったらしいメソッドで、
書きたくなくさせるのも、効果があるといえばあるのさ。
「高価な操作はソースコード上でもそう見えるようにしろ、そうしないとメンテの時に障害になる」
ってのはC++の思想だが、これも一理あるわけでさ。
(デザイナにとっては色が付けば良しなのだろうが、プログラマにとっては実行速度も管理対象であって)
jQueryが不味いのは、その手の操作がお手軽にできるから、そういった書き方になってしまいがちなこと。
これはjQueryそのものが遅いのではなくて、使う人が悪いのだけど、
これも含めてjQueryが悪いことにされてて、君のようにムキになる人が出てくるのも自然な成り行きではある。
ただ、既に書いたように、jQueryはHTMLベースになる点(なりがちな点)が本質的に筋が悪いんだよ。
ただそれは上記の通り、使う人の問題だが、
CSSクラスベースに移行したらクエリそのものが単純になる/必要なくなるのも事実でさ。
結果、CSSにすら移行出来ないサイトだけがjQueryを使い続けることになり、それは馬鹿にされるのも当然だよ。
そして今の君のような人に対する反動として、10年後に噴出する、というわけさ。
>>350
『今から』10年後な。
jQueryが必要ではなくなってから15年後、ってことだよ。
「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねw
なるほど君はデザイナ側か。
なら話は平行線だろうし、君はjQueryと心中して問題ないと思うよ。
プログラマにとってはそれはコストではないんだよ。
タイピングも速いし、それ以前に「デバッグ」のコストが大半だから。
色を付けるだけならスモークテスト=最終テストで、君はその発想しか出来てない。
実際、DOMクエリは100倍くらい遅くて、地道に削除するだけでもかなり高速化する。
だから、 document.getElementsByClassName みたいな糞長ったらしいメソッドで、
書きたくなくさせるのも、効果があるといえばあるのさ。
「高価な操作はソースコード上でもそう見えるようにしろ、そうしないとメンテの時に障害になる」
ってのはC++の思想だが、これも一理あるわけでさ。
(デザイナにとっては色が付けば良しなのだろうが、プログラマにとっては実行速度も管理対象であって)
jQueryが不味いのは、その手の操作がお手軽にできるから、そういった書き方になってしまいがちなこと。
これはjQueryそのものが遅いのではなくて、使う人が悪いのだけど、
これも含めてjQueryが悪いことにされてて、君のようにムキになる人が出てくるのも自然な成り行きではある。
ただ、既に書いたように、jQueryはHTMLベースになる点(なりがちな点)が本質的に筋が悪いんだよ。
ただそれは上記の通り、使う人の問題だが、
CSSクラスベースに移行したらクエリそのものが単純になる/必要なくなるのも事実でさ。
結果、CSSにすら移行出来ないサイトだけがjQueryを使い続けることになり、それは馬鹿にされるのも当然だよ。
そして今の君のような人に対する反動として、10年後に噴出する、というわけさ。
>>350
『今から』10年後な。
jQueryが必要ではなくなってから15年後、ってことだよ。
「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
354デフォルトの名無しさん
2018/11/09(金) 15:32:39.21ID:YLhQ0tUv いちいちなげーんだよ
ここ質問スレだよな?よそ行ってやってくれんか
ここ質問スレだよな?よそ行ってやってくれんか
355デフォルトの名無しさん
2018/11/09(金) 18:34:41.79ID:ya9Twat2 >>349
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねw
document.querySelectorAll()を$()と書けるようにする方法
方法1:
var $ = document.querySelectorAll.bind(document)
(48文字、minifyで46文字)
方法2:
jQueryのロード
(minify + gzipで約30,000文字w)
ブラウザがgzip解凍後の約85,000文字のjsで書かれたjQueryコードをパース、コンパイルwww
結構な時間です
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization/#parsecompile
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねw
document.querySelectorAll()を$()と書けるようにする方法
方法1:
var $ = document.querySelectorAll.bind(document)
(48文字、minifyで46文字)
方法2:
jQueryのロード
(minify + gzipで約30,000文字w)
ブラウザがgzip解凍後の約85,000文字のjsで書かれたjQueryコードをパース、コンパイルwww
結構な時間です
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization/#parsecompile
356デフォルトの名無しさん
2018/11/09(金) 19:52:57.84ID:UVRb8J0Z >>353
やっぱり、実行速度しか頭にないのなw
視野狭過ぎでワロタw
実行速度も何が何でも速いと思ってる。
そんなに実行速度が重要ならブラウザ使うの止めたほうが良い
速度は許容範囲かどうかで決めるものだ
今jQueryを使ってるサイトは、jQueryの速度が許容範囲ってことだ
なにせ一回読み込めばキャッシュが効くからな
遅いのは最初の一回だけという
> ただ、既に書いたように、jQueryはHTMLベースになる点(なりがちな点)が本質的に筋が悪いんだよ。
ウェブはHTMLベースで書くのだから仕方ないな。むしろHTMLベースで使いにくいものはだめだろう
> 『今から』10年後な。
「jQueryはオワコン(10年後にな!)」
もうこれ完全に不安煽ってるもの以外の何物でしか無いわw
> 「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
暗記済みの状態で楽なのはjQuery。覚えるのが嫌いな人っているよね
覚える苦労をして、後の開発を楽にする
VS
覚えるのが嫌だから、開発で大変な思いをしてまで、今楽をしたい
> 君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
切れないが? ソフトウェア開発において覚えることこそが技術力だし。そうやって覚えてしまうことで
読まなくて良いコードを増やしていくことで、開発速度はあげられる。
もっとも何でも覚えられるわけがないので、より汎用性があって世間でよく使われてるものに限ったほうが良い
つまり、オレオレライブラリなんか覚える価値がないってことな
やっぱり、実行速度しか頭にないのなw
視野狭過ぎでワロタw
実行速度も何が何でも速いと思ってる。
そんなに実行速度が重要ならブラウザ使うの止めたほうが良い
速度は許容範囲かどうかで決めるものだ
今jQueryを使ってるサイトは、jQueryの速度が許容範囲ってことだ
なにせ一回読み込めばキャッシュが効くからな
遅いのは最初の一回だけという
> ただ、既に書いたように、jQueryはHTMLベースになる点(なりがちな点)が本質的に筋が悪いんだよ。
ウェブはHTMLベースで書くのだから仕方ないな。むしろHTMLベースで使いにくいものはだめだろう
> 『今から』10年後な。
「jQueryはオワコン(10年後にな!)」
もうこれ完全に不安煽ってるもの以外の何物でしか無いわw
> 「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
暗記済みの状態で楽なのはjQuery。覚えるのが嫌いな人っているよね
覚える苦労をして、後の開発を楽にする
VS
覚えるのが嫌だから、開発で大変な思いをしてまで、今楽をしたい
> 君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
切れないが? ソフトウェア開発において覚えることこそが技術力だし。そうやって覚えてしまうことで
読まなくて良いコードを増やしていくことで、開発速度はあげられる。
もっとも何でも覚えられるわけがないので、より汎用性があって世間でよく使われてるものに限ったほうが良い
つまり、オレオレライブラリなんか覚える価値がないってことな
357デフォルトの名無しさん
2018/11/09(金) 19:54:07.17ID:UVRb8J0Z358デフォルトの名無しさん
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おじさん仕事できなさそうwwwww
ゴキブリ倒すのに戦車持ってくるみたいなwwwww
<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おじさん仕事できなさそうwwwww
ゴキブリ倒すのに戦車持ってくるみたいなwwwww
360デフォルトの名無しさん
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ベースの奴は取り残され、馬鹿にされるポジションになる、というのが俺の見立てであってさ。
> ソフトウェア開発において覚えることこそが技術力だし。
これは違う。やはり君はプログラマではない。だから分かる必要もないんだが、
ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
ただ、HTMLベースでやると、君みたいに暗記主体の積み上げ方式で出来るのも事実なんだよ。
だから、君のタイプは今後ともjQueryを使い続けた方が効率はいいし、おそらく君はそうするだろう。
一方、ある程度の能力を備えたプログラマにとっては、抽象化が使えるCSSベースの方が効率がいい。
そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、
強烈に嫌う奴も出てくるわけでさ。
同様のことはPHPにも言える。
PHPも仕様が糞すぎて、いちいち場合分けが必要になり、プログラミング上級者でも綺麗に書けなかったりする。
だから、上級者こそPHPを目の敵にする。
ところが、初心者〜中級者成り立ての程度なら、あれくらいのベタさ加減が丁度いい。
そして、自分達よりも綺麗に書ける上級者が存在しないから、彼等にとってはそれなりに快適な状況になってる。
ただ、上質なコードがその世界に存在しないことは本当に問題で、
結果、上質なコードを見たことがないから、PHPerは自分達のコードがトンデモだ、ということに気づけないでいる。
それがPHPerがやたら叩かれている理由だよ。
彼等の自己評価と、外部から見た客観評価に、ズレが有りすぎるのさ。
ま、これは正直、俺はJavaScripterにも当てはまると思っているけどね。
分かるか?両者が矛盾しているわけではないんだよ。
jQueryを使った方が効率がいいタイプもいれば、jQueryを捨てた方が効率がいいタイプもいる。
暗記ベースなら前者で、抽象化ベースなら後者だ。そして一般のプログラマは後者なんだよ。
だから今後ともjQuery不要論はずっと水掛け論になるんだよ。
言ってしまえばお互いポジショントークをしているにすぎないから。
ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、
CSSで行ける奴、或いは両方とも出来る奴は、CSSベースを選択することになる。
結果、HTMLベースの奴は取り残され、馬鹿にされるポジションになる、というのが俺の見立てであってさ。
361デフォルトの名無しさん
2018/11/09(金) 21:09:46.39ID:UVRb8J0Z >>360
> ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
お前、論理的な思考が出来てないなw
俺は覚えることが重要だと言ったが、抽象化能力とその応用力が不要などとは一言も言ってない
また暗記とは言ってない。細かい違いだが、どんな機能があるか覚えていればいいだけ
暗記(何も見ないでかけるようにしろ)とまでは言ってない
覚えることが重要だと言ったが、お前は覚えることは重要ではないと言うわけか?
少ない語群だと、文章を適切に伝えられないぞ
数学で数式を使うのは、短い文章(数式)で正確に意味を伝えるためだ。
数式を覚えてないなら、長い文章を読み書きしなければいけなくなる
それをソフトウェアでは「冗長」という。
「冗長」はバグを増やしテスト時間を増やすことにつながる
jQueryはその「冗長」を減らしてくれる。
> ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
お前、論理的な思考が出来てないなw
俺は覚えることが重要だと言ったが、抽象化能力とその応用力が不要などとは一言も言ってない
また暗記とは言ってない。細かい違いだが、どんな機能があるか覚えていればいいだけ
暗記(何も見ないでかけるようにしろ)とまでは言ってない
覚えることが重要だと言ったが、お前は覚えることは重要ではないと言うわけか?
少ない語群だと、文章を適切に伝えられないぞ
数学で数式を使うのは、短い文章(数式)で正確に意味を伝えるためだ。
数式を覚えてないなら、長い文章を読み書きしなければいけなくなる
それをソフトウェアでは「冗長」という。
「冗長」はバグを増やしテスト時間を増やすことにつながる
jQueryはその「冗長」を減らしてくれる。
362デフォルトの名無しさん
2018/11/09(金) 21:13:01.24ID:UVRb8J0Z > ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、
HTMLベース VS CSSベースの話をしてるのは
お前だけだけどなw
意味がさっぱりわからんし。
適切な構造でHTMLを書いて、それに合うようにCSSでデザインするだけの話
最後にCSSでもできないことがあれば、JavaScriptを使う
アニメーションとか昔に比べてCSSでできることも多くなったしね。
それがウェブサイトの基本だよ。
基本なのでこれは変わることがない
HTMLベース VS CSSベースの話をしてるのは
お前だけだけどなw
意味がさっぱりわからんし。
適切な構造でHTMLを書いて、それに合うようにCSSでデザインするだけの話
最後にCSSでもできないことがあれば、JavaScriptを使う
アニメーションとか昔に比べてCSSでできることも多くなったしね。
それがウェブサイトの基本だよ。
基本なのでこれは変わることがない
363デフォルトの名無しさん
2018/11/09(金) 21:15:44.51ID:UVRb8J0Z > そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、
あ、コレ言うやつよくいるよなw
糖衣構文"でしかない" というやつ
俺は、糖衣構文という素晴らしいもの という立場だからな
なぜ他のやり方でもできることなのに、わざわざ糖衣構文があるのか?
それは、糖衣構文があれば簡潔に正確に意味と意図を表現できるから
数式と一緒
あ、コレ言うやつよくいるよなw
糖衣構文"でしかない" というやつ
俺は、糖衣構文という素晴らしいもの という立場だからな
なぜ他のやり方でもできることなのに、わざわざ糖衣構文があるのか?
それは、糖衣構文があれば簡潔に正確に意味と意図を表現できるから
数式と一緒
364デフォルトの名無しさん
2018/11/09(金) 21:19:21.42ID:UVRb8J0Z あとPHPのはないウザい。関係ない話だろ。
自分が嫌いなものは嫌いって言って全部一緒くたにしてる証拠
客観的に物事を見れてない
自分が嫌いなものは嫌いって言って全部一緒くたにしてる証拠
客観的に物事を見れてない
365デフォルトの名無しさん
2018/11/09(金) 21:28:50.89ID:LcYc+UJI あとjQueryのはないウザい。関係ない話だろ。
言語(Javascript)とその言語で書かれたライブラリ(jQuery)一緒くたにしてる証拠
客観的に物事を見れてない
言語(Javascript)とその言語で書かれたライブラリ(jQuery)一緒くたにしてる証拠
客観的に物事を見れてない
366デフォルトの名無しさん
2018/11/09(金) 22:20:39.53ID:UVRb8J0Z jQueryはJavaScript用のライブラリなので関係あり
367デフォルトの名無しさん
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/
↓の専用スレに行け。なんで行かないの?
+ JavaScript & jQuery 質問用スレッド vol.8 +
https://mevius.5ch.net/test/read.cgi/hp/1510321470/
368デフォルトの名無しさん
2018/11/09(金) 22:49:20.88ID:UVRb8J0Z369デフォルトの名無しさん
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年かけて)衰退する」だね。
> 適切な構造で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年かけて)衰退する」だね。
370デフォルトの名無しさん
2018/11/10(土) 00:16:23.59ID:8OkJCHKT > 君が言っているのはHTMLベースだ。(HTMLがマスタデータ)
> それだと、どうしても開発効率が上がらないんだよ。
???
え、なんで?
例えばHTMLに「こんにちは」って書く場合
HTML以外の何を使ったら、どう開発効率が上がるんだ?
もう少し、○○という理由で、開発効率が上がるって書いてくんない?
根拠が待った書いてないからさ
> それだと、どうしても開発効率が上がらないんだよ。
???
え、なんで?
例えばHTMLに「こんにちは」って書く場合
HTML以外の何を使ったら、どう開発効率が上がるんだ?
もう少し、○○という理由で、開発効率が上がるって書いてくんない?
根拠が待った書いてないからさ
371デフォルトの名無しさん
2018/11/10(土) 00:17:12.68ID:8OkJCHKT > 理由は簡単で、変更の多いHTMLおよびCSSが上流に来ているから。
> HTML/CSSを変更するたびにJavaScriptまで変更/検証する必要があり、ループが大きいんだよ。
おまえ、下手なんじゃね?
JavaScriptはHTMLの変更に影響をつけないように作れよ
ほんと、下手
> HTML/CSSを変更するたびにJavaScriptまで変更/検証する必要があり、ループが大きいんだよ。
おまえ、下手なんじゃね?
JavaScriptはHTMLの変更に影響をつけないように作れよ
ほんと、下手
372デフォルトの名無しさん
2018/11/10(土) 00:17:32.18ID:8OkJCHKT 訂正 影響をうけないように作れよ
373デフォルトの名無しさん
2018/11/10(土) 00:21:25.82ID:8OkJCHKT HTMLは文章は変わるが、HTMLの構造は一旦決めたら変わらないんだぜ
トップページ、一覧ページ、詳細ページ
これぐらいの区別があるだけ、ページごとにHTMLの
構造が変わっていたら、見づらいだろ
そしてJavaScriptは、特定のクラスに対して処理しますって書くだけ
ウェブデザイナさんに、こういうクラスつけておいてくださいね。
そのクラスつけておいたところは、こうなりますから〜って伝えるだけ
クラス設計?そんな大げさなものじゃない。
1つ(ないし数個)クラスを作って伝えるだけ
トップページ、一覧ページ、詳細ページ
これぐらいの区別があるだけ、ページごとにHTMLの
構造が変わっていたら、見づらいだろ
そしてJavaScriptは、特定のクラスに対して処理しますって書くだけ
ウェブデザイナさんに、こういうクラスつけておいてくださいね。
そのクラスつけておいたところは、こうなりますから〜って伝えるだけ
クラス設計?そんな大げさなものじゃない。
1つ(ないし数個)クラスを作って伝えるだけ
374デフォルトの名無しさん
2018/11/10(土) 00:23:17.53ID:8OkJCHKT > CSSベースってのは、CSSクラスをまず設計して(マスタはCSSクラス)、それに対してJavaScriptを書き、
> そこに合うようにHTMLを書いて、最後に再びCSSで装飾を付けるんだよ。
> まともなサイトはほぼ全てこれだから、見てみればいい。
つまりCSSクラスを最初に設計して、JavaScriptを書くから、
jQueryが適してるって話にしかなってないんだが?
> そこに合うようにHTMLを書いて、最後に再びCSSで装飾を付けるんだよ。
> まともなサイトはほぼ全てこれだから、見てみればいい。
つまりCSSクラスを最初に設計して、JavaScriptを書くから、
jQueryが適してるって話にしかなってないんだが?
375デフォルトの名無しさん
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ベースだなw
繰り返すがCSSベースはjQueryと非常に相性がいい
.foo { color: red }
$('.foo').css({ color: 'red' })
書き方が違う程度で非常に近い書き方ができる。
セレクタに対して何かを適用するという考え、
セレクタベースだからだ
querySelectorAllだとこうは書けない。
単にセレクタで検索するだけだから、
その後ループして処理するという発想になる
CSSベースの開発ではjQueryを使うのが相性がいいし
そこがDOM APIでは越えられない壁。
あとどうも俺をHTMLベースとか言ってるようだが、
HTMLベースとCSSベースを分けて考えるなら、
俺はCSSベースだなw
繰り返すがCSSベースはjQueryと非常に相性がいい
376デフォルトの名無しさん
2018/11/10(土) 00:30:27.85ID:8OkJCHKT >>329を見ればわかるが
> 世界の大半を占めるウェブサイトは
> 「まず最初にHTML+CSSを書く」ということを
> しっかりと認識するようにな
最初に書くのは「HTML+CSS」だ
俺はHTMLを書いて、それに対してjQueryで処理しろとかいう話はしてない
何故か勝手に俺がHTMLベースだと決めつけられたw
jQueryはCSSベースになるし、CSSベースはjQueryと相性がいい
> 世界の大半を占めるウェブサイトは
> 「まず最初にHTML+CSSを書く」ということを
> しっかりと認識するようにな
最初に書くのは「HTML+CSS」だ
俺はHTMLを書いて、それに対してjQueryで処理しろとかいう話はしてない
何故か勝手に俺がHTMLベースだと決めつけられたw
jQueryはCSSベースになるし、CSSベースはjQueryと相性がいい
377デフォルトの名無しさん
2018/11/10(土) 00:58:59.92ID:VOHXjVDU まあ、君は、他のサイトをよく見て学べばいいと思うよ。多分それで解決する。
今のままなら、「jQueryおじさん」だな。
今のままなら、「jQueryおじさん」だな。
378デフォルトの名無しさん
2018/11/10(土) 01:01:02.16ID:nSd/jMeD バカかなこいつ。jsで書かれたライブラリなんだからjsでできることをまとめた関数以上でも以下でもない。
jQuery内部ではquerySelectorを使える環境ではquerySelectorを使うようになっている。
わざわざSizzleというセレクタライブラリを内包しているのになぜ?
それは遅いからwwwww
jQuery内部ではquerySelectorを使える環境ではquerySelectorを使うようになっている。
わざわざSizzleというセレクタライブラリを内包しているのになぜ?
それは遅いからwwwww
379デフォルトの名無しさん
2018/11/10(土) 01:12:03.37ID:liG2pvs9 自分が依存してるホスト言語様にケンカ売るとかwww何様のつもりだよ替えのきくライブラリのクセにwwww
380デフォルトの名無しさん
2018/11/10(土) 01:17:01.24ID:8OkJCHKT >>378
> わざわざSizzleというセレクタライブラリを内包しているのになぜ?
1. 昔はブラウザにquerySelectorが搭載されていなかった
2. ブラウザ間で対応しているセレクタの違いに対応するため
3: :has擬似クラスのような今のブラウザ使えないが、標準化される見通しのセレクタに対応している
4. :inputセレクタのようなjQueryによって拡張された便利なセレクタが使える
5. セレクタの拡張機能を使って独自のセレクタを作成可能
6. 特定ブラウザのセレクタバグの回避
こんなところかな
> わざわざSizzleというセレクタライブラリを内包しているのになぜ?
1. 昔はブラウザにquerySelectorが搭載されていなかった
2. ブラウザ間で対応しているセレクタの違いに対応するため
3: :has擬似クラスのような今のブラウザ使えないが、標準化される見通しのセレクタに対応している
4. :inputセレクタのようなjQueryによって拡張された便利なセレクタが使える
5. セレクタの拡張機能を使って独自のセレクタを作成可能
6. 特定ブラウザのセレクタバグの回避
こんなところかな
381デフォルトの名無しさん
2018/11/10(土) 01:17:36.71ID:8OkJCHKT382デフォルトの名無しさん
2018/11/10(土) 01:18:08.03ID:8OkJCHKT383デフォルトの名無しさん
2018/11/10(土) 01:23:38.77ID:NL2nbxgf JQueryはWeb業界のCOBOLとして残るやろ
どんなに新しくて思想が素晴らし技術でもも土方が使いこなして
コピペ量産できるレベルじゃないのと流行らず終わってしまう
どんなに新しくて思想が素晴らし技術でもも土方が使いこなして
コピペ量産できるレベルじゃないのと流行らず終わってしまう
384デフォルトの名無しさん
2018/11/10(土) 01:35:42.00ID:8OkJCHKT COBOLとの違いはDOMよりも優れているってことかな
jQueryはDOM APIと違ってCSSベースだからね
jQueryはDOM APIと違ってCSSベースだからね
385デフォルトの名無しさん
2018/11/10(土) 01:48:58.01ID:QAct5bTi >>383
COBOLは神格化しすぎだろw
COBOLは神格化しすぎだろw
386デフォルトの名無しさん
2018/11/10(土) 01:51:41.18ID:z7ZsqvtS jqueryはEventEmitter的なやつが入ってるも便利なんだよなあ
387デフォルトの名無しさん
2018/11/10(土) 03:31:41.00ID:1Rgn5iVr ブラウザ非互換の対応をしようとすると結局ライブラリ作る羽目になるんじゃないの。
おれも極力素のJSで軽量に済ませるようにしてるけど、やっぱそういう下らない作業からは解放されたいな。
おれも極力素のJSで軽量に済ませるようにしてるけど、やっぱそういう下らない作業からは解放されたいな。
388デフォルトの名無しさん
2018/11/10(土) 03:54:33.43ID:z7ZsqvtS .ready()みたいなやつを自分で書くのが地味に面倒
389デフォルトの名無しさん
2018/11/10(土) 07:01:00.07ID:3aLGJBed 自分とこはもう全部type=moduleでやってて
どうしても必要なとこではnomodule使うけど
基本的にIEとかではJS働かせてないな
もう確認もしてないし
あとはCanvasを積極的に使うのが互換性対処の肝かな
そうすればあってもちょっとした条件分岐くらいで
ライブラリ規模のをつくることはまず無くなる
どうしても必要なとこではnomodule使うけど
基本的にIEとかではJS働かせてないな
もう確認もしてないし
あとはCanvasを積極的に使うのが互換性対処の肝かな
そうすればあってもちょっとした条件分岐くらいで
ライブラリ規模のをつくることはまず無くなる
390デフォルトの名無しさん
2018/11/10(土) 07:28:09.30ID:8OkJCHKT とまあ、ウェブサイトではまず使わないCanvasとか言ってる時点で
ウェブでは例外にあたるサイトの話なわけでw
どうせゲームだろうな
ウェブでは例外にあたるサイトの話なわけでw
どうせゲームだろうな
391デフォルトの名無しさん
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を初めて、まだキャズムを越えてないから大騒ぎしてる、ってとこか?
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を初めて、まだキャズムを越えてないから大騒ぎしてる、ってとこか?
392デフォルトの名無しさん
2018/11/10(土) 10:30:19.15ID:omLk2QsU ゲームだけでは無いよ
vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
まあそれがjQueryの代わりっちゃ代わりのようなもんか
イベントバブリングやアニメーションも対応してるし、
操作対象をDOMにしたり、混合させて利用する事もできる
普通じゃないって言うけど、HTML5以降Webって言うのは
アプリケーションプラットフォームになったという認識で作ってる
vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
まあそれがjQueryの代わりっちゃ代わりのようなもんか
イベントバブリングやアニメーションも対応してるし、
操作対象をDOMにしたり、混合させて利用する事もできる
普通じゃないって言うけど、HTML5以降Webって言うのは
アプリケーションプラットフォームになったという認識で作ってる
393デフォルトの名無しさん
2018/11/10(土) 10:38:12.43ID:8OkJCHKT >>391
> だからお前はHTMLベースだし、大半のjQuery使用者もHTMLベースなんだよ。
CSSベースだってw
jQueryがCSSと相性がいいのわかってるだろ?
それにDOM APIはHTMLベースってことになるのわかっていってるのか?
> だからお前はHTMLベースだし、大半のjQuery使用者もHTMLベースなんだよ。
CSSベースだってw
jQueryがCSSと相性がいいのわかってるだろ?
それにDOM APIはHTMLベースってことになるのわかっていってるのか?
394デフォルトの名無しさん
2018/11/10(土) 10:39:14.50ID:8OkJCHKT >>391
> 脱jQueryをやったサイトを確認して、(最近ならGitubか?)
> 何故彼等はそういう判断をしたのか、結果、どう変わったのか、
どう変わったのか言ってみ?
俺、変わった所、全然わからない。
> 脱jQueryをやったサイトを確認して、(最近ならGitubか?)
> 何故彼等はそういう判断をしたのか、結果、どう変わったのか、
どう変わったのか言ってみ?
俺、変わった所、全然わからない。
395デフォルトの名無しさん
2018/11/10(土) 10:41:54.49ID:8OkJCHKT >>392
> アプリケーションプラットフォームになったという認識で作ってる
アプリケーションプラットフォームとしても使えるようになったからって
俺もアプリ作るぞーってなると思う?w
上の方でも言ったけど、ウェブがアプリケーションプラットフォームとなって
変わるのは、ウェブサイトじゃない。
デスクトップや家庭用ゲーム機やスマホアプリの世界から
人が去っていくことになるだけだよ。変わるのはそこ
> アプリケーションプラットフォームになったという認識で作ってる
アプリケーションプラットフォームとしても使えるようになったからって
俺もアプリ作るぞーってなると思う?w
上の方でも言ったけど、ウェブがアプリケーションプラットフォームとなって
変わるのは、ウェブサイトじゃない。
デスクトップや家庭用ゲーム機やスマホアプリの世界から
人が去っていくことになるだけだよ。変わるのはそこ
396デフォルトの名無しさん
2018/11/10(土) 10:44:33.37ID:8OkJCHKT ウェブサイトは今のままウェブサイト
ウェブサイトがアプリになるわけがない
だからWebAssemblyとか、jQueryの代替じゃないんだよ。
jQueryをやめて使うものじゃない。
WebAssemblyとかは.NET FrameworkやDirectXや
OpenGLやUnityをやめて使うものなんだよ
ウェブサイトがアプリになるわけがない
だからWebAssemblyとか、jQueryの代替じゃないんだよ。
jQueryをやめて使うものじゃない。
WebAssemblyとかは.NET FrameworkやDirectXや
OpenGLやUnityをやめて使うものなんだよ
397デフォルトの名無しさん
2018/11/10(土) 11:24:42.68ID:VOHXjVDU >>393
その意図的な誤用は止めろ。
「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。
HTMLベース:HTMLがマスタ
CSSベース:CSSクラスがマスタ
> それにDOM APIはHTMLベースってことになるのわかっていってるのか?
そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。
とにかくお前は他人がどういう作りにしているか、学んだ方がいいと思うぞ。
>>394
GitHubについてはスゲー変わったけどな。
分からないのなら、それでいいと思うよ。
ただ、変わった原因はjQueryでもないとも思うが。
GitHubは元々がポンコツすぎた。
その意図的な誤用は止めろ。
「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。
HTMLベース:HTMLがマスタ
CSSベース:CSSクラスがマスタ
> それにDOM APIはHTMLベースってことになるのわかっていってるのか?
そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。
とにかくお前は他人がどういう作りにしているか、学んだ方がいいと思うぞ。
>>394
GitHubについてはスゲー変わったけどな。
分からないのなら、それでいいと思うよ。
ただ、変わった原因はjQueryでもないとも思うが。
GitHubは元々がポンコツすぎた。
398デフォルトの名無しさん
2018/11/10(土) 11:25:42.07ID:1Rgn5iVr いい加減誰が何主張してるのか追う気も無くなってきたけど、結局どうしろと言ってるの。
自分の書いたサイトのURL貼って説明してみてよ。
自分の書いたサイトのURL貼って説明してみてよ。
399デフォルトの名無しさん
2018/11/10(土) 11:26:22.74ID:8OkJCHKT > 「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。
そうじゃない理由をいうかと言えば、何も言えないwww
> GitHubについてはスゲー変わったけどな。
変わった点を言うかと思えば何も言わないwww
ホント説得力皆無やでw
> そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。
jQueryはセレクタを書くだけでクエリはやりませんねw
そうじゃない理由をいうかと言えば、何も言えないwww
> GitHubについてはスゲー変わったけどな。
変わった点を言うかと思えば何も言わないwww
ホント説得力皆無やでw
> そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。
jQueryはセレクタを書くだけでクエリはやりませんねw
400デフォルトの名無しさん
2018/11/10(土) 11:26:53.09ID:VOHXjVDU >>392
> vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
これだよね。
フレームワークが流行らない一つの原因は、自前で用意しても出来てしまうこと。
> アプリケーションプラットフォームになったという認識で作ってる
プログラマはその認識で正しいと思うぜ。
ある意味、ドキュメントも、
・マークダウン等でHTMLを直接記述(少なくともHTML生成までは面倒を見る)…旧来手法
・テキストだけ書いて、ドキュメントアプリに流し込めばWebページ完成…アプリ的手法
があって、後者はブログなり静的HPフレームワークになるわけだが、
記事書きたい奴はhtmlを書きたいわけではないから、自然と後者によってくると俺は見ている。
とはいえ、そういう時代になっても、
とりあえず1回書けばいいだけなら、HTMLじか打ちの方が楽だし、旧来手法もある程度は残るだろうね。
> vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
これだよね。
フレームワークが流行らない一つの原因は、自前で用意しても出来てしまうこと。
> アプリケーションプラットフォームになったという認識で作ってる
プログラマはその認識で正しいと思うぜ。
ある意味、ドキュメントも、
・マークダウン等でHTMLを直接記述(少なくともHTML生成までは面倒を見る)…旧来手法
・テキストだけ書いて、ドキュメントアプリに流し込めばWebページ完成…アプリ的手法
があって、後者はブログなり静的HPフレームワークになるわけだが、
記事書きたい奴はhtmlを書きたいわけではないから、自然と後者によってくると俺は見ている。
とはいえ、そういう時代になっても、
とりあえず1回書けばいいだけなら、HTMLじか打ちの方が楽だし、旧来手法もある程度は残るだろうね。
401デフォルトの名無しさん
2018/11/10(土) 11:30:27.31ID:8OkJCHKT jQueryはCSSベースなのでCSSと相性がいい。
例えば、jQueryでCSSと同じように色を付ける場合、
CSSで書いたのと同じように "セレクタ" に "色を指定" する
まあCSSの範囲はCSSでやればいいんだが、
jQueryはデザインじゃなくて、イベントに関しても
CSSと似たような形で、 "セレクタ" に "イベントをバインド" する
CSSは要素がなくてもエラーにならないが、jQueryも同じように
要素がなくてもエラーにならない。CSSと非常によく似ている。
例えば、jQueryでCSSと同じように色を付ける場合、
CSSで書いたのと同じように "セレクタ" に "色を指定" する
まあCSSの範囲はCSSでやればいいんだが、
jQueryはデザインじゃなくて、イベントに関しても
CSSと似たような形で、 "セレクタ" に "イベントをバインド" する
CSSは要素がなくてもエラーにならないが、jQueryも同じように
要素がなくてもエラーにならない。CSSと非常によく似ている。
402デフォルトの名無しさん
2018/11/10(土) 11:30:35.49ID:1Rgn5iVr HTMLベースとかCSSベースってのもどういった概念を指してるのかわからないけど、セレクタで抽出したエレメントを操作するのがHTMLベースで、CSSクラスの定義を操作するのがCSSベースってこと?
403デフォルトの名無しさん
2018/11/10(土) 11:32:04.04ID:8OkJCHKT アプリケーション開発のプラットフォームは
jQueryの代替にはなりえない。
重要な点の一つだね。
みんながみんなアプリケーションを開発しているわけじゃない
ウェブの殆どはサイト
みんなが見てるのは、ウェブサイト
jQueryの代替にはなりえない。
重要な点の一つだね。
みんながみんなアプリケーションを開発しているわけじゃない
ウェブの殆どはサイト
みんなが見てるのは、ウェブサイト
404デフォルトの名無しさん
2018/11/10(土) 11:32:59.22ID:8OkJCHKT405デフォルトの名無しさん
2018/11/10(土) 11:43:58.85ID:VOHXjVDU >>399
jQueryおじさんは、違いの分からない男であったか…
(もっとも、このスレにはこれが分かるおっさんの方が少数派の気もするが)
つか、あれで分からないのなら、感度がないんだよ。
こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。
jQueryおじさんは、違いの分からない男であったか…
(もっとも、このスレにはこれが分かるおっさんの方が少数派の気もするが)
つか、あれで分からないのなら、感度がないんだよ。
こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。
406デフォルトの名無しさん
2018/11/10(土) 11:45:15.02ID:8OkJCHKT407デフォルトの名無しさん
2018/11/10(土) 11:45:37.39ID:1Rgn5iVr408デフォルトの名無しさん
2018/11/10(土) 11:46:24.46ID:8OkJCHKT > こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。
なんの話?
jQueryは今も世界中で動いていますね
世界の7割を超えるサイトで使われてるので
普通にサイト見てるだけでjQueryが問題なく動くことが証明できてる
なんの話?
jQueryは今も世界中で動いていますね
世界の7割を超えるサイトで使われてるので
普通にサイト見てるだけでjQueryが問題なく動くことが証明できてる
409デフォルトの名無しさん
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自体は宣言型で設計されてるんだよ。
> セレクタに対して処理をするんじゃなく、セレクタでセレクトされたエレメントを操作するんだよね。
いや、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自体は宣言型で設計されてるんだよ。
410デフォルトの名無しさん
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ベースには「マスタデータが直接見える為、ものすごくデバッグし易い」という大きな利点があって、
つまりはこれが蔓延る原因となっている。
その解釈であってるが、詳細は以下。
>>402
ああ、それは俺がここで使っている用語だからな。
ただ、一般解釈できる呼称にしているつもりだ。
要は、マスタデータをどこに持つか、ということ。
HTMLベース:HTMLがマスタ
CSSベース:CSSクラスがマスタ(この呼称が良いかはさておき、他よりは誤解がないはず)
jQueryの典型的コードは、「クエリして、その結果のDOMに○○」というものだ。
ここで毎回クエリが必要なのは、HTMLがマスタデータだからだ。
そしてそのクエリが遅いから、動作がもっさりする。
一方、マスタデータがHTMLではない場合、クエリは当然必要ない。
アプリでは内部データがマスタであり、そこから一方的にHTMLを吐き出す。
PHP鯖も、DBからマスタデータを取り寄せ、一方的にHTMLを生成するだけで、DOMクエリなんてやらない。
「DOMクエリが必要なのは、DOMがマスタデータだから」だ。
で、彼はこの抽象化能力がないから、ここが通じずに話が空回りしてる。
DOMクエリが遅いのだから、高速化にはこれを『必要ない』構造にするのが一番いい。
そして、大半のマトモなサイトはそれを既にやっていて、「いちいち何かをする前にDOMクエリ」はしない。
結果、クエリ自体しないのだから、jQueryの利点もない、というだけの話。
彼は知らないから話が通じないだけ。
ただ、これを「CSSベース」というのが分かりやすいかは微妙で、そこが君の疑問点なのは妥当だが、
では、この場合何が「マスタデータ」に当たるかといわれれば、JavaScriptでもないしHTMLではないし、
敢えていうならCSSクラスかな、というところ。
なお、HTMLベースには「マスタデータが直接見える為、ものすごくデバッグし易い」という大きな利点があって、
つまりはこれが蔓延る原因となっている。
411デフォルトの名無しさん
2018/11/10(土) 12:15:14.62ID:omLk2QsU >>395
ちょっと考え方が違うんじゃない?
WebやHTMLは文書のための規格として始まったけど、
今ではそうじゃないじゃん?
Web3.0っていう言葉もあるけど、
まだ「インタラクティブな文書表示」とも言えたWeb2.0の段階を
だんだん超えてきてるとは思わない?
別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、
いつの間にか作ってるものが「文書」を越えたアプリケーションになっていくって言うのが
ある意味自然な流れだと思うよ
Webサイトって言うのがもう「文書を提供する為の場所」だけではどんどんなくなってると思うけどな
別にゲーム的なものに限らなくてもね
ちょっと考え方が違うんじゃない?
WebやHTMLは文書のための規格として始まったけど、
今ではそうじゃないじゃん?
Web3.0っていう言葉もあるけど、
まだ「インタラクティブな文書表示」とも言えたWeb2.0の段階を
だんだん超えてきてるとは思わない?
別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、
いつの間にか作ってるものが「文書」を越えたアプリケーションになっていくって言うのが
ある意味自然な流れだと思うよ
Webサイトって言うのがもう「文書を提供する為の場所」だけではどんどんなくなってると思うけどな
別にゲーム的なものに限らなくてもね
412デフォルトの名無しさん
2018/11/10(土) 12:18:08.67ID:1Rgn5iVr >>409
集合に対する処理系なのか自前でループするとかそんな話じゃなく、そのコードで言えば $('.foo') でセレクトされたエレメント(達)に対して .css({ color: 'red' }) という操作をしてるんでしょ?
それを HTMLベースと言っていて、foo のスタイルそのものを変更するアプローチが CSSベースと言ってるんじゃないのか、という確認だよ。
集合に対する処理系なのか自前でループするとかそんな話じゃなく、そのコードで言えば $('.foo') でセレクトされたエレメント(達)に対して .css({ color: 'red' }) という操作をしてるんでしょ?
それを HTMLベースと言っていて、foo のスタイルそのものを変更するアプローチが CSSベースと言ってるんじゃないのか、という確認だよ。
413デフォルトの名無しさん
2018/11/10(土) 12:24:49.10ID:8OkJCHKT >>411
> WebやHTMLは文書のための規格として始まったけど、
> 今ではそうじゃないじゃん?
なんで技術主導で考えてるんだよw
一番最初に来るのは「要求」何をしたいかだ。
いくら何かができるようになったとしても、
それを使ってなにかしたいという「要求」がなければ使わない
新しいことができるようになったからって
誰もが新しいことするわけじゃないんだよ。
スマホができたからって、誰もがスマホアプリ作ったりしないだろうが?
ウェブをアプリプラットフォームとして使いたいと思ってるのは
今アプリを作っている所で、ウェブサイトの世界からすればよそ者
> WebやHTMLは文書のための規格として始まったけど、
> 今ではそうじゃないじゃん?
なんで技術主導で考えてるんだよw
一番最初に来るのは「要求」何をしたいかだ。
いくら何かができるようになったとしても、
それを使ってなにかしたいという「要求」がなければ使わない
新しいことができるようになったからって
誰もが新しいことするわけじゃないんだよ。
スマホができたからって、誰もがスマホアプリ作ったりしないだろうが?
ウェブをアプリプラットフォームとして使いたいと思ってるのは
今アプリを作っている所で、ウェブサイトの世界からすればよそ者
414デフォルトの名無しさん
2018/11/10(土) 12:26:14.66ID:8OkJCHKT > 別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
> 表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、
起きてない。mozillaのウェブサイトだって、殆どが静的コンテンツ
ページ開くたびに音楽流すとか、アニメーション流すとか
3Dでキャラクターがグリグリとか、やらないからさw
> 表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、
起きてない。mozillaのウェブサイトだって、殆どが静的コンテンツ
ページ開くたびに音楽流すとか、アニメーション流すとか
3Dでキャラクターがグリグリとか、やらないからさw
415デフォルトの名無しさん
2018/11/10(土) 12:28:12.32ID:VOHXjVDU >>412
言う必要なさそうだが、その解釈であってる。
HTMLがマスタデータだから、更新時にはHTMLを更新しなければならない。
CSSクラスがマスタなら、更新時にはCSSクラスを更新(add/removeまたはスタイルリスト操作)することになる。
まあこの「CSSベース」が分かりやすい呼称かはさておき、
マスタデータが○○なら、○○ベース、と呼んでる。(今ここでは)
言う必要なさそうだが、その解釈であってる。
HTMLがマスタデータだから、更新時にはHTMLを更新しなければならない。
CSSクラスがマスタなら、更新時にはCSSクラスを更新(add/removeまたはスタイルリスト操作)することになる。
まあこの「CSSベース」が分かりやすい呼称かはさておき、
マスタデータが○○なら、○○ベース、と呼んでる。(今ここでは)
416デフォルトの名無しさん
2018/11/10(土) 12:28:25.73ID:8OkJCHKT >>412
> そのコードで言えば $('.foo') でセレクトされたエレメント(達)に対して .css({ color: 'red' }) という操作をしてるんでしょ?
だからjQueryはそういう発想で使うものじゃないってこと
間違った発想で使ってるやつが非常に多いのは事実だがね
だからjQueryはHTMLベースとか言い出すアホがでてくる
内部はそうなっていても、jQueryは宣言型として考えることができるようになってる。
ループも条件分岐も書かなくて良いようになってる
だから同じ宣言型のCSSと非常に相性が良い
> そのコードで言えば $('.foo') でセレクトされたエレメント(達)に対して .css({ color: 'red' }) という操作をしてるんでしょ?
だからjQueryはそういう発想で使うものじゃないってこと
間違った発想で使ってるやつが非常に多いのは事実だがね
だからjQueryはHTMLベースとか言い出すアホがでてくる
内部はそうなっていても、jQueryは宣言型として考えることができるようになってる。
ループも条件分岐も書かなくて良いようになってる
だから同じ宣言型のCSSと非常に相性が良い
417デフォルトの名無しさん
2018/11/10(土) 12:31:22.88ID:8OkJCHKT jQueryはCSSベースなので、具体的なHTMLタグのことは考慮しない。
できるかどうかは置いといて、jQueryはクラスベースでプログラミングする
特定の名前のクラスの要素(それがHTMLのどのタグかは意識しない)を
どのようにするかという宣言で書いていく
CSSのクラスベースなのでHTMLがどのように変わっても問題ない。
jQueryではCSSを直接変えるのは基本的にしないでCSSクラスの更新を行う
jQueryでやるのはCSSクラスの更新=状態の変化だけだ
できるかどうかは置いといて、jQueryはクラスベースでプログラミングする
特定の名前のクラスの要素(それがHTMLのどのタグかは意識しない)を
どのようにするかという宣言で書いていく
CSSのクラスベースなのでHTMLがどのように変わっても問題ない。
jQueryではCSSを直接変えるのは基本的にしないでCSSクラスの更新を行う
jQueryでやるのはCSSクラスの更新=状態の変化だけだ
418デフォルトの名無しさん
2018/11/10(土) 12:35:11.86ID:1Rgn5iVr >>410
CSSベースのアプローチの真髄が分からんのだけど、HTML の構造に縛られなくなっても CSS の構造に縛られるようになるんじゃないの?
改修する時にはどのみちどちらかには手が入るからJS側の調整も無くなるわけじゃないだろうし、やりたいことの全部が CSS だけでできるわけでもないだろうし。
まあエレメント抽出なんてする必要が無いと言ってるわけじゃなく、基本をどっちに置くか程度の話だと思うけど。
まあおれも何するにも $('.foo') で始めるのはどうかと思うよ。コスト的に。
でも操作対象は明確だから、書き方としては悪くないと思う。
CSSベースのアプローチの真髄が分からんのだけど、HTML の構造に縛られなくなっても CSS の構造に縛られるようになるんじゃないの?
改修する時にはどのみちどちらかには手が入るからJS側の調整も無くなるわけじゃないだろうし、やりたいことの全部が CSS だけでできるわけでもないだろうし。
まあエレメント抽出なんてする必要が無いと言ってるわけじゃなく、基本をどっちに置くか程度の話だと思うけど。
まあおれも何するにも $('.foo') で始めるのはどうかと思うよ。コスト的に。
でも操作対象は明確だから、書き方としては悪くないと思う。
419デフォルトの名無しさん
2018/11/10(土) 12:40:02.46ID:1Rgn5iVr420デフォルトの名無しさん
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要素に対してこの処理が適用される
条件分岐も不要で、クラスを変えることでデザインを適用する
というのをCSSで書くと
a:hover { color: red } となる
ループ的なものはなく、このように宣言するだけで、
全てのa要素に対してこの処理が適用される
これをjQueryでシミュレートするならば、まず
a.hover { color: red } とクラスに変えておいてjQueryでは以下のようにする
$('a').hover(function(event) {
$(this).toggleClass('hover', event.type == 'mouseenter')
});
ループ的なものはなく、このように宣言するだけで、
全てのa要素に対してこの処理が適用される
条件分岐も不要で、クラスを変えることでデザインを適用する
421デフォルトの名無しさん
2018/11/10(土) 12:43:20.01ID:VOHXjVDU >>406
>>408
お前はまず全部読んでから、整理して回答する癖を付けろ
> なんの話?
GitHubの話に決まってるだろ
>>409
なるほど君は典型的なjQuery廚か。まあ、この点は分かりやすくていいね。
そうだ。それがjQueryの典型的な書き方で、結果、ものすごくもっさりするのも事実だ。
そしてjQuery厨は君のようにそれを「大正義」だと思っているらしく、
どんなにもっさりしていてもその書き方を止めない。
「宣言型」だからこの書き方の方が素晴らしい!と本気で勘違いしてる。
ただ、プログラミングってのは手段であって、目的ではない。
ユーザーは、そのサイトが快適かどうかは気にするが、中身のソースコードなんて気にしない。
宣言型の方がソースコードの管理は楽だし、HTMLベースの方がデバッグしやすいのも事実だが、
ユーザーエクスペリエンスを損ねるようでは意味がない。
ただ、CSSベースでも宣言型ではあるし、実際そんなに難しくもならないから、まともなところは既に移行済みだ。
そしてjQuery廚だけが取り残されつつある、というのが今だね。
>>408
お前はまず全部読んでから、整理して回答する癖を付けろ
> なんの話?
GitHubの話に決まってるだろ
>>409
なるほど君は典型的なjQuery廚か。まあ、この点は分かりやすくていいね。
そうだ。それがjQueryの典型的な書き方で、結果、ものすごくもっさりするのも事実だ。
そしてjQuery厨は君のようにそれを「大正義」だと思っているらしく、
どんなにもっさりしていてもその書き方を止めない。
「宣言型」だからこの書き方の方が素晴らしい!と本気で勘違いしてる。
ただ、プログラミングってのは手段であって、目的ではない。
ユーザーは、そのサイトが快適かどうかは気にするが、中身のソースコードなんて気にしない。
宣言型の方がソースコードの管理は楽だし、HTMLベースの方がデバッグしやすいのも事実だが、
ユーザーエクスペリエンスを損ねるようでは意味がない。
ただ、CSSベースでも宣言型ではあるし、実際そんなに難しくもならないから、まともなところは既に移行済みだ。
そしてjQuery廚だけが取り残されつつある、というのが今だね。
422デフォルトの名無しさん
2018/11/10(土) 12:45:37.73ID:8OkJCHKT そういや、仮想DOMは最終的に遅いっていう話があったな
仮想lDOMはDOM全部入れ替えよりも速いというだけで
そもそもDOM全部入れ替えなんてしねーよという話
仮想lDOMはDOM全部入れ替えよりも速いというだけで
そもそもDOM全部入れ替えなんてしねーよという話
423デフォルトの名無しさん
2018/11/10(土) 12:46:04.24ID:8OkJCHKT424デフォルトの名無しさん
2018/11/10(土) 12:46:39.27ID:8OkJCHKT > ユーザーエクスペリエンスを損ねるようでは意味がない。
はい、宣言型のjQuery使って
ユーザーエクスペリエンスを損ないません。
はい、宣言型のjQuery使って
ユーザーエクスペリエンスを損ないません。
425デフォルトの名無しさん
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ベースにしても、特段分かりにくくなるわけでもないのも事実で、
実際に軽くなるんだからまともな奴はみんなそうしてる、ってだけでさ。
指摘はその通り。一応いちいち確認しておくと、以下。
> 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ベースにしても、特段分かりにくくなるわけでもないのも事実で、
実際に軽くなるんだからまともな奴はみんなそうしてる、ってだけでさ。
426デフォルトの名無しさん
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ベースで合ってる?
つかそれはそれとしてルールへのスマートなアクセスのやり方教えて。
$('.foo').css({ color: 'blue' }) とやったら HTMLベースと言ってるのは合ってると思うが、
document.getElementById('css1').sheet.cssRules[0].style['color'] = 'blue'; とやったら CSSベースで合ってる?
つかそれはそれとしてルールへのスマートなアクセスのやり方教えて。
427デフォルトの名無しさん
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をいじらない、というわけではない。ましな方を適宜選択するだけ。
スタイルルールをいちいち書き換えるコードは、あまり使っている奴は居ないと思うぞ。
それよりは、スタイルリストごと全部入れ替えてると思う。
> document.getElementById('css1').sheet.cssRules[0].style['color'] = 'blue'; とやったら CSSベースで合ってる?
いや、そこは普通にクラスを足す。具体的には、
e.target.classList.add('highlight') とか。
.foo.highlight {color:blue;} は当然最初から書いておく。
つかここら辺は普通のサイトはこうしてるから、見ればいいと思うよ。
絶対にHTMLをいじらない、というわけではない。ましな方を適宜選択するだけ。
スタイルルールをいちいち書き換えるコードは、あまり使っている奴は居ないと思うぞ。
それよりは、スタイルリストごと全部入れ替えてると思う。
428デフォルトの名無しさん
2018/11/10(土) 13:59:17.38ID:1Rgn5iVr >>427
となるとエレメントに対してクラスを追加するという操作をしてるんだから、HTMLベースと言ってるところと一緒に思えるが、
またCSSベースが指す概念がよくわからなくなってきたよ。
CSSの定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。
となるとエレメントに対してクラスを追加するという操作をしてるんだから、HTMLベースと言ってるところと一緒に思えるが、
またCSSベースが指す概念がよくわからなくなってきたよ。
CSSの定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。
429デフォルトの名無しさん
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の定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。
ああ、これは違う。これをやるには大量にクラスを定義しまくる必要があるだろ。
実際、何個くらいまで実用に耐えられるのかは興味はあるにしても、
他にそんなコードを見たことがないので、採用はしないね。
そこは説明用の言葉を考えただけだから、過度に拘る必要はないが、
CSSがマスタなのは変わらないし、DOMクエリが必要ないのも変わらないだろ。
CSSは最初から .foo.highlight を持っていて、HTMLが変化しただけ。
俺がCSS「クラス」と言っているのが不味かったか?
CSSでは文法上分離してないが、あれは「構造クラス」と「デザインクラス」と分けて考えるべきで、
.foo は「構造クラス」で不変、.highlightは「デザインクラス」で適宜追加/削除するもの。
「構造クラス」はJavaScriptの「クラス」と同じで、またOOPの「クラス」とも同じ。変わることはない。
そして最初に設計されるべき物。
「デザインクラス」はただの追加アトリビュートだ。見た目を変える為に動的に追加/削除/変更される。
上記の通り、CSSクラスの使い方はOOPと同じだから、OOPを理解している奴は普通に適切に使える。
ところがJavaScripterにはOOPを理解してない奴も多いから、
(というよりはその上流のデザイナのせいか?
もっとも、上流にデザイナが居る時点で間違いだというのが俺の見解だが)
CSSもグチャグチャになってたりする。
CSSも本来は、
.構造クラス {}
.構造クラス.デザインクラス {}
の2種類だけで構成されるべきなんだよ。(基本的には)
> CSSの定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。
ああ、これは違う。これをやるには大量にクラスを定義しまくる必要があるだろ。
実際、何個くらいまで実用に耐えられるのかは興味はあるにしても、
他にそんなコードを見たことがないので、採用はしないね。
430デフォルトの名無しさん
2018/11/10(土) 14:44:43.10ID:VOHXjVDU >>428
というか、俺はオレオレ流の先進性がある(キリッな方法を宣伝しているのではなく、
割とみんなやってる方法を言ってるだけだから、新しい手法か?という期待をされても無理だ。
そんなもん知ってるわ!でしか無いと思う。
というか、俺はオレオレ流の先進性がある(キリッな方法を宣伝しているのではなく、
割とみんなやってる方法を言ってるだけだから、新しい手法か?という期待をされても無理だ。
そんなもん知ってるわ!でしか無いと思う。
431デフォルトの名無しさん
2018/11/10(土) 19:55:52.70ID:3aLGJBed DOMを縦横無尽に弄ろうとするから複雑になる
機能が小さく閉じたコンポーネントを組み合わせて設計すればいいだけ
直接CSSを弄ろうなど、愚の骨頂
機能が小さく閉じたコンポーネントを組み合わせて設計すればいいだけ
直接CSSを弄ろうなど、愚の骨頂
432デフォルトの名無しさん
2018/11/10(土) 20:28:54.94ID:8OkJCHKT >>431
それな。jQueryの使い方として、まずトップのクラスを一つ作る
正確には最初にCSSの設計を行って、CSSの構造でコンポーネントを定義する
この時sassを使うとネストができるのでHTMLの構造をCSSで定義しやすい
そしてjQueryはそのコンポーネントに対して処理を記述する
CSSで構造を作って、その構造通りにHTMLを書く
そしてCSSでは不可能なことが出てくればJavaScript(jQuery)の出番ってわけ
jQueryはCSSと相性がいい
それな。jQueryの使い方として、まずトップのクラスを一つ作る
正確には最初にCSSの設計を行って、CSSの構造でコンポーネントを定義する
この時sassを使うとネストができるのでHTMLの構造をCSSで定義しやすい
そしてjQueryはそのコンポーネントに対して処理を記述する
CSSで構造を作って、その構造通りにHTMLを書く
そしてCSSでは不可能なことが出てくればJavaScript(jQuery)の出番ってわけ
jQueryはCSSと相性がいい
433デフォルトの名無しさん
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を使ったときに発生する問題が全て解決されるってわけ
どや?w
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
jQueryはこのイベントを親で受けるっていうのがすごく書きやすい
$('.foo').on('click', ・・・) とあったら
$(document).on('click', '.foo', ・・・) と書き換えるだけ
documentでなくても、.fooの親である任意の要素でよい
ここでも「分離して動作」という処理がなくなって宣言的になる
bodyにonしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
それどころか、e.target.classList.contains を使って分離して動作させることもいらない
それでいて、共通イベントハンドラとか使わなくていいし、クロージャでそのノード個別のデータを渡すこともできる。
DOM APIを使ったときに発生する問題が全て解決されるってわけ
どや?w
434デフォルトの名無しさん
2018/11/10(土) 20:36:59.04ID:8OkJCHKT DOM APIの問題をあげたようだが、
それがjQueryによって解決されてるのを見ると、
やっぱりjQuery使ったほうが良いなってなるよなw
それがjQueryによって解決されてるのを見ると、
やっぱりjQuery使ったほうが良いなってなるよなw
435デフォルトの名無しさん
2018/11/10(土) 20:42:53.84ID:3aLGJBed >>432
それはjQueryの使い方でも使われ方でもないな
jQueryに限らないけど君みたいな大好きマンが語ることって、
もちろんそれは君の好きにしたら良いし否定はしないけど、やっぱり例外的なんだよ
コンポーネントで組むならそれ専用のライブラリを使うほうが絶対にいいし
一部に使うにしろShadowDOM然り相性が良いとは消して言えない
気軽で便利さが取り柄のjQueryのようなライブラリで、
考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
jQueryは正に比較的小規模なサイトでパッチを当てるような勢いで
縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ
それはjQueryの使い方でも使われ方でもないな
jQueryに限らないけど君みたいな大好きマンが語ることって、
もちろんそれは君の好きにしたら良いし否定はしないけど、やっぱり例外的なんだよ
コンポーネントで組むならそれ専用のライブラリを使うほうが絶対にいいし
一部に使うにしろShadowDOM然り相性が良いとは消して言えない
気軽で便利さが取り柄のjQueryのようなライブラリで、
考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
jQueryは正に比較的小規模なサイトでパッチを当てるような勢いで
縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ
436デフォルトの名無しさん
2018/11/10(土) 20:47:26.06ID:8OkJCHKT > 気軽で便利さが取り柄のjQueryのようなライブラリで、
> 考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
はっはっは。
つまりお前は、jQueryは気軽に使うもんだ。気軽に使うから問題出るやろ
って言ってるわけか。
全てお前の使い方が悪いんじゃないか
見ての通り、お前が上げたDOM APIの問題がすべてjQueryで解決していることを示した。
>>425で(DOM APIの場合は)
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、
〜略〜
> 結果、イベント起動部分のコードは全書き換えに近くなる。
といっているが、jQueryならたったこれだけだ。
> $('.foo').on('click', ・・・) とあったら
> $(document).on('click', '.foo', ・・・) と書き換えるだけ
イベントハンドラのコードは全く変更がいらない
> 考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
はっはっは。
つまりお前は、jQueryは気軽に使うもんだ。気軽に使うから問題出るやろ
って言ってるわけか。
全てお前の使い方が悪いんじゃないか
見ての通り、お前が上げたDOM APIの問題がすべてjQueryで解決していることを示した。
>>425で(DOM APIの場合は)
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、
〜略〜
> 結果、イベント起動部分のコードは全書き換えに近くなる。
といっているが、jQueryならたったこれだけだ。
> $('.foo').on('click', ・・・) とあったら
> $(document).on('click', '.foo', ・・・) と書き換えるだけ
イベントハンドラのコードは全く変更がいらない
437デフォルトの名無しさん
2018/11/10(土) 20:55:48.33ID:8OkJCHKT イベントハンドラのコードは全く変更がいらないと書いたが、
実はDOM APIのイベントハンドラの中身を
jQueryでほぼそのまま使えるってことも重要な所だな
DOM APIからjQueryへの移植が楽になっている
$(document).on('click', '.foo', function(event) {
ここで扱う、thisはDOM APIの場合と同じく、イベントが発生した要素だし、
eventもDOM APIと互換性のあるeventオブジェクトになっている
これは各イベントを親で受け取る場合だが、個別の要素で受け取る場合と全く同じ書き方で良い
})
実はDOM APIのイベントハンドラの中身を
jQueryでほぼそのまま使えるってことも重要な所だな
DOM APIからjQueryへの移植が楽になっている
$(document).on('click', '.foo', function(event) {
ここで扱う、thisはDOM APIの場合と同じく、イベントが発生した要素だし、
eventもDOM APIと互換性のあるeventオブジェクトになっている
これは各イベントを親で受け取る場合だが、個別の要素で受け取る場合と全く同じ書き方で良い
})
438デフォルトの名無しさん
2018/11/10(土) 21:08:34.79ID:8OkJCHKT 結局さ、CSSベースでJavaScriptを素敵な使い方をしようと思えば
DOM APIを使うよりも、jQueryを使うのが良いってことなんだよなー
DOM APIを使うよりも、jQueryを使うのが良いってことなんだよなー
439デフォルトの名無しさん
2018/11/10(土) 21:11:00.27ID:nSd/jMeD どこまで行っても所詮jsのライブラリだからな。jsでできる以上のことはできない。
jsで書いてループが必要なところは、ライブラリが内部で行っているだけ。
てかもしかして他の言語のライブラリの仕組みと勘違いしてるのかもしれんが、jsのライブラリって単なる他人の書いたコードだからなw
「jQuery設計した人はなぁ!すごいんだぞ!頭いいんだぞ!だから俺にひれ伏せ(?)」と主張しているにすぎない。
なぜか御主人様の自慢を始めてしまう奴隷のようだwwマヌケwwww
jsで書いてループが必要なところは、ライブラリが内部で行っているだけ。
てかもしかして他の言語のライブラリの仕組みと勘違いしてるのかもしれんが、jsのライブラリって単なる他人の書いたコードだからなw
「jQuery設計した人はなぁ!すごいんだぞ!頭いいんだぞ!だから俺にひれ伏せ(?)」と主張しているにすぎない。
なぜか御主人様の自慢を始めてしまう奴隷のようだwwマヌケwwww
440デフォルトの名無しさん
2018/11/10(土) 21:14:39.84ID:8OkJCHKT > どこまで行っても所詮jsのライブラリだからな。jsでできる以上のことはできない。
それはJavaScriptでできることの限界までできるってことじゃね?
それはJavaScriptでできることの限界までできるってことじゃね?
441デフォルトの名無しさん
2018/11/10(土) 21:17:06.38ID:8OkJCHKT >>439
> 「jQuery設計した人はなぁ!すごいんだぞ!頭いいんだぞ!だから俺にひれ伏せ(?)」と主張しているにすぎない。
いや、人の自慢はしてないぞw
(褒められたことではないが)jQueryの作者の名前知らないw
純粋にjQueryというライブラリ、その設計が素晴らしいと言ってるだけ
DOM APIの様々な問題(を都合よく語ってくれたのでw)それを解決している
> 「jQuery設計した人はなぁ!すごいんだぞ!頭いいんだぞ!だから俺にひれ伏せ(?)」と主張しているにすぎない。
いや、人の自慢はしてないぞw
(褒められたことではないが)jQueryの作者の名前知らないw
純粋にjQueryというライブラリ、その設計が素晴らしいと言ってるだけ
DOM APIの様々な問題(を都合よく語ってくれたのでw)それを解決している
442デフォルトの名無しさん
2018/11/10(土) 21:58:09.87ID:VOHXjVDU >>437その他
それは素のJavaScriptで出来ることをjQueryでやっただけで、
jQueryを使う意味が全くないだろ。
楽にもなってないし、無駄ラップしてる分遅くなってるし、jQueryに無駄に依存してる。
メリットが何もない。
当然、この状況でjQueryを使う馬鹿なんて居ない。
ただ、お前はjQueryの典型的な使い方>>409をしてるんだろ?
じゃあ437その他の書き方じゃねえだろ。
というか、お前は考え方が逆なんだよ。
409の書き方がjQuery使いに典型的な理由は、jQueryの恩恵を受けられるからなんだよ。
そしてCSSベースでがっちり組んでる奴にはjQueryのメリットなんて全くないから、
彼等はjQueryもフレームワークも大嫌いなわけでさ。
だから
> Queryは正に比較的小規模なサイトでパッチを当てるような勢いで
> 縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ (>>435)
これが正鵠を射てる。
小規模のサイトで技術力が比較的ない場合、
HTMLベース+jQueryで運用するのは極めて現実的な判断だ。だから広まった。
俺は歴史はあまり知らないが、どうやらCSSはかなり初期からあったのに、
「CSSでスタイルしようぜ」なんて言いだしたのは最初からでもないだろ。(特に国内のサイトは酷かった)
そして、みんな学んできて、『技術力が比較的ない』状態を脱しつつあるから、
今脱jQueryの動きがある、ってだけでさ。
特に不思議でもなんでもないだろ。
むしろお前が無理に居残ろうとする意味が分からない。
それは素のJavaScriptで出来ることをjQueryでやっただけで、
jQueryを使う意味が全くないだろ。
楽にもなってないし、無駄ラップしてる分遅くなってるし、jQueryに無駄に依存してる。
メリットが何もない。
当然、この状況でjQueryを使う馬鹿なんて居ない。
ただ、お前はjQueryの典型的な使い方>>409をしてるんだろ?
じゃあ437その他の書き方じゃねえだろ。
というか、お前は考え方が逆なんだよ。
409の書き方がjQuery使いに典型的な理由は、jQueryの恩恵を受けられるからなんだよ。
そしてCSSベースでがっちり組んでる奴にはjQueryのメリットなんて全くないから、
彼等はjQueryもフレームワークも大嫌いなわけでさ。
だから
> Queryは正に比較的小規模なサイトでパッチを当てるような勢いで
> 縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ (>>435)
これが正鵠を射てる。
小規模のサイトで技術力が比較的ない場合、
HTMLベース+jQueryで運用するのは極めて現実的な判断だ。だから広まった。
俺は歴史はあまり知らないが、どうやらCSSはかなり初期からあったのに、
「CSSでスタイルしようぜ」なんて言いだしたのは最初からでもないだろ。(特に国内のサイトは酷かった)
そして、みんな学んできて、『技術力が比較的ない』状態を脱しつつあるから、
今脱jQueryの動きがある、ってだけでさ。
特に不思議でもなんでもないだろ。
むしろお前が無理に居残ろうとする意味が分からない。
443デフォルトの名無しさん
2018/11/10(土) 22:11:33.57ID:8OkJCHKT444デフォルトの名無しさん
2018/11/10(土) 22:16:43.94ID:VOHXjVDU445デフォルトの名無しさん
2018/11/10(土) 22:20:32.47ID:8OkJCHKT > 俺は歴史はあまり知らないが、どうやらCSSはかなり初期からあったのに、
> 「CSSでスタイルしようぜ」なんて言いだしたのは最初からでもないだろ。(特に国内のサイトは酷かった)
知らないなら言わなきゃ良いのにw
1994年にホーコン・ウィウム・リーが初めてCSSの概念を提唱した時から
CSSでスタイルを適用するって話をしてるのに
https://www.w3.org/People/howcome/p/cascade.html
https://www.w3.org/Style/951106_Workshop/
> Style sheets have the potential of adding style to the web without sacrificing device-independence or
> document structure. Instead of adding visual tags to HTML, style sheets attach
> presentational information to the structure of SGML and HTML documents.
なにか言うたびに墓穴をほってるんだから、もう止めたら?w
> 「CSSでスタイルしようぜ」なんて言いだしたのは最初からでもないだろ。(特に国内のサイトは酷かった)
知らないなら言わなきゃ良いのにw
1994年にホーコン・ウィウム・リーが初めてCSSの概念を提唱した時から
CSSでスタイルを適用するって話をしてるのに
https://www.w3.org/People/howcome/p/cascade.html
https://www.w3.org/Style/951106_Workshop/
> Style sheets have the potential of adding style to the web without sacrificing device-independence or
> document structure. Instead of adding visual tags to HTML, style sheets attach
> presentational information to the structure of SGML and HTML documents.
なにか言うたびに墓穴をほってるんだから、もう止めたら?w
446デフォルトの名無しさん
2018/11/10(土) 22:21:59.95ID:8OkJCHKT >>444
ほー、ってことは
jQueryを使わないと
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
が問題はない と、そういったわけですか?
でも、jQueryを使うとがらりと変わることは無いってことには
異論はないわけですよね?
ほー、ってことは
jQueryを使わないと
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
が問題はない と、そういったわけですか?
でも、jQueryを使うとがらりと変わることは無いってことには
異論はないわけですよね?
447デフォルトの名無しさん
2018/11/10(土) 22:23:31.80ID:8OkJCHKT > そしてCSSベースでがっちり組んでる奴にはjQueryのメリットなんて全くないから、
> 彼等はjQueryもフレームワークも大嫌いなわけでさ。
どこの話をしてるだろう?
現実には彼らはjQueryを使っていますが? ウェブの7割以上。JavaScriptを使ってるサイトの97%以上。
それはjQueryにメリットがある何よりの証拠じゃないんですかねw
> 彼等はjQueryもフレームワークも大嫌いなわけでさ。
どこの話をしてるだろう?
現実には彼らはjQueryを使っていますが? ウェブの7割以上。JavaScriptを使ってるサイトの97%以上。
それはjQueryにメリットがある何よりの証拠じゃないんですかねw
448デフォルトの名無しさん
2018/11/10(土) 22:25:04.76ID:8OkJCHKT >>425
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。
それは問題はなにもないってことじゃないんですか?www
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。
それは問題はなにもないってことじゃないんですか?www
449デフォルトの名無しさん
2018/11/10(土) 22:25:21.28ID:VOHXjVDU >>445
> なにか言うたびに墓穴をほってるんだから、もう止めたら?w
お前がな。
https://mayonez.jp/topic/1758
使えなかった当初はさておき、海外のCSS対応に比べて国内はものすごく遅れた。
これをお前は知らないのか?
だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする?
> なにか言うたびに墓穴をほってるんだから、もう止めたら?w
お前がな。
https://mayonez.jp/topic/1758
使えなかった当初はさておき、海外のCSS対応に比べて国内はものすごく遅れた。
これをお前は知らないのか?
だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする?
450デフォルトの名無しさん
2018/11/10(土) 22:36:21.41ID:8OkJCHKT >>449
そのリンクを持ち出してきて、お前が何を言いたいのかが
まーた書かれてないんだがw
> だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする?
なろうとしてないよ?お前がなろうとしてるはずだって思いこんでるだけ
俺は今までずっとjQueryの技術について話をしているのに、
お前は、俺のことばっかりだよなw
jQueryそのものに対しては、遅れてるだとか誰も使ってないだとか
そんな根拠のないことしか言ってない
一つぐらいお前が>>425で書いた問題(問題じゃなかったことにしたんでしたっけ?w)
についてjQueryが解決していることにコメントでもしたら?
解決してないことを探し出すんじゃなくて
jQueryが "解決していること" を無視せずにコメントしろ言ってる
そのリンクを持ち出してきて、お前が何を言いたいのかが
まーた書かれてないんだがw
> だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする?
なろうとしてないよ?お前がなろうとしてるはずだって思いこんでるだけ
俺は今までずっとjQueryの技術について話をしているのに、
お前は、俺のことばっかりだよなw
jQueryそのものに対しては、遅れてるだとか誰も使ってないだとか
そんな根拠のないことしか言ってない
一つぐらいお前が>>425で書いた問題(問題じゃなかったことにしたんでしたっけ?w)
についてjQueryが解決していることにコメントでもしたら?
解決してないことを探し出すんじゃなくて
jQueryが "解決していること" を無視せずにコメントしろ言ってる
451デフォルトの名無しさん
2018/11/10(土) 22:46:13.68ID:VOHXjVDU >>446
> 異論はないわけですよね?
あるぞ。というかお前自身が書き換えてるだろ。
>>448
実際は最初からそう書くから、書き換えなんてしない。
両対応なんてする意味はないし。
だから、HTMLベースで行くのか、CSSベースで行くのかは、最初に決めるし、それで確定する。
そして、今時HTMLベースを選ぶのは技術力がない連中だけだ。
そのHTMLベースにjQueryは極めてフィットし、CSSベースにおいては無用の長物だから、結果的に、
jQuery使い≒HTMLベース≒技術力がない
が成立するから、馬鹿にされる要因にもなり得るし、実際、今そういう感じだろ。
もっとも、イベントエントリ部分は書き換えるにしても大した話ではない。
だから、正しいクラスの使い方をしていれば、移行するのは面倒だが難しい話ではない。
やればいいだけの話だ。
というか、お前は本当に色々知らないから話が通じてない。
もうここら辺でいいかな?どうしてもjQueryを否定されたくないんだろ?
俺はjQueryは役割を終えたという見方だし、お前の屁理屈をいくら聞いても全く変わらない。
このスレの他の連中も、割と公平な見方してると思うぜ。
> 異論はないわけですよね?
あるぞ。というかお前自身が書き換えてるだろ。
>>448
実際は最初からそう書くから、書き換えなんてしない。
両対応なんてする意味はないし。
だから、HTMLベースで行くのか、CSSベースで行くのかは、最初に決めるし、それで確定する。
そして、今時HTMLベースを選ぶのは技術力がない連中だけだ。
そのHTMLベースにjQueryは極めてフィットし、CSSベースにおいては無用の長物だから、結果的に、
jQuery使い≒HTMLベース≒技術力がない
が成立するから、馬鹿にされる要因にもなり得るし、実際、今そういう感じだろ。
もっとも、イベントエントリ部分は書き換えるにしても大した話ではない。
だから、正しいクラスの使い方をしていれば、移行するのは面倒だが難しい話ではない。
やればいいだけの話だ。
というか、お前は本当に色々知らないから話が通じてない。
もうここら辺でいいかな?どうしてもjQueryを否定されたくないんだろ?
俺はjQueryは役割を終えたという見方だし、お前の屁理屈をいくら聞いても全く変わらない。
このスレの他の連中も、割と公平な見方してると思うぜ。
452デフォルトの名無しさん
2018/11/10(土) 22:48:55.83ID:VOHXjVDU453デフォルトの名無しさん
2018/11/11(日) 00:01:21.30ID:Tyd11AGx >>452
何を解決したかって
各イベントを親で受けて、e.target.classList.contains を使って分離して動作させて
共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ないず
だから個別データはノードから動的に取得する必要があり、
単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
というコードを最初から書くんでしょう?
最初から多少煩雑になるコードを書いてるわけですよね?
何を解決したかって
各イベントを親で受けて、e.target.classList.contains を使って分離して動作させて
共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ないず
だから個別データはノードから動的に取得する必要があり、
単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
というコードを最初から書くんでしょう?
最初から多少煩雑になるコードを書いてるわけですよね?
454デフォルトの名無しさん
2018/11/11(日) 00:02:02.34ID:Tyd11AGx 実際に書いてみたら良いんじゃないですか?
その煩雑になるコードってやらを
その煩雑になるコードってやらを
455デフォルトの名無しさん
2018/11/11(日) 00:12:37.08ID:Tyd11AGx456デフォルトの名無しさん
2018/11/11(日) 00:20:37.58ID:nd8UQIYP >>453-455
日本語でおk
日本語でおk
457デフォルトの名無しさん
2018/11/11(日) 00:22:08.62ID:Tyd11AGx458デフォルトの名無しさん
2018/11/11(日) 00:28:45.76ID:nd8UQIYP >>457
日本語でおk
つかマジでそんなこと言ってないだろ。
もう、空回りしてる部分についてはこちらからはフォローしない。キリがないし、意味もないから。
内容を把握出来るまで何度でも読み返し、整理してから回答しろ。
日本語でおk
つかマジでそんなこと言ってないだろ。
もう、空回りしてる部分についてはこちらからはフォローしない。キリがないし、意味もないから。
内容を把握出来るまで何度でも読み返し、整理してから回答しろ。
459デフォルトの名無しさん
2018/11/11(日) 00:31:32.66ID:Tyd11AGx > つかマジでそんなこと言ってないだろ。
引用しかしてませんが?もう一回引用したら良い?
>>425より
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。
>>451より
> 実際は最初からそう書くから、書き換えなんてしない。
全書き換えに近くなるから、書き換えしなくてすむように
最初から>>425のように書くんでしょう?
引用しかしてませんが?もう一回引用したら良い?
>>425より
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。
>>451より
> 実際は最初からそう書くから、書き換えなんてしない。
全書き換えに近くなるから、書き換えしなくてすむように
最初から>>425のように書くんでしょう?
460デフォルトの名無しさん
2018/11/11(日) 00:58:14.90ID:nd8UQIYP >>459
日本語でおk
日本語でおk
461デフォルトの名無しさん
2018/11/11(日) 01:02:28.04ID:Tyd11AGx 自分が書いた日本語も読めなくなったのかw
462デフォルトの名無しさん
2018/11/11(日) 15:49:14.95ID:GIA5l4Dy いい加減Observable使おうぜ
463デフォルトの名無しさん
2018/11/11(日) 18:44:38.87ID:rM+vwstJ フレームワークがよくわからないのですが
node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
jQuery だけは DOM をいじるときと $.ajax ぐらいは使えるんですが
jQuery みたいな便利なライブラリ群って認識でいいんでしょうか
node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
jQuery だけは DOM をいじるときと $.ajax ぐらいは使えるんですが
jQuery みたいな便利なライブラリ群って認識でいいんでしょうか
464デフォルトの名無しさん
2018/11/11(日) 19:05:55.76ID:nd8UQIYP465デフォルトの名無しさん
2018/11/11(日) 22:04:33.71ID:Tyd11AGx >>463
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
その中でnode.jsはフレームワークじゃなくて実行環境。JavaScriptはブラウザ以外でも動く。
例えばWindowsだったらcscriptコマンドでコマンドプロンプト上でJavaScriptが動く。
node.jsも同じようにChromeで使われてるV8 JavaScriptエンジンを使ってコンソールで動く実行環境
だから本来はJavaScript本体と言ったらブラウザでしか使えないDOM APIは含まれない。
実際JavaScriptの仕様にもDOM APIは書いていない。それを区別できないやつがこんなスレタイで
ブラウザはJavaScrptの一部みたいなもんだからいいだろとか言ってるわけだが
話がそれたが、フレームワークは枠組み。全体的な仕組みは、こっちで作って呼び出してやるから
お前はその中の処理を書けばいいよ。というタイプ。ライブラリはその処理を書くときに使える便利な道具
例えば、ボタンをクリックしたらclickイベントを発生してやるから、
お前はその中身だけを書けばいいという仕組みがフレームワーク。と書くとブラウザでは
普通のことじゃね?と思うかもしれないが、その通り。ブラウザは一種のフレームワークになってる。
そこに新たにvue.jsやreact.jsというフレームワークを入れるというのはどういうことなのかというと、
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
その中でnode.jsはフレームワークじゃなくて実行環境。JavaScriptはブラウザ以外でも動く。
例えばWindowsだったらcscriptコマンドでコマンドプロンプト上でJavaScriptが動く。
node.jsも同じようにChromeで使われてるV8 JavaScriptエンジンを使ってコンソールで動く実行環境
だから本来はJavaScript本体と言ったらブラウザでしか使えないDOM APIは含まれない。
実際JavaScriptの仕様にもDOM APIは書いていない。それを区別できないやつがこんなスレタイで
ブラウザはJavaScrptの一部みたいなもんだからいいだろとか言ってるわけだが
話がそれたが、フレームワークは枠組み。全体的な仕組みは、こっちで作って呼び出してやるから
お前はその中の処理を書けばいいよ。というタイプ。ライブラリはその処理を書くときに使える便利な道具
例えば、ボタンをクリックしたらclickイベントを発生してやるから、
お前はその中身だけを書けばいいという仕組みがフレームワーク。と書くとブラウザでは
普通のことじゃね?と思うかもしれないが、その通り。ブラウザは一種のフレームワークになってる。
そこに新たにvue.jsやreact.jsというフレームワークを入れるというのはどういうことなのかというと、
466デフォルトの名無しさん
2018/11/11(日) 22:05:16.67ID:Tyd11AGx (>>465の続き)ブラウザ標準のフレームワークを、独自の思想を持った独自のフレームワークに作り変えている。
だから原則としてDOM APIを使わない。DOM APIを使わずに作れることがメリットと言っているが
まあセールストークだね。思想が違うのでフレームワークとしての使い方が大幅に変わるし
過去の資産が使えなくなるし、何よりサイトの一部にだけに取り入れることが難しい。
(つまりブラウザ標準のフレームワークとvue.jsやreact.js混ぜて使うことが難しい)
ブラウザ標準のHTMLを書いてその要素にイベントを割り当てるのではなく
そもそもHTMLをJavaScriptから生成することになるので、ウェブサイトを作るのには適していない
JavaScriptのフレームワークを使わないと、単純なページすら作れない。
さらにこれらのフレームワークはSPA(single page application)が基本となってるから、
複数ページに見えても1ページ。なので特定のページだけ使うとかじゃなくて
サイト全体とか特定のパス以下は全てフレームワークで管理することになる。
だからウェブサイトとして使っている所には普及しない。
ここいらはブラウザ特有の事情ね
jQueryは一般的にはライブラリと言われてるし、実際にライブラリでブラウザ標準のフレームワークを
互換性を保ちながら使いやすくしている。イベントハンドラを割り当てる方法とか
DOM APIのaddEventListenerではなくon等を用いるため、jQuery独自の世界になるように見えるが、
内部では単純にDOM APIを呼び出しているだけで、フレームワークに関しては独自の思想は持っていない
互換性があるので簡単に置き換えられる。DOM APIのイベントハンドラをほとんど変えずにjQueryで使えるしね
jQueryの特徴はむしろjQueryオブジェクト( $(セレクタ) )の方にあって、
0個以上のDOM要素を一つのオブジェクトにラップして塊として扱えるようにするのが特徴で
これにより宣言的な記述が可能になる。CSSとも相性が良い。CSSベースで正しく設計した時のjQueryの相性は抜群
jQueryは新たなフレームワークを作り出すものではなく、jQueryオブジェクトを導入するものなのでライブラリ
だから原則としてDOM APIを使わない。DOM APIを使わずに作れることがメリットと言っているが
まあセールストークだね。思想が違うのでフレームワークとしての使い方が大幅に変わるし
過去の資産が使えなくなるし、何よりサイトの一部にだけに取り入れることが難しい。
(つまりブラウザ標準のフレームワークとvue.jsやreact.js混ぜて使うことが難しい)
ブラウザ標準のHTMLを書いてその要素にイベントを割り当てるのではなく
そもそもHTMLをJavaScriptから生成することになるので、ウェブサイトを作るのには適していない
JavaScriptのフレームワークを使わないと、単純なページすら作れない。
さらにこれらのフレームワークはSPA(single page application)が基本となってるから、
複数ページに見えても1ページ。なので特定のページだけ使うとかじゃなくて
サイト全体とか特定のパス以下は全てフレームワークで管理することになる。
だからウェブサイトとして使っている所には普及しない。
ここいらはブラウザ特有の事情ね
jQueryは一般的にはライブラリと言われてるし、実際にライブラリでブラウザ標準のフレームワークを
互換性を保ちながら使いやすくしている。イベントハンドラを割り当てる方法とか
DOM APIのaddEventListenerではなくon等を用いるため、jQuery独自の世界になるように見えるが、
内部では単純にDOM APIを呼び出しているだけで、フレームワークに関しては独自の思想は持っていない
互換性があるので簡単に置き換えられる。DOM APIのイベントハンドラをほとんど変えずにjQueryで使えるしね
jQueryの特徴はむしろjQueryオブジェクト( $(セレクタ) )の方にあって、
0個以上のDOM要素を一つのオブジェクトにラップして塊として扱えるようにするのが特徴で
これにより宣言的な記述が可能になる。CSSとも相性が良い。CSSベースで正しく設計した時のjQueryの相性は抜群
jQueryは新たなフレームワークを作り出すものではなく、jQueryオブジェクトを導入するものなのでライブラリ
467デフォルトの名無しさん
2018/11/11(日) 22:07:46.99ID:Tyd11AGx >>463
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
直接的にこの質問に答えると、所詮JavaScriptのライブラリでしか無いので
JavaScriptでできる以上のことは出来ない。
何ができるようになるかじゃなく、作り方が変わる。
vue.js react.jsは作りやすくなると自称しているが、ウェブサイトには適していない
ウェブアプリとして作りやすいようになっているフレームワーク
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
直接的にこの質問に答えると、所詮JavaScriptのライブラリでしか無いので
JavaScriptでできる以上のことは出来ない。
何ができるようになるかじゃなく、作り方が変わる。
vue.js react.jsは作りやすくなると自称しているが、ウェブサイトには適していない
ウェブアプリとして作りやすいようになっているフレームワーク
468デフォルトの名無しさん
2018/11/11(日) 22:29:45.11ID:Tyd11AGx 訂正
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
node.jsは実行環境で、ブラウザなしにJavaScriptを動かすことができるようになる。
ブラウザではないのでDOM APIの代わりにAPIを搭載しておりローカルファイルにアクセスできたりする
(もちろんブラウザではな動かない)
vue.jsとreact.jsは所詮JavaScriptで実装されたもの(というべきだった)
だからJavaScrpitでできる以上のことは出来ないし、
ブラウザのJavaScriptで動くのだから、ブラウザのJavaScriptでできる以上のことは出来ない
ただし、React.jsはReactNativeといってブラウザ以外でもスマホアプリとして動くように
なってる。ブラウザ版とアプリ版でコードを共有したいなら使えるというメリットは有るが
AirBnb がReactNativeやめるとか言ってるし、UIにこだわるったりするなら茨の道なんだろうね。
んで、やっぱり、これはアプリの話なんだよw
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
node.jsは実行環境で、ブラウザなしにJavaScriptを動かすことができるようになる。
ブラウザではないのでDOM APIの代わりにAPIを搭載しておりローカルファイルにアクセスできたりする
(もちろんブラウザではな動かない)
vue.jsとreact.jsは所詮JavaScriptで実装されたもの(というべきだった)
だからJavaScrpitでできる以上のことは出来ないし、
ブラウザのJavaScriptで動くのだから、ブラウザのJavaScriptでできる以上のことは出来ない
ただし、React.jsはReactNativeといってブラウザ以外でもスマホアプリとして動くように
なってる。ブラウザ版とアプリ版でコードを共有したいなら使えるというメリットは有るが
AirBnb がReactNativeやめるとか言ってるし、UIにこだわるったりするなら茨の道なんだろうね。
んで、やっぱり、これはアプリの話なんだよw
469デフォルトの名無しさん
2018/11/11(日) 22:37:53.74ID:YkGULP39 >さらにこれらのフレームワークはSPA(single page application)が基本となってるから、
>複数ページに見えても1ページ。なので特定のページだけ使うとかじゃなくて
>サイト全体とか特定のパス以下は全てフレームワークで管理することになる。
細かいこと言うと、1ページでしかないから(React等を使っていない)他のページと
組み合わせて使うことは十分可能なんだよな。
>複数ページに見えても1ページ。なので特定のページだけ使うとかじゃなくて
>サイト全体とか特定のパス以下は全てフレームワークで管理することになる。
細かいこと言うと、1ページでしかないから(React等を使っていない)他のページと
組み合わせて使うことは十分可能なんだよな。
470デフォルトの名無しさん
2018/11/11(日) 22:43:08.27ID:Tyd11AGx471デフォルトの名無しさん
2018/11/11(日) 22:46:06.43ID:Tyd11AGx prototype.jsからjQueryへの移行のときとか、
1ページ内に、prototype.jsとjQueryを両方読み込んで、
HTML(とCSS)はそのままに1関数ずつ移行とかできたしね
1ページ内に、prototype.jsとjQueryを両方読み込んで、
HTML(とCSS)はそのままに1関数ずつ移行とかできたしね
472デフォルトの名無しさん
2018/11/11(日) 23:03:57.32ID:YkGULP39 なんでいきなり移行する話になるんだか。
共存自体は別に難しくないよ。非SPAで複数ページ連携するのと変わらん。
共存自体は別に難しくないよ。非SPAで複数ページ連携するのと変わらん。
473デフォルトの名無しさん
2018/11/11(日) 23:05:43.29ID:rM+vwstJ 463です
たくさんリプありがとうございます
まだいまいちわかってないけど
React Vue は複数ページに見えるページセットみたいなのをJSでかけて
クライアントはリンクふんだときにページ遷移にみえるように画面いれかえてくれるものってことなのかな
だからそのページセットがネイティブアプリでうごくってことなのかな
node.js は javascript で CGI サーバーサイドの物を作れるってことかな
llisten accept とかをJSでできるようになるのかな
JSで標準入出力をかくだけでCGIとして動くものなのかな
たくさんリプありがとうございます
まだいまいちわかってないけど
React Vue は複数ページに見えるページセットみたいなのをJSでかけて
クライアントはリンクふんだときにページ遷移にみえるように画面いれかえてくれるものってことなのかな
だからそのページセットがネイティブアプリでうごくってことなのかな
node.js は javascript で CGI サーバーサイドの物を作れるってことかな
llisten accept とかをJSでできるようになるのかな
JSで標準入出力をかくだけでCGIとして動くものなのかな
474デフォルトの名無しさん
2018/11/11(日) 23:07:25.77ID:Tyd11AGx475デフォルトの名無しさん
2018/11/11(日) 23:09:02.00ID:llAUtrTG >>473
釣れますか?
釣れますか?
476デフォルトの名無しさん
2018/11/11(日) 23:11:24.71ID:nd8UQIYP >>473
まあjQuery廚がするjQueryの話だけは鵜呑みにするなよ。
既に何度も言ったとおり、CSSベースで組んだ場合にjQueryを使うメリットは何もない。
だから、CSSベースでいける、と判断したところが脱jQueryしていってる。
そしてjQuery廚はCSSベースの意味を理解出来てないし、誤用している。
なお、話を戻すと、その手のフレームワークについては、
こういった解説を求めたり、或いはググったらQuitaとかに色々でてくるはずだが、
なんだかんだで間違いが多いから公式を読んだ方がいい。
そして、公式を読んでも意味が分からないのなら、それは君が今使うべき物ではない、ということ。
結局、ここで聞いて、俺達が何か言ったところで、君には間違いが見抜けないだろ。
なら、君自身が間違いを見抜けるようになるか、間違いがあった場合に誰かが訂正してくれる場所でないと、
質問する意味がないだろ。間違いを掴まされる可能性も普通にあるわけでさ。
そして、間違いが一番少ない場所は公式、ってことだ。通常、間違ってればすぐに訂正されるから。
最近の公式はどれもこれも布教用ページを持っているから、そこを読むのが一番いい。
そして、当然それは使用者のレベルも想定した上で書かれているから、
そこを読んで分からないのならお呼びではないって事で諦めた方がいい。つまり、
公式を読め、無理なら諦めろ、なんだが。
まあjQuery廚がするjQueryの話だけは鵜呑みにするなよ。
既に何度も言ったとおり、CSSベースで組んだ場合にjQueryを使うメリットは何もない。
だから、CSSベースでいける、と判断したところが脱jQueryしていってる。
そしてjQuery廚はCSSベースの意味を理解出来てないし、誤用している。
なお、話を戻すと、その手のフレームワークについては、
こういった解説を求めたり、或いはググったらQuitaとかに色々でてくるはずだが、
なんだかんだで間違いが多いから公式を読んだ方がいい。
そして、公式を読んでも意味が分からないのなら、それは君が今使うべき物ではない、ということ。
結局、ここで聞いて、俺達が何か言ったところで、君には間違いが見抜けないだろ。
なら、君自身が間違いを見抜けるようになるか、間違いがあった場合に誰かが訂正してくれる場所でないと、
質問する意味がないだろ。間違いを掴まされる可能性も普通にあるわけでさ。
そして、間違いが一番少ない場所は公式、ってことだ。通常、間違ってればすぐに訂正されるから。
最近の公式はどれもこれも布教用ページを持っているから、そこを読むのが一番いい。
そして、当然それは使用者のレベルも想定した上で書かれているから、
そこを読んで分からないのならお呼びではないって事で諦めた方がいい。つまり、
公式を読め、無理なら諦めろ、なんだが。
477デフォルトの名無しさん
2018/11/11(日) 23:13:52.77ID:Tyd11AGx >>473
> React Vue は複数ページに見えるページセットみたいなのをJSでかけて
> クライアントはリンクふんだときにページ遷移にみえるように画面いれかえてくれるものってことなのかな
それはどちらかといえばオマケ機能。たまたま(デフォルトで)そうやってるってだけで
そうやる必要もないし、フレームワークの話とは関係ない
> だからそのページセットがネイティブアプリでうごくってことなのかな
この話とネイティブアプリで動くのとは直接の関係はない
まあ設計はしやすいんだろうけど
> node.js は javascript で CGI サーバーサイドの物を作れるってことかな
それはあっている。CGIにすることもできるが、通常はnode.jsで
動くサーバーサイドフレームワークを使う
> llisten accept とかをJSでできるようになるのかな
できる
> JSで標準入出力をかくだけでCGIとして動くものなのかな
node.jsの使い方としてはあまり一般的ではないが
標準入出力の機能もあるのでCGIとしても使える
> React Vue は複数ページに見えるページセットみたいなのをJSでかけて
> クライアントはリンクふんだときにページ遷移にみえるように画面いれかえてくれるものってことなのかな
それはどちらかといえばオマケ機能。たまたま(デフォルトで)そうやってるってだけで
そうやる必要もないし、フレームワークの話とは関係ない
> だからそのページセットがネイティブアプリでうごくってことなのかな
この話とネイティブアプリで動くのとは直接の関係はない
まあ設計はしやすいんだろうけど
> node.js は javascript で CGI サーバーサイドの物を作れるってことかな
それはあっている。CGIにすることもできるが、通常はnode.jsで
動くサーバーサイドフレームワークを使う
> llisten accept とかをJSでできるようになるのかな
できる
> JSで標準入出力をかくだけでCGIとして動くものなのかな
node.jsの使い方としてはあまり一般的ではないが
標準入出力の機能もあるのでCGIとしても使える
478デフォルトの名無しさん
2018/11/11(日) 23:14:13.38ID:Tyd11AGx >>475
釣れるようですよ
釣れるようですよ
479デフォルトの名無しさん
2018/11/11(日) 23:15:10.44ID:rM+vwstJ >>475
ちがうんですか?
基本ホームページ制作で
ウェブサーバー上に HTMl CSS JS のテキストファイルをおいて動かしたことしかないので
本気でわかってないです
ただウェブ制作だけだとこの先厳しいってきくので
サーバーサイドよりのフロントエンドに手出したいなと思ってて
募集案件で Vue React Node とか使えることみたいな募集けっこうみかけるので
ぢどういうものなのかなときいてみた次第です
ちがうんですか?
基本ホームページ制作で
ウェブサーバー上に HTMl CSS JS のテキストファイルをおいて動かしたことしかないので
本気でわかってないです
ただウェブ制作だけだとこの先厳しいってきくので
サーバーサイドよりのフロントエンドに手出したいなと思ってて
募集案件で Vue React Node とか使えることみたいな募集けっこうみかけるので
ぢどういうものなのかなときいてみた次第です
480デフォルトの名無しさん
2018/11/11(日) 23:17:05.89ID:Tyd11AGx481デフォルトの名無しさん
2018/11/11(日) 23:21:32.87ID:YkGULP39 SPAと非SPAの共存の話をしているのになんで1ページの中に共存する話になるんだかw
482デフォルトの名無しさん
2018/11/11(日) 23:28:40.49ID:rM+vwstJ >>477
Node はどちらかというと他のホスティングサーバーで動くものというよりは
サーバープログラム自体をJSで作るためのものなんですね
npmっていうインストーラーを使うためのライブラリか何かだとおもってました…
VueとReactはまだよくわかってないので公式よんでみます
丁寧にありがとうございました
Node はどちらかというと他のホスティングサーバーで動くものというよりは
サーバープログラム自体をJSで作るためのものなんですね
npmっていうインストーラーを使うためのライブラリか何かだとおもってました…
VueとReactはまだよくわかってないので公式よんでみます
丁寧にありがとうございました
483デフォルトの名無しさん
2018/11/12(月) 00:08:20.33ID:u4h35p9a >>480
身も蓋もないが、実際、「公式を読め」がベストアンサーだろ。
日本語も論理も怪しい奴が一生懸命説明してくれたところで信じ切れないし、
ここで俺らがグダグダ説明するより数段ましな説明が公式にある。
○○ってなんですか系は、
・誤解をピンポイントで訂正していく
位しかここの使い道はないんだよ。
それで、ライブラリに無理に振ったようだから「釣りですか」なんて言われるわけでさ。
身も蓋もないが、実際、「公式を読め」がベストアンサーだろ。
日本語も論理も怪しい奴が一生懸命説明してくれたところで信じ切れないし、
ここで俺らがグダグダ説明するより数段ましな説明が公式にある。
○○ってなんですか系は、
・誤解をピンポイントで訂正していく
位しかここの使い道はないんだよ。
それで、ライブラリに無理に振ったようだから「釣りですか」なんて言われるわけでさ。
484デフォルトの名無しさん
2018/11/12(月) 01:17:07.58ID:5keBG8X8 「公式を読め」じゃ解答になっていない
公式のこういうところをこういうように読んで、
補足してこういう情報も見るとこの状況・段階では捗るよと教えてあげないと
ただ単に答えるの面倒くさいからって投げてるだけじゃん
公式のこういうところをこういうように読んで、
補足してこういう情報も見るとこの状況・段階では捗るよと教えてあげないと
ただ単に答えるの面倒くさいからって投げてるだけじゃん
485デフォルトの名無しさん
2018/11/12(月) 01:52:38.96ID:EMn4pr1Y 答えられないなら黙ってればいいのにな
486デフォルトの名無しさん
2018/11/12(月) 02:39:18.09ID:LIztjTMy きちんと公式が整備されてるのは幸せだよね
と最近実感した
と最近実感した
487デフォルトの名無しさん
2018/11/12(月) 03:08:32.30ID:SVvjW+l6 >>486
Yes、PHP!
Yes、PHP!
488デフォルトの名無しさん
2018/11/12(月) 07:14:02.24ID:u4h35p9a >>484-485
ならお前らがまず「ぼくがほしかったかいとうれい」を出して言え。
この点、jQuery厨はやってるだけましだし、やったからこそ文句を言う権利はあるが、
お前らやってないのに文句を言ってるだろ。
それがゆとりが駄目なところだ。
そして、お前らが一生懸命説明したとしても、公式を越えるのは容易ではない。
公式は、スキルがあり、お前ら以上に詳しい奴が、時間をかけて、しかも複数人数で書いてる。
沢山の人の目にも触れ、間違いや分かりにくい表現は修正されてる。
これらの意味が分からないのは、お前らが馬鹿だからだよ。
マジで、今後、公式も読めない奴はプログラマやっていけないよ。
公式も読んでない段階でここで質問するような馬鹿も、プログラマ辞めた方がいいと思うぜ。
それって、わざわざ誤解したがっているようなものだからな。
ならお前らがまず「ぼくがほしかったかいとうれい」を出して言え。
この点、jQuery厨はやってるだけましだし、やったからこそ文句を言う権利はあるが、
お前らやってないのに文句を言ってるだろ。
それがゆとりが駄目なところだ。
そして、お前らが一生懸命説明したとしても、公式を越えるのは容易ではない。
公式は、スキルがあり、お前ら以上に詳しい奴が、時間をかけて、しかも複数人数で書いてる。
沢山の人の目にも触れ、間違いや分かりにくい表現は修正されてる。
これらの意味が分からないのは、お前らが馬鹿だからだよ。
マジで、今後、公式も読めない奴はプログラマやっていけないよ。
公式も読んでない段階でここで質問するような馬鹿も、プログラマ辞めた方がいいと思うぜ。
それって、わざわざ誤解したがっているようなものだからな。
489デフォルトの名無しさん
2018/11/12(月) 07:32:44.63ID:SVvjW+l6 > これらの意味が分からないのは、お前らが馬鹿だからだよ。
英語だからでしょ?
英語だからでしょ?
490デフォルトの名無しさん
2018/11/12(月) 09:07:58.13ID:WiNaWTIj >>489
終わらせるなよw
終わらせるなよw
491デフォルトの名無しさん
2018/11/12(月) 09:17:26.32ID:UKgWKeA/ 約二名が批判しあっているが、身のある結論には行き着かない
492デフォルトの名無しさん
2018/11/12(月) 16:28:44.22ID:X/r+Zmkn 長文書いてるわりに中身がないからな
493デフォルトの名無しさん
2018/11/12(月) 16:34:07.15ID:SVvjW+l6 まあ、何を言おうが現実はこれってことだよ。
終わったと言い始めて3年だからな
https://w3techs.com/technologies/overview/javascript_library/all
w3techsによると2017年1月の時点で71.9%のサイトがJavaScriptのライブラリとして
jQueryを使用していることが判明し、それ以降もシェアの増加が続いていたが、
2018年4月〜2018年10月の約半年間で変化が見られず、ようやく73.3%〜73.4%で
増加が停止したようである。
しかしながら、減少の傾向は見られず、マーケットシェア(JavaScriptを使用しているサイトでの使用率)
https://w3techs.com/technologies/history_overview/javascript_library は97.2%を
示していることから、jQueryからの移行が始まったと言うより、上げ止まりであると考えられる
jQuery以外では、この1年でBootstrapが2%程度、Underscoreが1%程度増加している以外は
ほとんど変動はなく、期待されていたAngularは過去最高の0.5%から0.1%減少した0.4%に、
Reactは過去最高の0.6%から0.5%と大きく減少し、0.1%に下がっていることが判明した。
またいずれのライブラリも使用していないサイトは24.5%で
2017年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか?この先の動向が注目される
終わったと言い始めて3年だからな
https://w3techs.com/technologies/overview/javascript_library/all
w3techsによると2017年1月の時点で71.9%のサイトがJavaScriptのライブラリとして
jQueryを使用していることが判明し、それ以降もシェアの増加が続いていたが、
2018年4月〜2018年10月の約半年間で変化が見られず、ようやく73.3%〜73.4%で
増加が停止したようである。
しかしながら、減少の傾向は見られず、マーケットシェア(JavaScriptを使用しているサイトでの使用率)
https://w3techs.com/technologies/history_overview/javascript_library は97.2%を
示していることから、jQueryからの移行が始まったと言うより、上げ止まりであると考えられる
jQuery以外では、この1年でBootstrapが2%程度、Underscoreが1%程度増加している以外は
ほとんど変動はなく、期待されていたAngularは過去最高の0.5%から0.1%減少した0.4%に、
Reactは過去最高の0.6%から0.5%と大きく減少し、0.1%に下がっていることが判明した。
またいずれのライブラリも使用していないサイトは24.5%で
2017年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか?この先の動向が注目される
494デフォルトの名無しさん
2018/11/12(月) 16:43:28.03ID:SVvjW+l6 >>481
> SPAと非SPAの共存の話をしているのになんで1ページの中に共存する話になるんだかw
だってWordPressがjQueryを使ってる所に、
ReactやAngularで作られたプラグインのせるとか、
逆に将来WordPressがReactやAngularに乗り換えたとして、
jQueryで作られたプラグインのせるとか、共存できないと
移行なんて無理でしょ?全部いっぺんに変えられるわけがないんだから
フレームワークはサイト全体をそのフレームワークで構成するならいいが
パーツ単位で別のフレームワークで作られたもの混在や再利用がしづらいんだよ
そこで、ブラウザ標準のフレームワークとDOM APIを改良した
ライブラリであるjQueryが一番再利用性が高いということになる。
> SPAと非SPAの共存の話をしているのになんで1ページの中に共存する話になるんだかw
だってWordPressがjQueryを使ってる所に、
ReactやAngularで作られたプラグインのせるとか、
逆に将来WordPressがReactやAngularに乗り換えたとして、
jQueryで作られたプラグインのせるとか、共存できないと
移行なんて無理でしょ?全部いっぺんに変えられるわけがないんだから
フレームワークはサイト全体をそのフレームワークで構成するならいいが
パーツ単位で別のフレームワークで作られたもの混在や再利用がしづらいんだよ
そこで、ブラウザ標準のフレームワークとDOM APIを改良した
ライブラリであるjQueryが一番再利用性が高いということになる。
495デフォルトの名無しさん
2018/11/12(月) 22:38:28.19ID:Ff8BWBdH 別ページなんだから「全部いっぺんに」変える必要もないんだが、どうしてもそこが理解できないようだな。
SPAは別にReact難かに限らずjQuery使って作ることだってできるわけだが、あるページでjQueryを
使ったからといって他のページも全部jQuery使わなきゃならないわけじゃないと説明すればjQuery脳にも
理解できるかねぇ。
SPAは別にReact難かに限らずjQuery使って作ることだってできるわけだが、あるページでjQueryを
使ったからといって他のページも全部jQuery使わなきゃならないわけじゃないと説明すればjQuery脳にも
理解できるかねぇ。
496デフォルトの名無しさん
2018/11/12(月) 23:41:28.73ID:u4h35p9a497デフォルトの名無しさん
2018/11/13(火) 01:24:42.49ID:r1Hd5gXt498デフォルトの名無しさん
2018/11/13(火) 01:27:10.37ID:r1Hd5gXt >>495
だからすでにあるWordPressの一部に何かのフレームワークで作ったものを混ぜたり
あるフレームワーク作ったものを、他のフレームワークで使ったりするってことだよ
コンポーネントっていうのは、そうやって他の人が作ったものを使うってこと。
混ぜて使えないなら、そのフレームワークで全てを構成しなきゃならない
ってか、混ぜて使えないから、そうやって言い訳してるわけなんだろうけどねw
だからすでにあるWordPressの一部に何かのフレームワークで作ったものを混ぜたり
あるフレームワーク作ったものを、他のフレームワークで使ったりするってことだよ
コンポーネントっていうのは、そうやって他の人が作ったものを使うってこと。
混ぜて使えないなら、そのフレームワークで全てを構成しなきゃならない
ってか、混ぜて使えないから、そうやって言い訳してるわけなんだろうけどねw
499デフォルトの名無しさん
2018/11/13(火) 02:33:15.33ID:r1Hd5gXt いちゃもんおじさんが来ないので、jQueryとCSSの相性と
コンポーネントの再利用についてのサンプル https://jsfiddle.net/rueg1xv2/
要件:フォームコントロールにフォーカスがあたったら背景色を変えたい。
ただし全てではなく指定した要素のみ色などはCSSで指定したい。
(CSSの:focus擬似クラスでできるがあえてjQueryでw)
設計:CSSベースで設計する。対象としたい要素のクラスにtargetを指定する
フォーカスがあたっている場合のクラスをfocusとし、jQueryからはクラス名を
変えるだけで、具体的なデザインはCSSで行えるようにする
実装:
[CSS]
.target.focus {
background-color: #eee;
}
[jQuery]
$(document).on({
focusin: event => $(event.target).addClass('focus'),
focusout: event => $(event.target).removeClass('focus')
}, '.target');
解説:構造(といっても今回のは要素だけのフラットなものだが)を
CSSで最初に決めるて処理を適用している。HTMLの構造には依存しないので
HTMLに変更があったとしてもjQueryのコードに変更は必要ない
HTMLとCSSの基本であるデザインをCSSに分離しており、CSSを変えるだけでデザインを変えられる
jQueryで必要なのは適用する要素のセレクタとクラス名だけなので、それを変数で
変えられるようにすれば再利用が可能だし、社内共通名として定義できるなら決めうちでも良い
複数の要素に対応していながら、コードにはループはなく、宣言的に記述している。
DOMを直接変更するなとか変な制限があるフレームークを使っていなければ、今すぐ導入が可能
コンポーネントの再利用についてのサンプル https://jsfiddle.net/rueg1xv2/
要件:フォームコントロールにフォーカスがあたったら背景色を変えたい。
ただし全てではなく指定した要素のみ色などはCSSで指定したい。
(CSSの:focus擬似クラスでできるがあえてjQueryでw)
設計:CSSベースで設計する。対象としたい要素のクラスにtargetを指定する
フォーカスがあたっている場合のクラスをfocusとし、jQueryからはクラス名を
変えるだけで、具体的なデザインはCSSで行えるようにする
実装:
[CSS]
.target.focus {
background-color: #eee;
}
[jQuery]
$(document).on({
focusin: event => $(event.target).addClass('focus'),
focusout: event => $(event.target).removeClass('focus')
}, '.target');
解説:構造(といっても今回のは要素だけのフラットなものだが)を
CSSで最初に決めるて処理を適用している。HTMLの構造には依存しないので
HTMLに変更があったとしてもjQueryのコードに変更は必要ない
HTMLとCSSの基本であるデザインをCSSに分離しており、CSSを変えるだけでデザインを変えられる
jQueryで必要なのは適用する要素のセレクタとクラス名だけなので、それを変数で
変えられるようにすれば再利用が可能だし、社内共通名として定義できるなら決めうちでも良い
複数の要素に対応していながら、コードにはループはなく、宣言的に記述している。
DOMを直接変更するなとか変な制限があるフレームークを使っていなければ、今すぐ導入が可能
500デフォルトの名無しさん
2018/11/13(火) 02:46:25.17ID:4/lVJDsB 全部nanoやumbrellaで出来るな。
jQueryより軽いし。
所詮ライブラリだからおんなじことできるのにデブ使う必要もない。
どれでも好きな娘選んでエッチしていいよって言われたら一番かわいい娘選ぶだろ?
そういうこと。
jQueryより軽いし。
所詮ライブラリだからおんなじことできるのにデブ使う必要もない。
どれでも好きな娘選んでエッチしていいよって言われたら一番かわいい娘選ぶだろ?
そういうこと。
501デフォルトの名無しさん
2018/11/13(火) 03:19:50.73ID:r1Hd5gXt502デフォルトの名無しさん
2018/11/13(火) 03:49:08.69ID:r1Hd5gXt なんだnanoもumbrellaもjQueryライクなライブラリか
設計思想が同じならjQueryの代替にならないわけじゃないな
ただクローンはオリジナルを超えられないものだけど
設計思想が同じならjQueryの代替にならないわけじゃないな
ただクローンはオリジナルを超えられないものだけど
503デフォルトの名無しさん
2018/11/13(火) 08:00:15.11ID:6Th2Z+aX >>497
>>103
同じ事を俺だけでも何回も指摘済みだが。
>>499
間違いを垂れ流すのは止めろ。
お前自身が馬鹿なのが初心者にも分かるだろうから、お前では布教は無理だよ。
というか、何故お前は頑なに学習を拒む?
他の『快適な』サイトがどういう作りになってるか見ればすぐに分かるはずなのだが。
そもそもjQueryを使っただけで、「遅くなり、jQueryに依存する」というデメリットが付いてくる。
『今も』それを越えるメリットがあると思えば使えばいいし、
それは看過出来ないと思う奴らはjQueryを既に捨ててる。それだけの話だ。
jQueryの最大のメリットは、お前みたいな馬鹿でも、どんなグダグダなHTMLでも、何とかなってしまうことだ。
だから(今のお前もやっているように)HTMLベースで組むのは最初は悪いことではないし、妥当だ。
しかし、他の連中は色々学んで、それ以上の道を模索してる。
それがフレームワークであったり、脱jQueryであったり、素で書け、みたいなことだったりする。
フレームワークの使い方を覚えても「プログミングの本質的な腕前」には関係ないが、
各フレームワークがどこに問題を見いだし、どう解決しようとしたかを見ることは、
「プログミングの本質的な腕前」の上達に繋がる。
フレームワークを模索している連中は、その過程で、どんどん前に進んでいく。
お前はjQueryにこだわって、置き去りにされてるだけだ。(というよりそれをお前自身が望んでいる)
他の人とお前が話が通じてないのはそのためだ。君が分かってなさすぎる。
ただそれ以前に、君は日本語が怪しいから、そこをまず詰めた方がいいが。
>>103
同じ事を俺だけでも何回も指摘済みだが。
>>499
間違いを垂れ流すのは止めろ。
お前自身が馬鹿なのが初心者にも分かるだろうから、お前では布教は無理だよ。
というか、何故お前は頑なに学習を拒む?
他の『快適な』サイトがどういう作りになってるか見ればすぐに分かるはずなのだが。
そもそもjQueryを使っただけで、「遅くなり、jQueryに依存する」というデメリットが付いてくる。
『今も』それを越えるメリットがあると思えば使えばいいし、
それは看過出来ないと思う奴らはjQueryを既に捨ててる。それだけの話だ。
jQueryの最大のメリットは、お前みたいな馬鹿でも、どんなグダグダなHTMLでも、何とかなってしまうことだ。
だから(今のお前もやっているように)HTMLベースで組むのは最初は悪いことではないし、妥当だ。
しかし、他の連中は色々学んで、それ以上の道を模索してる。
それがフレームワークであったり、脱jQueryであったり、素で書け、みたいなことだったりする。
フレームワークの使い方を覚えても「プログミングの本質的な腕前」には関係ないが、
各フレームワークがどこに問題を見いだし、どう解決しようとしたかを見ることは、
「プログミングの本質的な腕前」の上達に繋がる。
フレームワークを模索している連中は、その過程で、どんどん前に進んでいく。
お前はjQueryにこだわって、置き去りにされてるだけだ。(というよりそれをお前自身が望んでいる)
他の人とお前が話が通じてないのはそのためだ。君が分かってなさすぎる。
ただそれ以前に、君は日本語が怪しいから、そこをまず詰めた方がいいが。
504デフォルトの名無しさん
2018/11/13(火) 08:08:23.05ID:nHdUvNqS >>498
最初はReactとかSPAの話だったんでその話しかしてないんだが、なんでWordPressとか持ち出すかね。
意図的に話をずらそうとしているのか「フレームワーク」で似たようなものだと区別ついてないのか。
「混ぜる」のミスリードも相変わらずだね。1ページ内で混在する話なんかしてないっつーの。
最初はReactとかSPAの話だったんでその話しかしてないんだが、なんでWordPressとか持ち出すかね。
意図的に話をずらそうとしているのか「フレームワーク」で似たようなものだと区別ついてないのか。
「混ぜる」のミスリードも相変わらずだね。1ページ内で混在する話なんかしてないっつーの。
505デフォルトの名無しさん
2018/11/13(火) 09:19:43.36ID:6Th2Z+aX >>499
というか、お前は初心者の発想から抜け出せていない。
話が通じないのは、これが原因かもしれん。
本来は、ライブラリ/フレームワークは「きちんと選んで使うもの」だ。
基準は彼等がよく言う、「どうせ同じようなコードを書くことになる」が分かりやすくていい。
だから本来は、「それがなかったら同じようなコードを書く奴だけが使え」というのも正しくて、偶にこれを言ってる奴もいるだろ。
現実はそうも行かず、全く意味分からない初心者も含めて使え、ということになっているが。
実際、「どうせ同じようなコードを書くことになる」は事実だ。
大規模化したコードの生産性を上げる為には、何らかのプチライブラリ/フレームワークが内部的に必要になる。
(敢えてそれをしない、というスタイルの奴も偶にいるが)
SPA向けのフレームワークは、SPAで典型的に必要になる制御に対し、枠組みを提供するものだ。
当然、無ければ無いで書けるが、彼等の指摘通り、「どうせ同じようなコードを書くことになる」。
なら、ジャストフィットする物があれば、使った方が楽だ。
jQueryも同じで、「どうせ同じようなコードを書くことになる」のなら、使うのは正しい。
つまり、ブラウザの差異を吸収する為に、或いはCSSセレクタを使う為に、jQueryと同じようなコードがどうせ必要な場合だ。
ところが、これらは環境の整備がすすみ、なくなってしまった。
なら、もう要らなくね?というのも自然な発想だ。
彼等は原点を忘れてなかったんだよ。
君にはライブラリを選定する立場になったことがなく、
「○○は使うもの。だって○○さんが決めたから」という感覚しかないから話が通じない。
そして、自分がそうであるから、頭ごなしに「jQueryを使え」と布教しているわけだが、
本来は、どのライブラリ/フレームワークを使うかは、
各自が、「どうせ同じようなコードを書くことになる」かどうかで判断することなんだよ。
そして、jQueryには、もう、「どうせ同じようなコードを書くことになる」理由がなくなってしまっている。
だから脱jQueryも自然な流れであってさ。あれは、意識高い系が、って話ではないんだよ。
というか、お前は初心者の発想から抜け出せていない。
話が通じないのは、これが原因かもしれん。
本来は、ライブラリ/フレームワークは「きちんと選んで使うもの」だ。
基準は彼等がよく言う、「どうせ同じようなコードを書くことになる」が分かりやすくていい。
だから本来は、「それがなかったら同じようなコードを書く奴だけが使え」というのも正しくて、偶にこれを言ってる奴もいるだろ。
現実はそうも行かず、全く意味分からない初心者も含めて使え、ということになっているが。
実際、「どうせ同じようなコードを書くことになる」は事実だ。
大規模化したコードの生産性を上げる為には、何らかのプチライブラリ/フレームワークが内部的に必要になる。
(敢えてそれをしない、というスタイルの奴も偶にいるが)
SPA向けのフレームワークは、SPAで典型的に必要になる制御に対し、枠組みを提供するものだ。
当然、無ければ無いで書けるが、彼等の指摘通り、「どうせ同じようなコードを書くことになる」。
なら、ジャストフィットする物があれば、使った方が楽だ。
jQueryも同じで、「どうせ同じようなコードを書くことになる」のなら、使うのは正しい。
つまり、ブラウザの差異を吸収する為に、或いはCSSセレクタを使う為に、jQueryと同じようなコードがどうせ必要な場合だ。
ところが、これらは環境の整備がすすみ、なくなってしまった。
なら、もう要らなくね?というのも自然な発想だ。
彼等は原点を忘れてなかったんだよ。
君にはライブラリを選定する立場になったことがなく、
「○○は使うもの。だって○○さんが決めたから」という感覚しかないから話が通じない。
そして、自分がそうであるから、頭ごなしに「jQueryを使え」と布教しているわけだが、
本来は、どのライブラリ/フレームワークを使うかは、
各自が、「どうせ同じようなコードを書くことになる」かどうかで判断することなんだよ。
そして、jQueryには、もう、「どうせ同じようなコードを書くことになる」理由がなくなってしまっている。
だから脱jQueryも自然な流れであってさ。あれは、意識高い系が、って話ではないんだよ。
506デフォルトの名無しさん
2018/11/13(火) 10:21:46.94ID:6pNagfSR いちいち長いからコードで端的に示してよ
507デフォルトの名無しさん
2018/11/13(火) 11:17:55.54ID:r1Hd5gXt ■ >>503 全行解説 (1/2)
> 同じ事を俺だけでも何回も指摘済みだが。
それがどれかを書かない
> 間違いを垂れ流すのは止めろ。
どれが間違いなのか言わない
> お前自身が馬鹿なのが初心者にも分かるだろうからお前では布教は無理だよ。
初心者でもわかるってことにしたい。無理と思い込みたい
> というか、何故お前は頑なに学習を拒む?
拒んでいない
> 他の『快適な』サイトがどういう作りになってるか見ればすぐに分かるはずなのだが。
快適なサイトがどれか書かない。見ればすぐに分かるってことにしたい
> そもそもjQueryを使っただけで、「遅くなり、jQueryに依存する」というデメリットが付いてくる。
速度は速ければ速いほど良いと思っている。問題があるそうかどうかという観点が抜けている。
依存するのは他のフレームワークの方がもっとひどい
> 『今も』それを越えるメリットがあると思えば使えばいいし、
だから3年たった今もみんな使っている
> それは看過出来ないと思う奴らはjQueryを既に捨ててる。それだけの話だ。
データには現れていない。むしろReactを捨ててる方が多かった。
> jQueryの最大のメリットは、お前みたいな馬鹿でも、どんなグダグダなHTMLでも、何とかなってしまうことだ。
どれをを使っても同じ。jQueryの技術から、利用者の能力へと話のすり替え
> だから(今のお前もやっているように)HTMLベースで組むのは最初は悪いことではないし、妥当だ。
最初と明言することで、それは最初だけなんだと思わせようとしている(実際にはプロはjQueryを使ってる。CSSベースで)
> 同じ事を俺だけでも何回も指摘済みだが。
それがどれかを書かない
> 間違いを垂れ流すのは止めろ。
どれが間違いなのか言わない
> お前自身が馬鹿なのが初心者にも分かるだろうからお前では布教は無理だよ。
初心者でもわかるってことにしたい。無理と思い込みたい
> というか、何故お前は頑なに学習を拒む?
拒んでいない
> 他の『快適な』サイトがどういう作りになってるか見ればすぐに分かるはずなのだが。
快適なサイトがどれか書かない。見ればすぐに分かるってことにしたい
> そもそもjQueryを使っただけで、「遅くなり、jQueryに依存する」というデメリットが付いてくる。
速度は速ければ速いほど良いと思っている。問題があるそうかどうかという観点が抜けている。
依存するのは他のフレームワークの方がもっとひどい
> 『今も』それを越えるメリットがあると思えば使えばいいし、
だから3年たった今もみんな使っている
> それは看過出来ないと思う奴らはjQueryを既に捨ててる。それだけの話だ。
データには現れていない。むしろReactを捨ててる方が多かった。
> jQueryの最大のメリットは、お前みたいな馬鹿でも、どんなグダグダなHTMLでも、何とかなってしまうことだ。
どれをを使っても同じ。jQueryの技術から、利用者の能力へと話のすり替え
> だから(今のお前もやっているように)HTMLベースで組むのは最初は悪いことではないし、妥当だ。
最初と明言することで、それは最初だけなんだと思わせようとしている(実際にはプロはjQueryを使ってる。CSSベースで)
508デフォルトの名無しさん
2018/11/13(火) 11:18:23.01ID:r1Hd5gXt ■ >>503 全行解説 (2/2)
> しかし、他の連中は色々学んで、それ以上の道を模索してる。
その他の連中が誰かを言わない。模索した結果がjQueryの利用者数に影響はなし
> それがフレームワークであったり、脱jQueryであったり、素で書け、みたいなことだったりする。
やっぱりjQueryでいいよねもその一つ
> フレームワークの使い方を覚えても「プログミングの本質的な腕前」には関係ないが、
> 各フレームワークがどこに問題を見いだし、どう解決しようとしたかを見ることは、
> 「プログミングの本質的な腕前」の上達に繋がる。
それと実際に使うかどうかは別の話
> フレームワークを模索している連中は、その過程で、どんどん前に進んでいく。
その結果が、Angular1からAngular2への作り直し、React止めたFacebook、Airbnb等。3歩進んで2歩下がる。
> お前はjQueryにこだわって、置き去りにされてるだけだ。(というよりそれをお前自身が望んでいる)
将来性不明ですぐ消える技術に振り回される連中を見て思う、Backboneに手を出さなくてよかった。Reactもかな?
> 他の人とお前が話が通じてないのはそのためだ。君が分かってなさすぎる。
どこがわかってないかの指摘がない。そういうことにしたいという希望
> ただそれ以前に、君は日本語が怪しいから、そこをまず詰めた方がいいが。
同上
まとめ
・新しいもの、新しいもの、と言ういうだけで成果がない
・技術に対して客観的な意見を言わない(速ければ良いわけじゃないってわかってるだろうにw)
・俺への指摘は、どれも根拠がない。(単なる個人攻撃)
> しかし、他の連中は色々学んで、それ以上の道を模索してる。
その他の連中が誰かを言わない。模索した結果がjQueryの利用者数に影響はなし
> それがフレームワークであったり、脱jQueryであったり、素で書け、みたいなことだったりする。
やっぱりjQueryでいいよねもその一つ
> フレームワークの使い方を覚えても「プログミングの本質的な腕前」には関係ないが、
> 各フレームワークがどこに問題を見いだし、どう解決しようとしたかを見ることは、
> 「プログミングの本質的な腕前」の上達に繋がる。
それと実際に使うかどうかは別の話
> フレームワークを模索している連中は、その過程で、どんどん前に進んでいく。
その結果が、Angular1からAngular2への作り直し、React止めたFacebook、Airbnb等。3歩進んで2歩下がる。
> お前はjQueryにこだわって、置き去りにされてるだけだ。(というよりそれをお前自身が望んでいる)
将来性不明ですぐ消える技術に振り回される連中を見て思う、Backboneに手を出さなくてよかった。Reactもかな?
> 他の人とお前が話が通じてないのはそのためだ。君が分かってなさすぎる。
どこがわかってないかの指摘がない。そういうことにしたいという希望
> ただそれ以前に、君は日本語が怪しいから、そこをまず詰めた方がいいが。
同上
まとめ
・新しいもの、新しいもの、と言ういうだけで成果がない
・技術に対して客観的な意見を言わない(速ければ良いわけじゃないってわかってるだろうにw)
・俺への指摘は、どれも根拠がない。(単なる個人攻撃)
509デフォルトの名無しさん
2018/11/13(火) 11:31:47.28ID:r1Hd5gXt ■ >>499 全行解説 (1/3)
> というか、お前は初心者の発想から抜け出せていない。
どこがという指摘がまた書いていない
> 話が通じないのは、これが原因かもしれん。
そういうことにしたいという希望
> 本来は、ライブラリ/フレームワークは「きちんと選んで使うもの」だ。
その結果jQueryになっただけの話
> 基準は彼等がよく言う、「どうせ同じようなコードを書くことになる」が分かりやすくていい。
「どうせ同じようなコードを(また別のフレームワークで)書くことになる」
> だから本来は、「それがなかったら同じようなコードを書く奴だけが使え」というのも正しくて、偶にこれを言ってる奴もいるだろ。
一体何の話を始めたのか?
> 現実はそうも行かず、全く意味分からない初心者も含めて使え、ということになっているが。
なっていることにしたいという願望
> 実際、「どうせ同じようなコードを書くことになる」は事実だ。
実際に書いてある。Backboneで書いてたら死んだ。Angular1で書いてたら、全く違うAngular2がでてきて作り直し
> 大規模化したコードの生産性を上げる為には、何らかのプチライブラリ/フレームワークが内部的に必要になる。
jQueryでいいじゃん。
> (敢えてそれをしない、というスタイルの奴も偶にいるが)
だからなんなんだろう?
> SPA向けのフレームワークは、SPAで典型的に必要になる制御に対し、枠組みを提供するものだ。
> 当然、無ければ無いで書けるが、彼等の指摘通り、「どうせ同じようなコードを書くことになる」。
また開発工数という概念が抜けてるのかな?時間が無限にあれば、誰でもなくてかける。
> というか、お前は初心者の発想から抜け出せていない。
どこがという指摘がまた書いていない
> 話が通じないのは、これが原因かもしれん。
そういうことにしたいという希望
> 本来は、ライブラリ/フレームワークは「きちんと選んで使うもの」だ。
その結果jQueryになっただけの話
> 基準は彼等がよく言う、「どうせ同じようなコードを書くことになる」が分かりやすくていい。
「どうせ同じようなコードを(また別のフレームワークで)書くことになる」
> だから本来は、「それがなかったら同じようなコードを書く奴だけが使え」というのも正しくて、偶にこれを言ってる奴もいるだろ。
一体何の話を始めたのか?
> 現実はそうも行かず、全く意味分からない初心者も含めて使え、ということになっているが。
なっていることにしたいという願望
> 実際、「どうせ同じようなコードを書くことになる」は事実だ。
実際に書いてある。Backboneで書いてたら死んだ。Angular1で書いてたら、全く違うAngular2がでてきて作り直し
> 大規模化したコードの生産性を上げる為には、何らかのプチライブラリ/フレームワークが内部的に必要になる。
jQueryでいいじゃん。
> (敢えてそれをしない、というスタイルの奴も偶にいるが)
だからなんなんだろう?
> SPA向けのフレームワークは、SPAで典型的に必要になる制御に対し、枠組みを提供するものだ。
> 当然、無ければ無いで書けるが、彼等の指摘通り、「どうせ同じようなコードを書くことになる」。
また開発工数という概念が抜けてるのかな?時間が無限にあれば、誰でもなくてかける。
510デフォルトの名無しさん
2018/11/13(火) 11:32:03.32ID:r1Hd5gXt ■ >>499 全行解説 (2/3)
> なら、ジャストフィットする物があれば、使った方が楽だ。
大部分のウェブサイトにはSPA向けのフレームワークはフィットしない。ジャストフィットするjQueryを使ったほうが楽だ
> jQueryも同じで、「どうせ同じようなコードを書くことになる」のなら、使うのは正しい。
10年前のコードが今も同じように動く
> つまり、ブラウザの差異を吸収する為に、或いはCSSセレクタを使う為に、jQueryと同じようなコードがどうせ必要な場合だ。
ブラウザの差異を吸収する時代は終わってる。今は純粋なDOM操作ライブラリだ
> ところが、これらは環境の整備がすすみ、なくなってしまった。
> なら、もう要らなくね?というのも自然な発想だ。
「 当然、無ければ無いで書けるが、」といったのは誰だったか。確か開発工数という概念が抜けてる人だったか
> 彼等は原点を忘れてなかったんだよ。
原点はDOM。それを便利に操作するライブラリ
> 君にはライブラリを選定する立場になったことがなく、
・俺への指摘は、どれも根拠がない。
> 「○○は使うもの。だって○○さんが決めたから」という感覚しかないから話が通じない。
・俺への指摘は、どれも根拠がない。
> そして、自分がそうであるから、頭ごなしに「jQueryを使え」と布教しているわけだが、
>>499で動くコードも書いている。お前はなにか書いたか?「頭ごなしにjQueryを使うな」だろ
> 本来は、どのライブラリ/フレームワークを使うかは、
> 各自が、「どうせ同じようなコードを書くことになる」かどうかで判断することなんだよ。
許容範囲のデメリット中で、どれだけ楽になるかだろ
> なら、ジャストフィットする物があれば、使った方が楽だ。
大部分のウェブサイトにはSPA向けのフレームワークはフィットしない。ジャストフィットするjQueryを使ったほうが楽だ
> jQueryも同じで、「どうせ同じようなコードを書くことになる」のなら、使うのは正しい。
10年前のコードが今も同じように動く
> つまり、ブラウザの差異を吸収する為に、或いはCSSセレクタを使う為に、jQueryと同じようなコードがどうせ必要な場合だ。
ブラウザの差異を吸収する時代は終わってる。今は純粋なDOM操作ライブラリだ
> ところが、これらは環境の整備がすすみ、なくなってしまった。
> なら、もう要らなくね?というのも自然な発想だ。
「 当然、無ければ無いで書けるが、」といったのは誰だったか。確か開発工数という概念が抜けてる人だったか
> 彼等は原点を忘れてなかったんだよ。
原点はDOM。それを便利に操作するライブラリ
> 君にはライブラリを選定する立場になったことがなく、
・俺への指摘は、どれも根拠がない。
> 「○○は使うもの。だって○○さんが決めたから」という感覚しかないから話が通じない。
・俺への指摘は、どれも根拠がない。
> そして、自分がそうであるから、頭ごなしに「jQueryを使え」と布教しているわけだが、
>>499で動くコードも書いている。お前はなにか書いたか?「頭ごなしにjQueryを使うな」だろ
> 本来は、どのライブラリ/フレームワークを使うかは、
> 各自が、「どうせ同じようなコードを書くことになる」かどうかで判断することなんだよ。
許容範囲のデメリット中で、どれだけ楽になるかだろ
511デフォルトの名無しさん
2018/11/13(火) 11:32:19.13ID:r1Hd5gXt ■ >>499 全行解説 (3/3)
> そして、jQueryには、もう、「どうせ同じようなコードを書くことになる」理由がなくなってしまっている。
大規模化してて書くことがたくさんあるんでしょ?その書いてる「同じようなコードを簡潔に書ける」のが理由なんだけど?
もう何も書かないで動くって話?CSSでできるならそりゃCSSでやるけど?
> だから脱jQueryも自然な流れであってさ。あれは、意識高い系が、って話ではないんだよ。
わざわざ言うのは、意識高い系がって思ってる証拠だな
> そして、jQueryには、もう、「どうせ同じようなコードを書くことになる」理由がなくなってしまっている。
大規模化してて書くことがたくさんあるんでしょ?その書いてる「同じようなコードを簡潔に書ける」のが理由なんだけど?
もう何も書かないで動くって話?CSSでできるならそりゃCSSでやるけど?
> だから脱jQueryも自然な流れであってさ。あれは、意識高い系が、って話ではないんだよ。
わざわざ言うのは、意識高い系がって思ってる証拠だな
512デフォルトの名無しさん
2018/11/13(火) 11:39:38.27ID:r1Hd5gXt これは「反論」ではなく「解説」であることに注意なw
みんなも解説を見ながら、やつが言ってることを聞きましょう。
みんなも解説を見ながら、やつが言ってることを聞きましょう。
513デフォルトの名無しさん
2018/11/13(火) 12:27:14.40ID:LlWHgPon 別にjQuery信者がどう考えてどう主張してどう使おうがどうでもいいじゃん
今あるものを大切に使って最低限の努力で目的を達成しようとするのも良いことだし
今あるものを大切に使って最低限の努力で目的を達成しようとするのも良いことだし
514デフォルトの名無しさん
2018/11/13(火) 12:32:59.50ID:M3rNGpof 糖質?
515デフォルトの名無しさん
2018/11/13(火) 13:02:09.89ID:vFkN1i8a 高い品質を求め続けて死んでいった日本の製造業みたいな考え方
516デフォルトの名無しさん
2018/11/13(火) 13:07:57.58ID:YD+aXj03 晩年は品質もそんなよくなかったのかなけどな。
517デフォルトの名無しさん
2018/11/13(火) 13:08:19.33ID:YD+aXj03 予測変換クソやな
518デフォルトの名無しさん
2018/11/13(火) 13:30:53.90ID:6Th2Z+aX >>507-512
お前にはそう読めるのだろうが、普通の人ならそうは読めない。
例えば、
> > 同じ事を俺だけでも何回も指摘済みだが。
> それがどれかを書かない
直前の行に書いてるだろ。再掲すると、
> >>497
> >>103
> 同じ事を俺だけでも何回も指摘済みだが。
103に決まってるだろ。
いまいちお前の頭がどういう風に障害持ちなのか分からないが、
どうやら君は非常に断片的にしか読めなくて、
これまでは2行単位でしか読んでなかったが、今はもう1行単位でしか読めなくなってる。
そして直前の行すら無視するのだから、話が通じるはずがない。
それでは一般の文章、例えば公式の紹介文も読めないと思うが。
ただお前のタイプ、リアルで遭遇するのは(俺には)ないが、ここ(2ch)で遭遇するのは3人目だ。
(お前が前から居るのは認識していたが)
何か2chにそういうのを集める理由があるのだろう。
もう少し軽度な奴、4レス前までしか追えない奴もJavaScriptスレの周りにいる。
ただこいつは4『レス』だから『忘れっぽい奴』位で対応出来るが、
さすがに直前の行も読めないようでは話は無理だ。空回りしすぎる。
お前にはそう読めるのだろうが、普通の人ならそうは読めない。
例えば、
> > 同じ事を俺だけでも何回も指摘済みだが。
> それがどれかを書かない
直前の行に書いてるだろ。再掲すると、
> >>497
> >>103
> 同じ事を俺だけでも何回も指摘済みだが。
103に決まってるだろ。
いまいちお前の頭がどういう風に障害持ちなのか分からないが、
どうやら君は非常に断片的にしか読めなくて、
これまでは2行単位でしか読んでなかったが、今はもう1行単位でしか読めなくなってる。
そして直前の行すら無視するのだから、話が通じるはずがない。
それでは一般の文章、例えば公式の紹介文も読めないと思うが。
ただお前のタイプ、リアルで遭遇するのは(俺には)ないが、ここ(2ch)で遭遇するのは3人目だ。
(お前が前から居るのは認識していたが)
何か2chにそういうのを集める理由があるのだろう。
もう少し軽度な奴、4レス前までしか追えない奴もJavaScriptスレの周りにいる。
ただこいつは4『レス』だから『忘れっぽい奴』位で対応出来るが、
さすがに直前の行も読めないようでは話は無理だ。空回りしすぎる。
519デフォルトの名無しさん
2018/11/13(火) 13:33:23.34ID:r1Hd5gXt >>513
多分、俺達が古いものをいつまでも使っていたらウェブが発展しない!
俺たちがウェブを変えていくんだ!とかいう謎の使命感(笑)に燃えてるんだと思うw
新しいものと速いことに執着しているのがその証
こっちは適切なタイミングで適切な道具を使うだけなのにね。
多分、俺達が古いものをいつまでも使っていたらウェブが発展しない!
俺たちがウェブを変えていくんだ!とかいう謎の使命感(笑)に燃えてるんだと思うw
新しいものと速いことに執着しているのがその証
こっちは適切なタイミングで適切な道具を使うだけなのにね。
520デフォルトの名無しさん
2018/11/13(火) 14:00:13.79ID:r1Hd5gXt >>518
なんか本気で勘違いしているみたいだから、訂正してあげるね
あんたが出してきたのは以下の 1) と 2.1) のみ、もともと 1) の話はしてないし、
肝心の 2.2) の話はどこ言ったの?
1) Usage of client-side programming languages for websites (JavaScript言語の使用率)
https://w3techs.com/technologies/overview/client_side_language/all
JavaScript 95.0%、Flash 4.1%、Silverlight 0.1%
2) Usage of JavaScript libraries for websites (JavaScriptライブラリの使用率)
https://w3techs.com/technologies/overview/javascript_library/all
2.1) Historical trends in the usage of JavaScript libraries for websites
https://w3techs.com/technologies/history_overview/javascript_library/all
jQueryは73.5%、未使用は24.4%
2.2) Market share trends for JavaScript libraries for websites
https://w3techs.com/technologies/history_overview/javascript_library
jQueryは97.2% (未使用を含めない場合、だから書いていない)
まとめると、ウェブサイトでJavaScript言語を使用しているのは95%で
(言語の使用率とは関係なく)
ウェブサイトでJavaScriptライブラリの使用率はjQueryが73.5%
・jQuery 2015年:61.5%↑、2016年:68.3%↑、2017年:71.9%↑、2018年:73.1%↑、現在:73.5%↑
・未使用 2015年:35.0%↓、2016年:28.7%↓、2017年:25.5%↓、2018年:24.0%↓、現在:24.4%↑
JavaScriptライブラリの中でのjQueryの使用率は97.2%
・jQuery 2015年:94.5%↑、2016年:95.8%↑、2017年:96.4%↑、2018年:96.2%↓、現在:97.2%↑
矢印は前年から上がってるか下がってるか
なんか本気で勘違いしているみたいだから、訂正してあげるね
あんたが出してきたのは以下の 1) と 2.1) のみ、もともと 1) の話はしてないし、
肝心の 2.2) の話はどこ言ったの?
1) Usage of client-side programming languages for websites (JavaScript言語の使用率)
https://w3techs.com/technologies/overview/client_side_language/all
JavaScript 95.0%、Flash 4.1%、Silverlight 0.1%
2) Usage of JavaScript libraries for websites (JavaScriptライブラリの使用率)
https://w3techs.com/technologies/overview/javascript_library/all
2.1) Historical trends in the usage of JavaScript libraries for websites
https://w3techs.com/technologies/history_overview/javascript_library/all
jQueryは73.5%、未使用は24.4%
2.2) Market share trends for JavaScript libraries for websites
https://w3techs.com/technologies/history_overview/javascript_library
jQueryは97.2% (未使用を含めない場合、だから書いていない)
まとめると、ウェブサイトでJavaScript言語を使用しているのは95%で
(言語の使用率とは関係なく)
ウェブサイトでJavaScriptライブラリの使用率はjQueryが73.5%
・jQuery 2015年:61.5%↑、2016年:68.3%↑、2017年:71.9%↑、2018年:73.1%↑、現在:73.5%↑
・未使用 2015年:35.0%↓、2016年:28.7%↓、2017年:25.5%↓、2018年:24.0%↓、現在:24.4%↑
JavaScriptライブラリの中でのjQueryの使用率は97.2%
・jQuery 2015年:94.5%↑、2016年:95.8%↑、2017年:96.4%↑、2018年:96.2%↓、現在:97.2%↑
矢印は前年から上がってるか下がってるか
521デフォルトの名無しさん
2018/11/13(火) 14:08:07.48ID:r1Hd5gXt こうやって見ると、おめでとう。ようやく今年、JavaScriptライブラリ未使用の
ウェブサイトが少しだけ増えた。だがjQueryを使用してるサイトも同じだけ増えたw
って感じだなw
>>520にはJavaScriptを使ってないサイトはデータとして出てきてないね
HTMLとCSSだけのページも相当数あるだろうにそのデータはないのかな?
それがないとJavaScriptライブラリを使わないで、
JavaScriptを使ってるサイトの割合はわからないね
ウェブサイトが少しだけ増えた。だがjQueryを使用してるサイトも同じだけ増えたw
って感じだなw
>>520にはJavaScriptを使ってないサイトはデータとして出てきてないね
HTMLとCSSだけのページも相当数あるだろうにそのデータはないのかな?
それがないとJavaScriptライブラリを使わないで、
JavaScriptを使ってるサイトの割合はわからないね
522デフォルトの名無しさん
2018/11/13(火) 14:09:29.80ID:r1Hd5gXt 訂正
× まとめると、ウェブサイトでJavaScript言語を使用しているのは95%で
○ まとめると、ウェブサイトでクライアントサイド言語を使用しているサイトのうちJavaScriptを使用しているのは95%で
× まとめると、ウェブサイトでJavaScript言語を使用しているのは95%で
○ まとめると、ウェブサイトでクライアントサイド言語を使用しているサイトのうちJavaScriptを使用しているのは95%で
523デフォルトの名無しさん
2018/11/13(火) 15:49:33.25ID:LlWHgPon ライブラリ未使用とかこだわりポイントが意味不明
ESでもスタンダードライブラリの仕様策定と実装が進んでるじゃん
エクステンシブルWebの精神で行くと小さなライブラリたくさん組み合わせるのがセオリーだし
そういう点でjQueryって組み合わせづらくて古臭いねって言うのだけは分かる
ESでもスタンダードライブラリの仕様策定と実装が進んでるじゃん
エクステンシブルWebの精神で行くと小さなライブラリたくさん組み合わせるのがセオリーだし
そういう点でjQueryって組み合わせづらくて古臭いねって言うのだけは分かる
524デフォルトの名無しさん
2018/11/13(火) 16:43:01.03ID:r1Hd5gXt > そういう点でjQueryって組み合わせづらくて古臭いねって言うのだけは分かる
ふーん、どんな所がか言える?
言えないでしょう?
ふーん、どんな所がか言える?
言えないでしょう?
525デフォルトの名無しさん
2018/11/13(火) 19:22:34.71ID:6Th2Z+aX >>520
相変わらず意図的に間違えてるよな。
いや実は素で間違えているのかもしれんが、多すぎて意図的だと読めるんだよ、普通の人には。
まあもういいが。
>>523
> ライブラリ未使用とかこだわりポイントが意味不明
彼等はそこにこだわっているわけではないと思うが。
結局この話題はひたすらに水掛け論だな。
本来は、「なければないでも出来るが、面倒だからjQueryを使う」というスタンスが正しいのだが、
jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。
ま、結果は待つしかないし、待てばいいだけだが。
「jQuery、いつ止めるの?今でしょ!」な人が今止めてるだけ。
GitHubも公式声明出しているが、当然だがプログラマ目線だ。
https://githubengineering.com/removing-jquery-from-github-frontend/
実際の所、1回作って終わりのWebページならほぼどうでもいいのも事実だし、
彼等が脱jQueryするかはまた別の問題だ。
ただ俺は、デザイナが無理してJavaScriptをいじること自体が間違いだと思っていて、
今のところ静的HPフレームワークに吸収されるのではないか、と見ている。
WordPress等も普通なら吸収する方向に動いているはずだが、そうでもないのか?
相変わらず意図的に間違えてるよな。
いや実は素で間違えているのかもしれんが、多すぎて意図的だと読めるんだよ、普通の人には。
まあもういいが。
>>523
> ライブラリ未使用とかこだわりポイントが意味不明
彼等はそこにこだわっているわけではないと思うが。
結局この話題はひたすらに水掛け論だな。
本来は、「なければないでも出来るが、面倒だからjQueryを使う」というスタンスが正しいのだが、
jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。
ま、結果は待つしかないし、待てばいいだけだが。
「jQuery、いつ止めるの?今でしょ!」な人が今止めてるだけ。
GitHubも公式声明出しているが、当然だがプログラマ目線だ。
https://githubengineering.com/removing-jquery-from-github-frontend/
実際の所、1回作って終わりのWebページならほぼどうでもいいのも事実だし、
彼等が脱jQueryするかはまた別の問題だ。
ただ俺は、デザイナが無理してJavaScriptをいじること自体が間違いだと思っていて、
今のところ静的HPフレームワークに吸収されるのではないか、と見ている。
WordPress等も普通なら吸収する方向に動いているはずだが、そうでもないのか?
526デフォルトの名無しさん
2018/11/13(火) 19:37:33.16ID:6OG45u85 ねえ、これいつまで続くの?
527デフォルトの名無しさん
2018/11/13(火) 19:57:23.03ID:r1Hd5gXt >>525
> 相変わらず意図的に間違えてるよな。
いつもどおりですが、どこをどう間違えているかを言わない。
> jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。
誰もそんな事は言ってない。いつもの思い込み。お前の願望。
話が進まないのは、お前が答えるべきことに何一つ答えないからやで
毎回毎回。答えない。言わないと。俺が教えてやってると言うのにw
> ま、結果は待つしかないし、待てばいいだけだが。
もう3年待った
> 「jQuery、いつ止めるの?今でしょ!」な人が今止めてるだけ。
あ、止めたんだw 飽きたんだね。ネガティブキャンペーンに
> GitHubも公式声明出しているが、当然だがプログラマ目線だ。
見るのはそこじゃない。本来書いてあるべきことのの
「やめてどういうメリットがあったかが書かれてない」ってのが重要
あれ読んでも「あ、やめたんすね。GitHubレベルの技術者でも
大変で時間がかかったんですね。メリットは?」って思うだけ
> 相変わらず意図的に間違えてるよな。
いつもどおりですが、どこをどう間違えているかを言わない。
> jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。
誰もそんな事は言ってない。いつもの思い込み。お前の願望。
話が進まないのは、お前が答えるべきことに何一つ答えないからやで
毎回毎回。答えない。言わないと。俺が教えてやってると言うのにw
> ま、結果は待つしかないし、待てばいいだけだが。
もう3年待った
> 「jQuery、いつ止めるの?今でしょ!」な人が今止めてるだけ。
あ、止めたんだw 飽きたんだね。ネガティブキャンペーンに
> GitHubも公式声明出しているが、当然だがプログラマ目線だ。
見るのはそこじゃない。本来書いてあるべきことのの
「やめてどういうメリットがあったかが書かれてない」ってのが重要
あれ読んでも「あ、やめたんすね。GitHubレベルの技術者でも
大変で時間がかかったんですね。メリットは?」って思うだけ
528デフォルトの名無しさん
2018/11/13(火) 19:58:21.09ID:YD+aXj03 もしかして: 自演
529デフォルトの名無しさん
2018/11/13(火) 19:58:57.20ID:r1Hd5gXt >>526
> ねえ、これいつまで続くの?
jQueryの使用率が今より10%さがるか、Bootstrap、Modernizer、Underscoreを除く
他のUI関連のフレームワーク・ライブラリの使用率が10%を超えたらかな
(なぜこの3つを除くかというと、Bootstrapは本来CSSフレームワークで
JavaScript部分にはjQueryを使っているから。Modernizerはブラウザが搭載している
機能判定をする補処的なライブラリでそれ自体で何かをするものじゃないから。
Underscoreは古いブラウザでも使える関数型風のライブラリでUIとは関係ない。
そして俺のお気に入りの一つだからw)
あいつがやめなくても俺がやめてあげよう。
だからすぐだよ!(皮肉w)
> ねえ、これいつまで続くの?
jQueryの使用率が今より10%さがるか、Bootstrap、Modernizer、Underscoreを除く
他のUI関連のフレームワーク・ライブラリの使用率が10%を超えたらかな
(なぜこの3つを除くかというと、Bootstrapは本来CSSフレームワークで
JavaScript部分にはjQueryを使っているから。Modernizerはブラウザが搭載している
機能判定をする補処的なライブラリでそれ自体で何かをするものじゃないから。
Underscoreは古いブラウザでも使える関数型風のライブラリでUIとは関係ない。
そして俺のお気に入りの一つだからw)
あいつがやめなくても俺がやめてあげよう。
だからすぐだよ!(皮肉w)
530デフォルトの名無しさん
2018/11/13(火) 20:10:44.94ID:YD+aXj03 https://github.com/twbs/bootstrap/issues/23204
によるとjQuery外すつもりだが人手が足りなくて無理らしい。Please help!とか言ってるわw
によるとjQuery外すつもりだが人手が足りなくて無理らしい。Please help!とか言ってるわw
531デフォルトの名無しさん
2018/11/13(火) 20:28:06.61ID:m5sWDhru >>524
全てだよ
jQueryって簡単に言うとライブラリと言うよりフレームワークだから
まずjQueryオブジェクトにラップする時点で
どう考えても他のDOM操作系のライブラリと相互親和性低いじゃん
jQueryはjQueryの世界で閉じちゃってるのは紛れもない事実
だからJSかjQueryかみたいな比較もしばしばされるでしょ?
それが良いとこでもあり悪いとこでもあるけど、
先にも述べたように某マニフェスト的な精神で見ると古臭い
全てだよ
jQueryって簡単に言うとライブラリと言うよりフレームワークだから
まずjQueryオブジェクトにラップする時点で
どう考えても他のDOM操作系のライブラリと相互親和性低いじゃん
jQueryはjQueryの世界で閉じちゃってるのは紛れもない事実
だからJSかjQueryかみたいな比較もしばしばされるでしょ?
それが良いとこでもあり悪いとこでもあるけど、
先にも述べたように某マニフェスト的な精神で見ると古臭い
532デフォルトの名無しさん
2018/11/13(火) 20:30:56.09ID:YD+aXj03 > jQueryって簡単に言うとライブラリと言うよりフレームワークだから
jQuery: The Write Less, Do More, JavaScript Library.
https://jquery.com
jQuery: The Write Less, Do More, JavaScript Library.
https://jquery.com
533デフォルトの名無しさん
2018/11/13(火) 20:38:55.64ID:GaZRhG0n jqueryはdesignerが触れるという意味において、流行ってるな。
534デフォルトの名無しさん
2018/11/13(火) 21:18:27.76ID:m5sWDhru >>532
自身がどう名乗ってるかはどうでもいい
そういう話はしていないから
ここでは
問題解決のための汎用性が高い機能を集めたもの:ライブラリ
問題解決のための枠組みを提供するもの:フレームワーク
という専ら粒度的な意味で使ってることは君も分かりきってるのに
全く無駄でしか無いレスを返すのは控えてくれ
一度警告したから、次からは取合ないよ
自身がどう名乗ってるかはどうでもいい
そういう話はしていないから
ここでは
問題解決のための汎用性が高い機能を集めたもの:ライブラリ
問題解決のための枠組みを提供するもの:フレームワーク
という専ら粒度的な意味で使ってることは君も分かりきってるのに
全く無駄でしか無いレスを返すのは控えてくれ
一度警告したから、次からは取合ないよ
535デフォルトの名無しさん
2018/11/13(火) 21:32:36.37ID:YD+aXj03 お前がどう思ってるかはどうでもいい。
536デフォルトの名無しさん
2018/11/13(火) 22:02:02.21ID:6Th2Z+aX >>527
君との話が進まないのは、君が毎回誤解/曲解して、その修正に1レス以上必要だからだ。
だからまじめにいちいち修正してたらいつまで経っても進めないし、
ならばと誤解を無視して強引に進めたら周りが混乱したようだし、これも不味かった。
GitHubが何を言ってるのか分からないのは、君がプログラマではないからだ。
(ただ、君はデザイナなのだから、分からなくてもいい)
プログラマなら、ああ、なるほどね、と理解は出来る。共感するかはまた別だが。
とはいえ、イノベーター連中が騒いでいたのとは違い、GitHubはおそらくアーリーアダプターに位置する。
この彼等が動いた、というのは大きいんだよ。
まあとにかく、君の言い分は分かった。
いずれにしても水掛け論だし、俺はここら辺でももういい。
プログラマにとっては、jQueryの問題点は色々あって、それはもう共通認識だ。
だからこそ、いつ脱jQueryするか、という話になる。
勿論、ずっとしない、というのも一つの選択だ。ただ、これもまた、非常に勇気の要る選択ではあるんだよ。
だからみんな顔色をうかがっているわけでさ。
君みたいなデザイナも脱jQueryするかは俺には分からん。
ただ、俺はデザイナは脱JavaScriptするべきだし、環境もそう整備される、と思っている。
君との話が進まないのは、君が毎回誤解/曲解して、その修正に1レス以上必要だからだ。
だからまじめにいちいち修正してたらいつまで経っても進めないし、
ならばと誤解を無視して強引に進めたら周りが混乱したようだし、これも不味かった。
GitHubが何を言ってるのか分からないのは、君がプログラマではないからだ。
(ただ、君はデザイナなのだから、分からなくてもいい)
プログラマなら、ああ、なるほどね、と理解は出来る。共感するかはまた別だが。
とはいえ、イノベーター連中が騒いでいたのとは違い、GitHubはおそらくアーリーアダプターに位置する。
この彼等が動いた、というのは大きいんだよ。
まあとにかく、君の言い分は分かった。
いずれにしても水掛け論だし、俺はここら辺でももういい。
プログラマにとっては、jQueryの問題点は色々あって、それはもう共通認識だ。
だからこそ、いつ脱jQueryするか、という話になる。
勿論、ずっとしない、というのも一つの選択だ。ただ、これもまた、非常に勇気の要る選択ではあるんだよ。
だからみんな顔色をうかがっているわけでさ。
君みたいなデザイナも脱jQueryするかは俺には分からん。
ただ、俺はデザイナは脱JavaScriptするべきだし、環境もそう整備される、と思っている。
537デフォルトの名無しさん
2018/11/14(水) 01:38:21.51ID:Da4Ohzbn >>531
> まずjQueryオブジェクトにラップする時点で
> どう考えても他のDOM操作系のライブラリと相互親和性低いじゃん
「ラップしてるから親和性低いはずだ」というのが根拠ない思い込みで、
他のDOM操作系ライブラリの方に問題があったら話は別だが、
jQueryは標準のDOM APIとの親和性が高い
例えば、これはDOM APIのquerySelectorAllを使って
要素を繰り返すコードだが
const es = document.querySelectorAll("li");
for(const e of es) {
console.log(e.textContent); // 当然のことながらeはDOM APIの要素
};
jQueryでも、そのまま使える。
const es = $("li");
for(const e of es) {
console.log(e.textContent); // eはDOM APIの要素
};
その逆でDOM APIの関数の戻り値をjQueryで使いたければ、そのままjQueryに渡せばよい
$( document.querySelectorAll("li") ).css({color: 'red'});
実際に動くサンプル
https://jsfiddle.net/x7nvc4og/
また以下のDOM APIのaddEventListenerとeventを使ったイベントハンドラだが
jQueryでも同じイベントハンドラがそのまま使える
https://developer.mozilla.org/ja/docs/Web/API/Event/target
実際に動くサンプル
https://jsfiddle.net/26Lw4kdg/
見てわかるようにjQueryはDOM APIと混ぜて使えるほど、親和性が高いんだよ
> まずjQueryオブジェクトにラップする時点で
> どう考えても他のDOM操作系のライブラリと相互親和性低いじゃん
「ラップしてるから親和性低いはずだ」というのが根拠ない思い込みで、
他のDOM操作系ライブラリの方に問題があったら話は別だが、
jQueryは標準のDOM APIとの親和性が高い
例えば、これはDOM APIのquerySelectorAllを使って
要素を繰り返すコードだが
const es = document.querySelectorAll("li");
for(const e of es) {
console.log(e.textContent); // 当然のことながらeはDOM APIの要素
};
jQueryでも、そのまま使える。
const es = $("li");
for(const e of es) {
console.log(e.textContent); // eはDOM APIの要素
};
その逆でDOM APIの関数の戻り値をjQueryで使いたければ、そのままjQueryに渡せばよい
$( document.querySelectorAll("li") ).css({color: 'red'});
実際に動くサンプル
https://jsfiddle.net/x7nvc4og/
また以下のDOM APIのaddEventListenerとeventを使ったイベントハンドラだが
jQueryでも同じイベントハンドラがそのまま使える
https://developer.mozilla.org/ja/docs/Web/API/Event/target
実際に動くサンプル
https://jsfiddle.net/26Lw4kdg/
見てわかるようにjQueryはDOM APIと混ぜて使えるほど、親和性が高いんだよ
538デフォルトの名無しさん
2018/11/14(水) 01:57:17.84ID:Da4Ohzbn jQueryがなぜDOM APIとこんなにも親和性が高いかと言うと、
DOM APIとの互換性を強く意識して設計されているからなんだよ
例えば、jQueryのEventオブジェクト
https://api.jquery.com/category/events/event-object/
ここに書いているように、独自に作り出されたものじゃなく、
標準のDOM APIのEventオブジェクトへのPolifillになっている
> jQuery's event system normalizes the event object according to W3C standards.
> The event object is guaranteed to be passed to the event handler.
> Most properties from the original event are copied over and normalized to the new event object.
Google翻訳
> jQueryのイベントシステムは、W3C標準に従ってイベントオブジェクトを正規化します。
> イベントオブジェクトは、イベントハンドラに渡されることが保証されています。
> 元のイベントのほとんどのプロパティは、新しいイベントオブジェクトにコピーされ、正規化されます。
またjQueryはDOM APIの document.querySelectorAll の戻り値であるNodeListに相当するものに
メソッドを追加したもの。NodeListにあるメソッドは要素を繰り返すためのものばかりで
NodeListの全ての要素に対して、一括でなにかをするメソッドはない
その反対でjQueryには要素一つを表すものは存在しない。NodeList相当のjQueryオブジェクトしか無いので
要素一つに対して何かをする場合は、DOM APIの要素をそのまま利用している
(例えばjQueryのeachメソッドのループ内で参照する要素一つやイベントハンドラ内のthisがDOM要素)
つまり
標準のDOM API・・・単一の要素に対してメソッドを呼び出す
jQuery・・・複数の要素に対してメソッドを呼び出す(単一要素を処理するときはDOM要素を使っている)
と機能を提供している対象が違っており、それぞれお互いを補完する形になっている。
DOM APIとの互換性を強く意識して設計されているからなんだよ
例えば、jQueryのEventオブジェクト
https://api.jquery.com/category/events/event-object/
ここに書いているように、独自に作り出されたものじゃなく、
標準のDOM APIのEventオブジェクトへのPolifillになっている
> jQuery's event system normalizes the event object according to W3C standards.
> The event object is guaranteed to be passed to the event handler.
> Most properties from the original event are copied over and normalized to the new event object.
Google翻訳
> jQueryのイベントシステムは、W3C標準に従ってイベントオブジェクトを正規化します。
> イベントオブジェクトは、イベントハンドラに渡されることが保証されています。
> 元のイベントのほとんどのプロパティは、新しいイベントオブジェクトにコピーされ、正規化されます。
またjQueryはDOM APIの document.querySelectorAll の戻り値であるNodeListに相当するものに
メソッドを追加したもの。NodeListにあるメソッドは要素を繰り返すためのものばかりで
NodeListの全ての要素に対して、一括でなにかをするメソッドはない
その反対でjQueryには要素一つを表すものは存在しない。NodeList相当のjQueryオブジェクトしか無いので
要素一つに対して何かをする場合は、DOM APIの要素をそのまま利用している
(例えばjQueryのeachメソッドのループ内で参照する要素一つやイベントハンドラ内のthisがDOM要素)
つまり
標準のDOM API・・・単一の要素に対してメソッドを呼び出す
jQuery・・・複数の要素に対してメソッドを呼び出す(単一要素を処理するときはDOM要素を使っている)
と機能を提供している対象が違っており、それぞれお互いを補完する形になっている。
539デフォルトの名無しさん
2018/11/14(水) 01:58:06.99ID:Da4Ohzbn540デフォルトの名無しさん
2018/11/14(水) 02:00:25.32ID:sJwxMrq1 なんでDOM APIとの互換性を考慮する必要があるの?ww
jQueryで全部できるんじゃないんですくぁ〜?wwwww
jQueryで全部できるんじゃないんですくぁ〜?wwwww
541デフォルトの名無しさん
2018/11/14(水) 02:08:33.10ID:Da4Ohzbn >>540
> なんでDOM APIとの互換性を考慮する必要があるの?ww
> jQueryで全部できるんじゃないんですくぁ〜?wwwww
だから、アンチjQueryが、jQueryを使っているならば
全部jQueryの世界で閉じてるはずだ!
jQueryで全部できるんじゃないですか〜って
思ってるのがそもそも間違いってことだよw
jQueryを使ったプログラミングでは日常的に標準のDOM要素を使っている。
実際にonのイベントハンドラ内のthisとかDOM要素なんだから。
jQueryは設計の時点で、標準のDOM要素を使うことを想定してある
それを知らないで、コードを上っ面だけ眺めて、全部jQueryでやってるように見える。
これ全部jQueryの世界だ。DOM APIの世界と全く違う!独自の世界だ!!
なんて言ってるから、呆れるわけでw
> なんでDOM APIとの互換性を考慮する必要があるの?ww
> jQueryで全部できるんじゃないんですくぁ〜?wwwww
だから、アンチjQueryが、jQueryを使っているならば
全部jQueryの世界で閉じてるはずだ!
jQueryで全部できるんじゃないですか〜って
思ってるのがそもそも間違いってことだよw
jQueryを使ったプログラミングでは日常的に標準のDOM要素を使っている。
実際にonのイベントハンドラ内のthisとかDOM要素なんだから。
jQueryは設計の時点で、標準のDOM要素を使うことを想定してある
それを知らないで、コードを上っ面だけ眺めて、全部jQueryでやってるように見える。
これ全部jQueryの世界だ。DOM APIの世界と全く違う!独自の世界だ!!
なんて言ってるから、呆れるわけでw
542デフォルトの名無しさん
2018/11/14(水) 02:23:13.08ID:Da4Ohzbn そうだ。良いことを思いついた。
NodeListにjQueryと同等のメソッドを追加すれば良いんじゃね!
標準のクラスを拡張するのはPrototype.jsで標準のメソッドとかぶり
痛い目を見た歴史があるが今の人類ならやれるかもしれん
jQueryの本質 = DOM APIに足りないNodeListへの一括操作メソッドを
提供してるってのがよく分かるだろう?
そうすりゃ標準のDOM APIを使っているように見えて
アンチjQueryさんも便利だねって満足するだろw
document.querySelectorAll("li").css({color: 'red'}) とか
document.querySelectorAll("li").on(function() {・・・} ) とか
左側が長すぎでバランス悪いな
document.querySelectorAll("li").addEventListener(function() {・・・} )
標準さんには、やっぱりこうか?w
NodeListにjQueryと同等のメソッドを追加すれば良いんじゃね!
標準のクラスを拡張するのはPrototype.jsで標準のメソッドとかぶり
痛い目を見た歴史があるが今の人類ならやれるかもしれん
jQueryの本質 = DOM APIに足りないNodeListへの一括操作メソッドを
提供してるってのがよく分かるだろう?
そうすりゃ標準のDOM APIを使っているように見えて
アンチjQueryさんも便利だねって満足するだろw
document.querySelectorAll("li").css({color: 'red'}) とか
document.querySelectorAll("li").on(function() {・・・} ) とか
左側が長すぎでバランス悪いな
document.querySelectorAll("li").addEventListener(function() {・・・} )
標準さんには、やっぱりこうか?w
543デフォルトの名無しさん
2018/11/14(水) 06:45:30.47ID:tTVxQWlP NodeListには全くタイプの異なる要素が含まれる可能性がある
それこそTextNodeとかも入りうるのにイベントやスタイルを一括処理するメソッドが入るのは不自然だろう
fiilterとか全部入れないといけなくなるし
そこはAPI提供先の言語の機能を借りた方が良いだろう
DOMってJSだけのものではないからね
それこそTextNodeとかも入りうるのにイベントやスタイルを一括処理するメソッドが入るのは不自然だろう
fiilterとか全部入れないといけなくなるし
そこはAPI提供先の言語の機能を借りた方が良いだろう
DOMってJSだけのものではないからね
544デフォルトの名無しさん
2018/11/14(水) 08:37:27.50ID:Da4Ohzbn >>543
> NodeListには全くタイプの異なる要素が含まれる可能性がある
なかなかおもしろいツッコミをしてくれたね 解説したくなっちゃうよw
jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ
これを見てほしい。なんとjQueryの引数には、セレクタや単一の要素、要素の配列だけではなく
任意のオブジェクトを渡すことができると、仕様にしっかりと明記されてるんだ
http://api.jquery.com/jQuery/#jQuery-object
> jQuery( object )
> object
> Type: PlainObject
> A plain object to wrap in a jQuery object.
だからタイプの異なる要素が含まれても問題ないと言うか、
必然的にそうなったと言うか、普通に作るとそうなるというか・・・
これjQueryが素晴らしいって話というよりも
「全くタイプの異なる要素が含まれても問題ない」ということに君が気づいていないだけ
これjQueryのプラグインを作ると理解できるんだよね。
例えば、console.logにA要素のURLとその文字列長を出力するlenという
jQueryプラグインを作る。そのコードは以下の通り
(function( $ ){
$.fn.len = function() {
return this.each(function() {
console.log(this.toString() + ':' + this.toString().length);
});
}
})( jQuery );
$("a").len(); と書くと全てのA要素のURLとその文字列長を出力する。
> NodeListには全くタイプの異なる要素が含まれる可能性がある
なかなかおもしろいツッコミをしてくれたね 解説したくなっちゃうよw
jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ
これを見てほしい。なんとjQueryの引数には、セレクタや単一の要素、要素の配列だけではなく
任意のオブジェクトを渡すことができると、仕様にしっかりと明記されてるんだ
http://api.jquery.com/jQuery/#jQuery-object
> jQuery( object )
> object
> Type: PlainObject
> A plain object to wrap in a jQuery object.
だからタイプの異なる要素が含まれても問題ないと言うか、
必然的にそうなったと言うか、普通に作るとそうなるというか・・・
これjQueryが素晴らしいって話というよりも
「全くタイプの異なる要素が含まれても問題ない」ということに君が気づいていないだけ
これjQueryのプラグインを作ると理解できるんだよね。
例えば、console.logにA要素のURLとその文字列長を出力するlenという
jQueryプラグインを作る。そのコードは以下の通り
(function( $ ){
$.fn.len = function() {
return this.each(function() {
console.log(this.toString() + ':' + this.toString().length);
});
}
})( jQuery );
$("a").len(); と書くと全てのA要素のURLとその文字列長を出力する。
545>>544の続き
2018/11/14(水) 08:38:50.65ID:Da4Ohzbn 上でjQueryには配列で管理していると書いたが、
上のコードにもあるように、eachメソッドでループしてそれぞれの
要素に対してメソッドを実行している。
jQuery関数の引数にセレクタを渡すとDOM要素の配列として内部で持ってるわけ
そしてそれぞれの要素に対してメソッド( 今回はtoString() )を実行しているだけなんだ。
ということは、つまり、このプラグインは、以下のような使い方もできる。
$(["red", "blue", "green"]).len();
jQueryオブジェクトでラップして使うための要件を要約すると
1. jQuery関数に渡したものは、配列に出来さえすればいい(すべてできる)
2. 配列をeachでループできればいい(配列なのでループできる)
3. オブジェクトに使用するメソッドが生えてさえすればいい
たったこれだけなんだ。DOM要素でなければいけないなんて要件はない。
配列化された個々のオブジェクトに使用するメソッドがあればいいだけなんだよ
(もちろんメソッドの有無を判定して、なければスキップすることもできる)
つまりな、全く異なるオブジェクトが入ろうが、ループで回してオブジェクトに
メソッドが生えていればそれを呼び出すだけなんだから、
まったく異なるタイプのオブジェクトだって対応できるんだよ
上のコードにもあるように、eachメソッドでループしてそれぞれの
要素に対してメソッドを実行している。
jQuery関数の引数にセレクタを渡すとDOM要素の配列として内部で持ってるわけ
そしてそれぞれの要素に対してメソッド( 今回はtoString() )を実行しているだけなんだ。
ということは、つまり、このプラグインは、以下のような使い方もできる。
$(["red", "blue", "green"]).len();
jQueryオブジェクトでラップして使うための要件を要約すると
1. jQuery関数に渡したものは、配列に出来さえすればいい(すべてできる)
2. 配列をeachでループできればいい(配列なのでループできる)
3. オブジェクトに使用するメソッドが生えてさえすればいい
たったこれだけなんだ。DOM要素でなければいけないなんて要件はない。
配列化された個々のオブジェクトに使用するメソッドがあればいいだけなんだよ
(もちろんメソッドの有無を判定して、なければスキップすることもできる)
つまりな、全く異なるオブジェクトが入ろうが、ループで回してオブジェクトに
メソッドが生えていればそれを呼び出すだけなんだから、
まったく異なるタイプのオブジェクトだって対応できるんだよ
546デフォルトの名無しさん
2018/11/14(水) 08:45:00.29ID:Da4Ohzbn これは、ダックタイピングの考え方そのものだよね
型は関係ない。使用するメソッドさえあればいい。
jQueryはDOMを扱うライブラリだから、
DOM要素でなければ引数に出来ないと思い込みがちなのはわかる。
だけど、jQueryで提供しているメソッドこそ、DOM操作用のメソッドってだけで
単一の要素を配列として操作するという設計は、DOM専用のものではなく
DOM以外にも適用可能なわけだ。
まさにこのような使い方ができる通り
$(["red", "blue", "green"]).len();
貼り忘れていた。実際に動くサンプル
https://jsfiddle.net/vxpk0yef/
型は関係ない。使用するメソッドさえあればいい。
jQueryはDOMを扱うライブラリだから、
DOM要素でなければ引数に出来ないと思い込みがちなのはわかる。
だけど、jQueryで提供しているメソッドこそ、DOM操作用のメソッドってだけで
単一の要素を配列として操作するという設計は、DOM専用のものではなく
DOM以外にも適用可能なわけだ。
まさにこのような使い方ができる通り
$(["red", "blue", "green"]).len();
貼り忘れていた。実際に動くサンプル
https://jsfiddle.net/vxpk0yef/
547デフォルトの名無しさん
2018/11/14(水) 08:54:39.25ID:Da4Ohzbn まあ、よくよく考えてみると、
> NodeListには全くタイプの異なる要素が含まれる可能性がある
$('.foo')と書いたって、全くタイプの異なる要素が含まれる可能性があるわけで。
例えば、$('.foo').prop('checked')と書いても、checkedプロパティが
存在しない要素の可能性もあるわけで、最初から対応済み。
(プロパティがなければスキップされる)今更なんだよねw
> NodeListには全くタイプの異なる要素が含まれる可能性がある
$('.foo')と書いたって、全くタイプの異なる要素が含まれる可能性があるわけで。
例えば、$('.foo').prop('checked')と書いても、checkedプロパティが
存在しない要素の可能性もあるわけで、最初から対応済み。
(プロパティがなければスキップされる)今更なんだよねw
548デフォルトの名無しさん
2018/11/14(水) 12:49:14.50ID:6FVvsHpP >>540
そういう大言はせめて、addEventListenerの第三引数が実装されてから、いえ
そういう大言はせめて、addEventListenerの第三引数が実装されてから、いえ
549デフォルトの名無しさん
2018/11/14(水) 12:58:16.26ID:6FVvsHpP >>543
俺はjQuery擁護派でも何でもないので、純粋に知的好奇心から尋ねるが、NodeListにテキストノードが入る再現コードは何だろう?
確かに、仕様上は要素ノードに限定されてはいないのだが、再現コードが分からんhttps://triple-underscore.github.io/DOM4-ja.html#interface-nodelist
俺はjQuery擁護派でも何でもないので、純粋に知的好奇心から尋ねるが、NodeListにテキストノードが入る再現コードは何だろう?
確かに、仕様上は要素ノードに限定されてはいないのだが、再現コードが分からんhttps://triple-underscore.github.io/DOM4-ja.html#interface-nodelist
550デフォルトの名無しさん
2018/11/14(水) 13:00:03.13ID:Da4Ohzbn >>548
それは互換性上の問題だから仕方ないね。
昔のIEには第三引数相当の機能がなかったんだから
別に今でも必要なら使える。jQueryは混ぜて使えるから
本格的な対応はjQuery 4.0の登場を待ちましょう。
https://github.com/jquery/jquery/wiki/jQuery-4.0-Event-Design
> Support all addEventListener options
> Avoid the need for a jQuery.Event wrapper
> Eliminate manual .trigger() bubbling and method calls
> Remove special events hooks
> Provide backcompat through Migrate 4.0
もうそろそろ3.4がリリースされる予定
今年の年末に4.0のベータ版を出すという話があったけど
遅れてるんだろうね
それは互換性上の問題だから仕方ないね。
昔のIEには第三引数相当の機能がなかったんだから
別に今でも必要なら使える。jQueryは混ぜて使えるから
本格的な対応はjQuery 4.0の登場を待ちましょう。
https://github.com/jquery/jquery/wiki/jQuery-4.0-Event-Design
> Support all addEventListener options
> Avoid the need for a jQuery.Event wrapper
> Eliminate manual .trigger() bubbling and method calls
> Remove special events hooks
> Provide backcompat through Migrate 4.0
もうそろそろ3.4がリリースされる予定
今年の年末に4.0のベータ版を出すという話があったけど
遅れてるんだろうね
551デフォルトの名無しさん
2018/11/14(水) 13:24:10.18ID:Da4Ohzbn >>549
わかってると思うがNodeListはNodeのコレクションなので、
理屈上はNode自身とそのサブクラスはコレクションに入れることができる
TextNodeはNodeのサブクラスなので入れることはできる
https://developer.mozilla.org/en-US/docs/Web/API/Text
>>543は全くタイプの異なる要素が入る可能性と言ってるがNodeでないものは入らない。
jQueryで言えば、contents()メソッドを使うと、jQueryオブジェクトにテキストノードが入る
サンプル
https://jsfiddle.net/32mwdfnc/
$("#id").contents().each(function() {
console.log(this.toString());
});
出力結果
[object Text]
[object HTMLSpanElement]
[object Text]
[object HTMLSpanElement]
俺の知る限りjQueryでテキストノードを取得する方法はこれだけだろう。
セレクタを使用している以上、セレクタから引っ張ってこれないものはメソッドを使って取得するしか無い
話はそれたが、NodeListにテキストノードが入る再現コードだが、同様に同じくセレクタから引っ張ってくる
DOM APIのqueryselectorAllでもテキストノードは取得できないはず
セレクタではなくXPathを使用すればテキストノードも引っ張ってこれるが、これはNodeListではない
将来テキストノードを取得するためのセレクタができる可能性はゼロではないと思うが
それはそれとして、図らずともjQueryはすでにテキストノードにも対応してる
( contents()メソッドの存在 )ってことが示せたと思う
わかってると思うがNodeListはNodeのコレクションなので、
理屈上はNode自身とそのサブクラスはコレクションに入れることができる
TextNodeはNodeのサブクラスなので入れることはできる
https://developer.mozilla.org/en-US/docs/Web/API/Text
>>543は全くタイプの異なる要素が入る可能性と言ってるがNodeでないものは入らない。
jQueryで言えば、contents()メソッドを使うと、jQueryオブジェクトにテキストノードが入る
サンプル
https://jsfiddle.net/32mwdfnc/
$("#id").contents().each(function() {
console.log(this.toString());
});
出力結果
[object Text]
[object HTMLSpanElement]
[object Text]
[object HTMLSpanElement]
俺の知る限りjQueryでテキストノードを取得する方法はこれだけだろう。
セレクタを使用している以上、セレクタから引っ張ってこれないものはメソッドを使って取得するしか無い
話はそれたが、NodeListにテキストノードが入る再現コードだが、同様に同じくセレクタから引っ張ってくる
DOM APIのqueryselectorAllでもテキストノードは取得できないはず
セレクタではなくXPathを使用すればテキストノードも引っ張ってこれるが、これはNodeListではない
将来テキストノードを取得するためのセレクタができる可能性はゼロではないと思うが
それはそれとして、図らずともjQueryはすでにテキストノードにも対応してる
( contents()メソッドの存在 )ってことが示せたと思う
552デフォルトの名無しさん
2018/11/14(水) 13:31:51.54ID:Da4Ohzbn ああそうか、NodeListを返すなら、queryselectorAll限定である必要はないな。
jQueryのcontents()メソッドに対応するDOM APIってことで調べたら、
childNodesがテキストノードも含まれるNodeListを返したよ
https://developer.mozilla.org/ja/docs/Web/API/Node/childNodes
jQueryのcontents()メソッドに対応するDOM APIってことで調べたら、
childNodesがテキストノードも含まれるNodeListを返したよ
https://developer.mozilla.org/ja/docs/Web/API/Node/childNodes
553デフォルトの名無しさん
2018/11/14(水) 16:03:13.17ID:DuV4GknS ローカルのjavascriptから公開されているAPIにアクセスできません
ググったらAPIを置いてる方で許可しろと出ましたが、公開している以上それはしてるはず?
他にブラウザのセキュリティを切るというのもありましたが、それはしたくありません
エラー内容(URLのhを抜いています)
クロスオリジン要求をブロックしました: 同一生成元ポリシーにより、ttps://ext.nicovideo.jp/api/getthumbinfo/sm500873 にあるリモートリソースの読み込みは拒否されます (理由: CORS ヘッダー ‘Access-Control-Allow-Origin’ が足りない)。
NetworkError: A network error occurred.
コード(htmlのボタンをクリックしたらgetJSON()。ググったのをコピーしてURLを変えただけ)
function getJSON(){
var req = new XMLHttpRequest();
req.onreadystatechange = function() {
if(req.readyState == 4 && req.status == 200){
alert(req.responseText);
}
};
// req.open("GET", "sm500873", false); // ローカルに保存したものはOK
req.open("GET", "ttps://ext.nicovideo.jp/api/getthumbinfo/sm500873", false); // ←エラー h抜き
req.send(null);
}
実際にアクセスしたいAPI
SOLD OUT 2 API ttps://so2-docs.mutoys.com/common/api.html
コードが間違っている
API側で許可されていない。普通は使う側がセキュリティを切る
その他
どれでしょう?
ググったらAPIを置いてる方で許可しろと出ましたが、公開している以上それはしてるはず?
他にブラウザのセキュリティを切るというのもありましたが、それはしたくありません
エラー内容(URLのhを抜いています)
クロスオリジン要求をブロックしました: 同一生成元ポリシーにより、ttps://ext.nicovideo.jp/api/getthumbinfo/sm500873 にあるリモートリソースの読み込みは拒否されます (理由: CORS ヘッダー ‘Access-Control-Allow-Origin’ が足りない)。
NetworkError: A network error occurred.
コード(htmlのボタンをクリックしたらgetJSON()。ググったのをコピーしてURLを変えただけ)
function getJSON(){
var req = new XMLHttpRequest();
req.onreadystatechange = function() {
if(req.readyState == 4 && req.status == 200){
alert(req.responseText);
}
};
// req.open("GET", "sm500873", false); // ローカルに保存したものはOK
req.open("GET", "ttps://ext.nicovideo.jp/api/getthumbinfo/sm500873", false); // ←エラー h抜き
req.send(null);
}
実際にアクセスしたいAPI
SOLD OUT 2 API ttps://so2-docs.mutoys.com/common/api.html
コードが間違っている
API側で許可されていない。普通は使う側がセキュリティを切る
その他
どれでしょう?
554デフォルトの名無しさん
2018/11/14(水) 16:25:09.78ID:CNd6PM4x555553
2018/11/14(水) 17:27:47.03ID:DuV4GknS >>554
レスありがとうございます
ニコ動のAPIのように公開されているものでも、CORSは許可していないということですか?
API公開≒CORS許可で、こちらに何か足りないと思ってました
保存したものなら大丈夫なので、保存だけ別の方法を探してみます
レスありがとうございます
ニコ動のAPIのように公開されているものでも、CORSは許可していないということですか?
API公開≒CORS許可で、こちらに何か足りないと思ってました
保存したものなら大丈夫なので、保存だけ別の方法を探してみます
556デフォルトの名無しさん
2018/11/14(水) 17:32:04.39ID:Da4Ohzbn ログインすりゃ使えるんじゃね?知らんけど
無制限に許可なんかしたら負荷かけられまくるんだから
誰がAPIを叩いたか知るためにもログイン必須はおかしくないでしょ?
無制限に許可なんかしたら負荷かけられまくるんだから
誰がAPIを叩いたか知るためにもログイン必須はおかしくないでしょ?
557デフォルトの名無しさん
2018/11/14(水) 17:47:55.65ID:1irFmXR9 基本的に外部サイトへのリクエストはセキュリティ上の理由で禁止されてるんだけど、それを許可するのがCORS
これは外部サイト(ここではAPI)側でしか設定できないから、迂回するにはCORSヘッダを付加するプロキシサーバーみたいなのを建てるしかない
GET限定で良ければ誰かが建てたそういうサーバーがある(CORS Anywhereとかcrossorigin.meとか)けど、利用する場合は自己責任で
(レスポンスが改ざんされたり、動いてなかったりするかもしれない)
これは外部サイト(ここではAPI)側でしか設定できないから、迂回するにはCORSヘッダを付加するプロキシサーバーみたいなのを建てるしかない
GET限定で良ければ誰かが建てたそういうサーバーがある(CORS Anywhereとかcrossorigin.meとか)けど、利用する場合は自己責任で
(レスポンスが改ざんされたり、動いてなかったりするかもしれない)
558デフォルトの名無しさん
2018/11/14(水) 19:32:52.05ID:XHaWO18a559デフォルトの名無しさん
2018/11/14(水) 20:52:38.60ID:tTVxQWlP >>544
問題あるかないかの話はしてないよ
そりゃ問題ないように作るということは幾らでもできるから
でもNodeListというクラスのメソッドとしては性質上「不自然」だって言ってるの
適当にコーディングするためのjQueryでは許されても標準では許されないよ
問題あるかないかの話はしてないよ
そりゃ問題ないように作るということは幾らでもできるから
でもNodeListというクラスのメソッドとしては性質上「不自然」だって言ってるの
適当にコーディングするためのjQueryでは許されても標準では許されないよ
560デフォルトの名無しさん
2018/11/14(水) 21:58:20.23ID:rJwbd1Hm jQueryが受けているのは「初心者にとって丁度いいから」というのもある。
PHPがそうだが、上級者から見ると「なんでこうした?」というのが多いが、
初心者にとってはそれくらいベタの方が使いやすい。
だからPHPも初心者受けは良い。同様に、jQueryも初心者受けは良い。ベタだからだ。
(フレームワークは初心者にとっては何をどう使えばいいかさっぱり分からない。
これがjQueryにはない、ということ。)
ただ、jQueryは低レベルすぎて、短く書けるだけで、やること/管理することが減るわけではないから、
上級者にとっては導入のメリットがない。
むしろ、依存関係が増え、記述が冗長になる(複数の書き方が混在する)という意味で悪だ。
だから、腕前を上げるに従い脱jQueryを目指すのも自然なことで、「自転車の補助輪だ」というのも当たってる。
タイピング量なんて全くどうでもいいし。
ただこれらは「上級者」に近くなってこないと理解出来ないし、
当然デザイナと話をしてても水掛け論にしかならず、話は堂々巡りだ。
ある意味、デザイナがプログラミングまで出張ってきているJavaScriptの世界が特殊なのだろう。
アプリを組めるレベルになってくるとjQueryの問題点は自明として、
それ以下だと認識出来ないから、意外にずっと使われるのかもね。ある意味PHPもそうだし。
あれは、「サイトの数」で比較するからjQueryのシェアが高く見えるんだろうな。
実際の「Web閲覧時間」での比較が出来れば一番良いのだけど、これは直接的には無理だから、
現実的には「サイト数をPVで加重平均」したものが妥当かな?
これだと実際に見られているシェアとなり、感覚的にも一致するはずだし。
>>544
> jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ
それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。
ま、NodeListについては、DOM自体がいまいちOOPに乗り切れてないことの問題ではあるが。
PHPがそうだが、上級者から見ると「なんでこうした?」というのが多いが、
初心者にとってはそれくらいベタの方が使いやすい。
だからPHPも初心者受けは良い。同様に、jQueryも初心者受けは良い。ベタだからだ。
(フレームワークは初心者にとっては何をどう使えばいいかさっぱり分からない。
これがjQueryにはない、ということ。)
ただ、jQueryは低レベルすぎて、短く書けるだけで、やること/管理することが減るわけではないから、
上級者にとっては導入のメリットがない。
むしろ、依存関係が増え、記述が冗長になる(複数の書き方が混在する)という意味で悪だ。
だから、腕前を上げるに従い脱jQueryを目指すのも自然なことで、「自転車の補助輪だ」というのも当たってる。
タイピング量なんて全くどうでもいいし。
ただこれらは「上級者」に近くなってこないと理解出来ないし、
当然デザイナと話をしてても水掛け論にしかならず、話は堂々巡りだ。
ある意味、デザイナがプログラミングまで出張ってきているJavaScriptの世界が特殊なのだろう。
アプリを組めるレベルになってくるとjQueryの問題点は自明として、
それ以下だと認識出来ないから、意外にずっと使われるのかもね。ある意味PHPもそうだし。
あれは、「サイトの数」で比較するからjQueryのシェアが高く見えるんだろうな。
実際の「Web閲覧時間」での比較が出来れば一番良いのだけど、これは直接的には無理だから、
現実的には「サイト数をPVで加重平均」したものが妥当かな?
これだと実際に見られているシェアとなり、感覚的にも一致するはずだし。
>>544
> jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ
それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。
ま、NodeListについては、DOM自体がいまいちOOPに乗り切れてないことの問題ではあるが。
561デフォルトの名無しさん
2018/11/14(水) 22:50:55.26ID:Da4Ohzbn > それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。
また、それがどこか答えない。
同じことの繰り返しだな。
通じない?当たり前だ
お前が何も言ってないんだから
また、それがどこか答えない。
同じことの繰り返しだな。
通じない?当たり前だ
お前が何も言ってないんだから
562デフォルトの名無しさん
2018/11/14(水) 23:02:21.85ID:rJwbd1Hm563デフォルトの名無しさん
2018/11/14(水) 23:08:02.36ID:Da4Ohzbn > いやモロに書いてるがな。
いつもどおり。リンクを示せば良いものを
書いていると書くだけでおしまい。
やり口がかわらんなぁw
いつもどおり。リンクを示せば良いものを
書いていると書くだけでおしまい。
やり口がかわらんなぁw
564デフォルトの名無しさん
2018/11/14(水) 23:09:10.35ID:Da4Ohzbn 訂正
× リンクを示せば良いものを
○ 引用するなどして、具体的な箇所を示せば良いものを
× リンクを示せば良いものを
○ 引用するなどして、具体的な箇所を示せば良いものを
565デフォルトの名無しさん
2018/11/14(水) 23:16:47.50ID:rJwbd1Hm >>563
お前もいつも通り連呼リアンだよな。
普通は562は「リンクを示した」と言うぜ。
お前、煽り抜きで頭おかしいと思うぜ。マジで池沼。
同様の奴が他に2人いると書いたが、お前が一番程度が酷い。
さすがにそれだとリアルの普通の会話も成立しないだろ。
お前もいつも通り連呼リアンだよな。
普通は562は「リンクを示した」と言うぜ。
お前、煽り抜きで頭おかしいと思うぜ。マジで池沼。
同様の奴が他に2人いると書いたが、お前が一番程度が酷い。
さすがにそれだとリアルの普通の会話も成立しないだろ。
566デフォルトの名無しさん
2018/11/14(水) 23:22:14.41ID:rJwbd1Hm >>564
英語読めるつもりなんだろ?自分で読めよ。
というか、あれ、脱jQueryが気になる奴は、読む価値はあると思うぜ。
お前は読んでも全部読むうちに忘れちゃうんだろうけどさ。
それでもお前の頭は交換不可能で、お前自身で鍛えるしかないんだから、
無い頭使って一生懸命読めよ。
それを繰り返してたら、お前のその頭も少しはましになるよ。
英語読めるつもりなんだろ?自分で読めよ。
というか、あれ、脱jQueryが気になる奴は、読む価値はあると思うぜ。
お前は読んでも全部読むうちに忘れちゃうんだろうけどさ。
それでもお前の頭は交換不可能で、お前自身で鍛えるしかないんだから、
無い頭使って一生懸命読めよ。
それを繰り返してたら、お前のその頭も少しはましになるよ。
567デフォルトの名無しさん
2018/11/14(水) 23:27:59.81ID:rJwbd1Hm なお、GitHubの公式声明の内容は割と普通のことなので、
普通に脱jQueryを実行出来る人は特に読む意味はありません。
何故脱jQueryなのか?に疑問を持つ人は、読む価値があると思います。
普通に脱jQueryを実行出来る人は特に読む意味はありません。
何故脱jQueryなのか?に疑問を持つ人は、読む価値があると思います。
568デフォルトの名無しさん
2018/11/14(水) 23:32:34.35ID:Da4Ohzbn だから、GitHubの声明には本来書いてあるはずのjQueryをなくして
その結果、何が得られたかが「書いてない」ってのが、注目する点なんだってばw
その結果、何が得られたかが「書いてない」ってのが、注目する点なんだってばw
569デフォルトの名無しさん
2018/11/14(水) 23:49:27.00ID:rJwbd1Hm570デフォルトの名無しさん
2018/11/15(木) 00:17:06.64ID:gWaB1LhD はい、想定通りのレスきました
571デフォルトの名無しさん
2018/11/15(木) 00:22:47.33ID:labK41wt572デフォルトの名無しさん
2018/11/15(木) 00:29:18.03ID:labK41wt573デフォルトの名無しさん
2018/11/15(木) 00:47:30.01ID:O4sg2hqu いつものインタビュー貼っておきますね
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
574デフォルトの名無しさん
2018/11/15(木) 00:58:36.39ID:g74yzjtM >>553-557
自分のPC にサーバーを立てて、サーバー経由でアクセスしないと、
ブラウザからでは、CORS でアクセスできない
例えば、自分のPC 内のHTML ファイルを、ブラウザで起動して、
そのページから、5ch へアクセスできない。
iframe 内に読み込んでも、iframe 内外が、別ドメインだからアクセスできない
ruby -run -e httpd . -p 8080
1-liner で、Web サーバーを起動して、そのindex.html からは、別ドメインにもアクセスできる
自分のPC にサーバーを立てて、サーバー経由でアクセスしないと、
ブラウザからでは、CORS でアクセスできない
例えば、自分のPC 内のHTML ファイルを、ブラウザで起動して、
そのページから、5ch へアクセスできない。
iframe 内に読み込んでも、iframe 内外が、別ドメインだからアクセスできない
ruby -run -e httpd . -p 8080
1-liner で、Web サーバーを起動して、そのindex.html からは、別ドメインにもアクセスできる
575デフォルトの名無しさん
2018/11/15(木) 01:02:00.51ID:gWaB1LhD576デフォルトの名無しさん
2018/11/15(木) 01:03:57.60ID:gWaB1LhD >>574
オリジンが違うんだから出来ねーよ
オリジンが違うんだから出来ねーよ
577デフォルトの名無しさん
2018/11/15(木) 15:35:01.66ID:kH0mg7oG オリジンが違ってもアクセスはできるだろ
取得した中身が読み取れないだけ
取得した中身が読み取れないだけ
578デフォルトの名無しさん
2018/11/15(木) 17:42:32.99ID:bhNItiA3 アクセス拒否されるし取得できない。
何いってんだコイツ
何いってんだコイツ
579デフォルトの名無しさん
2018/11/15(木) 20:16:01.66ID:gy9NL/ik 何いってんだコイツはお前だアホ
await fetch('https://developer.mozilla.org/',{mode:'no-cors'})
アクセスしてるだろうが
もし拒否されるのならServiceWorker導入ページでどうやって
外部リソースをリクエストしたりキャッシュしたりするつもりなんだ?
人様にケチ付ける前に自分が無知であることを知れよ
await fetch('https://developer.mozilla.org/',{mode:'no-cors'})
アクセスしてるだろうが
もし拒否されるのならServiceWorker導入ページでどうやって
外部リソースをリクエストしたりキャッシュしたりするつもりなんだ?
人様にケチ付ける前に自分が無知であることを知れよ
580デフォルトの名無しさん
2018/11/15(木) 21:17:25.79ID:lEvW1moB 元々の文脈考えたらアクセスできない、で良くね?
オリジン違えば非同期通信でAPIのレスポンスは取ってこれない
jsonp対応してれば行けるだろうがそれはまた別の話だ
オリジン違えば非同期通信でAPIのレスポンスは取ってこれない
jsonp対応してれば行けるだろうがそれはまた別の話だ
581デフォルトの名無しさん
2018/11/16(金) 01:36:26.11ID:RoXRfHM0582デフォルトの名無しさん
2018/11/16(金) 03:07:01.97ID:J23WDvJz > 人様にケチ付ける前に自分が無知であることを知れよ
で自分を人様って言ってるのも色々アレ
で自分を人様って言ってるのも色々アレ
583デフォルトの名無しさん
2018/11/16(金) 03:15:01.26ID:RoXRfHM0 まあそれは煽りでよく見る
584デフォルトの名無しさん
2018/11/16(金) 05:29:59.60ID:Fm6aQCaV585デフォルトの名無しさん
2018/11/18(日) 22:16:13.60ID:0UFE24fl JAVAscriptと書くのは普通ですか?
ネットで見たのですが
ネットで見たのですが
586デフォルトの名無しさん
2018/11/18(日) 23:02:17.55ID:nb8ry1fv 好きに書けばいいんです
587デフォルトの名無しさん
2018/11/19(月) 08:23:17.32ID:xSgeYMFO JaVa$cRiPt
588デフォルトの名無しさん
2018/11/29(木) 23:02:47.57ID:vNMQ8ba8 勉強にのためにライブラリのjplayerを解読しようとしてるが
難しすぎる。
おまえら、javascript勉強してるってこは
ライブリとかもすらすら読んでわかるの?
難しすぎる。
おまえら、javascript勉強してるってこは
ライブリとかもすらすら読んでわかるの?
589デフォルトの名無しさん
2018/11/29(木) 23:33:09.60ID:fezToc6/ >>588
前提でJQueryとかの知識がいるからじゃない?
こういうやつとか初心者が試行錯誤でやったやつの方がわけわからん
https://qiita.com/ryuichi1208/items/f9e6ac2b99bbe4fc82d3
前提でJQueryとかの知識がいるからじゃない?
こういうやつとか初心者が試行錯誤でやったやつの方がわけわからん
https://qiita.com/ryuichi1208/items/f9e6ac2b99bbe4fc82d3
590デフォルトの名無しさん
2018/11/29(木) 23:41:56.52ID:lCOis1qI jQuery使わなかったらもっと難解になるんだよな
591デフォルトの名無しさん
2018/11/30(金) 00:00:53.52ID:2ubbGZPs >>588
覚えればすむものは楽なんだよ。
単に覚えればいいだけ理解すればそれで終わりなんだから。
大変なのは>>589みたいなもの。ありえないほど短いコードで
実現しているから凄いといわれるけど一般的にはクソコードと言われる類。
なぜかというと、コードというのは簡単に読めるものじゃないといけない
もちろん知識をつけたもの、能力がある人にとってね。
知識があって能力がある人でも読むのに時間がかかるような
無駄な処理ばかりで何をやってるか分からないようなものは大変
それが「解読」という作業。これはコードに問題がある。
知識がなくてわからないのは解読じゃなくて単に読めないだけ
読んでる人に問題がある
覚えればすむものは楽なんだよ。
単に覚えればいいだけ理解すればそれで終わりなんだから。
大変なのは>>589みたいなもの。ありえないほど短いコードで
実現しているから凄いといわれるけど一般的にはクソコードと言われる類。
なぜかというと、コードというのは簡単に読めるものじゃないといけない
もちろん知識をつけたもの、能力がある人にとってね。
知識があって能力がある人でも読むのに時間がかかるような
無駄な処理ばかりで何をやってるか分からないようなものは大変
それが「解読」という作業。これはコードに問題がある。
知識がなくてわからないのは解読じゃなくて単に読めないだけ
読んでる人に問題がある
592デフォルトの名無しさん
2018/11/30(金) 08:44:57.62ID:VjmtC3o0 7行テトリスは、まるで暗号
jQuery のCSS セレクターを学べば?
基本的には、# . > など、Emmet と同じ
Ruby のNokogiri でもよい
jQuery のCSS セレクターを学べば?
基本的には、# . > など、Emmet と同じ
Ruby のNokogiri でもよい
593デフォルトの名無しさん
2018/12/02(日) 13:56:14.24ID:LBfjyA1g やっぱ、オレの勉強不足だな。
もっとjavascript勉強しよ。
日経ソフトウェア読んでると、javascriptに
Reactという仮想DOMとか出てきてるし
どんどん新しい技術出てきてる
もっとjavascript勉強しよ。
日経ソフトウェア読んでると、javascriptに
Reactという仮想DOMとか出てきてるし
どんどん新しい技術出てきてる
594デフォルトの名無しさん
2018/12/02(日) 16:53:20.50ID:2mHq7Ydm 仮想DOMは、なんでDOMを全部再構築するというアイデアが
出発点になってるのかわからない。
jQueryがやってるように普通に必要なところだけDOMを更新すればいいだろう
出発点になってるのかわからない。
jQueryがやってるように普通に必要なところだけDOMを更新すればいいだろう
595デフォルトの名無しさん
2018/12/02(日) 16:55:13.96ID:d6QByty/ なるだけ参照透明にしたいからじゃない?
596デフォルトの名無しさん
2018/12/02(日) 17:19:20.90ID:3j0ioh6B 部分更新も、複数回のDOM操作がinnerHTML差し替え1回で済ませられたらメリットはあるんじゃね。
597デフォルトの名無しさん
2018/12/02(日) 17:22:34.32ID:Bx+z5yQP598デフォルトの名無しさん
2018/12/02(日) 17:53:11.92ID:9iYB1akb 複雑になってくると毎回全部再構築した方が楽だと思うけど
昔はDOMが遅くて実現が難しいとかじゃなかったっけ
昔はDOMが遅くて実現が難しいとかじゃなかったっけ
599デフォルトの名無しさん
2018/12/02(日) 17:59:05.26ID:Bx+z5yQP >>598
jQuery死ね
jQuery死ね
600デフォルトの名無しさん
2018/12/02(日) 20:39:03.60ID:uIlAasYL 推薦書
Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発、
花谷 拓磨、2018/10/17
基礎から学ぶ Vue.js、mio、2018/5/29
Node.js超入門、掌田津耶乃、2017
Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう
野口 将人・倉見 洋輔、2017
入門 React ――コンポーネントベースのWebフロントエンド開発、2015
Reactビギナーズガイド ――コンポーネントベースのフロントエンド開発入門
Stoyan Stefanov, 2017
https://github.com/stoyan/reactbook
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017
Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発、
花谷 拓磨、2018/10/17
基礎から学ぶ Vue.js、mio、2018/5/29
Node.js超入門、掌田津耶乃、2017
Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう
野口 将人・倉見 洋輔、2017
入門 React ――コンポーネントベースのWebフロントエンド開発、2015
Reactビギナーズガイド ――コンポーネントベースのフロントエンド開発入門
Stoyan Stefanov, 2017
https://github.com/stoyan/reactbook
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017
601デフォルトの名無しさん
2018/12/02(日) 20:50:24.13ID:qYaSLKlW VueはVue.js入門が出たから猫の方はいらんよ
602デフォルトの名無しさん
2018/12/03(月) 08:37:17.60ID:qqs2cxrp >>598
> 複雑になってくると毎回全部再構築した方が楽だと思うけど
> 昔はDOMが遅くて実現が難しいとかじゃなかったっけ
つまりマッチポンプってこと?
1. jQueryなどを使って必要な部分だけ構築する・・・一番速い
2. (アホな)アイデア思いついた!全部再構築したほうがいいんじゃね?・・・遅い
3. VirtualDOM使えば(jQueryほど速くないけど)全部再構築しても遅くならない!
VirtualDOMって遅くならないだけなんだよね
決してjQueryよりは速くはならない
> 複雑になってくると毎回全部再構築した方が楽だと思うけど
> 昔はDOMが遅くて実現が難しいとかじゃなかったっけ
つまりマッチポンプってこと?
1. jQueryなどを使って必要な部分だけ構築する・・・一番速い
2. (アホな)アイデア思いついた!全部再構築したほうがいいんじゃね?・・・遅い
3. VirtualDOM使えば(jQueryほど速くないけど)全部再構築しても遅くならない!
VirtualDOMって遅くならないだけなんだよね
決してjQueryよりは速くはならない
603デフォルトの名無しさん
2018/12/03(月) 08:40:10.65ID:qqs2cxrp >>594
そもそも遅延描画する必要がないですよね
仮想DOM使っても結局変更部分はDOM操作をするんだから
仮想DOMを使わずに、変更部分をDOM操作すればもっと速いですよね
なんで仮想DOMは速いって嘘をつくんだろう?
遅くならないって言えばいいのに
そもそも遅延描画する必要がないですよね
仮想DOM使っても結局変更部分はDOM操作をするんだから
仮想DOMを使わずに、変更部分をDOM操作すればもっと速いですよね
なんで仮想DOMは速いって嘘をつくんだろう?
遅くならないって言えばいいのに
604デフォルトの名無しさん
2018/12/03(月) 08:55:08.53ID:oKREYEfs そもそも、仮想DOMの方が常にjQueryより速いと主張する奴がいるという思い込みじゃね?
605デフォルトの名無しさん
2018/12/03(月) 09:07:38.44ID:qqs2cxrp 例えば>>597にも書いてますね。
> VirtualDOMの仕事ってなに?(Reactの表示速度がはやい理由)
「Reactの表示速度が遅くならない理由」と書けばいいのに
もともとDOM全部再構築なんて遅くなるような馬鹿げたことはやってないんですよ
逆にどうやってjQueryでDOM全部再構築をやれと?
めんどくさくてやってられないし遅いのでやらない
遅くなるDOM全再構築なんて馬鹿げたことをやって
遅いだろう?でもこれだと遅くないんだぜってっていうのが
マッチポンプなんですよ
> VirtualDOMの仕事ってなに?(Reactの表示速度がはやい理由)
「Reactの表示速度が遅くならない理由」と書けばいいのに
もともとDOM全部再構築なんて遅くなるような馬鹿げたことはやってないんですよ
逆にどうやってjQueryでDOM全部再構築をやれと?
めんどくさくてやってられないし遅いのでやらない
遅くなるDOM全再構築なんて馬鹿げたことをやって
遅いだろう?でもこれだと遅くないんだぜってっていうのが
マッチポンプなんですよ
606デフォルトの名無しさん
2018/12/03(月) 09:08:21.84ID:+OGeTNm4 まぁ藁人形論法だね。
その他によく知らない初心者が勘違いしたまま質の悪いウソ情報をネットに垂れ流してるというのもある。
その他によく知らない初心者が勘違いしたまま質の悪いウソ情報をネットに垂れ流してるというのもある。
607デフォルトの名無しさん
2018/12/03(月) 09:11:08.96ID:+OGeTNm4 >>597は典型的な勘違いして垂れ流してる初心者だなw
こんなのよりReact登場初期の、初心者が知ったかでイキってられない時期に書かれた記事読んだ方がいい。
こんなのよりReact登場初期の、初心者が知ったかでイキってられない時期に書かれた記事読んだ方がいい。
608デフォルトの名無しさん
2018/12/03(月) 09:19:09.58ID:qqs2cxrp 「今までは、基本的に受け取った情報を元にDOMを
一から作成してブラウザに描画することが多かった」
こんなことやってませんからね
サーバーを介さないクライアントだけで処理できるもの、
例えばボタンがクリックされた時に何かを行う処理は
必要最小限のDOMしか変更しないんので速い
「受け取った情報を元に」と書いてあるからAjax前提の話か
ページ遷移の時の話だろうけど、ページ全体を読み込むよりかは
一部分のほうが早いのは当然として、それはAjaxを使えばいい。
Ajaxを使って、必要最小限のところだけ書き換えるのが普通
DOMを一から作成してブラウザに描画とかしないから
一から作成してブラウザに描画することが多かった」
こんなことやってませんからね
サーバーを介さないクライアントだけで処理できるもの、
例えばボタンがクリックされた時に何かを行う処理は
必要最小限のDOMしか変更しないんので速い
「受け取った情報を元に」と書いてあるからAjax前提の話か
ページ遷移の時の話だろうけど、ページ全体を読み込むよりかは
一部分のほうが早いのは当然として、それはAjaxを使えばいい。
Ajaxを使って、必要最小限のところだけ書き換えるのが普通
DOMを一から作成してブラウザに描画とかしないから
609デフォルトの名無しさん
2018/12/03(月) 12:37:01.63ID:xsY8Ca3Y SPAだと自前でページ遷移作ることになるやろ
610デフォルトの名無しさん
2018/12/03(月) 15:23:56.50ID:y4vgdg4E SPAにページ遷移という概念が存在するとは限らない
SPAはアプリケーションなのだから
ただ単純に実際のページ遷移を伴わない技術はpjaxと言ったほうが良い
SPAはアプリケーションなのだから
ただ単純に実際のページ遷移を伴わない技術はpjaxと言ったほうが良い
611デフォルトの名無しさん
2018/12/03(月) 21:51:55.26ID:r8O+Z3hZ あれ?いつもの奴ではないjQuery廚が沸いている?
が、まあいい。
そもそも素人向けの解説は当然色々端折るので厳密にはそれなりに間違いを含む。
これは至極当然だ。それに対して発狂しても意味がない。
それらは、「このレベル向けの解説ならこの程度で妥当か?」で判定されるべきだ。
この点、俺は597はまあまあだと思うが。
そもそも詳しく分かるんなら、もっと詳しい解説をググればいいだけだ。以下とか。
http://steps.dodgson.org/b/2014/12/11/why-is-real-dom-slow/
https://postd.cc/the-inner-workings-of-virtual-dom/
jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
だったらフレームワークにしちゃおうぜ、という話であってさ。
俺はReactが実際どこまで端折っているのかは知らんが、(使ってないし、使う予定もない)
上記2つの記事が正しければ、限界まで端折っている。
> React は処理を省いたコンポーネントの render() を呼びださない。 (1つ目のリンク)
> フローチャート内、renderはど頭の処理 (2つ目のリンク)
仮に現状では限界まで端折れていないとしても、
Reactのアップデート共に改善されて最終的には限界まで端折ることになる。
この辺の、改善を外部のアップデートに期待出来ることも、フレームワーク等を導入するメリットでもあるだろ。
が、まあいい。
そもそも素人向けの解説は当然色々端折るので厳密にはそれなりに間違いを含む。
これは至極当然だ。それに対して発狂しても意味がない。
それらは、「このレベル向けの解説ならこの程度で妥当か?」で判定されるべきだ。
この点、俺は597はまあまあだと思うが。
そもそも詳しく分かるんなら、もっと詳しい解説をググればいいだけだ。以下とか。
http://steps.dodgson.org/b/2014/12/11/why-is-real-dom-slow/
https://postd.cc/the-inner-workings-of-virtual-dom/
jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
だったらフレームワークにしちゃおうぜ、という話であってさ。
俺はReactが実際どこまで端折っているのかは知らんが、(使ってないし、使う予定もない)
上記2つの記事が正しければ、限界まで端折っている。
> React は処理を省いたコンポーネントの render() を呼びださない。 (1つ目のリンク)
> フローチャート内、renderはど頭の処理 (2つ目のリンク)
仮に現状では限界まで端折れていないとしても、
Reactのアップデート共に改善されて最終的には限界まで端折ることになる。
この辺の、改善を外部のアップデートに期待出来ることも、フレームワーク等を導入するメリットでもあるだろ。
612デフォルトの名無しさん
2018/12/03(月) 21:52:51.04ID:r8O+Z3hZ その記事内にもあるが、
> ウェブ開発者が文句をいう DOM の遅さは大半がレンダリング由来だったりする。
これは全くその通りで、レンダリングさえしなければDOMは遅くない。
(jQuery廚が居るから一応言っておくが、クエリもそれなりに遅い。
ただ、Reactとか使う人はクエリはほぼ全くしないはず。というかこの構成だと禁止かも?)
つまり、document.create等は十分速く(=仮想DOM構築も速い)、レンダリングだけが遅いから、
どうにかしてレンダリングを止めさせよう(少なくしよう)というのが遅延描画だ。
それが必要かどうかは場合による。
描画しなくて済む範囲が多ければ、当然ぶっちぎりで速い。
jQueryは生JavaScriptよりも本質的に遅いから、遅延描画が効くようなら、
生JavaScriptで遅延描画>フレームワークで遅延描画>>>生JavaScriptで描画>jQueryで描画
となる。
ただし遅延描画の肝心要のoffsetTop等がこれまた致命的に遅いので、(レンダリングを要する為)
単純に遅延描画にすれば(体感的に)速くなる訳でもない。
jQueryを使ってて許されてるのなら、そのサイトはスピード狂ではないので、
遅延描画を要求されることもないのではないかな?
ただそもそも、遅延描画が効くサイト構成の所も少ないかも。
例えばアマゾン、商品一覧はいちいち「次のページ」を押して遷移するようになっている。
SPAでページ毎に商品表示部分を全面描画してる。
(ページ全体の全面描画ではなく、商品部分の全面描画。念のため)
ページ内商品点数は36なので、この程度では遅延描画はあまり効果がない。
(というか下手にやると余計に遅くなる。少なくともPC環境ではそう。モバイルだと違うかも)
俺はこういうのは無限スクロールでぐりぐりやってればいくらでも見える方が好きなのだけど、
そういうサイトは確かに少ない。
(とりあえず150点くらい表示出来るオプション付けてくれ、と思うが、そういうところもない)
> ウェブ開発者が文句をいう DOM の遅さは大半がレンダリング由来だったりする。
これは全くその通りで、レンダリングさえしなければDOMは遅くない。
(jQuery廚が居るから一応言っておくが、クエリもそれなりに遅い。
ただ、Reactとか使う人はクエリはほぼ全くしないはず。というかこの構成だと禁止かも?)
つまり、document.create等は十分速く(=仮想DOM構築も速い)、レンダリングだけが遅いから、
どうにかしてレンダリングを止めさせよう(少なくしよう)というのが遅延描画だ。
それが必要かどうかは場合による。
描画しなくて済む範囲が多ければ、当然ぶっちぎりで速い。
jQueryは生JavaScriptよりも本質的に遅いから、遅延描画が効くようなら、
生JavaScriptで遅延描画>フレームワークで遅延描画>>>生JavaScriptで描画>jQueryで描画
となる。
ただし遅延描画の肝心要のoffsetTop等がこれまた致命的に遅いので、(レンダリングを要する為)
単純に遅延描画にすれば(体感的に)速くなる訳でもない。
jQueryを使ってて許されてるのなら、そのサイトはスピード狂ではないので、
遅延描画を要求されることもないのではないかな?
ただそもそも、遅延描画が効くサイト構成の所も少ないかも。
例えばアマゾン、商品一覧はいちいち「次のページ」を押して遷移するようになっている。
SPAでページ毎に商品表示部分を全面描画してる。
(ページ全体の全面描画ではなく、商品部分の全面描画。念のため)
ページ内商品点数は36なので、この程度では遅延描画はあまり効果がない。
(というか下手にやると余計に遅くなる。少なくともPC環境ではそう。モバイルだと違うかも)
俺はこういうのは無限スクロールでぐりぐりやってればいくらでも見える方が好きなのだけど、
そういうサイトは確かに少ない。
(とりあえず150点くらい表示出来るオプション付けてくれ、と思うが、そういうところもない)
613デフォルトの名無しさん
2018/12/03(月) 21:54:09.89ID:r8O+Z3hZ 2つ目の記事ではサーチのサジェストが例に挙げられている。
この場合、エレメントが選択的に削除されるので、確かにVirtualDOMの出番ではある。
jQueryでよくやるように、宣言的に記述する場合、
サーチサジェスト部分,innerHTML= となるが、生DOMでは全面書き換えとなる。
VirtualDOMなら同じ記述でも自動的に選択的に描画してくれる為、(一般的には)速くなる。
なお、やれば分かるが、この場合の選択的描画を自前でやると結構ウザイコードになる。
自動でやってくれるのならその方が断然楽だ。
とはいえ、俺はVirtualDOMは流行らないと思う。理由は、
・そもそも遅延/選択的描画が効く構成の所が少ない
・遅延/選択的描画するにしても再描画区画は確定的であり、フレームワークを導入するまでもない
・APIが超絶イマイチ
仮想DOMなんてユーザーに意識させてる時点でアウト。
あれはcssプロパティ draw:lazy ならブラウザが自動的に対処してくれる、程度でなきゃ駄目なのさ。
実験としては面白いと思うし、今のJavaScriptで動かすなら今の実装で致し方ないが。
しかしまあそれを言ったら、jQueryが流行った理由は
・時代がそれを必要としていた
・馬鹿には丁度いい頃合いだった
であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
発狂するくらいならフレームワークとか見た方がいいと思うぜ。
使う必要はないが、何故そんなフレームワークが出てきたのか、には意味があるから。
この場合、エレメントが選択的に削除されるので、確かにVirtualDOMの出番ではある。
jQueryでよくやるように、宣言的に記述する場合、
サーチサジェスト部分,innerHTML= となるが、生DOMでは全面書き換えとなる。
VirtualDOMなら同じ記述でも自動的に選択的に描画してくれる為、(一般的には)速くなる。
なお、やれば分かるが、この場合の選択的描画を自前でやると結構ウザイコードになる。
自動でやってくれるのならその方が断然楽だ。
とはいえ、俺はVirtualDOMは流行らないと思う。理由は、
・そもそも遅延/選択的描画が効く構成の所が少ない
・遅延/選択的描画するにしても再描画区画は確定的であり、フレームワークを導入するまでもない
・APIが超絶イマイチ
仮想DOMなんてユーザーに意識させてる時点でアウト。
あれはcssプロパティ draw:lazy ならブラウザが自動的に対処してくれる、程度でなきゃ駄目なのさ。
実験としては面白いと思うし、今のJavaScriptで動かすなら今の実装で致し方ないが。
しかしまあそれを言ったら、jQueryが流行った理由は
・時代がそれを必要としていた
・馬鹿には丁度いい頃合いだった
であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
発狂するくらいならフレームワークとか見た方がいいと思うぜ。
使う必要はないが、何故そんなフレームワークが出てきたのか、には意味があるから。
614デフォルトの名無しさん
2018/12/04(火) 00:09:05.94ID:bTQB60BC > であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
そんなデータどこにもないですよね?
そんなデータどこにもないですよね?
615デフォルトの名無しさん
2018/12/04(火) 00:10:53.45ID:bTQB60BC >>611
> jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
> やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
なんで遅延描画をしなければならないって
危機的状況に陥ってるの?w
まずそんなものは不要ですって認めるところから始めようか
> jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
> やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
なんで遅延描画をしなければならないって
危機的状況に陥ってるの?w
まずそんなものは不要ですって認めるところから始めようか
616デフォルトの名無しさん
2018/12/04(火) 01:15:34.56ID:V/vZILhe 君が現実に目を瞑るのは自由だが、
jQueryは本質的に「絶対に速度面では勝てないプラットフォーム」だから、
まともな奴なら確実に移行する。それがいつか、の問題でしかない。
ただ書いたとおり、遅延/選択的描画はブラウザにやらせるべき物で、
自前でやっても下手にやると余計に遅くなるのも事実。
React等はおそらく実験的プラットフォームで、そこから標準化しようという算段だろうが、これはまだかなり遠い。
とはいえ、遅延/選択的描画は正しく使えばぶっちぎりで速くなるから、
ブラウザが勝手にやってくれるのなら使わない奴は居ないと思う。
勿論その時はjQueryを使っていても恩恵があるし、仮想DOMを使っている自覚も無いはずだが。
結果、仮想DOM自体がjQueryキラーになることはない。この辺が>>604の指摘だよ。
宣言スタイルで記述すると、選択的描画は出来ず、基本的に「ここから下は全部再構築」になる。当然遅い。
仮想DOMはこのときにも速度が低下しない、って話さ。
ただしこれは「生JSで遅延/選択的描画を自前で実装した場合」比だから、
jQueryを使った場合は(当然全構築するから)ぶっちぎりで遅い。
つまり、React等は最初からjQueryなんて比較相手にしてない。
勿論jQueyで遅延/選択的描画を自前で実装することも出来るけど、そんな奴は普通居ない。
この場合は自前で描画関連の全DOMへの参照を保持しており、queryの必要がないから。
そして内部状態管理バリバリのステートフルなコードになり、
jQueryを使わないと何も出来ないような奴らではどうにもならない。
実際、君は2つ目の例(サーチサジェスト)とか、全DOM再構築コードを書くだろ。
jQueryの利点はデタラメなHTMLでもなんとでもなることだが、これ自体が減りつつある。
というか、デタラメなHTMLになるのは手で先にHTMLを書くからで、
DBからHTMLを生成する場合、デタラメなHTMLを生成する方が面倒だから。
つまり、鯖がhtmlを直接配信しているのならjQueryがフィットするが、
鯖でPHP等でhtmlを生成するのなら、本来はjQueryなんて要らないhtmlを普通に吐ける。
(実際そうかは別として)
いずれにしても、jQueryロック状態はあまりよろしくはないと思うぜ。それもまた自由だが。
jQueryは本質的に「絶対に速度面では勝てないプラットフォーム」だから、
まともな奴なら確実に移行する。それがいつか、の問題でしかない。
ただ書いたとおり、遅延/選択的描画はブラウザにやらせるべき物で、
自前でやっても下手にやると余計に遅くなるのも事実。
React等はおそらく実験的プラットフォームで、そこから標準化しようという算段だろうが、これはまだかなり遠い。
とはいえ、遅延/選択的描画は正しく使えばぶっちぎりで速くなるから、
ブラウザが勝手にやってくれるのなら使わない奴は居ないと思う。
勿論その時はjQueryを使っていても恩恵があるし、仮想DOMを使っている自覚も無いはずだが。
結果、仮想DOM自体がjQueryキラーになることはない。この辺が>>604の指摘だよ。
宣言スタイルで記述すると、選択的描画は出来ず、基本的に「ここから下は全部再構築」になる。当然遅い。
仮想DOMはこのときにも速度が低下しない、って話さ。
ただしこれは「生JSで遅延/選択的描画を自前で実装した場合」比だから、
jQueryを使った場合は(当然全構築するから)ぶっちぎりで遅い。
つまり、React等は最初からjQueryなんて比較相手にしてない。
勿論jQueyで遅延/選択的描画を自前で実装することも出来るけど、そんな奴は普通居ない。
この場合は自前で描画関連の全DOMへの参照を保持しており、queryの必要がないから。
そして内部状態管理バリバリのステートフルなコードになり、
jQueryを使わないと何も出来ないような奴らではどうにもならない。
実際、君は2つ目の例(サーチサジェスト)とか、全DOM再構築コードを書くだろ。
jQueryの利点はデタラメなHTMLでもなんとでもなることだが、これ自体が減りつつある。
というか、デタラメなHTMLになるのは手で先にHTMLを書くからで、
DBからHTMLを生成する場合、デタラメなHTMLを生成する方が面倒だから。
つまり、鯖がhtmlを直接配信しているのならjQueryがフィットするが、
鯖でPHP等でhtmlを生成するのなら、本来はjQueryなんて要らないhtmlを普通に吐ける。
(実際そうかは別として)
いずれにしても、jQueryロック状態はあまりよろしくはないと思うぜ。それもまた自由だが。
617デフォルトの名無しさん
2018/12/04(火) 04:16:52.76ID:tEZcZBkn いちいち長すぎだろ…要点まとめるぐらいできないのか
618デフォルトの名無しさん
2018/12/04(火) 06:15:12.11ID:Jf/aCYja >>616
お前うざいよ
お前うざいよ
619デフォルトの名無しさん
2018/12/04(火) 06:51:59.52ID:xAx9wf3n ブラウザにやらせるべきって言ってもブラウザ側にも限界があるし
PauseFrameとかその時その時のベストプラクティスを徹底するのも難しい
その辺りをケアしてくれるのがフレームワークのメリットなのだから
PauseFrameとかその時その時のベストプラクティスを徹底するのも難しい
その辺りをケアしてくれるのがフレームワークのメリットなのだから
620デフォルトの名無しさん
2018/12/04(火) 08:59:31.22ID:V/vZILhe >>619
現状のフレームワーク等はいい実験をしているとは思う。
ただ、描画に関してはブラウザの方が主管なので、本来は丸投げ出来るべきだ。
現行のAPIを組み合わせてもこれは無理だから現状は致し方ないとしても。
> PauseFrame
使いどころは、
A. ajaxで将来的に書き換えると分かっているframeを停止する
B. 画面外のframeを停止する
として、AはJS側でいいが、Bはブラウザが勝手にやるべきだ。
根本的な問題は、CSSが全く拡張不能なこと。CSSで
・pause: auto ならオフスクリーンの場合はpause『してもよい』
という拡張が出来れば、これが一番自然だ。仮想DOMについては、
・draw: lazy でオフスクリーンなら描画『しなくてもいい』
となる。ここら辺まで出来れば、
フレームワーク導入コストはほぼ0となり、もっと面白くなるのだけどね。
現状のフレームワーク等はいい実験をしているとは思う。
ただ、描画に関してはブラウザの方が主管なので、本来は丸投げ出来るべきだ。
現行のAPIを組み合わせてもこれは無理だから現状は致し方ないとしても。
> PauseFrame
使いどころは、
A. ajaxで将来的に書き換えると分かっているframeを停止する
B. 画面外のframeを停止する
として、AはJS側でいいが、Bはブラウザが勝手にやるべきだ。
根本的な問題は、CSSが全く拡張不能なこと。CSSで
・pause: auto ならオフスクリーンの場合はpause『してもよい』
という拡張が出来れば、これが一番自然だ。仮想DOMについては、
・draw: lazy でオフスクリーンなら描画『しなくてもいい』
となる。ここら辺まで出来れば、
フレームワーク導入コストはほぼ0となり、もっと面白くなるのだけどね。
621デフォルトの名無しさん
2018/12/04(火) 13:03:13.41ID:2JUdQ9PA >>620 俺の考えとしては
ブラウザは勿論最大限努力すべきだけど、プログラマがどんな書き方をしていても理論上最善に近いパフォーマンスをしてくれというのは明らかに無理があるし、
一方ある程度はブラウザ側がパフォーマンスのための機構を提示して、プログラマ側の努力を求める事も仕方ないと思う
また別の話として、CSSも数年前からJITが入ったり、ブラウザがよしなにやってくれる感は確かに高まっているけど、それと同時にHoudiniだったり従来よりローレベルな環境が提示されるようになってきておりプログラマの責任も高まってる
ブラウザは勿論最大限努力すべきだけど、プログラマがどんな書き方をしていても理論上最善に近いパフォーマンスをしてくれというのは明らかに無理があるし、
一方ある程度はブラウザ側がパフォーマンスのための機構を提示して、プログラマ側の努力を求める事も仕方ないと思う
また別の話として、CSSも数年前からJITが入ったり、ブラウザがよしなにやってくれる感は確かに高まっているけど、それと同時にHoudiniだったり従来よりローレベルな環境が提示されるようになってきておりプログラマの責任も高まってる
622デフォルトの名無しさん
2018/12/04(火) 17:16:44.38ID:bTQB60BC で、結局のところ、重要なのはJavaScriptでいろいろ解決しましょうじゃなくて
根本的な設計を改善するほうがいい。
つまり静的なページで作れば問題は解決すると言うこと
JavaScriptを使って動きをつけなきゃいけないことなんてほとんどないでしょ?
根本的な設計を改善するほうがいい。
つまり静的なページで作れば問題は解決すると言うこと
JavaScriptを使って動きをつけなきゃいけないことなんてほとんどないでしょ?
623デフォルトの名無しさん
2018/12/04(火) 18:43:50.06ID:T1qfCjQk >>622
は?
は?
624デフォルトの名無しさん
2018/12/04(火) 18:58:48.70ID:bTQB60BC625デフォルトの名無しさん
2018/12/04(火) 19:03:04.87ID:E1VClVEB >>624
は?
は?
626デフォルトの名無しさん
2018/12/04(火) 19:17:23.97ID:V/vZILhe >>621
考え方は間違っていないと思うけど、ちょっと混線してるかな?
自前で遅延/選択的描画を実装すると糞コードになるのは、
OOPで言うと、本来はオブジェクトA(ブラウザ)で完結する処理をオブジェクトB(JS)で無理に行っているからであって、
俺はそこを何とかして欲しいんだよね。
フレームワークに押し込んで隠蔽する、というのも一つの手ではあるけれど。
そちらのレスについては、単純には、
・馬鹿な書き方でもそこそこ速い
・チューニングしまくれば超速い
が通常目指すべきゴールだ。ここまではいいよな?
どちらを目指すべきかだが、両方追っかけているC++が若干迷走気味なので、
本当はどちらかに絞った方がいいんだよ。
Houdiniってことはゲーム畑に近いと思うけど、それなら当然後者を目指すべきと考え、
レンダリング制御関連のAPIがほぼ無いから困っているとは思う。
しかしそれは、APIさえ有れば十分に制御が出来る腕前があるからであって、
実際のWeb系はそこまで到達してない奴の方が多いと思う。
jQuery廚がよく言う「jQueryは簡単!」(=馬鹿でも問題ない)というのは実は偉大なことであって、
これ自体は素晴らしい。
(jQuery廚の問題は、結局そこに乗っかってしまっていて、結果、馬鹿なままな点であって)
俺個人としては、手を抜けるところは抜きたいので、前者に寄って欲しいんだけどね。
実際は後者に寄っている気はする。
というか、前者を実装するにしてもAPIが必要だし、普通はまず後者を実装するしかないからね。
ゴリゴリの制御が要求されたとしても超高速化したいのなら、技術的にはC++側にコードを注入出来ればいい。
昔で言うアドオンをサイトから毎回ダウンロードして使う、というイメージだ。
アドオン自体はサンドボックス上ではなかったので排除されてしまったが、サンドボックス上にすれば行けるはず。
WebAssemblyが近いが、あれはJS側上のサンドボックスのはずだから、あれのC++側版だね。
考え方は間違っていないと思うけど、ちょっと混線してるかな?
自前で遅延/選択的描画を実装すると糞コードになるのは、
OOPで言うと、本来はオブジェクトA(ブラウザ)で完結する処理をオブジェクトB(JS)で無理に行っているからであって、
俺はそこを何とかして欲しいんだよね。
フレームワークに押し込んで隠蔽する、というのも一つの手ではあるけれど。
そちらのレスについては、単純には、
・馬鹿な書き方でもそこそこ速い
・チューニングしまくれば超速い
が通常目指すべきゴールだ。ここまではいいよな?
どちらを目指すべきかだが、両方追っかけているC++が若干迷走気味なので、
本当はどちらかに絞った方がいいんだよ。
Houdiniってことはゲーム畑に近いと思うけど、それなら当然後者を目指すべきと考え、
レンダリング制御関連のAPIがほぼ無いから困っているとは思う。
しかしそれは、APIさえ有れば十分に制御が出来る腕前があるからであって、
実際のWeb系はそこまで到達してない奴の方が多いと思う。
jQuery廚がよく言う「jQueryは簡単!」(=馬鹿でも問題ない)というのは実は偉大なことであって、
これ自体は素晴らしい。
(jQuery廚の問題は、結局そこに乗っかってしまっていて、結果、馬鹿なままな点であって)
俺個人としては、手を抜けるところは抜きたいので、前者に寄って欲しいんだけどね。
実際は後者に寄っている気はする。
というか、前者を実装するにしてもAPIが必要だし、普通はまず後者を実装するしかないからね。
ゴリゴリの制御が要求されたとしても超高速化したいのなら、技術的にはC++側にコードを注入出来ればいい。
昔で言うアドオンをサイトから毎回ダウンロードして使う、というイメージだ。
アドオン自体はサンドボックス上ではなかったので排除されてしまったが、サンドボックス上にすれば行けるはず。
WebAssemblyが近いが、あれはJS側上のサンドボックスのはずだから、あれのC++側版だね。
627デフォルトの名無しさん
2018/12/04(火) 19:25:43.01ID:VeulgD+K 3DグラフィックスのHoudiniと勘違いしてない?
CSS拡張APIのHoudiniだよ?
CSS拡張APIのHoudiniだよ?
628デフォルトの名無しさん
2018/12/04(火) 19:27:12.66ID:T1qfCjQk >>624
あのさ、お前のようなヴァカの主義なんか興味ないんだよ、クソ間抜け。
あのさ、お前のようなヴァカの主義なんか興味ないんだよ、クソ間抜け。
629デフォルトの名無しさん
2018/12/04(火) 19:38:52.76ID:V/vZILhe >>622
君が静的なサイトしか作れないからといって、そうだと思いこむのはさすがに不味いと思うぞ。
>>624
というか、前から疑問なのだが、君は普段どんなサイトを見てるんだ?
純粋に静的なページって、今時、あまり見ないだろ。
例えば、動的な順で並べると以下か?
Amazon等ECサイト…大体SPA
2ch等掲示板…2chは糞だが、本来はDBに格納してPHP等でhtmlを生成して配信。
Yahoo等のニュースサイト…同上。更新頻度がやや低いだけ。
MDN/MSDN等…同上。さらに更新頻度は低い。でも更新機能があるからDBがあった方が楽。
ブログ…この辺から直接html配信でも行けるはずだが、実際はDB使っている方が多いのでは?
他に何がある?
DBも使わずhtmlを直接書いて配信してるサイトなんて、普段ほぼ見なくね?
零細サイトはほぼこれだから、サイト数(=仕事)だけは多いのかもしれんが。
君が静的なサイトしか作れないからといって、そうだと思いこむのはさすがに不味いと思うぞ。
>>624
というか、前から疑問なのだが、君は普段どんなサイトを見てるんだ?
純粋に静的なページって、今時、あまり見ないだろ。
例えば、動的な順で並べると以下か?
Amazon等ECサイト…大体SPA
2ch等掲示板…2chは糞だが、本来はDBに格納してPHP等でhtmlを生成して配信。
Yahoo等のニュースサイト…同上。更新頻度がやや低いだけ。
MDN/MSDN等…同上。さらに更新頻度は低い。でも更新機能があるからDBがあった方が楽。
ブログ…この辺から直接html配信でも行けるはずだが、実際はDB使っている方が多いのでは?
他に何がある?
DBも使わずhtmlを直接書いて配信してるサイトなんて、普段ほぼ見なくね?
零細サイトはほぼこれだから、サイト数(=仕事)だけは多いのかもしれんが。
630デフォルトの名無しさん
2018/12/04(火) 20:11:14.45ID:V/vZILhe >>627
してる。というか、ググったらそれが出てきて、Web系の会社も記事を出してて、
OpenCVでキャンバスに描くぜ!なノリだったからそれだと思った。
そして改めてググり直した。
https://developers.google.com/web/updates/2016/05/houdini?hl=ja
う〜ん。最初はこんなもんかもしれんが、
これは pause: auto や draw: lazy が効率よく出来るタイプの物ではないな。
初期のJavaScriptはこんな感じでちょこっと動きを付けていたのかも?
そしてそれをCSS側に移動しただけのような。
今のところCSSはプログラム出来ない(しない)で来ていて、それによる良さもあると思うのだけど。
勿論これが出来れば便利ではあるが、グダグダなのが増えて管理コストが増加してポシャる気が。
なんであれ「出来ることはいいことだ」という考え方もありだけど、
俺自身は「出来ることと出来ないことがはっきりしていて、使い分ける」方が管理が楽だと思っている。
なんというか、この中途半端に出来る感が、凄くJSっぽくはあるが。
とはいえ、JSは駄目だがCSSはあり、というサイトも多いはずなので、無駄に広まりそうだが。
してる。というか、ググったらそれが出てきて、Web系の会社も記事を出してて、
OpenCVでキャンバスに描くぜ!なノリだったからそれだと思った。
そして改めてググり直した。
https://developers.google.com/web/updates/2016/05/houdini?hl=ja
う〜ん。最初はこんなもんかもしれんが、
これは pause: auto や draw: lazy が効率よく出来るタイプの物ではないな。
初期のJavaScriptはこんな感じでちょこっと動きを付けていたのかも?
そしてそれをCSS側に移動しただけのような。
今のところCSSはプログラム出来ない(しない)で来ていて、それによる良さもあると思うのだけど。
勿論これが出来れば便利ではあるが、グダグダなのが増えて管理コストが増加してポシャる気が。
なんであれ「出来ることはいいことだ」という考え方もありだけど、
俺自身は「出来ることと出来ないことがはっきりしていて、使い分ける」方が管理が楽だと思っている。
なんというか、この中途半端に出来る感が、凄くJSっぽくはあるが。
とはいえ、JSは駄目だがCSSはあり、というサイトも多いはずなので、無駄に広まりそうだが。
631デフォルトの名無しさん
2018/12/04(火) 21:28:10.23ID:xAx9wf3n >>630
HoudiniはCSSの枠組みで標準化されているが、実際にはCSSというスタイルシートの仕様の延長上のものと捉えるのは間違っている
もちろん単純なCSSの拡張、柔軟化の仕様も含むが、それ以上に重大な仕様が含まれている
Houdiniとは、スタイルシートのパースから、レイアウト・ペイント・将来的には文字描画も含む
要するにブラウザのDOMレンダリングシステムをローレベルでほぼ丸ごと露出させるという
Extensible Webの精神に乗っ取ったけして中途半端ではない非常に深く広くしっかりとしたAPIだと捉えるのが正しい
pause: auto だの draw: lazy だのも素直に実現できる
>>グダグダなのが増えて管理コストが増加してポシャる
その考え方が本当に間違っている
Extensible Webは皆低レイヤーを触ろうと言ってるんじゃない
皆が求める機能を標準に追加していくのは難しいところがあるから
なんでも作れるAPIを提供してライブラリに任せましょう
そこで本当に便利なものができたら標準に組み込んでも良いねという精神だ
逆に新しい高レイヤーの機能入れたいねとなったときには、
必ずそれを構築できる低レイヤーのAPIを提供することになっている
それが最近よく聞くLayered APIと呼ばれる取り組みだ
つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
HoudiniはCSSの枠組みで標準化されているが、実際にはCSSというスタイルシートの仕様の延長上のものと捉えるのは間違っている
もちろん単純なCSSの拡張、柔軟化の仕様も含むが、それ以上に重大な仕様が含まれている
Houdiniとは、スタイルシートのパースから、レイアウト・ペイント・将来的には文字描画も含む
要するにブラウザのDOMレンダリングシステムをローレベルでほぼ丸ごと露出させるという
Extensible Webの精神に乗っ取ったけして中途半端ではない非常に深く広くしっかりとしたAPIだと捉えるのが正しい
pause: auto だの draw: lazy だのも素直に実現できる
>>グダグダなのが増えて管理コストが増加してポシャる
その考え方が本当に間違っている
Extensible Webは皆低レイヤーを触ろうと言ってるんじゃない
皆が求める機能を標準に追加していくのは難しいところがあるから
なんでも作れるAPIを提供してライブラリに任せましょう
そこで本当に便利なものができたら標準に組み込んでも良いねという精神だ
逆に新しい高レイヤーの機能入れたいねとなったときには、
必ずそれを構築できる低レイヤーのAPIを提供することになっている
それが最近よく聞くLayered APIと呼ばれる取り組みだ
つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
632デフォルトの名無しさん
2018/12/04(火) 22:12:04.80ID:WEhkJbZf この静的って、DOMを弄らないって意味ではないの?
昔ながらのPOSTで全画面更新で充分だって主張に読めたけど。
流石にバックエンド無しと取るのはちょっと変な気がする。
昔ながらのPOSTで全画面更新で充分だって主張に読めたけど。
流石にバックエンド無しと取るのはちょっと変な気がする。
633デフォルトの名無しさん
2018/12/04(火) 22:34:21.67ID:ZSkJl4U8 いやでもapacheの説明書とかではjsもhtmlやcssと同じくスタティックコンテンツやけども…
634デフォルトの名無しさん
2018/12/04(火) 23:57:54.73ID:V/vZILhe >>631
まあ言っていることは分かるし、その通りだが…
> pause: auto だの draw: lazy だのも素直に実現できる
表現は出来るが、これだと実際やるのはJSだろ。
つまり、今JSで実装しているReactのコードをCSSに持っていくだけであり、速度上のメリットは無い。
それでも外部APIが素晴らしく改善されるので効果はあるが、俺が欲しいのはコレジャナイ。
JSで実装する遅延描画がイマイチなのは、offsetTop等が糞遅いからで、
これは『正しい』offsetTopを要求するAPIしかないからだ。
だから、offsetTopの度にリフローを行い、未描画のDOMがないか全チェックする為、遅くなる。(多分)
ただ、遅延描画に必要なのは「そのページ以上の所まで描画済みか?」であり、
offsetTopの精度が悪くてもいい。(未描画DOMが残ってても問題ない)
そしてこの「精度の悪いoffsetTop」をAPIとして定義しろ、なんていちいちやっていてもキリがないから、
レンダラに介入させろ、というわけだ。
レンダラ内でラスタライズしている時、アドレスからおおよそのoffsetTopなんて一瞬で出せる。
当然高速化するし、きめ細かく制御出来るから、限界まで高速化出来る。
(ただしGPUにやらせようぜなんて話が出てたからそうなると一筋縄ではいかないが)
まあ言っていることは分かるし、その通りだが…
> pause: auto だの draw: lazy だのも素直に実現できる
表現は出来るが、これだと実際やるのはJSだろ。
つまり、今JSで実装しているReactのコードをCSSに持っていくだけであり、速度上のメリットは無い。
それでも外部APIが素晴らしく改善されるので効果はあるが、俺が欲しいのはコレジャナイ。
JSで実装する遅延描画がイマイチなのは、offsetTop等が糞遅いからで、
これは『正しい』offsetTopを要求するAPIしかないからだ。
だから、offsetTopの度にリフローを行い、未描画のDOMがないか全チェックする為、遅くなる。(多分)
ただ、遅延描画に必要なのは「そのページ以上の所まで描画済みか?」であり、
offsetTopの精度が悪くてもいい。(未描画DOMが残ってても問題ない)
そしてこの「精度の悪いoffsetTop」をAPIとして定義しろ、なんていちいちやっていてもキリがないから、
レンダラに介入させろ、というわけだ。
レンダラ内でラスタライズしている時、アドレスからおおよそのoffsetTopなんて一瞬で出せる。
当然高速化するし、きめ細かく制御出来るから、限界まで高速化出来る。
(ただしGPUにやらせようぜなんて話が出てたからそうなると一筋縄ではいかないが)
635デフォルトの名無しさん
2018/12/04(火) 23:58:28.93ID:V/vZILhe >>631(続き)
> つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
言っていることは分かるし、確かにこれ以外に現実的路線はないが、果たして上手く行くかね?
今以上にフレームワークが乱立して、なんだかな、な状態になりそうな気がするが。
それも含めてWebだというのならそうだが、
今フレームワークを乱立させてる連中をどうにかして一ヶ所に集中させ、一ついい物を作る方が、
皆にとって幸せだと思うがな。
現状のフレームワークなんて全部死に体だし、あれでは浮かばれんだろ。
> 今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
これがかなり無理があるんだよ。
JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが、
実際はC++ヘビーでレンダラやDOMが実行時間の大半を占めてるだろ。
JS側には改善予算(改善しろ)がないんだよ。
かといって、C++側にAPIやフックを用意させるのもかなり無理な話ではあるが、
しかしJSがパフォーマンスの全責任を負うのはそれ以上に『原理的に』無理だ。
強いて言うなら、現状のブラウザは十分高速で、1ページ程度ならレンダリングは一瞬だ。
遅いのは無駄に10ページ分レンダリングしてたりするか、無駄に遅いJSを実行しているからであり、
ここら辺を遅延描画で改善してやれば可能だが、
今はこれを実装する為の「速い(が精度の悪い)offsetTop」がないんだよ。
> それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
現実的にはこの路線しかないからな。これは認める。
> つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
言っていることは分かるし、確かにこれ以外に現実的路線はないが、果たして上手く行くかね?
今以上にフレームワークが乱立して、なんだかな、な状態になりそうな気がするが。
それも含めてWebだというのならそうだが、
今フレームワークを乱立させてる連中をどうにかして一ヶ所に集中させ、一ついい物を作る方が、
皆にとって幸せだと思うがな。
現状のフレームワークなんて全部死に体だし、あれでは浮かばれんだろ。
> 今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
これがかなり無理があるんだよ。
JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが、
実際はC++ヘビーでレンダラやDOMが実行時間の大半を占めてるだろ。
JS側には改善予算(改善しろ)がないんだよ。
かといって、C++側にAPIやフックを用意させるのもかなり無理な話ではあるが、
しかしJSがパフォーマンスの全責任を負うのはそれ以上に『原理的に』無理だ。
強いて言うなら、現状のブラウザは十分高速で、1ページ程度ならレンダリングは一瞬だ。
遅いのは無駄に10ページ分レンダリングしてたりするか、無駄に遅いJSを実行しているからであり、
ここら辺を遅延描画で改善してやれば可能だが、
今はこれを実装する為の「速い(が精度の悪い)offsetTop」がないんだよ。
> それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
現実的にはこの路線しかないからな。これは認める。
636デフォルトの名無しさん
2018/12/05(水) 00:18:53.86ID:HfjLZhFv きたないコード書いてそうだなあ
637デフォルトの名無しさん
2018/12/05(水) 00:27:04.77ID:n6GZlX92 >>632
すまん、それはちょっと俺が先走った。
普通の「静的ページ」は君の定義で正しいだろう。
俺は616に書いたとおり、jQueryが活躍するサイトはHTMLがグダグダな場合で、
それはhtmlを自動生成してない場合と認識しているから、
彼はjQuery廚なのもあり、先走ってしまった。
さて、実際yahooニュースをJS無しで確認してみると、
<noscript>が大量に使われているものの、どうでもいい場所ばかりだ。
これなら変にアドブロックするより、JSを切った方がいいのでは…とも思える。
SPAでもないし、ポップアップもない。リンクはいちいちページ遷移する。
これは「静的ページ」だ。
もうちょっとましな作りかと思っていたのだが、
確かにこれで大して問題ないのも事実だな。
もっとも、鯖側で動的にhtmlを生成する場合、
当然画一的なhtmlとなり、IDやclassをきっちり振ることも簡単だから、
jQueryを使う意味はほぼ無いと思う、という主張はそのままだが。
(yahooはjQuery使っているが)
すまん、それはちょっと俺が先走った。
普通の「静的ページ」は君の定義で正しいだろう。
俺は616に書いたとおり、jQueryが活躍するサイトはHTMLがグダグダな場合で、
それはhtmlを自動生成してない場合と認識しているから、
彼はjQuery廚なのもあり、先走ってしまった。
さて、実際yahooニュースをJS無しで確認してみると、
<noscript>が大量に使われているものの、どうでもいい場所ばかりだ。
これなら変にアドブロックするより、JSを切った方がいいのでは…とも思える。
SPAでもないし、ポップアップもない。リンクはいちいちページ遷移する。
これは「静的ページ」だ。
もうちょっとましな作りかと思っていたのだが、
確かにこれで大して問題ないのも事実だな。
もっとも、鯖側で動的にhtmlを生成する場合、
当然画一的なhtmlとなり、IDやclassをきっちり振ることも簡単だから、
jQueryを使う意味はほぼ無いと思う、という主張はそのままだが。
(yahooはjQuery使っているが)
638デフォルトの名無しさん
2018/12/05(水) 06:07:21.44ID:KtLqbb1s639デフォルトの名無しさん
2018/12/05(水) 07:03:28.49ID:UkapFAmF >>635
>>一ついい物を作る方が
君がそれができるというのならしてみると良い
Webは一度APIを入れると中々消すことができない
だけど流れは早いので慎重に進めすぎるわけにもいかない
それを両方解決できる人間はこの世にいない
今のまま標準に機能を入れ続けていったらそれこそカオスになる
だからそういったリスクはライブラリに押し付けるのが正しい
>>JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが
俺は今あるコードのことを言ってるんじゃない
これからは高レベルなAPIは低レベルなAPIをもとに作っていくことになるのだから
なにか新しい機能を求めたり、今まで難しかったことを素直に実現するため
Houdini含む低レベルAPI叩いたり、それを利用したライブラリを使うときは
その機能のパフォーマンスを含む責任はJSサイドに来ると言っているんだよ
>>一ついい物を作る方が
君がそれができるというのならしてみると良い
Webは一度APIを入れると中々消すことができない
だけど流れは早いので慎重に進めすぎるわけにもいかない
それを両方解決できる人間はこの世にいない
今のまま標準に機能を入れ続けていったらそれこそカオスになる
だからそういったリスクはライブラリに押し付けるのが正しい
>>JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが
俺は今あるコードのことを言ってるんじゃない
これからは高レベルなAPIは低レベルなAPIをもとに作っていくことになるのだから
なにか新しい機能を求めたり、今まで難しかったことを素直に実現するため
Houdini含む低レベルAPI叩いたり、それを利用したライブラリを使うときは
その機能のパフォーマンスを含む責任はJSサイドに来ると言っているんだよ
640デフォルトの名無しさん
2018/12/05(水) 08:57:03.83ID:2zrT35AA 一般人「クライアントからの情報に応じてサーバーサイドでJavaやPHP、Rubyなどで動的にHTMLを生成して返すのが動的ページ、用意してあるHTMLをそのまま返すのが静的ページ」
キチガイ「Javascriptが動いてたら動的ページ!」
なぜキチガイはイカれた頭の中のオレオレ定義をその汚い口からひり出してしまうのか…
キチガイ「Javascriptが動いてたら動的ページ!」
なぜキチガイはイカれた頭の中のオレオレ定義をその汚い口からひり出してしまうのか…
641デフォルトの名無しさん
2018/12/05(水) 09:46:02.65ID:n6GZlX92 >>639
> Webは一度APIを入れると中々消すことができない
> だけど流れは早いので慎重に進めすぎるわけにもいかない
これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
そしてWebが速いって言ったって、結果出来上がっているのはゴミの山であって、
進歩(=成功したパス=使えるものとして残った経路)だけ見ればC#の方が断然速い。
事実として今のJavaScriptはC#の後追いでしかないだろ。
> それを両方解決できる人間はこの世にいない
これは「創始者」がこれに近いものとして振る舞う、というのが他言語/OSSの習わしだ。
この点、ブレンダン・アイクが全く出てこないところがJavaScriptの不幸な点ではあるけれど。
とはいえ、現状で現実的判断をするなら、君の言っている方向性しかない。
ただ、カオスにはもうなってると思うけどな。
○○ってフレームワークはどうですか?みたいな質問ばかりなのがそれを如実に示してる。
標準さえ汚れなければいい、という考え方もありだが、
Promiseは要らない子だと俺は思うし、防波堤になりきれてない。
> 君がそれができるというのならしてみると良い
機会があればやるかもしれん。(これは君も同じだと思うが)
俺が今フレームワークとして欲しいのは遅延描画だけで、Houdiniでは無理だからすぐにはやらないね。
ただ、どっちかと言えば俺が試してみたいのはフレームワークではなくJavaScript自体の直接的拡張であり、
JSエンジンの低レベルAPIについて提供するような方向になっているか知ってれば教えて欲しい。
例えば async とか、ああいう言語拡張をする為のJSそのものの低レベルAPIだ。
> Webは一度APIを入れると中々消すことができない
> だけど流れは早いので慎重に進めすぎるわけにもいかない
これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
そしてWebが速いって言ったって、結果出来上がっているのはゴミの山であって、
進歩(=成功したパス=使えるものとして残った経路)だけ見ればC#の方が断然速い。
事実として今のJavaScriptはC#の後追いでしかないだろ。
> それを両方解決できる人間はこの世にいない
これは「創始者」がこれに近いものとして振る舞う、というのが他言語/OSSの習わしだ。
この点、ブレンダン・アイクが全く出てこないところがJavaScriptの不幸な点ではあるけれど。
とはいえ、現状で現実的判断をするなら、君の言っている方向性しかない。
ただ、カオスにはもうなってると思うけどな。
○○ってフレームワークはどうですか?みたいな質問ばかりなのがそれを如実に示してる。
標準さえ汚れなければいい、という考え方もありだが、
Promiseは要らない子だと俺は思うし、防波堤になりきれてない。
> 君がそれができるというのならしてみると良い
機会があればやるかもしれん。(これは君も同じだと思うが)
俺が今フレームワークとして欲しいのは遅延描画だけで、Houdiniでは無理だからすぐにはやらないね。
ただ、どっちかと言えば俺が試してみたいのはフレームワークではなくJavaScript自体の直接的拡張であり、
JSエンジンの低レベルAPIについて提供するような方向になっているか知ってれば教えて欲しい。
例えば async とか、ああいう言語拡張をする為のJSそのものの低レベルAPIだ。
642デフォルトの名無しさん
2018/12/05(水) 18:04:37.79ID:VqW7A1t3 >>636
全くもって。
全くもって。
643デフォルトの名無しさん
2018/12/05(水) 20:58:57.31ID:UkapFAmF >>641
>>これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
その場合でも旧バージョンは旧エンジンで動かせば良いのだから
しかしWebでは旧サイトは旧ブラウザで見れば良いとは言えない
JSもしかり、機能を非推奨としても、新しい機能との兼ね合いを定義しないといけないし
廃そうとしても10年以上かかる
>>結果出来上がっているのはゴミの山
WebAPIをゴミの山と言うのは流石に言いすぎだと思う
1つ1つ思い返してみても、ゴミだったねと言えるAPIはそう多くない
>>ブレンダン・アイクが全く出てこないところ
間違っている
彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
彼が慎重なおかげでJSはまだ「失敗」していない
勢いのまま進んでたら失敗していたであろう瞬間はいくつもあった
とは言え、今まで話してきたのはほとんどWebAPIについてだ
JSとWeb違う 彼がWebに口出す責任はない
そもそもWebとは皆の総意の中に秩序を見出す形で作られるものなのだから
皆がその時実現したいと思っていることを実現できるようにするのが正しいWebだ
だから流れは速い
それをプロプライエタリで創始者が全て管理するプラットフォームと比べて、あれが悪いこれが悪いというのは間違っている
なぜならそれは男がいて女がいるようなものだから
男が女らしくなったら男じゃないし、女が男らしくなったら女じゃない
男に女らしくないとか、女に男らしくないとか言うのは根本的に間違っていること
男らしいのが好きか、女らしいのが好きか、という話でしか無い
>>これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
その場合でも旧バージョンは旧エンジンで動かせば良いのだから
しかしWebでは旧サイトは旧ブラウザで見れば良いとは言えない
JSもしかり、機能を非推奨としても、新しい機能との兼ね合いを定義しないといけないし
廃そうとしても10年以上かかる
>>結果出来上がっているのはゴミの山
WebAPIをゴミの山と言うのは流石に言いすぎだと思う
1つ1つ思い返してみても、ゴミだったねと言えるAPIはそう多くない
>>ブレンダン・アイクが全く出てこないところ
間違っている
彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
彼が慎重なおかげでJSはまだ「失敗」していない
勢いのまま進んでたら失敗していたであろう瞬間はいくつもあった
とは言え、今まで話してきたのはほとんどWebAPIについてだ
JSとWeb違う 彼がWebに口出す責任はない
そもそもWebとは皆の総意の中に秩序を見出す形で作られるものなのだから
皆がその時実現したいと思っていることを実現できるようにするのが正しいWebだ
だから流れは速い
それをプロプライエタリで創始者が全て管理するプラットフォームと比べて、あれが悪いこれが悪いというのは間違っている
なぜならそれは男がいて女がいるようなものだから
男が女らしくなったら男じゃないし、女が男らしくなったら女じゃない
男に女らしくないとか、女に男らしくないとか言うのは根本的に間違っていること
男らしいのが好きか、女らしいのが好きか、という話でしか無い
644デフォルトの名無しさん
2018/12/05(水) 21:01:06.04ID:UkapFAmF >>641
>>○○ってフレームワークはどうですか?みたいな質問ばかり
いやいや、それが理想なのに、質問がまだまだ少なすぎるくらいだよ
というか、カオスになったら、モジュールの検索のしやすさや、そのためのスレを立てることが必要になるはずだ
でもまだそういった、「これを実現するためにどのライブラリが良いんだろう」という質問がなく、
具体的なライブラリばかり質問に挙がるのだから、全然まだまだってことだ
>>Promiseは要らない子
Promiseがどうして要らない子だと思うのかさっぱりわからない
Promiseとasync-awaitの関係は他と比べても無難で普通だ
Kotlinの用に中断可能なスレッドの組み合わせでやるのも面白いが、
基本的に「スクリプト言語である」はJSは、何かの対象を操作するためのものであって、
例えばWebならレンダリングスレッド上でイベントを受け取ったり操作したりすることが基本の動作であるから
今の仕組みになるのが最も自然と言える
>>言語拡張をする為のJSそのものの低レベルAPI
アイディアは昔から出てるが、これこそ正に流行り廃りが激しく未開拓な分野
安易に入れてしまうと後々公開するので、マクロ的な機能はずっと後
ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい
>>○○ってフレームワークはどうですか?みたいな質問ばかり
いやいや、それが理想なのに、質問がまだまだ少なすぎるくらいだよ
というか、カオスになったら、モジュールの検索のしやすさや、そのためのスレを立てることが必要になるはずだ
でもまだそういった、「これを実現するためにどのライブラリが良いんだろう」という質問がなく、
具体的なライブラリばかり質問に挙がるのだから、全然まだまだってことだ
>>Promiseは要らない子
Promiseがどうして要らない子だと思うのかさっぱりわからない
Promiseとasync-awaitの関係は他と比べても無難で普通だ
Kotlinの用に中断可能なスレッドの組み合わせでやるのも面白いが、
基本的に「スクリプト言語である」はJSは、何かの対象を操作するためのものであって、
例えばWebならレンダリングスレッド上でイベントを受け取ったり操作したりすることが基本の動作であるから
今の仕組みになるのが最も自然と言える
>>言語拡張をする為のJSそのものの低レベルAPI
アイディアは昔から出てるが、これこそ正に流行り廃りが激しく未開拓な分野
安易に入れてしまうと後々公開するので、マクロ的な機能はずっと後
ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい
645デフォルトの名無しさん
2018/12/05(水) 23:32:43.96ID:n6GZlX92 >>643
> いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
これは技術的にはそうだが、実際はいきなりは壊してない。
JSと同じく、一旦obsoleteにして様子見し、衰退を待ちつつ、だ。
JS界隈ならちょうどjQueryと同じだ。
そこそこ互換性を壊しつつ、どのバージョンを使うかはユーザー選択だ。
だからこの意味で「メジャーアップデートのときに互換性を壊すことができる」を利点とするなら、
それはjQueryが素晴らしくフィットするわけだし、実際そうだから蔓延ったわけだろ。
ならずっとjQueryをポリフィルライブラリとして使えばいいだけだ。
実際そういう人もいるだろう。
> 彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
そうなのか。ならそれは正しい姿だ。
> 正しいWebだ
いややはり買いかぶりすぎだよ。
これは君だけではなく、最近の連中はみんなこんな感じだが。他言語も含めて。
自分が乗っかっているプラットフォームが正義だ、と思いこみたがっている。
実際の所、プロプライエタリにもオープンにもそれぞれの良さはある。
そしてWebは実質Google/MS/Appleによる準プロプライエタリだし、
C++仕様委員会の方が裾野も広くてオープンだ。
が、そもそもこんなのはどうでも良くて、
上位階層で「気に入らなければ使わない」という自由が保障されているから、
外部から見てどういう状況か明確に分かれば問題ない。
この意味で、ブラウザ上で動く言語がJSに限定されている現状は「プロプライエタリ」以上に大問題なわけだが、
お前らはこれを問題だとは認めないわけだろ。
まあこれもWebAssemblyで改善されそうだし、正しい方向に向かってはいるが。
> いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
これは技術的にはそうだが、実際はいきなりは壊してない。
JSと同じく、一旦obsoleteにして様子見し、衰退を待ちつつ、だ。
JS界隈ならちょうどjQueryと同じだ。
そこそこ互換性を壊しつつ、どのバージョンを使うかはユーザー選択だ。
だからこの意味で「メジャーアップデートのときに互換性を壊すことができる」を利点とするなら、
それはjQueryが素晴らしくフィットするわけだし、実際そうだから蔓延ったわけだろ。
ならずっとjQueryをポリフィルライブラリとして使えばいいだけだ。
実際そういう人もいるだろう。
> 彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
そうなのか。ならそれは正しい姿だ。
> 正しいWebだ
いややはり買いかぶりすぎだよ。
これは君だけではなく、最近の連中はみんなこんな感じだが。他言語も含めて。
自分が乗っかっているプラットフォームが正義だ、と思いこみたがっている。
実際の所、プロプライエタリにもオープンにもそれぞれの良さはある。
そしてWebは実質Google/MS/Appleによる準プロプライエタリだし、
C++仕様委員会の方が裾野も広くてオープンだ。
が、そもそもこんなのはどうでも良くて、
上位階層で「気に入らなければ使わない」という自由が保障されているから、
外部から見てどういう状況か明確に分かれば問題ない。
この意味で、ブラウザ上で動く言語がJSに限定されている現状は「プロプライエタリ」以上に大問題なわけだが、
お前らはこれを問題だとは認めないわけだろ。
まあこれもWebAssemblyで改善されそうだし、正しい方向に向かってはいるが。
646デフォルトの名無しさん
2018/12/05(水) 23:34:08.33ID:n6GZlX92 >>644
> 全然まだまだってことだ
なるほどそっちの立場か。それは理解した。
俺は「適切に制限されている方がいい」という立場だから、見方は異なるが、ここを合わせる必要はない。
Promiseについては君の立場なら「あり」だろう。
俺の立場なら、ほぼ async で間に合うのだから「要らない」し、
そもそもパクリ元のC#にpromiseなんて無いのに「要るわけがない」だろ、となる。
それ以前に、promiseが必要なのはいわゆるcallback地獄だが、
これも非同期なのに無理に同期的に書いた結果であって、
最初から非同期で書けばそんなことにはならないし。
> ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい
ASTは正直言って要らん。あれはローレベルすぎる。
俺が欲しいのはJSパーサに対してコードを注入出来るものと、Proxyの超豪華版だね。
ただまあ、全体的にそちらに向かっているとは理解した。
ちなみにdocument等、いわゆるグローバルをフック出来るようになるかは分かる?
ReactでJSXが必要になるのはdocumentに対する操作を全部VirtualDOM側にフックする為で、
documentそのものをフック(上書き)出来ればAPIの外面上の違いは極めて少なく出来る。
(jQueryのコードみたいに全部 $(document)してくれてれば$の上書きで簡単にフック出来るから、
jQueryはこの意味では逆転ホームランの可能性を秘めているわけだが。
というか、DOM操作を全て$()でフックしてくれてるjQueryとvirtualDOMは技術的にはかなり相性がいいはずだが、
全く話題になってないところを見ると、virtualDOMやってる連中もjQueryは死ね、と思ってるんだろうな)
> 全然まだまだってことだ
なるほどそっちの立場か。それは理解した。
俺は「適切に制限されている方がいい」という立場だから、見方は異なるが、ここを合わせる必要はない。
Promiseについては君の立場なら「あり」だろう。
俺の立場なら、ほぼ async で間に合うのだから「要らない」し、
そもそもパクリ元のC#にpromiseなんて無いのに「要るわけがない」だろ、となる。
それ以前に、promiseが必要なのはいわゆるcallback地獄だが、
これも非同期なのに無理に同期的に書いた結果であって、
最初から非同期で書けばそんなことにはならないし。
> ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい
ASTは正直言って要らん。あれはローレベルすぎる。
俺が欲しいのはJSパーサに対してコードを注入出来るものと、Proxyの超豪華版だね。
ただまあ、全体的にそちらに向かっているとは理解した。
ちなみにdocument等、いわゆるグローバルをフック出来るようになるかは分かる?
ReactでJSXが必要になるのはdocumentに対する操作を全部VirtualDOM側にフックする為で、
documentそのものをフック(上書き)出来ればAPIの外面上の違いは極めて少なく出来る。
(jQueryのコードみたいに全部 $(document)してくれてれば$の上書きで簡単にフック出来るから、
jQueryはこの意味では逆転ホームランの可能性を秘めているわけだが。
というか、DOM操作を全て$()でフックしてくれてるjQueryとvirtualDOMは技術的にはかなり相性がいいはずだが、
全く話題になってないところを見ると、virtualDOMやってる連中もjQueryは死ね、と思ってるんだろうな)
647デフォルトの名無しさん
2018/12/06(木) 00:03:12.65ID:3Vav0lUR 準プロプライエタリwwwww
広義の強制連行wwwww
広義の強制連行wwwww
648デフォルトの名無しさん
2018/12/06(木) 00:04:54.72ID:hDSk7yGP 話が長い
プロプライエタリの意味が分かってないんだろうなぁとは思った
プロプライエタリの意味が分かってないんだろうなぁとは思った
649デフォルトの名無しさん
2018/12/06(木) 03:08:30.00ID:q+ffO04V650デフォルトの名無しさん
2018/12/06(木) 04:20:19.55ID:+HhXq2pO 読んでる人偉いな
651デフォルトの名無しさん
2018/12/06(木) 12:44:28.29ID:cVfYjbad パクリ元のC#だか言ってる時点で御里が知れてる
C#にTaskとasync-awaitの絡みが入る前からdojoでdefferedが使われている
つうかESがよく参考にしてるのはC#じゃない、.NETだろ
C#にTaskとasync-awaitの絡みが入る前からdojoでdefferedが使われている
つうかESがよく参考にしてるのはC#じゃない、.NETだろ
652デフォルトの名無しさん
2018/12/06(木) 22:44:18.59ID:1VqVrE/R 流れぶった切って悪いが、
教えてくだしい。
↓を解読しようとしてるんだけど、DLしたら文字化けしてる?のときって
どうしらいいでしょうか?
ttps://d21agqkwgk4jud.cloudfront.net/MW-Common/RS4B/v0.1.9mw_2018-10-09/js/viewer_loader_v0.1.9mw_2018-10-09.js
教えてくだしい。
↓を解読しようとしてるんだけど、DLしたら文字化けしてる?のときって
どうしらいいでしょうか?
ttps://d21agqkwgk4jud.cloudfront.net/MW-Common/RS4B/v0.1.9mw_2018-10-09/js/viewer_loader_v0.1.9mw_2018-10-09.js
653デフォルトの名無しさん
2018/12/07(金) 02:41:15.18ID:DSF//pMG ttps://github.com/getify/LABjs
解読したいだけならこっち見れば良いんじゃないかな
解読したいだけならこっち見れば良いんじゃないかな
654デフォルトの名無しさん
2018/12/07(金) 03:39:36.49ID:dLDIWV31 雑誌読み放題とかのシャッフル画像を元に戻したいなら、
ブラウザを改造して、キャンバスの描画情報を出力できるようにしちゃったほうが早い
ブラウザを改造して、キャンバスの描画情報を出力できるようにしちゃったほうが早い
655652
2018/12/08(土) 02:27:44.56ID:aFqsKPg6656デフォルトの名無しさん
2018/12/08(土) 12:53:03.79ID:B4lKd+QM JSでスクリーンキャプチャしてもいいが
OS上で動くキャプチャツール使ったほうが良いだろう
OS上で動くキャプチャツール使ったほうが良いだろう
657デフォルトの名無しさん
2018/12/09(日) 09:32:12.46ID:IPgjDJi3 >>654
>雑誌読み放題とかのシャッフル画像を元に戻したいなら、
シャッフル画像ってこんなやつか、
http://demon-uploader.rosepink.us/uploads/2018120909160154095.png
有料の漫画発信サービスって、大元の画像ってサーバーにあると
思ってたが、こんな感じで加工して、まるまる出回らないようにしてたのか
っで、javascriptのcanvasで描画し直してユーザーのブラウザに表示してんだな
オレの仕事、工業用機械のプログラム担当だから、
web業界は知らんが、漫画発信ってこんなことしてんだな
>雑誌読み放題とかのシャッフル画像を元に戻したいなら、
シャッフル画像ってこんなやつか、
http://demon-uploader.rosepink.us/uploads/2018120909160154095.png
有料の漫画発信サービスって、大元の画像ってサーバーにあると
思ってたが、こんな感じで加工して、まるまる出回らないようにしてたのか
っで、javascriptのcanvasで描画し直してユーザーのブラウザに表示してんだな
オレの仕事、工業用機械のプログラム担当だから、
web業界は知らんが、漫画発信ってこんなことしてんだな
658デフォルトの名無しさん
2018/12/09(日) 22:09:22.03ID:hxDQDI9h 画像でも、DL されたくない場合に、画像上で右クリック禁止などにするけど、
F12 開発者ツールを起動して、URL を突き止められて、直リンクされる
だから、コピーされたくない場合は、canvas に描く
F12 開発者ツールを起動して、URL を突き止められて、直リンクされる
だから、コピーされたくない場合は、canvas に描く
659デフォルトの名無しさん
2018/12/09(日) 22:48:22.77ID:Ka5BzZUg 今どき違法サイトだとしても直リンクはしないだろ
660デフォルトの名無しさん
2018/12/09(日) 23:15:43.62ID:uilfb1+8 仮想DOMにはデメリットはないの?
661デフォルトの名無しさん
2018/12/09(日) 23:43:25.74ID:LCYDMKL+ 一旦仮想DOMを構築してからそれを実際のDOMに反映させるという手順を踏む以上、
ある程度のオーバーヘッドはある。
やりたいことがごく少量のDOM操作で済むような場合はかえって高くつく可能性がある。
ある程度のオーバーヘッドはある。
やりたいことがごく少量のDOM操作で済むような場合はかえって高くつく可能性がある。
662デフォルトの名無しさん
2018/12/10(月) 00:11:14.50ID:87PFSWwb663デフォルトの名無しさん
2018/12/10(月) 00:24:42.59ID:l8HcJzUp664デフォルトの名無しさん
2018/12/10(月) 01:15:42.73ID:ADpwiSWg >>661
指摘はその通りだが、実際はそこは問題にはならない。
体感100倍くらいDOMのレンダリングは遅いので、オーバーヘッドは1%だし、無視出来る。
それで10ページ分纏めてレンダリングしているのを遅延描画に出来れば、単純に10倍速くなる。
普通に考えて、『導入に手間がかからなければ』みんな使う。
(ただし実際の所はネットワークディレイの方が支配的で、
変に無理してSPA等するよりも物理鯖に金かけた方が効果があることもよくあるが)
最大の問題は、ブラウザが勝手にやってくれるのではなくて、手動でやれ、という点だ。
>>662
> DOM APIを使って直接DOMをいじるのはご法度
これは(jQuery含めて)DOMフレームワークの宿命だ。
というか、フレームワークの場合はフレームワークに合わせるのが当然であって、
それが必要なのにライブラリだと嘘ぶくjQueryは相当汚いのさ。
VirtualDOMは実験としては面白いが、手動でやらないといけない現状の仕様では、流行らせるのは厳しい。
自動でやってくれるのなら確実に流行る。
が、その場合は現状のvirtualDOMの知識なんて不要なレベルまで隠蔽される。
(はず。ただしJavaScriptの仕様委員会はかなり間抜けなのであまり期待は出来ないが)
指摘はその通りだが、実際はそこは問題にはならない。
体感100倍くらいDOMのレンダリングは遅いので、オーバーヘッドは1%だし、無視出来る。
それで10ページ分纏めてレンダリングしているのを遅延描画に出来れば、単純に10倍速くなる。
普通に考えて、『導入に手間がかからなければ』みんな使う。
(ただし実際の所はネットワークディレイの方が支配的で、
変に無理してSPA等するよりも物理鯖に金かけた方が効果があることもよくあるが)
最大の問題は、ブラウザが勝手にやってくれるのではなくて、手動でやれ、という点だ。
>>662
> DOM APIを使って直接DOMをいじるのはご法度
これは(jQuery含めて)DOMフレームワークの宿命だ。
というか、フレームワークの場合はフレームワークに合わせるのが当然であって、
それが必要なのにライブラリだと嘘ぶくjQueryは相当汚いのさ。
VirtualDOMは実験としては面白いが、手動でやらないといけない現状の仕様では、流行らせるのは厳しい。
自動でやってくれるのなら確実に流行る。
が、その場合は現状のvirtualDOMの知識なんて不要なレベルまで隠蔽される。
(はず。ただしJavaScriptの仕様委員会はかなり間抜けなのであまり期待は出来ないが)
665デフォルトの名無しさん
2018/12/10(月) 01:17:12.68ID:dLfSHYXu 以上、間抜けの長文でしたw
666デフォルトの名無しさん
2018/12/10(月) 06:20:05.87ID:09FPYSch667デフォルトの名無しさん
2018/12/10(月) 10:52:32.91ID:l8HcJzUp >>663
これ質問だから何かお願いします
これ質問だから何かお願いします
668デフォルトの名無しさん
2018/12/10(月) 12:31:44.90ID:FHPn309q >>666
jQuery語る奴にもいってやれ
jQuery語る奴にもいってやれ
669デフォルトの名無しさん
2018/12/10(月) 12:55:42.53ID:/ycQ7ddD DOM をjQuery で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する
Vue.js から見たら、仮想DOMがすべての情報だから、
仮想DOM以外の情報は捉えられない
教えなかったら誤動作する
Vue.js から見たら、仮想DOMがすべての情報だから、
仮想DOM以外の情報は捉えられない
670デフォルトの名無しさん
2018/12/10(月) 13:19:29.74ID:Tx0SRd+v DOMをAPIで変えた場合も同じ
671デフォルトの名無しさん
2018/12/10(月) 13:59:37.35ID:l8HcJzUp bootstrapはjQueryありきだからUIは自前でデザインしないといかんね
672デフォルトの名無しさん
2018/12/10(月) 18:13:52.48ID:87PFSWwb673デフォルトの名無しさん
2018/12/10(月) 20:11:33.28ID:xE5gMYqx674デフォルトの名無しさん
2018/12/10(月) 20:24:16.30ID:87PFSWwb それが仮想DOMの限界なんだよ
ウェブの標準との相性が悪い
ウェブの標準との相性が悪い
675デフォルトの名無しさん
2018/12/10(月) 22:13:45.73ID:VLQ/eMIp >>674
それは仮想DOMというよりは、フレームワーク全体の問題なのではなくて?
それは仮想DOMというよりは、フレームワーク全体の問題なのではなくて?
676デフォルトの名無しさん
2018/12/10(月) 22:53:24.37ID:pyV5g1n2 触らずに済むように作ったら
触れないからダメって言われても
触れないからダメって言われても
677デフォルトの名無しさん
2018/12/10(月) 23:15:27.01ID:ADpwiSWg その通りだな。
問題でも限界でもなく、当然の仕様であり、それが嫌なら使うな、でしかない。
というか直接いじったらフレームワーク導入の意味が無いし。
問題でも限界でもなく、当然の仕様であり、それが嫌なら使うな、でしかない。
というか直接いじったらフレームワーク導入の意味が無いし。
678デフォルトの名無しさん
2018/12/11(火) 13:17:30.38ID:8P4INi0w Doodle2というスクリプトから画像を描画できるCOMコンポーネントを64ビットのwindows10で使うことは無理でしょうか?
古い32ビットのDLLなので難しいかとは思うもですが
XPで使っていて自分にはこれで十分な機能だったので
使えるのならコードも流用できるので使いたいのです
C:\Windows\System32\ にはレジスト出来ず、調べたところC:\Windows\SysWOW64\のほうに入れるこはできましたが
依存 .DLL ファイルに問題がある、っぽいエラーがでてダメでした
何かを持ってきたり頑張れば使えるようになるのか、どうやっても無理なのかだけでも知りたいのですが
さすがに今使ってる人はいないとjは思うんですが
古い32ビットのDLLなので難しいかとは思うもですが
XPで使っていて自分にはこれで十分な機能だったので
使えるのならコードも流用できるので使いたいのです
C:\Windows\System32\ にはレジスト出来ず、調べたところC:\Windows\SysWOW64\のほうに入れるこはできましたが
依存 .DLL ファイルに問題がある、っぽいエラーがでてダメでした
何かを持ってきたり頑張れば使えるようになるのか、どうやっても無理なのかだけでも知りたいのですが
さすがに今使ってる人はいないとjは思うんですが
679デフォルトの名無しさん
2018/12/11(火) 14:12:20.06ID:TJahXBH3 + JavaScript の質問用スレッド vol.126 +
680デフォルトの名無しさん
2018/12/11(火) 22:02:27.12ID:4Gwy4fqu681678
2018/12/12(水) 21:56:56.08ID:4T7y3Eos まずスレチすいませんでした
こういうのをどこで質問していいかわからず、もし使ったことのある人がいるならこのスレかなと思いここにしてしまいました
どうにか解決したので報告だけさせてください
>>680
すごくヒントになりました
結局dllは不足なかったことがわかり不思議でよく考えてみたところ
wscriptのほうもSystem32のものではなく、SysWOW64の32ビットのものを指定して実行したところ問題なく使うことができました
わかってみたら単純なことでしたが思いこんでました
ありがとういございました
こういうのをどこで質問していいかわからず、もし使ったことのある人がいるならこのスレかなと思いここにしてしまいました
どうにか解決したので報告だけさせてください
>>680
すごくヒントになりました
結局dllは不足なかったことがわかり不思議でよく考えてみたところ
wscriptのほうもSystem32のものではなく、SysWOW64の32ビットのものを指定して実行したところ問題なく使うことができました
わかってみたら単純なことでしたが思いこんでました
ありがとういございました
682680
2018/12/13(木) 03:26:42.51ID:gvmz4tGp683デフォルトの名無しさん
2018/12/14(金) 21:27:47.36ID:RXUkcmUO JavaScriptの非同期の書き方がまだおぼつかないのですが
var defarr = [];
for(x of list) {
var d = new $.Deferred();
$ajax(...)
.done(() => { d.resolve() });
defarr.push(d.promise());
});
return $.when.apply($,defarr);
みたいな感じでAPIからデータをとってきて画面に非同期で順番に表示する
みたいな処理があるときに
途中で中断したいときどこにどういうコードをはさめばいいんでしょうか
var defarr = [];
for(x of list) {
var d = new $.Deferred();
$ajax(...)
.done(() => { d.resolve() });
defarr.push(d.promise());
});
return $.when.apply($,defarr);
みたいな感じでAPIからデータをとってきて画面に非同期で順番に表示する
みたいな処理があるときに
途中で中断したいときどこにどういうコードをはさめばいいんでしょうか
684デフォルトの名無しさん
2018/12/16(日) 20:50:25.64ID:Ihsud1U9 中断の伝播とか真剣にやってるとやっぱり複雑になってきたときにバグるよ
手抜きして要素を非表示にしたりメインツリーから消したりして
表示までの処理は動いてるけど機能しない状態にするのが一番お手軽で安全
手抜きして要素を非表示にしたりメインツリーから消したりして
表示までの処理は動いてるけど機能しない状態にするのが一番お手軽で安全
685デフォルトの名無しさん
2018/12/16(日) 21:00:20.73ID:PZR245oq requreを使っているfile.jsライブラリファイルをインポートできなくて困っています。
file.js内には「func」という関数が定義されていて
これをインポート先で呼び出したいとします。
ただし「file.js」内部にはrequireが使われていて
これに失敗します。
.htmlファイルから
scriptタグのsrc属性で読み出す。
普通なら 「file.func()」で関数を呼び出せる
のですが、
requireが失敗するためにfile.jsをbrowserify
で変換しました。
変換後はrequireが使えるようになりますが
変換の影響でfile.js内部のコードが変なコードで
囲まれて内部で定義されている関数「func」
がインポート先から見つけられなくなってしまいます。
requireを内部で使っているファイルを
.htmlのscript src属性でファイルパスで読み込んで
内部の関数を呼び出すにはどうしたらいいでしょうか?
file.js内には「func」という関数が定義されていて
これをインポート先で呼び出したいとします。
ただし「file.js」内部にはrequireが使われていて
これに失敗します。
.htmlファイルから
scriptタグのsrc属性で読み出す。
普通なら 「file.func()」で関数を呼び出せる
のですが、
requireが失敗するためにfile.jsをbrowserify
で変換しました。
変換後はrequireが使えるようになりますが
変換の影響でfile.js内部のコードが変なコードで
囲まれて内部で定義されている関数「func」
がインポート先から見つけられなくなってしまいます。
requireを内部で使っているファイルを
.htmlのscript src属性でファイルパスで読み込んで
内部の関数を呼び出すにはどうしたらいいでしょうか?
686デフォルトの名無しさん
2018/12/16(日) 21:19:05.88ID:sSyo+mRg ライブラリLAB.jsの質問
script src="LAB.js" で読み込んだあとで
$LAB
.script("jquery.js").wait()
.script("jquery.ui.js")
.script("jquery.lightbox.js")
.wait(function() {
$(document).ready(function() {
$('#gallary').lightbox();
});
});
とすると実行されるのですが、
htmlにscript src="LAB.js" を書かずに
下記にあるように、LABjsを動的に読み込むと
$LABが未定義ってなるのですが、
このように〜.jsを動的に読み込んだ後ってどうすればコードが
動くのでしょうか?
load LABjs itself dynamically!
ttps://gist.github.com/getify/603980
script src="LAB.js" で読み込んだあとで
$LAB
.script("jquery.js").wait()
.script("jquery.ui.js")
.script("jquery.lightbox.js")
.wait(function() {
$(document).ready(function() {
$('#gallary').lightbox();
});
});
とすると実行されるのですが、
htmlにscript src="LAB.js" を書かずに
下記にあるように、LABjsを動的に読み込むと
$LABが未定義ってなるのですが、
このように〜.jsを動的に読み込んだ後ってどうすればコードが
動くのでしょうか?
load LABjs itself dynamically!
ttps://gist.github.com/getify/603980
687デフォルトの名無しさん
2018/12/16(日) 21:39:52.63ID:hQcn4k02688デフォルトの名無しさん
2018/12/16(日) 22:18:46.36ID:sSyo+mRg >>687
document.onreadystatechange = function() {
if (document.readyState == "complete") {
$LAB (以下略)
}
}
ありがとうございました。これで動きました。
document.onreadystatechange = function() {
if (document.readyState == "complete") {
$LAB (以下略)
}
}
ありがとうございました。これで動きました。
689デフォルトの名無しさん
2018/12/17(月) 11:44:23.10ID:a8xIU8gO これほど書き方が統一されていない言語あるかね?
function書くだけなのにいくつもパターンありすぎ
function書くだけなのにいくつもパターンありすぎ
690デフォルトの名無しさん
2018/12/17(月) 11:48:12.21ID:CbYGITFN python行けば?誰も止めないよ
691デフォルトの名無しさん
2018/12/17(月) 13:51:26.97ID:5b5zFVKa pythonは関数を書くときにdefとlambdaがある
692デフォルトの名無しさん
2018/12/17(月) 17:37:22.98ID:hwQSpcEY つまり未だにアロー記法を採用してくれないPHP最強ってことだな
何回function書かせるねん
何回function書かせるねん
693デフォルトの名無しさん
2018/12/17(月) 17:48:18.50ID:ZJ97yaAm 打つのが面倒でないならjavascriptでも全部functionで通してもええんやで。
所詮(function () {}).bind(this)の糖衣構文に過ぎない。
所詮(function () {}).bind(this)の糖衣構文に過ぎない。
694デフォルトの名無しさん
2018/12/17(月) 18:28:11.97ID:qj8qNOmK 入力補完でfunctionを打つのは楽だから、基本はfunction使う
アローより可読性高いから
ワンラインで済むときと、thisを受け継ぎたい時だけアロー使う
アローより可読性高いから
ワンラインで済むときと、thisを受け継ぎたい時だけアロー使う
695デフォルトの名無しさん
2018/12/17(月) 18:44:46.88ID:9ZuiQDAU mapとかfilterの引数もfunction渡すの?
複数行あるならともかく、一行で済むものにわざわざfunctionとreturn書くのは、可読性の観点だと逆効果のような
複数行あるならともかく、一行で済むものにわざわざfunctionとreturn書くのは、可読性の観点だと逆効果のような
696デフォルトの名無しさん
2018/12/17(月) 18:58:59.52ID:ZJ97yaAm697デフォルトの名無しさん
2018/12/17(月) 21:20:06.41ID:lO+98ZHR > 所詮(function () {}).bind(this)の糖衣構文に過ぎない。
糖衣構文って素晴らしいよね
糖衣構文って素晴らしいよね
698デフォルトの名無しさん
2018/12/17(月) 22:29:47.87ID:ZJ97yaAm 念のため、素晴らしくないとは言ってないからな。
functionでも書けるから、そうしたいならどうぞご勝手に、という話。
functionでも書けるから、そうしたいならどうぞご勝手に、という話。
699デフォルトの名無しさん
2018/12/18(火) 14:54:48.45ID:LIt8HoLP アロー使ったら複数行でもreturnなしにしてほしい
最後の行の値を返せばいいだけと思うけど、難しいのかな
最後の行の値を返せばいいだけと思うけど、難しいのかな
700デフォルトの名無しさん
2018/12/18(火) 15:53:26.83ID:Y4LQpz29 () => (
,
,
,
)
どうぞ。
,
,
,
)
どうぞ。
701デフォルトの名無しさん
2018/12/18(火) 17:10:59.06ID:DOEC5j1K むしろアロー関数は1行でしか使えないようにしてほしいくらいだ
702デフォルトの名無しさん
2018/12/18(火) 18:43:12.10ID:G1V4hdx+ yield 文って、generator function から呼び出された普通の関数の
中で使うとどうなる?
エラーになるか、それとも、あたかも、親の generator function
の中から yield 文が実行されたかのように動作するかどちら?
書き方は間違ってるかもしれないけど、こんな感じの事やったらどうなる?
function *func1() {
yield 1;
func2();
yield 3;
}
function func2() {
yield 2;
}
console.log( func1().next() );
console.log( func1().next() );
console.log( func1().next() );
中で使うとどうなる?
エラーになるか、それとも、あたかも、親の generator function
の中から yield 文が実行されたかのように動作するかどちら?
書き方は間違ってるかもしれないけど、こんな感じの事やったらどうなる?
function *func1() {
yield 1;
func2();
yield 3;
}
function func2() {
yield 2;
}
console.log( func1().next() );
console.log( func1().next() );
console.log( func1().next() );
703デフォルトの名無しさん
2018/12/18(火) 18:52:16.34ID:owoWX2Rf エラーになるかどうか知りたいの?
コンソールに張り付けろよ
コンソールに張り付けろよ
704デフォルトの名無しさん
2018/12/18(火) 19:07:53.94ID:G1V4hdx+ var aaa = func1;
console.log( aaa.next() );
・・・
みたいに修正してから、やってみたら func2() 内の yield でエラーが出た。
console.log( aaa.next() );
・・・
みたいに修正してから、やってみたら func2() 内の yield でエラーが出た。
705デフォルトの名無しさん
2018/12/18(火) 19:08:58.50ID:G1V4hdx+ >>703
そんな方法があったとは・・・
そんな方法があったとは・・・
706デフォルトの名無しさん
2018/12/18(火) 19:31:11.55ID:owoWX2Rf function* func1() {
yield 1;
yield* func2();
yield 3;
}
function* func2() {
yield 2;
}
俺のESP能力が高ければこれが助けになるだろう。
yield 1;
yield* func2();
yield 3;
}
function* func2() {
yield 2;
}
俺のESP能力が高ければこれが助けになるだろう。
707デフォルトの名無しさん
2018/12/18(火) 19:42:52.51ID:G1V4hdx+ >>706
それだと、func2() も generator function になるよね。
自分が思っていたのは、もし、普通の関数でも
yield が使えれば、JS でも、SetEvent() と WaitForSingleObject()
みたいな同期オブジェクトを作れるんじゃないかということだった。
そうすれば、wasm を使って、Windows プログラムも移植できるの
ではないかと思った。
それだと、func2() も generator function になるよね。
自分が思っていたのは、もし、普通の関数でも
yield が使えれば、JS でも、SetEvent() と WaitForSingleObject()
みたいな同期オブジェクトを作れるんじゃないかということだった。
そうすれば、wasm を使って、Windows プログラムも移植できるの
ではないかと思った。
708デフォルトの名無しさん
2018/12/18(火) 20:07:42.22ID:GicIxRpF >>707
それは何の為に?
WebAssembly(wasm)なら移植の必要すらなく動かせる(はず)だろ。
それ以前にGraalVMなんてのも出てきたみたいだが。
> JavaScriptだけでなくあらゆる言語をブラウザで扱えるように、GraalVMをChromiumにリンクすることを考えた学生が1人います。
> https://www.infoq.com/jp/news/2018/05/oracle-graalvm-v1
>>705
インタプリタがある言語(≒スクリプト言語)なら通常のデバッグ方法だ。
それは何の為に?
WebAssembly(wasm)なら移植の必要すらなく動かせる(はず)だろ。
それ以前にGraalVMなんてのも出てきたみたいだが。
> JavaScriptだけでなくあらゆる言語をブラウザで扱えるように、GraalVMをChromiumにリンクすることを考えた学生が1人います。
> https://www.infoq.com/jp/news/2018/05/oracle-graalvm-v1
>>705
インタプリタがある言語(≒スクリプト言語)なら通常のデバッグ方法だ。
709デフォルトの名無しさん
2018/12/18(火) 21:15:58.80ID:ZUOAn4Wo >>707
普通の関数でyieldが使えてもそれはジェネレータ関数ができること以上のことができるようにならないだろう
結局処理は同期的で待ち合わせには使えないのだから
async関数でというのなら分かるがそれはもうasync generatorがある
普通の関数でyieldが使えてもそれはジェネレータ関数ができること以上のことができるようにならないだろう
結局処理は同期的で待ち合わせには使えないのだから
async関数でというのなら分かるがそれはもうasync generatorがある
710デフォルトの名無しさん
2018/12/18(火) 23:58:38.14ID:TqbWLs2l やっぱ、数学ができない人にはわからないんだと思う。
ちなみにおいらは数学は主席。
今のwasmは、sleepはできるが、SetEventやMutex などを
待つことができないので、
>WebAssembly(wasm)なら移植の必要すらなく動かせる(はず)だろ。
これは違う。
すまんが、何度説明しても分からん人には分からん。
日本語の問題ではない。句読点の問題でもない。数学の問題なんだ。
ちなみにおいらは数学は主席。
今のwasmは、sleepはできるが、SetEventやMutex などを
待つことができないので、
>WebAssembly(wasm)なら移植の必要すらなく動かせる(はず)だろ。
これは違う。
すまんが、何度説明しても分からん人には分からん。
日本語の問題ではない。句読点の問題でもない。数学の問題なんだ。
711デフォルトの名無しさん
2018/12/19(水) 00:02:06.41ID:H4njPJ7X ああ、この前の数学君か
元気だな、頑張れ
元気だな、頑張れ
712デフォルトの名無しさん
2018/12/19(水) 06:35:13.60ID:Ujgti5e8 WASMはもう実験的にSABとAtomicsサポートしてるでしょ
何を知ったげに言ってるんだか
何を知ったげに言ってるんだか
713デフォルトの名無しさん
2018/12/19(水) 08:43:58.69ID:kJYKyqgv 数学くんは虚学の悪いとこ取りしたような人だね。
714デフォルトの名無しさん
2018/12/19(水) 09:41:58.49ID:Yvire5cb >>712
wasm は、emscripten_sleep(millisecond) をサポートしてるので、もともと問題の根は浅い。
でもあなたの言ってることはSetEvent()やMutex()などの同期オブジェクトとは直接関係
ない。それに proposal 段階で、実装報告は見当たらないんじゃないの。
wasm は、emscripten_sleep(millisecond) をサポートしてるので、もともと問題の根は浅い。
でもあなたの言ってることはSetEvent()やMutex()などの同期オブジェクトとは直接関係
ない。それに proposal 段階で、実装報告は見当たらないんじゃないの。
715デフォルトの名無しさん
2018/12/19(水) 10:08:12.65ID:Yvire5cb 【数学首席のオイラが書く(言葉の美しさは知らん)】
atomic fence は、二つのスレッドが同時に読み書きすることを防ぐ目的で使うもの。
たとえば、グローバル変数 a に「1足す」場合、CPUは、それをいったん(内部)
レジスタなどに読み取ってから、1足し、最後に同じグローバル変数 a に書き戻す。
この際、二つのスレッドがほぼ同時に「読んで」しまった場合、合計で「2」を足して欲しいのに、「1」しか足されなくなってしまう。それを防ぐために、ある同時に「読む」ことすら防ぐフェンスのようなものを用意するためのもの。だから、専用APIとして、
InterlockedIncrement() があったり、CPU自体にもマシン語レベルでLOCK修飾なるもの
があったりする。
一方、SetEvent() などのイベント発生を「待つ」ことは、この仕組みだけでは不十分で、
次のような単純なやり方では CPU がフルパワー状態になり、電力の無駄使いになる。
ちなみに、このように (HLT 命令を使っていない) BUSY LOOP では、CPU の 電力消費
が何十倍にもなることがある(だから、sleep()命令は特殊な実装を行ってる)。:
ATOMIC_FENC g_fence;
BOOL g_bEvnet = 0;
void mySetEvent() // スレッドBが使うとする。
{
g_bEvent = 1;
}
void myWaitForEvent() // スレッドAが使うとする。
{
// 以下ループで、CPUがフルパワー状態になり電気の無駄使いになる:
for ( ;; ) {
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
if ( !g_bEvent ) {
g_bEvent = 0;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
break;
}
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
}
atomic fence は、二つのスレッドが同時に読み書きすることを防ぐ目的で使うもの。
たとえば、グローバル変数 a に「1足す」場合、CPUは、それをいったん(内部)
レジスタなどに読み取ってから、1足し、最後に同じグローバル変数 a に書き戻す。
この際、二つのスレッドがほぼ同時に「読んで」しまった場合、合計で「2」を足して欲しいのに、「1」しか足されなくなってしまう。それを防ぐために、ある同時に「読む」ことすら防ぐフェンスのようなものを用意するためのもの。だから、専用APIとして、
InterlockedIncrement() があったり、CPU自体にもマシン語レベルでLOCK修飾なるもの
があったりする。
一方、SetEvent() などのイベント発生を「待つ」ことは、この仕組みだけでは不十分で、
次のような単純なやり方では CPU がフルパワー状態になり、電力の無駄使いになる。
ちなみに、このように (HLT 命令を使っていない) BUSY LOOP では、CPU の 電力消費
が何十倍にもなることがある(だから、sleep()命令は特殊な実装を行ってる)。:
ATOMIC_FENC g_fence;
BOOL g_bEvnet = 0;
void mySetEvent() // スレッドBが使うとする。
{
g_bEvent = 1;
}
void myWaitForEvent() // スレッドAが使うとする。
{
// 以下ループで、CPUがフルパワー状態になり電気の無駄使いになる:
for ( ;; ) {
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
if ( !g_bEvent ) {
g_bEvent = 0;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
break;
}
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
}
716デフォルトの名無しさん
2018/12/19(水) 10:09:02.19ID:Yvire5cb >>715
[続き]
そこで今度は、myWaitForEvent()のループを次のように書き換えたとする:
for ( ;; ) {
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
if ( !g_bEvent ) {
g_bEvent = 0;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
sleep(100); // 100(ms) 待つ。
break;
}
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
この場合は、電力消費はかなり抑制されるが、スレッドBで mySetEvent()が呼ばれて
から、スレッドAのmyWaitForEvent()がそれを知って、ループから脱出するまでに、
最悪100(ms)の遅延が発生してしまう。だから、OSは、WaitForSingleObject() API
などの専用の同期メカニズムを用意しなくてはならない。Emscriptenにはまだそれ
が整備されていない。
[続き]
そこで今度は、myWaitForEvent()のループを次のように書き換えたとする:
for ( ;; ) {
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
if ( !g_bEvent ) {
g_bEvent = 0;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
sleep(100); // 100(ms) 待つ。
break;
}
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
この場合は、電力消費はかなり抑制されるが、スレッドBで mySetEvent()が呼ばれて
から、スレッドAのmyWaitForEvent()がそれを知って、ループから脱出するまでに、
最悪100(ms)の遅延が発生してしまう。だから、OSは、WaitForSingleObject() API
などの専用の同期メカニズムを用意しなくてはならない。Emscriptenにはまだそれ
が整備されていない。
717デフォルトの名無しさん
2018/12/19(水) 10:11:23.08ID:Yvire5cb >>715
【修正】
void mySetEvent() // スレッドBが使うとする。
{
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
g_bEvent = 1;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
【修正】
void mySetEvent() // スレッドBが使うとする。
{
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
g_bEvent = 1;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
718デフォルトの名無しさん
2018/12/19(水) 10:12:13.28ID:Yvire5cb719デフォルトの名無しさん
2018/12/19(水) 10:14:39.02ID:Yvire5cb >>715
【sleep()を使う場合の最もましなコード】
(それでもどうしても遅延が発生する。)
void mySetEvent() // スレッドBが使うとする。
{
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
g_bEvent = 1;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
void myWaitForEvent() // スレッドAが使うとする。
{
// 以下ループで、CPUがフルパワー状態になり電気の無駄使いになる:
for ( ;; ) {
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
if ( g_bEvent ) {
g_bEvent = 0;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
sleep(100); // 100(ms) 待つ。
break;
}
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
}
【sleep()を使う場合の最もましなコード】
(それでもどうしても遅延が発生する。)
void mySetEvent() // スレッドBが使うとする。
{
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
g_bEvent = 1;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
void myWaitForEvent() // スレッドAが使うとする。
{
// 以下ループで、CPUがフルパワー状態になり電気の無駄使いになる:
for ( ;; ) {
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
if ( g_bEvent ) {
g_bEvent = 0;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
sleep(100); // 100(ms) 待つ。
break;
}
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
}
}
720デフォルトの名無しさん
2018/12/19(水) 10:15:59.44ID:Yvire5cb721デフォルトの名無しさん
2018/12/19(水) 10:17:28.95ID:Yvire5cb >>719
【再修正】
void myWaitForEvent() // スレッドAが使うとする。
{
// 以下ループで、最悪100(ms)の遅延が発生する。
for ( ;; ) {
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
if ( g_bEvent ) {
g_bEvent = 0;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
break;
}
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
sleep(100); // 100(ms) 待つ。
}
}
【再修正】
void myWaitForEvent() // スレッドAが使うとする。
{
// 以下ループで、最悪100(ms)の遅延が発生する。
for ( ;; ) {
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
if ( g_bEvent ) {
g_bEvent = 0;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
break;
}
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
sleep(100); // 100(ms) 待つ。
}
}
722デフォルトの名無しさん
2018/12/19(水) 10:46:30.85ID:YX/OcQwS いや、もうAtomicsAPIがChromeでオリジントライアルで使えるでしょ
もう解決してる問題に対して何をイキっちゃってんの
いくら数学の理論構成や計算ができようと意味はないよ
そんなのは機械でできることだから
正しい問題と前提を認識できて初めて数学という道具は有益に使えるんだから
君がやってるのはただ思考力の無駄遣い
まあ君の頭だからどう無駄に使おうと勝手だけど、スレ汚しは勘弁してね
もう解決してる問題に対して何をイキっちゃってんの
いくら数学の理論構成や計算ができようと意味はないよ
そんなのは機械でできることだから
正しい問題と前提を認識できて初めて数学という道具は有益に使えるんだから
君がやってるのはただ思考力の無駄遣い
まあ君の頭だからどう無駄に使おうと勝手だけど、スレ汚しは勘弁してね
723デフォルトの名無しさん
2018/12/19(水) 13:13:50.30ID:Yvire5cb >>722
なるほど、Atomics の wait() と notify() の事か:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics/wait
分かった、すまんかった。
しかし、海外のサイトを検索しても、この関数のことは一切発見することが出来なかったんだよ。
await や async や、その他の便利ラッパクラスみたいなものより、こっちの関数の方が重要だ。
初見だが、多分、notify() と wait() が、Win32API の SetEvent() と WaitForSingleObject() に大体
対応していて、それがあればスレッドの同期に関してはほとんどの用途では足りると思う。
効率の良い(電気もCPUパワーも無駄にしない) sleep() もこれらを使えば実装できてしまうだろう。
なるほど、Atomics の wait() と notify() の事か:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics/wait
分かった、すまんかった。
しかし、海外のサイトを検索しても、この関数のことは一切発見することが出来なかったんだよ。
await や async や、その他の便利ラッパクラスみたいなものより、こっちの関数の方が重要だ。
初見だが、多分、notify() と wait() が、Win32API の SetEvent() と WaitForSingleObject() に大体
対応していて、それがあればスレッドの同期に関してはほとんどの用途では足りると思う。
効率の良い(電気もCPUパワーも無駄にしない) sleep() もこれらを使えば実装できてしまうだろう。
724デフォルトの名無しさん
2018/12/19(水) 14:57:22.19ID:kJYKyqgv またWindowsのAPIに固執してるの?
いい加減に理解しなよ。Windowsとwebは無関係だって。
いい加減に理解しなよ。Windowsとwebは無関係だって。
725デフォルトの名無しさん
2018/12/19(水) 17:02:01.51ID:Yvire5cb マルチプラットフォーム環境として、wasm や JVM や CrossBrdige(FlashCC) など
を調査してるから、Windowsアプリが移植できるかどうかに興味があるんだ。
を調査してるから、Windowsアプリが移植できるかどうかに興味があるんだ。
726デフォルトの名無しさん
2018/12/19(水) 20:13:23.94ID:kJYKyqgv Windowsアプリが移植できるかと、同じAPIを持ってる事は無関係だし、
事実同じAPIも持ってないよね。
なのに見立てる理由がわかんない。
事実同じAPIも持ってないよね。
なのに見立てる理由がわかんない。
727デフォルトの名無しさん
2018/12/19(水) 21:13:53.09ID:Ujgti5e8 基本的にLLVMに変換可能なプログラムなら移植できるけど
OS特有のAPIやライブラリ使ってちゃそりゃそのまま移植できるはずがない
OS特有のAPIやライブラリ使ってちゃそりゃそのまま移植できるはずがない
728デフォルトの名無しさん
2018/12/20(木) 01:35:15.77ID:Gok/GJGq だからそれをやっちゃおうかな、っちゅう話ですわ。
729デフォルトの名無しさん
2018/12/20(木) 08:29:03.69ID:uRkd43kp やっちゃおう、にどれだけ価値があるかわからんけどね。
そこまで言うなら、前回のIMEだって、やっぱりIMEを移植すべき問題じゃん。
同じAPI使うってのは、wasmでのWin32API互換ライブラリを作るって夢を語ってるって事なのかな?
簡単な道ではないと思うけど。
WINE何年かかってんよって話。
そこまで言うなら、前回のIMEだって、やっぱりIMEを移植すべき問題じゃん。
同じAPI使うってのは、wasmでのWin32API互換ライブラリを作るって夢を語ってるって事なのかな?
簡単な道ではないと思うけど。
WINE何年かかってんよって話。
730デフォルトの名無しさん
2018/12/20(木) 12:51:09.87ID:y+eXSBvj WasmでというよりJSででしょ
現状Web API叩くのはJSからしかできないのだから
現状Web API叩くのはJSからしかできないのだから
731デフォルトの名無しさん
2018/12/21(金) 02:52:57.38ID:7eLtsaJR foo =function(){}とか
bar = ()=>{} とか
エディタがDocコメ認識してくれないことが多くてなあ…
bar = ()=>{} とか
エディタがDocコメ認識してくれないことが多くてなあ…
732デフォルトの名無しさん
2018/12/21(金) 03:02:08.56ID:pse73zvs jsdocって言語機能が名前から想像するよりはるかに異なるjava用のjavadocの単なるメクラポーティングだしなぁ…
js用にもっと相応しいドキュメント仕様が普及してもよかっただろうに世の中うまくいかんのう…
js用にもっと相応しいドキュメント仕様が普及してもよかっただろうに世の中うまくいかんのう…
733デフォルトの名無しさん
2018/12/23(日) 03:20:59.12ID:UYmMiioW iframe要素のsrcを変更したら画像のロードが終了してからloadが発火すると思うんだけど
この間(画像のロードしてる間)にiframeのHTMLにcss挿入するのってどうしたらいい?
この間(画像のロードしてる間)にiframeのHTMLにcss挿入するのってどうしたらいい?
734デフォルトの名無しさん
2018/12/23(日) 03:32:31.98ID:yUjQiXy1 へけっ
735デフォルトの名無しさん
2018/12/23(日) 18:55:55.79ID:Wgmswpxd >>733
src を変える前に iframe の style 属性を指定しておくのでダメであれば、
別に、タイマーイベントみたいなので、少し遅れてから、イベントハンドラ
の中から iframe の style 属性を変えればいいだけではないの。
src を変える前に iframe の style 属性を指定しておくのでダメであれば、
別に、タイマーイベントみたいなので、少し遅れてから、イベントハンドラ
の中から iframe の style 属性を変えればいいだけではないの。
736デフォルトの名無しさん
2018/12/23(日) 20:07:18.83ID:yUjQiXy1 だめやろうなぁ
737デフォルトの名無しさん
2018/12/24(月) 02:47:05.59ID:oR/7w3yW エクセルのマクロとかすら使ったことがないし
数学も超苦手なのですが
プログラムを始めてみたくてウズウズしてます。
仕事で使ってる動画ソフトが
javascriptでスクリプトを追加できるので
java scriptをはじめてのプログラムとして始めてみたいのですが
何から揃えればよいのでしょうか?
数学も超苦手なのですが
プログラムを始めてみたくてウズウズしてます。
仕事で使ってる動画ソフトが
javascriptでスクリプトを追加できるので
java scriptをはじめてのプログラムとして始めてみたいのですが
何から揃えればよいのでしょうか?
738デフォルトの名無しさん
2018/12/24(月) 05:38:37.54ID:zcolqab1 ブラウザ
739デフォルトの名無しさん
2018/12/24(月) 12:33:43.31ID:67lBbMM7740デフォルトの名無しさん
2018/12/24(月) 16:16:56.97ID:Vnn2/Eqf 知識0なのに実用的なプログラムから始めるのは間違っている
HTMLを学んでてそこに動きを付けたいとかいう段階的な目的とステップがあるなら別だけど
マクロとしてのJSを学びたいのにWebに手を出すというのは無理筋
基本的に勉強用の非実用言語環境でできれば配列くらいの知識まで身につけといてから
Webとか手を出さないで直接マクロに行かないと絶対に挫折する
HTMLを学んでてそこに動きを付けたいとかいう段階的な目的とステップがあるなら別だけど
マクロとしてのJSを学びたいのにWebに手を出すというのは無理筋
基本的に勉強用の非実用言語環境でできれば配列くらいの知識まで身につけといてから
Webとか手を出さないで直接マクロに行かないと絶対に挫折する
741デフォルトの名無しさん
2018/12/24(月) 18:15:32.52ID:9l1J7bMi マクロとしてのJSって何だよ・・・・
やりたいこととしてはブラウザよりNodeの方が向いているとは思うが
やりたいこととしてはブラウザよりNodeの方が向いているとは思うが
742デフォルトの名無しさん
2018/12/24(月) 18:21:49.02ID:Vnn2/Eqf いや、もうやりたいことは決まってるでしょ
いくら比較的余計な知識が要らないとは言え
NodeでのJS入門環境が充実してるわけでもないのに
いくら比較的余計な知識が要らないとは言え
NodeでのJS入門環境が充実してるわけでもないのに
743デフォルトの名無しさん
2018/12/24(月) 20:00:11.14ID:BJHgzAj7 webpackで依存関係が数百とかなってわけがわからなくなる
744737
2018/12/24(月) 23:14:29.77ID:oR/7w3yW みなさんありがとうございます。
「なにかゲームしたい」くらいな感覚でプログラムをやってみたいと思ってました。
必要に迫られて始めたいわけではなくて
暇なときにテトリスする代わりに
クネクネ動くhello worldを作ったり
自分で使うようのアプリとか作れたら楽しそうだなと思った次第でした。
今は小さくて安い小型パソコンがたくさんあるのでそういうパソコンで
暇な時にシコシコプログラム作れたら
すごく楽しいんじゃないかと
ついでにJs覚えれば仕事の動画編集にも活かせそうだしなんか良いかなみたいな感覚でした。
htmlもかじってみようと思います。
「なにかゲームしたい」くらいな感覚でプログラムをやってみたいと思ってました。
必要に迫られて始めたいわけではなくて
暇なときにテトリスする代わりに
クネクネ動くhello worldを作ったり
自分で使うようのアプリとか作れたら楽しそうだなと思った次第でした。
今は小さくて安い小型パソコンがたくさんあるのでそういうパソコンで
暇な時にシコシコプログラム作れたら
すごく楽しいんじゃないかと
ついでにJs覚えれば仕事の動画編集にも活かせそうだしなんか良いかなみたいな感覚でした。
htmlもかじってみようと思います。
745デフォルトの名無しさん
2018/12/25(火) 06:55:27.86ID:NrxUWHxX >>738
グリフィンドールに10点!!
グリフィンドールに10点!!
746デフォルトの名無しさん
2018/12/28(金) 09:59:07.54ID:7xgXna2y MSDNからMDNにとばされるんだけど…
747デフォルトの名無しさん
2018/12/28(金) 12:22:40.64ID:CNCn0lYj 統合されたんだから当たり前じゃん
748デフォルトの名無しさん
2018/12/28(金) 22:17:34.14ID:6Xnlajxx Excelの表をGraphqlに変換することは出来ますか?
749デフォルトの名無しさん
2018/12/28(金) 22:18:40.05ID:6Xnlajxx750デフォルトの名無しさん
2018/12/28(金) 22:35:42.83ID:g72FtTfN 質問です。下記のようなプログラムで、'テスト'をhoge内に記載する場合は
どのようにすればいいでしょうか?
const hoge = {
hoge1:'hogehoge1',
hoge2:'hogehoge2'
};
console.log(hoge.hoge1 + 'テスト')
イメージ的にはこんな感じにしたいです
const hoge = {
hoge1:'hogehoge1',
hoge2:'hogehoge2'
(hoge1+テスト)
};
console.log(hoge.hoge1)
結果:hogehoge1テスト
どのようにすればいいでしょうか?
const hoge = {
hoge1:'hogehoge1',
hoge2:'hogehoge2'
};
console.log(hoge.hoge1 + 'テスト')
イメージ的にはこんな感じにしたいです
const hoge = {
hoge1:'hogehoge1',
hoge2:'hogehoge2'
(hoge1+テスト)
};
console.log(hoge.hoge1)
結果:hogehoge1テスト
751デフォルトの名無しさん
2018/12/28(金) 23:15:33.48ID:8m6KRjls const hoge = {
hoge1:'hogehoge1'
+'テスト',
hoge2:'hogehoge2'
};
hoge1:'hogehoge1'
+'テスト',
hoge2:'hogehoge2'
};
752デフォルトの名無しさん
2018/12/28(金) 23:57:17.21ID:+Hytqb0t >>748
gatsby-transformer-excelあったと思う
gatsby-transformer-excelあったと思う
753デフォルトの名無しさん
2018/12/29(土) 09:01:54.50ID:OV3vXkdP >>746-747
メソッド一覧とかプロパティ一覧、関数一覧のページはMSDNのほうが見やすかったから
索引的なページは残しておいてほしかった
エディタのマクロ書くときなんかはMSDNのほうが都合よかったので残念
メソッド一覧とかプロパティ一覧、関数一覧のページはMSDNのほうが見やすかったから
索引的なページは残しておいてほしかった
エディタのマクロ書くときなんかはMSDNのほうが都合よかったので残念
754デフォルトの名無しさん
2018/12/29(土) 10:27:57.06ID:X90mX2aj MDNに文句を言いましょう
755デフォルトの名無しさん
2018/12/31(月) 00:10:35.03ID:c5mCkIDs Electronでクロスプラットフォームのアプリ開発の出来ることを知ったプログラミング初心者ですが、一般的なElectronの開発はVue.jsやReact.jsを併用するのでしょうか?
756デフォルトの名無しさん
2018/12/31(月) 12:44:57.49ID:ub+ffh8E 好きなようにすりゃいいんだよ。なんだよ一般的て
757デフォルトの名無しさん
2019/01/01(火) 14:16:52.62ID:venw+ri0 もうElectronは古い
今からはできる限りPWAでやる風潮
今からはできる限りPWAでやる風潮
758デフォルトの名無しさん
2019/01/01(火) 17:49:09.57ID:MDjquhVw React学ぶのにオススメのチュートリアルや本ありますか?
759デフォルトの名無しさん
2019/01/01(火) 19:27:21.70ID:cA+NVdVY 本は薄い奴が今のところ比較的新しいけど、残念なことにそれでも情報が古いからGithubのreadmeとか見ないとダメ
その本に書かれているライブラリはもう開発停止していたりするから
ReactよりもReduxのほうが大変かもね
その本に書かれているライブラリはもう開発停止していたりするから
ReactよりもReduxのほうが大変かもね
760デフォルトの名無しさん
2019/01/01(火) 21:59:08.65ID:0nxjkBRM >>758
Q. ○○を学ぶのにオススメのチュートリアルや本ありますか?
A. 公式
JavaScript界隈の場合はほぼ全部これ。
公式読んで無理なら諦めた方がいいと思う。当然だが、
1. JavaScript界隈の場合は布教意識ありまくりで公式がかなり充実している。
2. 公式は対象技術レベルを想定して書かれている=読んで無理ならどうせ使いこなせない。
3. 公式以外は「ぼくががんばったきろく」を残したい馬鹿ばかりで、間違いが多すぎる。
4. そもそも普通の奴は「ぼくのさいこうのチュートリアル」なんて作らない。
公式のチュートリアルを充実させる方向に参加する。したがって当然非公式サイトはおしなべてゴミ。
5. 本を書いている奴は本で食っている=一線のプログラマではなくただのテクニカルライタであり、
売れない本は書きたくない。よってどうしても後追いになるし、技術レベルも低い。
6. JavaScriptの場合はフレームワークonフレームワークの状態だから、
はっきり言って、構想を聞いて「あ、いいね」とぱっと思えるのでなければ使う必要がない。
だから本来、対象者にはリファレンスしか必要ない。Nodeとかそんな感じでしょ。
というか、自分が知ってるフレームワーク等と比べてみたらいい。
例えばjQueryを使っている奴は公式トップの3例を見て、「素晴らしい」と思えるから使っているわけだろ。
Nodeの場合は公式トップは空で、aboutで鯖を立てる例だけ出しているが、魅力のアピールにはそれで十分なわけだろ。
同様に、reactの場合も公式トップの4例で十分だと思っているからあの構成な訳で、
それで魅力を感じないのであれば使う必要はないし、意味が分からないのなら使いこなせない。
Q. ○○を学ぶのにオススメのチュートリアルや本ありますか?
A. 公式
JavaScript界隈の場合はほぼ全部これ。
公式読んで無理なら諦めた方がいいと思う。当然だが、
1. JavaScript界隈の場合は布教意識ありまくりで公式がかなり充実している。
2. 公式は対象技術レベルを想定して書かれている=読んで無理ならどうせ使いこなせない。
3. 公式以外は「ぼくががんばったきろく」を残したい馬鹿ばかりで、間違いが多すぎる。
4. そもそも普通の奴は「ぼくのさいこうのチュートリアル」なんて作らない。
公式のチュートリアルを充実させる方向に参加する。したがって当然非公式サイトはおしなべてゴミ。
5. 本を書いている奴は本で食っている=一線のプログラマではなくただのテクニカルライタであり、
売れない本は書きたくない。よってどうしても後追いになるし、技術レベルも低い。
6. JavaScriptの場合はフレームワークonフレームワークの状態だから、
はっきり言って、構想を聞いて「あ、いいね」とぱっと思えるのでなければ使う必要がない。
だから本来、対象者にはリファレンスしか必要ない。Nodeとかそんな感じでしょ。
というか、自分が知ってるフレームワーク等と比べてみたらいい。
例えばjQueryを使っている奴は公式トップの3例を見て、「素晴らしい」と思えるから使っているわけだろ。
Nodeの場合は公式トップは空で、aboutで鯖を立てる例だけ出しているが、魅力のアピールにはそれで十分なわけだろ。
同様に、reactの場合も公式トップの4例で十分だと思っているからあの構成な訳で、
それで魅力を感じないのであれば使う必要はないし、意味が分からないのなら使いこなせない。
761デフォルトの名無しさん
2019/01/02(水) 03:56:07.95ID:2lhCREwi 「Reactを学ぶ」とかワケワカランな
スマホだってなんだって説明書見て使ってれば自分にとって十分使いこなせてるでしょ
「Reactのプロ」になる必要なんてないんだから
ただ道具の一つとして自然に使っていけばいいだけ
スマホだってなんだって説明書見て使ってれば自分にとって十分使いこなせてるでしょ
「Reactのプロ」になる必要なんてないんだから
ただ道具の一つとして自然に使っていけばいいだけ
762デフォルトの名無しさん
2019/01/02(水) 16:10:49.32ID:/JRa6BYE emscripten_sleep() の以下のソース、理解が出来ない。JSに不慣れだから余計。
誰か助けて欲しい。emscripten は、少なくとも asm.js 形式だと、JS から、
JS の emscripten_sleep() 関数を単純に呼び出している。
以下の、{{{・・・}}} の三重括弧や、callback の部分の意味が理解できない。
[x:\yyyy\emsdk\emscripten\1.38.21\src\library_async.js]
mergeInto(LibraryManager.library, {
#if ASYNCIFY
・・・
emscripten_async_resume: function() {
var callback = 0;
___async = 0;
___async_unwind = 1;
while (1) {
if (!___async_cur_frame) return;
callback = {{{ makeGetValueAsm('___async_cur_frame', 8, 'i32') }}};
// the signature of callback is always vi
// the only argument is ctx
{{{ makeDynCall('vi') }}}(callback | 0, (___async_cur_frame + 8)|0);
if (___async) return; // that was an async call
if (!___async_unwind) {
// keep the async stack
___async_unwind = 1;
continue;
}
// unwind normal stack frame
stackRestore({{{ makeGetValueAsm('___async_cur_frame', 4, 'i32') }}});
// pop the last async stack frame
___async_cur_frame = {{{ makeGetValueAsm('___async_cur_frame', 0, 'i32') }}};
}
},
誰か助けて欲しい。emscripten は、少なくとも asm.js 形式だと、JS から、
JS の emscripten_sleep() 関数を単純に呼び出している。
以下の、{{{・・・}}} の三重括弧や、callback の部分の意味が理解できない。
[x:\yyyy\emsdk\emscripten\1.38.21\src\library_async.js]
mergeInto(LibraryManager.library, {
#if ASYNCIFY
・・・
emscripten_async_resume: function() {
var callback = 0;
___async = 0;
___async_unwind = 1;
while (1) {
if (!___async_cur_frame) return;
callback = {{{ makeGetValueAsm('___async_cur_frame', 8, 'i32') }}};
// the signature of callback is always vi
// the only argument is ctx
{{{ makeDynCall('vi') }}}(callback | 0, (___async_cur_frame + 8)|0);
if (___async) return; // that was an async call
if (!___async_unwind) {
// keep the async stack
___async_unwind = 1;
continue;
}
// unwind normal stack frame
stackRestore({{{ makeGetValueAsm('___async_cur_frame', 4, 'i32') }}});
// pop the last async stack frame
___async_cur_frame = {{{ makeGetValueAsm('___async_cur_frame', 0, 'i32') }}};
}
},
763デフォルトの名無しさん
2019/01/02(水) 16:12:12.28ID:/JRa6BYE >>762
・・・
emscripten_sleep: function(ms) {
Module['setAsync'](); // tell the scheduler that we have a callback on hold
Browser.safeSetTimeout(_emscripten_async_resume, ms);
},
・・・
}
・・・
emscripten_sleep: function(ms) {
Module['setAsync'](); // tell the scheduler that we have a callback on hold
Browser.safeSetTimeout(_emscripten_async_resume, ms);
},
・・・
}
764デフォルトの名無しさん
2019/01/02(水) 16:28:37.28ID:/JRa6BYE 以下の前提がある時、
callback = {{{ makeGetValueAsm('___async_cur_frame', 8, 'i32') }}};
{{{ makeDynCall('vi') }}}(callback | 0, (___async_cur_frame + 8)|0);
の部分が、何を意味するのか分かる人いない?
---------------------------------------
var Module = {};
Module["asm"] = (function(global, env, buffer) {
"use asm";
var HEAP8 = new global.Int8Array(buffer);
var HEAP16 = new global.Int16Array(buffer);
var HEAP32 = new global.Int32Array(buffer);
var HEAPU8 = new global.Uint8Array(buffer);
・・・・
}
var dynCall_vi = Module["dynCall_vi"] = function() { return Module["asm"]["dynCall_vi"].apply(null, arguments) };
function makeDynCall(sig) {
if (!EMULATED_FUNCTION_POINTERS) {
return 'dynCall_' + sig;
} else {
return 'ftCall_' + sig;
}
}
callback = {{{ makeGetValueAsm('___async_cur_frame', 8, 'i32') }}};
{{{ makeDynCall('vi') }}}(callback | 0, (___async_cur_frame + 8)|0);
の部分が、何を意味するのか分かる人いない?
---------------------------------------
var Module = {};
Module["asm"] = (function(global, env, buffer) {
"use asm";
var HEAP8 = new global.Int8Array(buffer);
var HEAP16 = new global.Int16Array(buffer);
var HEAP32 = new global.Int32Array(buffer);
var HEAPU8 = new global.Uint8Array(buffer);
・・・・
}
var dynCall_vi = Module["dynCall_vi"] = function() { return Module["asm"]["dynCall_vi"].apply(null, arguments) };
function makeDynCall(sig) {
if (!EMULATED_FUNCTION_POINTERS) {
return 'dynCall_' + sig;
} else {
return 'ftCall_' + sig;
}
}
765デフォルトの名無しさん
2019/01/02(水) 16:46:37.75ID:+DxIoQKP 三重波括弧についてはEmscripten独自のマクロみたいだね
多分だけどビルド時に当該箇所が置換されるんだと思う
https://github.com/kripken/emscripten/blob/52479350e642453bf74ceca108fca8e1f43b30d5/src/parseTools.js#L11-L12
マクロ展開後がどうなるか分からないからこれ以上は分からない
多分だけどビルド時に当該箇所が置換されるんだと思う
https://github.com/kripken/emscripten/blob/52479350e642453bf74ceca108fca8e1f43b30d5/src/parseTools.js#L11-L12
マクロ展開後がどうなるか分からないからこれ以上は分からない
766デフォルトの名無しさん
2019/01/02(水) 18:09:44.66ID:/JRa6BYE [何をやってるかの自分なりの推定]
例えば、main() 関数の中で、emscripten_sleep(n) を使うと、setTimeout() を使って、
emscripten_async_resume() 関数を、n(ms) 後に起動するようにしておく。そして、
その段階では、main() の後の処理を全て素通りして、main() 関数から return する。
これは、if 文で、label という名称の local 変数の値で場合わけして、goto で色々な
ラベルに飛んでいるような感じ。でも、JS には、goto 文がないので、関数の処理全体を
大体 while(1) 文のブロック中に入れてしまって、必要な時に break する事で、while
ブロックの次の場所に飛ぶようにしてある。そして、そこで label 変数の値で場合分けして、
何らかの処理を行う。実は、この時、main() 関数に割り当てられた識別番号をどこかの
グローバル変数 g_k に残しておく。この識別番号は、0 から割り振られた小さな値で、
どこかの配列 g_func_s[]には、色々な関数の先頭アドレスが入っており、main もその中の
1つとして入っている。例えば、main に割り振られた識別番号が 5 なら、g_funs[5] で
main の関数アドレスが取得できるようになってるらしい。
次に、n(ms) の時間が経過すると、emscripten_async_resume() が呼び出される。この時点では、
main() 関数は実行を終えてしまっているので、何とかして、もう一度 main() 関数を起動しなおして、
上手く、emscripten_sleep() の直後の行にまで戻りたい。そこで、g_k に残された番号を頼りに、
g_func_s[g_k] の関数を起動しなおす。g_func_s[g_k] には、main 関数の先頭アドレスが入ってい
るので、main 関数を再起動することは出来ることは出来る。
で、main をもう一度起動して、なんとかして、emscripten_sleep() の直後の行にまで進む。
これは、変数「label 」に上手く値を入れることで、何とかしているんだと思う。
この時、スタック・ポインタの値も、元に戻す。
STACKTOP が、スタック・ポインタで、HEAP32[] が、CPU 全体のアドレス空間みたいなもの。
大体、HEAP32[STACKTOP] と書くことで、該当のスタックの近くにアクセスできるらしい。
例えば、main() 関数の中で、emscripten_sleep(n) を使うと、setTimeout() を使って、
emscripten_async_resume() 関数を、n(ms) 後に起動するようにしておく。そして、
その段階では、main() の後の処理を全て素通りして、main() 関数から return する。
これは、if 文で、label という名称の local 変数の値で場合わけして、goto で色々な
ラベルに飛んでいるような感じ。でも、JS には、goto 文がないので、関数の処理全体を
大体 while(1) 文のブロック中に入れてしまって、必要な時に break する事で、while
ブロックの次の場所に飛ぶようにしてある。そして、そこで label 変数の値で場合分けして、
何らかの処理を行う。実は、この時、main() 関数に割り当てられた識別番号をどこかの
グローバル変数 g_k に残しておく。この識別番号は、0 から割り振られた小さな値で、
どこかの配列 g_func_s[]には、色々な関数の先頭アドレスが入っており、main もその中の
1つとして入っている。例えば、main に割り振られた識別番号が 5 なら、g_funs[5] で
main の関数アドレスが取得できるようになってるらしい。
次に、n(ms) の時間が経過すると、emscripten_async_resume() が呼び出される。この時点では、
main() 関数は実行を終えてしまっているので、何とかして、もう一度 main() 関数を起動しなおして、
上手く、emscripten_sleep() の直後の行にまで戻りたい。そこで、g_k に残された番号を頼りに、
g_func_s[g_k] の関数を起動しなおす。g_func_s[g_k] には、main 関数の先頭アドレスが入ってい
るので、main 関数を再起動することは出来ることは出来る。
で、main をもう一度起動して、なんとかして、emscripten_sleep() の直後の行にまで進む。
これは、変数「label 」に上手く値を入れることで、何とかしているんだと思う。
この時、スタック・ポインタの値も、元に戻す。
STACKTOP が、スタック・ポインタで、HEAP32[] が、CPU 全体のアドレス空間みたいなもの。
大体、HEAP32[STACKTOP] と書くことで、該当のスタックの近くにアクセスできるらしい。
767デフォルトの名無しさん
2019/01/02(水) 18:50:37.56ID:/JRa6BYE function dynCall_vi(index,a1) {
index = index|0;
a1=a1|0;
FUNCTION_TABLE_vi[index&15](a1|0);
}
var FUNCTION_TABLE_vi = [b2,b2,b2,b2,_main__async_cb,b2,_vfprintf__async_cb,
_fflush__async_cb_2,_fflush__async_cb_1,_fflush__async_cb_3,
_fflush__async_cb,___fflush_unlocked__async_cb,___fflush_unlocked__async_cb_4,
_printf__async_cb,b2,b2];
index = index|0;
a1=a1|0;
FUNCTION_TABLE_vi[index&15](a1|0);
}
var FUNCTION_TABLE_vi = [b2,b2,b2,b2,_main__async_cb,b2,_vfprintf__async_cb,
_fflush__async_cb_2,_fflush__async_cb_1,_fflush__async_cb_3,
_fflush__async_cb,___fflush_unlocked__async_cb,___fflush_unlocked__async_cb_4,
_printf__async_cb,b2,b2];
768デフォルトの名無しさん
2019/01/02(水) 19:52:48.79ID:2lhCREwi 単純にスタックを切り替えて該当処理を再開できるようにしてるだけじゃん
769デフォルトの名無しさん
2019/01/03(木) 00:47:27.22ID:8NinKkm9770デフォルトの名無しさん
2019/01/03(木) 01:00:48.19ID:8NinKkm9 >>768
asm.js は、JSの「subset」とされる。だから、JSでサポートされてないことは、
asm.jsでも本質的には出来ない。JSは、
・sleep()関数が存在せず、wait()関数も今のところサポートされているブラウザが
かなり限定されるので、原則的には、関数の途中で無限ループ以外では停止する
ことは出来ない。
・関数callを使わずに、アセンブラの単純な(大域) jmp のようなことは
出来ない。だから、スタックポインタだけを元に戻しても、命令ポインタ(IP)
を元に戻すことが難しい。
・LLVMでも、原則的にはコードは個別の関数としてだけ作ることが出来て、
関数の外にコードを書くことはおそらく出来ない。
・ただし、LLVMの場合は、longjmp やスタックポインタなどのサポートが
色々と有るのでそのあたりを利用すれば何らかの方法があるかもしれない。
・だから、Emscriptenのemsripten_sleep()は、非常に高度なことをやっており、
「待ちたい時」は、いったんそれまでの呼び出し連鎖の全ての関数を逆に戻って、
「システム」にまで戻る。原則的には、全ての関数は、なんらかのイベント
からスタートしているので、これは、イベント・ハンドラの処理をいったん
終了して、ブラウザに制御を戻すような事になる。
・一定時間が経過すると、設定しておいたresume用のハンドラがシステムによって
起動されるので、そのタイミングで、呼び出し連鎖の全ての関数を再度、
「再起動」する。この仕組みを使わないと「EIP」を元に戻すことが出来ない
ためである。なお、スタックポインタについては、独自のグローバル変数を元に戻す
だけで済む。スタック自体は、巨大な「配列」をCPUのメモリー空間のように
して、スタックポインタに該当する変数を配列の添え字としてアクセスするような
事をしている。
asm.js は、JSの「subset」とされる。だから、JSでサポートされてないことは、
asm.jsでも本質的には出来ない。JSは、
・sleep()関数が存在せず、wait()関数も今のところサポートされているブラウザが
かなり限定されるので、原則的には、関数の途中で無限ループ以外では停止する
ことは出来ない。
・関数callを使わずに、アセンブラの単純な(大域) jmp のようなことは
出来ない。だから、スタックポインタだけを元に戻しても、命令ポインタ(IP)
を元に戻すことが難しい。
・LLVMでも、原則的にはコードは個別の関数としてだけ作ることが出来て、
関数の外にコードを書くことはおそらく出来ない。
・ただし、LLVMの場合は、longjmp やスタックポインタなどのサポートが
色々と有るのでそのあたりを利用すれば何らかの方法があるかもしれない。
・だから、Emscriptenのemsripten_sleep()は、非常に高度なことをやっており、
「待ちたい時」は、いったんそれまでの呼び出し連鎖の全ての関数を逆に戻って、
「システム」にまで戻る。原則的には、全ての関数は、なんらかのイベント
からスタートしているので、これは、イベント・ハンドラの処理をいったん
終了して、ブラウザに制御を戻すような事になる。
・一定時間が経過すると、設定しておいたresume用のハンドラがシステムによって
起動されるので、そのタイミングで、呼び出し連鎖の全ての関数を再度、
「再起動」する。この仕組みを使わないと「EIP」を元に戻すことが出来ない
ためである。なお、スタックポインタについては、独自のグローバル変数を元に戻す
だけで済む。スタック自体は、巨大な「配列」をCPUのメモリー空間のように
して、スタックポインタに該当する変数を配列の添え字としてアクセスするような
事をしている。
771デフォルトの名無しさん
2019/01/03(木) 01:14:16.10ID:8NinKkm9 >>770
[補足]
・データ用のスタックポインタは、単純にSTACKTOPという名称のJSの
グローバル変数によって模倣するとする。
・CPUの全アドレス空間は、HEAP32[] という32BIT整数の配列で
模倣するとする。
・その結果、スタック変数(local auto 変数)は、HEAP32[STACKTOP + ofs/4]
のような形式でアクセスできるようになる。
・通常のCPUでは、関数を呼び出した親のコードのアドレスが、スタック上に保存
されたあと、命令ポインタ IP の値が、呼び出し先の関数の先頭アドレスに修正される。
・JSの関数呼び出しも、ブラウザの内部的な変数に「戻りアドレス」が保存されて、
ある意味ではこれとよく似たことは行われていると考えてよい。
・しかし、このスタックは、HEAP32[] や、STACKTOP とはまったく独立した
ブラウザの内部的な領域にある。
・つまり、この「戻り値アドレス」は、HEAP32[]の中には入ってない。
・だから、STACKTOP を元に戻したところで、CPUの場合のように単純にはいかない。
・その結果、関数呼び出し連鎖を全て cancel する動作と、全て call し直して元に戻す
という動作は、STACKTOP の動作とは別に行わなくてはならない。
・ラベル名やラベル番号を指定した大域 goto 命令みたいなものが有れば話は別なのだが、
多分、JS にはそれがないためである。
[補足]
・データ用のスタックポインタは、単純にSTACKTOPという名称のJSの
グローバル変数によって模倣するとする。
・CPUの全アドレス空間は、HEAP32[] という32BIT整数の配列で
模倣するとする。
・その結果、スタック変数(local auto 変数)は、HEAP32[STACKTOP + ofs/4]
のような形式でアクセスできるようになる。
・通常のCPUでは、関数を呼び出した親のコードのアドレスが、スタック上に保存
されたあと、命令ポインタ IP の値が、呼び出し先の関数の先頭アドレスに修正される。
・JSの関数呼び出しも、ブラウザの内部的な変数に「戻りアドレス」が保存されて、
ある意味ではこれとよく似たことは行われていると考えてよい。
・しかし、このスタックは、HEAP32[] や、STACKTOP とはまったく独立した
ブラウザの内部的な領域にある。
・つまり、この「戻り値アドレス」は、HEAP32[]の中には入ってない。
・だから、STACKTOP を元に戻したところで、CPUの場合のように単純にはいかない。
・その結果、関数呼び出し連鎖を全て cancel する動作と、全て call し直して元に戻す
という動作は、STACKTOP の動作とは別に行わなくてはならない。
・ラベル名やラベル番号を指定した大域 goto 命令みたいなものが有れば話は別なのだが、
多分、JS にはそれがないためである。
772デフォルトの名無しさん
2019/01/03(木) 01:41:07.74ID:8NinKkm9 JSも、全てのコードを一つの関数の中に収めてしまって、
continue label 文や break label 文を使えば、好きなラベルに
jmp 出来る気がする。
もしそうだとすれば、関数の戻り値のラベル番号も、独自スタック
HEAP32[STACKTOP + ofs/4] に保存し、関数 call は、
JS の関数 call を使わずに、continue label / break label
を用い、関数から戻るときは、HEAP32[] から、戻り値の
ラベル番号を取得して、そのラベルに continue label または、
break label を使って jmp すれば、もっとすっきり実装してしまえる
かも知れない。
continue label 文や break label 文を使えば、好きなラベルに
jmp 出来る気がする。
もしそうだとすれば、関数の戻り値のラベル番号も、独自スタック
HEAP32[STACKTOP + ofs/4] に保存し、関数 call は、
JS の関数 call を使わずに、continue label / break label
を用い、関数から戻るときは、HEAP32[] から、戻り値の
ラベル番号を取得して、そのラベルに continue label または、
break label を使って jmp すれば、もっとすっきり実装してしまえる
かも知れない。
773デフォルトの名無しさん
2019/01/03(木) 03:01:45.80ID:fco1PFrc sleepは全然複雑じゃない
CPUを例に出すのは大間違いsleepしてもその間に別の処理が走るわけではないのだから
スタックの切り替えだなんだのは必要ないしやっていない
ただ処理ループを一旦抜けてsetTimeoutで待って再開してるだけ
CPUを例に出すのは大間違いsleepしてもその間に別の処理が走るわけではないのだから
スタックの切り替えだなんだのは必要ないしやっていない
ただ処理ループを一旦抜けてsetTimeoutで待って再開してるだけ
774デフォルトの名無しさん
2019/01/03(木) 05:08:32.78ID:Hc/0Zpss > CPUを例に出すのは大間違いsleepしてもその間に別の処理が走るわけではないのだから
JavaScriptでsleepを実装すると「その間に別の処理が走ってしまうから」
それを妨害するのが大変なんでしょ
JavaScriptでsleepを実装すると「その間に別の処理が走ってしまうから」
それを妨害するのが大変なんでしょ
775デフォルトの名無しさん
2019/01/03(木) 09:28:46.87ID:NOMEwXEr 公式のsleep(2000)の実装例
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function
てかマジでグダグダ言う前にMDNとか読めよドアホ>>770
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function
てかマジでグダグダ言う前にMDNとか読めよドアホ>>770
776デフォルトの名無しさん
2019/01/03(木) 10:15:21.62ID:Hc/0Zpss777デフォルトの名無しさん
2019/01/03(木) 10:25:31.04ID:NOMEwXEr >>776
おまえがsleepを分かってないことは分かった
おまえがsleepを分かってないことは分かった
778デフォルトの名無しさん
2019/01/03(木) 10:48:05.95ID:NOMEwXEr >>770
どうもアホがいて空回りしそうだから先に言っておく
> 原則的には、関数の途中で無限ループ以外では停止する
> ことは出来ない。
これがasync/awaitで構文的に緩和されてる。
勿論それでもシングルスレッドだから、
実行中のコンテキスト(スタック等)の切換は行わなければならないが、
async/awaitをサポートした時点でそれはJSエンジン側の仕事になってる。
emscripten自体はasync/awaitの標準化以前から存在するから、
その部分が結果的にポリフィル的になっているのは致し方ない。
どうもアホがいて空回りしそうだから先に言っておく
> 原則的には、関数の途中で無限ループ以外では停止する
> ことは出来ない。
これがasync/awaitで構文的に緩和されてる。
勿論それでもシングルスレッドだから、
実行中のコンテキスト(スタック等)の切換は行わなければならないが、
async/awaitをサポートした時点でそれはJSエンジン側の仕事になってる。
emscripten自体はasync/awaitの標準化以前から存在するから、
その部分が結果的にポリフィル的になっているのは致し方ない。
779デフォルトの名無しさん
2019/01/03(木) 10:52:03.35ID:fco1PFrc >>774
妨害してないよ
正確にはビジーループに変換されるsleepもあるけど動作には関係ない
なぜなら複数スレッドの処理が実際の1スレッドで動くよう変換されるわけではないから
むしろメインスレッドをブロックしないためにsetTimeoutが使われてる
その間に別のJSが動こうとそれは世界が違う話なので関係ない
妨害してないよ
正確にはビジーループに変換されるsleepもあるけど動作には関係ない
なぜなら複数スレッドの処理が実際の1スレッドで動くよう変換されるわけではないから
むしろメインスレッドをブロックしないためにsetTimeoutが使われてる
その間に別のJSが動こうとそれは世界が違う話なので関係ない
780デフォルトの名無しさん
2019/01/03(木) 11:20:52.45ID:NSJq2GPH >>778
async, await はダメだよ。
停止せずに素通りしてしまうから。
戻ってくることは出来るけど、async 修飾したその関数にだけしか
戻って来れないので、sleep には使えない。
async, await はダメだよ。
停止せずに素通りしてしまうから。
戻ってくることは出来るけど、async 修飾したその関数にだけしか
戻って来れないので、sleep には使えない。
781デフォルトの名無しさん
2019/01/03(木) 11:27:05.78ID:NOMEwXEr782デフォルトの名無しさん
2019/01/03(木) 11:37:39.37ID:NOMEwXEr ただそれ以前に、emscriptenは要するにC++→JS変換してくれるわけで、
sleepも当然サポートされていてそれなりに変換されてるだけだろ。
馬鹿なら馬鹿なりにそれを有り難く使えばいいだけだと思うが。
お前らのオレオレ実装よりは数段マシだと思うぜ。
sleepも当然サポートされていてそれなりに変換されてるだけだろ。
馬鹿なら馬鹿なりにそれを有り難く使えばいいだけだと思うが。
お前らのオレオレ実装よりは数段マシだと思うぜ。
783デフォルトの名無しさん
2019/01/03(木) 15:03:04.04ID:NSJq2GPH 現実世界では、天才だといわれてきたが。
784デフォルトの名無しさん
2019/01/03(木) 16:46:36.63ID:fco1PFrc いくら天才でも正しい前提知識を持ってないんじゃ仕方ない
785デフォルトの名無しさん
2019/01/03(木) 17:47:55.93ID:gRBMU2bw 10000ms指定したらUIが10秒止まるクソ関数が作れるなんて聞いた事ないし
簡単に作れちゃったら困る
簡単に作れちゃったら困る
786デフォルトの名無しさん
2019/01/03(木) 18:21:47.24ID:NOMEwXEr 簡単に作れるけどな
787デフォルトの名無しさん
2019/01/03(木) 18:56:01.52ID:NSJq2GPH788デフォルトの名無しさん
2019/01/03(木) 18:56:36.55ID:NSJq2GPH >>786
なら、作って欲しい。
なら、作って欲しい。
789デフォルトの名無しさん
2019/01/03(木) 19:11:23.28ID:NOMEwXEr ggrks
790デフォルトの名無しさん
2019/01/03(木) 19:19:13.19ID:NSJq2GPH >>789
何度ググっても出てこない。
何度ググっても出てこない。
791デフォルトの名無しさん
2019/01/03(木) 19:40:17.29ID:fco1PFrc どういうときにどう上手く行かないのかを言ってくれないとな
792デフォルトの名無しさん
2019/01/03(木) 20:06:11.56ID:NOMEwXEr そんな知能なさそうだし。
sleepなんて昔から話題としては出尽くしていて、ググレばいくらでも出てくる。
それを出てこないと言いきる辺り、つまりはコードクレクレ君で、コピペプログラマ以下だろ。
(ググったコードについても読めないからコピペすら出来ない)
sleepなんて昔から話題としては出尽くしていて、ググレばいくらでも出てくる。
それを出てこないと言いきる辺り、つまりはコードクレクレ君で、コピペプログラマ以下だろ。
(ググったコードについても読めないからコピペすら出来ない)
793デフォルトの名無しさん
2019/01/03(木) 21:50:51.86ID:eJU/mZfW また数学首席くんが妄想してんの?
いい加減自分が向いてないって気づけば良いのに。
いい加減自分が向いてないって気づけば良いのに。
794デフォルトの名無しさん
2019/01/03(木) 22:48:54.84ID:NOMEwXEr こいつはスルースキル特化型だな。
俺はスルースキル・モンスターと呼んでいるが、最近このタイプは増えてきている。
危険な兆候だよ。
俺はスルースキル・モンスターと呼んでいるが、最近このタイプは増えてきている。
危険な兆候だよ。
795デフォルトの名無しさん
2019/01/03(木) 22:52:45.12ID:Hc/0Zpss じゃあお前の職業は、スキースキル・ハンターで
>>794
「スルースキル・モンスター」を説明してください
「スルースキル・モンスター」を説明してください
797デフォルトの名無しさん
2019/01/04(金) 09:53:39.24ID:GK4v5jr/ canvas の width や、グラフィック描画時の座標指定が、ブラウザの拡大率を
100%にしても、実際の画面のピクセル座標とは違っている。
<meta name="viewport" content="width=device-width, initial-scale=1">
を指定しても駄目だった。ぴったり同じにする方法ある?
100%にしても、実際の画面のピクセル座標とは違っている。
<meta name="viewport" content="width=device-width, initial-scale=1">
を指定しても駄目だった。ぴったり同じにする方法ある?
798デフォルトの名無しさん
2019/01/04(金) 15:04:48.00ID:GK4v5jr/ Chromeで拡大率100%の時、HTML 内の JS で、
value = window.devicePixelRatio;
console.log( "window.devicePixelRatio = " + value );
とすると、1.25 と表示される。
HTML の <div> tag の style を css で width: 100px; などとしたものを
Chrome で 100% の拡大率で表示したものを、ScreenShot をとって調べてみると、
125 dot 程度になっていた。
使用OSは、Win7 で、確か、文字を大きめに表示する設定にしてある。
value = window.devicePixelRatio;
console.log( "window.devicePixelRatio = " + value );
とすると、1.25 と表示される。
HTML の <div> tag の style を css で width: 100px; などとしたものを
Chrome で 100% の拡大率で表示したものを、ScreenShot をとって調べてみると、
125 dot 程度になっていた。
使用OSは、Win7 で、確か、文字を大きめに表示する設定にしてある。
799デフォルトの名無しさん
2019/01/04(金) 15:50:35.77ID:XP0z3+7N canvasの内部的な座標とcanvasのelement的な座標の比で調整するのじゃダメなんかい
800デフォルトの名無しさん
2019/01/04(金) 16:11:48.10ID:fcxyg7i+ そもそもピクセルが正方形とも限らないわけで
デバイス、ドライバ、OSが順に抽象化したあと更にブラウザが抽象化したものが
Webアプリからは見えるのでそこをどうこうしようとするのはナンセンス
それでもどうしてもどうにかしたいというのなら
devicePixelRatioやrenderedPixelWidthを元にその文だけCanvasをCSSで縮小してみるとか
デバイス、ドライバ、OSが順に抽象化したあと更にブラウザが抽象化したものが
Webアプリからは見えるのでそこをどうこうしようとするのはナンセンス
それでもどうしてもどうにかしたいというのなら
devicePixelRatioやrenderedPixelWidthを元にその文だけCanvasをCSSで縮小してみるとか
801デフォルトの名無しさん
2019/01/04(金) 16:50:58.90ID:GK4v5jr/ 色々試して、以下のようにすると、ほぼ 1px = 物理 1 pixel になった。
こんな方法でよい?
<style>
#div0 {
transform: scale(0.8); // 1.0 / 1.25
transform-origin: top left;
}
</style>
<div id="div0">
実際に表示したいタグ達
</div>
こんな方法でよい?
<style>
#div0 {
transform: scale(0.8); // 1.0 / 1.25
transform-origin: top left;
}
</style>
<div id="div0">
実際に表示したいタグ達
</div>
802デフォルトの名無しさん
2019/01/05(土) 01:10:26.21ID:A90WoquU それでいいけど
単純にwidthを表示の1.25倍にしたらどうなるのかな
単純にwidthを表示の1.25倍にしたらどうなるのかな
803デフォルトの名無しさん
2019/01/05(土) 08:40:55.94ID:7vIhmJH5 canvas の putImageData() で、引数が7つのタイプの場合の引数の意味が分からない。
context.putImageData(imgData,x,y,dirtyX,dirtyY,dirtyWidth,dirtyHeight);
http://www.webtech360.com/detail/html5-canvas-draw-pictures-and-manipulate-pixels-3555.html
↑の図で合ってる? 日本人の感覚だと、この図では、「dirtyAaaa」という言葉
と合ってるようには思えないんだけど。
context.putImageData(imgData,x,y,dirtyX,dirtyY,dirtyWidth,dirtyHeight);
http://www.webtech360.com/detail/html5-canvas-draw-pictures-and-manipulate-pixels-3555.html
↑の図で合ってる? 日本人の感覚だと、この図では、「dirtyAaaa」という言葉
と合ってるようには思えないんだけど。
804デフォルトの名無しさん
2019/01/05(土) 09:24:30.49ID:7vIhmJH5 >>802
実験してみると、
HTML tag の width と、css(style) の width の二種類の意味が違っていて、
<canvas width=aaa style="width:bbb;">
とした場合、
aaa = 論理的な横方向のドット数;
bbb = 物理的な横方向のドット数;
の意味になるらしく、canvas の色々な描画関数で渡す x 座標を log_x とすると、
原則的には、
phys_x = canvas_phys_left + (log_x / aaa * bbb);
のように座標変換された後に画面に表示されるらしい。
JavaScript だと、
canvas = (getElementById("ID名") などで DOM 要素を取得);
canvas.width = 論理的な横方向のドット数;
canvas.style.width = 物理的な横方向のドット数;
と書けるようだ。
ただし、>>801 のやり方だと、canvas の左上の座標が(0,0)で
ない場合にも、canvas の左上の位置を自動的に調整(縮尺)してくれるが、
今回のやり方だと、それは自分で調整しなくてはならない。
実験してみると、
HTML tag の width と、css(style) の width の二種類の意味が違っていて、
<canvas width=aaa style="width:bbb;">
とした場合、
aaa = 論理的な横方向のドット数;
bbb = 物理的な横方向のドット数;
の意味になるらしく、canvas の色々な描画関数で渡す x 座標を log_x とすると、
原則的には、
phys_x = canvas_phys_left + (log_x / aaa * bbb);
のように座標変換された後に画面に表示されるらしい。
JavaScript だと、
canvas = (getElementById("ID名") などで DOM 要素を取得);
canvas.width = 論理的な横方向のドット数;
canvas.style.width = 物理的な横方向のドット数;
と書けるようだ。
ただし、>>801 のやり方だと、canvas の左上の座標が(0,0)で
ない場合にも、canvas の左上の位置を自動的に調整(縮尺)してくれるが、
今回のやり方だと、それは自分で調整しなくてはならない。
805デフォルトの名無しさん
2019/01/05(土) 09:26:31.72ID:7vIhmJH5 >>804
あ、確か逆さまだったと思う。
だから、
誤: <canvas width=aaa style="width:bbb;">
正: <canvas width=bbb style="width:aaa;">
が確か正しい。
あ、確か逆さまだったと思う。
だから、
誤: <canvas width=aaa style="width:bbb;">
正: <canvas width=bbb style="width:aaa;">
が確か正しい。
806デフォルトの名無しさん
2019/01/05(土) 09:27:38.04ID:7vIhmJH5 >>805
だから、確か、
canvas.width = 物理的な横方向のドット数;
canvas.style.width = 論理的な横方向のドット数;
だったと思う。
だから、確か、
canvas.width = 物理的な横方向のドット数;
canvas.style.width = 論理的な横方向のドット数;
だったと思う。
807デフォルトの名無しさん
2019/01/06(日) 18:47:08.41ID:RK31I1jj つ チラ裏
808デフォルトの名無しさん
2019/01/06(日) 22:56:13.91ID:EEI9V+3n webページでフォーム入力した項目を確認のために埋め込まれたような形で一旦表示させたいんですけど、こういうのはJavaScriptで実装するんですかね?
どうググったら、ここら辺の情報取得できますかね?
自分、pythonしかできなくて、フロントエンド的なところは全然わからないです。。。
どうググったら、ここら辺の情報取得できますかね?
自分、pythonしかできなくて、フロントエンド的なところは全然わからないです。。。
809デフォルトの名無しさん
2019/01/06(日) 23:16:51.05ID:QwoLvlkS javascript使う
vue.jsとか使えば楽
vue.jsとか使えば楽
810デフォルトの名無しさん
2019/01/06(日) 23:31:44.52ID:pcr+etW3811デフォルトの名無しさん
2019/01/06(日) 23:38:17.77ID:TbUKTpaD812デフォルトの名無しさん
2019/01/06(日) 23:53:49.41ID:QwoLvlkS フロントでvaildateしてユーザーに伝えたいという意味と解釈したけど違った?
813デフォルトの名無しさん
2019/01/07(月) 00:28:47.48ID:nb8eFh2w814デフォルトの名無しさん
2019/01/07(月) 00:47:13.54ID:IMoYk5nw >>813
あるサイトと同様のものをJavaScriptで得たい場合、F12を押してコードを見るのが一番早い。
つっても2chなんてゴミなので、参考にするならもうちょっとましなサイトの方がいいが。
DBと照合したいのならサーバーサイドで、君の場合はPythonでやった方がいいと思うよ。
あるサイトと同様のものをJavaScriptで得たい場合、F12を押してコードを見るのが一番早い。
つっても2chなんてゴミなので、参考にするならもうちょっとましなサイトの方がいいが。
DBと照合したいのならサーバーサイドで、君の場合はPythonでやった方がいいと思うよ。
815デフォルトの名無しさん
2019/01/07(月) 00:51:51.70ID:nb8eFh2w816デフォルトの名無しさん
2019/01/07(月) 02:05:35.08ID:52D4hsE6 > あるサイトと同様のものをJavaScriptで得たい場合、F12を押してコードを見るのが一番早い。
そうとは限らない。今のJavaScriptは圧縮などかけられてるから
見た所で意味不明というものがたくさんある
そうとは限らない。今のJavaScriptは圧縮などかけられてるから
見た所で意味不明というものがたくさんある
817デフォルトの名無しさん
2019/01/07(月) 02:07:20.52ID:52D4hsE6818デフォルトの名無しさん
2019/01/07(月) 06:08:04.91ID:fwjV5x3t javascriptの出番なし
819デフォルトの名無しさん
2019/01/07(月) 11:09:06.87ID:pzLLoDSE jsいらんだろ
820デフォルトの名無しさん
2019/01/07(月) 12:01:38.74ID:52D4hsE6 >>819
それはある意味真実。HTMLとCSSだけで殆どのことができますっていうのが理想
それはある意味真実。HTMLとCSSだけで殆どのことができますっていうのが理想
821デフォルトの名無しさん
2019/01/07(月) 12:31:11.69ID:lmbNEshB >>803
dirty の意味は、汚染されている事。
つまり、Canvas のデータの事だろ
一度でも、Canvas に描いたものは汚染されるから、JavaScript のデータには戻せない。
ブラウザのセキュリティ機構をパスしていない
dirty の意味は、汚染されている事。
つまり、Canvas のデータの事だろ
一度でも、Canvas に描いたものは汚染されるから、JavaScript のデータには戻せない。
ブラウザのセキュリティ機構をパスしていない
822デフォルトの名無しさん
2019/01/07(月) 12:51:53.95ID:iRM6IrG4 ちょっとググった限りでは、refreshしないといけない部分だからdirty rectangleと言われるようになった感じ?
823デフォルトの名無しさん
2019/01/08(火) 01:00:58.27ID:o7vKw7lQ dirty bitとかのdirtyと同じ
ただ「描き込みがされる、変更がされる」という意味なだけ
ただ「描き込みがされる、変更がされる」という意味なだけ
824デフォルトの名無しさん
2019/01/08(火) 02:56:28.08ID:Wrr+1l7l 汚ねぇ花火だなのdirtyと一緒?
825デフォルトの名無しさん
2019/01/12(土) 07:29:22.71ID:7un73cLT どうやったら習得できるんでしょうか?
授業だけでは全然習得できませんでした
jQueryをコピペするだけしかできません
教科書書き写せって言われたのでしていますが
タイピング練習している気分で、1行1行
何かいてるか理解できていません
読めないから見るのも嫌になってます
初心者の時に何やってたか教えてください
授業だけでは全然習得できませんでした
jQueryをコピペするだけしかできません
教科書書き写せって言われたのでしていますが
タイピング練習している気分で、1行1行
何かいてるか理解できていません
読めないから見るのも嫌になってます
初心者の時に何やってたか教えてください
826デフォルトの名無しさん
2019/01/12(土) 09:25:53.56ID:Ybdj3XEu >>825
> 授業だけでは
> 教科書書き写せって言われたのでしていますが
どこでどういう風に習ったんだ?
JavaScriptは比較的簡単な言語ではあるが、
授業で習った程度で出来るようになると思っている時点で大間違いだぞ。
ズブの初心者が数時間で出来るようになるのなら、専門職として成立しないだろ。
> 授業だけでは
> 教科書書き写せって言われたのでしていますが
どこでどういう風に習ったんだ?
JavaScriptは比較的簡単な言語ではあるが、
授業で習った程度で出来るようになると思っている時点で大間違いだぞ。
ズブの初心者が数時間で出来るようになるのなら、専門職として成立しないだろ。
827デフォルトの名無しさん
2019/01/12(土) 09:56:20.35ID:Ybdj3XEu あと、どこを目指している?
Webデザイナになりたいのなら、そんなもんで構わないとも思うが。
Webデザイナになりたいのなら、そんなもんで構わないとも思うが。
828デフォルトの名無しさん
2019/01/12(土) 10:13:31.48ID:8njw2BgM コピペして必要になったら理解するための勉強すればいいんじゃね
それだと基礎ができてねえとか言われるしクソコードになるけど
基礎勉強していてもどうせクソコードと言われるんだしな
それだと基礎ができてねえとか言われるしクソコードになるけど
基礎勉強していてもどうせクソコードと言われるんだしな
829デフォルトの名無しさん
2019/01/12(土) 15:57:47.77ID:xa1AucJl 詐欺プログラミングスクールの何週間でプロに、とか3ヶ月でマスター全部ウソだから。
宗教ビジネスとかに近いやり口だよアレ。規制・逮捕・投獄すればいいのに。
宗教ビジネスとかに近いやり口だよアレ。規制・逮捕・投獄すればいいのに。
830デフォルトの名無しさん
2019/01/12(土) 16:28:36.05ID:gZqMJwxN >>825
読めないし意味がわからないのは当たり前だし
それをどうこうする方法もない
新しいことを学ぶというのは非常に困難なことだと理解しろ
数学や国語だって頭の柔らかい子供がきっちり何百年もかけて練られた
体系立てられた教育で10年以上もかけてやっと習得できるものなんだぞ
つまりざっと1000時間は必要ということだ
もちろん1000時間かけても分からない人も居る
でも自分の頭を信じて、わからないものが分かるようになれると信じて
いやいや苦しいながら1000時間頑張る以外無いんだよ
とりあえずチュートリアル的なサイトを最初はコピペから一通りやる
そのときにちょっと改変してみたりしてどう結果が変わるのかから
それがどういう意味をもつ行為だったのか、そこがどういう効果をもつ部分だったのかを理解していく
意味が分からないことが100出てきたら、ググり倒してなんとかそれを99にするよう必死に努力する
多少程度分かるようになってきたらもう一度MDNのような網羅的に載っているとこをみて自分が知らない知識を仕入れる
構文やAPIは別に暗記する必要はない こういうことに使えるものがあるということをできるだけ知っておく
その繰り返し つまり基礎と応用を行ったり来たりして
段階的にではなくまんべんなく少しずつ積み重ねていき、ある時からはその穴を埋めていく
基礎はだいたいわかったと思ったら、ググって他人の書いたコードを見る
そうすると自分の知らない書き方や機能が使われていて、しかも非常に読みにくい
でもそれに慣れていく
もう一度MDNを全部隅から隅まで必ず読む
JS再入門をやってみる それで中級者
各構文の詳細をきっきり理解し、スコープチェーンやプロトタイプチェーンといった概念を学び
今まで何となく書いてきたものの真意を理解する
構文やAPIを仕様書を直接見て理解できるようにする
基本的な仕様書を一通り必ず読む それで上級者
そっからは自分の好きなコミュニティに所属して深掘りする
読めないし意味がわからないのは当たり前だし
それをどうこうする方法もない
新しいことを学ぶというのは非常に困難なことだと理解しろ
数学や国語だって頭の柔らかい子供がきっちり何百年もかけて練られた
体系立てられた教育で10年以上もかけてやっと習得できるものなんだぞ
つまりざっと1000時間は必要ということだ
もちろん1000時間かけても分からない人も居る
でも自分の頭を信じて、わからないものが分かるようになれると信じて
いやいや苦しいながら1000時間頑張る以外無いんだよ
とりあえずチュートリアル的なサイトを最初はコピペから一通りやる
そのときにちょっと改変してみたりしてどう結果が変わるのかから
それがどういう意味をもつ行為だったのか、そこがどういう効果をもつ部分だったのかを理解していく
意味が分からないことが100出てきたら、ググり倒してなんとかそれを99にするよう必死に努力する
多少程度分かるようになってきたらもう一度MDNのような網羅的に載っているとこをみて自分が知らない知識を仕入れる
構文やAPIは別に暗記する必要はない こういうことに使えるものがあるということをできるだけ知っておく
その繰り返し つまり基礎と応用を行ったり来たりして
段階的にではなくまんべんなく少しずつ積み重ねていき、ある時からはその穴を埋めていく
基礎はだいたいわかったと思ったら、ググって他人の書いたコードを見る
そうすると自分の知らない書き方や機能が使われていて、しかも非常に読みにくい
でもそれに慣れていく
もう一度MDNを全部隅から隅まで必ず読む
JS再入門をやってみる それで中級者
各構文の詳細をきっきり理解し、スコープチェーンやプロトタイプチェーンといった概念を学び
今まで何となく書いてきたものの真意を理解する
構文やAPIを仕様書を直接見て理解できるようにする
基本的な仕様書を一通り必ず読む それで上級者
そっからは自分の好きなコミュニティに所属して深掘りする
831デフォルトの名無しさん
2019/01/12(土) 16:39:55.64ID:9/u5urH+ >>830
長い
長い
832デフォルトの名無しさん
2019/01/12(土) 17:08:51.58ID:XDHakXaX >>825
初心というか、新しいことを始めるときにはだいたいこんな感じ。
1) 適当に検索して必要な部品をコピペする
2) コピペ同士の整合性確保と自分の美意識に従って整形する
3) 時間が許す限り 2 を繰り返す
4) 試験する
整形するところで、たとえば未知の関数ならその役割や必要なパラメータを理解する必要があるし。
コピペを適当に順序を組み替えてみると予期しないエラーが生じることもあるから、その原因を調べることで理解が深まったりするし。
要は好奇心が自分を動かしてるんだろうな。そりゃ打ち込みだけなら眠くなるだけだわ。
初心というか、新しいことを始めるときにはだいたいこんな感じ。
1) 適当に検索して必要な部品をコピペする
2) コピペ同士の整合性確保と自分の美意識に従って整形する
3) 時間が許す限り 2 を繰り返す
4) 試験する
整形するところで、たとえば未知の関数ならその役割や必要なパラメータを理解する必要があるし。
コピペを適当に順序を組み替えてみると予期しないエラーが生じることもあるから、その原因を調べることで理解が深まったりするし。
要は好奇心が自分を動かしてるんだろうな。そりゃ打ち込みだけなら眠くなるだけだわ。
833デフォルトの名無しさん
2019/01/12(土) 19:02:39.47ID:7un73cLT たくさんのレスありがとうございました。
ちょっとやる気出てきました
が、道のりは険しそうですね
webの専門学校の授業でhtmlとcssを学び
ページは作れるようになったものの
javascriptはよくわからないまま授業が終わり
今はphpを覚えさせられてる段階です
3ヶ月ぐらいです
授業は教科書一冊を前から順番に終わらせた感じですが
先生はcssで出来るなら無理にjavascriptを使わなくて良いって言ってました
先生も他の言語が得意みたいで、あまりjavascriptは詳しそうな感じではなかったです
jQueryはどんなライブラリがあるのかを知り、
それを確実にコピペができることが大事って言われたのですが
コードが読めないjQueryをコピペするのはあまり面白くありませんでした
目指してるのはwebアプリとかゲームとか個人で作りたいです
javascript(Vue.js)とphp(laravel)を覚えてアプリを作ろうと考えています
将来グーグルアプリやアップルストアに置いたりしたいです
MDNは先生もおすすめしていますが
難しすぎるのと、同時に画面表示すると作業しにくいので本を書き写しています
まだ寝るまで時間あるので引き続き書き写ししようと思います
クラスで取り残されてて、あんまり質問できない空気なので
意見もらえて勉強になりました
ちょっとやる気出てきました
が、道のりは険しそうですね
webの専門学校の授業でhtmlとcssを学び
ページは作れるようになったものの
javascriptはよくわからないまま授業が終わり
今はphpを覚えさせられてる段階です
3ヶ月ぐらいです
授業は教科書一冊を前から順番に終わらせた感じですが
先生はcssで出来るなら無理にjavascriptを使わなくて良いって言ってました
先生も他の言語が得意みたいで、あまりjavascriptは詳しそうな感じではなかったです
jQueryはどんなライブラリがあるのかを知り、
それを確実にコピペができることが大事って言われたのですが
コードが読めないjQueryをコピペするのはあまり面白くありませんでした
目指してるのはwebアプリとかゲームとか個人で作りたいです
javascript(Vue.js)とphp(laravel)を覚えてアプリを作ろうと考えています
将来グーグルアプリやアップルストアに置いたりしたいです
MDNは先生もおすすめしていますが
難しすぎるのと、同時に画面表示すると作業しにくいので本を書き写しています
まだ寝るまで時間あるので引き続き書き写ししようと思います
クラスで取り残されてて、あんまり質問できない空気なので
意見もらえて勉強になりました
834デフォルトの名無しさん
2019/01/12(土) 19:42:31.64ID:Ybdj3XEu >>833
> 同時に画面表示すると作業しにくいので本を書き写しています
今すぐ2画面にして、片方でMDNを見ながらもう片方でコーディングする癖を付けろ。
今なら2万円くらいで出来るはず。
そして今すぐゲーム作成に着手しろ。(詳細後述)
> (略) 3ヶ月ぐらいです
ズブの素人からか?ならそんなもんだ。
君が特に頭が悪いって事ではない。
> コードが読めないjQueryをコピペするのはあまり面白くありませんでした
これはもうやらなくていい。時間の無駄だ。
> 目指してるのはwebアプリとかゲームとか個人で作りたいです
> javascript(Vue.js)とphp(laravel)を覚えてアプリを作ろうと考えています
Webで言う「アプリ」は「ドキュメント」と対比されるもので、
上記jQueryを使うのは主に「ドキュメント」であり、つまり君にはjQueryの知識は不要だ。
そして、「アプリ」と言われるのは実はHTML主体のアプリ(ECサイト/掲示板/社内クライアント(勤怠管理等))であって、
これら向けのフレームワークがvueであり、またサーバーサイドの知識も有った方がいいからPHPもありだが、
君の目標のcanvasアプリでは、はっきり言ってvueやPHPの知識はいらない。
君の専門学校は一般的なHTML/CSS/JavaScript/PHPの講習をしており、これ自体は悪くない。
しかし君にはjQueryもvueもPHPも必要なく、今現在のHTML/CSS/JavaScriptだけで出来る。
だから今すぐゲーム作りに着手しろ。最初は○×ゲームやオセロ等で構わない。
プログラミングなんて手段でしかないから、結局のところ、モチベーションが上がらないと上達もしない。
写経の際にいじくり倒して快感を得られるタイプなら写経も効果あるが、
君の場合はそうではないのだから、写経は時間の無駄だ。
一応の知識は揃っているはずだから、君は今すぐ君がやりたいこと、例えばゲームを試しに作ってみることだ。
そうすれば、今の自分に何が足りないか分かるだろうし、そこを先生に聞けばいいんだよ。
折角金払って専門学校に行っているのだから、先生をうまく活用した方がいい。
> 同時に画面表示すると作業しにくいので本を書き写しています
今すぐ2画面にして、片方でMDNを見ながらもう片方でコーディングする癖を付けろ。
今なら2万円くらいで出来るはず。
そして今すぐゲーム作成に着手しろ。(詳細後述)
> (略) 3ヶ月ぐらいです
ズブの素人からか?ならそんなもんだ。
君が特に頭が悪いって事ではない。
> コードが読めないjQueryをコピペするのはあまり面白くありませんでした
これはもうやらなくていい。時間の無駄だ。
> 目指してるのはwebアプリとかゲームとか個人で作りたいです
> javascript(Vue.js)とphp(laravel)を覚えてアプリを作ろうと考えています
Webで言う「アプリ」は「ドキュメント」と対比されるもので、
上記jQueryを使うのは主に「ドキュメント」であり、つまり君にはjQueryの知識は不要だ。
そして、「アプリ」と言われるのは実はHTML主体のアプリ(ECサイト/掲示板/社内クライアント(勤怠管理等))であって、
これら向けのフレームワークがvueであり、またサーバーサイドの知識も有った方がいいからPHPもありだが、
君の目標のcanvasアプリでは、はっきり言ってvueやPHPの知識はいらない。
君の専門学校は一般的なHTML/CSS/JavaScript/PHPの講習をしており、これ自体は悪くない。
しかし君にはjQueryもvueもPHPも必要なく、今現在のHTML/CSS/JavaScriptだけで出来る。
だから今すぐゲーム作りに着手しろ。最初は○×ゲームやオセロ等で構わない。
プログラミングなんて手段でしかないから、結局のところ、モチベーションが上がらないと上達もしない。
写経の際にいじくり倒して快感を得られるタイプなら写経も効果あるが、
君の場合はそうではないのだから、写経は時間の無駄だ。
一応の知識は揃っているはずだから、君は今すぐ君がやりたいこと、例えばゲームを試しに作ってみることだ。
そうすれば、今の自分に何が足りないか分かるだろうし、そこを先生に聞けばいいんだよ。
折角金払って専門学校に行っているのだから、先生をうまく活用した方がいい。
835デフォルトの名無しさん
2019/01/12(土) 20:05:20.01ID:Ybdj3XEu ちなみに、今時のPCで2画面出力出来ないのはほぼあり得ないし、
TVが有ればHDMI端子がないのもほぼあり得ない。
そして、線をつなげば割と自動認識していきなり2画面になるという安直さ。
まあ、TVが有ればやってみ。
TVが有ればHDMI端子がないのもほぼあり得ない。
そして、線をつなげば割と自動認識していきなり2画面になるという安直さ。
まあ、TVが有ればやってみ。
836デフォルトの名無しさん
2019/01/12(土) 20:59:34.69ID:7un73cLT 詳しくありがとうございます
クラスではipadを見ながらやってるって人がいて
うらやましいと思ってましたが、2画面って方法があるんですね
勉強のためにバイトやめてしまったので今お金がないです(T_T)
お金でき次第買います
今すぐ、ゲーム作りですか?
見た目を用意するのはhtmlで出来そうですが
参考書でも買わないと作れないですね
作りたいゲームはあると言えばあるので
明日本屋で見て、できそうならやってみます
クラスではipadを見ながらやってるって人がいて
うらやましいと思ってましたが、2画面って方法があるんですね
勉強のためにバイトやめてしまったので今お金がないです(T_T)
お金でき次第買います
今すぐ、ゲーム作りですか?
見た目を用意するのはhtmlで出来そうですが
参考書でも買わないと作れないですね
作りたいゲームはあると言えばあるので
明日本屋で見て、できそうならやってみます
837デフォルトの名無しさん
2019/01/12(土) 22:20:16.81ID:Ybdj3XEu >>836
> クラスではipadを見ながらやってるって人がいて
それと同等にはなる。
スマホだとさすがにきついと思うから、安物でいいからモニタを買った方がいい。
つか、専門学校なら最初から2画面にしとけよ、とは思うが。(君が悪いわけではないが)
> 見た目を用意するのはhtmlで出来そうですが
それでいい。
見た目だけ、例えばオセロならまず盤面をHTMLで用意するところから始める。
次に、クリックしたら石をおくようにする。つまりはクリックしたところにクラスを加えるだけだが。
そしたら、後は、「挟んだ石は自動的にひっくり返る」ようにすれば、手動での対戦は出来るようになる。
そして後はCPUで適切な手を考えられるようにすれば、CPUとの対戦が出来るようになる、というわけだ。
これ読んで大体「オセロなら出来そうだ」と思えるか?
なら、もう十分だから、アイデアもあるようだし、それに取りかかった方がいい。
やらないと上達しない。やる為には、自分がやりたいことをやるのが一番いい。
本を買う必要は無いとも思うが、まあ思うようにやればいい。
> クラスではipadを見ながらやってるって人がいて
それと同等にはなる。
スマホだとさすがにきついと思うから、安物でいいからモニタを買った方がいい。
つか、専門学校なら最初から2画面にしとけよ、とは思うが。(君が悪いわけではないが)
> 見た目を用意するのはhtmlで出来そうですが
それでいい。
見た目だけ、例えばオセロならまず盤面をHTMLで用意するところから始める。
次に、クリックしたら石をおくようにする。つまりはクリックしたところにクラスを加えるだけだが。
そしたら、後は、「挟んだ石は自動的にひっくり返る」ようにすれば、手動での対戦は出来るようになる。
そして後はCPUで適切な手を考えられるようにすれば、CPUとの対戦が出来るようになる、というわけだ。
これ読んで大体「オセロなら出来そうだ」と思えるか?
なら、もう十分だから、アイデアもあるようだし、それに取りかかった方がいい。
やらないと上達しない。やる為には、自分がやりたいことをやるのが一番いい。
本を買う必要は無いとも思うが、まあ思うようにやればいい。
838デフォルトの名無しさん
2019/01/13(日) 10:01:03.08ID:ZUrC3wug ただゲームを作りたいというだけなのに練習にしろ本番にしろ
HTML/CSS/JSのセットを学ぶ必要性はない
Google Blockyやプチコンのようなもので学んだほうが良い
HTML/CSS/JSのセットを学ぶ必要性はない
Google Blockyやプチコンのようなもので学んだほうが良い
839デフォルトの名無しさん
2019/01/13(日) 10:14:09.92ID:/M42Y9uV HTML/CSS/JSのセットを学ぶことは無駄にはならんよ。
今後のGUIの主流になりつつあるから。
ただ、ゲームを作りたいだけならオーバースペックだ、というだけで。
今後のGUIの主流になりつつあるから。
ただ、ゲームを作りたいだけならオーバースペックだ、というだけで。
840デフォルトの名無しさん
2019/01/13(日) 10:32:25.08ID:/M42Y9uV あとその手の「初心者でも子供でも簡単に出来る」って奴は大概すぐポシャるので俺は勧めないね。
scratchが一時期言われてたけど、今全く聞かないでしょ。
何故プロがそれらを使わないのかを理解出来ないうちは、所詮その程度って事だよ。
専門学校はプロ養成予備校みたいな位置づけだし、今ならHTML/CSS/JavaScriptで妥当だ。
当人は「学ばないと出来ない」という感覚なのか、出来ない理由を探しているから、
そうではなく、出来るところから始めろ、というだけ。
JavaScriptはコミュニティが腐っているが、言語としてはまあまあだよ。
そこで上達出来るかは本人次第だ。
とはいえ、初心者だと雑音を雑音と認識することも難しいから、難儀な話ではあるが。
scratchが一時期言われてたけど、今全く聞かないでしょ。
何故プロがそれらを使わないのかを理解出来ないうちは、所詮その程度って事だよ。
専門学校はプロ養成予備校みたいな位置づけだし、今ならHTML/CSS/JavaScriptで妥当だ。
当人は「学ばないと出来ない」という感覚なのか、出来ない理由を探しているから、
そうではなく、出来るところから始めろ、というだけ。
JavaScriptはコミュニティが腐っているが、言語としてはまあまあだよ。
そこで上達出来るかは本人次第だ。
とはいえ、初心者だと雑音を雑音と認識することも難しいから、難儀な話ではあるが。
841デフォルトの名無しさん
2019/01/14(月) 14:10:49.06ID:qAC/hIw5 このスレはじめてきたけど、上の方でjQueryをやたら推してる人って頭おかしいの?
842デフォルトの名無しさん
2019/01/14(月) 14:47:13.30ID:WA0+I2lc jQuery推しがおかしいかおかしくないかはどうでも良くて
それに論理的に反論できないならば、言ってることは正しいってことさ
それに論理的に反論できないならば、言ってることは正しいってことさ
843デフォルトの名無しさん
2019/01/14(月) 14:50:15.30ID:qAC/hIw5 えっ、jQueryおじさんが反論を理解できていないだけじゃないの?
844デフォルトの名無しさん
2019/01/14(月) 15:20:39.58ID:WA0+I2lc それは違うな。
845デフォルトの名無しさん
2019/01/14(月) 16:57:53.59ID:MmdBprG3 >>843
そうだよ
そうだよ
846デフォルトの名無しさん
2019/01/14(月) 17:36:34.87ID:WA0+I2lc jQueryのシェアがまた伸びてた。73.7%。5ヶ月連続で毎月0.1%増えてる。
0.1%増加なんて僅かだと思うかもしれないが、
Reactの現在のシェア(増加ではない)が0.2%、Vueが0.2%、Angularが0.4%
https://w3techs.com/technologies/history_overview/javascript_library/all
0.1%増加なんて僅かだと思うかもしれないが、
Reactの現在のシェア(増加ではない)が0.2%、Vueが0.2%、Angularが0.4%
https://w3techs.com/technologies/history_overview/javascript_library/all
847デフォルトの名無しさん
2019/01/14(月) 18:16:36.57ID:ft32dWPM848デフォルトの名無しさん
2019/01/14(月) 21:49:08.71ID:E+94DXGY shadow-root(attachShadow)って何ができるの?
ふつーに要素を作るんじゃなくて使うってことは何かできることがあると思って
ふつーに要素を作るんじゃなくて使うってことは何かできることがあると思って
849デフォルトの名無しさん
2019/01/15(火) 19:19:49.80ID:Mzm8zFRT jQuery使わない人の声だけがでかいのはわかる
javascriptフレームワークなんて誰も使ってない
javascriptフレームワークなんて誰も使ってない
850デフォルトの名無しさん
2019/01/15(火) 19:25:43.57ID:URfldHzA 声がでかいのはjQueryバカだが。
851デフォルトの名無しさん
2019/01/15(火) 20:18:42.32ID:XcHWZlYr jQuery厨は結局「jQueryは不滅です」と言い張るだけだから議論する意味はない。
実際はじきに結論がでるから待てばいい。
予想するなら、version3に上げている連中(6.4%)は今後とも使う気なのだと思う。
今だにversion1を使っている(=バージョンを上げてまで使う気はない)のが大半(85.7%)で、
つまり大半は様子見中で、だからこそこの話に食いつく奴が多い。
https://w3techs.com/technologies/details/js-jquery/all/all
このサイトのシェアはサイト数で算出しているから、
どうしてもvue等の「アプリ」用フレームワークは低く出る。
とはいえ、それを勘案しても実際に低いのも事実だが。
https://w3techs.com/technologies/topsite/javascript_library
実際はじきに結論がでるから待てばいい。
予想するなら、version3に上げている連中(6.4%)は今後とも使う気なのだと思う。
今だにversion1を使っている(=バージョンを上げてまで使う気はない)のが大半(85.7%)で、
つまり大半は様子見中で、だからこそこの話に食いつく奴が多い。
https://w3techs.com/technologies/details/js-jquery/all/all
このサイトのシェアはサイト数で算出しているから、
どうしてもvue等の「アプリ」用フレームワークは低く出る。
とはいえ、それを勘案しても実際に低いのも事実だが。
https://w3techs.com/technologies/topsite/javascript_library
852デフォルトの名無しさん
2019/01/15(火) 20:21:33.86ID:JZTSzU8d > 実際はじきに結論がでるから待てばいい。
いつでるんだよ・・・もう3年経ってるぞ
いつでるんだよ・・・もう3年経ってるぞ
853デフォルトの名無しさん
2019/01/15(火) 20:33:42.53ID:XcHWZlYr854デフォルトの名無しさん
2019/01/15(火) 20:40:39.71ID:JZTSzU8d シェアを気にしてるんじゃないんだよ。合理的な判断から。
ウェブの大半を占めるウェブサイトを作ってるのはウェブデザイナーが大半で
ウェブアプリを開発してるのはごく一部。そんなところにプログラミングが主である
React、Angular、Vueが普及するわけもなく、殆どは軽い使い方しかしてないんだから
jQueryで必要十分だってこと
シェアは単にそれを証明している指標に過ぎない
ウェブの大半を占めるウェブサイトを作ってるのはウェブデザイナーが大半で
ウェブアプリを開発してるのはごく一部。そんなところにプログラミングが主である
React、Angular、Vueが普及するわけもなく、殆どは軽い使い方しかしてないんだから
jQueryで必要十分だってこと
シェアは単にそれを証明している指標に過ぎない
855デフォルトの名無しさん
2019/01/15(火) 21:23:45.38ID:o/u10+7j これからはBackboneや!
これからはEmberや!
これからはKnockoutや!
これからはAngular1や!
フレームワーク使ってるほうが死亡してるんだけどな
これからはEmberや!
これからはKnockoutや!
これからはAngular1や!
フレームワーク使ってるほうが死亡してるんだけどな
856デフォルトの名無しさん
2019/01/15(火) 21:26:47.44ID:XcHWZlYr >>854
サイト数で言えば「ドキュメント」が多いだけで、
トラフィックの大半は「アプリ」ないしはニュースサイト等の「軽量アプリ+DB」だよ。
つかそれ前にも言ったけど、お前普段どんなサイトを見てるんだよまじで。
とりあえず単純に定義しておくと、以下な。
アプリ: ajaxやPOST使いまくり
軽量アプリ: POST機能はあるが主ではない
ドキュメント: ajaxやPOSTは全くない
サイト数で言えば「ドキュメント」が多いだけで、
トラフィックの大半は「アプリ」ないしはニュースサイト等の「軽量アプリ+DB」だよ。
つかそれ前にも言ったけど、お前普段どんなサイトを見てるんだよまじで。
とりあえず単純に定義しておくと、以下な。
アプリ: ajaxやPOST使いまくり
軽量アプリ: POST機能はあるが主ではない
ドキュメント: ajaxやPOSTは全くない
857デフォルトの名無しさん
2019/01/15(火) 21:31:34.93ID:+Q2URMA7 >>856
そんな定義初めて見たわ
そんな定義初めて見たわ
858デフォルトの名無しさん
2019/01/15(火) 21:31:43.02ID:o/u10+7j トラフィックの大半は映像、JavaScript関係ないがな
世界のインターネットトラフィックの過半数を「映像視聴」が占めている
https://gigazine.net/news/20181003-global-internet-downstream/
世界のインターネットトラフィックの過半数を「映像視聴」が占めている
https://gigazine.net/news/20181003-global-internet-downstream/
859デフォルトの名無しさん
2019/01/15(火) 21:41:47.16ID:XcHWZlYr >>858
ああ、まあそりゃそうだ。
ただ、その手のサイトは普通「アプリ」だと思うぞ。
が、まあ、それなら、ダウンストリームを除いて、アップトラフィック、で測るべきだな。
回線速度サイト等で言う、「上り回線」内のトラフィック数だ。
(映像視聴中もping的なアップトラフィックがあるのは知っているが、それらは除いて)
ああ、まあそりゃそうだ。
ただ、その手のサイトは普通「アプリ」だと思うぞ。
が、まあ、それなら、ダウンストリームを除いて、アップトラフィック、で測るべきだな。
回線速度サイト等で言う、「上り回線」内のトラフィック数だ。
(映像視聴中もping的なアップトラフィックがあるのは知っているが、それらは除いて)
860デフォルトの名無しさん
2019/01/15(火) 21:48:27.78ID:XcHWZlYr861デフォルトの名無しさん
2019/01/15(火) 21:49:57.09ID:o/u10+7j >>859
連想ゲームやってるんじゃねーんだ
トラフィックが多いのは映像
映像はアプリ
アプリはJavaScriptを使ってる
だからトラフィックが多いのはJavaScript
違うからな。
ゲームで考えてみろ。多いのはデータであって
プログラムじゃねぇ
連想ゲームやってるんじゃねーんだ
トラフィックが多いのは映像
映像はアプリ
アプリはJavaScriptを使ってる
だからトラフィックが多いのはJavaScript
違うからな。
ゲームで考えてみろ。多いのはデータであって
プログラムじゃねぇ
862デフォルトの名無しさん
2019/01/15(火) 21:56:31.56ID:XcHWZlYr863デフォルトの名無しさん
2019/01/15(火) 22:31:29.43ID:Jm3tkwyg LayeredAPI使って帯域節約していきましょうってことでしょ
864デフォルトの名無しさん
2019/01/15(火) 22:56:55.97ID:panAyOn8865デフォルトの名無しさん
2019/01/15(火) 23:01:45.06ID:+Q2URMA7 >>860
オレオレ定義で妄想おつ
オレオレ定義で妄想おつ
866デフォルトの名無しさん
2019/01/16(水) 06:46:16.07ID:2Lqji3T2 な? >>864のように声だけデカイんだよ
867デフォルトの名無しさん
2019/01/19(土) 03:47:07.72ID:pxg53bXv list.map(x => new Hoge(x))
これを
list.map(Hoge)
みたいに書きたいんですが出来ませんか?
staticでファクトリーメソッド実装するしかない?
これを
list.map(Hoge)
みたいに書きたいんですが出来ませんか?
staticでファクトリーメソッド実装するしかない?
868デフォルトの名無しさん
2019/01/19(土) 06:14:08.63ID:xhDg2W2P >>867
const Hoge = class {
constructor(a) {
this.a = a;
}
}
const hogeProxy = new Proxy(Hoge, {
get: (target, key) => key === target.name ? x => new target(x) : target[key],
has: (target, key) => (key in target || key === target.name) ? true : false,
})
with (hogeProxy) {
console.log([1, 2, 3].map(Hoge));
}
//=> [Hoge {a: 1}, Hoge {a: 2}, Hoge {a: 3}]
const Hoge = class {
constructor(a) {
this.a = a;
}
}
const hogeProxy = new Proxy(Hoge, {
get: (target, key) => key === target.name ? x => new target(x) : target[key],
has: (target, key) => (key in target || key === target.name) ? true : false,
})
with (hogeProxy) {
console.log([1, 2, 3].map(Hoge));
}
//=> [Hoge {a: 1}, Hoge {a: 2}, Hoge {a: 3}]
869デフォルトの名無しさん
2019/01/19(土) 08:42:38.70ID:NKRnmbDh >>867
class Hoge {
constructor(x) {
this.x = x;
}
}
function foo(Hoge) {
list.map(Hoge);
}
foo(x => new Hoge(x))
class Hoge {
constructor(x) {
this.x = x;
}
}
function foo(Hoge) {
list.map(Hoge);
}
foo(x => new Hoge(x))
870デフォルトの名無しさん
2019/01/19(土) 10:11:49.19ID:61MkY90x871デフォルトの名無しさん
2019/01/19(土) 15:43:36.73ID:wiNfQeeu Ruby では、: で始まるシンボルで、メソッド名を渡すことで、インスタンスメソッドを呼べる
# 数値に変換してから、配列内のすべての数字を足す
puts numbers.map(&:to_i).inject(:+)
# 数値に変換してから、配列内のすべての数字を足す
puts numbers.map(&:to_i).inject(:+)
872デフォルトの名無しさん
2019/01/19(土) 15:58:41.16ID:xhDg2W2P 655 デフォルトの名無しさん sage 2018/10/15(月) 05:44:32.10 ID:5+V16LLD
>>649
メソッドにしておくと select(&::positive?) と書けるという理由だった気がする
657 デフォルトの名無しさん 2018/10/15(月) 09:25:55.90 ID:/ogVl406
>>655
きったねえ文法だなぁw
美しい(笑)
疑似コードがそのまま動く(笑)
&::とかの意味不明な疑似コードがどこにあるってんだよwww
658 デフォルトの名無しさん sage 2018/10/15(月) 10:09:06.69 ID:r7U1tD/N
擬似コードがそのまま動くのはPythonじゃね
関数型言語なら演算子がそのまま第一級関数であることとカリー化を使って data |> select ((>) 0) みたいに書けたりするね
ガチ関数型でなくてもまともなラムダがある言語なら select(x => x > 0) と遥かに見通し良く書ける
Rubyの &:: は極めて驚きが大きく醜悪な機能の一つだね
>>649
メソッドにしておくと select(&::positive?) と書けるという理由だった気がする
657 デフォルトの名無しさん 2018/10/15(月) 09:25:55.90 ID:/ogVl406
>>655
きったねえ文法だなぁw
美しい(笑)
疑似コードがそのまま動く(笑)
&::とかの意味不明な疑似コードがどこにあるってんだよwww
658 デフォルトの名無しさん sage 2018/10/15(月) 10:09:06.69 ID:r7U1tD/N
擬似コードがそのまま動くのはPythonじゃね
関数型言語なら演算子がそのまま第一級関数であることとカリー化を使って data |> select ((>) 0) みたいに書けたりするね
ガチ関数型でなくてもまともなラムダがある言語なら select(x => x > 0) と遥かに見通し良く書ける
Rubyの &:: は極めて驚きが大きく醜悪な機能の一つだね
873デフォルトの名無しさん
2019/01/19(土) 16:23:10.62ID:NKRnmbDh >>871
> Ruby では、: で始まるシンボルで、メソッド名を渡すことで、インスタンスメソッドを呼べる
シンボルってただの文字列と変わらないからね
定義しなくて使えるから、タイポしてもエラーになるわけじゃないし
> Ruby では、: で始まるシンボルで、メソッド名を渡すことで、インスタンスメソッドを呼べる
シンボルってただの文字列と変わらないからね
定義しなくて使えるから、タイポしてもエラーになるわけじゃないし
874デフォルトの名無しさん
2019/01/19(土) 16:34:18.49ID:TO8T1N5e >>867ですがいろいろとありがとうございます。
list.map(Number)ができるならlist.map(Hoge)もできるんじゃないかと思ったのですが、一筋縄では行かないようですね
おうちゃくせずに素直に仮引数つけます
list.map(Number)ができるならlist.map(Hoge)もできるんじゃないかと思ったのですが、一筋縄では行かないようですね
おうちゃくせずに素直に仮引数つけます
875デフォルトの名無しさん
2019/01/19(土) 16:57:46.13ID:TeWxng+0 昔はコンストラクタがただの関数だったから、class構文にしなきゃできるな
es5にトランスパイルすればいける
es5にトランスパイルすればいける
876デフォルトの名無しさん
2019/01/19(土) 17:01:01.38ID:ukgk9vnp >>875
なるほどね。何のこっちゃと思ったがそういうことか。
なるほどね。何のこっちゃと思ったがそういうことか。
877デフォルトの名無しさん
2019/01/19(土) 17:17:55.46ID:SwmccsG2 コンパイラエラー C2872 あいまいなシンボルです。
コンパイルエラーが解消出来ません。
ご教授下さい。
■コンパイルエラー内容
error C2872: 'MarketplaceWebServiceProducts' : あいまいなシンボルです
■やりたいこと
AmazonのAPI「Marketplace Web Service API (MWS)」のHello world
以下ページの右上 オレンジ色の「Download」ボタンから入手できる
「MWSProducts_2011-10-01_v2017-03-22.dll」の使用
https://developer.amazonservices.jp/doc/products/products/v20111001/cSharp.html
■DLLの使用
Visual Studioの対象プロジェクトのプロパティから、
上記DLLの参照を追加しました
■コーディング
using namespace MarketplaceWebServiceProducts;//←ここはコンパイルOK
using namespace MarketplaceWebServiceProducts::Mock;//←★ここで上記コンパイルエラー
■ご質問
上位の「MarketplaceWebServiceProducts」が正常なのに、
下位の「Mock」を付けるとあいまいなシンボルになるのはなぜでしょうか。
解決策をご教授ください。(可能であれば実装をご提供ください)
■環境
Visual Studio
.Net 4.0
C++/Cli
コンパイルエラーが解消出来ません。
ご教授下さい。
■コンパイルエラー内容
error C2872: 'MarketplaceWebServiceProducts' : あいまいなシンボルです
■やりたいこと
AmazonのAPI「Marketplace Web Service API (MWS)」のHello world
以下ページの右上 オレンジ色の「Download」ボタンから入手できる
「MWSProducts_2011-10-01_v2017-03-22.dll」の使用
https://developer.amazonservices.jp/doc/products/products/v20111001/cSharp.html
■DLLの使用
Visual Studioの対象プロジェクトのプロパティから、
上記DLLの参照を追加しました
■コーディング
using namespace MarketplaceWebServiceProducts;//←ここはコンパイルOK
using namespace MarketplaceWebServiceProducts::Mock;//←★ここで上記コンパイルエラー
■ご質問
上位の「MarketplaceWebServiceProducts」が正常なのに、
下位の「Mock」を付けるとあいまいなシンボルになるのはなぜでしょうか。
解決策をご教授ください。(可能であれば実装をご提供ください)
■環境
Visual Studio
.Net 4.0
C++/Cli
878デフォルトの名無しさん
2019/01/19(土) 17:43:38.99ID:TqFwYkHH スレタイ音読
879デフォルトの名無しさん
2019/01/19(土) 18:28:01.65ID:wiNfQeeu >本当にありがとうございます!!!!!!!!!!!!
>キモヲタ万歳!!!!!!キモヲタ役に立つ!!!!!!!!
この質問者は、荒らしだから、無視しろ!
>キモヲタ万歳!!!!!!キモヲタ役に立つ!!!!!!!!
この質問者は、荒らしだから、無視しろ!
880デフォルトの名無しさん
2019/01/19(土) 19:13:31.85ID:42e10N7I881デフォルトの名無しさん
2019/01/19(土) 19:25:13.47ID:ZDGn0g7S だから場合分けするんだよ
882デフォルトの名無しさん
2019/01/19(土) 19:30:47.77ID:42e10N7I Hogeの方で工夫するのならスタティックメソッドを生やすのとえっと変わらんじゃん
もしくはHoge.aryFrom(list) みたいなの用意してもいいんだし
もしくはHoge.aryFrom(list) みたいなの用意してもいいんだし
883デフォルトの名無しさん
2019/01/19(土) 19:33:39.03ID:NKRnmbDh はは、Rubyじゃあるまいし、カッコつけないと
関数呼び出しにならないのに、どうやって場合分けするっていうんだ
はは
関数呼び出しにならないのに、どうやって場合分けするっていうんだ
はは
884デフォルトの名無しさん
2019/01/19(土) 19:39:24.01ID:ZDGn0g7S886デフォルトの名無しさん
2019/01/20(日) 00:27:30.68ID:40HwJ7d/ > list.map(x => new Hoge(x))
> これを
> list.map(Hoge)
> みたいに書きたいんですが出来ませんか?
Hogeのどこが関数なの?
関数っていうのはHoge()ってやらないといけないんだよ?
ほんとうに情けないんわ
> これを
> list.map(Hoge)
> みたいに書きたいんですが出来ませんか?
Hogeのどこが関数なの?
関数っていうのはHoge()ってやらないといけないんだよ?
ほんとうに情けないんわ
887デフォルトの名無しさん
2019/01/20(日) 00:37:29.30ID:62lK6b9v const double = n => n * 2;
[1, 2, 3].map(double);
//=> [2, 4, 6]
ワロタwww
>>886によるとこのdoubleは関数じゃないらしいw
double(1)みたいな呼び出しじゃないからだってwwwww
[1, 2, 3].map(double);
//=> [2, 4, 6]
ワロタwww
>>886によるとこのdoubleは関数じゃないらしいw
double(1)みたいな呼び出しじゃないからだってwwwww
888デフォルトの名無しさん
2019/01/20(日) 00:42:24.82ID:62lK6b9v class Hoge {
constructor(x) {
this.x = x;
}
}
console.log(typeof Hoge);
//=> function
> Hogeのどこが関数なの?
wwwww
constructor(x) {
this.x = x;
}
}
console.log(typeof Hoge);
//=> function
> Hogeのどこが関数なの?
wwwww
889デフォルトの名無しさん
2019/01/20(日) 01:16:35.87ID:U54SgNBZ >>888
お前はこの意味がわかってないんだな
> 関数形式で呼ばれたか、コンストラクタとして呼ばれたかで分けるってことだよ
list.map(Hoge) のHogeは
関数形式で呼ばれたか、コンストラクタとして呼ばれたか
どっちか言ってみ
お前はこの意味がわかってないんだな
> 関数形式で呼ばれたか、コンストラクタとして呼ばれたかで分けるってことだよ
list.map(Hoge) のHogeは
関数形式で呼ばれたか、コンストラクタとして呼ばれたか
どっちか言ってみ
890デフォルトの名無しさん
2019/01/20(日) 01:58:00.54ID:62lK6b9v そんな雑魚レス見てないし関係ない。
> 関数っていうのはHoge()ってやらないといけないんだよ?
これは恥ずかしい誤りwww
反例
[1, 2, 3].forEach(console.log)
> 関数っていうのはHoge()ってやらないといけないんだよ?
これは恥ずかしい誤りwww
反例
[1, 2, 3].forEach(console.log)
891デフォルトの名無しさん
2019/01/20(日) 05:48:06.80ID:y/Svh0b0 spanやdivのクリックイベントを、buttonと同じ要素に出来ないでしょうか?
コンソールでイベントを確認すると、currentTargetが
divはHTMLParagraphElementで、buttonはHTMLButtonElementになっています。
CSSでdivタグをボタン風にしていることもあるので、
Javascript上でもボタン扱いしたいのですが、書き方次第で変更できるのでしょうか?
コンソールでイベントを確認すると、currentTargetが
divはHTMLParagraphElementで、buttonはHTMLButtonElementになっています。
CSSでdivタグをボタン風にしていることもあるので、
Javascript上でもボタン扱いしたいのですが、書き方次第で変更できるのでしょうか?
892デフォルトの名無しさん
2019/01/20(日) 07:49:29.85ID:U54SgNBZ >>890
なんだ?お前重箱の隅ばかりついて、
関数形式で呼ばれたか、コンストラクタとして呼ばれたかで分けても
元の質問者の希望である
list.map(Hoge) とはかけないってことに
まだ気づいてないのか?
なんだ?お前重箱の隅ばかりついて、
関数形式で呼ばれたか、コンストラクタとして呼ばれたかで分けても
元の質問者の希望である
list.map(Hoge) とはかけないってことに
まだ気づいてないのか?
893デフォルトの名無しさん
2019/01/20(日) 07:51:00.80ID:U54SgNBZ894デフォルトの名無しさん
2019/01/20(日) 09:12:39.85ID:fBsdchbe895デフォルトの名無しさん
2019/01/20(日) 10:08:42.25ID:U54SgNBZ >>891
> CSSでdivタグをボタン風にしていることもあるので、
> Javascript上でもボタン扱いしたいのですが、書き方次第で変更できるのでしょうか?
そもそもdivタグをボタンにするのが間違い。
そこにクリックできるボタンがあるのなら、ボタンで作るのが正しい
見た目はCSSで変える。何がほしいか?ボタンがほしいならボタンを使う。それだけのこと
> CSSでdivタグをボタン風にしていることもあるので、
> Javascript上でもボタン扱いしたいのですが、書き方次第で変更できるのでしょうか?
そもそもdivタグをボタンにするのが間違い。
そこにクリックできるボタンがあるのなら、ボタンで作るのが正しい
見た目はCSSで変える。何がほしいか?ボタンがほしいならボタンを使う。それだけのこと
896デフォルトの名無しさん
2019/01/20(日) 10:15:54.36ID:z7e/RJqb897デフォルトの名無しさん
2019/01/20(日) 12:26:13.71ID:CrxCXx63 >>896
ボタンにa要素はお勧めしない
ボタンにa要素はお勧めしない
898デフォルトの名無しさん
2019/01/20(日) 15:35:58.63ID:pkTQkmr2 >divはHTMLParagraphElementで、buttonはHTMLButtonElementになっています
多分どちらも、HTMLElement から派生したクラスじゃないの?
Vue.js では、ルーター用のリンクを、<a> タグ以外にも変えられる
<router-link to="/foo" tag="li">foo</router-link>
<!-- 以下のように描画されます -->
<li>foo</li>
tag="button" で、ボタンにもできる
多分どちらも、HTMLElement から派生したクラスじゃないの?
Vue.js では、ルーター用のリンクを、<a> タグ以外にも変えられる
<router-link to="/foo" tag="li">foo</router-link>
<!-- 以下のように描画されます -->
<li>foo</li>
tag="button" で、ボタンにもできる
899デフォルトの名無しさん
2019/01/20(日) 23:43:12.79ID:y/Svh0b0 >>893-894
そういうことではなく、divをクリックしたら
Javascript的に「これはボタン要素です」って認識させたいんです。
>>895-896
確かにそうなんですが、UIとかボタンじゃないほうが良い場合が多々あるんです。
でもデザイン的にボタン風が良いので、spanやdivで代用します。(よく利用されています
<a href="javascript::void(0);" class="button">ボタン</a>で、a要素をボタンにもできますが、
aは使いにくいんですよね。やっぱりデザイン的に使いたいだけなんで、spanかdivなんです。
>>898
Vue.jsは知りませんが、イメージとしてはそういうことがしたいです。
HTML5とかJavascriptとかjQueryとかで可能なら一番なのですが・・・
そういうことではなく、divをクリックしたら
Javascript的に「これはボタン要素です」って認識させたいんです。
>>895-896
確かにそうなんですが、UIとかボタンじゃないほうが良い場合が多々あるんです。
でもデザイン的にボタン風が良いので、spanやdivで代用します。(よく利用されています
<a href="javascript::void(0);" class="button">ボタン</a>で、a要素をボタンにもできますが、
aは使いにくいんですよね。やっぱりデザイン的に使いたいだけなんで、spanかdivなんです。
>>898
Vue.jsは知りませんが、イメージとしてはそういうことがしたいです。
HTML5とかJavascriptとかjQueryとかで可能なら一番なのですが・・・
900デフォルトの名無しさん
2019/01/20(日) 23:53:43.09ID:enluc8/B そもそもJSにdivをbuttonとして誤認識させた後に何をしたいのかがよくわからないけど、どうしてもHTMLButtonElementにしたいってのが目的ならそういうコンバーターなり何なりを作るしかないんじゃないの
901デフォルトの名無しさん
2019/01/21(月) 00:11:05.42ID:oLr+arIk >>899
意味不明。初心者が馬鹿やろうとしてるとしか。
JavaScriptも24年の歴史があり、広く使われているのだから、
初心者が思いつくようなところで今更困ることはほぼ無い。
それはやり方を間違えているだけ。
多分CSSについて勉強した方がいい。
意味不明。初心者が馬鹿やろうとしてるとしか。
JavaScriptも24年の歴史があり、広く使われているのだから、
初心者が思いつくようなところで今更困ることはほぼ無い。
それはやり方を間違えているだけ。
多分CSSについて勉強した方がいい。
902デフォルトの名無しさん
2019/01/21(月) 00:55:24.42ID:DW5LJSe/ この世にIEという存在がなければそんな変なことは考えないのですが、
IEの利用者がまだいてbuttonのクリックイベントと、divのクリックイベントでは
差異があるので、なんとかしようと考えた次第です。
とりあえず「簡単にはできないし、まず無理」という結論であればそれを受け入れます。
IEの利用者がまだいてbuttonのクリックイベントと、divのクリックイベントでは
差異があるので、なんとかしようと考えた次第です。
とりあえず「簡単にはできないし、まず無理」という結論であればそれを受け入れます。
903デフォルトの名無しさん
2019/01/21(月) 01:12:29.24ID:oLr+arIk >>902
馬鹿乙
IEなんて大昔からあるだろ。
それが本当に必要なら、誰かが既に開発して、それこそjQueryにでも搭載されてるよ。
無い=要らない、ってことなんだよ。初心者ならやり方を間違ってるだけ。
馬鹿乙
IEなんて大昔からあるだろ。
それが本当に必要なら、誰かが既に開発して、それこそjQueryにでも搭載されてるよ。
無い=要らない、ってことなんだよ。初心者ならやり方を間違ってるだけ。
904デフォルトの名無しさん
2019/01/21(月) 01:17:37.84ID:WT3LElYg 挙動を統一したいならCanvasでやれ
そういうフレームワークも増えてきてる
そういうフレームワークも増えてきてる
905デフォルトの名無しさん
2019/01/21(月) 05:38:32.19ID:VYjLMLtx906デフォルトの名無しさん
2019/01/21(月) 07:58:41.38ID:vkfJXJ7K カード型みたいにボックスの中に画像、タイトル、アイコン、とかいろんな要素があって
そのカードがボタンの役割をしているならdivでもいいんじゃないの?
むしろbuttonタグの中にdivやらspanやら、iとかいろいろ要素ぶっ込むものなのかね?
そのカードがボタンの役割をしているならdivでもいいんじゃないの?
むしろbuttonタグの中にdivやらspanやら、iとかいろいろ要素ぶっ込むものなのかね?
907デフォルトの名無しさん
2019/01/21(月) 08:15:29.19ID:ubpSrO6v ieがdivのクリックイベントを拾わない…?
908デフォルトの名無しさん
2019/01/21(月) 08:30:56.83ID:8RTHI8s9 >>899
UIだけなら、CSSでボタンライクではないようにも変更できるわけでdiv要素を使う理由はない
UIだけなら、CSSでボタンライクではないようにも変更できるわけでdiv要素を使う理由はない
909デフォルトの名無しさん
2019/01/21(月) 09:28:46.72ID:63p0KSKR >>907
Enterキー押下時のclickイベント拾わない話じゃねーかとエスパーしてみる
それは他のブラウザでも同じなので、keydownイベント拾ってEnterキーだけ抽出してclickイベント時と同じ挙動をさせるしかないよね
shift/alt/meta/ctrlキー同時押しはもちろん排除するとしてさ
Enterキー押下時のclickイベント拾わない話じゃねーかとエスパーしてみる
それは他のブラウザでも同じなので、keydownイベント拾ってEnterキーだけ抽出してclickイベント時と同じ挙動をさせるしかないよね
shift/alt/meta/ctrlキー同時押しはもちろん排除するとしてさ
910デフォルトの名無しさん
2019/01/21(月) 12:48:28.69ID:DT8npDQe911デフォルトの名無しさん
2019/01/21(月) 14:19:25.15ID:PNnv4t9U javascriptでreplaceを用いた特定の文字の置換ができないです。
// サーバーからデータを受信したとき
function onReceive(data) {
let json = JSON.parse(data);
let messages = document.getElementById('chat');
let li = document.createElement('li');
if(json.text == 'おい'){
json.text = 'オイオイオイ'
}
// JSONから必要なデータを取り出して、テキストにする
li.innerHTML = json.count + ":" + "<span style='color:green'><big><b>ななしさん</b></big></span>" + "ID:" + socket.id + "<BR>" + json.text;
// 画面に要素を追加する
messages.appendChild(li);
}
これがソースコードの一部です。
このソースコードで、「おい」と打ったら「オイオイオイ」と返ってくるのですが、
「あいうおいえお」と打ったら「あいうおいえお」と返ってきます。
本当は「あいうオイオイオイえお」と返ってきてほしいです。
// サーバーからデータを受信したとき
function onReceive(data) {
let json = JSON.parse(data);
let messages = document.getElementById('chat');
let li = document.createElement('li');
if(json.text == 'おい'){
json.text = 'オイオイオイ'
}
// JSONから必要なデータを取り出して、テキストにする
li.innerHTML = json.count + ":" + "<span style='color:green'><big><b>ななしさん</b></big></span>" + "ID:" + socket.id + "<BR>" + json.text;
// 画面に要素を追加する
messages.appendChild(li);
}
これがソースコードの一部です。
このソースコードで、「おい」と打ったら「オイオイオイ」と返ってくるのですが、
「あいうおいえお」と打ったら「あいうおいえお」と返ってきます。
本当は「あいうオイオイオイえお」と返ってきてほしいです。
912デフォルトの名無しさん
2019/01/21(月) 14:23:43.50ID:DqxQvGU+ replace使ってないから
913デフォルトの名無しさん
2019/01/21(月) 14:27:21.86ID:PNnv4t9U if(json.text == 'おい'){
json.text = 'オイオイオイ'
}
上記の部分を
json.text.replace('おい','オイオイオイ')
にしたら何も表示されなくなってしまいました。
json.text = 'オイオイオイ'
}
上記の部分を
json.text.replace('おい','オイオイオイ')
にしたら何も表示されなくなってしまいました。
914デフォルトの名無しさん
2019/01/21(月) 14:31:42.02ID:DqxQvGU+915デフォルトの名無しさん
2019/01/21(月) 14:39:13.61ID:PNnv4t9U916デフォルトの名無しさん
2019/01/21(月) 14:40:34.76ID:PNnv4t9U917デフォルトの名無しさん
2019/01/21(月) 14:45:16.85ID:DqxQvGU+ replaceってヒントを貰ってるんだから、replaceについて調べればいいだけ
918デフォルトの名無しさん
2019/01/21(月) 16:01:51.07ID:PNnv4t9U919デフォルトの名無しさん
2019/01/21(月) 16:05:59.24ID:DqxQvGU+ 無能ってすぐ人に答えを求めるよな
https://medaka.5ch.net/test/read.cgi/prog/1540885252/
やっぱり俺って有能なんだなあ
すぐ人に答えを求めたりしないしな
https://medaka.5ch.net/test/read.cgi/prog/1540885252/
やっぱり俺って有能なんだなあ
すぐ人に答えを求めたりしないしな
920デフォルトの名無しさん
2019/01/21(月) 17:34:06.91ID:UEk4ntQa # 詳しい人、知恵を貸してくれ。
div1 = document.createElement("div")、document.body.appendChild(div1)
として、div1 の style の position を absolute や fixed として、
style.top, style.left に座標を指定しても、以下のような affiliate がある場合、
newBox の margin の 100px と全く同じだけ、div1 の位置が下に下がってしまう。
仕様上は、position:absolute は、親要素であるところの body 要素の左上の点からの
相対位置で指定されるはずなのに、なぜだろう?
自分の理解では、以下の affiliate は、div1 などのもっとも年上の兄弟として
追加されるだけだから、div1 の位置には影響を与えないと思うんだが。
var func = function(){
var parent = document.getElementsByTagName("body")[0];
var newBox = document.createElement("div");
newBox.setAttribute('id', 'vdbanner');
newBox.setAttribute("style","display:block!important;position:relative!important;top:0!important;left:0!important;margin:100px 0 !important;padding:0!important;text-align:center!important;");
newBox.innerHTML = "広告内容";
parent.insertBefore(newBox, parent.firstChild);
}
try {
window.addEventListener("load", func, false);
}
catch(e) {
window.attachEvent("onload", func);
}
div1 = document.createElement("div")、document.body.appendChild(div1)
として、div1 の style の position を absolute や fixed として、
style.top, style.left に座標を指定しても、以下のような affiliate がある場合、
newBox の margin の 100px と全く同じだけ、div1 の位置が下に下がってしまう。
仕様上は、position:absolute は、親要素であるところの body 要素の左上の点からの
相対位置で指定されるはずなのに、なぜだろう?
自分の理解では、以下の affiliate は、div1 などのもっとも年上の兄弟として
追加されるだけだから、div1 の位置には影響を与えないと思うんだが。
var func = function(){
var parent = document.getElementsByTagName("body")[0];
var newBox = document.createElement("div");
newBox.setAttribute('id', 'vdbanner');
newBox.setAttribute("style","display:block!important;position:relative!important;top:0!important;left:0!important;margin:100px 0 !important;padding:0!important;text-align:center!important;");
newBox.innerHTML = "広告内容";
parent.insertBefore(newBox, parent.firstChild);
}
try {
window.addEventListener("load", func, false);
}
catch(e) {
window.attachEvent("onload", func);
}
921デフォルトの名無しさん
2019/01/21(月) 17:53:37.90ID:DqxQvGU+ 長ったらしいので翻訳。まずimportant;は使うな
#vdbanner {
display: block !important;
position: relative !important;
top: 0 !important;
left: 0 !important;
margin: 100px 0 !important;
padding: 0 !important;
text-align: center !important;
}
$(function() {
$("<div/>", {id: 'vdbanner', text: '広告内容'}).prependTo('body');
});
#vdbanner {
display: block !important;
position: relative !important;
top: 0 !important;
left: 0 !important;
margin: 100px 0 !important;
padding: 0 !important;
text-align: center !important;
}
$(function() {
$("<div/>", {id: 'vdbanner', text: '広告内容'}).prependTo('body');
});
922デフォルトの名無しさん
2019/01/21(月) 17:59:05.34ID:PNnv4t9U できたぞ、質問に答えられないバカ
var result = json.text
for(var i=0;i<json.text.length;i++){
if(json.text[i] == 'お' && json.text[i+1]=='い'){
var tagetString = json.text;
var reString = /おい/gi; // 複数を置換する時は"g"を、
// 大文字/小文字の区別をしない場合には"i"を指定します。
var repStrung = "オイオイオイ";
result = tagetString.replace(reString, repStrung);
}
}
じゃあな無能
var result = json.text
for(var i=0;i<json.text.length;i++){
if(json.text[i] == 'お' && json.text[i+1]=='い'){
var tagetString = json.text;
var reString = /おい/gi; // 複数を置換する時は"g"を、
// 大文字/小文字の区別をしない場合には"i"を指定します。
var repStrung = "オイオイオイ";
result = tagetString.replace(reString, repStrung);
}
}
じゃあな無能
923デフォルトの名無しさん
2019/01/21(月) 18:04:30.32ID:DqxQvGU+ 一行で書けるけど、じゃあなって言われたな。じゃあなwwww
924デフォルトの名無しさん
2019/01/21(月) 18:29:08.32ID:mEBdwP2z >>899
ボタン部分だけのクリックじゃなくて、
もう少し範囲を広くして、ボタンを含む、div で、クリックイベントを動作させたいのかね?
ボタン部分だけだと、範囲が狭くて、うまく押せない人がいるから
それと投稿者は、次に投稿する際に、名前欄に最初の投稿のレス番号を入れてくれ
ボタン部分だけのクリックじゃなくて、
もう少し範囲を広くして、ボタンを含む、div で、クリックイベントを動作させたいのかね?
ボタン部分だけだと、範囲が狭くて、うまく押せない人がいるから
それと投稿者は、次に投稿する際に、名前欄に最初の投稿のレス番号を入れてくれ
925デフォルトの名無しさん
2019/01/21(月) 18:34:04.07ID:mEBdwP2z926デフォルトの名無しさん
2019/01/21(月) 18:36:35.58ID:mEBdwP2z >>920
web の質問は、こちらの板ではなく、web制作管理板の方へ書き込んでください!
web の質問は、こちらの板ではなく、web制作管理板の方へ書き込んでください!
927デフォルトの名無しさん
2019/01/21(月) 18:37:59.67ID:/g0A2C06 >>922 は酷いコードだなあ
928デフォルトの名無しさん
2019/01/21(月) 18:53:53.44ID:UEk4ntQa929デフォルトの名無しさん
2019/01/21(月) 18:59:45.68ID:x6DE2oRu930デフォルトの名無しさん
2019/01/21(月) 19:03:58.42ID:UOzXXkDM >>922
var result = json.text.replace('おい', 'オイオイオイ')
var result = json.text.replace('おい', 'オイオイオイ')
931デフォルトの名無しさん
2019/01/21(月) 22:12:37.48ID:XPYcyOEd >>930
それを複数個作るとエラーが出るんです。
それを複数個作るとエラーが出るんです。
932デフォルトの名無しさん
2019/01/21(月) 22:20:46.95ID:UOzXXkDM >>931
var result = json.text.replace(/おい/g, 'オイオイオイ')
var result = json.text.replace(/おい/g, 'オイオイオイ')
933デフォルトの名無しさん
2019/01/21(月) 23:50:10.62ID:30QJt/vt ES6で新たに導入された式や文は
ES5.1の構文糖衣と考えて良いの?
ES5.1の構文糖衣と考えて良いの?
934デフォルトの名無しさん
2019/01/21(月) 23:51:40.65ID:DqxQvGU+ 「ES5.1の構文糖衣」という表現がおかしい
935デフォルトの名無しさん
2019/01/22(火) 06:53:00.52ID:dHPHLM6Z Class構文は再現できないので糖衣構文ではない
936デフォルトの名無しさん
2019/01/22(火) 09:26:06.80ID:QhWv4dIw >>935
> ECMAScript 2015 で導入された JavaScript クラスは、
> JavaScript にすでにあるプロトタイプベース継承の糖衣構文です。
> クラス構文は、新しいオブジェクト指向継承モデルを JavaScript に導入しているわけではありません。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Classes
> ECMAScript 2015 で導入された JavaScript クラスは、
> JavaScript にすでにあるプロトタイプベース継承の糖衣構文です。
> クラス構文は、新しいオブジェクト指向継承モデルを JavaScript に導入しているわけではありません。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Classes
937デフォルトの名無しさん
2019/01/22(火) 09:32:15.42ID:zKxMKaTe クラス構文だと関数で呼べないから違うものを導入してるよね
938デフォルトの名無しさん
2019/01/22(火) 10:20:50.82ID:SJtsjRub 糖衣構文かどうかにこだわるのってなんでだろう?
マウント取りたいだけな気がする
マウント取りたいだけな気がする
939デフォルトの名無しさん
2019/01/22(火) 12:50:28.60ID:RZTSN9tm940デフォルトの名無しさん
2019/01/22(火) 14:53:55.47ID:SJtsjRub なんかそもそも糖衣構文という言葉をわかってないやつがいるみたいだ
糖衣構文の条件
× ECMAScript 2015で書いたのと同等のことを、ES5で(複雑に)書けること
○ ES5で書いたのと同等のことを、ECMAScript 2015で(シンプルに)書けること
>>939
お前変換の向きが逆
糖衣構文の条件
× ECMAScript 2015で書いたのと同等のことを、ES5で(複雑に)書けること
○ ES5で書いたのと同等のことを、ECMAScript 2015で(シンプルに)書けること
>>939
お前変換の向きが逆
941デフォルトの名無しさん
2019/01/22(火) 15:28:28.10ID:RZTSN9tm それは絶対に違うね
新しい構文というのは問題を新しく解決する為に入れられるわけで
古いコードで書いてたコードがシンプルに書けるようになるものでない方が珍しい
そんな事を語っても仕方がない
古いコードで再現できるかどうかの方が意味がある
新しい構文というのは問題を新しく解決する為に入れられるわけで
古いコードで書いてたコードがシンプルに書けるようになるものでない方が珍しい
そんな事を語っても仕方がない
古いコードで再現できるかどうかの方が意味がある
942デフォルトの名無しさん
2019/01/22(火) 16:20:43.54ID:SJtsjRub また意味不明な
新しい構文の中で従来では複雑な書き方だったものを
シンプルに書けるようにしたものを特別に糖衣構文とよぶんだろ
誰が新しい構文はすべて糖衣構文って言ったんだ?
誰も言ってないだろ
新しい構文の中で従来では複雑な書き方だったものを
シンプルに書けるようにしたものを特別に糖衣構文とよぶんだろ
誰が新しい構文はすべて糖衣構文って言ったんだ?
誰も言ってないだろ
943デフォルトの名無しさん
2019/01/22(火) 18:15:41.76ID:ADfWWjFL シンタックスシュガーがあるならシンタックスヌガーとかシンタックスハニーがあってもおかしくないよね
944デフォルトの名無しさん
2019/01/22(火) 18:31:09.00ID:bOf9tfZi シンタクティックシュガーな。
945デフォルトの名無しさん
2019/01/22(火) 19:07:04.65ID:dHPHLM6Z >>942
度合いの問題だ
「ほぼシンプルに書けるようにすることが目的で導入されたもの」を糖衣構文と呼ぶのは分かる
ほかの要素を無視できるという意味での「ほぼ」だ
そうするとそのほぼというのは例えば感覚で8割〜9割としよう
しかしClass構文でのその目的、重要度はせいぜい6〜7割だということを言ってる
Class構文は従来__proto__を使わないとできなかったスタティックとプロトタイプメソッド両方の継承ということができる
これが俺にとって重要度・構文価値の〜1/10
さらにnewTargetの存在によりビルトインクラスの継承ができるようになった
これが俺にとって重要度・構文価値の〜3/10
少なくともこういう要素はClass構文を語る上で無視できる存在ではないだろう?
そうすると一般にClass構文は糖衣構文ということはできないというのが俺の主張だ
なのでそう言いたいのならコンテキストを絞った上で言わなければいけない
今回の場合も、もし「ES6で新たに導入された式や文は ES5.1の構文糖衣と考えて良い」と答えると
そういうClass構文などの無視できない重要なポイントを気にしていない、
下手すると気にしなくていいという発言になってしまうだろう?
君はそこを取るに足らないポイントだと考えるから、そう言えるんだろうが、
俺は>>933にそこももっと知っておいてほしい、説明したいと思うんだよ
そういう違いさ
度合いの問題だ
「ほぼシンプルに書けるようにすることが目的で導入されたもの」を糖衣構文と呼ぶのは分かる
ほかの要素を無視できるという意味での「ほぼ」だ
そうするとそのほぼというのは例えば感覚で8割〜9割としよう
しかしClass構文でのその目的、重要度はせいぜい6〜7割だということを言ってる
Class構文は従来__proto__を使わないとできなかったスタティックとプロトタイプメソッド両方の継承ということができる
これが俺にとって重要度・構文価値の〜1/10
さらにnewTargetの存在によりビルトインクラスの継承ができるようになった
これが俺にとって重要度・構文価値の〜3/10
少なくともこういう要素はClass構文を語る上で無視できる存在ではないだろう?
そうすると一般にClass構文は糖衣構文ということはできないというのが俺の主張だ
なのでそう言いたいのならコンテキストを絞った上で言わなければいけない
今回の場合も、もし「ES6で新たに導入された式や文は ES5.1の構文糖衣と考えて良い」と答えると
そういうClass構文などの無視できない重要なポイントを気にしていない、
下手すると気にしなくていいという発言になってしまうだろう?
君はそこを取るに足らないポイントだと考えるから、そう言えるんだろうが、
俺は>>933にそこももっと知っておいてほしい、説明したいと思うんだよ
そういう違いさ
946デフォルトの名無しさん
2019/01/22(火) 19:14:29.74ID:yOIcAU/3947デフォルトの名無しさん
2019/01/22(火) 19:19:26.12ID:yOIcAU/3 そして+αの部分がclassでしか使えないのかといえばそうではなく
classを使わなくても、+αの機能は使えるから
やっぱりclassは糖衣構文
classを使わなくても、+αの機能は使えるから
やっぱりclassは糖衣構文
948デフォルトの名無しさん
2019/01/22(火) 19:33:50.03ID:dHPHLM6Z >>947
Class構文のES5で代替不可能な機能はES6の他のより基本的な機能で代替可能だから、
ES6も入れたら糖衣構文と言ってもいいよ
でも今回はそうじゃないから
ES6の機能が、従来のES5の機能の糖衣構文と言えるかという話だから
その辺り俺は言葉に慎重だが、君は適当
そういう違いさ
Class構文のES5で代替不可能な機能はES6の他のより基本的な機能で代替可能だから、
ES6も入れたら糖衣構文と言ってもいいよ
でも今回はそうじゃないから
ES6の機能が、従来のES5の機能の糖衣構文と言えるかという話だから
その辺り俺は言葉に慎重だが、君は適当
そういう違いさ
949デフォルトの名無しさん
2019/01/22(火) 19:34:52.68ID:hY3Lw6Bc 糖衣構文の反対はキムチ構文って呼ぶってことで
この話題終わりにしませんか?
この話題終わりにしませんか?
950デフォルトの名無しさん
2019/01/22(火) 19:38:42.19ID:dHPHLM6Z951デフォルトの名無しさん
2019/01/22(火) 19:41:39.36ID:ClMLgqLU 言葉に慎重なら糖衣構文っていう和訳も微妙
952デフォルトの名無しさん
2019/01/22(火) 19:54:31.00ID:bOf9tfZi 構文的砂糖
953デフォルトの名無しさん
2019/01/22(火) 20:06:22.32ID:YQBTnTrr954デフォルトの名無しさん
2019/01/22(火) 20:16:41.69ID:YQBTnTrr955デフォルトの名無しさん
2019/01/22(火) 22:05:19.77ID:4TOwjU0o 話変わるけどジェネレーターは糖衣構文じゃないよねさすがに。
956デフォルトの名無しさん
2019/01/22(火) 22:38:28.82ID:dHPHLM6Z >>953,954
意味不明なのはあんただ
俺は0.999だからNoとか0.001だからYesとか言うのは嫌いだし
そういう0か1かで糖衣構文「であるのかどうか」を話す気はない
たとえちょっと変な表現であろうと、今回の話の流れの上で糖衣構文「と呼んだほうが良いか」を
アナログ的に考えて、俺なりの想いを持って方が良い、悪いと話している
また俺はClass限定の話を始めたわけではない
わかりやすい一例としてまずClassでの事実を1つ挙げただけ
そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
変におかしな流れに誘導したのは君の方だよ
少なくとも俺は>>933を俺なりに解釈して話を始めた
そこで君が横から言葉の使い方がどうのこうのヤンヤン言って来ても知らんがなって感じ
君の脳内パーサではエラーが出たんだろうが、それをエラーですエラーですエラーですよって、うるさい目覚まし時計かって感じ
俺のゆるゆるパーサでは通ったんだから俺は話を進める、君は固まっとく、でいいじゃないか
俺までどうにかして止めようとする必要はない、俺はそういうのは嫌いだね
JSでも値をチェックして例外を吐くとかね
値をできるだけ加工したり用意の仕方を工夫して無効な値を極力作らないようにする方が俺は好きだ
ともかく君の定義ではそもそも話がおかしいのはおっしゃる通り
だからこそ俺はその定義は今回はそぐわないとしてるところに、わざわざその破綻する定義を持ってきて
ギーギーガーガーおかしいおかしい言われても しつこいポンコツ機械かよって感じ
まあそんな感じ
意味不明なのはあんただ
俺は0.999だからNoとか0.001だからYesとか言うのは嫌いだし
そういう0か1かで糖衣構文「であるのかどうか」を話す気はない
たとえちょっと変な表現であろうと、今回の話の流れの上で糖衣構文「と呼んだほうが良いか」を
アナログ的に考えて、俺なりの想いを持って方が良い、悪いと話している
また俺はClass限定の話を始めたわけではない
わかりやすい一例としてまずClassでの事実を1つ挙げただけ
そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
変におかしな流れに誘導したのは君の方だよ
少なくとも俺は>>933を俺なりに解釈して話を始めた
そこで君が横から言葉の使い方がどうのこうのヤンヤン言って来ても知らんがなって感じ
君の脳内パーサではエラーが出たんだろうが、それをエラーですエラーですエラーですよって、うるさい目覚まし時計かって感じ
俺のゆるゆるパーサでは通ったんだから俺は話を進める、君は固まっとく、でいいじゃないか
俺までどうにかして止めようとする必要はない、俺はそういうのは嫌いだね
JSでも値をチェックして例外を吐くとかね
値をできるだけ加工したり用意の仕方を工夫して無効な値を極力作らないようにする方が俺は好きだ
ともかく君の定義ではそもそも話がおかしいのはおっしゃる通り
だからこそ俺はその定義は今回はそぐわないとしてるところに、わざわざその破綻する定義を持ってきて
ギーギーガーガーおかしいおかしい言われても しつこいポンコツ機械かよって感じ
まあそんな感じ
957デフォルトの名無しさん
2019/01/22(火) 23:13:06.23ID:YQBTnTrr958デフォルトの名無しさん
2019/01/22(火) 23:13:38.81ID:XoIF472X 頭イカれてるエンジニアによくある回答
959デフォルトの名無しさん
2019/01/22(火) 23:25:49.01ID:k+Ga/jCN 糖衣構文+αじゃなくて、完璧に糖衣構文でしょ
糖衣構文+αだったら糖衣構文とは言わないよ
糖衣構文+αだったら糖衣構文とは言わないよ
960デフォルトの名無しさん
2019/01/22(火) 23:28:26.41ID:IcipLgKo 糖衣構文か否かの議論の果てにどんな結論があるんだろ
961デフォルトの名無しさん
2019/01/22(火) 23:30:12.08ID:Rn6qecVY >>959
同意
同意
962デフォルトの名無しさん
2019/01/22(火) 23:46:44.98ID:5TeSwszl var flagA = false && true || true;
変数flagAがtrueとなるのは、
false && trueがfalseになって、
false || true
true
となるからだと思うのですが、
ひとつ目がfalseなのに何故ショートサーキット評価されないのでしょうか。
最初に末尾まで見てて、&&の後ろがひとつの論理式である時だけショートサーキット評価されるってことですか。
あと、
var flagB = true || false && false;
flagBがtrueになるのは何故ですか。
true || falseがtrueになって、
true && false
false
になると思うんですが。
変数flagAがtrueとなるのは、
false && trueがfalseになって、
false || true
true
となるからだと思うのですが、
ひとつ目がfalseなのに何故ショートサーキット評価されないのでしょうか。
最初に末尾まで見てて、&&の後ろがひとつの論理式である時だけショートサーキット評価されるってことですか。
あと、
var flagB = true || false && false;
flagBがtrueになるのは何故ですか。
true || falseがtrueになって、
true && false
false
になると思うんですが。
963デフォルトの名無しさん
2019/01/23(水) 00:10:25.21ID:djVGMpuO >>959
いうだろ?
ES5で書いたものをclassで完璧に書けるんだぜ?
追加効果があったとしても関係ないだろ
それにそもそも糖衣構文って完全に同じものを
実現しなくてはいけないなんて制限はないんだが?
ほぼすべての糖衣構文はある機能に特化することでより便利にしているが
その反面あるきのう以外のことができなくなってる
他のどんなものが糖衣構文と呼ばれてるか考えてみなよ
糖衣構文という言葉に惑わされてるだけだろ
いうだろ?
ES5で書いたものをclassで完璧に書けるんだぜ?
追加効果があったとしても関係ないだろ
それにそもそも糖衣構文って完全に同じものを
実現しなくてはいけないなんて制限はないんだが?
ほぼすべての糖衣構文はある機能に特化することでより便利にしているが
その反面あるきのう以外のことができなくなってる
他のどんなものが糖衣構文と呼ばれてるか考えてみなよ
糖衣構文という言葉に惑わされてるだけだろ
964デフォルトの名無しさん
2019/01/23(水) 00:11:52.34ID:djVGMpuO965デフォルトの名無しさん
2019/01/23(水) 00:18:30.88ID:eDsfqelL >>962
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Operator_Precedence
論理積と論理和では論理積の方が優先度が高く、短絡評価は論理積と論理和それぞれの評価について行われる
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Operator_Precedence
論理積と論理和では論理積の方が優先度が高く、短絡評価は論理積と論理和それぞれの評価について行われる
966デフォルトの名無しさん
2019/01/23(水) 00:18:39.97ID:djVGMpuO 一つ例を出してやる
C言語でswitch〜caseはifの糖衣構文と呼ばれているが、
ifでやれることのすべてをswitch〜caseでやれるわけじゃない
switch(a) ← 変数aとの比較限定になっている
この点においてswitchはifの制限版
また逆にswitch〜caseのfall throughはifでは実現できない
この点において、switchは糖衣構文+αの機能を持っていると言える
C言語でswitch〜caseはifの糖衣構文と呼ばれているが、
ifでやれることのすべてをswitch〜caseでやれるわけじゃない
switch(a) ← 変数aとの比較限定になっている
この点においてswitchはifの制限版
また逆にswitch〜caseのfall throughはifでは実現できない
この点において、switchは糖衣構文+αの機能を持っていると言える
967デフォルトの名無しさん
2019/01/23(水) 00:20:16.03ID:NPxQuWhQ >>962
ショートサーキットしてる
false && true || trueの二番目のtrueは評価されない
それと後者の答えは優先順位が違うから
&& は||より先に評価される
四則演算でいうと||が足し算で&&はかけ算
ショートサーキットしてる
false && true || trueの二番目のtrueは評価されない
それと後者の答えは優先順位が違うから
&& は||より先に評価される
四則演算でいうと||が足し算で&&はかけ算
969デフォルトの名無しさん
2019/01/23(水) 00:59:58.12ID:GUcVvLjn QZは馬鹿だから無視でおk
「車は右側を走れるか」みたいな話は余計脱線するだけ
「車は右側を走れるか」みたいな話は余計脱線するだけ
970デフォルトの名無しさん
2019/01/23(水) 01:06:50.82ID:djVGMpuO ふむ。まあ要するにES6の機能をES5で実現できれば糖衣構文。
実現できなければ糖衣構文ではない。という定義は
完全に間違っているってことだな
実現できなければ糖衣構文ではない。という定義は
完全に間違っているってことだな
971デフォルトの名無しさん
2019/01/23(水) 01:08:18.69ID:GUcVvLjn972デフォルトの名無しさん
2019/01/23(水) 13:27:42.36ID:1r6euYxZ せっかちなのは君の好きにすればいいけど
勝手に思い込んで突っ走って人に迷惑かけて……
もうクズの見本みたいな振る舞いしてる事に気が付いたほうがいいよ
勿体ないよ
勝手に思い込んで突っ走って人に迷惑かけて……
もうクズの見本みたいな振る舞いしてる事に気が付いたほうがいいよ
勿体ないよ
973デフォルトの名無しさん
2019/01/23(水) 19:36:29.61ID:djVGMpuO 特に言い返すことは無いようで
974デフォルトの名無しさん
2019/01/24(木) 20:07:28.47ID:iWJQcTkX const foo = [1, 3, 5, 7, 9];
const bar = [3];
console.log(foo[bar]); // 7
このコードの意味がよくわかりません
状況からしてbar[0]の3を自動で取り出してfooの添え字にしてるように見えますが、そんな意味不明な動きしますか?
Cでいう*barみたいに配列の先頭アドレスから値を取り出してる??
const bar = [3];
console.log(foo[bar]); // 7
このコードの意味がよくわかりません
状況からしてbar[0]の3を自動で取り出してfooの添え字にしてるように見えますが、そんな意味不明な動きしますか?
Cでいう*barみたいに配列の先頭アドレスから値を取り出してる??
975デフォルトの名無しさん
2019/01/24(木) 20:18:20.31ID:x2HCgLhu976デフォルトの名無しさん
2019/01/24(木) 20:28:18.18ID:iWJQcTkX >>975
すみません、業務で見たコードで、実際にはfoo相当の配列はオブジェクトの配列でした
先のコードは自分で実験用に動かしたコードです
なるほど、添え字に配列変数を指定すると、toStringメソッドが走る
配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
なので要素が数字かつ1つしかなければ、その数字を添字にしたのと同じことになる、ということでしょうか
すみません、業務で見たコードで、実際にはfoo相当の配列はオブジェクトの配列でした
先のコードは自分で実験用に動かしたコードです
なるほど、添え字に配列変数を指定すると、toStringメソッドが走る
配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
なので要素が数字かつ1つしかなければ、その数字を添字にしたのと同じことになる、ということでしょうか
977デフォルトの名無しさん
2019/01/24(木) 20:43:27.11ID:x2HCgLhu >>976
概ねその通りだが、俺は
> 配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
これが仕様なのか環境依存なのかは知らんよ。
いずれにしても、「配列を添字として使う」事自体があり得ないだろ。
糞コードだし、修正すべきだよ。
動いているからバグとして検出されず、結果的に修正漏れになっている、ということかな。
なおその手の詳細な挙動を知りたければ、仕様書を読むしかない。
JavaScriptの仕様書は他言語で言う仕様書ではなく、実装指示書(詳細設計書)といった方が正しい。
だからオグジェクトの配列のアクセスの仕方(セマンティクス)がいちいち細かく書いてある。
その中で原則的には全てtoStringされていたはずなので、結果的にはそういう挙動になる。
つまり、
× > 添え字に配列変数を指定すると、toStringメソッドが走る
○ 添え字は何であれ全てtoStringされる
だったはず。気になるなら仕様書を確認して。
概ねその通りだが、俺は
> 配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
これが仕様なのか環境依存なのかは知らんよ。
いずれにしても、「配列を添字として使う」事自体があり得ないだろ。
糞コードだし、修正すべきだよ。
動いているからバグとして検出されず、結果的に修正漏れになっている、ということかな。
なおその手の詳細な挙動を知りたければ、仕様書を読むしかない。
JavaScriptの仕様書は他言語で言う仕様書ではなく、実装指示書(詳細設計書)といった方が正しい。
だからオグジェクトの配列のアクセスの仕方(セマンティクス)がいちいち細かく書いてある。
その中で原則的には全てtoStringされていたはずなので、結果的にはそういう挙動になる。
つまり、
× > 添え字に配列変数を指定すると、toStringメソッドが走る
○ 添え字は何であれ全てtoStringされる
だったはず。気になるなら仕様書を確認して。
978デフォルトの名無しさん
2019/01/24(木) 20:48:20.57ID:x2HCgLhu × オグジェクトの配列の
○ オグジェクトや配列の
読める範囲ではあるが、若干混乱するかもしれないので念のため。
○ オグジェクトや配列の
読める範囲ではあるが、若干混乱するかもしれないので念のため。
979デフォルトの名無しさん
2019/01/24(木) 20:48:26.62ID:iWJQcTkX980デフォルトの名無しさん
2019/01/24(木) 21:44:28.43ID:iDh5zyV0 オグジェクトを訂正するのかと思った
981デフォルトの名無しさん
2019/01/25(金) 06:27:54.21ID:i+3XWQgy 別にこの程度非難轟々するほどのコードじゃないだろう
暗黙の型変換がたった1回働いてるだけでしかないのだし
添字は必ずシンボルか文字列として評価されるってことも常識として知っておかないといけないこと
この程度にそんなに目くじらを立ててたらJSが読み書きしにくくなるというか
JSは避けてRustで書いてWasmにするとかした方が良いと思う
暗黙の型変換がたった1回働いてるだけでしかないのだし
添字は必ずシンボルか文字列として評価されるってことも常識として知っておかないといけないこと
この程度にそんなに目くじらを立ててたらJSが読み書きしにくくなるというか
JSは避けてRustで書いてWasmにするとかした方が良いと思う
982デフォルトの名無しさん
2019/01/25(金) 11:52:33.10ID:t0q3jFj9 普通にボロカスに言われるコードだと思う
983デフォルトの名無しさん
2019/01/25(金) 13:15:39.10ID:cZ2z9LwS でも文字列を引数にとる既存の関数をタグ付きテンプレートとして呼び出せるのって['foo']が'foo'に変換される仕様のお陰なんだよなぁ
'hogefugapiyo'.split('fuga').join('hage');
↓
'hogefugapiyo'.split`fuga`.join`hage`
意味のないコードだけどあくまで例として。
'hogefugapiyo'.split('fuga').join('hage');
↓
'hogefugapiyo'.split`fuga`.join`hage`
意味のないコードだけどあくまで例として。
984デフォルトの名無しさん
2019/01/25(金) 13:52:06.04ID:dvigx+iy foo = [ 1, 3, 5, 7, 9 ];
bar = [ 3 ];
p foo[ bar ]
Ruby では、エラーになる。
配列から整数への、暗黙の型変換はできない
やっぱり、JS は、バグる。
怖い
bar = [ 3 ];
p foo[ bar ]
Ruby では、エラーになる。
配列から整数への、暗黙の型変換はできない
やっぱり、JS は、バグる。
怖い
985デフォルトの名無しさん
2019/01/25(金) 14:53:54.07ID:UUOT6d+j javascriptでいう関数ひとつ取ってもる〜ピぃは
def
ブロック
Proc.new
proc
lambda
->
用途に合わせてどれが使えどれが使えないのか、使える場合変換は必要かどうか、変換なしで使える場合も挙動がどう異なるのか(同じように使える場合もすこしづつ挙動が異なるからw)あっちとこっちは相互にどういう変換方法があったか、等しっかり考えて作るもんなww
さすがるっピ!www
def
ブロック
Proc.new
proc
lambda
->
用途に合わせてどれが使えどれが使えないのか、使える場合変換は必要かどうか、変換なしで使える場合も挙動がどう異なるのか(同じように使える場合もすこしづつ挙動が異なるからw)あっちとこっちは相互にどういう変換方法があったか、等しっかり考えて作るもんなww
さすがるっピ!www
986デフォルトの名無しさん
2019/01/25(金) 19:30:27.27ID:a/PpKsi/ >>981みたいな奴が普通に居るのがJavaScriptコミュニティが腐ってる証拠な。
プログラミングを知らない癖に出来ると勘違いした馬鹿が間違ったことを吹聴しすぎてて、
馬鹿が再生産されまくっている。
とはいえ問題点は981以外には分かっているようだし、この話はもういいが。
他言語出身者なら、当初参考にするのはMDNだけにして、
個人が俺ツエーしてるだけのブログ等は全部無視した方がいい。
他言語ではあり得ない確率で間違ってるから、無駄にはまることになる。
emscripten/WebAssemblyが本格稼働するかどうか俺は懐疑的ではあるが、
実際にそうなったときに馬鹿JSerが一斉粛清されるかどうかは見物ではある。
「動けばいい」という基準で書いている限り、「動けばいい」程度のコードしか書けるようにはならない。
しかしこれがJSerの大半なのもまた事実だ。
一般的に「良いコード」とされる物を書けるかどうかはプログラマの技量のみに依存し、
JavaScriptだからといって書けない事はない。
ただ、どちらかというとJSはC寄りで、どんな糞コードでも書けてしまう。
ただこれは、単にJSerの技量が足りないだけであって、推奨されているわけではないので注意のこと。
>>979は今後色々と実感することになるとは思う。
プログラミングを知らない癖に出来ると勘違いした馬鹿が間違ったことを吹聴しすぎてて、
馬鹿が再生産されまくっている。
とはいえ問題点は981以外には分かっているようだし、この話はもういいが。
他言語出身者なら、当初参考にするのはMDNだけにして、
個人が俺ツエーしてるだけのブログ等は全部無視した方がいい。
他言語ではあり得ない確率で間違ってるから、無駄にはまることになる。
emscripten/WebAssemblyが本格稼働するかどうか俺は懐疑的ではあるが、
実際にそうなったときに馬鹿JSerが一斉粛清されるかどうかは見物ではある。
「動けばいい」という基準で書いている限り、「動けばいい」程度のコードしか書けるようにはならない。
しかしこれがJSerの大半なのもまた事実だ。
一般的に「良いコード」とされる物を書けるかどうかはプログラマの技量のみに依存し、
JavaScriptだからといって書けない事はない。
ただ、どちらかというとJSはC寄りで、どんな糞コードでも書けてしまう。
ただこれは、単にJSerの技量が足りないだけであって、推奨されているわけではないので注意のこと。
>>979は今後色々と実感することになるとは思う。
987デフォルトの名無しさん
2019/01/25(金) 19:32:46.97ID:tmiziBOT 今はもうtypescriptで書くのが普通
988デフォルトの名無しさん
2019/01/25(金) 20:14:43.16ID:fW+xzaQf TypeScript使うのはReact使ってるときぐらいだろ?
989デフォルトの名無しさん
2019/01/25(金) 20:18:01.23ID:tmiziBOT 冗談きつい
990デフォルトの名無しさん
2019/01/25(金) 20:31:44.04ID:fW+xzaQf >>989
あ、すまん。ReactじゃなくてAngularだね
あ、すまん。ReactじゃなくてAngularだね
991デフォルトの名無しさん
2019/01/25(金) 20:37:08.43ID:tmiziBOT そうじゃなくて、もう普通にみんな使ってるから
992デフォルトの名無しさん
2019/01/25(金) 21:42:00.59ID:lgKiVxcF c#に似せるならもっとc#にすればよかったのに
あの型の定義の仕方が嫌だ
あの型の定義の仕方が嫌だ
993デフォルトの名無しさん
2019/01/25(金) 22:24:46.13ID:fW+xzaQf994デフォルトの名無しさん
2019/01/25(金) 22:31:45.82ID:NHrDct4H こんなのあった。TypeScript圧倒的。
https://twitter.com/__sakito__/status/1071307378950266882
https://twitter.com/5chan_nel (5ch newer account)
https://twitter.com/__sakito__/status/1071307378950266882
https://twitter.com/5chan_nel (5ch newer account)
995デフォルトの名無しさん
2019/01/25(金) 22:50:09.67ID:7NAKvkXa >>994
どこが?www
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png
GitHub Top Languages by Repositories Created: TypeScript is Not in the Top 5.
https://github.blog/2018-11-15-state-of-the-octoverse-top-programming-languages/
https://i.imgur.com/pZcCdjw.png
どこが?www
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png
GitHub Top Languages by Repositories Created: TypeScript is Not in the Top 5.
https://github.blog/2018-11-15-state-of-the-octoverse-top-programming-languages/
https://i.imgur.com/pZcCdjw.png
996デフォルトの名無しさん
2019/01/25(金) 23:35:19.53ID:tmiziBOT 今時型定義も入れずにnpmモジュール作ってるやつとか、白い目で見られるぞ
997デフォルトの名無しさん
2019/01/26(土) 00:03:22.84ID:Ve68vOks >>996
ごく少数から?www
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png
GitHub Top Languages by Repositories Created: TypeScript is Not in the Top 5.
https://github.blog/2018-11-15-state-of-the-octoverse-top-programming-languages/
https://i.imgur.com/pZcCdjw.png
ごく少数から?www
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png
GitHub Top Languages by Repositories Created: TypeScript is Not in the Top 5.
https://github.blog/2018-11-15-state-of-the-octoverse-top-programming-languages/
https://i.imgur.com/pZcCdjw.png
998デフォルトの名無しさん
2019/01/26(土) 00:10:36.62ID:yLgVaINv >>997
下のページのtypescriptの伸びは見ないふりしてるの?
下のページのtypescriptの伸びは見ないふりしてるの?
999デフォルトの名無しさん
2019/01/26(土) 00:31:22.48ID:Ve68vOks >>998
延びた結果がこの差なんだよねwww
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png
延びた結果がこの差なんだよねwww
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png
1000デフォルトの名無しさん
2019/01/26(土) 00:32:01.77ID:qvEagMOI javascript最高!
rupyキチガイ死ね!
rupyキチガイ死ね!
10011001
Over 1000Thread このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 237日 10時間 0分 38秒
新しいスレッドを立ててください。
life time: 237日 10時間 0分 38秒
10021002
Over 1000Thread 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- トランプ米大統領声明 「中国はパニックに陥った」 [お断り★]
- 【宗教】日本、仏教国で仏教離れ最多 信者の4割、現在「無宗教」 米研究所調査 ★3 [樽悶★]
- 米商務長官 トランプ関税「撤回の可能性ない。 世界はアメリカから搾取やめるべき。関税率是正なら交渉の余地あり」 [Hitzeschleier★]
- 長野智子 フジテレビ報告書で〝誤報〟判明「文春は謝罪するべき」…女性アナF氏を「3悪人」扱い ★2 [ぐれ★]
- 中居正広の弁護士・犬塚氏、直撃にダッシュで逃走…被害女性を「不快」にさせた“フジと利益相反”の受任 [Ailuropoda melanoleuca★]
- 注文した料理が来ないまま45分経過 → 食べてないのに「席を空けて」と店員に退店を促されて激怒、トラブルになった男性 [パンナ・コッタ★]
- 【訃報】日経平均先物、ガチで下落が止まらないマイナス1400 [943688309]
- トランプ「利下げしろ😡」→FRB議長「トランプ関税でインフレの可能性大 だから利下げしない」 [175344491]
- 【火だるま】「NISA損切り」すべきか否か、ガチで意見が割れる [458340425]
- 岸田「貯蓄から投資へ新NISA!子育て支援で異次元の少子化対策!マイナンバー活用でデジタル田園都市国家!」 こいつの評価 [452836546]
- 生きててたのしくなかったなぁ
- じゃあ関税以外でアメリカの製造業を立て直す方法があるなら言ってみろよ [512028397]