のテンプレを読んだ上で質問してください。
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は
ttp://http://validator.w3.org/">ttp://validator.w3.org/ で [Check] してみてください。 (8) 質問を具体的かつ詳細に書くと回答を得られやすいです。
ttps://mevius.5ch.net/test/read.cgi/tech/1427008785/ （ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）
この問題はねSPAだからといってパフォーマンスさげないよね？
無駄なことはしないよね？という話で解決するんだよ。
例えば、
ttp://example.com/foo/1 とかにアクセスした時、 index.html に30x のリダイレクトしたりはしない
なぜかって？ リダイレクトしたらパフォーマンス落ちるでしょ？
つまりね。PATH_INFO（でいいかな？）の情報を持った状態で
サーバーサイドアプリが呼び出されるんだよ
そこでサーバーサイド側の仕組みを使って404を返せばいい
SPAの話なのに何を言ってるのと思うかもしれないけど、
ちゃんとしたSPAっていうのはF5を押しても同じ画面が表示されるし
URLも
ttp://example.com/foo/1 のままになるもの SPAは/foo/1のデータをAjaxで読み込むものだと思ってるかもしれないけど、
それは他のページから辿った場合で、直接
ttp://example.com/foo/1 に アクセスした場合は、JavaScriptで取ってくるそのデータを最初からHTMLに埋め込むものなんだよ。
なぜかって？ ページアクセスして表示されてからデータを取りに行くとパフォーマンスさがるだろ？
だからSPAは基本Ajaxでデータを取るのは間違ってないんだけど、最初のページに限っては
最初からHTMLに埋め込んでおく。埋め込むことができるってことは、
データが見つからない時に404を返すことも容易
そして検索エンジンとかは、基本的にAjaxを使ってデータを読んだりしない。
読むことも有るかもしれないけど、Ajaxリクエスト（Content-Type: application/json）として
そのページを読み込むことはないだろう。だからいま問題にしているどうやって404を返すか？という
話は実は当てはまらない。検索エンジンは
ttp://example.com/foo/1 を直接読み込むのだから Ajaxによるリクエスト、つまり別ページを読み込んでからSPAの処理としてページを読み込む場合は
そのリクエストを404にすればよい。たしかにページ自体は404にはならないんだけどね。
でも検索エンジンには関係ない話
現状
ttps://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を返すことができる。
今、話をしてるのはクローラーの話だって分かってない？
クローラーはクッキーやローカルストレージは使わない
ttps://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のどちらかに決定することが可能
（まあ他にもリダイレクトとかあるだろうけどいずれにしろどれかに決定できる）
クローラーがブラウザと同じようにクライアントサイドだけでアプリを動かしているかもしれないじゃないか
とか頓珍漢なこと言うなよ？ それなにもクロールしてないからｗ クローラーの使命を果たしていない
ん？ もしかしてもそうなのかもしれないが、他のやつも
404が「サーバーから返すもの」
つまり HTTPというプロトコルを使ってクライアントから
サーバーにアクセスした時に、サーバーからクライアントへ
返すものだって分かってないのか？
404はHTTPプロトコルレベルの話なんだから、
仮にHTMLとJavaScriptだけで動くものがって
一切サーバーとアクセスしない=HTTPプロトコルを使わない場合
には、当然HTTPプロトコルレベルの話であるHTTPステータスコード404（200も）はでてこない。
これは常識だよね？
ここまではいいよね？
議論していただいていてありがとうございます。
その後facebookでもソフト404を許容していることがわかったりとか
サービスによってまちまちであることがわかったので、
他のサービスとの比較もしてみて、どうしても必要だったら
リダイレクトで404ページに飛ばすという簡易戦略で検証を進めてみます。
ありがとうございました。
そういわれるとちょっと違うと言わざるをえないんだよね。
仕方ないんで、facebookで再現する方法を探してきたよ
まず以下のABC News（でいいのかな？）のページを開く
ttps://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が
ttps://www.facebook.com/abc/about/aa になる HTTPステータスコードは404。（もちろんSPA状態から抜け出てはいない）
abount/aaなんてページは存在しないので画面は正しく表示されない
facebookは画面が変わらないようだが、ソフト404としてエラー画面にしようと思えばできるだろう
=== ここまではSPAとしてこのURLを開いた時のHTTPステータスコードの話 ===
ttps://www.facebook.com/abc/about/aa を直接入力して開くと facebookの画面がでてくるのか？ というともちろんそうじゃない。
HTTPステータスコードは404だし、「このページはご利用いただけません
リンクに問題があるか、ページが削除された可能性があります。」の画面がでてくる
つまりまとめると、
ttps://www.facebook.com/abc/about/aa というURLで示される存在しないリソースを要求したときは404になる。 SPA状態でアクセスされているときは、内部的に404になっているとしても画面上はそれが出てこない。
最初から言っているとおりだが、SPAで404を返したいという質問が意味不明で、単にサーバーにアクセスされて
レスポンスを返す時に、そのリソースが存在しないときは404を返すだけでいいんだよ。
200になってしまうのはでも書いたけど
1. URIからサーバーにリクエストを投げる
2. サーバーからindex.html/js相当を貰う
3. クライアントのJSでURIから画面と内容を表示するのデータを貰うためにサーバーにリクエストを投げる
4. サーバーから画面と内容を表示するためのデータを貰う
5. そのデータを使って画面と内容をレンダリングする
この状態になってるからだよ
SPAのためのindex.htm/jsの読み込みと（そのURLで示される）データの読み込みを
二段階に分けてしまうからそうなる
SPAでデータがない時に404を返したければ、リクエストを2回に分けるのではなく
2. と 4. の内容をまとめて1回で行うようにする。
そうすれば404が返せるし、パフォーマンスアップにもつながる
クローラーはURLを直接入力したときと同じように取得するわけだから
facebookで存在しないページをクロールしてしまうことはない。
（GoogleBotはJavaScriptを実行するとかSPAだからとかいうのは全く関係ない話）
> 2. と 4. の内容をまとめて1回で行うようにする。
補足 ↑言っておくけど、これはサーバーサイドでレンダリングするって話じゃない
HTMLにJSONを埋め込めばいいだけ
っていうのは前スレのこれを呼んでいればわかるはずだが
ttps://mevius.5ch.net/test/read.cgi/tech/1427008785/889 ttps://qiita.com/takeshy/items/b7e1b6bd30d12ecb02c6 > 1.データを別々にAjaxで取得
> 各CollectionやModelがRESTを使ってデータをAjaxで取得するので、
> リクエスト数が多くて遅くなる上に、ブラウザの同じサイトに対しての同時リクエスト数制限にひっかかります。
> 1.に関しては、初期画面のHTMLにAjaxで取得予定のデータを予め埋め込んでしまい、
> 初期データとして使うことで初期画面表示時のAjax呼び出しをなくしました。
ttps://qiita.com/takeshy/items/ba8b3ee4606993c1c5b8 > 初期表示時にサーバとの通信を極力行わない
> SPAで作成する場合、各モデルごとにサーバとデータを同期する必要がありますが、
> データを初期のHTMLにJSONデータとして埋め込んでしまうことで、Ajax通信を回避することが可能です。
HTTP2だってあるし、ブラウザもESMの導入で依存関係が1000を超えるようなケースが出てきてるので
パッケージング仕様標準化も含め最適化に乗り出してるしさ
そもそもSPAならServiceWorkerでCache使うだろうと
化石は化石として、現場を荒らすような真似はせずシーラカンスのように漂っててほしいな。
ちゃんと書いてあるでしょ
レスだけして、反論の一つもないってどういうことだよｗ
悔しかったからレスしたが、言い返せるものは何もなかったって
言ってるようなもんだよ
chrome-extensionと連携するサービスですがその中でお金のかかるapiを使おうとしています。(例えばGoogleTranslateAPI等)
自作のchrome-extensionユーザーには
(私が自腹を切るので)無料で使ってもらおうと思っているのですが、
chrome-extension以外のユーザーからは使ってもらいたくありません。
その場合どうやって制約をかければいいでしょうか？
一応考えているのはproxyとなるapiサーバを作って
ユーザー認証を行いそこから使ってもらおうと考えているのですか
トークンはsessionStorageに配置しているのでそれを取られると
結局無断で使われてしまいます。
ttps://support.google.com/cloud/answer/6310037?hl=ja エラーなのかってことだな
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
await使いながらループ順を維持したいなら昔ながらのforを使うしかないんだろうか。
それって処理順序が不定じゃなくて
処理終了するタイミングの違いだろ。
処理終了を順序良くしたいなら同期処理するしかないのでは？
というか非同期にする意味がない。
あとasync-awaitでmap使うんだったらPromise.allを使ったほうがいいのでは？
Promise.allをmapっていってるとか？
参考:
ttps://qiita.com/m0a/items/6b3965295df92d7bb28d ↓
result = await Promise.all( ary.map( async v = await f( v ) ) )
理由は書いたとおり、awaitが使いたかったから。
同期的にやりたいのは山々なんだけど、非同期な関数が混ざってるから仕方なく。
Promise.allはもちろん使ってる。そうしないとPromise[]しか返ってこないし。
やっぱりforしかないのかな。
Promise-Iteration を使うとか
ttps://qiita.com/toniov/items/127267fb64a960e8166e それなら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
なるほど、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() })
それを真似してライブラリを作っても良いかもしれない
と言ってもいろいろあるわけで。どれのこと
これ
ttps://www.granfairs.com/blog/staff/local-storage-01 サイズ５MBしかないし単純のkey-value型でしょ
indexdbのほうが良い気がする。
手軽さはlocalStorageとsessionStorageのほうがはるかに上
要は適材適所
ハンドリングするにはどうすればいいでしょうか？
キーボードで選択&エンターされる場合もあるので
onclickは適当ではないと思います
キーボードでフォーカス＆enterした場合にもclickが発火するんですね
JavaScript・ブラウザ関連の質問も、web制作管理板へ書き込む方が良い
そうだよ。jQueryの機能ではなくDOM API自体がそうなってる
他の部分をクリックした時にそのUI部品を閉じる、
というような処理をする時は
UI表示時にclickなどのハンドラをセットして
自分以外の部分がクリックされていたら自分を消してハンドラを削除する、
というようなやり方をするのでしょうか？
そのために各環境向けに調整することを許された標準要素がある
それらを再実装することは最もやってはいけないこと
標準要素に出来る限り頼って軽くスタイルをあてるだけが良い
bootstrapは再実装してるよ
documentレベルにハンドラ追加して
バブルアップしてきたイベントで対応
そういうのはサポート環境決まった上で
きちんと検証してユーザーからのフィードバックもしてるからね
個人ではそれは無理
多数の意見？
上は試しました。
初歩的な質問なのかもしれませんが、ブラウザ上のpixel座標と全く違う箇所をクリックしてしまいます。
どうしたらいけますでしょうか？
セレクトボックスを再実装すべきではないということですが、
セレクトボックスは
通常CSSで実装されるドロップダウンメニューの
メインメニューが一つになったものと考えられるので、そこまで難解ではないのでは？
select要素だと項目の最大の文字数によってサイズが規定されますが
それを避けたいので、再実装しています
デレゲーションですね
考えてみればいちいちハンドラの付け外しをする必要なかったです
ありがとうございました
例えばスマホでは画面が小さいのでselect要素が選択された時、文字が拡大表示される
これからはスマートウォッチのような超小型デバイスで見られるかもしれないし、
標準要素を使えば操作に関してもデバイスや閲覧者のハンデに応じた補正が入る
それらを全て再実装することは不可能なのですべきではないということ
もしそれっぽくデザインしてもそれが別の環境では改悪になることもある
Webっていうのは様々なデバイスで様々に見られる柔軟性が良いのであって
Flashが廃れてHTML5が栄えた理由の一つもFlashがスマホという新しい環境に適応できなかったから
だから自分の好きなデザインで固定化するという悪歴史の繰り返しは避けないといけない
それがサイトの構成上本当にどうしても必要なものであれば良い
でもデザイン上自作したほうが良いように思えるという理由ならやめとけ
そうはいかない場合もありますよね
なんとか元のタグを生かそうとしたのですが機能上不可能だったので自分で実装しました
人の忠告を聞く気がないなら初めから自分で好きにやればいい
JavaScriptに精通している事、とあるのですが、どのレベルまで行っていれば
その条件を満たしていると考えてよいでしょうか？
具体例などを挙げて頂けると幸いです。
会社によっても違うかと。
teratailでスコアをある程度jsで取れてる？
qiitaに、記事を書いてる？
検討してみます。
いえ、teratailやqiitaにはノータッチです…。
処理を細切れにasync即時関数にするくらいしかないのかな。
yield (async () => {
})();
もうちょっと目に優しい方法があると良いが。
あと、ESで言うとどのバージョンに含まれる仕様なんだろうか。
一番いい方法はどういったものですか？
lodashの_.differenceメソッドを使用する
ttps://lodash.com/docs/4.17.5#difference _.difference([2, 1], [2, 3]);
// => [1]
これはいいですね
ありがとうございました
バニラならfilterで
var foo = [1,2,3,4,5]
var bar = [2,4,6]
foo.filter(x => !bar.includes(x))
//=> [1,3,5]
バーニラ バニラ バーニラ
いいね、今は一行で書けるんだな。
こんだけのことのためにlodash導入とかご苦労なこってｗｗｗ
_.difference(foo, foo);
foo.filter(x => !bar.includes(x))
_ difference foo foo ・・・4ワード
foo filter x => ! bar includes x ・・・8ワード
二倍違ってるし、バニラだと
「filterでincludeしてないのを除く」ということの
意味を考えないといけない
さらにlodashは古いブラウザでも動く
バカが。lodashロードするのに1行必要だ。
javascriptのレベルで考えるなら数十行の追加に等しい。
以下lodashのdifference実装だが
さらにbaseDifference, baseFlatten, isArrayLikeObjectも読み込んでる。
function difference(array, ...values) {
return isArrayLikeObject(array)
? baseDifference(array, baseFlatten(values, 1, isArrayLikeObject, true))
: []
}
ttp://https://github.com/lodash/lodash/blob/master/difference.js">ttps://github.com/lodash/lodash/blob/master/difference.js 8ワードどころじゃ済まないなｗ
高々 ： デフォルトの名無しさん [sage] 2018/03/11(日) 10:34:30.08:GDHggCkQ
l o d a s h 完 敗
問題は自分の作業がどれだけ減るかだろ。テストも含めて
lodashのdifferenceはすでに十分テストされてる
それからお前のコードは配列の差集合をもとめることだけなのか？
実際に仕事してりゃもっとたくさんのことやるだろ。
それがlodash使うことで大幅に減るんだよ
javascriptではないのですか？
一方はコンソールでそのまま実行できました！
これはjavascriptなんですね？ありがとうございます！
何でもかんでも自分で書くようになって
下手なコードた大量に生産されます。
初心者「こんなにたくさん書いたんだぜ時間もかかったすごいだろ！」
differenceはjavascriptのAPIではないよ。
外部のライブラリだから別途ロードしないといけないし、リファレンスもjavascriptのじゃなくてそのライブラリのを調べないといけない。
君のプロジェクトが他のライブラリ採用してたら全く役に立たないね。
はfilterもincludesも標準javascript APIだから外部ライブラリのロードなしに使えるし、javascriptのリファレンスにも載ってるよ。
ここはお仕事相談所ではありません
JavaScript を自ら学ぶ人のための質問スレッドです
とにかく楽がしたい人はお呼びではありません
問題はjQueryというライブラリでもフレームワークでもない
独自世界を提供する強すぎる存在がいてバランスを崩していること
まだ標準と対立することで標準側にいい影響を与えてくれるなら良いのだが
jQueryの開発者もそうだし、特にその利用者なんて全くその気がないのが問題
昔っから『JSをJavaと呼ぶ』問題があるが、それ以上に『jQueryとJSの関係性が分からない』問題が酷い
ここでも良く、便利だから、簡潔だから初学者にはとりあえずjQuery使って教えれば良いんだよ
という論調の奴が度々湧くがそれは大変危険
なぜならjQueryはWeb APIとの親和性が極めて中途半端で、水と油のように馴染めない存在だから
極論を言えば同じJSでもjQuery中心で始めるかどうかで、それぞれ別言語を習ってると言っても良い
jQueryと非jQuery派にはシナジーがほとんど無くただ食い合ってるだけっていうのが本当に深刻な問題
これからのExtensible Web精神やそれに基づいて生まれてくるだろう大量のライブラリとも強く反発する
ttp://https://jquery.com/">ttps://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に準拠している
ttps://api.jquery.com/category/events/event-object/ > jQuery's event system normalizes the event object according to W3C standards.
たまに ： デフォルトの名無しさん [sage] 2018/03/12(月) 22:18:02.24:g7F15aU3
間違いなくgoogleやappleやfacebookやらの連中だよ
そいつらが2000年前後に無責任なhackを推し進めたことで生まれた問題だ
jQuery が原因ではない、採用した奴らが悪い
「IEが糞、IEは時代遅れ、IEは解釈を誤っている、IEは...」とか言ってブラウザ主導で機能拡張しまくった奴らも同罪
HTMLはただの「ドキュメント」だ「文章」が正しく表示されればその役割を果たしたと言える
それをHTMLを「アプリケーションプラットホーム」と勘違いしてる一部の狂信者たちがバカみたいに機能拡張しまくるからこんなことになる
何が乱立するのが正しい、だ
くたばれ
上の方にこんな記事見つかったぜ
見事にjQueryがExtensible Webにいい影響を与えたって例に出てるぜ？
根拠なくjQueryが阻害してるとかいうのやめてもらおうか？
Extensible Web
ttps://html5experts.jp/iwase/10825/ > しかし近年、Webの開発者が先導して、ブラウザの新機能へ影響を与えるケースが
> 出てきています。 例えば、querySelector や、Object.observe が具体例です。
> これらの例は、以下のフィードバックループによって生まれてきています：
> Webに本当に必要な機能を生み出すためには、 上記のように、
> ユースケースに沿った実践的なフィードバックループを回すことが重要です。
>
> 既にこのプロセスはWeb標準化にも取り込まれています。例をあげると、
>
> ライブラリ例 標準化された例
> jQuery querySelector
> Ember, AngularJS Object.observe
> Sass, Less CSS Variables
> jQuery で実践的に有効性が示され、querySelectorとして標準化されました。
> これにより、jQueryのパフォーマンスは向上し、さらに Zepto.js のような
> 軽量化ライブラリが登場・・・といったWebの好循環を起こしました。
俺はシナジーは「ほとんど」無いと言った
逆に言うと数個はあったと認めてる
それ以上に害が大きいということ
なぜならjQueryなどを参考にした機能が標準にも入ったことで
似てるがやや違う機能というのが多くなってしまったというのも事実だから
つまり標準を補うものではなく、ただ「中途半端」に対立している別世界の存在になってしまっている
最も、「初心者の理解を阻害すること」については同意するが
その２つには因果関係は無いかもしれないが、
jQueryのあり方とその２つは因果関係がある
jQueryっていうのは、つまらん標準のフォローと、それだけではなく
実装の混乱からWeb技術者を守るために生まれた
その当時の存在っていうのは大変素晴らしいものであった
大きい存在が居ることは良いことにもなり得る
実際jQueryはWebに良い影響も与えた
でも現在は大袈裟に言うとユーザーを二分してしまっている
別にjQueryが悪いんじゃない、むしろ最初覚えるのがライブラリからと
思わせてるっていうのは、標準や環境が悪いのだろうよ
でもそれを初学者に頑なに勧める回答者も悪いよ
Webっていうのは先にどんどん進んでいくものだし、先に勧めていかないといけないからね
今この瞬間この場で適当な回答ができれば良いんじゃない
教えた初学者がそのうち自分たちと共にWebを作っていくようになるんだから
IEだって見方によってはActiveXObjectだったり、いろいろ協力で素晴らしい技術を提供していた
でもそれを悪だと言わないといけないし、現状どうしても無視できない存在でも
あえて切るべきと唱え続けなければいけないときっていうのがある
jQueryも今からそういう立場になっていくってことだよ
それであんたの言いたい害ってなに？
別世界でも何でもないなｗ
そうあってほしい。でも理由はなにもない。
だから俺が理由を書いてあげよう。
AngularやReactがなぜ普及しないのか？
それはJavaScriptの世界を作ろうとしているから
残念ながらウェブのほとんどはJavaScriptを必要としない世界
そもそもHTMLが文書を書くために作られたもので、
世の中の大半は静的な文書で成り立ってる 例 Wikipedia、ブログ
もちろん一部にJavaScriptを使っているわけだが、一部なんだよ、一部。
AngularやReactなどのフレームワークはほぼ全てにJavaScriptを
導入しようとしている。そんなもん望んでないのにね。
よく知られた事実として、jQueryのシェアは伸び続けている
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
ttps://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）の延長技術であって
そうでないものは欲しいと思ってない。それが現実なんだよね。
つまり、おまえさんの言いたいことはこういうことか？
「これから廃れる運命にあるjQueryを今更、勧めるな」
では、これから発展する仮想DOM系は初心者に進めて良いと？(そういう問題でもないと思うのだが)
てっきり、おまえさんの主張は「なぜならjQueryはWeb APIとの親和性が極めて中途半端で、水と油のように馴染めない存在だから」関係だと思ったんだがな
俺が初心者にjQueryを勧めるべきではないと思う理由は、初心者にとって、jQueryオブジェクトにラップされたコードを理解するのは困難だからだ
初心者がjQueryから学習を始めると、
・これってjQueryでどう書きますか？(明らかにESの範疇)
・〜はjQueryでないと出来ないんですね(ピュアJSで出来ないと思ってる)
のように、jQueryで出来ることと出来ないことの区別が全く出来ず、見当違いの方向に理解を進める
jQueryに限った問題ではないが、jQueryはよく分からなくても書けてしまう(サンプルコードが多い)が為にそういう傾向が強い
> 見当違いの方向に理解を進める
じゃあその見当違いにならないように説明すればおしまい
コードもわかりやすく簡潔に書けない
主張は3行以内で明確に
ちょっと言いたいことが違うかな
どちらかと言うとIEガーと言ってほしくない
それでブラウザ互換をどうこうでjQueryを「必須のように」言ってほしくない
そういう一部の仕事の実情がJavaScriptという世界の全てだと考えてほしくない
それは世界の中心かもしれないが、巨大な世界からしてみれば小さいコアでしかない
そしてやっぱり最初は「義務教育の学校」のように「綺麗事」でシンプルに教えていくべきで
血汗涙にまみれた現場で生き残っていくための「今」役に立つ「生の」実践テクニックは
初学者を卒業して応用が効くようになって、「今」実務コードが書ける用になった時「専門学校」で習うべきことだと思う
別にjQueryの質問をしてくる初心者がどうのこうのは関係がない
本当に未熟な初学者にjQueryが必須のように教えるのは良くないと言うだけ
そして実際に教えていることというよりも、そういうスタンスだということが何度も表明されているので反発してるだけ
あとは他のフレームワークでも同じだよ
それがベースで依存するような学ばせ方をしてはいけない
でも、いつもかつもなんでもかんでも１つのフレームワークに依存するようなことなんて無いし、
ライブラリだって拡張として小さく必要のために使ってるのなら問題ないんだよ
jQueryはその常識から外れた大きすぎる存在だから特に注意ってだけ
麻薬のようなもの
だから複数のフレームワークを同時に使うことが難しい
フレームワークの導入や変更は大変な作業になる
だけどjQueryはライブラリなので、コードの一部だけ
使ったり使わなかったりできる。
仮に必要なくなったら徐々に減らすこともできるし
徐々にjQuery使うようにもできる
が勘違いしているのはjQueryはウェブアプリでは
多くの場面に使えるから使用してる量が増えているだけのことを
まるでjQueryに依存してしまう（逃れられない）と思っていること
jQueryはDOM APIを混ぜても便利に使える。
その証拠が$関数を始めとしてjQueryの多くのAPIは
DOM要素を引数にすることができるし、イベントハンドラのthisもDOM要素
フレームワークは導入するのは大変な作業になるが
jQueryは使うのをやめるのも簡単なので安心して気軽に導入できる
それからよくjQueryは上手く扱えるという奴が居るが、それは経験あるお前だから、そしてJS波乱期からライブラリの発展をそれなりに体験している俺たちだから言えること
自分が言ってるのは赤ちゃんにスマホを持たせて、鉛筆で字を書かせたり本を読んだり砂場で遊んだり、何かを為すため体を使い苦労して作った経験が極めて少ない事になると
実際基本的に普段それをする必要が無いとしても、不便である素な経験がない事で困ることは出てくるし、広い意味でその子がスマホ以外の素の実世界の発展のために活躍できにくくなるということ
> 違う、JavaScriptのJの字しか知らないような奴に、標準DOM APIなんて使えたもんじゃない、覚える必要も無いと言うことを思わすなということ
出だしから間違えてるよね？
誰が「標準DOM APIなんて使えたもんじゃない、覚える必要もない」などと言った？
俺は言ってない。じゃあ誰か？
お前だよ。何者でもないお前が「標準DOM APIなんて使えたもんじゃない、覚える必要もない」って
言ってるんだよ。
もう一つの間違いは「JavaScriptのJの字しか知らないような奴」
JavaScriptのJの字しか知らないような奴だと誰が証明した？
本人がそう名乗っているわけじゃない。他人がわかるはずがない。
つまり、これもお前なんだよ。何者でもないお前がそう言ってるんだよ。
ようするにな、お前は自分が作り出した敵と戦ってるだけだ
他人の発言遮るっていうのはjQueryの話をするなだけじゃなくて
そいつは低レベルだから（思い込み）高度な話はするなと遮ることも含まれる
こいつは赤ちゃんだからといってレスの内容を変えるのは
傲慢な考え以外の何物でもない
自分の考えを発言しろというのは、誰かがjQueryを使った解答をしたら
それを遮るんじゃなくて、自分の考え、つまりDOM APIを使った解答をしろということ
他人の足を引っ張るな。自分の考えを発言しろ。
なんも知らない人がググるであろう「js ライブラリ フレームワーク」
とか検索するとjQueryやめとけ系の記事いっぱいでてくるぞ
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
ttps://medaka.5ch.net/test/read.cgi/prog/1485008061/ jQueryを使わない = DOM操作をしない = DOM APIも使わない
これなら理屈にあってるんですよ。
今のフレームワークはDOM APIを使わないですからね。
でもjQueryで解決できることなら、そりゃ当然jQueryで回答しますわ
なぜjQueryで回答できるような質問ばかりなのでしょうか？
それこそが結論ですよ。JavaScriptのフレームワークはほとんど使われてない証拠です。
英語のスレで英語のスラングで答えるようなもんだから何の問題もない
間違った答えを言ってないことは確定なんだよ
ここまでずっと１スレに１回は議論のなかでそういう論がでている
一部のjQueryニキの潜在意識にあるのは確実
JavaScriptのJの字しか知らないような奴でないと誰が証明した？
そうかもしれない奴にjQueryを勧誘するなということ
勘違いしてほしくないが自分はjQueryの回答をするなというつもりはない
個々の質問への回答としてライブラリを使う例があれば勿論そのほうが良い
だが、具体的な例で言うと
誰かがライブラリ使わずに回答したらやれ互換性だのコードの短さだの主張して
ライブラリを使うべきという論争が始まるだろ
自分からすると、それこそ足を引っ張るなと言いたいね
俺たちはそういうライブラリの長所は視野が狭く誇張されたものだと思ってるし、
実際は何も使わなく書くことが無いとしても、
一般例として教え習うときはそういう「特殊な」ライブラリを使わないほうがいいと考えてるんだよ
そして「全体として」過度にライブラリを推すのは自重すべきだと感じてる
反ライブラリ派の多くは、結局そういうライブラリ使いの
短絡的なドヤ思想が嫌いなんだよ
こっちは地道に初心者を育てようとしてるんだから足を引っ張らないで欲しい
一生懸命近所の子供に筆算のやり方教えようとしてたら
変なおっさんが、そんな物、非効率だし不確かだから、電卓を使う法が良い
と言ったような感じを自分たちはいつも感じてる
本人に変な気がなくとも実際妨害されるし、
それによって子どもたちが筆算の必要性軽視してしまったらショックだろ？
何事も最初から楽するなと言いたい
そして何が普通か分からないうちの奴は、「騙して」でも
きついことさせて鍛えさせるんだよ
そうしないと極論育ったときに使い捨てになるだけ
自分はせっかくここであえて回答させてもらう関係になったのだから
この一瞬の経験で今後も良い影響を与えたいし、
立派な子に育って欲しいと思ってるんだよ
これはエゴだが、自分は5chのJS質問スレ2,30くらいからずっといる身として
ここは淡白なその場よければ終わりの一問一答スレになるべきではないと思ってる
無駄な指摘だったな。
また質問者を子供扱いですか？
それが傲慢だっての
とはいえ双方の言い分は分かるが、俺は ID:oazhajsT を支持する。
> 楽するな
この言い方は角が立つから「ずっとブラックボックス扱いではいけない」と言った方がいい。
中で何が行われているか理解した上で手抜きするのと、
なんだか分からないがこうすれば出来るからいい、ではその後の理解が違ってくる。
そして前者はつぶしが利くが、後者は環境（フレームワーク等）を変えたら全部覚え直しだ。
プログラマとしてやっていくつもりなら、前者でなくては話にならない。
例えて言うなら、連立方程式を逆行列の暗記で解くな、ということではないかな。
あれは「等式を並べて引いても『当然』等号は成立する」事を理解して
式変形していくことが「数学的に」重要なのであって、
「プログラミング的に」は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依存になるのは不味い。（使うのはかまわないにしても）
そしてこの板はプログラム技術板だ。理解をすっ飛ばしてちゃっちゃとやりたいだけならWeb板でいい。
・今お前が使っているブラウザですら動く物が作れない奴に、各種ブラウザ対応を説く必要はない。
というか、そいつらが独り立ちできる頃には解決されているかもしれんし、駄目ならそのときに教えればいい。
・実際、jQueryは上記のように「ちゃんとした」状況では使いどころがない。
だからプログラマとして「ちゃんとした」JavaScriptを学ぶつもりなら、除外しろ、と言うのも分からなくもない。
そして、実際、今後は「アプリ」のサイトでは次第に使われなくなっていくのも自明だ。使う理由がないから。
・jQueryは抽象レベルも中途半端。というかこれは使う側の問題だが、
DOM+「ちょっと」をワンライナーであちこちに書きまくるのは実はまずい。
それは関数として呼ばれるべき物であって。
だから何を関数化すべきか分からない初心者にとっては標準DOMの煩雑さの方がいいコードになりやすい。
（こういう教条的なのは俺は嫌いなのだが、初心者的に「1行ならインラインで、5行以上は関数で」とかだと、
なまじ1行であれこれ書けるが故に悲惨なことになる。
余談だがPHPも状況は似ていて、あれは標準自体がクソだから上達を阻害している。
Goもクソだが、Go/JavaScript/PHPしか知らない意識高いWeb系がGoに傾倒するのも分からなくもない)
彼らはその先の、正しくクラス等を構成したときのJavaScriptの速さ、CSSのメンテのしやすさ等を知ることがない。
ただ、これを知らなくてもいい連中(=デザイナ)も大量に混ざっているのも事実。
だからデザイナはWeb板で、プログラマはこの板で、と棲み分け、方向性もそう絞ればいいと思う。
jQueryは、60点のコードをお手軽に目指す為のものであって、実はどうやっても100点のコードにはならない。
（正確に言うと、100点のコードではjQueryが活躍する場所がほとんど無い）
これを分かった上で使い捨てのコードと割り切ってjQueryを使うのはありだが、
100点のコードをそもそも書けない（書く気がない）のはプログラマとしてはまずい。
ちなみに乱立については、JavaScriptはWeb的民主主義(気に入らないならforkしろ）で行くことにしているようだから、
これは民主主義のコストでしかない。
もちろん君たちが学んだことがフレームワーク等の頓死で全部無駄になるのも、当然として受け入れるしかない。
それが嫌なら全部標準でいけ、ということになる。実際、それでも大して苦労しないし。
事実としてjQueryは役に立つから広く使われており、これがJavaScriptを牽引したのも事実だろうが、
今後役割を縮小して行くのもまた事実だろう。
必要な機能は既に標準に取り込まれた。逆に言えば残りの機能はいらないって事だ。
そしてjQueryを学んだコストが全く無駄になる日もいつか来るし、受け入れるしかないんだよ。
いくら根拠のない決めつけ、思い込みで語ってもデータがなければ信頼性はゼロだしね
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
ttps://medaka.5ch.net/test/read.cgi/prog/1485008061/ 2018年の今は73.2%がjQueryを使ってる。未だに増え続けている。
しかも他のフレームワークよりも伸びは大きい
さて結局jQueryは使うのだから、残る問題勉強する順番なわけだがこれを読むと良いよ
挫折する学生が続出したゲーム制作、「学習の優先順位」を変えてみたら見違えるようにモチベが改善した話「ゲーム以外でも大事」
ttps://togetter.com/li/1202257 > 「Unityでゲーム作るならC言語から」という話題があるようですが、
> Unityを導入するのにあわせて、言語等の必須知識の学習を後回しにすることで、
> 学生のモチベが劇的に改善したらしい専門学校様のスライドがこちら。
言いたいことはこれのまんまだが、言語の勉強したいのでなければ、
つまり解决したい問題があるなら、その解決方法を提示するこそが初学者には重要
成果が見えるとモチベーションにつながる。
DOM APIを勉強するなとはいってない。jQueryの後で良いということ。
俺偉いよな。思い込みじゃなくてデータを示している。
ハッカーと遅延評価勉強法
ttp://d.hatena.ne.jp/LukeSilvia/20080402/1207149044 > 日本の（というかはてな界隈）ハッカーはほぼ「遅延評価勉強法」をしている気がします。
> ここから遅延評価勉強法とは、「その知識が必要になった時に初めて勉強する方法」です。
> もっと言えば、「○○を学んだから××をやってみる」ではなく、
> 「××をやりたいから○○を勉強する」と定義できます。
> 具体的遅延評価勉強法
> ここからは憶測ですが、遅延評価勉強法を具体的にやるとすれば、それは、「Webのソースを読む」、
> 「Webからコードを持ってきてごにょごにょいじってみる」ということになるのかなと思います。
>
> ハッカーに「良いプログラマーになるためにやることは？」と聞くと、「ソースを読む」ということが
> 必ずといって良いほどでてきます。逆に、「ソース読んでいない人はだめだ」という表現もよく言われていると思います。
>
> この「ソースを読む」とは、そもそも「これどうやって動いているんだ？」と思って
> 初めて実行するものだと思うのです。つまり、遅延評価勉強法です。
ttp://www.swatz.net/entry/2013/01/13/220400 > 学習効率を落とす「プロセス思考型」に陥っていないか
> 今日とある尊敬している起業家の人にグサリとささるご指摘をいただいた。
>
> 「プロセス思考型」に陥っていないか？
> 「プロセス思考型」とは
> プロセス、つまり過程であり、やり方や方法論をまず考える思考。それがプロセス思考型というらしい。
>
>
> そして、これは非常に学習効率が悪いと教えていたいただいた。
> このプロセス思考の最大の欠点は、非常にシンプルなものだった。
> 考えすぎて、行動を起こさない
>
> その通りすぎて、泣きそうになる。いやマジで。当たり前のことだが、目からウロコだった。
>
> 逆に学習効率の高いのは、これまたシンプルで、
>
> ひたすら行動を起こすこと
俺の行動にも当てはまるな。いろいろ言う前にjQueryでさっさっと答を書く（行動を起こす）
一方いろいろ言ってくるやつは、俺をどうやって追い出そうかの話ばかり考えて
行動（質問者にレスを返すこと）を起こさない
jQueryはJavaScriptのライブラリなのでスレ違いじゃないよ
そうは言ってもアセンブリのスレでエクセルマクロの話するやつはえんがちょやろ
質問するような人は初心者だからjQueryで答えればいい
実際君だけがjQuery派で、完全に四面楚歌だろ。
理由は簡単で、君以外には自明だからだよ。
jQueryは書く量を減らすことは出来るが、その程度でしかない。
HTMLが正しくクラス構成されていれば、そもそも書かずに済むんだよ。それを君は分かってない。
とはいえ、君は多分見たことがないだけだろうから、適当に探し出して試しに機能追加してみればいい。
あれ？っと思うほど簡単に機能追加できたりするから。
jQueryで答えて欲しいのならjQueryスレで質問しろ、ってことだろ。
> そうは言ってもアセンブリのスレでエクセルマクロの話するやつはえんがちょやろ
アセンブリのスレでアセンブリ用のライブラリはOKですね。
そういやアセンブリ用のライブラリはマクロ、通称マクロライブラリって言われてたね
> jQueryは書く量を減らすことは出来るが、その程度でしかない。
アセンブリ言語に比べれば、高級言語なんて全部
書く量を減らすことができる程度よ。
それが重要なんだけどな。
時間が減る、すなわちコストが減るという言い方にすれば
わかりやすいと思うが
だからそれが違うんだよ。
騙されたと思ってclassとID振りまくっているサイトのコードとか見てみろよ。
例えて言うなら、
jQuery： ゴミゴミした町でも、地図やナビがあれば問題なし
正しいHTML： いやそもそも区画整理して、地図なんか無くても迷わないようにしろ
なんだよ。
jQueryは汚い構成をごまかすのに便利だが、最初から美しく構成されてれば使いどころがないんだよ。
そしてその「美しく構成すること」に手間をかけろ、というのが正しいプログラミング道だ。
ただ、JavaScriptの問題は、上流行程のデザイナとPHPerがゴミばかりで、ゴミ処理ばっかさせられる点だ。
そしてそれが日常化しているから、問題だと気づけない。
(だからこれに関してはjQueryの責任ではないんだが…)
何が言いたいのか分からんが、
jQueryが要らなくなるならばDOM APIも要らなくなる
HTMLが汚いなら、DOM APIを使っていても、同じHTMLなんだから汚い
jQueryの話をまったくしてないよお前
綺麗なHTMLとCSSを正しく使われている場合
相性が良いんだよ。
水掛け論だからもういいけど、俺はjQueryは今後廃れる方向だと確信している。
理由はこれまで書いたとおり。
君がそう思わないのは君の自由。
どちらが正しいかは歴史が証明してくれるし、それを待つしかない。
根拠書いてないから説得力に書けるだろう？ 説明できないのさ。
だから代わって俺が説明するよ。具体的にね
良いプログラミングに必要なことに「宣言型」というのがある
「ﾌﾟﾘﾝｼﾌﾟﾙ ｵﾌﾞ ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ3年目までに身につけたい一生役立つ101の原理原則」の77ページ
ttps://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で書くと処理が含まれずに宣言的になってる。
がいう「美しく構成する」とか「正しいプログラミング道」というのは
まさにjQueryのことなんだよ。
もちろんjQueryを使ってもDOM APIの癖で命令型で書いてしまうやつがいる。
それはそいつの問題であって、そんなやつがこんな所に出てきたら
俺が矯正してあげているわけだがｗ
JavaScriptの問題点を解决している物の一つがjQueryなんだよ。
> 水掛け論だからもういいけど、俺はjQueryは今後廃れる方向だと確信している。
あんたの確信なんかどうでもいいんだわ
データが去年からの1年間で増えているってことのほうが
よっぽど信頼性が有る
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
ttps://medaka.5ch.net/test/read.cgi/prog/1485008061/ 2018年の今は73.2%がjQueryを使ってる。未だに増え続けている。
しかも他のフレームワークよりも伸びは大きい
君がそう思うのは自由なんだが、宣言型だけでは遅延描画が出来ないんだよ。
(正確に言うと、状態を持たないコードだけでは遅延描画は出来ない)
だから糞遅いコードになってしまう。
というか、当初俺は何でこんな遅いコードを何の恥じらいもなくこいつらは書くのか疑問だったんだが、
それが関数型()の洗脳の結果なんだよ。
実際、関数型()は何も成果を出せてないだろ。大騒ぎした割には、何も物にならなかった。
宣言的に書いて問題ないところは宣言的に書くべきだ。これは事実だが、
全部宣言的に書いていいわけではないんだよ。この点を関数型()の奴らは間違っている。
何事も適材適所はあるわけでね。
とはいえ、面倒だから全部ブラウザがやれ、JavaScriptは宣言型でしか書かない(ｷﾘｯ
ってのも最終的にはありだと思う。これはVirtualDOMとして動いてるんだろ。
ブラウザに内蔵されて全自動になれば俺は使うし、コードも変更するが、
それはそのときの話。まだまだ先だよ。
というかね、糞重いサイトとか大体コードが糞なわけで、
関数型()の奴らは命令型で書けないことを隠す為に「宣言的に書く」と言い訳しているだけ。
それが最適なら命令型で書くべきであってね。
動けばいいのなら何でもいいんだが、実際はそうじゃないだろ。JavaScriptはサクサク感が勝負であってさ。
そもそも○○であればいい！ってのは馬鹿であって、何事も適材適所なんだよ。
単純に宣言型にすれば見やすいとか見にくいとか、そういう話でもない。
そしてその辺を振り回して意味無い議論に終始するのがライブラリ厨が嫌われる理由だよ。
jQueryを使うことを必死で正当化しているだけだろ。
実際、ブラウザ間の差異は減ってきているし、jQueryが役に立つ局面は減る一方だ。これは事実だよ。
その上で、使った方が捗るというのなら使えばいい。
俺はメリット無いから使わないってだけ。
ほんと呆れたｗ
理由がさ、いきなり技術的な話
だからダメなんだよ。
ユースケース考えろ。誰が今jQueryを使っているか
そのjQueryを使っている人たちが、遅延描画できないって
騒いてるか？ 問題にすらしてないだろ
ほんと自分が言ってることが理由になってないのが
分かってないんだろうな。
その結果が2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
ttps://medaka.5ch.net/test/read.cgi/prog/1485008061/ > 騒いてるか？ 問題にすらしてないだろ
その結果、サイトがもっさりしてる。
でも技術力が無く改善できないから「問題ない」「こんな物です」と言い張っている。
勿論遅い理由はjQueryを使っていることで、だからこそjQueryを使わない事を肯定されたら困る。
それがお前が必死に抵抗している理由だろ。
jQuery使っている限り生JavaScriptの速度に勝てるはずもなく、
それ以前にjQuery厨は馬鹿だから速度チューニングもマトモに出来ない。
だから世界全体がとろいままでいてくれないと困る。
俺はそんなのにはつきあわない。サクサク感が勝負だ。
そして速いJavaScriptのコードをリリースすることによってjQueryの問題点を露呈させ、
jQueryしか使えない馬鹿共を淘汰することを目指す。
繰り返すが、問題ない部分は何やってもいいんだよ。
それこそjQueryでもフレームワークでも使えばいい。書きたいように書けばいい。
ただな、もっさり感に直結するところは速いコードが必要なんだよ。
それもしないjQeury厨はユーザを無視している。
今が廃れた結果なんだと思う
backbone.jsがでた当たり、5年以上前から必要な人は
どんどん脱jQueryをした。そしてほぼ全員が移行してしまった。
今残ってる70%以上のユーザーはそもそもJavaScriptのフレームワークを必要としない人たち。
必要な人達は移行済みなんだからこれ以上jQueryの利用者は減らない。
これからじゃない。もう（移行は）終わってしまったんだよ。
> その結果、サイトがもっさりしてる。
？ jQueryの方が軽いんやで？
Virtual DOMが速いのはウソだった。仮想DOMは遅い。
ttps://mevius.5ch.net/test/read.cgi/hp/1519842565/ 遅いところだけ局所的にチューニングすることが可能
> 今残ってる70%以上のユーザーはそもそもJavaScriptのフレームワークを必要としない人たち。
これは当たっている。
ただそれ以前に、HTMLが正しく作られていれば、生JavaScriptでも大して苦労しない。
jQueryは所詮糖衣構文を提供している程度であってね。
だから積極的に使う理由はないんだよ。
今俺は使ってない。jQueryによって速くなることもない。
てかお前もう話について来れてないな？
だからそれは駄目だとで言ったろ。
jQueryを使うのなら全面jQeuryじゃないとまずいんだよ。
> だから積極的に使う理由はないんだよ。
糖衣構文というのは、それが必要だと強く求められたから
使わないでできるのも限らず、採用されたんだよ。
その経緯を知ってるなら、糖衣構文だからこそ積極的に
使うべしってなるはずなんだが。
> 今俺は使ってない。jQueryによって速くなることもない。
> てかお前もう話について来れてないな？
ついてくると言うか、お前が明後日の方向にとんでいってるのを
眺めてる状態なんだがｗ
誰も速度なんて求めてない。
わかる？
> jQueryを使うのなら全面jQeuryじゃないとまずいんだよ。
全然まずくないよ。
問題点があるならば、問題点を修正するべきだが、
問題点として考えたれてない部分のパフォーマンスを上げることに意味はない。
最初に考えるべきは、それが問題かどうか
問題かどうかを検証する前に対処するな
具体的に言うならば、50msを5msにしてくれなんて誰も思ってない
だからそれが単なる糖衣じゃないのが問題なんだよ。
テキストベースでやってるから無駄にパースする必要があり、それも遅い理由だろ。
なるほどお前がやっているのはその程度なのだろう。それなら問題ない。
> テキストベースでやってるから無駄にパースする必要があり、それも遅い理由だろ。
テキストベースでなんてやってないけど？
そもそも遅くないし。
おい、全面jQuery化が必要なのは速度ではなくリークの問題だぞ。よく読め。
jQueryのインタフェースがテキストベースだろ。お前は何を言っているんだ？
> なるほどお前がやっているのはその程度なのだろう。それなら問題ない。
俺だけじゃないね。世界の7割以上がその程度なんだよ。
> おい、全面jQuery化が必要なのは速度ではなくリークの問題だぞ。よく読め。
jQuery使わなかったらリークするんだねｗ
> jQueryのインタフェースがテキストベースだろ。お前は何を言っているんだ？
何を言ってるんだよはお前だろｗ．
document.querySelector('#foo\bar');
DOM API自体がテキストベースだろｗ
マジで読め。
なるほどお前はjQueryもブラックボックスで中で何をやっているのか理解してないんだな。
まあいいよ、俺はこれまでもjQueryを使ってないし、今後も使うことはない。
君が使い続けるのは君の自由。
で、これ以上続ける理由無いよな？
> なるほどお前はjQueryもブラックボックスで中で何をやっているのか理解してないんだな。
知ってるが？ 今はブラウザがquerySelectorAllをサポートしていれば、
それに丸投げしてる。だからjQueryのインターフェースがテキストベースって
いうのが意味不明なんだが、お前はjQueryのソースコードが見れるのに
ブラックボックスって思っちゃってるんだなｗ
これ以上続ける理由がないというのなら
質問者にDOM API使って回答しろよｗ
俺は最初から質問者にjQueryを使って回答している
こんなくだらない話をやめるなら、
俺にかまってちゃんしてないで
俺みたく質問者に回答しろ
今度俺が質問者と話をしてる間に
よこから話しかけて来んなよ？
だってお前コード読んでないじゃん。例えば、
> フローがないと読みやすい
> 宣言型のコードは、順序や条件分岐がありません。純然たる事実が宣言的に書かれているため、
> コードが読みやすくなります。
> 一方、命令形のコードは、常に「状態」と「制御」と「データのフロー」を頭に描かないと、
> 事実を正確に理解できません。そのため、流れを追いながら読まなければならなくなります。
これ、間違いなんだよね。というかここだけ見ると間違いではないのだけど、
実際の所、こんな局所区画で読める読めない、という話にはならないんだよ。
だからこれドヤ顔で持ってくること自体が初心者の証。
といっても君には通じないだろうけどね。
> 今度俺が質問者と話をしてる間に
> よこから話しかけて来んなよ？
お前は誰と戦っているんだ？それは俺ではないぞ多分。
> これ、間違いなんだよね。というかここだけ見ると間違いではないのだけど、
> 実際の所、こんな局所区画で読める読めない、という話にはならないんだよ。
間違いと言うだけで、それがどう間違いなのか理由がない。
よーくみてください。理由がまったく書いてない
反論できないはずなのに、反論した気になってる
そういうレスなのです。
生暖かく見てあげましょうｗ
まあ俺はそういう煽って情報を出させようとする奴には情報をやらないことにしている。
というか、割と自明だから、どちらが正しいかは分かる奴には分かるし、それで十分だ。
お前は情報がないんだから出さなくていい
つうかね、多分君は数行のコードしか読んだこと無いんだよ。だからそういう発想になる。
数千行のコードを試しに読んでみろ。どこで引っかかるか分かるから。
jQueryみたいに数行の個別関数の固まりだと何万行あっても所詮数行の技術レベルで読めるんだよ。
そうではなく、一つのサイトのコードを読んでみろ。その場合は数千行で十分だ。
そうすれば、俺が何を言っているか分かるだろう。
俺は前から言っているが、お前にはこれが全く足りてないんだよ。
だからおかしな方向に走ってしまっている。
> そうすれば、俺が何を言っているか分かるだろう。
読んだ。わからなかった。以上。お前のターン。はい答えろ
（つきあってられるか）
じゃあ諦めろ。
というかマジで１回数千行のコード読んでみろ。色々違った物が見えるようになると思うよ。
ちなこっちについては教えておいてやる。
(つっても俺は使ってないから確認に時間がかかった)
ttps://qiita.com/kazu56/items/8e92d08fd1bba0a2d771 jQueryってDOMの生成とクエリを同じインタフェースにしてるだろ。
だから先頭に<があるかどうか確認しないといけない。これで無駄に遅くなる。
(しかもタグの書き方に自由度があり、これでも無駄に遅くなる)
というかその他諸々色々被せてあったと思うが。
まあ便利ではあるんだろうけど、動作速度はその分遅くなってるよ。
傍目からみてちょっとやりすぎ。無駄が多すぎ。
まあ君の問題はそこだよね。自分が問題ないと信じることは問題ないと言い張るだけ。
ただjQuery厨の問題はそこではなく、既に書いたとおり、
問題になっていたとしても絶対に宣言型で糞遅いコードを書くことだね。
そしてjQueryを使ったらjQueryロックされてしまうから生で書きまくるわけにも行かんし。
結果、逃げ場がなくなるという。（対策が出来なくなる）
まあ、jQueryが嫌われているのも理由があるって事だよ。君は認めないのだろうけど。
なんでその議論を無視して問題が有ることにしてるだか
こうやってお前の卑怯な手を俺がバラしてるから
続けても意味ないぞｗ
DOM APIを使ったコードと混ぜることができる。
jQueryを使って取得したものに対して、DOM APIで処理したり
逆にDOM APIで取得したものをjQueryで処理したりできる。
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';
});
var btn = document.getElementById('button')
btn.addEventListener('click', handler, false);
$('#button').on('click', handler);
function handler(e) {
alert(e.target.textContent);
}
だからそれは問題になるときもあるんだよ。
君がやっているコードの規模ではそうならないだけで。
ああそれと、俺は君を飼い慣らしてやろうと思っている奴だから、
他の連中よりは比較的風当たりはマシなはずだぜ。
(追い出すのではなく、有効活用しようとしている）
君がコードを書いて回答すること自体は俺は評価している。
ただなあ、ちょっとピントがずれてるんだよ。
だから君をちょっと教育して、もうちょっとマシな回答が出るようにしたい。
前から思っているけど、君には明らかに「大規模コード」の経験が足りてないんだよ。
だからそれをやれと本当に何度も言っている。
君は数行のコードにフォーカスしていて、それは十分出来ている。
だけどそれがプログラミング上問題になることはないんだよ。その辺を理解できていない。
数行のコードを綺麗に書く技術と、数千行のコードを纏める技術は別物なんだよ。
君には後者の視点が全くない。だから回答がちぐはぐになっている。
だから、騙されたと思って、マジでちょっとでかいの書いてみ？多分世界が広がるから。
そしたら今の君がずいぶんトンチンカンだったことも分かるだろうし。
> だからそれは問題になるときもあるんだよ。
> 君がやっているコードの規模ではそうならないだけで。
俺だけじゃない。世界の大部分が問題にならないっていったろ
大部分っていうのは全部じゃない。
俺と同じことを言うな。
お前が言ったことじゃない。俺が言ったことだ
大部分は問題にならないと
> 前から思っているけど、君には明らかに「大規模コード」の経験が足りてないんだよ。
> だからそれをやれと本当に何度も言っている。
説得力がない。まず行動を起こせ
俺に経験が足りないと口先だけでごまかすことは行動じゃない
まずお前がコードを書け
大規模経験者ならではだとわかるコードをな
> 数行のコードを綺麗に書く技術と、数千行のコードを纏める技術は別物なんだよ。
> 君には後者の視点が全くない。だから回答がちぐはぐになっている。
なんだ、大規模なコードを書いたことがないのはお前じゃないかｗ
関数一つやファイル一つで、数千行書くのは大規模なコードとは言わない
大変なだけなコードだ
大規模コードの開発者は、数行のコードの集まりで
数千行のコードを作るんだよ。
そんな事も知らないのか？
ttps://code.jquery.com/jquery-3.3.1.js お前の定義では大規模なコードになるだろうが、
ソースコードを見てみろ
ttps://github.com/jquery/jquery/tree/master/src それぞれが数十〜数百程度の短いコードのファイルがたくさんある
関数一つで見れば殆どが数行から数十行だ
それらをビルドでくっつけることで1万行を超えるコードにしてるんだよ。
数行のコードと数千行のコードで書き方が違うって
それはお前が大規模なコードの経験がないだけだ
どれも数行のコードの集まりでできてるだろうさ
俺から大規模なコードのプロジェクトを一つだしてあげよう
JavaScriptではなくRubyだが
ttps://github.com/gitlabhq/gitlabhq gitlabは大規模なコード中でもコードの品質が高いものだ
数行のコードの集まりでできてるぞ。ほとんどの関数はかなり短い
だからそれは既に言ったが、それは初心者でも読めるコードでしかないんだよ。
それをいくら読んでも今の君以上には上達しない。
てゆうか君がどうしたいのか俺にはさっぱり分からない。
上達する気があるのなら、俺がオススメするのは「大規模コードを書くこと」であって、
それは君自身がやらなければならないことだからいくら俺を煽っても意味がない。
俺を信じないのも君の自由だ。
コードの組み方にも色々あるのだけど、ライブラリみたいに平べったいコードばかり読んでても駄目なんだ。
いや、読むこと自体は悪くはないが、同じタイプのコードを何度読んでも駄目なんだ。引き出しが増えない。
だから今の君は平べったくないコードを読まないといけないのだけど、君にはここら辺の話も通じないだろ？
まあ君が上達すれば俺が今何を言っているか分かるだろうさ。どうするかは君の自由で。
ちなみに俺はjQuery厨を追い出そうとしているのではなく、改心させようとしている。
つまり、教育することで「jQuery使えばいいってわけではないんだな」と悟らせ、
結果的にjQuery厨を除去しようとしている。どうも食いついてこないのだが。
それは単純に考えて一番スマートな解決策とも言えるわけだけど、
こういう場で人に教えるにあたっては不味い点もあるということは分かるだろう？
だから理由かけって、
お前はこうなんだ！って言うばかりで、
なぜなのかその理由がまったく書かれてない
説得力ゼロなんだよ
こと言ってるが書いてるからなｗ
これもいつもの思い込み、決めつけ
一つのファイルで1万行超えるクソコードを再設計して最終的に
半分以下まで減らしたし（半分までで終わりな転職したから）
一人でやってるプロジェクトでも今数えたら4000行以上のものがある
（俺は数千行程度で大規模コードとは思わんが、お前がそう思うんならそうなんだろう）
Javascriptのアプリ作成でnpmとかbowerとかいうのを使うみたいなんですが、
コマンドを実行するとnpm_moduleというディレクトリとbower_componentsというディレクトリに数百ディレクトリ+数千ファイルが出来上がって怖いです
アプリ使ってくれる人がサイト見るたびに数千ファイルダウンロードとかやってられないと思うんですが、これ全部アップロードしないとダメなんでしょうか？
webpackとかparcelを使って一つのファイルに纏めて使うよ。
お早いご返信ありがとうございます
容量100MB超えていてどうなるかと思ったんですがwebpack試してみたらbundle.jsは1kb程度になったので一安心です
HTTP2とかにしたって選択して必要なものからプッシュで送っていくことができるようになってるのに
そういうメリット全部殺して１つに纏めるとか愚の骨頂だな
お前がそういう設定なのはお前の自由だが、誰も信じないよ。
お前が言っているような、
jQueryを使えば全てハッピー、コードも綺麗になるし問題は全て解決！なんて事には全くならない。
だからこそフレームワークが乱立しているわけでね。（それが上手くいっているかはさておき）
jQueryを廃止したがっている連中もかなりの数いて、ググればいくらでも出てくるだろ。
そしてそれもある程度妥当な意見なんだよ。これはちゃんと認めないと駄目だ。
君は「俺が正しい、お前が間違い」という言い方しかしないが、そういうことにはならない。
Web的民主主義では、各自が各自なりの解決策を考えて実行している。
そういう流れがあるってのは、一定数の支持を得ているから。
勿論jQueryを使い続けている奴もいるし、君がそうしたければそうすればいい。
たった数行のコードも書けないようなに対して、ライブラリを勧めるのは確かに間違っている。
それだと、いちいち引っかかる度に聞きに来るのか？となるだろ。きりがない。
少なくとも数行のコードは自分で書けるようにならないと話にならない。
美しくなくてもいいが、ちゃんと動くコードを自分で書けないと駄目なんだよ。まずはそこからだ。
逆に、その程度は書けるというのなら、質問者自身がそれを証明する必要がある。
大前提としてここは匿名掲示板なのだから、自分が何者かは全て投稿で決まるんだよ。
だから数行で書けることについて「一番いい方法」を単に聞くのは、
数行のコードも書けない馬鹿なクレクレ君だと言っているようなものだし、実際そんな扱いだろ。
書けるのなら、「俺はこう書いてみたが、どうもしっくりこない。もっと別の書き方がないか？」と言って
コードを出せば済む話であってね。
だから質問の仕方なりの回答をするのは極めて妥当で、
逆に、未熟者扱いされたくなければ、ちゃんとそうだと相手にも分かるような投稿をしないと駄目なんだ。
お前にはそういう、コミュニケーションする上での大前提ってのが欠けてる。だから話が空回りする。
再度言うが、あの質問に対してライブラリでの回答は不適切だ。
あと技術的観点で言うと、厳密に言えば、filterも_.differenceもシャローコピーを返すから
> ある配列から別の配列に存在する要素を削除する
事にはならない。
ただ実際はシャローコピーでも問題ない事が多いし、お前らも区別してないようだけど、
本当はこういうところをキッチリ詰めていかないと駄目なんだけどね。
とはいえそもそも質問者も区別できてないし、いちいち言う価値もないから放置だけどね。
> jQueryを使えば全てハッピー、コードも綺麗になるし問題は全て解決！なんて事には全くならない。
誰がそんなこと言ったの？
少なくとも俺は言っていない。
じゃあ誰が言ったのか？それはお前だよ。
お前が「jQueryを使えば全てハッピー、コードも綺麗になるし問題は全て解決！」
って言ってるんだよ
明らかになったし説得力がまったくない
人からどう思われるかが大事なことだぞ
君が世界の中心じゃないんだから
ちゃんとコミュニケーション取れるようになれよｗ
そんな話してないだろ
残念な奴
jQuery厨は池沼です！って自己紹介乙。
お前はそういうところが駄目なんだよ。
いいかい？今このスレにjQuery厨は君しかいない。
そしてその君が小学生レベルの論理でドヤ顔をしている。しかもに続き2回目だ。
どうやら君にはこれが切り札らしい。
それを見て、他の人がどう思うかだよ。
君が何をしたいのかさっぱり分からないのだけども、もしjQueryを布教したいのなら、
そんな幼稚な考えでいることを示したら、完全に逆効果だよ。
jQueryを必死で肯定している奴はこんな馬鹿しかいない、と取られてしまう。
はよく書けているし、全くその通りだよ。
そしてここは、最後に言った奴が勝つ場所ではなく、
双方が持論を勝手に述べあい、読者がどっちが正しいか勝手に判断する場所だ。
賢く振る舞うってのも重要なんだよ。
大体お前、自己矛盾にも気づけてない馬鹿だろ。
の論理に依れば、どんな大規模コードでも数行の関数の固まりだから読める、とお前は言う。
ならば、どんな長文でも単文の固まりでしかないわけだから、長文を読めないお前は矛盾するだろ。()
単文が読めれば、後は繰り返すだけなんだろ？
長文内部で論理を構成する技術なんて、存在しないんだろ？
プログラミングも同じなんだよ。
末端の関数を小綺麗に書くのと、それらを組み合わせて巨大論理を構成する技術は別物だ。
お前はここら辺を全く理解できてない。
そして、こんな事はいちいち俺が指摘しなくても他の連中も分かってる。
それで、俺と君の言い分を見比べて、どっちがマトモっぽく見えるかだよ。
コテハン付けてくれ
VS
俺は（jQueryで）回答したいだけ
別物だというのなら、なおのこと、
巨大論理（何そのオレオレ用語？）は今する話題じゃないな
末端の関数を小綺麗に書く話（質問者の質問自体が小さな関数の話なんだからしょうがない）を
している段階で、巨大論理しってるかー、巨大論理しってるかーって言われても
今その話関係ないですよね？で終わり
巨大論理の話したいならネタふれや。俺はそれにも対応できる。
まあオレオレ用語使ってる自体で、経験ないってわかるけどな
> ならば、どんな長文でも単文の固まりでしかないわけだから、
↑上記は間違い。
× どんな大規模コードでも数行の関数の固まりだから
○ どんな大規模コードでも数行の関数の固まりにするんだから
お前の超巨大なクソコード関数が、勝手に小さな塊になるわけじゃない
俺を含めたプロは小さな塊に"する" のだから当然読める
日本語でおｋ
というかやっぱりお前は馬鹿なんだよ。どうしてそういう話になっているのか、
またそれが明らかに技術用語ではなくてただの日本語だとも理解できないんだろ。
それが君が「長文を読めない理由」だ。君は論理を追えてない。日本語能力にも問題がある。
君がjQueryにこだわるのは君の自由だが、
他の人が怒っているのは、君の回答は質問者の為にならないから。
ピントがずれてるから、長期的には本人の為にならないんだよ。
だから君は邪魔者だとされ、他の人は君を追い出そうとしている。
俺は君の回答する姿勢だけは認めるから、君を有効活用しようとしている。
君がピントがずれている理由は俺には明確に分かるから、修正を試みている。
それで君が有効な回答が出来るようになれば、追い出そうとしていた奴らにとっても利益だろ。
というのは既に俺は言ったし、それ以前に読み返せば分かるだろ。
君は以前から話が複雑になったら定期的にサマリを求めるが、それは君が論理を追えないのを隠す為。
それは君が馬鹿だから。俺の話は終始一貫しているのだが、君はそうだとも気づけない。
プログラミング言語と自然言語は別物だが、この点に関しては同じだ。
君が77から始まる一連の流れ(約150レス）を追えないのは、君の頭の中の論理スコープが150レス分以下だから。
だから話の発端等がスコープ外になってしまって、君にとっては何がなんだか分からなくなってる。
そしてそのたびに君は定期的にサマリを求める。それは例えば以下もそうだろ。
> 長文で読みにくいなｗ ()
日本語を読めないのを隠す為に、読みにくいということにして短く書き直すことを求めている。
実際こう言われたら3行サマリを出す奴が多いから、君はこのやり方を覚えたんだろう。
だけどそれは君が気づいていないだけで、普通に話に付いていける人にとってはウザイだけ。
俺も何度も「それは既に言ったが」と言ってるだろ。
君の頭が悪いのは君の責任だ。話について来れなければ、分かるまで何度でも読み返せ。
それに対して他人の努力を求めるのはお前の傲慢だよ。お前が気づいていないだけでね。
だからそれ以上の論理を組まれると読めなくなっている。
これは普通の人よりはかなり馬鹿で、話が通じないキチガイだと取られて当然だ。
君の戦闘力が4だとすると、俺や他の人の戦闘力は150よりは上って事になる。それくらい差がある。
頭の中で論理を追えなくなったら読めなくなるのはプログラミング言語でも同じだ。
だから「必要論理スコープ」が小さくなるようにコードを書け、というのが最近の作法で、
具体的には「狭いスコープ」「短い関数」であり、上位レベルでやると「粗結合」「OOP」になる。
これ自体は悪いことではないんだが、問題は、この結果、
頭が悪いままのやつが淘汰されないことと、全く鍛えられないことだ。
マラソンを走れる奴がジョギングするから余裕があるのであって、
ジョギングしかできない奴がジョギングしてもそれはいっぱいいっぱいでしかない。
良いコードは能力値に余裕がある状態でないと書けない。
だから上達する為には能力値を上げることも一つの鍵であり、
これには限界近くまで負荷を高めないといけない。
電卓ばかり使っていたら計算能力なんて高くならないのは当たり前の話だ。
自分に計算能力がなかったら、自分で鍛えるしかない。
だから基礎の基礎の部分では敢えて苦労しろというのも当たってはいる。
これ自体は悪いことではない。
ただ問題は、実は粗結合はオーバーヘッドもかなり伴う、ということ。
俺が思うに、実行効率で10-100%、コード量で20-50%悪化する。
だからどこまで密結合で組み、どこから粗結合にするかはちゃんと設計しないといけない。
全面粗結合で書いたコードは簡単でいいが、逆に言うとそれだけが取り柄なんだよ。
クラスベースのHTMLについて、反対している奴はいないだろ。
これは当たり前の話で、HTML/CSS/JavaScriptの全てが見通し良くなるからだ。
ところがこれは難しいとも言われてるだろ。この理由も簡単で、
クラスを通してHTML/CSS/JavaScriptが密結合してしまうからだよ。
ただ、この程度の密結合なら、常人でも扱える範囲だ。だから「良い」とされているわけであって、
逆に、超人しか扱えないレベルなら、「そんなん使えるかボケ！」となる。
だからHTML/CSS/JavaScriptの世界は緩やかにクラスベースに移行していく。（てか今既にそうだが）
そして君はそれに付いていけない。
理由は君の頭の中のワーキングメモリが一般人比で著しく足りないから。つまり馬鹿だから。
だから俺はまずそれをさっさと増設しろ、それがお前の為にもなる、と言っている。
少なくとも、常人程度のワーキングメモリは持っておかないと駄目なんだ。
いろいろなところで付いていけないから。君が長文を読めないのもこれが理由だよ。
お前は今、淘汰されるべき側にいる。それを自覚しろ。
だからお前はその中でやりくりしているし、その世界しか知らないから、不自由を感じれない。
ところが俺たちは15GB積んでいて、400MBじゃ話にならない事も知っている。
それだけの違いがある。これがいろいろ話が通じない根本の理由だよ。
鍛える為には、日本語でなら、長文を何度も読んで読めるように努力することだね。
読んでいるうちから頭の部分を忘れているようでは話にならない。
JavaScriptでなら、「それなりに密結合した」大規模論理を書くことだね。
それは今君がやっている、ただ単にくっつけただけの平べったい論理構成ではだめだ。
とはいえ、JavaScriptのコードは確かにその類が多いのも事実ではあるが。
特にjQuery厨はそうなりやすい。これがjQueryの不味いところでもある。
(ただし既に言ったようにこれは使い方の問題であり、jQuery自体が不味いわけではない）
反jQueryの連中は、jQueryを使ってきていて、その中で様々な問題に遭遇していて、
環境が変わりつつある今、最早メリットよりもデメリットの方が上回る、という判断を自分でしている。
君は自分で判断する能力が無く、単に「みんなが使っているから」と繰り返すだけ。
まだメリットの方が上回るという見方ならさておき、君は何がデメリットなのかも理解できてない。
そこら辺がやっぱりズレてるんだよ。
マウント取りたがったところで、ちぐはぐさが痛いだけ。
もちろんその痛さを垂れ流すのも君の自由ではあるが。
話が読めてないのに長文書くから余計に主張の意味がわからん。
せめて話を読んでから長文書こうか。
俺の気に入る話しかするな、受け付けんぞっていってるだけだが
彼はあれだけの分量で誠意をもって話をしてるんだから
今は間違いなく彼が話の中心
話を読めていないのは君
誠意をもって適切な文量で返答しろ
小学生の作文の宿題みたいで微笑ましいｗ
簡潔な言葉でブレイクスルーを生み出そう
そして、読めない奴に限って「お前の文が悪い」としたがること。
これはプログラミング言語でも同じだ。
大規模プログラムがあったとして、それが読めないとき、
初心者は常に「コードが汚いから」と言うが、実際は「お前の頭が悪いだけ」だ。
今回もしかり。
お前らはそうやってずっと逃げてきているのだろうよ。
ただ、今後ともドキュメントは増える一方だし、読みこなす力も求められる一方だ。
2chの長文なんてリアルの論文なら序文程度にしかならないし、
お前ら普段からどんだけドキュメントを読んでないんだ？
これについてはマジで鍛えた方がいい。
今後のプログラマはドキュメントを読めないと話にならない。
BitCoinとかお前ら向きだと思うぞ。
ttp://www.kk-kernel.co.jp/qgis/HALTAK/FEBupload/nakamotosatoshi-paper.pdf いや、確実にお前の文が悪いだろｗ
違うよ。
伝わらなきゃ気に入るも気に入らないも無いよって言ってる。
こんな短い指摘も読めないのに長文書かないで。
頭の方で間違ったら軌道修正もめんどくさい。
ロードされた自身のアドレスを取得する方法ってありますか？
アドレスって？
無いから、ロードするときに変数に取っとくかDOMの属性に追加するか、iframe使うぐらいしか無いと思う。
パスのことです不正確ですいません
ありがとうございます
なんとかしてみます
JSとつきあってます
何倍も技術力上だと思うわ
jQueryのプラグインも作れるし、オリジナルのライブラリも作れる。
てかそういう事言ってると、OSのAPI使うしか能がないとか言えてしまうじゃん
自分で作ってもゴミが出来上がるだけなんだよね
そういうコードが書かれてるんだよjavascriptで。
そのjavascriptレベルの話をするスレで１ライブラリのAPIの話するって頭わいてんのか
お前の基準だとどのライブラリだって同じ1ライブラリ扱いにされてしまう
世の中には世界中で多く使われている品質が高いライブラリもあれば
個人が作ったそいつやその会社でしか使えないような覚える価値のないライブラリも有る
そういうのを取捨選択することも含めて
JavaScriptを使ったプログラミングなんだよ
に重なってしまうんだけどこれを解決するには
どうするのが一般的ですか？
Biggerlinkでリンクをdiv要素に拡大させた部分をクリックすると通常ウインドウで
開いてしまいます
これをうまく回避する方法はありますか？
誘導ありがとうございます
変数がとっちらかるのが気になるので、
各種フレームワークみたいにアプリケーション全体を包括するクラスを作って、
(new Application()).start()
みたいな形で全てを起動したいと思います
各種モジュールも、クラスのプロパティに読み込みたいと思います
でも、こういうやり方をJavaScript界ではあまり見ない気がします
何故でしょうか？
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の一般的なやり方は、
それはお前のやり方だろ？
イケてないのはお前だよ
このコードはクソだー！って叫んでる
なんて愚かなのだろうか
ばれないと思ったか？
何を言ってるかいまいちわからんが、メンバ変数が持てないから悪いって言ってるのかな？
それは、Javaで言うimport xxxx.yyyy.zzzzした、zzzzも同じようなもんだと思うが。
向いてないから辞めたら？
もう何年たつっけ？10年？
import/export
モジュールを全てクラスの属性にしてしまうと
jQueryとのバランスが美しくなかったりといまいちなことが分かりました
それに全てを一つのクラスにするのは、
コードをモジュールにするのと大差ないといえばありません
一番不満なのは、変数宣言や初期化の場所がとっちらかってることと
エントリーポイントが分かりにくいことなので
・変数宣言と初期化は、コードの先頭(require処理の後ろ)にまとめて置く
・エントリーポイントはmain関数にまとめる
・main関数はコードの末尾で呼び出す
としたら、
まぁクラス化しなくてもいいかと思える感じになりました
ありがとうございました
実は、Node.js だけでは面倒くさいから、それだけでは作らない。
Express + Express Generator フレームワークを使う
Node.jsは、Ruby で、Sinatra を、full scratch で書くのと同じ。
Express + Express Generatorが、Rails と同じ
だから先に、Rubyをやれば、フレームワークが理解しやすい
意味不明
jQueryって只のライブラリだよ？
ライブラリをクラスでどう使うよ？
クラスの中で使うでしょ。
単にDOM操作をjQueryで行うだけだよ
あんたが思うバランスの良いコードを
単にjQueryつかえばいいだけだよ
ttps://www.youtube.com/watch?v=k_0ZzvHbNBQ&list=PLillGF-RfqbYRpji8t4SxUkMxfowG4Kqp YouTube に動画ある
変数名で特定できるようにすればいいじゃん
やりたいことは「ポップアップ内の文字選択も出来るようにしたい」なのだけど、
かなり大きめのポップアップも出ることがあるので、今はポップアップ自体の移動を出来るようにしていて、
この結果、ポップアップ内の文字選択が出来なくなっている。（動いてしまうから）
今のカーソル形状が取れれば、テキスト用カーソルの時だけ移動しなければいいだけなのだが。
document.body.style.cursorには反映されてないところまでは確認した。
カーソル形状は単純には取れないようなので、（第一のガン）
mousedown でどこで押されたかを確認するようにしたのだが、
そもそもテキストノードは e.target に入らないので、（第二のガン）
親エレメントで受けるしかなく、そこから走査するしかない。
この場合、Element.getBoundingClientRect() を使って e.clientX 等と比較することになるが、
Nodeにはこのメソッドが無い。（第三のガン）
結果、テキストノード上のテキストへの当たり判定が出来ない。
（なおいちいち当たり判定しても、
文字列が行の途中で終わっているときに対応できない。---(A)
この場合、ブラウザは正しく文字の真上だけ文字選択カーソルにするが、
自前で走査すると文字列が終わった画面右の方でも当たりの判定になってしまう。）
これってマジ？
そうならAPIの不備だよね。経緯は色々あるのだとは思うが。
selection API (onselectstart) も試したが駄目だ。これも上記(A)の時に対応できてない。
こちらに見落としや違う方法での実装方法があるならご指摘よろしく。
希望としては、「文字の真上＝文字選択カーソルの時は選択、それ以外は移動」としたい。
ブラウザが当たり判定をした結果の「今のカーソル形状」が取れれば一番いいのだが。
もしブラウザの画面がそうだったら困るだろ？
ウィンドウには頭の部分にDnD可能なバーを付けるという「常識」があるのだから大人しくそれに従えばいいだけ
全面DnD可能にするのは動画窓くらいのもの
> ウィンドウには頭の部分にDnD可能なバーを付けるという「常識」があるのだから
ウインドウはそうだが、俺が言っているのはポップアップだ。
ポップアップにタイトルバーを付けたがる馬鹿はいないだろ。
俺はいちいちタイトルバーを触るＵＩはダサいと思ってるんだよ。
カーソルの形が変化するのだから、今どっちのモードかは誰でも分かる。
「文字」の上でDnDすれば文字選択、「余白」でDnDすれば移動、というだけだ。
PDFで言う「選択」と「手のひらツール」の自動切り替えでしかない。
動画窓なんて全面移動でいいのだからタイトルバーなんて付けてる馬鹿はいないだろ。
というか、昔は付いていたが、だんだんと外れて来て、最近は本当に動画部分だけになった。
余分な物は表示するべきではない、というのは当たってる。
確かに今から考えると昔の画面は無駄だったろ。スマホ（画面が狭い)の影響かもしれんが。
まあ、上記俺のＵＩに慣れたら、タイトルバーなんてダサいと思うようになると思うよ。
そして、俺はWindows等も同じ方向に行くと思っている。
とはいえ、結局やっぱり取れないのか？
せっかく当たり判定を全部ブラウザがやってくれてるのだから、結果だけ欲しいんだが。
stackoverflowとかも見たけど、やっぱり出来ないみたいなんだよね。
それに今回はどちらにせよ動画の話みたいにはできないだろ
動画の件とは逆にどこでもDnDできちゃ不味いという話なんだから
どちらにせよポップアップにDnDできる領域を作らないといけない
まさか文字の隙間でDnDしたいわけではないのだろう？
テキストの部分触ってもDnDできなくて、その周りの空白部分でDnDできるとか分かりにくいし
それなら空白の代わりにDnD可能そうなバーを付けたほうが明らかに良いだろう？
まあ別にそのバーをデザイン上の問題でどうしても透明にしようが何れにせよ
テキストとは別にDnD可能領域をつけることでできるよ
新入社員がパソコン使えないとニュースになる時代、バーを見てドラッグアンドドロップできそう！って思ってもらえるかね。
スマホアプリにはd&dできるバーなんて無いぞ。
TextNodeはDOMの仕組み的にElementじゃないからその手のメソッドは持ってないし、持つべきではない
普通に<span>とかのインライン要素で囲めば判定できる
ただ、1行選択する場合とかは余白からドラッグするのが一般的なので、使いにくい人もいるだろうね
スマホでもそんなUIを採用してる例はないし、長押しで移動モードとかの方がわかりやすいかもね
> まあ別にそのバーをデザイン上の問題でどうしても透明にしようが何れにせよ
> テキストとは別にDnD可能領域をつけることでできるよ
それは分かっているし、実際 autohide のタイトルバーも採用するつもりでいる。
ただし別件でだが。
> テキストの部分触ってもDnDできなくて、その周りの空白部分でDnDできるとか分かりにくいし
これで十分なんだよ。
カーソルが「文字選択」なら文字選択になるし、「それ以外」なら移動になる。
必要なら「移動」カーソルに変えておいてもいい。だったら見たとおりにしかならんだろ。
そもそもこの切り替えも付けるし。（全面移動か、上記自動切り替えか）
なお、デザイン上、余白部分はかなりあるから、つまむのに苦労するということはない。
というか「余白」という曖昧な表現を使っているから不味いのか？
例えば、PDF文書なら、通常左右の端から3cmずつくらいは必ず「余白」になってるだろ。
そして文字選択する場合、必ず当該文字の真上から開始するのだから、あれも単純に、
・文字領域の上からDnDを開始した場合、文字選択
・左右の余白領域の上からDnDを開始した場合、「手のひらツール」で文書そのものの移動
でよかったと思うんだよ。それでカーソル形状を変化させてれば、混乱しようもない。
例えば2chで同一IDや返信をポップアップするとして、数が多ければ１画面の高さを越えるだろ？
これと同じ。俺も必要なだけ出すから。これに対する解は、
A. ポップアップにタイトルバーとスクロールバーを装備（正規ウインドウ化）
B. ポップアップを元画面に固定、元画面のスクロールによってスクロールさせる…大体の2chブラウザがこれ
C. ポップアップ自体に移動/スクロール機能を付ける…現状だが文字選択が出来ない
D. Cに対して自動切り替え機能を導入し、文字選択できるようにする…これをやろうとしている
なんだよ。君がA推しなのはいいし、実際そうしているアプリもある。
ただ、今俺が試したいのはDなんだよ。多分混乱はしないし、一番いい解だと思うから。
Bは、元画面をそこまでしか読んでいないのに、
ポップアップを読む為にスクロールして、戻ってこないといけないのがウザイ。
Aは、ポップアップとしては不味いＵＩだと思っている。
ポップアップはタイトルバー等がないことによって「不完全なウインドウ」であることを明確にしている。
そしてそれは「不完全」だからこそ、自動消滅するということで辻褄が合っている。
「完全な」ウインドウが自動消滅するようでは不味いんだよ。俺はそこは、
・タイトルバー等を装備した「完全な」ウインドウは永続的であり、明示的消去動作のみによって消去される
・「不完全な」ウインドウは、自動消滅する
という、分かりやすいラインに従うべきだと思っている。
ポップアップを移動させたいが為だけでタイトルバーを付けてこの原則を崩すのは悪手だ。
ということを言い出してもきりがない。
所詮はGUIは感性の産物でユーザー主観でしかない。
だから全部実装してユーザ選択にするのがベストだし、最終的には多分そうする。
そして今回はDを実装して試そうとしているだけ。
> TextNodeはDOMの仕組み的にElementじゃない
見た目そんな感じだね。
> 持つべきではない
そんなわけない。TextNodeがTextElementであっても何も問題ないだろ。
> 普通に<span>とかのインライン要素で囲めば判定できる
出来ない。正確に言うと、出来ることを保証できない。
<span>で囲んだだけでCSSでは別扱いでき、フォントサイズ等が変更される可能性もある。
だからこの方法では「出来るときもある」だけであり、「出来る」というのは間違い。
ただなるべく無駄なことはしたくないので、DOM変更で対応するのは最後になる。
あと、この方法だと結局長方形としてしか扱えず、
複数行で最終行だけ短いとき等にも対応できない。
ブラウザ自身はこういう場合も問題なく当たり判定して、文字の上の時だけカーソルを変えている。
> 使いにくい人もいるだろうね
どのみちユーザ選択にするから問題ない。
> 長押しで移動モード
これはかなり最悪。ゆっくり選択することが出来なくなる。
右クリックメニューで「移動」「選択」モードの明示的切り替えの方がマシ。
今のところmousemove/downをdispatchEventしてSelectionが変化するか見ようとしているが、
反応しねえ。
もしくはSVGのforeignObjectにスタイルなどを適切に適応したポップアップ部分の複製を入れて
テキスト背景色などを調整した上Canvasに描画して当たり判定をする
知恵を貸してくれた皆様ありがとう。
Range.getClientRects()では文字単位でピクセル値も出せるから、当たり判定は問題なく出来た。
結局の所、俺がRangeを知らなかっただけだった。最初からこれでよかった。
というか、一般的にテキストの当たり判定は出来ないので、HTMLでもそうだと思いこんでいた。
なんだかんだでHTML周りはよくできている。（他のＧＵＩに比べて）
これについては、これまで何回か聞く人もいて、とずっと言われてたろ。
まあ俺もそう思っていたのだが、実はそうじゃなかった、というわけさ。
互換表を見る限り目新しいAPIというわけではなさそうだが、
普通は使わないから知名度が低いのも致し方無しか。
ちなみにuhyohyoでは解説されてる。
ttps://uhyohyo.net/javascript/8_1.html 正直俺はこのサイトの書き方は嫌いなのだが、ここの内容はいい。
こいつは少なくともある程度以上の腕だというのが読んでいても分かる。
JavaScriptを解説しているサイトって、初心者が一生懸命やった記録を残しました、
みたいなところばかりで、ポイントがずれているから、ミスリードされる。
この辺を自分で判別できない初心者ならuhyohyoを全部読むのもありだと思うぞ。
（結果的には俺がそうすべきだったわけだが)
RangeはNodeをElementにキャストできる。（意味的に）
だからNodeがElementの親でメソッドが足りない、という点はほぼ全て回避できるはず。
本来の使い方か？といわれたら微妙だが。
たまたま日本語だから上手く言ってるように見えるだけ
再生終了後に広告載ようとしてるのですが、
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="
ttps://www.yahoo.co.jp/"><img src="C9GWegFV0AA_j_m.jpg" width="150px" id ="a03" class="test2" /></a> </div>
とりあえず、開発者ツールでa hrefの実際の値を確認
書き換えられてなければ、イベントでpreventDefaultされてるんじゃない？
解決しました。ありがとうございました。
a hrefは書き換えはされていませんでした。
preventDefaultがされていたのが原因でした。
preventDefaultって機能の存在を知りませんでした。
jquery.jplayer.js
var handler = function(e) {
e.preventDefault();
};
どういうケースを想定しているのか知らんが、
字毎のboundingBox(＝マウスでなぞったときに反転するエリアのはず）が取れるから、
全て対応できると思うぞ。
気になるuniコードがあればこちらで試してみてもいいが。
言語やフォントやモードによっては日本語のぶら下がりのような禁則処理なんかで
ボックスからはみ出す場合もある
そう信じるのはお前の自由
ページはMDNのCSSサンプルページからで、ちょっとfiddleで試した。
ttps://developer.mozilla.org/ja/docs/Web/CSS/hyphens ttps://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 }
多分アラビア語とかになるんだろうけどマージンがある場合はBOXをはみ出して描画するようになってたと思う
BOX≒選択範囲だけどBOX≒描画範囲ではないからね
続け字が連続してきて何度もフォント設定の置換が入るとBOXがズレる仕様バグが残ってるし
「続け字」というのは詳しく知らんが、英語の筆記体のようなものだとすると、
それは文字間の区切りが曖昧なだけであって、最終結果のBoundingBoxをはみ出る理由にはならんだろ。
君が何故出来ないことにしたいのか分からんが、
レンダリングしている物(ブラウザ)が返してきている値なんだから普通は問題なく信用できるし、
ブラウザにバグがあるというのならそれはまた別の話だ。
仕様バグ、というのも何が言いたいのか分からんが、
BondingBoxに仕様バグも糞もない。
「表示領域を囲んだ矩形を返せ」以外の仕様なんてないし。
テキストの幅が取れることが分かったので、
ついでに間延びしている<input type="text'>について、
入力後にちょうどいい幅まで縮めようとしている。
前回ググッた時に見かけた覚えがあったのでだいぶ探してみたが、
どうやらcreateTextRange(IE専用）だったようだ。
chromeでやれる方法を知っている人がいれば教えて。
あるいはCSSで出来るというオチある？
見た目これはAPIを整備中、というところかな？
HTMLInputElementの継承とか見ると、オブジェクト指向しようとしている。
ttps://developer.mozilla.org/ja/docs/Web/API/HTMLInputElement なら内部文字列は textNode 扱いで Range 経由で取得というのが妥当だが、
<input>自体がHTML的に中途半端(終了タグがない等）だから、整備中か？
なおjQueryUI等にこの機能を持っている物があればそれも教えてくれれば助かる。
参考に見に行く。
基本的には、フォーカスが当たったらちょっと伸びて、
フォーカスが外れたら入力文字列をちょうど表示しているところまで縮めたい。
ただし span 等に変更することはなく、inputのままで、だ。
span 等に変更すると、見た目、入力が出来ないのか？と勘違いされそうなので。
なお selection -> range -> getBoundingClientRect等で取得は試したが駄目だった。
そもそもinput要素がどのように表示されるか厳密に決まっているわけではない
環境に応じて調整されたUIが表示ができるようにするための専用要素なのだから
それを細かく調整しようと思うこと自体が誤り
分からないなら黙ってればいいのに
文字列の幅を取得してすぐDOMから削除でいいのでは
そんな的外れなことばかり言ってるからJavaScripterは馬鹿なままなんだよ。
お前らは何が正しいかすら理解できていない。
そしてそれすら自覚できてないから間違った情報を拡散し、余計に馬鹿が再生産されてる。
それは本当に止めた方がいい。
環境依存の部分を自動的に隠蔽したいのなら、<span>と同様、自動伸縮すればいいだけ。
手動でやれというのなら、通常のオブジェクト指向のように、統合的に扱えればいいだけ。
<input type="text"></input>で入力が内部textNodeになれば、それが出来るだろ。
Webの場合はこの辺の「統合的」な視点が全く欠けており、三流プログラマのやり方になっている。
そしてそれしか知らないから「jQueryは素晴らしいとか」とか明らかに間違ったことを言い出す。
そもそもjQueryみたいなグルーライブラリが必要なこと自体が間違っているし、
実際他環境ではそんな物は必要ないんだよ。お前らは知らないのだろうけど。
とはいえHTMLは全体的にはよくできているのも事実だが。
(そして俺は今回はscrollWidthで解決できてしまえそうだ)
余談だが、よく言われている「上級者はコードが短い」というのは、これなんだよ。
お前らはjQueryみたいな糖衣構文を使って短くすることしか出来ないからそうだと言い張っているが、
或いは宣言的に書くから短くなる、ということにして関数型()マンセーしているが、
それは自ら馬鹿であると主張しているのと同じだ。
上級者は同じ記述スタイルでも書くコードが少なくて済むんだよ。
ただこれを説明するのは難しかったのだが、Webには分かりやすい例がある事に気づいた。
要するに、上級者のコードには無駄な if が無いんだよ。
よく言われているブラウザの互換性の問題では、無駄に if 文を書く必要があるだろ。
当然、統一しておいてくれよな、と思ったことはあるだろ。余分なコードが無くて済むから。
同じなんだよ。上級者のコードでは内部的な互換性が高く、いちいち処理を分ける必要がない。
余分なコードがないから、コードが短くなる。
糖衣構文で短くなっているわけではない。
ただ、この違いを理解できない馬鹿が一文字一句の「コードの短さ」のみを主張しているだけでね。
それは回りくどすぎる。というか悪いがその方法なら俺も当然知ってる。
というかな、上記にも絡むが、
・一通り出来ない＝初級者
・一通り出来る＝中級者 ←お前ら
・最適なやり方を選択できる＝上級者
なんだよ。
何かお題が与えられたとして、やり方が分からないは初級者。
とにかく実現は出来るは中級者。多分お前らはここが多い。
ただ、本当にそれが最適か考えないと、上級者にはなれない。お前らはこれを怠っているから上達しない。
今回、「本来の」順で考えるなら、
A. CSSに何かプロパティを設定したら、勝手に伸縮する (例；逆だが text-overflow: ellipsis 等）
B. 直接クエリできるメソッドを使う (例: createTextRange、ただしIE専用)
C. input自体の幅を変更して計測する
D. inputをcloneNodeして中身をコピーし、その場に貼り、不可視で計測する
E. spanに中身をコピーし、styleも全コピーし、どこかに貼り、不可視で計測する
だろ。styleのコピーがいる分EはDより面倒で「コードが増える。」
逆に言えばこれがないから「上級者のコードは短い」んだよ。糖衣構文で短いのではなくてね。
ＣはDよりもさらに簡単で、いったん width='0px' にすれば scrollWidth で幅が取れるというもの。
可視状態でやっていいのか？というのはあるが、現実的に問題なさそうだからこれで行く予定。
それとは別に、A, B が存在する可能性もあるから聞いたんだ。俺は仕様に詳しいわけではないから。
ただこれも、環境が整えば当然のごとく A, B が出来るようになるわけだが、
お前らはこれが出来るべきだとも理解できてないからおかしな事になってる。
糞な仕様につき合っており、それで満足してしまっていて、問題を感じていない。
ちゃんと「本来はどうあるべきなのか」を考えるようにしないと上達しない。
アホ
input要素が具体的にどのようなUIで表示されるかはHTMLの仕様外なんだよ
内部に入力テキストが表示されている必要も無いのだから
それに依存した動作をしようとすること自体がナンセンス
例えるなら右クリックメニューの内容に応じて何かをしたいと言ってるようなもの
それがどうしてもしたいならむしろ右クリックメニューを作れと言ってるんだよ
当たり前だろ
いろいろ言い訳してるやつとはレベルが違う
お前がそう思うのはお前の自由。
俺はそういうお前らが駆逐される日が来ることを願っている。
お前を含めて、JavaScript界隈には間違っていることを平気で垂れ流す奴が多すぎる。
それでお互いの足を引っ張り合っていて、結果的にお前らは本来あるべきレベルにも達していない。
俺は多少でもそれを是正し、結果的に次世代の成長を早め、（というより本来の成長速度に戻し）
結果的にお前らが駆逐される日が来るように誘導している。
> <input>自体がHTML的に中途半端(終了タグがない等）だから、整備中か？
終了タグがないのはinputは空要素だから。とかは基礎知識だから覚えとくといいよ。
世の中にはたくさん考慮する事があって、例えばinputの種類によっては削除ボタンとか、パスワードを可視化ボタンを出すブラウザもある。
他にもプレースホルダとか、入力状態のIMEをどう考えるのか？そうすると、単純にテキストを描画してるだけではないし、文字の横幅だけという訳にはいかない。
writing-mode:vertical-rlの場合はscrollWidthは期待した値にならないし、IMEやUnicodeの将来的な拡張にも備える必要がある。
とりあえず仕様とかわからんが、動けばいーやというのがお前みたいな初心者
何度も言うが、そう思うのはお前の自由。
他の人がどう取るかは、他の人の自由。
俺は初心者がお前みたいな馬鹿に騙され続けるのを止めようとしている。
それがJavaScript界の浄化に繋がると期待している。
そう思いたいならお前の自由だよｗ
分かってない君でいいんじゃないの
偉そうだが、中級者をけなすあなたは上級者なのか？
腕がよければ相手の力量を正確に見積もれるし、
逆に、見誤るようならそれはお前が無能である証明でしかない。
教えてもらったことの検証も間違ってたり、用語の使い方も不自然だったり
多分、Web以外の得意分野があると思い込んでるけど、実はそちらも中級者ぐらいとみた
console.log(GainNode.gain.value); とやっても常に同じ値しか出ない。
ADSR の R の部分を作ってて気づいたんだが、どうにも現在値が取得できないので困った。
仕方なく別の方法にしたけど… じゃあなんのための getter なんだこれは？
色で行ったらアルファ、もしくはcssみたいなもの
そして色と同じく音の大きさっていうのは相対的なものだし、
色の輝度と明度が違うように、音にも音量以外にも音圧があるし、
もちろん周波数によっても感じ方が違う
それとAudioParamのvalueは仕様上getterではなくただの値だぞ
内部プロパティもといネイティブ世界の値とリンクさせないといけないから
実装上アクセサになってるが、別にクオンタム毎の捜査/更新でも良いし、
ProxyやArrayのlengthのような実装の方が仕様に沿っているが
簡潔さを考えた場合にアクセサにしたのだろう
＞D. inputをcloneNodeして中身をコピーし、その場に貼り、不可視で計測する
＞E. spanに中身をコピーし、styleも全コピーし、どこかに貼り、不可視で計測する
＞styleのコピーがいる分EはDより面倒で「コードが増える。」
同じものを同じ場所に貼り付けたら同じスタイルになると無邪気に思っていらっしゃる感じかなー
他分野でスーパーエンジニアでいらっしゃるあなた様の考える仕様がどれだけ素晴らしいかは推し量るのも恐れ多いですけれども
Webのフロントエンドについてはブラウザの実装が全てなので、仕様に文句つけてる暇はなく、
糞仕様の糞APIに付き合うかラップしたフレームワークを作るか使うかしかないし、
APIに文句ばっかりつけてるうちは永遠にフロントエンド初心者だよ
> 糞仕様の糞APIに付き合うかラップしたフレームワークを作るか使うかしかないし、
その通りだ。だから俺は一番マシな解法でやる。それは既に示した。
それよりもマシな解を示せるのなら偉ぶって構わないとは思うが、
そうではないのにお前らがただ上級者ぶるのは俺には理解不能だ。
それとは別に、これを認めるのなら、
当然これがお前らの成長を阻害している要因の一つだとは認識できるだろ。
仕様のグダグダな所を暗記するのがプログラミングの勉強ではない。
お前らがブラウザ互換性の問題の勉強に費やした時間もまた、無に帰すときが必ず来る。
PHPとかも相当酷いから、
逆に暗記重視の文系プログラマにとっては安住の地になっている感があるが、
そうではない奴はPHPを目の敵にしてるだろ。
仕様のグダグダな部分はだんだんと修正されていく。
APIが不備な部分はだんだんと整備されていく。
ブラウザの互換性もだんだんと上がっていく。
お前らが腕前をこれらに依拠しているのなら、お前らの存在価値は自然と目減りしていく。
それを自覚しろと言っているのだよ。
とはいえ、君らがどうするかは君らの自由だが、
間違ったことを垂れ流してミスリードし、次世代の足を引っ張る権利は君らにはないんだよ。
だからそれはマジで止めろと言っている。
長文書くようになったなぁｗ
いや、他者評価ではなく、自己評価を聞いてるんだが
「お前がそう思うならお前の中ではそうなんだろう」なんて切り返しは要らん
仕様が分かっていないと自認する割には、他人を初級者〜上級者まで評価する程度の実力を持っていると思っている節があるようだし、おなた自身の認識に矛盾がある
変な要求を場当たり的に解決できたのを自慢げに語られてもねぇ
DOMを触れる前提の解決策はすでにマシとは言いがたい
ReactやVunみたいに分離や仮想DOMが普及してきてる
＞<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の場合はこの辺の「統合的」な視点が全く欠けており
統合的な観点が欠けているのはどなたでしょうかね。
> ReactやVunみたいに分離や仮想DOMが普及してきてる
jQueryの73.4%に比べれば1%以下では普及してるとは言えないです
ttps://w3techs.com/technologies/overview/javascript_library/all 例えば現代の日本人の0.5%に使われてる着物というものがあったら
大ヒット大普及と言えるだろう
無意味な使用率とかを見ちゃうようではなぁ
自分で、
>お前らが腕前をこれらに依拠しているのなら、お前らの存在価値は自然と目減りしていく。
とか言っちゃうくせに新しい技術への考慮をしないとは
事実jQuery使ったサイトは多いけど、すでにあるものの修正か、使いたいライブラリがあるか、シンタックスシュガーとして楽するみたいな使い方ばっかりだな
標準APIとCSS,JavaScriptの機能拡充で使う必要性はかなり薄れた
それ別人やぞ
> 例えば現代の日本人の0.5%に使われてる着物というものがあったら
それは「着物」の場合ですね。別の話です。
> 事実jQuery使ったサイトは多いけど、すでにあるものの修正か、使いたいライブラリがあるか、シンタックスシュガーとして楽するみたいな使い方ばっかりだな
因果関係が逆になってますね。
楽するみたいな使い方ぐらいしかする必要がないからjQueryを使うんですよ
ほとんどはReactとかAngular使ってデスクトップアプリみたいなものを
作りたいなんて思ってないんです。
企業サイトを楽に作りたいだけです。
需要があって供給が決まります。
普及率なんて使うときの目安にもならんのに
何かを見て決めて実行した結果が、普及率として形になるんだよ。
結果を言ってるだけ。目安にしろと言ってない。
> type="text"だけ例外的にvalueではなくてcontentのtextNodeで扱うのは統合性の観点から問題があるし、
いや、それはtextNodeではないぞ
彼も同じ勘違いをしていたようだが、彼には初心者特有の「事実と想像(思い込み)を区別できてない」ものを感じた
> 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のスレは他言語と比べて活発で、今日でも休日なのにお前らは投稿しまくりだ。
お前らが努力をしてないってわけではないのだろうさ。
ただ、上記のように、環境が悪いから上達しにくい、ってのはあるんだよ。
だから、これらを正しく認識した上で、空回りは止めろと、俺は言ってるんだよ。
だから、それはどうでもいいだろ
自己満足にしかならん
> 俺は<input>全体が<div><span>と同格に扱える仕様であるべきだと思っている。
知らんがな。お前が思ってたからってだから何だよ？
理由の一つぐらいいえ。
俺なら言えるぞ、inputはdivやspanと同格に扱えるものではない。
なぜならdivやspanは出力するためのものだ。
intputは逆に入力するためのものだ。
見やすさと入力のしやすさは違う。出力は製作者側がコントロールできるが
入力は何を入力するかは決められない。どうやって入力するかも決められない
本質的にまったく違うものなんだから、お前の主張は根本から間違いだってわかる
何の自己満足？
俺は単に事実を提示しただけ
おまえは ID:k7L1I/bs と同一人物なのか
自作自演してまで味方を増やそうとするとは
お前、、、レスする前にまずは全文読めよ。
ただまあ、
> 俺なら言えるぞ、inputはdivやspanと同格に扱えるものではない。
> なぜならdivやspanは出力するためのものだ。
> intputは逆に入力するためのものだ。
これは「オブジェクト指向では」間違いだということになっている。
とはいえ見た限り、DOMのオブジェクト指向は後付で、ややちぐはぐなのも事実だが。
君が非オブジェクト指向派で、
> 本質的にまったく違う
と思うのならそれはそれでいいが、
おそらくDOMについてはオブジェクト指向で取り扱う方が正しい。
おそらく君はそれ以前で、「オブジェクト指向」を理解できていないのだと思う。
これについては勉強した方がいい。
ただまあ、オブジェクト指向自体の勉強はやややりにくいのも事実だが…。
自分が使用しているライブラリの普及率の高さを見てニヤニヤする自己満足
事実は事実だが、掲示する意味がないといってるんだよ
知ってる。ってか常識
DOM とは Document Object Model の略
なんでお前そんなレベルの話してんの？
> なぜならdivやspanは出力するためのものだ。
> intputは逆に入力するためのものだ。
> これは「オブジェクト指向では」間違いだということになっている。
なってない。というか、なってるという証拠示せよ
日本語でおｋ
＞本来はこれが正しい仕様だ。valueは生の値、textContentはDOMStringだ。
それは思いっきり間違った仕様だし、典型的なアンチパターンです。
valueから一意に計算されるものをvalueと別に保持するべきではないし、
「とある属性の値をDOMStringに変換したもの」は要素の「内容(Content)」ではないので、
これをtextContentで返すべきでもありません。
textContentは要素の"内容"であるべきで、inputだけ例外として内容でないものをContentとしては
HTMLというもの全体の統合性が失われる。
目先の処理の統合性のために、データ構造そのものの統合性を失わせるのでは本末転倒。
HTMLにおいて"内容"(Content)というのは特別な意味を持つ専門用語なので、
そういった基本を学んでからDOM APIに文句をつけることをおすすめします。
＞HTMLInputElementはNodeを継承しているのだからtextContentをオーバーライドしてないことがおかしい。
オーバーライドしてますよ。空要素(内容を持たない要素)なので常に空文字列が返ります。
【HTMLはJavaScriptのためにあるものではないので】
JavaScriptから扱うときの処理を数行減らすためだけに、データ構造の整合性を失わせることはできません。
日本語を勉強しろ
君がそう思うのならそれはそれでいいのだが、
俺の考えだけ言っておくと、以下になる。
> inputだけ例外として内容でないものをContentとしては
inputの表示内容を textNode にしてchildNodes[0]にすれば、
Range で統合的に取り扱えるようになる。
そのときにその表示内容が textContent で取得/変更出来るのは自然だ。
だから、「inputは空要素」というのがそもそもの間違いで、
XHTMLではとりあえず終了タグ付けようとしただろ。（ポシャったが）
あれは方向はあってるんだよ。
> オーバーライドしてますよ。空要素(内容を持たない要素)なので常に空文字列が返ります
これが後付なんだよ。今の仕様を無理矢理OOPに乗せて、
オーバーライドしたことにして辻褄を合わせている。今の君の主張のようにね。
同様なのはNodeもそうだが、例えば、
ttps://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 が理解できてないのも一理あるだろうよ。
> Range で統合的に取り扱えるようになる。
それは悪いやり方ですね。
textNode ならtextNodeのメソッドを持っていなければいけないので、
つまり、inputの表示内容の、nextSiblingやparentElementってなんでしょうって
話になりますね。
> こんなのを見てOOPを学べるはずもない。教材が悪すぎる。
お前の頭が悪すぎるだけだよｗ
1. a は b である！（お前の間違った考え）
2. しかしにbはaと考えると問題が有る（間違った前提だからそうなる）
3. よって、aはbであるDOMはクソ（そもそもaがbであると言い出したのはお前）
まあ、こういう論理してますからねｗ
nextSibling は null になる。childNodes.length===1だから。
parentElement は当然<input>だ。
特に問題ないし、自然だろ。
＞inputの表示内容を textNode にしてchildNodes[0]にすれば、
＞Range で統合的に取り扱えるようになる。
繰り返しますが、HTMLはJavaScriptのための（ｒｙ
それからこれも繰り返しますが、【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で表示内容は取れません。
表示内容は画像かもしれないし、カレンダーかもしれないし、アナログ時計かもしれないし、ただの色かもしれない。
＞2018-04-07というのは便宜上このようにシリアライズしているだけであって、"#808040"というテキストを表しているわけではないし
訂正
#808040というのは便宜上このようにシリアライズしているだけであって、"#808040"というテキストを表しているわけではないし
dateからもっとわかりやすいcolorに変えてからの修正ミス
現在は（おそらく）TextNodeが反応するイベントがないってだけで
過去にはありましたからね
ttps://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);
> parentElement は当然<input>だ。
> 特に問題ないし、自然だろ。
あっはっは、馬鹿も休み休み言え
<span><input value=1>a</span>
<span><custom value=1>a</span>
HTMLとしての整合性が取れなくなるからね。
inputの中身まで消えちゃうｗｗｗ
君のこだわりがよく分からないが、さらにつき合うと、
> 表示内容は画像かもしれないし、カレンダーかもしれないし、アナログ時計かもしれないし、
それならそれが入ればいいだけだろ。textならtextNodeであって。
具体的には、
<input><img></img></input>
<input><calender></calender></input>
<input><analogClock></analogClock></input>
で特段何か問題が発生するとは思えないが。
<span value=0><input value=1 data-value=2>a</span>
valueの1とaの両方にマッチするっていうのは
非直感的なクソ仕様ですよ
「input要素に限りvalueはテキストノードとして扱われます」
なんて書いてあったら、そいつは本当に人間なのか？って思うｗ
というかな、多分君は「抽象思考」が出来ていない。
タグってのは単なる「参照」なんだよ。（プログラミング用語での参照、日本語でいう参照ポイント）
今問題なのは、<input>の中身に参照がないから捕まえられないことであって、
それは単にタグ付ければ回避できる、って話であって、
逆に、単に参照を付けただけだから、それで何か新しい問題が発生するって事もないんだよ。
HTMLが先進的だったのは、文章にタグを付けて、参照できることにしたことなんだよ。
それ以前は文章→ビットマップに変換だから、当たり判定なんて基本的に出来ないし。
だって参照がないから。
<input type="date">でカレンダーで日付を表示するのか、
2018-04-07みたいな文字列の形式で日付を表示するのかは
【ユーザーエージェント依存】なので、そんなことはできませんし、できる必要もありませんし、
マークアップ側が指定すべきものでもありません。
HTMLとして必要な情報は「これは日付の入力フォームである」という情報だけであり、
リッチクライアントならカレンダーを表示するだろうし、
テキストブラウザなら「2018年4月7日」などとテキストで表示され、数字を編集することになるだろうし、
音声ブラウザなら音声的に処理するでしょう。
あなたは全てのクライアントがいずれ完全互換になるとか思っているのかもしれませんが、
人間自体が完全互換ではないので、そうなる未来は我々の生きている間にはおそらく来ませんよ
だからそれが、「参照ポイントを付加した」だけだ、って言ったんだよ。
今<input>で出来ていることを、
<input><中身></中身></input>に変更したことによって生じる違いは、
・中身に参照を追加した
だけなんだよ。今できていることが出来なくなることはない。
君はだいぶ論点がずれている。
君は表示のことしか考えてないが、そもそも参照を付加しても表示は何も変わらない。
だから君の375での指摘は全く意味をなしてないんだ。分かるか？
> <input><中身></中身></input>に変更したことによって生じる違いは、
> ・中身に参照を追加した
> だけなんだよ。今できていることが出来なくなることはない。
DOMツリーを全操作して、子要素がないものを全部取得することができなくなる
処理をシンプルにできなくなる
OOPで言うと、参照を付加する＝今privateな物をpublicにしただけなんだよ。
だから何も変わらない。これで分かるか？
> だから何も変わらない。これで分かるか？
既存のpublicなメソッドに名前を変更すると
互換性が壊れる。
互換性を保つ上であたりまえのこと。
element.childNodes[0].nodeValue でも参照できますとか
混乱のもとでしかない
オブジェクトの属性が、
オブジェクトが所有するオブジェクトの属性 と同じとか
オブジェクト指向が分かってないとしか思えない
いやだから、<input><calender></calender></input>なんてやって
「この<input type="date">の中身はカレンダーです！」とか宣言できないし、しちゃいけないし、できちゃいけないんですよ
それを決めるのは開発者じゃなくてユーザーです
ユーザーが自分の環境で一番使いやすい入力・表示形式を選びます
あるinput要素にtextContentとして扱える内容があるのかどうか、開発側にはわからない、
ユーザーエージェント依存の部分なので、<input>は空要素でなければなりません。
＞今privateな物をpublicにしただけなんだよ。
だからそこpublicにしちゃダメなんですよ、UAによって何してくるか違うところなんで
開発者はユーザーエージェントがなんであれ、統合的に処理できるようにしなきゃいけないので
あるかどうかもわからないtextContentじゃなくて、どういう形式のフォームが使われるにせよ
確実に存在する"値"のシリアライズ文字列だけをvalueプロパティから取り出して扱うわけです。
異なるノードから同参照になる例としては、要素ノードと属性ノードがある
後はHTML Standardで反映型属性(正確な用語は忘れた)があって、valueもそれだった記憶がある
> 後はHTML Standardで反映型属性(正確な用語は忘れた)があって
反映型IDL属性だった
ttps://teratail.com/questions/86442 いずれにしても重要なのは仕様を正しく理解して使いこなす事であって、仕様が分からない状態でコードを作り上げる事じゃない
彼は分からない道具を組み合わせて、分からないままでコードを書き上げようとしている
createTextRangeを知っていて、代替APIを発見できない検索スキルの低さも問題だが(初心者でも数秒で発見できる)
ttps://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/setSelectionRange 音の大きさとかじゃなくて、単にそのつまみ自体の値が欲しいのよね。
setValueAtTime でオートメーションを GainNode に大量に入れてやるわけだけど、
リリース(音の停止)の時はそれを現在位置でキャンセルして、現在の値からフェードアウトさせる必要がある。
その現在の値(つまり、最後に設定した値)が GainNode.gain.value で取得できないから、何やねんこれはとなってるわけ。
> 後はHTML Standardで反映型属性(正確な用語は忘れた)があって、valueもそれだった記憶がある
value属性は反映されてなかったので、撤回する
すまん
> あるかどうかもわからないtextContentじゃなくて、どういう形式のフォームが使われるにせよ
> 確実に存在する"値"のシリアライズ文字列だけをvalueプロパティから取り出して扱うわけです。
そもそも textContent は階層が潰れた文字列だし、
そこに textNode ならそれそのまま、
<calender>ならそれに対して textContent を発行した内容を返せばいいだけだろ。
それがシリアライズ文字列を返すのならそれが返るし、そうじゃない仕様なら空でもいいし。
いずれにしても普通の<div>等のtextContentと矛盾無く同じ並びになると思うが。
あれも多分 childNodes.map(function(v){return v.textContent;}).join(' ') だろ。
俺には何故君が出来ないと思えるのかさっぱり分からない。
ここで与太議論しても何も変わらないから終わりでもいいのだけど、君がこだわる理由も分からない。
当たり前だが、DOMの仕様がクソなのは君のせいじゃない。
あれは見た限り元々OOPじゃなかったのを無理にOOPに乗せようとしてるからおかしな事になってる。
でも多分、方向性としては正しいし、次第に綺麗に整備されていくだろうよ。
> あれは見た限り元々OOPじゃなかったのを
ここだけ読んでもほんと頭が悪いなｗ
DOMはDocument Object Modelの略
すなわち「モデル」だ
OOPはobject-oriented programmingの略
すなわち「プログラミング」だ
モデルはでプログラミングじぇねぇ
OOPはプログラミングなので、対象が違う
Javascripとんのためにあるんやないんやでぇ〜♪
＞ここで与太議論しても何も変わらないから
そうですね、あなたがここで何を言おうとあなたの言うような仕様にはならないでしょう
「色データを文字列で表現したもの」と
「色を表すテキスト」は別物ですし、textContentやtextNodeは「色を表すテキスト」にしかなりません。
HTMLの基本構造としてそういうものなので。
<input type="color">が扱うことがわかっているのは「色データそのもの」や「色データを文字列で表現したもの」で、
「色を表すテキスト」を扱うかどうかはブラウザ依存で、開発者にはわかりません。
あなたの言うような仕様だとしたら、ブラウザは
カラーコードをユーザーにそのまま表示している時: "#00a3af"
色そのものしか扱ってない時: ""(空文字列)
ひどい時: "浅葱色"
をtextContentとして返してくるでしょうから、何が返ってくるのかわからないtextContentなんて誰も使わないでしょう。
> あなたの言うような仕様だとしたら、(中略）
> をtextContentとして返してくるでしょうから、何が返ってくるのかわからないtextContentなんて誰も使わないでしょう。
それでいいと思うが。両方とも。つまり、
・textそのものでない場合はそれなりの文字列で返す仕様でいい。
まあ普通色ならARGBかWebColorの文字列になると思うが、それは仕様で決めればいい。
・誰も使わなくてもいい。
君は何がそんなに気に障っているのだ？それで誰も困らないだろ？
今できていることが出来なくなるわけでもないし。
> 今できていることが出来なくなるわけでもないし。
できなくなるんだから問題だって言ってるだろｗ
人の話聞けよ
ちょっと言い方が曖昧だった。
多分、色について textContent で内容を取るのなら、
それはそのまま style:color に対して指定できる文字列が仕様としては良いだろう。
だから #xxxxxx とか red とか、まあそれはご存じの通り、で。
＞・textそのものでない場合はそれなりの文字列で返す仕様でいい。
＞ まあ普通色ならARGBかWebColorの文字列になると思うが、それは仕様で決めればいい。
<input type="color"> が、カラーコードのテキストノードを子要素として持つというのは
img要素が画像データを文字列にシリアライズしたものをテキストノードで子要素に持ったり
audio要素が音声データを文字列にシリアライズしたのものをテキストノードで子要素に持つようなものです。
明らかにHTMLの構造として異常ですから、確実に却下されるでしょう。
> img要素が画像データを文字列にシリアライズしたものをテキストノードで子要素に持ったり
> audio要素が音声データを文字列にシリアライズしたのものをテキストノードで子要素に持つようなものです。
そこはgetterでしょうに。
というか毎回なの？こいつ。
textContent は子孫要素のテキストノードをまとめたものを返すものですから、
<input type="color">がtextContentでカラーコードを返すとすれば、
子要素としてカラーコードのテキストを持つということであり、
これはimg要素が画像データを文字列にシリアライズしたものをテキストノードで子要素として直接持っていることに相当します。
これもさっき言いましたが、HTMLとそのDOMにおける"Content"の意味、ちゃんと勉強してくださいね。
動くコードも書かずにぐちぐちいうだけ
jQuery兄さんの足元にも及ばないな
textContentで子孫ノードにないものを返すのはありえないし、
参照するデータのシリアライズ文字列をいちいちテキストノードで保持するというのもこれまたありえない
だからそこはgetterだろと（2度目）
お前の提案したAPIだとテキストノードで保持することになるって意味な
テストしてみたが当たり前に取得できるぞ
他の人も同じこと思ってるけど、
的はずれな用語を持ち出してきても意味不明なんだよ。
お前の言うgetterがなんなのかわけわからんし、
おそらくお前自身がわかってない。
わかってるというのならgetterとやらでどうなるのか説明してみ
>XHTMLではとりあえず終了タグ付けようとしただろ。
全然違う。HTMLとXHTMLの概念は変わらず、空要素も両者ある。
XHTMLは<br />のように「空要素のスラッシュを義務化」しようとしただけ。
>input
オブジェクトを定義するXAMLとかでは<TextBox>value</TextBox>みたいにできるから、できても変ではない。
(ただし、Xamlはあらゆる属性を子要素として記述できるというだけ)
しかし、HTMLは文章の構造を定義するmので、今更変更するメリットはない
>互換性の問題は深刻ではないので
これは間違い。かなり規模のでかい破壊的変更になる。
・親も含めてtextContentやinnerHTMLの結果が変わる
・過去のHTMLの解釈が大幅に変更され、パーサが複雑に
・セキュリティ上の多数の懸念
概念的にもinputは「フォームの部品」であり、それ以上分解できなくても不自然ではない
>Range で統合的に取り扱えるようになる
それは無理。それこそ表示はブラウザに依存するから。IMEの未確定文字などの複雑な概念は単純には処理できない
>getter
意味がよくわからん
HTMLを壊そうとしてるんだよなｗ
「ポップアップ」「参照」「参照ポイント」「getter」あたりは世間と認識がだいぶずれてる
> 空要素についても同様に終了タグを付与するか、開始タグの末尾を「/>」としなければならない。
> 終了タグを付与する <br></br> という表記の場合は、タグの間に空白類文字すら含めてはいけない。
> また、後方互換性のために <br></br> ではなく、<br /> と表記することが推奨されている
>
ttps://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の両方が子要素になってしまう。
＞つまり終了タグ無し要素は無しになってるだろ。
終了タグとか関係なしに、内容を持たない「空要素」という概念があって、
は？ どこをどう読んだらそういう解釈になるのか。文盲？
空要素という概念が先にあって、表記形式として<br></br>か<br />のどっちか使えってだけで
XHTMLでは空要素にとって終了タグがあるかどうかなんて ど う で も い い ってことなんだけど
終了タグも<br />も空要素の表現手法であって、空要素が主、タグは従
タグにやたらこだわってるあたり、本当にWebの基礎の基礎がわかってないんじゃない？
タグなんて要素を表現する書式でしかないんだから、XHTMLでスラッシュが義務化されようが
終了タグが容認されようが、「空要素」という概念自体には何の関係もないよ
＞そんなに複雑だと思うか？
＞俺が試した限り、未確定文字もインクリメンタルサーチに当たるから、単純に、
だからー、それユーザーの環境によって違うのね
ユーザーによってデバイスもOSもブラウザも入力メソッドも何もかもバラバラ
お前の環境ではそうだった、っていうのはお前の環境ではそうっていう以上のものではないので、この議論に無意味
お前Webでユーザーの環境を開発者が決定できると勘違いしてるんじゃね？
行がちょっとずれたけど、2行目は5行目の前あたりに入れて読んでねー
了解。お前は文盲と理解した。お前とのレスもこれまで。
＞＞空要素についても同様に終了タグを付与するか、開始タグの末尾を「/>」としなければならない。
＞終了タグ無し要素は無しになってるだろ。
文盲はあなたですよねー、
＞終了タグを付与するか、開始タグの末尾を「/>」としなければならない。
いいですか。"終了タグを付与する」" OR "開始タグの末尾を「/>」とする"のどっちかをやれって言ってるわけだよ
"開始タグの末尾を「/>」とすれば、終了タグはなくてもいい"って言ってんの
終了タグ無し要素は無しって何？
どっちかといえば終了タグなしの /> が推奨だヨ
っていうテキストを読んで「終了タグ無し要素は無しになってる」とか本気で文盲としか思えん
もしかして上級者気取りで仕様書程度の英語も読めない感じ？
ttps://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 />.
(空要素は終了タグを持つか、開始タグが /> で終了するか、どちらか一方が必要です。)
つかXAMLってWPFかよ。以下読んだ。
ttps://docs.microsoft.com/ja-jp/dotnet/framework/wpf/advanced/xaml-overview-wpf 見た目、以下か。
・終了タグ必須
・textNodeなし、絶対にタグで囲め
・case sensitive
まあ確かにHTMLを参考に作ったんだからこうなるわな。仕様としては妥当だ。
とはいえ冗長だし、人間が書く用ではないが。
.（ドット）で明示的にプロパティと分かるようになっているね。
確かにこれの方がいい。
ただ個人的には、XAMLとか中途半端なことをせず、
WPFはHTMLを全面採用した方がいいとは思ったが。
え？ お前マジでそれいってんの？
知識なさすぎるだろｗ
> つかXAMLってWPFかよ。
XAMLはXAML、WPFとともに作られたがWPFではない
実際にXamarinでも使われている
ほんと？情報ありがとう。
じゃあ Firefox の実装が変なんかな。
どんなに
GainNode.gain.value = v;
なり
GainNode.gain.setValueAtTime(v, t);
なりで指定しても GainNode.gain.value が 0.1400049 みたいな固定の値しか返してくれないんだ。
初期値(=1)でもないし、なんじゃその値は。
自分のためにつくってるプログラムだから Firefox でないと意味ないし…。まあ別の方法でリリース制御はできたからいいけど。
> 見た目、以下か。
名前からXAMLはXMLの一種だと気づけ
そもそもXMLにはHTMLという決まったタグはなく
タグを仕様として作ってから使うもの、その仕様の一つがXAML
> ・終了タグ必須
XMLなんだから当たり前
> ・textNodeなし、絶対にタグで囲め
XMLなんだからtextNodeある
> ・case sensitive
XMLなんだから当たり前
> まあ確かにHTMLを参考に作ったんだからこうなるわな。仕様としては妥当だ。
XMLをベースに作った。HTMLは関係ない
> とはいえ冗長だし、人間が書く用ではないが。
人間でも読み書きしやすい
>
ttp://ytabuchi.hatenablog.com/entry/2017/01/04/160000 > 新年一発目は XAML Previewer についてです。Xamarin.Forms の XAML は手書きする必要があります。
> ただ個人的には、XAMLとか中途半端なことをせず、
> WPFはHTMLを全面採用した方がいいとは思ったが。
HTMLはタグセットが決まってるのでそんな事はできない
1レスでいくつ突っ込めば良いんだか
いろいろ、お疲れ様(大変だな…)
今まで属性はRangeに含まれていなかったのに、勝手に含まれるようになれば
互換性が壊れるって分からんのかね？
空要素の記述方法が、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を調べてみればわかるけど、かなり複雑な部類
スマホの横持ちとかでは、全画面が入力欄になったり、音声入力があったり、将来的な変化も見込まれる
> 例えば、こういうコードがすでに存在するとする。
> <input value="aaa">bbb</input>
> 現在はXMLとして書くと「<input value="aaa" />bbb」となるが
これは本当なのか？この記述をしているところのソースくれ。
なお俺はこれは間違っていると思うぞ。
俺は /> で閉じて良いのは中身がないときだけであり、
中身がある場合は常に閉じタグ</input>を使わなければならない、と理解している。
勿論、ご指摘のように、俺はXML専門家ではないが。
> とりあえず、WindowsのIME関連のAPIを調べてみればわかるけど、かなり複雑な部類
> スマホの横持ちとかでは、全画面が入力欄になったり、音声入力があったり、将来的な変化も見込まれる
それで？
未確定文字は結局の所、
・未確定でも値に反映して確定後に書き直す…俺の環境
・確定するまでは値に反映しない
のどちらかしか無いと思うが。
> 現在は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: テキストノード
仕様変更の前後どちらの文書なのか検出してパーサを変えなきゃいけない。
ブラウザはバリデータではないから、間違ったマークアップが施された文書だからって無視するわけにはいかない。
おｋ。動かしてみたが再現した。
詳細はの通り、今のDomParserだと</input>を無視するからだね。
> 仕様変更の前後どちらの文書なのか検出してパーサを変えなきゃいけない。
それはお約束がド頭に付いていることになってるから問題ないだろ。
＞それはお約束がド頭に付いていることになってるから問題ないだろ。
HTML5にはつかない。
HTML5にはDTDがないので
<!DOCTYPE html>
としか書かれていない。仕様変更の前後を識別できない。
ならHTML6には付ければいいだけの話だろ。
HTMLは4.01以前と違ってそうやって大きくバージョンを区切る方式を取りやめ
HTML Living Standard として日々更新を続けるようになりました。
HTML1.0→2.0→3.2→4.01のような大々的変更を移行期間を取って行うのではなくて、
日々少しずつ更新される HTML Living Standard に追従してブラウザは機能を実装し、
ある程度の段階でマイナーバージョンとしてw3cが勧告を出す、という流れになっています
ですから、文書のパース結果のDOMが変わるような大々的変更はしばらく行われることはないでしょう。
未確定文字は、実装依存で各ブラウザによって動作がかなり違う
ブラウザはもちろん、OS、デバイス、デバイスの状態、IME、IMEの設定などに左右されるので対応困難
求めるものにもよるけど、現状のなんとなくvalueを見るが限度。「Range で統合的に取り扱う」なんてのは結局実現できない
もっと変なことをしたいなら、オンラインのエディタとかVSCodeとかをみてみるといいよ。苦しいながら、実装はしてある
DOMパーサの破壊的変更は過去のブラウザやパーサが全滅するわけで、相当の理由と議論がなければ無理。
refererのスペルミスを直せレベルのハイリスク・ノーリターン
> 詳細はの通り、今のDomParserだと</input>を無視するからだね。
今のDomParserというが、HTML5では仕様化された。
なんと現実に存在する動きに合わせて仕様が作られ
間違ったHTMLであっても、どのブラウザでも同じように表示されるように
間違ったHTMLをどのように解釈するかが仕様化された
なるほどね、HTML parserでXHTMLを読み込ませたケースを想定しているのか
> ブラウザはバリデータではないから、間違ったマークアップが施された文書だからって無視するわけにはいかない。
いや、XHTML parserなら正しく文法エラーをはねるよ
HTML parserが文法違反に寛容なだけ
というか、Content-Typeでparserを振り分けてるから、bodyを読み込んだ後でparser分岐が発生する仕様にすると遅すぎるよね
html4まではこのように長かった。だがこれが正式な書き方だった。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "
ttp://www.w3.org/TR/html4/strict.dtd"> なぜhtml5ではこのように短くなったか？ それは単に長いという理由の他に
IE6では当時は間違った書き方である <!DOCTYPE html>でも標準準拠モードとして
扱うという仕様だったため、ならもうhtmlだけでいいじゃん、動くしｗｗｗ
という理由でこうなった
また、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を解釈する方法が仕様化された
> いや、XHTML parserなら正しく文法エラーをはねるよ
> HTML parserが文法違反に寛容なだけ
XHTMLはXMLをベースとしてしたから、XMLとして
正しくなければ描画できない。
これはどのブラウザでも同じように解釈させるため
間違った書き方を排除することで、どのブラウザでも
同じように描画できるようになるはずだった。
だが現実には単にエラーになるHTMLばかりで
手間がかかるだけで何もメリットを生み出さなかった
それをよこめにブラウザベンダーXHTMLではなく
現実的な回答をHTML5という形で実現させた。
それが間違ったHTMLを解釈するための仕様だ。
これにより、HTML5は文法違反であっても
どのブラウザでも同じように解釈されるようになった
今は文法違反を単に無視するのではない、
文法違反は仕様どおりに解釈するのだ
HTML StandardはXML parserも定義しているわけで、XMLが完全に排除されたわけではないけどね
選択の自由はユーザにある
例えばGainへの接続を切ったり、その前のノードを止めたりして
Gainへデータが流れていないとvalueは変わらないぞ
ttps://martinfowler.com/articles/201803-refactoring-2nd-ed.html 「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. 」
かと言ってC#かというとう〜ん。
消去法でこれしかないじゃん。
でもマーチンファウラーが書くとなるとクラスベースオブジェクト指向だろうな。クラスベース構文や方法論嫌ってるやつも多いjavascriptコミュニティでの受け取られ方やいかに。
使わざるを得ないだろ、ビジネス的に
JavaScriptという言語がクラスベース取り入れたんだから
クラスベースっていうのはそのクラスシステムに縛られざるを得ない言語のことを指すのであって
プロトタイプベースの言語でも結局構造化の過程で何らかのクラスシステムを利用するのは当然だけど
それに縛られないっていうのがポイントなんだから、そこは変わっていないぞ
あくまでまともな選択肢が増えたと言うだけだ
「mapメソッドが追加されたから、関数型嫌ってる奴も使わざるを得ない」
というのと同じくらい大げさ
個人的には好きだけど
onsenUIってどうなの？
あと、リファレンスがまとまってる所が見づらかったので、良いサイトないかなって探してるんだけどどっかある？
俺の頭が悪かった
onsenUIやるのにいい感じのハウツーなサイトない？
というか、リファレンスとか言うからいけないのか
サンプルが欲しいっす
あと、エミュレータと実機で動き違うの酷くね？
デバッガ入れるの面倒でエミュレータいじってたから普通にハマったわ
何でも実機デバッグは基本。
次は気をつけるので許してください
関数の呼び出しで
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が呼ばれない件だから、一応リファレンスにも書いてあってなんか納得は出来たんだけども
そこで代入するのはなんと言うかエグいな。
そもそもそんなコード、この環境以外で動くのか？
関数内でcは宣言してないから、スコープ的に見えないだろと思っていたら動いてて気持ち悪い…
ハァ？Javascript知らないなら「Javascriptのことは門外漢ですが、」とレスの冒頭に書いとけよ。
すまんね
門外漢です
要するに引数未定義でも引数を与えられるんだな
んで、代入式の戻り値が渡されていると
cは代入式が処理された際にグローバル変数として宣言された事になると
スッキリした
サンクス
関数内のcはグローバルスコープのcを指していて
イベントハンドラ中のc=でそのグローバル変数のcに代入されてるだけ
一応自分でも調べたよ
代入式の戻り値は代入した値で
この場合hogeの中ではargument[0]が5って参照できるんだってね
引数が多いときに便利らしいけど、Java勢だから想像すらできなかったわ
てか今見るとparaになっててだめだこりゃ
横だが、まだそれでもだいぶ理解を間違えているがな。argumentSだ。
複数形かどうかはJavaScriptにおいては無駄に厳密に適用されてる。
あと、のコードはかなり酷い。
公式でこれならかなり終わってるし、
なら数年以内に確実に廃れると思うから、そのフレームワーク自体使わない方がいいと思うぞ。
それから、Java自体はかなり終わっている言語な事を自覚した方がいい。
(内でも言及されているが、関数ポインタがなかったというのが救いようがない)
それとは別に、JavaScripterもプログラマとしては終わっているから、
この意味ではまともなJava勢が流入してくることは俺は歓迎するが。
君はちなみにJavaならどれくらい書ける？
お前Java書けなそうだなｗ
どうせ15年以上前の知識しか持ってないだろ？
グローバル変数 c が読み出されてるだけ。
もちろん良いやり方ではない。
俺は内での著者の判断には同意する。
ただしそれはの言うようなマーケティング上の理由ではなく、
著者の言うような技術的な問題だよ。
マーケティング的にはJavaは最も成功した言語だし、
リファクタリングが今後必要なソフトウェア資産もJavaが最も多いのは事実だ。
JavaScriptなんて保守する価値もないゴミコードばかりだし、
それ以前に書き捨ての文化だろ。俺はこれが悪いとも思わないが。
話はしなくていいからｗ
うん、俺も書いてから漏らしたと思った
ありがとう
公式…？
分かりづらいかも知れないけど、俺ね
知り合いの会社の新人の子とやらが書いたコードをデバッグしててハマったんだよ
俺がどのくらい書けるかって言われてもなあ
SIerだから推して知るべしって感じ
趣味で多少は書くし、量産型の中ではマシな方じゃないってレベル
あと、もう6年くらい前にInazumaVotouってAndroidアプリで投票騒ぎを起こしたことがあるよ
コードはウンコでスパゲティだったが、一応動いたな（笑）
おそらくスキあらば叩こうと思って聞いたんだろうなｗ
他の事なら聞いておきたいなって
ググっても出てこないがイナズマイレブンの人気投票で大騒ぎしたあれか？
お前こっちに来るか？
JavaScript情報交換所(プログラミング既習者専用）
ttps://mevius.5ch.net/test/read.cgi/tech/1449440793/ Javaで3,000行以上平気で書けて、JavaScriptもやりたいというのなら俺は応援する。
正直なところ、JavaScript使いはプログラマではなくデザイナやExcelマクロレベルなので、
開店休業状態になってる。
他に聞いておきたいこともあれば、それも答えるが。
それそれ
検索でなくなっちゃったか
楽しかったからたまにまとめブログ見ると未だにニヤつけるんだよね
俺は勘違いしてなければいいや
今後もその子サポートをしてやってほしいって言われてるから、困ったら聞きに行くかも
あと、煽るわけじゃないけど行数多けりゃ良いってもんでもなくない？
100万ステップのモンスターを一人で保守させられてたが、文字のスプリットから手作業でやってたりとか
if(a==1){data=1}とかってクソコードが目についてなあ…（笑）
俺が最初に作ったオセロでも1000ステップ位はあっと思うぞ
やっぱ書いて消してのクソコードばっかなんだがね
ちなみに「公式」ってのはこの場合onsenの公式サイト上のコードのこと。
その知り合いがどれくらい書けるのか知らんが、
書けない奴が公式サイトからコピペするのはよくあることだし、
書ける奴はこんなコード最初から書かない。
だからコピペでソースは公式の可能性が高いと見ての話だ。
ああ、それならなんだったか
リストの番号を関数に渡す方法がわからなくていじった云々言ってたよ
流石に公式がこんなウンコみたいなウンコしてたら誰も使わないっしょ
ごめん、もう来ません（汗）
> あと、煽るわけじゃないけど行数多けりゃ良いってもんでもなくない？
これはその通りだが、説明は後述するとして、
> 100万ステップのモンスターを一人で保守させられてたが、文字のスプリットから手作業でやってたりとか
君は余裕で合格、俺は歓迎する。
> 俺が最初に作ったオセロでも1000ステップ位はあっと思うぞ
俺が思うに、Java勢で3,000行のコードを取り扱ったことがない奴はいないと思うんだよ。
君のように他人が大量に書いたコードを保守させられて、規模とかも次元が違うだろ。
ところがJavaScripterにはこれがいないんだよ。ここら辺からだいぶ違う。
理由は簡単で、実際、JavaScriptにおいてはそこまでの規模にならないことも多いからだ。
ただ、これがかなりの元凶で、1,000行程度ならデタラメでも動かせるし、
保守するにしても書き直した方が早いから書き捨てになってしまう。
俺が思うに、ちゃんとした構造を考えて、Javaなら当然OOPに乗せて、
その効果を発揮するのはおそらく3,000行程度以上からで、
逆に言えば、それ以下で収まるのならグダグダ考えずに書いた方が早い。
勿論Javaではこんな事は認められず、「まず構造を考えてからコーディングしろ」となっていると思う。
それが仮に100行のコードであったとしてもね。
それはJavaは現在においては超大規模なコードを扱う前提だから、OOPに乗ってないコードが存在すると困るから。
これは、プログラミングとしては正しい。
ところが、JavaScripterは「構造を考えることのメリット」すら知らないから、考えることもない。
だから話の内容が幼稚すぎてな。
JavaScript自体は良い言語だと俺は思うんだけどね。
何度も言っているが、の著者の見解には同意する。
合格すか ありがとう
まあ俺JSは門外漢だし、交換できるほどの情報は持ってないよ
そもそも言語の歴史や方向性が違うから比較するのはナンセンスだと思うけどな
どんな言語だろうと業務システムでビジネスロジック書くのに使われてれば、再利用を想定した作りになると思うよ
UIが変わっても業務は変わらないからレガシーになりやすいと言うか
その中でJavaScriptはUI、Javaはロジックを担当してると言うだけでさ
良い言語も悪い言語も目的別に使いこなせるといいよねえ
その本については良く分からん（笑）
単に がJavaScript詳しくないだけでしょ
Javaが不味いのは、その著者も言っているとおり、
関数が第一級オブジェクトでないことだ。
正確には、第一級オブジェクトである必然性は多分無いが、
関数ポインタが使えず、その回避策に継承を用いるのは明確な間違いだ。
そしてJavaはこの期間が長すぎて、間違ったコードが量産されてしまっているし、
界隈に関数ポインタを使えない奴（使おうとも思いもつかない奴）も多すぎるだろ。
ただこれも、著者が言っているとおり、
その当時は関数ポインタなんてそんなに重要視されていなかった。
それよりはクラスシステムだったし、
逆に、今はそれがあるからこそ、その次の関数ポインタ、ってのはある。
だからこの辺の歴史的経緯を無視するのはナンセンスだが、
Javaはそれにしても進化が遅すぎた。
> どんな言語だろうと業務システムでビジネスロジック書くのに使われてれば、再利用を想定した作りになると思うよ
> UIが変わっても業務は変わらないからレガシーになりやすいと言うか
> その中でJavaScriptはUI、Javaはロジックを担当してると言うだけでさ
これはその通りだが、つまりはUIが変わり易すぎて、JavaScriptの場合は書き捨てになってしまっている。
結果、プログラマとしては全く上達してない。
Java->JavaScriptは、文法その他を覚えるだけでいいが、
JavaScript->Javaは、プログラミング自体に習熟する必要があるから、無理だね。
Web系()とか言って馬鹿にされているのも、状況を知れば納得すると思うよ。
関数ポインタがなにか分かってないやつの言い方だ
Javaのmethodオブジェクトじゃあかんの？
これがWeb系()の実態だよ。
Javaが良い言語とは全く思わないけど、
JavaのOOP至上主義は結果的にプログラマに上達を促している。
あんまり考えたことはなかったけどね。
JavaScripterは自由にやっているけど、方向性を間違えているから全く上達してない。
勿論ちゃんとやっている奴も中にはいるんだろうけどさ。
そこで俺は、ちゃんとしたプログラマがJavaScript界隈に流入してきて、
結果的にデタラメなお前らが駆逐されることを望んでいる。
勿論、お前らでもちゃんとしてれば駆逐されないし、界隈も浄化されるからお前らにもメリットがある。
お前らが反対しているのは、つまりは駆逐される側だと自覚してんだろ。
せいぜい安らかに死ね。
と言いたいところだが、残念ながら、早々変わらないとも思うが。
それはどれ？これか？
ttps://docs.oracle.com/javase/jp/6/api/java/lang/reflect/Method.html 俺はJava使いではないので、Java用語で言われても正確には分からん。すまん。
プログラミング用語だ。
知ってるふりした無知だなってよく分かる発言だなｗ
日本語でおｋ
あまり強い言葉を遣うなよ弱く見えるぞ状態
公式リファレンスなんてめったに読まんから分からんが多分それ
関数ポインタって要は関数のアドレスを格納してる変数でしょ？
Javaの場合、プリミティブじゃなきゃ、だっか？忘れたが基本は変数すべてがポインタみたいなもんらしいよ
関数ポインタが使えて何が嬉しいかってのがよく分からんけど、呼び出す関数の差し替えができるとか、複数機能を横断的に使用できるとかって話じゃないのかね？
methodオブジェクトはインスタンス化されたクラスの中にある関数そのものへのポインタで、こいつを使うとクラスから関数引っこ抜いて直接呼び出したり書き換えたり出来る とうろ覚え
一回しか使ったことないからあやふやですまん
差し替えとか継ぎ足しが出来るかは知らんわ
自分の知ってる言語の用語にとらわれている＝他の言語を知らない
OOPに則ってデザパタ使って自分で一から開発したソースでさえ数ヶ月も経つと分からなくなる
型もアクセスレベルも無いってのがとにかく最悪だな
関数ポインタの理解については、それで合ってる。
問題は、いちいちリフレクションかよ！ってことで、もっと日常的に使おうよ！ってこと。
変数と同格で使えるようになれば、もっと分かりやすいコードが書けるよ、ってだけ。
書けば慣れるし、使えば確かに便利だと実感すると思うよ。
> 差し替えとか継ぎ足しが出来るかは知らんわ
これはやりたがっている奴はいるが、これ自体はさほどインパクトはないね。
関数ポインタなんて言わずにJavaならJava用語使って言えよ
あー
たしかこれで引っこ抜くの都度都度おまじないが必要だった気がするな
セキュリティーがどうとかだったか？
まあ、javaやってればそのくらいは身につくんじゃないの？
言われてみるとあったら便利だけど、無くてもクラスから呼び出すだけだからあんまりピンとこないな
それよりvmとgcが…おや、出かける時間だ
まあjavaScriptはどっかでちゃんとやりたいしその内お世話になるかも
その時は宜しくどうぞってことで
でかける時間になっちゃった（笑）
無理だからと言って書き捨てばかりしているようでは、
いつまで経っても書き捨てのコードしか書けない。
多少無理でも歯を食いしばって無理矢理でも保守しないと、
何が問題なのか認識できないし、当然改善なんて出来ない。
Javaにおいては多分最初から「書き直し」の選択肢はない。
これがプログラマを育てている一面はあるよ。
> 型もアクセスレベルも無いってのがとにかく最悪だな
関係ない。
が、関係あるのなら、君は「型」「アクセスレベル」の類推を文法に依っていることになる。
それが間違いだろ。
もっとも、書けば解決する話なら、TypeScriptみたいに、
或いはコメントにでも書いてしまえば解決するだけの話だろ。
試しにやってみろよ。
やっぱり15年前の狭い知識で
粋がってただけだな
JavaScriptは書き捨てるからクソと言われても、どこがどう悪いのか書いてないと詳しくない人が騒いでるようにしか見えんな
普通に巨大なプログラムはいくらでもあるんだけど
行ってらっしゃい。
まあその気になったらよろしく。
> セキュリティーがどうとかだったか？
つかそもそもリフレクションってこんな時に使うものではない。
あれは動→静変換とか、privateに上書きとか、だろ。
> 言われてみるとあったら便利だけど、無くてもクラスから呼び出すだけだからあんまりピンとこないな
それは使ってないときの実感としては合ってる。俺もそうだった。
だけど、使い出したら関数ポインタ無しなんて糞言語だと実感するようになる。
> それよりvmとgcが…おや、出かける時間だ
ここら辺はJavaと同じ。
JavaScriptもVM上（とは言われないが所詮はスクリプト言語だから)だし、GCもある。
NGにして見えなかったと言い訳できないようにID変えておくねｗ
はいはい。ここまでラムダもででこず、
やっぱり15年前の狭い知識で
粋がってただけだな
> 関数ポインタという用語をを日常的に使うのはCとレガシーなC++だけな気がする
正解。関数ポインタが使われているのはC/C++と
あまり詳しくないけどObjective-Cもかな？
まあともかく多くのモダンな言語に関数ポインタなんてレガシーなものはない
ついでに言っておくと、
Web系言語(JavaScript/PHP/Go)はWeb情報に間違いが多いので、
MDNとStackOverflow以外はうのみにしない方がいい。
まあ、Java知ってれば、これ嘘くせー、ってのは大体分かるとは思うが。
チャリがパンクexceptionをcatchしてwalk()を実行中。
リフレクションの詳しい意味合いまでは知らないなあ
無理やりいろいろ呼び出せるし便利って思ってたけど（笑）
へー、そうなのか
javascriptのエンジンってやつがvmなの？
そうなんだ？
条件にマッチしてるものを探すのがjavascriptの方が難しい気はするなあ
まあ、滅多にやらんから運が悪いのかも知れんけど
あってる。関数ポインタはC言語系ぐらいにしかない
あまり皮肉言うなよｗ
リアルで分かってないやつに言っても
理解できないぞｗ
なんでも関数ポインタとしかいわない
みたいな話じゃないの？
プロならそれを関数ポインタと呼ぶのは間違いだって
知ってるからさぁ
Javaで書くとだとこういう感じね
Collection.sort(list, (p1, p2) -> p1.getAge() - p2.getAge());
まあ、よく分からんけどそれのことを言ってたんでしょ？
着いた！
System.exit(0);
文脈から、JavaScriptのことをJavaって読んでるのがわかったとしても
間違ってる用語を使ってる人は素人にしか見えないって話だよ
うむ、まあ俺も寝るが、
> 無理やりいろいろ呼び出せるし便利って思ってたけど（笑）
そうなんだけど、あれは「奥の手」であって、常用すると不味いでしょ。
どうしても必要なのは動→静変換時くらいで、
あとは、使うこと自体が間違っている、とも言えるはず。
> javascriptのエンジンってやつがvmなの？
ソース（テキスト、Javaの場合はバイトコード）を読み込んでサンドボックス上、
という意味ではそうだね。
> 条件にマッチしてるものを探すのがjavascriptの方が難しい気はするなあ
ググったら大体ブログなりquitaなりが引っかかると思うけど、
Javaの常識では考えられないくらいほど間違いが多いから気を付けて。
勿論正しい情報もあるとしてね。
それは関数オブジェクト
関数ポインタと比べてもっと高機能な存在
用語の正しさとかは気にしすぎてもしょうがないんだけど、JNIとかの絡みで本物の関数ポインタを扱う可能性があるので、混同するのはよろしくない
> javascriptのエンジンってやつがvmなの？
VMとは限らないからねｗ
どうも、IQ9（笑）の人は
素人まるだしなものでｗ
自作自演ですね。
こうもバレバレなのに続けるのを見ると逆に感心するわ
汎用のシステム開発言語だぞ
Web系の開発が過熱してる時期に出てきたからWeb系の実績が多いだけ
この人なんつーか、何かを話題に出す度に大昔の記憶と思い込みだけでモノ話してるよな
jQuery、SPA、HTML、XML、Java、Go、どれ一つとってもまともな知識がない。
全部断片の聞きかじりを覚えてるだけ。
もう少し真面目にやりゃ良いのにな。
あと、Goはいいぞ。
マジそれなｗ
そいつ今度はこっちであばれてるようだぞ
なんか万引きは貧困が原因で、お金持ってるのに
万引きする人はいないって言いたいらしい。
その根拠の示し方がそいつとまったく一緒
聞きかじりの言葉を並べるだけで、内容をまったく理解してない
もうそろそろ違法ﾀﾞｳﾝﾛｰﾄﾞ問題を再開しても良い頃だ
ttps://medaka.5ch.net/test/read.cgi/prog/1518681416/ 所詮はマシンリーダブル言語
もしかして、
ヒューマンリーダブル＝マシンアンリーダブルだと思ってる？
一つ簡単なゲームを作りました
ただどうしても警告が取れなくて困っています
ttp://sonicgefard.playcode.io/ こっちが実行ページで
ttps://playcode.io/sonicgefard?tabs=console&script.js&output こっちがソースが見れるページです
ゲームハードメーカーが出したゲームソフトを当てるというクイズゲームです
phina.jsというライブラリを使ってます
javascriptは独学で初心者同然です
根本的にわかってないという可能性もあります
どうしたらゲームの機能を維持して警告を取ることができるでしょうか？
同意。Goは糞。
あれをありがたがっているのはC++/C#/Javaのどれも使えない奴（≒Web系)だけ。
とはいえこれらではWeb向けライブラリが薄いので、WebにはGoの方がマシなのも事実だが。
俺の予想では、GoはWeb向け以外で流行ることはない。
これはJavaScriptがデスクトップにも適用範囲を広げようとしているのとは好対照だ。
ただこれも、JavaScriptそのものというよりは、HTMLが秀逸でGUIに最適だからだが。
だからWPFはHTMLモドキを採用したがJavaScript自体は採用せず、C#のままだし。
>Web向けライブラリが薄い
具体的に
あれ？DockerってGoだったはずだけど？
うちの環境だとdoctype宣言が2つある
って警告が出るだけなんだが(edge,win10,64)
いいぞ、軽量プロセスと並行プログラミング。
他の言語で同じ事をしようとするとすごく辛い部分。
C#もJavaも実務で使うぐらい使ってるが、Goはどちらの毛色とも確かに違うが違って良い。
使えないから持ち上げてるんじゃなくて、Goでならシンプルに解決できる問題があるから使うんだが。
Web向けで流行ってるわけではなくて、バックエンド系でしょ。
依存無しシングルバイナリが簡単に吐けるし、クロスコンパイルも充実。
もしかしてGo使ってもないのにdisってる？
あれはXMLであって。
しかもBindingの仕組みやら、アニメーションやイベントやら準備されてる。
むしろ、HTMLがXMLもどきでしょ…。strictで無いのは特に。
SGMLとか若い人は知らんのかな。
と言うか知識レベルが恥ずかしすぎるから、もう喋らない方が良いんじゃないかなぁ。
> GoがWeb系ってどんな脳みそしてるんだろ。
自分の仕事はウェブ系ではない
↓
自分の仕事では関係ない
↓
よってGoはウェブ系
今後はgolangが広がってくかもしれないけどね
仕事してるとは思えない知識の少なさとその少なさの自覚のなさだよ。
俺にこいつが下についたら、速やかに干す。
知識の少なさって、どこを見て判断したの？ｗ
知識を問われるような事言われたかなぁ？ｗ
tomcatやらasp.netのIISに相当するものは無いからな。
APIサーバとしては優秀だが。
高校生でエンジニアを目指してもいない頃からHTMLとXMLの関係ぐらい知ってたぞ
どういう事？
jQueryから、SPAの勘違い(突然レスポンスコードの思い込みで発狂しgooglemapを例に挙げたら、twitterというアプリケーションでは無いものを挙げてきたり)から、HTMLの属性と小要素を混同してみたり、
xamlをHTMLもどきと言ってみたり、
基本的に知識のベースラインが無いところに砂上の楼閣のように聞きかじったことを積み上げて独自理論で的の外れた長文書くところから、知識が少ないと総合的に言ったんだけど。
ID:6pCy057fが知識無いって言ってるんじゃないよ？
chromeでコンソール開いた状態で
ノーミスで時間切れまでやったけどエラーひとつもでなかったが。
あとMSのゲームばっか聞きすぎｗ
64bit Windows10・Chrome でプレイしたけど、何も問題ない
今は、phina.js とか、
pixi.js を使った、Phaser とかが流行っているのか
ふーむ
それだけなら問題ないのかな？
なんかこのサイトのエディタで警告みたいなものが一つ出てるんですけどこれは無視して
いいのかな？
msのゲームがよく聞かれるのはたまたまですね
ソースを見てもらえばわかる通り完全なランダムです
偏りがあるとしたらそれはmath.random()メソッドのせいですな
問題ないんですかね
ならいいか
ありがとうございます
phina.jsを選んだのは開発者が日本の方なので日本語のテキストがネットに多かったからです
書いてよ
いやゲームの場合、数学的に質のいい乱数でも人間が不自然に感じることがある。この辺は奥が深い。
ttp://blog.livedoor.jp/lunarmodule7/archives/4523745.html 研究になるくらい。
ttps://playcode.io/sonicgefard?tabs=console&script.js&output このソースが見れるサイトはplaycodeっていうんですけど
このサイトのエディタの226行目に警告が出てます
ttps://i.imgur.com/SHtf8NC.png 「too many errors. (93% scanned)」というメッセージなんですけどさっぱり意味が分からなくて
別のエディタで見てみたけど何も出ないよ
エディタ側の不具合じゃね
ああそうなんですか
じゃあ無視していいのかな？
これからは複数のエディタで確かめてみる事にします
ありがとうございました
> いやゲームの場合、数学的に質のいい乱数でも人間が不自然に感じることがある。
面倒くさいから読まないが、テトリスで
I-テトリミノがなかなか出てこなかったら
乱数どうなってるんだ？って思うやつだな。
今のまともなテトリスは完全な乱数ではなく、
すべて形が同じ回数になるように出現する
だから予測して積むことができる
まずは画像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としても無反応で表示されませんでした。
どのようにすればよろしいでしょうか…
手元に環境なくてごめんけど
とりあえずhogeに引数つけてみたら？
function hoge(info){
var t_url = info.srcUrl;
alert(t_url)
};
すみません；自分の検索が弱くいくつもあったかとは思うのですが
最終的に、urlを拡張機能で、javascriptとして得て、
PHPファイルに渡して、そこで画像アップロードまでを一連化ですとか
最終的に自分の便利ツールをいくつか作成してみたいと思い
ここは飛ばせないと思い、注力しておりました。
有難うございました！できました！
本当にこのあたりを理解していない現段階でしたので、大変に有難かったです；
有難うございました！！！
こういう要素が見つかる
<img src="tagindex.gif" alt="TAG index" border="0">
誰かが作った、拡張機能があるのなら、それを使えば？
この板よりも、web制作管理板の、JavaScript のスレに書き込んだ方がよい
教わり、本当に有難かったのですが、
画像にマウスオーバーしているだけで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制作管理板の、JavaScript のスレに書き込んだ方がよい
君は、F12開発者ツールも知らなかったの？
JavaScript, jQuery も知らないじゃないの？
そんな人が、作ることは無理。
ツールを探した方がよい
すみません…右クリック「検証」のような事から多少操作はしっていましたが、
F12というそういう事もはっきりとした知識をもって操作はしておりませんでした…
javascript、jQueryは今勉強中というつもりでして、
すみません…
しかしもう少しここで待たせて頂けませんでしょうか…自分も引き続いて
色々のパターンを試したいと思います、すみません…
web系云々なんてこのスレの質問内容から見て今更の話だけど
ショートカットキーを押下してスクリプト起動を想定してる様に見えるが
態々そうする理由があるの？
こだわる理由としましては、
例えば目的の画像があり、
ここを右クリック、メニューより項目を選んで起動
という２つの動作でなく
ショートカットで一発起動
という、秒数で言えば２〜３秒の差かもしれませんが
ツールとしてはこの上下は長く使うには間違いなく大差が生まれると思ったためです。
自分自身が使うのですが、人が使うにしても
対象右クリック、〜〜〜 より、一発の方が凄く速いと思ったので、です・・
の時点ですごく満足させて頂きましたので、
先ほど自分が述べましたあたりを含めて
今後勉強していこうと思います。
退散いたしますので、有難うございました！！！
ショートカットキーは覚えていられないから、右クリックメニューが基本。
そこに、ショートカットキーも書いておく
この板では、web系の開発者が少ない。
web制作管理板の方が、開発者が多いから、回答者も多い
jQuery関係の話なら特によく俺がレスしている
cdn証明書期限切れのお粗末
webを修理したのもjQueryなわけで
とりあえず最低限のサンプルは作ってみたけど
ttps://pastebin.com/5m2cwZnp このままじゃchrome.commandsを利用する利点があまり無い
これ以上は
・イベントの基本
・content scriptとbackground pageの領分
を理解してもらわないとフォローのしようが無い
ttps://mevius.5ch.net/test/read.cgi/hp/1520329583/957-958 アフィカス死ね
ttps://jsfiddle.net/ab7fc708/8/ これのconsole.logが、3: 5 ab: "c"という順番になるのは何故ですか。
また[true && false]がfalseになるのがよくわかりません。
オブジェクトの中身に本来順番は無い
たまたま数値を先にしてあとは挿入順に整理するブラウザが多いだけ
後者は何が疑問なのかが分からない
ブラウザの仕様だったんですね なるほど
このコード自体本に書かれたものを書き写しただけなんですが、後者についてはそもそもソースの意味がよくわかってないです。もうちょっと調べてみます。
どうもありがとうございます。
すみませんレス見落としてました。
論理演算子はわかります！ &&ならAかつBという意味になりますよね
これ普通にtrue && falseの解がfalseって意味ですよね
[true && false]でどうなるのを期待したの？
先に左側を評価して、そこで答えが確定したら、右側を評価(実行)しない。
論理式全体の戻り値は、最後に評価された式の値
true && B
false && B
上は、Bを評価して返すけど、
下は、falseの時点で、偽が確定するから、Bを評価せず、falseを返す
true || B
false || B
上は、trueの時点で、真が確定するから、Bを評価せず、trueを返す。
下は、Bを評価して返す
a ||= 1
これは、a = a || 1 なので、aが偽なら、aに1を代入する。
デフォルト値を入れる、定番の書き方
JSの本にcomputed property nameについて書かれていたのですが、サンプルソースの意味がよくわからなくて質問しました。
何かしようとしてたわけではないです(というか普通こんな書き方はしないですよね)。
言葉で書くと複雑ですけどがそのまま答えですね、どうもありがとうございました。
A || B では A が truthy なら A が返り、falsy なら B が返る。
A が返る場合 B は評価されない。
("hello" || "world") && ("hello" && "world") は "world" になる。
お前らマジでJavaScriptの前に日本語を勉強した方がいい。話にならない。
MDN用語(getter)も通じないところをみると、お前らはMDNも読まない/読む気がないようだが、
実際はお前らの日本語が酷すぎてMDNすら読めないからだろ。
今回の話なら、以下2つになる。
ttp://https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_Operators">ttps://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_Operatorsttps://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Object_initializer 質問者は何が分かってないのか明示できるほどの日本語能力が無い。
この場合、仮に正しい回答をしたとしても、どうせ通じないから意味がない。
また、MDNには複数の人が何度もレビューした結果が掲載されているのに対し、
ここではお前らみたいな馬鹿が思いつきを書くだけだ。
どうしても一般的な回答のレベルは劣ってしまう。
唯一、質問者が勘違いしているところをピンポイントで救済できるとき以外は
MDNの方が常にマシだとわきまえた方がいい。
： デフォルトの名無しさん [sage] 2018/04/24(火) 00:09:45.01:F18TbmJE
「終了タグなし要素はなしになっただろ」とか言いだすようなヤツが日本語能力について語っても、その……。
お前は日本語じゃなくてもいいから言語を勉強しよう
getterの意味はわかってるけど、お前の用途が間違ってるんだよ
オブジェクト指向の設計の話をしてるのに、実装(getter)の話をされてもね
JavaScriptのgetterは出番はないし、C++の実装ではAudioとか関係なくgetterは使うし
俺は許せないんだ！って叫んでるやつがいるってだけじゃない？
ムシムシｗｗｗ
「ウリはザパニーズニダ」が多すぎるって話。
こいつらがいなくなれば、このスレは相当改善される。
何故かは分からんが、JavaScriptのスレにだけゴキブリ大集合だ。
Q. true && false が false になるのが理解できません。どうしてですか？
A. お前が馬鹿だから
いやマジで
アンドとかオアとか、ビット演算とか応用レベルで理解してるプログラマって少ない。
ビットマスクで解決する部分をほとんどのプログラマがブーリアン型大量に定義したりしてる。あれ、疲れるからやめてほしい。
内部的に、1bit に最適化しているかも知れないし
自分で、1bitに最適化する必要はない
ほら、こういうレスが来ちゃう
すべてのオブジェクトはObjectの拡張だし
何ビット目が何を意味するかを管理してたら、
何変数が何を意味するかを管理するのと、コスト的には変わらんよね
ほんとそれ
たまたまではないのでデマにだまされないように
オブジェクトの列挙は配列数値が先、次に挿入順にするようにECMAの仕様で決められている
細かいことを言うとfor-in構文の場合だけ互換性の観点から規則が緩いが、
そこでもこの列挙順を利用することにはなっているので
新たに仕様を参照する場合はそこから何か独自にソートしたりすることは考えづらいので
必然的にこの列挙順になるようになってる
この知ったかサイコデマやろう！
危うく騙されるところだったぜ！
いや、そこまで言う必要はない
物は言いようで「たまたま」のニュアンスにもよることだし
はぁ、視野が狭いのおれ
おれはもう諦めるよ
> すべてのオブジェクトはObjectの拡張だし
Object.create(null)
typeofしてみろやｗｗｗ
それは全てのオブジェクトはオブジェクトの拡張と言ってるようなもんだ
それはObject型
$( "#sid" ).clone().appendTo( "#divid" );
のように直接行うのではなく、テーブルのため、あとからまとめて追加したいと考えています。
そのため、clone()をいったん文字列として格納したいのですが、
どのようにしたら良いのでしょうか。
.text()を使用すると、valueのみ表示され、タグ<select ･･･ などが格納されません。
テーブルのためとか文字列として格納とかさっぱり意味分からんけど
そのまま変数に入れればいいんじゃない
let elem = $("#sid").clone();
//その他の処理
elem.appendTo("#divid");
君が求めているのは
ttps://developer.mozilla.org/ja/docs/Web/API/Element/outerHTML だが、後からまとめて追加するだけなら、jQueryオブジェクトのままでいいと思うがな
わざわざ、文字列に変換するコストが無駄
全く意味がわからない
var docFragment = document.createDocumentFragment();
メモリ内だけに存在する、まだDOM に追加していない、
DocumentFragment を使えば？
JS, jQuery の質問は、web制作管理板へ書き込む方がよい。
この板には、あまりweb系の開発者がいないから
> メモリ内だけに存在する、まだDOM に追加していない、
> DocumentFragment を使えば？
それでもいいんだけど、jQueryオブジェクトがその状態だから、.clone()だけで目的は達成してるんだよね
そこから、更に文字列化する意味が分からない
DOM要素は文字列化は無理
Reflecting content attributesの範囲で文字列化は可能だけど、完全ではないね
質問者の期待値に依る
outerHTMLでいけました。
var tr_row = '<tr>' + ”ここにいれたい。” +
'<td><input type="text" ...></td>' +
'<td><input type="text" ...></td>' +
'</tr>';
上記場所に入れる際に、<tr>タグの途中なので、appenndはできないしと思い、
文字に変換するのはどうすればよいのかという次第でした。
てか<td>で囲む必要はないの？
innerHTML などで1度に挿入したりするけど、
こういうのは、デモを作る際だけにしておいた方がよい
こういう書き方は、保守性が低いし、
構文をパースしてDOM を組み立てるから、実行速度も遅い
ブラウザのHTMLパーサはカリカリにチューニングされていて爆速だから、
JavaScript側でこねくり回すより遥かに効率良かったりする
innerHtmlなら途中でレイアウトなどの余計な処理が走ったりすることもないし
シングル・ダブルクォーテーションの扱いも面倒だし、
URL エスケープ処理も面倒
あちこち、バグる
文字列で、タグを作るもんじゃない
使うなら徹頭徹尾使えと
jQuery便利なんだが、デバッグ難しいからねえ・・・
jQueryだからって特に難しいことなんてないぞ
エラーで落ちても知らんぷりの言語だしね。
エラー時にダイアログを出す設定も有ったはずだが
（普通のサイトでうざくなるんで通常はOFFにするけど）
やっぱり単にデバッグの仕方を知らずに
難しいって言ってるだけな気がしてきた
本人の能力の問題ｗ
あなたはどこを読んで勘違いしたんですか？ｗ
結局、マトモなデバッグ方法無いって事じゃん。
ミンシン並み。
ブラウザにデバッガが内蔵されてる
知らないなら素直に知らないって認めなよ？
他の言語のデバッガと比べても最高クラスのデバッガだと思う。
各オブジェクトのメモリ使用状況とかわかるし
実行時のパフォーマンスの分析
ttps://developers.google.com/web/tools/chrome-devtools/rendering-tools/?hl=ja メモリの問題の解決
ttps://developers.google.com/web/tools/chrome-devtools/memory-problems/?hl=ja Timeline イベント リファレンス
ttps://developers.google.com/web/tools/chrome-devtools/evaluate-performance/performance-reference?hl=ja 結局主要ブラウザ全部で動作見なきゃいけないし
ブラウザがたくさんあるんだからその問題はどうあがいても避けられないのでは？
(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側の仕様による
マルチポストになるので質問〆ます
javascript側は前者で問題ない
もしかしたら fd.append('y[]', '2'); fd.append('y[]', '1'); の方が良いかもしれんが
さんも〆たあとなのにありがとうございました
あとまた質問なんですけど
ブラウザゲームで特定の画面のときにデータを読んでCGI経由で保存するみたいなことをしたいのですが
if(location.pathname.indexOf(URLキーワード) >= 0) {
var data = document.getElementByClassName(クラス名);
POST
：
ってかいてもそのページで動きません
console.log(location.pathname);
if(location.pathname.indexOf(キーワード) >= 0) {
って直前にいれるとブラウザの表示と別のＵＲＬが表示されます
ページ遷移はせずにURLだけかわっていくような仕組みみたいです
直接かいても window.onload = function() { の中に書いても同じで
いちばん最初に読み込んだページでしか動かないみたいで
特定のＵＲＬや要素が出現した場合にだけ動作するようにするにはどうしたらいいんでしょうか
.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もすぐかけるかなと思ったんですが
スクリプト言語は型がぐちゃぐちゃでエラーの原因がまったく特定できなくて泣きそう
まずな。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の証明書が切れてしまって一時的に使用できなくなった
あくまでjQueryが利用していたCDNであって、ローカルにダウンロードして
使っていたり別のCDNを使っていたのであれば関係ない
問題はすでに解决している
そのエラーが必ずしも}の数が原因とも限らないが、
もしそうなら}を適当に増やしたり減らしたりして
改めてエラーの位置を確認するとだいぶ役に立つと思うよ
> はじめから javascript のソース整形がはいってるエディタってないんでしょうか…
つ VSCode
わー ありがとうございます
これすっごい便利ですね
色もついてるし
自動整形してみたらやっぱり } の数がちがってたみたいで1分で原因わかりました
ほんとに感謝です
大学ではUNIX艦橋だったのでemacsって色がつくエディタはいってたけど
Windowsだとメモ帳しかなくて途中に if 文とか追加したらインデントぐちゃぐちゃして困ってました
朝ちょうど入れ違いで回答いただけてたんですね
for-in がまずかったんですね
ループインデックスでかきなおしてみます
丁寧な回答ありがとうございます
便利だろう。俺はVSCodeが好きだがこれ系のエディタは他にもAtom、Sublime、Bracketsとかもあるぞ。書いとかないと他のエディタの信者に怒られるので念のため
教えてくれた方ありがとうございました
あとVSCroeってPHPは整形できないんですね
キーワードハイライトはついてたんですけど
ちょっと残念
さんのほかのもちょっとためしてみますね
それ系のエディタ共通の話だけど基本的に個々の機能は拡張機能で追加する形態だからね。jsとかhtmlとかが特例なのよ。
{
let aaa = null;
let foo = (bar) => {
aaa = "bbb";
}
}
↑見たいな構造のコードを見かけたんですが、
この一番外側の中括弧ってどういう意味やメリットがあるんでしょうか？
スコープを汚染しないため
以前即時関数でやってたのと目的は同じ
ttps://jsfiddle.net/1o93q4xs/ このコード自体では意味がないけどな。
なるほど、ありがとうございました
中括弧と言えばオブジェクトだみたいな頭してましたが、
そう言えばもうブロックスコープが使えるんでしたね
安価付け忘れた
ありがとうございました
hogeの中で計算を実行して、結果をサーバー(Node.js)にPOSTしたいです。
今は、このような関数を用意して、POSTしようと試行錯誤しているのですが、合ってますかね？
hogehogeはこの関数実行前に(ほかの関数で)計算済みです。
ttps://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();
});'
むしろどうしてそれでうまくいくと考えたのか？
そもそもそれで何がしたいのかが不明
もう一度最初からサンプルやドキュメントちゃんと見てごらん
適当に目を瞑ってキーボード叩いただけじゃそりゃ動かないよ
本当ですか…
javascript自体触ったことないので完全に手探りなので…
考えとしては、nodejs側でPOSTを受け取りたいので、クライアントサイドのjsで変数をPOSTしてあげれば良いのかなっていう素人の考えです
HTML(ejs)の中で入力内容をPOSTしているソースコードはよくあるのですが、jsで変数をPOSTするソースコードは見つからず、、
根本的に考え方が間違っているのでしょうか？
Node.jsを勉強すればいいのか、はたまたJavaScriptを、Expressを、、と色々ありすぎてよく分からない状況ですね
間違ってないとは思うけどjsでformを生成する理由はある？
最初からhtmlに記述しといてvalueを弄くれば良くないか
純粋にjsから送るならXMLHttpRequestの方が向いてる気がする
node側はbodyParserが何してるのか分からんから答えられない
とりあえずconsole.log(req.body);したものを貼ってくれ
あとExpressなら最初にそう書いて
実は、Node.js だけでは面倒くさいから、それだけでは作らない。
Express + Express Generator フレームワークを使う
Node.jsは、Ruby で、Sinatra を、full scratch で書くのと同じ。
Express + Express Generatorが、Rails と同じ
だから先に、無料のRails チュートリアルをやれば、フレームワークが理解しやすい
YouTube のTraversy Media で、Express, Rails とか色々やってる
ほんとルビウンコの周り廻ってるハエにはろくなのがいない
先にRuby やって、無料のRails チュートリアルをやれば、
MVC, web アプリの作り方がわかる
しかも、Rails以降の、多くの言語のフレームワークの基礎になっているから、
Railsを勉強していると、どの言語でも作れるようになる
他の言語でも、フレームワークを、Railsと同じように作っているから、応用できる
DB, Linux コマンド、環境構築も学べる
HTML, CSS, JavaScript, SASS,
Bootstrap などのCSS フレームワークも学べる
しかも、Rails以降の、どの言語のフレームワークにも通用する。
例えば、Node.js + Express Generator とか
所詮Railsはサーバーサイド用のフレームワークですからね
電卓アプリを作りたいので、HTMLには数字や記号のボタンを押す処理だけ書いて(ボタンを押すとJSの変数に代入などな処理を行う)、
実際の数字の繰り上がり処理や足し算とかの処理はjavascript側で処理してるんですよね
単純にゴチャゴチャしてるHTMLファイルが嫌いなだけなんですけど…
理想としては、=を押した際に、計算する関数を呼んで、計算し終わったらそのままnode.jsに変数を渡したいです
こういう場合はXMLhttpRequestの方が良いんですかね？(全く存在を知りませんでした)
Express使ってます
ttps://pastebin.com/7jEkzyww console.log(req.body)の出力はこんな感じです
Nullオブジェクト？なので、そもそもうまくPOST出来てなさそうです
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
Express, Rails とか色々やってる
先にRuby やって、無料のRails チュートリアルをやっていないと、
Node.js + Express Generator の仕組みがわからないと思う
上にも書いたけど多分bodyParser.text()が機能してない(てかtextで良いんだよね？)
ソースはrequire部分から貼ってもらった方が良いかも
電卓アプリか
それなら、Electron (Node.js + Chromium) の方が良さそう。
VSCode も、Electron製
Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう
野口 将人・倉見 洋輔、2017
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
ttps://youtu.be/k_0ZzvHbNBQ?list=PLillGF-RfqbYRpji8t4SxUkMxfowG4Kqp これでわからないなら、先にRuby やって、無料のRails チュートリアルから勉強する
ありがとうございます
githubのExample真似ただけなので、json形式でした
XMLhttpRequestでjson形式に整形したデータを送れば良いのですかね？
それとも、text形式にしたほうが良いんですかね？
ttp://https://pastebin.com/RNfTFFUE">ttps://pastebin.com/RNfTFFUE： デフォルトの名無しさん [sage] 2018/05/08(火) 02:14:30.98:aOEwk35o
XMLhttpRequestで送るときはxhr.open("POST", "/hoge")
routes/hoge.jsで受け取るときは
router.post('/', function())
ってややこしいですね…
このせいで2時間ほど頭悩ましてました…
HTML内でのjavascriptをnodejsみたく扱えるライブラリ等を使わないなら
全然別物としてそれぞれ勉強したほうが良い
それ何て言うライブラリですか？
これからは統一するなら送信はfetch、受取はSW
SuperAgent、Axios
ブラウザネイティブのFetchは、大人の事情で
すでに使い方が複雑になってしまったので
おすすめできない
それはhttpクライアントライブラリです。
HTML内でのjavascriptをnodejsみたく扱えるライブラリとやらを紹介してください。あるんでしょ？
全くそんなことはないが
例えばAirbnbのスタイルガイドでは複数行コメントは//使うな/**/使えと書いてある。
ありがとうございます
難しいですね…
キーボードの発火点である検索ボックスなどのInput要素を特定して、addEventListenerでフォーカスを登録し、
フォーカスイベント直後にblurを呼び出しフォーカスを外すなどの方法を考えたのですが,Input要素の取得がそもそもうまくいきませんでした。もっと単純な方法で、サイト全体でキーボードを無効にする方法などないでしょうか？
解析できないようにしたいのですがどうしたら良いのですか？
avgleというサイトみたいに
Chromeだと
ソースコードを見る・・・CTRL+U
デベロッパーツール・・・CTRL+SHIFT+I
> exec() と同様に（またはこれとコンビで）、
> test() が同じグローバル正規表現インスタンスで複数回呼び出されると、前回のマッチの先に進むことになります。
>
ttps://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/RegExp/test 対応してくれた人がいたのならありがとう。
あ、そうです。難読化です。
デバッガが以下でとまってしまいません？
(function anonymous(
) {
debugger
})
いや、止まるかけど解析はできるだろって話。
debuggerステートメントを入れてれば、そこでデバッグできるように止まるが
止まるのが嫌なら、デバッガのActivate break pointsを無効にすればいいし、
デバッガで止まっていても、ソースコード見れるし
いくらでもやりたい放題
どのクラスタにどのマーカーを含めるかを、マーカー同士の距離から自動的に計算してクラスター化してくれるライブラリはないでしょうか？
これじゃダメなんか？
ttps://developers.google.com/maps/documentation/javascript/marker-clustering?hl=ja chrome拡張のjavascriptでサイト外のサウンドをならすことってできますか？
ttps://stackoverflow.com/questions/32356613/chrome-extension-not-playing-sound-when-button-is-clicked .mp3のとこにＵＲＬをうめこんだら音でました
<audio>タグとかをうめこんでうんたらとかが必要かと思ってたらたった３行でよかったんですね
ありがとうございました
a = new Audio()
a.src = url
a.play()
は
new Audio(url).play()
と書けるから
classもfunctionは使わないし、
連想配列を使ったオブジェクトへの
メソッド定義にも必要ない
function.selfメタプロパティにする案もあるが
Strict Modeで使えない機能は要らん
〜すれば不要だなんて何事にも言えることだし
つうかES2015の著者も提案してることからも重要性は分かるだろう
function.sentのようにfunction.meとかで入るべきだよ
何が問題？
無名関数に再起をするためだけに外にも分かる名前を付けないといけないのは問題だろう
そもそも名前を付けるに値しない、付けなくても良いような関数であっても
無理やり固有の名前を付けないといけないということなんだからさ
仮に名前が最初から付いていたとしても、super()のように関係性による参照は重要
複雑なことするならちゃんと名前を付けるべきだと思うの
> function.sentのようにfunction.meとかで入るべきだよ
arguments.callee 問題を回避する為には this 値束縛の例外機構が必要で関数呼び出しの処理に手を入れる必要がある
これは「arguments.callee 問題を知っている人にとっては」直観的な動作ではなく、分かりづらい
> 無名関数に再起をするためだけに外にも分かる名前を付けないといけないのは問題だろう
名前付き関数式はスコープが外に漏れないよ
> そもそも名前を付けるに値しない、付けなくても良いような関数であっても
それは発想力の問題であって、名前を付ける方がリーダブルコード的には正しいと思う
特に再帰関数は可読性を下げるので、名前はあった方が分かりやすい
jQueryに代表される「とにかく無名関数式を使え」な偏重的傾向は可読性とは正反対のポリシーでしかないので、好ましくないと個人的には思ってる
彼らの主張は「ショートコーディング最高！名前を付けるのは悪！」という感じでどうにも共感できない
でも自分自身を呼び出すことが目的であって、例えば関数meを呼び出すことが目的じゃないからね
関数名meをmyに変えたら変更しないといけなくなってしまうし
superの例と同じくそこは抽象的な物があったほうがいいんじゃない？
普通の名前付き関数式は確かにもれないが、
アロー関数とかも「fn(()=>{})」の代わりに「let cb;fn(cb=()=>{})」とかにしろってことでしょ？
あと変数はできるだけ名前を短くして寿命（スコープ）を短くするのが良いと個人的には思うよ
ショートコーディング最高というのではなくてね、
昔のとある言語界のようにスコープが広くて説明口調の何十文字もある関数名が好まれていたものの対局としてね
汎用的な関数とか、関数の引数のような使われる範囲の広い名前は比較的きっちり決めるべきだけどね
そうでないものは、それこそ一旦途中計算をとっておくようなものはtempか、
スコープ狭くてそこの２行で使わないようなものならtでも十分
結局、function.me で arguments.callee 問題をどう解決するの？
> アロー関数とかも「fn(()=>{})」の代わりに「let cb;fn(cb=()=>{})」とかにしろってことでしょ？
そんなことはいっていない
自分が主張しているのは名前付き関数式
> あと変数はできるだけ名前を短くして寿命（スコープ）を短くするのが良いと個人的には思うよ
名前を短くしても寿命は短くならない
同様に名前を無くすことで寿命が短くなることもない
それはただの論理のすり替え
そもそも、これは再帰関数ではなく、コールバック関数
で触れたし、ぐぐればすぐに出てくると思うんだけど…
arguments.callee() における this 値が何かを考えれば、すぐわかる
彼は function.me() にも同様の問題がある事に気が付いてなかったような気がしてきた(実際、>742に反論してこなかったし)
だから例えばそうやって他に渡された関数がその先で自己呼び出しするためには
定義した場所で名前を付けて置かないといけないでしょ？
()で囲んだ即時関数にしろ、コールバックにしろ、式中でアロー関数を定義する場合は
宣言を別にしないといけないし不格好になるよという例だよ
それで結局、君はアロー関数中の使用なら必要性を認めるし問題は無いということでOK？
君がやけに拘るthis値もアロー関数は定義された場所のthis値で固定されるんだから
そもそもどのように参照がされようがthis値が変わったりはしないのは自明で
そこに何も新しいことや考えないといけないことは生まれない
そもそもアローでない関数に関してもメタプロパティなんだから仕様でどうとでもできる話
function.me()と読んだらthisがfunctionになるわけでもあるまいし
まあ自然なのはfunction.meというキーワードが自己関数を素朴に参照することだろう
つまりme()のようにfunction.me()とできればいいし、
me.call()のようにfunction.me.call()とできればいい
> だから例えばそうやって他に渡された関数がその先で自己呼び出しするためには
だから、名前付き関数式なら自己呼び出しできると説明したよね？
繰り返すけど、
- 名前を短くしても寿命は短くならない
- 同様に名前を無くすことで寿命が短くなることもない
- 再帰関数は可読性を下げるので、名前はあった方が分かりやすい
> それで結局、君はアロー関数中の使用なら必要性を認めるし問題は無いということでOK？
アロー関数には名前を付ける機構があって良いとは思うけど、arguments.callee は必要性を感じない
> つまりme()のようにfunction.me()とできればいいし、
それが直観的でない事はで説明した
拡張するなら、@callee() とかの方がまだわかりやすい
ただし、自己呼び出しなら「名前を付ける機構さえあればいい」
スコープを無駄に拡張する必要はない
アロー関数の問題は「名前を付ける機構がないこと」
解決するには、「アロー関数に名前を付ける機構を作ってくれればいい」
関数式は現状維持で何の問題もない、以上
非アロー関数にこだわってるのは君の方でしょ
というか君の言い方を真似して言うと、
ただアロー関数の問題に気が付いて無かっただけでしょ
というかfunction.meが直感的で無いっていうのは
this周りの話だと思うけど、そのことについてはsuperを例に挙げたじゃん
直感的で無いと感じるのはただ単に君がメタプロパティに馴染みがないからでしょ
super.method()、new.target()としたときthisについて、
またはfunction.sentが採用されればそれについて知っていれば何も違和感なんて生じようがないよ
それにメタプロパティの良いところは、新しい予約語も記号も消化せずに済むところなんだから
@とかJSの残り少ない貴重な資源でしょ
向こうでも同じことを言ったがな
アロー関数は、functionの代替、短い書き方じゃねぇ。
関数を値のように扱うためのものだ。
基本は n => func(n) の形、=> の左の部分は他の書き方でもいいけど
=> の右側に { retun hoge } みたいに {} や returnを使おうと思ったら
それはアンチパターンだ
そんな複雑な処理をするためのものじゃねぇ
だから再起に使おうとか思うんじゃねーよｗ
ソースは？ｗ
少なくともお前は間違っていると思う
アローは this の束縛が特徴だと思ってるが
× 値として使う
○ 引数として使う
そもそもの発端はの「名前を付けないといけないと言うことが問題だろう」に反論したこと
この文脈で名前をつける機構のないアロー関数に言及してると思う方が無理があるでしょ
アロー関数の問題には気が付いていたけど、論点を拡大させすぎると君は都合のいい部分だけ抽出して反論するから、あえて言及しなかったんだよ
軽い気持ちでargumentsを話題に出してしまって申し訳ない
chrome extension で実装したんですがデベロッパーモードにしないで動かすにはどうすればいいんでしょうか
自分用につくったんですけど知り合いも使いたいみたいで導入ハードルをさげたいんですよね
あとプレーヤーごとにデータをわけて個別にマイページ表示したいので
送信するPOSTのなかにユーザIDなり暗号化したトークンなりをいれたいんですが
どうやって実装するのが簡単でしょうか
配布する chrome extension を共通にしてその中の post の内容を外からの変数でかえることってできるんでしょうか
あるいはプレーヤーごとに ID をうめこんだ extension ファイルを配ったほうがいいのでしょうか
> functionはthisとかargumentsが使えるし排除する積極的理由が思い浮かばないんだが
その通りだと思う
アロー関数だけにしたら、this値束縛でいろいろと弊害が出てくる
- call,apply,bindが使えない
- addEventListenerの第二引数に非関数オブジェクトを指定しても無効
googleに登録する（審査有り）
ChromeではないChroniumを使う
諦めてデベロッパーモードにする
ユーザーIDかなんかは乱数で作って保存しとけ
既にスレ違いだから気をつけろ
chrome拡張の話はスレ違いなんですね
気をつけます
今やブラウザ拡張もWeb標準技術の１つだから
ttps://browserext.github.io/browserext/ 乱数で作って保存するっていうのはどこに保存すればいいんでしょうか？
識別する文字列を鯖側で乱数作成するにしても
ユーザがアカウント名として入力するでもいいんですが
配布する拡張機能側にうめこむ方法がわかりません
ユーザごとにIDをうめこんだ違うファイルを配るか
拡張機能内に何かしら入力欄を作って入力しないと無理ですよね？
自分で読み直してみて, 何がしたいのかその文章から読み取ってもらえると思う？
普通にストレージはchrome.storage.localとかで提供されてるけど。
エクステンションごとに保存先が独立して用意される。
ちなみにgoogle認証とかで識別したほうが楽じゃない。
乱数だとエクステンションをアンインストールしたタイミングでヒモ付が消えることになる
拡張機能をインストールしてブラゲーページをみたとき
特定の画面でDOMを抜き出す ＋ ユーザ識別トークンを付与してサーバー送信
サーバー（PSP CGI)は受け取ったデータをユーザ識別トークンごとに保存
表示ページではユーザ全体の集計結果を公開してログインするとユーザごとの個別データが見られる
というイメージなんですけど
拡張機能側で毎回同じ識別トークンを知るor個別に作るにはどうしたらいいのかなって
PHPもJSも4月から覚えたばかりでウェブアプリつくるの自体がはじめてなので
認識が間違ってたらごめんなさい
わー ありがとうございます！
localStrageっていうの localStrage.put() get() だけで使えたので簡単そう
初回アクセス時にクライアント側で乱数を生成してlocalStrageに保存して
localStrageから取り出してつけるだけでいけそうです
これ実態はメモリじゃなくてファイルになってるんでしょうか
PCの電源落としたりセッションやIPがかわっても毎回取り出せるのかな
有効期限のないクッキーみたいなもの？
google認証軽くしらべてみたんですけど理解できなかったので自分には難しそうです
サンプルコードいくつかみたけどどれも何かしら入力文字列があったので
ユーザは何も入力しなくてもサーバー側で固有のトークンを取り出せるんでしょうか
とりあえずlocalStrage使う方向ですすめてみます
本当にありがとうございました！
oauthって、聞いたことない？
gmailは大体の人が使ってるからパスワード入力を省略できる。
例えばHTMLの中に<a onclick="hoge()">と書いてあるとして
そのhoge関数はどのスクリプトにあるhoge()が呼ばれるんでしょうか？ブラウザでは同時にいくつものjavascriptが走っていると思うんですが
試しにGreasemonkeyでスクリプトfugaを作りそこからHTMLの適当な要素にonclick="hoge()"を追記して発火させてみると
ちゃんとGreasemonkey下のfugaスクリプト内のhoge()が呼ばれますが
ブラウザはどうしてhoge関数がGreasemonkey下のfugaスクリプト内にあると分かるんでしょうか？
動いている全てのスクリプトの関数名を走査しているんでしょうか
だとしたらhoge()とたまたま同名の関数が他のスクリプトにあったらどっちにいってしまうのか
確実にfuga内のhoge関数を呼ぶようにonclickに指定する方法はないのか
が分かりません…
何がわかんないのかよくわからないな。
同時に幾つものjsが走っているというのはあくまでタブ単位の話
複数のタブにまたがってグローバルスコープは共有しないから大丈夫
でも同名の関数が衝突することはあるから確かに気をついないとダメだね。
レスありがとうございます
他のタブの関数が呼ばれてしまうということは心配していないのですが
同じ１つのタブの中でもサイト作者が作ったJS、ブラウザアドオンのJS、GreasemonkeyのJS、と複数走っていますよね？
そこで同名の関数があったらどうなるんでしょう？
また確実に自分のスクリプトの中の関数を呼ぶ方法があれば知りたいです
またmin()とかmax()みたいにごく短くてありふれた名前の下位関数を作ることはよくあると思うんですが
関数名がブラウザには全部一緒くたに記憶されているんだとしたらそれすらも危険という気がしてきました
自作スクリプト全体を(function(){…})()で包んだとしても、先程の例のhoge()が呼べてしまうので
やはりmin()やmax()も宣言すれば全体から見えてしまう（上書きしている？）のでしょうか？
あと現在のスコープに関数定義が見つからない場合１つ外側のスコープを探しに行くよ
Browserアドオン。エクステンションに関しては別の処理系で動いているから名前衝突は起こさない。ただしDomだけは共有してる。
ありがとうございます
そこで最初の疑問になるのですが
Greasemonkeyやブラウザアドオンのjsからdocumentの要素にonclick="hoge()"等と書き加えた場合、
いざページを見ていてユーザーがその要素をクリックした時は、ブラウザからはHTML（DOM)だけを見ているのであれば
hoge()がどこのスクリプトから書き加えられたか分からない（どのスコープのその関数を呼べばいいか分からない）と思うのです。
その時でもなぜちゃんとhoge()が呼ばれるのかしっくりきません
また確実に自分のスクリプトを呼ばせる方法が知りたいです
その要素のaddEventListenerを呼び出して該当関数を渡せばいい
どのスクリプトファイルかを判断する必要はない
グローバルスコープは共有されるからだ
その書き方だとグローバル変数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文字に全てを押し込めて衝突を避けてるけど
サイト側が$を使っちゃうとそれまでの話
jQueryのソースコードでは、windowの、jQuery, $ に、
jQueryオブジェクトを代入してる
この2つだけが、グローバル変数
イベントハンドラーを、<a onclick="hoge()"> のように、HTML に直接書くのは、ダメ！
jQuery の、on とかで、JavaScript から設定する
モジュール管理は、Node.js が使っている、CommonJS とか。
ES6(2015) で、import文ができた
JavaScript, jQuery の質問は、
この板よりも、web制作管理板へ書き込んだ方が良い
そちらの方が、人が多い
グローバルスコープで発生する名前の衝突を避けるには不要なオブジェクトをグローバルスコープに曝さなければいいんだよ
ライブラリではそのために特定の名前に全部詰め込んでそれだけをグローバルスコープに晒したりしているよ
あとはwindow.foo.barみたいに独自のネームスペースを切り出してその中だけを使うといったやり方もあるよ
javaが分かるならパッケージ名みたいなものだと言えば伝わるかな
(function(){})()の意味は無名関数の即時実行だよ
スコープの話と絡めると良くあるのは(function(global){var foo; ... global.bar=foo;})(window)みたいな使い方だよ
この例だとグローバルスコープにbarと言う名前でfooというオブジェクトを曝してるよ
あとはえーと、addEventListenerで登録するのは関数の名前じゃなくてFunctionオブジェクトそのものだよ
無名関数も登録できるよね
リスナーが実行されるときに名前で関数を探しているわけではないんだよ
> 是非はともかくjQueryやlodashなんかは1文字に全てを押し込めて衝突を避けてるけど
> サイト側が$を使っちゃうとそれまでの話
jQueryもlodashも$や_をサイト側でも使っても問題ない方法を用意してるよ
jQuery.noConflict()
ttps://api.jquery.com/jquery.noconflict/ _.noConflict()
ttps://lodash.com/docs/4.17.10#noConflict functionで囲うのは関数定義がスコープを生成するからだよ
さっきも説明したと思うけど
>仮にファイルAはウェブサイト側のjs、ファイルBはブラウザアドオンのjsだとします
この場合は処理系が分離してるから。
関数名が衝突するどころかブラウザのアドオンからウェブサイト側のjs内の関数呼び出しはできない。
DOMしか共有してない。 何度も言うけどDOMしか共有してないから
2,3hで終わる話
DOM共有してるならなんとかなるな
mousemoveとかで呼び出したい関数をセットすればいい
Greasemonkeyはセキュリティのために何度も仕様変更してるし
だから、関数スコープでぐぐれ
関数で括ったら、スコープが漏れない
グローバル変数は共有する必要がなければ使わないものだ
A・P・I！
出来ると思うか？
悪意のWebサイト開設者が裏でJS回して「○○小学校に爆弾設置する」みたいな犯罪予告ツイートさせたらサイト訪問した奴の人生終わるぞ
だからTwitter Developer DocumentationのJSAPIにも載ってないし出来ない
だからJS単体で裏で勝手にツイートさせる事は不可能
consumer secret晒す必要あるけど。
こっそり訪問者にツイートさせたところがconsumer secretに紐付くお前が童貞されて罰を受けるだけ
特定のページをみはって特定の情報（DOM)がでたらツイートするBOTアカウントを作りたくて
訪問した人のアカウントで勝手にツイートするわけじゃないです
動作自体はローカルで動かすのでツイッターアカウントとパスワードｗｐソースにうめこんでも大丈夫なはず
他の言語でブラウザを経由せずにwgetみたいなことをやってもいいんですけど
ログイン認証があるのでログイン後に表示されるHTMLを取得する方法がわからないので
ブックマークレットだったりchrome拡張にできるjsが便利かなと
rest api で検索してみら node.js や npm のインストールがいるっていわれるんですけど
unix サーバー環境をもってないです…
nodeでやるにしてもunixサーバーなんか要らないよ。
もうちょっと具体的な機能の説明を頼む。
なんだかわからんけどパスワード類埋め込みだと悪用されるで。tweet自体はサーバサイドってやったほうが良い。
JavaScriptならNodeが良いと思うけどね(Nodeすら導入出来ないなら諦めろ)
npmくらいは使ってんだろ。普段から
具体的な内容まではいえないですけど情報が変化するサイトがあって
その情報を分析して特定の反応がきたときにツイートするBOTを作りたいんです
FXや株価のシグナルをつぶやくみたいなイメージに近いかもです
ほんとはcronか何かで定期的にそのサイトにHTTPアクセスにいくサーバーサイドアプリが一番なんですけど
その情報を表示するのにログインが必要なんですよね
で自分がログインした後のページのHTMLを取得する方法がわからないので
ログインまではブラウザで手動でやって
あとはjsで一定時間ごとにreloadかけてgetElementByClassとかで情報を抜き出して
分析してツイートするみたいなことをしたいのです
その情報を表示するサイトはぜんぜん他人のサイトでその上でJSを動かすって意味ではなくて
JSを動かすのは自分のブラウザ上だけで公開するわけでもないので
BOTのアカウント情報をうめこんでも大丈夫だと思います
JSから自分のつくったBOTアカウントにツイートさせることができればやりたいことはできそうなんです…
ttps://qiita.com/sand/items/b01d7d8f3d9c1642298b headless chrome使えば大抵のことは自動化できる
ありがとうございます
確かにこれならやりたいことができそうなんですが
導入にコマンドライン操作がいっぱい必要みたいですね
ためしに最初の１行をプロンプトにうってみたけど curl がないっていわれた…
コマンドラインになれてないので exe クリックするか
ブラウザ上で完結する作業以外は自分にはまだ難しそうです…
せっかく教えていただいたのにすいません
はっきり言うがお前のやりたいことはTwitterの公式APIドキュメント読めば簡単に実現出来る
自分で調べる気のない奴は向いてないからやめちまえ
ツイッターもJSもそこそこ有名だから
JSからツイートするぐらいの関数なら誰かが作ってないかなと思って質問してみましたが意外といないものなんですね
時間はかかりそうですが自分でプロトコルから勉強して作ってみます
お答えいただいたかたがたありがとうございました
レベルの低い質問をしてしまって失礼しました
つーかツイートするだけでAPIの仕様まで理解しなきゃいけないとか欠陥言語もいいとこ
何のためのブラックボックス化だよ
そもそもchrome extension作ろうと思ったら
yoとかである程度コードジェネレートしないとどうでもいい所で詰まるよ。
まぁいいけどさ。
WebAPIの仕様を知らないといけないことが何故言語の欠陥になるのか？
はひょっとしてWebAPIというものをご存じないのではないか？
HTTPリクエストするのにHttpヘッダを理解しろ
っていってるのと同じことじゃねーの？
メールを自動化するなら少しは理解しとかなきゃダメだろ
あとはと同じ
Ruby で、Mechanize, Selenium WebDriver で自動操作できる。
大学や図書館にもログインできる
パスワードを入れて、ボタンを押す。
element.send_key "パスワード"
driver.find_element(:css, 'ボタン').click
Nokogiri で、スクレイピングもできる。
ほとんど、jQuery と同じ
公開されているAPI を使わないなら、webページを自分で解析しないといけない。
どのタグに、どういう情報があるのか、分析するのが大変
API を使わずに、5ch 専用ブラウザを作れないのも、同じ理由。
自分で5ch の仕様を解析するのが、面倒だから
npmっていうコマンドがないっていわれます
使いたくないというかjs自体4月から独学で勉強はじめたばっかりで…
上位のフレームワーク的なものまで手だせる段階じゃなくて…
node.jsっていうのもよくきくので以前１回調べたんですけど
サーバー側で動作するjavascriptでスケーラビリティが必要な場合に
Apache+CGIのかわりにつかう速いウェブサーバー？って認識だったので関係ないと思ってましたが
普通にクライアントサイドjavascriptかくのにも必要な技術なんでしょうか
今回たまたま拡張機能使うのが楽そうだと思ってjsにしただけでjsはほとんどかかないので
知らなくてすむ技術なんだったらそれにこしたことはないんですが
話きいてるとそれを覚えてそのなかのツイッターライブラリ探したほうが速い感じなんですね
あのあといろいろ検索してみたんですが
javaやｐｈpならトークン4つセットしたあとツイート内容引数1つうけとるだけでつぶやける関数があって
5,6行でツイートできるサンプルが結構でてくるのに…
javascriptだけは複雑な数十行のサンプルしかでてこない…
レン鯖かりてCGIにポストしてCGI側でツイートするほうがはやいのかな…
iMacrosって調べてみたら
>条件分岐などの操作ができない。
ってかいてあったんですけど単に操作記録してループ再生できるだけでは？
プログラミングの知識が必要ないってあるんですけど
HTMLを読んだりができないとやりたいことができない気がします
というかwebの解析自体はできててツイートしたい文字までは用意できてるんですよね…
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 と同じ
ブラウザの自動操作は、Ruby で、Mechanize, Selenium WebDriver
スクレイピングは、Nokogiri。
これは、jQuery と同じ
黙ってNodeインストールして使えや
webページから、内容を抜き出して処理してから、
テキストボックスに文字列を入力して、送信ボタンを押す
driver.navigate.to "webページのURL"
element = driver.find_element(:css, '取得したいセレクター')
ここで要素から、内容を抜き出して処理する
element = driver.find_element(:css, 'テキストボックス')
element.send_key "入力したい文字列"
driver.find_element(:css, '送信ボタン').click
インストールしてみました
npmも勝手にはいってたみたいで
プロンプトにうったら動くようになりました♪
ためしに
> npm search twitter
っていろいろでてきました
とりあえずこのままjsでtwitter APIたたきにいくか
言語ごとかえてCUIでブラウザ操作してログイン後のHTMLよみにいくか
まだきめかねてますがまた明日がんばってみようと思います
リプくれたかたありがとうございました
そう。node.jsはサーバサイドというか、ブラウザ以外の場所でjsを使うために生み出されたけど、ライブラリ共有の仕組みが便利でブラウザで使うと便利なライブラリの共有にも使われてる。くらいの理解で。
ドットインストールとかで勉強してみるのはどうかな？いずれ使う日はくる
ttp://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1226114724/53 この掲示板(万有サロン)に優秀な書き込みを●して、総額●148万円の賞金をゲットしよう！(*^^)v
ttp://jbbs.livedoor.jp/study/3729/ →リンクが不良なら、検索窓に入れる！ せっかくコードかけて動作させようとしたのに
アプリから twitter API 叩くための４つのキー取得するのに電話番号認証がいるみたいです…
ブラウザでログインすれば普通にツイートできるし
ツイッターの専用クライアントからは電話番号とかなしで普通にツイートできてるのに…
アプリからツイートするのだけ電話番号いるって…
twitter API 経由せずにツイートしたいってさすがにこのスレできくべき内容じゃないですよね
もうお手上げなのであきらめます
BOT対策でしょうかね。ロシアがアメリカの選挙に介入するのにずいぶん利用したらしいから。
だからheadless chrome使えばと
にやり方が書いている
Ruby + Selenium WebDriver で、ブラウザの自動操作
Java、C#、Python、Ruby、Perl、PHP、JavaScript
Java以外でよく使われてるのはご想像の通りpythonとjavascript
Seleniumは同一コードで多種のブラウザを操作できるメリットがあるがセットアップはやや面倒。
chromeに絞ってよいならばやはり今はheadless chrome使うのが楽。puppeteerというnpmパッケージ入れるだけ。
OmniAuthを利用して、Twitterログイン機能を作る【初心者向け】
ttps://qiita.com/To_BB/items/01863aa50d628c069b64 認証も何も、プログラミングしていないだろ
設定ファイルに記述しているだけ
アプリ認証なしでアカウント名とパスワードだけでツイートしたいって話じゃないのかよ
みたいに、
Ruby の、Mechanize, Selenium WebDriver などで、
ブラウザを自動操作すれば？
アカウント名・パスワードを入力して、ツイートボタンを押す
JSスレできいてんだからJSのコードだしてやればいいだろ
ttps://qiita.com/ko-he-8/items/1bc26fd6ecdf6a8bf946 これとかどうなん？
ソースぱっと見 username password だけでいけそうだよ
new ActiveXObject( "InternetExplorer.Application" );
とかかかれてるからこれ毎回IE窓起動されんのか？
Selenium WebDriver で、ブラウザの自動操作するために、
漏れは、各社のブラウザドライバーもダウンロードしてるよ
chromedriver.exe
MicrosoftWebDriver.exe - Edge 用
chrome には、headless モードもあるから、画面表示なしで操作もできる
ActiveX は、やった事ない。
いつも、VBScript から、ピラフが使っている奴だろ
のソースコードを見たけど、VBScript, JScript などのWSH だろ。
sleep ばっかりで、これは面倒
Selenium WebDriver をすすめる
selenium勧めるのはいいと思うけど、それはjsでも出来る。
お前らがRubyしか使えない事を他人に押し付けるな。
npmも使ったことない初心者に新しい言語覚えろとか相手にされるわけないだろ
禁煙の立て札の前でタバコ吸って注意した人の顔面に煙吹き掛けるようなやつら。
デフォルト設定ではサーバーからクライアントへ送信するパケットの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日
1KB 以下の話なんて、無意味だろw
> 現状ネットワーク帯域が逼迫しており何らかの対策を考えています
別の所に原因がある
ピーク時に2万3000クライアント程が同時接続しててその時にネットワーク帯域が不足するのでどうしたものかと悩んでいました
とりあえず半分の512バイトで圧縮するように設定して負荷検証してみました
実際のパケット自体は100バイト未満が6割、600〜900バイトが3割、1割はそれ以外（MAXは986バイト）
結果としては問題なく捌けているみたいですが、他のサーバーに比べるとCPU使用率が10%ほど高くなるみたいです（元々が20%前後なのでCPU負荷的には問題なさそうです）
メモリに関しては長時間の使用によってパフォーマンスが落ちるとの事なので1週間様子を見て大丈夫そうであればこれで行くことになりそうです
パケットログとサーバーの送信直前（emit直前）の時間の差はツールの問題で1ms単位でしか見れませんが遅延も問題になるほどではありません（最大の遅延で3msほどで済んでいます）
ユーザーをパーティに分けてリーダーにだけ送信して
他のメンバーにはリーダーからP2Pで送らせるとかさ
Chromeだけでもよいので。
mouseoverとmouseoutの発生順って、規定されてないよね？
○○の場合だけならこの順、てのもないよね？
バブリング、キャプチャリングのことか？
いや違う。書いたとおりmouseoverとmouseoutの発生順だ。
mouseout->mouseoverの順で固定されていればコードが減らせるんだが、
そうだとは誰も書いてないし、以下見る限りやはり駄目っぽいんだが、
誰か知らないかなと思って。
ttps://stackoverflow.com/questions/282245/what-is-the-event-precedence-in-javascript 単純に、固定されていないと、
・mouseout->mouseoverの順で発生した場合
・mouseover->mouseoutの順で発生した場合
の両方を想定して書く必要があるだろ。
どっちかに固定されていれば片方だけで済み、その分コードが少なくなる。
だからプログラミングモデルとしては、固定されていた方がいいんだよ。
例えば、.NETは割と固定されてる。
ただ、上記リンクを見る限り、ブラウザの実装の余地を残す為（というのは後付だろうが）
放置って感じか。
10年前のstackoverflowは見なくていいから仕様を読もう
ttps://w3c.github.io/uievents/#events-mouseevent-event-order 10年経ったら君の街でさえもあちこち変わってるだろう？
Webの世界なんてそれとは比べものにならないよ
> mouseout->mouseoverの順で固定されていればコードが減らせるんだが、
コードを書いて検証してみたのか？
仕様にも書いてあるようだが
ttps://triple-underscore.github.io/uievents-ja.html#events-mouseevent-event-order おお、サンクス。
確認したところ、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の仕様委員会は馬鹿だから、気づかなかったのか？とも思える。
その変化の遅い１０年越しの変更にもついてこれてないあんたは何も言えないよ
.NETだってそもそもTaskあってのasyncなんだが
「Webの世界なんてそれとは比べものにならないよ」と言ってるのに
「JSは他よりも進んでるんだぜ」と言ってるように思われるなんて心外
> googleさんもうちょっと頑張ってくれ、とは思うが、
> このレベルの詳細についてはMDNも未対応なのは認識した。
こういう認識の人がJavaScriptの何たるかを語っても説得力がまるでない
二次情報をあてにして、振り回されるだけ
それを「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は冗長だと判定したようだ。
2のoverが発生した後にenterがキャプチャ順で発生している。
本当は2のoverは5.5の所にないといけない。
そしたらenterがキャプチャ順、over/outがキャプチャ/バブル、leaveがバブル順で
綺麗に入れ子になるだろ。
C++の場合はリソース管理上厳密に入れ子必須なのだが、
JavaScriptの場合はここら辺が甘いから上達しないってのはある。
元凶は仕様委員会がゴミだから仕様がゴミになっていること。
結果、JavaScriptではゴミコードしか書けなくなっており、
お前らは美しいコードを見たことがなく、感覚が鈍いままになってる。
C++が良いとも思わないが、ある程度「ちゃんとした」環境がないと上達しない。
動けばいい、でやっている限り、動けばいい程度のコードしか書けないままだ。
JavaScriptは仕様委員会の連中がこの程度なのが最悪だ。
何を目指してこの仕様にしたのか、どういうユースケースを想定しているのか、さっぱり分からない。
お前らと話していると、技術的な面にはだいぶズレを感じる。
何度も言っているが、お前らは分かってないし、上達してない。これは自覚した方がいい。
ただ、ググッても出てこないような仕様を抑えている点を見ても、
お前らが努力してないって事はないんだろう。(これも前に言ったが)
今のお前らでは気づけないのだろうけど、
JavaScriptにはお前らの上達を阻害している要因が結構ある。
それは自覚して回避することは可能だから、信者になってマンセーするのではなく、
良い点と悪い点を冷静に見極めて行った方がいい。
そうすれば割とあっさり上達するのかもしれん。
今更変更してて、しかもMDNに4年後も反映されてないってのは想定外だった。
もっとも、仕様化されている≠今の実装がそうとは限らない、もガンな所だが。
JavaScriptが「プログラミング言語全般からすると」比較的簡単な言語だ、
と認識しているのならそれで問題はない。
> .NETだってそもそもTaskあってのasyncなんだが
それはない。
JavaScriptでpromiseが既に要らない子なのと同様、
C#では既にtaskは要らない子だよ。この点はC#も失敗してる。
JavaScriptは仕様委員会がパヨク化していて、ポリコレを振り回しているのがいけない。
asyncが見えていたのに「○○はpromiseを返します」なAPIとか、
httpsでしか使えません、とか、腐ってるだろ。
httpsにするかしないかはユーザ判断であって、JavaScriptの仕様委員会が決めることではない。
技術的な話に徹しておらず、結果的におかしな仕様選択になっており、次第に腐って行ってる。
何でこんなになってしまったのかは知らんが。
他言語も最近はかなりの頻度で仕様変更してる。
JavaScriptの変化が特段早いわけでは全くない。
ただ、Webは下地が固まってないのを変更しているから、変更が大きく見えるだけ。
俺はMDNは一次情報扱いだ。
ただし4年も遅れているとは認識出来ていなかった。
googleは結局Webページの巡回であって、pdf文書やGithubの中身の網羅までは出来てないって事だ。
冷静に考えれば当たり前だが、俺は気づいていなかった。
DOMの話なんだからJavaScriptの仕様とは関係ないだろ
そういうふうに詰めが甘いから、お前からは素人臭してしてこないんだわ
個人のブログからネタ拾って紹介したりしてるぞ？
そんなんあったっけ？URLよろ。
APIの一次情報でもない、DOMの一次情報でもない
MDNはブラウザが実装している機能の一次情報
> DOMの話なんだからJavaScriptの仕様とは関係ないだろ
> そういうふうに詰めが甘いから、お前からは素人臭してしてこないんだわ
まさにその通りなんだが、「お前ら」は ID:qM8cSWzB に訂正しておいてくれ
DOMをJavaScript以外で扱ったことがないようだ
「Promiseが既に要らない子」はFetch全否定だし、仕様書をまともに読んだことがないのだろう
MDNはFxの一次情報
あなたはFxだけ対応すればいいと考えているのだな
くぷぷｗｗｗ
Firefoxだけの一次情報なわけないだろｗｗｗｗ
要するに、自分にとって一番良さそうな資料を読めば良いだけ。
仕様書を読んでる俺カッコイイとか、必要ないんだよ。
俺にとってはMDNが一番マシだから、俺はそうしてる。
仕様、説明、サンプルコード、互換表、注意点、が載ってる。
仕様書は仕様しか載ってない。
MDNに同項目があるのならそっちの方が便利だ。
MouseEventOrderについて丸々抜け落ちている理由は分からない。
MDNを書いている奴らからはコードを書いているニオイはするから、
この項目の重要性が認識出来ていないとは考えにくい。
ブラウザに未実装なのか？
しかしあの仕様はどっちかというとJavaScriptの他項目と同じで、
「美しい仕様を考えた」よりは「現状のブラウザの実装を調べた」に近いから、
これも考えにくいのだが。
とはいえ、この件で妥当な「載せなかった理由」が無ければ、
MDNの項目の選定もおかしいことになり、
お前らの主張「仕様書を読め」も妥当だということになるが。
ブラウザが実装している機能の
一次情報だろ
wikiみたいなもんだろ
ttp://hkdnet.hatenablog.com/entry/2017/10/22/100000 > んで、これをちょっと読んでたんですがサンプルコードがわけわかんなかったんですよね。
> 僕が作った例のがイケてるんじゃね？と思ったのでコントリビュートしてみました。
一次情報がなんだって？ｗｗｗｗｗ
なら日本語でおk
このオジサンは
Web > 君の街 という比較例を出しただけなのになんでC#とかasyncとかの話勝手に持ち出してきて発狂してるの？？？
それが分からないのはお前が馬鹿だからだ。
他の連中は反発しつつも、
「何故俺がそれをここで言うか」についてはついて来れてるだろ。
ああそーーっすかぁ
>>JavaScriptは「簡単」だし「遅れてる」面も結構ある。
他言語をやれば分かる話なのに、理解出来ないのは、他言語が全く出来ないからだ
こんなマウント取りやっといて10年前のstackoverflow漁ってたの図星されたから悔しかったわけじゃないんすねー
俺がバカだったんすね
すいません勉強しまーーーす
突っ込んでくるところがおかしい。
折角877で仕様の不自然な点を挙げているのだから、（技術論）
仕様に詳しいつもりならそこに突っ込んでこいよ。
俺を言い負かしたいのならそこが格好の攻撃ポイントだろ。
なんつーか、マジでお前ら『文系的』揚げ足取りしかしないよな。
C/C++スレの連中も十分狂ってるが、あいつらは基本的に技術論だからいいんだよ。
お前ら、こんなレス読んでてもなんの足しにもならんだろ。
そういう姿勢が上達を妨げている、ってのもあるよ。
幼稚園児レベルの「言われたら言い返す」ではなくて、もうちょっと大人になれ。
俺がお前らにマウント取って、何の意味があるんだよ？
> こんなマウント取りやっといて10年前のstackoverflow漁ってたの図星されたから悔しかったわけじゃないんすねー
こういう風に取れる＝お前はマウント取りをしたがっている、と分かる。
まあ、若いんだろうさ。
もちろんやりたければやればいいんだが、
それをしたところで何もお前の為にはならないといい加減気付け。
JavaScriptがどうなのか、というのは比較論であって、
当たり前だが他言語も知ってないと何も言えるはずがないんだよ。
そして他言語を知ってれば、マンセーではなくて、
いいところも悪いところもある、と分かるはずなんだよ。
お前らからはこの感じを受けない。
だから知りもせずにマンセーしてんじゃねーよ馬鹿共、と言っているわけでさ。
他言語と比べれば、
> JavaScriptは「簡単」だし「遅れてる」面も結構ある。
のは事実だし、具体的に挙げたろ。
それについて技術的に突っ込んでくるのではなく、
こう言ったことに対し感情的に突っ込んでくるうちはお前らは上達しないよ。
どこからでもいつでも生存期間を延長しようと言語仕様そのものが狙ってくる。
従ってアプリ固有のマクロ程度が使用限界となる。
意味わからん
誰も他言語と比較なんてしてないんだけど
君自信も「仕様の更新頻度が高い」と認めてたじゃないか？
までに色々書いてるけど全部自分に跳ね返ってないか？
一番人の発言を変な捉え方して、意固地になってるのは君だと思うよ
そもそもね
Webって「完成物」じゃないからね、常に発展途上で皆で作っていくのがWebなの
仕様だって沢山定められているし機関もあるけど、別にそれらがWebの支配者なわけじゃない
MDNに無い？ なら書き加えればいいじゃん？ と思われるだけ
現状の改善のためには不満を持つことは大変よいことだけど
少なくともここはその不満を書き散らすような場所じゃない
君は街の観光案内所に行って、この街は遅れてる！認めろ！とか叫ぶ人なのか？
Googleとの対決に負けて以降、W3Cは機能していないんだから。
まともなやつならWHATWG追うだろ
名前は忘れたがXHTMLガン押しのカリスマおっちゃんいたジャン
その後にHTML5を進めた貢献者もそのおっちゃんだけど
良くも悪くもそのおっちゃんのセンスに振り回されてたのが昔だよ
一方Googleはデータ主義だし、各専門科は狭い分野を担当している
仕様も分散してカリスマがいない事によるデメリットもあるけど
どちらかというと今の方が個人的には気に入ってる
俺はXHTMLには否定的だったな。
XSLTは最悪の技術だった
自分のセンスが正しいことが証明されたよ
カスタム・タグのセキュリティについてはHTML Tidyのプロジェクトで議論しているのでよかったらどうぞ。
基本的に悪い方向に向かっていると思います。
これを安全に扱えるのは最早Googleしかいないんじゃないでしょうか。
後方互換性がなかったのが問題だった
これについては、MSの功罪が大きい
MSがIEをアップデートしていたならば、XHTML2が生き残る道はあった
Webサイトと言うのはもはやそういうものとは限らないからな
Googleの野心にウェブ全体が付き合わされる必要はないんじゃないでしょうかね。
なんでもMSのせいにするのはやめろ
ネットスケープはとにかく落ちるブラウザで、直前に読んでいたページのせいで次のページが落ちるなんてこともよくあった。
ネットスケープに一番苦しめられてたはずのウェブ屋さんは何故かネットスケープマンセーしてたんだよね。
そして今、グーグルに一番苦しめられてるはずのウェブ屋さんがグーグルマンセーなんだよ。
おそらくこれ知能指数の問題じゃないかとにらんでる。
ウェブ屋さんの平均知能指数は他の業種より低いはず。
僕は、たった二週間で作られた言語がそんなにいいわけないと考えるんだけどね。
固定することなく次々仕様が改良されていく、とても素晴らしいってね。
仕様がころころ変わって一番いじめられてるはずのウェブ屋さんがそんなこと言うんだから、面白いよね。
XML Schema はだめ。
早く捨て去った方が良い。
最近はJSer同士の喧嘩がほとんどだった気がする
いいぞ、もっとやれ
決定的なアルゴリズムと言う面でも、別にカスタムタグがあるからといって非決定的になるわけでもなく、カスタムタグ通りに動くだけであって、カスタムタグを想定していないガバガバな方がよろしくないかと。
そこまで否定的な事言ってたか？確かにTidyのIssueで何度も上がってるが、その文脈での反論には「そもそもvalidatorじゃ無いんだよ？」とツッコミ入ってたかと。
Javascriptがダメと言うのは、もう論外の発想では？
なんのための標準化なのか
せ、生活水準？
俺はたった二週間でできるわけないので、
その情報の出処はどこなのか、どの部分を二週間で作ったのか
それまでに似たようなものを作っていたのではないのか？って思うけどね。
Javascriptは明らかに駄目だろう。
元々はちょっとしたマクロのようなものを想定していたんだろう。
その程度のものをアプリに使おうというのが無理筋すぎる。
しかもそれがネットを介して作動するのだから、もはや気がくるってる。
だから改良されたでしょ？
今のJavaScriptは昔のJavaScriptとはぜんぜん違うよ
いいや駄目だ。
だめではないね。最新のJavaScriptは
他のどんな言語よりも優れてる
最新の仕様に無頓着なのは完全に別問題、言い訳もクソもない
848 デフォルトの名無しさん sage 2018/05/31(木) 13:00:56.28 ID:Mu/CSqL6
日本生まれのクソ言語Ruby『最も嫌われているプログラミング言語』堂々ランクイン！！
ttps://japan.zdnet.com/article/35109803/ おめでとうクソ言語！🎊
おめでとう日本の恥！！ｗｗｗ
ttps://japan.zdnet.com/storage/2017/11/02/e28392adae17a191547db083133339eb/171106-zdnet-1-01-languages-1-900x675.png 何でもMSのせいにはしていない
違うよ。当初から単なるマクロは想定してない。だろう論で話さずに、lispが作りたかったんや！って本人が言ってるあれ読んできたら良いよ。
ネットを介してが何を指してるかもわからんけど。
ブラウザ≒ランタイムなのが気に食わないのかな？
> 意味わからん
そりゃお前が馬鹿だからだ。
ただお前、866か？
ならそれは有効な情報だったし、多少はマジレスしよう。
今のお前の価値観は、完全に「Webしか出来ない意識高い系」そのものだ。
非Web系言語を何でもいいから一つでもやってみるといい。
そうすれば、JavaScriptの糞な所が理解出来、
自分の発言のどの部分が間違っているか分かるだろう。
> そうすれば、JavaScriptの糞な所が理解出来、
> 自分の発言のどの部分が間違っているか分かるだろう。
意訳
説明ができない。相手を説得できるだけの根拠がない
せや、相手にJavaScriptの糞な所を自分で見つけさせよう
相手が糞な所を調べられなければ、相手のせいにできるし
相手が糞な所調べれば、一石二鳥
俺って頭いい！
ということで、お前の卑怯な戦略は封じたので、
さっさとJavaScriptが糞な所をお前が説明しろ
XHTMLの仕様を引き合いに出すのになぜかW3Cじゃなくて日本語wikipedia持ってきて頓珍漢なこと書いた挙げ句2018年にHTML6とかいうワード出してきたLiving Standardの存在すら知らない化石だろ
仕様書の中身覚える必要は全くないけど仕様を知りたくなった時に適切な場所で調べる能力がないのはエンジニアとして終わってんだよなあ
昔よりだいぶマシになったとは言え書かずに済むなら書きたくない言語だ
何でそんなに信者になるのか分からん。
お前らが馬鹿なままで居続けるのはお前らの自由だ。
同様に、お前らが俺のアドバイスを信じてみるのも自由だ。
結果は周りの奴ら、つまりお前らの同僚や後輩が判定してくれる。
今と同様に間抜けなことを言い続けたら馬鹿だと見なされるだけ。
JavaScriptが糞かどうかは別として、
他言語を学ぶのは上達への一つの方法ではあるから、やってみるといい。
そうすれば、JavaScriptがどうなのか客観的に分かるだろう。
そもそも、良い/悪いってのは比較論なんだから、
他言語を何一つ知らない奴が言っていい事ではないんだよ。
ES5以前のこの動きは駄目だろうと言いたくなる仕様が沢山あって初心者が中級者に上がる所が辛い言語だと思うわ。
肝心のES2015も新サポートの構文増え過ぎで、勉強し始めは「これらは本当に同じ言語なのか…？」と戸惑うところが結構あったし。
でもまあ、モダンな環境に一通り触った今ならそんな糞言語だとは思わんな。
それは非Web系の常識だ。
JavaScriptは特に悲惨で、仕様と実装が全く同期してない。
だから割と出たとこ勝負で、それが嫌だから例のnpmの件、
・作者がnpmと揉めてコードを引き上げたら、
それをリンクしていたWebサイトが突然軒並み動作しなくなってプチ祭り状態、
どんな凄いライブラリなのかと思いきや、なんとたった1行！
他言語の連中の反応はマジで冷ややか、『こいつらはコード書けないのか？』
なんて事が起きる。
仕様と実装が同期していないのも、普通に考える「実装が追いつかない」ではなく、
・仕様化されているが、実装されていない
・仕様化されているが、異なる実装になっている
・実装されているが、仕様化されていない
（リファレンス実装無し＝物によって動作がバラバラ）
の全部ある。
だから仕様を調べて…という『一般常識』だと盛大に空振りすることもよくある。
俺はこれがJavaScriptの最悪なところだと思うけど、
JavaScriptしか知らない奴はこれが普通と思っているから、話が通じない。
プログラミング部分はRuby でやって、
Rails から、jQuery, Vue.js とか使うのが一番
ttps://youtu.be/ycOeM2umXkY 伊藤淳一 Junichi Ito の動画
Rails 5.1 から、Vue.js を使う
ヘイトぶちまけたいなら愚痴スレ行け
ちなみに俺は素のJSは馴染まないから理由がない限りTypeScript使う
そして死刑が執行されて民衆が納得する。
このままだと暴動起きるよ？
848 デフォルトの名無しさん sage 2018/05/31(木) 13:00:56.28 ID:Mu/CSqL6
日本生まれのクソ言語Ruby『最も嫌われているプログラミング言語』堂々ランクイン！！
ttps://japan.zdnet.com/article/35109803/ おめでとうクソ言語！🎊
おめでとう日本の恥！！ｗｗｗ
ttps://japan.zdnet.com/storage/2017/11/02/e28392adae17a191547db083133339eb/171106-zdnet-1-01-languages-1-900x675.png 君は非常に大きな考え違いをしている
それは大変な間違いだよ
仕様は仕様、それを勝手に利用してる実装は実装
両者の問題を混同してはいけない
君の理屈だと例えばあるビデオコーディック対応と謳ってながら実際は
プロファイルなどによって再生できなかったり、色の再現などに関して問題が起きたり
いろんなプレイヤー間に非互換性があることに関して
そのコーディック仕様に文句を言うようなもの
そういうライセンスを与えてるならまだしも、
仕様側には世の中の実装を正す責任も権利もないし
そういうことで仕様に対して文句をいうのは完璧にお門違いの話
実装に関しても、もし〇〇対応と言っておきながら違っていたら嘘を言ってることになるが
実際はそんな具体的に対応機能を列挙してそれを価値として売ってるブラウザなんて少ないし
実装に誰から言われなくとも自分たちで気づいて直す義務があるとまでは言えない
『これとこれとこのプレイヤーでは最低でも再生できる動画を作りたい』と願うのは俺たちの方で、
あくまでそれは『俺たちの勝手な願い』なのだから、そこで生じる問題は俺たちが負うのは至極当然のこと
もし、実装に直して欲しいと願う部分があるならば、最低でもissueやパッチを投げるくらいの義務は俺たちの方にある
それなのに実装や、ましてや仕様を「悪」というのは随分おこがましいな
仕様を最初に調べるのが常識なのにMDNやら10年前のstackoverflowやら漁って失敗したのがオマエだろ
JSはクソだがベンダの実装がクソなことと言語がクソなことの区別がつかないオマエはそれ以下の糞
ここの区別がついてないと昔よりだいぶマシになったモダンな言語仕様通りに書いて、実装の汚いところはトランスパイラによしなにやってもらうという解決ができない
御託並べて仕様も読まない奴「仕様など読む必要ない！」
前者は嫌だが、後者ならまあ普通に使えると思ってる。
※個人の意見です。
ES2018使えるか、ES5どまりか、って違いじゃないの
