+ JavaScript の質問用スレッド vol.125 +
レス数が1000を超えています。これ以上書き込みはできません。
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
前スレ
+ JavaScript の質問用スレッド vol.124 + [転載禁止](c)2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1427008785/
(ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです) さて、むそろそろ俺の登場かな?
この問題はねSPAだからといってパフォーマンスさげないよね?
無駄なことはしないよね?という話で解決するんだよ。
例えば、http://example.com/foo/1 とかにアクセスした時、
index.html に30x のリダイレクトしたりはしない
なぜかって? リダイレクトしたらパフォーマンス落ちるでしょ?
つまりね。PATH_INFO(でいいかな?)の情報を持った状態で
サーバーサイドアプリが呼び出されるんだよ
そこでサーバーサイド側の仕組みを使って404を返せばいい
SPAの話なのに何を言ってるのと思うかもしれないけど、
ちゃんとしたSPAっていうのはF5を押しても同じ画面が表示されるし
URLも http://example.com/foo/1 のままになるもの
SPAは/foo/1のデータをAjaxで読み込むものだと思ってるかもしれないけど、
それは他のページから辿った場合で、直接 http://example.com/foo/1 に
アクセスした場合は、JavaScriptで取ってくるそのデータを最初からHTMLに埋め込むものなんだよ。
なぜかって? ページアクセスして表示されてからデータを取りに行くとパフォーマンスさがるだろ?
だからSPAは基本Ajaxでデータを取るのは間違ってないんだけど、最初のページに限っては
最初からHTMLに埋め込んでおく。埋め込むことができるってことは、
データが見つからない時に404を返すことも容易
そして検索エンジンとかは、基本的にAjaxを使ってデータを読んだりしない。
読むことも有るかもしれないけど、Ajaxリクエスト(Content-Type: application/json)として
そのページを読み込むことはないだろう。だからいま問題にしているどうやって404を返すか?という
話は実は当てはまらない。検索エンジンは http://example.com/foo/1 を直接読み込むのだから
Ajaxによるリクエスト、つまり別ページを読み込んでからSPAの処理としてページを読み込む場合は
そのリクエストを404にすればよい。たしかにページ自体は404にはならないんだけどね。
でも検索エンジンには関係ない話 SPAを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか?
現状
https://support.google.com/webmasters/answer/181708?hl=ja
に示すみたいにソフト404エラーみたいになってるんですが
SPAでステータスコードを返す方法がよくわからないんです。 補足
「その与えられたURIだけでルータが割り振ったあとコントロールのJS内で画面と内容をレンダリング」
という処理をするためには、
1. URIからサーバーにリクエストを投げる
2. サーバーからindex.html/js相当を貰う
3. クライアントのJSでURIから画面と内容を表示するのデータを貰うためにサーバーにリクエストを投げる
4. サーバーから画面と内容を表示するためのデータを貰う
5. そのデータを使って画面と内容をレンダリングする
の3〜4のサーバーへのリクエストの処理について考察できてないんでしょ?
そしてSPAでは2回サーバーにリクエストを投げるのが当たり前で解決できない問題だと思い込んじゃってる。
まともなSPAだとここを1回にする。理由は2回リクエストを投げるとパフォーマンスが落ちるから。
2回サーバーにリクエストを投げる方法だと2の時点で200が返ってきてしまい、4の時点で404を返すことになるが、
リクエストを1回にした場合は、2の段階でindex.html/js相当+画面と内容を表示するためのデータを貰うことになるので
この時点で404を返すことができる。 クローラーについて
今、話をしてるのはクローラーの話だって分かってない?
クローラーはクッキーやローカルストレージは使わない
https://www.suzukikenichi.com/blog/googlebot-uses-a-web-rendering-service-that-is-based-on-chrome-41/
ページレンダリング中に一時的に使ってるかもしれないが読み込み時に毎回クリアされる
クローラーっていうのは、HTMLを取得(ページをレンダリング)する処理と、URLをかき集める処理が別れている
そしてクローラーは自分が知ってるURLに対してGETリクエストを送る
だから一回もリクエストを送らないということはありえないんだよ。
クローラーはブラウザじゃない。ブラウザのように前の状態というのを持たない。
だからアプリの作りが例えサーバーと通信しない作りであっても
知ってるURLに対して初回アクセスと同じようにかならずGETリクエストを送ってくる
そしてクッキーやローカルストレージは持たない
クローラーは必ずSPAのアプリケーションの特定のURLに対して直接GETでアクセスしてきており
(アクセスしない = 最新の情報がわからないのだからクロールされてるページ内容の更新を行わない)
なおかつ初回アクセスと同じようにデータは空なのだから、状態は200か404のどちらかに決定することが可能
(まあ他にもリダイレクトとかあるだろうけどいずれにしろどれかに決定できる)
クローラーがブラウザと同じようにクライアントサイドだけでアプリを動かしているかもしれないじゃないか
とか頓珍漢なこと言うなよ? それなにもクロールしてないからw クローラーの使命を果たしていない ターニングポイント
ん? もしかして>>834もそうなのかもしれないが、他のやつも
404が「サーバーから返すもの」
つまり HTTPというプロトコルを使ってクライアントから
サーバーにアクセスした時に、サーバーからクライアントへ
返すものだって分かってないのか?
404はHTTPプロトコルレベルの話なんだから、
仮にHTMLとJavaScriptだけで動くものがって
一切サーバーとアクセスしない=HTTPプロトコルを使わない場合
には、当然HTTPプロトコルレベルの話であるHTTPステータスコード404(200も)はでてこない。
これは常識だよね?
ここまではいいよね? すいません。404の件で質問したものですけどスレが切り替わった後でも
議論していただいていてありがとうございます。
その後facebookでもソフト404を許容していることがわかったりとか
サービスによってまちまちであることがわかったので、
他のサービスとの比較もしてみて、どうしても必要だったら
リダイレクトで404ページに飛ばすという簡易戦略で検証を進めてみます。
ありがとうございました。 >>8
そういわれるとちょっと違うと言わざるをえないんだよね。
仕方ないんで、facebookで再現する方法を探してきたよ
まず以下のABC News(でいいのかな?)のページを開く
https://www.facebook.com/abc/
その左側の「ページ情報」と「投稿」のリンクをクリックして
ページを行き来してみると(ブラウザのURLが変わることに注意)
Ajax(xhr)での通信が行われており、これがSPAであることがわかる
(Chromeのデベロッパーツールなんかで確認してね)
(ページ上の「メールアドレスまたは電話番号」とかいう文字を適当な文字列に変えておけば
SPAから抜け出してしまった時にすぐに気付ける)
=== ここまではfacebookでSPAで動作していることの確認 ===
で、Chromeのデベロッパーツールなどで左側の「ページ情報」のリンクを以下のように書き換えてみる
<a class="_2yau" data-endpoint="/abc/about/?ref=page_internal" aria-current="page" href="/abc/about/?ref=page_internal">
↓
<a class="_2yau" data-endpoint="/abc/about/aa?ref=page_internal" aria-current="page" href="/abc/about/aa?ref=page_internal">
(「abount/」を「about/aa」に変えた)
この状態で「ページ情報」をクリックした時 URLが https://www.facebook.com/abc/about/aa になる
HTTPステータスコードは404。(もちろんSPA状態から抜け出てはいない)
abount/aaなんてページは存在しないので画面は正しく表示されない
facebookは画面が変わらないようだが、ソフト404としてエラー画面にしようと思えばできるだろう
=== ここまではSPAとしてこのURLを開いた時のHTTPステータスコードの話 === じゃあ、ブラウザのURLに https://www.facebook.com/abc/about/aa を直接入力して開くと
facebookの画面がでてくるのか? というともちろんそうじゃない。
HTTPステータスコードは404だし、「このページはご利用いただけません
リンクに問題があるか、ページが削除された可能性があります。」の画面がでてくる
つまりまとめると、
https://www.facebook.com/abc/about/aa というURLで示される存在しないリソースを要求したときは404になる。
SPA状態でアクセスされているときは、内部的に404になっているとしても画面上はそれが出てこない。
最初から言っているとおりだが、SPAで404を返したいという質問が意味不明で、単にサーバーにアクセスされて
レスポンスを返す時に、そのリソースが存在しないときは404を返すだけでいいんだよ。 SPAだからどうしても200になってしまうっていうのは間違いで、
200になってしまうのは>>5でも書いたけど
1. URIからサーバーにリクエストを投げる
2. サーバーからindex.html/js相当を貰う
3. クライアントのJSでURIから画面と内容を表示するのデータを貰うためにサーバーにリクエストを投げる
4. サーバーから画面と内容を表示するためのデータを貰う
5. そのデータを使って画面と内容をレンダリングする
この状態になってるからだよ
SPAのためのindex.htm/jsの読み込みと(そのURLで示される)データの読み込みを
二段階に分けてしまうからそうなる
SPAでデータがない時に404を返したければ、リクエストを2回に分けるのではなく
2. と 4. の内容をまとめて1回で行うようにする。
そうすれば404が返せるし、パフォーマンスアップにもつながる この検証からfacebookは(調べた範囲では)ソフト404を使ってないことになるね。
クローラーはURLを直接入力したときと同じように取得するわけだから
facebookで存在しないページをクロールしてしまうことはない。
(GoogleBotはJavaScriptを実行するとかSPAだからとかいうのは全く関係ない話) > SPAでデータがない時に404を返したければ、リクエストを2回に分けるのではなく
> 2. と 4. の内容をまとめて1回で行うようにする。
補足 ↑言っておくけど、これはサーバーサイドでレンダリングするって話じゃない
HTMLにJSONを埋め込めばいいだけ
っていうのは前スレのこれを呼んでいればわかるはずだが
https://mevius.5ch.net/test/read.cgi/tech/1427008785/889
https://qiita.com/takeshy/items/b7e1b6bd30d12ecb02c6
> 1.データを別々にAjaxで取得
> 各CollectionやModelがRESTを使ってデータをAjaxで取得するので、
> リクエスト数が多くて遅くなる上に、ブラウザの同じサイトに対しての同時リクエスト数制限にひっかかります。
> 1.に関しては、初期画面のHTMLにAjaxで取得予定のデータを予め埋め込んでしまい、
> 初期データとして使うことで初期画面表示時のAjax呼び出しをなくしました。
https://qiita.com/takeshy/items/ba8b3ee4606993c1c5b8
> 初期表示時にサーバとの通信を極力行わない
> SPAで作成する場合、各モデルごとにサーバとデータを同期する必要がありますが、
> データを初期のHTMLにJSONデータとして埋め込んでしまうことで、Ajax通信を回避することが可能です。 同時リクエスト数制限の話はもうやめようぜ
HTTP2だってあるし、ブラウザもESMの導入で依存関係が1000を超えるようなケースが出てきてるので
パッケージング仕様標準化も含め最適化に乗り出してるしさ
そもそもSPAならServiceWorkerでCache使うだろうと 案の定SSR無しとかいろんな前提を捨ててHTTPがどうの言ってたのか。
化石は化石として、現場を荒らすような真似はせずシーラカンスのように漂っててほしいな。 だからSSR(サーバサイドレンダリング)無しの前提で話をしてますよw
ちゃんと書いてあるでしょ
レスだけして、反論の一つもないってどういうことだよw
悔しかったからレスしたが、言い返せるものは何もなかったって
言ってるようなもんだよ 前スレ眺めてたけど明らかに勘違いをごまかしてるのはレスポンスコードにこだわってる方だろ このスレにでてきた例はTwitterじゃなくてFacebookだけど、こっちはSPA とあるサービスを作っています。
chrome-extensionと連携するサービスですがその中でお金のかかるapiを使おうとしています。(例えばGoogleTranslateAPI等)
自作のchrome-extensionユーザーには
(私が自腹を切るので)無料で使ってもらおうと思っているのですが、
chrome-extension以外のユーザーからは使ってもらいたくありません。
その場合どうやって制約をかければいいでしょうか?
一応考えているのはproxyとなるapiサーバを作って
ユーザー認証を行いそこから使ってもらおうと考えているのですか
トークンはsessionStorageに配置しているのでそれを取られると
結局無断で使われてしまいます。 ページと言う概念で見てるのかそうじゃないのかがまずでかいんじゃないの? というか、404は何がnot foundの時の
エラーなのかってことだな Apache24を起動すると以下のような文章が表示され、
localホストと入力してもIt Works!が出なくなってしまいました。
サクラエディタを使用してコードを書いていますが、実行結果が表示されません。
知り合いが言うにはデフォルトで表示する文書の内容替えたか、
デフォルトの文章内容いじったのでは?と言われましたが心当たりがありません。
Apache自体は動いてるようなのですが、どのようにしたらよろしいでしょうか?
AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name,
using fe80::f862:7a8d:c09a:60b8. Set the 'ServerName' directive globally to suppress this message electronアプリに適したデザインガイドラインは何でしょうか? Array.mapの中でawait使いたかったんでcallbackをasyncにしたら処理順序が不定になってしまった。
await使いながらループ順を維持したいなら昔ながらのforを使うしかないんだろうか。 >>29
それって処理順序が不定じゃなくて
処理終了するタイミングの違いだろ。
処理終了を順序良くしたいなら同期処理するしかないのでは?
というか非同期にする意味がない。 >>29
あとasync-awaitでmap使うんだったらPromise.allを使ったほうがいいのでは?
Promise.allをmapっていってるとか?
参考:
https://qiita.com/m0a/items/6b3965295df92d7bb28d result = ary.map( v => f( v ) )
↓
result = await Promise.all( ary.map( async v = await f( v ) ) ) >>30
理由は書いたとおり、awaitが使いたかったから。
同期的にやりたいのは山々なんだけど、非同期な関数が混ざってるから仕方なく。
Promise.allはもちろん使ってる。そうしないとPromise[]しか返ってこないし。
やっぱりforしかないのかな。 1個ずつ順番に待って実行したいってことか
それならreduce使えば良いんじゃない?
ary = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
delay = v => new Promise( ok => setTimeout( ( ) => ok( v ), 100 ) )
sum = ary.reduce( ( s, n ) => s + n ) //55
↓
sum = await ary.reduce( async ( s, n ) => await s + await delay( n ) ) //55 >>36
なるほど、reduceは思いつかなかった。
もしかしてこれ、await sを後に持ってくると順序が変わってしまったりする?
どっちにしても試してみる。ありがとう。 初歩的な質問ですみません
要素数の決まっている配列の中身をそれぞれ別の配列(やオブジェクト)で初期化したいとき(Ruby の Array.new(6){ Array.new } がやりたい時)、
何か簡単に書けるやり方はあるでしょうか。
これぐらいでいちいち for ループ書いてを回すのもコードが長くなってなんだかなあという感じで、今は
function arrayInit(length, cb) {
return new Array(length).fill(null).map(cb)
}
const ary = arrayInit(6, () => { return new Array })
こういう感じで処理していますが、 一旦 fill で無関係な値で埋め立てないといけないのが冗長な感じがします 最後丸括弧抜けてますね
const ary = arrayInit(6, () => { return new Array() }) const ary = [...'.'.repeat(6)].map(_=>[]); const ary = Array.from(Array(6),_=>[]); const ary = [...Array(6)].map(_=>[]); 今では立ち消えになったTypedObject提案にこの手の構造化の仕組みがあったから
それを真似してライブラリを作っても良いかもしれない >>45
と言ってもいろいろあるわけで。どれのこと ブラウザにデータを保存するlocalStorage(ローカルストレージ)の使い方 >>47
サイズ5MBしかないし単純のkey-value型でしょ
indexdbのほうが良い気がする。 >>49
手軽さはlocalStorageとsessionStorageのほうがはるかに上
要は適材適所 jQueryでa要素のリンクをクリックされた時の処理を
ハンドリングするにはどうすればいいでしょうか?
キーボードで選択&エンターされる場合もあるので
onclickは適当ではないと思います >>52の件ですが
キーボードでフォーカス&enterした場合にもclickが発火するんですね jQuery の質問は、web制作管理板のjQueryのスレへ
JavaScript・ブラウザ関連の質問も、web制作管理板へ書き込む方が良い >>54
そうだよ。jQueryの機能ではなくDOM API自体がそうなってる セレクトボックスのようなUI部品を表示し、
他の部分をクリックした時にそのUI部品を閉じる、
というような処理をする時は
UI表示時にclickなどのハンドラをセットして
自分以外の部分がクリックされていたら自分を消してハンドラを削除する、
というようなやり方をするのでしょうか? 閲覧環境がクリックという概念を発生させやすいデバイスとは限らない
そのために各環境向けに調整することを許された標準要素がある
それらを再実装することは最もやってはいけないこと
標準要素に出来る限り頼って軽くスタイルをあてるだけが良い >>57
documentレベルにハンドラ追加して
バブルアップしてきたイベントで対応 >>59
そういうのはサポート環境決まった上で
きちんと検証してユーザーからのフィードバックもしてるからね
個人ではそれは無理 > (ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです)
多数の意見? ブラウザ内座標をpx基準で(x,y)にある要素をクリックすることはできますか? document.elementFromPoint(x, y).click();
上は試しました。
初歩的な質問なのかもしれませんが、ブラウザ上のpixel座標と全く違う箇所をクリックしてしまいます。
どうしたらいけますでしょうか? >>58
セレクトボックスを再実装すべきではないということですが、
セレクトボックスは
通常CSSで実装されるドロップダウンメニューの
メインメニューが一つになったものと考えられるので、そこまで難解ではないのでは?
select要素だと項目の最大の文字数によってサイズが規定されますが
それを避けたいので、再実装しています
>>60
デレゲーションですね
考えてみればいちいちハンドラの付け外しをする必要なかったです
ありがとうございました >>65
例えばスマホでは画面が小さいのでselect要素が選択された時、文字が拡大表示される
これからはスマートウォッチのような超小型デバイスで見られるかもしれないし、
標準要素を使えば操作に関してもデバイスや閲覧者のハンデに応じた補正が入る
それらを全て再実装することは不可能なのですべきではないということ
もしそれっぽくデザインしてもそれが別の環境では改悪になることもある
Webっていうのは様々なデバイスで様々に見られる柔軟性が良いのであって
Flashが廃れてHTML5が栄えた理由の一つもFlashがスマホという新しい環境に適応できなかったから
だから自分の好きなデザインで固定化するという悪歴史の繰り返しは避けないといけない
それがサイトの構成上本当にどうしても必要なものであれば良い
でもデザイン上自作したほうが良いように思えるという理由ならやめとけ セマンティクス的な意味でもそのままの要素を使う方が望ましいのは当然ですが
そうはいかない場合もありますよね
なんとか元のタグを生かそうとしたのですが機能上不可能だったので自分で実装しました これ以上アドバイスしようがない
人の忠告を聞く気がないなら初めから自分で好きにやればいい ちょっと抽象的な質問で恐縮なのですが、ハロワの要求する経験欄に、
JavaScriptに精通している事、とあるのですが、どのレベルまで行っていれば
その条件を満たしていると考えてよいでしょうか?
具体例などを挙げて頂けると幸いです。 >>70
会社によっても違うかと。
teratailでスコアをある程度jsで取れてる?
qiitaに、記事を書いてる? 答えてくれた方、ありがとうございます。
>>71
検討してみます。
>>72
いえ、teratailやqiitaにはノータッチです…。 generatorの中でawait使いたくなって混乱した。
処理を細切れにasync即時関数にするくらいしかないのかな。
yield (async () => {
})();
もうちょっと目に優しい方法があると良いが。 もうChromeとかではasync generatorが使える ググってもよくわからんかったが、そのasync generatorてのを使った記述ってどんな感じなの?
あと、ESで言うとどのバージョンに含まれる仕様なんだろうか。 ある配列から別の配列に存在する要素を削除する
一番いい方法はどういったものですか? >>77
lodashの_.differenceメソッドを使用する
https://lodash.com/docs/4.17.5#difference
_.difference([2, 1], [2, 3]);
// => [1] >>78
これはいいですね
ありがとうございました >>77
バニラならfilterで
var foo = [1,2,3,4,5]
var bar = [2,4,6]
foo.filter(x => !bar.includes(x))
//=> [1,3,5] >>80
いいね、今は一行で書けるんだな。
こんだけのことのためにlodash導入とかご苦労なこってwww >83
_.difference(foo, foo);
foo.filter(x => !bar.includes(x))
_ difference foo foo ・・・4ワード
foo filter x => ! bar includes x ・・・8ワード
二倍違ってるし、バニラだと
「filterでincludeしてないのを除く」ということの
意味を考えないといけない
さらにlodashは古いブラウザでも動く >>84
バカが。lodashロードするのに1行必要だ。
javascriptのレベルで考えるなら数十行の追加に等しい。
以下lodashのdifference実装だが
さらにbaseDifference, baseFlatten, isArrayLikeObjectも読み込んでる。
function difference(array, ...values) {
return isArrayLikeObject(array)
? baseDifference(array, baseFlatten(values, 1, isArrayLikeObject, true))
: []
}
https://github.com/lodash/lodash/blob/master/difference.js
8ワードどころじゃ済まないなw
高々>>78解くのにどれだけ演算・容量コスト掛けてんだ無能。
「自分で実装したくありません。何かよいライブラリありませんか」って質問ならライブラリスレで聞けや。 differenceを定義しとけば3wordで済むね
l o d a s h 完 敗 なんか屁理屈いってんなーw
問題は自分の作業がどれだけ減るかだろ。テストも含めて
lodashのdifferenceはすでに十分テストされてる
それからお前のコードは配列の差集合をもとめることだけなのか?
実際に仕事してりゃもっとたくさんのことやるだろ。
それがlodash使うことで大幅に減るんだよ mdnでdifference検索したけど出てきませんでした。ブラウザでもnot definedとかでてきてエラーになります。
javascriptではないのですか?
一方>>80はコンソールでそのまま実行できました!
これはjavascriptなんですね?ありがとうございます! このように無知な人に下手に自力で書くように進めると
何でもかんでも自分で書くようになって
下手なコードた大量に生産されます。
初心者「こんなにたくさん書いたんだぜ時間もかかったすごいだろ!」 >>88
differenceはjavascriptのAPIではないよ。
外部のライブラリだから別途ロードしないといけないし、リファレンスもjavascriptのじゃなくてそのライブラリのを調べないといけない。
君のプロジェクトが他のライブラリ採用してたら全く役に立たないね。
>>80はfilterもincludesも標準javascript APIだから外部ライブラリのロードなしに使えるし、javascriptのリファレンスにも載ってるよ。 >>87
ここはお仕事相談所ではありません
JavaScript を自ら学ぶ人のための質問スレッドです
とにかく楽がしたい人はお呼びではありません JavaScriptほど広く多くの人に使われてるスクリプト言語はないのにね 今のjavascript系ライブラリ乱立地獄はこういう奴らのせい Extensible Web的にはライブラリが乱立するのが正しい
問題はjQueryというライブラリでもフレームワークでもない
独自世界を提供する強すぎる存在がいてバランスを崩していること
まだ標準と対立することで標準側にいい影響を与えてくれるなら良いのだが
jQueryの開発者もそうだし、特にその利用者なんて全くその気がないのが問題
昔っから『JSをJavaと呼ぶ』問題があるが、それ以上に『jQueryとJSの関係性が分からない』問題が酷い
ここでも良く、便利だから、簡潔だから初学者にはとりあえずjQuery使って教えれば良いんだよ
という論調の奴が度々湧くがそれは大変危険
なぜならjQueryはWeb APIとの親和性が極めて中途半端で、水と油のように馴染めない存在だから
極論を言えば同じJSでもjQuery中心で始めるかどうかで、それぞれ別言語を習ってると言っても良い
jQueryと非jQuery派にはシナジーがほとんど無くただ食い合ってるだけっていうのが本当に深刻な問題
これからのExtensible Web精神やそれに基づいて生まれてくるだろう大量のライブラリとも強く反発する jQueryはライブラリだよ
https://jquery.com/
> jQuery is a fast, small, and feature-rich JavaScript library.
ここに書いてあるとおり
jQueryの成果はDOM API標準にも大きな影響を与え
セレクタによるDOM要素抽出、classList、dataset、CSSのanimationなど
jQueryを参考にしたであろうAPIがいくつか有る
またDOM APIとの互換性も考えられており、イベントに関しては
DOM APIのイベントハンドラがそのまま使える場合も有るぐらい
jQueryのEventオブジェクトはW3C standardsに準拠している
https://api.jquery.com/category/events/event-object/
> jQuery's event system normalizes the event object according to W3C standards.
たまに>>94みたいに反論してくるやつがいるが、文章をよく見てみよう。
理由、根拠が何一つ書いていないのがわかるはずだ。
俺はこのレスに理由、根拠をちゃんと書いている jQueryそのものは確かにあなたの言う通りExtancible Webのを阻害するものだけど、ライブラリの乱立や混沌や対立、深刻な問題を引き起こしてるのは
間違いなくgoogleやappleやfacebookやらの連中だよ
そいつらが2000年前後に無責任なhackを推し進めたことで生まれた問題だ
jQuery が原因ではない、採用した奴らが悪い
「IEが糞、IEは時代遅れ、IEは解釈を誤っている、IEは...」とか言ってブラウザ主導で機能拡張しまくった奴らも同罪
HTMLはただの「ドキュメント」だ「文章」が正しく表示されればその役割を果たしたと言える
それをHTMLを「アプリケーションプラットホーム」と勘違いしてる一部の狂信者たちがバカみたいに機能拡張しまくるからこんなことになる おいおいw Extensible Webでぐぐったら
上の方にこんな記事見つかったぜ
見事にjQueryがExtensible Webにいい影響を与えたって例に出てるぜ?
根拠なくjQueryが阻害してるとかいうのやめてもらおうか?
Extensible Web
https://html5experts.jp/iwase/10825/
> しかし近年、Webの開発者が先導して、ブラウザの新機能へ影響を与えるケースが
> 出てきています。 例えば、querySelector や、Object.observe が具体例です。
> これらの例は、以下のフィードバックループによって生まれてきています:
> Webに本当に必要な機能を生み出すためには、 上記のように、
> ユースケースに沿った実践的なフィードバックループを回すことが重要です。
>
> 既にこのプロセスはWeb標準化にも取り込まれています。例をあげると、
>
> ライブラリ例 標準化された例
> jQuery querySelector
> Ember, AngularJS Object.observe
> Sass, Less CSS Variables > といったところが代表的でしょう。例えば、セレクタを用いたDOM操作は
> jQuery で実践的に有効性が示され、querySelectorとして標準化されました。
> これにより、jQueryのパフォーマンスは向上し、さらに Zepto.js のような
> 軽量化ライブラリが登場・・・といったWebの好循環を起こしました。 Object.observeは無かったことリスト入りしたぞwww TypeScript使うとJqueryオブジェクトとDOM APIの混乱が減ると思うからオススメ。 >>95,98
俺はシナジーは「ほとんど」無いと言った
逆に言うと数個はあったと認めてる
それ以上に害が大きいということ
なぜならjQueryなどを参考にした機能が標準にも入ったことで
似てるがやや違う機能というのが多くなってしまったというのも事実だから
つまり標準を補うものではなく、ただ「中途半端」に対立している別世界の存在になってしまっている 「Webの発展に貢献すること」と「初心者の理解を阻害すること」に因果関係はない
最も、「初心者の理解を阻害すること」については同意するが >>103
その2つには因果関係は無いかもしれないが、
jQueryのあり方とその2つは因果関係がある
jQueryっていうのは、つまらん標準のフォローと、それだけではなく
実装の混乱からWeb技術者を守るために生まれた
その当時の存在っていうのは大変素晴らしいものであった
大きい存在が居ることは良いことにもなり得る
実際jQueryはWebに良い影響も与えた
でも現在は大袈裟に言うとユーザーを二分してしまっている
別にjQueryが悪いんじゃない、むしろ最初覚えるのがライブラリからと
思わせてるっていうのは、標準や環境が悪いのだろうよ
でもそれを初学者に頑なに勧める回答者も悪いよ
Webっていうのは先にどんどん進んでいくものだし、先に勧めていかないといけないからね
今この瞬間この場で適当な回答ができれば良いんじゃない
教えた初学者がそのうち自分たちと共にWebを作っていくようになるんだから
IEだって見方によってはActiveXObjectだったり、いろいろ協力で素晴らしい技術を提供していた
でもそれを悪だと言わないといけないし、現状どうしても無視できない存在でも
あえて切るべきと唱え続けなければいけないときっていうのがある
jQueryも今からそういう立場になっていくってことだよ > つまり標準を補うものではなく、ただ「中途半端」に対立している別世界の存在になってしまっている
別世界でも何でもないなw >>104を呼んでも心に響かないのは単なる根性論になってるからだよ。
そうあってほしい。でも理由はなにもない。
だから俺が理由を書いてあげよう。
AngularやReactがなぜ普及しないのか?
それはJavaScriptの世界を作ろうとしているから
残念ながらウェブのほとんどはJavaScriptを必要としない世界
そもそもHTMLが文書を書くために作られたもので、
世の中の大半は静的な文書で成り立ってる 例 Wikipedia、ブログ
もちろん一部にJavaScriptを使っているわけだが、一部なんだよ、一部。
AngularやReactなどのフレームワークはほぼ全てにJavaScriptを
導入しようとしている。そんなもん望んでないのにね。
よく知られた事実として、jQueryのシェアは伸び続けている
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
このスレにも書いてあるが、2017年で71.9%のシェアだったjQueryは
1年後の2018年で1.4%も増えて73.2%になっている
Angularやreactなんて1%にも満たない
なぜか?それはjQueryがウェブの大部分にマッチしたライブラリだからなんだよ。
技術ができればそれが使われる。なんて考えるのは素人。使う理由がなければ使われない。
人々が求めているのは仕事が楽になる方法であって新しい技術じゃないんだよ
欲しいのは今やっていること(=73.2%はjQuery)の延長技術であって
そうでないものは欲しいと思ってない。それが現実なんだよね。 >>104
つまり、おまえさんの言いたいことはこういうことか?
「これから廃れる運命にあるjQueryを今更、勧めるな」
では、これから発展する仮想DOM系は初心者に進めて良いと?(そういう問題でもないと思うのだが)
てっきり、おまえさんの主張は「なぜならjQueryはWeb APIとの親和性が極めて中途半端で、水と油のように馴染めない存在だから」関係だと思ったんだがな
俺が初心者にjQueryを勧めるべきではないと思う理由は、初心者にとって、jQueryオブジェクトにラップされたコードを理解するのは困難だからだ
初心者がjQueryから学習を始めると、
・これってjQueryでどう書きますか?(明らかにESの範疇)
・〜はjQueryでないと出来ないんですね(ピュアJSで出来ないと思ってる)
のように、jQueryで出来ることと出来ないことの区別が全く出来ず、見当違いの方向に理解を進める
jQueryに限った問題ではないが、jQueryはよく分からなくても書けてしまう(サンプルコードが多い)が為にそういう傾向が強い js質問スレでjqが喧嘩吹っ掛けるスレがあると聞いて jqに喧嘩ふっかけてこてんぱんにされてるっていうのが正しい >>108
> 見当違いの方向に理解を進める
じゃあその見当違いにならないように説明すればおしまい まとまりのない長文を書くやつは
コードもわかりやすく簡潔に書けない
主張は3行以内で明確に >>108
ちょっと言いたいことが違うかな
どちらかと言うとIEガーと言ってほしくない
それでブラウザ互換をどうこうでjQueryを「必須のように」言ってほしくない
そういう一部の仕事の実情がJavaScriptという世界の全てだと考えてほしくない
それは世界の中心かもしれないが、巨大な世界からしてみれば小さいコアでしかない
そしてやっぱり最初は「義務教育の学校」のように「綺麗事」でシンプルに教えていくべきで
血汗涙にまみれた現場で生き残っていくための「今」役に立つ「生の」実践テクニックは
初学者を卒業して応用が効くようになって、「今」実務コードが書ける用になった時「専門学校」で習うべきことだと思う
別にjQueryの質問をしてくる初心者がどうのこうのは関係がない
本当に未熟な初学者にjQueryが必須のように教えるのは良くないと言うだけ
そして実際に教えていることというよりも、そういうスタンスだということが何度も表明されているので反発してるだけ >>108
あとは他のフレームワークでも同じだよ
それがベースで依存するような学ばせ方をしてはいけない
でも、いつもかつもなんでもかんでも1つのフレームワークに依存するようなことなんて無いし、
ライブラリだって拡張として小さく必要のために使ってるのなら問題ないんだよ
jQueryはその常識から外れた大きすぎる存在だから特に注意ってだけ
麻薬のようなもの フレームワークは開発者の作ったコードを呼び出す側
だから複数のフレームワークを同時に使うことが難しい
フレームワークの導入や変更は大変な作業になる
だけどjQueryはライブラリなので、コードの一部だけ
使ったり使わなかったりできる。
仮に必要なくなったら徐々に減らすこともできるし
徐々にjQuery使うようにもできる
>>114が勘違いしているのはjQueryはウェブアプリでは
多くの場面に使えるから使用してる量が増えているだけのことを
まるでjQueryに依存してしまう(逃れられない)と思っていること
jQueryはDOM APIを混ぜても便利に使える。
その証拠が$関数を始めとしてjQueryの多くのAPIは
DOM要素を引数にすることができるし、イベントハンドラのthisもDOM要素
フレームワークは導入するのは大変な作業になるが
jQueryは使うのをやめるのも簡単なので安心して気軽に導入できる 違う、JavaScriptのJの字しか知らないような奴に、標準DOM APIなんて使えたもんじゃない、覚える必要も無いと言うことを思わすなということ
それからよくjQueryは上手く扱えるという奴が居るが、それは経験あるお前だから、そしてJS波乱期からライブラリの発展をそれなりに体験している俺たちだから言えること
自分が言ってるのは赤ちゃんにスマホを持たせて、鉛筆で字を書かせたり本を読んだり砂場で遊んだり、何かを為すため体を使い苦労して作った経験が極めて少ない事になると
実際基本的に普段それをする必要が無いとしても、不便である素な経験がない事で困ることは出てくるし、広い意味でその子がスマホ以外の素の実世界の発展のために活躍できにくくなるということ >>116
> 違う、JavaScriptのJの字しか知らないような奴に、標準DOM APIなんて使えたもんじゃない、覚える必要も無いと言うことを思わすなということ
出だしから間違えてるよね?
誰が「標準DOM APIなんて使えたもんじゃない、覚える必要もない」などと言った?
俺は言ってない。じゃあ誰か?
お前だよ。何者でもないお前が「標準DOM APIなんて使えたもんじゃない、覚える必要もない」って
言ってるんだよ。
もう一つの間違いは「JavaScriptのJの字しか知らないような奴」
JavaScriptのJの字しか知らないような奴だと誰が証明した?
本人がそう名乗っているわけじゃない。他人がわかるはずがない。
つまり、これもお前なんだよ。何者でもないお前がそう言ってるんだよ。
ようするにな、お前は自分が作り出した敵と戦ってるだけだ それから言いたいのは他人の発言を遮るんじゃなくて自分の考えを発言しろ
他人の発言遮るっていうのはjQueryの話をするなだけじゃなくて
そいつは低レベルだから(思い込み)高度な話はするなと遮ることも含まれる
こいつは赤ちゃんだからといってレスの内容を変えるのは
傲慢な考え以外の何物でもない
自分の考えを発言しろというのは、誰かがjQueryを使った解答をしたら
それを遮るんじゃなくて、自分の考え、つまりDOM APIを使った解答をしろということ
他人の足を引っ張るな。自分の考えを発言しろ。 今から始めるフロントの「初学者」はもうjQuery やんないんじゃないの?
なんも知らない人がググるであろう「js ライブラリ フレームワーク」
とか検索するとjQueryやめとけ系の記事いっぱいでてくるぞ でもjQueryは使われてますからね。
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
jQueryを使わない = DOM操作をしない = DOM APIも使わない
これなら理屈にあってるんですよ。
今のフレームワークはDOM APIを使わないですからね。 フレームワークを使う話ならもちろんフレームワークを使った回答をしますね。
でもjQueryで解決できることなら、そりゃ当然jQueryで回答しますわ
なぜjQueryで回答できるような質問ばかりなのでしょうか?
それこそが結論ですよ。JavaScriptのフレームワークはほとんど使われてない証拠です。 アラム語のスレの質問に英語の文法では〜とか答えるようなもの。どんなに英語が支配してようが関係ないだろ。アラム語のスレだというのに jQueryはJavaScriptのライブラリなので例えがおかしい
英語のスレで英語のスラングで答えるようなもんだから何の問題もない 実際に質問者がjQueryの回答をみて、解决したって言ったんだから
間違った答えを言ってないことは確定なんだよ >>117
ここまでずっと1スレに1回は議論のなかでそういう論がでている
一部のjQueryニキの潜在意識にあるのは確実
JavaScriptのJの字しか知らないような奴でないと誰が証明した?
そうかもしれない奴にjQueryを勧誘するなということ >>118
勘違いしてほしくないが自分はjQueryの回答をするなというつもりはない
個々の質問への回答としてライブラリを使う例があれば勿論そのほうが良い
だが、具体的な例で言うと
誰かがライブラリ使わずに回答したらやれ互換性だのコードの短さだの主張して
ライブラリを使うべきという論争が始まるだろ
自分からすると、それこそ足を引っ張るなと言いたいね
俺たちはそういうライブラリの長所は視野が狭く誇張されたものだと思ってるし、
実際は何も使わなく書くことが無いとしても、
一般例として教え習うときはそういう「特殊な」ライブラリを使わないほうがいいと考えてるんだよ
そして「全体として」過度にライブラリを推すのは自重すべきだと感じてる
反ライブラリ派の多くは、結局そういうライブラリ使いの
短絡的なドヤ思想が嫌いなんだよ
こっちは地道に初心者を育てようとしてるんだから足を引っ張らないで欲しい 例えるならあれだな
一生懸命近所の子供に筆算のやり方教えようとしてたら
変なおっさんが、そんな物、非効率だし不確かだから、電卓を使う法が良い
と言ったような感じを自分たちはいつも感じてる
本人に変な気がなくとも実際妨害されるし、
それによって子どもたちが筆算の必要性軽視してしまったらショックだろ?
何事も最初から楽するなと言いたい
そして何が普通か分からないうちの奴は、「騙して」でも
きついことさせて鍛えさせるんだよ
そうしないと極論育ったときに使い捨てになるだけ
自分はせっかくここであえて回答させてもらう関係になったのだから
この一瞬の経験で今後も良い影響を与えたいし、
立派な子に育って欲しいと思ってるんだよ
これはエゴだが、自分は5chのJS質問スレ2,30くらいからずっといる身として
ここは淡白なその場よければ終わりの一問一答スレになるべきではないと思ってる SPAも勘違いしてた彼はいつも暴走してんのか。
無駄な指摘だったな。 >>127
また質問者を子供扱いですか?
それが傲慢だっての 相変わらずjQuery厨は懲りないな。
とはいえ双方の言い分は分かるが、俺は ID:oazhajsT を支持する。
>>127
> 楽するな
この言い方は角が立つから「ずっとブラックボックス扱いではいけない」と言った方がいい。
中で何が行われているか理解した上で手抜きするのと、
なんだか分からないがこうすれば出来るからいい、ではその後の理解が違ってくる。
そして前者はつぶしが利くが、後者は環境(フレームワーク等)を変えたら全部覚え直しだ。
プログラマとしてやっていくつもりなら、前者でなくては話にならない。
例えて言うなら、連立方程式を逆行列の暗記で解くな、ということではないかな。
あれは「等式を並べて引いても『当然』等号は成立する」事を理解して
式変形していくことが「数学的に」重要なのであって、
「プログラミング的に」は2x2行列なら確定的に求まる逆行列で実装するが、
暗記しているだけだと、知らないと全く何も出来ないことになる。
実際、大体のBigNumは筆算をプログラムでやっているだけだし、
中身を知らないとちょっとでも外れたら対応ができなくなってしまう。
とはいえ、中学の時点では「とにかく並べて引け」であってその意味を理解しているわけではないから、
初心者にも「全て理解して挑め」ってのも無理はある。
また、現実問題、jQuery厨が言っていることも一理ある。
現実はWebの大半はドキュメントであり、アプリではない。
だから実は「jQueryのシェアはー」ってのも都合のいい誇張で、
フレームワークのシェアを問うなら、「アプリ」のところだけでjQueryの比率を見なければならない。
当然これはだだ下がりのはずだ。 結局は、その本人がどこを目指すか、ではないかな。
デザイナならjQuery程度でもあり、というのも一理ある。
そしてこれが今のJavaScriptの酷さに繋がっており、頭に来ているというのも分かる。
プログラマとしてのJavaScripterの多くは全く成長していない。
理由はクソデザイナ/クソPHPerの下請けだから、というのが多分大きい。
元々与えられたHTMLがクソすぎてJavaScriptだけでは効率を上げられないから、
初学者のJavaScripterはそんなものだと勘違いしてしまうし、クソなコードしか書けない馬鹿も淘汰できない。
そしてクソコードが再生産され、また初学者はそれを見て学ぶ、という悪循環となっている。
俺はWeb系ではないが、全くjQueryを使ってないし、今後とも使うつもりもない。その理由は、
・jQueryは実はフレームワーク化しており、jQueryで生成したDOMはjQuery経由で消去しないとリークする。
・jQueryは「HTMLノードベース」のコードになってしまうことが最悪。
というか、そもそもHTMLにちゃんとクラス付けされてれば、DOMのquery自体ほぼしないしjQueryのメリットはなくなる。
標準のDOMガーって言うのは、
逆に言えば、あれで十分だと判断されているからそれ以上増えないのであって、実際そう。
だから標準だけで苦労するというのなら、それはそもそもコード(というかHTML)の構造がまずいだけ。
(なおこれはlodashにも当てはまる。必要ないから標準に取り込まれないだけ。)
ただ、「クラスベースのCSSは難しい」「SPAは難しい」とされる馬鹿ばかりのJavaScriptの世界では、
この真実を言うとおそらく袋だたきにされ、そして世界は歪んだまま、ということになっているように見える。
正しいプログラミングを出来る奴が切れるのも分かる。
というか、俺も今のJavaScripterは全員死なねーかな、と思っているし。 棲み分けをするなら、少なくともこのスレはjQuery禁止が妥当のように思える。
・プログラマとしてやっていくつもりなら、jQuery依存になるのは不味い。(使うのはかまわないにしても)
そしてこの板はプログラム技術板だ。理解をすっ飛ばしてちゃっちゃとやりたいだけならWeb板でいい。
・今お前が使っているブラウザですら動く物が作れない奴に、各種ブラウザ対応を説く必要はない。
というか、そいつらが独り立ちできる頃には解決されているかもしれんし、駄目ならそのときに教えればいい。
・実際、jQueryは上記のように「ちゃんとした」状況では使いどころがない。
だからプログラマとして「ちゃんとした」JavaScriptを学ぶつもりなら、除外しろ、と言うのも分からなくもない。
そして、実際、今後は「アプリ」のサイトでは次第に使われなくなっていくのも自明だ。使う理由がないから。
・jQueryは抽象レベルも中途半端。というかこれは使う側の問題だが、
DOM+「ちょっと」をワンライナーであちこちに書きまくるのは実はまずい。
それは関数として呼ばれるべき物であって。
だから何を関数化すべきか分からない初心者にとっては標準DOMの煩雑さの方がいいコードになりやすい。
(こういう教条的なのは俺は嫌いなのだが、初心者的に「1行ならインラインで、5行以上は関数で」とかだと、
なまじ1行であれこれ書けるが故に悲惨なことになる。
余談だがPHPも状況は似ていて、あれは標準自体がクソだから上達を阻害している。
Goもクソだが、Go/JavaScript/PHPしか知らない意識高いWeb系がGoに傾倒するのも分からなくもない) まあ、一言で言うと、「jQueryによってお手軽に実現できること自体が成長を阻んでいる」ってのも事実。
彼らはその先の、正しくクラス等を構成したときのJavaScriptの速さ、CSSのメンテのしやすさ等を知ることがない。
ただ、これを知らなくてもいい連中(=デザイナ)も大量に混ざっているのも事実。
だからデザイナはWeb板で、プログラマはこの板で、と棲み分け、方向性もそう絞ればいいと思う。
jQueryは、60点のコードをお手軽に目指す為のものであって、実はどうやっても100点のコードにはならない。
(正確に言うと、100点のコードではjQueryが活躍する場所がほとんど無い)
これを分かった上で使い捨てのコードと割り切ってjQueryを使うのはありだが、
100点のコードをそもそも書けない(書く気がない)のはプログラマとしてはまずい。
ちなみに乱立については、JavaScriptはWeb的民主主義(気に入らないならforkしろ)で行くことにしているようだから、
これは民主主義のコストでしかない。
もちろん君たちが学んだことがフレームワーク等の頓死で全部無駄になるのも、当然として受け入れるしかない。
それが嫌なら全部標準でいけ、ということになる。実際、それでも大して苦労しないし。
事実としてjQueryは役に立つから広く使われており、これがJavaScriptを牽引したのも事実だろうが、
今後役割を縮小して行くのもまた事実だろう。
必要な機能は既に標準に取り込まれた。逆に言えば残りの機能はいらないって事だ。
そしてjQueryを学んだコストが全く無駄になる日もいつか来るし、受け入れるしかないんだよ。 ↑長文で読みにくいなw ってか読まなくていいよw
いくら根拠のない決めつけ、思い込みで語ってもデータがなければ信頼性はゼロだしね
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
2018年の今は73.2%がjQueryを使ってる。未だに増え続けている。
しかも他のフレームワークよりも伸びは大きい
さて結局jQueryは使うのだから、残る問題勉強する順番なわけだがこれを読むと良いよ
挫折する学生が続出したゲーム制作、「学習の優先順位」を変えてみたら見違えるようにモチベが改善した話「ゲーム以外でも大事」
https://togetter.com/li/1202257
> 「Unityでゲーム作るならC言語から」という話題があるようですが、
> Unityを導入するのにあわせて、言語等の必須知識の学習を後回しにすることで、
> 学生のモチベが劇的に改善したらしい専門学校様のスライドがこちら。
言いたいことはこれのまんまだが、言語の勉強したいのでなければ、
つまり解决したい問題があるなら、その解決方法を提示するこそが初学者には重要
成果が見えるとモチベーションにつながる。
DOM APIを勉強するなとはいってない。jQueryの後で良いということ。
俺偉いよな。思い込みじゃなくてデータを示している。 >>134のリンク先を読んでいて、遅延評価勉強法という造語を見つけた
ハッカーと遅延評価勉強法
http://d.hatena.ne.jp/LukeSilvia/20080402/1207149044
> 日本の(というかはてな界隈)ハッカーはほぼ「遅延評価勉強法」をしている気がします。
> ここから遅延評価勉強法とは、「その知識が必要になった時に初めて勉強する方法」です。
> もっと言えば、「○○を学んだから××をやってみる」ではなく、
> 「××をやりたいから○○を勉強する」と定義できます。
> 具体的遅延評価勉強法
> ここからは憶測ですが、遅延評価勉強法を具体的にやるとすれば、それは、「Webのソースを読む」、
> 「Webからコードを持ってきてごにょごにょいじってみる」ということになるのかなと思います。
>
> ハッカーに「良いプログラマーになるためにやることは?」と聞くと、「ソースを読む」ということが
> 必ずといって良いほどでてきます。逆に、「ソース読んでいない人はだめだ」という表現もよく言われていると思います。
>
> この「ソースを読む」とは、そもそも「これどうやって動いているんだ?」と思って
> 初めて実行するものだと思うのです。つまり、遅延評価勉強法です。 wizのスレで延々とffの素晴らしさを説くようなもの。シンプルにスレ違いなだけだ。ffのスレがあるというのに。 http://www.swatz.net/entry/2013/01/13/220400
> 学習効率を落とす「プロセス思考型」に陥っていないか
> 今日とある尊敬している起業家の人にグサリとささるご指摘をいただいた。
>
> 「プロセス思考型」に陥っていないか?
> 「プロセス思考型」とは
> プロセス、つまり過程であり、やり方や方法論をまず考える思考。それがプロセス思考型というらしい。
>
>
> そして、これは非常に学習効率が悪いと教えていたいただいた。
> このプロセス思考の最大の欠点は、非常にシンプルなものだった。
> 考えすぎて、行動を起こさない
>
> その通りすぎて、泣きそうになる。いやマジで。当たり前のことだが、目からウロコだった。
>
> 逆に学習効率の高いのは、これまたシンプルで、
>
> ひたすら行動を起こすこと
俺の行動にも当てはまるな。いろいろ言う前にjQueryでさっさっと答を書く(行動を起こす)
一方いろいろ言ってくるやつは、俺をどうやって追い出そうかの話ばかり考えて
行動(質問者にレスを返すこと)を起こさない >>136
jQueryはJavaScriptのライブラリなのでスレ違いじゃないよ >>138
そうは言ってもアセンブリのスレでエクセルマクロの話するやつはえんがちょやろ JavaScript初心者にはjQuery、DOMは中級者になってから覚えればいい
質問するような人は初心者だからjQueryで答えればいい >>138
実際君だけがjQuery派で、完全に四面楚歌だろ。
理由は簡単で、君以外には自明だからだよ。
jQueryは書く量を減らすことは出来るが、その程度でしかない。
HTMLが正しくクラス構成されていれば、そもそも書かずに済むんだよ。それを君は分かってない。
とはいえ、君は多分見たことがないだけだろうから、適当に探し出して試しに機能追加してみればいい。
あれ?っと思うほど簡単に機能追加できたりするから。 >>140
jQueryで答えて欲しいのならjQueryスレで質問しろ、ってことだろ。 >>139
> そうは言ってもアセンブリのスレでエクセルマクロの話するやつはえんがちょやろ
アセンブリのスレでアセンブリ用のライブラリはOKですね。
そういやアセンブリ用のライブラリはマクロ、通称マクロライブラリって言われてたね >>141
> jQueryは書く量を減らすことは出来るが、その程度でしかない。
アセンブリ言語に比べれば、高級言語なんて全部
書く量を減らすことができる程度よ。
それが重要なんだけどな。
時間が減る、すなわちコストが減るという言い方にすれば
わかりやすいと思うが >>144
だからそれが違うんだよ。
騙されたと思ってclassとID振りまくっているサイトのコードとか見てみろよ。
例えて言うなら、
jQuery: ゴミゴミした町でも、地図やナビがあれば問題なし
正しいHTML: いやそもそも区画整理して、地図なんか無くても迷わないようにしろ
なんだよ。
jQueryは汚い構成をごまかすのに便利だが、最初から美しく構成されてれば使いどころがないんだよ。
そしてその「美しく構成すること」に手間をかけろ、というのが正しいプログラミング道だ。
ただ、JavaScriptの問題は、上流行程のデザイナとPHPerがゴミばかりで、ゴミ処理ばっかさせられる点だ。
そしてそれが日常化しているから、問題だと気づけない。
(だからこれに関してはjQueryの責任ではないんだが…) >>145
何が言いたいのか分からんが、
jQueryが要らなくなるならばDOM APIも要らなくなる
HTMLが汚いなら、DOM APIを使っていても、同じHTMLなんだから汚い
jQueryの話をまったくしてないよお前 それからjQueryが一番有効的に働くのは
綺麗なHTMLとCSSを正しく使われている場合
相性が良いんだよ。 >>147
水掛け論だからもういいけど、俺はjQueryは今後廃れる方向だと確信している。
理由はこれまで書いたとおり。
君がそう思わないのは君の自由。
どちらが正しいかは歴史が証明してくれるし、それを待つしかない。 >>145が「美しく構成する」とか「正しいプログラミング道」とか言ってるけど
根拠書いてないから説得力に書けるだろう? 説明できないのさ。
だから代わって俺が説明するよ。具体的にね
良いプログラミングに必要なことに「宣言型」というのがある
「プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則」の77ページ
https://books.google.co.jp/books?id=biseDAAAQBAJ&pg=PA77&lpg=PA77
> 宣言型でプログラミング
> 命令形のプログラミングは「問題の解法」、すなわちデータ構造とアルゴリズムを記述します。
> 一方、宣言型のプログラミングは「問題の定義」、すなわち説くべき問題の性質や、
> その際にに満たすべき成約を記述します。
> フローがないと読みやすい
> 宣言型のコードは、順序や条件分岐がありません。純然たる事実が宣言的に書かれているため、
> コードが読みやすくなります。
> 一方、命令形のコードは、常に「状態」と「制御」と「データのフロー」を頭に描かないと、
> 事実を正確に理解できません。そのため、流れを追いながら読まなければならなくなります。
> 宣言型を取り入れる
> 例えば、宣言型の汎用プログラミング言語の代表的なカテゴリに、関数型言語があります。
> また、汎用言語ではありませんが、HTMLやCSS、SQLも宣言型です。
> 一方、プログラミングのパラダイムが命令形の言語を仕様スr場合でも、
> 宣言型の表現を部分的に取り入れ、宣言型の利点を享受しましょう。 さて、なんでここで俺が宣言型の話を始めたかと言うと、
察しがいい人と、その話をされたら困る辞めてくれって思ってる人(笑)は
気づいていると思うけど、jQueryは宣言的であるということ
JavaScriptは本来命令型だが、jQueryを使うとHTMLやCSSと同じく
宣言型に書くことができるようになる。
例えばCSSで
.klass { color: red }
みたいなものはjQueryで
$('.klass').css({color: 'red'})
と書くことができる。似てるだろう?文法が違うだけといえる。
つまりjQueryで書くと処理が含まれずに宣言的になってる。
>>145がいう「美しく構成する」とか「正しいプログラミング道」というのは
まさにjQueryのことなんだよ。
もちろんjQueryを使ってもDOM APIの癖で命令型で書いてしまうやつがいる。
それはそいつの問題であって、そんなやつがこんな所に出てきたら
俺が矯正してあげているわけだがw
JavaScriptの問題点を解决している物の一つがjQueryなんだよ。 >>148
> 水掛け論だからもういいけど、俺はjQueryは今後廃れる方向だと確信している。
あんたの確信なんかどうでもいいんだわ
データが去年からの1年間で増えているってことのほうが
よっぽど信頼性が有る
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
2018年の今は73.2%がjQueryを使ってる。未だに増え続けている。
しかも他のフレームワークよりも伸びは大きい >>149
君がそう思うのは自由なんだが、宣言型だけでは遅延描画が出来ないんだよ。
(正確に言うと、状態を持たないコードだけでは遅延描画は出来ない)
だから糞遅いコードになってしまう。
というか、当初俺は何でこんな遅いコードを何の恥じらいもなくこいつらは書くのか疑問だったんだが、
それが関数型()の洗脳の結果なんだよ。
実際、関数型()は何も成果を出せてないだろ。大騒ぎした割には、何も物にならなかった。
宣言的に書いて問題ないところは宣言的に書くべきだ。これは事実だが、
全部宣言的に書いていいわけではないんだよ。この点を関数型()の奴らは間違っている。
何事も適材適所はあるわけでね。
とはいえ、面倒だから全部ブラウザがやれ、JavaScriptは宣言型でしか書かない(キリッ
ってのも最終的にはありだと思う。これはVirtualDOMとして動いてるんだろ。
ブラウザに内蔵されて全自動になれば俺は使うし、コードも変更するが、
それはそのときの話。まだまだ先だよ。
というかね、糞重いサイトとか大体コードが糞なわけで、
関数型()の奴らは命令型で書けないことを隠す為に「宣言的に書く」と言い訳しているだけ。
それが最適なら命令型で書くべきであってね。
動けばいいのなら何でもいいんだが、実際はそうじゃないだろ。JavaScriptはサクサク感が勝負であってさ。
そもそも○○であればいい!ってのは馬鹿であって、何事も適材適所なんだよ。
単純に宣言型にすれば見やすいとか見にくいとか、そういう話でもない。
そしてその辺を振り回して意味無い議論に終始するのがライブラリ厨が嫌われる理由だよ。
jQueryを使うことを必死で正当化しているだけだろ。
実際、ブラウザ間の差異は減ってきているし、jQueryが役に立つ局面は減る一方だ。これは事実だよ。
その上で、使った方が捗るというのなら使えばいい。
俺はメリット無いから使わないってだけ。 > 君がそう思うのは自由なんだが、宣言型だけでは遅延描画が出来ないんだよ。
ほんと呆れたw
理由がさ、いきなり技術的な話
だからダメなんだよ。
ユースケース考えろ。誰が今jQueryを使っているか
そのjQueryを使っている人たちが、遅延描画できないって
騒いてるか? 問題にすらしてないだろ
ほんと自分が言ってることが理由になってないのが
分かってないんだろうな。 その上で、使った方が捗るというのなら使えばいい。
その結果が2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/ >>153
> 騒いてるか? 問題にすらしてないだろ
その結果、サイトがもっさりしてる。
でも技術力が無く改善できないから「問題ない」「こんな物です」と言い張っている。
勿論遅い理由はjQueryを使っていることで、だからこそjQueryを使わない事を肯定されたら困る。
それがお前が必死に抵抗している理由だろ。
jQuery使っている限り生JavaScriptの速度に勝てるはずもなく、
それ以前にjQuery厨は馬鹿だから速度チューニングもマトモに出来ない。
だから世界全体がとろいままでいてくれないと困る。
俺はそんなのにはつきあわない。サクサク感が勝負だ。
そして速いJavaScriptのコードをリリースすることによってjQueryの問題点を露呈させ、
jQueryしか使えない馬鹿共を淘汰することを目指す。
繰り返すが、問題ない部分は何やってもいいんだよ。
それこそjQueryでもフレームワークでも使えばいい。書きたいように書けばいい。
ただな、もっさり感に直結するところは速いコードが必要なんだよ。
それもしないjQeury厨はユーザを無視している。 思うんだけど、これからjQueryは廃れていくと言うけれど
今が廃れた結果なんだと思う
backbone.jsがでた当たり、5年以上前から必要な人は
どんどん脱jQueryをした。そしてほぼ全員が移行してしまった。
今残ってる70%以上のユーザーはそもそもJavaScriptのフレームワークを必要としない人たち。
必要な人達は移行済みなんだからこれ以上jQueryの利用者は減らない。
これからじゃない。もう(移行は)終わってしまったんだよ。 >>155
> その結果、サイトがもっさりしてる。
? jQueryの方が軽いんやで?
Virtual DOMが速いのはウソだった。仮想DOMは遅い。
https://mevius.5ch.net/test/read.cgi/hp/1519842565/ jQueryはフレームワークと違ってライブラリだから
遅いところだけ局所的にチューニングすることが可能 >>156
> 今残ってる70%以上のユーザーはそもそもJavaScriptのフレームワークを必要としない人たち。
これは当たっている。
ただそれ以前に、HTMLが正しく作られていれば、生JavaScriptでも大して苦労しない。
jQueryは所詮糖衣構文を提供している程度であってね。
だから積極的に使う理由はないんだよ。
>>157
今俺は使ってない。jQueryによって速くなることもない。
てかお前もう話について来れてないな?
>>158
だからそれは駄目だと>>131で言ったろ。
jQueryを使うのなら全面jQeuryじゃないとまずいんだよ。 > jQueryは所詮糖衣構文を提供している程度であってね。
> だから積極的に使う理由はないんだよ。
糖衣構文というのは、それが必要だと強く求められたから
使わないでできるのも限らず、採用されたんだよ。
その経緯を知ってるなら、糖衣構文だからこそ積極的に
使うべしってなるはずなんだが。 >>159
> 今俺は使ってない。jQueryによって速くなることもない。
> てかお前もう話について来れてないな?
ついてくると言うか、お前が明後日の方向にとんでいってるのを
眺めてる状態なんだがw
誰も速度なんて求めてない。
わかる?
> jQueryを使うのなら全面jQeuryじゃないとまずいんだよ。
全然まずくないよ。
問題点があるならば、問題点を修正するべきだが、
問題点として考えたれてない部分のパフォーマンスを上げることに意味はない。
最初に考えるべきは、それが問題かどうか
問題かどうかを検証する前に対処するな
具体的に言うならば、50msを5msにしてくれなんて誰も思ってない >>160
だからそれが単なる糖衣じゃないのが問題なんだよ。
テキストベースでやってるから無駄にパースする必要があり、それも遅い理由だろ。 >>161
なるほどお前がやっているのはその程度なのだろう。それなら問題ない。 >>162
> テキストベースでやってるから無駄にパースする必要があり、それも遅い理由だろ。
テキストベースでなんてやってないけど?
そもそも遅くないし。 >>161
おい、全面jQuery化が必要なのは速度ではなくリークの問題だぞ。よく読め。 >>164
jQueryのインタフェースがテキストベースだろ。お前は何を言っているんだ? >>163
> なるほどお前がやっているのはその程度なのだろう。それなら問題ない。
俺だけじゃないね。世界の7割以上がその程度なんだよ。 >>165
> おい、全面jQuery化が必要なのは速度ではなくリークの問題だぞ。よく読め。
jQuery使わなかったらリークするんだねw >>166
> jQueryのインタフェースがテキストベースだろ。お前は何を言っているんだ?
何を言ってるんだよはお前だろw.
document.querySelector('#foo\bar');
DOM API自体がテキストベースだろw >>168
マジで読め。
>>169
なるほどお前はjQueryもブラックボックスで中で何をやっているのか理解してないんだな。
まあいいよ、俺はこれまでもjQueryを使ってないし、今後も使うことはない。
君が使い続けるのは君の自由。
で、これ以上続ける理由無いよな? >>170
> なるほどお前はjQueryもブラックボックスで中で何をやっているのか理解してないんだな。
知ってるが? 今はブラウザがquerySelectorAllをサポートしていれば、
それに丸投げしてる。だからjQueryのインターフェースがテキストベースって
いうのが意味不明なんだが、お前はjQueryのソースコードが見れるのに
ブラックボックスって思っちゃってるんだなw >>170
これ以上続ける理由がないというのなら
質問者にDOM API使って回答しろよw
俺は最初から質問者にjQueryを使って回答している
こんなくだらない話をやめるなら、
俺にかまってちゃんしてないで
俺みたく質問者に回答しろ
今度俺が質問者と話をしてる間に
よこから話しかけて来んなよ? >>171
だってお前コード読んでないじゃん。例えば、
>>149
> フローがないと読みやすい
> 宣言型のコードは、順序や条件分岐がありません。純然たる事実が宣言的に書かれているため、
> コードが読みやすくなります。
> 一方、命令形のコードは、常に「状態」と「制御」と「データのフロー」を頭に描かないと、
> 事実を正確に理解できません。そのため、流れを追いながら読まなければならなくなります。
これ、間違いなんだよね。というかここだけ見ると間違いではないのだけど、
実際の所、こんな局所区画で読める読めない、という話にはならないんだよ。
だからこれドヤ顔で持ってくること自体が初心者の証。
といっても君には通じないだろうけどね。 >>172
> 今度俺が質問者と話をしてる間に
> よこから話しかけて来んなよ?
お前は誰と戦っているんだ?それは俺ではないぞ多分。 はい、みなさん、コレですよコレ
> これ、間違いなんだよね。というかここだけ見ると間違いではないのだけど、
> 実際の所、こんな局所区画で読める読めない、という話にはならないんだよ。
間違いと言うだけで、それがどう間違いなのか理由がない。
よーくみてください。理由がまったく書いてない
反論できないはずなのに、反論した気になってる
そういうレスなのです。
生暖かく見てあげましょうw >>175
まあ俺はそういう煽って情報を出させようとする奴には情報をやらないことにしている。
というか、割と自明だから、どちらが正しいかは分かる奴には分かるし、それで十分だ。 さっきから情報出してあげるの俺だけどなw
お前は情報がないんだから出さなくていい >>175
つうかね、多分君は数行のコードしか読んだこと無いんだよ。だからそういう発想になる。
数千行のコードを試しに読んでみろ。どこで引っかかるか分かるから。 >>179
jQueryみたいに数行の個別関数の固まりだと何万行あっても所詮数行の技術レベルで読めるんだよ。
そうではなく、一つのサイトのコードを読んでみろ。その場合は数千行で十分だ。
そうすれば、俺が何を言っているか分かるだろう。
俺は前から言っているが、お前にはこれが全く足りてないんだよ。
だからおかしな方向に走ってしまっている。 > そうではなく、一つのサイトのコードを読んでみろ。その場合は数千行で十分だ。
> そうすれば、俺が何を言っているか分かるだろう。
読んだ。わからなかった。以上。お前のターン。はい答えろ
(つきあってられるか) >>181
じゃあ諦めろ。
というかマジで1回数千行のコード読んでみろ。色々違った物が見えるようになると思うよ。 >>171
ちなこっちについては教えておいてやる。
(つっても俺は使ってないから確認に時間がかかった)
https://qiita.com/kazu56/items/8e92d08fd1bba0a2d771
jQueryってDOMの生成とクエリを同じインタフェースにしてるだろ。
だから先頭に<があるかどうか確認しないといけない。これで無駄に遅くなる。
(しかもタグの書き方に自由度があり、これでも無駄に遅くなる)
というかその他諸々色々被せてあったと思うが。
まあ便利ではあるんだろうけど、動作速度はその分遅くなってるよ。
傍目からみてちょっとやりすぎ。無駄が多すぎ。 で? 1ns遅くなるから、それがどうしたっていうの? ライブラリの話はライブラリのスレでやれよ。jQueryはライブラリ。ほんと頭おかしい。 >>184
まあ君の問題はそこだよね。自分が問題ないと信じることは問題ないと言い張るだけ。
ただjQuery厨の問題はそこではなく、既に書いたとおり、
問題になっていたとしても絶対に宣言型で糞遅いコードを書くことだね。
そしてjQueryを使ったらjQueryロックされてしまうから生で書きまくるわけにも行かんし。
結果、逃げ場がなくなるという。(対策が出来なくなる)
まあ、jQueryが嫌われているのも理由があるって事だよ。君は認めないのだろうけど。 だからjQueryの速度で問題になってないって言ってるだろ
なんでその議論を無視して問題が有ることにしてるだか
こうやってお前の卑怯な手を俺がバラしてるから
続けても意味ないぞw jQueryは只のライブラリなので、一行ぐらいの単位で
DOM APIを使ったコードと混ぜることができる。
jQueryを使って取得したものに対して、DOM APIで処理したり
逆にDOM APIで取得したものをjQueryで処理したりできる。 jQueryとDOM APIが混ぜて使えることの例を出そうか?
DOM APIで取得したDOM要素に対して、jQueryのcssメソッドで色をつける例
$(document.querySelectorAll('li')).css('color', 'red');
jQueryで取得したものに対して、DOM APIのstyleで色をつける例
$('li').each(function() {
this.style.color = 'red';
});
同様にJavaScriptのmapメソッドを使って色をつける例
$('li').get().map(function(el) {
el.style.color = 'red';
}); DOM API と jQuery で同じイベントハンドラを共通で使える例
var btn = document.getElementById('button')
btn.addEventListener('click', handler, false);
$('#button').on('click', handler);
function handler(e) {
alert(e.target.textContent);
} >>188
だからそれは問題になるときもあるんだよ。
君がやっているコードの規模ではそうならないだけで。
ああそれと、俺は君を飼い慣らしてやろうと思っている奴だから、
他の連中よりは比較的風当たりはマシなはずだぜ。
(追い出すのではなく、有効活用しようとしている)
君がコードを書いて回答すること自体は俺は評価している。
ただなあ、ちょっとピントがずれてるんだよ。
だから君をちょっと教育して、もうちょっとマシな回答が出るようにしたい。
前から思っているけど、君には明らかに「大規模コード」の経験が足りてないんだよ。
だからそれをやれと本当に何度も言っている。
君は数行のコードにフォーカスしていて、それは十分出来ている。
だけどそれがプログラミング上問題になることはないんだよ。その辺を理解できていない。
数行のコードを綺麗に書く技術と、数千行のコードを纏める技術は別物なんだよ。
君には後者の視点が全くない。だから回答がちぐはぐになっている。
だから、騙されたと思って、マジでちょっとでかいの書いてみ?多分世界が広がるから。
そしたら今の君がずいぶんトンチンカンだったことも分かるだろうし。 >>192
> だからそれは問題になるときもあるんだよ。
> 君がやっているコードの規模ではそうならないだけで。
俺だけじゃない。世界の大部分が問題にならないっていったろ
大部分っていうのは全部じゃない。
俺と同じことを言うな。
お前が言ったことじゃない。俺が言ったことだ
大部分は問題にならないと >>192
> 前から思っているけど、君には明らかに「大規模コード」の経験が足りてないんだよ。
> だからそれをやれと本当に何度も言っている。
説得力がない。まず行動を起こせ
俺に経験が足りないと口先だけでごまかすことは行動じゃない
まずお前がコードを書け
大規模経験者ならではだとわかるコードをな >>192
> 数行のコードを綺麗に書く技術と、数千行のコードを纏める技術は別物なんだよ。
> 君には後者の視点が全くない。だから回答がちぐはぐになっている。
なんだ、大規模なコードを書いたことがないのはお前じゃないかw
関数一つやファイル一つで、数千行書くのは大規模なコードとは言わない
大変なだけなコードだ
大規模コードの開発者は、数行のコードの集まりで
数千行のコードを作るんだよ。
そんな事も知らないのか? 例えばjQueryのコードだって、1万行を超えている
https://code.jquery.com/jquery-3.3.1.js
お前の定義では大規模なコードになるだろうが、
ソースコードを見てみろ
https://github.com/jquery/jquery/tree/master/src
それぞれが数十〜数百程度の短いコードのファイルがたくさんある
関数一つで見れば殆どが数行から数十行だ
それらをビルドでくっつけることで1万行を超えるコードにしてるんだよ。
数行のコードと数千行のコードで書き方が違うって
それはお前が大規模なコードの経験がないだけだ つーか、自分が思う大規模なコードのプロジェクトの一つでもあげたら?
どれも数行のコードの集まりでできてるだろうさ
俺から大規模なコードのプロジェクトを一つだしてあげよう
JavaScriptではなくRubyだが
https://github.com/gitlabhq/gitlabhq
gitlabは大規模なコード中でもコードの品質が高いものだ
数行のコードの集まりでできてるぞ。ほとんどの関数はかなり短い >>196
だからそれは既に言ったが、それは初心者でも読めるコードでしかないんだよ。
それをいくら読んでも今の君以上には上達しない。
てゆうか君がどうしたいのか俺にはさっぱり分からない。
上達する気があるのなら、俺がオススメするのは「大規模コードを書くこと」であって、
それは君自身がやらなければならないことだからいくら俺を煽っても意味がない。
俺を信じないのも君の自由だ。
コードの組み方にも色々あるのだけど、ライブラリみたいに平べったいコードばかり読んでても駄目なんだ。
いや、読むこと自体は悪くはないが、同じタイプのコードを何度読んでも駄目なんだ。引き出しが増えない。
だから今の君は平べったくないコードを読まないといけないのだけど、君にはここら辺の話も通じないだろ?
まあ君が上達すれば俺が今何を言っているか分かるだろうさ。どうするかは君の自由で。
ちなみに俺はjQuery厨を追い出そうとしているのではなく、改心させようとしている。
つまり、教育することで「jQuery使えばいいってわけではないんだな」と悟らせ、
結果的にjQuery厨を除去しようとしている。どうも食いついてこないのだが。 極論質問される度にライブラリ作って、『それは「run()」で済むよ』という回答があったとして
それは単純に考えて一番スマートな解決策とも言えるわけだけど、
こういう場で人に教えるにあたっては不味い点もあるということは分かるだろう? 今は人の作った便利なものを使いこなす能力のほうが求められている 今日はjQuery厨がpythonスレをrubyコードで荒らしてるクズと同一人物であることが分かったな。性根が腐ってるわこいつ >>198
だから理由かけって、
お前はこうなんだ!って言うばかりで、
なぜなのかその理由がまったく書かれてない
説得力ゼロなんだよ それから勝手に俺が大規模コード書いてないような
こと言ってるが書いてるからなw
これもいつもの思い込み、決めつけ
一つのファイルで1万行超えるクソコードを再設計して最終的に
半分以下まで減らしたし(半分までで終わりな転職したから)
一人でやってるプロジェクトでも今数えたら4000行以上のものがある
(俺は数千行程度で大規模コードとは思わんが、お前がそう思うんならそうなんだろう) 初歩的なことですみませんが教えてください
Javascriptのアプリ作成でnpmとかbowerとかいうのを使うみたいなんですが、
コマンドを実行するとnpm_moduleというディレクトリとbower_componentsというディレクトリに数百ディレクトリ+数千ファイルが出来上がって怖いです
アプリ使ってくれる人がサイト見るたびに数千ファイルダウンロードとかやってられないと思うんですが、これ全部アップロードしないとダメなんでしょうか? >>205
webpackとかparcelを使って一つのファイルに纏めて使うよ。 >>206
お早いご返信ありがとうございます
容量100MB超えていてどうなるかと思ったんですがwebpack試してみたらbundle.jsは1kb程度になったので一安心です せっかくモジュールで分かれていて各ファイル毎にキャッシュが効くし
HTTP2とかにしたって選択して必要なものからプッシュで送っていくことができるようになってるのに
そういうメリット全部殺して1つに纏めるとか愚の骨頂だな parcelは知らんがwebpackは好きにカスタマイズできるぞ >>203
お前がそういう設定なのはお前の自由だが、誰も信じないよ。
お前が言っているような、
jQueryを使えば全てハッピー、コードも綺麗になるし問題は全て解決!なんて事には全くならない。
だからこそフレームワークが乱立しているわけでね。(それが上手くいっているかはさておき)
jQueryを廃止したがっている連中もかなりの数いて、ググればいくらでも出てくるだろ。
そしてそれもある程度妥当な意見なんだよ。これはちゃんと認めないと駄目だ。
君は「俺が正しい、お前が間違い」という言い方しかしないが、そういうことにはならない。
Web的民主主義では、各自が各自なりの解決策を考えて実行している。
そういう流れがあるってのは、一定数の支持を得ているから。
勿論jQueryを使い続けている奴もいるし、君がそうしたければそうすればいい。 ちなみに教育方針について言うと、
たった数行のコードも書けないような>>77に対して、ライブラリを勧めるのは確かに間違っている。
それだと、いちいち引っかかる度に聞きに来るのか?となるだろ。きりがない。
少なくとも数行のコードは自分で書けるようにならないと話にならない。
美しくなくてもいいが、ちゃんと動くコードを自分で書けないと駄目なんだよ。まずはそこからだ。
逆に、その程度は書けるというのなら、質問者自身がそれを証明する必要がある。
大前提としてここは匿名掲示板なのだから、自分が何者かは全て投稿で決まるんだよ。
だから数行で書けることについて「一番いい方法」を単に聞くのは、
数行のコードも書けない馬鹿なクレクレ君だと言っているようなものだし、実際そんな扱いだろ。
書けるのなら、「俺はこう書いてみたが、どうもしっくりこない。もっと別の書き方がないか?」と言って
コードを出せば済む話であってね。
だから質問の仕方なりの回答をするのは極めて妥当で、
逆に、未熟者扱いされたくなければ、ちゃんとそうだと相手にも分かるような投稿をしないと駄目なんだ。
お前にはそういう、コミュニケーションする上での大前提ってのが欠けてる。だから話が空回りする。
再度言うが、あの質問に対してライブラリでの回答は不適切だ。
あと技術的観点で言うと、厳密に言えば、filterも_.differenceもシャローコピーを返すから
> ある配列から別の配列に存在する要素を削除する
事にはならない。
ただ実際はシャローコピーでも問題ない事が多いし、お前らも区別してないようだけど、
本当はこういうところをキッチリ詰めていかないと駄目なんだけどね。
とはいえそもそも質問者も区別できてないし、いちいち言う価値もないから放置だけどね。 >>210
> jQueryを使えば全てハッピー、コードも綺麗になるし問題は全て解決!なんて事には全くならない。
誰がそんなこと言ったの?
少なくとも俺は言っていない。
じゃあ誰が言ったのか?それはお前だよ。
お前が「jQueryを使えば全てハッピー、コードも綺麗になるし問題は全て解決!」
って言ってるんだよ 馬鹿なんだろう。結局思い込みだけで話しをしてることが
明らかになったし説得力がまったくない >>212
人からどう思われるかが大事なことだぞ
君が世界の中心じゃないんだから >>215
ちゃんとコミュニケーション取れるようになれよw
そんな話してないだろ >>212
jQuery厨は池沼です!って自己紹介乙。
お前はそういうところが駄目なんだよ。
いいかい?今このスレにjQuery厨は君しかいない。
そしてその君が小学生レベルの論理でドヤ顔をしている。しかも>>117に続き2回目だ。
どうやら君にはこれが切り札らしい。
それを見て、他の人がどう思うかだよ。
君が何をしたいのかさっぱり分からないのだけども、もしjQueryを布教したいのなら、
そんな幼稚な考えでいることを示したら、完全に逆効果だよ。
jQueryを必死で肯定している奴はこんな馬鹿しかいない、と取られてしまう。
>>104はよく書けているし、全くその通りだよ。
そしてここは、最後に言った奴が勝つ場所ではなく、
双方が持論を勝手に述べあい、読者がどっちが正しいか勝手に判断する場所だ。
賢く振る舞うってのも重要なんだよ。
大体お前、自己矛盾にも気づけてない馬鹿だろ。
>>196の論理に依れば、どんな大規模コードでも数行の関数の固まりだから読める、とお前は言う。
ならば、どんな長文でも単文の固まりでしかないわけだから、長文を読めないお前は矛盾するだろ。(>>134)
単文が読めれば、後は繰り返すだけなんだろ?
長文内部で論理を構成する技術なんて、存在しないんだろ?
プログラミングも同じなんだよ。
末端の関数を小綺麗に書くのと、それらを組み合わせて巨大論理を構成する技術は別物だ。
お前はここら辺を全く理解できてない。
そして、こんな事はいちいち俺が指摘しなくても他の連中も分かってる。
それで、俺と君の言い分を見比べて、どっちがマトモっぽく見えるかだよ。 どうでもいい書き込みをしたいだけのやつ
VS
俺は(jQueryで)回答したいだけ > 末端の関数を小綺麗に書くのと、それらを組み合わせて巨大論理を構成する技術は別物だ。
別物だというのなら、なおのこと、
巨大論理(何そのオレオレ用語?)は今する話題じゃないな
末端の関数を小綺麗に書く話(質問者の質問自体が小さな関数の話なんだからしょうがない)を
している段階で、巨大論理しってるかー、巨大論理しってるかーって言われても
今その話関係ないですよね?で終わり
巨大論理の話したいならネタふれや。俺はそれにも対応できる。
まあオレオレ用語使ってる自体で、経験ないってわかるけどな > >>196の論理に依れば、どんな大規模コードでも数行の関数の固まりだから読める、とお前は言う。
> ならば、どんな長文でも単文の固まりでしかないわけだから、
↑上記は間違い。
× どんな大規模コードでも数行の関数の固まりだから
○ どんな大規模コードでも数行の関数の固まりにするんだから
お前の超巨大なクソコード関数が、勝手に小さな塊になるわけじゃない
俺を含めたプロは小さな塊に"する" のだから当然読める 巨大論理くんは、明日俺が見るまでに巨大論理のネタフリしておくように >>222
日本語でおk
というかやっぱりお前は馬鹿なんだよ。どうしてそういう話になっているのか、
またそれが明らかに技術用語ではなくてただの日本語だとも理解できないんだろ。
それが君が「長文を読めない理由」だ。君は論理を追えてない。日本語能力にも問題がある。
君がjQueryにこだわるのは君の自由だが、
他の人が怒っているのは、君の回答は質問者の為にならないから。
ピントがずれてるから、長期的には本人の為にならないんだよ。
だから君は邪魔者だとされ、他の人は君を追い出そうとしている。
俺は君の回答する姿勢だけは認めるから、君を有効活用しようとしている。
君がピントがずれている理由は俺には明確に分かるから、修正を試みている。
それで君が有効な回答が出来るようになれば、追い出そうとしていた奴らにとっても利益だろ。
というのは既に俺は言ったし、それ以前に読み返せば分かるだろ。
君は以前から話が複雑になったら定期的にサマリを求めるが、それは君が論理を追えないのを隠す為。
それは君が馬鹿だから。俺の話は終始一貫しているのだが、君はそうだとも気づけない。
プログラミング言語と自然言語は別物だが、この点に関しては同じだ。
君が77から始まる一連の流れ(約150レス)を追えないのは、君の頭の中の論理スコープが150レス分以下だから。
だから話の発端等がスコープ外になってしまって、君にとっては何がなんだか分からなくなってる。
そしてそのたびに君は定期的にサマリを求める。それは例えば以下もそうだろ。
> 長文で読みにくいなw (>>134)
日本語を読めないのを隠す為に、読みにくいということにして短く書き直すことを求めている。
実際こう言われたら3行サマリを出す奴が多いから、君はこのやり方を覚えたんだろう。
だけどそれは君が気づいていないだけで、普通に話に付いていける人にとってはウザイだけ。
俺も何度も「それは既に言ったが」と言ってるだろ。
君の頭が悪いのは君の責任だ。話について来れなければ、分かるまで何度でも読み返せ。
それに対して他人の努力を求めるのはお前の傲慢だよ。お前が気づいていないだけでね。 見たところ、お前の頭の中は4レス分くらいしかワーキングメモリがない。
だからそれ以上の論理を組まれると読めなくなっている。
これは普通の人よりはかなり馬鹿で、話が通じないキチガイだと取られて当然だ。
君の戦闘力が4だとすると、俺や他の人の戦闘力は150よりは上って事になる。それくらい差がある。
頭の中で論理を追えなくなったら読めなくなるのはプログラミング言語でも同じだ。
だから「必要論理スコープ」が小さくなるようにコードを書け、というのが最近の作法で、
具体的には「狭いスコープ」「短い関数」であり、上位レベルでやると「粗結合」「OOP」になる。
これ自体は悪いことではないんだが、問題は、この結果、
頭が悪いままのやつが淘汰されないことと、全く鍛えられないことだ。
マラソンを走れる奴がジョギングするから余裕があるのであって、
ジョギングしかできない奴がジョギングしてもそれはいっぱいいっぱいでしかない。
良いコードは能力値に余裕がある状態でないと書けない。
だから上達する為には能力値を上げることも一つの鍵であり、
これには限界近くまで負荷を高めないといけない。
電卓ばかり使っていたら計算能力なんて高くならないのは当たり前の話だ。
自分に計算能力がなかったら、自分で鍛えるしかない。
だから基礎の基礎の部分では敢えて苦労しろというのも当たってはいる。 馬鹿な君が書いたコードは、確かに短くて、君みたいな馬鹿でも読めるコードなのだろう。
これ自体は悪いことではない。
ただ問題は、実は粗結合はオーバーヘッドもかなり伴う、ということ。
俺が思うに、実行効率で10-100%、コード量で20-50%悪化する。
だからどこまで密結合で組み、どこから粗結合にするかはちゃんと設計しないといけない。
全面粗結合で書いたコードは簡単でいいが、逆に言うとそれだけが取り柄なんだよ。
クラスベースのHTMLについて、反対している奴はいないだろ。
これは当たり前の話で、HTML/CSS/JavaScriptの全てが見通し良くなるからだ。
ところがこれは難しいとも言われてるだろ。この理由も簡単で、
クラスを通してHTML/CSS/JavaScriptが密結合してしまうからだよ。
ただ、この程度の密結合なら、常人でも扱える範囲だ。だから「良い」とされているわけであって、
逆に、超人しか扱えないレベルなら、「そんなん使えるかボケ!」となる。
だからHTML/CSS/JavaScriptの世界は緩やかにクラスベースに移行していく。(てか今既にそうだが)
そして君はそれに付いていけない。
理由は君の頭の中のワーキングメモリが一般人比で著しく足りないから。つまり馬鹿だから。
だから俺はまずそれをさっさと増設しろ、それがお前の為にもなる、と言っている。
少なくとも、常人程度のワーキングメモリは持っておかないと駄目なんだ。
いろいろなところで付いていけないから。君が長文を読めないのもこれが理由だよ。
お前は今、淘汰されるべき側にいる。それを自覚しろ。 例えて言えば、お前の脳には400MBのRAMしか積んでないんだよ。
だからお前はその中でやりくりしているし、その世界しか知らないから、不自由を感じれない。
ところが俺たちは15GB積んでいて、400MBじゃ話にならない事も知っている。
それだけの違いがある。これがいろいろ話が通じない根本の理由だよ。
鍛える為には、日本語でなら、長文を何度も読んで読めるように努力することだね。
読んでいるうちから頭の部分を忘れているようでは話にならない。
JavaScriptでなら、「それなりに密結合した」大規模論理を書くことだね。
それは今君がやっている、ただ単にくっつけただけの平べったい論理構成ではだめだ。
とはいえ、JavaScriptのコードは確かにその類が多いのも事実ではあるが。
特にjQuery厨はそうなりやすい。これがjQueryの不味いところでもある。
(ただし既に言ったようにこれは使い方の問題であり、jQuery自体が不味いわけではない)
反jQueryの連中は、jQueryを使ってきていて、その中で様々な問題に遭遇していて、
環境が変わりつつある今、最早メリットよりもデメリットの方が上回る、という判断を自分でしている。
君は自分で判断する能力が無く、単に「みんなが使っているから」と繰り返すだけ。
まだメリットの方が上回るという見方ならさておき、君は何がデメリットなのかも理解できてない。
そこら辺がやっぱりズレてるんだよ。
マウント取りたがったところで、ちぐはぐさが痛いだけ。
もちろんその痛さを垂れ流すのも君の自由ではあるが。 SPAといい、話が読めてなさすぎるだろ。
話が読めてないのに長文書くから余計に主張の意味がわからん。
せめて話を読んでから長文書こうか。 話が読めていないと言うのは簡単だわな
俺の気に入る話しかするな、受け付けんぞっていってるだけだが
彼はあれだけの分量で誠意をもって話をしてるんだから
今は間違いなく彼が話の中心
話を読めていないのは君>>230
誠意をもって適切な文量で返答しろ 分量を書くのが誠意なの?
小学生の作文の宿題みたいで微笑ましいw 凄まじい長文を書いても結局1ミリも世界を変えられてない事に気付いてるかな?
簡潔な言葉でブレイクスルーを生み出そう 確実に言えることは、俺の4レスの意味を取れる奴と取れない奴がいること。
そして、読めない奴に限って「お前の文が悪い」としたがること。
これはプログラミング言語でも同じだ。
大規模プログラムがあったとして、それが読めないとき、
初心者は常に「コードが汚いから」と言うが、実際は「お前の頭が悪いだけ」だ。
今回もしかり。
お前らはそうやってずっと逃げてきているのだろうよ。
ただ、今後ともドキュメントは増える一方だし、読みこなす力も求められる一方だ。
2chの長文なんてリアルの論文なら序文程度にしかならないし、
お前ら普段からどんだけドキュメントを読んでないんだ?
これについてはマジで鍛えた方がいい。
今後のプログラマはドキュメントを読めないと話にならない。
BitCoinとかお前ら向きだと思うぞ。
http://www.kk-kernel.co.jp/qgis/HALTAK/FEBupload/nakamotosatoshi-paper.pdf 誰が見ても文章力も技術力もjQuery厨のほうが上だぞ >>232
違うよ。
伝わらなきゃ気に入るも気に入らないも無いよって言ってる。
こんな短い指摘も読めないのに長文書かないで。
頭の方で間違ったら軌道修正もめんどくさい。 ajaxでロードした部分自体にその部分リロードするボタンを作りたいのですが、
ロードされた自身のアドレスを取得する方法ってありますか? >>242
無いから、ロードするときに変数に取っとくかDOMの属性に追加するか、iframe使うぐらいしか無いと思う。 >>243
パスのことです不正確ですいません
>>244
ありがとうございます
なんとかしてみます 巨大論理くんよりもjQueryアニキの方が
何倍も技術力上だと思うわ 出来合いのライブラリを使う = ライブラリを使うしか能がないってことにならないよ
jQueryのプラグインも作れるし、オリジナルのライブラリも作れる。
てかそういう事言ってると、OSのAPI使うしか能がないとか言えてしまうじゃん javascriptのライブラリって、chromeの特定のバージョンのバグ対策とか、そういう細かい処理が入ってるから
自分で作ってもゴミが出来上がるだけなんだよね おいおいライブラリなんだから当たり前だろ。
そういうコードが書かれてるんだよjavascriptで。
そのjavascriptレベルの話をするスレで1ライブラリのAPIの話するって頭わいてんのか 1ライブラリだって思ってるからダメなんだよ
お前の基準だとどのライブラリだって同じ1ライブラリ扱いにされてしまう
世の中には世界中で多く使われている品質が高いライブラリもあれば
個人が作ったそいつやその会社でしか使えないような覚える価値のないライブラリも有る
そういうのを取捨選択することも含めて
JavaScriptを使ったプログラミングなんだよ 動的に追加した要素がその下にある要素
に重なってしまうんだけどこれを解決するには
どうするのが一般的ですか? リンクをポップアップで開く系のjQueryプラグイン使ってるのですが
Biggerlinkでリンクをdiv要素に拡大させた部分をクリックすると通常ウインドウで
開いてしまいます
これをうまく回避する方法はありますか? jQuery の質問は、web制作管理板のjQuery のスレへ、書き込んで Node.jsについてですが、
変数がとっちらかるのが気になるので、
各種フレームワークみたいにアプリケーション全体を包括するクラスを作って、
(new Application()).start()
みたいな形で全てを起動したいと思います
各種モジュールも、クラスのプロパティに読み込みたいと思います
でも、こういうやり方をJavaScript界ではあまり見ない気がします
何故でしょうか? const path = require('path');
const url = require('url');
const fs = require('fs');
const os = require('os');
みたいな形に、
いきなりグローバル空間にモジュールを入れた変数をごろごろ転がすのって
何か気持ち悪いです
クラスがしっかり管理して、
pathでなくて、this.pathやthis.modules.pathでアクセスした方がずっといいと思います
でも、何故JavaScript界ではそうしないのでしょう?
あほなのでしょうか? グローバル空間に転がしたところで同じ物を指すならそれで良いと思うけど。
クラスベースじゃなくてプロトタイプベースだから、それで良いというか良かったというか。
やりたいなら、クロージャ内に持たせればいいんでないの?
nodeの場合はファイル単位のスコープになってるから、別にconstで適当に放り出していいと思うけどね。
ただ、thisが指すものもコンテキスト次第だから、this.modulesはナンセンスな気がするよ。
modules.path = require('path')
とでもすればいいんだろうけど、それも実質
const path=require('path')だよ。 JavaScriptの一般的なやり方は、
コードの中に変数が出てきた時に
その変数がどこで定義したものなのか、
変数を参照しているコードだけでは分からないというところがイケてないのです
アプリケーション側で用意した変数なのか、
モジュールを読み込んだ変数なのか、
それともローカル変数なのか、
変数を参照しているコードだけを見ても分かりません
しかしクラスがアプリケーション全体を管理するやり方だと、
ローカル変数なら単体でそのまま書かれているし
それ以外の特殊な変数ならクラスのプロパティとしてアクセスするので、
変数記述部分からすぐに分かります
イケてますね? >>261
> みたいな形に、
> いきなりグローバル空間にモジュールを入れた変数をごろごろ転がすのって
> 何か気持ち悪いです
そのコードを書いたのはお前だろ?
つまり気持ち悪いのはお前だよ >>264
> JavaScriptの一般的なやり方は、
それはお前のやり方だろ?
イケてないのはお前だよ 自分でクソなコード書いておいて
このコードはクソだー!って叫んでる
なんて愚かなのだろうか
ばれないと思ったか? >>264
何を言ってるかいまいちわからんが、メンバ変数が持てないから悪いって言ってるのかな?
それは、Javaで言うimport xxxx.yyyy.zzzzした、zzzzも同じようなもんだと思うが。
向いてないから辞めたら? JavaScriptでグローバル変数が使えなくなって
もう何年たつっけ?10年? JavaScriptって今いちばんイケてる言語だよな >>264の件ですが
モジュールを全てクラスの属性にしてしまうと
jQueryとのバランスが美しくなかったりといまいちなことが分かりました
それに全てを一つのクラスにするのは、
コードをモジュールにするのと大差ないといえばありません
一番不満なのは、変数宣言や初期化の場所がとっちらかってることと
エントリーポイントが分かりにくいことなので
・変数宣言と初期化は、コードの先頭(require処理の後ろ)にまとめて置く
・エントリーポイントはmain関数にまとめる
・main関数はコードの末尾で呼び出す
としたら、
まぁクラス化しなくてもいいかと思える感じになりました
ありがとうございました 「Node.js超入門、掌田津耶乃、2017」を読めば?
実は、Node.js だけでは面倒くさいから、それだけでは作らない。
Express + Express Generator フレームワークを使う
Node.jsは、Ruby で、Sinatra を、full scratch で書くのと同じ。
Express + Express Generatorが、Rails と同じ
だから先に、Rubyをやれば、フレームワークが理解しやすい >>272
意味不明
jQueryって只のライブラリだよ?
ライブラリをクラスでどう使うよ?
クラスの中で使うでしょ。
単にDOM操作をjQueryで行うだけだよ
あんたが思うバランスの良いコードを
単にjQueryつかえばいいだけだよ Node.js & Express From Scratch
https://www.youtube.com/watch?v=k_0ZzvHbNBQ&list=PLillGF-RfqbYRpji8t4SxUkMxfowG4Kqp
YouTube に動画ある >>264
変数名で特定できるようにすればいいじゃん 今のカーソル形状って取れるんだっけ?
やりたいことは「ポップアップ内の文字選択も出来るようにしたい」なのだけど、
かなり大きめのポップアップも出ることがあるので、今はポップアップ自体の移動を出来るようにしていて、
この結果、ポップアップ内の文字選択が出来なくなっている。(動いてしまうから)
今のカーソル形状が取れれば、テキスト用カーソルの時だけ移動しなければいいだけなのだが。
document.body.style.cursorには反映されてないところまでは確認した。 テキストノードのテキストへの当たり判定って出来ない?
カーソル形状は単純には取れないようなので、(第一のガン)
mousedown でどこで押されたかを確認するようにしたのだが、
そもそもテキストノードは e.target に入らないので、(第二のガン)
親エレメントで受けるしかなく、そこから走査するしかない。
この場合、Element.getBoundingClientRect() を使って e.clientX 等と比較することになるが、
Nodeにはこのメソッドが無い。(第三のガン)
結果、テキストノード上のテキストへの当たり判定が出来ない。
(なおいちいち当たり判定しても、
文字列が行の途中で終わっているときに対応できない。---(A)
この場合、ブラウザは正しく文字の真上だけ文字選択カーソルにするが、
自前で走査すると文字列が終わった画面右の方でも当たりの判定になってしまう。)
これってマジ?
そうならAPIの不備だよね。経緯は色々あるのだとは思うが。
selection API (onselectstart) も試したが駄目だ。これも上記(A)の時に対応できてない。
こちらに見落としや違う方法での実装方法があるならご指摘よろしく。
希望としては、「文字の真上=文字選択カーソルの時は選択、それ以外は移動」としたい。
ブラウザが当たり判定をした結果の「今のカーソル形状」が取れれば一番いいのだが。 そもそもポップアップのどこでもDnD可能にしていることが大間違い
もしブラウザの画面がそうだったら困るだろ?
ウィンドウには頭の部分にDnD可能なバーを付けるという「常識」があるのだから大人しくそれに従えばいいだけ
全面DnD可能にするのは動画窓くらいのもの >>279
> ウィンドウには頭の部分にDnD可能なバーを付けるという「常識」があるのだから
ウインドウはそうだが、俺が言っているのはポップアップだ。
ポップアップにタイトルバーを付けたがる馬鹿はいないだろ。
俺はいちいちタイトルバーを触るUIはダサいと思ってるんだよ。
カーソルの形が変化するのだから、今どっちのモードかは誰でも分かる。
「文字」の上でDnDすれば文字選択、「余白」でDnDすれば移動、というだけだ。
PDFで言う「選択」と「手のひらツール」の自動切り替えでしかない。
動画窓なんて全面移動でいいのだからタイトルバーなんて付けてる馬鹿はいないだろ。
というか、昔は付いていたが、だんだんと外れて来て、最近は本当に動画部分だけになった。
余分な物は表示するべきではない、というのは当たってる。
確かに今から考えると昔の画面は無駄だったろ。スマホ(画面が狭い)の影響かもしれんが。
まあ、上記俺のUIに慣れたら、タイトルバーなんてダサいと思うようになると思うよ。
そして、俺はWindows等も同じ方向に行くと思っている。
とはいえ、結局やっぱり取れないのか?
せっかく当たり判定を全部ブラウザがやってくれてるのだから、結果だけ欲しいんだが。
stackoverflowとかも見たけど、やっぱり出来ないみたいなんだよね。 ダサさでは無く直感的なわかりやすさを重視すべき
それに今回はどちらにせよ動画の話みたいにはできないだろ
動画の件とは逆にどこでもDnDできちゃ不味いという話なんだから
どちらにせよポップアップにDnDできる領域を作らないといけない
まさか文字の隙間でDnDしたいわけではないのだろう?
テキストの部分触ってもDnDできなくて、その周りの空白部分でDnDできるとか分かりにくいし
それなら空白の代わりにDnD可能そうなバーを付けたほうが明らかに良いだろう?
まあ別にそのバーをデザイン上の問題でどうしても透明にしようが何れにせよ
テキストとは別にDnD可能領域をつけることでできるよ その直感の元ってwinやmacのウィンドウシステムやん。
新入社員がパソコン使えないとニュースになる時代、バーを見てドラッグアンドドロップできそう!って思ってもらえるかね。
スマホアプリにはd&dできるバーなんて無いぞ。 >>280
TextNodeはDOMの仕組み的にElementじゃないからその手のメソッドは持ってないし、持つべきではない
普通に<span>とかのインライン要素で囲めば判定できる
ただ、1行選択する場合とかは余白からドラッグするのが一般的なので、使いにくい人もいるだろうね
スマホでもそんなUIを採用してる例はないし、長押しで移動モードとかの方がわかりやすいかもね >>281
> まあ別にそのバーをデザイン上の問題でどうしても透明にしようが何れにせよ
> テキストとは別にDnD可能領域をつけることでできるよ
それは分かっているし、実際 autohide のタイトルバーも採用するつもりでいる。
ただし別件でだが。
> テキストの部分触ってもDnDできなくて、その周りの空白部分でDnDできるとか分かりにくいし
これで十分なんだよ。
カーソルが「文字選択」なら文字選択になるし、「それ以外」なら移動になる。
必要なら「移動」カーソルに変えておいてもいい。だったら見たとおりにしかならんだろ。
そもそもこの切り替えも付けるし。(全面移動か、上記自動切り替えか)
なお、デザイン上、余白部分はかなりあるから、つまむのに苦労するということはない。
というか「余白」という曖昧な表現を使っているから不味いのか?
例えば、PDF文書なら、通常左右の端から3cmずつくらいは必ず「余白」になってるだろ。
そして文字選択する場合、必ず当該文字の真上から開始するのだから、あれも単純に、
・文字領域の上からDnDを開始した場合、文字選択
・左右の余白領域の上からDnDを開始した場合、「手のひらツール」で文書そのものの移動
でよかったと思うんだよ。それでカーソル形状を変化させてれば、混乱しようもない。 ポップアップが巨大で1画面の高さを超えることもあるから、タイトルバーでは駄目だというのもある。
例えば2chで同一IDや返信をポップアップするとして、数が多ければ1画面の高さを越えるだろ?
これと同じ。俺も必要なだけ出すから。これに対する解は、
A. ポップアップにタイトルバーとスクロールバーを装備(正規ウインドウ化)
B. ポップアップを元画面に固定、元画面のスクロールによってスクロールさせる…大体の2chブラウザがこれ
C. ポップアップ自体に移動/スクロール機能を付ける…現状だが文字選択が出来ない
D. Cに対して自動切り替え機能を導入し、文字選択できるようにする…これをやろうとしている
なんだよ。君がA推しなのはいいし、実際そうしているアプリもある。
ただ、今俺が試したいのはDなんだよ。多分混乱はしないし、一番いい解だと思うから。
Bは、元画面をそこまでしか読んでいないのに、
ポップアップを読む為にスクロールして、戻ってこないといけないのがウザイ。
Aは、ポップアップとしては不味いUIだと思っている。
ポップアップはタイトルバー等がないことによって「不完全なウインドウ」であることを明確にしている。
そしてそれは「不完全」だからこそ、自動消滅するということで辻褄が合っている。
「完全な」ウインドウが自動消滅するようでは不味いんだよ。俺はそこは、
・タイトルバー等を装備した「完全な」ウインドウは永続的であり、明示的消去動作のみによって消去される
・「不完全な」ウインドウは、自動消滅する
という、分かりやすいラインに従うべきだと思っている。
ポップアップを移動させたいが為だけでタイトルバーを付けてこの原則を崩すのは悪手だ。
ということを言い出してもきりがない。
所詮はGUIは感性の産物でユーザー主観でしかない。
だから全部実装してユーザ選択にするのがベストだし、最終的には多分そうする。
そして今回はDを実装して試そうとしているだけ。 >>283
> TextNodeはDOMの仕組み的にElementじゃない
見た目そんな感じだね。
> 持つべきではない
そんなわけない。TextNodeがTextElementであっても何も問題ないだろ。
> 普通に<span>とかのインライン要素で囲めば判定できる
出来ない。正確に言うと、出来ることを保証できない。
<span>で囲んだだけでCSSでは別扱いでき、フォントサイズ等が変更される可能性もある。
だからこの方法では「出来るときもある」だけであり、「出来る」というのは間違い。
ただなるべく無駄なことはしたくないので、DOM変更で対応するのは最後になる。
あと、この方法だと結局長方形としてしか扱えず、
複数行で最終行だけ短いとき等にも対応できない。
ブラウザ自身はこういう場合も問題なく当たり判定して、文字の上の時だけカーソルを変えている。
> 使いにくい人もいるだろうね
どのみちユーザ選択にするから問題ない。
> 長押しで移動モード
これはかなり最悪。ゆっくり選択することが出来なくなる。
右クリックメニューで「移動」「選択」モードの明示的切り替えの方がマシ。
今のところmousemove/downをdispatchEventしてSelectionが変化するか見ようとしているが、
反応しねえ。 Canvasに描画すればmeasureTextできるから、努力すれば各行の幅が取れる
もしくはSVGのforeignObjectにスタイルなどを適切に適応したポップアップ部分の複製を入れて
テキスト背景色などを調整した上Canvasに描画して当たり判定をする Range.getClientRects()で出来そうだ。
知恵を貸してくれた皆様ありがとう。 Houdini v2でテキスト周りの処理ができるようになればいいね いや何のことだ?
Range.getClientRects()では文字単位でピクセル値も出せるから、当たり判定は問題なく出来た。
結局の所、俺がRangeを知らなかっただけだった。最初からこれでよかった。
というか、一般的にテキストの当たり判定は出来ないので、HTMLでもそうだと思いこんでいた。
なんだかんだでHTML周りはよくできている。(他のGUIに比べて)
これについては、これまで何回か聞く人もいて、>>287とずっと言われてたろ。
まあ俺もそう思っていたのだが、実はそうじゃなかった、というわけさ。
互換表を見る限り目新しいAPIというわけではなさそうだが、
普通は使わないから知名度が低いのも致し方無しか。
ちなみにuhyohyoでは解説されてる。
https://uhyohyo.net/javascript/8_1.html
正直俺はこのサイトの書き方は嫌いなのだが、ここの内容はいい。
こいつは少なくともある程度以上の腕だというのが読んでいても分かる。
JavaScriptを解説しているサイトって、初心者が一生懸命やった記録を残しました、
みたいなところばかりで、ポイントがずれているから、ミスリードされる。
この辺を自分で判別できない初心者ならuhyohyoを全部読むのもありだと思うぞ。
(結果的には俺がそうすべきだったわけだが)
RangeはNodeをElementにキャストできる。(意味的に)
だからNodeがElementの親でメソッドが足りない、という点はほぼ全て回避できるはず。
本来の使い方か?といわれたら微妙だが。 残念だけどこれじゃ添字などに完璧に対応できてるわけじゃない
たまたま日本語だから上手く言ってるように見えるだけ カーソルの形状も文字の選択もマウスに依存したUIだから、タッチデバイスとかで使う人がいるなら相当気をつけて実装しないとまずかったりもする jplayerっていう動画とか音声を再生するプレイヤーが
再生終了後に広告載ようとしてるのですが、
class名=jp-video-playのとこにリンク付きのimgを入れたんだけど
何故か、クリックしてもa hrefの無効になってるみたい。
a hrefが無効ってvoid(0)とかしかないと思ってるんですが、
jquery.jplayer.jsを読んでもさっぱりわかりません。
jp-video-playがshow()とhide()してるだけでした。
a hrefが無効って何が原因なんでしょうか?
<div class="jp-video-play">
<a href="https://www.yahoo.co.jp/"><img src="C9GWegFV0AA_j_m.jpg" width="150px" id ="a03" class="test2" /></a>
</div> >>294
とりあえず、開発者ツールでa hrefの実際の値を確認
書き換えられてなければ、イベントでpreventDefaultされてるんじゃない? >>295
解決しました。ありがとうございました。
a hrefは書き換えはされていませんでした。
preventDefaultがされていたのが原因でした。
preventDefaultって機能の存在を知りませんでした。
jquery.jplayer.js
var handler = function(e) {
e.preventDefault();
}; >>292
どういうケースを想定しているのか知らんが、
字毎のboundingBox(=マウスでなぞったときに反転するエリアのはず)が取れるから、
全て対応できると思うぞ。
気になるuniコードがあればこちらで試してみてもいいが。 >>297
言語やフォントやモードによっては日本語のぶら下がりのような禁則処理なんかで
ボックスからはみ出す場合もある 俺の環境でちょっと試した限り動いているぞ。
ページはMDNのCSSサンプルページからで、ちょっとfiddleで試した。
https://developer.mozilla.org/ja/docs/Web/CSS/hyphens
https://jsfiddle.net/qznatw8y/10/
・chromeではそもそも3例ともハイフンが表示されない
・FFでは3例目(auto)だけ自動挿入されてる (An ex"-"tremely long English word)
なので対象は3例目のこのハイフンであり、結果は以下で、right==93はハイフンを含んでいる。
DOMRect { x: 49, y: 349.1000061035156, width: 44, height: 18, top: 349.1000061035156, right: 93, bottom: 367.1000061035156, left: 49 } _display:108:23
07:20:27.560 DOMRect { x: 49, y: 368.1000061035156, width: 50, height: 18, top: 368.1000061035156, right: 99, bottom: 386.1000061035156, left: 49 } _display:108:23
07:20:27.562 DOMRect { x: 49, y: 387.1000061035156, width: 29, height: 18, top: 387.1000061035156, right: 78, bottom: 405.1000061035156, left: 49 } _display:108:23
07:20:27.564 DOMRect { x: 49, y: 406.1000061035156, width: 51, height: 18, top: 406.1000061035156, right: 100, bottom: 424.1000061035156, left: 49 } _display:108:23
07:20:27.568 DOMRect { x: 49, y: 425.1000061035156, width: 34, height: 18, top: 425.1000061035156, right: 83, bottom: 443.1000061035156, left: 49 } Androidのテキストレンダリング周りの処理見たことがあるけど
多分アラビア語とかになるんだろうけどマージンがある場合はBOXをはみ出して描画するようになってたと思う
BOX≒選択範囲だけどBOX≒描画範囲ではないからね
続け字が連続してきて何度もフォント設定の置換が入るとBOXがズレる仕様バグが残ってるし >>302
「続け字」というのは詳しく知らんが、英語の筆記体のようなものだとすると、
それは文字間の区切りが曖昧なだけであって、最終結果のBoundingBoxをはみ出る理由にはならんだろ。
君が何故出来ないことにしたいのか分からんが、
レンダリングしている物(ブラウザ)が返してきている値なんだから普通は問題なく信用できるし、
ブラウザにバグがあるというのならそれはまた別の話だ。
仕様バグ、というのも何が言いたいのか分からんが、
BondingBoxに仕様バグも糞もない。
「表示領域を囲んだ矩形を返せ」以外の仕様なんてないし。 スレ違いとは思いますがAcrobatのJavascript APIについてこちらで質問してもいいでしょうか? input要素内部のテキストの幅を知りたいのだが、どうすればいい?
テキストの幅が取れることが分かったので、
ついでに間延びしている<input type="text'>について、
入力後にちょうどいい幅まで縮めようとしている。
前回ググッた時に見かけた覚えがあったのでだいぶ探してみたが、
どうやらcreateTextRange(IE専用)だったようだ。
chromeでやれる方法を知っている人がいれば教えて。
あるいはCSSで出来るというオチある?
見た目これはAPIを整備中、というところかな?
HTMLInputElementの継承とか見ると、オブジェクト指向しようとしている。
https://developer.mozilla.org/ja/docs/Web/API/HTMLInputElement
なら内部文字列は textNode 扱いで Range 経由で取得というのが妥当だが、
<input>自体がHTML的に中途半端(終了タグがない等)だから、整備中か?
なおjQueryUI等にこの機能を持っている物があればそれも教えてくれれば助かる。
参考に見に行く。
基本的には、フォーカスが当たったらちょっと伸びて、
フォーカスが外れたら入力文字列をちょうど表示しているところまで縮めたい。
ただし span 等に変更することはなく、inputのままで、だ。
span 等に変更すると、見た目、入力が出来ないのか?と勘違いされそうなので。
なお selection -> range -> getBoundingClientRect等で取得は試したが駄目だった。 こいつほんと馬鹿だな
そもそもinput要素がどのように表示されるか厳密に決まっているわけではない
環境に応じて調整されたUIが表示ができるようにするための専用要素なのだから
それを細かく調整しようと思うこと自体が誤り 訳:わかりませんw
分からないなら黙ってればいいのに 裏で不可視状態で同じフォント、同じサイズ、同じ文字列のspan作ってDOMの適当なところに挿入
文字列の幅を取得してすぐDOMから削除でいいのでは >>309
そんな的外れなことばかり言ってるからJavaScripterは馬鹿なままなんだよ。
お前らは何が正しいかすら理解できていない。
そしてそれすら自覚できてないから間違った情報を拡散し、余計に馬鹿が再生産されてる。
それは本当に止めた方がいい。
環境依存の部分を自動的に隠蔽したいのなら、<span>と同様、自動伸縮すればいいだけ。
手動でやれというのなら、通常のオブジェクト指向のように、統合的に扱えればいいだけ。
<input type="text"></input>で入力が内部textNodeになれば、それが出来るだろ。
Webの場合はこの辺の「統合的」な視点が全く欠けており、三流プログラマのやり方になっている。
そしてそれしか知らないから「jQueryは素晴らしいとか」とか明らかに間違ったことを言い出す。
そもそもjQueryみたいなグルーライブラリが必要なこと自体が間違っているし、
実際他環境ではそんな物は必要ないんだよ。お前らは知らないのだろうけど。
とはいえHTMLは全体的にはよくできているのも事実だが。
(そして俺は今回はscrollWidthで解決できてしまえそうだ)
余談だが、よく言われている「上級者はコードが短い」というのは、これなんだよ。
お前らはjQueryみたいな糖衣構文を使って短くすることしか出来ないからそうだと言い張っているが、
或いは宣言的に書くから短くなる、ということにして関数型()マンセーしているが、
それは自ら馬鹿であると主張しているのと同じだ。
上級者は同じ記述スタイルでも書くコードが少なくて済むんだよ。
ただこれを説明するのは難しかったのだが、Webには分かりやすい例がある事に気づいた。
要するに、上級者のコードには無駄な if が無いんだよ。
よく言われているブラウザの互換性の問題では、無駄に if 文を書く必要があるだろ。
当然、統一しておいてくれよな、と思ったことはあるだろ。余分なコードが無くて済むから。
同じなんだよ。上級者のコードでは内部的な互換性が高く、いちいち処理を分ける必要がない。
余分なコードがないから、コードが短くなる。
糖衣構文で短くなっているわけではない。
ただ、この違いを理解できない馬鹿が一文字一句の「コードの短さ」のみを主張しているだけでね。 >>311
それは回りくどすぎる。というか悪いがその方法なら俺も当然知ってる。
というかな、上記にも絡むが、
・一通り出来ない=初級者
・一通り出来る=中級者 ←お前ら
・最適なやり方を選択できる=上級者
なんだよ。
何かお題が与えられたとして、やり方が分からない>>309は初級者。
とにかく実現は出来る>>311は中級者。多分お前らはここが多い。
ただ、本当にそれが最適か考えないと、上級者にはなれない。お前らはこれを怠っているから上達しない。
今回、「本来の」順で考えるなら、
A. CSSに何かプロパティを設定したら、勝手に伸縮する (例;逆だが text-overflow: ellipsis 等)
B. 直接クエリできるメソッドを使う (例: createTextRange、ただしIE専用)
C. input自体の幅を変更して計測する
D. inputをcloneNodeして中身をコピーし、その場に貼り、不可視で計測する
E. spanに中身をコピーし、styleも全コピーし、どこかに貼り、不可視で計測する
だろ。styleのコピーがいる分EはDより面倒で「コードが増える。」
逆に言えばこれがないから「上級者のコードは短い」んだよ。糖衣構文で短いのではなくてね。
CはDよりもさらに簡単で、いったん width='0px' にすれば scrollWidth で幅が取れるというもの。
可視状態でやっていいのか?というのはあるが、現実的に問題なさそうだからこれで行く予定。
それとは別に、A, B が存在する可能性もあるから聞いたんだ。俺は仕様に詳しいわけではないから。
ただこれも、環境が整えば当然のごとく A, B が出来るようになるわけだが、
お前らはこれが出来るべきだとも理解できてないからおかしな事になってる。
糞な仕様につき合っており、それで満足してしまっていて、問題を感じていない。
ちゃんと「本来はどうあるべきなのか」を考えるようにしないと上達しない。 >>312
アホ
input要素が具体的にどのようなUIで表示されるかはHTMLの仕様外なんだよ
内部に入力テキストが表示されている必要も無いのだから
それに依存した動作をしようとすること自体がナンセンス
例えるなら右クリックメニューの内容に応じて何かをしたいと言ってるようなもの
それがどうしてもしたいならむしろ右クリックメニューを作れと言ってるんだよ
当たり前だろ この長文の人の明後日のモチベーションはどこからくるの? jQuery兄さんは黙って実装コードを提示する
いろいろ言い訳してるやつとはレベルが違う >>315
お前がそう思うのはお前の自由。
俺はそういうお前らが駆逐される日が来ることを願っている。
お前を含めて、JavaScript界隈には間違っていることを平気で垂れ流す奴が多すぎる。
それでお互いの足を引っ張り合っていて、結果的にお前らは本来あるべきレベルにも達していない。
俺は多少でもそれを是正し、結果的に次世代の成長を早め、(というより本来の成長速度に戻し)
結果的にお前らが駆逐される日が来るように誘導している。 >312 は初心者なんだろうな
> <input>自体がHTML的に中途半端(終了タグがない等)だから、整備中か?
終了タグがないのはinputは空要素だから。とかは基礎知識だから覚えとくといいよ。
世の中にはたくさん考慮する事があって、例えばinputの種類によっては削除ボタンとか、パスワードを可視化ボタンを出すブラウザもある。
他にもプレースホルダとか、入力状態のIMEをどう考えるのか?そうすると、単純にテキストを描画してるだけではないし、文字の横幅だけという訳にはいかない。
writing-mode:vertical-rlの場合はscrollWidthは期待した値にならないし、IMEやUnicodeの将来的な拡張にも備える必要がある。
とりあえず仕様とかわからんが、動けばいーやというのがお前みたいな初心者 >>321
何度も言うが、そう思うのはお前の自由。
他の人がどう取るかは、他の人の自由。
俺は初心者がお前みたいな馬鹿に騙され続けるのを止めようとしている。
それがJavaScript界の浄化に繋がると期待している。 「お前らは分かってない」が口癖のいつもの人
分かってない君でいいんじゃないの >>313
偉そうだが、中級者をけなすあなたは上級者なのか? それはお前が勝手に決めることだ。
腕がよければ相手の力量を正確に見積もれるし、
逆に、見誤るようならそれはお前が無能である証明でしかない。 分かってない君は初心者だな。基礎知識も足りないし、頭の中の情報も更新されてない。
教えてもらったことの検証も間違ってたり、用語の使い方も不自然だったり
多分、Web以外の得意分野があると思い込んでるけど、実はそちらも中級者ぐらいとみた Web Audio API の GainNode って、現在の値が valueで取得できるわけじゃないんだな。
console.log(GainNode.gain.value); とやっても常に同じ値しか出ない。
ADSR の R の部分を作ってて気づいたんだが、どうにも現在値が取得できないので困った。
仕方なく別の方法にしたけど… じゃあなんのための getter なんだこれは? Gainは回路上における音量のつまみだぞ、けして測定器ではない
色で行ったらアルファ、もしくはcssみたいなもの
そして色と同じく音の大きさっていうのは相対的なものだし、
色の輝度と明度が違うように、音にも音量以外にも音圧があるし、
もちろん周波数によっても感じ方が違う
それとAudioParamのvalueは仕様上getterではなくただの値だぞ
内部プロパティもといネイティブ世界の値とリンクさせないといけないから
実装上アクセサになってるが、別にクオンタム毎の捜査/更新でも良いし、
ProxyやArrayのlengthのような実装の方が仕様に沿っているが
簡潔さを考えた場合にアクセサにしたのだろう >>313
>D. inputをcloneNodeして中身をコピーし、その場に貼り、不可視で計測する
>E. spanに中身をコピーし、styleも全コピーし、どこかに貼り、不可視で計測する
>styleのコピーがいる分EはDより面倒で「コードが増える。」
同じものを同じ場所に貼り付けたら同じスタイルになると無邪気に思っていらっしゃる感じかなー
他分野でスーパーエンジニアでいらっしゃるあなた様の考える仕様がどれだけ素晴らしいかは推し量るのも恐れ多いですけれども
Webのフロントエンドについてはブラウザの実装が全てなので、仕様に文句つけてる暇はなく、
糞仕様の糞APIに付き合うかラップしたフレームワークを作るか使うかしかないし、
APIに文句ばっかりつけてるうちは永遠にフロントエンド初心者だよ >>>333
> 糞仕様の糞APIに付き合うかラップしたフレームワークを作るか使うかしかないし、
その通りだ。だから俺は一番マシな解法でやる。それは既に示した。
それよりもマシな解を示せるのなら偉ぶって構わないとは思うが、
そうではないのにお前らがただ上級者ぶるのは俺には理解不能だ。
それとは別に、これを認めるのなら、
当然これがお前らの成長を阻害している要因の一つだとは認識できるだろ。
仕様のグダグダな所を暗記するのがプログラミングの勉強ではない。
お前らがブラウザ互換性の問題の勉強に費やした時間もまた、無に帰すときが必ず来る。
PHPとかも相当酷いから、
逆に暗記重視の文系プログラマにとっては安住の地になっている感があるが、
そうではない奴はPHPを目の敵にしてるだろ。
仕様のグダグダな部分はだんだんと修正されていく。
APIが不備な部分はだんだんと整備されていく。
ブラウザの互換性もだんだんと上がっていく。
お前らが腕前をこれらに依拠しているのなら、お前らの存在価値は自然と目減りしていく。
それを自覚しろと言っているのだよ。
とはいえ、君らがどうするかは君らの自由だが、
間違ったことを垂れ流してミスリードし、次世代の足を引っ張る権利は君らにはないんだよ。
だからそれはマジで止めろと言っている。 jQuery兄さんにこてんぱんにされてから
長文書くようになったなぁw >>328
いや、他者評価ではなく、自己評価を聞いてるんだが
「お前がそう思うならお前の中ではそうなんだろう」なんて切り返しは要らん
仕様が分かっていないと自認する割には、他人を初級者〜上級者まで評価する程度の実力を持っていると思っている節があるようだし、おなた自身の認識に矛盾がある 「ならば……今すぐ怠惰なエンドユーザーどもすべてに環境をアップデートさせてみろ!」って感じ >>334
変な要求を場当たり的に解決できたのを自慢げに語られてもねぇ
DOMを触れる前提の解決策はすでにマシとは言いがたい
ReactやVunみたいに分離や仮想DOMが普及してきてる >>312
><input type="text"></input>で入力が内部textNodeになれば、それが出来るだろ。
input要素はtextだけじゃなくて、dateとかrangeとかいろいろある
これらはHTMLに直接記述したり、JSから取り扱うときにはDOMStringにシリアライズされるけれども、
その意味するものがテキストとは限らないし、UAでの表示・入力方式もカレンダーなど、テキスト以外の形態を取るかもしれない。
つまり、input要素のvalueはDOMStringではあってもTextであるとは限らない。
type="text"だけ例外的にvalueではなくてcontentのtextNodeで扱うのは統合性の観点から問題があるし、
JSで扱うときにDOMStringになるからといって、テキストでないものをUAでの取り扱いも無視してtextNodeとしてcontentに入れてしまうのは
HTMLやそのDOMの基本構造から外れてしまい、これも統合性の観点から大問題。
>Webの場合はこの辺の「統合的」な視点が全く欠けており
統合的な観点が欠けているのはどなたでしょうかね。 >>338
> ReactやVunみたいに分離や仮想DOMが普及してきてる
jQueryの73.4%に比べれば1%以下では普及してるとは言えないです
https://w3techs.com/technologies/overview/javascript_library/all そんなことはない
例えば現代の日本人の0.5%に使われてる着物というものがあったら
大ヒット大普及と言えるだろう >>340
無意味な使用率とかを見ちゃうようではなぁ
自分で、
>お前らが腕前をこれらに依拠しているのなら、お前らの存在価値は自然と目減りしていく。
とか言っちゃうくせに新しい技術への考慮をしないとは
事実jQuery使ったサイトは多いけど、すでにあるものの修正か、使いたいライブラリがあるか、シンタックスシュガーとして楽するみたいな使い方ばっかりだな
標準APIとCSS,JavaScriptの機能拡充で使う必要性はかなり薄れた 用途も使われてきた期間も違うから比べるもんでもないけどね >>341
> 例えば現代の日本人の0.5%に使われてる着物というものがあったら
それは「着物」の場合ですね。別の話です。 >>342
> 事実jQuery使ったサイトは多いけど、すでにあるものの修正か、使いたいライブラリがあるか、シンタックスシュガーとして楽するみたいな使い方ばっかりだな
因果関係が逆になってますね。
楽するみたいな使い方ぐらいしかする必要がないからjQueryを使うんですよ
ほとんどはReactとかAngular使ってデスクトップアプリみたいなものを
作りたいなんて思ってないんです。
企業サイトを楽に作りたいだけです。
需要があって供給が決まります。 なぜ普及率云々の話になってるんだ?
普及率なんて使うときの目安にもならんのに 普及率を見て何かを決めるんじゃなくて、
何かを見て決めて実行した結果が、普及率として形になるんだよ。
結果を言ってるだけ。目安にしろと言ってない。 >>339
> type="text"だけ例外的にvalueではなくてcontentのtextNodeで扱うのは統合性の観点から問題があるし、
いや、それはtextNodeではないぞ
彼も同じ勘違いをしていたようだが、彼には初心者特有の「事実と想像(思い込み)を区別できてない」ものを感じた >>339
> type="text"だけ例外的にvalueではなくてcontentのtextNodeで扱うのは統合性の観点から問題があるし、
これは俺の書き方が悪かったが、
俺は<input>全体が<div><span>と同格に扱える仕様であるべきだと思っている。
(今回はtpye='"text"だったから分かりやすいようにそれ限定で書いていただけ)
同様に<textarea>もだ。
そうすれば、<textarea><input>の場合だけ value にしている if 文が抜ける。
本来はこれが正しい仕様だ。valueは生の値、textContentはDOMStringだ。
というか方向は確実にこっちで、
HTMLInputElementはNodeを継承しているのだからtextContentをオーバーライドしてないことがおかしい。
これについては互換性の問題は深刻ではないので、追加(というより修正)されてもおかしくない。
お前らはここら辺の、「本来あるべき形」ってのが見えてない。
それはプログラミングで統合的に扱おうとしてないからだ。
ここら辺の、「仕様」の例外はどうやっても避けられないから、処理を分けるしかない。
それはわざわざ汚いコードを書かされる羽目になり、
「処理を分けずに書くことが出来る上級者」にとってはものすごいストレスになる。
一方、「いちいち処理を分けて書くしかできない初心者」にとっては何もなく、
ここら辺がPHPが上級者に『だけ』強烈に嫌われる理由でもある。
PHPは言語仕様自体が酷すぎて、上級者でも本当に酷いコードを書かされる羽目になる。
結果、上級者は去り、PHPは初心者の楽園となり、それはそれで楽しいのだろうが、
上級者のコード(美しいコード)がその世界に存在しないってのは、PHPerが馬鹿にとどまる理由の一つでもある。
JavaScriptは言われるほど酷くはないが、同様に、
仕様が汚いから美しいコードが存在しにくいというのはあって、
これもお前らの上達を阻害している要因ではある。
JavaScriptのスレは他言語と比べて活発で、今日でも休日なのにお前らは投稿しまくりだ。
お前らが努力をしてないってわけではないのだろうさ。
ただ、上記のように、環境が悪いから上達しにくい、ってのはあるんだよ。
だから、これらを正しく認識した上で、空回りは止めろと、俺は言ってるんだよ。 >>348
だから、それはどうでもいいだろ
自己満足にしかならん > これは俺の書き方が悪かったが、
> 俺は<input>全体が<div><span>と同格に扱える仕様であるべきだと思っている。
知らんがな。お前が思ってたからってだから何だよ?
理由の一つぐらいいえ。
俺なら言えるぞ、inputはdivやspanと同格に扱えるものではない。
なぜならdivやspanは出力するためのものだ。
intputは逆に入力するためのものだ。
見やすさと入力のしやすさは違う。出力は製作者側がコントロールできるが
入力は何を入力するかは決められない。どうやって入力するかも決められない
本質的にまったく違うものなんだから、お前の主張は根本から間違いだってわかる >>351
何の自己満足?
俺は単に事実を提示しただけ >>350
おまえは ID:k7L1I/bs と同一人物なのか
自作自演してまで味方を増やそうとするとは >>352
お前、、、レスする前にまずは全文読めよ。
ただまあ、
> 俺なら言えるぞ、inputはdivやspanと同格に扱えるものではない。
> なぜならdivやspanは出力するためのものだ。
> intputは逆に入力するためのものだ。
これは「オブジェクト指向では」間違いだということになっている。
とはいえ見た限り、DOMのオブジェクト指向は後付で、ややちぐはぐなのも事実だが。
君が非オブジェクト指向派で、
> 本質的にまったく違う
と思うのならそれはそれでいいが、
おそらくDOMについてはオブジェクト指向で取り扱う方が正しい。
おそらく君はそれ以前で、「オブジェクト指向」を理解できていないのだと思う。
これについては勉強した方がいい。
ただまあ、オブジェクト指向自体の勉強はやややりにくいのも事実だが…。 >>353
自分が使用しているライブラリの普及率の高さを見てニヤニヤする自己満足
事実は事実だが、掲示する意味がないといってるんだよ > おそらくDOMについてはオブジェクト指向で取り扱う方が正しい。
知ってる。ってか常識
DOM とは Document Object Model の略
なんでお前そんなレベルの話してんの? >>355
> なぜならdivやspanは出力するためのものだ。
> intputは逆に入力するためのものだ。
> これは「オブジェクト指向では」間違いだということになっている。
なってない。というか、なってるという証拠示せよ >>350
>本来はこれが正しい仕様だ。valueは生の値、textContentはDOMStringだ。
それは思いっきり間違った仕様だし、典型的なアンチパターンです。
valueから一意に計算されるものをvalueと別に保持するべきではないし、
「とある属性の値をDOMStringに変換したもの」は要素の「内容(Content)」ではないので、
これをtextContentで返すべきでもありません。
textContentは要素の"内容"であるべきで、inputだけ例外として内容でないものをContentとしては
HTMLというもの全体の統合性が失われる。
目先の処理の統合性のために、データ構造そのものの統合性を失わせるのでは本末転倒。
HTMLにおいて"内容"(Content)というのは特別な意味を持つ専門用語なので、
そういった基本を学んでからDOM APIに文句をつけることをおすすめします。
>HTMLInputElementはNodeを継承しているのだからtextContentをオーバーライドしてないことがおかしい。
オーバーライドしてますよ。空要素(内容を持たない要素)なので常に空文字列が返ります。
【HTMLはJavaScriptのためにあるものではないので】
JavaScriptから扱うときの処理を数行減らすためだけに、データ構造の整合性を失わせることはできません。 >>360
君がそう思うのならそれはそれでいいのだが、
俺の考えだけ言っておくと、以下になる。
> inputだけ例外として内容でないものをContentとしては
inputの表示内容を textNode にしてchildNodes[0]にすれば、
Range で統合的に取り扱えるようになる。
そのときにその表示内容が textContent で取得/変更出来るのは自然だ。
だから、「inputは空要素」というのがそもそもの間違いで、
XHTMLではとりあえず終了タグ付けようとしただろ。(ポシャったが)
あれは方向はあってるんだよ。
> オーバーライドしてますよ。空要素(内容を持たない要素)なので常に空文字列が返ります
これが後付なんだよ。今の仕様を無理矢理OOPに乗せて、
オーバーライドしたことにして辻褄を合わせている。今の君の主張のようにね。
同様なのはNodeもそうだが、例えば、
https://developer.mozilla.org/ja/docs/Web/API/HTMLInputElement
で見ると、継承階層は
EventTarget <- Node <- Element <- HTMLElement <- HTMLInputElement
であり、実は addEventListenerはEventTargetのメソッドだ。
だから理屈的には textNode に対しても addEventLister できる事になり、
確かに出来るのだが、イベントには反応しない。
これも同様に、Element階層でイベントに反応するaddEventListerがオーバーライドされており、
EventTargetのaddEventListerはただの空関数です、ということは出来る。
しかし明らかに辻褄合わせだろ。間違ったOOPの使い方であってさ。
こんなのを見てOOPを学べるはずもない。教材が悪すぎる。
そりゃ ID:C4tJt4pN が理解できてないのも一理あるだろうよ。 > inputの表示内容を textNode にしてchildNodes[0]にすれば、
> Range で統合的に取り扱えるようになる。
それは悪いやり方ですね。
textNode ならtextNodeのメソッドを持っていなければいけないので、
つまり、inputの表示内容の、nextSiblingやparentElementってなんでしょうって
話になりますね。 >>362
> こんなのを見てOOPを学べるはずもない。教材が悪すぎる。
お前の頭が悪すぎるだけだよw
1. a は b である!(お前の間違った考え)
2. しかしにbはaと考えると問題が有る(間違った前提だからそうなる)
3. よって、aはbであるDOMはクソ(そもそもaがbであると言い出したのはお前)
まあ、こういう論理してますからねw >>363
nextSibling は null になる。childNodes.length===1だから。
parentElement は当然<input>だ。
特に問題ないし、自然だろ。 >>362
>inputの表示内容を textNode にしてchildNodes[0]にすれば、
>Range で統合的に取り扱えるようになる。
繰り返しますが、HTMLはJavaScriptのための(ry
それからこれも繰り返しますが、【input要素の表示内容はテキストとは限らないので】、textNodeにはできません。
>だから、「inputは空要素」というのがそもそもの間違いで、
<input type="color" value="#808040">を
<input type="color">#808040</input>と書けというのは明らかに不条理ですよ
2018-04-07というのは便宜上このようにシリアライズしているだけであって、"#808040"というテキストを表しているわけではないし、
UAで表示されるのもテキストとは限りません。
実際、Windows+ChromeではHTMLに直書きしたり、JavaScriptで読み取る際にこそシリアライズされた文字列を使いますが、
ユーザーにはただ色そのものが表示されるだけですし、入力時にもこのシリアライズ文字列は使われなません。
>そのときにその表示内容が textContent で取得/変更出来るのは自然だ。
input要素がテキストを表示するとは限らないので、textContentで表示内容は取れません。
表示内容は画像かもしれないし、カレンダーかもしれないし、アナログ時計かもしれないし、ただの色かもしれない。 >>366
>2018-04-07というのは便宜上このようにシリアライズしているだけであって、"#808040"というテキストを表しているわけではないし
訂正
#808040というのは便宜上このようにシリアライズしているだけであって、"#808040"というテキストを表しているわけではないし
dateからもっとわかりやすいcolorに変えてからの修正ミス TextNodeがイベントに反応しないっていうのも間違いで
現在は(おそらく)TextNodeが反応するイベントがないってだけで
過去にはありましたからね
https://stackoverflow.com/questions/4789342/textnode-addeventlistener
var textNode = document.getElementById("div").firstChild;
textNode.addEventListener("DOMCharacterDataModified", function(evt) {
alert("Text changed from '" + evt.prevValue + "' to '" + evt.newValue + "'");
}, false); >>365
> parentElement は当然<input>だ。
> 特に問題ないし、自然だろ。
あっはっは、馬鹿も休み休み言え
<span><input value=1>a</span>
<span><custom value=1>a</span> HTMLの属性を要素としてみなすと、
HTMLとしての整合性が取れなくなるからね。 XPathとかで全てのテキストノードを消すと
inputの中身まで消えちゃうwww >>366,367
君のこだわりがよく分からないが、さらにつき合うと、
> 表示内容は画像かもしれないし、カレンダーかもしれないし、アナログ時計かもしれないし、
それならそれが入ればいいだけだろ。textならtextNodeであって。
具体的には、
<input><img></img></input>
<input><calender></calender></input>
<input><analogClock></analogClock></input>
で特段何か問題が発生するとは思えないが。 xpathでテキストノードを選択すると
<span value=0><input value=1 data-value=2>a</span>
valueの1とaの両方にマッチするっていうのは
非直感的なクソ仕様ですよ
「input要素に限りvalueはテキストノードとして扱われます」
なんて書いてあったら、そいつは本当に人間なのか?って思うw >>366,367
というかな、多分君は「抽象思考」が出来ていない。
タグってのは単なる「参照」なんだよ。(プログラミング用語での参照、日本語でいう参照ポイント)
今問題なのは、<input>の中身に参照がないから捕まえられないことであって、
それは単にタグ付ければ回避できる、って話であって、
逆に、単に参照を付けただけだから、それで何か新しい問題が発生するって事もないんだよ。
HTMLが先進的だったのは、文章にタグを付けて、参照できることにしたことなんだよ。
それ以前は文章→ビットマップに変換だから、当たり判定なんて基本的に出来ないし。
だって参照がないから。 >>372
<input type="date">でカレンダーで日付を表示するのか、
2018-04-07みたいな文字列の形式で日付を表示するのかは
【ユーザーエージェント依存】なので、そんなことはできませんし、できる必要もありませんし、
マークアップ側が指定すべきものでもありません。
HTMLとして必要な情報は「これは日付の入力フォームである」という情報だけであり、
リッチクライアントならカレンダーを表示するだろうし、
テキストブラウザなら「2018年4月7日」などとテキストで表示され、数字を編集することになるだろうし、
音声ブラウザなら音声的に処理するでしょう。
あなたは全てのクライアントがいずれ完全互換になるとか思っているのかもしれませんが、
人間自体が完全互換ではないので、そうなる未来は我々の生きている間にはおそらく来ませんよ >>375
だからそれが、「参照ポイントを付加した」だけだ、って言ったんだよ。
今<input>で出来ていることを、
<input><中身></中身></input>に変更したことによって生じる違いは、
・中身に参照を追加した
だけなんだよ。今できていることが出来なくなることはない。
君はだいぶ論点がずれている。
君は表示のことしか考えてないが、そもそも参照を付加しても表示は何も変わらない。
だから君の375での指摘は全く意味をなしてないんだ。分かるか? 横からすまんが、踊る分かってない君に対する皆さんの誠実な突っ込みには大変勉強させていただいております。 > 今<input>で出来ていることを、
> <input><中身></中身></input>に変更したことによって生じる違いは、
> ・中身に参照を追加した
> だけなんだよ。今できていることが出来なくなることはない。
DOMツリーを全操作して、子要素がないものを全部取得することができなくなる value要素だけを特別扱いするということは、
処理をシンプルにできなくなる >>375
OOPで言うと、参照を付加する=今privateな物をpublicにしただけなんだよ。
だから何も変わらない。これで分かるか? > OOPで言うと、参照を付加する=今privateな物をpublicにしただけなんだよ。
> だから何も変わらない。これで分かるか?
既存のpublicなメソッドに名前を変更すると
互換性が壊れる。 新たにメソッドを増やすときは、今までとは違った名前にすることは
互換性を保つ上であたりまえのこと。 element.value で参照できるものに対して
element.childNodes[0].nodeValue でも参照できますとか
混乱のもとでしかない
オブジェクトの属性が、
オブジェクトが所有するオブジェクトの属性 と同じとか
オブジェクト指向が分かってないとしか思えない >>376
いやだから、<input><calender></calender></input>なんてやって
「この<input type="date">の中身はカレンダーです!」とか宣言できないし、しちゃいけないし、できちゃいけないんですよ
それを決めるのは開発者じゃなくてユーザーです
ユーザーが自分の環境で一番使いやすい入力・表示形式を選びます
あるinput要素にtextContentとして扱える内容があるのかどうか、開発側にはわからない、
ユーザーエージェント依存の部分なので、<input>は空要素でなければなりません。
>今privateな物をpublicにしただけなんだよ。
だからそこpublicにしちゃダメなんですよ、UAによって何してくるか違うところなんで
開発者はユーザーエージェントがなんであれ、統合的に処理できるようにしなきゃいけないので
あるかどうかもわからないtextContentじゃなくて、どういう形式のフォームが使われるにせよ
確実に存在する"値"のシリアライズ文字列だけをvalueプロパティから取り出して扱うわけです。 >>383
異なるノードから同参照になる例としては、要素ノードと属性ノードがある
後はHTML Standardで反映型属性(正確な用語は忘れた)があって、valueもそれだった記憶がある >>385
> 後はHTML Standardで反映型属性(正確な用語は忘れた)があって
反映型IDL属性だった
https://teratail.com/questions/86442
いずれにしても重要なのは仕様を正しく理解して使いこなす事であって、仕様が分からない状態でコードを作り上げる事じゃない
彼は分からない道具を組み合わせて、分からないままでコードを書き上げようとしている
createTextRangeを知っていて、代替APIを発見できない検索スキルの低さも問題だが(初心者でも数秒で発見できる)
https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/setSelectionRange >>332
音の大きさとかじゃなくて、単にそのつまみ自体の値が欲しいのよね。
setValueAtTime でオートメーションを GainNode に大量に入れてやるわけだけど、
リリース(音の停止)の時はそれを現在位置でキャンセルして、現在の値からフェードアウトさせる必要がある。
その現在の値(つまり、最後に設定した値)が GainNode.gain.value で取得できないから、何やねんこれはとなってるわけ。 >>385
> 後はHTML Standardで反映型属性(正確な用語は忘れた)があって、valueもそれだった記憶がある
value属性は反映されてなかったので、撤回する
すまん >>384
> あるかどうかもわからないtextContentじゃなくて、どういう形式のフォームが使われるにせよ
> 確実に存在する"値"のシリアライズ文字列だけをvalueプロパティから取り出して扱うわけです。
そもそも textContent は階層が潰れた文字列だし、
そこに textNode ならそれそのまま、
<calender>ならそれに対して textContent を発行した内容を返せばいいだけだろ。
それがシリアライズ文字列を返すのならそれが返るし、そうじゃない仕様なら空でもいいし。
いずれにしても普通の<div>等のtextContentと矛盾無く同じ並びになると思うが。
あれも多分 childNodes.map(function(v){return v.textContent;}).join(' ') だろ。
俺には何故君が出来ないと思えるのかさっぱり分からない。
ここで与太議論しても何も変わらないから終わりでもいいのだけど、君がこだわる理由も分からない。
当たり前だが、DOMの仕様がクソなのは君のせいじゃない。
あれは見た限り元々OOPじゃなかったのを無理にOOPに乗せようとしてるからおかしな事になってる。
でも多分、方向性としては正しいし、次第に綺麗に整備されていくだろうよ。 > 当たり前だが、DOMの仕様がクソなのは君のせいじゃない。
> あれは見た限り元々OOPじゃなかったのを
ここだけ読んでもほんと頭が悪いなw
DOMはDocument Object Modelの略
すなわち「モデル」だ
OOPはobject-oriented programmingの略
すなわち「プログラミング」だ
モデルはでプログラミングじぇねぇ 確かに、DOMはIDLの集合でしかないな
OOPはプログラミングなので、対象が違う HTMLはぁ〜
Javascripとんのためにあるんやないんやでぇ〜♪ >>389
>ここで与太議論しても何も変わらないから
そうですね、あなたがここで何を言おうとあなたの言うような仕様にはならないでしょう
「色データを文字列で表現したもの」と
「色を表すテキスト」は別物ですし、textContentやtextNodeは「色を表すテキスト」にしかなりません。
HTMLの基本構造としてそういうものなので。
<input type="color">が扱うことがわかっているのは「色データそのもの」や「色データを文字列で表現したもの」で、
「色を表すテキスト」を扱うかどうかはブラウザ依存で、開発者にはわかりません。
あなたの言うような仕様だとしたら、ブラウザは
カラーコードをユーザーにそのまま表示している時: "#00a3af"
色そのものしか扱ってない時: ""(空文字列)
ひどい時: "浅葱色"
をtextContentとして返してくるでしょうから、何が返ってくるのかわからないtextContentなんて誰も使わないでしょう。 >>393
> あなたの言うような仕様だとしたら、(中略)
> をtextContentとして返してくるでしょうから、何が返ってくるのかわからないtextContentなんて誰も使わないでしょう。
それでいいと思うが。両方とも。つまり、
・textそのものでない場合はそれなりの文字列で返す仕様でいい。
まあ普通色ならARGBかWebColorの文字列になると思うが、それは仕様で決めればいい。
・誰も使わなくてもいい。
君は何がそんなに気に障っているのだ?それで誰も困らないだろ?
今できていることが出来なくなるわけでもないし。 > 君は何がそんなに気に障っているのだ?それで誰も困らないだろ?
> 今できていることが出来なくなるわけでもないし。
できなくなるんだから問題だって言ってるだろw
人の話聞けよ >>393
ちょっと言い方が曖昧だった。
多分、色について textContent で内容を取るのなら、
それはそのまま style:color に対して指定できる文字列が仕様としては良いだろう。
だから #xxxxxx とか red とか、まあそれはご存じの通り、で。 >>394
>・textそのものでない場合はそれなりの文字列で返す仕様でいい。
> まあ普通色ならARGBかWebColorの文字列になると思うが、それは仕様で決めればいい。
<input type="color"> が、カラーコードのテキストノードを子要素として持つというのは
img要素が画像データを文字列にシリアライズしたものをテキストノードで子要素に持ったり
audio要素が音声データを文字列にシリアライズしたのものをテキストノードで子要素に持つようなものです。
明らかにHTMLの構造として異常ですから、確実に却下されるでしょう。 >>397
> img要素が画像データを文字列にシリアライズしたものをテキストノードで子要素に持ったり
> audio要素が音声データを文字列にシリアライズしたのものをテキストノードで子要素に持つようなものです。
そこはgetterでしょうに。 またSPAの時みたいに思いこみで話してんの?
というか毎回なの?こいつ。 >>398
textContent は子孫要素のテキストノードをまとめたものを返すものですから、
<input type="color">がtextContentでカラーコードを返すとすれば、
子要素としてカラーコードのテキストを持つということであり、
これはimg要素が画像データを文字列にシリアライズしたものをテキストノードで子要素として直接持っていることに相当します。
これもさっき言いましたが、HTMLとそのDOMにおける"Content"の意味、ちゃんと勉強してくださいね。 あぁ、SPAやろうだったか。
動くコードも書かずにぐちぐちいうだけ
jQuery兄さんの足元にも及ばないな なんていうか意図的に「文字列」と「テキスト」を混同しているみたいだな
textContentで子孫ノードにないものを返すのはありえないし、
参照するデータのシリアライズ文字列をいちいちテキストノードで保持するというのもこれまたありえない >>402
だからそこはgetterだろと(2度目) >>403
お前の提案したAPIだとテキストノードで保持することになるって意味な >>387
テストしてみたが当たり前に取得できるぞ >>403
他の人も同じこと思ってるけど、
的はずれな用語を持ち出してきても意味不明なんだよ。
お前の言うgetterがなんなのかわけわからんし、
おそらくお前自身がわかってない。
わかってるというのならgetterとやらでどうなるのか説明してみ 根本的に基礎知識不足がひどいな
>XHTMLではとりあえず終了タグ付けようとしただろ。
全然違う。HTMLとXHTMLの概念は変わらず、空要素も両者ある。
XHTMLは<br />のように「空要素のスラッシュを義務化」しようとしただけ。
>input
オブジェクトを定義するXAMLとかでは<TextBox>value</TextBox>みたいにできるから、できても変ではない。
(ただし、Xamlはあらゆる属性を子要素として記述できるというだけ)
しかし、HTMLは文章の構造を定義するmので、今更変更するメリットはない
>互換性の問題は深刻ではないので
これは間違い。かなり規模のでかい破壊的変更になる。
・親も含めてtextContentやinnerHTMLの結果が変わる
・過去のHTMLの解釈が大幅に変更され、パーサが複雑に
・セキュリティ上の多数の懸念
概念的にもinputは「フォームの部品」であり、それ以上分解できなくても不自然ではない
>Range で統合的に取り扱えるようになる
それは無理。それこそ表示はブラウザに依存するから。IMEの未確定文字などの複雑な概念は単純には処理できない
>getter
意味がよくわからん Rangeで同じように扱えるようにするだけのために
HTMLを壊そうとしてるんだよなw 分かってない君は語彙が変なのが余計にわかりづらさを助長してるな
「ポップアップ」「参照」「参照ポイント」「getter」あたりは世間と認識がだいぶずれてる >>407
> 空要素についても同様に終了タグを付与するか、開始タグの末尾を「/>」としなければならない。
> 終了タグを付与する <br></br> という表記の場合は、タグの間に空白類文字すら含めてはいけない。
> また、後方互換性のために <br></br> ではなく、<br /> と表記することが推奨されている
> https://ja.wikipedia.org/wiki/Extensible_HyperText_Markup_Language
つまり終了タグ無し要素は無しになってるだろ。
> 「空要素のスラッシュを義務化」
この解釈は矮小化してる。上記参照。
> (ただし、Xamlはあらゆる属性を子要素として記述できるというだけ)
俺は知らんがXAMLの連中はそれの方が一般的でいいと解釈したんだろ。わからんでもないだろ。
> しかし、HTMLは文章の構造を定義するmので、今更変更するメリットはない
そう思うのは勝手だが、XHTMLとかも要するにAltHTMLだろ。
HTMLもJavaScriptも色々糞な所はあるんだよ。(HTMLそのものというよりはDOMだが)
ただ、両方とも我慢できないほどではないから現状があるわけで。
> パーサが複雑に
これはない。単純になる。
> 概念的にもinputは「フォームの部品」であり、それ以上分解できなくても不自然ではない
<input type="text">についてもそう思うか?
> IMEの未確定文字などの複雑な概念は単純には処理できない
そんなに複雑だと思うか?
俺が試した限り、未確定文字もインクリメンタルサーチに当たるから、単純に、
・未確定文字も「入力されている」扱い
・確定時に該当部分を消して書き直しているだけ
っぽいぞ。少なくともvalueと見た目からはそう見える。
まあこれは余談だが。
> 意味がよくわからん
お前もかよ > これはない。単純になる。
それはない。複雑になる。 属性を子要素にするとか何も分かってない
まず属性は複数ある。
<input value="a" type="text">
この場合、typeも子要素になる。
valueとtypeの両方が子要素になってしまう。 >>410
>つまり終了タグ無し要素は無しになってるだろ。
終了タグとか関係なしに、内容を持たない「空要素」という概念があって、
は? どこをどう読んだらそういう解釈になるのか。文盲?
空要素という概念が先にあって、表記形式として<br></br>か<br />のどっちか使えってだけで
XHTMLでは空要素にとって終了タグがあるかどうかなんて ど う で も い い ってことなんだけど
終了タグも<br />も空要素の表現手法であって、空要素が主、タグは従
タグにやたらこだわってるあたり、本当にWebの基礎の基礎がわかってないんじゃない?
タグなんて要素を表現する書式でしかないんだから、XHTMLでスラッシュが義務化されようが
終了タグが容認されようが、「空要素」という概念自体には何の関係もないよ
>そんなに複雑だと思うか?
>俺が試した限り、未確定文字もインクリメンタルサーチに当たるから、単純に、
だからー、それユーザーの環境によって違うのね
ユーザーによってデバイスもOSもブラウザも入力メソッドも何もかもバラバラ
お前の環境ではそうだった、っていうのはお前の環境ではそうっていう以上のものではないので、この議論に無意味
お前Webでユーザーの環境を開発者が決定できると勘違いしてるんじゃね? >>413
行がちょっとずれたけど、2行目は5行目の前あたりに入れて読んでねー >>413
了解。お前は文盲と理解した。お前とのレスもこれまで。 >>415
>>空要素についても同様に終了タグを付与するか、開始タグの末尾を「/>」としなければならない。
>終了タグ無し要素は無しになってるだろ。
文盲はあなたですよねー、
>終了タグを付与するか、開始タグの末尾を「/>」としなければならない。
いいですか。"終了タグを付与する」" OR "開始タグの末尾を「/>」とする"のどっちかをやれって言ってるわけだよ
"開始タグの末尾を「/>」とすれば、終了タグはなくてもいい"って言ってんの
終了タグ無し要素は無しって何? 空要素は終了タグつけるか、終了タグなしなら /> で開始タグを閉じてね
どっちかといえば終了タグなしの /> が推奨だヨ
っていうテキストを読んで「終了タグ無し要素は無しになってる」とか本気で文盲としか思えん しかもなーんで引用するのがw3cじゃなくてWikipediaなんですかねえ
もしかして上級者気取りで仕様書程度の英語も読めない感じ?
https://www.w3.org/TR/xhtml1/#h-4.6
以下引用、括弧内は引用者訳
4.3. For non-empty elements, end tags are required
(空でない要素は終了タグが必須です)
4.6. Empty Elements
Empty elements must either have an end tag or the start tag must end with />.
(空要素は終了タグを持つか、開始タグが /> で終了するか、どちらか一方が必要です。) >>407
つかXAMLってWPFかよ。以下読んだ。
https://docs.microsoft.com/ja-jp/dotnet/framework/wpf/advanced/xaml-overview-wpf
見た目、以下か。
・終了タグ必須
・textNodeなし、絶対にタグで囲め
・case sensitive
まあ確かにHTMLを参考に作ったんだからこうなるわな。仕様としては妥当だ。
とはいえ冗長だし、人間が書く用ではないが。
.(ドット)で明示的にプロパティと分かるようになっているね。
確かにこれの方がいい。
ただ個人的には、XAMLとか中途半端なことをせず、
WPFはHTMLを全面採用した方がいいとは思ったが。 >>420
え? お前マジでそれいってんの?
知識なさすぎるだろw 1つ目
> つかXAMLってWPFかよ。
XAMLはXAML、WPFとともに作られたがWPFではない
実際にXamarinでも使われている >>405
ほんと?情報ありがとう。
じゃあ Firefox の実装が変なんかな。
どんなに
GainNode.gain.value = v;
なり
GainNode.gain.setValueAtTime(v, t);
なりで指定しても GainNode.gain.value が 0.1400049 みたいな固定の値しか返してくれないんだ。
初期値(=1)でもないし、なんじゃその値は。
自分のためにつくってるプログラムだから Firefox でないと意味ないし…。まあ別の方法でリリース制御はできたからいいけど。 2つ目
> 見た目、以下か。
名前からXAMLはXMLの一種だと気づけ
そもそもXMLにはHTMLという決まったタグはなく
タグを仕様として作ってから使うもの、その仕様の一つがXAML 3つ目
> ・終了タグ必須
XMLなんだから当たり前 4つ目
> ・textNodeなし、絶対にタグで囲め
XMLなんだからtextNodeある 4つ目
> ・case sensitive
XMLなんだから当たり前 6つ目
> まあ確かにHTMLを参考に作ったんだからこうなるわな。仕様としては妥当だ。
XMLをベースに作った。HTMLは関係ない 7つ目
> とはいえ冗長だし、人間が書く用ではないが。
人間でも読み書きしやすい
> http://ytabuchi.hatenablog.com/entry/2017/01/04/160000
> 新年一発目は XAML Previewer についてです。Xamarin.Forms の XAML は手書きする必要があります。 8つ目
> ただ個人的には、XAMLとか中途半端なことをせず、
> WPFはHTMLを全面採用した方がいいとは思ったが。
HTMLはタグセットが決まってるのでそんな事はできない ほんとひどいわw
1レスでいくつ突っ込めば良いんだか > ID:C4tJt4pN
いろいろ、お疲れ様(大変だな…) そもそも属性を要素とみなしてしまえばRangeで扱えるようになるとか言ってるが
今まで属性はRangeに含まれていなかったのに、勝手に含まれるようになれば
互換性が壊れるって分からんのかね? この人HTMLを<tag attribute="属性値">内容</tag>みたいな書式のことだと思ってるのでは >つまり終了タグ無し要素は無しになってるだろ。
空要素の記述方法が、XMLでは<hoge></hoge>か<hoge />とする。HTML5では<hoge>とすることになっただけ
パース後の内部表現は同じ
>XHTMLとかも要するにAltHTMLだろ
すでにhtml5が発行されて、議論は終結した。
>パーサ
例えば、こういうコードがすでに存在するとする。
<input value="aaa">bbb</input>
現在はXMLとして書くと「<input value="aaa" />bbb」となるが仕様変更すると「<input value="aaa">bbb</input>」となり、解釈が変わってしまう
>未確定文字
とりあえず、WindowsのIME関連のAPIを調べてみればわかるけど、かなり複雑な部類
スマホの横持ちとかでは、全画面が入力欄になったり、音声入力があったり、将来的な変化も見込まれる JavaScriptやDOMに疎いのはまだしも、XMLの知識がおかしいのは流石に現代プログラマーとしてヤバさを感じる >>435
> 例えば、こういうコードがすでに存在するとする。
> <input value="aaa">bbb</input>
> 現在はXMLとして書くと「<input value="aaa" />bbb」となるが
これは本当なのか?この記述をしているところのソースくれ。
なお俺はこれは間違っていると思うぞ。
俺は /> で閉じて良いのは中身がないときだけであり、
中身がある場合は常に閉じタグ</input>を使わなければならない、と理解している。
勿論、ご指摘のように、俺はXML専門家ではないが。
> とりあえず、WindowsのIME関連のAPIを調べてみればわかるけど、かなり複雑な部類
> スマホの横持ちとかでは、全画面が入力欄になったり、音声入力があったり、将来的な変化も見込まれる
それで?
未確定文字は結局の所、
・未確定でも値に反映して確定後に書き直す…俺の環境
・確定するまでは値に反映しない
のどちらかしか無いと思うが。 >>435
> 現在はXMLとして書くと「<input value="aaa" />bbb」となるが
HTML parserで動かしてないか?
XML parserならSynraxErrorになりそうだが、Content-Typeは正しく指定されてるのかね… 後方互換性の話かと
現在のHTML5では、<input>要素に終了タグを書いても無視されるので
<p>xxx<input value="aaa">bbb</input></p>
のパース後のDOMは
p
├xxx : テキストノード
├input value="aaa": HTMLInputElement
└bbb: テキストノード
これをXMLで表記すると <p>xxx<input value="aaa" />bbb</p>
仮にHTMLがinputをnon-emptyとして扱うするように仕様変更すると、パース後のDOMが変わり
p
├xxx : テキストノード
└input value="aaa": HTMLInputElement
└ bbb: テキストノード
仕様変更の前後どちらの文書なのか検出してパーサを変えなきゃいけない。
ブラウザはバリデータではないから、間違ったマークアップが施された文書だからって無視するわけにはいかない。 >>439
おk。動かしてみたが再現した。
詳細は>>440の通り、今のDomParserだと</input>を無視するからだね。
>>440
> 仕様変更の前後どちらの文書なのか検出してパーサを変えなきゃいけない。
それはお約束がド頭に付いていることになってるから問題ないだろ。 >>441
>それはお約束がド頭に付いていることになってるから問題ないだろ。
HTML5にはつかない。
HTML5にはDTDがないので
<!DOCTYPE html>
としか書かれていない。仕様変更の前後を識別できない。 >>442
ならHTML6には付ければいいだけの話だろ。 >>443
HTMLは4.01以前と違ってそうやって大きくバージョンを区切る方式を取りやめ
HTML Living Standard として日々更新を続けるようになりました。
HTML1.0→2.0→3.2→4.01のような大々的変更を移行期間を取って行うのではなくて、
日々少しずつ更新される HTML Living Standard に追従してブラウザは機能を実装し、
ある程度の段階でマイナーバージョンとしてw3cが勧告を出す、という流れになっています
ですから、文書のパース結果のDOMが変わるような大々的変更はしばらく行われることはないでしょう。 >>437
未確定文字は、実装依存で各ブラウザによって動作がかなり違う
ブラウザはもちろん、OS、デバイス、デバイスの状態、IME、IMEの設定などに左右されるので対応困難
求めるものにもよるけど、現状のなんとなくvalueを見るが限度。「Range で統合的に取り扱う」なんてのは結局実現できない
もっと変なことをしたいなら、オンラインのエディタとかVSCodeとかをみてみるといいよ。苦しいながら、実装はしてある
DOMパーサの破壊的変更は過去のブラウザやパーサが全滅するわけで、相当の理由と議論がなければ無理。
refererのスペルミスを直せレベルのハイリスク・ノーリターン 2chで知りたいことがあったら知ったかぶりしていい加減なことを言えばいいというのは本当だな >>441
> 詳細は>>440の通り、今のDomParserだと</input>を無視するからだね。
今のDomParserというが、HTML5では仕様化された。
なんと現実に存在する動きに合わせて仕様が作られ
間違ったHTMLであっても、どのブラウザでも同じように表示されるように
間違ったHTMLをどのように解釈するかが仕様化された 訂正 なんと現実に存在するブラウザの動きに合わせて仕様が作られ >>440
なるほどね、HTML parserでXHTMLを読み込ませたケースを想定しているのか
> ブラウザはバリデータではないから、間違ったマークアップが施された文書だからって無視するわけにはいかない。
いや、XHTML parserなら正しく文法エラーをはねるよ
HTML parserが文法違反に寛容なだけ >>442
というか、Content-Typeでparserを振り分けてるから、bodyを読み込んだ後でparser分岐が発生する仕様にすると遅すぎるよね html5のDOCTYPEはこのように短い。 <!DOCTYPE html>
html4まではこのように長かった。だがこれが正式な書き方だった。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
なぜhtml5ではこのように短くなったか? それは単に長いという理由の他に
IE6では当時は間違った書き方である <!DOCTYPE html>でも標準準拠モードとして
扱うという仕様だったため、ならもうhtmlだけでいいじゃん、動くしwww
という理由でこうなった
また、metaタグによるcharsetの正しい指定方法は本来これ
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
contentが属性であり、その中に値として "text/html; charset=utf-8" と書かなければいけなかった
html5では<meta charset="utf-8">だけで良い。
なぜこのような仕様になったか? それは間違ったHTMLでも
それなりに解釈してあげるよという それはIE6のおせっかい機能を仕様にしたものだった。
iE6のおせっかい解釈
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
↓ http-equiv 書かないやついるかもしれないだろ?
<meta content="text/html; charset=utf-8">
↓ ダブルクォートでくくらないやついるかも知れないだろ?
<meta content=text/html; charset=utf-8>
↓ content 書かないやついるかもしれないだろ?
<meta charset=utf-8>
↓
よし、これでIE6動くんだから、これをHTML5の仕様にしてしまおうぜ!
HTML5の仕様を考えたやつはいい意味で頭がおかしい。
かくしてHTML5は間違ったHTMLを解釈する方法が仕様化された >>449
> いや、XHTML parserなら正しく文法エラーをはねるよ
> HTML parserが文法違反に寛容なだけ
XHTMLはXMLをベースとしてしたから、XMLとして
正しくなければ描画できない。
これはどのブラウザでも同じように解釈させるため
間違った書き方を排除することで、どのブラウザでも
同じように描画できるようになるはずだった。
だが現実には単にエラーになるHTMLばかりで
手間がかかるだけで何もメリットを生み出さなかった
それをよこめにブラウザベンダーXHTMLではなく
現実的な回答をHTML5という形で実現させた。
それが間違ったHTMLを解釈するための仕様だ。
これにより、HTML5は文法違反であっても
どのブラウザでも同じように解釈されるようになった
今は文法違反を単に無視するのではない、
文法違反は仕様どおりに解釈するのだ 2018年に「HTML6」なんてワードがITエンジニアの口から出てきたらそれだけで採用面接落とされるよ >>452
HTML StandardはXML parserも定義しているわけで、XMLが完全に排除されたわけではないけどね
選択の自由はユーザにある >>423
例えばGainへの接続を切ったり、その前のノードを止めたりして
Gainへデータが流れていないとvalueは変わらないぞ Javaの教祖マーティン・ファウラー御大、名著「リファクタリング」第2版にJavaではなくJavascript を採用してしまうwwwww
https://martinfowler.com/articles/201803-refactoring-2nd-ed.html >>456
「Choosing JavaScript was deeply ironic for me, as many readers may know, I'm not a fan of it. [2] It has too many awkward edge cases and clunky idioms. 」 but still has annoying holes that are built into the fabric of the language from its earliest days. 嫌いだけどそうせざるを得ないんだろうマーケティング的に。今更Javaの本書いてもなぁ。
かと言ってC#かというとう〜ん。
消去法でこれしかないじゃん。
でもマーチンファウラーが書くとなるとクラスベースオブジェクト指向だろうな。クラスベース構文や方法論嫌ってるやつも多いjavascriptコミュニティでの受け取られ方やいかに。 クラスベース構文や方法論嫌ってるやつも
使わざるを得ないだろ、ビジネス的に
JavaScriptという言語がクラスベース取り入れたんだから JSが取り入れたのはよりまともなクラスシステムなだけだぞ
クラスベースっていうのはそのクラスシステムに縛られざるを得ない言語のことを指すのであって
プロトタイプベースの言語でも結局構造化の過程で何らかのクラスシステムを利用するのは当然だけど
それに縛られないっていうのがポイントなんだから、そこは変わっていないぞ
あくまでまともな選択肢が増えたと言うだけだ
「mapメソッドが追加されたから、関数型嫌ってる奴も使わざるを得ない」
というのと同じくらい大げさ functionでクラスが作れるとか特殊すぎだもんな
個人的には好きだけど 最近monacaでアプリ作ってるって子から相談を受けて、調べた結果なんとか解決してあげられたんだけど
onsenUIってどうなの?
あと、リファレンスがまとまってる所が見づらかったので、良いサイトないかなって探してるんだけどどっかある? さよか…ありがとさん
俺の頭が悪かった
onsenUIやるのにいい感じのハウツーなサイトない? 公式リファレンス見てできるようにならんといつまで経ってもそのままだぞ コードを読むときには役に立つが、逆引きには全く使えなくない?
というか、リファレンスとか言うからいけないのか
サンプルが欲しいっす
あと、エミュレータと実機で動き違うの酷くね?
デバッガ入れるの面倒でエミュレータいじってたから普通にハマったわ chromeのモバイルビューエミュレートも実機とは違うし。
何でも実機デバッグは基本。 まともに動くと思った俺が馬鹿だったよ…
次は気をつけるので許してください せっかくだし、笑われついでに書いてしまうか
関数の呼び出しで
function hoge(){
alert❨"押された!c=" + para❩;
}
--中略--
page内
<ons-list-item tappable onclick="hoge(c=5)>押せ!</ons-list-item>
みたいなコードがあって、このc=5の意味が全くわからなくてさ
エミュレータ上ではcは1で初期化されてて
実機では3が代入されていた
jsは詳しくないけど、なんじゃこりゃと面食らってしまった
概念の名前だけでも誰か教えてくれないか?
もう一つはons.readyが呼ばれない件だから、一応リファレンスにも書いてあってなんか納得は出来たんだけども あ 実機で代入されていたのは「5」3だったらスマホ壊してたわ >>471
そこで代入するのはなんと言うかエグいな。 >>473
そもそもそんなコード、この環境以外で動くのか?
関数内でcは宣言してないから、スコープ的に見えないだろと思っていたら動いてて気持ち悪い… > 関数内でcは宣言してないから、スコープ的に見えないだろ
ハァ?Javascript知らないなら「Javascriptのことは門外漢ですが、」とレスの冒頭に書いとけよ。 友だちが教えてくれた
要するに引数未定義でも引数を与えられるんだな
んで、代入式の戻り値が渡されていると
cは代入式が処理された際にグローバル変数として宣言された事になると
スッキリした
サンクス 引数は関係がない
関数内のcはグローバルスコープのcを指していて
イベントハンドラ中のc=でそのグローバル変数のcに代入されてるだけ ありがとう
一応自分でも調べたよ
代入式の戻り値は代入した値で
この場合hogeの中ではargument[0]が5って参照できるんだってね
引数が多いときに便利らしいけど、Java勢だから想像すらできなかったわ
てか今見るとparaになっててだめだこりゃ >>479
横だが、まだそれでもだいぶ理解を間違えているがな。argumentSだ。
複数形かどうかはJavaScriptにおいては無駄に厳密に適用されてる。
あと、>>471のコードはかなり酷い。
公式でこれならかなり終わってるし、
なら数年以内に確実に廃れると思うから、そのフレームワーク自体使わない方がいいと思うぞ。
それから、Java自体はかなり終わっている言語な事を自覚した方がいい。
(>>456内でも言及されているが、関数ポインタがなかったというのが救いようがない)
それとは別に、JavaScripterもプログラマとしては終わっているから、
この意味ではまともなJava勢が流入してくることは俺は歓迎するが。
君はちなみにJavaならどれくらい書ける? >>480
お前Java書けなそうだなw
どうせ15年以上前の知識しか持ってないだろ? arguments[0] には 5 が(代入式 c=5 の評価値)入っていて、hoge から読み出せるが、この場合それは参照されていない。
グローバル変数 c が読み出されてるだけ。
もちろん良いやり方ではない。 >>481
俺は>>456内での著者の判断には同意する。
ただしそれは>>459の言うようなマーケティング上の理由ではなく、
著者の言うような技術的な問題だよ。
マーケティング的にはJavaは最も成功した言語だし、
リファクタリングが今後必要なソフトウェア資産もJavaが最も多いのは事実だ。
JavaScriptなんて保守する価値もないゴミコードばかりだし、
それ以前に書き捨ての文化だろ。俺はこれが悪いとも思わないが。 いや、私は考えが浅いですって
話はしなくていいからw この人HTMLやXMLの基礎の基礎も知らないで適当ぶっこいてボロクソに叩かれた人でしょ >>480
うん、俺も書いてから漏らしたと思った
ありがとう
公式…?
分かりづらいかも知れないけど、俺>>463ね
知り合いの会社の新人の子とやらが書いたコードをデバッグしててハマったんだよ
俺がどのくらい書けるかって言われてもなあ
SIerだから推して知るべしって感じ
趣味で多少は書くし、量産型の中ではマシな方じゃないってレベル
あと、もう6年くらい前にInazumaVotouってAndroidアプリで投票騒ぎを起こしたことがあるよ
コードはウンコでスパゲティだったが、一応動いたな(笑) で、なんのためにどれくらい書けるのか聞いたのか
おそらくスキあらば叩こうと思って聞いたんだろうなw てか理解を間違えてるってのは複数形のこと?
他の事なら聞いておきたいなって >>486
ググっても出てこないがイナズマイレブンの人気投票で大騒ぎしたあれか?
>>488
お前こっちに来るか?
JavaScript情報交換所(プログラミング既習者専用)
https://mevius.5ch.net/test/read.cgi/tech/1449440793/
Javaで3,000行以上平気で書けて、JavaScriptもやりたいというのなら俺は応援する。
正直なところ、JavaScript使いはプログラマではなくデザイナやExcelマクロレベルなので、
開店休業状態になってる。
他に聞いておきたいこともあれば、それも答えるが。 >>489
それそれ
検索でなくなっちゃったか
楽しかったからたまにまとめブログ見ると未だにニヤつけるんだよね
俺は勘違いしてなければいいや
今後もその子サポートをしてやってほしいって言われてるから、困ったら聞きに行くかも
あと、煽るわけじゃないけど行数多けりゃ良いってもんでもなくない?
100万ステップのモンスターを一人で保守させられてたが、文字のスプリットから手作業でやってたりとか
if(a==1){data=1}とかってクソコードが目についてなあ…(笑)
俺が最初に作ったオセロでも1000ステップ位はあっと思うぞ
やっぱ書いて消してのクソコードばっかなんだがね >>486
ちなみに「公式」ってのはこの場合onsenの公式サイト上のコードのこと。
その知り合いがどれくらい書けるのか知らんが、
書けない奴が公式サイトからコピペするのはよくあることだし、
書ける奴はこんなコード最初から書かない。
だからコピペでソースは公式の可能性が高いと見ての話だ。 >>491
ああ、それならなんだったか
リストの番号を関数に渡す方法がわからなくていじった云々言ってたよ
流石に公式がこんなウンコみたいなウンコしてたら誰も使わないっしょ あ 1読んだら学習スレでしたか
ごめん、もう来ません(汗) >>490
> あと、煽るわけじゃないけど行数多けりゃ良いってもんでもなくない?
これはその通りだが、説明は後述するとして、
> 100万ステップのモンスターを一人で保守させられてたが、文字のスプリットから手作業でやってたりとか
君は余裕で合格、俺は歓迎する。
> 俺が最初に作ったオセロでも1000ステップ位はあっと思うぞ
俺が思うに、Java勢で3,000行のコードを取り扱ったことがない奴はいないと思うんだよ。
君のように他人が大量に書いたコードを保守させられて、規模とかも次元が違うだろ。
ところがJavaScripterにはこれがいないんだよ。ここら辺からだいぶ違う。
理由は簡単で、実際、JavaScriptにおいてはそこまでの規模にならないことも多いからだ。
ただ、これがかなりの元凶で、1,000行程度ならデタラメでも動かせるし、
保守するにしても書き直した方が早いから書き捨てになってしまう。
俺が思うに、ちゃんとした構造を考えて、Javaなら当然OOPに乗せて、
その効果を発揮するのはおそらく3,000行程度以上からで、
逆に言えば、それ以下で収まるのならグダグダ考えずに書いた方が早い。
勿論Javaではこんな事は認められず、「まず構造を考えてからコーディングしろ」となっていると思う。
それが仮に100行のコードであったとしてもね。
それはJavaは現在においては超大規模なコードを扱う前提だから、OOPに乗ってないコードが存在すると困るから。
これは、プログラミングとしては正しい。
ところが、JavaScripterは「構造を考えることのメリット」すら知らないから、考えることもない。
だから話の内容が幼稚すぎてな。
JavaScript自体は良い言語だと俺は思うんだけどね。
何度も言っているが、>>456の著者の見解には同意する。 お、おう
合格すか ありがとう
まあ俺JSは門外漢だし、交換できるほどの情報は持ってないよ
そもそも言語の歴史や方向性が違うから比較するのはナンセンスだと思うけどな
どんな言語だろうと業務システムでビジネスロジック書くのに使われてれば、再利用を想定した作りになると思うよ
UIが変わっても業務は変わらないからレガシーになりやすいと言うか
その中でJavaScriptはUI、Javaはロジックを担当してると言うだけでさ
良い言語も悪い言語も目的別に使いこなせるといいよねえ
その本については良く分からん(笑) 普通にReactとかelectronとかのプログラムは大規模になるし、oopしてるけどね
単に>>494 がJavaScript詳しくないだけでしょ >>495
Javaが不味いのは、その著者も言っているとおり、
関数が第一級オブジェクトでないことだ。
正確には、第一級オブジェクトである必然性は多分無いが、
関数ポインタが使えず、その回避策に継承を用いるのは明確な間違いだ。
そしてJavaはこの期間が長すぎて、間違ったコードが量産されてしまっているし、
界隈に関数ポインタを使えない奴(使おうとも思いもつかない奴)も多すぎるだろ。
ただこれも、著者が言っているとおり、
その当時は関数ポインタなんてそんなに重要視されていなかった。
それよりはクラスシステムだったし、
逆に、今はそれがあるからこそ、その次の関数ポインタ、ってのはある。
だからこの辺の歴史的経緯を無視するのはナンセンスだが、
Javaはそれにしても進化が遅すぎた。
> どんな言語だろうと業務システムでビジネスロジック書くのに使われてれば、再利用を想定した作りになると思うよ
> UIが変わっても業務は変わらないからレガシーになりやすいと言うか
> その中でJavaScriptはUI、Javaはロジックを担当してると言うだけでさ
これはその通りだが、つまりはUIが変わり易すぎて、JavaScriptの場合は書き捨てになってしまっている。
結果、プログラマとしては全く上達してない。
Java->JavaScriptは、文法その他を覚えるだけでいいが、
JavaScript->Javaは、プログラミング自体に習熟する必要があるから、無理だね。
Web系()とか言って馬鹿にされているのも、状況を知れば納得すると思うよ。 関数ポインタ関数ポインタってくり返し言うと素人っぽいぞw
関数ポインタがなにか分かってないやつの言い方だ そして俺は関数ポインタなんてよく分からん…(笑)
Javaのmethodオブジェクトじゃあかんの? まあ見ての通り、こいつら幼稚園児かよって思うでしょ。
これがWeb系()の実態だよ。
Javaが良い言語とは全く思わないけど、
JavaのOOP至上主義は結果的にプログラマに上達を促している。
あんまり考えたことはなかったけどね。
JavaScripterは自由にやっているけど、方向性を間違えているから全く上達してない。
勿論ちゃんとやっている奴も中にはいるんだろうけどさ。
そこで俺は、ちゃんとしたプログラマがJavaScript界隈に流入してきて、
結果的にデタラメなお前らが駆逐されることを望んでいる。
勿論、お前らでもちゃんとしてれば駆逐されないし、界隈も浄化されるからお前らにもメリットがある。
お前らが反対しているのは、つまりは駆逐される側だと自覚してんだろ。
せいぜい安らかに死ね。
と言いたいところだが、残念ながら、早々変わらないとも思うが。 そこに書いてあるreflectはJava用語じゃないなぁ
プログラミング用語だ。
知ってるふりした無知だなってよく分かる発言だなw 素人っぽさが文章に溢れてるって言うこと
あまり強い言葉を遣うなよ弱く見えるぞ状態 >>501
公式リファレンスなんてめったに読まんから分からんが多分それ
関数ポインタって要は関数のアドレスを格納してる変数でしょ?
Javaの場合、プリミティブじゃなきゃ、だっか?忘れたが基本は変数すべてがポインタみたいなもんらしいよ
関数ポインタが使えて何が嬉しいかってのがよく分からんけど、呼び出す関数の差し替えができるとか、複数機能を横断的に使用できるとかって話じゃないのかね?
methodオブジェクトはインスタンス化されたクラスの中にある関数そのものへのポインタで、こいつを使うとクラスから関数引っこ抜いて直接呼び出したり書き換えたり出来る とうろ覚え
一回しか使ったことないからあやふやですまん
差し替えとか継ぎ足しが出来るかは知らんわ 特に関数ポインタって繰り返してる所が素人っぽさを増強してる。
自分の知ってる言語の用語にとらわれている=他の言語を知らない JavaScriptは書くのは本当に簡単なんだけど保守が難しい
OOPに則ってデザパタ使って自分で一から開発したソースでさえ数ヶ月も経つと分からなくなる
型もアクセスレベルも無いってのがとにかく最悪だな >>505
関数ポインタの理解については、それで合ってる。
問題は、いちいちリフレクションかよ!ってことで、もっと日常的に使おうよ!ってこと。
変数と同格で使えるようになれば、もっと分かりやすいコードが書けるよ、ってだけ。
書けば慣れるし、使えば確かに便利だと実感すると思うよ。
> 差し替えとか継ぎ足しが出来るかは知らんわ
これはやりたがっている奴はいるが、これ自体はさほどインパクトはないね。 ほらな、やっぱり素人っぽさが出まくってるw
関数ポインタなんて言わずにJavaならJava用語使って言えよ >>509
あー
たしかこれで引っこ抜くの都度都度おまじないが必要だった気がするな
セキュリティーがどうとかだったか?
まあ、javaやってればそのくらいは身につくんじゃないの?
言われてみるとあったら便利だけど、無くてもクラスから呼び出すだけだからあんまりピンとこないな
それよりvmとgcが…おや、出かける時間だ
まあjavaScriptはどっかでちゃんとやりたいしその内お世話になるかも
その時は宜しくどうぞってことで
でかける時間になっちゃった(笑) >>507
無理だからと言って書き捨てばかりしているようでは、
いつまで経っても書き捨てのコードしか書けない。
多少無理でも歯を食いしばって無理矢理でも保守しないと、
何が問題なのか認識できないし、当然改善なんて出来ない。
Javaにおいては多分最初から「書き直し」の選択肢はない。
これがプログラマを育てている一面はあるよ。
> 型もアクセスレベルも無いってのがとにかく最悪だな
関係ない。
が、関係あるのなら、君は「型」「アクセスレベル」の類推を文法に依っていることになる。
それが間違いだろ。
もっとも、書けば解決する話なら、TypeScriptみたいに、
或いはコメントにでも書いてしまえば解決するだけの話だろ。
試しにやってみろよ。 はいはい。ここまでラムダもででこず、
やっぱり15年前の狭い知識で
粋がってただけだな 関数ポインタという用語をを日常的に使うのはCとレガシーなC++だけな気がする
JavaScriptは書き捨てるからクソと言われても、どこがどう悪いのか書いてないと詳しくない人が騒いでるようにしか見えんな
普通に巨大なプログラムはいくらでもあるんだけど >>511
行ってらっしゃい。
まあその気になったらよろしく。
> セキュリティーがどうとかだったか?
つかそもそもリフレクションってこんな時に使うものではない。
あれは動→静変換とか、privateに上書きとか、だろ。
> 言われてみるとあったら便利だけど、無くてもクラスから呼び出すだけだからあんまりピンとこないな
それは使ってないときの実感としては合ってる。俺もそうだった。
だけど、使い出したら関数ポインタ無しなんて糞言語だと実感するようになる。
> それよりvmとgcが…おや、出かける時間だ
ここら辺はJavaと同じ。
JavaScriptもVM上(とは言われないが所詮はスクリプト言語だから)だし、GCもある。 どうやら都合が悪い話を見なかったことにしてるみたいだから
NGにして見えなかったと言い訳できないようにID変えておくねw
はいはい。ここまでラムダもででこず、
やっぱり15年前の狭い知識で
粋がってただけだな >>514
> 関数ポインタという用語をを日常的に使うのはCとレガシーなC++だけな気がする
正解。関数ポインタが使われているのはC/C++と
あまり詳しくないけどObjective-Cもかな?
まあともかく多くのモダンな言語に関数ポインタなんてレガシーなものはない >>511
ついでに言っておくと、
Web系言語(JavaScript/PHP/Go)はWeb情報に間違いが多いので、
MDNとStackOverflow以外はうのみにしない方がいい。
まあ、Java知ってれば、これ嘘くせー、ってのは大体分かるとは思うが。 >>515
チャリがパンクexceptionをcatchしてwalk()を実行中。
リフレクションの詳しい意味合いまでは知らないなあ
無理やりいろいろ呼び出せるし便利って思ってたけど(笑)
へー、そうなのか
javascriptのエンジンってやつがvmなの?
>>518
そうなんだ?
条件にマッチしてるものを探すのがjavascriptの方が難しい気はするなあ
まあ、滅多にやらんから運が悪いのかも知れんけど とりあえずjava公式を見てjava用語じゃないとか言うのはどうかと思うよ… JavaScriptには関数ポインタはないって思ってるけどあってる? >>521
あってる。関数ポインタはC言語系ぐらいにしかない >>519
あまり皮肉言うなよw
リアルで分かってないやつに言っても
理解できないぞw テレビゲームはみんなファミコンというばあちゃんと同じ
なんでも関数ポインタとしかいわない function f = unko(){alert("kuso")}
みたいな話じゃないの? >>525
プロならそれを関数ポインタと呼ぶのは間違いだって
知ってるからさぁ >>525
Javaで書くとだとこういう感じね
Collection.sort(list, (p1, p2) -> p1.getAge() - p2.getAge()); そうなんだ?
まあ、よく分からんけどそれのことを言ってたんでしょ?
着いた!
System.exit(0); >>528
文脈から、JavaScriptのことをJavaって読んでるのがわかったとしても
間違ってる用語を使ってる人は素人にしか見えないって話だよ >>519
うむ、まあ俺も寝るが、
> 無理やりいろいろ呼び出せるし便利って思ってたけど(笑)
そうなんだけど、あれは「奥の手」であって、常用すると不味いでしょ。
どうしても必要なのは動→静変換時くらいで、
あとは、使うこと自体が間違っている、とも言えるはず。
> javascriptのエンジンってやつがvmなの?
ソース(テキスト、Javaの場合はバイトコード)を読み込んでサンドボックス上、
という意味ではそうだね。
> 条件にマッチしてるものを探すのがjavascriptの方が難しい気はするなあ
ググったら大体ブログなりquitaなりが引っかかると思うけど、
Javaの常識では考えられないくらいほど間違いが多いから気を付けて。
勿論正しい情報もあるとしてね。 >>525
それは関数オブジェクト
関数ポインタと比べてもっと高機能な存在
用語の正しさとかは気にしすぎてもしょうがないんだけど、JNIとかの絡みで本物の関数ポインタを扱う可能性があるので、混同するのはよろしくない わかってるとは思うけど、
> javascriptのエンジンってやつがvmなの?
VMとは限らないからねw
どうも、IQ9(笑)の人は
素人まるだしなものでw まあ少なくとも>>530みたいなやつの話を信じてしまうような人は言語かかわらず偽情報には注意だな 同じタイミングで消えたところからもわかるように
自作自演ですね。 なかなか清々しいほどの自作自演だったなw
こうもバレバレなのに続けるのを見ると逆に感心するわ Goが「Web系言語」ってどこの世界の話だ?
汎用のシステム開発言語だぞ
Web系の開発が過熱してる時期に出てきたからWeb系の実績が多いだけ
この人なんつーか、何かを話題に出す度に大昔の記憶と思い込みだけでモノ話してるよな このスレのこいつ、ホントになんとかならないのかな。
jQuery、SPA、HTML、XML、Java、Go、どれ一つとってもまともな知識がない。
全部断片の聞きかじりを覚えてるだけ。
もう少し真面目にやりゃ良いのにな。
あと、Goはいいぞ。 >>537
マジそれなw
そいつ今度はこっちであばれてるようだぞ
なんか万引きは貧困が原因で、お金持ってるのに
万引きする人はいないって言いたいらしい。
その根拠の示し方がそいつとまったく一緒
聞きかじりの言葉を並べるだけで、内容をまったく理解してない
もうそろそろ違法ダウンロード問題を再開しても良い頃だ
https://medaka.5ch.net/test/read.cgi/prog/1518681416/ Goは絶賛するほどよい言語ではない。
所詮はマシンリーダブル言語 >>540
もしかして、
ヒューマンリーダブル=マシンアンリーダブルだと思ってる? 質問です
一つ簡単なゲームを作りました
ただどうしても警告が取れなくて困っています
http://sonicgefard.playcode.io/
こっちが実行ページで
https://playcode.io/sonicgefard?tabs=console&script.js&output
こっちがソースが見れるページです
ゲームハードメーカーが出したゲームソフトを当てるというクイズゲームです
phina.jsというライブラリを使ってます
javascriptは独学で初心者同然です
根本的にわかってないという可能性もあります
どうしたらゲームの機能を維持して警告を取ることができるでしょうか? >>539
同意。Goは糞。
あれをありがたがっているのはC++/C#/Javaのどれも使えない奴(≒Web系)だけ。
とはいえこれらではWeb向けライブラリが薄いので、WebにはGoの方がマシなのも事実だが。
俺の予想では、GoはWeb向け以外で流行ることはない。
これはJavaScriptがデスクトップにも適用範囲を広げようとしているのとは好対照だ。
ただこれも、JavaScriptそのものというよりは、HTMLが秀逸でGUIに最適だからだが。
だからWPFはHTMLモドキを採用したがJavaScript自体は採用せず、C#のままだし。 >>543
>Web向けライブラリが薄い
具体的に > 俺の予想では、GoはWeb向け以外で流行ることはない。
あれ?DockerってGoだったはずだけど? XMLを「HTMLもどき」とか言いながら上級者ぶるの見てる方が恥ずかしくなるからやめてけれ〜 >>542
うちの環境だとdoctype宣言が2つある
って警告が出るだけなんだが(edge,win10,64) GoがWeb系ってどんな脳みそしてるんだろ。
いいぞ、軽量プロセスと並行プログラミング。
他の言語で同じ事をしようとするとすごく辛い部分。
C#もJavaも実務で使うぐらい使ってるが、Goはどちらの毛色とも確かに違うが違って良い。
使えないから持ち上げてるんじゃなくて、Goでならシンプルに解決できる問題があるから使うんだが。
Web向けで流行ってるわけではなくて、バックエンド系でしょ。
依存無しシングルバイナリが簡単に吐けるし、クロスコンパイルも充実。
もしかしてGo使ってもないのにdisってる? WPFのxamlをHTMLもどきと言うのも頭おかしいわ。
あれはXMLであって。
しかもBindingの仕組みやら、アニメーションやイベントやら準備されてる。
むしろ、HTMLがXMLもどきでしょ…。strictで無いのは特に。
SGMLとか若い人は知らんのかな。
と言うか知識レベルが恥ずかしすぎるから、もう喋らない方が良いんじゃないかなぁ。 >>548
> GoがWeb系ってどんな脳みそしてるんだろ。
自分の仕事はウェブ系ではない
↓
自分の仕事では関係ない
↓
よってGoはウェブ系 Web向けライブラリも流石に現段階ではJavaやC#のほうが実績あるでしょ
今後はgolangが広がってくかもしれないけどね >>550
仕事してるとは思えない知識の少なさとその少なさの自覚のなさだよ。
俺にこいつが下についたら、速やかに干す。 >>552
知識の少なさって、どこを見て判断したの?w
知識を問われるような事言われたかなぁ?w >>551
tomcatやらasp.netのIISに相当するものは無いからな。
APIサーバとしては優秀だが。 つーかIT業界でどんだけ偏った仕事をしてたらXMLを知らないなんて状況になるんだ
高校生でエンジニアを目指してもいない頃からHTMLとXMLの関係ぐらい知ってたぞ >>553
どういう事?
jQueryから、SPAの勘違い(突然レスポンスコードの思い込みで発狂しgooglemapを例に挙げたら、twitterというアプリケーションでは無いものを挙げてきたり)から、HTMLの属性と小要素を混同してみたり、
xamlをHTMLもどきと言ってみたり、
基本的に知識のベースラインが無いところに砂上の楼閣のように聞きかじったことを積み上げて独自理論で的の外れた長文書くところから、知識が少ないと総合的に言ったんだけど。 あ、誤解してたらごめん。
ID:6pCy057fが知識無いって言ってるんじゃないよ? 追加すると、C#とJavaにWeb向けライブラリが薄いってのもかなりの知識不足だな。 >>542
chromeでコンソール開いた状態で
ノーミスで時間切れまでやったけどエラーひとつもでなかったが。
あとMSのゲームばっか聞きすぎw >>542
64bit Windows10・Chrome でプレイしたけど、何も問題ない
今は、phina.js とか、
pixi.js を使った、Phaser とかが流行っているのか >>547
ふーむ
それだけなら問題ないのかな?
>>559
なんかこのサイトのエディタで警告みたいなものが一つ出てるんですけどこれは無視して
いいのかな?
msのゲームがよく聞かれるのはたまたまですね
ソースを見てもらえばわかる通り完全なランダムです
偏りがあるとしたらそれはmath.random()メソッドのせいですな
>>560
問題ないんですかね
ならいいか
ありがとうございます
phina.jsを選んだのは開発者が日本の方なので日本語のテキストがネットに多かったからです >>562
https://playcode.io/sonicgefard?tabs=console&script.js&output
このソースが見れるサイトはplaycodeっていうんですけど
このサイトのエディタの226行目に警告が出てます
https://i.imgur.com/SHtf8NC.png
「too many errors. (93% scanned)」というメッセージなんですけどさっぱり意味が分からなくて >>564
別のエディタで見てみたけど何も出ないよ
エディタ側の不具合じゃね >>565
ああそうなんですか
じゃあ無視していいのかな?
これからは複数のエディタで確かめてみる事にします
ありがとうございました >>563
> いやゲームの場合、数学的に質のいい乱数でも人間が不自然に感じることがある。
面倒くさいから読まないが、テトリスで
I-テトリミノがなかなか出てこなかったら
乱数どうなってるんだ?って思うやつだな。
今のまともなテトリスは完全な乱数ではなく、
すべて形が同じ回数になるように出現する
だから予測して積むことができる google chrome拡張機能でマウスオーバーさせて右クリックなりで画像URLを取得するものを作成したいと思っています。
まずは画像URLを取得して色々する、そのURL取得自体ができないので質問に参りました。
ttp://oxynotes.com/?p=8906
ttp://www.kagua.biz/tool/chrome-extension/gazo-no-url.html
検索してこちらあたりから見て、background.jsを改良して作成できると思いまして、
以下のようなbackground.jsを作成しました。
///////////////////////////
chrome.contextMenus.create({title: "hogehoge", "contexts":["image"],onclick: hoge}, function(){
alert("コンテキストメニュー登録完了");
});
function hoge(){
var t_url = hoge.srcUrl;
alert(t_url)
};
///////////////////////////
しかしこれではurlはundefinedとなり表示されませんでした。
hoge.srcUrlをinfo.srcUrlとしても無反応で表示されませんでした。
どのようにすればよろしいでしょうか… >>568
手元に環境なくてごめんけど
とりあえずhogeに引数つけてみたら?
function hoge(info){
var t_url = info.srcUrl;
alert(t_url)
}; >>569
すみません;自分の検索が弱くいくつもあったかとは思うのですが
最終的に、urlを拡張機能で、javascriptとして得て、
PHPファイルに渡して、そこで画像アップロードまでを一連化ですとか
最終的に自分の便利ツールをいくつか作成してみたいと思い
ここは飛ばせないと思い、注力しておりました。
>>570
有難うございました!できました!
本当にこのあたりを理解していない現段階でしたので、大変に有難かったです;
有難うございました!!! ブラウザの右クリックメニューで、要素の検査で、F12開発者ツールが起動すると、
こういう要素が見つかる
<img src="tagindex.gif" alt="TAG index" border="0">
誰かが作った、拡張機能があるのなら、それを使えば?
この板よりも、web制作管理板の、JavaScript のスレに書き込んだ方がよい >>570では、568で質問したchrome右クリックをしている状態での画像URLを表示することを
教わり、本当に有難かったのですが、
画像にマウスオーバーしているだけでURLを抽出するものに取り組んでいるのですが、
色々やってもうまくいかない状態です…
manifest.jsonからショートカットキーで以下のbackground.jsに飛んできたとしまして、
/////////////////
chrome.commands.onCommand.addListener( function aabb(uiui){
var img_url = uiui.srcUrl;
alert(img_url);
};
ショートカットキーでここは起動するのですが、img_urlは存在してない扱いで、
alertは undefined表示となってしまいます。と自分でも本当にごちゃごちゃですが・・
すみません、なんとか教えて頂けませんでしょうか・・web制作板に行くべきですが、
568の経緯もあって、すみません・・。 この板には、web系の開発者はいないだろ。
web制作管理板の、JavaScript のスレに書き込んだ方がよい
君は、F12開発者ツールも知らなかったの?
JavaScript, jQuery も知らないじゃないの?
そんな人が、作ることは無理。
ツールを探した方がよい >>575
すみません…右クリック「検証」のような事から多少操作はしっていましたが、
F12というそういう事もはっきりとした知識をもって操作はしておりませんでした…
javascript、jQueryは今勉強中というつもりでして、
すみません…
しかしもう少しここで待たせて頂けませんでしょうか…自分も引き続いて
色々のパターンを試したいと思います、すみません… >>576
web系云々なんてこのスレの質問内容から見て今更の話だけど
ショートカットキーを押下してスクリプト起動を想定してる様に見えるが
態々そうする理由があるの? >>577
こだわる理由としましては、
例えば目的の画像があり、
ここを右クリック、メニューより項目を選んで起動
という2つの動作でなく
ショートカットで一発起動
という、秒数で言えば2〜3秒の差かもしれませんが
ツールとしてはこの上下は長く使うには間違いなく大差が生まれると思ったためです。
自分自身が使うのですが、人が使うにしても
対象右クリック、〜〜〜 より、一発の方が凄く速いと思ったので、です・・ すみませんでした;。
>>570の時点ですごく満足させて頂きましたので、
先ほど自分が述べましたあたりを含めて
今後勉強していこうと思います。
退散いたしますので、有難うございました!!! ショートカットキー・右クリックメニューの両方やればよい
ショートカットキーは覚えていられないから、右クリックメニューが基本。
そこに、ショートカットキーも書いておく
この板では、web系の開発者が少ない。
web制作管理板の方が、開発者が多いから、回答者も多い 俺はこっちにも出張してるぞw
jQuery関係の話なら特によく俺がレスしている webを壊したjQuery
cdn証明書期限切れのお粗末 webを壊したのがjQueryなら
webを修理したのもjQueryなわけで >>579
とりあえず最低限のサンプルは作ってみたけど
https://pastebin.com/5m2cwZnp
このままじゃchrome.commandsを利用する利点があまり無い
これ以上は
・イベントの基本
・content scriptとbackground pageの領分
を理解してもらわないとフォローのしようが無い https://jsfiddle.net/ab7fc708/8/
これのconsole.logが、3: 5 ab: "c"という順番になるのは何故ですか。
また[true && false]がfalseになるのがよくわかりません。 >>586
オブジェクトの中身に本来順番は無い
たまたま数値を先にしてあとは挿入順に整理するブラウザが多いだけ
後者は何が疑問なのかが分からない es2015のcomputed property nameが分からんのか単に論理演算子が分からんのかどっちや >>587
ブラウザの仕様だったんですね なるほど
このコード自体本に書かれたものを書き写しただけなんですが、後者についてはそもそもソースの意味がよくわかってないです。もうちょっと調べてみます。
どうもありがとうございます。 >>588
すみませんレス見落としてました。
論理演算子はわかります! &&ならAかつBという意味になりますよね AかつBが共にtrueでtrueであって、片方falseだよ。 >>591
これ普通にtrue && falseの解がfalseって意味ですよね >>586
[true && false]でどうなるのを期待したの? Ruby の論理演算子は、短絡評価(short)。
先に左側を評価して、そこで答えが確定したら、右側を評価(実行)しない。
論理式全体の戻り値は、最後に評価された式の値
true && B
false && B
上は、Bを評価して返すけど、
下は、falseの時点で、偽が確定するから、Bを評価せず、falseを返す
true || B
false || B
上は、trueの時点で、真が確定するから、Bを評価せず、trueを返す。
下は、Bを評価して返す
a ||= 1
これは、a = a || 1 なので、aが偽なら、aに1を代入する。
デフォルト値を入れる、定番の書き方 >>597
JSの本にcomputed property nameについて書かれていたのですが、サンプルソースの意味がよくわからなくて質問しました。
何かしようとしてたわけではないです(というか普通こんな書き方はしないですよね)。
言葉で書くと複雑ですけど>>594がそのまま答えですね、どうもありがとうございました。 短絡評価はわかるけど、A && BはAがfalseの時にBを評価しないでfalseを返す、AがtrueならBも評価するはず。&と|を間違えてないか? A && B では A が falsy なら A が返り、truthy なら B が返る。
A || B では A が truthy なら A が返り、falsy なら B が返る。
A が返る場合 B は評価されない。
("hello" || "world") && ("hello" && "world") は "world" になる。 相変わらずの馬鹿っぷりにあきれる。
お前らマジでJavaScriptの前に日本語を勉強した方がいい。話にならない。
MDN用語(getter)も通じないところをみると、お前らはMDNも読まない/読む気がないようだが、
実際はお前らの日本語が酷すぎてMDNすら読めないからだろ。
今回の話なら、以下2つになる。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_Operators
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Object_initializer
質問者は何が分かってないのか明示できるほどの日本語能力が無い。
この場合、仮に正しい回答をしたとしても、どうせ通じないから意味がない。
また、MDNには複数の人が何度もレビューした結果が掲載されているのに対し、
ここではお前らみたいな馬鹿が思いつきを書くだけだ。
どうしても一般的な回答のレベルは劣ってしまう。
唯一、質問者が勘違いしているところをピンポイントで救済できるとき以外は
MDNの方が常にマシだとわきまえた方がいい。
>>587-588までは順当としても、それ以降は酷すぎる。
お前らがJavaScriptを職業スキルとして選ぶのなら、MDNとは一生つき合うことになる。
MDNが読めないようなら、まず日本語(或いは英語)を鍛えないとどうにもならないぞ。
そして回答する側も相手側の日本語レベルを考えて回答しろよ。空回りしすぎ。 君はMDNより先にXMLやHTML、DOMの仕様書先に読んだ方がいいと思うよ つか、「空要素は終了タグつけるか、空要素タグを使って表現しろ(≒空要素タグを使うなら終了タグは不要)」って文を見て
「終了タグなし要素はなしになっただろ」とか言いだすようなヤツが日本語能力について語っても、その……。 >>602
お前は日本語じゃなくてもいいから言語を勉強しよう
getterの意味はわかってるけど、お前の用途が間違ってるんだよ
オブジェクト指向の設計の話をしてるのに、実装(getter)の話をされてもね
JavaScriptのgetterは出番はないし、C++の実装ではAudioとか関係なくgetterは使うし いや、getter はめっちゃ使うけど、それはおいとてなんの話だ? UMLでgetter/setterという用語を使うのが
俺は許せないんだ!って叫んでるやつがいるってだけじゃない?
ムシムシwww >>606
「ウリはザパニーズニダ」が多すぎるって話。
こいつらがいなくなれば、このスレは相当改善される。
何故かは分からんが、JavaScriptのスレにだけゴキブリ大集合だ。
Q. true && false が false になるのが理解できません。どうしてですか?
A. お前が馬鹿だから
いやマジで いや、いつものよくわからない憤りをもった子でしょ。 >>608
アンドとかオアとか、ビット演算とか応用レベルで理解してるプログラマって少ない。
ビットマスクで解決する部分をほとんどのプログラマがブーリアン型大量に定義したりしてる。あれ、疲れるからやめてほしい。 bool 型で十分。
内部的に、1bit に最適化しているかも知れないし
自分で、1bitに最適化する必要はない Javascriptって変数の型宣言して作ることはできないの?varで作ってから入力読み込んだデータを型変換して入れるしかない? Jaascriptは全部64bit(32bit環境では32bit)だと思う
すべてのオブジェクトはObjectの拡張だし
何ビット目が何を意味するかを管理してたら、
何変数が何を意味するかを管理するのと、コスト的には変わらんよね >>589
たまたまではないのでデマにだまされないように
オブジェクトの列挙は配列数値が先、次に挿入順にするようにECMAの仕様で決められている
細かいことを言うとfor-in構文の場合だけ互換性の観点から規則が緩いが、
そこでもこの列挙順を利用することにはなっているので
新たに仕様を参照する場合はそこから何か独自にソートしたりすることは考えづらいので
必然的にこの列挙順になるようになってる >>587
この知ったかサイコデマやろう!
危うく騙されるところだったぜ! >>621
いや、そこまで言う必要はない
物は言いようで「たまたま」のニュアンスにもよることだし >>618
>>619
はぁ、視野が狭いのおれ
おれはもう諦めるよ >>618
> すべてのオブジェクトはObjectの拡張だし
Object.create(null) typeofで帰ってくるのはObjectでなくobjectだからな
それは全てのオブジェクトはオブジェクトの拡張と言ってるようなもんだ select要素をコピーして追加したいのですが、
$( "#sid" ).clone().appendTo( "#divid" );
のように直接行うのではなく、テーブルのため、あとからまとめて追加したいと考えています。
そのため、clone()をいったん文字列として格納したいのですが、
どのようにしたら良いのでしょうか。
.text()を使用すると、valueのみ表示され、タグ<select ・・・ などが格納されません。 >>628
テーブルのためとか文字列として格納とかさっぱり意味分からんけど
そのまま変数に入れればいいんじゃない
let elem = $("#sid").clone();
//その他の処理
elem.appendTo("#divid"); >>628
君が求めているのは
https://developer.mozilla.org/ja/docs/Web/API/Element/outerHTML
だが、後からまとめて追加するだけなら、jQueryオブジェクトのままでいいと思うがな
わざわざ、文字列に変換するコストが無駄 >clone()をいったん文字列として格納したい
全く意味がわからない
var docFragment = document.createDocumentFragment();
メモリ内だけに存在する、まだDOM に追加していない、
DocumentFragment を使えば?
JS, jQuery の質問は、web制作管理板へ書き込む方がよい。
この板には、あまりweb系の開発者がいないから >>631
> メモリ内だけに存在する、まだDOM に追加していない、
> DocumentFragment を使えば?
それでもいいんだけど、jQueryオブジェクトがその状態だから、.clone()だけで目的は達成してるんだよね
そこから、更に文字列化する意味が分からない というかオブジェクトは単純なものでないと文字列化できない
DOM要素は文字列化は無理 >>633
Reflecting content attributesの範囲で文字列化は可能だけど、完全ではないね
質問者の期待値に依る すみません皆様
outerHTMLでいけました。
var tr_row = '<tr>' + ”ここにいれたい。” +
'<td><input type="text" ...></td>' +
'<td><input type="text" ...></td>' +
'</tr>';
上記場所に入れる際に、<tr>タグの途中なので、appenndはできないしと思い、
文字に変換するのはどうすればよいのかという次第でした。 prependTo()でエエやん
てか<td>で囲む必要はないの? 漏れも、面倒くさい時は、文字列で階層のあるHTML タグを作って、
innerHTML などで1度に挿入したりするけど、
こういうのは、デモを作る際だけにしておいた方がよい
こういう書き方は、保守性が低いし、
構文をパースしてDOM を組み立てるから、実行速度も遅い そうでもない
ブラウザのHTMLパーサはカリカリにチューニングされていて爆速だから、
JavaScript側でこねくり回すより遥かに効率良かったりする
innerHtmlなら途中でレイアウトなどの余計な処理が走ったりすることもないし ごちゃごちゃDOM操作するより文字列組み立ててブッ込む方がはるかに保守性も性能も高いと思うけど テンプレートリテラルも実用域に入ってきたし文字列でも保守性問題ないな。 タグにclass が付いていたり、URL があったりしても面倒。
シングル・ダブルクォーテーションの扱いも面倒だし、
URL エスケープ処理も面倒
あちこち、バグる
文字列で、タグを作るもんじゃない 少なくともこの質問のケースでは文字列で組み立てる意味ない jQuery嫌いな自分が言うのも変だけど
使うなら徹頭徹尾使えと >>646
jQuery便利なんだが、デバッグ難しいからねえ・・・ 理由なく難しいと言われても何のことか分からんのだが?
jQueryだからって特に難しいことなんてないぞ >>648
エラーで落ちても知らんぷりの言語だしね。 エラーで落ちたらログにでるじゃん?
エラー時にダイアログを出す設定も有ったはずだが
(普通のサイトでうざくなるんで通常はOFFにするけど)
やっぱり単にデバッグの仕方を知らずに
難しいって言ってるだけな気がしてきた
本人の能力の問題w printfデバッグって・・・未だにそんな事やってるのか。 >>653
あなたはどこを読んで勘違いしたんですか?w >>654
結局、マトモなデバッグ方法無いって事じゃん。
ミンシン並み。 どこにもそんな事かいてないし、
ブラウザにデバッガが内蔵されてる
知らないなら素直に知らないって認めなよ? chrome のデバッガは確かにすごいけどもうそれとにらめっこしながら開発はしたくない
結局主要ブラウザ全部で動作見なきゃいけないし 必要ないなら見なくていいと思うけど、おまえはなにが言いたいんだ? >>658
ブラウザがたくさんあるんだからその問題はどうあがいても避けられないのでは? javascriptでphp CGIにajax送信をしたいんですが
(x, 1) (y, 2) (y, 1) ...
みたいな同じタグや値を持つ可能性のある複数データペアを送信するのってどうしたらいいでしょうか
var fd = new FormData();
fd.append('x', '1');
fd.append('y', '2');
fd.append('y', '1');
でも
var fd = new FormData();
fd.append('name', 'x'); fd.append('value', '1');
fd.append('name', 'x'); fd.append('value', '1');
fd.append('name', 'y'); fd.append('value', '2');
でもダメでした
req = new XMLHttpRequest();
req.open('POST', URL, true);
req.send(fd);
こんな感じでおくって
CGI で $_POST で受け取ってます PHP側もからむ問題みたいなので他できいてみます
マルチポストになるので質問〆ます >>662
javascript側は前者で問題ない
もしかしたら fd.append('y[]', '2'); fd.append('y[]', '1'); の方が良いかもしれんが >>662の件別スレで解決できました
>>665さんも〆たあとなのにありがとうございました
あとまた質問なんですけど
ブラウザゲームで特定の画面のときにデータを読んでCGI経由で保存するみたいなことをしたいのですが
if(location.pathname.indexOf(URLキーワード) >= 0) {
var data = document.getElementByClassName(クラス名);
POST
:
ってかいてもそのページで動きません
console.log(location.pathname);
if(location.pathname.indexOf(キーワード) >= 0) {
って直前にいれるとブラウザの表示と別のURLが表示されます
ページ遷移はせずにURLだけかわっていくような仕組みみたいです
直接かいても window.onload = function() { の中に書いても同じで
いちばん最初に読み込んだページでしか動かないみたいで
特定のURLや要素が出現した場合にだけ動作するようにするにはどうしたらいいんでしょうか 何度もすいません
.getElementsByClassName の帰り値がよくわからなくて困ってます
function next() {
var scores = document.getElementsByClassName('score');
if(scores == null || scores.length == 0) {
setTimeout(next, 1000);
return;
}
console.log(scores.length); // 3
for(var score in scores) {
console.log(score); // 0
console.log(score.nodeName); // undefined
}
}
scores.lengthが3になってるので要素の取得は成功してるように思うんですが
for文で中身をとりだそうとしても0と表示されるだけで
innnerHtmlやNodeTypeを表示してもundefinedになってしまいます
for-in の使い方がまちがってますか?
Javaを大学で習ったので文法の近いjsもすぐかけるかなと思ったんですが
スクリプト言語は型がぐちゃぐちゃでエラーの原因がまったく特定できなくて泣きそう >>668
まずな。for in っていうのはオブジェクトが持ってるプロパティを取得するもので
arrayに対してfor in を使うのは間違いとされているんだよ
添字以外のものが取得できてしまう場合がある。
例えば、a = [1, 2, 3] だけなら添字しか取得できないが、
a.hoge = "test" とか実行できるので、その場合は添字0〜2に加えてhogeも列挙してしまう。
正しくはarrayの要素を列挙するなら、for of を使用することだがIEは非対応だ
また、getElementsByClassNameの戻り値は実は配列のように見えるが、NodeListという型で
これはJavaScriptの配列の条件を満たしていない。そもそもgetElementsByClassNameといった
DOMのAPIはJavaScriptの範囲外。ブラウザが提供しているものでJavaScript以外の言語でも
使える仕様であるため、JavaScriptとは独立した存在でJavaScriptの配列と互換性が保たれていない
使えるようにしようという話もあるが一体いつになるのやら
そういう配列っぽいけどJavaScriptの配列ではないものは、それに応じたやり方をするしか無く
getElementsByClassNameの戻り値の場合は、0からlengthまで、カウンタ変数を
インクリメントしていく昔ながらのfor文を使うのが基本の方法
for ofの他に、NodeListのforEachメソッドを使うやり方もあるが動かないブラウザがある
変わったやり方として、NodeListのような配列っぽいオブジェクトをJavaScriptの配列に変換するという方法がある。
JavaScriptの配列に変換するとforEachメソッドが使えるようになる。
この変換の方法としていくつかやり方があって、
1. Array.prototype.forEach.callを直接使う方法
2. Array.prototype.slice.callを使う方法、
3. 比較的最近のブラウザで使えるスプレッド構文を使う方法
4. 同じく比較的最近のブラウザで使えるArray.fromを使う方法
などがある
まあいろいろしがらみがあって、できると思ったようにはできないってことだ うーん…
syntax エラーがとれない…
はじめから javascript のソース整形がはいってるエディタってないんでしょうか…
ほんの200行ぐらいのソースなのに {} の対応ができてないみたいで
Uncaught SyntaxError: Unexpected token }
で1時間以上はまってる…
新しい言語独学するのってほんと大変ですね…
心おれそうです まあ長く書いてしまったが、ようは
for文を使うか、JavaScriptの配列に変換するのかの
どちらかってことだな。
自力でやるのならね。
そこで登場するのがjQuery。jQueryを使うと
このような面倒くさい問題も解决してくれる
jQueryを使えばループ自体が必要なくなることも多いのだが、
ループを使う場合であっても以下のように簡単に記述することができる
もちろんどのブラウザでも動く
$('.score').each(function() {
// this = scoreの要素
}) cdnのssl証明書期限切れで動かなくなるけどなw ↑知らない人に説明しておくと、jQuery自体に問題があったのではなく、
CDNのトラブルでSSLの証明書が切れてしまって一時的に使用できなくなった
あくまでjQueryが利用していたCDNであって、ローカルにダウンロードして
使っていたり別のCDNを使っていたのであれば関係ない
問題はすでに解决している >>670
そのエラーが必ずしも}の数が原因とも限らないが、
もしそうなら}を適当に増やしたり減らしたりして
改めてエラーの位置を確認するとだいぶ役に立つと思うよ >>670
> はじめから javascript のソース整形がはいってるエディタってないんでしょうか…
つ VSCode >>675
わー ありがとうございます
これすっごい便利ですね
色もついてるし
自動整形してみたらやっぱり } の数がちがってたみたいで1分で原因わかりました
ほんとに感謝です
大学ではUNIX艦橋だったのでemacsって色がつくエディタはいってたけど
Windowsだとメモ帳しかなくて途中に if 文とか追加したらインデントぐちゃぐちゃして困ってました
>>669
朝ちょうど入れ違いで回答いただけてたんですね
for-in がまずかったんですね
ループインデックスでかきなおしてみます
丁寧な回答ありがとうございます >>676
便利だろう。俺はVSCodeが好きだがこれ系のエディタは他にもAtom、Sublime、Bracketsとかもあるぞ。書いとかないと他のエディタの信者に怒られるので念のため おかげさまでだいぶすすみました
教えてくれた方ありがとうございました
あとVSCroeってPHPは整形できないんですね
キーワードハイライトはついてたんですけど
ちょっと残念
>>677さんのほかのもちょっとためしてみますね >>679
それ系のエディタ共通の話だけど基本的に個々の機能は拡張機能で追加する形態だからね。jsとかhtmlとかが特例なのよ。 "use strict";
{
let aaa = null;
let foo = (bar) => {
aaa = "bbb";
}
}
↑見たいな構造のコードを見かけたんですが、
この一番外側の中括弧ってどういう意味やメリットがあるんでしょうか? let使ってるからその変数のスコープを限定しているんだろう。
このコード自体では意味がないけどな。 >>682
なるほど、ありがとうございました
中括弧と言えばオブジェクトだみたいな頭してましたが、
そう言えばもうブロックスコープが使えるんでしたね >>683
安価付け忘れた
ありがとうございました ウェブサイト上のボタンを押すと、関数Hogeを実行し
hogeの中で計算を実行して、結果をサーバー(Node.js)にPOSTしたいです。
今は、このような関数を用意して、POSTしようと試行錯誤しているのですが、合ってますかね?
hogehogeはこの関数実行前に(ほかの関数で)計算済みです。
https://pastebin.com/sHDJ5zPs
また、このPOSTを下記のようにNode.jsで受け取ろうとしたところ、
TypeError: Cannot read property 'input' of undefined
とエラーを吐いてしまいました。req.body.form.input.valueでは無いのでしょうか
'router.post('/', function(req, res, next) {
var formula = req.body.form.input.value;
console.log(formula);
res.end();
});' 正直言って1つ2つではなく何もかも違う
むしろどうしてそれでうまくいくと考えたのか?
そもそもそれで何がしたいのかが不明
もう一度最初からサンプルやドキュメントちゃんと見てごらん
適当に目を瞑ってキーボード叩いただけじゃそりゃ動かないよ >>687
本当ですか…
javascript自体触ったことないので完全に手探りなので…
考えとしては、nodejs側でPOSTを受け取りたいので、クライアントサイドのjsで変数をPOSTしてあげれば良いのかなっていう素人の考えです
HTML(ejs)の中で入力内容をPOSTしているソースコードはよくあるのですが、jsで変数をPOSTするソースコードは見つからず、、
根本的に考え方が間違っているのでしょうか?
Node.jsを勉強すればいいのか、はたまたJavaScriptを、Expressを、、と色々ありすぎてよく分からない状況ですね >>688
間違ってないとは思うけどjsでformを生成する理由はある?
最初からhtmlに記述しといてvalueを弄くれば良くないか
純粋にjsから送るならXMLHttpRequestの方が向いてる気がする
node側はbodyParserが何してるのか分からんから答えられない
とりあえずconsole.log(req.body);したものを貼ってくれ
あとExpressなら最初にそう書いて 「Node.js超入門、掌田津耶乃、2017」を読めば?
実は、Node.js だけでは面倒くさいから、それだけでは作らない。
Express + Express Generator フレームワークを使う
Node.jsは、Ruby で、Sinatra を、full scratch で書くのと同じ。
Express + Express Generatorが、Rails と同じ
だから先に、無料のRails チュートリアルをやれば、フレームワークが理解しやすい
YouTube のTraversy Media で、Express, Rails とか色々やってる またこいつか
ほんとルビウンコの周り廻ってるハエにはろくなのがいない JavaScript は、Ruby よりもずっと難しいから、
先にRuby やって、無料のRails チュートリアルをやれば、
MVC, web アプリの作り方がわかる
しかも、Rails以降の、多くの言語のフレームワークの基礎になっているから、
Railsを勉強していると、どの言語でも作れるようになる
他の言語でも、フレームワークを、Railsと同じように作っているから、応用できる
DB, Linux コマンド、環境構築も学べる
HTML, CSS, JavaScript, SASS,
Bootstrap などのCSS フレームワークも学べる
しかも、Rails以降の、どの言語のフレームワークにも通用する。
例えば、Node.js + Express Generator とか はいウソです。RailsやってもReactやAngularはわかりません。
所詮Railsはサーバーサイド用のフレームワークですからね >>689
電卓アプリを作りたいので、HTMLには数字や記号のボタンを押す処理だけ書いて(ボタンを押すとJSの変数に代入などな処理を行う)、
実際の数字の繰り上がり処理や足し算とかの処理はjavascript側で処理してるんですよね
単純にゴチャゴチャしてるHTMLファイルが嫌いなだけなんですけど…
理想としては、=を押した際に、計算する関数を呼んで、計算し終わったらそのままnode.jsに変数を渡したいです
こういう場合はXMLhttpRequestの方が良いんですかね?(全く存在を知りませんでした)
Express使ってます https://pastebin.com/7jEkzyww
console.log(req.body)の出力はこんな感じです
Nullオブジェクト?なので、そもそもうまくPOST出来てなさそうです 'router.post('/', function(req, res, next) {
var formula = req.body.form.input.value;
console.log(formula);
res.end();
});'
前後を' ' で囲わないし、
'/' ではなく、'/post'
>req.body.form.input.value;
req.body['message']
<form method="post" action="/hello/post">
<input type="text" name="message">
<input type="submit" value="送信">
</form>
この場合、ファイル名は、hello.js YouTube のTraversy Media の動画を見てみ。
Express, Rails とか色々やってる
先にRuby やって、無料のRails チュートリアルをやっていないと、
Node.js + Express Generator の仕組みがわからないと思う >>695
上にも書いたけど多分bodyParser.text()が機能してない(てかtextで良いんだよね?)
ソースはrequire部分から貼ってもらった方が良いかも >>694
電卓アプリか
それなら、Electron (Node.js + Chromium) の方が良さそう。
VSCode も、Electron製
Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう
野口 将人・倉見 洋輔、2017 Express Generator なら、自動的に以下が書かれている。
var bodyParser = require('body-parser');
bodyParser.json()
もし、JSON なら、HTML のContent-Type ヘッダに、
text/json か application/json という MIME タイプも必要
YouTube のTraversy Media の動画を見てみ。
Express, Rails とか色々やってる
Node.js & Express From Scratch [Part 1] - Intro & Environment
https://youtu.be/k_0ZzvHbNBQ?list=PLillGF-RfqbYRpji8t4SxUkMxfowG4Kqp
これでわからないなら、先にRuby やって、無料のRails チュートリアルから勉強する >>698
ありがとうございます
githubのExample真似ただけなので、json形式でした
XMLhttpRequestでjson形式に整形したデータを送れば良いのですかね?
それとも、text形式にしたほうが良いんですかね?
https://pastebin.com/RNfTFFUE
>>699
今回はWEBアプリケーションの練習なので、デスクトップアプリはまたの機会にしてみたいです。 XMLhttpRequestでjson形式に整形したデータを送る感じで動きました
XMLhttpRequestで送るときはxhr.open("POST", "/hoge")
routes/hoge.jsで受け取るときは
router.post('/', function())
ってややこしいですね…
このせいで2時間ほど頭悩ましてました… >>702
HTML内でのjavascriptをnodejsみたく扱えるライブラリ等を使わないなら
全然別物としてそれぞれ勉強したほうが良い 逆逆、
これからは統一するなら送信はfetch、受取はSW >>704
SuperAgent、Axios
ブラウザネイティブのFetchは、大人の事情で
すでに使い方が複雑になってしまったので
おすすめできない >>706
それはhttpクライアントライブラリです。
HTML内でのjavascriptをnodejsみたく扱えるライブラリとやらを紹介してください。あるんでしょ? JavaScriptのコメントで/**/って使わないと聞いたのですか、皆さんは気にしてますか? 普通に使うが。
例えばAirbnbのスタイルガイドでは複数行コメントは//使うな/**/使えと書いてある。 AndroidのWebViewで利用したいのですが、Googleなどの検索サイトを読み込んだ後に、JavascriptでKeyboardが出るのを無効にしたいのですが、どのような方法があるでしょうか?
キーボードの発火点である検索ボックスなどのInput要素を特定して、addEventListenerでフォーカスを登録し、
フォーカスイベント直後にblurを呼び出しフォーカスを外すなどの方法を考えたのですが,Input要素の取得がそもそもうまくいきませんでした。もっと単純な方法で、サイト全体でキーボードを無効にする方法などないでしょうか? ブラウザの開発者ツールを開いても
解析できないようにしたいのですがどうしたら良いのですか?
avgleというサイトみたいに え? avgleに限らず解析できないサイトなんてないだろ ブラウザのツールバーからもいけるけど、
Chromeだと
ソースコードを見る・・・CTRL+U
デベロッパーツール・・・CTRL+SHIFT+I MDNのRegExp.prototype.testに以下が追加されていることに今気づいた。
> exec() と同様に(またはこれとコンビで)、
> test() が同じグローバル正規表現インスタンスで複数回呼び出されると、前回のマッチの先に進むことになります。
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/RegExp/test
対応してくれた人がいたのならありがとう。 >>716,715
あ、そうです。難読化です。
デバッガが以下でとまってしまいません?
(function anonymous(
) {
debugger
}) >>719
いや、止まるかけど解析はできるだろって話。
debuggerステートメントを入れてれば、そこでデバッグできるように止まるが
止まるのが嫌なら、デバッガのActivate break pointsを無効にすればいいし、
デバッガで止まっていても、ソースコード見れるし
いくらでもやりたい放題 google map apiで地図を作ってるんですが、国内だけでマーカーを27000個ほど配置する必要があるため、クラスタリングしたいと考えてますが、
どのクラスタにどのマーカーを含めるかを、マーカー同士の距離から自動的に計算してクラスター化してくれるライブラリはないでしょうか? ブラウザゲームで特定のタグが出現したら音がなるような仕組みを作りたいんですけど
chrome拡張のjavascriptでサイト外のサウンドをならすことってできますか? >>724
.mp3のとこにURLをうめこんだら音でました
<audio>タグとかをうめこんでうんたらとかが必要かと思ってたらたった3行でよかったんですね
ありがとうございました 1行でいいよ
a = new Audio()
a.src = url
a.play()
は
new Audio(url).play()
と書けるから varとfunction文を使わないjavascriptの入門書ってないですか? >>728
classもfunctionは使わないし、
連想配列を使ったオブジェクトへの
メソッド定義にも必要ない codeacademyがes6みたいなのでこれ使ってみます functionはthisとかargumentsが使えるし排除する積極的理由が思い浮かばないんだが thisはともかくargumentsはrest parametersでよくね?待ち望んだ本物の配列だぞ arguments.calleeが重要
function.selfメタプロパティにする案もあるが arguments.calleeは名前を付ければ不要
Strict Modeで使えない機能は要らん 名前を付けないといけないと言うことが問題だろう
〜すれば不要だなんて何事にも言えることだし
つうかES2015の著者も提案してることからも重要性は分かるだろう
function.sentのようにfunction.meとかで入るべきだよ > 名前を付けないといけないと言うことが問題だろう
何が問題? >>738
無名関数に再起をするためだけに外にも分かる名前を付けないといけないのは問題だろう
そもそも名前を付けるに値しない、付けなくても良いような関数であっても
無理やり固有の名前を付けないといけないということなんだからさ
仮に名前が最初から付いていたとしても、super()のように関係性による参照は重要 自分を呼び出したりプロパティ生やしたり
複雑なことするならちゃんと名前を付けるべきだと思うの >>737
> function.sentのようにfunction.meとかで入るべきだよ
arguments.callee 問題を回避する為には this 値束縛の例外機構が必要で関数呼び出しの処理に手を入れる必要がある
これは「arguments.callee 問題を知っている人にとっては」直観的な動作ではなく、分かりづらい
>>740
> 無名関数に再起をするためだけに外にも分かる名前を付けないといけないのは問題だろう
名前付き関数式はスコープが外に漏れないよ
> そもそも名前を付けるに値しない、付けなくても良いような関数であっても
それは発想力の問題であって、名前を付ける方がリーダブルコード的には正しいと思う
特に再帰関数は可読性を下げるので、名前はあった方が分かりやすい
jQueryに代表される「とにかく無名関数式を使え」な偏重的傾向は可読性とは正反対のポリシーでしかないので、好ましくないと個人的には思ってる
彼らの主張は「ショートコーディング最高!名前を付けるのは悪!」という感じでどうにも共感できない >>741
でも自分自身を呼び出すことが目的であって、例えば関数meを呼び出すことが目的じゃないからね
関数名meをmyに変えたら変更しないといけなくなってしまうし
superの例と同じくそこは抽象的な物があったほうがいいんじゃない?
>>742
普通の名前付き関数式は確かにもれないが、
アロー関数とかも「fn(()=>{})」の代わりに「let cb;fn(cb=()=>{})」とかにしろってことでしょ?
あと変数はできるだけ名前を短くして寿命(スコープ)を短くするのが良いと個人的には思うよ
ショートコーディング最高というのではなくてね、
昔のとある言語界のようにスコープが広くて説明口調の何十文字もある関数名が好まれていたものの対局としてね
汎用的な関数とか、関数の引数のような使われる範囲の広い名前は比較的きっちり決めるべきだけどね
そうでないものは、それこそ一旦途中計算をとっておくようなものはtempか、
スコープ狭くてそこの2行で使わないようなものならtでも十分 >>743
結局、function.me で arguments.callee 問題をどう解決するの?
> アロー関数とかも「fn(()=>{})」の代わりに「let cb;fn(cb=()=>{})」とかにしろってことでしょ?
そんなことはいっていない
自分が主張しているのは名前付き関数式
> あと変数はできるだけ名前を短くして寿命(スコープ)を短くするのが良いと個人的には思うよ
名前を短くしても寿命は短くならない
同様に名前を無くすことで寿命が短くなることもない
それはただの論理のすり替え > アロー関数とかも「fn(()=>{})」の代わりに「let cb;fn(cb=()=>{})」とかにしろってことでしょ?
そもそも、これは再帰関数ではなく、コールバック関数 ここで言う arguments.callee 問題 ってどういうもの? >>746
>>742で触れたし、ぐぐればすぐに出てくると思うんだけど…
arguments.callee() における this 値が何かを考えれば、すぐわかる
彼は function.me() にも同様の問題がある事に気が付いてなかったような気がしてきた(実際、>742に反論してこなかったし) >>744-747
だから例えばそうやって他に渡された関数がその先で自己呼び出しするためには
定義した場所で名前を付けて置かないといけないでしょ?
()で囲んだ即時関数にしろ、コールバックにしろ、式中でアロー関数を定義する場合は
宣言を別にしないといけないし不格好になるよという例だよ
それで結局、君はアロー関数中の使用なら必要性を認めるし問題は無いということでOK?
君がやけに拘るthis値もアロー関数は定義された場所のthis値で固定されるんだから
そもそもどのように参照がされようがthis値が変わったりはしないのは自明で
そこに何も新しいことや考えないといけないことは生まれない
そもそもアローでない関数に関してもメタプロパティなんだから仕様でどうとでもできる話
function.me()と読んだらthisがfunctionになるわけでもあるまいし
まあ自然なのはfunction.meというキーワードが自己関数を素朴に参照することだろう
つまりme()のようにfunction.me()とできればいいし、
me.call()のようにfunction.me.call()とできればいい >>749
> だから例えばそうやって他に渡された関数がその先で自己呼び出しするためには
だから、名前付き関数式なら自己呼び出しできると説明したよね?
繰り返すけど、
- 名前を短くしても寿命は短くならない
- 同様に名前を無くすことで寿命が短くなることもない
- 再帰関数は可読性を下げるので、名前はあった方が分かりやすい
> それで結局、君はアロー関数中の使用なら必要性を認めるし問題は無いということでOK?
アロー関数には名前を付ける機構があって良いとは思うけど、arguments.callee は必要性を感じない
> つまりme()のようにfunction.me()とできればいいし、
それが直観的でない事は>>742で説明した
拡張するなら、@callee() とかの方がまだわかりやすい
ただし、自己呼び出しなら「名前を付ける機構さえあればいい」
スコープを無駄に拡張する必要はない >>744で「自分が主張しているのは名前付き関数式」といってるのに、彼はアロー関数の問題に執拗にこだわるから論点が曖昧になってる
アロー関数の問題は「名前を付ける機構がないこと」
解決するには、「アロー関数に名前を付ける機構を作ってくれればいい」
関数式は現状維持で何の問題もない、以上 console.log((n => {let fact = n => n ? n * fact(n-1) : 1; return fact(n);})(5)); >>751
非アロー関数にこだわってるのは君の方でしょ
というか君の言い方を真似して言うと、
ただアロー関数の問題に気が付いて無かっただけでしょ
というかfunction.meが直感的で無いっていうのは
this周りの話だと思うけど、そのことについてはsuperを例に挙げたじゃん
直感的で無いと感じるのはただ単に君がメタプロパティに馴染みがないからでしょ
super.method()、new.target()としたときthisについて、
またはfunction.sentが採用されればそれについて知っていれば何も違和感なんて生じようがないよ
それにメタプロパティの良いところは、新しい予約語も記号も消化せずに済むところなんだから
@とかJSの残り少ない貴重な資源でしょ こっちでもアロー関数ネタやってんのかよw
向こうでも同じことを言ったがな
アロー関数は、functionの代替、短い書き方じゃねぇ。
関数を値のように扱うためのものだ。
基本は n => func(n) の形、=> の左の部分は他の書き方でもいいけど
=> の右側に { retun hoge } みたいに {} や returnを使おうと思ったら
それはアンチパターンだ
そんな複雑な処理をするためのものじゃねぇ
だから再起に使おうとか思うんじゃねーよw 妄想納得くん向こうでミジメに敗退してるじゃんw
ソースは?w アロー関数のほうが自然だから基本的にはアロー関数を使いたいね 関数は昔から値として扱えるよね
アローは this の束縛が特徴だと思ってるが 誤解されるから訂正するよ
× 値として使う
○ 引数として使う >>753
そもそもの発端は>>737の「名前を付けないといけないと言うことが問題だろう」に反論したこと
この文脈で名前をつける機構のないアロー関数に言及してると思う方が無理があるでしょ
アロー関数の問題には気が付いていたけど、論点を拡大させすぎると君は都合のいい部分だけ抽出して反論するから、あえて言及しなかったんだよ 732だがまさかこんなに熱い議論になるとは思わなかった
軽い気持ちでargumentsを話題に出してしまって申し訳ない いいってことよ。なんでもおもちゃにするだけの話だしな ブラウザゲームのデータをよんでサーバーに記録するようなのを作りたくて
chrome extension で実装したんですがデベロッパーモードにしないで動かすにはどうすればいいんでしょうか
自分用につくったんですけど知り合いも使いたいみたいで導入ハードルをさげたいんですよね
あとプレーヤーごとにデータをわけて個別にマイページ表示したいので
送信するPOSTのなかにユーザIDなり暗号化したトークンなりをいれたいんですが
どうやって実装するのが簡単でしょうか
配布する chrome extension を共通にしてその中の post の内容を外からの変数でかえることってできるんでしょうか
あるいはプレーヤーごとに ID をうめこんだ extension ファイルを配ったほうがいいのでしょうか >>732
> functionはthisとかargumentsが使えるし排除する積極的理由が思い浮かばないんだが
その通りだと思う
アロー関数だけにしたら、this値束縛でいろいろと弊害が出てくる
- call,apply,bindが使えない
- addEventListenerの第二引数に非関数オブジェクトを指定しても無効 >>763
googleに登録する(審査有り)
ChromeではないChroniumを使う
諦めてデベロッパーモードにする
ユーザーIDかなんかは乱数で作って保存しとけ
既にスレ違いだから気をつけろ 回等ありがとうございます
chrome拡張の話はスレ違いなんですね
気をつけます スレ違いじゃないならききたいんですけど
乱数で作って保存するっていうのはどこに保存すればいいんでしょうか?
識別する文字列を鯖側で乱数作成するにしても
ユーザがアカウント名として入力するでもいいんですが
配布する拡張機能側にうめこむ方法がわかりません
ユーザごとにIDをうめこんだ違うファイルを配るか
拡張機能内に何かしら入力欄を作って入力しないと無理ですよね? >>769
自分で読み直してみて, 何がしたいのかその文章から読み取ってもらえると思う? >>769
普通にストレージはchrome.storage.localとかで提供されてるけど。
エクステンションごとに保存先が独立して用意される。
ちなみにgoogle認証とかで識別したほうが楽じゃない。
乱数だとエクステンションをアンインストールしたタイミングでヒモ付が消えることになる >>770
拡張機能をインストールしてブラゲーページをみたとき
特定の画面でDOMを抜き出す + ユーザ識別トークンを付与してサーバー送信
サーバー(PSP CGI)は受け取ったデータをユーザ識別トークンごとに保存
表示ページではユーザ全体の集計結果を公開してログインするとユーザごとの個別データが見られる
というイメージなんですけど
拡張機能側で毎回同じ識別トークンを知るor個別に作るにはどうしたらいいのかなって
PHPもJSも4月から覚えたばかりでウェブアプリつくるの自体がはじめてなので
認識が間違ってたらごめんなさい
>>771
わー ありがとうございます!
localStrageっていうの localStrage.put() get() だけで使えたので簡単そう
初回アクセス時にクライアント側で乱数を生成してlocalStrageに保存して
localStrageから取り出してつけるだけでいけそうです
これ実態はメモリじゃなくてファイルになってるんでしょうか
PCの電源落としたりセッションやIPがかわっても毎回取り出せるのかな
有効期限のないクッキーみたいなもの?
google認証軽くしらべてみたんですけど理解できなかったので自分には難しそうです
サンプルコードいくつかみたけどどれも何かしら入力文字列があったので
ユーザは何も入力しなくてもサーバー側で固有のトークンを取り出せるんでしょうか
とりあえずlocalStrage使う方向ですすめてみます
本当にありがとうございました! >>772
oauthって、聞いたことない?
gmailは大体の人が使ってるからパスワード入力を省略できる。 どうにもわからないことがあります
例えばHTMLの中に<a onclick="hoge()">と書いてあるとして
そのhoge関数はどのスクリプトにあるhoge()が呼ばれるんでしょうか?ブラウザでは同時にいくつものjavascriptが走っていると思うんですが
試しにGreasemonkeyでスクリプトfugaを作りそこからHTMLの適当な要素にonclick="hoge()"を追記して発火させてみると
ちゃんとGreasemonkey下のfugaスクリプト内のhoge()が呼ばれますが
ブラウザはどうしてhoge関数がGreasemonkey下のfugaスクリプト内にあると分かるんでしょうか?
動いている全てのスクリプトの関数名を走査しているんでしょうか
だとしたらhoge()とたまたま同名の関数が他のスクリプトにあったらどっちにいってしまうのか
確実にfuga内のhoge関数を呼ぶようにonclickに指定する方法はないのか
が分かりません… >>774
何がわかんないのかよくわからないな。
同時に幾つものjsが走っているというのはあくまでタブ単位の話
複数のタブにまたがってグローバルスコープは共有しないから大丈夫
でも同名の関数が衝突することはあるから確かに気をついないとダメだね。 >>775
レスありがとうございます
他のタブの関数が呼ばれてしまうということは心配していないのですが
同じ1つのタブの中でもサイト作者が作ったJS、ブラウザアドオンのJS、GreasemonkeyのJS、と複数走っていますよね?
そこで同名の関数があったらどうなるんでしょう?
また確実に自分のスクリプトの中の関数を呼ぶ方法があれば知りたいです
またmin()とかmax()みたいにごく短くてありふれた名前の下位関数を作ることはよくあると思うんですが
関数名がブラウザには全部一緒くたに記憶されているんだとしたらそれすらも危険という気がしてきました
自作スクリプト全体を(function(){…})()で包んだとしても、先程の例のhoge()が呼べてしまうので
やはりmin()やmax()も宣言すれば全体から見えてしまう(上書きしている?)のでしょうか? Greasemonkeyは使ったことないのでよく分からないけど同一スコープで同名の関数が複数定義された場合後勝ちになるよ
あと現在のスコープに関数定義が見つからない場合1つ外側のスコープを探しに行くよ >>776
Browserアドオン。エクステンションに関しては別の処理系で動いているから名前衝突は起こさない。ただしDomだけは共有してる。 >>777-778
ありがとうございます
そこで最初の疑問になるのですが
Greasemonkeyやブラウザアドオンのjsからdocumentの要素にonclick="hoge()"等と書き加えた場合、
いざページを見ていてユーザーがその要素をクリックした時は、ブラウザからはHTML(DOM)だけを見ているのであれば
hoge()がどこのスクリプトから書き加えられたか分からない(どのスコープのその関数を呼べばいいか分からない)と思うのです。
その時でもなぜちゃんとhoge()が呼ばれるのかしっくりきません
また確実に自分のスクリプトを呼ばせる方法が知りたいです >>779
その要素のaddEventListenerを呼び出して該当関数を渡せばいい >>779
どのスクリプトファイルかを判断する必要はない
グローバルスコープは共有されるからだ >>779
その書き方だとグローバル変数hogeかグローバルスコープに定義されているhoge関数が実行されるよ
どのファイルかを気にしているけれどJavaScriptはファイル単位でスコープが分かれるわけではないよ
ファイルAでグローバルスコープにhoge関数を定義してファイルBでbuttonのonclick属性にhogeを追加するとして、どちらのファイルも読み込まれた後にbuttonをクリックすればhogeは実行されるはずだよ ありがとうございます
まとめて書きます
ファイルA.jsとファイルB.jsの作者がまったく別の人でお互いの内容を知らず、
まず順番が来たファイルAがbuttonのonclickにhoge関数を追加してhoge関数の本体も定義、
次に順番が来たファイルBがimgのonclickに(たまたま同名の)hoge関数を追加してhoge関数の本体も定義した(内容は全くの別物)という場合、
buttonやimgをクリックした時にファイルAのhoge本体とファイルBのhoge本体のどちらが呼ばれるのか?という問題が分からないのです
関数名はグローバルスコープで全て共有されるとしたら後で定義したほうが勝ちになるというのは分かるのですが
だとするとスクリプト全体を(function(){…})()で包むということの意味は何になるのでしょうか?
包んだ変数名や関数名をグローバルスコープから隠すことだと思っていたのですが ↑の補記
話を具体的にするために言い換えますと、
仮にファイルAはウェブサイト側のjs、ファイルBはブラウザアドオンのjsだとします
ブラウザアドオン側のjsの作者は、ウェブサイト側のjsで作って使っている関数名を全て調べて知っておく(そして衝突を避ける)
なんてことをするのは現実的ではないと思うのですが
どうやって衝突を避けるのでしょう? という疑問なのです
ファイルAのjs内で呼び合っている関数ならスコープで保護されるのは分かるのですが
HTML(DOM)のonclick等に書いてしまった場合スコープ情報が抜け落ちるような気がするのです
細かい話ですが、要素のaddEventListenerに登録する場合も、そのまま関数名だけならスコープ情報を登録してくれそうな気がしますが
関数に引数を渡したくてaddEventListener("click","function(){hoge(a,b,c)}",false)のように登録してしまった場合はやはりスコープ情報が抜け落ちそうな気がするのですが
そんなことはないのでしょうか? どこをどう話せば良いか分からんし、スコープ情報ってなんや?っ感じだけど
前提として衝突を100%回避するのは無理
是非はともかくjQueryやlodashなんかは1文字に全てを押し込めて衝突を避けてるけど
サイト側が$を使っちゃうとそれまでの話 window.jQuery = window.$ = jQuery;
jQueryのソースコードでは、windowの、jQuery, $ に、
jQueryオブジェクトを代入してる
この2つだけが、グローバル変数 >>774
イベントハンドラーを、<a onclick="hoge()"> のように、HTML に直接書くのは、ダメ!
jQuery の、on とかで、JavaScript から設定する
モジュール管理は、Node.js が使っている、CommonJS とか。
ES6(2015) で、import文ができた
JavaScript, jQuery の質問は、
この板よりも、web制作管理板へ書き込んだ方が良い
そちらの方が、人が多い >>787,788の言う通り完全に衝突を避けるのは不可能だけど実際上ほとんど問題にならないよ
グローバルスコープで発生する名前の衝突を避けるには不要なオブジェクトをグローバルスコープに曝さなければいいんだよ
ライブラリではそのために特定の名前に全部詰め込んでそれだけをグローバルスコープに晒したりしているよ
あとはwindow.foo.barみたいに独自のネームスペースを切り出してその中だけを使うといったやり方もあるよ
javaが分かるならパッケージ名みたいなものだと言えば伝わるかな
(function(){})()の意味は無名関数の即時実行だよ
スコープの話と絡めると良くあるのは(function(global){var foo; ... global.bar=foo;})(window)みたいな使い方だよ
この例だとグローバルスコープにbarと言う名前でfooというオブジェクトを曝してるよ
あとはえーと、addEventListenerで登録するのは関数の名前じゃなくてFunctionオブジェクトそのものだよ
無名関数も登録できるよね
リスナーが実行されるときに名前で関数を探しているわけではないんだよ >>787
> 是非はともかくjQueryやlodashなんかは1文字に全てを押し込めて衝突を避けてるけど
> サイト側が$を使っちゃうとそれまでの話
jQueryもlodashも$や_をサイト側でも使っても問題ない方法を用意してるよ
jQuery.noConflict()
https://api.jquery.com/jquery.noconflict/
_.noConflict()
https://lodash.com/docs/4.17.10#noConflict 大事なことを言い忘れたよ
functionで囲うのは関数定義がスコープを生成するからだよ >>786
さっきも説明したと思うけど
>仮にファイルAはウェブサイト側のjs、ファイルBはブラウザアドオンのjsだとします
この場合は処理系が分離してるから。
関数名が衝突するどころかブラウザのアドオンからウェブサイト側のjs内の関数呼び出しはできない。
DOMしか共有してない。 何度も言うけどDOMしか共有してないから あと、質問するくらいだったら自分で検証環境つくって動かしてみたほうが早い。
2,3hで終わる話 >>793
DOM共有してるならなんとかなるな
mousemoveとかで呼び出したい関数をセットすればいい ブラウザの拡張とかの場合は特殊ケースだからあんまり深く考えてもしょうがない
Greasemonkeyはセキュリティのために何度も仕様変更してるし >>786
だから、関数スコープでぐぐれ
関数で括ったら、スコープが漏れない
グローバル変数は共有する必要がなければ使わないものだ javascriptからtwitterにツイートするってどうすればできますか? JSだけでTLを取得するのはあったんですが投稿するのが他の言語しかみつからなくて… >>798
出来ると思うか?
悪意のWebサイト開設者が裏でJS回して「○○小学校に爆弾設置する」みたいな犯罪予告ツイートさせたらサイト訪問した奴の人生終わるぞ
だからTwitter Developer DocumentationのJSAPIにも載ってないし出来ない 他の言語がツイート出来るのは、Twitter開発者として公式サイトから認定されて、ツール越しに発言した内容を責任持ちますという取り決めがされてるから可能なだけ。
だからJS単体で裏で勝手にツイートさせる事は不可能 rest api使えば出来るよ。
consumer secret晒す必要あるけど。
こっそり訪問者にツイートさせたところがconsumer secretに紐付くお前が童貞されて罰を受けるだけ >>801,802,803
特定のページをみはって特定の情報(DOM)がでたらツイートするBOTアカウントを作りたくて
訪問した人のアカウントで勝手にツイートするわけじゃないです
動作自体はローカルで動かすのでツイッターアカウントとパスワードwpソースにうめこんでも大丈夫なはず
他の言語でブラウザを経由せずにwgetみたいなことをやってもいいんですけど
ログイン認証があるのでログイン後に表示されるHTMLを取得する方法がわからないので
ブックマークレットだったりchrome拡張にできるjsが便利かなと
>>803
rest api で検索してみら node.js や npm のインストールがいるっていわれるんですけど
unix サーバー環境をもってないです… node要らないよ。
nodeでやるにしてもunixサーバーなんか要らないよ。 >>804
もうちょっと具体的な機能の説明を頼む。
なんだかわからんけどパスワード類埋め込みだと悪用されるで。tweet自体はサーバサイドってやったほうが良い。 BOTならサーバサイド, 常駐アプリのイメージ
JavaScriptならNodeが良いと思うけどね(Nodeすら導入出来ないなら諦めろ) nodeは怖くないよ。
npmくらいは使ってんだろ。普段から >>806
具体的な内容まではいえないですけど情報が変化するサイトがあって
その情報を分析して特定の反応がきたときにツイートするBOTを作りたいんです
FXや株価のシグナルをつぶやくみたいなイメージに近いかもです
>>808
ほんとはcronか何かで定期的にそのサイトにHTTPアクセスにいくサーバーサイドアプリが一番なんですけど
その情報を表示するのにログインが必要なんですよね
で自分がログインした後のページのHTMLを取得する方法がわからないので
ログインまではブラウザで手動でやって
あとはjsで一定時間ごとにreloadかけてgetElementByClassとかで情報を抜き出して
分析してツイートするみたいなことをしたいのです すいません まだわかりにくかったと思うので補足です
その情報を表示するサイトはぜんぜん他人のサイトでその上でJSを動かすって意味ではなくて
JSを動かすのは自分のブラウザ上だけで公開するわけでもないので
BOTのアカウント情報をうめこんでも大丈夫だと思います
JSから自分のつくったBOTアカウントにツイートさせることができればやりたいことはできそうなんです… >>812
ありがとうございます
確かにこれならやりたいことができそうなんですが
導入にコマンドライン操作がいっぱい必要みたいですね
ためしに最初の1行をプロンプトにうってみたけど curl がないっていわれた…
コマンドラインになれてないので exe クリックするか
ブラウザ上で完結する作業以外は自分にはまだ難しそうです…
せっかく教えていただいたのにすいません 分からんなら勉強しろよ
はっきり言うがお前のやりたいことはTwitterの公式APIドキュメント読めば簡単に実現出来る
自分で調べる気のない奴は向いてないからやめちまえ 確かにそのとおりなんですが
ツイッターもJSもそこそこ有名だから
JSからツイートするぐらいの関数なら誰かが作ってないかなと思って質問してみましたが意外といないものなんですね
時間はかかりそうですが自分でプロトコルから勉強して作ってみます
お答えいただいたかたがたありがとうございました
レベルの低い質問をしてしまって失礼しました このスレに知ってる奴がいないだけで、ないはずはないので探してみるか他できくといいんじゃね
つーかツイートするだけでAPIの仕様まで理解しなきゃいけないとか欠陥言語もいいとこ
何のためのブラックボックス化だよ 今どきコードの断片をブログで共有って時代じゃないから。npm にいくらでもライブラリはある。でもnode使いたくないんだよね。
そもそもchrome extension作ろうと思ったら
yoとかである程度コードジェネレートしないとどうでもいい所で詰まるよ。
まぁいいけどさ。 「ツイートするにはこれ使ってね」とTwitter自身が言ってるWebAPIを知らずに何故ツイート出来ると思えるのか?
WebAPIの仕様を知らないといけないことが何故言語の欠陥になるのか?
>>816はひょっとしてWebAPIというものをご存じないのではないか? メール送るのにSMTP
HTTPリクエストするのにHttpヘッダを理解しろ
っていってるのと同じことじゃねーの? >>820
メールを自動化するなら少しは理解しとかなきゃダメだろ というか様々な用途で利用される標準化されたプロトコルとTwitter一社のWebAPIを比較することのバカバカしさをだな
あとは>>817と同じ ブラウザの自動操作・マクロなら、iMacros, Selenium WebDriver
Ruby で、Mechanize, Selenium WebDriver で自動操作できる。
大学や図書館にもログインできる
パスワードを入れて、ボタンを押す。
element.send_key "パスワード"
driver.find_element(:css, 'ボタン').click
Nokogiri で、スクレイピングもできる。
ほとんど、jQuery と同じ
公開されているAPI を使わないなら、webページを自分で解析しないといけない。
どのタグに、どういう情報があるのか、分析するのが大変
API を使わずに、5ch 専用ブラウザを作れないのも、同じ理由。
自分で5ch の仕様を解析するのが、面倒だから >>817
npmっていうコマンドがないっていわれます
>>818
使いたくないというかjs自体4月から独学で勉強はじめたばっかりで…
上位のフレームワーク的なものまで手だせる段階じゃなくて…
node.jsっていうのもよくきくので以前1回調べたんですけど
サーバー側で動作するjavascriptでスケーラビリティが必要な場合に
Apache+CGIのかわりにつかう速いウェブサーバー?って認識だったので関係ないと思ってましたが
普通にクライアントサイドjavascriptかくのにも必要な技術なんでしょうか
今回たまたま拡張機能使うのが楽そうだと思ってjsにしただけでjsはほとんどかかないので
知らなくてすむ技術なんだったらそれにこしたことはないんですが
話きいてるとそれを覚えてそのなかのツイッターライブラリ探したほうが速い感じなんですね
あのあといろいろ検索してみたんですが
javaやphpならトークン4つセットしたあとツイート内容引数1つうけとるだけでつぶやける関数があって
5,6行でツイートできるサンプルが結構でてくるのに…
javascriptだけは複雑な数十行のサンプルしかでてこない…
レン鯖かりてCGIにポストしてCGI側でツイートするほうがはやいのかな…
>>823
iMacrosって調べてみたら
>条件分岐などの操作ができない。
ってかいてあったんですけど単に操作記録してループ再生できるだけでは?
プログラミングの知識が必要ないってあるんですけど
HTMLを読んだりができないとやりたいことができない気がします
というかwebの解析自体はできててツイートしたい文字までは用意できてるんですよね… npm というコマンド名から、コマンドの実行ファイルを探す手順は、
OS のユーザー環境変数 Path に、
実行ファイルのあるディレクトリを追加していないと、探せない
漏れのPC で、コマンドプロンプトで入力すると、
>where node
C:\Program Files\nodejs\node.exe
>where npm
C:\Program Files\nodejs\npm
C:\Program Files\nodejs\npm.cmd
JavaScript は、Ruby よりもずっと難しいから、
先にRuby やって、無料のRails チュートリアルをやれば、
MVC, web アプリの作り方がわかる
例えば、Groovy のGrails, Node.js + Express Generator などが、Rails と同じ >823 に書いた通り
ブラウザの自動操作は、Ruby で、Mechanize, Selenium WebDriver
スクレイピングは、Nokogiri。
これは、jQuery と同じ Ruby で、Selenium WebDriver なら、こういう感じ
webページから、内容を抜き出して処理してから、
テキストボックスに文字列を入力して、送信ボタンを押す
driver.navigate.to "webページのURL"
element = driver.find_element(:css, '取得したいセレクター')
ここで要素から、内容を抜き出して処理する
element = driver.find_element(:css, 'テキストボックス')
element.send_key "入力したい文字列"
driver.find_element(:css, '送信ボタン').click >>827
インストールしてみました
>>825
npmも勝手にはいってたみたいで
プロンプトにうったら動くようになりました♪
ためしに
> npm search twitter
っていろいろでてきました
とりあえずこのままjsでtwitter APIたたきにいくか
言語ごとかえてCUIでブラウザ操作してログイン後のHTMLよみにいくか
まだきめかねてますがまた明日がんばってみようと思います
リプくれたかたありがとうございました >>824
そう。node.jsはサーバサイドというか、ブラウザ以外の場所でjsを使うために生み出されたけど、ライブラリ共有の仕組みが便利でブラウザで使うと便利なライブラリの共有にも使われてる。くらいの理解で。
ドットインストールとかで勉強してみるのはどうかな?いずれ使う日はくる ●●●●ケネディ大統領が暗殺された●唯一の理●由は、イスラエルの核保有に反対した為である●●●
http://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1226114724/53
この掲示板(万有サロン)に優秀な書き込みを●して、総額●148万円の賞金をゲットしよう!(*^^)v
http://jbbs.livedoor.jp/study/3729/ →リンクが不良なら、検索窓に入れる! あああああ
せっかくコードかけて動作させようとしたのに
アプリから twitter API 叩くための4つのキー取得するのに電話番号認証がいるみたいです…
ブラウザでログインすれば普通にツイートできるし
ツイッターの専用クライアントからは電話番号とかなしで普通にツイートできてるのに…
アプリからツイートするのだけ電話番号いるって…
twitter API 経由せずにツイートしたいってさすがにこのスレできくべき内容じゃないですよね
もうお手上げなのであきらめます スレ違い荒らしの、Rubyクズ野郎、次見かけた時点で報復にお前の大好きなRubyスレをゲロ画像とうんこ画像で埋めてやるわ。いい加減頭来た >>832
BOT対策でしょうかね。ロシアがアメリカの選挙に介入するのにずいぶん利用したらしいから。 >>832
だからheadless chrome使えばと >828
にやり方が書いている
Ruby + Selenium WebDriver で、ブラウザの自動操作 SeleniumはJava製のソフトだが操作には色々な言語のバインディングがある。
Java、C#、Python、Ruby、Perl、PHP、JavaScript
Java以外でよく使われてるのはご想像の通りpythonとjavascript
Seleniumは同一コードで多種のブラウザを操作できるメリットがあるがセットアップはやや面倒。
chromeに絞ってよいならばやはり今はheadless chrome使うのが楽。puppeteerというnpmパッケージ入れるだけ。 twitter 公式API 使えとかうそ教えた奴責任もって最後まで教えてやれよ Ruby でも、OmniAuth Twitter という、gem を使う
OmniAuthを利用して、Twitterログイン機能を作る【初心者向け】
https://qiita.com/To_BB/items/01863aa50d628c069b64 OmniAuth Twitter という、gem を使っているから、
認証も何も、プログラミングしていないだろ
設定ファイルに記述しているだけ どっちにしろAPI keyとAPI secretいるって書いてるじゃん
アプリ認証なしでアカウント名とパスワードだけでツイートしたいって話じゃないのかよ >828
みたいに、
Ruby の、Mechanize, Selenium WebDriver などで、
ブラウザを自動操作すれば?
アカウント名・パスワードを入力して、ツイートボタンを押す なんでJSスレでRubyの回答するんだ?
JSスレできいてんだからJSのコードだしてやればいいだろ
https://qiita.com/ko-he-8/items/1bc26fd6ecdf6a8bf946
これとかどうなん?
ソースぱっと見 username password だけでいけそうだよ
new ActiveXObject( "InternetExplorer.Application" );
とかかかれてるからこれ毎回IE窓起動されんのか? jQuery なら良いけど、素のJS は、あまり慣れていないから、Ruby でスマンな
Selenium WebDriver で、ブラウザの自動操作するために、
漏れは、各社のブラウザドライバーもダウンロードしてるよ
chromedriver.exe
MicrosoftWebDriver.exe - Edge 用 毎回、chrome, Edge が起動される。
chrome には、headless モードもあるから、画面表示なしで操作もできる
ActiveX は、やった事ない。
いつも、VBScript から、ピラフが使っている奴だろ >>845
のソースコードを見たけど、VBScript, JScript などのWSH だろ。
sleep ばっかりで、これは面倒
Selenium WebDriver をすすめる Rubyの話は別スレでやれ。
selenium勧めるのはいいと思うけど、それはjsでも出来る。
お前らがRubyしか使えない事を他人に押し付けるな。 Selenium WebDriverはjavascriptもあんだからjavascriptのコード教えてやればいいじゃん
npmも使ったことない初心者に新しい言語覚えろとか相手にされるわけないだろ ruby使うやつってこんなのばっかり。
禁煙の立て札の前でタバコ吸って注意した人の顔面に煙吹き掛けるようなやつら。 Socket.IO(というよりEngine.IOやwsののperMessageDeflate)の質問です
デフォルト設定ではサーバーからクライアントへ送信するパケットのpermessage-deflateによる圧縮はメッセージ部が1024バイト以上でないと圧縮されないことになっていますが、これは今のPCスペックでも設定を変えない方が良いですか
現状ネットワーク帯域が逼迫しており何らかの対策を考えています
この1024バイト以上でないと圧縮しないというのはEngine.IO 1.6.0で定義されたと思われます
perMessageDeflateに関してはwsライブラリを参照するように書いてあり、wsのドキュメントにパフォーマンスの問題から制限を掛けたということが記載されています
備考
wsに1024バイト以上の制限がかけられたのは2.0.0の2016年12月30日
Engine.IOに1024バイト以上の制限がかけられたのは1.6.0の2015年11月29日 jQuery とか、広告1つでも、30KB もあるのに、
1KB 以下の話なんて、無意味だろw >>854
> 現状ネットワーク帯域が逼迫しており何らかの対策を考えています
別の所に原因がある 854です
ピーク時に2万3000クライアント程が同時接続しててその時にネットワーク帯域が不足するのでどうしたものかと悩んでいました
とりあえず半分の512バイトで圧縮するように設定して負荷検証してみました
実際のパケット自体は100バイト未満が6割、600〜900バイトが3割、1割はそれ以外(MAXは986バイト)
結果としては問題なく捌けているみたいですが、他のサーバーに比べるとCPU使用率が10%ほど高くなるみたいです(元々が20%前後なのでCPU負荷的には問題なさそうです)
メモリに関しては長時間の使用によってパフォーマンスが落ちるとの事なので1週間様子を見て大丈夫そうであればこれで行くことになりそうです
パケットログとサーバーの送信直前(emit直前)の時間の差はツールの問題で1ms単位でしか見れませんが遅延も問題になるほどではありません(最大の遅延で3msほどで済んでいます) 不足するなら送る対象を減らせばいいじゃない
ユーザーをパーティに分けてリーダーにだけ送信して
他のメンバーにはリーダーからP2Pで送らせるとかさ ファイルがダウンロードされたら、自動的にそのファイルをローカルファイルとしてJavaScriptで操作できないでしょうか?
Chromeだけでもよいので。 一応確認したいんだが、
mouseoverとmouseoutの発生順って、規定されてないよね?
○○の場合だけならこの順、てのもないよね? >>862
バブリング、キャプチャリングのことか? >>863
いや違う。書いたとおりmouseoverとmouseoutの発生順だ。
mouseout->mouseoverの順で固定されていればコードが減らせるんだが、
そうだとは誰も書いてないし、以下見る限りやはり駄目っぽいんだが、
誰か知らないかなと思って。
https://stackoverflow.com/questions/282245/what-is-the-event-precedence-in-javascript 正確に言うと、「余分なコードを書かなくて済む」だな。
単純に、固定されていないと、
・mouseout->mouseoverの順で発生した場合
・mouseover->mouseoutの順で発生した場合
の両方を想定して書く必要があるだろ。
どっちかに固定されていれば片方だけで済み、その分コードが少なくなる。
だからプログラミングモデルとしては、固定されていた方がいいんだよ。
例えば、.NETは割と固定されてる。
ただ、上記リンクを見る限り、ブラウザの実装の余地を残す為(というのは後付だろうが)
放置って感じか。 >>865
10年前のstackoverflowは見なくていいから仕様を読もう
https://w3c.github.io/uievents/#events-mouseevent-event-order
10年経ったら君の街でさえもあちこち変わってるだろう?
Webの世界なんてそれとは比べものにならないよ >>866-867
おお、サンクス。
確認したところ、05 November 2013 -> 25 September 2014で導入されてるね。
つか、「JavaScript mouse event order」でググッても引っかからないのは、
googleさんもうちょっと頑張ってくれ、とは思うが、
このレベルの詳細についてはMDNも未対応なのは認識した。
> コードを書いて検証してみたのか?
それは意味無いだろ。
このコードで良いかの確認は出来ないのだから。
> Webの世界なんてそれとは比べものにならないよ
それは買いかぶりすぎだ。この点はWebは10年遅れてたと断定出来る。
.NETは最初からイベントの順番は決まっており、遅くとも2005には固定されてた。
全てがWebが早いわけではないし、Webが早いってのも嘘だよ。
Webは仕様の更新頻度が高いだけ。
相変わらずおまえら信者レベルが酷いが、JavaScriptが全て良いわけではないし、
最先端な訳でも全然無いぞ。そこはマジで理解した方がいい。
asyncだってC#の方が先に導入したろ。
そしてJavaScriptはPromiseというゴミを抱えることになってしまった。
お前らは「難しくて」「最先端な」JavaScriptを使いこなす俺カッコイイ、
じゃないと困るみたいだが、全然それはないから。
JavaScriptは「簡単」だし「遅れてる」面も結構ある。
他言語をやれば分かる話なのに、理解出来ないのは、他言語が全く出来ないからだよ。
まあ全般的にHTML周りはよく出来ているのも事実だが。
むしろ他言語で実験/検証済みのこの機能が2014まで導入されなかったことが問題だ。
だから意図的に残したのか、という解釈だったが、方針変更ならさておき、
その他の件見てもJavaScriptの仕様委員会は馬鹿だから、気づかなかったのか?とも思える。 せっかく教えてやったのにこの態度か。死んでしまうといい。 >>869
その変化の遅い10年越しの変更にもついてこれてないあんたは何も言えないよ JSが新しいなんて一度も思ったことないし、最先端が難しかったら何の意味も無い
.NETだってそもそもTaskあってのasyncなんだが つうかわざわざ例まで出して変化が早いから情報の鮮度に気をつけてねという意味で
「Webの世界なんてそれとは比べものにならないよ」と言ってるのに
「JSは他よりも進んでるんだぜ」と言ってるように思われるなんて心外 >>869
> googleさんもうちょっと頑張ってくれ、とは思うが、
> このレベルの詳細についてはMDNも未対応なのは認識した。
こういう認識の人がJavaScriptの何たるかを語っても説得力がまるでない
二次情報をあてにして、振り回されるだけ 2014になってようやくイベント順を固定した事なんて、全く威張れる話ではない。
それを「Webは速い(キリッ」とか、マジでヤバいってことだよ。
個人的にはWPF(2007)はHTMLを丸飲みすべきだったと思っていたが、
しなかった(出来なかった)理由はここら辺にもあるのだろう。
全般的にJavaScriptの仕様委員会の奴らからはコードを書いているニオイがしない。
これが多分、今のJavaScript界の一番の問題だ。
この仕様ではコードが書きづらい、というところが結構ある。(放置されている)
今回もそう。仕様もイマイチおかしいだろ。
プログラミングモデルとして整備するなら、
A: enter -> over -> out -> leave …入れ子(6パス=150%)
B: over -> enter -> out -> leave …W3C(5パス=125%)
C: over -> out -> enter -> leave …最速(4パス=100%)
Aのように入れ子にするのが妥当だが、何故かBになってるだろ。
これは enter は over の、leave は out の従属イベントになっていることを示唆している。
実際、実装上はそうだから、Cの順なら最速になる。(BはC比125%遅い)
ただしCはプログラミングモデルとしては意味不明だから、
一般的には「保証されていない」と表現されることになる。(for-inがこれ)
ところがこれもないだろ。
プログラミングモデルとして整合性も無し、最速でも無し。
コード書いてる奴らならAかCにする。ここら辺がちょっと違和感がある。
元々「規定無し」で来てたのをわざわざBにする意味はない。普通は決めるならAにする。
結果的にこういった間違った仕様の選択がJavaScriptを静かに殺していく。promiseもそうだ。
なお、WPFはどうなのかな?と思って確認したが、mouseover自体がない。
おそらくenter/leaveがbubbleするようになってて、それだけだ。
彼らはover/outは冗長だと判定したようだ。 仕様書Figure2のmouseover(C)の方が分かりやすいかな?
2のoverが発生した後にenterがキャプチャ順で発生している。
本当は2のoverは5.5の所にないといけない。
そしたらenterがキャプチャ順、over/outがキャプチャ/バブル、leaveがバブル順で
綺麗に入れ子になるだろ。
C++の場合はリソース管理上厳密に入れ子必須なのだが、
JavaScriptの場合はここら辺が甘いから上達しないってのはある。
元凶は仕様委員会がゴミだから仕様がゴミになっていること。
結果、JavaScriptではゴミコードしか書けなくなっており、
お前らは美しいコードを見たことがなく、感覚が鈍いままになってる。
C++が良いとも思わないが、ある程度「ちゃんとした」環境がないと上達しない。
動けばいい、でやっている限り、動けばいい程度のコードしか書けないままだ。
JavaScriptは仕様委員会の連中がこの程度なのが最悪だ。
何を目指してこの仕様にしたのか、どういうユースケースを想定しているのか、さっぱり分からない。
お前らと話していると、技術的な面にはだいぶズレを感じる。
何度も言っているが、お前らは分かってないし、上達してない。これは自覚した方がいい。
ただ、ググッても出てこないような仕様を抑えている点を見ても、
お前らが努力してないって事はないんだろう。(これも前に言ったが)
今のお前らでは気づけないのだろうけど、
JavaScriptにはお前らの上達を阻害している要因が結構ある。
それは自覚して回避することは可能だから、信者になってマンセーするのではなく、
良い点と悪い点を冷静に見極めて行った方がいい。
そうすれば割とあっさり上達するのかもしれん。 >>873
今更変更してて、しかもMDNに4年後も反映されてないってのは想定外だった。
もっとも、仕様化されている≠今の実装がそうとは限らない、もガンな所だが。 >>874
JavaScriptが「プログラミング言語全般からすると」比較的簡単な言語だ、
と認識しているのならそれで問題はない。
> .NETだってそもそもTaskあってのasyncなんだが
それはない。
JavaScriptでpromiseが既に要らない子なのと同様、
C#では既にtaskは要らない子だよ。この点はC#も失敗してる。
JavaScriptは仕様委員会がパヨク化していて、ポリコレを振り回しているのがいけない。
asyncが見えていたのに「○○はpromiseを返します」なAPIとか、
httpsでしか使えません、とか、腐ってるだろ。
httpsにするかしないかはユーザ判断であって、JavaScriptの仕様委員会が決めることではない。
技術的な話に徹しておらず、結果的におかしな仕様選択になっており、次第に腐って行ってる。
何でこんなになってしまったのかは知らんが。 >>875
他言語も最近はかなりの頻度で仕様変更してる。
JavaScriptの変化が特段早いわけでは全くない。
ただ、Webは下地が固まってないのを変更しているから、変更が大きく見えるだけ。 >>876
俺はMDNは一次情報扱いだ。
ただし4年も遅れているとは認識出来ていなかった。
googleは結局Webページの巡回であって、pdf文書やGithubの中身の網羅までは出来てないって事だ。
冷静に考えれば当たり前だが、俺は気づいていなかった。 > 全般的にJavaScriptの仕様委員会の奴らからはコードを書いているニオイがしない。
DOMの話なんだからJavaScriptの仕様とは関係ないだろ
そういうふうに詰めが甘いから、お前からは素人臭してしてこないんだわ MDNが一時情報?
個人のブログからネタ拾って紹介したりしてるぞ? 一次情報と言ってもJavaScriptの一次情報じゃない
APIの一次情報でもない、DOMの一次情報でもない
MDNはブラウザが実装している機能の一次情報 >>883
> DOMの話なんだからJavaScriptの仕様とは関係ないだろ
> そういうふうに詰めが甘いから、お前からは素人臭してしてこないんだわ
まさにその通りなんだが、「お前ら」は ID:qM8cSWzB に訂正しておいてくれ
DOMをJavaScript以外で扱ったことがないようだ
「Promiseが既に要らない子」はFetch全否定だし、仕様書をまともに読んだことがないのだろう >>886
MDNはFxの一次情報
あなたはFxだけ対応すればいいと考えているのだな >>888
くぷぷwww
Firefoxだけの一次情報なわけないだろwwww 全般的にお前らは無駄に意識が高すぎて、形式に拘りすぎだ。
要するに、自分にとって一番良さそうな資料を読めば良いだけ。
仕様書を読んでる俺カッコイイとか、必要ないんだよ。
俺にとってはMDNが一番マシだから、俺はそうしてる。
仕様、説明、サンプルコード、互換表、注意点、が載ってる。
仕様書は仕様しか載ってない。
MDNに同項目があるのならそっちの方が便利だ。
MouseEventOrderについて丸々抜け落ちている理由は分からない。
MDNを書いている奴らからはコードを書いているニオイはするから、
この項目の重要性が認識出来ていないとは考えにくい。
ブラウザに未実装なのか?
しかしあの仕様はどっちかというとJavaScriptの他項目と同じで、
「美しい仕様を考えた」よりは「現状のブラウザの実装を調べた」に近いから、
これも考えにくいのだが。
とはいえ、この件で妥当な「載せなかった理由」が無ければ、
MDNの項目の選定もおかしいことになり、
お前らの主張「仕様書を読め」も妥当だということになるが。 良さそうもなにもMDNは
ブラウザが実装している機能の
一次情報だろ http://hkdnet.hatenablog.com/entry/2017/10/22/100000
> んで、これをちょっと読んでたんですがサンプルコードがわけわかんなかったんですよね。
> 僕が作った例のがイケてるんじゃね?と思ったのでコントリビュートしてみました。
一次情報がなんだって?wwwww >>869
このオジサンは
Web > 君の街 という比較例を出しただけなのになんでC#とかasyncとかの話勝手に持ち出してきて発狂してるの??? >>895
それが分からないのはお前が馬鹿だからだ。
他の連中は反発しつつも、
「何故俺がそれをここで言うか」についてはついて来れてるだろ。 >>896
ああそーーっすかぁ
>>JavaScriptは「簡単」だし「遅れてる」面も結構ある。
他言語をやれば分かる話なのに、理解出来ないのは、他言語が全く出来ないからだ
こんなマウント取りやっといて10年前のstackoverflow漁ってたの図星されたから悔しかったわけじゃないんすねー
俺がバカだったんすね
すいません勉強しまーーーす つかマジでお前ら文系プログラマっぽいよな。
突っ込んでくるところがおかしい。
折角877で仕様の不自然な点を挙げているのだから、(技術論)
仕様に詳しいつもりならそこに突っ込んでこいよ。
俺を言い負かしたいのならそこが格好の攻撃ポイントだろ。
なんつーか、マジでお前ら『文系的』揚げ足取りしかしないよな。
C/C++スレの連中も十分狂ってるが、あいつらは基本的に技術論だからいいんだよ。
お前ら、こんなレス読んでてもなんの足しにもならんだろ。
そういう姿勢が上達を妨げている、ってのもあるよ。
幼稚園児レベルの「言われたら言い返す」ではなくて、もうちょっと大人になれ。 >>897
俺がお前らにマウント取って、何の意味があるんだよ?
> こんなマウント取りやっといて10年前のstackoverflow漁ってたの図星されたから悔しかったわけじゃないんすねー
こういう風に取れる=お前はマウント取りをしたがっている、と分かる。
まあ、若いんだろうさ。
もちろんやりたければやればいいんだが、
それをしたところで何もお前の為にはならないといい加減気付け。
JavaScriptがどうなのか、というのは比較論であって、
当たり前だが他言語も知ってないと何も言えるはずがないんだよ。
そして他言語を知ってれば、マンセーではなくて、
いいところも悪いところもある、と分かるはずなんだよ。
お前らからはこの感じを受けない。
だから知りもせずにマンセーしてんじゃねーよ馬鹿共、と言っているわけでさ。
他言語と比べれば、
> JavaScriptは「簡単」だし「遅れてる」面も結構ある。
のは事実だし、具体的に挙げたろ。
それについて技術的に突っ込んでくるのではなく、
こう言ったことに対し感情的に突っ込んでくるうちはお前らは上達しないよ。 Javascriptはプログラマがオブジェクトの生存期間をコントロールしにくい。
どこからでもいつでも生存期間を延長しようと言語仕様そのものが狙ってくる。
従ってアプリ固有のマクロ程度が使用限界となる。 >>881
意味わからん
誰も他言語と比較なんてしてないんだけど
君自信も「仕様の更新頻度が高い」と認めてたじゃないか?
>>899
までに色々書いてるけど全部自分に跳ね返ってないか?
一番人の発言を変な捉え方して、意固地になってるのは君だと思うよ
そもそもね
Webって「完成物」じゃないからね、常に発展途上で皆で作っていくのがWebなの
仕様だって沢山定められているし機関もあるけど、別にそれらがWebの支配者なわけじゃない
MDNに無い? なら書き加えればいいじゃん? と思われるだけ
現状の改善のためには不満を持つことは大変よいことだけど
少なくともここはその不満を書き散らすような場所じゃない
君は街の観光案内所に行って、この街は遅れてる!認めろ!とか叫ぶ人なのか? WebはGoogleの思い通りに改変されていくものだからね。
Googleとの対決に負けて以降、W3Cは機能していないんだから。 いつまでW3Cに固執してるんだよ
まともなやつならWHATWG追うだろ W3Cの方がGoogleよりも属人的だったぞ
名前は忘れたがXHTMLガン押しのカリスマおっちゃんいたジャン
その後にHTML5を進めた貢献者もそのおっちゃんだけど
良くも悪くもそのおっちゃんのセンスに振り回されてたのが昔だよ
一方Googleはデータ主義だし、各専門科は狭い分野を担当している
仕様も分散してカリスマがいない事によるデメリットもあるけど
どちらかというと今の方が個人的には気に入ってる > XHTMLガン押し
俺はXHTMLには否定的だったな。
XSLTは最悪の技術だった
自分のセンスが正しいことが証明されたよ XHTMLなら決定性のあるアルゴリズムで解析できるので、セキュリティ的な意味合いで良さがあった。
カスタム・タグのセキュリティについてはHTML Tidyのプロジェクトで議論しているのでよかったらどうぞ。
基本的に悪い方向に向かっていると思います。
これを安全に扱えるのは最早Googleしかいないんじゃないでしょうか。 「XHTMLが悪かった」というのは局所的に見過ぎてる
後方互換性がなかったのが問題だった
これについては、MSの功罪が大きい
MSがIEをアップデートしていたならば、XHTML2が生き残る道はあった 構造化された文章ならその価値はあるだろうが
Webサイトと言うのはもはやそういうものとは限らないからな タグの動作を拡張できるというのは非常に危険なことです。
Googleの野心にウェブ全体が付き合わされる必要はないんじゃないでしょうかね。 ウェブ屋さんはちょっと変わった人が多いんだよね。
ネットスケープはとにかく落ちるブラウザで、直前に読んでいたページのせいで次のページが落ちるなんてこともよくあった。
ネットスケープに一番苦しめられてたはずのウェブ屋さんは何故かネットスケープマンセーしてたんだよね。
そして今、グーグルに一番苦しめられてるはずのウェブ屋さんがグーグルマンセーなんだよ。
おそらくこれ知能指数の問題じゃないかとにらんでる。
ウェブ屋さんの平均知能指数は他の業種より低いはず。 ウェブ屋さんが昔よく言ってたのは、Javascriptはたった二週間で作られた、天才じゃなければそんなことはできない、天才が作ったんだから最高の言語だ、こんな感じ。
僕は、たった二週間で作られた言語がそんなにいいわけないと考えるんだけどね。 最近のウェブ屋さんが良く言うのは、リビング・スタンダードね。
固定することなく次々仕様が改良されていく、とても素晴らしいってね。
仕様がころころ変わって一番いじめられてるはずのウェブ屋さんがそんなこと言うんだから、面白いよね。 XHTML も XSLT も別に悪いもんじゃない。もちろん JavaScript もだ。
XML Schema はだめ。 Javascriptは駄目すぎですよ。
早く捨て去った方が良い。 アンチJS見るのだいぶ久しぶりじゃない?
最近はJSer同士の喧嘩がほとんどだった気がする
いいぞ、もっとやれ XMLは正直、SGMLよりはるかにマシだと思うけどな。
決定的なアルゴリズムと言う面でも、別にカスタムタグがあるからといって非決定的になるわけでもなく、カスタムタグ通りに動くだけであって、カスタムタグを想定していないガバガバな方がよろしくないかと。
そこまで否定的な事言ってたか?確かにTidyのIssueで何度も上がってるが、その文脈での反論には「そもそもvalidatorじゃ無いんだよ?」とツッコミ入ってたかと。
Javascriptがダメと言うのは、もう論外の発想では? Living Standardを否定する人は老害じゃないかと思う
なんのための標準化なのか >>912
俺はたった二週間でできるわけないので、
その情報の出処はどこなのか、どの部分を二週間で作ったのか
それまでに似たようなものを作っていたのではないのか?って思うけどね。 >>918
Javascriptは明らかに駄目だろう。
元々はちょっとしたマクロのようなものを想定していたんだろう。
その程度のものをアプリに使おうというのが無理筋すぎる。
しかもそれがネットを介して作動するのだから、もはや気がくるってる。 >>923
だから改良されたでしょ?
今のJavaScriptは昔のJavaScriptとはぜんぜん違うよ >>925
だめではないね。最新のJavaScriptは
他のどんな言語よりも優れてる ウェブ屋さんはなぜ考えることをやめてしまうのだろう。 みんなが考えた結果がJavaScriptの進化では? 新しいJSと他の言語の比較はwasmが本格化したら考えてくれれば良いけど
最新の仕様に無頓着なのは完全に別問題、言い訳もクソもない >>923
違うよ。当初から単なるマクロは想定してない。だろう論で話さずに、lispが作りたかったんや!って本人が言ってるあれ読んできたら良いよ。
ネットを介してが何を指してるかもわからんけど。
ブラウザ≒ランタイムなのが気に食わないのかな? Web屋ではないけど、どうして考えることをやめたんだろう、と考えることをやめた人に言われたらちょっと面食らうな。 >>901
> 意味わからん
そりゃお前が馬鹿だからだ。
ただお前、866か?
ならそれは有効な情報だったし、多少はマジレスしよう。
今のお前の価値観は、完全に「Webしか出来ない意識高い系」そのものだ。
非Web系言語を何でもいいから一つでもやってみるといい。
そうすれば、JavaScriptの糞な所が理解出来、
自分の発言のどの部分が間違っているか分かるだろう。 > 非Web系言語を何でもいいから一つでもやってみるといい。
> そうすれば、JavaScriptの糞な所が理解出来、
> 自分の発言のどの部分が間違っているか分かるだろう。
意訳
説明ができない。相手を説得できるだけの根拠がない
せや、相手にJavaScriptの糞な所を自分で見つけさせよう
相手が糞な所を調べられなければ、相手のせいにできるし
相手が糞な所調べれば、一石二鳥
俺って頭いい! >>934
ということで、お前の卑怯な戦略は封じたので、
さっさとJavaScriptが糞な所をお前が説明しろ なんか伸びてると思ったらまた例の自称他分野の上級者くんがわいただけか
XHTMLの仕様を引き合いに出すのになぜかW3Cじゃなくて日本語wikipedia持ってきて頓珍漢なこと書いた挙げ句2018年にHTML6とかいうワード出してきたLiving Standardの存在すら知らない化石だろ
仕様書の中身覚える必要は全くないけど仕様を知りたくなった時に適切な場所で調べる能力がないのはエンジニアとして終わってんだよなあ 俺明日からTypeScriptでサーバサイドを書く仕事するんだ。楽しみ 「俺がJavascriptが糞だと思う根拠を俺は説明できないからお前が他の色々な言語と比較して俺の意見としてよろしく説明しろ」 「お前はYESと言った、俺の意見はNOだ。お前は俺の代わりに調べてNOであることを証明しろ」 Webに限らず普通はまず仕様を調べて、それから実際のところどうなってんのか実装を見るものだと思うけど…… さすがにJavascriptが素晴らしいってのはないわ。 うむ、JavaScriptは素晴らしくない
昔よりだいぶマシになったとは言え書かずに済むなら書きたくない言語だ てかお前ら必死すぎ。
何でそんなに信者になるのか分からん。
お前らが馬鹿なままで居続けるのはお前らの自由だ。
同様に、お前らが俺のアドバイスを信じてみるのも自由だ。
結果は周りの奴ら、つまりお前らの同僚や後輩が判定してくれる。
今と同様に間抜けなことを言い続けたら馬鹿だと見なされるだけ。
JavaScriptが糞かどうかは別として、
他言語を学ぶのは上達への一つの方法ではあるから、やってみるといい。
そうすれば、JavaScriptがどうなのか客観的に分かるだろう。
そもそも、良い/悪いってのは比較論なんだから、
他言語を何一つ知らない奴が言っていい事ではないんだよ。 JSは昨日動いてたコードが今日のブラウザのアップデートで動きませんを回避するために、
ES5以前のこの動きは駄目だろうと言いたくなる仕様が沢山あって初心者が中級者に上がる所が辛い言語だと思うわ。
肝心のES2015も新サポートの構文増え過ぎで、勉強し始めは「これらは本当に同じ言語なのか…?」と戸惑うところが結構あったし。
でもまあ、モダンな環境に一通り触った今ならそんな糞言語だとは思わんな。 >>941
それは非Web系の常識だ。
JavaScriptは特に悲惨で、仕様と実装が全く同期してない。
だから割と出たとこ勝負で、それが嫌だから例のnpmの件、
・作者がnpmと揉めてコードを引き上げたら、
それをリンクしていたWebサイトが突然軒並み動作しなくなってプチ祭り状態、
どんな凄いライブラリなのかと思いきや、なんとたった1行!
他言語の連中の反応はマジで冷ややか、『こいつらはコード書けないのか?』
なんて事が起きる。
仕様と実装が同期していないのも、普通に考える「実装が追いつかない」ではなく、
・仕様化されているが、実装されていない
・仕様化されているが、異なる実装になっている
・実装されているが、仕様化されていない
(リファレンス実装無し=物によって動作がバラバラ)
の全部ある。
だから仕様を調べて…という『一般常識』だと盛大に空振りすることもよくある。
俺はこれがJavaScriptの最悪なところだと思うけど、
JavaScriptしか知らない奴はこれが普通と思っているから、話が通じない。 Haxe は良いけど、JS ではプログラミング出来ない
プログラミング部分はRuby でやって、
Rails から、jQuery, Vue.js とか使うのが一番 Rails 5.1で作るVue.jsアプリケーション 〜Herokuデプロイからシステムテストまで〜
https://youtu.be/ycOeM2umXkY
伊藤淳一 Junichi Ito の動画
Rails 5.1 から、Vue.js を使う まぁそもそもJavaScriptが嫌いなら無理して使わなくてええんやで?
ヘイトぶちまけたいなら愚痴スレ行け
ちなみに俺は素のJSは馴染まないから理由がない限りTypeScript使う 普通に考えてあんな糞言語広めたやつは裁きの場に出るべきじゃないか?
そして死刑が執行されて民衆が納得する。
このままだと暴動起きるよ? >>947
君は非常に大きな考え違いをしている
それは大変な間違いだよ
仕様は仕様、それを勝手に利用してる実装は実装
両者の問題を混同してはいけない
君の理屈だと例えばあるビデオコーディック対応と謳ってながら実際は
プロファイルなどによって再生できなかったり、色の再現などに関して問題が起きたり
いろんなプレイヤー間に非互換性があることに関して
そのコーディック仕様に文句を言うようなもの
そういうライセンスを与えてるならまだしも、
仕様側には世の中の実装を正す責任も権利もないし
そういうことで仕様に対して文句をいうのは完璧にお門違いの話
実装に関しても、もし〇〇対応と言っておきながら違っていたら嘘を言ってることになるが
実際はそんな具体的に対応機能を列挙してそれを価値として売ってるブラウザなんて少ないし
実装に誰から言われなくとも自分たちで気づいて直す義務があるとまでは言えない
『これとこれとこのプレイヤーでは最低でも再生できる動画を作りたい』と願うのは俺たちの方で、
あくまでそれは『俺たちの勝手な願い』なのだから、そこで生じる問題は俺たちが負うのは至極当然のこと
もし、実装に直して欲しいと願う部分があるならば、最低でもissueやパッチを投げるくらいの義務は俺たちの方にある
それなのに実装や、ましてや仕様を「悪」というのは随分おこがましいな >>947
仕様を最初に調べるのが常識なのにMDNやら10年前のstackoverflowやら漁って失敗したのがオマエだろ
JSはクソだがベンダの実装がクソなことと言語がクソなことの区別がつかないオマエはそれ以下の糞
ここの区別がついてないと昔よりだいぶマシになったモダンな言語仕様通りに書いて、実装の汚いところはトランスパイラによしなにやってもらうという解決ができない 御託並べて働きもしない奴「働く必要などない!」
御託並べて仕様も読まない奴「仕様など読む必要ない!」 生jsとトランス前提のjsでは話が変わってくると思うけどな。
前者は嫌だが、後者ならまあ普通に使えると思ってる。
※個人の意見です。 それ生か変換かっていう話じゃなくて
ES2018使えるか、ES5どまりか、って違いじゃないの >>955
日本語でおk。
> それなのに実装や、ましてや仕様を「悪」というのは随分おこがましいな
俺以外も含めて、誰も「仕様を『悪』」とは言ってない。
ちゃんと理解出来るまで読み返せ。
日本語が通じないお前に対していくら書いても通じないと分かりきっているから俺は書かない。
が、頑張って書いた分についてはポイントだけ教えてやる。
君は「他言語でも同様」「JavaScript特有」の案件の区別が付いてない。
これは、やはり君はJavaScriptしか知らないことを意味する。
その程度で、比較論をぶつのは適当ではない。
議論したいのなら、まずは話の筋を完全に理解出来るまで何度でも読み返せ。
今のお前に必要なのはそれだよ。
>>956
君はそこを攻撃ポイントだと捉えているようだが、
俺は「失敗」とは思っていない。逆に、地雷臭を感じている。
あと、JavaScripterの信者化はいったい何なんだ?
JavaScriptが糞かどうかと、お前らが糞かどうかは別の話だ。
逆に、仮にJavaScriptがものすごく素晴らしいとしても、
それを使っているお前らが素晴らしいことには全くならない。
なんだかんだでJavaとPythonが蔓延っているのは、あの程度が丁度良いからだ。
本当に頭抜けているのなら、その言語が世界を統一してしまう。かつてのCがそうだ。
JavaScriptにはそこまでの勢いなんて全くない。
これを認識出来ないのは、お前らがJavaScriptの世界に引きこもっているからだ。 C言語が世界を統一したことなんてないんだけど?
むしろCOBOLの方が使われていただろう 分量すごいのに中身が全然ない…
日本語ってここまで薄められるんだ… JSの良し悪しなら言語比較スレにでも行って好きにやってくれ
CだってC89や下手すりゃK&Rで時代が止まってる様な発言したらそりゃ突っ込まれるだろうに ならさっさと877,878の技術面に突っ込んで来いよ。
お前らの根本的原因はそこなんだよ。
C++のスレの連中は異様なほど技術面に執着する。
お前らは逆に、異様なほど「JavaScriptは素晴らしい」事にしたがる。
だからこういう流れになる。これもいつものことだろ。
俺は今更のこの仕様にしたこと、そしてそれが4年も放置されていることに
地雷臭を感じてる。
それについてお前らの見解はないのか?
(話を理解出来ない奴が大半だとは思うが) ID:FoNGS0Kl が仕様と実装の違いを理解してのは>>947を読めば分かる > C++のスレの連中は異様なほど技術面に執着する。
暇なんだろうね。 普通にライブラリが異なる実装がある言語は仕様と実装のズレなんていくらでもあるのにな
複数の主要な実装があるのが珍しいだけな気がする >>961
君は良く他の言語だったら〜というが、他の言語スレだったら取り合ってもらえないだろうよ
決定的な反論をぶつけて叩き出さないのも全て、俺たちが多様性というのを尊重してるから
あいつとこいつと君と俺の意見が同じような日本語を使ってるはずなのに全然合わないように、
中央管理者の居ない状況で個々の者同士がやり取りするのは一定のルールは必要とは言え
結局細部に齟齬が生じるのが自然の摂理なんだよ
これはもうWebというものの成り立ちからくるものだから、そのポリシーを批判しても仕方がない
もちろん細かな変更はしようがあるが、今だってWebを整えたとも言えるGoogleだって、
Webを牛耳ってると非難する人が出るように明らかな改善というのを定義するのは難しい
いろんなデバイス、いろんな人間が関わっているのがWebだから、程々曖昧にしてバランスを取るしかない
そういう部分が嫌というのは気持ちは分かるが、Webから離れてくれと言うしか無い
1つ言うなれば、仕様やリファレンスに疑問を感じたら自分が直せ 君もWebの一員なんだから
結局そういう物っていうのは、残念ながら世界を作って管理してる神の書いた聖書ってわけじゃないんだよ
Webにおいて仕様やリファレンスとは、勝手に人間がこの世の仕組みや物に名前を付けてる辞書のようなものでしかない
その辞書の内容だって個々違ったりするし、最新の現実を100%表してるわけではない 絶対ってものではないんだよ
でも今更Webに神を置くことなんて不可能なのは君でも分かってくれるだろう?
ならどうしろというのさ? >>969
日本語でおk、マジで。
だから通じてねえと言ってるんだよ。
俺はWebを批判しているのではない。そんなことは言ってないだろ。
そもそも俺は全般的に現状肯定派だ。ここが根本的に違う。
お前らは「JavaScriptは素晴らしい」ということにしたいだけだ。
それは明確な間違いで、何にもならないから、止めろと言っている。
が、お前らのレベルはもう完全に宗教だから、好きにすればいい。
それで馬鹿なままなのは自業自得だ。
ここからは離れ、本題に行く。
> 1つ言うなれば、仕様やリファレンスに疑問を感じたら自分が直せ
これに対する感覚が決定的に違う。
お前らは若く、自分が全知全能の神で、疑問があれば「相手が間違っている」と断定している。
つまり、「現状否定派」だ。
俺は、これには「書かなかった理由があった」と推定している。
つまり、「現状肯定派」なんだよ。
だから、疑問に思ったからといって闇雲に参加して書き加えるとかはしない。
なおこの違いは要するに年の違いだから、お前らが今「現状否定派」なのは問題ではない。
それはいわゆる「若さの特権」だし、若いうちはそれでいい。
「現状肯定派」には今回の件は以下のように映る。
1. 世界中の誰も4年もMouseEventOrderをMDNに追記しようと思わなかったとは考えにくい。
2. まともなプログラマならこの項目が重要だとは認識出来る。(googleも)
3. W3Cの仕様B(877)はゴミ。
4. とりあえず手持ちの環境で軽く試したが、どうやらW3C仕様で動いているっぽい。
重要な項目が、既に実装完了の状態なのに、
誰もMDNに書こうとも思わないってのは明らかにおかしいだろ。
書きたくない理由があるんだよ。分かってて書いてない。 可能性として俺が思いつくのは以下。
α:W3Cなんて無視
(しかしWHATWGはHTMLだけでDOMにはノータッチのようだが)
β:現状のブラウザに未実装の物があるから宣伝を控えている?(消極的無視)
(未実装のブラウザのライフタイム終了と共に宣伝開始か?
しかし新機能を喧伝している状況でこれもない)
γ:W3Cの仕様が気に入らないから仕様変更するつもりか?
俺はこの中ではγかと思っているから、この仕様には乗れない=地雷臭を感じてる。
で、ここら辺についてはお前らの方が詳しいから、何か意見はないのか?と聞いている。
俺にはW3Cがこの仕様にした理由が見えないから、状況が読めない。
一応969の内容に答えておくと、
そんなことは基本的に俺は思ってないわけ。
「俺がやりさえすれば全て上手く行く」「駄目なのはお前らがやってるからだ」というのは、
ガキが巣くっているこのスレみたいな所ならともかく、
俺と同年齢層/同技術レベルの奴らも多数参加している場所ではあり得ない。
Webの現状がどうあろうと、それは関わってきた奴らがこれまで努力してきた結果であり、
そこに俺が参加したからといってたちどころに改善するなんてことはあり得ない。
こんなのは年を取った奴らは全員理解している。
(とはいえ糞は糞である事実は変わらない。
それをさも素晴らしいかのごとく言うな馬鹿タレ、という話)
だからそもそもそういう指摘をしてくること自体が若いんだよ。
ただ、それは若さの特権だから、お前は今はそれでいい。 ここ厶板のJSスレなんだから
DOMの仕様策定に物申すなら向こうでやってよ 向こうでやってよって、自分たちで自分たちの住処ぶっ壊して移住してきたくせによく言うよな。 enterはoverに従属
overはmoveに従属
それで一体何が問題なのか・・ そもそもココでJSの仕様がどうだのと長文の持論を連発し始めてる時点で仕様書もロクに読めないクズ お前らは分かってない君が仕様書を読めない人なのは、以前も見た >>970
> お前らは「JavaScriptは素晴らしい」ということにしたいだけだ。
いや、大多数はそんなこと思ってなくて、お前の技術力の無さをJavaScriptのせいにするなよと思ってるだけだぞ。
(俺はC#やJavaの方が好きだし)
> まともなプログラマならこの項目が重要だとは認識出来る
なぜ仕様書も読まずに5chに質問するやつが自分に異様な自信を持っているのかわからん
需要があればググれば質問がヒットする。単にMouseイベントの順番の重要性が低いから書いてないんでしょ。 この人マジで全く根拠のない思い込みの知ったかぶりで適当こいてるだけだから一切話聞く必要ない
別にLiving Standardが素晴らしいとは言わないけど DOM Living Standard の *存在を知らない* のはエンジニアとして論外
>>971
>(しかしWHATWGはHTMLだけでDOMにはノータッチのようだが)
つ https://dom.spec.whatwg.org そもそもW3Cへの批判を並べながらECMAScriptを語るってのが意味不明
DOMの話してんじゃないの そもそもJavaScript素晴らしいとか言ってんのごくわずかしかいないのに誰と戦ってるのか
ほとんどのWeb屋は英語と同じでJavaScriptがWebの共通語だから使ってるだけで、大抵別のお気に入り言語がある JavaScriptは現在勝ち言語なんだからわざわざ素晴らしいとかアピールする必要なんて無いだろ
そんなこと言ってる人も見ないが 一応 >>877 に突っ込むと、「Cの順なら最速」は意味不明。
stopPropergationでenterが止まるのを見てもわかるように、overの伝搬を利用してenterを実装することを想定した仕様だと思う
入れ子ではなくセットで、overに従属するenterが後から来るのは特段不自然ではない
(C#でもClosing→FormClosing→Closed→FormClosedという順番のイベントがある)
パフォーマンスとIEとjQueryの動作を破壊してまでAを採用する理由がないならBにするのが妥当に見えるが
> WPFはどうなのかな?と思って確認したが、mouseover自体がない。
WinFormsにもWPFにもoverとenterはないと思う
何を持って「.NETは最初からイベントの順番は決まっており、遅くとも2005には固定されてた」なの? 深刻な確証バイアス罹患者だろうからどうしようもない >>979
おっと?これは失敬。
確認したが、EventOrderについては記載がない。
ということは、彼らはこちらを向いていて、W3Cは参考程度の扱いって事か?
それなら一応の辻褄は合う。 >>986
未定義は馬鹿が踏みがちなので、わざわざ「未定義」と注記しているのだよ >>980
DOMとJavaScriptの関係性を理解できてない模様
他人を批判する前に仕様書を読めといいたい >>983
> 何を持って「.NETは最初からイベントの順番は決まっており
「.NET Event order」でググレば俺には最初にヒットするが
> Windows フォームのイベントの順序
> https://docs.microsoft.com/ja-jp/dotnet/framework/winforms/order-of-events-in-windows-forms
その他諸々。いちいち全部決まってるよ。
また、addEventListenerで足した順に処理される。
> (C#でもClosing→FormClosing→Closed→FormClosedという順番のイベントがある)
ClosingとClosedはobsoleteだ。
そしてセットが問題ではなく、入れ子になってないのが妥当ではないと言っている。
とはいえFormsについては最早どうでもいい。
> stopPropergationでenterが止まるのを見てもわかるように
これはアウトだろ。WHATWGとW3Cのどちらにもそれを想起させる記載はない。
ただ、俺環境では止まらないが。もういっぺん確認してみて。
> 「Cの順なら最速」は意味不明。
これは分からなくていい。
俺が最速の実装を目指したら結果的にこうなる、という例でしかない。
君が別の解になることはあり得るし、問題ではない。ただ、
> overの伝搬を利用してenterを実装する
を想定しているのならそれは俺と同じであり、
・overとoutを伝播させてenterとleaveを作る。
・だからoutよりenterが先に来ているBでは、outを事前に空伝播する必要がある。
・同様に、Aの場合はenterがoverよりも前で、overを空伝播させる必要がある。
・空伝播を一回もさせずに済むのはCの時。
だからCは伝播がそれぞれ1回ずつの4パス、Bはout*2で合計5パス、
Aはさらにoverが2回で合計6パス、という想定だ。
が、まあ、これ自体は重要ではない。
普通は決めるならAだし、あるいは規定無し=実装任せで最速実装できるようにする。
どちらでもないのはものすごく違和感がある。 >>983
> パフォーマンスとIEとjQueryの動作を破壊してまでAを採用する理由がないならBにするのが妥当に見えるが
ちなみにこれは最初期からこの実装だった、という想定でいいのか?
ならW3Cは現行のブラウザの実装をそのまま仕様化しただけで、
当然google等が文句を言う筋はないが、
google自身はこの仕様が不味いと理解しているから賛成もせず黙っている、といったところか。
Aの場合はリソース確保/解放をenter/leaveで行い、処理をover/outで行うという、一番綺麗なソースになる。
ただしリソース確保については if (ptr==null) でoverのド頭でやってもいいから、
リソース解放のleaveが最後になっているBにしても問題はない。
だから「高速化」という名目でA->Bにすることはあり得る。
さすがにCまでやると、outの後にenterとなり、全く直感的ではなくなるので、
現行のソースが動かなくなる可能性もある。
(仕様化されていなくてもそれを想定して書いている奴はおり、結果的にそれらが動かなくなる)
だからそこまではやらなかった、というのも割と納得出来るストーリーだ。
で、Bが仕様化されてしまって、ちょ、待てよ、といったところか。
W3Cの連中はマジでコード書いてなさそうなので、googleがここら辺を説明しても通じないとは思う。
それで偉そうに言われたら、分裂するのもまあ納得出来る。 >>989
>いちいち全部決まってるよ。
「書いてあるのだけ」決まってる。実際にはこの前後や間にMove、Layoutなんかが割り込まれる。
なお、イベントの実行順はC#では保証されない。(アクセサでイベント追加/削除を自由に定義できるため)
>stopPropergationでenterが止まる
すまん、再確認したら、拾い物のサンプルで使ってたライブラリが悪さしてたわ・・・
>最初期からこの実装だった
前そうだった気はするけど、さすがに古いバージョンを確認する気は起きん
Pointerイベントに向けて整理しただけかもしれない
ちなみに、Chromiumでは多分この報告で修正されてる。以前はそれなりに実装が異なったらしい。
https://bugs.chromium.org/p/chromium/issues/detail?id=470947
> 処理をover/outで行うという
それはレアケースな気がするが >>991
> なお、イベントの実行順はC#では保証されない。
マルチキャストデリゲートが登録順に実行される仕様なんだよ。
だからJavaScriptのノリでaddEventListenerしていく分には順番は保証されてる。
まあもうこれはいい。
> それはレアケースな気がするが
それはない。
mouseenterの項目見れば分かるが、それぞれが単発イベントになるから重いんだよ。
> With deep hierarchies, the amount of mouseenter events sent can be quite huge and cause significant performance problems.
> In such cases, it is better to listen for mouseover events.
> https://developer.mozilla.org/en-US/docs/Web/Events/mouseenter
だから実行性能を取るのならover/outで組むべきで、実際そういうサイトも多い。
君にenter/leaveで組む積極的理由があるのならご自由に。
単にC#出身で知らなかっただけならover/outへの切り替えを検討した方がいい。
とはいえ単純な置き換えにはならないが。
> ちなみに、Chromiumでは多分この報告で修正されてる。
> Actual event order: mouseenter mouseover mouseleave mouseout
これは元はenter/leaveを作ってそれを伝播させる実装か。
境界跨ぎを厳密に計算して追跡出来ればこれの方が速いのかもしれん。
で、他に合わせて修正か。なるほどchromiumの連中は面白くないだろう。
これだと元凶はFFだな。以下見る限りIEもベースはバブル順だったらしいし。
> https://www.quirksmode.org/js/events_order.html
後方互換性については、逆に2015/05までのライブラリは全て問題なしだと言えるのだが、
この状況だと今更修正する感じはなさそうだな。
なら積極広報すればいいのに、とも思うが。 なんの根拠もないのにwhatwg domでググることすらしないで
>(しかしWHATWGはHTMLだけでDOMにはノータッチのようだが)
とか書いちゃうヤツだから、
自分が詳しくない分野に関する話ほどコイツの発言は無視した方がよいぞ
適当にはったりでっち上げてる可能性があるからなー >>985
>確認したが、EventOrderについては記載がない。
DOMにマウスイベントの発火順が載ってないのは当たり前だよ
>Abstract
>DOM defines a platform-neutral model for events, aborting activities, and node trees.
別に仕様書の細かいところまで読んで覚えなくてもいいけど、要旨ぐらい読んでよ、マジでマジで Google mapをちょっと大きめのディスプレーで開くと、メモリー使用がGB超えるんだよ。
これ何かおかしい方向に進んでるような。 このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 104日 23時間 34分 23秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。