◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:+ JavaScript の質問用スレッド vol.126 + ->画像>4枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1527917483/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
JavaScript を自ら学ぶ人のための質問スレッドです。 http://validator.w3.org/ で [Check] してみてください。 >>2 の質問テンプレートを活用してみてください。 http://2chb.net/r/tech/1518940081/ (10) ライブラリ関連の質問は禁止です。関連スレにあるライブラリ質問スレで質問して下さい。
超ド素人です。スレ汚しをお詫びします。
「d3.js tsv」で検索！
<input type='submit' value='送信'>
なにかするってお願いでもするの？
== はなるべく型を合わせようとしてから比較する
>>12 どうもありがとうございます
理解出来ました
===の方が確実っぽいですね
直接javascriptの事ではないと思いますが、すみませんこちらで…
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が使えます
いろいろ試しましたが原因がわかりません
読んだけどわかりません
なんでこういう連中は再現する最小コード書かないかなぁ
どうやらVisual studio Codeの仕様のせいだったみたいです
仮にそうだとしても人はそれを凡ミスと呼ぶ
>>29 >>23 >このプロパティは読み込みが終了した後に有効になり、プロパティのデータ型は読込処理を行うメソッドによって変わります。
そのレベルでインテリセンスが機能しないのなら既に遭遇して知っているはずだし、
VSCの仕様です
VSCの仕様でもなんでもないやん
>>23 のドキュメントにFileReader.resultの型はstring|ArrayBufferだって書いてあるのを読めなかっただけやんけ無能
「俺ではなく他の問題だ」と主張するのは初心者の典型的パターンだな。
>>35 質問スレで意味のわかない用語で返すのやめてもらえますか
そもそも書いてる事理解できれば質問スレにきません
結果は文字列かも知れないしそうじゃないかも知れない
>>37 当たり前だがMDNやMSDNは普通のレベルのプログラマなら読めるように書かれている。
理解出来ないのなら自分の馬鹿さ加減を自覚し、責任転嫁するのは止めた方がいい。
>>42 次は最低限
>>1 の(1), (4), (6), (8), (9)を守ってくれよな無能
ってかaにカーソル当てたら型が出るだろ。VSCでは。
じゃ質問はもうとっくに終わってるので関係ないですね
煽るのはちゃんと回答してからにしてくださいね 無能
>>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の仕様」と思い込むな。
無知すぎてその解決法も間違ってて依然無知だと言うことにすら気づいてない。
ちゃんと真摯に聞け。
いじってくるから返してるだけですが
解決済みだと思いこんでる問題だろ。
確かにあとから苦労するだろうな。中途半端で理解した気になって、あまつさえ人につっかかる人間性だと。
まぁ、いよいよ言うに困ったら「いじってくるから返してるだけ」なんて言うレベルだし仕方ねえかな。
プログラムを動かすことが目的なのであって完璧で無駄のないプログラム
>>76 > 自分が答えるときは手本のコード貼るだけですけどね
君が答えられるようになるまでに何年かかるかだね。
君みたいな「完璧超人な俺が間違うはずがない」って勘違いは、
昨日プログミングを始めました、みたいな奴に多いのだが。
>>77 もう何度も答えてますよ
わかればコード書いてわからなければスルーで済む話
この手の質問スレにはろくに答えもしないのに説教したがりが多いですね
まったく無駄な存在ｗ
>>62 あれだけはっきり書いても伝わらないのね
・必要な情報が出ていない
・誤情報が出ている
>>76 問題ないと思うならもうそれでいいよ。
>>78 間違った答えだけどね。
釘を打つにはレンガが良い、みたいな答え。
>>80 しつけーよ
書くならさっさと書けや
２行のコードでどこまで引っ張るつもりだよｗ
>>81 書いたじゃんw
理解してレスしなければ話は終わってたのに、どうして？
理解できてないから間違った答えだと認めたくない、ならそう言えば？
こっちは配列文字列に入りゃそれでいいんだよｗ
そういう意味では最初から文字列の配列に入ってる。
最初からエラーじゃなかったと言ってるだろうがｗ
[63,61,59,57,55].forEach((v,i)=>{ 👀
ついでに
>>90 それはわかる
>>89 ありがとう。びびったわ
node.jsのhttpモジュールでapiからjson取得してそれを使ってゴニョゴニョしたいんですが
>>88 みたいなことにならないなら好きにすればいいと思うよ
think49に粘着してる奴、過去にthink49と何かあったの？(あるいは、マルチポスト晒された質問者が逆恨みしてるの？)
>>95 ts使ってるけど、lintでセミコロン使わない設定にしてる。それでなんの問題もないけど。
なんでセミコロン抜くとエラーになるん？
ご質問です。
jquery大嫌いな人間だけど
>>99 言った人に聞けばいいじゃん。
理由は「もう古いから」って言われたんだろ？
それしか理由が言えないやつならそれまでってことだよ
代替案が提示できないか提示してもメリットを言えなければ
そのエンジニアはただの園児ってことだよｗ
このスレでも何度も話題になったが、いずれも代替案を
言えないか、言ったとしてもメリットが無かった。
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
http://2chb.net/r/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使ったほうが短いとｗ
ネイティブのコードなんか書きたくない
macのsafari用にbookmarkletで
>>106 document.bodyにtextarea要素をappendChild
>>99 es2015で十分じゃん。なんであえてjquery使う必要があるの？といいたいのでは？
ie11対応したいならbabelとか挟んどけば
> es2015で十分じゃん。なんであえてjquery使う必要があるの？といいたいのでは？
JQueryが古いからダメと言うのは、ちょっと語弊があるけど細かく説明するのが面倒くさいからが半分、今流行ってるライブラリ使いたい/JQueryと食い合わせが悪いってのが半分な気がするな。
流行りだから使うって考えがアホ
それにjQuery以外に流行ってるものなんかあるかいｗ
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シェア下がってんなｗ 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だと何行も書かないといけないのがよく分かるよｗ
>>112 ああ、vanillaでブラウザ互換を気にしないでできない事も減ったし、と言い直すわ。
JQuery でテーブルの各行の高さを求めるにはどうしたらいいですか。
互換性が機能の違いを吸収するライブラリのことを
>>95 馬鹿か、負担付けなければこの手の間違いにすぐ気がつく
付けない経験が少ないから分からなかっただけだろ
JavaScript初心者です
>>122 今のやり方はローカルにビルド環境を作って、
ビルドして結合した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で動かなくてもいいやってことになるぞｗ
それとは結構違うな
class言ってるんだからモダンブラウザで良いでしょ
>>128 シェアの8割～9割の意味をもう少し考えたらどうだ
>>131 どれくらい多くの人が見れるかでしょう？
モジュールに対応している人だけが見れるサイトだと
1～2割の人が見れなくなる
>>132 それでなんでFirefoxで動かなくていいやってことになるんだ？
JavaScriptを理解するのってどのくらいの期間かかるものなの？
IEしか使えないってのは要するに企業ユーザーであって
>>138 たのしいRuby 第5版、2016
これを読んで半年、オブジェクト指向・関数型で、Ruby をいじくりまわしてから、JavaScript に戻ればよい。
CSS セレクターを使う、jQuery と、Ruby のNokogiri が、ほぼ同じ
Progate のサイトでも、やってみれば？
プロレベルでは以下の2冊だから、数年は掛かる
JavaScript 第6版、2012、David Flanagan
初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017
インタラクティブ・データビジュアライゼーション
>>145 > CSS セレクターを使う、jQuery と、Ruby のNokogiri が、ほぼ同じ
ぜんぜん違う。NokogiriはjQueryに比べたら洗練されていない
通称jQueryオブジェクト呼ばれている、いちばん重要な
オブジェクトがNokogiriには搭載されていない
そのせいでCSSで取得した複数のオブジェクトをeachで繰り返して
操作するというjQuery以前のやり方をしないといけなくなってる。
NokogiriでjQueryを学んだ気になると、jQueryとしては
悪いコードになってしまう。
そりゃ、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 内に書くと、グローバル関数になってしまうから、良くない
>>160 >>161 ありがとうございます。onclickは古いんですね。
web制作板の存在は知りませんでした。行ってきます
>>162 古いから使うな、ってのも間違いなんだが、
使い分けの意味が分からず、イベントリスナーで問題ないうちは、全部イベントリスナーでも問題ないよ。
WEB広告の内容ってJavaScriptで取得できますか?
>>164 不可能。そういう悪用ができないようになってる
キャンバス上に描く図形の色を変数から指定したいのですが変数名を入れる時にただの文字列と区別させて認識させるにはどうしたらいいでしょうか？
ダウンロードにプログレスつけるのって簡単にできる？
Fetchって使ったことないので調べてみます
>>164 できる、getUserMediaでスクリーンをキャプチャできる
>>172 え？なに？ それ使ったら、ユーザーの画面キャプチャして
サーバーに勝手に送信できちゃうの？
ここクリックしてーとかやったら
気になるあの娘のパソコンの画面とか
見放題だな！
>>172-173 > カメラやスクリーンシェアリング、マイクのようなビデオやオーディオ入力装置の使用許可をユーザーに要求します。
> スクリーンシェアリング
>
https://developer.mozilla.org/ja/docs/Web/API/MediaDevices/getUserMedia そのための機能なのだから、出来るのだろうね
> 使用許可をユーザーに要求します。
これでなんで入替えできるの？
>>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のとき
>>182 > このくらいなら手で書かれることは十分にある
> このくらいは理解できないとJS中級者にはなれない
ねーよ。お前ら相変わらず世界観が歪んでるな。
>>183 このくらいの複雑度
つまり五段回くらいの評価が一行に書かれることって
アロー関数とかが入った今ますます書かれるようになってると俺は思うが
特にreduceとか使うとこの例と似た状況にもなりがち
>>185 俺の意見は、「変数の入れ替えをその書き方でする奴は居ない」だが、これで理解出来るか？
その程度の「複雑度」なら、大したことはないし、普通の人なら頭の中で読めるでしょ。
> reduce
reduceってのは数値演算をするときに多用するのであって、
通常のJavaScript(＝DOM操作等）ではほぼ使わない。
そもそも変数の入れ替えも『初心者用の教材の』ソート等では使うが、実用では皆無でしょ。
お前、前から居るズレてる奴で、相変わらずズレてるよな。
>>185 というか、お前、前からreduceにこだわってるよな。
JavaScriptでどういう操作をする時にそれが有用なのか、言えるか？
おい複雑度っていうのを俺俺で使うんじゃない。
コードメトリクス用語の「複雑度」とごっちゃになって紛らわしい
>>177 のようなものは「複雑度」はあがらない。
上から下に単純に読み下せばいいからだ
こういうのは単に知らない命令があったってだけで複雑なのではない
「複雑度」というのは、コード自体は読めるが絡まっていて読みづらいということを指す。
具体的にはループ、条件分岐が増えることで「複雑度」が増えていく
ちなみにコードが複雑というのは、コードの問題だが、
reduceは数値演算で多様？
>>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は汎用だよ。誰が数値計算にしか使っちゃいけないって言ったんだろｗ
>>193 あと、多分、中級者の基準がおかしい。
君のはJavaScript『文法』の中級者なんだよ。
JavaScriptはプログラミング言語であり、プログラミング言語は実装の道具だ。
だから、本来の『JavaScript中級者』ってのは、何を実装出来るかで測られるべきなんだよ。
俺の定義なら、以下だね。
・初級者：一通りも出来ない。
・中級者：一通りやりたいことは出来る。
つまり、「ポップアップを作りたい」「ここをクリックしたらこう動かしたい」等、
やりたいことがあれば、とりあえず動く物は作れる。
・上級者：最初から最適な構造を考えて実装出来る。
勿論、新文法が便利なら使えばいいのだけど、最適な構造かどうかと新文法はほぼ関係ない。
（むしろ本質的に必要な物は先に取り入れられるから、新文法は基本的にオマケでしかないし）
それよりも、コード構造の方が何倍も重要なんだよ。
>>196 > reduceの中でfetchのプロミスをthenで繋げるようにして一時に１ダウンロードしか走らないように制限したり、
> 無数の関数を次々適用したいとき
やるのは自由だが、それ、普通に配列をforで回しても実装出来るだろ。
新文法を使う＝上級者、というのは完全に間違いだって事だよ。
君らは文法にしか目が行かないからそういうことしか言えない。
それは初心者にありがちなパターンでもあるけど。
（初心者は文法から入るしかないから、どうしてもそこに目が行く）
>>194 「思っているのだろうけど」とか止めてくれない？
自分はこういう構文が良いものだとも、ああ書くべきだとも言っていないよね？
こういう使い方もできる、こうも書かれることもある
そのくらい思いついて、すんなり読めるようになろうと言ってるだけ
無理に使う？君が無理かどうかなんて知ったことじゃない
>>195 長期的って言うのがそういう期間を指しているのか知らんけど
デバッグも完璧に終わってリリースしてしばらくたった後、大型アップデート時に
ってことならまだ分かるけど、今どきは毎日小変更デプロイでしょ
そういう体制だと将来的に困ったら丸ごとすげ替えればいいっていうのは通用しない
複雑なものを放置しとくと、実際困ること必至
それがJSerの考え方の面白い特徴だとか、古すぎぃ
>>198 それ、reduceでできるよね。わざわざforを使って本質的でない一時変数をいじくりたい理由とは？ｗ
reduceなんて何年も前から使える。es2015ですらない。
文法にしか目に行ってないのは君自身のことだね。悪いけど一緒にしないでもらえる？
君はどこまでも自分本意な考えで、自分の知らない文法＝新文法、自分の知らない文法を他人が使うのがとにかく気に入らない、これに尽きる。これに後付けで理屈をくっつけているだけ。
>>199 > こういう使い方もできる、こうも書かれることもある
この必要がないんだよ。むしろ、してはいけない。
それが分からないのは君が『長期的』メンテナンスしたことがないからだね。
> 長期的って言うのがそういう期間を指しているのか知らんけど
CやJavaの世界では20～30年以上だね。
そして「コードメトリクス」はそれを前提としてるから、JavaScriptにそれを適用するのも無理がある。
>>197 君は本当によくわかってる。正に君の言う通り。
自分はJavaScriptを道具だとは思っていない。
もちろん君の定義も分かる
でも曖昧で幅広すぎるでしょ？
ここはWeb制作板じゃないというのもあるし
なんだかんだ言ってもやっぱり今回は文法の問題だったので
文法レベルで言わせてもらった
ってわけでもない
自分が中級者と言って想定したのは「右も左も分からない段階を抜けてそこそこ使えてきた段階」
つまり、とにかく基準は何にせよ俺は初級者は抜けられたぞ！って思ってるような人に
そこで満足してほしくないからちょっと意地悪で大げさに発破かけただけ
皆どちらかと言うと君の基準だろうから、そこはわかった上であえて文法面をぶつけてみただけ
すまんね、自分バランス取るのが好きなひねくれ者だから
>>200 > 本質的でない一時変数をいじくりたい理由とは？ｗ
ああ、そっちの宗教の人か。
まあ、流儀があってやっているのならいい。
それで君にとって「読みやすくなる」のならそれもありだ。
ただ、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 やっぱ藁人形ｗ
誰も一行で書けるからreduceがいいなどとは言ってない。
ましてや関数型至上主義者ならなおさらそのようなことは言わないだろう。
> なんであんな糞使えないメソッドが導入されたのかが俺には謎だ。
つまり、「俺に分からないreduceなんてみんなも使うべきじゃないんだ！」
ガキか。
>>207 それならそれでいい。
俺はお前の書き込み全部デタラメだと思ってるぞ。
>>209 だから、まず、
> 俺に分からないreduceなんてみんなも使うべきじゃないんだ！
が間違いなんだよ。
君にとって reduce が難しいからそう思えるのだろうけど、
実際、reduceが分からない奴なんて居ない。使いどころがないだけだ。
>>196 も無理矢理でしかない。
indexOf等と比べてゴミなのは事実だろ。
というか、JavaScriptのスレには前からreduceが大好きな奴がいるが、
ここまで来るとjQuery廚と同じく布教目的か？
なら筋が悪いから無理だ。
> 君にとって reduce が難しいからそう思えるのだろうけど、
>>190 でも似たようなことを書いたが
コード側の問題 と 人間側の問題をはっきり区別つけろ
reduceがわからないっていうのは人間側の問題だ
コードの問題じゃない
>>211 だから、何度も言っているが、
× 使いどころが分からない
○ 使いどころがない
なんだよ。
結局、
>>196 も、『一時的に』配列として持たせてreduceしただけだろ。
最初からいきなり縮退させれば済むだけの話。
reduceは『配列として意味がある』(≒配列として『持つしかない』)物を縮退させるメソッドであって、
そもそもそのケースがJavaScriptの用途においてはほぼ無いんだよ。
そして他言語でもこのメソッド持ってないだろ。大して使えないからだよ。
>>212 俺の立場をはっきりさせた方がいいのか？なら、そちらと同じで、
・reduceを使ってもコードメトリクス的な「複雑度」については上がらない。（これが原因で『長期的に』読めなくなることはない）
・reduceは難しくはない。（これが原因で『短期的に』読めなくなることもない）
・使っているコードに遭遇しないのは、そもそも使いどころがないから。
・
>>196 はイキった馬鹿が無理に使う例だが、まあ、やりたければやればいい。大局的な問題にはならない。
> ○ 使いどころがない
> ・reduceを使ってもコードメトリクス的な「複雑度」については上がらない。（これが原因で『長期的に』読めなくなることはない）
reduceは初期状態があって、データの数だけ
reduceの問題は、reduceをしたくてreduceを使うのではなく
> 何をしているのか、何のために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の用途においてはほぼ無いんだよ。
君が遭遇したことがないだけの話だなｗ
「ボクが出会ったことないユースケースなんだから、みんなも遭遇したこと無いに決まってるんだ！」
経験不足だよ。
反例として、フィルターの種類、数、適用順を自由にユーザーに選ばせ画像に適用するクライアント側のコード書いたことあるがｗ
>>223 URLくれれば見に行くが。
無理なら、reduceをどう使ったか分かるように言え。
つってもまあ、そのケースなら、関数を配列に入れてreduceしただけか？
なら
>>196 と同じだと思うが。
reduce禁止くん、「reduceは『配列として意味がある』物を縮退させるメソッドであって、そのケースがJavaScriptの用途においてはほぼ無い」って言ってるけど、これわざわざ配列使わずにやるの？ｗ
>>225 俺は禁止とは一言も言ってないぞ。
使い道がないから使わない、と言ってるだけ。
>>220-222 「jquery event」「jquery preventdefault vs stoppropagation」で検索！
click は、要素をクリックする。
submit は、フォーム送信する
preventdefault は、イベントの既定の動作を、キャンセルする。
stoppropagation は、イベントの伝播を止める
JavaScript, jQuery の質問は、この板ではなく、web制作管理板へ書き込んで！
一番新しいプロジェクトでreduce何かに使ってたかなと思ったら
>>228 前者は filter + map でやるべきだ。
後者は
>>191 と同じだな。
意味的にはコンストラクタなのだから、関数として切り出すことに問題はないし、それで終わりだ。
filter+mapの方が良いとも限らないと思うよ
あとはDの場合はvalue.d1とvalued2の両方を追加するとかもできるね
>>230-231 reduceが効果的に使われているというのならそのURLを紹介してくれ。
>>221 > reduceの場合も中身（関数）を読まなくてはならず、
> そこが単純な関数なら、forで書いても単純だからだ。
reduceはコードを読まなくても、初期状態から状態を変えていってるっていうのがわかる
forはただのループでしかなので、それがわからない
理解できた？
http://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はローカルにもブラウザにもアクセスできるってこと？
VSCode は、Electron で作られている普通のIDE。
ブラウザの拡張機能やアプリと同じだよ
>>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.0toString()
name="form1" の form を参照するのに document.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が何にためにあるのかを知っていれば
>>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ってアクセス解析の類い。
んじゃそれ外して試せばいいじゃんとなるだろうけど、いつか確かめるけど事情により今すぐは難しい。
といった感じで実用面では他のより良い手段でやればいいことなので問題があるわけじゃないんだけど、理由は知っておきたいという話。
どこでハマるか分からんし。
> どこでハマるか分からんし。
>>267 > 同じコードが動いたり動かなかったりするからなんでって聞いてるの
それはそうだから、でしかないだろ。
まず、今現在「仕様」かどうか確認しろよ。
それで「仕様」でないのなら、それは偶々動いていただけであって、それだけでしかない。
ブラウザは大幅に更新されてる。
元々それを動かすコードをブラウザが持っていたとして、
仕様から外れた時点でそれをどこで落とすかはブラウザ開発者の自由だし、
結果的に一部残っていて動いたり動かなかったりするのも問題なしだ。
そしてそうなってるだけだろ。
「仕様」でなければ何の不思議もないし、「仕様」であればバグ報告すればいいだけだろ。
そしてその範囲を知る意味もない。
ありがちなパターンとしては、「古いコードもある程度までは動くようにする」為に、
初期構築（最初の構築)だけはそのコードを通し（つまり旧来方法でのアクセスも可能）、
追加で動的構築したDOMについては追跡してない(つまり旧来方法でのアクセスは不可能)といったところか。
ただこれを知ったところで、いつ変更されるかも分からんし、意味無いだろ。
> どこでハマるか分からんし。
「仕様」かどうかはさておき、「みんな」が「今」使ってない方法を使ったら駄目、ってことでしかないだろ。
そういったコードは、必要に応じて書き換えて「今」のトレンドに乗るようにするか、
jQueryみたいに「バージョン○○では…」と自前で管理しきるしかない。
どっちもする気がないのなら、それはお前の問題だ。
初心者にありがちな、全て「仕様」で確定している、という勘違いなら、頭を切り換えた方がいい。
厳密に仕様準拠なら、「必ずundefinedが返る」のが正しいが、
JavaScript界隈はそういう厳密さより、上記のように旧来コードも動くような曖昧さを残した方が好まれる。
結果、今の君のように、「ある日突然コードが動かなくなって？？？、環境依存？？？」な事も発生し、
それが長期的に生産性を下げる要因になっているのも事実だが。
>>269 > もう誰も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年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか？この先の動向が注目される
前線の開発者が新規にwebアプリ作る時はもう使わんというだけで
Angularが減ったのはまだ誤差の範囲内だと思うけど
保守ではjQueryあるけど新規は全くない
そもそも新規の仕事ってのがないってだけなので、
>>278 「3.1.3 DOM tree accessors」の中だったか
参考までに、どうやって検索した？
とりあえずバグなんで、ブラウザの対応待ちですわ
>>280 自演か？
それを257が言うのはともかく、お前が言うのはおかしいだろ。
自演ではないね。
>>282 まず立場をはっきりさせろよ。
まあお前のレスを見る限り、正直、257のケース以外のところで怒らせてると思うけどね。
>>283 俺の立場は「誰が書いたか？」ではなくて「書いてある内容」しかみない
だから俺にも立場を求めるな。
>>284 やはり通じてねえw
そこがお前の駄目なところで、客もそれに怒ったんだと思うぜ。
まあ、完全に空回りだからもういいが。
>>285 流行り通じてねぇｗ
「
とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
」
ということが、起こったんですよ。彼の現場ではね！
って話だろうがｗ
>>280 ブラウザはOSやグラフィックドライバなどのバグにきちんと対処してるぞ
>>267 >別サーバへ設置するとコールバックの中でも動いたりする
実行環境が異なると、使っているライブラリも変わる
それと一般的には、動いたり動かなかったりするのは、非同期処理を勘違いしているとか。
promise とかで、ちゃんと解決してない
処理A, B の順番では動くけど、B, A の順番では動かないとか
1回目は、ファイルの読み込みに時間が掛かるから、エラーになっても、
2回目は、キャッシュから読み込むから、エラーにならないとか
ちゃんと非同期処理をやっていないのに、タイミング次第で動いているアプリは多い。
その特徴はエラーになったり、動いたりすること
ログを見れば、わかる
>>286 > 客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
「言った」の主語が
>>280 に読める、と
>>281 は言ってる
>>287 > ○ はやり通じてねぇｗ
日本語頑張れ
>>291 概ね同意だ。
善し悪しはさておき、WHATWGにあるのなら、今現在も仕様としてブラウザ開発者側に認識されているだろう。
なら、既に実装されて十分動いていたコードが意図的に落とされることはない。となると、
1. そもそも257のコードに問題があって、それが何らかの理由で顕在化しただけ
2. 元々ブラウザにバグがあって、それが検出されずにずっと残っていただけ
3. ブラウザのコードの更新時に、レグレッションテストに引っかからずバグを挿入してしまっただけ
のどれかだが、可能性が一番高いのは 1. だね。
俺自身はブラウザなんてバグだらけで全く信用ならないプラットフォームだと認識しているから、
こなれてない書き方は出来るだけしないようにしている。
そこではまっても本当に時間の無駄でしかないから。
だからそんなコードはさっさと書き直せ、という立場だ。
ただ、ブラウザのバグだという立場なら、バグ報告をするにしてもコードを切り分けていかないといけないし、
仮に 1. なら、idで書き直しても動かないケースが発生するはずだから、
どのみちそのコードに関しては詳細検討が必要になってしまったね。まあ頑張れ。
ある意味、「仕様外」だったほうが楽だったのではないかな？
もっとも、バグ報告したとしても、直すのも開発者側の自由だから、このまま放置される可能性もあるが。
JavaScripterは全般的にそうだが、最近の初心者は、仕様の隅を使いたがる傾向がある。
仕様を隅々まで知って、それを『使い切る』事がいいことだ/上級テクニックだと勘違いしている。
そういうところでしか差別化出来ないから、そういう小手先テクニックに異常にこだわるわけだ。
ただ、それが仕様内でも、それを動かすのは人間が作ったソフトウェアであって、
そこにバグがある可能性があり、実際、ブラウザなんてバグだらけだ。
こなれてない書き方をするのなら、それなりの覚悟と能力が必要だって事だ。
勿論それをやるのも自由だけど。
(もっとも、257がこなれてないか、と言われれば、こなれているが古い書き方、かな？)
最近の初心者が仕様の隅まで知りたがる？ｗ嘘つけｗｗｗ
いろいろありがとう。
>>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は馬鹿しかいない。これは断言出来る。
他言語と比べても相当酷い。
＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
>>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 の、インストールが必要。
>>294 コピペプログラマが無自覚で結果的に仕様の隅をつついたコードになっていることはあり得る。
彼等は書かないのだから、どういうコードが標準なのか当然知らないから。
ただ、本質的な問題はそこじゃない。
コピペプログラマがコピペしてきた元コードが糞だって事なんだよ。
コピペ自体が褒められるべき事ではないにしても、元コードがまともなら局所的にはまともなコードになる。
今回で言えば、誰かが最初に
document.name
の糞コードを書いた、ということなんだよ。
これがコピペであれば、どこかの馬鹿がドヤ顔で「こんな書き方も出来る(ｷﾘｯ」した結果、ということだ。
正直、JavaScript界隈はこれが多すぎる。
糞コードが糞コードを再生産してて、しかもみんなそれに気づいてない。
JavaScript界隈はバージョン管理を止めてしまった。
結果、猶予期間中にアップデートして新しい書き方に変更していかないといけない状況になってる。
旧来の、バージョン○○では動きます、みたいな管理方法が出来なくなっている。
だからそもそも257流の管理方法は不適だ。
古い書き方のままでどこまで動かせるか厳密に言える状況ではなく、適宜書き換えていくしかなくなってる。
だから、本来は古いwebサイトは閉鎖されるべきなんだよ。
今 document.name なんて書いているまともなサイトがあるとは思えないから、
おそらくはかなり古いサイトを参考にしたか、どこかの馬鹿がドヤ顔したかだが、
正直、前者もかなりある。
質問です。
>>309 ありがとうございます
こういう場合でもthisは使えるんですね
まずWebの仕様とJSを一括にするのは違和感あるけど、まあそれはいいとして
> まあ色々言いたいことあるけど長くなるから取り敢えず１つだけにすると
>>312 コピペか？ポエムか？
意味不明すぎ。
流れ上俺への批判だろうが、該当する箇所がどこだかさっぱり分からない。
お前も「JavaScripterは馬鹿しかいない」という俺の自説を補強したいのか？
他言語スレでは馬鹿が噛みついて来るにしても、少なくともどこに噛みつかれたかは分かるぜ。
お前らではまともに会話が成立しないではないか。
下記のjsonをJavaScriptの多元連想配列に格納する方法を教えてください。
>>315 $.getJSON( url, function( json ) {
console.log( json['name1']['key1'] );
});
俺ならawait fetch使うがjQueryがいいってんだからしょうがないね
>>314 それ以上知能指数が低いアピール続けてると誰からも取り合ってもらえなくなるぞ
あ、もう手遅れかｗ
今どきjQueryでって頭が湧いてるとしか思えんな
荒らしと会話するな。質問に答えるな。
しかしこれは一方的に
>>315 が悪いだろ。
>>316 で死ねと言われる理由もないし、そりゃ死ねと返すだろ。
まあこのレベルの質問はWeb板で、というのは同意だが。
ほんと、jQueryの話題がでると、頭フットーするやつがいるなぁｗ
>>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操作ライブラリへの回帰を目指している。
>>325 > jQueryの話題がでると、頭フットーするやつがいるなぁｗ
お前もな。
好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
急速に衰退するかは微妙だが、引き金になるとしたらWebAssemblyが成功したら、かな？
そう簡単に行くとも思えんが、あれはゲームチェンジャーになり得る。
>>327 > 好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
> それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
逆逆ｗ 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どう考えても終わりません。不安を煽って間違ってる方向へ変えようと、
明らかにずれてる方向が正しいんだと、布教してるやつがいるから事実を伝えてるだけ
jQueryの代替なんてまだ登場してないんだよ。React？Angular？ WebAssembly？
それらはjQueryの代替ではなく大規模なウェブアプリを作るためのもの。
ウェブサイトに適してるのは昔も今もjQueryだ。
jQueryが終わるとしたらWeb componentsが完成して、
使えるコンポーネントが "出揃った時" だろう
つまりウェブサイトを作ってる連中が「JavaScriptなんて全く使わねぇ。
誰かが作ったコンポーネントを使ったHTMLを書くだけで終わり」と
言い出すまでってことだ
そうなれば本来あるべき完全分業の世界に行くことができる。
HTMLのパーツを作るのはプログラマ。それを使うのはウェブデザイナー。
今はウェブデザイナーが書いたHTMLにJavaScript（jQuery）で動きをつけるという形で分業している。
jQueryを使うのはJavaScriptよりも圧倒的に楽だから。セレクタを使うからウェブデザインとの相性も良い。
React、Angular、WebAssembly などはウェブデザイナーの仕事であるデザインの作成を
プログラマの領域に吸収するやり方なので、世界の大半を占めるウェブサイトには全く適していない
世界の大半を占めるウェブサイトは
IE11のことを考えないコードを指摘するのは人間のクズ
>>328 > 逆逆ｗ 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どっちが先とかはどうでもよくて、お前も必死過ぎなのは事実だよ。
どうしても、jQueryは不滅です、ってことにしたいんだろ。それもまた、不安だからだよ。
> 今はウェブデザイナーが書いたHTMLにJavaScript（jQuery）で動きをつけるという形で分業している。
> ウェブデザイナーの仕事であるデザインの作成を
> プログラマの領域に吸収するやり方なので
この、君の現状認識については同意出来る。
> 「まず最初にHTML+CSSを書く」ということを
これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
CSSの恩恵を正しく受ける為にはクラス設計が必要となる。
そしてそれは工程が逆転する、つまりプログラマが上流、デザイナが下流になるから、
Webデザイナが牛耳っている職場ではかなり無理がある。変化するにしても時間はかかるだろう。
それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
どっちに賭けるかも含めて、個人の自由だ。
> jQueryの代替なんてまだ登場してないんだよ。
jQueryの売りはCSSセレクタで、それは標準に入ってしまった。
大体それ以前に、まともにクラス設計されてたら getElementsByClassName だけで済んでしまって、
querySelectorすら必要ない。（アプリならqueryすらしないし）
その他諸々jQueryが色々便利に出来ていることは認めるが、
最早、無ければ無いでいいや、程度でしか無いと思うが？
まあこれについては水掛け論だからもういいが、
少なくとも、俺と同じ「もう要らないんじゃね？」と思う奴が一定数居るからこそ「不要論」が出るわけで、
そこは君も認めないと駄目だと思うぜ。
jQueryはHTMLベースになる点が本質的に筋が悪いんだよ。(逆に、それが取っつきやすい点でもあるが)
馬鹿って変なところにこだわって前へ進めないままなんだよなあ
jQueryの遅さは機能性から来るそのDOMAPI利用の冗長さにあって
ブラウザもPCもどんどこ高性能になってるよ。
>>331 > > 「まず最初にHTML+CSSを書く」ということを
> これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
中途半端に引用するな
ほんとな。わざと１行で書いて、都合よく引用させないように
徹底しないといけないよな
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」ということを
ってかいただろ
プログラマ的に間違ってるとか、大半を占めるウェブサイトになんの関係があるんですか？
上で、ゲームチェンジャーになりうるとか言ったが、なんのゲームを変えるのかを
明確に言ったらどうだ？それは「プログラマ的なゲーム」だろう
チェンジするのはウェブサイトの世界じゃない。デスクトップやスマホアプリ・ゲームの世界だ
デスクトップやスマホと言ったウェブでない世界を壊してウェブに来るだけの話
その場合になくなるのはjQueryじゃなくて.NET FrameworkやUnityだよ
WebAssemblyとか語るやつは、新しく何ができるかしか言わない。
>>331 > それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
いつまで待てばいいの？ｗ
このスレ立ててからもうすぐ2年になる
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
http://2chb.net/r/prog/1485008061/ You-Dont-Need-jQueryができてからは3年ぐらい立つか？
もうそろそろ結論出たってことでいいと思うんだけど？
あと3年？ 5年？ 10年？ まだまだかかりそうだねぇｗ
jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな
> jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな
俺が老害かどうかじゃなくて、現実を見たほうが良くね？ｗ
>>303 ありがとう
意外と単純な探し方でびっくりした
宗教論よりこういう書き込みが増えてほしいな
>>336 意図的におかしな引用をしたつもりはないが、そう取れたのならすまんかった。
現状認識において、俺と君には大差ない。再度確認するなら、
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」
そうだ。正確に言えば、そうだった。これが変わりつつある。
> いまウェブの大半を占めるウェブサイトの制作が楽になることはない
これが違う。静的HP用のフレームワークを使えば、楽になる。
本来はWordPress等もここを目指しているはずだが、
JavaScriptをいちいち書かないといけないのなら、それは上手く行ってないだけだね。
> そしてjQueryのスピードにも全く困っていないというのも重要な所だな
これはそうだとも言えるが、そうでも無いとも言える。
そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
それがJQueryかどうかは別だが、
フレームワークもjQueryも無しなら（いろんな意味で）遅いサイトになりにくいのも事実だ。
結果、素で書け、と言われるのもまた然り。
が、話が広がりすぎるので絞ると、
>>344 > そうだ。正確に言えば、そうだった。これが変わりつつある。
ねーよｗ
少なくともウェブデザイナがJavaScriptを書くことはない。そうだろう？
>>345 > そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
> それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
> それがJQueryかどうかは別だが、
> フレームワークもjQueryも無しなら（いろんな意味で）遅いサイトになりにくいのも事実だ。
> 結果、素で書け、と言われるのもまた然り。
やっぱり、実行速度しか目に入ってないんだなｗ
かわいそうに。
ほとんどの人は、楽になる方法しか求めてないよ
jQueryをやめて楽になるか？ 何一つ楽にならない
速いとか遅いとか言ってる限り、現状のjQueryのシェアが
落ちてない事実は理解できないだろうよ
> 今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
document.querySelectorAll() を
>>345 > 「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
> なら、10年後くらいではないかな。
「staticおじさん」なる言葉が発生したときには、staticばかり使ってる人はすでにいなかったわけだが、
jQueryの場合、使っている所が大半を締めてる。状況はぜんぜん違うんだが何と何を比べてるんだ？
まあ、適材適所っしょ。
>>349 > document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねｗ
なるほど君はデザイナ側か。
なら話は平行線だろうし、君はjQueryと心中して問題ないと思うよ。
プログラマにとってはそれはコストではないんだよ。
タイピングも速いし、それ以前に「デバッグ」のコストが大半だから。
色を付けるだけならスモークテスト＝最終テストで、君はその発想しか出来てない。
実際、DOMクエリは100倍くらい遅くて、地道に削除するだけでもかなり高速化する。
だから、 document.getElementsByClassName みたいな糞長ったらしいメソッドで、
書きたくなくさせるのも、効果があるといえばあるのさ。
「高価な操作はソースコード上でもそう見えるようにしろ、そうしないとメンテの時に障害になる」
ってのはC++の思想だが、これも一理あるわけでさ。
(デザイナにとっては色が付けば良しなのだろうが、プログラマにとっては実行速度も管理対象であって）
jQueryが不味いのは、その手の操作がお手軽にできるから、そういった書き方になってしまいがちなこと。
これはjQueryそのものが遅いのではなくて、使う人が悪いのだけど、
これも含めてjQueryが悪いことにされてて、君のようにムキになる人が出てくるのも自然な成り行きではある。
ただ、既に書いたように、jQueryはHTMLベースになる点（なりがちな点）が本質的に筋が悪いんだよ。
ただそれは上記の通り、使う人の問題だが、
CSSクラスベースに移行したらクエリそのものが単純になる/必要なくなるのも事実でさ。
結果、CSSにすら移行出来ないサイトだけがjQueryを使い続けることになり、それは馬鹿にされるのも当然だよ。
そして今の君のような人に対する反動として、10年後に噴出する、というわけさ。
>>350 『今から』10年後な。
jQueryが必要ではなくなってから15年後、ってことだよ。
「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
いちいちなげーんだよ
>>349 > document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねｗ
document.querySelectorAll()を$()と書けるようにする方法
方法１：
var $ = document.querySelectorAll.bind(document)
（48文字、minifyで46文字）
方法２：
jQueryのロード
（minify + gzipで約30,000文字ｗ）
ブラウザがgzip解凍後の約85,000文字のjsで書かれたjQueryコードをパース、コンパイルｗｗｗ
結構な時間です
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization/#parsecompile >>353 やっぱり、実行速度しか頭にないのなｗ
視野狭過ぎでワロタｗ
実行速度も何が何でも速いと思ってる。
そんなに実行速度が重要ならブラウザ使うの止めたほうが良い
速度は許容範囲かどうかで決めるものだ
今jQueryを使ってるサイトは、jQueryの速度が許容範囲ってことだ
なにせ一回読み込めばキャッシュが効くからな
遅いのは最初の一回だけという
> ただ、既に書いたように、jQueryはHTMLベースになる点（なりがちな点）が本質的に筋が悪いんだよ。
ウェブはHTMLベースで書くのだから仕方ないな。むしろHTMLベースで使いにくいものはだめだろう
> 『今から』10年後な。
「jQueryはオワコン（10年後にな！）」
もうこれ完全に不安煽ってるもの以外の何物でしか無いわｗ
> 「楽だ」と思えるのは君が既に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おじさん仕事できなさそうｗｗｗｗｗ
ゴキブリ倒すのに戦車持ってくるみたいなｗｗｗｗｗ
>>356 > ソフトウェア開発において覚えることこそが技術力だし。
これは違う。やはり君はプログラマではない。だから分かる必要もないんだが、
ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
ただ、HTMLベースでやると、君みたいに暗記主体の積み上げ方式で出来るのも事実なんだよ。
だから、君のタイプは今後ともjQueryを使い続けた方が効率はいいし、おそらく君はそうするだろう。
一方、ある程度の能力を備えたプログラマにとっては、抽象化が使えるCSSベースの方が効率がいい。
そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、
強烈に嫌う奴も出てくるわけでさ。
同様のことはPHPにも言える。
PHPも仕様が糞すぎて、いちいち場合分けが必要になり、プログラミング上級者でも綺麗に書けなかったりする。
だから、上級者こそPHPを目の敵にする。
ところが、初心者～中級者成り立ての程度なら、あれくらいのベタさ加減が丁度いい。
そして、自分達よりも綺麗に書ける上級者が存在しないから、彼等にとってはそれなりに快適な状況になってる。
ただ、上質なコードがその世界に存在しないことは本当に問題で、
結果、上質なコードを見たことがないから、PHPerは自分達のコードがトンデモだ、ということに気づけないでいる。
それがPHPerがやたら叩かれている理由だよ。
彼等の自己評価と、外部から見た客観評価に、ズレが有りすぎるのさ。
ま、これは正直、俺はJavaScripterにも当てはまると思っているけどね。
分かるか？両者が矛盾しているわけではないんだよ。
jQueryを使った方が効率がいいタイプもいれば、jQueryを捨てた方が効率がいいタイプもいる。
暗記ベースなら前者で、抽象化ベースなら後者だ。そして一般のプログラマは後者なんだよ。
だから今後ともjQuery不要論はずっと水掛け論になるんだよ。
言ってしまえばお互いポジショントークをしているにすぎないから。
ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、
CSSで行ける奴、或いは両方とも出来る奴は、CSSベースを選択することになる。
結果、HTMLベースの奴は取り残され、馬鹿にされるポジションになる、というのが俺の見立てであってさ。
>>360 > ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
お前、論理的な思考が出来てないなｗ
俺は覚えることが重要だと言ったが、抽象化能力とその応用力が不要などとは一言も言ってない
また暗記とは言ってない。細かい違いだが、どんな機能があるか覚えていればいいだけ
暗記（何も見ないでかけるようにしろ）とまでは言ってない
覚えることが重要だと言ったが、お前は覚えることは重要ではないと言うわけか？
少ない語群だと、文章を適切に伝えられないぞ
数学で数式を使うのは、短い文章（数式）で正確に意味を伝えるためだ。
数式を覚えてないなら、長い文章を読み書きしなければいけなくなる
それをソフトウェアでは「冗長」という。
「冗長」はバグを増やしテスト時間を増やすことにつながる
jQueryはその「冗長」を減らしてくれる。
> ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、
> そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、
あとPHPのはないウザい。関係ない話だろ。
あとjQueryのはないウザい。関係ない話だろ。
jQueryはJavaScript用のライブラリなので関係あり
jQueryはJavaScript用のライブラリなので、jQueryの質問はjQueryの仕様による。JavaScriptの仕様から求まるものではない。
↓の専用スレに行け。なんで行かないの？
+ JavaScript & jQuery 質問用スレッド vol.8 +
http://2chb.net/r/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およびCSSが上流に来ているから。
HTMLは文章は変わるが、HTMLの構造は一旦決めたら変わらないんだぜ
> CSSベースってのは、CSSクラスをまず設計して(マスタはCSSクラス)、それに対してJavaScriptを書き、
jQueryとCSSは非常に相性がいい。
>>329 を見ればわかるが
> 世界の大半を占めるウェブサイトは
> 「まず最初にHTML+CSSを書く」ということを
> しっかりと認識するようにな
最初に書くのは「HTML+CSS」だ
俺はHTMLを書いて、それに対してjQueryで処理しろとかいう話はしてない
何故か勝手に俺がHTMLベースだと決めつけられたｗ
jQueryはCSSベースになるし、CSSベースはjQueryと相性がいい
まあ、君は、他のサイトをよく見て学べばいいと思うよ。多分それで解決する。
バカかなこいつ。jsで書かれたライブラリなんだからjsでできることをまとめた関数以上でも以下でもない。
自分が依存してるホスト言語様にケンカ売るとかｗｗｗ何様のつもりだよ替えのきくライブラリのクセにｗｗｗｗ
>>378 > わざわざSizzleというセレクタライブラリを内包しているのになぜ？
1. 昔はブラウザにquerySelectorが搭載されていなかった
2. ブラウザ間で対応しているセレクタの違いに対応するため
3: :has擬似クラスのような今のブラウザ使えないが、標準化される見通しのセレクタに対応している
4. :inputセレクタのようなjQueryによって拡張された便利なセレクタが使える
5. セレクタの拡張機能を使って独自のセレクタを作成可能
6. 特定ブラウザのセレクタバグの回避
こんなところかな
>>378 > jsでできることをまとめた関数以上でも以下でもない。
焦点は同じことをいかに楽にできるかどうかだよ
>>377 > まあ、君は、他のサイトをよく見て学べばいいと思うよ。多分それで解決する。
どのサイトでもjQueryが使われてる
それを見てよく学んだｗ
JQueryはWeb業界のCOBOLとして残るやろ
COBOLとの違いはDOMよりも優れているってことかな
jqueryはEventEmitter的なやつが入ってるも便利なんだよなあ
ブラウザ非互換の対応をしようとすると結局ライブラリ作る羽目になるんじゃないの。
.ready()みたいなやつを自分で書くのが地味に面倒
自分とこはもう全部type=moduleでやってて
とまあ、ウェブサイトではまず使わないCanvasとか言ってる時点で
>>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を初めて、まだキャズムを越えてないから大騒ぎしてる、ってとこか？
ゲームだけでは無いよ
>>391 > だからお前はHTMLベースだし、大半のjQuery使用者もHTMLベースなんだよ。
CSSベースだってｗ
jQueryがCSSと相性がいいのわかってるだろ？
それにDOM APIはHTMLベースってことになるのわかっていってるのか？
>>391 > 脱jQueryをやったサイトを確認して、(最近ならGitubか？）
> 何故彼等はそういう判断をしたのか、結果、どう変わったのか、
どう変わったのか言ってみ？
俺、変わった所、全然わからない。
>>392 > アプリケーションプラットフォームになったという認識で作ってる
アプリケーションプラットフォームとしても使えるようになったからって
俺もアプリ作るぞーってなると思う？ｗ
上の方でも言ったけど、ウェブがアプリケーションプラットフォームとなって
変わるのは、ウェブサイトじゃない。
デスクトップや家庭用ゲーム機やスマホアプリの世界から
人が去っていくことになるだけだよ。変わるのはそこ
ウェブサイトは今のままウェブサイト
>>393 その意図的な誤用は止めろ。
「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。
HTMLベース：HTMLがマスタ
CSSベース：CSSクラスがマスタ
> それにDOM APIはHTMLベースってことになるのわかっていってるのか？
そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。
とにかくお前は他人がどういう作りにしているか、学んだ方がいいと思うぞ。
>>394 GitHubについてはスゲー変わったけどな。
分からないのなら、それでいいと思うよ。
ただ、変わった原因はjQueryでもないとも思うが。
GitHubは元々がポンコツすぎた。
いい加減誰が何主張してるのか追う気も無くなってきたけど、結局どうしろと言ってるの。
> 「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。
>>392 > vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
これだよね。
フレームワークが流行らない一つの原因は、自前で用意しても出来てしまうこと。
> アプリケーションプラットフォームになったという認識で作ってる
プログラマはその認識で正しいと思うぜ。
ある意味、ドキュメントも、
・マークダウン等でHTMLを直接記述（少なくともHTML生成までは面倒を見る）…旧来手法
・テキストだけ書いて、ドキュメントアプリに流し込めばWebページ完成…アプリ的手法
があって、後者はブログなり静的HPフレームワークになるわけだが、
記事書きたい奴はhtmlを書きたいわけではないから、自然と後者によってくると俺は見ている。
とはいえ、そういう時代になっても、
とりあえず1回書けばいいだけなら、HTMLじか打ちの方が楽だし、旧来手法もある程度は残るだろうね。
jQueryはCSSベースなのでCSSと相性がいい。
HTMLベースとかCSSベースってのもどういった概念を指してるのかわからないけど、セレクタで抽出したエレメントを操作するのがHTMLベースで、CSSクラスの定義を操作するのがCSSベースってこと？
アプリケーション開発のプラットフォームは
>>402 jQueryはCSSでも使われるセレクタに対して処理を適用する
だから最初にCSSのクラス設計を行う必要がある。
だからCSSベースらしいｗ
>>399 jQueryおじさんは、違いの分からない男であったか…
（もっとも、このスレにはこれが分かるおっさんの方が少数派の気もするが)
つか、あれで分からないのなら、感度がないんだよ。
こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。
>>405 いや、お前がやるべきはぐちじゃなくて
俺が言っていることへの指摘だろう？
結局何も言えない。
githubもjQueryやめた効果を何も書いていないｗ
>>404 セレクタに対して処理をするんじゃなく、セレクタでセレクトされたエレメントを操作するんだよね。
んで
>>397 で言ってるクエリ自体をやらないってことは、セレクタでエレメントを抽出せず操作するってことじゃないのかな。
とするとDOMは操作せずスタイルだけをいじるって趣旨なんじゃないのかな。
早い話、セレクタで操作対象のDOMエレメントを抽出した時点でHTMLベースだという主張ではないのかね。
> こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。
>>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は文書のための規格として始まったけど、
> 今ではそうじゃないじゃん?
なんで技術主導で考えてるんだよｗ
一番最初に来るのは「要求」何をしたいかだ。
いくら何かができるようになったとしても、
それを使ってなにかしたいという「要求」がなければ使わない
新しいことができるようになったからって
誰もが新しいことするわけじゃないんだよ。
スマホができたからって、誰もがスマホアプリ作ったりしないだろうが？
ウェブをアプリプラットフォームとして使いたいと思ってるのは
今アプリを作っている所で、ウェブサイトの世界からすればよそ者
> 別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
>>412 言う必要なさそうだが、その解釈であってる。
HTMLがマスタデータだから、更新時にはHTMLを更新しなければならない。
CSSクラスがマスタなら、更新時にはCSSクラスを更新(add/removeまたはスタイルリスト操作）することになる。
まあこの「CSSベース」が分かりやすい呼称かはさておき、
マスタデータが○○なら、○○ベース、と呼んでる。（今ここでは）
>>412 > そのコードで言えば $('.foo') でセレクトされたエレメント（達）に対して .css({ color: 'red' }) という操作をしてるんでしょ？
だからjQueryはそういう発想で使うものじゃないってこと
間違った発想で使ってるやつが非常に多いのは事実だがね
だからjQueryはHTMLベースとか言い出すアホがでてくる
内部はそうなっていても、jQueryは宣言型として考えることができるようになってる。
ループも条件分岐も書かなくて良いようになってる
だから同じ宣言型のCSSと非常に相性が良い
jQueryはCSSベースなので、具体的なHTMLタグのことは考慮しない。
>>410 CSSベースのアプローチの真髄が分からんのだけど、HTML の構造に縛られなくなっても CSS の構造に縛られるようになるんじゃないの？
改修する時にはどのみちどちらかには手が入るからJS側の調整も無くなるわけじゃないだろうし、やりたいことの全部が CSS だけでできるわけでもないだろうし。
まあエレメント抽出なんてする必要が無いと言ってるわけじゃなく、基本をどっちに置くか程度の話だと思うけど。
まあおれも何するにも $('.foo') で始めるのはどうかと思うよ。コスト的に。
でも操作対象は明確だから、書き方としては悪くないと思う。
>>416 なんか書き方で言ってるのか動きで言ってるのかの違いっぽいのかな。
おれは書き方は結構スマートだと思うが動きを考えると使う所を選びたいといった感覚だけど。
もう少し具体的に書くと、例えばA要素に対してhoverしたときに色を変えたい
>>406 >>408 お前はまず全部読んでから、整理して回答する癖を付けろ
> なんの話？
GitHubの話に決まってるだろ
>>409 なるほど君は典型的なjQuery廚か。まあ、この点は分かりやすくていいね。
そうだ。それがjQueryの典型的な書き方で、結果、ものすごくもっさりするのも事実だ。
そしてjQuery厨は君のようにそれを「大正義」だと思っているらしく、
どんなにもっさりしていてもその書き方を止めない。
「宣言型」だからこの書き方の方が素晴らしい！と本気で勘違いしてる。
ただ、プログラミングってのは手段であって、目的ではない。
ユーザーは、そのサイトが快適かどうかは気にするが、中身のソースコードなんて気にしない。
宣言型の方がソースコードの管理は楽だし、HTMLベースの方がデバッグしやすいのも事実だが、
ユーザーエクスペリエンスを損ねるようでは意味がない。
ただ、CSSベースでも宣言型ではあるし、実際そんなに難しくもならないから、まともなところは既に移行済みだ。
そしてjQuery廚だけが取り残されつつある、というのが今だね。
そういや、仮想DOMは最終的に遅いっていう話があったな
>>421 > そうだ。それが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; } だったとして、
>>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を縦横無尽に弄ろうとするから複雑になる
>>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を使ったときに発生する問題が全て解決されるってわけ
どや？ｗ
DOM APIの問題をあげたようだが、
>>432 それはjQueryの使い方でも使われ方でもないな
jQueryに限らないけど君みたいな大好きマンが語ることって、
もちろんそれは君の好きにしたら良いし否定はしないけど、やっぱり例外的なんだよ
コンポーネントで組むならそれ専用のライブラリを使うほうが絶対にいいし
一部に使うにしろShadowDOM然り相性が良いとは消して言えない
気軽で便利さが取り柄のjQueryのようなライブラリで、
考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
jQueryは正に比較的小規模なサイトでパッチを当てるような勢いで
縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ
> 気軽で便利さが取り柄のjQueryのようなライブラリで、
> 考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
はっはっは。
つまりお前は、jQueryは気軽に使うもんだ。気軽に使うから問題出るやろ
って言ってるわけか。
全てお前の使い方が悪いんじゃないか
見ての通り、お前が上げたDOM APIの問題がすべてjQueryで解決していることを示した。
>>425 で（DOM APIの場合は）
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、
～略～
> 結果、イベント起動部分のコードは全書き換えに近くなる。
といっているが、jQueryならたったこれだけだ。
> $('.foo').on('click', ・・・) とあったら
> $(document).on('click', '.foo', ・・・) と書き換えるだけ
イベントハンドラのコードは全く変更がいらない
イベントハンドラのコードは全く変更がいらないと書いたが、
結局さ、CSSベースでJavaScriptを素敵な使い方をしようと思えば
どこまで行っても所詮jsのライブラリだからな。jsでできる以上のことはできない。
> どこまで行っても所詮jsのライブラリだからな。jsでできる以上のことはできない。
>>439 > 「jQuery設計した人はなぁ！すごいんだぞ！頭いいんだぞ！だから俺にひれ伏せ(?)」と主張しているにすぎない。
いや、人の自慢はしてないぞｗ
（褒められたことではないが）jQueryの作者の名前知らないｗ
純粋にjQueryというライブラリ、その設計が素晴らしいと言ってるだけ
DOM APIの様々な問題（を都合よく語ってくれたのでｗ）それを解決している
>>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で解決すると、意味がないといいはる。
発言に矛盾が生じてますねｗ
>>443 お前はマジで日本語をもう少しちゃんとやるか、半島に帰れ。
俺は、
> 問題がある
なんて言ってない。
というか、お前が必死だったのはここを読み間違えたからか。
> 俺は歴史はあまり知らないが、どうやらCSSはかなり初期からあったのに、
> 「CSSでスタイルしようぜ」なんて言いだしたのは最初からでもないだろ。（特に国内のサイトは酷かった）
知らないなら言わなきゃ良いのにｗ
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.
なにか言うたびに墓穴をほってるんだから、もう止めたら？ｗ
>>444 ほー、ってことは
jQueryを使わないと
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
が問題はない と、そういったわけですか？
でも、jQueryを使うとがらりと変わることは無いってことには
異論はないわけですよね？
> そしてCSSベースでがっちり組んでる奴にはjQueryのメリットなんて全くないから、
>>425 > そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。
それは問題はなにもないってことじゃないんですか？ｗｗｗ
>>445 > なにか言うたびに墓穴をほってるんだから、もう止めたら？ｗ
お前がな。
https://mayonez.jp/topic/1758 使えなかった当初はさておき、海外のCSS対応に比べて国内はものすごく遅れた。
これをお前は知らないのか？
だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする？
>>449 そのリンクを持ち出してきて、お前が何を言いたいのかが
まーた書かれてないんだがｗ
> だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする？
なろうとしてないよ？お前がなろうとしてるはずだって思いこんでるだけ
俺は今までずっとjQueryの技術について話をしているのに、
お前は、俺のことばっかりだよなｗ
jQueryそのものに対しては、遅れてるだとか誰も使ってないだとか
そんな根拠のないことしか言ってない
一つぐらいお前が
>>425 で書いた問題（問題じゃなかったことにしたんでしたっけ？ｗ）
について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年って答えなかったっけ？ｗ
そうだね。結論が出るまで10年後ってレスしてるね
>>456 後で書き換えるかもしれないから、あとで書き換えなくて良いように、
必要ないかもしれないのに、煩雑になるコードを最初から書いているってさ
YAGNIな俺とは正反対だねｗ
>>457 日本語でおk
つかマジでそんなこと言ってないだろ。
もう、空回りしてる部分についてはこちらからはフォローしない。キリがないし、意味もないから。
内容を把握出来るまで何度でも読み返し、整理してから回答しろ。
> つかマジでそんなこと言ってないだろ。
引用しかしてませんが？もう一回引用したら良い？
>>425 より
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。
>>451 より
> 実際は最初からそう書くから、書き換えなんてしない。
全書き換えに近くなるから、書き換えしなくてすむように
最初から
>>425 のように書くんでしょう？
フレームワークがよくわからないのですが
>>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は作りやすくなると自称しているが、ウェブサイトには適していない
ウェブアプリとして作りやすいようになっているフレームワーク
訂正
>さらにこれらのフレームワークはSPA（single page application）が基本となってるから、
>>469 可能か不可能かじゃなくて難しいって話をしている
例えば既存でサイトが既にあったとして
URLを変えずに1ページずつ移行していきましょうとか大変
prototype.jsからjQueryへの移行のときとか、
なんでいきなり移行する話になるんだか。
463です
>>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が一番再利用性が高いということになる。
別ページなんだから「全部いっぺんに」変える必要もないんだが、どうしてもそこが理解できないようだな。
>>493 それ何度も言ってるが、お前意図的に間違えてるだろ。
或いは、実はお前は英語が読めなくて、マジで勘違いしてるのか？
>>496 じゃあ、お前が本当はどうなのかを書くべきでは？
「お前は間違ってるー」「お前は間違ってるー」って
叫んでも、説得力無いんやで？
>>495 だからすでにあるWordPressの一部に何かのフレームワークで作ったものを混ぜたり
あるフレームワーク作ったものを、他のフレームワークで使ったりするってことだよ
コンポーネントっていうのは、そうやって他の人が作ったものを使うってこと。
混ぜて使えないなら、そのフレームワークで全てを構成しなきゃならない
ってか、混ぜて使えないから、そうやって言い訳してるわけなんだろうけどねｗ
いちゃもんおじさんが来ないので、jQueryとCSSの相性と https://jsfiddle.net/rueg1xv2/ 全部nanoやumbrellaで出来るな。
>>500 > 全部nanoやumbrellaで出来るな。
みたいね。ここに書いて
なんだnanoもumbrellaも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もかな？
> 他の人とお前が話が通じてないのはそのためだ。君が分かってなさすぎる。
どこがわかってないかの指摘がない。そういうことにしたいという希望
> ただそれ以前に、君は日本語が怪しいから、そこをまず詰めた方がいいが。
同上
まとめ
・新しいもの、新しいもの、と言ういうだけで成果がない
・技術に対して客観的な意見を言わない（速ければ良いわけじゃないってわかってるだろうにｗ）
・俺への指摘は、どれも根拠がない。（単なる個人攻撃）
■
>>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も自然な流れであってさ。あれは、意識高い系が、って話ではないんだよ。
わざわざ言うのは、意識高い系がって思ってる証拠だな
これは「反論」ではなく「解説」であることに注意なｗ
別にjQuery信者がどう考えてどう主張してどう使おうがどうでもいいじゃん
高い品質を求め続けて死んでいった日本の製造業みたいな考え方
>>507-512 お前にはそう読めるのだろうが、普通の人ならそうは読めない。
例えば、
> > 同じ事を俺だけでも何回も指摘済みだが。
> それがどれかを書かない
直前の行に書いてるだろ。再掲すると、
>
>>497 >
>>103 > 同じ事を俺だけでも何回も指摘済みだが。
103に決まってるだろ。
いまいちお前の頭がどういう風に障害持ちなのか分からないが、
どうやら君は非常に断片的にしか読めなくて、
これまでは2行単位でしか読んでなかったが、今はもう1行単位でしか読めなくなってる。
そして直前の行すら無視するのだから、話が通じるはずがない。
それでは一般の文章、例えば公式の紹介文も読めないと思うが。
ただお前のタイプ、リアルで遭遇するのは（俺には)ないが、ここ(2ch)で遭遇するのは3人目だ。
(お前が前から居るのは認識していたが)
何か2chにそういうのを集める理由があるのだろう。
もう少し軽度な奴、4レス前までしか追えない奴もJavaScriptスレの周りにいる。
ただこいつは4『レス』だから『忘れっぽい奴』位で対応出来るが、
さすがに直前の行も読めないようでは話は無理だ。空回りしすぎる。
>>513 多分、俺達が古いものをいつまでも使っていたらウェブが発展しない！
俺たちがウェブを変えていくんだ！とかいう謎の使命感（笑）に燃えてるんだと思うｗ
新しいものと速いことに執着しているのがその証
こっちは適切なタイミングで適切な道具を使うだけなのにね。
>>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を使用してるサイトも同じだけ増えたｗ
って感じだなｗ
>>520 にはJavaScriptを使ってないサイトはデータとして出てきてないね
HTMLとCSSだけのページも相当数あるだろうにそのデータはないのかな？
それがないとJavaScriptライブラリを使わないで、
JavaScriptを使ってるサイトの割合はわからないね
訂正
ライブラリ未使用とかこだわりポイントが意味不明
> そういう点でjQueryって組み合わせづらくて古臭いねって言うのだけは分かる
>>520 相変わらず意図的に間違えてるよな。
いや実は素で間違えているのかもしれんが、多すぎて意図的だと読めるんだよ、普通の人には。
まあもういいが。
>>523 > ライブラリ未使用とかこだわりポイントが意味不明
彼等はそこにこだわっているわけではないと思うが。
結局この話題はひたすらに水掛け論だな。
本来は、「なければないでも出来るが、面倒だからjQueryを使う」というスタンスが正しいのだが、
jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。
ま、結果は待つしかないし、待てばいいだけだが。
「jQuery、いつ止めるの？今でしょ！」な人が今止めてるだけ。
GitHubも公式声明出しているが、当然だがプログラマ目線だ。
https://githubengineering.com/removing-jquery-from-github-frontend/ 実際の所、1回作って終わりのWebページならほぼどうでもいいのも事実だし、
彼等が脱jQueryするかはまた別の問題だ。
ただ俺は、デザイナが無理してJavaScriptをいじること自体が間違いだと思っていて、
今のところ静的HPフレームワークに吸収されるのではないか、と見ている。
WordPress等も普通なら吸収する方向に動いているはずだが、そうでもないのか？
>>525 > 相変わらず意図的に間違えてるよな。
いつもどおりですが、どこをどう間違えているかを言わない。
> jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。
誰もそんな事は言ってない。いつもの思い込み。お前の願望。
話が進まないのは、お前が答えるべきことに何一つ答えないからやで
毎回毎回。答えない。言わないと。俺が教えてやってると言うのにｗ
> ま、結果は待つしかないし、待てばいいだけだが。
もう3年待った
> 「jQuery、いつ止めるの？今でしょ！」な人が今止めてるだけ。
あ、止めたんだｗ 飽きたんだね。ネガティブキャンペーンに
> GitHubも公式声明出しているが、当然だがプログラマ目線だ。
見るのはそこじゃない。本来書いてあるべきことのの
「やめてどういうメリットがあったかが書かれてない」ってのが重要
あれ読んでも「あ、やめたんすね。GitHubレベルの技術者でも
大変で時間がかかったんですね。メリットは？」って思うだけ
>>526 > ねえ、これいつまで続くの？
jQueryの使用率が今より10%さがるか、Bootstrap、Modernizer、Underscoreを除く
他のUI関連のフレームワーク・ライブラリの使用率が10%を超えたらかな
（なぜこの3つを除くかというと、Bootstrapは本来CSSフレームワークで
JavaScript部分にはjQueryを使っているから。Modernizerはブラウザが搭載している
機能判定をする補処的なライブラリでそれ自体で何かをするものじゃないから。
Underscoreは古いブラウザでも使える関数型風のライブラリでUIとは関係ない。
そして俺のお気に入りの一つだからｗ）
あいつがやめなくても俺がやめてあげよう。
だからすぐだよ！（皮肉ｗ）
https://github.com/twbs/bootstrap/issues/23204 によるとjQuery外すつもりだが人手が足りなくて無理らしい。Please help!とか言ってるわｗ
>>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 https://jsfiddle.net/x7nvc4og/ https://developer.mozilla.org/ja/docs/Web/API/Event/target https://jsfiddle.net/26Lw4kdg/ 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レス以上必要だからだ。
一つも修正してないじゃんｗ
なんでDOM APIとの互換性を考慮する必要があるの？ｗｗ
>>540 > なんでDOM APIとの互換性を考慮する必要があるの？ｗｗ
> jQueryで全部できるんじゃないんですくぁ～？ｗｗｗｗｗ
だから、アンチjQueryが、jQueryを使っているならば
全部jQueryの世界で閉じてるはずだ！
jQueryで全部できるんじゃないですか～って
思ってるのがそもそも間違いってことだよｗ
jQueryを使ったプログラミングでは日常的に標準のDOM要素を使っている。
実際にonのイベントハンドラ内のthisとかDOM要素なんだから。
jQueryは設計の時点で、標準のDOM要素を使うことを想定してある
それを知らないで、コードを上っ面だけ眺めて、全部jQueryでやってるように見える。
これ全部jQueryの世界だ。DOM APIの世界と全く違う！独自の世界だ！！
なんて言ってるから、呆れるわけでｗ
そうだ。良いことを思いついた。
NodeListには全くタイプの異なる要素が含まれる可能性がある
>>543 http://api.jquery.com/jQuery/#jQuery-object 上でjQueryには配列で管理していると書いたが、
これは、ダックタイピングの考え方そのものだよね
型は関係ない。使用するメソッドさえあればいい。
jQueryはDOMを扱うライブラリだから、
DOM要素でなければ引数に出来ないと思い込みがちなのはわかる。
だけど、jQueryで提供しているメソッドこそ、DOM操作用のメソッドってだけで
単一の要素を配列として操作するという設計は、DOM専用のものではなく
DOM以外にも適用可能なわけだ。
まさにこのような使い方ができる通り
$(["red", "blue", "green"]).len();
貼り忘れていた。実際に動くサンプル
https://jsfiddle.net/vxpk0yef/ まあ、よくよく考えてみると、
>>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を抜いています）
クロスオリジン要求をブロックしました: 同一生成元ポリシーにより、
https://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", "
https://ext.nicovideo.jp/api/getthumbinfo/sm500873", false); // ←エラー h抜き
req.send(null);
}
実際にアクセスしたいAPI
SOLD OUT 2 API
https://so2-docs.mutoys.com/common/api.html コードが間違っている
API側で許可されていない。普通は使う側がセキュリティを切る
その他
どれでしょう？
>>553 とても明確に理由が示されているのだが > CORS
下のSOLD OUTの方がどうなってるかは知らん
CORSについてはブラウザでやるのを諦めるのが正解
>>554 レスありがとうございます
ニコ動のAPIのように公開されているものでも、CORSは許可していないということですか？
API公開≒CORS許可で、こちらに何か足りないと思ってました
保存したものなら大丈夫なので、保存だけ別の方法を探してみます
ログインすりゃ使えるんじゃね？知らんけど
基本的に外部サイトへのリクエストはセキュリティ上の理由で禁止されてるんだけど、それを許可するのがCORS
>>557 なんやこれ便利すぎるｗｗｗ
jQuery糖質キチガイに辟易しながらもこのスレ覗いてて良かったｗｗｗｗ
>>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の事だぞ。
> いやモロに書いてるがな。
訂正
>>563 お前もいつも通り連呼リアンだよな。
普通は562は「リンクを示した」と言うぜ。
お前、煽り抜きで頭おかしいと思うぜ。マジで池沼。
同様の奴が他に2人いると書いたが、お前が一番程度が酷い。
さすがにそれだとリアルの普通の会話も成立しないだろ。
>>564 英語読めるつもりなんだろ？自分で読めよ。
というか、あれ、脱jQueryが気になる奴は、読む価値はあると思うぜ。
お前は読んでも全部読むうちに忘れちゃうんだろうけどさ。
それでもお前の頭は交換不可能で、お前自身で鍛えるしかないんだから、
無い頭使って一生懸命読めよ。
それを繰り返してたら、お前のその頭も少しはましになるよ。
なお、GitHubの公式声明の内容は割と普通のことなので、
だから、GitHubの声明には本来書いてあるはずのjQueryをなくして
>>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 )に反論しただけなので、あなたのは論点がずれてる
そうだね。俺のレスへの返信じゃなかったわｗ
俺はDOM API不要論者じゃないので。
俺は
>>550 にも書いてあるように混ぜて使って良い派
むしろ普段から混ぜて使っているんだよ派か
（jQueryで出てくるthisはDOM要素だから）
オリジンが違ってもアクセスはできるだろ
アクセス拒否されるし取得できない。
何いってんだコイツはお前だアホ
await fetch('
https://developer.mozilla.org/', {mode:'no-cors'})
アクセスしてるだろうが
もし拒否されるのならServiceWorker導入ページでどうやって
外部リソースをリクエストしたりキャッシュしたりするつもりなんだ？
人様にケチ付ける前に自分が無知であることを知れよ
元々の文脈考えたらアクセスできない、で良くね？
>>579 そもそも文法エラーだなそれ。
出直してこいｗ
> 人様にケチ付ける前に自分が無知であることを知れよ
>>580 元の文脈的にサムネイルとかのメディアデータへのリンクが分かるのなら
それはimgやvideoタグで表示されられるかも
JAVAscriptと書くのは普通ですか？
勉強にのためにライブラリのjplayerを解読しようとしてるが
jQuery使わなかったらもっと難解になるんだよな
>>588 覚えればすむものは楽なんだよ。
単に覚えればいいだけ理解すればそれで終わりなんだから。
大変なのは
>>589 みたいなもの。ありえないほど短いコードで
実現しているから凄いといわれるけど一般的にはクソコードと言われる類。
なぜかというと、コードというのは簡単に読めるものじゃないといけない
もちろん知識をつけたもの、能力がある人にとってね。
知識があって能力がある人でも読むのに時間がかかるような
無駄な処理ばかりで何をやってるか分からないようなものは大変
それが「解読」という作業。これはコードに問題がある。
知識がなくてわからないのは解読じゃなくて単に読めないだけ
読んでる人に問題がある
7行テトリスは、まるで暗号
やっぱ、オレの勉強不足だな。
仮想DOMは、なんでDOMを全部再構築するというアイデアが
部分更新も、複数回のDOM操作がinnerHTML差し替え1回で済ませられたらメリットはあるんじゃね。
複雑になってくると毎回全部再構築した方が楽だと思うけど
推薦書
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 は典型的な勘違いして垂れ流してる初心者だなｗ
こんなのよりReact登場初期の、初心者が知ったかでイキってられない時期に書かれた記事読んだ方がいい。
「今までは、基本的に受け取った情報を元にDOMを
SPAにページ遷移という概念が存在するとは限らない
あれ？いつもの奴ではない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のアップデート共に改善されて最終的には限界まで端折ることになる。
この辺の、改善を外部のアップデートに期待出来ることも、フレームワーク等を導入するメリットでもあるだろ。
その記事内にもあるが、
2つ目の記事ではサーチのサジェストが例に挙げられている。
> であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
>>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ロック状態はあまりよろしくはないと思うぜ。それもまた自由だが。
いちいち長すぎだろ…要点まとめるぐらいできないのか
ブラウザにやらせるべきって言ってもブラウザ側にも限界があるし
>>619 現状のフレームワーク等はいい実験をしているとは思う。
ただ、描画に関してはブラウザの方が主管なので、本来は丸投げ出来るべきだ。
現行のAPIを組み合わせてもこれは無理だから現状は致し方ないとしても。
> PauseFrame
使いどころは、
A. ajaxで将来的に書き換えると分かっているframeを停止する
B. 画面外のframeを停止する
として、AはJS側でいいが、Bはブラウザが勝手にやるべきだ。
根本的な問題は、CSSが全く拡張不能なこと。CSSで
・pause: auto ならオフスクリーンの場合はpause『してもよい』
という拡張が出来れば、これが一番自然だ。仮想DOMについては、
・draw: lazy でオフスクリーンなら描画『しなくてもいい』
となる。ここら辺まで出来れば、
フレームワーク導入コストはほぼ０となり、もっと面白くなるのだけどね。
>>620 俺の考えとしては
ブラウザは勿論最大限努力すべきだけど、プログラマがどんな書き方をしていても理論上最善に近いパフォーマンスをしてくれというのは明らかに無理があるし、
一方ある程度はブラウザ側がパフォーマンスのための機構を提示して、プログラマ側の努力を求める事も仕方ないと思う
また別の話として、CSSも数年前からJITが入ったり、ブラウザがよしなにやってくれる感は確かに高まっているけど、それと同時にHoudiniだったり従来よりローレベルな環境が提示されるようになってきておりプログラマの責任も高まってる
で、結局のところ、重要なのはJavaScriptでいろいろ解決しましょうじゃなくて
>>623 バカ？w
ほとんどのサイトは静的なページで事足りる
>>621 考え方は間違っていないと思うけど、ちょっと混線してるかな？
自前で遅延/選択的描画を実装すると糞コードになるのは、
OOPで言うと、本来はオブジェクトA（ブラウザ）で完結する処理をオブジェクトB(JS)で無理に行っているからであって、
俺はそこを何とかして欲しいんだよね。
フレームワークに押し込んで隠蔽する、というのも一つの手ではあるけれど。
そちらのレスについては、単純には、
・馬鹿な書き方でもそこそこ速い
・チューニングしまくれば超速い
が通常目指すべきゴールだ。ここまではいいよな？
どちらを目指すべきかだが、両方追っかけているC++が若干迷走気味なので、
本当はどちらかに絞った方がいいんだよ。
Houdiniってことはゲーム畑に近いと思うけど、それなら当然後者を目指すべきと考え、
レンダリング制御関連のAPIがほぼ無いから困っているとは思う。
しかしそれは、APIさえ有れば十分に制御が出来る腕前があるからであって、
実際のWeb系はそこまで到達してない奴の方が多いと思う。
jQuery廚がよく言う「jQueryは簡単！」（＝馬鹿でも問題ない）というのは実は偉大なことであって、
これ自体は素晴らしい。
(jQuery廚の問題は、結局そこに乗っかってしまっていて、結果、馬鹿なままな点であって)
俺個人としては、手を抜けるところは抜きたいので、前者に寄って欲しいんだけどね。
実際は後者に寄っている気はする。
というか、前者を実装するにしてもAPIが必要だし、普通はまず後者を実装するしかないからね。
ゴリゴリの制御が要求されたとしても超高速化したいのなら、技術的にはC++側にコードを注入出来ればいい。
昔で言うアドオンをサイトから毎回ダウンロードして使う、というイメージだ。
アドオン自体はサンドボックス上ではなかったので排除されてしまったが、サンドボックス上にすれば行けるはず。
WebAssemblyが近いが、あれはJS側上のサンドボックスのはずだから、あれのC++側版だね。
3Dグラフィックスの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を弄らないって意味ではないの？
いやでも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がパフォーマンスの全責任を負うのはそれ以上に『原理的に』無理だ。
強いて言うなら、現状のブラウザは十分高速で、１ページ程度ならレンダリングは一瞬だ。
遅いのは無駄に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をそのまま返すのが静的ページ」
>>639 > Webは一度APIを入れると中々消すことができない
> だけど流れは早いので慎重に進めすぎるわけにもいかない
これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
そしてWebが速いって言ったって、結果出来上がっているのはゴミの山であって、
進歩(＝成功したパス＝使えるものとして残った経路）だけ見ればC#の方が断然速い。
事実として今のJavaScriptはC#の後追いでしかないだろ。
> それを両方解決できる人間はこの世にいない
これは「創始者」がこれに近いものとして振る舞う、というのが他言語/OSSの習わしだ。
この点、ブレンダン・アイクが全く出てこないところがJavaScriptの不幸な点ではあるけれど。
とはいえ、現状で現実的判断をするなら、君の言っている方向性しかない。
ただ、カオスにはもうなってると思うけどな。
○○ってフレームワークはどうですか？みたいな質問ばかりなのがそれを如実に示してる。
標準さえ汚れなければいい、という考え方もありだが、
Promiseは要らない子だと俺は思うし、防波堤になりきれてない。
> 君がそれができるというのならしてみると良い
機会があればやるかもしれん。(これは君も同じだと思うが）
俺が今フレームワークとして欲しいのは遅延描画だけで、Houdiniでは無理だからすぐにはやらないね。
ただ、どっちかと言えば俺が試してみたいのはフレームワークではなくJavaScript自体の直接的拡張であり、
JSエンジンの低レベルAPIについて提供するような方向になっているか知ってれば教えて欲しい。
例えば async とか、ああいう言語拡張をする為のJSそのものの低レベルAPIだ。
>>641 >>これは買いかぶりすぎで、「Webは」ではなく、全言語について当てはまる。
いいや、他の言語環境ではメジャーアップデートのときに互換性を壊すことができる
その場合でも旧バージョンは旧エンジンで動かせば良いのだから
しかしWebでは旧サイトは旧ブラウザで見れば良いとは言えない
JSもしかり、機能を非推奨としても、新しい機能との兼ね合いを定義しないといけないし
廃そうとしても10年以上かかる
>>結果出来上がっているのはゴミの山
WebAPIをゴミの山と言うのは流石に言いすぎだと思う
１つ１つ思い返してみても、ゴミだったねと言える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は死ね、と思ってるんだろうな）
準プロプライエタリｗｗｗｗｗ
話が長い
>>879 お前みたいなヴァカに比べたら在日はみんな天才だよ
ITオンチ丸出しの恥ずかしいロートル野郎だな
パクリ元のC#だか言ってる時点で御里が知れてる
雑誌読み放題とかのシャッフル画像を元に戻したいなら、
>>654 ネット配信の漫画の画像をコピーしようかと思ってるのですが、
ブラウザ改装って、javascriptでどうにかなるのですか？
>>653 LAB.jsを改造したのが使われるみたいです。
JSでスクリーンキャプチャしてもいいが
>>654 >雑誌読み放題とかのシャッフル画像を元に戻したいなら、
シャッフル画像ってこんなやつか、
有料の漫画発信サービスって、大元の画像ってサーバーにあると
思ってたが、こんな感じで加工して、まるまる出回らないようにしてたのか
っで、javascriptのcanvasで描画し直してユーザーのブラウザに表示してんだな
オレの仕事、工業用機械のプログラム担当だから、
web業界は知らんが、漫画発信ってこんなことしてんだな
画像でも、DL されたくない場合に、画像上で右クリック禁止などにするけど、
一旦仮想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 に教えないといけない。
bootstrapはjQueryありきだからUIは自前でデザインしないといかんね
>>667 DOM をDOM API で更新した場合は、それを仮想DOM に教えないといけない。
教えなかったら誤動作する
>>672 うーん
めんどくさいね
reactはDOM変更されたのを読み取れるから勝手に仮想も変更しといてほしいんだが
それが仮想DOMの限界なんだよ
>>674 それは仮想DOMというよりは、フレームワーク全体の問題なのではなくて？
触らずに済むように作ったら
その通りだな。
Doodle2というスクリプトから画像を描画できるCOMコンポーネントを64ビットのwindows10で使うことは無理でしょうか？
+ JavaScript の質問用スレッド vol.126 +
まずスレチすいませんでした
こういうのをどこで質問していいかわからず、もし使ったことのある人がいるならこのスレかなと思いここにしてしまいました
どうにか解決したので報告だけさせてください
>>680 すごくヒントになりました
結局dllは不足なかったことがわかり不思議でよく考えてみたところ
wscriptのほうもSystem32のものではなく、SysWOW64の32ビットのものを指定して実行したところ問題なく使うことができました
わかってみたら単純なことでしたが思いこんでました
ありがとういございました
JavaScriptの非同期の書き方がまだおぼつかないのですが
中断の伝播とか真剣にやってるとやっぱり複雑になってきたときにバグるよ
requreを使っているfile.jsライブラリファイルをインポートできなくて困っています。
ライブラリ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!
https://gist.github.com/getify/603980 JavaScript の質問は、web制作管理板の方へ書き込んでください！
こちらのスレは、答える人が少ない
>>683 頼んでいた非同期処理を、中断・取り消すのか。
そういうのは、できるかな？
「javascript 非同期処理 中断」で検索！
>>685 「javascript require commonjs」で検索！
>>686 「javascript 動的 読み込み」で検索！
>>687 document.onreadystatechange = function() {
if (document.readyState == "complete") {
$LAB (以下略)
}
}
ありがとうございました。これで動きました。
これほど書き方が統一されていない言語あるかね？
pythonは関数を書くときにdefとlambdaがある
つまり未だにアロー記法を採用してくれないPHP最強ってことだな
打つのが面倒でないならjavascriptでも全部functionで通してもええんやで。
入力補完でfunctionを打つのは楽だから、基本はfunction使う
mapとかfilterの引数もfunction渡すの？
>>695 > ワンラインで済むときと、thisを受け継ぎたい時だけアロー使う
> ワンラインで済むときと、
> 所詮(function () {}).bind(this)の糖衣構文に過ぎない。
念のため、素晴らしくないとは言ってないからな。
アロー使ったら複数行でもreturnなしにしてほしい
むしろアロー関数は1行でしか使えないようにしてほしいくらいだ
yield 文って、generator function から呼び出された普通の関数の
エラーになるかどうか知りたいの？
var aaa = func1;
function* func1() {
>>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はもう実験的にSABとAtomicsサポートしてるでしょ
>>712 wasm は、emscripten_sleep(millisecond) をサポートしてるので、もともと問題の根は浅い。
でもあなたの言ってることはSetEvent()やMutex()などの同期オブジェクトとは直接関係
ない。それに proposal 段階で、実装報告は見当たらないんじゃないの。
【数学首席のオイラが書く(言葉の美しさは知らん)】
>>715 >>715 >>716 【修正】
誤：if ( !g_bEvent ) {
正：if ( g_bEvent ) {
>>715 >>719 【修正】
誤：// 以下ループで、CPUがフルパワー状態になり電気の無駄使いになる：
正：// 以下ループで、最悪100(ms)の遅延が発生する。
>>719 いや、もう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に固執してるの？
マルチプラットフォーム環境として、wasm や JVM や CrossBrdige(FlashCC) など
Windowsアプリが移植できるかと、同じAPIを持ってる事は無関係だし、
基本的にLLVMに変換可能なプログラムなら移植できるけど
やっちゃおう、にどれだけ価値があるかわからんけどね。
WasmでというよりJSででしょ
foo =function(){}とか
jsdocって言語機能が名前から想像するよりはるかに異なるjava用のjavadocの単なるメクラポーティングだしなぁ…
iframe要素のsrcを変更したら画像のロードが終了してからloadが発火すると思うんだけど
>>733 src を変える前に iframe の style 属性を指定しておくのでダメであれば、
別に、タイマーイベントみたいなので、少し遅れてから、イベントハンドラ
の中から iframe の style 属性を変えればいいだけではないの。
エクセルのマクロとかすら使ったことがないし
>>738 確かに。
冗談のようだけど重要だな
Chromeなど開発モードがあるブラウザを使い、それの操作方法に多少は馴れておけって意味では
知識０なのに実用的なプログラムから始めるのは間違っている
マクロとしてのJSって何だよ・・・・
いや、もうやりたいことは決まってるでしょ
webpackで依存関係が数百とかなってわけがわからなくなる
みなさんありがとうございます。
Excelの表をGraphqlに変換することは出来ますか？
>>748 続き
横幅やセルの色や結合までGraphqlでもっていけたらいいなぁと思うんですが・・
質問です。下記のようなプログラムで、'テスト'をhoge内に記載する場合は
const hoge = {
>>748 gatsby-transformer-excelあったと思う
>>746-747 メソッド一覧とかプロパティ一覧、関数一覧のページはMSDNのほうが見やすかったから
索引的なページは残しておいてほしかった
エディタのマクロ書くときなんかはMSDNのほうが都合よかったので残念
Electronでクロスプラットフォームのアプリ開発の出来ることを知ったプログラミング初心者ですが、一般的なElectronの開発はVue.jsやReact.jsを併用するのでしょうか？
もうElectronは古い
React学ぶのにオススメのチュートリアルや本ありますか？
本は薄い奴が今のところ比較的新しいけど、残念なことにそれでも情報が古いからGithubのreadmeとか見ないとダメ
>>758 Q. ○○を学ぶのにオススメのチュートリアルや本ありますか？
A. 公式
JavaScript界隈の場合はほぼ全部これ。
公式読んで無理なら諦めた方がいいと思う。当然だが、
1. JavaScript界隈の場合は布教意識ありまくりで公式がかなり充実している。
2. 公式は対象技術レベルを想定して書かれている＝読んで無理ならどうせ使いこなせない。
3. 公式以外は「ぼくががんばったきろく」を残したい馬鹿ばかりで、間違いが多すぎる。
4. そもそも普通の奴は「ぼくのさいこうのチュートリアル」なんて作らない。
公式のチュートリアルを充実させる方向に参加する。したがって当然非公式サイトはおしなべてゴミ。
5. 本を書いている奴は本で食っている＝一線のプログラマではなくただのテクニカルライタであり、
売れない本は書きたくない。よってどうしても後追いになるし、技術レベルも低い。
6. JavaScriptの場合はフレームワークonフレームワークの状態だから、
はっきり言って、構想を聞いて「あ、いいね」とぱっと思えるのでなければ使う必要がない。
だから本来、対象者にはリファレンスしか必要ない。Nodeとかそんな感じでしょ。
というか、自分が知ってるフレームワーク等と比べてみたらいい。
例えばjQueryを使っている奴は公式トップの3例を見て、「素晴らしい」と思えるから使っているわけだろ。
Nodeの場合は公式トップは空で、aboutで鯖を立てる例だけ出しているが、魅力のアピールにはそれで十分なわけだろ。
同様に、reactの場合も公式トップの4例で十分だと思っているからあの構成な訳で、
それで魅力を感じないのであれば使う必要はないし、意味が分からないのなら使いこなせない。
「Reactを学ぶ」とかワケワカランな
emscripten_sleep() の以下のソース、理解が出来ない。JSに不慣れだから余計。
>>762 以下の前提がある時、
[何をやってるかの自分なりの推定]
function dynCall_vi(index,a1) {
単純にスタックを切り替えて該当処理を再開できるようにしてるだけじゃん
>>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も、全てのコードを一つの関数の中に収めてしまって、
sleepは全然複雑じゃない
> CPUを例に出すのは大間違いsleepしてもその間に別の処理が走るわけではないのだから
>>775 だからそれsleepじゃないよ
sleepはその場で停止して（他にスレッドがないならば）
他の処理に割り込まれないという特徴がある
それを実現できてない
>>776 おまえがsleepを分かってないことは分かった
>>770 どうもアホがいて空回りしそうだから先に言っておく
> 原則的には、関数の途中で無限ループ以外では停止する
> ことは出来ない。
これがasync/awaitで構文的に緩和されてる。
勿論それでもシングルスレッドだから、
実行中のコンテキスト（スタック等）の切換は行わなければならないが、
async/awaitをサポートした時点でそれはJSエンジン側の仕事になってる。
emscripten自体はasync/awaitの標準化以前から存在するから、
その部分が結果的にポリフィル的になっているのは致し方ない。
>>774 妨害してないよ
正確にはビジーループに変換されるsleepもあるけど動作には関係ない
なぜなら複数スレッドの処理が実際の１スレッドで動くよう変換されるわけではないから
むしろメインスレッドをブロックしないためにsetTimeoutが使われてる
その間に別のJSが動こうとそれは世界が違う話なので関係ない
>>778 async, await はダメだよ。
停止せずに素通りしてしまうから。
戻ってくることは出来るけど、async 修飾したその関数にだけしか
戻って来れないので、sleep には使えない。
>>780 お前が馬鹿だということは分かった
つかマジな話、お前らsleepを全く理解してないな
ただそれ以前に、emscriptenは要するにC++→JS変換してくれるわけで、
いくら天才でも正しい前提知識を持ってないんじゃ仕方ない
10000ms指定したらUIが10秒止まるクソ関数が作れるなんて聞いた事ないし
>>782 >sleepも当然サポートされていてそれなりに変換されてるだけだろ。
バグがある。
どういうときにどう上手く行かないのかを言ってくれないとな
そんな知能なさそうだし。
また数学首席くんが妄想してんの？
こいつはスルースキル特化型だな。
>>794 「スルースキル・モンスター」を説明してください
canvas の width や、グラフィック描画時の座標指定が、ブラウザの拡大率を
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的な座標の比で調整するのじゃダメなんかい
そもそもピクセルが正方形とも限らないわけで
色々試して、以下のようにすると、ほぼ 1px = 物理 1 pixel になった。
こんな方法でよい？
<style>
#div0 {
transform: scale(0.8); // 1.0 / 1.25
transform-origin: top left;
}
</style>
<div id="div0">
実際に表示したいタグ達
</div>
それでいいけど
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 >>801 のやり方だと、canvas の左上の座標が(0,0)で >>804 あ、確か逆さまだったと思う。
だから、
誤： <canvas width=aaa style="width:bbb;">
正： <canvas width=bbb style="width:aaa;">
が確か正しい。
>>805 webページでフォーム入力した項目を確認のために埋め込まれたような形で一旦表示させたいんですけど、こういうのはJavaScriptで実装するんですかね？
javascript使う
>>808 そもそも何を表示するの？
フォーム入力した項目って最初から見えてるだろ。
>>808 まず現状フォームをどうやって表示してるのか
サーバーサイドPython？
入力フォームなら値をPOSTで受け取ってるだろうから
確認画面を生成するだけなのでは
フロントでvaildateしてユーザーに伝えたいという意味と解釈したけど違った？
>>809 >>810 >>811 >>812 イメージとしては、5chのこの投稿欄みたいにフォームに入力した後に、
入力事項が画面に埋め込まれて、下のあたりに「投稿」のようなボタンが出るイメージ
確かにPOSTで受け取った内容を生成すればいいだけか...笑
サーバサイドはpythonです。
JSでもできるけど、その場合フォーム入力の内容をDBのデータと比較検証したい場合
には不向き、ということになるんですかね...?
>>813 あるサイトと同様のものをJavaScriptで得たい場合、F12を押してコードを見るのが一番早い。
つっても2chなんてゴミなので、参考にするならもうちょっとましなサイトの方がいいが。
DBと照合したいのならサーバーサイドで、君の場合はPythonでやった方がいいと思うよ。
>>814 なるほど！
どうもです！ありがとうございます！
> あるサイトと同様のものをJavaScriptで得たい場合、F12を押してコードを見るのが一番早い。
>>809 > vue.jsとか使えば楽
vue.jsの出番なし（笑）
>>819 それはある意味真実。HTMLとCSSだけで殆どのことができますっていうのが理想
>>803 dirty の意味は、汚染されている事。
つまり、Canvas のデータの事だろ
一度でも、Canvas に描いたものは汚染されるから、JavaScript のデータには戻せない。
ブラウザのセキュリティ機構をパスしていない
ちょっとググった限りでは、refreshしないといけない部分だからdirty rectangleと言われるようになった感じ？
dirty bitとかのdirtyと同じ
どうやったら習得できるんでしょうか？
>>825 > 授業だけでは
> 教科書書き写せって言われたのでしていますが
どこでどういう風に習ったんだ？
JavaScriptは比較的簡単な言語ではあるが、
授業で習った程度で出来るようになると思っている時点で大間違いだぞ。
ズブの初心者が数時間で出来るようになるのなら、専門職として成立しないだろ。
あと、どこを目指している？
コピペして必要になったら理解するための勉強すればいいんじゃね
詐欺プログラミングスクールの何週間でプロに、とか3ヶ月でマスター全部ウソだから。
>>825 読めないし意味がわからないのは当たり前だし
それをどうこうする方法もない
新しいことを学ぶというのは非常に困難なことだと理解しろ
数学や国語だって頭の柔らかい子供がきっちり何百年もかけて練られた
体系立てられた教育で１０年以上もかけてやっと習得できるものなんだぞ
つまりざっと1000時間は必要ということだ
もちろん1000時間かけても分からない人も居る
でも自分の頭を信じて、わからないものが分かるようになれると信じて
いやいや苦しいながら1000時間頑張る以外無いんだよ
とりあえずチュートリアル的なサイトを最初はコピペから一通りやる
そのときにちょっと改変してみたりしてどう結果が変わるのかから
それがどういう意味をもつ行為だったのか、そこがどういう効果をもつ部分だったのかを理解していく
意味が分からないことが100出てきたら、ググり倒してなんとかそれを99にするよう必死に努力する
多少程度分かるようになってきたらもう一度MDNのような網羅的に載っているとこをみて自分が知らない知識を仕入れる
構文やAPIは別に暗記する必要はない こういうことに使えるものがあるということをできるだけ知っておく
その繰り返し つまり基礎と応用を行ったり来たりして
段階的にではなくまんべんなく少しずつ積み重ねていき、ある時からはその穴を埋めていく
基礎はだいたいわかったと思ったら、ググって他人の書いたコードを見る
そうすると自分の知らない書き方や機能が使われていて、しかも非常に読みにくい
でもそれに慣れていく
もう一度MDNを全部隅から隅まで必ず読む
JS再入門をやってみる それで中級者
各構文の詳細をきっきり理解し、スコープチェーンやプロトタイプチェーンといった概念を学び
今まで何となく書いてきたものの真意を理解する
構文やAPIを仕様書を直接見て理解できるようにする
基本的な仕様書を一通り必ず読む それで上級者
そっからは自分の好きなコミュニティに所属して深掘りする
>>825 初心というか、新しいことを始めるときにはだいたいこんな感じ。
1) 適当に検索して必要な部品をコピペする
2) コピペ同士の整合性確保と自分の美意識に従って整形する
3) 時間が許す限り 2 を繰り返す
4) 試験する
整形するところで、たとえば未知の関数ならその役割や必要なパラメータを理解する必要があるし。
コピペを適当に順序を組み替えてみると予期しないエラーが生じることもあるから、その原因を調べることで理解が深まったりするし。
要は好奇心が自分を動かしてるんだろうな。そりゃ打ち込みだけなら眠くなるだけだわ。
たくさんのレスありがとうございました。
>>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画面出力出来ないのはほぼあり得ないし、
詳しくありがとうございます
>>836 > クラスではipadを見ながらやってるって人がいて
それと同等にはなる。
スマホだとさすがにきついと思うから、安物でいいからモニタを買った方がいい。
つか、専門学校なら最初から2画面にしとけよ、とは思うが。（君が悪いわけではないが）
> 見た目を用意するのはhtmlで出来そうですが
それでいい。
見た目だけ、例えばオセロならまず盤面をHTMLで用意するところから始める。
次に、クリックしたら石をおくようにする。つまりはクリックしたところにクラスを加えるだけだが。
そしたら、後は、「挟んだ石は自動的にひっくり返る」ようにすれば、手動での対戦は出来るようになる。
そして後はCPUで適切な手を考えられるようにすれば、CPUとの対戦が出来るようになる、というわけだ。
これ読んで大体「オセロなら出来そうだ」と思えるか？
なら、もう十分だから、アイデアもあるようだし、それに取りかかった方がいい。
やらないと上達しない。やる為には、自分がやりたいことをやるのが一番いい。
本を買う必要は無いとも思うが、まあ思うようにやればいい。
ただゲームを作りたいというだけなのに練習にしろ本番にしろ
HTML/CSS/JSのセットを学ぶことは無駄にはならんよ。
あとその手の「初心者でも子供でも簡単に出来る」って奴は大概すぐポシャるので俺は勧めないね。
このスレはじめてきたけど、上の方で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使わない人の声だけがでかいのはわかる
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 > 実際はじきに結論がでるから待てばいい。
>>852 >>369 俺は堂々巡りの話はもうやらない。
jQueryと心中するのも、脱jQueryするのも、自由。
それぞれが自分が正しいと思う方向に向かって進めばいいだけ。
シェアを過度に気にするのは、自分で判断出来ない証拠。
シェアを気にしてるんじゃないんだよ。合理的な判断から。
これからはBackboneや！
>>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))
>>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 Ruby では、: で始まるシンボルで、メソッド名を渡すことで、インスタンスメソッドを呼べる
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 きったねえ文法だなぁｗ
美しい（笑）
疑似コードがそのまま動く（笑）
&::とかの意味不明な疑似コードがどこにあるってんだよｗｗｗ
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構文にしなきゃできるな
>>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の方で工夫するのならスタティックメソッドを生やすのとえっと変わらんじゃん
はは、Rubyじゃあるまいし、カッコつけないと
関数形式で呼ばれたか、コンストラクタとして呼ばれたかで分けるってことだよ
昔みんなやってたじゃん
>>882 そうだよ。変わらんよ。だからどうしたって話だし
>>884 そう書いたんだが、全く伝わってなかった
> list.map(x => new Hoge(x))
const double = n => n * 2;
[1, 2, 3].map(double);
//=> [2, 4, 6]
ワロタｗｗｗ
>>886 によるとこのdoubleは関数じゃないらしいｗ
double(1)みたいな呼び出しじゃないからだってｗｗｗｗｗ
class Hoge {
>>888 お前はこの意味がわかってないんだな
> 関数形式で呼ばれたか、コンストラクタとして呼ばれたかで分けるってことだよ
list.map(Hoge) のHogeは
関数形式で呼ばれたか、コンストラクタとして呼ばれたか
どっちか言ってみ
そんな雑魚レス見てないし関係ない。
spanやdivのクリックイベントを、buttonと同じ要素に出来ないでしょうか？
>>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という存在がなければそんな変なことは考えないのですが、
>>902 馬鹿乙
IEなんて大昔からあるだろ。
それが本当に必要なら、誰かが既に開発して、それこそjQueryにでも搭載されてるよ。
無い＝要らない、ってことなんだよ。初心者ならやり方を間違ってるだけ。
挙動を統一したいならCanvasでやれ
またcanvasおじさんが湧いた
>>899 ボタン要素でスタイルシートでお好みのデザインに合わせればいいよ
カード型みたいにボックスの中に画像、タイトル、アイコン、とかいろんな要素があって
>>899 UIだけなら、CSSでボタンライクではないようにも変更できるわけでdiv要素を使う理由はない
>>907 Enterキー押下時のclickイベント拾わない話じゃねーかとエスパーしてみる
それは他のブラウザでも同じなので、keydownイベント拾ってEnterキーだけ抽出してclickイベント時と同じ挙動をさせるしかないよね
shift/alt/meta/ctrlキー同時押しはもちろん排除するとしてさ
>>909 それだけなら、tabindex属性付与だけで実装可能ではないか？
ボタンの何をエミュレーションしたいのかがわからん、には同意
javascriptでreplaceを用いた特定の文字の置換ができないです。
if(json.text == 'おい'){
>>913 だされた課題は自分でやれ
どうせ本当に出された問題は
「以下のコードをreplaceを使って書き直しましょう」
なんだろ？
答えを聞くな
>>914 違います。
課題は課題なんですけど、
課題内容は「リアルタイム通信を使用してアプリケーションを作ろう」です。
課題の一部がどうしてもわからないので聞いています。
replaceってヒントを貰ってるんだから、replaceについて調べればいいだけ
>>917 おい、おっさん。
こんな時間に即返信するとかなにやってんの？ニート？ｗ
お前は「答えない」じゃなくて「答えられない」だろｗ
無能のくせにでしゃばるなよｗｗ
無能ってすぐ人に答えを求めるよな
http://2chb.net/r/prog/1540885252/ やっぱり俺って有能なんだなあ
すぐ人に答えを求めたりしないしな
# 詳しい人、知恵を貸してくれ。
長ったらしいので翻訳。まず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');
});
できたぞ、質問に答えられないバカ
一行で書けるけど、じゃあなって言われたな。じゃあなｗｗｗｗ
>>899 ボタン部分だけのクリックじゃなくて、
もう少し範囲を広くして、ボタンを含む、div で、クリックイベントを動作させたいのかね？
ボタン部分だけだと、範囲が狭くて、うまく押せない人がいるから
それと投稿者は、次に投稿する際に、名前欄に最初の投稿のレス番号を入れてくれ
>>918 >おい、おっさん。
>こんな時間に即返信するとかなにやってんの？ニート？ｗ
>お前は「答えない」じゃなくて「答えられない」だろｗ
>無能のくせにでしゃばるなよｗｗ
>>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で新たに導入された式や文は
>>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割～９割としよう
しかしClass構文でのその目的、重要度はせいぜい６～７割だということを言ってる
Class構文は従来__proto__を使わないとできなかったスタティックとプロトタイプメソッド両方の継承ということができる
これが俺にとって重要度・構文価値の～1/10
さらにnewTargetの存在によりビルトインクラスの継承ができるようになった
これが俺にとって重要度・構文価値の～3/10
少なくともこういう要素はClass構文を語る上で無視できる存在ではないだろう？
そうすると一般にClass構文は糖衣構文ということはできないというのが俺の主張だ
なのでそう言いたいのならコンテキストを絞った上で言わなければいけない
今回の場合も、もし「ES6で新たに導入された式や文は ES5.1の構文糖衣と考えて良い」と答えると
そういうClass構文などの無視できない重要なポイントを気にしていない、
下手すると気にしなくていいという発言になってしまうだろう？
君はそこを取るに足らないポイントだと考えるから、そう言えるんだろうが、
俺は
>>933 にそこももっと知っておいてほしい、説明したいと思うんだよ
そういう違いさ
>>945 長ったらしくて読む気がしないが
要するにお前が言いたいのは、
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での事実を１つ挙げただけ
そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
変におかしな流れに誘導したのは君の方だよ
少なくとも俺は
>>933 を俺なりに解釈して話を始めた
そこで君が横から言葉の使い方がどうのこうのヤンヤン言って来ても知らんがなって感じ
君の脳内パーサではエラーが出たんだろうが、それをエラーですエラーですエラーですよって、うるさい目覚まし時計かって感じ
俺のゆるゆるパーサでは通ったんだから俺は話を進める、君は固まっとく、でいいじゃないか
俺までどうにかして止めようとする必要はない、俺はそういうのは嫌いだね
JSでも値をチェックして例外を吐くとかね
値をできるだけ加工したり用意の仕方を工夫して無効な値を極力作らないようにする方が俺は好きだ
ともかく君の定義ではそもそも話がおかしいのはおっしゃる通り
だからこそ俺はその定義は今回はそぐわないとしてるところに、わざわざその破綻する定義を持ってきて
ギーギーガーガーおかしいおかしい言われても しつこいポンコツ機械かよって感じ
まあそんな感じ
>>956 俺はclass = 糖衣構文＋αなんだから糖衣構文だって言ってるのに、
お前が、完璧じゃないから糖衣構文と言ってはいけないと言ってるんだろ
1じゃなければ0と言ってるのはお前だ
糖衣構文＋αじゃなくて、完璧に糖衣構文でしょ
糖衣構文か否かの議論の果てにどんな結論があるんだろ
var flagA = false && true || true;
>>959 いうだろ？
ES5で書いたものをclassで完璧に書けるんだぜ？
追加効果があったとしても関係ないだろ
それにそもそも糖衣構文って完全に同じものを
実現しなくてはいけないなんて制限はないんだが？
ほぼすべての糖衣構文はある機能に特化することでより便利にしているが
その反面あるきのう以外のことができなくなってる
他のどんなものが糖衣構文と呼ばれてるか考えてみなよ
糖衣構文という言葉に惑わされてるだけだろ
>>960 それな。
>>938 ですでに俺が言ったことだが
一つ例を出してやる
>>962 ショートサーキットしてる
false && true || trueの二番目のtrueは評価されない
それと後者の答えは優先順位が違うから
&& は||より先に評価される
四則演算でいうと||が足し算で&&はかけ算
>>966 ＞逆にswitch～caseのfall throughはifでは実現できない
そんなことはないと思う
https://ideone.com/tVia2L QZは馬鹿だから無視でおｋ
ふむ。まあ要するにES6の機能をES5で実現できれば糖衣構文。
>>956 > そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
話したいことがあるのなら勝手に書け
そしてそれに食いつく奴が居るかどうかだろ
順序が逆だ
せっかちなのは君の好きにすればいいけど
const foo = [1, 3, 5, 7, 9];
>>974 そんな糞コードは理解出来なくていい
教科書なら捨てた方がいい
百歩譲って「添字はtoString()してるだけ」ということを教えたかったのなら、
数字と文字でやるべきだ
>>975 すみません、業務で見たコードで、実際にはfoo相当の配列はオブジェクトの配列でした
先のコードは自分で実験用に動かしたコードです
なるほど、添え字に配列変数を指定すると、toStringメソッドが走る
配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
なので要素が数字かつ1つしかなければ、その数字を添字にしたのと同じことになる、ということでしょうか
>>976 概ねその通りだが、俺は
> 配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
これが仕様なのか環境依存なのかは知らんよ。
いずれにしても、「配列を添字として使う」事自体があり得ないだろ。
糞コードだし、修正すべきだよ。
動いているからバグとして検出されず、結果的に修正漏れになっている、ということかな。
なおその手の詳細な挙動を知りたければ、仕様書を読むしかない。
JavaScriptの仕様書は他言語で言う仕様書ではなく、実装指示書（詳細設計書）といった方が正しい。
だからオグジェクトの配列のアクセスの仕方（セマンティクス）がいちいち細かく書いてある。
その中で原則的には全てtoStringされていたはずなので、結果的にはそういう挙動になる。
つまり、
× > 添え字に配列変数を指定すると、toStringメソッドが走る
○ 添え字は何であれ全てtoStringされる
だったはず。気になるなら仕様書を確認して。
× オグジェクトの配列の
>>977 丁寧にありがとうございます
どう見てもミスっぽいので直しときます
まさかこれで動くとは思わなかった……js怖い
別にこの程度非難轟々するほどのコードじゃないだろう
でも文字列を引数にとる既存の関数をタグ付きテンプレートとして呼び出せるのって['foo']が'foo'に変換される仕様のお陰なんだよなぁ
foo = [ 1, 3, 5, 7, 9 ];
javascriptでいう関数ひとつ取ってもる～ピぃは
>>981 みたいな奴が普通に居るのがJavaScriptコミュニティが腐ってる証拠な。
プログラミングを知らない癖に出来ると勘違いした馬鹿が間違ったことを吹聴しすぎてて、
馬鹿が再生産されまくっている。
とはいえ問題点は981以外には分かっているようだし、この話はもういいが。
他言語出身者なら、当初参考にするのはMDNだけにして、
個人が俺ツエーしてるだけのブログ等は全部無視した方がいい。
他言語ではあり得ない確率で間違ってるから、無駄にはまることになる。
emscripten/WebAssemblyが本格稼働するかどうか俺は懐疑的ではあるが、
実際にそうなったときに馬鹿JSerが一斉粛清されるかどうかは見物ではある。
「動けばいい」という基準で書いている限り、「動けばいい」程度のコードしか書けるようにはならない。
しかしこれがJSerの大半なのもまた事実だ。
一般的に「良いコード」とされる物を書けるかどうかはプログラマの技量のみに依存し、
JavaScriptだからといって書けない事はない。
ただ、どちらかというとJSはC寄りで、どんな糞コードでも書けてしまう。
ただこれは、単にJSerの技量が足りないだけであって、推奨されているわけではないので注意のこと。
>>979 は今後色々と実感することになるとは思う。
TypeScript使うのはReact使ってるときぐらいだろ？
>>989 あ、すまん。ReactじゃなくてAngularだね
c#に似せるならもっとc#にすればよかったのに
>>991 それはあんたの会社での話でしょ？
あんたの会社の話でもなく、Angular関係でもなく
TypeScriptが使われてることを証明する証拠でもあるの？
>>994 どこが？ｗｗｗ
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
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/ 今時型定義も入れずにnpmモジュール作ってるやつとか、白い目で見られるぞ
>>996 ごく少数から？ｗｗｗ
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
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/ >>997 下のページのtypescriptの伸びは見ないふりしてるの？
>>998 延びた結果がこの差なんだよねｗｗｗ
Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
javascript最高！
このスレッドは１０００を超えました。
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
このスレへの固定リンク： http://5chb.net/r/tech/1527917483/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「+ JavaScript の質問用スレッド vol.126 + ->画像>4枚 」 を見た人も見ています：・+ JavaScript の質問用スレッド vol.126 + + JavaScript の質問用スレッド vol.140 + + JavaScript の質問用スレッド vol.141 + + JavaScript の質問用スレッド vol.133 + + JavaScript の質問用スレッド vol.130 + + JavaScript の質問用スレッド vol.142 + + JavaScript の質問用スレッド vol.125 + + JavaScript の質問用スレッド vol.129 + + JavaScript の質問用スレッド vol.123 + + JavaScript の質問用スレッド vol.129 + + JavaScript の質問用スレッド vol.129 + + JavaScript の質問用スレッド vol.124 + + JavaScript の質問用スレッド vol.124 + + JavaScript の質問用スレッド vol.122 + +JavaScript の質問用スレッド vol.42 + + JavaScript & jQuery 質問用スレッド vol.7 + + JavaScript(ECMAScript)質問用スレッド vol.123 + + JavaScript & jQuery 質問用スレッド vol.6 + JavaScript の質問用スレッド vol.126 (307) ★スレッド立てるまでもない質問用スレッド★その26 + JavaScript のお題用スレッド + Mac OS X初心者質問用スレ 28.2 Mac OS X 初心者質問用スレ 17.0 足場屋さんへの質問スレッド 01 囲碁・初心者専用の質問スレッド 第30局 足場屋さんへの質問スレッド 2 囲碁・初心者専用の質問スレッド 第37局 総合！革靴についての質問スレッド60足目 総合！革靴についての質問スレッド 45足目 ◆◇◆釣り初心者のための質問スレッド190◆◇◆ 総合！革靴についての質問スレッド 44足目 Civilization6 (Civ6) 質問スレッド Vol.7 超初心者のための質問スレッド★アンプ編 47★ 超初心者のための質問スレッド ★総合スレ78★ ◆◇◆釣り初心者のための質問スレッド142◆◇◆NIC 超初心者のための質問スレッド★スピーカー編 78★ 【水明華ネット教会】キリスト教@質問箱301【パパラッチを隔離するための専用スレッド】 ★★Java質問･相談スレッド182★★ 【BTW】Minecraft BetterThanWolves専用スレッド Part3 【DTM】悶絶★初心者質問スレッドVol.81【5歳児】 ★★Java質問･相談スレッド184★★ iPhone 質問スレッド part50 iPhone 質問スレッド part61 iPhone 質問スレッド part62 スレッドを立てるまでもない質問スレッド Part 343 スレッドを立てるまでもない質問スレッド Part 348 ★★Java質問･相談スレッド183★★ ★★Java質問･相談スレッド180★★ ちょっとした質問スレッド＠ファミレス板 ver.1 スレッドを立てるまでもない質問スレッド Part 345 スレッドを立てるまでもない質問スレッド Part 342 Shade 相談/質問スレッド Ver.47.0 スレッドを立てるまでもない質問スレッド Part 350 スレッドを立てるまでもない質問スレッド Part 341 スレッドを立てるまでもない質問スレッド Part 349 【DTM】初心者質問スレッドVol.85ワッチョイ有り スレッドを立てるまでもない質問スレッド Part 366 Windows8 / 8.1 質問スレッド Part33 javascriptで質問 質問スレッド in 言語板 Mac初心者質問スレッド285 Windows 7 質問スレッド Part51 宝塚初心者質問スレッド～Part75 宝塚初心者質問スレッド～Part72 【スレッド立てるまでもない質問】 ヤフオク初心者質問スレッド 820問目
13:18:14 up 65 days, 14:17, 0 users, load average: 9.89, 11.74, 14.67
in 0.10137009620667 sec
@0.10137009620667@0b7 on 062202
