+ JavaScript の質問用スレッド vol.126 +
レス数が1000を超えています。これ以上書き込みはできません。
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です) (10) ライブラリ関連の質問は禁止です。関連スレにあるライブラリ質問スレで質問して下さい。 超ド素人です。スレ汚しをお詫びします。
D3.jsを使ってグラフを描画するhtmlがあり、そのグラフのデータが.tsvで読み込まれるようになっている場合、どこに.tsvファイルを置けば良いのでしょうか?
というか、そもそもtsvもhtml?javascript?コードに含めるのでしょうか?
さっぱり見当違いなことを言っていたらすみません。
よろしくお願いします。 「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ファイルからの相対パスか?
または、プロジェクトルートからの相対パスか?
または、カレントディレクトリからの相対パスか? <input type='submit' value='送信'>
をクリックしたとき送信する前に、何かしてから
送信するにはどうしたらよいですか? なにかするってお願いでもするの?
ちゃんと合格できますようにって
何をするかによって、何処にお参りに行けばいいか変わる == はなるべく型を合わせようとしてから比較する
=== はそのまま比較する
詳しくは MDN の演算子のページとか
あとは「JavaScript 暗黙の型変換」でググれ >>12
どうもありがとうございます
理解出来ました
===の方が確実っぽいですね 直接javascriptの事ではないと思いますが、すみませんこちらで…
Googlechrome右クリックメニューをjavascirptを勉強して簡単なものを作成してみました。
右クリックメニューはショートカットキーを割り当てることもできると思うのですが、
右クリック、ショートカットキーを押す、という流れでなく、
chromeを開いた状態で
最初から「Ctrl+何か」 などで 右クリック→ショートカットキー
となるプログラムは、どの言語あたりなら作成できそうでしょうか・・
ショートカットキーを押すだけで右クリック開く→選択
というものを省くのが狙いですがすみません。
なんとか開発したくすみません・・ https://ideone.com/YCk1t6
javascriptで普通にキーイベントと一緒に修飾キーも拾えてるようだが
コレじゃダメなのか >>17-18
ご指示頂けても難しかったですが
なんとかできました。有難うございました! >>14
ショートサーキット(短絡)評価とかだろ。
AND, OR, ||, && など
例えば、A AND Bという論理式があった場合、
Aがfalseなら、その時点で式全体の結果は、falseで確定するため、
Bがどうであるかについてはチェックしない
この場合、式B が評価(実行)されないから、
B に関数呼び出しとか、変数を更新するなど副作用があると、
if, else 文で書くよりも、可読性が低い
「javascript 短絡評価」で検索! >>14
実行はただ単に何かの処理を実行すると言うだけ
評価は何かを実行して値を返す ファイルリーダーについての質問です。ここのソースを使ってます
https://www.sejuku.net/blog/32532
ファイルを読み込んだ後
var a=reader.result;
var b=a.split(',');
とやるとb[]の変数がsubstringなどが使えなくなります
aの段階では文字列として認識されてますがbになると変になります
readerを使わずに文字列でsplitすると普通にsubstringが使えます
いろいろ試しましたが原因がわかりません 読んだけどわかりません
終了後の result プロパティには、ファイルの内容をテキストとして読み取った文字列が格納されます。
と書いてます なんでこういう連中は再現する最小コード書かないかなぁ
そういう発想がないからバグの原因特定が出来ないんやで どうやらVisual studio Codeの仕様のせいだったみたいです
変換候補に出ないのでどこかに文法の間違いがあると思ってました
コード自体にエラーはなかったようです 仮にそうだとしても人はそれを凡ミスと呼ぶ
どうでもいいことで1時間潰したんだし >>29
>>23
>このプロパティは読み込みが終了した後に有効になり、プロパティのデータ型は読込処理を行うメソッドによって変わります。 そのレベルでインテリセンスが機能しないのなら既に遭遇して知っているはずだし、
今回初めて遭遇したのなら何らかの問題がコード側にあるだろ。
動的型だから何に対して substring を使っても文法エラーにはならない。
これで通ったと勘違いしているだけだね。多分。 VSCの仕様です
var a=reader.result.tostring();
にすればできるようになったのでそれで原因解決かとおもったけど
他の関係ない箇所でもsubstringの予測がでてこないのでおかしいと思って
調べると var が原因らしいとわかった
var a=reader.result;
var b=a.split(',');
という書き方ではVSCではbの型が確定しないので予測候補にでてこない
最初にvar a="";と入れてやると候補にでてくるようになる
ただし候補でないからといってエラーになるわけではない VSCの仕様でもなんでもないやん>>23のドキュメントにFileReader.resultの型はstring|ArrayBufferだって書いてあるのを読めなかっただけやんけ無能 「俺ではなく他の問題だ」と主張するのは初心者の典型的パターンだな。
そして100%「お前の問題だ」となるお約束展開。
昔はこのタイプは居なかったと思うのだが、何でこうなるかな? >>35
質問スレで意味のわかない用語で返すのやめてもらえますか
そもそも書いてる事理解できれば質問スレにきません 結果は文字列かも知れないしそうじゃないかも知れない
これじゃあ予測候補出せるわけ無いよね
以上 >>37
当たり前だがMDNやMSDNは普通のレベルのプログラマなら読めるように書かれている。
理解出来ないのなら自分の馬鹿さ加減を自覚し、責任転嫁するのは止めた方がいい。 >>42
次は最低限>>1の(1), (4), (6), (8), (9)を守ってくれよな無能 ってかaにカーソル当てたら型が出るだろ。VSCでは。 じゃ質問はもうとっくに終わってるので関係ないですね
それに必要な情報は書いていたはずです
最初から型の問題だと限定して問題なのはたった2行ですし
リファレンス読めばわかるというなら誰でもresultの仕様みれば答えられるはずですよね
それなのに後出しでイキってくる人ばかり 煽るのはちゃんと回答してからにしてくださいね 無能 >>47
問題なのはその二行じゃない。
その二行に気づかないお前と、その二行で正しいと思ってる今の理解力と、
それでもなおまだ自分に非がないと思ってるお前の人格だ。
/** @type String[] */なり、/** @type string*/で解決するだろ。無理に型変換したり初期値入れたりしなくても。
無理に推論させるためにソース自体に無駄なコードを書くな。
インテリセンスは万能じゃないし、インテリセンスが出ないから使えないと思うのも頭おかしい。
実際にエラーになってから言え。
原因はみんなある程度わかってて、その原因についてお前が切り分けられるかを問題にしてて、案の定お前は切り分けできなかった。
それでお前は、回答者が答えを教えない事を批判してるようだが、そのへんがそもそも噛み合ってない。
誰も答えがわからなかったんじゃない。
皆のヒントでお前が答えがわからなかったんだ。 そもそも余計な代入して、それで解決したと思うほうが頭おかしいだろ。
何が起こってるかぐらい把握しろよ。 人格云々っていつからここは人生相談板になったんですか? 人が事細かく詳細説明した後ならなんとでもいえますよね
あきらかにわかってる人いなかったっぽいし >>52
質問スレなんだから質問する人間が理解できるレベルであることを求めてもおかしくはあるまい。
>>53
お前が説明しなくてもわかってるし、型ヒントで充分なのは
>>23読んだらわかる。即レスで答え出てる。 >>47
> それに必要な情報は書いていたはずです
- 環境(Visual studio Code)を書いていなかった
- 「...とb[]の変数がsubstringなどが使えなくなります」と誤った判断から、誤った情報を開示していた(変換候補に出ないのでどこかに文法の間違いがあると思っていた)
どう見ても、>>22の情報開示ミスだけとね
「22の思いこみによる勘違い」をエスパーして、「未開示情報」をエスパーしないと、回答不可能だよね お前以外はとっくに気づいててそれ以上言わなかっただけ。
お前はその上間違った解法が正しいと思ってる。
致命的。 これが答えわかってる人のレスですか?>>31>>33 インテリセンスに出ないから間違ってるに違いない、と言う思い込みも異常だけど、インテリセンスに頼るならインテリセンスに対してちゃんと情報を提示するのは当然だし、
それは無駄な代入で行われるべきではない。 >>60
あなたはわかったのかもしれませんが他の人はわかってませんよ
別方向の回答してるし >>55
aは文字列として認識している
bは文字列として認識していない
仕様がわかってれば答えでてるも同然じゃないですか?
少なくともエスパーしないと無理というレベルではないでしょう >>61
別方向の回答!?
お前は何を読んでるんだ?
試したか?型ヒント。 >>62
お前がエスパーを求めたのは「エラーになる」という発言。
実際にはならない。
文字列として認識させたいなら、文字列として認識してくれるように頼めばいいだけで、
それが型ヒントだけど。 人には偉そうに言ってたみたいだけど、いきがるのもいい加減にして無知を認めろ。
それが質問者だ。 無知でなければ質問スレにはきませんよ
エスパーしないと無理といってるし他の人はわかってなかったですね >>67
普通は>>22からはシンタックスエラーまたは実行時エラーと受け取るんだよ。
インテリセンスに出てこないだけという意味だと君が言ったのは>>29でしょ。
君はそこらへんから間違っている。
とはいえ、ここまで主張しまくる馬鹿も珍しいが。
まあ最初から再現コードを上げてれば防げた話だね。無能ってのは事実だよ。 >>67
多分お前がまだ良く分かってないから、大多数が分かってるのが理解できないんだと思うけどな。
無知を認めるなら、間違った解決法に対して「これでいい」「これで問題ない」「これがVSCodeの仕様」と思い込むな。
無知すぎてその解決法も間違ってて依然無知だと言うことにすら気づいてない。
ちゃんと真摯に聞け。 いじってくるから返してるだけですが
もう解決済みの問題ですよ
コードも思った通り動きますし
どこかに認識不足があったとしても後は自力でどうにでもなります 解決済みだと思いこんでる問題だろ。
認識不足ではなくて勘違いどころか、壁に釘を打ち込む為に金槌使わずにレンガ使ってるのを「これで解決しました。もう問題ありません」って主張してるようなもんだぞ。
自力でどうにもなってないから、間違ってる、型ヒント使えと言ってるんだよ。
自力でどうにかなってるという勘違いをまず改めろよ。
なんの為の質問と耳の痛いレスなんだよ。
釘は金槌で打つもので、レンガでも打てるけどそれは根本的に間違ってる。
それぐらい認識しろ。 確かにあとから苦労するだろうな。中途半端で理解した気になって、あまつさえ人につっかかる人間性だと。 まぁ、いよいよ言うに困ったら「いじってくるから返してるだけ」なんて言うレベルだし仕方ねえかな。
無駄な時間使ったわ。
いじられてんじゃなくて良くなるように指摘されてると理解できないとか、よっぽどプライドと意識の高い人なんだろう。
他人に無能と言う割に、無能と言われるとムキになるところからもわかるけど。 プログラムを動かすことが目的なのであって完璧で無駄のないプログラム
を目指すのが目的ではないので問題ないですよ
あと教えたいのか教えたくないのかはっきりしましょうね
1レスで済む問題です
人格攻撃挟んだり説教はさんだりそれこそ無駄ですよ
自分が答えるときは手本のコード貼るだけですけどね >>76
> 自分が答えるときは手本のコード貼るだけですけどね
君が答えられるようになるまでに何年かかるかだね。
君みたいな「完璧超人な俺が間違うはずがない」って勘違いは、
昨日プログミングを始めました、みたいな奴に多いのだが。 >>77
もう何度も答えてますよ
わかればコード書いてわからなければスルーで済む話
この手の質問スレにはろくに答えもしないのに説教したがりが多いですね
まったく無駄な存在w >>62
あれだけはっきり書いても伝わらないのね
・必要な情報が出ていない
・誤情報が出ている >>76
問題ないと思うならもうそれでいいよ。
>>78
間違った答えだけどね。
釘を打つにはレンガが良い、みたいな答え。 >>80
しつけーよ
書くならさっさと書けや
2行のコードでどこまで引っ張るつもりだよw >>81
書いたじゃんw
理解してレスしなければ話は終わってたのに、どうして?
理解できてないから間違った答えだと認めたくない、ならそう言えば? こっちは配列文字列に入りゃそれでいいんだよw
プライド高いだの苦労するだのもっとよくしてやろうとか大げさなんだよw
なんだよそのたとえ話はw禅問答かよw そういう意味では最初から文字列の配列に入ってる。
ただインテリセンスが判断しきらないだけ。
だからJSDoc書くんだよ。
大げさも何もw
言い方やら何かしらをやりだまにあげて、本当に言いたい事をごまかすの辞めたら?
言っていいよ。惨めだから辞めてくれって。 最初からエラーじゃなかったと言ってるだろうがw
だからおまえの解決法は間違ってるとかこいつなに言ってんだろうとw
まぁそんなことは放っといてどんどんプログラム書き進めて完成したところだ [63,61,59,57,55].forEach((v,i)=>{
})
[63,61,59,57,55].forEach((v,i)=>{
})
二つ目がエラーになる
なぜなのか... 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) ついでに
TypeError: Cannot read property '55' of undefined
からundefinedの55番目を参照しようとしているのは分かるわけだから3行目の[]がインデクサとして解釈されていることも明らか >>90
それはわかる
>>89
ありがとう。びびったわ node.jsのhttpモジュールでapiからjson取得してそれを使ってゴニョゴニョしたいんですが
レスポンスが終わった際jsonを返すにはどうしたらよいのでしょう?
promise使って返す事は出来たのですが他の方法があればご教授ください >>88みたいなことにならないなら好きにすればいいと思うよ think49に粘着してる奴、過去にthink49と何かあったの?(あるいは、マルチポスト晒された質問者が逆恨みしてるの?)
反論してる人を全てthink49と思いこんでるようだけど、スレ違いの話題を延々と続けられて迷惑してる人が大勢いることにまだ気が付かないわけ?
質問者の為を思うなら、質問者がクローズしたここで苦情を申し立てるより、質問継続しているteratailで回答してくるべきでしょ >>95
ts使ってるけど、lintでセミコロン使わない設定にしてる。それでなんの問題もないけど。
なんでセミコロン抜くとエラーになるん? ご質問です。
当方デザイナー兼コーダーとして、自社サイトの制作に携わることになりました。
その際サーバー側を担当するエンジニアからjqueryはもう古いから、他のライブラリを使うかせめてjavascriptで実装するようにと言われました。
大手のサイト等拝見しても、jqueryは現役ですし、特に陳腐化するような懸念は感じられなかったのですが何か理由があるのでしょうか。よろしくお願いします。 jquery大嫌いな人間だけど
古いからは何の理由にもなってないと思う >>99
言った人に聞けばいいじゃん。
理由は「もう古いから」って言われたんだろ?
それしか理由が言えないやつならそれまでってことだよ
代替案が提示できないか提示してもメリットを言えなければ
そのエンジニアはただの園児ってことだよw
このスレでも何度も話題になったが、いずれも代替案を
言えないか、言ったとしてもメリットが無かった。 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% >>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 >>104
それを見るたびに思う。jQuery使ったほうが短いとw
ネイティブのコードなんか書きたくない macのsafari用にbookmarkletで
選択範囲のリンクを取得したいのですが
alert prompt 共に2000文字以上表示出来なくて
リンク全てを得ることが出来ません
こういう場合どんな方法を使えばいいですか?
よろしくお願いします >>106
document.bodyにtextarea要素をappendChild >>99
es2015で十分じゃん。なんであえてjquery使う必要があるの?といいたいのでは?
ie11対応したいならbabelとか挟んどけば > es2015で十分じゃん。なんであえてjquery使う必要があるの?といいたいのでは?
esなんちゃらの対応範囲はJavaScriptという言語であって
JavaScriptの範囲外のDOM操作は何も変わらない
DOM APIっていうのはブラウザが提供してるAPIだから
JavaScriptではない。本来はこのスレの対象外
jQueryはDOM APIをシンプルにするものだから
esなんちゃらを使ってもjQueryは必要 JQueryが古いからダメと言うのは、ちょっと語弊があるけど細かく説明するのが面倒くさいからが半分、今流行ってるライブラリ使いたい/JQueryと食い合わせが悪いってのが半分な気がするな。
まあvanillaでできない事も減ったし。 流行りだから使うって考えがアホ
それに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%伸びてるしな >>110
> まあvanillaでできない事も減ったし。
jQueryはvanillaを使って作られてるのだから
jQueryでできることはvanillaでできるのは当たり前。
「できないこと」ではなくて「面倒なこと」という方が正しい
vanillaで面倒なことは減っては来たが、それでもjQueryの方が簡単
https://github.com/nefe/You-Dont-Need-jQuery を見れば
jQueryがほんの僅かのコードで書けているものが
vanillaだと何行も書かないといけないのがよく分かるよw >>112
ああ、vanillaでブラウザ互換を気にしないでできない事も減ったし、と言い直すわ。 JQuery でテーブルの各行の高さを求めるにはどうしたらいいですか。
たとえば最初の行の高さを求めるのに
$('table > tbody > tr').eq(0).height()
などとやると height() がないと怒られます。
実際には、最初の行の高さを求めたいのではなく、最初から特定の行までの行の高さの総和を求めたいのですが。 互換性が機能の違いを吸収するライブラリのことを
英語でなんて言いましたっけね?
Polyfillは標準があって、その標準に準拠させるためのライブラリ
ShimもShamも似たような意味で
単に違いを吸収するだけとは違う気がします。 >>95
馬鹿か、負担付けなければこの手の間違いにすぐ気がつく
付けない経験が少ないから分からなかっただけだろ JavaScript初心者です
JavaScriptの中で別のJavaScriptを読み込んで、その中のclassを使いたいのですが、やり方を教えていただけませんか?
html5とJavaScript(enchant.js)でゲームを作っていて、main.jsの記述を減らすためにファイルを分けようとしたのですが、どうにも上手く読み込んでくれません… >>122
今のやり方はローカルにビルド環境を作って、
ビルドして結合したjsファイルを生成して
それを配布して使うんやで ブラウザがモジュールに対応してないからビルドが必要になるということ モダンブラウザは対応してるでしょ
シェアの8割〜9割は対応してることになる
非サポート組はnomoduleで最低限の機能提供するか
JS切ってるのと同等に扱ったほうが良いだろうね 小さく始める 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つあり、
そのゲームエンジンが採用している方を使えばよい >>126
1割以下のブラウザは捨てていいって判断だと
SafariやFirefoxで動かなくてもいいやってことになるぞw それとは結構違うな
レガシーブラウザを使い続けてるって言うのは特殊な部分があるし、
ブラウザもその下のハードウェアも性能に期待できないから
ポリフィルという重しを課してまでモダンブラウザと同等に働かせるべきかと言うと
自分はハテナを浮かべるな class言ってるんだからモダンブラウザで良いでしょ >>128
シェアの8割〜9割の意味をもう少し考えたらどうだ >>131
どれくらい多くの人が見れるかでしょう?
モジュールに対応している人だけが見れるサイトだと
1〜2割の人が見れなくなる >>132
それでなんでFirefoxで動かなくていいやってことになるんだ? JavaScriptを理解するのってどのくらいの期間かかるものなの?
ドットインストールの有料コース3週くらいやってんだけど未だ難しい IEしか使えないってのは要するに企業ユーザーであって
それは案件ごとに要望に沿うだけの話だけど
宗教的理由によりIEしか使えない奴らはそれこそ知らんと言っても良いと思う >>138
たのしいRuby 第5版、2016
これを読んで半年、オブジェクト指向・関数型で、Ruby をいじくりまわしてから、JavaScript に戻ればよい。
CSS セレクターを使う、jQuery と、Ruby のNokogiri が、ほぼ同じ
Progate のサイトでも、やってみれば?
プロレベルでは以下の2冊だから、数年は掛かる
JavaScript 第6版、2012、David Flanagan
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017 インタラクティブ・データビジュアライゼーション
――D3.jsによるデータの可視化
原書は第2版が去年出てるみたいです。
日本語版の第2版の出版予定はありませんか? >>145
> CSS セレクターを使う、jQuery と、Ruby のNokogiri が、ほぼ同じ
ぜんぜん違う。NokogiriはjQueryに比べたら洗練されていない
通称jQueryオブジェクト呼ばれている、いちばん重要な
オブジェクトがNokogiriには搭載されていない
そのせいでCSSで取得した複数のオブジェクトをeachで繰り返して
操作するというjQuery以前のやり方をしないといけなくなってる。
NokogiriでjQueryを学んだ気になると、jQueryとしては
悪いコードになってしまう。 そりゃ、jQuery の方が洗練されてる。
Nokogiri では、単数と複数(配列)の戻り値を返す、2つの関数に分かれているから面倒
jQueryでは、単数・複数・該当要素なしでも、統一的に扱えるし、メソッドチェーンできる >>145
理解するのにどのくらいかかるかって質問してるのに
何でrubyやらjQueryが出てくるんだ? JSを理解するとは仕様書のどこを読んでも、うんうんそうだよね、と言える状況のこと
型変換、スコープチェーン、プロトタイプチェーンのようにイメージの積み重ねでの閃きのような物が必要な概念もあるけど
一方共有渡しの原理とかは仕様書を読まないと絶対に納得できない むしろ自分の中の話でなかったら何なんだ?
お前の中では>>151が世界の代弁者のつもりにでも見えるのか? すみません、以下のコードが読めません。分解して教えてくださいませんか?
1 function presetDiary(dateStr){};
2 htmlStr += "<a onclick='presetDiary(\"" +dateStr + "\");'>"+cellStr+"</a></td>";
2行目はダブルクォーテーションとシングルクオーテーションが入り乱れていて
何が書かれているかわからなくなってます。
普通にHTMLタグで書くと
<a onclick="presetDiary(dateStr)">cellStr</a></td>
となると考えていいのでしょうか? > 2行目はダブルクォーテーションとシングルクオーテーションが入り乱れていて
> 何が書かれているかわからなくなってます。
わかるだろ?
お前が本当に言いたいことは、
どこがどう対応しているのか調べるのが
「面倒です」ってだけだろ
嘘つくなや。そして怠けるな 1. は単なる関数定義。
入門書を読むか、検索でもすれば?
2.
><a onclick="presetDiary(dateStr)">cellStr</a></td>
こうだろ
<a onclick='presetDiary("dateStr");'>cellStr</a></td>
でも変数、dateStr を、" " で囲むのは、おかしい。
この文は、間違い onclickとイベントリスナーclickの違いって何があるんでしょうか? onclickの方が古く、問題があるので
解決策として出てきたのがイベントリスナー HTML 内に書くと、グローバル関数になってしまうから、良くない
また、addEventListener() は、ブラウザによっては使えないから、
jQuery を使う方が、互換性が高い
web 関連の質問は、web制作管理板へ書き込んでください。
そこの方が、知っている人が多い >>160
>>161
ありがとうございます。onclickは古いんですね。
web制作板の存在は知りませんでした。行ってきます >>162
古いから使うな、ってのも間違いなんだが、
使い分けの意味が分からず、イベントリスナーで問題ないうちは、全部イベントリスナーでも問題ないよ。 WEB広告の内容ってJavaScriptで取得できますか?
他社サービスの広告を埋め込み配置して表示させる(hiddenでもかまわない)
JavaScriptで広告の内容を取得してユーザーIDと合わせてサーバーに送信して保存する
保存したデータから個々のユーザーが興味を持っている事がわかるのでマーケティングに利用する
ということができるのではないかと考えています >>164
不可能。そういう悪用ができないようになってる キャンバス上に描く図形の色を変数から指定したいのですが変数名を入れる時にただの文字列と区別させて認識させるにはどうしたらいいでしょうか?
var str=フォーム.色.value;
con.fillStyle = 'str';
としているのですがどうしても黒のままなのです ダウンロードにプログレスつけるのって簡単にできる?
手元にとどいてるファイルのサイズってJSでみれる? Fetchって使ったことないので調べてみます
ありがとうございます >>164
できる、getUserMediaでスクリーンをキャプチャできる >>172
え?なに? それ使ったら、ユーザーの画面キャプチャして
サーバーに勝手に送信できちゃうの?
ここクリックしてーとかやったら
気になるあの娘のパソコンの画面とか
見放題だな! >>172-173
> カメラやスクリーンシェアリング、マイクのようなビデオやオーディオ入力装置の使用許可をユーザーに要求します。
> スクリーンシェアリング
> https://developer.mozilla.org/ja/docs/Web/API/MediaDevices/getUserMedia
そのための機能なのだから、出来るのだろうね > 使用許可をユーザーに要求します。
だめじゃんw
WEB広告表示されたら、画面をキャプチャして送信していいか?って聞くんだろ? これでなんで入替えできるの?
b = [a, a = b][0]; >>177
それを分からない奴が、そんな書き方のプログラムを読む意味はない 訳:「わからないので説明できない。俺が分からないのだからお前もわかる必要はない」 >>179
そう思うのならそれでいいと思うよ
普通の人は「まんまだろ」としか思わないと思うけど
てゆうかマジでそれ何?uglifierの出力か何か? >>179
つーか、ググったらヒットしたわ。ちょっと違うけど。
> a = [b][b = a,0];
> https://stackoverflow.com/questions/9864420/how-does-bb-a-0-swap-between-a-and-b
後ろ側は配列として解釈されないのか?という心配はあるが。
サイトのコード読んでいるのなら、minifyするときにそうなった可能性がある。
(良いやり方だとも思わないし、具体的に何を使えばそうなるのかも知らんが)
手でそんなのを書く奴は居ないので、
もし君がそこに引っかかっている(=文法も十分に分からない初心者)なら、今は別のコードを読むべきだ。 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 ] >>182
> このくらいなら手で書かれることは十分にある
> このくらいは理解できないとJS中級者にはなれない
ねーよ。お前ら相変わらず世界観が歪んでるな。 >>183
このくらいの複雑度
つまり五段回くらいの評価が一行に書かれることって
アロー関数とかが入った今ますます書かれるようになってると俺は思うが
特にreduceとか使うとこの例と似た状況にもなりがち >>185
俺の意見は、「変数の入れ替えをその書き方でする奴は居ない」だが、これで理解出来るか?
その程度の「複雑度」なら、大したことはないし、普通の人なら頭の中で読めるでしょ。
> reduce
reduceってのは数値演算をするときに多用するのであって、
通常のJavaScript(=DOM操作等)ではほぼ使わない。
そもそも変数の入れ替えも『初心者用の教材の』ソート等では使うが、実用では皆無でしょ。
お前、前から居るズレてる奴で、相変わらずズレてるよな。 >>185
というか、お前、前からreduceにこだわってるよな。
JavaScriptでどういう操作をする時にそれが有用なのか、言えるか? おい複雑度っていうのを俺俺で使うんじゃない。
コードメトリクス用語の「複雑度」とごっちゃになって紛らわしい
>>177のようなものは「複雑度」はあがらない。
上から下に単純に読み下せばいいからだ
こういうのは単に知らない命令があったってだけで複雑なのではない
「複雑度」というのは、コード自体は読めるが絡まっていて読みづらいということを指す。
具体的にはループ、条件分岐が増えることで「複雑度」が増えていく ちなみにコードが複雑というのは、コードの問題だが、
コードが読めないっていうのは、人間側の問題だからな
人間側の問題なのに「これ複雑っすよー」っていうやつが多い
(単にそいつが読めないだけ) reduceは数値演算で多様?
[1,2,3,4,5].reduce((o,n)=>{o[`n${n}`]=n;return o},{})
みたいに第二引数にオブジェクト渡して繰り返し操作したりもよくあることだと思うけど
君が全然JSを知らない・知ろうとしない。使って来てない・使おうとしないから
本当に解説書の一番上に乗っている形でしか構文やAPIの使い方を思い浮かばないのは勝手だけど
人のことをズレてるとか言うもんじゃないよ。ただ単に君の応用力が矮小なだけだからね >>189
言いたいことは分かるが、
var tmp=a;a=b;b=tmp;
と比べたら複雑なのは事実だろ。
ただし、これにより「コードが読めなくなる」事はあり得ないので、
『大規模コードの長期的メンテナンス』を前提とした
コードメトリクス用語の「複雑度」なら全く上がらないのも事実だ。
ただ、JavaScripterの話を聞いている限り、
こいつらは「どういうコードが読めなくなるか」については知らないし、
それで何とかなる世界なのだと思う。
これ自体は俺はありだと思っているし、このやり方は他言語の連中も学ぶべきだと思う。
つまり、四角四面で「絶対にメンテナンスしきる」のではなく、
ある程度の集積度や規模に留め、コードをある程度使い捨てにしていく、という方法だ。
長期メンテナンス前提で書くと色々面倒だったりするだろ。そのコストが省ける。 「コードをある程度使い捨てにしていく」っていうのはまた面白い話だけど
あの十数文字のコードがそんなに大げさな話に繋がるものかぁ?
どちらにせよ自分としてはちょっと話が違う気がする
コードを捨ててもいいから適当にああいう書き方をするっていうことになるならね
やっぱり幾らかテクニカルなコードっていうのは「どうにでもなれ!」って感じよりはむしろ
書いた本人は効率的で読みやすいと思ってる場合が多いのだろうから
もし読めない人がチームメンバーにいるのならそう書くべきじゃないだろうよ
だって「スマート」という目的が果たされてないのだから
ただ自分が言ってるのは、だからといって一般的に読めないままでいいということではないということ
あの程度は普通に読めるようになっとこうよ、中級者くらいを名乗るなら、と言いたいだけ >>191
var o = {n1: 1, n2: 2, n3: 3, n4: 4, n5: 5};
その例なら普通はリテラルで書くだろ。
もっと多ければどうせコンストラクタとして分離するし、関係なくなる。
多分君は『文法を学ぶ』事を学習と思っているのだろうけど、そうじゃない。
書いて、デバッグして、メンテして、それが学習だよ。
新文法は便利に使えばいいのであって、無理に使うものではない。
君には>>189-190が何を言っているか分からないだろ。 >>193
前提が全然違う。
あの程度は普通に読めるのは、当たり前なんだ。
そして、あの手の「1行の範囲にとどまる複雑さ」なんて、長期的には全く問題にならない、といってるんだよ。
まあ君には通じないとも思うけど。 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程度が低すぎるわ。質問に答えるでもなく程度が低いのに突っかかってばかり。糖質かな?
死ねばいいのに。 >>193
あと、多分、中級者の基準がおかしい。
君のはJavaScript『文法』の中級者なんだよ。
JavaScriptはプログラミング言語であり、プログラミング言語は実装の道具だ。
だから、本来の『JavaScript中級者』ってのは、何を実装出来るかで測られるべきなんだよ。
俺の定義なら、以下だね。
・初級者:一通りも出来ない。
・中級者:一通りやりたいことは出来る。
つまり、「ポップアップを作りたい」「ここをクリックしたらこう動かしたい」等、
やりたいことがあれば、とりあえず動く物は作れる。
・上級者:最初から最適な構造を考えて実装出来る。
勿論、新文法が便利なら使えばいいのだけど、最適な構造かどうかと新文法はほぼ関係ない。
(むしろ本質的に必要な物は先に取り入れられるから、新文法は基本的にオマケでしかないし)
それよりも、コード構造の方が何倍も重要なんだよ。 >>196
> reduceの中でfetchのプロミスをthenで繋げるようにして一時に1ダウンロードしか走らないように制限したり、
> 無数の関数を次々適用したいとき
やるのは自由だが、それ、普通に配列をforで回しても実装出来るだろ。
新文法を使う=上級者、というのは完全に間違いだって事だよ。
君らは文法にしか目が行かないからそういうことしか言えない。
それは初心者にありがちなパターンでもあるけど。
(初心者は文法から入るしかないから、どうしてもそこに目が行く) >>194
「思っているのだろうけど」とか止めてくれない?
自分はこういう構文が良いものだとも、ああ書くべきだとも言っていないよね?
こういう使い方もできる、こうも書かれることもある
そのくらい思いついて、すんなり読めるようになろうと言ってるだけ
無理に使う?君が無理かどうかなんて知ったことじゃない
>>195
長期的って言うのがそういう期間を指しているのか知らんけど
デバッグも完璧に終わってリリースしてしばらくたった後、大型アップデート時に
ってことならまだ分かるけど、今どきは毎日小変更デプロイでしょ
そういう体制だと将来的に困ったら丸ごとすげ替えればいいっていうのは通用しない
複雑なものを放置しとくと、実際困ること必至
それがJSerの考え方の面白い特徴だとか、古すぎぃ >>198
それ、reduceでできるよね。わざわざforを使って本質的でない一時変数をいじくりたい理由とは?w
reduceなんて何年も前から使える。es2015ですらない。
文法にしか目に行ってないのは君自身のことだね。悪いけど一緒にしないでもらえる?
君はどこまでも自分本意な考えで、自分の知らない文法=新文法、自分の知らない文法を他人が使うのがとにかく気に入らない、これに尽きる。これに後付けで理屈をくっつけているだけ。 >>199
> こういう使い方もできる、こうも書かれることもある
この必要がないんだよ。むしろ、してはいけない。
それが分からないのは君が『長期的』メンテナンスしたことがないからだね。
> 長期的って言うのがそういう期間を指しているのか知らんけど
CやJavaの世界では20〜30年以上だね。
そして「コードメトリクス」はそれを前提としてるから、JavaScriptにそれを適用するのも無理がある。 >>197
君は本当によくわかってる。正に君の言う通り。
自分はJavaScriptを道具だとは思っていない。
もちろん君の定義も分かる
でも曖昧で幅広すぎるでしょ?
ここはWeb制作板じゃないというのもあるし
なんだかんだ言ってもやっぱり今回は文法の問題だったので
文法レベルで言わせてもらった
ってわけでもない
自分が中級者と言って想定したのは「右も左も分からない段階を抜けてそこそこ使えてきた段階」
つまり、とにかく基準は何にせよ俺は初級者は抜けられたぞ!って思ってるような人に
そこで満足してほしくないからちょっと意地悪で大げさに発破かけただけ
皆どちらかと言うと君の基準だろうから、そこはわかった上であえて文法面をぶつけてみただけ
すまんね、自分バランス取るのが好きなひねくれ者だから >>200
> 本質的でない一時変数をいじくりたい理由とは?w
ああ、そっちの宗教の人か。
まあ、流儀があってやっているのならいい。
それで君にとって「読みやすくなる」のならそれもありだ。
ただ、reduceを知らないってことは無いし、それで読みやすくなるって事もないけどね。
関数型()の奴は1行にこだわるが、
関数間のいわゆるコードメトリクス上の「複雑さ」には無頓着なんだよ。君もね。
まあいいけど。 すまんな
自分、盛り上げるのは好きだけど盛り上がってくるとどうでも良くなるんだ
もう寝るね >>203
そういうのを藁人形論法という。
俺はforも使う。
俺には選択の自由があり適宜使い分けるが君はforにこだわる。
正しく君のほうが宗教だ。 >>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はそもそも筋が悪いんだ。
配列を縮退させるメソッドなのだが、そもそも縮退させるような物は最初から配列にしない。
だから一時配列で便利に初期化、みたいな例ばかりな訳でさ。
なんであんな糞使えないメソッドが導入されたのかが俺には謎だ。 >>206
やっぱ藁人形w
誰も一行で書けるからreduceがいいなどとは言ってない。
ましてや関数型至上主義者ならなおさらそのようなことは言わないだろう。
> なんであんな糞使えないメソッドが導入されたのかが俺には謎だ。
つまり、「俺に分からないreduceなんてみんなも使うべきじゃないんだ!」
ガキか。 >>207
それならそれでいい。
俺はお前の書き込み全部デタラメだと思ってるぞ。 >>209
だから、まず、
> 俺に分からないreduceなんてみんなも使うべきじゃないんだ!
が間違いなんだよ。
君にとって reduce が難しいからそう思えるのだろうけど、
実際、reduceが分からない奴なんて居ない。使いどころがないだけだ。
>>196も無理矢理でしかない。
indexOf等と比べてゴミなのは事実だろ。
というか、JavaScriptのスレには前からreduceが大好きな奴がいるが、
ここまで来るとjQuery廚と同じく布教目的か?
なら筋が悪いから無理だ。 > 君にとって reduce が難しいからそう思えるのだろうけど、
自己紹介乙w
> reduceが分からない奴なんて居ない。使いどころがないだけだ。
はいはい。じゃ更新しといてやるよ。
「ボクが使いどころが分からないreduceなんて、みんなも使うべきじゃないんだ!」
ガキか。
使いどころで使ってんだよ。テメーが分からないからって強制してくんじゃねーぞクズ。 >>190でも似たようなことを書いたが
コード側の問題 と 人間側の問題をはっきり区別つけろ
reduceがわからないっていうのは人間側の問題だ
コードの問題じゃない >>211
だから、何度も言っているが、
× 使いどころが分からない
○ 使いどころがない
なんだよ。
結局、>>196も、『一時的に』配列として持たせてreduceしただけだろ。
最初からいきなり縮退させれば済むだけの話。
reduceは『配列として意味がある』(≒配列として『持つしかない』)物を縮退させるメソッドであって、
そもそもそのケースがJavaScriptの用途においてはほぼ無いんだよ。
そして他言語でもこのメソッド持ってないだろ。大して使えないからだよ。
>>212
俺の立場をはっきりさせた方がいいのか?なら、そちらと同じで、
・reduceを使ってもコードメトリクス的な「複雑度」については上がらない。(これが原因で『長期的に』読めなくなることはない)
・reduceは難しくはない。(これが原因で『短期的に』読めなくなることもない)
・使っているコードに遭遇しないのは、そもそも使いどころがないから。
・>>196はイキった馬鹿が無理に使う例だが、まあ、やりたければやればいい。大局的な問題にはならない。 > ○ 使いどころがない
使い所はあるだろう?
いや、開発効率とか考えずに、可能不可能だけの話をしたいなら
アセンブラでもできるから高級言語の使い所はないって話になるけど > ・reduceを使ってもコードメトリクス的な「複雑度」については上がらない。(これが原因で『長期的に』読めなくなることはない)
条件分岐、ループが減るので、reduceを使うと複雑度は下がる
当然のことながら僕新人なんですみたいな
人間の問題の話はしない reduceは初期状態があって、データの数だけ
状態を変更していくというパターンにすべて使える
例えば、初期状態が0で、配列の数値を加算していくとか
もちろん加算だけじゃなくて任意の計算ができるし
初期状態も数値ではなくて配列などでも良い reduceの問題は、reduceをしたくてreduceを使うのではなく
reduceを使って何かをする、というところにあると思う
後から又は他人がコードを読んだときに
何をしているのか、何のためにreduceを使用しているのかを
一旦考えないといけない
利便性はあると思うが
やりたいことそのものズバリを表している名前や動作ではない
というところが難点なのではなかろうか > 何をしているのか、何のためにreduceを使用しているのかを
> 一旦考えないといけない
forでも同じ。なんのためにループしているのか
一旦考えてる reduceの場合(人間に問題がない場合)
その名前から「初期値になにかの計算を計上していってる」ってことまで
単語一つで分る
同じことをforでやろうとすると、forは繰り返しているだけ(何をしたいの?)
変数を見つける。その変数になにかの処理を行って、同じ変数に入れている
ここまでコードを読んで、あぁreduce相当の事をやっているんですねとわかる
reduceという単語一つでわかるのと、
コードを読んでいかないとわからない
この違いがある クロームで見たとき5chで書き込むボタンを押したとき
ボタンを押す処理をする前に自分の考えた処理を付け加えたい場合
どのようなコードを書けばよろしいでしょうか?
もしよろしければ教えてくださいませ。 >>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を取ったりしてしまうことだ。
結果、余計に読むコードが増え、重複したコードが分散してしまう。
これはコードを書く側の問題だが、実際、この問題の方が大きいと思う。 >>220
onsubmit で間に合わなければ mousedown か mouseover とかで >>213
> 結局、>>196も、『一時的に』配列として持たせてreduceしただけだろ。
> 最初からいきなり縮退させれば済むだけの話。
>
> reduceは『配列として意味がある』(≒配列として『持つしかない』)物を縮退させるメソッドであって、
> そもそもそのケースがJavaScriptの用途においてはほぼ無いんだよ。
君が遭遇したことがないだけの話だなw
「ボクが出会ったことないユースケースなんだから、みんなも遭遇したこと無いに決まってるんだ!」
経験不足だよ。
反例として、フィルターの種類、数、適用順を自由にユーザーに選ばせ画像に適用するクライアント側のコード書いたことあるがw >>223
URLくれれば見に行くが。
無理なら、reduceをどう使ったか分かるように言え。
つってもまあ、そのケースなら、関数を配列に入れてreduceしただけか?
なら>>196と同じだと思うが。 reduce禁止くん、「reduceは『配列として意味がある』物を縮退させるメソッドであって、そのケースがJavaScriptの用途においてはほぼ無い」って言ってるけど、これわざわざ配列使わずにやるの?w
フィルターの順番変えたり途中位置に追加したり削除したりクソめんどくさそうw
reduce禁止くんについてく人は配列も禁止だそうだけど頑張ってねw
でもJavaScriptの用途においてそんなケースほぼ無いそうだから大丈夫だよね!w >>225
俺は禁止とは一言も言ってないぞ。
使い道がないから使わない、と言ってるだけ。 >>220-222
「jquery event」「jquery preventdefault vs stoppropagation」で検索!
click は、要素をクリックする。
submit は、フォーム送信する
preventdefault は、イベントの既定の動作を、キャンセルする。
stoppropagation は、イベントの伝播を止める
JavaScript, jQuery の質問は、この板ではなく、web制作管理板へ書き込んで! 一番新しいプロジェクトでreduce何かに使ってたかなと思ったら
一つは空配列に必要なら追加していく形、
要は例えばmapだと同じ数の要素の配列しか返せないからその代わりにreduceを使っていたのと
もう一つは空オブジェクトを取って文字列の配列からオブジェクトにシンボルプロパティを生やしていく
っていうのに使ってた >>228
前者は filter + map でやるべきだ。
後者は >>191と同じだな。
意味的にはコンストラクタなのだから、関数として切り出すことに問題はないし、それで終わりだ。 filter+mapの方が良いとも限らないと思うよ
例えばAの場合はvalue.a、Bの場合はvalue.b、Cの場合はvalue.c、そうでなければ追加しないとすると
まずfilterで、AかBかCかというチェックを書いて
またmapでも篩分けしないといけないもの
reduceだといっぺんで済むでしょ
それと何箇所も使わないものをわざわざ関数に切り出しても何にも変わらないよ あとはDの場合はvalue.d1とvalued2の両方を追加するとかもできるね
というかそもそもfilter+mapの方が良かったら最初からそう書いてると思うけど >>230-231
reduceが効果的に使われているというのならそのURLを紹介してくれ。 >>221
> reduceの場合も中身(関数)を読まなくてはならず、
> そこが単純な関数なら、forで書いても単純だからだ。
reduceはコードを読まなくても、初期状態から状態を変えていってるっていうのがわかる
forはただのループでしかなので、それがわからない
理解できた? ttp://black-flag.net/jquery/20131119-4881.html
このもっと見るボタンを押した時にだけ.jsonを読み込むサンプルなんだけど
.json形式で外部ファイル読み込むようにするんじゃなく本体のhtmlに組み込むにはどうやんの このページには、やり方が書いてないだろ。
要素の挿入かな?
$("#parent").append("<p>あいう:<b>abc</b></p>");
jQuery などの質問は、この板よりも、web制作管理板へ書き込んで! >>237
よく分からん
申し訳ないけどそのままコピーして使えるように記述して jQuery も知らんの?
$( ) は、jQuery関数
#parent の# は、id を表す。
<div id="parent"></div>
HTML, CSS, JavaScript, jQueryの、初心者用の本でも読んで、勉強して Electornってブラウザで動くのにnode.jsなんですか?
初心者すぎてその辺よくわからん node.js は、普通のプログラム言語と同じで、ローカルPC のファイルにアクセスできる。
だから、node.js を使っているElectron は、VSCode を作った
VSCodeは、普通のIDE と同じ。
ただ、JavaScript で作られただけ じゃあnodeはローカルにもブラウザにもアクセスできるってこと? VSCode は、Electron で作られている普通のIDE。
ローカルPC のファイルにアクセスできる
Electron は、node.js + ブラウザのChromium。
画面は、HTML, CSS, JavaScript で作って、ブラウザで表示している
ほとんどの言語の開発で、VSCode を使う
漏れは、Ruby から、Selenium WebDriver を使って、ブラウザを自動操作している
Rubyで、ローカルPCの画像ファイルにアクセスして、
HTML, CSS, JavaScript で画面を作って、画像をブラウザで表示している
言語が異なっても、基本的な仕組みは同じ ブラウザの拡張機能やアプリと同じだよ
普通のUIはChromiumで普通のWebページ側のメインプロセス、
それとNodeのバックグラウンドプロセスが通信でやり取りする形
ただその通信が幾らか隠蔽されてるのでメインプロセスからでも特権的なAPIが自然と使える >>248
なるほど
7.toString()だと
SyntaxError: identifier starts immediately after numeric literal
7が数字から始まる不正な変数名だと認識されるという理解でよろしいか? 中学英語も出来ないのかよ…
識別子が数値リテラルの直後から始まってます 7は数値リテラルと認識されてるんで変数名と認識されてるわけではない >>247
そんなのは無視でいい。
初心者はそういうところばかりに目が行くようだが、上達を妨げるだけ。
そんな書き方する馬鹿なんていない。 >>250
identifierは中学で習う英単語には出てこないが?
http://www.eigo-duke.com/tango/tangoindex.html
高2でようやくidentifyがでてくる
immediatelyは高1。numericもliteralも高校でも出てこない 7..toString(2)
(7.).toString(2)
(7.0).toString(2)
どれでも文字列の、'111' と表示される
(7.0)
(7.)
7.
どれでも数値型の、7 と表示される 7.0toString()
とできないように
7.toString()
とできないということ 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 じゃダメな理由が分からない。
実は同じコードが同じ外部ライブラリ使って同じブラウザで動く環境もあるから、サーバのセキュリティがらみの設定の問題のような気がしながらもよく分からずにいる。
原因とかチェックポイントとかアドバイスください。 呼び出し元はどう本体呼び出してんの?
スタックトレース見てみたら? もしかして
document.forms.form1 「js document」で検索!
Document
https://developer.mozilla.org/ja/docs/Web/API/document
document は、DOM ツリー のエントリーポイント。
document.write などが有名
自作のフォーム名などが、document のメソッド名になる事はない。
document のメソッド名は、あらかじめ決まっているから >>258
どうやら外部ライブラリは body の中に scriptタグを作り出し、そこでロードされるスクリプトにコールバックを呼び出すだけのコードが書かれてるらしい。
だからグローバルスコープからのコールバック呼び出しかな。
この scriptタグの生成によって document の再構築でも起こって、まだ form1 が取り込まれてない状態になってるとかかな?
>>259
いや、普通は document.form1 で参照できてる。
>>260
メソッドじゃなくプロパティじゃないかな。
document 直下にフォームの name のプロパティが出来上がる。
という動作はブラウザでJavaScriptが盛り込まれた頃からの仕様だと思ってたけど、非推薦かなんかになってたりする? >>261
仕様ならMDNなり仕様書なりに載ってるはずだから、とりあえず探してみれば?
それ以前にまともな奴ならそんな物使わないが。
nameは重複許可だから、それは仕様バグであり、使い物にならない。
仮に仕様であったとしても、削除/変更されるのは時間の問題だ。地雷臭が酷すぎる。
お前も含めてJavaScripterは全員馬鹿だからここら辺を理解出来ないようだけど。 nameが何にためにあるのかを知っていれば
重複可なのが当たり前でそのformを1つだけ参照するものがあっても
常識の範囲で有意義に使えることが分かる
まあ馬鹿にはわからないだろうが >>263
唯一性をユーザー側で保証出来るのならid使え、ってことになってるだろ。
旧API(のつもり?)を使用し続けるのなら、それが今どういう状況になっているのか、自分で把握しておく必要がある。
そんな質問している時点でアウトでしょ。
とりあえず仕様書やMDNを漁って、「今でも使えるものか」確認しないと駄目だと思うよ。
ただそれ以前に、それが仕様であったとしても、動かないんなら意味無いけど。
(お前が「仕様だ!俺は悪くない!」とごねたところでコードが動くようにはならない)
大体、document.forms.xxx ならさておき、ドキュメント直下 document.xxx は不味いとすぐ分かるだろ。
それが仕様であったなら、早々に非推奨になって削除されるべきだし、実際多分そうなんだろ。
仕様がどんどん改訂されるプラットフォームなのだから、良くも悪くもトレンドに沿ってないと駄目なんだよ。
それだって、idで参照するようにしていれば、最初からそんな疑問すらわかないわけでさ。
仕様だから使える!と思ってる時点で馬鹿確定なんだよ。
お前も含めて、JavaSripterはコードを書き捨てばかりしているから、大局観が全く育ってない。
動かないから書き直す、ではなく、
何故書き直す羽目になったのか、どう書いていれば書き直さずに済んだのか、それを考える癖を付けた方がいい。
繰り返すが、それ、id/classで参照する今風のコードなら、問題すら発生しなかったわけでしょ。
お前ら、マッチポンプをしていることにすら気づいてないだろ。 >>266
英語読みきれてなかったらスマンだけど、それはアプリケーションサーバの設定の問題でローカル開発環境では form の name が出力されてなかったってことかな?
であればちょっと違うかも。
>>265
言わんとしてることはよく分かるよ。
でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
どうやってもその書き方じゃ動かないという話なら、機能として削除されたんだろうとも思うわけ。
>>257 の例だと、コールバックじゃないところでの例えば smtForm1内での document.form1 は問題無いし、それどころか同じものを別サーバへ設置するとコールバックの中でも動いたりする。
同じブラウザで。サーバはどっちも同じ apache で。ブラウザに渡ってる HTML も全く同一で。
しかしブラウザ依存でもないようで、動かない時はどのブラウザでも同じように動かない。
だからクロスドメイン周りの設定に差があるのかとサーバからの HTTPヘッダを比較してもこれと言った差も無いようで、よくわからんって話さ。
ただこのページに仕込んである他のJSの挙動が置くサーバによって違ってるのかもしれない。ページが安定した後の document に影響があるようなことは無いだろうと思って言わなくて悪かったけど。
ちなみに他のJSってアクセス解析の類い。
んじゃそれ外して試せばいいじゃんとなるだろうけど、いつか確かめるけど事情により今すぐは難しい。
といった感じで実用面では他のより良い手段でやればいいことなので問題があるわけじゃないんだけど、理由は知っておきたいという話。
どこでハマるか分からんし。 > どこでハマるか分からんし。
だからみんなjQuery使うんだよ >>267
> 同じコードが動いたり動かなかったりするからなんでって聞いてるの
それはそうだから、でしかないだろ。
まず、今現在「仕様」かどうか確認しろよ。
それで「仕様」でないのなら、それは偶々動いていただけであって、それだけでしかない。
ブラウザは大幅に更新されてる。
元々それを動かすコードをブラウザが持っていたとして、
仕様から外れた時点でそれをどこで落とすかはブラウザ開発者の自由だし、
結果的に一部残っていて動いたり動かなかったりするのも問題なしだ。
そしてそうなってるだけだろ。
「仕様」でなければ何の不思議もないし、「仕様」であればバグ報告すればいいだけだろ。
そしてその範囲を知る意味もない。
ありがちなパターンとしては、「古いコードもある程度までは動くようにする」為に、
初期構築(最初の構築)だけはそのコードを通し(つまり旧来方法でのアクセスも可能)、
追加で動的構築したDOMについては追跡してない(つまり旧来方法でのアクセスは不可能)といったところか。
ただこれを知ったところで、いつ変更されるかも分からんし、意味無いだろ。
> どこでハマるか分からんし。
「仕様」かどうかはさておき、「みんな」が「今」使ってない方法を使ったら駄目、ってことでしかないだろ。
そういったコードは、必要に応じて書き換えて「今」のトレンドに乗るようにするか、
jQueryみたいに「バージョン○○では…」と自前で管理しきるしかない。
どっちもする気がないのなら、それはお前の問題だ。
初心者にありがちな、全て「仕様」で確定している、という勘違いなら、頭を切り換えた方がいい。
厳密に仕様準拠なら、「必ずundefinedが返る」のが正しいが、
JavaScript界隈はそういう厳密さより、上記のように旧来コードも動くような曖昧さを残した方が好まれる。
結果、今の君のように、「ある日突然コードが動かなくなって???、環境依存???」な事も発生し、
それが長期的に生産性を下げる要因になっているのも事実だが。 >>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年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか?この先の動向が注目される 前線の開発者が新規にwebアプリ作る時はもう使わんというだけで
全体から見たらそんなのごくごく希少さね Angularが減ったのはまだ誤差の範囲内だと思うけど
Reactがこんなに減ったのはなんでだろうな 保守ではjQueryあるけど新規は全くない
俺なところはほぼAngular
最近はJAVA有料化の流れのおかげでnodejsも上げてきてる そもそも新規の仕事ってのがないってだけなので、
jQueryがまったくないという言い方はおかしい
同様にAngularやReactを使うこともないんだから
新規の仕事が無いのでね
たいていは過去やったことの続きか、
別の客に同じようなものを提供するので
そこで使われてるjQueryがそのまま使われる >>278
「3.1.3 DOM tree accessors」の中だったか
参考までに、どうやって検索した? とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど >>280
自演か?
それを257が言うのはともかく、お前が言うのはおかしいだろ。 自演ではないね。
そういう事がありましたってことだよ
起こったことはちゃんと書かないとw >>282
まず立場をはっきりさせろよ。
まあお前のレスを見る限り、正直、257のケース以外のところで怒らせてると思うけどね。 >>283
俺の立場は「誰が書いたか?」ではなくて「書いてある内容」しかみない
だから俺にも立場を求めるな。 >>284
やはり通じてねえw
そこがお前の駄目なところで、客もそれに怒ったんだと思うぜ。
まあ、完全に空回りだからもういいが。 >>285
流行り通じてねぇw
「
とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
」
ということが、起こったんですよ。彼の現場ではね!
って話だろうがw >>280
ブラウザはOSやグラフィックドライバなどのバグにきちんと対処してるぞ >>267
>別サーバへ設置するとコールバックの中でも動いたりする
実行環境が異なると、使っているライブラリも変わる
それと一般的には、動いたり動かなかったりするのは、非同期処理を勘違いしているとか。
promise とかで、ちゃんと解決してない
処理A, B の順番では動くけど、B, A の順番では動かないとか
1回目は、ファイルの読み込みに時間が掛かるから、エラーになっても、
2回目は、キャッシュから読み込むから、エラーにならないとか
ちゃんと非同期処理をやっていないのに、タイミング次第で動いているアプリは多い。
その特徴はエラーになったり、動いたりすること
ログを見れば、わかる >>286
> 客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
「言った」の主語が>>280に読める、と>>281は言ってる
>>287
> ○ はやり通じてねぇw
日本語頑張れ >>291
概ね同意だ。
善し悪しはさておき、WHATWGにあるのなら、今現在も仕様としてブラウザ開発者側に認識されているだろう。
なら、既に実装されて十分動いていたコードが意図的に落とされることはない。となると、
1. そもそも257のコードに問題があって、それが何らかの理由で顕在化しただけ
2. 元々ブラウザにバグがあって、それが検出されずにずっと残っていただけ
3. ブラウザのコードの更新時に、レグレッションテストに引っかからずバグを挿入してしまっただけ
のどれかだが、可能性が一番高いのは 1. だね。
俺自身はブラウザなんてバグだらけで全く信用ならないプラットフォームだと認識しているから、
こなれてない書き方は出来るだけしないようにしている。
そこではまっても本当に時間の無駄でしかないから。
だからそんなコードはさっさと書き直せ、という立場だ。
ただ、ブラウザのバグだという立場なら、バグ報告をするにしてもコードを切り分けていかないといけないし、
仮に 1. なら、idで書き直しても動かないケースが発生するはずだから、
どのみちそのコードに関しては詳細検討が必要になってしまったね。まあ頑張れ。
ある意味、「仕様外」だったほうが楽だったのではないかな?
もっとも、バグ報告したとしても、直すのも開発者側の自由だから、このまま放置される可能性もあるが。
JavaScripterは全般的にそうだが、最近の初心者は、仕様の隅を使いたがる傾向がある。
仕様を隅々まで知って、それを『使い切る』事がいいことだ/上級テクニックだと勘違いしている。
そういうところでしか差別化出来ないから、そういう小手先テクニックに異常にこだわるわけだ。
ただ、それが仕様内でも、それを動かすのは人間が作ったソフトウェアであって、
そこにバグがある可能性があり、実際、ブラウザなんてバグだらけだ。
こなれてない書き方をするのなら、それなりの覚悟と能力が必要だって事だ。
勿論それをやるのも自由だけど。
(もっとも、257がこなれてないか、と言われれば、こなれているが古い書き方、かな?) 最近の初心者が仕様の隅まで知りたがる?w嘘つけwww
仕様の隅まで知りたがるのはCおじさんとか古い人たちだろ。あの年代はCの仕様を勘違いしてたことがバレようものなら翌日から同僚に蔑まれてえんがちょされるような世代。
最近の特にWeb系のやつらなんか、必要になったらググって出てきたコードコピペする世代じゃんwwwww いろいろありがとう。
>>267 で言ったアクセス解析のJS(これまた別のドメイン extdomain2 にある)を外したら動くようになった。
このJSはページロード初期に動いて終わりだと思ったら、タイマーで定期的に動き続けてるようだ。
ビーコン的に外と通信してるわけでもなさそうだから何やってるのかは分からないし、>>257 の smtFrom1 と smtForm1Callback の間でその JS の処理は割り込んでないようだけど、
少なくとも初期に DOM をいじってるようだからその影響なんだと思う。
それでも smtForm1 では document.form1 を参照できてるから、関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど、現状の詳細を伏せたままここで話を深められるほど単純なことでもなさそうだから、ちょっと引きこもります。
ありがとう。 >>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を取り込むときに増えるのは分かるが、よく分からん時に増えるときもある) 仕様の隅とかカッコつけなくて良いから
ただ「俺はそんな仕様知らないし勉強する気もない」だけでしょ
自分の意見を表明するだけで良いところを
ひたすら他人を絡めようとする奴は程度が知れてる 防衛機制の一種だろうな。
誰でも自分が無能と認めるわけにはいかないのさ。 >>297-298
それが俺の自説を補強することにしかなってないことに気づけないのが、
お前らが馬鹿たる所以だよ。
マジでJavaScripterは馬鹿しかいない。これは断言出来る。
他言語と比べても相当酷い。 \__________________/
V
___ _
/ ____ヽ /  ̄  ̄ \
| | /, −、, -、l /、 ヽ きみ頭だいじょうぶ?
| _| -|○ | ○|| |・ |―-、 |
, ―-、 (6 _ー つ-´、} q -´ 二 ヽ |
| -⊂) \ ヽ_  ̄ ̄ノノ ノ_ ー | |
| ̄ ̄|/ (_ ∪ ̄ / 、 \ \. ̄` | /
ヽ ` ,.|  ̄ | | O===== |
`− ´ | | _| / | >>295
あと、実は、2.もあるかもね。
まともな奴(=バグ報告出来るレベルの奴)はそんな設計しないから、
バグ報告すら上がってきてない可能性もある。
1a. id
1b. document.forms[name]
1c. document[name]
でどれも動くとしても、まともな奴ならaかbだ。
「非推奨」なんて言われなくとも、推奨はaに決まっている。
そして、
2a. ノードそのものを渡す
2b. 名前を渡して、document[name]でアクセスしてもらう
ここもおかしいだろ。普通はaだ。
(決め打ち出来る状況だからだろうが、普通はその手の場合は決め打ちは無理だし)
おかしなコードが何故動かないか調査するのに精を出すよりも、
おかしなコードを修正する方に精を出す方が有意義だと思うが、まあこれは個人の自由だ。
ただ、俺は「仕様内」でもブラウザで動くかは信用ならんと実感しているから、
俺ならさっさと修正して終わりにするが。
(ブラウザのバグだとか言いだしたら長くcloseしない案件になってしまう。
ブラウザのバグ取りが目的ではないし) 正直、>>278以外に参考になるレスがない
>>279は気になってるんだが、本人から回答は貰えそうにないか… >>302
まずDocumentクラスの仕様を見るでしょ?
https://html.spec.whatwg.org/multipage/dom.html#the-document-object
// DOM tree accessors の getter object (DOMString name); を見つけるでしょ
その説明を見て終わり 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 >>294
コピペプログラマが無自覚で結果的に仕様の隅をつついたコードになっていることはあり得る。
彼等は書かないのだから、どういうコードが標準なのか当然知らないから。
ただ、本質的な問題はそこじゃない。
コピペプログラマがコピペしてきた元コードが糞だって事なんだよ。
コピペ自体が褒められるべき事ではないにしても、元コードがまともなら局所的にはまともなコードになる。
今回で言えば、誰かが最初に
document.name
の糞コードを書いた、ということなんだよ。
これがコピペであれば、どこかの馬鹿がドヤ顔で「こんな書き方も出来る(キリッ」した結果、ということだ。
正直、JavaScript界隈はこれが多すぎる。
糞コードが糞コードを再生産してて、しかもみんなそれに気づいてない。
JavaScript界隈はバージョン管理を止めてしまった。
結果、猶予期間中にアップデートして新しい書き方に変更していかないといけない状況になってる。
旧来の、バージョン○○では動きます、みたいな管理方法が出来なくなっている。
だからそもそも257流の管理方法は不適だ。
古い書き方のままでどこまで動かせるか厳密に言える状況ではなく、適宜書き換えていくしかなくなってる。
だから、本来は古いwebサイトは閉鎖されるべきなんだよ。
今 document.name なんて書いているまともなサイトがあるとは思えないから、
おそらくはかなり古いサイトを参考にしたか、どこかの馬鹿がドヤ顔したかだが、
正直、前者もかなりある。 質問です。
Parentを親に持つクラス Child には、自身のインスタンスを生成する関数があります。
(この書き方で良いのかは分かりませんが)
//基本クラス
class Parent{
}
//派生クラス
class Child extends Parent{
//自身のインスタンスを生成する
static CreateInstance(){ return new Child(); }
}
このとき、CreateInstance関数を
Parent側で用意するにはどう書くのが良いでしょうか。 >>309
ありがとうございます
こういう場合でもthisは使えるんですね まずWebの仕様とJSを一括にするのは違和感あるけど、まあそれはいいとして
今はWHATWGなどに立派な仕様があるんだからさ
それが元々どこかのブラウザの独自実装だろうが、デファクトだろうが、
ブラウザのお偉いさんが話し合って決めたことだろうが、
メーリングリストで決まったことだろうが、
なにがどうだって仕様は仕様なんだからさ、それを素直に参照すればいいじゃん
まあ色々言いたいことあるけど長くなるから取り敢えず1つだけにすると
Webって言うのは皆の合意、というより総意で決まって来たものだからさ
中央集権的な所が丸ごと決めきってから出す物と比べたら、
そりゃ良いところもあるし、同じだけ悪いところもある
でもその悪いとこだけを引き合いに出すのはおかしいと思うね
それはWebがWebの道を選んだ時点でどうしても付いてくる「特徴」だもの
それを改めようと思ったらWebがWebじゃ無くなっちゃう
WebはWebらしくて、他は他らしい、で良いじゃん
別にWebの特徴が嫌いなら他所へ行けばいいじゃん?
それをせずにそんな批判ばかりしたって、俺からすると、
「WebやWebの人間はこんな悪いとこがあるのに注目されて盛り上がっちゃって俺まで付き合わされておかしいだろ!」っていう妬みにしか聞こえないよ
でもたまたまラッキーでWebが発展できたわけじゃないからね
Webやコミュニティがこの形だったからこのよう発展できたわけ
それは事実として認めないとね > まあ色々言いたいことあるけど長くなるから取り敢えず1つだけにすると
うんとっても短いね棒 >>312
コピペか?ポエムか?
意味不明すぎ。
流れ上俺への批判だろうが、該当する箇所がどこだかさっぱり分からない。
お前も「JavaScripterは馬鹿しかいない」という俺の自説を補強したいのか?
他言語スレでは馬鹿が噛みついて来るにしても、少なくともどこに噛みつかれたかは分かるぜ。
お前らではまともに会話が成立しないではないか。 下記のjsonをJavaScriptの多元連想配列に格納する方法を教えてください。
{
"name1": {
"key1": "value1",
"key2": "value2"
}
}
$.getJSON(url) で取得はできますが、
どのようなアクセスでvalue1等に辿れますでしょうか?
json['name1']['key1'] == 'value1' を期待していますが違うようです。 >>315
$.getJSON( url, function( json ) {
console.log( json['name1']['key1'] );
});
俺ならawait fetch使うがjQueryがいいってんだからしょうがないね >>314
それ以上知能指数が低いアピール続けてると誰からも取り合ってもらえなくなるぞ
あ、もう手遅れかw 今どきjQueryでって頭が湧いてるとしか思えんな 荒らしと会話するな。質問に答えるな。
荒らしと会話するものも、荒らしと同じ
このスレで質問しないように!
JavaScript, jQuery のスレは、web制作管理板にあるので、そこへ書き込め
この板には、荒らしが多いから、書き込まないように!
他の質問スレにも、よくいる。
質問に答えると、お前に聞いていないとか、馬鹿とか、荒らしてくる奴が多い しかしこれは一方的に>>315が悪いだろ。
>>316で死ねと言われる理由もないし、そりゃ死ねと返すだろ。
まあこのレベルの質問はWeb板で、というのは同意だが。 ほんと、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年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか?この先の動向が注目される 近年jQueryは余計な機能減らしてきててDOM操作ライブラリへの回帰を目指している。
jQuery.slimには$.ajaxや$.getJSONは入っていない。 >>325
> jQueryの話題がでると、頭フットーするやつがいるなぁw
お前もな。
好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
急速に衰退するかは微妙だが、引き金になるとしたらWebAssemblyが成功したら、かな?
そう簡単に行くとも思えんが、あれはゲームチェンジャーになり得る。 >>327
> 好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
> それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
逆逆w 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どう考えても終わりません。不安を煽って間違ってる方向へ変えようと、
明らかにずれてる方向が正しいんだと、布教してるやつがいるから事実を伝えてるだけ
jQueryの代替なんてまだ登場してないんだよ。React?Angular? WebAssembly?
それらはjQueryの代替ではなく大規模なウェブアプリを作るためのもの。
ウェブサイトに適してるのは昔も今もjQueryだ。
jQueryが終わるとしたらWeb componentsが完成して、
使えるコンポーネントが "出揃った時" だろう
つまりウェブサイトを作ってる連中が「JavaScriptなんて全く使わねぇ。
誰かが作ったコンポーネントを使ったHTMLを書くだけで終わり」と
言い出すまでってことだ
そうなれば本来あるべき完全分業の世界に行くことができる。
HTMLのパーツを作るのはプログラマ。それを使うのはウェブデザイナー。
今はウェブデザイナーが書いたHTMLにJavaScript(jQuery)で動きをつけるという形で分業している。
jQueryを使うのはJavaScriptよりも圧倒的に楽だから。セレクタを使うからウェブデザインとの相性も良い。
React、Angular、WebAssembly などはウェブデザイナーの仕事であるデザインの作成を
プログラマの領域に吸収するやり方なので、世界の大半を占めるウェブサイトには全く適していない 世界の大半を占めるウェブサイトは
「まず最初にHTML+CSSを書く」ということを
しっかりと認識するようにな
まず最初にビルド環境を整えましょうじゃないんだよw IE11のことを考えないコードを指摘するのは人間のクズ
JQの時点でお察ししろクソ野郎
ちなみに、あたしはクソ女だからな!
女の言う事は従えよ? >>328
> 逆逆w 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どっちが先とかはどうでもよくて、お前も必死過ぎなのは事実だよ。
どうしても、jQueryは不滅です、ってことにしたいんだろ。それもまた、不安だからだよ。
> 今はウェブデザイナーが書いたHTMLにJavaScript(jQuery)で動きをつけるという形で分業している。
> ウェブデザイナーの仕事であるデザインの作成を
> プログラマの領域に吸収するやり方なので
この、君の現状認識については同意出来る。
> 「まず最初にHTML+CSSを書く」ということを
これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
CSSの恩恵を正しく受ける為にはクラス設計が必要となる。
そしてそれは工程が逆転する、つまりプログラマが上流、デザイナが下流になるから、
Webデザイナが牛耳っている職場ではかなり無理がある。変化するにしても時間はかかるだろう。
それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
どっちに賭けるかも含めて、個人の自由だ。
> jQueryの代替なんてまだ登場してないんだよ。
jQueryの売りはCSSセレクタで、それは標準に入ってしまった。
大体それ以前に、まともにクラス設計されてたら getElementsByClassName だけで済んでしまって、
querySelectorすら必要ない。(アプリならqueryすらしないし)
その他諸々jQueryが色々便利に出来ていることは認めるが、
最早、無ければ無いでいいや、程度でしか無いと思うが?
まあこれについては水掛け論だからもういいが、
少なくとも、俺と同じ「もう要らないんじゃね?」と思う奴が一定数居るからこそ「不要論」が出るわけで、
そこは君も認めないと駄目だと思うぜ。 jQueryはHTMLベースになる点が本質的に筋が悪いんだよ。(逆に、それが取っつきやすい点でもあるが)
だから頻繁にリニューアルするサイトならCSSベースの方が効率がいい。
文書を流し込んで出来上がり、だからだ。
(そしてその場合は、CSSクラスをがっちり組んでしまう為、jQueryの恩恵がない)
その点、おそらくWordPress等もそこを目指しているはずだが、
いまいちjQueryが死にきってないところをみると、
WordPressではJavaScriptをある程度書かないと駄目なのかな?
まあそれはさておき、
> 世界の大半を占めるウェブサイト
はつまりほぼ静的なサイトであり、お約束的動きしか必要ないのだから、(ハンバーガーメニューとか)
最終的には静的ページ用のフレームワークで全て終了するようになるはずだが。
Hugoとか、どこまで出来るのか知らんが、出てきてるだろ。
他サイトでやってない動きが必要なら自前で書くしかないけど、ほぼ静的サイトでそれは不要だろ。
デザイナがJavaScriptを書かなければならないのは、環境が整備されてないからだよ。
そしてプログラマにとってはjQueryはもうどっちでもいい存在になってる。
或いはここは君も同意してくれるのかな?
> jQueryが終わるとしたらWeb componentsが完成して、
> 使えるコンポーネントが "出揃った時" だろう
確認してみたが、この意見にも同意出来る。
ただ、若干大がかりすぎるとは思うが。俺は静的HP用フレームワークでいいと思うぜ。
shadowDOMなんてここで持ち出す必要なんて無いと思うのだが。
あと、デザイナはどうしても独自の動きを付けたいのかね?
だとすると、永久に「出揃う」事はないが。
とまあ、つらつら書いてみたが、俺と君の認識は似ている、というかほぼ同じだろう。
WebAssemblyについては、俺は「プログラマがjQuery禁止にされる理由」になり得ると見ている。
今現在jQueryを使って悪い点は、第一に速度面だろ。だから。 馬鹿って変なところにこだわって前へ進めないままなんだよなあ
そういうの捨てれば楽になるのに jQueryの遅さは機能性から来るそのDOMAPI利用の冗長さにあって
WebAssemblyでDOMAPIを叩ける用になっても同じことをすれば速度は変わらないだろ
こいつホント中身スッカスカの思考しかできない、文字通りのカス ブラウザもPCもどんどこ高性能になってるよ。
そんなに言うほど遅くない。
慣れている物で素早く開発し、ちゃんと制御することも大事じゃん。 >>331
> > 「まず最初にHTML+CSSを書く」ということを
> これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
中途半端に引用するな
ほんとな。わざと1行で書いて、都合よく引用させないように
徹底しないといけないよな
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」ということを
ってかいただろ
プログラマ的に間違ってるとか、大半を占めるウェブサイトになんの関係があるんですか?
上で、ゲームチェンジャーになりうるとか言ったが、なんのゲームを変えるのかを
明確に言ったらどうだ?それは「プログラマ的なゲーム」だろう
チェンジするのはウェブサイトの世界じゃない。デスクトップやスマホアプリ・ゲームの世界だ
デスクトップやスマホと言ったウェブでない世界を壊してウェブに来るだけの話
その場合になくなるのはjQueryじゃなくて.NET FrameworkやUnityだよ WebAssemblyとか語るやつは、新しく何ができるかしか言わない。
何がどう楽になるのかをけっして言わない。
なぜか?それを言ってしまうと「あぁうちには関係ありませんね」って
言われるのが目に見えてるからだ
WebAssemblyで楽にならないわけがない。では何が楽になるのか?
マルチプラットフォームのアプリをウェブアプリにするのが楽になるんだよ。
いまウェブの大半を占めるウェブサイトの制作が楽になることはない
新しいことができるようになったら、みんな新しいことをするはずだとか
思ってるのかもしれないが、大半は新しいことなんてしようと思っていない
今の仕事が楽にしようと思っている。
だからWebAssemblyもそうだし、JavaScriptフレームワークの導入も大変だし、
jQuery捨ててDOM APIを使うのも、大変になるだけなので使おうと思わない。
そしてjQueryのスピードにも全く困っていないというのも重要な所だな >>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 jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな
そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
だから新規で作るものはjQueryを見送ってるし
保守してる人間たちはこれから廃れていくjQueryにしがみつくしかない
JAVAと同じだな > jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな
1.7(2011年11月)ぐらいから殆ど変わってないんだが?
もう7年も前だぜ・・・
> そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
ESとは対象分野が違う、ESにDOM操作の命令はない
そういう基本的なところを分ってないやつが
> だから新規で作るものはjQueryを見送ってるし
とかいっても、説得力ゼロだよw 俺が老害かどうかじゃなくて、現実を見たほうが良くね?w
老害と言われた俺が言ってることが、現実となってるとしたら、
それはどういうことなんだろうね
React、0.6%から0.1%にシェア減っちゃいましたよ? >>303
ありがとう
意外と単純な探し方でびっくりした
宗教論よりこういう書き込みが増えてほしいな >>336
意図的におかしな引用をしたつもりはないが、そう取れたのならすまんかった。
現状認識において、俺と君には大差ない。再度確認するなら、
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」
そうだ。正確に言えば、そうだった。これが変わりつつある。
> いまウェブの大半を占めるウェブサイトの制作が楽になることはない
これが違う。静的HP用のフレームワークを使えば、楽になる。
本来はWordPress等もここを目指しているはずだが、
JavaScriptをいちいち書かないといけないのなら、それは上手く行ってないだけだね。
> そしてjQueryのスピードにも全く困っていないというのも重要な所だな
これはそうだとも言えるが、そうでも無いとも言える。
そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
それがJQueryかどうかは別だが、
フレームワークもjQueryも無しなら(いろんな意味で)遅いサイトになりにくいのも事実だ。
結果、素で書け、と言われるのもまた然り。 が、話が広がりすぎるので絞ると、
・デザイナ(またはその下請けが)JavaScriptを書かなくてよくなったときにjQueryは終わる
というのは俺も君も共通見解だ。これはいいな?なら、逆説的に、君も
・プログラマにはもう既にjQueryは無用の長物となっている
事を認めることになるが、ここまでもいいよな?
そしてデザイナがいつJavaScriptを書かなくて良くなるかは、
・Web componentsが完成して、使えるコンポーネントが "出揃った時" (君)
・静的HP用フレームワークが整備され、普及したとき(俺)
と詳細な意見は異なるが、まあこれは誤差の範囲だろ。
> いつまで待てばいいの?w
「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
なら、10年後くらいではないかな。
今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
そしてその彼等が主力、具体的には30代前半にさしかかり、
「jQueryなんて要りません」派が現場での主流派になったときに牙をむくってだけの話さ。
が、正直なところ、俺と君には議論になるほどの意見の相違はないぞ。
別段、君の現状認識に間違いがあるとも思えないし、jQueryが死ぬにしても時間はかかるよ。
もし頓死する可能性があるとしたら、WebAssemblyの出現によって次の次元のスピード競争に巻き込まれたら、って話さ。
ただ、正直、俺にはWebAssemblyがどこを目指しているのかよく分からんし、そもそも立ち上がるかも微妙だとは思う。
だからって、jQueryが安泰で未来永劫使われる、ってことも無いよ。繰り返すが、
今から始める人にとっては、「重複機能ばっかり…」なのも事実だろ。 >>344
> そうだ。正確に言えば、そうだった。これが変わりつつある。
ねーよw
少なくともウェブデザイナがJavaScriptを書くことはない。そうだろう? >>345
> そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
> それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
> それがJQueryかどうかは別だが、
> フレームワークもjQueryも無しなら(いろんな意味で)遅いサイトになりにくいのも事実だ。
> 結果、素で書け、と言われるのもまた然り。
やっぱり、実行速度しか目に入ってないんだなw
かわいそうに。
ほとんどの人は、楽になる方法しか求めてないよ
jQueryをやめて楽になるか? 何一つ楽にならない
速いとか遅いとか言ってる限り、現状のjQueryのシェアが
落ちてない事実は理解できないだろうよ > 今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
同じことをこんなに簡単にできるなんて!
としか思わないよw
楽になるかどうかだからね。 document.querySelectorAll() を
$() とかけるだけで、素晴らしいって思うだろうねw >>345
> 「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
> なら、10年後くらいではないかな。
「staticおじさん」なる言葉が発生したときには、staticばかり使ってる人はすでにいなかったわけだが、
jQueryの場合、使っている所が大半を締めてる。状況はぜんぜん違うんだが何と何を比べてるんだ? まあ、適材適所っしょ。
React信者は自分のスキルセットを至高で唯一の物だと思いがち。
jQueryで十分なものもあれば、Vueで十分なものもあるし、Reactが適してるものもある。 >>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流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。 いちいちなげーんだよ
ここ質問スレだよな?よそ行ってやってくれんか >>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 >>353
やっぱり、実行速度しか頭にないのなw
視野狭過ぎでワロタw
実行速度も何が何でも速いと思ってる。
そんなに実行速度が重要ならブラウザ使うの止めたほうが良い
速度は許容範囲かどうかで決めるものだ
今jQueryを使ってるサイトは、jQueryの速度が許容範囲ってことだ
なにせ一回読み込めばキャッシュが効くからな
遅いのは最初の一回だけという
> ただ、既に書いたように、jQueryはHTMLベースになる点(なりがちな点)が本質的に筋が悪いんだよ。
ウェブはHTMLベースで書くのだから仕方ないな。むしろHTMLベースで使いにくいものはだめだろう
> 『今から』10年後な。
「jQueryはオワコン(10年後にな!)」
もうこれ完全に不安煽ってるもの以外の何物でしか無いわw
> 「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
暗記済みの状態で楽なのはjQuery。覚えるのが嫌いな人っているよね
覚える苦労をして、後の開発を楽にする
VS
覚えるのが嫌だから、開発で大変な思いをしてまで、今楽をしたい
> 君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
切れないが? ソフトウェア開発において覚えることこそが技術力だし。そうやって覚えてしまうことで
読まなくて良いコードを増やしていくことで、開発速度はあげられる。
もっとも何でも覚えられるわけがないので、より汎用性があって世間でよく使われてるものに限ったほうが良い
つまり、オレオレライブラリなんか覚える価値がないってことな >>355
> 結構な時間です
誰も速度の違いに気づかないレベルでした 実行速度と通信量は重要な要素なわけだよ
昨今は多言語対応も要求されるだけに余計にな >>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 >>356
> ソフトウェア開発において覚えることこそが技術力だし。
これは違う。やはり君はプログラマではない。だから分かる必要もないんだが、
ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
ただ、HTMLベースでやると、君みたいに暗記主体の積み上げ方式で出来るのも事実なんだよ。
だから、君のタイプは今後ともjQueryを使い続けた方が効率はいいし、おそらく君はそうするだろう。
一方、ある程度の能力を備えたプログラマにとっては、抽象化が使えるCSSベースの方が効率がいい。
そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、
強烈に嫌う奴も出てくるわけでさ。
同様のことはPHPにも言える。
PHPも仕様が糞すぎて、いちいち場合分けが必要になり、プログラミング上級者でも綺麗に書けなかったりする。
だから、上級者こそPHPを目の敵にする。
ところが、初心者〜中級者成り立ての程度なら、あれくらいのベタさ加減が丁度いい。
そして、自分達よりも綺麗に書ける上級者が存在しないから、彼等にとってはそれなりに快適な状況になってる。
ただ、上質なコードがその世界に存在しないことは本当に問題で、
結果、上質なコードを見たことがないから、PHPerは自分達のコードがトンデモだ、ということに気づけないでいる。
それがPHPerがやたら叩かれている理由だよ。
彼等の自己評価と、外部から見た客観評価に、ズレが有りすぎるのさ。
ま、これは正直、俺はJavaScripterにも当てはまると思っているけどね。
分かるか?両者が矛盾しているわけではないんだよ。
jQueryを使った方が効率がいいタイプもいれば、jQueryを捨てた方が効率がいいタイプもいる。
暗記ベースなら前者で、抽象化ベースなら後者だ。そして一般のプログラマは後者なんだよ。
だから今後ともjQuery不要論はずっと水掛け論になるんだよ。
言ってしまえばお互いポジショントークをしているにすぎないから。
ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、
CSSで行ける奴、或いは両方とも出来る奴は、CSSベースを選択することになる。
結果、HTMLベースの奴は取り残され、馬鹿にされるポジションになる、というのが俺の見立てであってさ。 >>360
> ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
お前、論理的な思考が出来てないなw
俺は覚えることが重要だと言ったが、抽象化能力とその応用力が不要などとは一言も言ってない
また暗記とは言ってない。細かい違いだが、どんな機能があるか覚えていればいいだけ
暗記(何も見ないでかけるようにしろ)とまでは言ってない
覚えることが重要だと言ったが、お前は覚えることは重要ではないと言うわけか?
少ない語群だと、文章を適切に伝えられないぞ
数学で数式を使うのは、短い文章(数式)で正確に意味を伝えるためだ。
数式を覚えてないなら、長い文章を読み書きしなければいけなくなる
それをソフトウェアでは「冗長」という。
「冗長」はバグを増やしテスト時間を増やすことにつながる
jQueryはその「冗長」を減らしてくれる。 > ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、
HTMLベース VS CSSベースの話をしてるのは
お前だけだけどなw
意味がさっぱりわからんし。
適切な構造でHTMLを書いて、それに合うようにCSSでデザインするだけの話
最後にCSSでもできないことがあれば、JavaScriptを使う
アニメーションとか昔に比べてCSSでできることも多くなったしね。
それがウェブサイトの基本だよ。
基本なのでこれは変わることがない > そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、
あ、コレ言うやつよくいるよなw
糖衣構文"でしかない" というやつ
俺は、糖衣構文という素晴らしいもの という立場だからな
なぜ他のやり方でもできることなのに、わざわざ糖衣構文があるのか?
それは、糖衣構文があれば簡潔に正確に意味と意図を表現できるから
数式と一緒 あとPHPのはないウザい。関係ない話だろ。
自分が嫌いなものは嫌いって言って全部一緒くたにしてる証拠
客観的に物事を見れてない あとjQueryのはないウザい。関係ない話だろ。
言語(Javascript)とその言語で書かれたライブラリ(jQuery)一緒くたにしてる証拠
客観的に物事を見れてない jQueryはJavaScript用のライブラリなので関係あり jQueryはJavaScript用のライブラリなので、jQueryの質問はjQueryの仕様による。JavaScriptの仕様から求まるものではない。
↓の専用スレに行け。なんで行かないの?
+ JavaScript & jQuery 質問用スレッド vol.8 +
https://mevius.5ch.net/test/read.cgi/hp/1510321470/ >>367
(ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです) >>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ベースだ。(HTMLがマスタデータ)
> それだと、どうしても開発効率が上がらないんだよ。
???
え、なんで?
例えばHTMLに「こんにちは」って書く場合
HTML以外の何を使ったら、どう開発効率が上がるんだ?
もう少し、○○という理由で、開発効率が上がるって書いてくんない?
根拠が待った書いてないからさ > 理由は簡単で、変更の多いHTMLおよびCSSが上流に来ているから。
> HTML/CSSを変更するたびにJavaScriptまで変更/検証する必要があり、ループが大きいんだよ。
おまえ、下手なんじゃね?
JavaScriptはHTMLの変更に影響をつけないように作れよ
ほんと、下手 HTMLは文章は変わるが、HTMLの構造は一旦決めたら変わらないんだぜ
トップページ、一覧ページ、詳細ページ
これぐらいの区別があるだけ、ページごとにHTMLの
構造が変わっていたら、見づらいだろ
そしてJavaScriptは、特定のクラスに対して処理しますって書くだけ
ウェブデザイナさんに、こういうクラスつけておいてくださいね。
そのクラスつけておいたところは、こうなりますから〜って伝えるだけ
クラス設計?そんな大げさなものじゃない。
1つ(ないし数個)クラスを作って伝えるだけ > CSSベースってのは、CSSクラスをまず設計して(マスタはCSSクラス)、それに対してJavaScriptを書き、
> そこに合うようにHTMLを書いて、最後に再びCSSで装飾を付けるんだよ。
> まともなサイトはほぼ全てこれだから、見てみればいい。
つまりCSSクラスを最初に設計して、JavaScriptを書くから、
jQueryが適してるって話にしかなってないんだが? jQueryとCSSは非常に相性がいい。
.foo { color: red }
$('.foo').css({ color: 'red' })
書き方が違う程度で非常に近い書き方ができる。
セレクタに対して何かを適用するという考え、
セレクタベースだからだ
querySelectorAllだとこうは書けない。
単にセレクタで検索するだけだから、
その後ループして処理するという発想になる
CSSベースの開発ではjQueryを使うのが相性がいいし
そこがDOM APIでは越えられない壁。
あとどうも俺をHTMLベースとか言ってるようだが、
HTMLベースとCSSベースを分けて考えるなら、
俺はCSSベースだなw
繰り返すがCSSベースはjQueryと非常に相性がいい >>329を見ればわかるが
> 世界の大半を占めるウェブサイトは
> 「まず最初にHTML+CSSを書く」ということを
> しっかりと認識するようにな
最初に書くのは「HTML+CSS」だ
俺はHTMLを書いて、それに対してjQueryで処理しろとかいう話はしてない
何故か勝手に俺がHTMLベースだと決めつけられたw
jQueryはCSSベースになるし、CSSベースはjQueryと相性がいい まあ、君は、他のサイトをよく見て学べばいいと思うよ。多分それで解決する。
今のままなら、「jQueryおじさん」だな。 バカかなこいつ。jsで書かれたライブラリなんだからjsでできることをまとめた関数以上でも以下でもない。
jQuery内部ではquerySelectorを使える環境ではquerySelectorを使うようになっている。
わざわざSizzleというセレクタライブラリを内包しているのになぜ?
それは遅いからwwwww 自分が依存してるホスト言語様にケンカ売るとかwww何様のつもりだよ替えのきくライブラリのクセにwwww >>378
> わざわざSizzleというセレクタライブラリを内包しているのになぜ?
1. 昔はブラウザにquerySelectorが搭載されていなかった
2. ブラウザ間で対応しているセレクタの違いに対応するため
3: :has擬似クラスのような今のブラウザ使えないが、標準化される見通しのセレクタに対応している
4. :inputセレクタのようなjQueryによって拡張された便利なセレクタが使える
5. セレクタの拡張機能を使って独自のセレクタを作成可能
6. 特定ブラウザのセレクタバグの回避
こんなところかな >>378
> jsでできることをまとめた関数以上でも以下でもない。
焦点は同じことをいかに楽にできるかどうかだよ >>377
> まあ、君は、他のサイトをよく見て学べばいいと思うよ。多分それで解決する。
どのサイトでもjQueryが使われてる
それを見てよく学んだw JQueryはWeb業界のCOBOLとして残るやろ
どんなに新しくて思想が素晴らし技術でもも土方が使いこなして
コピペ量産できるレベルじゃないのと流行らず終わってしまう COBOLとの違いはDOMよりも優れているってことかな
jQueryはDOM APIと違ってCSSベースだからね jqueryはEventEmitter的なやつが入ってるも便利なんだよなあ ブラウザ非互換の対応をしようとすると結局ライブラリ作る羽目になるんじゃないの。
おれも極力素のJSで軽量に済ませるようにしてるけど、やっぱそういう下らない作業からは解放されたいな。 .ready()みたいなやつを自分で書くのが地味に面倒 自分とこはもう全部type=moduleでやってて
どうしても必要なとこではnomodule使うけど
基本的にIEとかではJS働かせてないな
もう確認もしてないし
あとはCanvasを積極的に使うのが互換性対処の肝かな
そうすればあってもちょっとした条件分岐くらいで
ライブラリ規模のをつくることはまず無くなる とまあ、ウェブサイトではまず使わないCanvasとか言ってる時点で
ウェブでは例外にあたるサイトの話なわけでw
どうせゲームだろうな >>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を初めて、まだキャズムを越えてないから大騒ぎしてる、ってとこか? ゲームだけでは無いよ
vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
まあそれがjQueryの代わりっちゃ代わりのようなもんか
イベントバブリングやアニメーションも対応してるし、
操作対象をDOMにしたり、混合させて利用する事もできる
普通じゃないって言うけど、HTML5以降Webって言うのは
アプリケーションプラットフォームになったという認識で作ってる >>391
> だからお前はHTMLベースだし、大半のjQuery使用者もHTMLベースなんだよ。
CSSベースだってw
jQueryがCSSと相性がいいのわかってるだろ?
それにDOM APIはHTMLベースってことになるのわかっていってるのか? >>391
> 脱jQueryをやったサイトを確認して、(最近ならGitubか?)
> 何故彼等はそういう判断をしたのか、結果、どう変わったのか、
どう変わったのか言ってみ?
俺、変わった所、全然わからない。 >>392
> アプリケーションプラットフォームになったという認識で作ってる
アプリケーションプラットフォームとしても使えるようになったからって
俺もアプリ作るぞーってなると思う?w
上の方でも言ったけど、ウェブがアプリケーションプラットフォームとなって
変わるのは、ウェブサイトじゃない。
デスクトップや家庭用ゲーム機やスマホアプリの世界から
人が去っていくことになるだけだよ。変わるのはそこ ウェブサイトは今のままウェブサイト
ウェブサイトがアプリになるわけがない
だからWebAssemblyとか、jQueryの代替じゃないんだよ。
jQueryをやめて使うものじゃない。
WebAssemblyとかは.NET FrameworkやDirectXや
OpenGLやUnityをやめて使うものなんだよ >>393
その意図的な誤用は止めろ。
「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。
HTMLベース:HTMLがマスタ
CSSベース:CSSクラスがマスタ
> それにDOM APIはHTMLベースってことになるのわかっていってるのか?
そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。
とにかくお前は他人がどういう作りにしているか、学んだ方がいいと思うぞ。
>>394
GitHubについてはスゲー変わったけどな。
分からないのなら、それでいいと思うよ。
ただ、変わった原因はjQueryでもないとも思うが。
GitHubは元々がポンコツすぎた。 いい加減誰が何主張してるのか追う気も無くなってきたけど、結局どうしろと言ってるの。
自分の書いたサイトのURL貼って説明してみてよ。 > 「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。
そうじゃない理由をいうかと言えば、何も言えないwww
> GitHubについてはスゲー変わったけどな。
変わった点を言うかと思えば何も言わないwww
ホント説得力皆無やでw
> そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。
jQueryはセレクタを書くだけでクエリはやりませんねw >>392
> vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
これだよね。
フレームワークが流行らない一つの原因は、自前で用意しても出来てしまうこと。
> アプリケーションプラットフォームになったという認識で作ってる
プログラマはその認識で正しいと思うぜ。
ある意味、ドキュメントも、
・マークダウン等でHTMLを直接記述(少なくともHTML生成までは面倒を見る)…旧来手法
・テキストだけ書いて、ドキュメントアプリに流し込めばWebページ完成…アプリ的手法
があって、後者はブログなり静的HPフレームワークになるわけだが、
記事書きたい奴はhtmlを書きたいわけではないから、自然と後者によってくると俺は見ている。
とはいえ、そういう時代になっても、
とりあえず1回書けばいいだけなら、HTMLじか打ちの方が楽だし、旧来手法もある程度は残るだろうね。 jQueryはCSSベースなのでCSSと相性がいい。
例えば、jQueryでCSSと同じように色を付ける場合、
CSSで書いたのと同じように "セレクタ" に "色を指定" する
まあCSSの範囲はCSSでやればいいんだが、
jQueryはデザインじゃなくて、イベントに関しても
CSSと似たような形で、 "セレクタ" に "イベントをバインド" する
CSSは要素がなくてもエラーにならないが、jQueryも同じように
要素がなくてもエラーにならない。CSSと非常によく似ている。 HTMLベースとかCSSベースってのもどういった概念を指してるのかわからないけど、セレクタで抽出したエレメントを操作するのがHTMLベースで、CSSクラスの定義を操作するのがCSSベースってこと? アプリケーション開発のプラットフォームは
jQueryの代替にはなりえない。
重要な点の一つだね。
みんながみんなアプリケーションを開発しているわけじゃない
ウェブの殆どはサイト
みんなが見てるのは、ウェブサイト >>402
jQueryはCSSでも使われるセレクタに対して処理を適用する
だから最初にCSSのクラス設計を行う必要がある。
だからCSSベースらしいw >>399
jQueryおじさんは、違いの分からない男であったか…
(もっとも、このスレにはこれが分かるおっさんの方が少数派の気もするが)
つか、あれで分からないのなら、感度がないんだよ。
こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。 >>405
いや、お前がやるべきはぐちじゃなくて
俺が言っていることへの指摘だろう?
結局何も言えない。
githubもjQueryやめた効果を何も書いていないw >>404
セレクタに対して処理をするんじゃなく、セレクタでセレクトされたエレメントを操作するんだよね。
んで >>397 で言ってるクエリ自体をやらないってことは、セレクタでエレメントを抽出せず操作するってことじゃないのかな。
とするとDOMは操作せずスタイルだけをいじるって趣旨なんじゃないのかな。
早い話、セレクタで操作対象のDOMエレメントを抽出した時点でHTMLベースだという主張ではないのかね。 > こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。
なんの話?
jQueryは今も世界中で動いていますね
世界の7割を超えるサイトで使われてるので
普通にサイト見てるだけでjQueryが問題なく動くことが証明できてる >>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自体は宣言型で設計されてるんだよ。 >>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ベースには「マスタデータが直接見える為、ものすごくデバッグし易い」という大きな利点があって、
つまりはこれが蔓延る原因となっている。 >>395
ちょっと考え方が違うんじゃない?
WebやHTMLは文書のための規格として始まったけど、
今ではそうじゃないじゃん?
Web3.0っていう言葉もあるけど、
まだ「インタラクティブな文書表示」とも言えたWeb2.0の段階を
だんだん超えてきてるとは思わない?
別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、
いつの間にか作ってるものが「文書」を越えたアプリケーションになっていくって言うのが
ある意味自然な流れだと思うよ
Webサイトって言うのがもう「文書を提供する為の場所」だけではどんどんなくなってると思うけどな
別にゲーム的なものに限らなくてもね >>409
集合に対する処理系なのか自前でループするとかそんな話じゃなく、そのコードで言えば $('.foo') でセレクトされたエレメント(達)に対して .css({ color: 'red' }) という操作をしてるんでしょ?
それを HTMLベースと言っていて、foo のスタイルそのものを変更するアプローチが CSSベースと言ってるんじゃないのか、という確認だよ。 >>411
> WebやHTMLは文書のための規格として始まったけど、
> 今ではそうじゃないじゃん?
なんで技術主導で考えてるんだよw
一番最初に来るのは「要求」何をしたいかだ。
いくら何かができるようになったとしても、
それを使ってなにかしたいという「要求」がなければ使わない
新しいことができるようになったからって
誰もが新しいことするわけじゃないんだよ。
スマホができたからって、誰もがスマホアプリ作ったりしないだろうが?
ウェブをアプリプラットフォームとして使いたいと思ってるのは
今アプリを作っている所で、ウェブサイトの世界からすればよそ者 > 別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
> 表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、
起きてない。mozillaのウェブサイトだって、殆どが静的コンテンツ
ページ開くたびに音楽流すとか、アニメーション流すとか
3Dでキャラクターがグリグリとか、やらないからさw >>412
言う必要なさそうだが、その解釈であってる。
HTMLがマスタデータだから、更新時にはHTMLを更新しなければならない。
CSSクラスがマスタなら、更新時にはCSSクラスを更新(add/removeまたはスタイルリスト操作)することになる。
まあこの「CSSベース」が分かりやすい呼称かはさておき、
マスタデータが○○なら、○○ベース、と呼んでる。(今ここでは) >>412
> そのコードで言えば $('.foo') でセレクトされたエレメント(達)に対して .css({ color: 'red' }) という操作をしてるんでしょ?
だからjQueryはそういう発想で使うものじゃないってこと
間違った発想で使ってるやつが非常に多いのは事実だがね
だからjQueryはHTMLベースとか言い出すアホがでてくる
内部はそうなっていても、jQueryは宣言型として考えることができるようになってる。
ループも条件分岐も書かなくて良いようになってる
だから同じ宣言型のCSSと非常に相性が良い jQueryはCSSベースなので、具体的なHTMLタグのことは考慮しない。
できるかどうかは置いといて、jQueryはクラスベースでプログラミングする
特定の名前のクラスの要素(それがHTMLのどのタグかは意識しない)を
どのようにするかという宣言で書いていく
CSSのクラスベースなのでHTMLがどのように変わっても問題ない。
jQueryではCSSを直接変えるのは基本的にしないでCSSクラスの更新を行う
jQueryでやるのはCSSクラスの更新=状態の変化だけだ >>410
CSSベースのアプローチの真髄が分からんのだけど、HTML の構造に縛られなくなっても CSS の構造に縛られるようになるんじゃないの?
改修する時にはどのみちどちらかには手が入るからJS側の調整も無くなるわけじゃないだろうし、やりたいことの全部が CSS だけでできるわけでもないだろうし。
まあエレメント抽出なんてする必要が無いと言ってるわけじゃなく、基本をどっちに置くか程度の話だと思うけど。
まあおれも何するにも $('.foo') で始めるのはどうかと思うよ。コスト的に。
でも操作対象は明確だから、書き方としては悪くないと思う。 >>416
なんか書き方で言ってるのか動きで言ってるのかの違いっぽいのかな。
おれは書き方は結構スマートだと思うが動きを考えると使う所を選びたいといった感覚だけど。 もう少し具体的に書くと、例えば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要素に対してこの処理が適用される
条件分岐も不要で、クラスを変えることでデザインを適用する >>406
>>408
お前はまず全部読んでから、整理して回答する癖を付けろ
> なんの話?
GitHubの話に決まってるだろ
>>409
なるほど君は典型的なjQuery廚か。まあ、この点は分かりやすくていいね。
そうだ。それがjQueryの典型的な書き方で、結果、ものすごくもっさりするのも事実だ。
そしてjQuery厨は君のようにそれを「大正義」だと思っているらしく、
どんなにもっさりしていてもその書き方を止めない。
「宣言型」だからこの書き方の方が素晴らしい!と本気で勘違いしてる。
ただ、プログラミングってのは手段であって、目的ではない。
ユーザーは、そのサイトが快適かどうかは気にするが、中身のソースコードなんて気にしない。
宣言型の方がソースコードの管理は楽だし、HTMLベースの方がデバッグしやすいのも事実だが、
ユーザーエクスペリエンスを損ねるようでは意味がない。
ただ、CSSベースでも宣言型ではあるし、実際そんなに難しくもならないから、まともなところは既に移行済みだ。
そしてjQuery廚だけが取り残されつつある、というのが今だね。 そういや、仮想DOMは最終的に遅いっていう話があったな
仮想lDOMはDOM全部入れ替えよりも速いというだけで
そもそもDOM全部入れ替えなんてしねーよという話 >>421
> そうだ。それがjQueryの典型的な書き方で、結果、ものすごくもっさりするのも事実だ。
もっさいりしているという証拠は?
結局いつも出せないんだよねw > ユーザーエクスペリエンスを損ねるようでは意味がない。
はい、宣言型のjQuery使って
ユーザーエクスペリエンスを損ないません。 >>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ベースにしても、特段分かりにくくなるわけでもないのも事実で、
実際に軽くなるんだからまともな奴はみんなそうしてる、ってだけでさ。 id="css1" の style の一件目が .foo { color: red; } だったとして、
$('.foo').css({ color: 'blue' }) とやったら HTMLベースと言ってるのは合ってると思うが、
document.getElementById('css1').sheet.cssRules[0].style['color'] = 'blue'; とやったら CSSベースで合ってる?
つかそれはそれとしてルールへのスマートなアクセスのやり方教えて。 >>426
> document.getElementById('css1').sheet.cssRules[0].style['color'] = 'blue'; とやったら CSSベースで合ってる?
いや、そこは普通にクラスを足す。具体的には、
e.target.classList.add('highlight') とか。
.foo.highlight {color:blue;} は当然最初から書いておく。
つかここら辺は普通のサイトはこうしてるから、見ればいいと思うよ。
絶対にHTMLをいじらない、というわけではない。ましな方を適宜選択するだけ。
スタイルルールをいちいち書き換えるコードは、あまり使っている奴は居ないと思うぞ。
それよりは、スタイルリストごと全部入れ替えてると思う。 >>427
となるとエレメントに対してクラスを追加するという操作をしてるんだから、HTMLベースと言ってるところと一緒に思えるが、
またCSSベースが指す概念がよくわからなくなってきたよ。
CSSの定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。 >>428
そこは説明用の言葉を考えただけだから、過度に拘る必要はないが、
CSSがマスタなのは変わらないし、DOMクエリが必要ないのも変わらないだろ。
CSSは最初から .foo.highlight を持っていて、HTMLが変化しただけ。
俺がCSS「クラス」と言っているのが不味かったか?
CSSでは文法上分離してないが、あれは「構造クラス」と「デザインクラス」と分けて考えるべきで、
.foo は「構造クラス」で不変、.highlightは「デザインクラス」で適宜追加/削除するもの。
「構造クラス」はJavaScriptの「クラス」と同じで、またOOPの「クラス」とも同じ。変わることはない。
そして最初に設計されるべき物。
「デザインクラス」はただの追加アトリビュートだ。見た目を変える為に動的に追加/削除/変更される。
上記の通り、CSSクラスの使い方はOOPと同じだから、OOPを理解している奴は普通に適切に使える。
ところがJavaScripterにはOOPを理解してない奴も多いから、
(というよりはその上流のデザイナのせいか?
もっとも、上流にデザイナが居る時点で間違いだというのが俺の見解だが)
CSSもグチャグチャになってたりする。
CSSも本来は、
.構造クラス {}
.構造クラス.デザインクラス {}
の2種類だけで構成されるべきなんだよ。(基本的には)
> CSSの定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。
ああ、これは違う。これをやるには大量にクラスを定義しまくる必要があるだろ。
実際、何個くらいまで実用に耐えられるのかは興味はあるにしても、
他にそんなコードを見たことがないので、採用はしないね。 >>428
というか、俺はオレオレ流の先進性がある(キリッな方法を宣伝しているのではなく、
割とみんなやってる方法を言ってるだけだから、新しい手法か?という期待をされても無理だ。
そんなもん知ってるわ!でしか無いと思う。 DOMを縦横無尽に弄ろうとするから複雑になる
機能が小さく閉じたコンポーネントを組み合わせて設計すればいいだけ
直接CSSを弄ろうなど、愚の骨頂 >>431
それな。jQueryの使い方として、まずトップのクラスを一つ作る
正確には最初にCSSの設計を行って、CSSの構造でコンポーネントを定義する
この時sassを使うとネストができるのでHTMLの構造をCSSで定義しやすい
そしてjQueryはそのコンポーネントに対して処理を記述する
CSSで構造を作って、その構造通りにHTMLを書く
そしてCSSでは不可能なことが出てくればJavaScript(jQuery)の出番ってわけ
jQueryはCSSと相性がいい >>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 DOM APIの問題をあげたようだが、
それがjQueryによって解決されてるのを見ると、
やっぱりjQuery使ったほうが良いなってなるよなw >>432
それはjQueryの使い方でも使われ方でもないな
jQueryに限らないけど君みたいな大好きマンが語ることって、
もちろんそれは君の好きにしたら良いし否定はしないけど、やっぱり例外的なんだよ
コンポーネントで組むならそれ専用のライブラリを使うほうが絶対にいいし
一部に使うにしろShadowDOM然り相性が良いとは消して言えない
気軽で便利さが取り柄のjQueryのようなライブラリで、
考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
jQueryは正に比較的小規模なサイトでパッチを当てるような勢いで
縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ > 気軽で便利さが取り柄のjQueryのようなライブラリで、
> 考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
はっはっは。
つまりお前は、jQueryは気軽に使うもんだ。気軽に使うから問題出るやろ
って言ってるわけか。
全てお前の使い方が悪いんじゃないか
見ての通り、お前が上げたDOM APIの問題がすべてjQueryで解決していることを示した。
>>425で(DOM APIの場合は)
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、
〜略〜
> 結果、イベント起動部分のコードは全書き換えに近くなる。
といっているが、jQueryならたったこれだけだ。
> $('.foo').on('click', ・・・) とあったら
> $(document).on('click', '.foo', ・・・) と書き換えるだけ
イベントハンドラのコードは全く変更がいらない イベントハンドラのコードは全く変更がいらないと書いたが、
実はDOM APIのイベントハンドラの中身を
jQueryでほぼそのまま使えるってことも重要な所だな
DOM APIからjQueryへの移植が楽になっている
$(document).on('click', '.foo', function(event) {
ここで扱う、thisはDOM APIの場合と同じく、イベントが発生した要素だし、
eventもDOM APIと互換性のあるeventオブジェクトになっている
これは各イベントを親で受け取る場合だが、個別の要素で受け取る場合と全く同じ書き方で良い
}) 結局さ、CSSベースでJavaScriptを素敵な使い方をしようと思えば
DOM APIを使うよりも、jQueryを使うのが良いってことなんだよなー どこまで行っても所詮jsのライブラリだからな。jsでできる以上のことはできない。
jsで書いてループが必要なところは、ライブラリが内部で行っているだけ。
てかもしかして他の言語のライブラリの仕組みと勘違いしてるのかもしれんが、jsのライブラリって単なる他人の書いたコードだからなw
「jQuery設計した人はなぁ!すごいんだぞ!頭いいんだぞ!だから俺にひれ伏せ(?)」と主張しているにすぎない。
なぜか御主人様の自慢を始めてしまう奴隷のようだwwマヌケwwww > どこまで行っても所詮jsのライブラリだからな。jsでできる以上のことはできない。
それはJavaScriptでできることの限界までできるってことじゃね? >>439
> 「jQuery設計した人はなぁ!すごいんだぞ!頭いいんだぞ!だから俺にひれ伏せ(?)」と主張しているにすぎない。
いや、人の自慢はしてないぞw
(褒められたことではないが)jQueryの作者の名前知らないw
純粋にjQueryというライブラリ、その設計が素晴らしいと言ってるだけ
DOM APIの様々な問題(を都合よく語ってくれたのでw)それを解決している >>437その他
それは素のJavaScriptで出来ることをjQueryでやっただけで、
jQueryを使う意味が全くないだろ。
楽にもなってないし、無駄ラップしてる分遅くなってるし、jQueryに無駄に依存してる。
メリットが何もない。
当然、この状況でjQueryを使う馬鹿なんて居ない。
ただ、お前はjQueryの典型的な使い方>>409をしてるんだろ?
じゃあ437その他の書き方じゃねえだろ。
というか、お前は考え方が逆なんだよ。
409の書き方がjQuery使いに典型的な理由は、jQueryの恩恵を受けられるからなんだよ。
そしてCSSベースでがっちり組んでる奴にはjQueryのメリットなんて全くないから、
彼等はjQueryもフレームワークも大嫌いなわけでさ。
だから
> Queryは正に比較的小規模なサイトでパッチを当てるような勢いで
> 縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ (>>435)
これが正鵠を射てる。
小規模のサイトで技術力が比較的ない場合、
HTMLベース+jQueryで運用するのは極めて現実的な判断だ。だから広まった。
俺は歴史はあまり知らないが、どうやらCSSはかなり初期からあったのに、
「CSSでスタイルしようぜ」なんて言いだしたのは最初からでもないだろ。(特に国内のサイトは酷かった)
そして、みんな学んできて、『技術力が比較的ない』状態を脱しつつあるから、
今脱jQueryの動きがある、ってだけでさ。
特に不思議でもなんでもないだろ。
むしろお前が無理に居残ろうとする意味が分からない。 >>442
> それは素のJavaScriptで出来ることをjQueryでやっただけで、
> jQueryを使う意味が全くないだろ。
バカなのかな?
>>425で自分で
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
とか問題があると言いながら、
jQueryで解決すると、意味がないといいはる。
発言に矛盾が生じてますねw >>443
お前はマジで日本語をもう少しちゃんとやるか、半島に帰れ。
俺は、
> 問題がある
なんて言ってない。
というか、お前が必死だったのはここを読み間違えたからか。 > 俺は歴史はあまり知らないが、どうやら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 >>444
ほー、ってことは
jQueryを使わないと
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
が問題はない と、そういったわけですか?
でも、jQueryを使うとがらりと変わることは無いってことには
異論はないわけですよね? > そしてCSSベースでがっちり組んでる奴にはjQueryのメリットなんて全くないから、
> 彼等はjQueryもフレームワークも大嫌いなわけでさ。
どこの話をしてるだろう?
現実には彼らはjQueryを使っていますが? ウェブの7割以上。JavaScriptを使ってるサイトの97%以上。
それはjQueryにメリットがある何よりの証拠じゃないんですかねw >>425
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。
それは問題はなにもないってことじゃないんですか?www >>445
> なにか言うたびに墓穴をほってるんだから、もう止めたら?w
お前がな。
https://mayonez.jp/topic/1758
使えなかった当初はさておき、海外のCSS対応に比べて国内はものすごく遅れた。
これをお前は知らないのか?
だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする? >>449
そのリンクを持ち出してきて、お前が何を言いたいのかが
まーた書かれてないんだがw
> だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする?
なろうとしてないよ?お前がなろうとしてるはずだって思いこんでるだけ
俺は今までずっとjQueryの技術について話をしているのに、
お前は、俺のことばっかりだよなw
jQueryそのものに対しては、遅れてるだとか誰も使ってないだとか
そんな根拠のないことしか言ってない
一つぐらいお前が>>425で書いた問題(問題じゃなかったことにしたんでしたっけ?w)
についてjQueryが解決していることにコメントでもしたら?
解決してないことを探し出すんじゃなくて
jQueryが "解決していること" を無視せずにコメントしろ言ってる >>446
> 異論はないわけですよね?
あるぞ。というかお前自身が書き換えてるだろ。
>>448
実際は最初からそう書くから、書き換えなんてしない。
両対応なんてする意味はないし。
だから、HTMLベースで行くのか、CSSベースで行くのかは、最初に決めるし、それで確定する。
そして、今時HTMLベースを選ぶのは技術力がない連中だけだ。
そのHTMLベースにjQueryは極めてフィットし、CSSベースにおいては無用の長物だから、結果的に、
jQuery使い≒HTMLベース≒技術力がない
が成立するから、馬鹿にされる要因にもなり得るし、実際、今そういう感じだろ。
もっとも、イベントエントリ部分は書き換えるにしても大した話ではない。
だから、正しいクラスの使い方をしていれば、移行するのは面倒だが難しい話ではない。
やればいいだけの話だ。
というか、お前は本当に色々知らないから話が通じてない。
もうここら辺でいいかな?どうしてもjQueryを否定されたくないんだろ?
俺はjQueryは役割を終えたという見方だし、お前の屁理屈をいくら聞いても全く変わらない。
このスレの他の連中も、割と公平な見方してると思うぜ。 >>450
> jQueryが "解決していること" を無視せずにコメントしろ言ってる
>>451参照してくれ。
そもそも問題がないのに、何を解決したつもりなんだ?
マジで日本語どうにかしろ >>452
何を解決したかって
各イベントを親で受けて、e.target.classList.contains を使って分離して動作させて
共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ないず
だから個別データはノードから動的に取得する必要があり、
単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
というコードを最初から書くんでしょう?
最初から多少煩雑になるコードを書いてるわけですよね? 実際に書いてみたら良いんじゃないですか?
その煩雑になるコードってやらを >>451
> 俺はjQueryは役割を終えたという見方だし、お前の屁理屈をいくら聞いても全く変わらない。
たしか俺が、>>338で結論出るまで、あとどれくらいか聞いた時
たしか10年って答えなかったっけ?w
そうだね。結論が出るまで10年後ってレスしてるね >>456
後で書き換えるかもしれないから、あとで書き換えなくて良いように、
必要ないかもしれないのに、煩雑になるコードを最初から書いているってさ
YAGNIな俺とは正反対だねw >>457
日本語でおk
つかマジでそんなこと言ってないだろ。
もう、空回りしてる部分についてはこちらからはフォローしない。キリがないし、意味もないから。
内容を把握出来るまで何度でも読み返し、整理してから回答しろ。 > つかマジでそんなこと言ってないだろ。
引用しかしてませんが?もう一回引用したら良い?
>>425より
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。
>>451より
> 実際は最初からそう書くから、書き換えなんてしない。
全書き換えに近くなるから、書き換えしなくてすむように
最初から>>425のように書くんでしょう? フレームワークがよくわからないのですが
node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
jQuery だけは DOM をいじるときと $.ajax ぐらいは使えるんですが
jQuery みたいな便利なライブラリ群って認識でいいんでしょうか >>463
公式を読むのが一番早いし誤解がない。
公式を読めない/読む気もないのならプログラマには向いてないから辞めた方がいい。
公式を読んで色々ググった上で疑問点があるときのみここに書き込め。 >>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というフレームワークを入れるというのはどういうことなのかというと、 (>>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オブジェクトを導入するものなのでライブラリ >>463
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか
直接的にこの質問に答えると、所詮JavaScriptのライブラリでしか無いので
JavaScriptでできる以上のことは出来ない。
何ができるようになるかじゃなく、作り方が変わる。
vue.js react.jsは作りやすくなると自称しているが、ウェブサイトには適していない
ウェブアプリとして作りやすいようになっているフレームワーク 訂正
> 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 >さらにこれらのフレームワークはSPA(single page application)が基本となってるから、
>複数ページに見えても1ページ。なので特定のページだけ使うとかじゃなくて
>サイト全体とか特定のパス以下は全てフレームワークで管理することになる。
細かいこと言うと、1ページでしかないから(React等を使っていない)他のページと
組み合わせて使うことは十分可能なんだよな。 >>469
可能か不可能かじゃなくて難しいって話をしている
例えば既存でサイトが既にあったとして
URLを変えずに1ページずつ移行していきましょうとか大変 prototype.jsからjQueryへの移行のときとか、
1ページ内に、prototype.jsとjQueryを両方読み込んで、
HTML(とCSS)はそのままに1関数ずつ移行とかできたしね なんでいきなり移行する話になるんだか。
共存自体は別に難しくないよ。非SPAで複数ページ連携するのと変わらん。 463です
たくさんリプありがとうございます
まだいまいちわかってないけど
React Vue は複数ページに見えるページセットみたいなのをJSでかけて
クライアントはリンクふんだときにページ遷移にみえるように画面いれかえてくれるものってことなのかな
だからそのページセットがネイティブアプリでうごくってことなのかな
node.js は javascript で CGI サーバーサイドの物を作れるってことかな
llisten accept とかをJSでできるようになるのかな
JSで標準入出力をかくだけでCGIとして動くものなのかな >>462
1ページの中にvue.jsとreact.jsを共存させるサンプル教えて
もちろんフレーム使わずに >>473
まあjQuery廚がするjQueryの話だけは鵜呑みにするなよ。
既に何度も言ったとおり、CSSベースで組んだ場合にjQueryを使うメリットは何もない。
だから、CSSベースでいける、と判断したところが脱jQueryしていってる。
そしてjQuery廚はCSSベースの意味を理解出来てないし、誤用している。
なお、話を戻すと、その手のフレームワークについては、
こういった解説を求めたり、或いはググったらQuitaとかに色々でてくるはずだが、
なんだかんだで間違いが多いから公式を読んだ方がいい。
そして、公式を読んでも意味が分からないのなら、それは君が今使うべき物ではない、ということ。
結局、ここで聞いて、俺達が何か言ったところで、君には間違いが見抜けないだろ。
なら、君自身が間違いを見抜けるようになるか、間違いがあった場合に誰かが訂正してくれる場所でないと、
質問する意味がないだろ。間違いを掴まされる可能性も普通にあるわけでさ。
そして、間違いが一番少ない場所は公式、ってことだ。通常、間違ってればすぐに訂正されるから。
最近の公式はどれもこれも布教用ページを持っているから、そこを読むのが一番いい。
そして、当然それは使用者のレベルも想定した上で書かれているから、
そこを読んで分からないのならお呼びではないって事で諦めた方がいい。つまり、
公式を読め、無理なら諦めろ、なんだが。 >>473
> React Vue は複数ページに見えるページセットみたいなのをJSでかけて
> クライアントはリンクふんだときにページ遷移にみえるように画面いれかえてくれるものってことなのかな
それはどちらかといえばオマケ機能。たまたま(デフォルトで)そうやってるってだけで
そうやる必要もないし、フレームワークの話とは関係ない
> だからそのページセットがネイティブアプリでうごくってことなのかな
この話とネイティブアプリで動くのとは直接の関係はない
まあ設計はしやすいんだろうけど
> node.js は javascript で CGI サーバーサイドの物を作れるってことかな
それはあっている。CGIにすることもできるが、通常はnode.jsで
動くサーバーサイドフレームワークを使う
> llisten accept とかをJSでできるようになるのかな
できる
> JSで標準入出力をかくだけでCGIとして動くものなのかな
node.jsの使い方としてはあまり一般的ではないが
標準入出力の機能もあるのでCGIとしても使える >>475
ちがうんですか?
基本ホームページ制作で
ウェブサーバー上に HTMl CSS JS のテキストファイルをおいて動かしたことしかないので
本気でわかってないです
ただウェブ制作だけだとこの先厳しいってきくので
サーバーサイドよりのフロントエンドに手出したいなと思ってて
募集案件で Vue React Node とか使えることみたいな募集けっこうみかけるので
ぢどういうものなのかなときいてみた次第です >>476
お前が言っていることを3行でまとめてやろう
・jQueryは嫌いだ
・ここで質問するな、公式を見ろ。
・俺は参考になる話は何もしない SPAと非SPAの共存の話をしているのになんで1ページの中に共存する話になるんだかw >>477
Node はどちらかというと他のホスティングサーバーで動くものというよりは
サーバープログラム自体をJSで作るためのものなんですね
npmっていうインストーラーを使うためのライブラリか何かだとおもってました…
VueとReactはまだよくわかってないので公式よんでみます
丁寧にありがとうございました >>480
身も蓋もないが、実際、「公式を読め」がベストアンサーだろ。
日本語も論理も怪しい奴が一生懸命説明してくれたところで信じ切れないし、
ここで俺らがグダグダ説明するより数段ましな説明が公式にある。
○○ってなんですか系は、
・誤解をピンポイントで訂正していく
位しかここの使い道はないんだよ。
それで、ライブラリに無理に振ったようだから「釣りですか」なんて言われるわけでさ。 「公式を読め」じゃ解答になっていない
公式のこういうところをこういうように読んで、
補足してこういう情報も見るとこの状況・段階では捗るよと教えてあげないと
ただ単に答えるの面倒くさいからって投げてるだけじゃん きちんと公式が整備されてるのは幸せだよね
と最近実感した >>484-485
ならお前らがまず「ぼくがほしかったかいとうれい」を出して言え。
この点、jQuery厨はやってるだけましだし、やったからこそ文句を言う権利はあるが、
お前らやってないのに文句を言ってるだろ。
それがゆとりが駄目なところだ。
そして、お前らが一生懸命説明したとしても、公式を越えるのは容易ではない。
公式は、スキルがあり、お前ら以上に詳しい奴が、時間をかけて、しかも複数人数で書いてる。
沢山の人の目にも触れ、間違いや分かりにくい表現は修正されてる。
これらの意味が分からないのは、お前らが馬鹿だからだよ。
マジで、今後、公式も読めない奴はプログラマやっていけないよ。
公式も読んでない段階でここで質問するような馬鹿も、プログラマ辞めた方がいいと思うぜ。
それって、わざわざ誤解したがっているようなものだからな。 > これらの意味が分からないのは、お前らが馬鹿だからだよ。
英語だからでしょ? 約二名が批判しあっているが、身のある結論には行き着かない まあ、何を言おうが現実はこれってことだよ。
終わったと言い始めて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年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか?この先の動向が注目される >>481
> SPAと非SPAの共存の話をしているのになんで1ページの中に共存する話になるんだかw
だってWordPressがjQueryを使ってる所に、
ReactやAngularで作られたプラグインのせるとか、
逆に将来WordPressがReactやAngularに乗り換えたとして、
jQueryで作られたプラグインのせるとか、共存できないと
移行なんて無理でしょ?全部いっぺんに変えられるわけがないんだから
フレームワークはサイト全体をそのフレームワークで構成するならいいが
パーツ単位で別のフレームワークで作られたもの混在や再利用がしづらいんだよ
そこで、ブラウザ標準のフレームワークとDOM APIを改良した
ライブラリであるjQueryが一番再利用性が高いということになる。 別ページなんだから「全部いっぺんに」変える必要もないんだが、どうしてもそこが理解できないようだな。
SPAは別にReact難かに限らずjQuery使って作ることだってできるわけだが、あるページでjQueryを
使ったからといって他のページも全部jQuery使わなきゃならないわけじゃないと説明すればjQuery脳にも
理解できるかねぇ。 >>493
それ何度も言ってるが、お前意図的に間違えてるだろ。
或いは、実はお前は英語が読めなくて、マジで勘違いしてるのか? >>496
じゃあ、お前が本当はどうなのかを書くべきでは?
「お前は間違ってるー」「お前は間違ってるー」って
叫んでも、説得力無いんやで? >>495
だからすでにあるWordPressの一部に何かのフレームワークで作ったものを混ぜたり
あるフレームワーク作ったものを、他のフレームワークで使ったりするってことだよ
コンポーネントっていうのは、そうやって他の人が作ったものを使うってこと。
混ぜて使えないなら、そのフレームワークで全てを構成しなきゃならない
ってか、混ぜて使えないから、そうやって言い訳してるわけなんだろうけどねw いちゃもんおじさんが来ないので、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を直接変更するなとか変な制限があるフレームークを使っていなければ、今すぐ導入が可能 全部nanoやumbrellaで出来るな。
jQueryより軽いし。
所詮ライブラリだからおんなじことできるのにデブ使う必要もない。
どれでも好きな娘選んでエッチしていいよって言われたら一番かわいい娘選ぶだろ?
そういうこと。 >>500
> 全部nanoやumbrellaで出来るな。
みたいね。ここに書いて なんだnanoもumbrellaもjQueryライクなライブラリか
設計思想が同じならjQueryの代替にならないわけじゃないな
ただクローンはオリジナルを超えられないものだけど >>497
>>103
同じ事を俺だけでも何回も指摘済みだが。
>>499
間違いを垂れ流すのは止めろ。
お前自身が馬鹿なのが初心者にも分かるだろうから、お前では布教は無理だよ。
というか、何故お前は頑なに学習を拒む?
他の『快適な』サイトがどういう作りになってるか見ればすぐに分かるはずなのだが。
そもそもjQueryを使っただけで、「遅くなり、jQueryに依存する」というデメリットが付いてくる。
『今も』それを越えるメリットがあると思えば使えばいいし、
それは看過出来ないと思う奴らはjQueryを既に捨ててる。それだけの話だ。
jQueryの最大のメリットは、お前みたいな馬鹿でも、どんなグダグダなHTMLでも、何とかなってしまうことだ。
だから(今のお前もやっているように)HTMLベースで組むのは最初は悪いことではないし、妥当だ。
しかし、他の連中は色々学んで、それ以上の道を模索してる。
それがフレームワークであったり、脱jQueryであったり、素で書け、みたいなことだったりする。
フレームワークの使い方を覚えても「プログミングの本質的な腕前」には関係ないが、
各フレームワークがどこに問題を見いだし、どう解決しようとしたかを見ることは、
「プログミングの本質的な腕前」の上達に繋がる。
フレームワークを模索している連中は、その過程で、どんどん前に進んでいく。
お前はjQueryにこだわって、置き去りにされてるだけだ。(というよりそれをお前自身が望んでいる)
他の人とお前が話が通じてないのはそのためだ。君が分かってなさすぎる。
ただそれ以前に、君は日本語が怪しいから、そこをまず詰めた方がいいが。 >>498
最初はReactとかSPAの話だったんでその話しかしてないんだが、なんでWordPressとか持ち出すかね。
意図的に話をずらそうとしているのか「フレームワーク」で似たようなものだと区別ついてないのか。
「混ぜる」のミスリードも相変わらずだね。1ページ内で混在する話なんかしてないっつーの。 >>499
というか、お前は初心者の発想から抜け出せていない。
話が通じないのは、これが原因かもしれん。
本来は、ライブラリ/フレームワークは「きちんと選んで使うもの」だ。
基準は彼等がよく言う、「どうせ同じようなコードを書くことになる」が分かりやすくていい。
だから本来は、「それがなかったら同じようなコードを書く奴だけが使え」というのも正しくて、偶にこれを言ってる奴もいるだろ。
現実はそうも行かず、全く意味分からない初心者も含めて使え、ということになっているが。
実際、「どうせ同じようなコードを書くことになる」は事実だ。
大規模化したコードの生産性を上げる為には、何らかのプチライブラリ/フレームワークが内部的に必要になる。
(敢えてそれをしない、というスタイルの奴も偶にいるが)
SPA向けのフレームワークは、SPAで典型的に必要になる制御に対し、枠組みを提供するものだ。
当然、無ければ無いで書けるが、彼等の指摘通り、「どうせ同じようなコードを書くことになる」。
なら、ジャストフィットする物があれば、使った方が楽だ。
jQueryも同じで、「どうせ同じようなコードを書くことになる」のなら、使うのは正しい。
つまり、ブラウザの差異を吸収する為に、或いはCSSセレクタを使う為に、jQueryと同じようなコードがどうせ必要な場合だ。
ところが、これらは環境の整備がすすみ、なくなってしまった。
なら、もう要らなくね?というのも自然な発想だ。
彼等は原点を忘れてなかったんだよ。
君にはライブラリを選定する立場になったことがなく、
「○○は使うもの。だって○○さんが決めたから」という感覚しかないから話が通じない。
そして、自分がそうであるから、頭ごなしに「jQueryを使え」と布教しているわけだが、
本来は、どのライブラリ/フレームワークを使うかは、
各自が、「どうせ同じようなコードを書くことになる」かどうかで判断することなんだよ。
そして、jQueryには、もう、「どうせ同じようなコードを書くことになる」理由がなくなってしまっている。
だから脱jQueryも自然な流れであってさ。あれは、意識高い系が、って話ではないんだよ。 ■ >>503 全行解説 (1/2)
> 同じ事を俺だけでも何回も指摘済みだが。
それがどれかを書かない
> 間違いを垂れ流すのは止めろ。
どれが間違いなのか言わない
> お前自身が馬鹿なのが初心者にも分かるだろうからお前では布教は無理だよ。
初心者でもわかるってことにしたい。無理と思い込みたい
> というか、何故お前は頑なに学習を拒む?
拒んでいない
> 他の『快適な』サイトがどういう作りになってるか見ればすぐに分かるはずなのだが。
快適なサイトがどれか書かない。見ればすぐに分かるってことにしたい
> そもそもjQueryを使っただけで、「遅くなり、jQueryに依存する」というデメリットが付いてくる。
速度は速ければ速いほど良いと思っている。問題があるそうかどうかという観点が抜けている。
依存するのは他のフレームワークの方がもっとひどい
> 『今も』それを越えるメリットがあると思えば使えばいいし、
だから3年たった今もみんな使っている
> それは看過出来ないと思う奴らはjQueryを既に捨ててる。それだけの話だ。
データには現れていない。むしろReactを捨ててる方が多かった。
> jQueryの最大のメリットは、お前みたいな馬鹿でも、どんなグダグダなHTMLでも、何とかなってしまうことだ。
どれをを使っても同じ。jQueryの技術から、利用者の能力へと話のすり替え
> だから(今のお前もやっているように)HTMLベースで組むのは最初は悪いことではないし、妥当だ。
最初と明言することで、それは最初だけなんだと思わせようとしている(実際にはプロはjQueryを使ってる。CSSベースで) ■ >>503 全行解説 (2/2)
> しかし、他の連中は色々学んで、それ以上の道を模索してる。
その他の連中が誰かを言わない。模索した結果がjQueryの利用者数に影響はなし
> それがフレームワークであったり、脱jQueryであったり、素で書け、みたいなことだったりする。
やっぱりjQueryでいいよねもその一つ
> フレームワークの使い方を覚えても「プログミングの本質的な腕前」には関係ないが、
> 各フレームワークがどこに問題を見いだし、どう解決しようとしたかを見ることは、
> 「プログミングの本質的な腕前」の上達に繋がる。
それと実際に使うかどうかは別の話
> フレームワークを模索している連中は、その過程で、どんどん前に進んでいく。
その結果が、Angular1からAngular2への作り直し、React止めたFacebook、Airbnb等。3歩進んで2歩下がる。
> お前はjQueryにこだわって、置き去りにされてるだけだ。(というよりそれをお前自身が望んでいる)
将来性不明ですぐ消える技術に振り回される連中を見て思う、Backboneに手を出さなくてよかった。Reactもかな?
> 他の人とお前が話が通じてないのはそのためだ。君が分かってなさすぎる。
どこがわかってないかの指摘がない。そういうことにしたいという希望
> ただそれ以前に、君は日本語が怪しいから、そこをまず詰めた方がいいが。
同上
まとめ
・新しいもの、新しいもの、と言ういうだけで成果がない
・技術に対して客観的な意見を言わない(速ければ良いわけじゃないってわかってるだろうにw)
・俺への指摘は、どれも根拠がない。(単なる個人攻撃) ■ >>499 全行解説 (1/3)
> というか、お前は初心者の発想から抜け出せていない。
どこがという指摘がまた書いていない
> 話が通じないのは、これが原因かもしれん。
そういうことにしたいという希望
> 本来は、ライブラリ/フレームワークは「きちんと選んで使うもの」だ。
その結果jQueryになっただけの話
> 基準は彼等がよく言う、「どうせ同じようなコードを書くことになる」が分かりやすくていい。
「どうせ同じようなコードを(また別のフレームワークで)書くことになる」
> だから本来は、「それがなかったら同じようなコードを書く奴だけが使え」というのも正しくて、偶にこれを言ってる奴もいるだろ。
一体何の話を始めたのか?
> 現実はそうも行かず、全く意味分からない初心者も含めて使え、ということになっているが。
なっていることにしたいという願望
> 実際、「どうせ同じようなコードを書くことになる」は事実だ。
実際に書いてある。Backboneで書いてたら死んだ。Angular1で書いてたら、全く違うAngular2がでてきて作り直し
> 大規模化したコードの生産性を上げる為には、何らかのプチライブラリ/フレームワークが内部的に必要になる。
jQueryでいいじゃん。
> (敢えてそれをしない、というスタイルの奴も偶にいるが)
だからなんなんだろう?
> SPA向けのフレームワークは、SPAで典型的に必要になる制御に対し、枠組みを提供するものだ。
> 当然、無ければ無いで書けるが、彼等の指摘通り、「どうせ同じようなコードを書くことになる」。
また開発工数という概念が抜けてるのかな?時間が無限にあれば、誰でもなくてかける。 ■ >>499 全行解説 (2/3)
> なら、ジャストフィットする物があれば、使った方が楽だ。
大部分のウェブサイトにはSPA向けのフレームワークはフィットしない。ジャストフィットするjQueryを使ったほうが楽だ
> jQueryも同じで、「どうせ同じようなコードを書くことになる」のなら、使うのは正しい。
10年前のコードが今も同じように動く
> つまり、ブラウザの差異を吸収する為に、或いはCSSセレクタを使う為に、jQueryと同じようなコードがどうせ必要な場合だ。
ブラウザの差異を吸収する時代は終わってる。今は純粋なDOM操作ライブラリだ
> ところが、これらは環境の整備がすすみ、なくなってしまった。
> なら、もう要らなくね?というのも自然な発想だ。
「 当然、無ければ無いで書けるが、」といったのは誰だったか。確か開発工数という概念が抜けてる人だったか
> 彼等は原点を忘れてなかったんだよ。
原点はDOM。それを便利に操作するライブラリ
> 君にはライブラリを選定する立場になったことがなく、
・俺への指摘は、どれも根拠がない。
> 「○○は使うもの。だって○○さんが決めたから」という感覚しかないから話が通じない。
・俺への指摘は、どれも根拠がない。
> そして、自分がそうであるから、頭ごなしに「jQueryを使え」と布教しているわけだが、
>>499で動くコードも書いている。お前はなにか書いたか?「頭ごなしにjQueryを使うな」だろ
> 本来は、どのライブラリ/フレームワークを使うかは、
> 各自が、「どうせ同じようなコードを書くことになる」かどうかで判断することなんだよ。
許容範囲のデメリット中で、どれだけ楽になるかだろ ■ >>499 全行解説 (3/3)
> そして、jQueryには、もう、「どうせ同じようなコードを書くことになる」理由がなくなってしまっている。
大規模化してて書くことがたくさんあるんでしょ?その書いてる「同じようなコードを簡潔に書ける」のが理由なんだけど?
もう何も書かないで動くって話?CSSでできるならそりゃCSSでやるけど?
> だから脱jQueryも自然な流れであってさ。あれは、意識高い系が、って話ではないんだよ。
わざわざ言うのは、意識高い系がって思ってる証拠だな これは「反論」ではなく「解説」であることに注意なw
みんなも解説を見ながら、やつが言ってることを聞きましょう。 別にjQuery信者がどう考えてどう主張してどう使おうがどうでもいいじゃん
今あるものを大切に使って最低限の努力で目的を達成しようとするのも良いことだし 高い品質を求め続けて死んでいった日本の製造業みたいな考え方 >>507-512
お前にはそう読めるのだろうが、普通の人ならそうは読めない。
例えば、
> > 同じ事を俺だけでも何回も指摘済みだが。
> それがどれかを書かない
直前の行に書いてるだろ。再掲すると、
> >>497
> >>103
> 同じ事を俺だけでも何回も指摘済みだが。
103に決まってるだろ。
いまいちお前の頭がどういう風に障害持ちなのか分からないが、
どうやら君は非常に断片的にしか読めなくて、
これまでは2行単位でしか読んでなかったが、今はもう1行単位でしか読めなくなってる。
そして直前の行すら無視するのだから、話が通じるはずがない。
それでは一般の文章、例えば公式の紹介文も読めないと思うが。
ただお前のタイプ、リアルで遭遇するのは(俺には)ないが、ここ(2ch)で遭遇するのは3人目だ。
(お前が前から居るのは認識していたが)
何か2chにそういうのを集める理由があるのだろう。
もう少し軽度な奴、4レス前までしか追えない奴もJavaScriptスレの周りにいる。
ただこいつは4『レス』だから『忘れっぽい奴』位で対応出来るが、
さすがに直前の行も読めないようでは話は無理だ。空回りしすぎる。 >>513
多分、俺達が古いものをいつまでも使っていたらウェブが発展しない!
俺たちがウェブを変えていくんだ!とかいう謎の使命感(笑)に燃えてるんだと思うw
新しいものと速いことに執着しているのがその証
こっちは適切なタイミングで適切な道具を使うだけなのにね。 >>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%↑
矢印は前年から上がってるか下がってるか こうやって見ると、おめでとう。ようやく今年、JavaScriptライブラリ未使用の
ウェブサイトが少しだけ増えた。だがjQueryを使用してるサイトも同じだけ増えたw
って感じだなw
>>520にはJavaScriptを使ってないサイトはデータとして出てきてないね
HTMLとCSSだけのページも相当数あるだろうにそのデータはないのかな?
それがないとJavaScriptライブラリを使わないで、
JavaScriptを使ってるサイトの割合はわからないね 訂正
× まとめると、ウェブサイトでJavaScript言語を使用しているのは95%で
○ まとめると、ウェブサイトでクライアントサイド言語を使用しているサイトのうちJavaScriptを使用しているのは95%で ライブラリ未使用とかこだわりポイントが意味不明
ESでもスタンダードライブラリの仕様策定と実装が進んでるじゃん
エクステンシブルWebの精神で行くと小さなライブラリたくさん組み合わせるのがセオリーだし
そういう点でjQueryって組み合わせづらくて古臭いねって言うのだけは分かる > そういう点でjQueryって組み合わせづらくて古臭いねって言うのだけは分かる
ふーん、どんな所がか言える?
言えないでしょう? >>520
相変わらず意図的に間違えてるよな。
いや実は素で間違えているのかもしれんが、多すぎて意図的だと読めるんだよ、普通の人には。
まあもういいが。
>>523
> ライブラリ未使用とかこだわりポイントが意味不明
彼等はそこにこだわっているわけではないと思うが。
結局この話題はひたすらに水掛け論だな。
本来は、「なければないでも出来るが、面倒だからjQueryを使う」というスタンスが正しいのだが、
jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。
ま、結果は待つしかないし、待てばいいだけだが。
「jQuery、いつ止めるの?今でしょ!」な人が今止めてるだけ。
GitHubも公式声明出しているが、当然だがプログラマ目線だ。
https://githubengineering.com/removing-jquery-from-github-frontend/
実際の所、1回作って終わりのWebページならほぼどうでもいいのも事実だし、
彼等が脱jQueryするかはまた別の問題だ。
ただ俺は、デザイナが無理してJavaScriptをいじること自体が間違いだと思っていて、
今のところ静的HPフレームワークに吸収されるのではないか、と見ている。
WordPress等も普通なら吸収する方向に動いているはずだが、そうでもないのか? >>525
> 相変わらず意図的に間違えてるよな。
いつもどおりですが、どこをどう間違えているかを言わない。
> jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。
誰もそんな事は言ってない。いつもの思い込み。お前の願望。
話が進まないのは、お前が答えるべきことに何一つ答えないからやで
毎回毎回。答えない。言わないと。俺が教えてやってると言うのにw
> ま、結果は待つしかないし、待てばいいだけだが。
もう3年待った
> 「jQuery、いつ止めるの?今でしょ!」な人が今止めてるだけ。
あ、止めたんだw 飽きたんだね。ネガティブキャンペーンに
> GitHubも公式声明出しているが、当然だがプログラマ目線だ。
見るのはそこじゃない。本来書いてあるべきことのの
「やめてどういうメリットがあったかが書かれてない」ってのが重要
あれ読んでも「あ、やめたんすね。GitHubレベルの技術者でも
大変で時間がかかったんですね。メリットは?」って思うだけ >>526
> ねえ、これいつまで続くの?
jQueryの使用率が今より10%さがるか、Bootstrap、Modernizer、Underscoreを除く
他のUI関連のフレームワーク・ライブラリの使用率が10%を超えたらかな
(なぜこの3つを除くかというと、Bootstrapは本来CSSフレームワークで
JavaScript部分にはjQueryを使っているから。Modernizerはブラウザが搭載している
機能判定をする補処的なライブラリでそれ自体で何かをするものじゃないから。
Underscoreは古いブラウザでも使える関数型風のライブラリでUIとは関係ない。
そして俺のお気に入りの一つだからw)
あいつがやめなくても俺がやめてあげよう。
だからすぐだよ!(皮肉w) https://github.com/twbs/bootstrap/issues/23204
によるとjQuery外すつもりだが人手が足りなくて無理らしい。Please help!とか言ってるわw >>524
全てだよ
jQueryって簡単に言うとライブラリと言うよりフレームワークだから
まずjQueryオブジェクトにラップする時点で
どう考えても他のDOM操作系のライブラリと相互親和性低いじゃん
jQueryはjQueryの世界で閉じちゃってるのは紛れもない事実
だからJSかjQueryかみたいな比較もしばしばされるでしょ?
それが良いとこでもあり悪いとこでもあるけど、
先にも述べたように某マニフェスト的な精神で見ると古臭い > jQueryって簡単に言うとライブラリと言うよりフレームワークだから
jQuery: The Write Less, Do More, JavaScript Library.
https://jquery.com jqueryはdesignerが触れるという意味において、流行ってるな。 >>532
自身がどう名乗ってるかはどうでもいい
そういう話はしていないから
ここでは
問題解決のための汎用性が高い機能を集めたもの:ライブラリ
問題解決のための枠組みを提供するもの:フレームワーク
という専ら粒度的な意味で使ってることは君も分かりきってるのに
全く無駄でしか無いレスを返すのは控えてくれ
一度警告したから、次からは取合ないよ >>527
君との話が進まないのは、君が毎回誤解/曲解して、その修正に1レス以上必要だからだ。
だからまじめにいちいち修正してたらいつまで経っても進めないし、
ならばと誤解を無視して強引に進めたら周りが混乱したようだし、これも不味かった。
GitHubが何を言ってるのか分からないのは、君がプログラマではないからだ。
(ただ、君はデザイナなのだから、分からなくてもいい)
プログラマなら、ああ、なるほどね、と理解は出来る。共感するかはまた別だが。
とはいえ、イノベーター連中が騒いでいたのとは違い、GitHubはおそらくアーリーアダプターに位置する。
この彼等が動いた、というのは大きいんだよ。
まあとにかく、君の言い分は分かった。
いずれにしても水掛け論だし、俺はここら辺でももういい。
プログラマにとっては、jQueryの問題点は色々あって、それはもう共通認識だ。
だからこそ、いつ脱jQueryするか、という話になる。
勿論、ずっとしない、というのも一つの選択だ。ただ、これもまた、非常に勇気の要る選択ではあるんだよ。
だからみんな顔色をうかがっているわけでさ。
君みたいなデザイナも脱jQueryするかは俺には分からん。
ただ、俺はデザイナは脱JavaScriptするべきだし、環境もそう整備される、と思っている。 >>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 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要素を使っている)
と機能を提供している対象が違っており、それぞれお互いを補完する形になっている。 >>536
> 君との話が進まないのは、君が毎回誤解/曲解して、その修正に1レス以上必要だからだ。
一つも修正してないじゃんw なんでDOM APIとの互換性を考慮する必要があるの?ww
jQueryで全部できるんじゃないんですくぁ〜?wwwww >>540
> なんでDOM APIとの互換性を考慮する必要があるの?ww
> jQueryで全部できるんじゃないんですくぁ〜?wwwww
だから、アンチjQueryが、jQueryを使っているならば
全部jQueryの世界で閉じてるはずだ!
jQueryで全部できるんじゃないですか〜って
思ってるのがそもそも間違いってことだよw
jQueryを使ったプログラミングでは日常的に標準のDOM要素を使っている。
実際にonのイベントハンドラ内のthisとかDOM要素なんだから。
jQueryは設計の時点で、標準のDOM要素を使うことを想定してある
それを知らないで、コードを上っ面だけ眺めて、全部jQueryでやってるように見える。
これ全部jQueryの世界だ。DOM APIの世界と全く違う!独自の世界だ!!
なんて言ってるから、呆れるわけで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 NodeListには全くタイプの異なる要素が含まれる可能性がある
それこそTextNodeとかも入りうるのにイベントやスタイルを一括処理するメソッドが入るのは不自然だろう
fiilterとか全部入れないといけなくなるし
そこはAPI提供先の言語の機能を借りた方が良いだろう
DOMってJSだけのものではないからね >>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とその文字列長を出力する。 上でjQueryには配列で管理していると書いたが、
上のコードにもあるように、eachメソッドでループしてそれぞれの
要素に対してメソッドを実行している。
jQuery関数の引数にセレクタを渡すとDOM要素の配列として内部で持ってるわけ
そしてそれぞれの要素に対してメソッド( 今回はtoString() )を実行しているだけなんだ。
ということは、つまり、このプラグインは、以下のような使い方もできる。
$(["red", "blue", "green"]).len();
jQueryオブジェクトでラップして使うための要件を要約すると
1. jQuery関数に渡したものは、配列に出来さえすればいい(すべてできる)
2. 配列をeachでループできればいい(配列なのでループできる)
3. オブジェクトに使用するメソッドが生えてさえすればいい
たったこれだけなんだ。DOM要素でなければいけないなんて要件はない。
配列化された個々のオブジェクトに使用するメソッドがあればいいだけなんだよ
(もちろんメソッドの有無を判定して、なければスキップすることもできる)
つまりな、全く異なるオブジェクトが入ろうが、ループで回してオブジェクトに
メソッドが生えていればそれを呼び出すだけなんだから、
まったく異なるタイプのオブジェクトだって対応できるんだよ これは、ダックタイピングの考え方そのものだよね
型は関係ない。使用するメソッドさえあればいい。
jQueryはDOMを扱うライブラリだから、
DOM要素でなければ引数に出来ないと思い込みがちなのはわかる。
だけど、jQueryで提供しているメソッドこそ、DOM操作用のメソッドってだけで
単一の要素を配列として操作するという設計は、DOM専用のものではなく
DOM以外にも適用可能なわけだ。
まさにこのような使い方ができる通り
$(["red", "blue", "green"]).len();
貼り忘れていた。実際に動くサンプル
https://jsfiddle.net/vxpk0yef/ まあ、よくよく考えてみると、
> NodeListには全くタイプの異なる要素が含まれる可能性がある
$('.foo')と書いたって、全くタイプの異なる要素が含まれる可能性があるわけで。
例えば、$('.foo').prop('checked')と書いても、checkedプロパティが
存在しない要素の可能性もあるわけで、最初から対応済み。
(プロパティがなければスキップされる)今更なんだよねw >>540
そういう大言はせめて、addEventListenerの第三引数が実装されてから、いえ >>543
俺はjQuery擁護派でも何でもないので、純粋に知的好奇心から尋ねるが、NodeListにテキストノードが入る再現コードは何だろう?
確かに、仕様上は要素ノードに限定されてはいないのだが、再現コードが分からんhttps://triple-underscore.github.io/DOM4-ja.html#interface-nodelist >>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のベータ版を出すという話があったけど
遅れてるんだろうね >>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を返すなら、queryselectorAll限定である必要はないな。
jQueryのcontents()メソッドに対応するDOM APIってことで調べたら、
childNodesがテキストノードも含まれるNodeListを返したよ
https://developer.mozilla.org/ja/docs/Web/API/Node/childNodes ローカルの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側で許可されていない。普通は使う側がセキュリティを切る
その他
どれでしょう? >>553
とても明確に理由が示されているのだが > CORS
下のSOLD OUTの方がどうなってるかは知らん
CORSについてはブラウザでやるのを諦めるのが正解 >>554
レスありがとうございます
ニコ動のAPIのように公開されているものでも、CORSは許可していないということですか?
API公開≒CORS許可で、こちらに何か足りないと思ってました
保存したものなら大丈夫なので、保存だけ別の方法を探してみます ログインすりゃ使えるんじゃね?知らんけど
無制限に許可なんかしたら負荷かけられまくるんだから
誰がAPIを叩いたか知るためにもログイン必須はおかしくないでしょ? 基本的に外部サイトへのリクエストはセキュリティ上の理由で禁止されてるんだけど、それを許可するのがCORS
これは外部サイト(ここではAPI)側でしか設定できないから、迂回するにはCORSヘッダを付加するプロキシサーバーみたいなのを建てるしかない
GET限定で良ければ誰かが建てたそういうサーバーがある(CORS Anywhereとかcrossorigin.meとか)けど、利用する場合は自己責任で
(レスポンスが改ざんされたり、動いてなかったりするかもしれない) >>557
なんやこれ便利すぎるwww
jQuery糖質キチガイに辟易しながらもこのスレ覗いてて良かったwwww >>544
問題あるかないかの話はしてないよ
そりゃ問題ないように作るということは幾らでもできるから
でもNodeListというクラスのメソッドとしては性質上「不自然」だって言ってるの
適当にコーディングするためのjQueryでは許されても標準では許されないよ jQueryが受けているのは「初心者にとって丁度いいから」というのもある。
PHPがそうだが、上級者から見ると「なんでこうした?」というのが多いが、
初心者にとってはそれくらいベタの方が使いやすい。
だからPHPも初心者受けは良い。同様に、jQueryも初心者受けは良い。ベタだからだ。
(フレームワークは初心者にとっては何をどう使えばいいかさっぱり分からない。
これがjQueryにはない、ということ。)
ただ、jQueryは低レベルすぎて、短く書けるだけで、やること/管理することが減るわけではないから、
上級者にとっては導入のメリットがない。
むしろ、依存関係が増え、記述が冗長になる(複数の書き方が混在する)という意味で悪だ。
だから、腕前を上げるに従い脱jQueryを目指すのも自然なことで、「自転車の補助輪だ」というのも当たってる。
タイピング量なんて全くどうでもいいし。
ただこれらは「上級者」に近くなってこないと理解出来ないし、
当然デザイナと話をしてても水掛け論にしかならず、話は堂々巡りだ。
ある意味、デザイナがプログラミングまで出張ってきているJavaScriptの世界が特殊なのだろう。
アプリを組めるレベルになってくるとjQueryの問題点は自明として、
それ以下だと認識出来ないから、意外にずっと使われるのかもね。ある意味PHPもそうだし。
あれは、「サイトの数」で比較するからjQueryのシェアが高く見えるんだろうな。
実際の「Web閲覧時間」での比較が出来れば一番良いのだけど、これは直接的には無理だから、
現実的には「サイト数をPVで加重平均」したものが妥当かな?
これだと実際に見られているシェアとなり、感覚的にも一致するはずだし。
>>544
> jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ
それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。
ま、NodeListについては、DOM自体がいまいちOOPに乗り切れてないことの問題ではあるが。 > それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。
また、それがどこか答えない。
同じことの繰り返しだな。
通じない?当たり前だ
お前が何も言ってないんだから >>561
いやモロに書いてるがな。
マジな話、お前英語も読めないよな?語学の問題ではなくて、知能の問題で。
日本語だけ2行ずつしか読めない、ってのもあり得ないし。
それともお前の頭の中ではスコープ外で話題を追跡出来てないのか?
俺が言ってるのは当然>>525内URLの事だぞ。 > いやモロに書いてるがな。
いつもどおり。リンクを示せば良いものを
書いていると書くだけでおしまい。
やり口がかわらんなぁw 訂正
× リンクを示せば良いものを
○ 引用するなどして、具体的な箇所を示せば良いものを >>563
お前もいつも通り連呼リアンだよな。
普通は562は「リンクを示した」と言うぜ。
お前、煽り抜きで頭おかしいと思うぜ。マジで池沼。
同様の奴が他に2人いると書いたが、お前が一番程度が酷い。
さすがにそれだとリアルの普通の会話も成立しないだろ。 >>564
英語読めるつもりなんだろ?自分で読めよ。
というか、あれ、脱jQueryが気になる奴は、読む価値はあると思うぜ。
お前は読んでも全部読むうちに忘れちゃうんだろうけどさ。
それでもお前の頭は交換不可能で、お前自身で鍛えるしかないんだから、
無い頭使って一生懸命読めよ。
それを繰り返してたら、お前のその頭も少しはましになるよ。 なお、GitHubの公式声明の内容は割と普通のことなので、
普通に脱jQueryを実行出来る人は特に読む意味はありません。
何故脱jQueryなのか?に疑問を持つ人は、読む価値があると思います。 だから、GitHubの声明には本来書いてあるはずのjQueryをなくして
その結果、何が得られたかが「書いてない」ってのが、注目する点なんだってばw >>568
お前はそれを連呼しているが、実際そうじゃない。
やっぱりお前、英語も読めないよな。まあ、当然か。
語学以前に論理/記憶がお前の頭にはないからな。
まあ、そういう池沼レベルの奴でも使える、というのはjQueryの利点ではあるよ。
お前も>>409で指摘している点だ。
Excelだって数式までは宣言型で逐次処理無し(順序の概念無し)なのでアホでも使えるし。 >>550
昔のIEが対応外になっている時点で関係ない
そして、俺はDOM API不要論者(>>540)に反論しただけなので、あなたのは論点がずれてる いつものインタビュー貼っておきますね
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html >>553-557
自分のPC にサーバーを立てて、サーバー経由でアクセスしないと、
ブラウザからでは、CORS でアクセスできない
例えば、自分のPC 内のHTML ファイルを、ブラウザで起動して、
そのページから、5ch へアクセスできない。
iframe 内に読み込んでも、iframe 内外が、別ドメインだからアクセスできない
ruby -run -e httpd . -p 8080
1-liner で、Web サーバーを起動して、そのindex.html からは、別ドメインにもアクセスできる >>572
そして、俺はDOM API不要論者(>>540)に反論しただけなので、あなたのは論点がずれてる
そうだね。俺のレスへの返信じゃなかったわw
俺はDOM API不要論者じゃないので。
俺は >>550にも書いてあるように混ぜて使って良い派
むしろ普段から混ぜて使っているんだよ派か
(jQueryで出てくるthisはDOM要素だから) オリジンが違ってもアクセスはできるだろ
取得した中身が読み取れないだけ アクセス拒否されるし取得できない。
何いってんだコイツ 何いってんだコイツはお前だアホ
await fetch('https://developer.mozilla.org/',{mode:'no-cors'})
アクセスしてるだろうが
もし拒否されるのならServiceWorker導入ページでどうやって
外部リソースをリクエストしたりキャッシュしたりするつもりなんだ?
人様にケチ付ける前に自分が無知であることを知れよ 元々の文脈考えたらアクセスできない、で良くね?
オリジン違えば非同期通信でAPIのレスポンスは取ってこれない
jsonp対応してれば行けるだろうがそれはまた別の話だ >>579
そもそも文法エラーだなそれ。
出直してこいw > 人様にケチ付ける前に自分が無知であることを知れよ
で自分を人様って言ってるのも色々アレ >>580
元の文脈的にサムネイルとかのメディアデータへのリンクが分かるのなら
それはimgやvideoタグで表示されられるかも JAVAscriptと書くのは普通ですか?
ネットで見たのですが 勉強にのためにライブラリのjplayerを解読しようとしてるが
難しすぎる。
おまえら、javascript勉強してるってこは
ライブリとかもすらすら読んでわかるの? jQuery使わなかったらもっと難解になるんだよな >>588
覚えればすむものは楽なんだよ。
単に覚えればいいだけ理解すればそれで終わりなんだから。
大変なのは>>589みたいなもの。ありえないほど短いコードで
実現しているから凄いといわれるけど一般的にはクソコードと言われる類。
なぜかというと、コードというのは簡単に読めるものじゃないといけない
もちろん知識をつけたもの、能力がある人にとってね。
知識があって能力がある人でも読むのに時間がかかるような
無駄な処理ばかりで何をやってるか分からないようなものは大変
それが「解読」という作業。これはコードに問題がある。
知識がなくてわからないのは解読じゃなくて単に読めないだけ
読んでる人に問題がある 7行テトリスは、まるで暗号
jQuery のCSS セレクターを学べば?
基本的には、# . > など、Emmet と同じ
Ruby のNokogiri でもよい やっぱ、オレの勉強不足だな。
もっとjavascript勉強しよ。
日経ソフトウェア読んでると、javascriptに
Reactという仮想DOMとか出てきてるし
どんどん新しい技術出てきてる 仮想DOMは、なんでDOMを全部再構築するというアイデアが
出発点になってるのかわからない。
jQueryがやってるように普通に必要なところだけDOMを更新すればいいだろう 部分更新も、複数回のDOM操作がinnerHTML差し替え1回で済ませられたらメリットはあるんじゃね。 複雑になってくると毎回全部再構築した方が楽だと思うけど
昔はDOMが遅くて実現が難しいとかじゃなかったっけ 推薦書
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 VueはVue.js入門が出たから猫の方はいらんよ >>598
> 複雑になってくると毎回全部再構築した方が楽だと思うけど
> 昔はDOMが遅くて実現が難しいとかじゃなかったっけ
つまりマッチポンプってこと?
1. jQueryなどを使って必要な部分だけ構築する・・・一番速い
2. (アホな)アイデア思いついた!全部再構築したほうがいいんじゃね?・・・遅い
3. VirtualDOM使えば(jQueryほど速くないけど)全部再構築しても遅くならない!
VirtualDOMって遅くならないだけなんだよね
決してjQueryよりは速くはならない >>594
そもそも遅延描画する必要がないですよね
仮想DOM使っても結局変更部分はDOM操作をするんだから
仮想DOMを使わずに、変更部分をDOM操作すればもっと速いですよね
なんで仮想DOMは速いって嘘をつくんだろう?
遅くならないって言えばいいのに そもそも、仮想DOMの方が常にjQueryより速いと主張する奴がいるという思い込みじゃね? 例えば>>597にも書いてますね。
> VirtualDOMの仕事ってなに?(Reactの表示速度がはやい理由)
「Reactの表示速度が遅くならない理由」と書けばいいのに
もともとDOM全部再構築なんて遅くなるような馬鹿げたことはやってないんですよ
逆にどうやってjQueryでDOM全部再構築をやれと?
めんどくさくてやってられないし遅いのでやらない
遅くなるDOM全再構築なんて馬鹿げたことをやって
遅いだろう?でもこれだと遅くないんだぜってっていうのが
マッチポンプなんですよ まぁ藁人形論法だね。
その他によく知らない初心者が勘違いしたまま質の悪いウソ情報をネットに垂れ流してるというのもある。 >>597は典型的な勘違いして垂れ流してる初心者だなw
こんなのよりReact登場初期の、初心者が知ったかでイキってられない時期に書かれた記事読んだ方がいい。 「今までは、基本的に受け取った情報を元にDOMを
一から作成してブラウザに描画することが多かった」
こんなことやってませんからね
サーバーを介さないクライアントだけで処理できるもの、
例えばボタンがクリックされた時に何かを行う処理は
必要最小限のDOMしか変更しないんので速い
「受け取った情報を元に」と書いてあるからAjax前提の話か
ページ遷移の時の話だろうけど、ページ全体を読み込むよりかは
一部分のほうが早いのは当然として、それはAjaxを使えばいい。
Ajaxを使って、必要最小限のところだけ書き換えるのが普通
DOMを一から作成してブラウザに描画とかしないから SPAにページ遷移という概念が存在するとは限らない
SPAはアプリケーションなのだから
ただ単純に実際のページ遷移を伴わない技術はpjaxと言ったほうが良い あれ?いつもの奴ではない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のアップデート共に改善されて最終的には限界まで端折ることになる。
この辺の、改善を外部のアップデートに期待出来ることも、フレームワーク等を導入するメリットでもあるだろ。 その記事内にもあるが、
> ウェブ開発者が文句をいう DOM の遅さは大半がレンダリング由来だったりする。
これは全くその通りで、レンダリングさえしなければDOMは遅くない。
(jQuery廚が居るから一応言っておくが、クエリもそれなりに遅い。
ただ、Reactとか使う人はクエリはほぼ全くしないはず。というかこの構成だと禁止かも?)
つまり、document.create等は十分速く(=仮想DOM構築も速い)、レンダリングだけが遅いから、
どうにかしてレンダリングを止めさせよう(少なくしよう)というのが遅延描画だ。
それが必要かどうかは場合による。
描画しなくて済む範囲が多ければ、当然ぶっちぎりで速い。
jQueryは生JavaScriptよりも本質的に遅いから、遅延描画が効くようなら、
生JavaScriptで遅延描画>フレームワークで遅延描画>>>生JavaScriptで描画>jQueryで描画
となる。
ただし遅延描画の肝心要のoffsetTop等がこれまた致命的に遅いので、(レンダリングを要する為)
単純に遅延描画にすれば(体感的に)速くなる訳でもない。
jQueryを使ってて許されてるのなら、そのサイトはスピード狂ではないので、
遅延描画を要求されることもないのではないかな?
ただそもそも、遅延描画が効くサイト構成の所も少ないかも。
例えばアマゾン、商品一覧はいちいち「次のページ」を押して遷移するようになっている。
SPAでページ毎に商品表示部分を全面描画してる。
(ページ全体の全面描画ではなく、商品部分の全面描画。念のため)
ページ内商品点数は36なので、この程度では遅延描画はあまり効果がない。
(というか下手にやると余計に遅くなる。少なくともPC環境ではそう。モバイルだと違うかも)
俺はこういうのは無限スクロールでぐりぐりやってればいくらでも見える方が好きなのだけど、
そういうサイトは確かに少ない。
(とりあえず150点くらい表示出来るオプション付けてくれ、と思うが、そういうところもない) 2つ目の記事ではサーチのサジェストが例に挙げられている。
この場合、エレメントが選択的に削除されるので、確かにVirtualDOMの出番ではある。
jQueryでよくやるように、宣言的に記述する場合、
サーチサジェスト部分,innerHTML= となるが、生DOMでは全面書き換えとなる。
VirtualDOMなら同じ記述でも自動的に選択的に描画してくれる為、(一般的には)速くなる。
なお、やれば分かるが、この場合の選択的描画を自前でやると結構ウザイコードになる。
自動でやってくれるのならその方が断然楽だ。
とはいえ、俺はVirtualDOMは流行らないと思う。理由は、
・そもそも遅延/選択的描画が効く構成の所が少ない
・遅延/選択的描画するにしても再描画区画は確定的であり、フレームワークを導入するまでもない
・APIが超絶イマイチ
仮想DOMなんてユーザーに意識させてる時点でアウト。
あれはcssプロパティ draw:lazy ならブラウザが自動的に対処してくれる、程度でなきゃ駄目なのさ。
実験としては面白いと思うし、今のJavaScriptで動かすなら今の実装で致し方ないが。
しかしまあそれを言ったら、jQueryが流行った理由は
・時代がそれを必要としていた
・馬鹿には丁度いい頃合いだった
であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
発狂するくらいならフレームワークとか見た方がいいと思うぜ。
使う必要はないが、何故そんなフレームワークが出てきたのか、には意味があるから。 > であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
そんなデータどこにもないですよね? >>611
> jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
> やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
なんで遅延描画をしなければならないって
危機的状況に陥ってるの?w
まずそんなものは不要ですって認めるところから始めようか 君が現実に目を瞑るのは自由だが、
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ロック状態はあまりよろしくはないと思うぜ。それもまた自由だが。 いちいち長すぎだろ…要点まとめるぐらいできないのか ブラウザにやらせるべきって言ってもブラウザ側にも限界があるし
PauseFrameとかその時その時のベストプラクティスを徹底するのも難しい
その辺りをケアしてくれるのがフレームワークのメリットなのだから >>619
現状のフレームワーク等はいい実験をしているとは思う。
ただ、描画に関してはブラウザの方が主管なので、本来は丸投げ出来るべきだ。
現行のAPIを組み合わせてもこれは無理だから現状は致し方ないとしても。
> PauseFrame
使いどころは、
A. ajaxで将来的に書き換えると分かっているframeを停止する
B. 画面外のframeを停止する
として、AはJS側でいいが、Bはブラウザが勝手にやるべきだ。
根本的な問題は、CSSが全く拡張不能なこと。CSSで
・pause: auto ならオフスクリーンの場合はpause『してもよい』
という拡張が出来れば、これが一番自然だ。仮想DOMについては、
・draw: lazy でオフスクリーンなら描画『しなくてもいい』
となる。ここら辺まで出来れば、
フレームワーク導入コストはほぼ0となり、もっと面白くなるのだけどね。 >>620 俺の考えとしては
ブラウザは勿論最大限努力すべきだけど、プログラマがどんな書き方をしていても理論上最善に近いパフォーマンスをしてくれというのは明らかに無理があるし、
一方ある程度はブラウザ側がパフォーマンスのための機構を提示して、プログラマ側の努力を求める事も仕方ないと思う
また別の話として、CSSも数年前からJITが入ったり、ブラウザがよしなにやってくれる感は確かに高まっているけど、それと同時にHoudiniだったり従来よりローレベルな環境が提示されるようになってきておりプログラマの責任も高まってる で、結局のところ、重要なのはJavaScriptでいろいろ解決しましょうじゃなくて
根本的な設計を改善するほうがいい。
つまり静的なページで作れば問題は解決すると言うこと
JavaScriptを使って動きをつけなきゃいけないことなんてほとんどないでしょ? >>623
バカ?w
ほとんどのサイトは静的なページで事足りる >>621
考え方は間違っていないと思うけど、ちょっと混線してるかな?
自前で遅延/選択的描画を実装すると糞コードになるのは、
OOPで言うと、本来はオブジェクトA(ブラウザ)で完結する処理をオブジェクトB(JS)で無理に行っているからであって、
俺はそこを何とかして欲しいんだよね。
フレームワークに押し込んで隠蔽する、というのも一つの手ではあるけれど。
そちらのレスについては、単純には、
・馬鹿な書き方でもそこそこ速い
・チューニングしまくれば超速い
が通常目指すべきゴールだ。ここまではいいよな?
どちらを目指すべきかだが、両方追っかけているC++が若干迷走気味なので、
本当はどちらかに絞った方がいいんだよ。
Houdiniってことはゲーム畑に近いと思うけど、それなら当然後者を目指すべきと考え、
レンダリング制御関連のAPIがほぼ無いから困っているとは思う。
しかしそれは、APIさえ有れば十分に制御が出来る腕前があるからであって、
実際のWeb系はそこまで到達してない奴の方が多いと思う。
jQuery廚がよく言う「jQueryは簡単!」(=馬鹿でも問題ない)というのは実は偉大なことであって、
これ自体は素晴らしい。
(jQuery廚の問題は、結局そこに乗っかってしまっていて、結果、馬鹿なままな点であって)
俺個人としては、手を抜けるところは抜きたいので、前者に寄って欲しいんだけどね。
実際は後者に寄っている気はする。
というか、前者を実装するにしてもAPIが必要だし、普通はまず後者を実装するしかないからね。
ゴリゴリの制御が要求されたとしても超高速化したいのなら、技術的にはC++側にコードを注入出来ればいい。
昔で言うアドオンをサイトから毎回ダウンロードして使う、というイメージだ。
アドオン自体はサンドボックス上ではなかったので排除されてしまったが、サンドボックス上にすれば行けるはず。
WebAssemblyが近いが、あれはJS側上のサンドボックスのはずだから、あれのC++側版だね。 3DグラフィックスのHoudiniと勘違いしてない?
CSS拡張APIのHoudiniだよ? >>624
あのさ、お前のようなヴァカの主義なんか興味ないんだよ、クソ間抜け。 >>622
君が静的なサイトしか作れないからといって、そうだと思いこむのはさすがに不味いと思うぞ。
>>624
というか、前から疑問なのだが、君は普段どんなサイトを見てるんだ?
純粋に静的なページって、今時、あまり見ないだろ。
例えば、動的な順で並べると以下か?
Amazon等ECサイト…大体SPA
2ch等掲示板…2chは糞だが、本来はDBに格納してPHP等でhtmlを生成して配信。
Yahoo等のニュースサイト…同上。更新頻度がやや低いだけ。
MDN/MSDN等…同上。さらに更新頻度は低い。でも更新機能があるからDBがあった方が楽。
ブログ…この辺から直接html配信でも行けるはずだが、実際はDB使っている方が多いのでは?
他に何がある?
DBも使わずhtmlを直接書いて配信してるサイトなんて、普段ほぼ見なくね?
零細サイトはほぼこれだから、サイト数(=仕事)だけは多いのかもしれんが。 >>627
してる。というか、ググったらそれが出てきて、Web系の会社も記事を出してて、
OpenCVでキャンバスに描くぜ!なノリだったからそれだと思った。
そして改めてググり直した。
https://developers.google.com/web/updates/2016/05/houdini?hl=ja
う〜ん。最初はこんなもんかもしれんが、
これは pause: auto や draw: lazy が効率よく出来るタイプの物ではないな。
初期のJavaScriptはこんな感じでちょこっと動きを付けていたのかも?
そしてそれをCSS側に移動しただけのような。
今のところCSSはプログラム出来ない(しない)で来ていて、それによる良さもあると思うのだけど。
勿論これが出来れば便利ではあるが、グダグダなのが増えて管理コストが増加してポシャる気が。
なんであれ「出来ることはいいことだ」という考え方もありだけど、
俺自身は「出来ることと出来ないことがはっきりしていて、使い分ける」方が管理が楽だと思っている。
なんというか、この中途半端に出来る感が、凄くJSっぽくはあるが。
とはいえ、JSは駄目だがCSSはあり、というサイトも多いはずなので、無駄に広まりそうだが。 >>630
HoudiniはCSSの枠組みで標準化されているが、実際にはCSSというスタイルシートの仕様の延長上のものと捉えるのは間違っている
もちろん単純なCSSの拡張、柔軟化の仕様も含むが、それ以上に重大な仕様が含まれている
Houdiniとは、スタイルシートのパースから、レイアウト・ペイント・将来的には文字描画も含む
要するにブラウザのDOMレンダリングシステムをローレベルでほぼ丸ごと露出させるという
Extensible Webの精神に乗っ取ったけして中途半端ではない非常に深く広くしっかりとしたAPIだと捉えるのが正しい
pause: auto だの draw: lazy だのも素直に実現できる
>>グダグダなのが増えて管理コストが増加してポシャる
その考え方が本当に間違っている
Extensible Webは皆低レイヤーを触ろうと言ってるんじゃない
皆が求める機能を標準に追加していくのは難しいところがあるから
なんでも作れるAPIを提供してライブラリに任せましょう
そこで本当に便利なものができたら標準に組み込んでも良いねという精神だ
逆に新しい高レイヤーの機能入れたいねとなったときには、
必ずそれを構築できる低レイヤーのAPIを提供することになっている
それが最近よく聞くLayered APIと呼ばれる取り組みだ
つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
それ嫌だとしても、そういうことにしていきましょうということに、もうなっている この静的って、DOMを弄らないって意味ではないの?
昔ながらのPOSTで全画面更新で充分だって主張に読めたけど。
流石にバックエンド無しと取るのはちょっと変な気がする。 いやでもapacheの説明書とかではjsもhtmlやcssと同じくスタティックコンテンツやけども… >>631
まあ言っていることは分かるし、その通りだが…
> pause: auto だの draw: lazy だのも素直に実現できる
表現は出来るが、これだと実際やるのはJSだろ。
つまり、今JSで実装しているReactのコードをCSSに持っていくだけであり、速度上のメリットは無い。
それでも外部APIが素晴らしく改善されるので効果はあるが、俺が欲しいのはコレジャナイ。
JSで実装する遅延描画がイマイチなのは、offsetTop等が糞遅いからで、
これは『正しい』offsetTopを要求するAPIしかないからだ。
だから、offsetTopの度にリフローを行い、未描画のDOMがないか全チェックする為、遅くなる。(多分)
ただ、遅延描画に必要なのは「そのページ以上の所まで描画済みか?」であり、
offsetTopの精度が悪くてもいい。(未描画DOMが残ってても問題ない)
そしてこの「精度の悪いoffsetTop」をAPIとして定義しろ、なんていちいちやっていてもキリがないから、
レンダラに介入させろ、というわけだ。
レンダラ内でラスタライズしている時、アドレスからおおよそのoffsetTopなんて一瞬で出せる。
当然高速化するし、きめ細かく制御出来るから、限界まで高速化出来る。
(ただしGPUにやらせようぜなんて話が出てたからそうなると一筋縄ではいかないが) >>631(続き)
> つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
言っていることは分かるし、確かにこれ以外に現実的路線はないが、果たして上手く行くかね?
今以上にフレームワークが乱立して、なんだかな、な状態になりそうな気がするが。
それも含めてWebだというのならそうだが、
今フレームワークを乱立させてる連中をどうにかして一ヶ所に集中させ、一ついい物を作る方が、
皆にとって幸せだと思うがな。
現状のフレームワークなんて全部死に体だし、あれでは浮かばれんだろ。
> 今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
これがかなり無理があるんだよ。
JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが、
実際はC++ヘビーでレンダラやDOMが実行時間の大半を占めてるだろ。
JS側には改善予算(改善しろ)がないんだよ。
かといって、C++側にAPIやフックを用意させるのもかなり無理な話ではあるが、
しかしJSがパフォーマンスの全責任を負うのはそれ以上に『原理的に』無理だ。
強いて言うなら、現状のブラウザは十分高速で、1ページ程度ならレンダリングは一瞬だ。
遅いのは無駄に10ページ分レンダリングしてたりするか、無駄に遅いJSを実行しているからであり、
ここら辺を遅延描画で改善してやれば可能だが、
今はこれを実装する為の「速い(が精度の悪い)offsetTop」がないんだよ。
> それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
現実的にはこの路線しかないからな。これは認める。 >>632
すまん、それはちょっと俺が先走った。
普通の「静的ページ」は君の定義で正しいだろう。
俺は616に書いたとおり、jQueryが活躍するサイトはHTMLがグダグダな場合で、
それはhtmlを自動生成してない場合と認識しているから、
彼はjQuery廚なのもあり、先走ってしまった。
さて、実際yahooニュースをJS無しで確認してみると、
<noscript>が大量に使われているものの、どうでもいい場所ばかりだ。
これなら変にアドブロックするより、JSを切った方がいいのでは…とも思える。
SPAでもないし、ポップアップもない。リンクはいちいちページ遷移する。
これは「静的ページ」だ。
もうちょっとましな作りかと思っていたのだが、
確かにこれで大して問題ないのも事実だな。
もっとも、鯖側で動的にhtmlを生成する場合、
当然画一的なhtmlとなり、IDやclassをきっちり振ることも簡単だから、
jQueryを使う意味はほぼ無いと思う、という主張はそのままだが。
(yahooはjQuery使っているが) >>637
もう口閉じてろ
ここはお前のような馬鹿が議論する場じゃねぇんだよ。板違いって事知れや間抜け >>635
>>一ついい物を作る方が
君がそれができるというのならしてみると良い
Webは一度APIを入れると中々消すことができない
だけど流れは早いので慎重に進めすぎるわけにもいかない
それを両方解決できる人間はこの世にいない
今のまま標準に機能を入れ続けていったらそれこそカオスになる
だからそういったリスクはライブラリに押し付けるのが正しい
>>JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが
俺は今あるコードのことを言ってるんじゃない
これからは高レベルなAPIは低レベルなAPIをもとに作っていくことになるのだから
なにか新しい機能を求めたり、今まで難しかったことを素直に実現するため
Houdini含む低レベルAPI叩いたり、それを利用したライブラリを使うときは
その機能のパフォーマンスを含む責任はJSサイドに来ると言っているんだよ 一般人「クライアントからの情報に応じてサーバーサイドでJavaやPHP、Rubyなどで動的にHTMLを生成して返すのが動的ページ、用意してあるHTMLをそのまま返すのが静的ページ」
キチガイ「Javascriptが動いてたら動的ページ!」
なぜキチガイはイカれた頭の中のオレオレ定義をその汚い口からひり出してしまうのか… >>639
> Webは一度APIを入れると中々消すことができない
> だけど流れは早いので慎重に進めすぎるわけにもいかない
これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
そしてWebが速いって言ったって、結果出来上がっているのはゴミの山であって、
進歩(=成功したパス=使えるものとして残った経路)だけ見ればC#の方が断然速い。
事実として今のJavaScriptはC#の後追いでしかないだろ。
> それを両方解決できる人間はこの世にいない
これは「創始者」がこれに近いものとして振る舞う、というのが他言語/OSSの習わしだ。
この点、ブレンダン・アイクが全く出てこないところがJavaScriptの不幸な点ではあるけれど。
とはいえ、現状で現実的判断をするなら、君の言っている方向性しかない。
ただ、カオスにはもうなってると思うけどな。
○○ってフレームワークはどうですか?みたいな質問ばかりなのがそれを如実に示してる。
標準さえ汚れなければいい、という考え方もありだが、
Promiseは要らない子だと俺は思うし、防波堤になりきれてない。
> 君がそれができるというのならしてみると良い
機会があればやるかもしれん。(これは君も同じだと思うが)
俺が今フレームワークとして欲しいのは遅延描画だけで、Houdiniでは無理だからすぐにはやらないね。
ただ、どっちかと言えば俺が試してみたいのはフレームワークではなくJavaScript自体の直接的拡張であり、
JSエンジンの低レベルAPIについて提供するような方向になっているか知ってれば教えて欲しい。
例えば async とか、ああいう言語拡張をする為のJSそのものの低レベルAPIだ。 >>641
>>これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
その場合でも旧バージョンは旧エンジンで動かせば良いのだから
しかしWebでは旧サイトは旧ブラウザで見れば良いとは言えない
JSもしかり、機能を非推奨としても、新しい機能との兼ね合いを定義しないといけないし
廃そうとしても10年以上かかる
>>結果出来上がっているのはゴミの山
WebAPIをゴミの山と言うのは流石に言いすぎだと思う
1つ1つ思い返してみても、ゴミだったねと言えるAPIはそう多くない
>>ブレンダン・アイクが全く出てこないところ
間違っている
彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
彼が慎重なおかげでJSはまだ「失敗」していない
勢いのまま進んでたら失敗していたであろう瞬間はいくつもあった
とは言え、今まで話してきたのはほとんどWebAPIについてだ
JSとWeb違う 彼がWebに口出す責任はない
そもそもWebとは皆の総意の中に秩序を見出す形で作られるものなのだから
皆がその時実現したいと思っていることを実現できるようにするのが正しいWebだ
だから流れは速い
それをプロプライエタリで創始者が全て管理するプラットフォームと比べて、あれが悪いこれが悪いというのは間違っている
なぜならそれは男がいて女がいるようなものだから
男が女らしくなったら男じゃないし、女が男らしくなったら女じゃない
男に女らしくないとか、女に男らしくないとか言うのは根本的に間違っていること
男らしいのが好きか、女らしいのが好きか、という話でしか無い >>641
>>○○ってフレームワークはどうですか?みたいな質問ばかり
いやいや、それが理想なのに、質問がまだまだ少なすぎるくらいだよ
というか、カオスになったら、モジュールの検索のしやすさや、そのためのスレを立てることが必要になるはずだ
でもまだそういった、「これを実現するためにどのライブラリが良いんだろう」という質問がなく、
具体的なライブラリばかり質問に挙がるのだから、全然まだまだってことだ
>>Promiseは要らない子
Promiseがどうして要らない子だと思うのかさっぱりわからない
Promiseとasync-awaitの関係は他と比べても無難で普通だ
Kotlinの用に中断可能なスレッドの組み合わせでやるのも面白いが、
基本的に「スクリプト言語である」はJSは、何かの対象を操作するためのものであって、
例えばWebならレンダリングスレッド上でイベントを受け取ったり操作したりすることが基本の動作であるから
今の仕組みになるのが最も自然と言える
>>言語拡張をする為のJSそのものの低レベルAPI
アイディアは昔から出てるが、これこそ正に流行り廃りが激しく未開拓な分野
安易に入れてしまうと後々公開するので、マクロ的な機能はずっと後
ただASTを取れるようになったり、モジュールとして自然JS以外の言語をより自然に読めるようになるのはそう遠くはないと思っておいていい >>643
> いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
これは技術的にはそうだが、実際はいきなりは壊してない。
JSと同じく、一旦obsoleteにして様子見し、衰退を待ちつつ、だ。
JS界隈ならちょうどjQueryと同じだ。
そこそこ互換性を壊しつつ、どのバージョンを使うかはユーザー選択だ。
だからこの意味で「メジャーアップデートのときに互換性を壊すことができる」を利点とするなら、
それはjQueryが素晴らしくフィットするわけだし、実際そうだから蔓延ったわけだろ。
ならずっとjQueryをポリフィルライブラリとして使えばいいだけだ。
実際そういう人もいるだろう。
> 彼は今でも出しゃばっており、TC39の貴重なストッパー役となっている
そうなのか。ならそれは正しい姿だ。
> 正しいWebだ
いややはり買いかぶりすぎだよ。
これは君だけではなく、最近の連中はみんなこんな感じだが。他言語も含めて。
自分が乗っかっているプラットフォームが正義だ、と思いこみたがっている。
実際の所、プロプライエタリにもオープンにもそれぞれの良さはある。
そしてWebは実質Google/MS/Appleによる準プロプライエタリだし、
C++仕様委員会の方が裾野も広くてオープンだ。
が、そもそもこんなのはどうでも良くて、
上位階層で「気に入らなければ使わない」という自由が保障されているから、
外部から見てどういう状況か明確に分かれば問題ない。
この意味で、ブラウザ上で動く言語がJSに限定されている現状は「プロプライエタリ」以上に大問題なわけだが、
お前らはこれを問題だとは認めないわけだろ。
まあこれもWebAssemblyで改善されそうだし、正しい方向に向かってはいるが。 >>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は死ね、と思ってるんだろうな) 準プロプライエタリwwwww
広義の強制連行wwwww 話が長い
プロプライエタリの意味が分かってないんだろうなぁとは思った >>879
お前みたいなヴァカに比べたら在日はみんな天才だよ
ITオンチ丸出しの恥ずかしいロートル野郎だな パクリ元のC#だか言ってる時点で御里が知れてる
C#にTaskとasync-awaitの絡みが入る前からdojoでdefferedが使われている
つうかESがよく参考にしてるのはC#じゃない、.NETだろ 流れぶった切って悪いが、
教えてくだしい。
↓を解読しようとしてるんだけど、DLしたら文字化けしてる?のときって
どうしらいいでしょうか?
ttps://d21agqkwgk4jud.cloudfront.net/MW-Common/RS4B/v0.1.9mw_2018-10-09/js/viewer_loader_v0.1.9mw_2018-10-09.js ttps://github.com/getify/LABjs
解読したいだけならこっち見れば良いんじゃないかな 雑誌読み放題とかのシャッフル画像を元に戻したいなら、
ブラウザを改造して、キャンバスの描画情報を出力できるようにしちゃったほうが早い >>654
ネット配信の漫画の画像をコピーしようかと思ってるのですが、
ブラウザ改装って、javascriptでどうにかなるのですか?
>>653
LAB.jsを改造したのが使われるみたいです。 JSでスクリーンキャプチャしてもいいが
OS上で動くキャプチャツール使ったほうが良いだろう >>654
>雑誌読み放題とかのシャッフル画像を元に戻したいなら、
シャッフル画像ってこんなやつか、
http://demon-uploader.rosepink.us/uploads/2018120909160154095.png
有料の漫画発信サービスって、大元の画像ってサーバーにあると
思ってたが、こんな感じで加工して、まるまる出回らないようにしてたのか
っで、javascriptのcanvasで描画し直してユーザーのブラウザに表示してんだな
オレの仕事、工業用機械のプログラム担当だから、
web業界は知らんが、漫画発信ってこんなことしてんだな 画像でも、DL されたくない場合に、画像上で右クリック禁止などにするけど、
F12 開発者ツールを起動して、URL を突き止められて、直リンクされる
だから、コピーされたくない場合は、canvas に描く 一旦仮想DOMを構築してからそれを実際のDOMに反映させるという手順を踏む以上、
ある程度のオーバーヘッドはある。
やりたいことがごく少量のDOM操作で済むような場合はかえって高くつく可能性がある。 >>660
DOM APIと相性が悪い。
DOM APIを使って直接DOMをいじるのはご法度
いじりたい場合、フレームワークのやり方に合わせる必要がある >>661
メモリもりもり使いそうだね
あとSEO的にはどうなのかな?
>>662
ドラッグしてリスト入れ替えとか無理? >>661
指摘はその通りだが、実際はそこは問題にはならない。
体感100倍くらいDOMのレンダリングは遅いので、オーバーヘッドは1%だし、無視出来る。
それで10ページ分纏めてレンダリングしているのを遅延描画に出来れば、単純に10倍速くなる。
普通に考えて、『導入に手間がかからなければ』みんな使う。
(ただし実際の所はネットワークディレイの方が支配的で、
変に無理してSPA等するよりも物理鯖に金かけた方が効果があることもよくあるが)
最大の問題は、ブラウザが勝手にやってくれるのではなくて、手動でやれ、という点だ。
>>662
> DOM APIを使って直接DOMをいじるのはご法度
これは(jQuery含めて)DOMフレームワークの宿命だ。
というか、フレームワークの場合はフレームワークに合わせるのが当然であって、
それが必要なのにライブラリだと嘘ぶくjQueryは相当汚いのさ。
VirtualDOMは実験としては面白いが、手動でやらないといけない現状の仕様では、流行らせるのは厳しい。
自動でやってくれるのなら確実に流行る。
が、その場合は現状のvirtualDOMの知識なんて不要なレベルまで隠蔽される。
(はず。ただしJavaScriptの仕様委員会はかなり間抜けなのであまり期待は出来ないが) >>664
お前さ、長文うざいんだよ。
ここは質問用スレッドであって
テメエのプログラム論語る場所じゃねーんだよ。クソ野郎。
今すぐ消え失せろ DOM をjQuery で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する
Vue.js から見たら、仮想DOMがすべての情報だから、
仮想DOM以外の情報は捉えられない bootstrapはjQueryありきだからUIは自前でデザインしないといかんね >>667
DOM をDOM API で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する >>672
うーん
めんどくさいね
reactはDOM変更されたのを読み取れるから勝手に仮想も変更しといてほしいんだが それが仮想DOMの限界なんだよ
ウェブの標準との相性が悪い >>674
それは仮想DOMというよりは、フレームワーク全体の問題なのではなくて? 触らずに済むように作ったら
触れないからダメって言われても その通りだな。
問題でも限界でもなく、当然の仕様であり、それが嫌なら使うな、でしかない。
というか直接いじったらフレームワーク導入の意味が無いし。 Doodle2というスクリプトから画像を描画できるCOMコンポーネントを64ビットのwindows10で使うことは無理でしょうか?
古い32ビットのDLLなので難しいかとは思うもですが
XPで使っていて自分にはこれで十分な機能だったので
使えるのならコードも流用できるので使いたいのです
C:\Windows\System32\ にはレジスト出来ず、調べたところC:\Windows\SysWOW64\のほうに入れるこはできましたが
依存 .DLL ファイルに問題がある、っぽいエラーがでてダメでした
何かを持ってきたり頑張れば使えるようになるのか、どうやっても無理なのかだけでも知りたいのですが
さすがに今使ってる人はいないとjは思うんですが + JavaScript の質問用スレッド vol.126 + まずスレチすいませんでした
こういうのをどこで質問していいかわからず、もし使ったことのある人がいるならこのスレかなと思いここにしてしまいました
どうにか解決したので報告だけさせてください
>>680
すごくヒントになりました
結局dllは不足なかったことがわかり不思議でよく考えてみたところ
wscriptのほうもSystem32のものではなく、SysWOW64の32ビットのものを指定して実行したところ問題なく使うことができました
わかってみたら単純なことでしたが思いこんでました
ありがとういございました JavaScriptの非同期の書き方がまだおぼつかないのですが
var defarr = [];
for(x of list) {
var d = new $.Deferred();
$ajax(...)
.done(() => { d.resolve() });
defarr.push(d.promise());
});
return $.when.apply($,defarr);
みたいな感じでAPIからデータをとってきて画面に非同期で順番に表示する
みたいな処理があるときに
途中で中断したいときどこにどういうコードをはさめばいいんでしょうか 中断の伝播とか真剣にやってるとやっぱり複雑になってきたときにバグるよ
手抜きして要素を非表示にしたりメインツリーから消したりして
表示までの処理は動いてるけど機能しない状態にするのが一番お手軽で安全 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属性でファイルパスで読み込んで
内部の関数を呼び出すにはどうしたらいいでしょうか? ライブラリ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 JavaScript の質問は、web制作管理板の方へ書き込んでください!
こちらのスレは、答える人が少ない
>>683
頼んでいた非同期処理を、中断・取り消すのか。
そういうのは、できるかな?
「javascript 非同期処理 中断」で検索!
>>685
「javascript require commonjs」で検索!
>>686
「javascript 動的 読み込み」で検索! >>687
document.onreadystatechange = function() {
if (document.readyState == "complete") {
$LAB (以下略)
}
}
ありがとうございました。これで動きました。 これほど書き方が統一されていない言語あるかね?
function書くだけなのにいくつもパターンありすぎ pythonは関数を書くときにdefとlambdaがある つまり未だにアロー記法を採用してくれないPHP最強ってことだな
何回function書かせるねん 打つのが面倒でないならjavascriptでも全部functionで通してもええんやで。
所詮(function () {}).bind(this)の糖衣構文に過ぎない。 入力補完でfunctionを打つのは楽だから、基本はfunction使う
アローより可読性高いから
ワンラインで済むときと、thisを受け継ぎたい時だけアロー使う mapとかfilterの引数もfunction渡すの?
複数行あるならともかく、一行で済むものにわざわざfunctionとreturn書くのは、可読性の観点だと逆効果のような >>695
> ワンラインで済むときと、thisを受け継ぎたい時だけアロー使う
> ワンラインで済むときと、 > 所詮(function () {}).bind(this)の糖衣構文に過ぎない。
糖衣構文って素晴らしいよね 念のため、素晴らしくないとは言ってないからな。
functionでも書けるから、そうしたいならどうぞご勝手に、という話。 アロー使ったら複数行でもreturnなしにしてほしい
最後の行の値を返せばいいだけと思うけど、難しいのかな むしろアロー関数は1行でしか使えないようにしてほしいくらいだ 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() ); エラーになるかどうか知りたいの?
コンソールに張り付けろよ var aaa = func1;
console.log( aaa.next() );
・・・
みたいに修正してから、やってみたら func2() 内の yield でエラーが出た。 function* func1() {
yield 1;
yield* func2();
yield 3;
}
function* func2() {
yield 2;
}
俺のESP能力が高ければこれが助けになるだろう。 >>706
それだと、func2() も generator function になるよね。
自分が思っていたのは、もし、普通の関数でも
yield が使えれば、JS でも、SetEvent() と WaitForSingleObject()
みたいな同期オブジェクトを作れるんじゃないかということだった。
そうすれば、wasm を使って、Windows プログラムも移植できるの
ではないかと思った。 >>707
それは何の為に?
WebAssembly(wasm)なら移植の必要すらなく動かせる(はず)だろ。
それ以前にGraalVMなんてのも出てきたみたいだが。
> JavaScriptだけでなくあらゆる言語をブラウザで扱えるように、GraalVMをChromiumにリンクすることを考えた学生が1人います。
> https://www.infoq.com/jp/news/2018/05/oracle-graalvm-v1
>>705
インタプリタがある言語(≒スクリプト言語)なら通常のデバッグ方法だ。 >>707
普通の関数でyieldが使えてもそれはジェネレータ関数ができること以上のことができるようにならないだろう
結局処理は同期的で待ち合わせには使えないのだから
async関数でというのなら分かるがそれはもうasync generatorがある やっぱ、数学ができない人にはわからないんだと思う。
ちなみにおいらは数学は主席。
今のwasmは、sleepはできるが、SetEventやMutex などを
待つことができないので、
>WebAssembly(wasm)なら移植の必要すらなく動かせる(はず)だろ。
これは違う。
すまんが、何度説明しても分からん人には分からん。
日本語の問題ではない。句読点の問題でもない。数学の問題なんだ。 WASMはもう実験的にSABとAtomicsサポートしてるでしょ
何を知ったげに言ってるんだか >>712
wasm は、emscripten_sleep(millisecond) をサポートしてるので、もともと問題の根は浅い。
でもあなたの言ってることはSetEvent()やMutex()などの同期オブジェクトとは直接関係
ない。それに proposal 段階で、実装報告は見当たらないんじゃないの。 【数学首席のオイラが書く(言葉の美しさは知らん)】
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の終了。
}
} >>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にはまだそれ
が整備されていない。 >>715
【修正】
void mySetEvent() // スレッドBが使うとする。
{
BeginAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの開始。
g_bEvent = 1;
EndAtomicFence(&g_fence); // あなたが言ったAtomic Fenceの終了。
} >>716
【修正】
誤:if ( !g_bEvent ) {
正:if ( g_bEvent ) { >>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の終了。
}
} >>719
【修正】
誤:// 以下ループで、CPUがフルパワー状態になり電気の無駄使いになる:
正:// 以下ループで、最悪100(ms)の遅延が発生する。 >>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) 待つ。
}
} いや、もうAtomicsAPIがChromeでオリジントライアルで使えるでしょ
もう解決してる問題に対して何をイキっちゃってんの
いくら数学の理論構成や計算ができようと意味はないよ
そんなのは機械でできることだから
正しい問題と前提を認識できて初めて数学という道具は有益に使えるんだから
君がやってるのはただ思考力の無駄遣い
まあ君の頭だからどう無駄に使おうと勝手だけど、スレ汚しは勘弁してね >>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() もこれらを使えば実装できてしまうだろう。 またWindowsのAPIに固執してるの?
いい加減に理解しなよ。Windowsとwebは無関係だって。 マルチプラットフォーム環境として、wasm や JVM や CrossBrdige(FlashCC) など
を調査してるから、Windowsアプリが移植できるかどうかに興味があるんだ。 Windowsアプリが移植できるかと、同じAPIを持ってる事は無関係だし、
事実同じAPIも持ってないよね。
なのに見立てる理由がわかんない。 基本的にLLVMに変換可能なプログラムなら移植できるけど
OS特有のAPIやライブラリ使ってちゃそりゃそのまま移植できるはずがない やっちゃおう、にどれだけ価値があるかわからんけどね。
そこまで言うなら、前回のIMEだって、やっぱりIMEを移植すべき問題じゃん。
同じAPI使うってのは、wasmでのWin32API互換ライブラリを作るって夢を語ってるって事なのかな?
簡単な道ではないと思うけど。
WINE何年かかってんよって話。 WasmでというよりJSででしょ
現状Web API叩くのはJSからしかできないのだから foo =function(){}とか
bar = ()=>{} とか
エディタがDocコメ認識してくれないことが多くてなあ… jsdocって言語機能が名前から想像するよりはるかに異なるjava用のjavadocの単なるメクラポーティングだしなぁ…
js用にもっと相応しいドキュメント仕様が普及してもよかっただろうに世の中うまくいかんのう… iframe要素のsrcを変更したら画像のロードが終了してからloadが発火すると思うんだけど
この間(画像のロードしてる間)にiframeのHTMLにcss挿入するのってどうしたらいい? >>733
src を変える前に iframe の style 属性を指定しておくのでダメであれば、
別に、タイマーイベントみたいなので、少し遅れてから、イベントハンドラ
の中から iframe の style 属性を変えればいいだけではないの。 エクセルのマクロとかすら使ったことがないし
数学も超苦手なのですが
プログラムを始めてみたくてウズウズしてます。
仕事で使ってる動画ソフトが
javascriptでスクリプトを追加できるので
java scriptをはじめてのプログラムとして始めてみたいのですが
何から揃えればよいのでしょうか? >>738
確かに。
冗談のようだけど重要だな
Chromeなど開発モードがあるブラウザを使い、それの操作方法に多少は馴れておけって意味では 知識0なのに実用的なプログラムから始めるのは間違っている
HTMLを学んでてそこに動きを付けたいとかいう段階的な目的とステップがあるなら別だけど
マクロとしてのJSを学びたいのにWebに手を出すというのは無理筋
基本的に勉強用の非実用言語環境でできれば配列くらいの知識まで身につけといてから
Webとか手を出さないで直接マクロに行かないと絶対に挫折する マクロとしてのJSって何だよ・・・・
やりたいこととしてはブラウザよりNodeの方が向いているとは思うが いや、もうやりたいことは決まってるでしょ
いくら比較的余計な知識が要らないとは言え
NodeでのJS入門環境が充実してるわけでもないのに webpackで依存関係が数百とかなってわけがわからなくなる みなさんありがとうございます。
「なにかゲームしたい」くらいな感覚でプログラムをやってみたいと思ってました。
必要に迫られて始めたいわけではなくて
暇なときにテトリスする代わりに
クネクネ動くhello worldを作ったり
自分で使うようのアプリとか作れたら楽しそうだなと思った次第でした。
今は小さくて安い小型パソコンがたくさんあるのでそういうパソコンで
暇な時にシコシコプログラム作れたら
すごく楽しいんじゃないかと
ついでにJs覚えれば仕事の動画編集にも活かせそうだしなんか良いかなみたいな感覚でした。
htmlもかじってみようと思います。 Excelの表をGraphqlに変換することは出来ますか? >>748
続き
横幅やセルの色や結合までGraphqlでもっていけたらいいなぁと思うんですが・・ 質問です。下記のようなプログラムで、'テスト'を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'
}; >>748
gatsby-transformer-excelあったと思う >>746-747
メソッド一覧とかプロパティ一覧、関数一覧のページはMSDNのほうが見やすかったから
索引的なページは残しておいてほしかった
エディタのマクロ書くときなんかはMSDNのほうが都合よかったので残念 Electronでクロスプラットフォームのアプリ開発の出来ることを知ったプログラミング初心者ですが、一般的なElectronの開発はVue.jsやReact.jsを併用するのでしょうか? もうElectronは古い
今からはできる限りPWAでやる風潮 React学ぶのにオススメのチュートリアルや本ありますか? 本は薄い奴が今のところ比較的新しいけど、残念なことにそれでも情報が古いからGithubのreadmeとか見ないとダメ
その本に書かれているライブラリはもう開発停止していたりするから
ReactよりもReduxのほうが大変かもね >>758
Q. ○○を学ぶのにオススメのチュートリアルや本ありますか?
A. 公式
JavaScript界隈の場合はほぼ全部これ。
公式読んで無理なら諦めた方がいいと思う。当然だが、
1. JavaScript界隈の場合は布教意識ありまくりで公式がかなり充実している。
2. 公式は対象技術レベルを想定して書かれている=読んで無理ならどうせ使いこなせない。
3. 公式以外は「ぼくががんばったきろく」を残したい馬鹿ばかりで、間違いが多すぎる。
4. そもそも普通の奴は「ぼくのさいこうのチュートリアル」なんて作らない。
公式のチュートリアルを充実させる方向に参加する。したがって当然非公式サイトはおしなべてゴミ。
5. 本を書いている奴は本で食っている=一線のプログラマではなくただのテクニカルライタであり、
売れない本は書きたくない。よってどうしても後追いになるし、技術レベルも低い。
6. JavaScriptの場合はフレームワークonフレームワークの状態だから、
はっきり言って、構想を聞いて「あ、いいね」とぱっと思えるのでなければ使う必要がない。
だから本来、対象者にはリファレンスしか必要ない。Nodeとかそんな感じでしょ。
というか、自分が知ってるフレームワーク等と比べてみたらいい。
例えばjQueryを使っている奴は公式トップの3例を見て、「素晴らしい」と思えるから使っているわけだろ。
Nodeの場合は公式トップは空で、aboutで鯖を立てる例だけ出しているが、魅力のアピールにはそれで十分なわけだろ。
同様に、reactの場合も公式トップの4例で十分だと思っているからあの構成な訳で、
それで魅力を感じないのであれば使う必要はないし、意味が分からないのなら使いこなせない。 「Reactを学ぶ」とかワケワカランな
スマホだってなんだって説明書見て使ってれば自分にとって十分使いこなせてるでしょ
「Reactのプロ」になる必要なんてないんだから
ただ道具の一つとして自然に使っていけばいいだけ 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') }}};
}
}, >>762
・・・
emscripten_sleep: function(ms) {
Module['setAsync'](); // tell the scheduler that we have a callback on hold
Browser.safeSetTimeout(_emscripten_async_resume, ms);
},
・・・
} 以下の前提がある時、
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;
}
} [何をやってるかの自分なりの推定]
例えば、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] と書くことで、該当のスタックの近くにアクセスできるらしい。 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]; 単純にスタックを切り替えて該当処理を再開できるようにしてるだけじゃん >>768
おいらは数学主席だが、そんな単純じゃない。
もっと非常に複雑なことをやってる。
>>765
その情報は助かった。自分一人では数ヶ月間は気付く事は出来なかったと思う。 >>768
asm.js は、JSの「subset」とされる。だから、JSでサポートされてないことは、
asm.jsでも本質的には出来ない。JSは、
・sleep()関数が存在せず、wait()関数も今のところサポートされているブラウザが
かなり限定されるので、原則的には、関数の途中で無限ループ以外では停止する
ことは出来ない。
・関数callを使わずに、アセンブラの単純な(大域) jmp のようなことは
出来ない。だから、スタックポインタだけを元に戻しても、命令ポインタ(IP)
を元に戻すことが難しい。
・LLVMでも、原則的にはコードは個別の関数としてだけ作ることが出来て、
関数の外にコードを書くことはおそらく出来ない。
・ただし、LLVMの場合は、longjmp やスタックポインタなどのサポートが
色々と有るのでそのあたりを利用すれば何らかの方法があるかもしれない。
・だから、Emscriptenのemsripten_sleep()は、非常に高度なことをやっており、
「待ちたい時」は、いったんそれまでの呼び出し連鎖の全ての関数を逆に戻って、
「システム」にまで戻る。原則的には、全ての関数は、なんらかのイベント
からスタートしているので、これは、イベント・ハンドラの処理をいったん
終了して、ブラウザに制御を戻すような事になる。
・一定時間が経過すると、設定しておいたresume用のハンドラがシステムによって
起動されるので、そのタイミングで、呼び出し連鎖の全ての関数を再度、
「再起動」する。この仕組みを使わないと「EIP」を元に戻すことが出来ない
ためである。なお、スタックポインタについては、独自のグローバル変数を元に戻す
だけで済む。スタック自体は、巨大な「配列」をCPUのメモリー空間のように
して、スタックポインタに該当する変数を配列の添え字としてアクセスするような
事をしている。 >>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 にはそれがないためである。 JSも、全てのコードを一つの関数の中に収めてしまって、
continue label 文や break label 文を使えば、好きなラベルに
jmp 出来る気がする。
もしそうだとすれば、関数の戻り値のラベル番号も、独自スタック
HEAP32[STACKTOP + ofs/4] に保存し、関数 call は、
JS の関数 call を使わずに、continue label / break label
を用い、関数から戻るときは、HEAP32[] から、戻り値の
ラベル番号を取得して、そのラベルに continue label または、
break label を使って jmp すれば、もっとすっきり実装してしまえる
かも知れない。 sleepは全然複雑じゃない
CPUを例に出すのは大間違いsleepしてもその間に別の処理が走るわけではないのだから
スタックの切り替えだなんだのは必要ないしやっていない
ただ処理ループを一旦抜けてsetTimeoutで待って再開してるだけ > CPUを例に出すのは大間違いsleepしてもその間に別の処理が走るわけではないのだから
JavaScriptでsleepを実装すると「その間に別の処理が走ってしまうから」
それを妨害するのが大変なんでしょ >>775
だからそれsleepじゃないよ
sleepはその場で停止して(他にスレッドがないならば)
他の処理に割り込まれないという特徴がある
それを実現できてない >>776
おまえがsleepを分かってないことは分かった >>770
どうもアホがいて空回りしそうだから先に言っておく
> 原則的には、関数の途中で無限ループ以外では停止する
> ことは出来ない。
これがasync/awaitで構文的に緩和されてる。
勿論それでもシングルスレッドだから、
実行中のコンテキスト(スタック等)の切換は行わなければならないが、
async/awaitをサポートした時点でそれはJSエンジン側の仕事になってる。
emscripten自体はasync/awaitの標準化以前から存在するから、
その部分が結果的にポリフィル的になっているのは致し方ない。 >>774
妨害してないよ
正確にはビジーループに変換されるsleepもあるけど動作には関係ない
なぜなら複数スレッドの処理が実際の1スレッドで動くよう変換されるわけではないから
むしろメインスレッドをブロックしないためにsetTimeoutが使われてる
その間に別のJSが動こうとそれは世界が違う話なので関係ない >>778
async, await はダメだよ。
停止せずに素通りしてしまうから。
戻ってくることは出来るけど、async 修飾したその関数にだけしか
戻って来れないので、sleep には使えない。 >>780
お前が馬鹿だということは分かった
つかマジな話、お前らsleepを全く理解してないな ただそれ以前に、emscriptenは要するにC++→JS変換してくれるわけで、
sleepも当然サポートされていてそれなりに変換されてるだけだろ。
馬鹿なら馬鹿なりにそれを有り難く使えばいいだけだと思うが。
お前らのオレオレ実装よりは数段マシだと思うぜ。 いくら天才でも正しい前提知識を持ってないんじゃ仕方ない 10000ms指定したらUIが10秒止まるクソ関数が作れるなんて聞いた事ないし
簡単に作れちゃったら困る >>782
>sleepも当然サポートされていてそれなりに変換されてるだけだろ。
バグがある。 どういうときにどう上手く行かないのかを言ってくれないとな そんな知能なさそうだし。
sleepなんて昔から話題としては出尽くしていて、ググレばいくらでも出てくる。
それを出てこないと言いきる辺り、つまりはコードクレクレ君で、コピペプログラマ以下だろ。
(ググったコードについても読めないからコピペすら出来ない) また数学首席くんが妄想してんの?
いい加減自分が向いてないって気づけば良いのに。 こいつはスルースキル特化型だな。
俺はスルースキル・モンスターと呼んでいるが、最近このタイプは増えてきている。
危険な兆候だよ。 >>794
「スルースキル・モンスター」を説明してください canvas の width や、グラフィック描画時の座標指定が、ブラウザの拡大率を
100%にしても、実際の画面のピクセル座標とは違っている。
<meta name="viewport" content="width=device-width, initial-scale=1">
を指定しても駄目だった。ぴったり同じにする方法ある? 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 で、確か、文字を大きめに表示する設定にしてある。 canvasの内部的な座標とcanvasのelement的な座標の比で調整するのじゃダメなんかい そもそもピクセルが正方形とも限らないわけで
デバイス、ドライバ、OSが順に抽象化したあと更にブラウザが抽象化したものが
Webアプリからは見えるのでそこをどうこうしようとするのはナンセンス
それでもどうしてもどうにかしたいというのなら
devicePixelRatioやrenderedPixelWidthを元にその文だけCanvasをCSSで縮小してみるとか 色々試して、以下のようにすると、ほぼ 1px = 物理 1 pixel になった。
こんな方法でよい?
<style>
#div0 {
transform: scale(0.8); // 1.0 / 1.25
transform-origin: top left;
}
</style>
<div id="div0">
実際に表示したいタグ達
</div> それでいいけど
単純にwidthを表示の1.25倍にしたらどうなるのかな 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」という言葉
と合ってるようには思えないんだけど。 >>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 の左上の位置を自動的に調整(縮尺)してくれるが、
今回のやり方だと、それは自分で調整しなくてはならない。 >>804
あ、確か逆さまだったと思う。
だから、
誤: <canvas width=aaa style="width:bbb;">
正: <canvas width=bbb style="width:aaa;">
が確か正しい。 >>805
だから、確か、
canvas.width = 物理的な横方向のドット数;
canvas.style.width = 論理的な横方向のドット数;
だったと思う。 webページでフォーム入力した項目を確認のために埋め込まれたような形で一旦表示させたいんですけど、こういうのはJavaScriptで実装するんですかね?
どうググったら、ここら辺の情報取得できますかね?
自分、pythonしかできなくて、フロントエンド的なところは全然わからないです。。。 javascript使う
vue.jsとか使えば楽 >>808
そもそも何を表示するの?
フォーム入力した項目って最初から見えてるだろ。 >>808
まず現状フォームをどうやって表示してるのか
サーバーサイドPython?
入力フォームなら値をPOSTで受け取ってるだろうから
確認画面を生成するだけなのでは フロントでvaildateしてユーザーに伝えたいという意味と解釈したけど違った? >>809 >>810 >>811 >>812
イメージとしては、5chのこの投稿欄みたいにフォームに入力した後に、
入力事項が画面に埋め込まれて、下のあたりに「投稿」のようなボタンが出るイメージ
確かにPOSTで受け取った内容を生成すればいいだけか...笑
サーバサイドはpythonです。
JSでもできるけど、その場合フォーム入力の内容をDBのデータと比較検証したい場合
には不向き、ということになるんですかね...? >>813
あるサイトと同様のものをJavaScriptで得たい場合、F12を押してコードを見るのが一番早い。
つっても2chなんてゴミなので、参考にするならもうちょっとましなサイトの方がいいが。
DBと照合したいのならサーバーサイドで、君の場合はPythonでやった方がいいと思うよ。 >>814
なるほど!
どうもです!ありがとうございます! > あるサイトと同様のものをJavaScriptで得たい場合、F12を押してコードを見るのが一番早い。
そうとは限らない。今のJavaScriptは圧縮などかけられてるから
見た所で意味不明というものがたくさんある >>809
> vue.jsとか使えば楽
vue.jsの出番なし(笑) >>819
それはある意味真実。HTMLとCSSだけで殆どのことができますっていうのが理想 >>803
dirty の意味は、汚染されている事。
つまり、Canvas のデータの事だろ
一度でも、Canvas に描いたものは汚染されるから、JavaScript のデータには戻せない。
ブラウザのセキュリティ機構をパスしていない ちょっとググった限りでは、refreshしないといけない部分だからdirty rectangleと言われるようになった感じ? dirty bitとかのdirtyと同じ
ただ「描き込みがされる、変更がされる」という意味なだけ どうやったら習得できるんでしょうか?
授業だけでは全然習得できませんでした
jQueryをコピペするだけしかできません
教科書書き写せって言われたのでしていますが
タイピング練習している気分で、1行1行
何かいてるか理解できていません
読めないから見るのも嫌になってます
初心者の時に何やってたか教えてください >>825
> 授業だけでは
> 教科書書き写せって言われたのでしていますが
どこでどういう風に習ったんだ?
JavaScriptは比較的簡単な言語ではあるが、
授業で習った程度で出来るようになると思っている時点で大間違いだぞ。
ズブの初心者が数時間で出来るようになるのなら、専門職として成立しないだろ。 あと、どこを目指している?
Webデザイナになりたいのなら、そんなもんで構わないとも思うが。 コピペして必要になったら理解するための勉強すればいいんじゃね
それだと基礎ができてねえとか言われるしクソコードになるけど
基礎勉強していてもどうせクソコードと言われるんだしな 詐欺プログラミングスクールの何週間でプロに、とか3ヶ月でマスター全部ウソだから。
宗教ビジネスとかに近いやり口だよアレ。規制・逮捕・投獄すればいいのに。 >>825
読めないし意味がわからないのは当たり前だし
それをどうこうする方法もない
新しいことを学ぶというのは非常に困難なことだと理解しろ
数学や国語だって頭の柔らかい子供がきっちり何百年もかけて練られた
体系立てられた教育で10年以上もかけてやっと習得できるものなんだぞ
つまりざっと1000時間は必要ということだ
もちろん1000時間かけても分からない人も居る
でも自分の頭を信じて、わからないものが分かるようになれると信じて
いやいや苦しいながら1000時間頑張る以外無いんだよ
とりあえずチュートリアル的なサイトを最初はコピペから一通りやる
そのときにちょっと改変してみたりしてどう結果が変わるのかから
それがどういう意味をもつ行為だったのか、そこがどういう効果をもつ部分だったのかを理解していく
意味が分からないことが100出てきたら、ググり倒してなんとかそれを99にするよう必死に努力する
多少程度分かるようになってきたらもう一度MDNのような網羅的に載っているとこをみて自分が知らない知識を仕入れる
構文やAPIは別に暗記する必要はない こういうことに使えるものがあるということをできるだけ知っておく
その繰り返し つまり基礎と応用を行ったり来たりして
段階的にではなくまんべんなく少しずつ積み重ねていき、ある時からはその穴を埋めていく
基礎はだいたいわかったと思ったら、ググって他人の書いたコードを見る
そうすると自分の知らない書き方や機能が使われていて、しかも非常に読みにくい
でもそれに慣れていく
もう一度MDNを全部隅から隅まで必ず読む
JS再入門をやってみる それで中級者
各構文の詳細をきっきり理解し、スコープチェーンやプロトタイプチェーンといった概念を学び
今まで何となく書いてきたものの真意を理解する
構文やAPIを仕様書を直接見て理解できるようにする
基本的な仕様書を一通り必ず読む それで上級者
そっからは自分の好きなコミュニティに所属して深掘りする >>825
初心というか、新しいことを始めるときにはだいたいこんな感じ。
1) 適当に検索して必要な部品をコピペする
2) コピペ同士の整合性確保と自分の美意識に従って整形する
3) 時間が許す限り 2 を繰り返す
4) 試験する
整形するところで、たとえば未知の関数ならその役割や必要なパラメータを理解する必要があるし。
コピペを適当に順序を組み替えてみると予期しないエラーが生じることもあるから、その原因を調べることで理解が深まったりするし。
要は好奇心が自分を動かしてるんだろうな。そりゃ打ち込みだけなら眠くなるだけだわ。 たくさんのレスありがとうございました。
ちょっとやる気出てきました
が、道のりは険しそうですね
webの専門学校の授業でhtmlとcssを学び
ページは作れるようになったものの
javascriptはよくわからないまま授業が終わり
今はphpを覚えさせられてる段階です
3ヶ月ぐらいです
授業は教科書一冊を前から順番に終わらせた感じですが
先生はcssで出来るなら無理にjavascriptを使わなくて良いって言ってました
先生も他の言語が得意みたいで、あまりjavascriptは詳しそうな感じではなかったです
jQueryはどんなライブラリがあるのかを知り、
それを確実にコピペができることが大事って言われたのですが
コードが読めないjQueryをコピペするのはあまり面白くありませんでした
目指してるのはwebアプリとかゲームとか個人で作りたいです
javascript(Vue.js)とphp(laravel)を覚えてアプリを作ろうと考えています
将来グーグルアプリやアップルストアに置いたりしたいです
MDNは先生もおすすめしていますが
難しすぎるのと、同時に画面表示すると作業しにくいので本を書き写しています
まだ寝るまで時間あるので引き続き書き写ししようと思います
クラスで取り残されてて、あんまり質問できない空気なので
意見もらえて勉強になりました >>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だけで出来る。
だから今すぐゲーム作りに着手しろ。最初は○×ゲームやオセロ等で構わない。
プログラミングなんて手段でしかないから、結局のところ、モチベーションが上がらないと上達もしない。
写経の際にいじくり倒して快感を得られるタイプなら写経も効果あるが、
君の場合はそうではないのだから、写経は時間の無駄だ。
一応の知識は揃っているはずだから、君は今すぐ君がやりたいこと、例えばゲームを試しに作ってみることだ。
そうすれば、今の自分に何が足りないか分かるだろうし、そこを先生に聞けばいいんだよ。
折角金払って専門学校に行っているのだから、先生をうまく活用した方がいい。 ちなみに、今時のPCで2画面出力出来ないのはほぼあり得ないし、
TVが有ればHDMI端子がないのもほぼあり得ない。
そして、線をつなげば割と自動認識していきなり2画面になるという安直さ。
まあ、TVが有ればやってみ。 詳しくありがとうございます
クラスではipadを見ながらやってるって人がいて
うらやましいと思ってましたが、2画面って方法があるんですね
勉強のためにバイトやめてしまったので今お金がないです(T_T)
お金でき次第買います
今すぐ、ゲーム作りですか?
見た目を用意するのはhtmlで出来そうですが
参考書でも買わないと作れないですね
作りたいゲームはあると言えばあるので
明日本屋で見て、できそうならやってみます >>836
> クラスではipadを見ながらやってるって人がいて
それと同等にはなる。
スマホだとさすがにきついと思うから、安物でいいからモニタを買った方がいい。
つか、専門学校なら最初から2画面にしとけよ、とは思うが。(君が悪いわけではないが)
> 見た目を用意するのはhtmlで出来そうですが
それでいい。
見た目だけ、例えばオセロならまず盤面をHTMLで用意するところから始める。
次に、クリックしたら石をおくようにする。つまりはクリックしたところにクラスを加えるだけだが。
そしたら、後は、「挟んだ石は自動的にひっくり返る」ようにすれば、手動での対戦は出来るようになる。
そして後はCPUで適切な手を考えられるようにすれば、CPUとの対戦が出来るようになる、というわけだ。
これ読んで大体「オセロなら出来そうだ」と思えるか?
なら、もう十分だから、アイデアもあるようだし、それに取りかかった方がいい。
やらないと上達しない。やる為には、自分がやりたいことをやるのが一番いい。
本を買う必要は無いとも思うが、まあ思うようにやればいい。 ただゲームを作りたいというだけなのに練習にしろ本番にしろ
HTML/CSS/JSのセットを学ぶ必要性はない
Google Blockyやプチコンのようなもので学んだほうが良い HTML/CSS/JSのセットを学ぶことは無駄にはならんよ。
今後のGUIの主流になりつつあるから。
ただ、ゲームを作りたいだけならオーバースペックだ、というだけで。 あとその手の「初心者でも子供でも簡単に出来る」って奴は大概すぐポシャるので俺は勧めないね。
scratchが一時期言われてたけど、今全く聞かないでしょ。
何故プロがそれらを使わないのかを理解出来ないうちは、所詮その程度って事だよ。
専門学校はプロ養成予備校みたいな位置づけだし、今ならHTML/CSS/JavaScriptで妥当だ。
当人は「学ばないと出来ない」という感覚なのか、出来ない理由を探しているから、
そうではなく、出来るところから始めろ、というだけ。
JavaScriptはコミュニティが腐っているが、言語としてはまあまあだよ。
そこで上達出来るかは本人次第だ。
とはいえ、初心者だと雑音を雑音と認識することも難しいから、難儀な話ではあるが。 このスレはじめてきたけど、上の方でjQueryをやたら推してる人って頭おかしいの? jQuery推しがおかしいかおかしくないかはどうでも良くて
それに論理的に反論できないならば、言ってることは正しいってことさ えっ、jQueryおじさんが反論を理解できていないだけじゃないの? 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 >>843
× 反論を理解できていない
○ 何も理解出来ていない shadow-root(attachShadow)って何ができるの?
ふつーに要素を作るんじゃなくて使うってことは何かできることがあると思って jQuery使わない人の声だけがでかいのはわかる
javascriptフレームワークなんて誰も使ってない 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 > 実際はじきに結論がでるから待てばいい。
いつでるんだよ・・・もう3年経ってるぞ >>852
>>369
俺は堂々巡りの話はもうやらない。
jQueryと心中するのも、脱jQueryするのも、自由。
それぞれが自分が正しいと思う方向に向かって進めばいいだけ。
シェアを過度に気にするのは、自分で判断出来ない証拠。 シェアを気にしてるんじゃないんだよ。合理的な判断から。
ウェブの大半を占めるウェブサイトを作ってるのはウェブデザイナーが大半で
ウェブアプリを開発してるのはごく一部。そんなところにプログラミングが主である
React、Angular、Vueが普及するわけもなく、殆どは軽い使い方しかしてないんだから
jQueryで必要十分だってこと
シェアは単にそれを証明している指標に過ぎない これからはBackboneや!
これからはEmberや!
これからはKnockoutや!
これからはAngular1や!
フレームワーク使ってるほうが死亡してるんだけどな >>854
サイト数で言えば「ドキュメント」が多いだけで、
トラフィックの大半は「アプリ」ないしはニュースサイト等の「軽量アプリ+DB」だよ。
つかそれ前にも言ったけど、お前普段どんなサイトを見てるんだよまじで。
とりあえず単純に定義しておくと、以下な。
アプリ: ajaxやPOST使いまくり
軽量アプリ: POST機能はあるが主ではない
ドキュメント: ajaxやPOSTは全くない トラフィックの大半は映像、JavaScript関係ないがな
世界のインターネットトラフィックの過半数を「映像視聴」が占めている
https://gigazine.net/news/20181003-global-internet-downstream/ >>858
ああ、まあそりゃそうだ。
ただ、その手のサイトは普通「アプリ」だと思うぞ。
が、まあ、それなら、ダウンストリームを除いて、アップトラフィック、で測るべきだな。
回線速度サイト等で言う、「上り回線」内のトラフィック数だ。
(映像視聴中もping的なアップトラフィックがあるのは知っているが、それらは除いて) >>857
ならお前がもっと『ここでの議論に適した』いい定義を出せばいいだけの話
お前らゆとりはそういうところが駄目なんだよ >>859
連想ゲームやってるんじゃねーんだ
トラフィックが多いのは映像
映像はアプリ
アプリはJavaScriptを使ってる
だからトラフィックが多いのはJavaScript
違うからな。
ゲームで考えてみろ。多いのはデータであって
プログラムじゃねぇ >>861
バカなのかお前は。
話が見えてないなら読み直せドアホ。 LayeredAPI使って帯域節約していきましょうってことでしょ list.map(x => new Hoge(x))
これを
list.map(Hoge)
みたいに書きたいんですが出来ませんか?
staticでファクトリーメソッド実装するしかない? >>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}] >>867
class Hoge {
constructor(x) {
this.x = x;
}
}
function foo(Hoge) {
list.map(Hoge);
}
foo(x => new Hoge(x)) Ruby では、: で始まるシンボルで、メソッド名を渡すことで、インスタンスメソッドを呼べる
# 数値に変換してから、配列内のすべての数字を足す
puts numbers.map(&:to_i).inject(:+) 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の &:: は極めて驚きが大きく醜悪な機能の一つだね >>871
> Ruby では、: で始まるシンボルで、メソッド名を渡すことで、インスタンスメソッドを呼べる
シンボルってただの文字列と変わらないからね
定義しなくて使えるから、タイポしてもエラーになるわけじゃないし >>867ですがいろいろとありがとうございます。
list.map(Number)ができるならlist.map(Hoge)もできるんじゃないかと思ったのですが、一筋縄では行かないようですね
おうちゃくせずに素直に仮引数つけます 昔はコンストラクタがただの関数だったから、class構文にしなきゃできるな
es5にトランスパイルすればいける >>875
なるほどね。何のこっちゃと思ったがそういうことか。 コンパイラエラー 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 >本当にありがとうございます!!!!!!!!!!!!
>キモヲタ万歳!!!!!!キモヲタ役に立つ!!!!!!!!
この質問者は、荒らしだから、無視しろ! >>875
いや、できないだろ
普通に読んだらthisがインスタンスとならないのだから Hogeの方で工夫するのならスタティックメソッドを生やすのとえっと変わらんじゃん
もしくはHoge.aryFrom(list) みたいなの用意してもいいんだし はは、Rubyじゃあるまいし、カッコつけないと
関数呼び出しにならないのに、どうやって場合分けするっていうんだ
はは 関数形式で呼ばれたか、コンストラクタとして呼ばれたかで分けるってことだよ
昔みんなやってたじゃん
>>882
そうだよ。変わらんよ。だからどうしたって話だし >>884
そう書いたんだが、全く伝わってなかった > list.map(x => new Hoge(x))
> これを
> list.map(Hoge)
> みたいに書きたいんですが出来ませんか?
Hogeのどこが関数なの?
関数っていうのはHoge()ってやらないといけないんだよ?
ほんとうに情けないんわ const double = n => n * 2;
[1, 2, 3].map(double);
//=> [2, 4, 6]
ワロタwww
>>886によるとこのdoubleは関数じゃないらしいw
double(1)みたいな呼び出しじゃないからだってwwwww class Hoge {
constructor(x) {
this.x = x;
}
}
console.log(typeof Hoge);
//=> function
> Hogeのどこが関数なの?
wwwww >>888
お前はこの意味がわかってないんだな
> 関数形式で呼ばれたか、コンストラクタとして呼ばれたかで分けるってことだよ
list.map(Hoge) のHogeは
関数形式で呼ばれたか、コンストラクタとして呼ばれたか
どっちか言ってみ そんな雑魚レス見てないし関係ない。
> 関数っていうのはHoge()ってやらないといけないんだよ?
これは恥ずかしい誤りwww
反例
[1, 2, 3].forEach(console.log) spanやdivのクリックイベントを、buttonと同じ要素に出来ないでしょうか?
コンソールでイベントを確認すると、currentTargetが
divはHTMLParagraphElementで、buttonはHTMLButtonElementになっています。
CSSでdivタグをボタン風にしていることもあるので、
Javascript上でもボタン扱いしたいのですが、書き方次第で変更できるのでしょうか? >>890
なんだ?お前重箱の隅ばかりついて、
関数形式で呼ばれたか、コンストラクタとして呼ばれたかで分けても
元の質問者の希望である
list.map(Hoge) とはかけないってことに
まだ気づいてないのか? >>891
$('span, div, button').click(function() {
console.log(this);
}); >>891
同じHTMLElementだというのがOOPの考え方
ただしHTMLでは徹底出来てないから要注意だが
とはいえ、実際同じとして扱って書いても問題なく動くはず
やってみてから言え >>891
> CSSでdivタグをボタン風にしていることもあるので、
> Javascript上でもボタン扱いしたいのですが、書き方次第で変更できるのでしょうか?
そもそもdivタグをボタンにするのが間違い。
そこにクリックできるボタンがあるのなら、ボタンで作るのが正しい
見た目はCSSで変える。何がほしいか?ボタンがほしいならボタンを使う。それだけのこと >>891 アクセシビリティ上の問題があるから >>895 の意見に同意
素直に button 要素なり a 要素なりを使っとけー >divはHTMLParagraphElementで、buttonはHTMLButtonElementになっています
多分どちらも、HTMLElement から派生したクラスじゃないの?
Vue.js では、ルーター用のリンクを、<a> タグ以外にも変えられる
<router-link to="/foo" tag="li">foo</router-link>
<!-- 以下のように描画されます -->
<li>foo</li>
tag="button" で、ボタンにもできる >>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とかで可能なら一番なのですが・・・ そもそもJSにdivをbuttonとして誤認識させた後に何をしたいのかがよくわからないけど、どうしてもHTMLButtonElementにしたいってのが目的ならそういうコンバーターなり何なりを作るしかないんじゃないの >>899
意味不明。初心者が馬鹿やろうとしてるとしか。
JavaScriptも24年の歴史があり、広く使われているのだから、
初心者が思いつくようなところで今更困ることはほぼ無い。
それはやり方を間違えているだけ。
多分CSSについて勉強した方がいい。 この世にIEという存在がなければそんな変なことは考えないのですが、
IEの利用者がまだいてbuttonのクリックイベントと、divのクリックイベントでは
差異があるので、なんとかしようと考えた次第です。
とりあえず「簡単にはできないし、まず無理」という結論であればそれを受け入れます。 >>902
馬鹿乙
IEなんて大昔からあるだろ。
それが本当に必要なら、誰かが既に開発して、それこそjQueryにでも搭載されてるよ。
無い=要らない、ってことなんだよ。初心者ならやり方を間違ってるだけ。 挙動を統一したいならCanvasでやれ
そういうフレームワークも増えてきてる またcanvasおじさんが湧いた
>>899
ボタン要素でスタイルシートでお好みのデザインに合わせればいいよ カード型みたいにボックスの中に画像、タイトル、アイコン、とかいろんな要素があって
そのカードがボタンの役割をしているならdivでもいいんじゃないの?
むしろbuttonタグの中にdivやらspanやら、iとかいろいろ要素ぶっ込むものなのかね? >>899
UIだけなら、CSSでボタンライクではないようにも変更できるわけでdiv要素を使う理由はない >>907
Enterキー押下時のclickイベント拾わない話じゃねーかとエスパーしてみる
それは他のブラウザでも同じなので、keydownイベント拾ってEnterキーだけ抽出してclickイベント時と同じ挙動をさせるしかないよね
shift/alt/meta/ctrlキー同時押しはもちろん排除するとしてさ >>909
それだけなら、tabindex属性付与だけで実装可能ではないか?
ボタンの何をエミュレーションしたいのかがわからん、には同意 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);
}
これがソースコードの一部です。
このソースコードで、「おい」と打ったら「オイオイオイ」と返ってくるのですが、
「あいうおいえお」と打ったら「あいうおいえお」と返ってきます。
本当は「あいうオイオイオイえお」と返ってきてほしいです。 if(json.text == 'おい'){
json.text = 'オイオイオイ'
}
上記の部分を
json.text.replace('おい','オイオイオイ')
にしたら何も表示されなくなってしまいました。 >>913
だされた課題は自分でやれ
どうせ本当に出された問題は
「以下のコードをreplaceを使って書き直しましょう」
なんだろ?
答えを聞くな >>914
違います。
課題は課題なんですけど、
課題内容は「リアルタイム通信を使用してアプリケーションを作ろう」です。
課題の一部がどうしてもわからないので聞いています。 replaceってヒントを貰ってるんだから、replaceについて調べればいいだけ >>917
おい、おっさん。
こんな時間に即返信するとかなにやってんの?ニート?w
お前は「答えない」じゃなくて「答えられない」だろw
無能のくせにでしゃばるなよww # 詳しい人、知恵を貸してくれ。
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);
} 長ったらしいので翻訳。まず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');
}); できたぞ、質問に答えられないバカ
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);
}
}
じゃあな無能 一行で書けるけど、じゃあなって言われたな。じゃあなwwww >>899
ボタン部分だけのクリックじゃなくて、
もう少し範囲を広くして、ボタンを含む、div で、クリックイベントを動作させたいのかね?
ボタン部分だけだと、範囲が狭くて、うまく押せない人がいるから
それと投稿者は、次に投稿する際に、名前欄に最初の投稿のレス番号を入れてくれ >>918
>おい、おっさん。
>こんな時間に即返信するとかなにやってんの?ニート?w
>お前は「答えない」じゃなくて「答えられない」だろw
>無能のくせにでしゃばるなよww
>>911
も、同じID。PNnv4t9U
こいつは、いつもの荒らしだから、皆答えないように! >>920
web の質問は、こちらの板ではなく、web制作管理板の方へ書き込んでください! >>921
それ、無料レンタルサーバー Xrea の Affiliate だよ。
結局、body 要素に、position: fixed; top:0px; を付けたら直った。 >>922
var result = json.text.replace('おい', 'オイオイオイ') >>930
それを複数個作るとエラーが出るんです。 >>931
var result = json.text.replace(/おい/g, 'オイオイオイ') ES6で新たに導入された式や文は
ES5.1の構文糖衣と考えて良いの? >>935
> ECMAScript 2015 で導入された JavaScript クラスは、
> JavaScript にすでにあるプロトタイプベース継承の糖衣構文です。
> クラス構文は、新しいオブジェクト指向継承モデルを JavaScript に導入しているわけではありません。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Classes クラス構文だと関数で呼べないから違うものを導入してるよね 糖衣構文かどうかにこだわるのってなんでだろう?
マウント取りたいだけな気がする >>936
よく読め
それはモデルとして、つまり抽象度の高い概念としての話であって
実際にES5で書き換えられるわけではない なんかそもそも糖衣構文という言葉をわかってないやつがいるみたいだ
糖衣構文の条件
× ECMAScript 2015で書いたのと同等のことを、ES5で(複雑に)書けること
○ ES5で書いたのと同等のことを、ECMAScript 2015で(シンプルに)書けること
>>939
お前変換の向きが逆 それは絶対に違うね
新しい構文というのは問題を新しく解決する為に入れられるわけで
古いコードで書いてたコードがシンプルに書けるようになるものでない方が珍しい
そんな事を語っても仕方がない
古いコードで再現できるかどうかの方が意味がある また意味不明な
新しい構文の中で従来では複雑な書き方だったものを
シンプルに書けるようにしたものを特別に糖衣構文とよぶんだろ
誰が新しい構文はすべて糖衣構文って言ったんだ?
誰も言ってないだろ シンタックスシュガーがあるならシンタックスヌガーとかシンタックスハニーがあってもおかしくないよね >>942
度合いの問題だ
「ほぼシンプルに書けるようにすることが目的で導入されたもの」を糖衣構文と呼ぶのは分かる
ほかの要素を無視できるという意味での「ほぼ」だ
そうするとそのほぼというのは例えば感覚で8割〜9割としよう
しかしClass構文でのその目的、重要度はせいぜい6〜7割だということを言ってる
Class構文は従来__proto__を使わないとできなかったスタティックとプロトタイプメソッド両方の継承ということができる
これが俺にとって重要度・構文価値の〜1/10
さらにnewTargetの存在によりビルトインクラスの継承ができるようになった
これが俺にとって重要度・構文価値の〜3/10
少なくともこういう要素はClass構文を語る上で無視できる存在ではないだろう?
そうすると一般にClass構文は糖衣構文ということはできないというのが俺の主張だ
なのでそう言いたいのならコンテキストを絞った上で言わなければいけない
今回の場合も、もし「ES6で新たに導入された式や文は ES5.1の構文糖衣と考えて良い」と答えると
そういうClass構文などの無視できない重要なポイントを気にしていない、
下手すると気にしなくていいという発言になってしまうだろう?
君はそこを取るに足らないポイントだと考えるから、そう言えるんだろうが、
俺は>>933にそこももっと知っておいてほしい、説明したいと思うんだよ
そういう違いさ >>945
長ったらしくて読む気がしないが
要するにお前が言いたいのは、
class = 糖衣構文+α って言いたいだけやろ? そして+αの部分がclassでしか使えないのかといえばそうではなく
classを使わなくても、+αの機能は使えるから
やっぱりclassは糖衣構文 >>947
Class構文のES5で代替不可能な機能はES6の他のより基本的な機能で代替可能だから、
ES6も入れたら糖衣構文と言ってもいいよ
でも今回はそうじゃないから
ES6の機能が、従来のES5の機能の糖衣構文と言えるかという話だから
その辺り俺は言葉に慎重だが、君は適当
そういう違いさ 糖衣構文の反対はキムチ構文って呼ぶってことで
この話題終わりにしませんか? >>949
それでも良いよ
俺はどういう機能か説明したい気ならあるが
くだらない言い争いはもう沢山だから >>948
もしかして
ES5で今までやっていたことをclass構文で簡潔に書けるようになっても、
ES6で追加された機能をES5で実現できなければ糖衣構文ではないって言ってる?
意味不明なんだけど >>934で
> 「ES5.1の構文糖衣」という表現がおかしい
とせっかく俺が言ったのに
>>935がclassのことを持ち出すから
おかしくなったって自覚してるのかな?
classは糖衣構文だが、そもそも最初にES6の機能がとかいう言い方はおかしいって指摘した。
マッチポンプかよ。自分がclass限定の話にしておいてclass限定の話はしてないって 話変わるけどジェネレーターは糖衣構文じゃないよねさすがに。 >>953,954
意味不明なのはあんただ
俺は0.999だからNoとか0.001だからYesとか言うのは嫌いだし
そういう0か1かで糖衣構文「であるのかどうか」を話す気はない
たとえちょっと変な表現であろうと、今回の話の流れの上で糖衣構文「と呼んだほうが良いか」を
アナログ的に考えて、俺なりの想いを持って方が良い、悪いと話している
また俺はClass限定の話を始めたわけではない
わかりやすい一例としてまずClassでの事実を1つ挙げただけ
そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
変におかしな流れに誘導したのは君の方だよ
少なくとも俺は>>933を俺なりに解釈して話を始めた
そこで君が横から言葉の使い方がどうのこうのヤンヤン言って来ても知らんがなって感じ
君の脳内パーサではエラーが出たんだろうが、それをエラーですエラーですエラーですよって、うるさい目覚まし時計かって感じ
俺のゆるゆるパーサでは通ったんだから俺は話を進める、君は固まっとく、でいいじゃないか
俺までどうにかして止めようとする必要はない、俺はそういうのは嫌いだね
JSでも値をチェックして例外を吐くとかね
値をできるだけ加工したり用意の仕方を工夫して無効な値を極力作らないようにする方が俺は好きだ
ともかく君の定義ではそもそも話がおかしいのはおっしゃる通り
だからこそ俺はその定義は今回はそぐわないとしてるところに、わざわざその破綻する定義を持ってきて
ギーギーガーガーおかしいおかしい言われても しつこいポンコツ機械かよって感じ
まあそんな感じ >>956
俺はclass = 糖衣構文+αなんだから糖衣構文だって言ってるのに、
お前が、完璧じゃないから糖衣構文と言ってはいけないと言ってるんだろ
1じゃなければ0と言ってるのはお前だ 糖衣構文+αじゃなくて、完璧に糖衣構文でしょ
糖衣構文+αだったら糖衣構文とは言わないよ 糖衣構文か否かの議論の果てにどんな結論があるんだろ 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
になると思うんですが。 >>959
いうだろ?
ES5で書いたものをclassで完璧に書けるんだぜ?
追加効果があったとしても関係ないだろ
それにそもそも糖衣構文って完全に同じものを
実現しなくてはいけないなんて制限はないんだが?
ほぼすべての糖衣構文はある機能に特化することでより便利にしているが
その反面あるきのう以外のことができなくなってる
他のどんなものが糖衣構文と呼ばれてるか考えてみなよ
糖衣構文という言葉に惑わされてるだけだろ >>960
それな。>>938ですでに俺が言ったことだが 一つ例を出してやる
C言語でswitch〜caseはifの糖衣構文と呼ばれているが、
ifでやれることのすべてをswitch〜caseでやれるわけじゃない
switch(a) ← 変数aとの比較限定になっている
この点においてswitchはifの制限版
また逆にswitch〜caseのfall throughはifでは実現できない
この点において、switchは糖衣構文+αの機能を持っていると言える >>962
ショートサーキットしてる
false && true || trueの二番目のtrueは評価されない
それと後者の答えは優先順位が違うから
&& は||より先に評価される
四則演算でいうと||が足し算で&&はかけ算 >>966
>逆にswitch〜caseのfall throughはifでは実現できない
そんなことはないと思う
https://ideone.com/tVia2L QZは馬鹿だから無視でおk
「車は右側を走れるか」みたいな話は余計脱線するだけ ふむ。まあ要するにES6の機能をES5で実現できれば糖衣構文。
実現できなければ糖衣構文ではない。という定義は
完全に間違っているってことだな >>956
> そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
話したいことがあるのなら勝手に書け
そしてそれに食いつく奴が居るかどうかだろ
順序が逆だ せっかちなのは君の好きにすればいいけど
勝手に思い込んで突っ走って人に迷惑かけて……
もうクズの見本みたいな振る舞いしてる事に気が付いたほうがいいよ
勿体ないよ const foo = [1, 3, 5, 7, 9];
const bar = [3];
console.log(foo[bar]); // 7
このコードの意味がよくわかりません
状況からしてbar[0]の3を自動で取り出してfooの添え字にしてるように見えますが、そんな意味不明な動きしますか?
Cでいう*barみたいに配列の先頭アドレスから値を取り出してる?? >>974
そんな糞コードは理解出来なくていい
教科書なら捨てた方がいい
百歩譲って「添字はtoString()してるだけ」ということを教えたかったのなら、
数字と文字でやるべきだ >>975
すみません、業務で見たコードで、実際にはfoo相当の配列はオブジェクトの配列でした
先のコードは自分で実験用に動かしたコードです
なるほど、添え字に配列変数を指定すると、toStringメソッドが走る
配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
なので要素が数字かつ1つしかなければ、その数字を添字にしたのと同じことになる、ということでしょうか >>976
概ねその通りだが、俺は
> 配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
これが仕様なのか環境依存なのかは知らんよ。
いずれにしても、「配列を添字として使う」事自体があり得ないだろ。
糞コードだし、修正すべきだよ。
動いているからバグとして検出されず、結果的に修正漏れになっている、ということかな。
なおその手の詳細な挙動を知りたければ、仕様書を読むしかない。
JavaScriptの仕様書は他言語で言う仕様書ではなく、実装指示書(詳細設計書)といった方が正しい。
だからオグジェクトの配列のアクセスの仕方(セマンティクス)がいちいち細かく書いてある。
その中で原則的には全てtoStringされていたはずなので、結果的にはそういう挙動になる。
つまり、
× > 添え字に配列変数を指定すると、toStringメソッドが走る
○ 添え字は何であれ全てtoStringされる
だったはず。気になるなら仕様書を確認して。 × オグジェクトの配列の
○ オグジェクトや配列の
読める範囲ではあるが、若干混乱するかもしれないので念のため。 >>977
丁寧にありがとうございます
どう見てもミスっぽいので直しときます
まさかこれで動くとは思わなかった……js怖い 別にこの程度非難轟々するほどのコードじゃないだろう
暗黙の型変換がたった1回働いてるだけでしかないのだし
添字は必ずシンボルか文字列として評価されるってことも常識として知っておかないといけないこと
この程度にそんなに目くじらを立ててたらJSが読み書きしにくくなるというか
JSは避けてRustで書いてWasmにするとかした方が良いと思う でも文字列を引数にとる既存の関数をタグ付きテンプレートとして呼び出せるのって['foo']が'foo'に変換される仕様のお陰なんだよなぁ
'hogefugapiyo'.split('fuga').join('hage');
↓
'hogefugapiyo'.split`fuga`.join`hage`
意味のないコードだけどあくまで例として。 foo = [ 1, 3, 5, 7, 9 ];
bar = [ 3 ];
p foo[ bar ]
Ruby では、エラーになる。
配列から整数への、暗黙の型変換はできない
やっぱり、JS は、バグる。
怖い javascriptでいう関数ひとつ取ってもる〜ピぃは
def
ブロック
Proc.new
proc
lambda
->
用途に合わせてどれが使えどれが使えないのか、使える場合変換は必要かどうか、変換なしで使える場合も挙動がどう異なるのか(同じように使える場合もすこしづつ挙動が異なるからw)あっちとこっちは相互にどういう変換方法があったか、等しっかり考えて作るもんなww
さすがるっピ!www >>981みたいな奴が普通に居るのがJavaScriptコミュニティが腐ってる証拠な。
プログラミングを知らない癖に出来ると勘違いした馬鹿が間違ったことを吹聴しすぎてて、
馬鹿が再生産されまくっている。
とはいえ問題点は981以外には分かっているようだし、この話はもういいが。
他言語出身者なら、当初参考にするのはMDNだけにして、
個人が俺ツエーしてるだけのブログ等は全部無視した方がいい。
他言語ではあり得ない確率で間違ってるから、無駄にはまることになる。
emscripten/WebAssemblyが本格稼働するかどうか俺は懐疑的ではあるが、
実際にそうなったときに馬鹿JSerが一斉粛清されるかどうかは見物ではある。
「動けばいい」という基準で書いている限り、「動けばいい」程度のコードしか書けるようにはならない。
しかしこれがJSerの大半なのもまた事実だ。
一般的に「良いコード」とされる物を書けるかどうかはプログラマの技量のみに依存し、
JavaScriptだからといって書けない事はない。
ただ、どちらかというとJSはC寄りで、どんな糞コードでも書けてしまう。
ただこれは、単にJSerの技量が足りないだけであって、推奨されているわけではないので注意のこと。
>>979は今後色々と実感することになるとは思う。 TypeScript使うのはReact使ってるときぐらいだろ? >>989
あ、すまん。ReactじゃなくてAngularだね c#に似せるならもっとc#にすればよかったのに
あの型の定義の仕方が嫌だ >>991
それはあんたの会社での話でしょ?
あんたの会社の話でもなく、Angular関係でもなく
TypeScriptが使われてることを証明する証拠でもあるの? >>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 今時型定義も入れずにnpmモジュール作ってるやつとか、白い目で見られるぞ >>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 >>997
下のページのtypescriptの伸びは見ないふりしてるの? >>998
延びた結果がこの差なんだよねwww
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png javascript最高!
rupyキチガイ死ね! このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 237日 10時間 0分 38秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。