+ JavaScript の質問用スレッド vol.136 +
レス数が1000を超えています。これ以上書き込みはできません。
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」から解離した議論はよそでやること。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。
【条件】期待する回答の条件を書いてください。
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです ■FAQ
◆開発者ツール(Developer Tools)の基本的な使い方
▼諸注意
- 本説明では Google Chrome の開発者ツールの名称に従います。他ブラウザで使う場合は適宜読み替えて下さい。
- Edge- でコンソールを使うには予め開発者ツールを起動しておく必要があります(開発者ツールを起動しないと console.log() が機能しません)
- Safari はデフォルトで開発者ツールが無効な為、有効に設定する必要があります。
https://developer.apple.com/library/safari/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/GettingStarted/GettingStarted.html
▼要素を検証
1. ページ上で右クリックして [要素を検証]
2. [Elements] パネルが開き、対象のDOMノードが選択される(選択対象が目的の要素でなければ [Elements] パネル上で選択し直す)
3. 右側のサイドバーから知りたいステータス名のタブを選択する
- [Styles] タブ … CSSプロパティの指定値を表示 (※カスケードによって上書きされたプロパティは取り消し線で表示される)
- [Computed] タブ … CSSプロパティの算出値を表示("font-size: 1em" を指定していても算出後の "*px" で表示される)
- [Properties] タブ … 選択したDOMノードのプロパティを表示
▼コンソール
1. JavaScript コード上で console.log('Hello, World!'); と入力
2. [Ctrl] + [Shift] + [I] キー(IE は [F12])で開発者ツールを開き、[Console] パネルを開く
3. [Console] パネルに "Hello, World!" と表示される
(※window.alert() は String 型に変換されますが、console.log() は Object 型の中身をそのまま表示してくれます。) ■FAQ(続き)
◆JavaScriptの実行速度
JavaScriptの速度は「ブラウザ名」「ブラウザのバージョン」「PCスペック」に依存します(ブラウザのバージョン毎に最適化具合が異なります)。
速度の疑問解消の為に http://jsperf.com/ （githubのアカウントが必要です）にコードをUPしてブラウザ毎に速度計測する事を推奨します。
例外として、仕様における理論上の速度が明確になっている場合があります。
例えば、正規表現によるマッチング処理を考えた場合、「RegExp#test > RegExp#exec > String#match」は ES5 仕様で保証（要出典）されています。
ES5 仕様において RegExp#test が最も処理数が少なく、String#match が最も処理数が多いことが明確だからです。
ブラウザによっては RegExp#test の最適化が十分でなく、String#match の最適化が RegExp#test より十分であれば逆転する可能性はありますが、各メソッドの最適化が一律であればこの前提が崩れる事はありません。
■各種仕様
◆ Standard ECMA-262
http://bclary.com/2004/11/07/ (ECMAScript 3 HTML版)
http://www2u.biglobe.ne.jp/~oz-07ams/2002/ecma262r3/ (ECMAScript 3 和訳)
http://www.ecma-international.org/ecma-262/5.1/ (ECMAScript 5.1 HTML版)
http://tsofthome.appspot.com/ecmascript.html (ECMAScript 5.1 和訳)
http://www.ecma-international.org/ecma-262/6.0/ (ECMAScript 6 / ECMAScript 2015)
http://kangax.github.io/compat-table/es5/ (ECMAScript 5 compatibility table)
http://kangax.github.io/compat-table/es6/ (ECMAScript 6 compatibility table)
◆ HTML Standard (HTML5)
http://www.whatwg.org/specs/web-apps/current-work/multipage/
http://momdo.s35.xrea.com/web-html-test/spec/WD-html51-20130528/Overview.html (HTML5.1 部分訳)
http://www.hcn.zaq.ne.jp/___/WEB/WebStorage-ja.html (Web Storage 和訳) ■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。 脈絡なくRubyとかいうオワコン言語の宣伝始めるキチガイが定期的に沸くため「Ruby」でNGワード登録推奨。 いいじゃん別に
昔みたいにちょくちょく多言語勢が遊びに来ることも無くなったし
バトロワスレも無くなったし
言語の比較からくる質問的話題作りとでも思えばさ
過疎ってるんだし、間口は広げるべきだよ 10年以上前のコードを引き継いだのですが、ソース内にfunction window.onload(){}なるメソッドがあり驚いています
windowロードされた時点で処理したい内容が書かれているのでそれは書き直す事ができるのですが
昔はfunction window.onload(){}といった書き方ができたのでしょうか？
変な質問ですがググってもよくわからなかったのでこちらで質問させてください
（もしかしたら前任者が最後に全置換とかして置いてった爆弾的なモノかもしれないので、それをはっきりさせたいのです…） えっ、むしろ今出来なくなってたの？
まあ使わないけどさ そんな書き方はじめて見たわ
function obj.prop () { ... }
みたいに関数名にドットシンタックス使ってるってことだよね？
試してみたらSyntaxErrorなった function window.onload(){}
じゃなくて
window.onload = function(){}
じゃね？ それな普通だが、そうじゃなかったから頭抱えてるんだろう >>13
少なくともNetscape3以降から現在までの主だったブラウザでは駄目なはずだし
見たこともないなあ
ただ昔、グーグルができる以前は特に
今では想像を絶するような謎コードとバッドノウハウが量産されたので
そんなのに出会ったと思っとけばいいんじゃない？ 今動いてないものを大切に持ってても意味ないだろ
さっさと消せ >>13
IEならオーバーライドみたいにして動きそう
ところでそれ、動いてるの？ 親→idが「list」のulタグ
子→liタグ
liタグを作ってulタグの中に追加したいとする
var li = document.createElement(`li`);
li.textContent = `あいう`;
console.log(document.getElementById(`list`));
var ti = document.getElementById(`list`).appendChild(li);
こんな感じにすると、appendChildの前のconsole.logで作ったliが既に追加された状態で出るのはなんで？
で、var li〜をコメントアウトすると追加されない それ、追加された状態で出てるんじゃなくて、出てから追加された状態に更新されてるんじゃない？ >>26
appendChild前に alert('before'); を入れる >>14,23,21
昔ならIEでなら動いたが正解なんでしょうか？…謎ですね
コードは当然書き直しますが貴重な意見が聞けて良かったです
ありがとうございました
>>24
やっぱりIE特有のアレなんですかね
これが1番濃厚な気がしています（現行のIEだと不安定な動きです…基本エラーになります）
>>25
当然のようにSyntaxErrorですね 不安定とか基本とか恥ずかしいから辞めてくれ
笑わせたいのか webページで2ページ以上あるPDF表示させる前に、指定したページだけサクッと削除できるような方法ってありませんか？ これを使う。
https://github.com/mozilla/pdf.js
何でもできるが、大変だと思うよ。
重ねて言うがサクッとは無理。 jsの入門書やって、ドットインストールのおみくじを作る…みたいなのをやってるんだけど
そこからwebサイト作るようになるには、何やればいいんでしょう
githubのソース見るとか？
入門書は沢山あるけど、そっから実際に作るまでどうしたらいいのか分からず、、 >>35
サーバー借りてwordpress入れてあれやこれややってりゃ出来る
サーバー触らないと超しんどいよ
確かさくらサーバーは一週間ぐらい無料で借りれたはず
多分最初はjs触らず、htmlとcssばかりになると思う >>31
サーバ側でならわりとプルンとできるよ
たいていの言語で、PDF扱うライブラリあるし 初心者は、Ruby の、Rails, Sinatra で作るのが早いし、わかりやすい。
でもGUI は、HTML, CSS, JavaScript だけど
Vue.js, Node.js + Express など、JavaScript のフレームワークは面倒 >>35
GitHub Pageが無料で手頃だからオススメ
別に「Webサイト」を作ろうとしなくてもいいと思うよ
Canvas使った１ページだけのアプリケーションでも良いんだからさ
サイト丸ごとっていうのは、現実的に不可能だよ
そういうのを目指しても器用貧乏になるだけ
枠にとらわれず自分のやりたいことに注力したほうが良いよ >>41
業務ではes6、個人ではes6だったりjQueryだったり いやそれライブラリだから…
es5/6/7と同列に語るなよ… 業務でも個人でもes6だな
たまにts書かされたりもする いくら最新の構文が使えてもAPIが使えなきゃしょうがない
Babelが出た当初はまだしも今では大量複雑なAPIをポリフィルしきるのは困難
よって業務でも個人でもmodule対応かどうかで分けて
フル機能をES2017+で、最低限の機能をES5で書いてる APIと構文は用途が違う
APIは使うかどうかは、使う理由があるかどうかしょう？
例えば現在地を知りたいなら、Geolocation API は必須だが
そうでないなら、使う必要がない。
新しいAPIだー、何が何でも使わなくちゃー
なんてなるわけないんだからさｗ
つまりは、最新の構文が使えることと、APIを使うことは別なわけで
なんでそこで、最新の構文が使えるのに、APIが使えないんだ、クソッ
なんて状態になるわけがない
> フル機能をES2017+で、最低限の機能をES5で書いてる
フル機能をES2017+で、最低限の機能もES2017+で書けばいいじゃん？
「最低限の機能」では新しいAPIを使ってないはずだから可能 >>45
BabelはトランスコンパイルするからPolyfillとは別概念だけど、いろいろとごっちゃにしてない？ >>46,47
ごっちゃにしてない
最新の構文が使えることと、APIを使うことは別ではない
APIは今や1機能と言うわけではなく各種Workletだったり、
書き方や設計の問題なのだから
モダンブラウザでは新しい構文・新しいAPIで新しい概念のコーディングができる
それが古いブラウザではできない
ポリフィルできない、プログレッシブにもしにくいAPIが増えてる現状
構文だけトランスパイルできても仕方がない
最低限の機能というのが伝わらなかったようだね
<script nomodule>alert('モダンブラウザ使えやゴラ')</script>
やってることはこれと実質変わらない
トランスパイルする必要がない > 最新の構文が使えることと、APIを使うことは別ではない
別だろ・・・・
お前JavaScriptとブラウザのAPIをごっちゃにしてるな
Nodeとか使ったことあるか？
お前の大好きなそのAPIはNodeにはないぞ
そのAPIがないNodeでも最新の構文が
使えるというメリットは有るわけだ >>49
Nodeは0系から使ってるが
>>そのAPIがないNodeでも最新の構文が
>>使えるというメリットは有るわけだ
何が言いたいのかさっぱり伝わらない
Nodeで最新の構文が使いたければ--harmony-*とするだけ
V8がまだ対応していないものは草案も草案だからまだ使おうとは思わない babelしてポリフィルかけた後のjsに対してAPI使えばいいんでないの？ 他人のコードを読んで学びたいんだけど、みんなgithubみてたりすんの？
それともカンファレンス行ったりする？ あ、ごめんすぐ前に>>40があったわ
github pageとか見ればいいんだね
チェックしてみる >>53
俺がずっと言ってるのはモダンブラウザとレガシーブラウザの差が付き過ぎてきたから
１つのコードを元に両対応しようとするのはもう限界を過ぎてるってこと 勉強しようと思ってyahooやgoogleのhtml見るとおったまげる >>52
だからブラウザのAPIなんか使わなくても、
新しい構文を使う意味はあるってことでしょｗ >>56
なあ、お前、お前のコードは必ず新しいAPIを使わなきゃならんのか？
モジュールごとにわけてないんか？
新しいAPIを使わないモジュールだってあるだろ
ないんか？驚きだ >>58
生HTMLやJavaScriptを書くことなんかなく、
変換して生成しているようなコードが出てくるから そうよ。古いブラウザに対応する場合でも
新しいコードで書いてbabelのようなツールで変換して生成する。
そうやって、モダンブラウザとレガシーブラウザの
差を吸収してるわけ。それが今の常識 googleはcssもjsも外部ファイルにしてないんだよね
html一枚のみ
超早い そう。もちろんコードを書くときは複数のファイルに分かれている
それをツールを使って結合している。 そうなんだよね。ブラウザがJavaScriptモジュールに対応したと言うけれど
外部ファイルである以上、どうしても遅くなるんだよ。
だから最終的には何かしらのフレームワークを使って
ビルドして1つないし数個のJavaScriptファイルにするっていうのが
現実的な解になる 今更ながらreact始めたけどこれいいね
vueはまだ >>46
例えば、class構文を使う時、「Geolocation APIの必要性」によって、採用を取りやめたり、採用に踏み切る事は有り得ない >>69
レスする相手間違ってるぞｗ
そういうことだよ。APIを使っても使わなくても
class構文が使えるというメリットがあるから
>>45が言うような「いくら最新の構文が使えてもAPIが使えなきゃしょうがない」
なんてことにはならないんだよ
たとえAPIが使えなくても、最新の構文が使える 俺はトランスパイラの一般的用途である１つファイルを書いたら
モダンブラウザにもレガシーブラウザにも対応できるという事について言ってるだけであり
ありとあらゆる場合においてBabelが不必要とは言っていないんだが
現実APIの対応差が大きすぎるので共有スクリプトで対処し切るのには限界がある
だから例えばモジュール対応で分けてピュアJSで行くべき
そして過去スレでも度々話題に出るようレガシーブラウザには無理をさせるべきではないので
その対応コードはかなり小さいとすると、
その対応コードだけトランスパイルを試みるよりも、プロダクトや社から
トランスパイラというシステム・工程を１つ取り去った方が良い
そういう「大局的なメリットがある」のでうちの所はそうしている
という事例を挙げて言っているのであって
いくら小さい局所的なケースだけをメリットが有る、使える云々言われても
あぁそうですねとしか言えないんだが >>71
言ってることが破綻してる
「APIの対応差が大きすぎる」のと
トランスパイラを使うことになんの関係もない
APIを使おうが使うまいが、JavaScriptのコードを書くわけで、
そのJavaScriptのコードは同じモダンな書き方に
統一したほうが楽だという話だろ
なんで「くっそAPIが使えない。だからAPIを使わないコードを書くしか無いけど
だがそのAPIを使わないコードを、古いJavaScriptコードで書かないと
いけない病気が発動してしまう」ってなるんだよ？ >>71は結論ありきで語ってるからめちゃくちゃになって
意味不明なんだが、要するに共有できるコードに
トランスパイラを使うかどうかって話
特定のAPIがなければ、そのサイトがまったく利用できないって
場合じゃない限り、モダンブラウザにはフル機能、
レガシーブラウザには制限された機能を提供することになる
つまりモダンブラウザ専用コードとモダンでもレガシーでも
使える共有するコードの二種類に分かれる
（レガシーのみで使うコードってのはないかごく少数）
で、>>71は共有コードに対してトランスパイラを使わずに
古い書き方をしましょうと言ってる。アホとしか言えない。
大半の機能は共有コードになるんだから、その部分こそ
新しい効率の良い書き方をして、レガシーブラウザ向けには
トランスパイラを使って同じコードで動くようにすることで
多くのムダが省ける >>71
> 俺はトランスパイラの一般的用途である１つファイルを書いたら
> モダンブラウザにもレガシーブラウザにも対応できるという事について言ってるだけであり
BabelはESの範疇でトランスコンパイルするだけで、全APIを吸収するとはいわれてない
完全なるあなたの勘違い >>74
言われてない?
俺が言ってるんだが
完全なるあなたの思い込み Babeは全APIを吸収するものである・・・>>77だけが言ってる
世間ではそんな事は言われていない API＝関数群
と思ってたけど最近はclassも多いし定数もあるしで日本語だと何になるんだろう gatsby勉強中なんですが
import React from "react"
import { Link } from "gatsby"
この{ Link }の部分はなぜ{}で囲まれているのでしょうか ttps://stackoverflow.com/questions/41337709/what-is-use-of-curly-braces-in-es6-import-statement
自己解決しました トランスパイラは、文法を変換するだけ。
IE, Edge では動かない
jQuery, Electron, React, Vue.js のようなフレームワークを使わないと、プラットフォーム互換性はない >>77
> 俺が言ってるんだが
では、あなたの認識がおかしい >>77が「全APIを吸収する」と言っているとして、どの辺が反論になってるの？ IEなどで動くように文法変換してるんだろ？
そこで吸収できないものをフレームワークで出来るって、どんなAPIの話してるんだ？ 質問
Javascriptでフォームから投稿した内容をtableで過去の他の人の投稿と混ぜて行毎に表示して、投稿した項目をキー毎に並び替えるのって可能？
PHPならDBに格納すれば出来るのはわかるけど、DBは無料のレンサバだと使えないっぽいし、サンプルとかも調べてみたけどjavascriptで両方やってるサンプルが見つからなかったわ >>87
その程度なら
テキストファイルに記録しておくなんて手もある DB に保存できないのなら、
過去の他人の投稿は、どこに保存しているの？
A の投稿は、AのPC に保存しているの？
そのデータを、B が取得できるの？
他人のPC 内のデータは、取得できないはず DB使うようになったら迷わず有料サーバー借りたほうがいい
ファイルをDB代わりにするとかしんどすぎる
xreaなら一ヶ月契約したら後はずっと無料で使えるってシステムだったと思うから、
そういうとこ探してもいいかもね >>88
>>89
さんくす、ググったらこれで出来るっぽいな
https://algorithm.joho.info/programming/javascript/localstorage-table/
Localstrageとかいうのに保存すれば行けるんやな、他人の表示されてるのか知らんけど
後はTableソートのプラグインでも入れて、自分しか投稿を削除できればいいか ああダメだったわ、他の人の投稿取得できてないわ・・・ ゴールが見えない
ソート用のライブラリとか対応してるフレームワーク使えば >>87
PeerJSとかのサービス使ってWebRTCで結べばWebブラウザが即席のサーバー代わりになる
Nodeやブラウザアプリで実装するのに比べてIPが変わっても大丈夫だし
DBはIndexedDBだったりクライアントサイドの技術で全部作れる >>98
お前が「ウンコ」と書く
お前がPCを落とす
相手が「チンコ」と書く
お前がPCを立ち上げサイトを開く
相手が、自分の書いた「チンコ」の上にいきなり「ウンコ」が現れビビる
さっき「チンコ」って書いたとき「ウンコ」なんて書かれてなかったのに！ >>99
それでも全然悪くないと思うよ
ラインだってそうだし、掲示板だって短時間とは言えそうだし
今でもあるのか分からないけど5chだって時間が入れ替わることあるしね
それに受付順にしたければそうすることは難しくないし >>100
お前が「ウンコ」と100回書く
お前がPCを落とす
相手１が「チンコ」と書く
相手２が「マンコ」と書く
相手１と相手２はこれを100回繰り返す
一ヶ月後、お前がPCを立ち上げサイトを開く
お前の書いた「チンコ」100回がチンコマンコ100セットの上に現れるが流れてしまっていて相手１も２も気づかないし時すでにお寿司
「チンコ」って超重要な情報だったのに！一ヶ月も前に書いといたのに！ >>101
いや、そうはならないでしょ
「お前」というのがサバ側の立場ってことだよね？
ならそもそもサバ側が立ち上がっていないとまず読み込めないし、
正常に書き込めないのだからそんな驚くような不思議挙動は起こりえない
普通に考えて遅延投稿も短時間の施行だけで良い
そういうレアなタイミング問題は考えても無駄
PC落とせばそりゃあサーバー落としたのと同じだから読み書きができない
それが嫌なら落とさなきゃいい、それだけ 事実上自分が中央集権サーバーになるんだな。
自サバをインターネットに晒してた時代に戻ったみたいだ。 インターネットに晒さないコンピュータをサーバと呼ぶ時代っていつだ Javascriptでブラウザーの「進む,戻る」ボタンを検知しようと思い調べ、
window.addEventListener('popstate', function(event) { .....
で、検知可能なのは確認できたのですが、
「進む,戻る」の区別が出来ません。
区別する方法をご存知の方、ご教示下さい。
よろしくお願いいたします。 戻る進むの区別は必要ない
どのstateの表示が求められているかを考えればいい >>107
無い
前後のhistory取ってそれと照合するしかない
めんどくさそ〜 >>110
俺が決めても必要がないものは必要がない
必要がないと言うかナンセンス
概念上いきなり過去のstateが開かれることもあるし、飛ぶことだってある
「戻る」「進む」という概念はナンセンス
pushするときはそのstateで必ず状態を復元できるようにする php使わないでサイト作れる？
それともNode.jsあれば作れる？ 87だけど、結局PHPで作ることにしたわ
何か負けた気分・・・ >>116
何がだよw
インターネットの仕組みをよく考えろ Webアプリ初心者がNode.jsに手を出すもんじゃない
どうせ後で詰まって時間を無駄に浪費する wordpressかなんかでいいんじゃない
あんまり低級なとこ触るとしんどいよ JavaScriptでcookieの(expireなどの)属性は設定できるけど、document.cookieをconsoleで表示させると属性が見えないんだけど、これは普通ですか？
Choromeのdeveloper toolとかじゃ設定されてるようなんだけど >>122 >>123
ありがとう。 これが仕様なんですね。
cookieStroeをgoogleするとAngularとかJavaでヒットするけど、生のJavaScriptじゃヒットしないような >>125
ありがとう。 まだ初心者なんで。
でも ChromeのDeveloper toolのコンソールで実験してもbrowserとかcookeisとかcookieStoreとかにアクセスできない。
これはWebExtensionとかいうのだから、普通のhtmlに埋め込んだJavaScriptからアクセスできるのでしょうか？
なにかimportとか外部ファイルを読み込む必要があるのでしょうか？ WebExtensionsはブラウザの拡張機能でのみ使えるAPI。通常のページからの使用はできない cookieStroe APIは確か今origin trial中でしょ
googleに自分のドメインを申請したサイトだけで使える
まあ今年度末くらいにはモダンブラウザで普通に使えるようになるんじゃない >>126
初心者であることはなんの免罪符にもならないので
あまり書かない方がいいよー
その方が学習が円滑に進むよー >>131
それdocument.cookie操作してるだけだから有効期限とかそいうのは取れないでしょ
それにjquery.cookieのプロジェクトはjQueryプラグインやめて単独動作可能なjs-cookieに移行してる おいおい、俺がいないうちに勝手に敗北とか言われてもな。
cookieはDOMじゃないんだから、そもそもjQuery厨の俺の意見として
jQueryプラグインとするなと言うべき案件だぞ
セレクタとどう組み合わせるんだ？って話だ
ということでjQuery厨の勝利だな。 >>127 >>128 >>129 >>130
ありがとうございます。 すっきりしました。 document.cookieは間違いなくDOMの仕様 DOM Level3以降の仕様からは消されたけどなw 脳足りんだな
いくら消されようと改めて定義されたり他と矛盾したりしない無い限り
その仕様は引き続き有効なんだよ Version3ではなくLevel3なのだから
Documentにcookieというプロパティを生やすのはずっとDOM2が参照されている
document.cookieは間違いなくDOMの仕様
脳足りんだな じゃあjQueryはDOM"要素"操作ライブラリって言えば納得するんか？
単なる言葉遊び、本質は変わらんよ 本質は変わらないんなら何故「cookieはDOMじゃないんだから」とか言ったんだ？ >>138
こういう人がいつの間にか動いていないシステムを作ってるんだろうな、と思う 何の仕様か良く分かってなかった人よりはずっと良さそう こいつDOMとHTMLの区別がついてないんだろ
「DOM要素」とかオレオレ用語使ってるし
DOMはDocument Object Model、ドキュメントのモデルであって
HTML要素はそこにマップされる仕様の一部でしか無い
document.cookieが「DOM上での要素」でないのは当たり前
しかし「DOM仕様の一部」であることは疑いようがない
Documentのインターフェイスを定義してるのがDOM仕様なのだから
document.cookieがDOM仕様でないはずがない The HTML DOM Element Object
https://www.w3schools.com/jsref/dom_obj_all.asp
要素は英語でElementっていうんやで >>145
document.cookieが「DOM上での要素、DOM要素」でないのは当たり前 なんだぞ cookie操作においてjQueryはオワコンってことじゃん 条件付きでオワコンと言うことは、
それ以外ではオワコンではないと言ってるのと同じやで web初心者です
主に他の業界を担当してました。
仕事やその案件の勉強のためにちょこちょこ色んなところを薄く手を付けてたら分からなくなってしまい、ここに質問させて下さい
▽今の状況
・progate（入門レベル）のHTML、CSS、javascript ES6はやった
・参考書でHTMLからidで取ってきて書き換えたり出力したりしてみた
・参考書を見てボタンクリックされたときの挙動書いてみたりした
・ローカルでHTML、CSS、jsファイルを作ってプログラムを書き、HTMLを開いて確認している
・PHPは少し分かる
・Node.jsを少し触らせて貰ったことがあり、そのときは開発サーバーでいじっていた
・他の言語の経験有り
▽
入門から実際にwebサイトを作るところでつまっています
ローカル環境で試したいです
以下、質問です
・フロント側もXAMPPのApacheとかでDocumentrootを指定して動かしてみたりした方がいいんでしょうか
・フロント側はHTML 1ページ（1ソースファイル）に対してjs 1ファイル（ページの挙動など）用意する感じなんでしょうか
・上の質問と繋がるのですが、Node.jsを触らせて貰ったとき、継承したりimportしたりしてましたが、フロント側も使ったりする機会はあるんでしょうか
（モジュールに分けて書くことがあるのか）
・DBから値を取得したりするのは素のHTML、jsでも出来ますか？Node.jsのようにサーバーサイドだけでしょうか
それとも、例えば表を作るときに、中の文字列などは仮置きで入れておいて、サーバーサイドのフレームワークなどに作成したファイル群を入れて、DBから取得してきたデータを仮置きしていた文字列部分を変数に変えて書き換えてもらうんでしょうか
例えばPHPのフレームワークのlaravelだと、phpでDBから取得する処理を書いて、bladeに渡して表示すると思いますが、
大体は先にフロント部分を作っておいて、サーバーサイドのフレームワークに乗せる、みたいなやり方なんでしょうか
長文、そして質問が分かり辛くてすいません…
教えてくださる方がいれば幸いです >>150
最初に言っておくと、Node.jsの導入って結構めんどくさい
廃れる可能性もあるから、要注意
・フロント側もXAMPPのApacheと
そう。テスト環境はXAMPPが良い。phpバージョンの差異には気をつけて
あとhosts書き換えることを覚えると良い。「ローカル 開発 hosts」でぐぐってみて
・フロント側はHTML 1ページ（1ソースファイル）に対してjs 1ファイル
大抵はjQueryと自前のjsの2つを読み込む。
ブラウザゲームのページを作るなど、よほど大きいコンテンツじゃない限りひとまとめで良いよ
分けても管理面倒なだけ
・継承したりimportしたり
継承ってのは多人数で開発する時に、機能を共有するためのもの
自分一人でブログサイト作るぐらいなら継承が必要な場面は無い
importはしたほうが良いが、多分どこで切り分けるかは分からないと思う。これは慣れなのでとりあえずやってみると良い
・DBから値を取得したり
サーバーサイドだけ
書き方はこんな漢字
https://qiita.com/AKYM21/items/5da2d8813bd8df5ab296
何を作りたいかは知らないけど、wordpressでもSymfonyでもフレームワーク使ったほうが楽と思う Node,jsのが廃れるの？Vue.jsじゃなくて？？ ここまできたらそうすう廃れたりはないだろうけど
なんで急にvueの名前出してきたのか？ >>153
可能性ね
phpとjqueryは腐らないだろうけど、Node.jsはそう遠くない内に衰退すると思っている
これは俺のカンなので、反論されても困るゾ >>152
おおおおおお…！！
ありがとうございます！
モヤモヤしてたとこが晴れました！
あとやっぱjqueryもやった方がいいのか…
お答え頂いたことを参考にやってみます
ありがとうございました！ そりゃ出来は良くても敷居が高い言語より出来が酷くても敷居が低い言語が残るよ
何人月で計算して数集めて、みんなでスパゲッティを作るのさ フロントエンジニアがやりたいのにバックエンドに入れられた
転職しよっかな… フロントは本当に気楽だからな〜
phpは止まったら死亡
dbは難易度高すぎィ！ むしろDB大好き
でphp嫌い
だからフロントに行きたい 楽なのはサーバーサイドで、気が楽なのはフロントだな >>161
お、客の誤字の責任を取らされる世界に来るかね？ >>144
>>134をよく読め
「cookieはDOMじゃないんだから」と書いてる >>163
デザイン系が好きなんだ
理系だけど大学はデザイン系に行ってた
なんのデザインも扱えないサーバーサイド楽しいと思う？ フロントは気が楽って実際にやってみればわかるけどクソ大変だぞ
上流が何も知らないと何故かサーバを作るところから始まるし、実現不可能なワイヤーフレームが上がってきたら出来ない理由を1から教えてあげないといけないし、デザインが期日通りに上がってこなかったらアラートも出さないといけない それで上がってきたデザインがjpegやpdf,excelだったりする
クライアントが実際にものが上がらないと見てくれないところの場合、デザインがなくてもそれっぽく見せないといけないし、デザインないのに大量に戻しを入れられる
上流の遅れのツケが全部下流に回ってきて、土日祝日構わず働かないといけないこともあるしサイトが24時公開の場合は時限公開しても待機してないといけない
給料も安いしよっぽどのどMじゃないとフロントエンジニアは出来ないね >>164
ばかか。だから>>144で "DOM要素" って訂正してるんだろ
なんかその感じだと DOM要素だったら間違いじゃなくなるから
訂正を認めないって必死になってる風に見えるぞｗ >>156
初心者は最初はフレームワークオススメしない
素でSQL書くようにしなさい
それをやっていく過程で、「こんなデータが送られてきたらやばくね？」とか気づく
そうしていくうちにセキュリティ意識が高くなるって自分でテスト攻撃と防御をするようになる
「フレームワークは中身何やってるんだかわからね」って感じになるから初心者は手を出すべきではない >>159
両方できるようになるべきだからその環境を喜べ フロントはjsでデータ保持して必要なときにajaxでバックエンドや他サービスへAPIリクエストするのが今後の主流だからその技術力がないとね
まあreactとか使うからバカでもできるんだが 今はサポートライブラリがたくさんあって公式でもsuspense来るからそうだけど、当初はreactでajaxは鬼門だっただろ。
少なくともバカには出来なかった。 jQueryのajaxの記法が変わった時は冷や汗が止まらなかった >>168
要素限定はお前が勝手に主張してるだけだろ
documentやwindowに.on()出来るし、.children()があるだろ
computedStyleはdefaultView見てるし、コンテキストオブジェクトでdocumentを指定出来るじゃないか >>150
Ruby on Rails, Sinatra をいじくり回すのが早い
DB アクセスは、フレームワークに付いている
HTML, CSS(SASS), JavaScript(JS) も使う。
JS は、jQuery, Vue.js, Node.js なども使う
テンプレートエンジンは、PHP に似た、ERB
<% price = 2500 * 1.05 %>
<p>
本の値段は<%= price %>円です。
</p>
Ruby で、PowerShell から、Web サーバーを起動すると、WEBrick が起動する。
ruby -run -e httpd . -p 8080
これだけで、index.html にアクセスできる。
http://localhost:8080 プログラマースレでRubyはオワコンみたいなのを読んだんだけど、どうなの？
javaとかより短く書けるからやってみたいなとも思うけど、今更なのかな？と思う気持ちもある 短く書ける事に何かメリットを感じるのなら、学習してみればいいんじゃないかな
俺にはちょっとよくわからない感覚だ >>173
なんで冷や汗が出るの？
古い記述が使えなくなったわけでもないし、
新しいjQueryにすぐに置き換えなければいけないわけでもないだろ >>176
世界的に使われなくなってるしそもそも嫌われてるからやらないほうがいい
気持ち悪い宗教に入信するのと同じレベル
短く書けるとか関係ない
世界の潮流に従うべき Python ブームに乗って、Pythonやった人が、ほとんど自滅してる
Ruby の偽は、nil, false の2つだけ。
一方、JavaScript(JS), Python, PHP などは、偽が10個ぐらいあるから、まともにプログラミングできない
Rubyは、jQuery のように、メソッドチェーンで書ける。
関数型。
加えて、オブジェクト指向 + Duck Typing で、JS のようにうっとおしい事もない
スコープが厳格だから、外側の変数を、内側へ通さない。
スコープを変える、メタプログラミング・DSL 用のメソッドが、区別されている
Sinatra をフルスクラッチで書くと、Web プログラミング・フレームワークの基本を学べる。
その後、無料のRails チュートリアルをやってもよい
Progate でも、途中まで無料でやれる Pythonは機械学習専用だな
webサーバーでpython使うメリットは、元々python使える人が楽に導入できるって程度のもの
それを知らずにpythonでwebは茨の道 >>180
これが典型的なruby使い
まず他言語を落としてから、rubyを持ち上げる
そりゃー嫌われれる そういえばRubyは言語自体よりコミュニティの
勘違い野郎たちの方に問題があるってきいたわ AWSでサポートされただけでtwitterのトレンド入りした化石言語のCOBOLこそが最強 今さら激遅ruby、さらにもっと遅くなるRails使うとかあり得ねえわ Ruby で、web プログラミングでも、HTML, CSS(SASS), JavaScript(JS) も使う。
JS は、jQuery, Vue.js, Node.js なども使うし、
JSは、Rubyに似せてくるから、Rubyをやって損はない
Windows でもファイル操作できるし、ツール作りにはよい。
PowerShell よりも使いやすい
Python は、AI・機械学習・数学統計・ラズパイとか。
普通のweb やると、爆死する
掌田津耶乃の本も、出たばっかり。
Python Django 超入門、2018
Node.js超入門、2017 windowsでrubyはねーよ
どれだけ知ったかなんだ >>180
> JavaScript(JS), Python, PHP などは、偽が10個ぐらいあるから、まともにプログラミングできない
今すぐ10個挙げてみろやホラッチョ糞Rubyキチガイ。
jsの関数相当がメソッド、Proc、lambda、ブロック、と4つもあり、
すべて変換が必要で、
それぞれ細かな挙動が異なり、
関数がファーストクラスオブジェクトではないクソ言語が流行ってるから！Rubyでもできるもん！
と関数型を標榜するとはヘソが茶を沸かすわｗｗｗｗｗ rubyだけは使わない方が良いという分かりやすい流れ サーバーサイドもフロントも両方やるけど、フロントのが大変だが気は楽だぞ。
バックエンドほどクリティカルなもんが多くない。 AudioElementのaudio.volume=0.3とWeb Audio APIのgain.value=0.3とでは音量が後者の方が小さく聞こえます
同じ値を設定したときの音量を統一したいのですが、どのようにするべきでしょうか？ 結局、jQuery房のDOM要素は完全敗北したのん？ 音量調整とか地獄すぎるな
端末やブラウザで変わりまくるんじゃないか フルスクラッチでwebアプリケーションを開発することになりました。
選定した技術について、色々とご指摘いただけると嬉しいです。
■インフラ
・Google App Engine Standard Environment(以下GAE/SE)
https://cloud.google.com/appengine/docs/standard/?hl=ja
■言語
node.js
■フロントエンド
GAE/SEにService Aとしてデプロイ
nuxt.jsを使いSSRする
もちろんSPA、PWAに対応
■バックエンド
GAE/SEににService Bとしてデプロイ
Apollo Server (RESTではなくGraphQLを使う)
https://www.apollographql.com/docs/apollo-server/
■データベース
Cloud Datastore
https://cloud.google.com/datastore/?hl=ja >>200
開発日記公開してくれ
そこにコメントする jQuery君は仕様に詳しくないのだから、あまりいじめてやるな そうか？
jQueryはDOM要素限定だと必死に主張してるだけに見えるが >>134 「cookieはDOMじゃないんだから」
>>137 「DOM Level3以降の仕様からは消されたけどなw」
>>139 「じゃあjQueryはDOM"要素"操作ライブラリって言えば納得するんか？ 単なる言葉遊び、本質は変わらんよ」
どれ一つ正しくないわけだが もうさ、くだらないからそろそろやめてくれ
つまらん jQuery房はプライド高い上に、後付け理論で訂正を整える事に必死だから嫌いだわ gatsbyでこんなコード片があるんだが
{posts
.filter(post => post.node.frontmatter.title.length > 0)
.map(({ node: post }) => {
return (...
map(({node: post})の{node: post}ってどういう構文なんだ
{node: post}ってのはjsonみたいなオブジェクトか何か？ >>216
聞く時はもうちょい丁寧に聞いたほうがいいよ 「分割代入 オブジェクト」くらいで引っかかるんじゃね >>215
jQuery房からまともな反論が返ってくるわけないんだから、その辺にしておきなよ
彼の完全敗北は皆わかってる
>>216
オブジェクト初期化子 >>219
自覚ないのか？ お前のこと言ってるんだよ 議論するなら技術的な内容を伴ったものにしろよ
ただ煽りあうマウントの取り合いは不毛 「cookieはDOMじゃない」はDOMの範疇なので間違い
「DOM Level3以降の仕様からCookieは削除されている]は意味不明
「DOM Level 2 HTML」があって「DOM Level 3 HTML」がないから削除されたと思い込んでるのかね
https://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-BBACDC08 ｊから
"The interfaces within this section are considered fundamental, and must be fully implemented by all conforming implementations of the DOM, including all HTML DOM implementations [DOM Level 2 HTML], unless otherwise specified."
を100回読め
「jQueryはDOM"要素"操作ライブラリ」をオレオレ理論すぎる
>>174で反論済
「本質は変わらん」て、DOMとDOM要素は本質的に違うだろうが
「documentはDOMじゃない＝documentはDOM要素じゃない」が通用するわけがない >>222
使ったこと無いけど、多分導入に結構時間がかかるのは分かる
学習コスト高い割に、そこまで機能が良いわけでもなく、独自要素が多すぎて潰しも効かないので使っていない >>222
nuxt.js(vuex)つかえばいいじゃん
なんかreact界隈って今となっては大昔のライブラリ戦争、jQueryに駆逐されたPrototype.js臭がするんだよね
簡単に記述できることを難しくしちゃってる所が特に・・・ >>213
ES2015(ES6)から入った分割代入という構文。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment
関数定義の引数の部分が{node: post}だと、実引数として渡ってきたオブジェクトのnodeというプロパティを、postという変数に代入して(束縛と言わないと怒る人もいそうだが)、関数定義の本文でpostという名前でアクセスできる（使える）ようになる。
つまり、
.map(({ node: post }) => {
return (...
は、
.map((post) => {
post = post.node;
return (...
と、等価。
引数を直接書き換えるのはお行儀が悪いと言われてる（V8の中の人によるとパフォーマンスも若干悪くなるらしい）ので、
.map((_post) => {
let post = _post.node;
return (...
とかでもいいよ。 >>224
一週間学習してるんだけどさ、7割くらい理解できたんだが、さあアプリ作るぞってなったときどこから作ればいいのか不明
こんなライブラリ初めてだわ
ネットみたらreact始めてすげー！redux導入して挫折ってブログが多い
>>227
もうプロジェクトでreact使うこと決まったんだよね
有名なログイン処理のreactとreduxサンプル
http://jasonwatmore.com/post/2017/09/16/react-redux-user-registration-and-login-tutorial-example
フロントでログイン処理するだけで約20ファイルもある
これとバックエンド繋ぐんだがマジで二重管理になるよな >>229
嫌すぎる…
ログインログアウトだけページ遷移許してもらえばreactの外で旧来スキームで出来ないの？ >>229
やっぱそうだよね。印象だけでもとっつきにくい。どういう場面で使えばいいのかよく分からなかった
プロジェクトに向いてるかどうかで考えた方が良いのかも知れない
ってプロジェクトで使う事が決まったのか、頑張って〜＼(^o^)／ >>230
それね
ログインページだけバックエンドのビューで生成してログイン後がreactってのもアリだとは思う
それだとcontrollerとviewのたったの2ファイルでできるしね
>>231
大手でもよくわからず使ってるプロジェクトもあるらしい
ほんとバグの温床になるよなぁ >>233
似たような調査Node学園祭でもやってたな Reactは使ったことないけど、Vueはかゆいとこに手が届かない感じがする
コンポーネントの親子関係とか、v-ifで子画面開くのにそれ用のフラグが必要だったり >>196
音量0と最大はどのブラウザ同じでも係数まではHTML5の仕様として決められておらずバラバラの可能性がある？
一度dBに変換するといったことも考えたのですが難しそうですね >>200
Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発、
花谷 拓磨、2018/10/17
この本によると、Heroku, AWS Lambda に当てはまらない場合は、GAE Standard がお勧め。
ただし、SMTP, WebSocket などは制限されている
それらを使う場合は、GAE Flexible になるため、
インスタンス課金 + サーバーを所持する形へ変わるため、Nuxt.js には適さない
Vue.js 日本語公式 Slack がある
下の本もよい。
基礎から学ぶ Vue.js、mio、2018/5/29 >>237
ありがとう、参考にします。
WebSocketは使わずGraphQLでJSON吐き出せれば十分なのでGAE/SEで良さそうですね。 >>236
探してみたけど、webで音声の扱いはロクな資料が無かったわ 質問
for ( let A of B ) {
...
}
というコードを書いた時、「B」はループの中で毎回評価（計算）される（＝重い処理を書かないほうがいい）んでしょうか？
それとも最初の1回だけですか？ >>240
その処理の中にconsole.logを仕込んで確かめると良い
良く使うデバッグ手法 >>241
言いたいことは分かるんですけど
世界で自分しか検証し得ない最先端のテーマならともかく
このありふれた疑問に対して答えを知ってるならサクッと教えてほしいです
車輪の再発明は嫌です すでにあるものと同じものを作るのが車輪の再発明であって、言語仕様を調べるのをサボることを言うのではない。
都合よく解釈しないように。
答え書いとくとBの評価は最初の一回のみ。
for ofではBはiterableオブジェクトでなければならず、最初にiteratorが取り出され、以降ループ毎にそのiteratorのnextメソッドの戻り値のオブジェクトのvalueプロパティに入っている値がAに入ることになっている。
これがnextメソッドの戻り値のオブジェクトのdoneプロパティがtrueになるまで続く。
処理系の実装でどのように最適化されてるかは知らないが、仕様ではそうなっている。 >>244
ありがとうございます。これでスッキリ使えます。
ただ言語仕様は調べたんです。一定時間調べて答えに辿り着かなかったので聞きました。
さあやるぞー。 訳が難しいのあるよね
iterableとかconfigurableとかinvariantsとか、意味は分かるけど日本語にすると PHPは初心者お断りってあるから聞き辛いけど、javascriptスレは初心者にも優しいのでありがたい trelloのチケットを横に動かすみたいな動きのものはvue.jsとか使えばいいの？
フレームワークを何から始めようか迷ってます >>239
ありがとう
適当に近い音量になるように計算させてみようと思います。 >>250
そもそも何故同じにしたいのか
全部WebAudioAPIで処理すればいいじゃない Bがジェネレーターとして重い処理を書かないほうがいいのかと聞いてるのなら
毎回評価されるという解になるな いやジェネレータからイテレータ取り出してんのは最初だけだろ。
前回のyieldから次のyieldまでの処理は当然毎回走るが、それは当たり前じゃん。毎回走ってほしい部分が走ってほしくないってどんな状況よ for (let i of [1, 2, 3]) {console.log(i)}
の結果が1 2 3になるか1 1 1になるかを自分で確かめることすら車輪の再発明（）とか言ってやりたがらないとかクズ過ぎる。
質問回答のコミュニケーションコストの方がよっぽど高くつくと思うのだが。 確かめるなら
for(let i of hoge()){
}
function hoge(){
console.log('hoge')
return [1, 2, 3]
}
じゃない？ >>255
うむ。>>254は罵っといて自分が理解してないという最高級のダサさ。 >>253
当たり前とも言えるがそこは隠蔽されてもいるんだからさ どうでもいいけど何でforでlet使ってるの？
constにしないの？
for (const i of arr) {
} 質問者がlet使ってるからでしょ
エラーでもないのに関係ないとこ変えると回答の本質がぼやける むしろなんでここでconst置けるような仕様にしたのか委員会を問い詰めたい。
ループ毎に値が変わる変数をconst宣言できるとかｗ
for-ofの()内はconst禁止でよかった。var/letなら直感に反しない。
トップレベルでは…
const A = 1;
A = 2; // エラー
なのにfor-ofでは…
for (const A of [1, 2]) {
console.log(A);
}
1
2 // for-ofちゃんナニ勝手にconst改変してくれちゃってんの？？自分のスコープだからってやりたい放題か！？こんな無法が許されていいのか！！ え？マジで言ってる？
for-of のlet/constはループ毎に毎回宣言してるのと同じじゃん
constによる最適化も期待できるんじゃないの >>263
const以前に、ブロックスコープの挙動は理解してないような
for (let i = 0; i < 4; i++)
document.addEventListener('click', e => console.log(i), false); >>264
毎回宣言ってどういう事？
一回だけじゃないの？
constで宣言すれば最適化で早いのは分かる >>267
宣言は1回だが、ブロックスコープはループ毎に発生してる
>>266の挙動を確認すれば分かる 違う。ブロックスコープが毎回発生するのは当たり前でそれだけでは説明できない。
それとは別に初期化句の変数宣言は特別扱いされる。 いやうまいことなってんだろうけどさ、
せいぜい>>264みたいな理解になるわけよパッと見。
const A = 1
const A = 2 // エラー
なのにfor ofのカッコの中に書くのはなんで許されるのって。
for (const A of [1, 2]) {
console.log(A);
}
が
{
const iter = [1, 2][Symbol.iterator]()
while (true) {
const {value: A, done} = iter.next()
if (done) break;
console.log(A)
}
}
のような動作になるだなんてfor of構文の見てくれからは推測不可能だろ。
for (const A of [1, 2])の字面だけ見たらループごとにAに1、2と代入されるように見える。
というか明らかにそう見えるような構文にしてる。
そう見えるようにしたいんだったらその場所ではconst禁止にしとけって話。 俺も似たようなことを思ったことがある
for(const i = 0; i < a.length; i++)
はエラーになるんだよな。 初学者が横から疑問が湧いたのですが
逆にどうしてfor-ofではlet Aじゃなくてconst Aを使うべきだと言えるのか、良く分からないです
だってループ自体の目的がAを改変することだったらletかvarにするしかないですよね？
それともfor-ofではAに渡されるのはBの一部の実体ではなくコピーなんですか？
（Aを書き換えてもBには反映されない）
だとしたらとんでもなく用途が限られるように思うのですが。 ×Aを改変
○Aを加工
と言ったほうが適切でしたかね .valueでinputのテキストボックス内に代入するとsubmitボタン押しても無反応になります
手動でキーボードから代入すると問題ないのですが何が原因なのでしょうか 強いて言うと、エラーは無反応です
コンソール開いてconsoleとnetworkみてもウンともすんともです 自己解決です>>276
エラーをあらためて探っていると
コンソールの各エラー項目の表示非表示チェックボックスが乱れていました
で、全部表示するようにしたら
TypeError: X[g].exec is not a function
というエラーが出てきました
どうやらObject.prototypeをいじっていのがいけなかったようです
関数にしたらsubmitも反応してくれるようになりました >>272
そりゃ i++ で変更してるし
同じくforと名乗ってても〜.forEach()に似た物と素直に考えられるかどうかかなぁ
>>273
jsでの代入や関数呼び出しと同じでAに入るものがプリミティブ型であればコピー、オブジェクト型であれば参照なので
for...of/for...inでletを使ったとしても変数Aに何かを代入してもBに反映されない
Aがオブジェクトならconstでもプロパティは変更できて参照元のオブジェクトにも反映される
perlやphpのような書き戻し可能なforeachの方がバグの温床になるような気がするけどね >>271
それいいな。
const forOf = (iterable, callback) => {
const iter = iterable[Symbol.iterator]()
for (let {value, done} = iter.next(); !done; {value, done} = iter.next()) callback(value)
}
Array.prototype.forEachと同じ感じで使える
forOf([1, 2], A => {
console.log(A)
})
1
2
forOf('ab', A => {
console.log(A)
})
"a"
"b"
ループの一時変数にletだconstだのムダな議論なくなるし。
まあ[...iterable].forEachでいいか… そもそもScalaみたくfor...ofならvarもletもconstも不要で自動的にconst扱いにすれば良かったんよ
将来的にそうなってほしい >>271
めっちゃ正論ティー
constの方がほんの少しパフォーマンス上がるとは言えほんの少しだし、
マイニングでもやらない限りconstで書く方がデメリットデカイ気がする >>271
ただ単に多くの言語の挙動に合わせただけ
その方がいろいろと都合がいいでしょ？ >>281
これで十分なものをなぜわざわざfor(const/let/var item of iterable)とか言うクソ構文を作ったのか
for(const item of iterable)と書かれて仕様知らないやつが初見でitemがループ毎に違う値入ってるとは夢にも思わないだろ。 お前らが何を言ってんのか理解できん
for-ofでのletとconstはまったく違うし、どっちも必要 console.logってbashでいうechoみたいにコードが読み込み・実行される際にしか出ないもんだと思ってたけど、あとから更新されたりするの？ >>286
お前こそなに言ってんだ。for ofでletは不要。
let B = [1, 2]
for (const A of B) {
A = 6
console.log(A);
}
//=> エラー
let B = [1, 2]
for (let A of B) {
A = 6
console.log(A);
}
//=> 6 6
console.log(B)
//=> [1, 2] >>289
まあconstのほうがお行儀がいいしlet使うことはないかも
ところで君はまだfor-ofの構文についてわかってないようだね >>289
間違いを防止するって意味なら結構アリだね
A==6と間違えてのA=6とか 初心者でjs勉強終わった人がフロントのフレームワークで何からやった方がいいかの議論 jsのフレームワークって小回り効かないのがなぁ
jQuery辺りのライブラリで十分、というか生jsしっかり覚えたほうがつぶしが利いて良い jqueryやったことない頃
生jsだけはしっかり把握してたから、実装は出来ないものの人のコードは読めたわ
まぁ他の言語も同じだけどね >>294
最終的にnuxt.jsに行き着くのだから
最初からnuxt.jsやらせるべき 仮想DOM系はバックエンド理解してないとやっても意味ないだろ >>300
1.Xから2.Xでいろいろ変わりすぎ
ドキュメント少なすぎ
1.Xのドキュメント邪魔
人柱になりたくなければ避けた方が無難 >>301
仮想DOM系のフレームワーク(react,vue)は、バックエンドとフロントエンドを分離するための技術ですよね？
フロントエンド側から見るとブラックボックスのエンドポイントを叩けばJSONが返ってくるシンプルな実装になっている。
バックエンドがどんなDBを使ってるか、どんな言語で実装されているのか等、深く理解する必要は無い。 https://twitter.com/ydnjp/status/1066529802142674945
https://pbs.twimg.com/media/Ds1LXSaV4AEFCRW.jpg:large
今から学習するならReactかVueの二択だな
Angularは淘汰された、jQueryも未来はない
バックエンド(WebAPI)はGraphQLでガチ決まり
これに異論唱える人は自分の周りにはもういない
安心して学習できる水準まで来てる
Prismaも組み合わせると尚良し
https://www.prisma.io/
■GitHub Starランキング
【JavaScriptフレームワーク編】
https://github.com/search?o=desc&;q=javascript&s=stars&type=Repositories
3位 vuejs/vue ☆122K
4位 facebook/react ☆117K
【GraphQL編】
https://github.com/search?q=GraphQL&;type=Repositories
3位 graphql/graphql-js ☆12.3K
4位 prisma/prisma ☆11.6K
5位 facebook/graphql ☆10.4K
7位 apollographql/apollo-client ☆9.4K
学ぶべきものはここに集約されてる
https://twitter.com/5chan_nel (5ch newer account) >>306
jQueryだけ「もう使いたくない」「使わないつもり」の割合が高いな >>304
そんな公式ひとつで全部まかなえるはずないだろ >>308
基本、公式以外を信用しない俺とは対極的な考えだな… >>304
wordpressのしょぼいテンプレートみたい。左メニューのクリック領域が狭くてが操作し辛い
見た目は若干アレだけど、内容は普通と思う >>305
バックエンドが勝手にデータ変更したり構造変えたら終了
バックエンドでやってるバリデーションと違うバリデーションをやったら整合性保てなくて終了
バックエンドとフロントエンドの設計を同時にし、改修する場合も同時にやらないといけない
勝手にバックエンドだけ変えたらフロントで持っていたstateが合わなくなる フロントちょこっとやってからバックエンドがっちりやって、またフロントに戻りつつある
○○はどっち弄っても出来るけどってもんがあるとあとは負荷や処理速度の問題になってくるなと最近思う >>314
それ別にvueとかreactとか仮想DOMとか関係なくね？
ていうか勝手に変えるなそんなもん いまはフロントとバックエンドって分け隔てより、ロジックとビューで分かれる事が多い気がする
ロジック班は当然バックエンドの知識もないといかんな バリデーションをフロントとバックエンドの両方で対応するの二重管理じゃん
フロントがデータを保持しているかどうかはバックエンドはわからん
フロントで値を更新して保持して永続化もして、なのにバックエンドはそんなの知らんしDBに保存してないからって
DBとフロントで違う値になることもありえる vue.jsはnuxt.jsとセットで使うものだ
vue.jsのベストプラクティスを集めたフレームワークonフレームワークがnuxt.js
SSRやPWA対応も一瞬
$yarn create nuxt-app test
$cd test
$yarn dev
これだけで雛形完成
あとはpagesフォルダ以下のvue(単一コンポーネントファイル)を弄ってサイトを構築していくだけ
https://ja.nuxtjs.org/guide/directory-structure SPAじゃない古典的なMVCアプリケーションでも
バックエンドが勝手にDB構造変えたら
テンプレートエンジンに入り組んだロジックを変更しなきゃいけないので
reactやvueだけに該当する問題じゃないよね、それ >>320
バックエンドはフロントエンドも含めたフレームワーク
しかしreactとかはバックエンドは含まない
reactとか使う場合はバックエンドとフロントエンドの両方で値を持つ必要がある
古典的なフレームワークはフロントで値は持たない あとまともなWebAPI設計者だったらadd-only approachを選択するので
破壊的な構造更新はめったに起きない
フロントエンド(クライアント)はGraphQLでリクエストするだけ
もうRESTは使わない ＞フレームワークonフレームワーク
ぜったいいやあああああああああああああ なんか話が噛み合わないな
2010年より以前の知識で止まってる人と会話してるみたいになってる Yahoo、楽天、CA、DeNA、GREE、mixiのような大企業の社員さんですか？
中小企業に勤務する場末のweb制作屋には高度すぎて理解できない jQueryは何故駄目なの？
vue.jsにする理由は？GraphQLってなに？
そもそもRESTってなんだ？ >>323
そんな案件ばかりだよ？
>>324
おれのこと？
>>322
GraphQL使いたいんだがね
そこまで複雑でもない
しかしバックエンドとフロントでルーティング合わせないといかんのもねえ >>326
別に駄目なわけじゃないよ
力不足なだけで
vueとかreactとかとかは
MVCベースのSPAのフロントの核となる前提で作られたものなので
それらに類するものを構築する上では非常にマッチする
jQueryはあらゆる場面で手軽に使うのが前提の汎用関数群なので
いろんなプログラムの部分部分で使うにはとても便利だけど
じゃあjQだけでSPA作ろうってなると足りないものが多いし
jQベースでそれを補おうとすると、ちょっと煩雑になりすぎる SPAってSingle Page Applicationの略だよね？
別にアプリケーション作る必要ないんだけど？ HTMLが動的に生成されるならそれはWebアプリです >>328
成る程ですね
SPAにするのは何故？
サーバーが組み立て済みのHTML吐き出すほうが楽じゃない？
そのHTMLをjQueryでちょこちょこ弄ってアニメーションさせてリッチな演出するのが業界の最先端技術だ！と
頭禿げてる先輩(専門卒)に教わったんですけど、もう古い？ 時価総額数千〜数兆円の大企業に勤務する、東大京大卒の正社員さまの
「2018年のweb業界の技術トレンドはこれだ！」というものを教えていただきたいです。
ちなみに私も専門卒です。年収は250万円です。ハゲてはいません。 >>331
全然古くない。もともとHTMLはドキュメントを記述するために
作られたもので、現在ウェブサイトの殆どは動きがないもの
アプリケーションに相当するものなんて殆どないよ
ウェブで出来ることが増えてきて上がってきてスマホアプリのような
アプリケーションも作れるようになったから、どの会社もみんな
アプリケーションで自社サイトを作り直すはずだ。みたいに考えてるやつが
一部いるだけで、そんな事するサイトはまず無い
昔はjQuery Mobileといって、jQueryをベースとしてスマホアプリと
同じようなインターフェースが作れるフレームワークがあったんだが、
それ（jQueryではなくjQuery Mobileね）が失敗したのもの理由は同じ
いくらなにかすごいことが出来るようになったとしても、会社サイトとか
情報サイトとかブログとかHTMLをベースとしているサイトが
なんの需要もなくスマホアプリ風にする理由がない つまり小説書いている人が、高性能パソコンを手に入れたからって
3Dアニメを作り出すようになるわけがないってことですかね よく考えてみたら、うちの会社の規模ですら静的HTMLオンリーはないですね。
よくある会社紹介サイトでも最新のお知らせ情報をリスト形式で表示するところあるじゃないですか？
これを毎回静的HTMLで更新するのは馬鹿らしい、ということで高専卒の新人くんが
Railsとかゆー、ウェッブアプリケーションを作るアプリで作ってました。
僕はHTML専門なんで、何をしてるのか分からなかったですけど・・・ >>331
UI/UXの観点からするとアプリケーションには
画面展開が行われるべき状況と
シームレスに展開されたほうがわかりやすい状況とが、それぞれある
アプリケーション側の観点からすると
プログラムはモデルありきであって、ビューが変わるのはその結果
たとえば画面全体が切り替わるのも、モーダルひとつ開くのも、基本的には同じこと
なのでウェブページの仕組みに制限されたくない
ってのがSPAが良しとされるところじゃないかな、と思ってる jQuery Mobile使ってたわ
今でもたまーに見かけるね
https://www.1-s.jp/
結構便利なんだけどページ内アンカを使えないという致命的な仕様があった >>335
たんなる会社紹介ページをRailsで作るとか無意味だよｗ
Railsで作るようなものは、ユーザーがログインして使うようなもので
ユーザーの操作でページが変わるようなもの
別の言い方をすれば、Googleが検索してクロールできないものだよ >>338
ええっ！？無意味なんですか？
管理メニューから、お知らせ記事投稿するだけでトップページのリストが変化するのをみて
高専くんすげー！ってハゲの先輩が感動してましたけど・・・？ >>338
まあでもそんなもんじゃね？
ワッツニュー部分だけちょろっと書いてCMS化しよーって時とか
まあ慣れてる言語でサクッと書いちゃうでしょ そうだよ。HTMLがメインでJavaScriptはちょっと動きをつけるだけで十分な場合に、
HTML廃止して、JavaScriptから全部生成します。
JavaScriptがなければ表示されないし、HTML+CSSでサイト作っていた人は
今度からJavaScriptに埋め込む必要があります。
そしてプログラミングを学んでください
なんてのは、難しくしてるだけなんだよ >>340
無意味だよ。
それって普通にローカルでHTML生成しても出来ることだからね
HTMLすらわからない人にサイト更新させるために導入するならわかるが、
そういうのはブログで良い
自分でRails使ってアプリ作るとかサイトを重くして
脆弱性を埋め込む可能性があるRailsを使うことに意味はない そうなんすか
高専君いま隣りにいるんですけど
「こいつら適当なこといってますよ」ですって >>344
それがどうかしたの？
あんたがその高専くん出ない証拠もないし
ハゲはお前かもしれないだろ サイト更新とか自前でやるにしても、CMSかWordPress導入するのが関の山だろ
そのCMSやWordPressでvueやreactが使われていたとしても、
それは自分でJavaScript使って作るわけじゃないしね。
つまりvueやreactが必要とされるのは「開発者」ってこと
自分らでちょこちょこって使うならjQueryでいいよ ブログとかウェブアプリとか専門に作ってる会社以外は
jQueryで必要十分ってことかな WordPressが良い
あの手っ取り早さは凄い
weordpressの中にjQueryも入っている >>347
そうでもないかも
vueやreactの本丸ではない細かな部品も
後発だけあって洗練されたのが沢山あって
例えばちょっとしたフォーム置くだけ
なんて場合でも結構使えるよ >>349
HTMLで書かれたページがあります。
何が簡単に使えるんですか？ vueはプログレッシブフレームワークだから
サイトの規模に合わせられる いや、そうじゃなくて、どれだけ簡単に使えるのか知りたいだけです
https://jsfiddle.net/ に書いてくれませんか？
vueを使った必要最小限のコードを 訂正。必要最小限じゃわからないので
イベントハンドラとDOMの変更をそれぞれ最低一つは書いてください >>354
やっぱりそんなもんですよね
HTMLで書けばすむものがJavaScriptに移動し
コードの量も増えてしまう
JavaScriptなし版
https://jsfiddle.net/s59042zf/1/
jQuery版（vue版にあわせてspanとdelを入れ替える）
https://jsfiddle.net/s59042zf/2/ HTMLの量が劇的に増えて可読性も下がってるな
jQueryも酷い HTMLで書いたほうが可読性いいじゃん
なにより、HTMLとCSSだけでできるからプログラマと作業が分業できる。
それにリストの二番目だけに、画像を入れたいとかよくある話だけど
そういう場合でも簡単に対応できるし柔軟性が上がってる laravelかwordpressだったらどっちのがいいの？ >>360
> 47都道府県の選択フォームをHTMLに直書きしたら可読性最悪だろう？
> いままで疑問に思わなかったの？
JavaScriptに直書きしても同じことでは？
それにSSIでも使って別ファイルに外出しすればいいじゃん？ >>358
用途による
企業HPならどっちでも
>>360
都道府県ぐらいなら自前で用意する
APIは怖くて無理、いつ無くなるか不安過ぎる >>361
>JavaScriptに直書きしても同じことでは？
APIの意味分かってる？ なんでもHTMLとjQueryでやろうとする老害がいるようですね
淘汰されてください 実際に今まで淘汰されているのは
フレームワークを使っていた連中だというｗ APIは利用回数や利用制限調べるのがめんどくさくない？
全部無視して回数制限にひっかかっちゃいましたﾊﾊﾊで済むならそれでもいいけど >>363
お前こそわかってる？
jQueryで（他人が書いた）HTMLを読み込めば終わりでしょ？ｗ >>352
はろーわーるど！
http://jsfiddle.net/6rzb5asm/
極論すると何やるにしても最終的に結果を表示するために
要素にアクセスして→表示内容を差し込む、ってのはするわけで
その前提の有無がjQueryとの違いなんだろうなと
jQueryにその機能がないというわけではなく
その前提があるかどうかっつー話ね Reactでサイト作成する場合に最低限必要なライブラリ
webpack
node.js
npm
react
react-dom
react-router-dom
redux
react-redux
connected-react-router
redux-logger
redux-thunk
prop-types
axios
babel-loader
babel-core
babel-preset-env
babel-preset-react
style-loader
css-loader
redux-devtools-extention >>370
これ全部使いこなして作成するんだぞ
当たり前だがこの他にもいろいろある
あとどうやってビルドするか自分でconfig作る >>335
の新着情報作る話が壮大になっててワロタ
リストにしてajaxで取得するぐらいでいいんじゃないの
使うのはjqueryだけだ >>370
民主党みたいなやつだなｗ
快適な環境のために家も必要だからゲームを始めるには一億円かかる！といった戯れ言の一種。
本当に最低限必要なものは、
babel-standalone
react
react-dom
終わり。
しかも上１つはreactのためと言うよりJSXで書くために必要なもの、
下２つは元々１つだったのが分かれただけ。 >>373
いや普通に必要でしょ
reduxなかったらバケツリレーさせるの？
自分でも把握できなくなるぞ？ >>374
jQueryでサイト作るとき、クリティカルな日付計算多発する案件の場合momentjsやdate-fns使う？使わない？ >>370
楽をするためにはどんな苦労も厭わないのがプログラマという人種なんですよ！ 選択は要件次第だし要件は客次第であって
普通のウェブとやらを勝手に決められるのは戴けない 久しぶりにpackage.json見直したら
devDependenciesが40行あったｗｗｗ いつだって私のやり方で
レッツエンジョイ！ジャスドゥーイット！ jQuery で済むなら、それが一番。
次いで、Rails
上よりも複雑なものは、React, Vue.js, Nuxt.js
Rails から、jQuery, Vue も使える jQuery信者の老害は何？
DOMセレクト？querySelector使えよ
Ajax?window.fetchかaxios使えよ
今更わざわざjQuery使う理由が分からん >>382
大抵のライブラリはjQueryが必要だからとりあえず入れておく必要がある
後は書くのが楽 >>383
ただのjQuery plugin大好きっ子だった >>382
jQueryを使うと、コードが短くなりバグが減るからだよ jQueryを、じゃなくて適切なライブラリを組み合わせて使うと、だろ DOMを操作する適切なライブラリって他にある？
jQueryの劣化版？ 便利なライブラリーでdomをこねくり回そうっていう考え方が間違っているんじゃないのか
オブジェクト指向的に考えると、コンポーネント化して十分に抽象化し、求められている専門で十分なメソッドを持たせておくべきじゃないのか >>389
最近、よくコンポーネントと聞くけど、Web Componentsのこと？
Vue.jsやReaact.jsにあるコンポーネント？ ReactもjQueryもやるけどjQuery便利
便利は正義
jQueryもう使いたくないってよく聞くが、何か問題起きてどうにもならなかった悲惨な経験があるんだろう
たかがjQueryごときで笑 >>389
> オブジェクト指向的に考えると、コンポーネント化して十分に抽象化し、求められている専門で十分なメソッドを持たせておくべきじゃないのか
そういう機能がDOMに存在しない
コンボボックス（セレクトボックス＋テキストエディア）すら
作る機能がDOMには存在しない
ブラウザネイティブ（ライブラリを一切使用しない）で
WebComponentができれば、その問題は解決するが
コンポーネント同士をどうやって連携するか？という問題は残ったまま あるサイトを改修する仕事受けて改修したんだけど、バッテリー消費が大きいと客に言われたんだが、
普通にchromeでjsの処理レポートを確認するしかないかな？ phpもフレームワークも使ったことなくてlaravelやらされて訳分かんなくなってフロントに逃げました フロントは言いました
あらゆるフレームワークの目指すところは
死である。 >>392
コンボボックスやらはWebComponentで可能だし
コンポーネント同士をどうやって連携するか？って？
その答え先に言ったじゃん
コンポーネント自体に十分なメソッドを生やせって >>397
スマホ用サイトで白ベースなんだけど、それ関係あるかも！
しかしスマホの液晶タイプによって白か黒かで違う？ >>399
と思って調べたら白黒でほとんど関係ないっぽい >>398
メソッドをはやした所で連携はできないよ まつたけってw
せめてちんこより大きいもので例えなきゃ意味ないじゃん >>400
関係ある
最近の液晶ディスプレイはバックライト部分OFFにできるし
有機ELやマイクロLEDなら黒は明らかに省エネ >>393
数十あるファイルの読み込み・コンパイルを並列に行うから、CPU 使用率も高い。
PC のエコモードで、1つのCPUだけにすれば、CPU使用率は低い
客は電力について、何にも知らないだろ
速さを競っているブラウザは、電力を食う 遅いほうが電力食うよ
遅いと処理の完了まで時間かかるだけで処理に費やす電力は大差ない
それとは別にバックライトとかの一定の電力が時間がかかればかかるほど食う
単純な話、１００秒で終わる処理を１０００００秒掛けてたらどんだけその処理に費やす電力が小さくてもバッテリー切れする >>407
ウェブアプリケーション的なの作るにはわりと重要なファクターなんだよ >>408
代わりに言ってくれてありがとう
そのとおりです 「消費電力を減らすにはどうしたらいいんだ」
「画面を暗くしましょう」
「暗く？そうしたらせっかくのかっこいいMacがダサくなるではないか」
「いいえ、かっこいいんです」
「？」
「いいですか、暗いというのはかっこいいんです」
「だが・・
「かっこいいんです。」
「わ、わかった。そういうことにしよう」
「わかればいいんです。名前をダークモードにしましょう」
「なんだその、中二病まんさ・・
「かっこいいんです。」
こうして消費電力を減らすという目的のために
ダサいデザインが出来ました とりあえずアニメーションを多用するなってのと画像は圧縮しろとしか言えない 全然重要じゃない。
最近はモバイル製品のバッテリーの持ちもよくなってるし充電スペースも増えてる。 https://developer.mozilla.org/ja/docs/Web/API/Window/postMessage
otherWindow.postMessage(message, targetOrigin);
で、
otherWindow.postMessage(message, '*');
だと全部のサイトに送信されるんですよね？
では、httpsのサイトのみに送信したいので、
otherWindow.postMessage(message, 'https://*');
みたいなのは出来ますか？ そこに指定するのは「オリジン」だからそういうことはできない
あとそれは古い書き方で今はオブジェクトで
{targetOrigin: '~' }と渡すほうが良い こんな下らないレスでスレ消費とか
お前らホント
暇人だな >>393
他には、60/秒など、フレームレートが高いと、電力を食う フレームレートが低いとUX を損なうでしょ
今の時代にまだ人間を犠牲にして機械を尊重してるとかナンセンス 日本製のカーナビってフレームレート低いよなぁ
何で5fpsしか出てないの？カックカクやん
あと液晶テレビの番組表とかも同様
トルネのヌルヌルサクサクUI/UXを見習え
いまならARMのSoC搭載すりゃ同等の表現できるだろうに・・・
フレームレートは60fps必須だよね
スマホでたまにカクカクしてるアプリみかけるけど速攻削除してるわ
UX意識してないサイトやアプリは使う気になれない webview使った側アプリだとモッサモサになる
React NativeやVue Nativeなどのネイティブアプリとして出力できるフレームワーク使うと改善される。
https://gamebiz.jp/?p=185520
＞当初スマートフォン版はCSSやJavaScriptを駆使したHTML5で開発したのですが、端末のスペックによっては、
＞魚がカクカク動いたり瞬間移動したように見えたり表現に限界がありました。
＞現在でも使っているCocos2d-js使ってネイティブアプリ化してレンダリングすることで、Androidユーザーにスムーズに魚が動くと言ってもらえるようになりました。 CSSやJSを駆使とか言ってるから限界に達したんだろ
昔はCSSやJSじゃ遅いからSVGアニメをどう駆使するかが最も重要なテクだったよ 質問です
xpathで「あるノードの次のノード」（１つ次のやつだけ）を指定する方法ってないんでしょうか。
例えば //td[@class="hoge"] で特定できるノードがあるとしてその右隣のtdを取得したいです。
//td[@class="hoge"]/next-sibling::td みたいに書ければいいと思うんですが。 //td[@class="hoge"]/following-sibling::td[1] react
anguler
vue
ってデザイナーが習得するの無理すぎない？ >>430はthが挟まると条件満たさないから厳密にやるならこうか
//td[@class="hoge"]/following-sibling::*[position()=1 and self::td] >>431
俺はずーっとそれを言ってるよ。
だからjQueryの代替にはならない あーすまん俺が勘違いしてた
JS/ESとMVCモデルを理解してないで使うのは難しいかもしれん 単一コンポーネントの.vueのほうがデザイナに優しいじゃん vueは生JSでも行けるから
jQueryを扱えるようなデザイナーならギリギリ行ける
Reactはトランスパイル前提みたいな部分があるから環境構築で詰む 例えば、はてなブログとかしている層が
ブログのデザインjsでちょこっと弄ろうとするのにReactは全く向いてない。
vueならギリギリセーフ。 ReactのJSXがキモすぎる
HTMLのタグにCSS埋め込むような気持ち悪さ
分離してくれよ
可読性さがるじゃん はぁReactでcss調整やってるんだけどさ、npmのビルドが5分かかるようになってきた
まだ1ページ目なのに
cssやるだけでビルドするの超作業効率悪い ReactでApp.jsにconst style =でcss書いてるんだけどさ、このstyleを子コンポーネントに渡すのって
いちいち子コンポーネントにパラメータ作って渡さないといけないの？
凄い苦痛… だから殆どがHTML+CSSだけで構成されてる
よくあるウェブサイトをReactで作るとか無意味だって言ったろ？
Reactなんかは普段JavaScriptとDOMだけで作ってる
大規模なウェブアプリなんかを効率よく作るためのフレームワーク
JavaScriptをjQueryを使って少ししか使ってない所に
導入するのは破綻しかもたらさない reactやめてvue.js使いなよ
vueのベストプラクティス集めたnuxt.jsオススメ
コンポーネント形式でファイルが分割されてるから
HTML+CSSで作業するより効率的になってる
webデザイナはpageフォルダ以下のfoo.vueをいじるだけ >>444
大規模じゃないし一人でやらされてる
>>445
vueは拒否されたw > コンポーネント形式でファイルが分割されてるから
HTML+CSSで作ってる人にとっては
そのコンポーネントの殆どが使わないものだろうさ vueは中国だしどんなによくてもファーウェイみたいになるかも Reactから依存外せるものは外したいなぁ
cssをjsxで作らないでscssにしてそっちだけビルドすればいいかな？ てかreactにしろtsにしろscssにしろ
変換しないといけないのがだるいよ
それ一発でできるのが理想じゃない？ 理想の話をするならHTTPに変わるステートフルなプロトコルに普及していただきたい Reactでビルドかけたら依存しあってるモジュールが350もあるらしい
フロント作るのにここまでやらんといけないのか
複雑すぎだろ javascriptの動的な読み込みって何かメリットありますか？ >>454
読み込みたくないときに読み込まなくて済む domのアニメーションずっとjQueryつかってるんだけど
少しモダンな方法にも挑戦したい
electronアプリの開発で練習したいんだけど
おすすめだよってフレームワークやライブラリある？ vueは最初の描画が遅すぎるのが厳しい
Reactより高速が売りだった再描画もReact16になって抜かれたから
パフォーマンス面では完全に置いていかれた感があるね
Reactよりも高速なままだったのならvue一択なんだけど
コミュニティ主導が為に
React15→React16みたいに
ゼロからコードを書いてやり直すとか無理だろうし多分詰んでる >>456
DOMでそんなにアニメーションするもんじゃないと思うよ
Canvas使ったほうが良い CanvasでCSSアニメーションの
再発明（笑） >>457
SSRすればいいじゃん
今はGAE/Node.jsあるよ？ 初歩的な質問でごめん
素のjsの勉強はしたところなんだけど、ページ上で面白いアニメーションみたいなの作りたい
ああいうのはフレームワーク使えばいいの？
XAMPPとMAMPは使える >>460
結局はvue.jsはフロントでは使い勝手がイマイチという結論にはなるわな >>463
Adobe Animate CCでhtml5とjs、WebGL、Scalable Vector Graphicsでアニメーション >>462
おもしろいアニメーションはツールあんまり関係ない
ありがちなアニメーションを手軽にやりたいなら
CSSフレームワーク使えばいいと思うよ >>451
ほんと、これだけ解決出来れば何にでも使うのに。
結局普通のサイトではjqueryの方が早く終わる。 結局、Reactなどの仮想DOMってさブラウザとネットワークが重いからわざわざめんどくさいことしてるわけだよな
通常のサイト作るより30倍くらい労力が必要
なぜならフレームワークや付随するライブラリの思想と仕様を把握しないといけないから
そしていちいちGithubのissueを確認してバグがあったら回避策を自分で実装しないといけない
その労力がハンパないわけ
つまりブラウザもネットワークも速ければjQueryでいいんだよ >>469
＞つまりブラウザもネットワークも速ければjQueryでいいんだよ
そやで
争いのない平和な世界や・・・
天国や・・・存在しないけどね・・・ えええええ
思いのはネットワークじゃなくてDOMなんじゃない？ >>471
ブラウザが速いってことはDOM構築も速くなる >>472
いやそうではなく
ネットワークとかハードウェアの速さの話ではなく
Reactなどが仮想DOMを使ってごにょごにょするのは
それこそjQueryみたいにいちいちDOMイジってるとリフローが遅いから
仮想環境でそれを済ませて、最後に1回だけポコッと差分だけDOMに投入する
って形をとってるわけじゃん？
jQueryでやるにしても、DOMいじりが遅いのはわかってるから
できるだけ文字列でやって、最後に$.html()でボコンと突っ込みましょう
ってのが推奨されてるわけで それだけスピードは大切って事よ
facebookはその辺が肝だと分かっているからか
React16は高速化され過ぎてビビる 速さを求める人の欲に上限はないからな
どれだけ速度が上がろうと「じゃあこっちで作ったらもっともっと速いんじゃね？」
のいたちごっこ 一つのことだけやりゃあ良いわけでもないんで
シングルスレッドのJSでは
一つの処理がササッと終わってくれるってのはわりと大事なわけよ みんな常にパフォーマンス意識してやってるの？
俺は、普通に書いてて重いと感じたら直す感じだけど >>477
さすがに明らかに無駄な処理や計算量が多い処理は気にするけど、それ以外は可読性とか参照透過性優先 >>477
どうせ書き直す可能性があるなら、最初からパフォーマンス考えて書いたほうが精神的に楽と気付いた
でも優先順位は>>478と同じく保守性がメイン >>473
> Reactなどが仮想DOMを使ってごにょごにょするのは
> それこそjQueryみたいにいちいちDOMイジってるとリフローが遅いから
jQueryとReactではReactの方が遅いって知ってる？ 質問です
要素を右クリックした時のメニューに好きなものを追加する機能（menuitem,contextmenu等）が廃止の方向だそうですが
代わりになるものは何かあるのでしょうか？ >>483
ありがとうございます
なんでこんな有用なものを削除していこうとするんでしょう
ブラウザアドオンもどんどん弱体化してますが 世の中にはいろんなデバイスとブラウザがある
右クリックで縦に並んだ追加しやすいメニューが出るなんて限らない
Webとは関係のないブラウザの問題 >>484
開発系を除けば、PCよりスマホでサイトを閲覧する人の方がはるかに多いから
全体で見ればもう不要という方向なのだ >>480
それはReact15までの話だぞ
16になって書き直してからはパフォーマンスが劇的に上がってる >>486
例えばgoogleスプレッドシートとかの右クリックメニューどうすんだろ？
PCでも使えなくなるんだよね？ >>488
htmlの仕様から消えるだけ
消える理由は、誰も使ってないから
jsの
addEventListener('contextmenu', 〜
は残るよ。
スプレッドシートも見てみたけど、menuitem,contextmenuは使ってない。
html5で追加された要素が瞬殺したってだけだな >>473
> jQueryでやるにしても、DOMいじりが遅いのはわかってるから
> できるだけ文字列でやって、最後に$.html()でボコンと突っ込みましょう
> ってのが推奨されてるわけで
そうだったのか知らんかった
いつも$("<div>").appendTo("#hoge").addClass("moge")
みたいなことやってた >>485-486
ありがとうございます
スマホでは使わないのは分かりますけどPCでは有用なわけで
軽自動車に付けられない装備は４ｔトラックやベンツや消防車からも外そう（その方がスッキリ統一できるから）
と言ってるような決定に思えます
最近はそんなのばっかりですよね
不満です >>493
いや、無くなった理由は誰も使ってないから
便利と思ってる人は少数派なのは間違いない
俺も右クリックメニューを導入するなら間違いなくjsの方で実装する
うまくやればスマホとPCで挙動合わせられるからな >>494
そうですね、ただ私はのちのちjsの方からすら削除しようって言い出しゃしないかと不安なのです
ともあれありがとうございました JSfiddleとかCodePenみたいなサイトでデバッガ付きのサイトってねーの？ example.comでF12とかcmd+opt+iすればよくね example.comいいよね
しょっちゅうF12から編集して色々試してるわ
JSfiddleなんかより全然使いやすい。差異も無い ブラウザデフォのコンテキストメニューに独自項目追加するのはユーザースクリプト作ってると便利だと思うこともあるけど
Webページ側でやられると元からあるのか自前なのか区別つきにくい場合もあるからねぇ
contextmenuイベント捕まえてpreventDefaultして自分で描画しろというのが今の流れ つまりコンテキストメニューをこっそり広告にしておいて
「コピー」をクリックしたつもりが広告クリックに… 面白いな
でも一瞬でアカウント停止食らうぞ
20年前なら通用したかもしれない >>501
もうちょっと後でも大丈夫だったよ
ソースはMTにアマゾン・アソシエイト貼るのが流行った頃にやってた俺 >>493
誰も使いたがらないものを実装する意味がないし
誰も実装したがらないものを仕様に入れておく意味がないだろう
不満と言うけどこのままWebが肥大化していくと不安だよ
ようやく長年の努力が実って今年くらいから機能をどんどん削除していけてるんだからさ
それは非常に喜ばしいことだよ Reactの最近の機能盛り盛りっぷりを見ると
肥大化する場所が変わっただけだなという感想 ウェブというかブラウザを
ただのドキュメントビューアと思っている人にとっては肥大化かもしれんが
アプリケーションプラットフォームと捉えている我々にとっては
まだまだ痩せすぎ こういう奴は何時になったらEWebとLAPIを理解するんだろうな バックエンドエンジニアはAPIでデータを出して、受け取るだけの簡単なお仕事になった
これからはバリデーションもフロントエンドエンジニアのお仕事
バックエンドでは都合の悪いデータが来たらエラー吐いて終了
データを送信したら後はフロントエンドエンジニアが如何様にも使ってくれ、責任は取らんってこと 生のVue.jsで書いていた50行程度の処理を
JSXのReactで書き直したら100行になったぜ！！
ただパフォーマンスは目に見えて改善したので満足 主にスポーツ用品などの研究や開発を手がけるクロステクノロジーラボ（福島県会津若松市）などは２７日、
外部からの電気を利用せずに水を水素と酸素に分解する特殊な炭素素材を開発したと発表した。
この素材は貴金属を使わず、少量の炭素と負極になるアルミなどを用い、製造費用も抑えられるとしている。
同社は、スポーツ用品販売大手ゼビオホールディングスのグループ企業にあたる。 >>508
50行→100行は
DX(開発者体験)悪すぎだな
そもそもwebアプリケーションのボトルネックって大半がバックエンドかつDBアクセスにあるから
フロントエンドでパフォーマンスが目に見えて改善するというのが信じられない
vue.jsでSSR使わず
reactでSSR使ってるとか
そういう比較してそう >>511
外部apiを叩いて取得したJSONを元に
23×300のテーブルを作って
数秒毎に更新をする処理だから結構負荷が大きいかと。
どちらかというとパフォーマンスが落ちても50行で実現するVueを褒めるべきかもしれない。
SSRはReactもVueもどっちも遅かったから普通にテンプレートエンジンを使った方が良さそう
そもそもFacebookがReactをSSRでは使ってないし バックエンド何使ってんの？
SSRはサーバレスアーキテクチャ(FaaS)だと糞遅いぞ >>512
想像するとすごい表だなｗ
topの結果がパカパカ更新されてるような絵が浮かんだ 仮想通貨取引所くらいじゃないとそんな高頻度かつ高密度の情報必要としないような気がするな
海外の取引所はGraphQL使って一度に欲しい情報を全部取得するようにしてた
従来のRESTだと向かない SSRするならAWS LambdaではなくGAE/SE Node.jsが適任 DOM apiで要素を取得するとmapとかforEachとかが使えないのですが
そういう変換するようなのは用意されているのでしょうか？
document.getElementsByTagName('div').map()
みたいにして使いたいのです >>518
使えなかったっけ？
まあそれで返ってくるのはコレクションだから配列に変換してあげればいいよ 変換するかArray.prototype.mapをcallしてもいいよ >>518
使えるブラウザと使えないブラウザがある
新しく追加された仕様だから、まだ対応してない
ブラウザがあるということ
そういったブラウザ間の互換性を吸収するためにjQueryがある >>519-520
chromeとff試しましたがnot a functionでした
なるほどcallしてみます
>>521
ブラウザの拡張にするほどでもない感じの簡易ブックマークレット用途なので
仕方なくDOMapiを使ったのです
使いたいサイト先がjQuery使ってればよかったのですが。 そういや昔ブックマークレットで改行ができないのが嫌で、
ブックマークレット自体はscriptタグを書き出すだけにして
特定のURLのスクリプトを読み込むようにしたなぁ >>518
[...document.getElementsByTagName('div')].map() >>518
NodeListはArrayライクオブジェクトであってArrayではないので、Array.fromで変換しましょう ただしArray.fromが全てのブラウザで動くとは限りません 新構文使った[...]とは違って単なる関数だからポリフィルあるし。 ということで、ブックマークレットにポリフィル埋め込みましょう！ NodeListはmapはないけどforEachもってるよ getElementsByTagNameが返すのはHTMLCollection
DOMは歴史的理由から、直感に反するような仕様が多いので
それを無くすためのjQueryでもある 秘技・プロトタイプ拡張でmapを生やすという手もあるぞ ただしDOMオブジェクトをプロトタイプ拡張
できるかどうかはブラウザ依存である >>531
ほんとだ、getElementsByTagName が返すのは NodeList じゃないんだな…
簡単に回したいなら document.querySelectorAll(‘div’).forEach でいいんじゃね >>534に書いてあるように、
実装を変える前のブラウザでは動かない >>535
querySelectorAllが実装されていたとしても
forEachが使えるかどうかはブラウザ依存 >>518
返すのが配列じゃなくてコレクションなんて気づけないよね最近は
色々便利になってきたし
jQuery以前に俺俺ライブラリ書いてたおっさんたちは
同じようにハマったからよく知ってっけど w3mやlynxではcallもダメだろ。つまりブラウザ依存。 逆に最近のほうが気付き易いだろ。
なぜならconsoleで実行するとコンストラクタ名が表示される親切機能ついてるし最近 Ruby のNokogiri は使いやすいけど、単数・複数形が異なる
一方、jQuery では、0・1・複数形のすべてが配列だから、シームレスに書ける >>542
死ね不人気クソ言語キチガイ苦しんで死ね > 返すのが配列じゃなくてコレクションなんて気づけないよね最近は
もともとJavaScriptはブラウザが実装しているDOM（C/C++で実装）
しているものを、呼び出して使える簡易な言語だったからな。
C/C++で実装されているものが、JavaScriptの配列（DOMとは無関係）に
なるわけがないんだよ 最近セミコロン省略してるのよく見るけど流行ってるの？
それともpythonerの悪いくせ？ >>537
forEachはPolyfill作れる 組み込みオブジェクトにメソッド追加して
Polyfill作れるかどうかはブラウザ依存 >>547
es仕様を完全把握してるからどこでセミコロンが自動挿入されるのか完璧に理解して使いこなしているのだ。お前のようなザコと一緒にするな。 >>547
ミニファイしたらセミコロン省略されるんだから最初からいらんだろ あとこのライブラリのコードとか
ttps://github.com/nathancahill/split/blob/master/packages/splitjs/src/split.js
あげたらキリないけどよく見る
セミコロン省略した方がかっこいい風潮あるのか？ 好き嫌いはともかくJavaScript Standard Styleくらい知っとけよ雑魚
https://github.com/standard/standard
スター2万 >>553
結構あるのか、気にしてなかっただけかも
>>551の通り把握できていれば省略しても何ら問題はない
インデントをタブにするかスペース2個にするかの違い（よりは影響大きいけど）
要は好み
混ざってて滅茶苦茶気持ち悪いな、これはさすがに良くない
https://qiita.com/khsk/items/f331798acfb99ef347fc >>556
こいつの思想のほうがよっぽど気持ち悪い
偉そうによくここまで適当なこと言えるな >>556
セミコロン禁止に抵抗ある人向けのJavaScript Semi-Standard Styleもあるらしい
https://github.com/Flet/semistandard >>558
でも大抵の参考書にはセミコロンは絶対つけましょうって書いてるからさ
今まで知らなかったわ >>562
ありがとう！
質問まとめて、またあとで質問させて頂きます 質問
var text="ランダムな文字列1abcランダムな文字列2defランダムな文字列3"
という文字列がある場合にtextからランダムな文字列2だけを削除する短い書き方はあるでしょうか？
つまりabcとdefで挟まれている部分を削除することが条件で、abcとdefはそのまま残して
"ランダムな文字列1abcdefランダムな文字列3"
となるようにしたいです >>564
text = text.replace( /(abc)(.*)(def)/, '$2' ) >>565
それだと結果が
"ランダムな文字列1ランダムな文字列2ランダムな文字列3"
となってしまいますよね？
でも応用して考えて分かりました、
text = text.replace( /(abc)(.*)(def)/, '$1$3' )
とすればいいわけですよね。
ありがとうございます！感謝感謝です >>566
ごめんなさいそうでした。
よく読んでなかった… 仮にランダムな文字列1にabcが入った場合
どちらのabcを優先したらよいのだろう >>564 >>567
いえいえ本当に助かりました
>>568
なるほどそれだと後の方ですかねぇ…でも今回の場合それは考えなくて大丈夫なので566でおｋです セミコロン省略がバグの温床になるときってのは要は謎の改行をしてるときで、まずそんな書き方するべきじゃないし、そんな書き方してる時点でバグとか気にしない人だろう return辺りで結局セミコロン必須の場面があったはず >>571
いや、だから謎の改行だろうがバグの可能性あるならセミコロンありでいいんじゃね？てこと
省略するメリットってタイプ量が減る、ファイルサイズが減る、くらい？ 結局改行が必要になるのでファイルサイズもほとんど変わらない
デメリットの方が多いと思う Javascript3大宗教論争
・セミコロン論争
・const論争
あと一つは？ 言語仕様のほとんどをなあなあにしたアイクとネスケが悪い jsは争点が多すぎて、逆に争うのが無駄だと気付きやすいかも
もう好きにやってろって ふわふわ言語
まぁでも大分良くはなったと思う
昔は本当に酷かった；； >>580
セミコロン２つもつけてんじゃねー！２つとも消せや！ >>521
結局これ。
ブラウザをコントロール出来る社内システム以外は新しいのが使いにくい。 問題「jQueryが使えないサイト用のブックマークレットなのですがどうしたらよいですか」
答え「jQueryを使えばよい」
安定のjQuery気違いクオリティｗｗｗ >>583
> 問題「jQueryが使えないサイト用のブックマークレットなのですがどうしたらよいですか」
どこにそんなふうに問題出したやつがいるの？
お前馬鹿じゃないの？
あ、だからヤブヘビするのかｗ 元の質問がブックマークレット用途だからjquery使ってないって言ってるじゃん
そもそもブックマークレット作るのに互換性なんてそうきにするもんでもないだろ
>>535 でいいと思うが ブックマークレット用途って言ったのは
jQueryの名前が出た後だろ
時系列ちゃんと考えろや
ブックマークレット用途っていうのなら
ポリフィルも使えないってことになるし
> >>535 でいいと思うが
forEachが使えないブラウザもある >>587
> forEachが使えないブラウザもある
w3mやlynxへの対応もしっかりなｗ >>589
はい。そうすると必然的にHTML+CSSメインで書いて
JavaScriptは動きをつけるという使い方になる
jQueryが一番得意とするやり方 NodeListのforEachが使えないブラウザもあるって、もはやIEぐらいなもんだろ
他のモダンブラウザはどれもまともに動くぞ
ブックマークレット用途でそんなの動作保証する必要あるのかっていう話よ いやIEで動かないのは問題だがブックマークレットならどうでもいいな >>587
> ブックマークレット用途っていうのなら
> ポリフィルも使えないってことになるし
なぜ？ >>591
> へーw3mでjQuery動くんだ知らなかった
JavaScriptが使えないブラウザでも出来る限り対応しろってことだよ
>>595
しらん。ブックマークレットだからjQueryが使えないといったやつに聞け
（元の質問者のことではない） >>597
> しらん。ブックマークレットだからjQueryが使えないといったやつに聞け
うん。だから、
「ブックマークレット用途っていうのなら
ポリフィルも使えないってことになるし 」
と発言した>>587に質問してる >>597
> JavaScriptが使えないブラウザでも出来る限り対応しろってことだよ
それ、もうjQuery関係ないじゃん
>>590の「jQueryが一番得意とするやり方」って明らかにおかしいだろ ファイルの冒頭・最後に、セミコロンを付けないと、
ファイル結合時に、文がつながってしまうことがあるとか >>598
なんで一つ前の>>586に言わないの？
> 元の質問がブックマークレット用途だからjquery使ってないって言ってるじゃん
（↑質問者はそんなこと言ってない。だから言ったのは>>586）
アンカーがなかったから気づかなかったのかな？
なら俺が言ったことでわかったから、それを踏まえて>>586に言おうね (使ってないのと使えないのとではずいぶん意味が違うな) （それ以前に質問者はブックマークレット用途だから使ってないなんて言ってないな） （ブックマークレットでjQuery使ってもいいしな） （元サイトで使われてないならブックマークレットで読み込んでもいいし） >>601
>>586をよく読みなさい
「元の質問がブックマークレット用途だからjquery使ってないって言ってるじゃん」
は他人の言を述べているだけでしょ？
>>586が「ブックマークレット用途だからjquery使ってない」わけではないでしょ？
そもそも、586がどうあれ、>>587は
「ブックマークレット用途っていうのなら
ポリフィルも使えないってことになるし 」
と書いてるんだよ
587は「586は〜といってる」ではなく、自分がそうだと思っている書き方でしょ？
この物言いで>>587に質問して何が悪いのさ
なんか、自分の発言を「他人の発言からとってきただけの借り物」かのような言い訳してくる奴、定期的に出てくるけど、日本語勉強した方がいいと思うよ？ > 「ブックマークレット用途っていうのなら
> ポリフィルも使えないってことになるし 」
>
> と書いてるんだよ
だって「元の質問がブックマークレット用途だからポリフィル使ってないって言ってるじゃん」 「元の質問がブックマークレット用途だからjquery使ってないって言ってるじゃん」
という嘘は許すが
「元の質問がブックマークレット用途だからポリフィル使ってないって言ってるじゃん」
という嘘は許さない
なぜならjQueryがきらいだからだ！
まあこんな発想なんだろうなぁ jQuery房は借り物の言葉で語って、何かあると「俺の発言は借り物だから元の発言者に文句をいえ」というわけか、なるほど >>612
そのままの意味だが？
>>587が>>586に責任転嫁してるのが現状 >>613
だから何が責任転嫁なんだ？全く意味不明 そもそも、ブックマークレットでポリフィル使えない云々は>>587しか言ってないじゃん ブックマークレットでjQueryが使えないというのなら、
当然ポリフィルも使えないんじゃね？
だってポリフィル読み込まないといけないでしょ？
ポリフィル読み込むのが許されるならjQuery読み込めばいいで終わるし >>617
それな。馬鹿はその関係性が理解できないんだよｗ ieはなんで開発やめないの？
ieコンポーネントに依存してるアプリがあるから？ jQuery厨とjQueryアンチの争いがいかに不毛かが掴める流れ >>586の「元の質問がブックマークレット用途だからjquery使ってないって言ってるじゃん」は>>522の代弁なのに、>>587が勝手に勘違いして「586がブックマークレットでjQueryは使えない」と誤読した
で、「ブックマークレットでjQueryを使えないなら、ポリフィルも使えいないはずだ」のニュアンスで>>587は書いたつもりだったが、日本語がおかしくて自分がそう考えている風に解釈できる文章だった
だが、>>587はそのミスに気が付かず、「これは586の弁だから、586に文句をいえ」と繰り返しているわけだな > で、「ブックマークレットでjQueryを使えないなら、ポリフィルも使えいないはずだ」のニュアンスで
jQuery房はこの手の文章表現が苦手だよね
「彼のXXXが正しいとするなら、YYYも正しいはずだ(だが、俺はそう思わん)」と書くべきところで「YYYだ」と書いて誤解が広がった事例を過去に何度も見てる
これ、結果的に正反対の意味になるのに、当人は気が付いてないんだよね >>622
お前アスペだろｗ やっと理解しましたって言えよ >>617
forEachのポリフィルなんて短いしブックマークレットでもベタ書き余裕だぞｗ
でjQueryはどうすんの？ｗｗｗ
数万行ベタ書きするわけにはいかねーから読み込むしかねーんだよなワロタｗｗｗｗｗ プログラミングに向いてる脳の持ち主はそもそもJavaScriptとか選ばないからへーきへーき >>624
いや、途中から9割方確信してたけど、日本語力の低さはどうやってもフォロー出来ないよ >>625
> forEachのポリフィルなんて短いしブックマークレットでもベタ書き余裕だぞｗ
頑張らなくて良いものを頑張るとかあほやで >>624
そもそも、初見で>>587を>>622で補完するのは無理だろ(本当に自論からもしれんし)
587の反応を見て自論か他論か判断する手段もあるだろうが、
587の不十分な日本語を読み手が脳内補完してやらなきゃいけない理由はこれっぽっちもないぞ
素直に「日本語間違ってました」と認めりゃいいのに というか、>>622だけでは補完出来ないじゃん
>>621の1行目で説明されている587自身の誤読まで想像出来なきゃならんでしょ
俺が587自身になって587と同じように586を誤読して587と同じように「彼のXXXが正しいとするなら、YYYも正しいはずだ(だが、俺はそう思わん)」を省略して書く事まで想定する
結論としては「587の頭になりきれない奴はアスペ(by >>624)」 俺も586を誤読できなかったから、アスペだったわ
>>624
やっと理解しました
586を誤読できるようになるまで精進します >>624
やっと理解しましたが、今後も>>587の他論を区別できそうにありません
私は永遠のアスペです >>624
やっと理解しました
>>587の行動原理を理解出来ない人＝アスペなのですね jQuery房はアスペが3人釣れたと喜んでるのな
本当にアホ ブックマークレットごときで熱くなれるお前ら気持ち悪い くだらないのは同意だが、jQuery房への批判が集中するのもわかる てか、ブックマークレットって今使うの？
devtoolか、でかい機能なら拡張機能にしないの？ くだらないことに熱くなれるのは若さ故の特権ってやつだな jQuery房の論理は穴だらけだから、気になって仕方なかったんだろ jQuery派が一人だけキモいのかと思ってたが、反jQuery派にもキモいのいたんだな もっと有用な話題にしてよ
レベルが低すぎて泣けるわ でも、まあ質問に対して>>621みたいな反応されたら、俺でも腹立つだろうな
そこだけは同情するわ コミュニケーションが成り立たない脳内補完の多い奴は早めに切り捨てろ、という教訓を得たな
ところで、 https://ja.javascript.info はこのスレ的にはどんな評価？
仕様に忠実なドキュメントという印象ではあるが 仕様に忠実なドキュメントなんて必要がない
仕様書を読めば良いのだから
本当に仕様を大事にしようとした時細かいニュアンスが重要
例えば参照の値渡し、共有渡しとか、実際は細かく言うとその言葉はESにとって間違いで
すでに存在する著名なキーワードでは表せないことが分かる
でもまとめるに当たっては著者が解釈してそれなりの言葉にするしかない
そうした時点で細かいニュアンスは正しく伝わらない
本当に仕様に忠実な情報が得たければ仕様書を読むこと
そして普段から長年メーリングリストで流れを追ってニュアンスを掴むことが大事 >>647
「仕様に忠実なドキュメント」のキーワードで脊髄反射レスするのは止めてくれ
それは俺のただの感想で、仕様をに忠実なだけのドキュメントではないことは読めばすぐ分かるはず 少ない可処分時間をいろんなことが取り合ってる現代、なんでそんなの読んでやらなきゃならないんだ。
何がしたいんだ？そのサイトの宣伝？ >>650
お前は日本語が読めないのか
「ところで、 https://ja.javascript.info はこのスレ的にはどんな評価？ 」 >>647
> 例えば参照の値渡し、共有渡しとか、実際は細かく言うとその言葉はESにとって間違いで
1分かからずに該当ページを探し出せた件
https://ja.javascript.info/object#ref-519 >>651
質問の体裁を取った宣伝なんだろ？バナー広告でよくある卑怯技と同じ。
ところで
https://travel.rakuten.co.jp
はこのスレ的にはどんな評価ｗｗｗｗ >>653
よく無根拠に妄想できるな
相手するだけ時間の無駄だった >>651
横だけど
そこより良いサイトはテンプレに腐るほどあるし、良いサイトならテンプレ見ればいいだけ
わざわざ劣化版を見る理由が無い
雑談なら他のスレに行けばいいし、宣伝以外の理由があれば逆に教えて欲しい
スレの評価を聞いて何があるのかがさっぱり分からない >>655
> そこより良いサイトはテンプレに腐るほどあるし、良いサイトならテンプレ見ればいいだけ
テンプレ(>>1-6)には仕様しかなくて、チュートリアル的なサイトがなかったと思うのだが、腐るほどあるならURLを教えてほしい
> 雑談なら他のスレに行けばいいし、宣伝以外の理由があれば逆に教えて欲しい
俺自身の復習と他人にお勧めできるチュートリアルサイトが欲しかった
俺自身は仕様も読むが、全体把握したい時に仕様だけで網羅するのはきつい(信頼性の高いサイトが別に欲しい。APIならMDNが比較的優秀だが)
https://ja.javascript.info に拘る理由はないので、質の高いサイトがあるなら是非教えてほしい 基本MDN Web Docsだけでいい
MDNは日本語版が糞で悲しいけど、>>646の直訳感の気持ち悪さよりはまし >>657
はじめからそう聞きなよ
サイトの評価とか変な聞き方するから何言ってるんだってなるんだよ
で、
＞チュートリアル的なサイト
は今どこが良いかは分からない、すまぬ
仕様見て勉強した方が早いからあんまりそういうの見ないんだ >>658
腐るほどあるようなので、MDN以外の選択肢を教えてほしい
MDNは90%程は正しいのだが、仕様と読み比べると、やや不適切な表現と感じる事がある
あと、日本語訳が追い付いてないものもあるし、MDNだけでは足りない https://ja.javascript.infoの訳者の自演なんだろうが感じ悪いな。やり方汚いし口も悪い。絶対見ないわ。てかローカルプロキシツールで禁止にしたわ。 >>659
すまん
話題転換のつもりで心の隅に残っていた質問を吐き出しただけだったので、質問内容の精査はしてなかった
やはり、チュートリアル系は少ないよな
https://uhyohyo.net/javascript/ とか http://azu.github.io/promises-book/ とか良いサイトもあるんだが 日本語版よりも、英語版をgoogle翻訳した物が一番読みやすい じゃあ自演もバレた所で
もうそろそろjQueryの話題に戻すかね？ 結局、選択肢がなくて、 https://ja.javascript.info/ を見つけた時にどうかと思ったんだが、知っている人はいなさそうなので、
https://github.com/iliakan/javascript-tutorial-en/tree/master はStar 4029で満足するしかなさそうだな…
宣伝目的なら、俺は@iliakanだが、有名な人なんだろうか >>649
俺は君のレスもそのサイトもよく読んだんだ上であえて「仕様に忠実なドキュメント」として見たときの評価をしている
そもそも俺の持論では、入門者や初級者はたくさんの情報を元に勉強するべし
だからこのサイトが多少良かろうが悪かろうが、結局その沢山のうちの１つということにしかならない
中級者ではどうかというと
例えばプロトタイプチェーンやスコープチェーンの話、これも沢山の説明を呼んで
自分に合った説明を見つけて概念を理解しないといけない
これもまた、色んな視点からの色んな説明が大事
このサイトのようなスマートな説明がいくら素晴らしかろうと、それだけでどうにかなるものではない
そして上級者に必要なのは仕様書
つまりね、このサイトは多他言語を習得してきてある程度知識のある人が
ざっとJSの概要を掴むのには良いかもしれないが、それだけくらいしか特長がない
「仕様に忠実っぽい」という特徴があるから、それに焦点を当てた評価が>>647
それ以上なにも言うことはできない
なぜなら実際のところこれで入門者が０から上達するのには無理だから
もちろんそれを可能にするサイトなんて他にも存在しない
結局特徴も面白みもない有象無象のJS入門サイトの一つということでしかない
それを狙ってるのなら良いのだが、ホント誰をターゲットにしてるんだ？とすら思う > 宣伝目的なら、俺は@iliakanだが、有名な人なんだろうか
有名じゃないから宣伝するんだろう？ 俺はuhyohyoネットの人好きだわ
最初IEディスりまくってたから > 俺は君のレスもそのサイトもよく読んだんだ上であえて「仕様に忠実なドキュメント」として見たときの評価をしている
まあぶっちゃけ自己満足だよねｗ
例えば小学校で習う内容には嘘が含まれてる。それは忠実に説明すると
あれこれ説明しなくてはならなくなって、理解の妨げになるから
あえて忠実にしないことで理解しやすくしている。
それがわからないならjQueryアスペと一緒 >>668
それは、IEディスるのが好きなのであって
IEディスっていれば誰でも良いと言ってるに過ぎないなｗ >>666
上級者なら仕様書だけを読めば自分で学習できるだろう
補完的なサイトが欲しいと俺は思うが、それすら要らないというならそれもまた良いだろう
初級者/中級者が数あるサイトを見て学ぶのはその通りだと思うが、それでも正しい情報である事が望ましい
そういう意味で仕様に忠実といったのであって、仕様をそのまま書くサイトを俺は求めていない(それなら、仕様書を読めばいい)
仕様を著者の判断で咀嚼して解説してくれるサイトが望ましい
そのバランスが比較的良いと思うサイトが俺の中では https://uhyohyo.net/javascript/
次点で https://ja.javascript.info/ は最近見つけたばかりで咀嚼が足りないが、悪くはないと俺は思った
だが、全部を解読出来てはいないので、知っている人に判断してほしかったのだが、ここには既知の人はいないようだ
一つのサイトで網羅できないのは当たり前だ
https://ja.javascript.info/ が中途半端というなら、仕様書以外の全てが中途半端だ
まあ、JavaScriptの場合は仕様が分散してるから、仕様書で歳一つで完結出来ない事も多いが × 仕様書で歳一つで完結出来ない事も多いが
〇 仕様書でさえ一つで完結出来ない事も多いが 今こんなん見つけた
https://devdocs.io/
やっぱ日本語はないな https://ja.javascript.info/variables#ref-360
若干、気になったのはコーディング規約にまで口出ししている点だな
それほど不自然な規約はないが、規約と言語仕様を同一に語っているので、これを読んだ後に別の規約を読んだら初心者は混乱しそうだ 他人を評価する暇があったら、
自分が評価される側になるサイトでも作ればいいじゃん
評論家気取りかね？ >>669
それはちょっと違うかな
そういう面もあるし、そうでない面もある
俺は教科書ほどクオリティが高くて体系的立てられている入門サイトは無いと思っている
それがあるなら話は別だ
だから色んな情報を見て自分の手で色んなことを試して真実を自分なりに解釈しないといけない
>>671
>>仕様書以外の全てが中途半端だ
だからそう言ってるだろう
まああと俺の好みにも合わないな
俺はこのように仕様をまとめ直したものが０からの学習においては良いとは思わない
初学者というのは応用力が無いのだから、機能を最低限のコードでスマートに紹介されても仕方がない
もっとコピペして自分で多少改変して試せるくらいのコード量のサンプル集の方が良いと思うね
中級者になるときの、基礎復習としては良いかもしれないが、
MDN然りただ仕様をまとめ直したものというのは然程変わらないものがすでにある >>673
https://devdocs.io/about#credits
「© 2005-2017 Mozilla Developer Network and individual contributors」か
API ReferenceならMDNで十分だが、MDNより軽快に動作するのが利点かね >>671
あれあれぇ〜？
https://ja.javascript.info/ じゃなくてもいい、たまたま見つけただけと言っておきながらな〜んで必死に擁護してるんですかねぇ？(^^;
宣伝したいから褒められないと困るのかなぁ〜？ しばしば登場するむちゃくちゃなサイトでも適当なサイトでもない
だけどテンプレに入れたい程か？と聞かれればそうではないな
別に覚えておくほどのサイトではなくて
Google先生の力で適切な人に適切なときに適切なページが表示されれば良いんじゃねと思う >>677
> だからそう言ってるだろう
全てが中途半端なら https://ja.javascript.info/ だけを取り上げてdisる意味がないと思うが
> MDN然りただ仕様をまとめ直したものというのは然程変わらないものがすでにある
だから、そのサイトを教えてくれといっている
俺は https://ja.javascript.info/ に拘ってはいない >>679
もっと良いサイトを紹介してくれれば、そちらに乗り換える このスレ闇深すぎない？
変なの引き寄せる能力が強すぎる 的を得るとかの誤字脱字が酷すぎる素人が適当に訳しただけの糞サイト >>681
俺はdisってはない
特に特徴もない有象無象のJS入門サイトと同じと評価してるだけ
そしてそれはプラスの評価だ
こんなサイト利用するなと言ってないだろう
利用するに足るサイトだとは評価してる
が、それ以上ではない
>>そのサイトを教えてくれ
意味がわからない
お前が何を求めてるのかはお前が一番知ってるだろう
本当にとにかく知りたいのならググって色んなサイトを見ればいい
例えばES2015以降追加された機能だけ、とか決まってるのならそうググればいい
そこらへんもわからないのに教えてくれと言われてもね
お前は何を知りたいんだ
今初学者で沢山知りたいことがあるというか何を知ったら良いのかわからないのなら
沢山サイトを見ろとしか言えない
強いて言うなら、更新日時が古いサイトは避けろ >>682
そのサイトお前にぴったりだからずっとそこ使ってろよｗ
もう質問はないな？じゃあなｗｗ 質問でもなんでもない。質問のテイを取り繕った宣伝。翻訳者死ね 真面目で良いサイトなら自然と使われていく
宣伝はいらない
そんなに目を引きたいのならもっと面白おかしいサイトにしたら良い >>686
> お前は何を知りたいんだ
>>657
> 本当にとにかく知りたいのならググって色んなサイトを見ればいい
君と私は全く違うタイプの技術者のようだな
ぐぐって得たサイトが正しい情報を発信しているとは限らないわけで、俺は素性の不明なサイトの情報を鵜呑みにはしない
仕様と比較して情報の正確性に確信が持てるか確認はする
毎回、ぐぐる度に確度を確認しなおすのは時間の無駄なので、確度が高いサイトをストックしておくぐらいの対策はする そもそも質問じゃねーし。
メルカリってこのスレ的にはどうですか？他にいいのあったら乗り換えるんですが。使ってみて答えてください！プレゼントはありません！ｗｗｗｗ >>693
>>657？
チュートリアルを求めてるのに仕様のまとめ直しサイトを挙げるって
ますますお前の考えてることがわからんな
俺はMDNの【JavaScript 「再」入門】とかの方がチュートリアル的だと思うがお前は違うのだろう？
>>確度が高いサイトをストック
すまんがそれもよく理解できない
「見終わっていないチュートリアルサイトをストック」なら分かる
仕様なら仕様書、実装ならコミットログやissueを見れば一発で分かる
結局の所仕様が見れるのならそれ以外を見る必要はない
俺が言ってるのは仕様書をとても見れない入門レベルの段階では
そもそも何が良いかわからんだろうってことだ
そのサイトが平均的に良くても特定の記事が正しいとは限らないしな
俺の経験上サイトはMDN含めどれも信用ならないと思ってる
ああ、あともしかしてお前はリファレンスサイトを知りたいのか？
チュートリアルと聞いてたからな
チュートリアルはこなすものだ
そのサイトを全部見たら、他のサイトに行く
並列でも良いが、そうやって複数のサイトを使って上達していくんだぞ
と俺は言ってるんだ
何か困ったときに調べたかったらどうするか？という話なら MDNを使え
それで済まないときはググればいい
リファレンスサイトならなおさらそのサイトは情報量という点で向かない
お前が種類別に１０も２０もサイトをストックしておくというのなら別だがな 発想を逆転させて、仕様書にチュートリアルやリファレンスを入れれば良いんだよ
こいつが求めてるのは、それなんだから 話題転換のつもりで振ったら集中砲火だもんな
ちょっとかわいそうだｗ 大体実装と仕様の団体がくっついてるサーバーサイド言語なら
サーバーサイドの実用的なプログラムをスタンダードライブラリ含めてチュートリアルしやすいけど
ESはIOから切り離されたただのスクリプト言語だし、仕様書は実装者のためのものになっちゃってるからね
読みやすさという点では改良されて来たけど、チュートリアルは期待できないね >>698
話題転換が大成功してるだけだと思うけど JavaScriptの争いポイントに参考サイトが含まれる未来が見えた
争点増やしすぎぃ それ前からいる（現実のブラウザを無視した）仕様厨の亜種だろ？
仕様の話ばかりしていて、現実のブラウザでは動かないものがありますよっていったら
親でも殺されたかのように反応する >>697
昔googleがそれだったんだけど、全く動かないコードや古いコードがほったらかしで本気で迷惑だった
サンプルもちゃんと更新してほしいが、できないならやらないで欲しい >>704
> できないならやらないで欲しい
そのお前の希望を叶えた結果。
誰もやらないんだよ？ >>705
いや、別に構わんよ
当時はピュアっピュアやったからgoogleのサンプルコードが間違ってると思わず、延々苦しんでたわ
たまに間違えるのは仕方ないけど、内容ボロボロで更新意欲0なら無い方が良い > 当時はピュアっピュアやったからgoogleのサンプルコードが間違ってると思わず、延々苦しんでたわ
間違ってるわけじゃないんだよ。当時はそれが正しかった。
同じブラウザでも、バージョンによって動きが変わる
バグの修正であっても、互換性の点から言えば挙動が変わってるから
互換性問題が発生する。つまり互換性問題は今もあるってことなんだよ。
だからそれを解決するライブラリは今も重要ってこと
延々と苦しまなくてすむように、そのノウハウがライブラリに入ってるのに
それを否定するから、そういう目に合うんだよ。
自業自得 こういう相手の事を想像で補完して、想像上の相手を否定していくやり方が認識の違いを大きくしていくんだな >>708
jsも一緒。ってかgoogleの間違ってるサンプルコードってどれよ？
本当にDOM関係ないサンプルコードなんだよな？ >>710
いや、ライブラリだ大事って話
JSの構文の問題だとライブラリじゃ解決できないじゃん > JSの構文の問題だとライブラリじゃ解決できないじゃん
Googleのサンプルコードが間違っていたんだよ！
→ GoogleのサンプルコードっていうのはJSのことなんだよ！
→ GoogleのサンプルコードのJSっていうのは構文のことなんだよ！
情報小出しっていうのはこういう事を言うのかｗ >>771
> JSの構文の問題だとライブラリじゃ解決できないじゃん
別に解決できると思うが？
for of が使えないなら、for of 相当機能を提供するライブラリを使えばいい こいつ何を言ってるんだ？
言ってもないことが聞こえるっていよいよ末期の思い込み病だな for-ofが使いたい時は結局イテレータ周りの実装も欲しいからライブラリだけじゃだめだね イテレータ が使えないなら、イテレータ 相当機能を提供するライブラリを使えばいい >>709のスタイルでレスしている奴が一定数このスレにいるんだよ
jQuery房もそうだし、チュートリアル質問に反論してる奴もそうだった
勝手にこちらの考えを想像して早々上の考えを否定してくるから、思ってもない事を否定されてる気分になるんだが、彼の中では真実なのさ × 早々上の考えを否定してくるから
〇 想像上の考えを否定してくるから 軟弱すぎだろ
2chではこれくらいが普通
好きの反対は無視だからな
あれくらいのツッコミは愛情だろ
否定された〜とか言ってるようなら最初からレスするな
yahoo知恵遅れに一生潜んでろ 否定されるのが嫌なんじゃなくて、勝手に想像して勝手に否定してくるのがうざいだけなんだがね
結局、間違ってるんだが、訂正しても信じないという妄信力の強さ 現実を見ずに想像上の仮想敵と戦ってる奴いるよな
>>714も同じようなものを感じてるんじゃないの >>716
> イテレータ が使えないなら、イテレータ 相当機能を提供するライブラリを使えばいい
それなｗ 否定されるのが嫌なんじゃなくて、勝手に想像して勝手に否定してくるのがうざいだけなんだがね
Googleのサンプルコードが間違っていたと言っただけで
DOM APIのことだと勘違いして、
JSだっていったら、今度はJSの構文のことではないと勝手に想像する
俺が言ってないことを勝手に想像すんなや >>725
書いてない情報を想像で補完するお前が悪い >>726
だからさっさとGoogleの間違ってるサンプルコードとやらを出せばいい
それをしないから、ズレた前提（？）で話が進むんだろ
それが嫌なら、最初から言わないことだ
ズレた前提が嫌なのはお前であって、俺じゃねーから 間違ったサンプルコード＝動かないコードを書いて延々苦しんでたんだろ？
ライブラリを使うことで、動かないコードを書かないですむから
延々苦しまなくてすむってことだろ
それぐらいわかれよ comic walkerでさ、漫画の画像保存すると真っ黒画像になるんだけど、
(FFのシフト押して右クリックして右クリックを無効にしないやつ)
これって、canvasに3重に重ねて、背景画像だけDLしてる？
application/octet-streamタイプの拡張子なしのファイルがやり取りされているけど
画像？ってかbase64っぽいんだけど、jpgとpngに戻せない。
さっぱりわからん。
おまえら、javascrit極めてるから、わかる？ >>727
俺は質問者ではないが、ずれた前提を勝手にお前が発明して回答するぐらいなら、前提を尋ねるか、回答しないべきだと思うぞ
お前の回答はノイズにしかならん >>731
だから俺はそれで困ってないと言ってるだろｗ >>704だけどジョギングから帰った
なんで俺抜きで盛り上がってんのｗ
どこが間違ってたかなんてさすがにもう全く覚えてないし、そんな事気にしてもしょうがないだろう
今googleは開発周りちゃんと整備してくれているし、サイトも見やすくなった、それでいいじゃん
過去にこだわる男はもてんぞ〜 過去にこだわってるから、昔のGoogleはなんて話をし始めたんだろう？ >>732
お前の心配なんて全くしてない
「質問の前提が足りないから俺の方で勝手に想像して、想像した前提を否定しておいてやったぞ。前提を書かないお前が悪いんだからな。」は明らかに質問を解決する気がないだろ
回答の体をとって質問者をやり込めたいだけの迷惑な奴 >>734
だから俺は持てないんだよ皆まで言わせるな >>736
うーん？そうだね。お前にとってはそういう人に見えるんだろうね。
で、俺の人格批判を好んでやってるわけ？
もっと建設的な話をしようぜ >>738
前提を勝手に補完するのが間違いだということが分からんのだな
補足要求しろ 勝手に補完してくれるようなエスパー体質の人しか質問スレには居残っていないよ
じっくり会話したいなら議論スレでも建てれば？ >>740
これから質問する奴は全員エスパー期待していいってことか >>741
前提を勝手に補完するのが間違いだということが分からんのだな いいんじゃない？
・前提を勝手に補完して最速で回答
・回答者に聞きながら丁寧に回答
両方がいれば質問者にとってはベストな展開だろう >>742
？？？
>>740は前提を勝手に補完するエスパーを期待してるんじゃないわけ？
エスパーミスったら、エスパーの自己責任ってことでしょ？ 自己責任と言っても責任なんて誰も取らんよ
質問者が困るだけ そうやな、回答者に正しく状況を知ってもらうのは質問者の責任 >>747
あぁ、そっちだ
回答者はただ自分の信念に基づいて回答するだけ
理解してもらう努力を放棄した質問者は、困る可能性が大きくなる >>745
その通り
エスパーした内容に勝手に否定して、話を広げてくるから非常に迷惑してる 俺がエスパーだったら漏らす直前まで我慢したくっさいくっさい俺の下利便を女子中学生の大腸にテレポートさせて様子を観察する 問題はエスパーではなく、自己完結君
■エスパー
- 「もし〜なら、〜です」(エスパーした前提を書く)
■自己完結君
- 「〜です」(エスパーした前提を書かない)
- エスパーした前提を含めて相手を否定する (自分で捏造した条件を自分で否定する独り相撲)
- 自己完結君に質問してもなんだかんだではぐらかす
- 複数レスを費やして、ようやく某エスパーが自己完結君をエスパーする(当人はエスパーした前提を書かない)
典型的な自己完結君は>>587で>>621がエスパーした
質問者以上に強力なエスパーを必要とするモンスター回答者 つまり、回答は相手に伝わらなくても良いし、伝わりづらい表現でこきおろしても良い
それで困るのは質問者で回答者は困らないから好き勝手に質問者をいじり倒す、というわけだな >>757
うお、マジかよ。かなりショックだわ・・・
js全然関係ないけど そりゃ、自己中な回答者ばかりいるスレで質問しようとは誰も思わんだろ 配列とかオブジェクトとかMapインスタンスの宣言でconstでなく敢えてletを使うコードを見かけるけど、
全部constで良いよね？
「オブジェクトがイミュータブルじゃない（freezeされてない）から明示的にletにしておく」
とかそういう思想でもあるの？
const/letの意味を勘違いしているのか、俺が勘違いしているのか？ >>763
俺は基本的にconst使ってるよ。
高階関数使って関数型的な書き方をすれば変数を
書き換えることもないのでlodashやjQueryとの相性も良い >>764
だよね
どうもconstをC/C++っぽいイメージでとらえてるっぽい constつけとけば変更されないくらいのしょうもない理解のやつが後を立たずバグが続出した。結果、全部letになった。
配列やオブジェクトのconstの挙動で混乱するらしい。
どうして混乱するのか俺は意味が分からず混乱した。 なんでconstでバグになってletでバグにならないのかわからん
letの使い方のうち値を変更しないものをconstにするだけだろう？ 基本型と参照型の違いを理解してないって事か
C/C++のポインタ/参照が分かってれば分かりそうなもんだが letのほうが短くて良い
定数と一時変数は分けるべき
constで宣言する変数を全部大文字スネークケースにするわけでも無いだろうし
単純に安全だからとりあえずconst使っとけというのは安易な考え >>768
JSに基本型も参照型もないでしょ
すべてが名付けの連鎖で説明できる >>769
君のような人が>>763のようなコードを書くんだろうね
まあこれが世に言うconst論争というやつか >>771
いや、普通に考えて今まで定数は例えば大文字スネークケースで書いたりしてきたでしょ
でも関数内の一時変数をそう書く人はまず居ない
なのにどちらにもconst使うっておかしいでしょ
そこまで神経質なら全部のオブジェクトもプロトタイプ調整してfreezeすべきだと思うよ
変化が無いからとconstを付けるのはどうしても違和感があるね >>774
letだと変更がありうるのではと身構える
constだと変更がないことが保証されるから脳の負担が減る
脳みそのためになるのよ Kotlinはvalとvar
Swiftはletとvar
この点はJavaScriptが非常に劣る点、羨ましい constと同じ意味になる
例えば a =: 123 みたいなシンタックスシュガーできないかな？ Scalaなんかもvalだし、valで良かったよな
まあそうすると今度は「varと似てて紛らわしい」派が現れるんだが
あるいはRustみたくletをconstの意味にして、可変にしたいならlet mutでも良い
可変の方が長ければみんな自然と不変寄りになるだろう
何にしてもconstがletより長いのは馬鹿げた仕様 Reactで
class Hoge {
// 省略
}
function mapStateToProps() {
// 省略
}
function mapDispatchToProps() {
// 省略
}
export default connect(mapStateToProps, mapDispatchToProps)(Hoge)
ってのがあるんだけど、このconnect()()ってどういう書き方なんだろ？ 高階関数って引数に関数を渡せる奴だよね？
connect(mapStateToProps, mapDispatchToProps)が高階関数
その後の(Hoge)は
connectの戻り値の関数(Hoge)
ってことなのかな？
つまりHogeが引数？ 戻り値を関数にする関数も高階関数というよ
要は関数を引数に取るか戻り値にしてたら高階関数だ
実装は知らんがそれを見るにconnectは関数を受け取って関数を返してるんだろうね sortがどういう手順で入れ替えをしているのかふと気になり
var ary=[8,5,7,6];
console.log(ary.sort(function(a,b) {
console.log(`a=${a}, b=${b} ${a-b>0} arr=[${ary}]`);
return a-b;
}));
というコードをChromeで試したところ
a=5, b=8 false arr=[8,5,7,6]
a=7, b=5 true arr=[8,5,7,6]
a=7, b=8 false arr=[5,8,7,6]
a=7, b=5 true arr=[5,8,7,6]
a=6, b=7 false arr=[5,7,8,6]
a=6, b=5 true arr=[5,7,8,6]
となりました
これはクイックソートではありませんよね？
false→trueのときに交換が行われているようなのですが
一体何ソートなのでしょうか ソート中のaryは都度更新されるわけじゃないね
firefoxは最後までarr=[8,5,7,6]のままだし もうホントに>>786こういうレスにはウンザリ
何も分かってないのに大間違いな回答するなと
それ何年前のコードだよ いい加減にしろ
ちょっとでもES DiscussやChromium issues追ってたら、長年度々話は出てたが
いよいよソートは常に安定にした方が良さげだねというコンセンサスが高まってるのがわかるだろう
そしてついにChromeが常に安定なTimソートに切り替えたっていう大事件を知らないっていうはずがない
仮に、仮にだよ
今日まで事故で入院してて意識がなくて知りようがなかったとかいう事情があったとしても
今のソースコード見れば嫌でも分かるでしょ
https://chromium.googlesource.com/v8/v8/+/master/third_party/v8/builtins/array-sort.tq
ソースコードを提示したいのなら、正しいソースコードを貼れ
それはもう人として最低限云々の話
>>786 悪気がなくともこういう奴を俺は本当に軽蔑する 入院してて意識がなくて知りようがなかった奴以下でワロタ ふぅ。だからいろいろ詰め合わせてあるって言ったろ？ 長年の意識不明状態から回復した>>788「はっ……！ 今は何年だ？ 俺はどれぐらい眠っていた？ まずはソースコードを読まなければ」 >>790,794
ちゃんと謝れる子はえらいんやで >>795
一時期は毎日patch書いてたよ
Chromiumの一部は俺のコードでできてるし俺の考えが反映されてる
俺の一部を使わせてやってんだから どうも有り難うございますと思え ここで証明出来ないことを書くと
どんな欲求が満たされるの？ 精神病院に入院してたんだろ
退院したらまずソースコード読め 俺も昔phpとマニュアルのバグ直してたな
勉強ついでの恩返しみたいなもんだ WebデベロッパーならWebに貢献しないと とまでは言わんが
意見を表立って言わないのにここで標準の文句だけは言う日本人の腐ったような奴が多すぎ
そりゃ全部を最新まで追うのは無理だが、自分の興味ある分野だけに絞ってもいい
案外少人数で進められていて、意見の出しがいがあることはすぐに気付ける 何のオープンソースプロジェクトにも貢献せず会社で与えられたコードだけを書くだけ
っていう人生はつまらなそう jQueryアンチさんには悲しいお知らせですが、
3ヶ月続けて、jQueryのシェアが上がり続けてますよ。
https://w3techs.com/technologies/history_overview/javascript_library/all
Usage Trend 73.0%(2017/12/1) -略-> 73.3% -> 73.4% -> 73.5% -> 73.6%
一年で+0.6%
こっちは連続はしてないけど上がってる
https://w3techs.com/technologies/history_overview/javascript_library
Market Share Trend 96.2%(2017/12/1) -> 97.3%
一年で+1.1% 意味がわからない
例えば犬アンチに犬のシェアが上がり続けてるぞと言ったところで何がどうなるというのだろうか >>805
jQueryアンチが、jQueryはこれから使われなくなっていくって
言ってるから意味があるんだよ。
犬アンチは犬が嫌いと言ってるだけで、
これからみんな犬を飼わなくなるっていってないので
その例えは的外れ >>806
皆使われなくなっていく（から、もう使うの辞めよう）なんて言ってるアンチは見ないぞ
皆使われなくなっていく（未来を目指していこう）って言ってるんだろ
むしろ皆使って皆安心みたいなところを否定してる人も多いと思うよ > 皆使われなくなっていく（未来を目指していこう）って言ってるんだろ
一部の人が言ってるだけで根拠はない（一部の人の希望）
現実は逆に使われていってる
誰も使われない未来になんて進もうとしてない
という話 jQueryって使っている人増えてるのな。安心した。 まだ今年は数日残ってるが
https://w3techs.com/technologies/history_overview/javascript_library/all/y
Zeptoは死んだか。
やっぱり大手ライブラリの互換ライブラリは死ぬ運命だよなぁ
軽いのが取り柄っていうのは結局機能を減らしてるので、劣化版でしかないわけで
lodashも減ってUnderscoreが伸びてるし。lodashはUnderscoreより機能多くて好きなんだがなぁ
あとは古いライブラリが使われなくなっていってる
一つ興味を引くのはReactが大きくシェアを減らしてる。残念なことだ。
Vueが増えてるしReactからの乗り換えかな？それ以外はReactブームで
試用してみたがユースケースに合わなかったりしてやめたってところなのだろう >>808
君は根本的に間違っているんだよ
戦い方がズレてる なんというか、せっかくのその主張のエネルギーが無駄
君は煙にパンチしてるようなもんだ
よく聞いてね アンチjQueryっていうのは、単純にjQueryが嫌いっていう人もいるけど、
長々と主張するのはほぼ「標準厨」だから
かれらはjQueryが嫌いなのではなく、モットーに合わないから排除しようとしている
本当の意味でのアンチなの
彼らの中では基本一般人のトレンドというものは全然考慮すべき事柄ではない
いい？ Webというのものは標準化サイドが決めたことが、
ある程度の年月をかけて大衆に流れていくものだと思っている
彼らにとってWebとは受け入れるものではなく作っていくもの
「誰も使われない未来になんて進もうとしてない」？
違う
彼らにとってはこういう主張、議論をすることこそがまさに
「理想の未来へ進めていってる」作業だと信じてるの
わかったかい？
今日のお話はここまで もう寝な > かれらはjQueryが嫌いなのではなく、モットーに合わないから排除しようとしている
> 本当の意味でのアンチなの
はい、自分の中でやってください。他人に押し付けないでください。
脱jQueryしようなんて普及させないでください。
ほとんどのサイトには合わないんだから迷惑です。
ゴミを巻き散らかさないでください zeptoまだ生きてたんだ？
今はumbrellaとかblissだよなぁ… 標準を作る人の目的と、
仕事をする人の目的は違うからな
仕事をする人に開発効率よりも標準のほうが重要だと言っても意味がない
標準を元に、ライブラリ・フレームワーク開発者が
便利なものを作る。大抵の人はその便利なものを使うという構図でいいのよ
目的が違う人に目的に合わないツールを押し付けない。最低限のルールだ じゃあここでjQueryの布教もしなくていいんじゃね？
新興宗教とアンチの構図を見てるようだ jQueryって単にprototype.jsと競合していただけで、
prototype.jsはなくなればjQueryを使わない理由がない >>233
この画像みるとReactとvueを使ってる奴がjQueryよりかなり多いのに
https://w3techs.com/technologies/history_overview/javascript_library
こっちだと比べ物にならないほどReactとvueが使われていない
日本人開発者は嘘つき見栄っ張りなのか？
それともReact使っているけど挫折したとか、何かのプライドでjQueryは使っていないことにしたいってことなのか？ 何を今さら
日本人は新しいもの使ったり０から物を作るのが好きってことは周知の事実でしょ
既存の物を効率的に使って楽をすべきという考えは日本人が最も低い >>819
そんなもん、参加者バイアスに決まってるじゃん
新しいものに興味がある人の投票結果だろうし、
手書きで追加されてるから、途中で追加された可能性もあるし
（本来すべての項目は、使ってる or 使ってない に分類されるはずなのだから
項目ごとの投票数の数は同じになるはずなのにそうなっていない）
jQueryは使ってない人よりも使ってる人が遥かに多いのに比べ
React、Vueは 使ってると同じぐらい使ってない人がいるし
データとしての信頼性は低い > この画像みるとReactとvueを使ってる奴がjQueryよりかなり多いのに
そもそも、その画像見てそういう結果にはならないでしょ？
赤丸と青丸の違いは本人の希望であって事実じゃない
赤青無視した丸の数（実際に使ってるかどうかの事実）は
・ReactとVueはおよそ半数が使っていると答えました。
・jQueryは使ってる人は使ってない人の5倍いることがわかりました。
という結果なんだから >>821
勝手な憶測は不要
その画像だとjQuery使ってる奴と同じくらいReactやVueを使ってるから実質同等の利用率だよな？
つまりjQuery使っていた奴らが今はみんなReactやVueを使ってるってこと
そしてjQueryは二度と使いたくないほどクソライブラリだと思ってる奴が半数以上もいる
jQuery未経験者にすら嫌われてるし
これが現実だろ >>820
好きかなあ？
その割には歴史的にも今の世の中にも
日本でゼロから作られたものって
それほど多くはないような… >>823
> その画像だとjQuery使ってる奴と同じくらいReactやVueを使ってるから実質同等の利用率だよな？
勝手な憶測はやめろ
Flowを見てみろ。使ってる or 使ってない に投票した人は少ない
この表は明らかに、どちらにも投票してない人がいる。
ReactやVueには投票したが、jQueryにはどちらにも入れてない人だっているだろう
だから、React、Vue、jQueryそれぞれで、使ってる or 使ってない 人の割合を知ることは出来るが
ReactとjQueryを比べることは出来ない > jQuery未経験者にすら嫌われてるし
何も評価してないってことじゃねーかｗ
使ってみたいと思ってるが、実際には使ってない
のが多いのはReactとVueだよな。
シールの通りだ >>825
jQueryは使ったことない奴なんてほとんどいないんだよ
だからReactに投票した奴はjQueryにも投票してる
そしてjQuery使っている奴と同じくらいReactやVueも使っているってことは明らかにjQueryからReactやVueのほうに移行しているってことだろ > jQueryは使ったことない奴なんてほとんどいないんだよ
> だからReactに投票した奴はjQueryにも投票してる
すべての人は「使ったことがある」「使ったことがない 」のどちらかに分類されるのだから
つまり各項目の「使ったことがある」「使ったことがない 」を合計したら同じにならなければいけない。
だが見てみろ。jQueryの下にあるSassとかLessは極端に少ないぞw
どういうことだ？
Reactには「使ったことがある」「使ったことがない 」のどちらかに投票したが
jQueryには「使ったことがある」「使ったことがない 」のどちらかにも投票してない人がいるってことだ >>828
おまえアホ？
sass利用者とjsライブラリ利用者が合うわけないだろ
そもそもポストイットに適当に貼ってるだけじゃねえかよ >>829
> sass利用者とjsライブラリ利用者が合うわけないだろ
なら使ったことがないに投票してるはずだが？
> そもそもポストイットに適当に貼ってるだけじゃねえかよ
jQueryは手書きで後から追加してるじゃねーか >>830
手書き部分はどうでもいいだろww
実際、Reactとvueはみんな使ってるってことだよ
そしてjQueryは半数以上が二度と使いたくないほどクソみたいに使えないクソライブラリだってこと
その事実さえあればいいのにお前は関係ないポストイットとか手書きとかそっちでしか対抗できてねえじゃねえか笑笑笑笑笑笑笑笑笑 > 手書き部分はどうでもいいだろww
よくないだろ。
後から追加してなきゃjQueryだけ手書きになったりしない。
全員が全てに解答してるわけじゃなく、
どちらにも表を入れてない人がいるということがわかる
あとから追加されたであろうjQueryが少ないのは考えられる話
> そしてjQueryは半数以上が二度と使いたくないほど
だから、使いたくないと言っていたとしても、
実際には使ってるだろ。5倍も差がある。現実受け入れろよｗ あとツイートに書かれてる通り、このアンケートは
30分とか1時間とかのセッションでとったものじゃないからな。
ヤフーのブースにカンファレンス開始時にはられて終了直前、朝から夕方まで提示されたものだ
いつjQueryが追加されたなかんてわからん。 そこまでしてjQuery使いたいならお前一人が使ってろよ
お前以外は全員ReactかVueに移行してるから > そこまでしてjQuery使いたいならお前一人が使ってろよ
だから世界中で73.6%の人が使ってる。今年一年で0.5%増えた。
（Reactは0.5%から0.2%へと、0.3%減った）
https://w3techs.com/technologies/history_overview/javascript_library/all/y 昨年は、Reactへの移行が始まった。
今年は、脱Reactの年だった。
来年は、脱Vueかもしれないな。 jQueryは過去に作ったサイトが残っているだけだから
今の開発者はもうjQuery使っていないぞ
ReactかVueで作っている > jQueryは過去に作ったサイトが残っているだけだから
それだとシェアが増えるはずがないんだよね・・・ >>839
そりゃ世の中クソサイトやwordpressが増えれば勝手にjQuery増えるだろ
使ってるつもりなくてもとりあえず付属しているからどうしようもない wordpressがvueに置き換わっても、
使ってるつもりなくてもとりあえず付属しているからどうしようもない
って言えるの？ >>842
DreamWeaverやらホームページビルダーやらが一緒に並んでいるのは興味深い
海の向こうではWordPressとDreamWeaverとWixは
CMSとして同列にならべて語るもんなんだなあ >>824
それは目に見えてないだけ 日本が得意なのは部品や原料作りだから
それらあるものを組み合わせて実際に素敵な製品を作るのは海外の方がずっと上手い またjQuery房がくだらないスレ立ててるな
世の中の大半「もうjQueryは使いたくない」
世の中の大半「ReactかVueを使ってる」
この事実を受け入れられずに時代についていけないゴミのようなjQuery房
カスサイトに勝手に付属しているjQueryの存在を知らずにみんな使っていると勘違いしているおバカちゃん >>847
ジャンルによるんじゃね？
ウェブアプリ作るときにはvueやreactのほうが使いやすいけど
昔ながらの階層が深い秘伝のタレ化するウェブサイト作るならjQみたいな
汎用関数群のほうがフィットするなあ、とも思う
このスレにいるむやみにjQを推してくるあいつがウザいとは思うけど
それはそれとして jQueryをうまく使うにはCSS設計が大事
CSSベースで設計して、そのとおりにHTMLタグを記述する
そして、jQueryでも同じセレクタにたいして
処理を適用すればシンプルに作ることが出来る Reactが急速にシェア減った理由ってなんだろう？ ちょっとしたサイトには大げさ過ぎるからな。戦艦みたいになってしまった。 そこまでやるならphp側で頑張ったほうが色々と手軽なんだよ >>852
でもreactが減った分vueに移動してるようには見えないんだよな
AirbnbがReact Nativeやめたっていうに追従したのかとも思ったが
6月半ば頃だから少し時期が合わない
これも時期は合わないが興味を引いたので
「Netflix が React やめて 50% 高速化」という記事が話題なので React のそもそもの嬉しさを語ります。
https://www.mediamaxjapan.com/techblog/bookmarks/netflix-stop-using-react/
> またまた衝撃的なニュースが飛び込んできました。Netflix が React を使うのをやめて、
> 昔ながらのサーバーサイドレンダリングに戻して、ランディングページを 50% 高速化した、と言うものです。
>
> 結論から言えば、Netflix は React の使いどころを見誤っていたんではないか、と思います。
> 加えて、単純に文字列を組み立てるだけの昔ながらのサーバーサイドレンダリングと異なり、
> クライアントフレームワークはコンポーネントツリーや仮想DOMという中間層を組み立ててから、
> 文字列にシリアライズする必要があるため、本質的にオーバーヘッドが大きくなります。
そうだね。テンプレートエンジン（文字組み立て）の方がDOM構築よりも速いのは当たり前だよね。
クライアントだけで完結しないもの（例えば初期ページの表示）はサーバーサイドでレンダリングしたほうが速いと >>855
俺はreactとvue同時にプロトタイプ作ってみて、vueの方が学習コスト少ないと思っただけだよ
ただjsのフレームワーク導入しても結局db・回線速度でボトルネックになるので
無いがベストかは分からなかった
特にnetflixみたいに動画や画像が多いとサーバーのストレージ速度などにも影響される
速度だけで考えるとキリが無い
逆に言うと学習コストばかりかかる上にFWが消え去る可能性があるなら、もうオレオレFW＋jQueryでいいじゃんってなる いまNetflixのサイトみたけどReact使われてるんだが ランディングページって書いてあるんだからトップページとかでしょ？ 動画サイトなんてreact関係ないし学習コスト低い方がよくね ネイティブアプリとコードを共通化するためでしょ？
逆に言えば、アプリ作らないならReactいらない >>860
そうだよ
スマホアプリとPCブラウザのwebアプリケーションからのリクエストを
同じバックエンドのエンドポイントに飛ばしてJSON受け取ってレンダリングする
この処理を共通化するのが目的
MVCの三階層モデルでいうなら
バックエンドはMCだけやったほうが効率が良いという理由もある(req/sが向上する)
BaaS(Firebaseなど)を使えばサーバ構築すらも丸投げできるし
フロントエンドだけ自分達で作ればサービス運営できるメリットがある
人件費削減(バックエンドエンジニア、サーバインフラエンジニア不要)
浮いた予算をBaaSの支払いに充当すると月間数億PVまでまかなえてしまう
それくらい人件費というものは高い もうすぐ2019年になろうとしている今
スマホアプリまたはPWA化してスマホ対応しない選択肢はない
(もしスマホ対応しない！という決断を上層部がしているのなら、いますぐ転職したほうが良い)
こういう背景があるからReactやVueが誕生した。
これらの仮想DOMライブラリを使わない場合
複雑に絡み合ったスパゲッティコードでJSON受け取りDOM差し込み処理することになる。
そういう地獄を見てきたからこそ
>>233のようにjQuery使ってるけどもう使いたくない、というエンジニアが増えた。 つまりjQuery推してる人はペライチのサイトやCMSサイトのデザインしか経験してない
場末のweb制作屋(非上場、年間売上数千万)に勤務しているか、フリーランスなんだろう。
まともな会社に勤務してたらReactかVueを使うプロジェクトに投入され
その有用性に気付くはずだしな >>863
あぁようやくわかったわ
こういうアンケートは
*利益/pv
などで聞くべきだ >>892
> スマホアプリまたはPWA化してスマホ対応しない選択肢はない
スマホ対応するのは簡単だよ。
メディアクエリーを使って、レスポンシブウェブデザインにすればいい
ようは幅などを見て各端末に最適化したCSSに切り替えるだけ レスポンシブウェブデザインは Responsive Web Design, RWDっていうみたいね。
PWAしなくてもRWDにすれば良い >>866
5年前からタイムスリップしてきたの？ｗｗｗｗｗ Googleモバイルファーストインデックス後はレスポンシブが唯一の選択肢か？ #inhouseseo 2017年8月25日
https://www.suzukikenichi.com/blog/responsive-web-design-is-the-way-to-go/
Google の Gary Illyes（ゲイリー・イリェーシュ）氏は、8月22日に開催された
ISM Spin-off #2 で、このようにレスポンシブ ウェブ デザインをかつてないほどに推奨しました。 スマホ「アプリ」または「アプリと同様にホーム画面にアイコンを置く」ことを前提にしてるから
レスポンシブデザインだけではスマホ対応とは言えない
ユーザ導線を配慮してReact NativeなりPWA化するなりしないと駄目だぞ
そういう意味では5年前からタイムスリップしてきたの？という感想が出るのは仕方ない ユーザの大半(いわゆるIT弱者、中高年)は検索すらしない
ニュースアプリのリンクをタップして行ける範囲か
スマホアプリアイコンをタップするところで止まる
なぜならスマホで文字入力は面倒だし音声検索も外では使いにくい(恥ずかしい)からだ
Chrome立ち上げて検索ウィンドウに興味のある単語入力させて
検索上位に行くようにSEOを頑張って…というのはもう古い
スマホアプリ化してガチ予算つんで広告してインストールさせる
これが今の業界だよ グノッシーって誰が使うんだよアハハ
→取引先重鎮が使ってた
日本はIt弱者極まれリって感じだったな >>870
あの、アプリの話なんかしてないんだけど？
ウェブサイトとアプリで同様のことが出来るものを
作ってる会社がどれほどあるとと言うんだ？
まずいろんなアプリを思い浮かべてみろ。
それのウェブ版はあるかい？
殆ど無いだろ >>871
ユーザの大半(いわゆるIT弱者、中高年)は検索すらしない
ニュースアプリのリンクをタップして行ける範囲か
スマホアプリアイコンをタップするところで止まる
アプリインストール画面がでたら出たらよくわからないので戻る
インストール？なにそれ？
間違って入れたとしても知らないアイコンは押さない
これが現実 ヤフオク
メルカリ
ラクマ
食べログ
価格コム
etc 世界にホームページがいくつあるか知っていますか？
http://toyoda-mo.com/index.php?QBlog-20180330-1
> 2017年には17億6692万6408となっています。 ホームページ…？
2000年前半からタイムスリップしてきたのか 世界・国内主要企業サイトの7割以上がレスポンシブデザインを使用
https://at21.jp/web/topic/topic33.html
> 前回に続き、世界および国内の主要企業サイトを対象に調査しました。
> その結果、スマートフォン対応サイトは、世界、国内ともに前回から増加し
> 8割を超えました。対応方法は、レスポンシブデザインが7割強と増加、
> スマートフォン専用サイトは1割前後にまで減少しました。 やっぱ世の中はレスポンシブウェブデザインの時代なんだな >>873>>874
お前・・・
逆だよ
アプリが主流なんだよ
で、アプリのweb版を見越して、webでどうするかがどれだけあるかなんだよ
俺は今はアプッリはとりあえず作って、内部的に簡易webサイトに飛ばしてるだけだけど
これ以上はヤバイな PV数で見てくれよ
月間30PV(自分のアクセスだけなので実質0PV)しかない「たかしのホームページ」が
10億あっても0PVだからね
役員しかアクセスしない自社サイトも同じだ
そういう小さい仕事しかしないからjQueryで十分だと感じてしまうのだよ
もうちょっと大きい仕事した経験をしてから発言してくれよ > アプリが主流なんだよ
上場してる100社のうち、
ウェブアプリを作ってる会社は何社？ モバイル：PC
のように
アプリ：モバイル
の割合が増えてるよ
ただ前者ほどは増えてない
この後どうなるか >>887
> モバイル：PC
> のように
> アプリ：モバイル
> の割合が増えてるよ
ひろゆき「それってなんかデータとかあるんですか？
なんだろう。ウソつくのやめてもらっていいですか。」 データ
2017〜2018年に突如出現したReactは
2018年の間にシェアを大きく減らした
2018年は、脱Reactの年だった。オワコンReact
Usage Trend
https://w3techs.com/technologies/history_overview/javascript_library/all/y
React： 2017年1月 なし、2018年1月 0.5%、2019年1月 0.2%
Market Share Trend
https://w3techs.com/technologies/history_overview/javascript_library/ms/y
React： 2017年1月 なし、2018年1月 0.7%、2019年1月 0.2%
※2019年1月は正確には2018年12月27日現在のデータ >>889
反論来ても問題ないように、いつから増えたかは言っていない
どれぐらい増えたかは自身で示されればいいんじゃないすうかｗ >>888
あぁわかった
彼に話が通じない理由
スマホアプリの開発経験がないんだね
だからHTMLで構成されたwebアプリケーションをそのままスマホアプリ化できることをしらない
レスポンシブデザインがwebブラウザ上でしか使われていない、スマホアプリとは無関係な技術だと勘違いしてるのか
道理で平行線なわけだ 反論来ても問題ないように、いつから増えたかは言っていない
＝反論されたら言い返せないから、はぐらかすために言ってない。
＝でもデータ示せとくるのは想定外だった。だから聞かれても言わない（答えられない）
やっぱりウゾじゃないですかーｗ > スマホアプリの開発経験がないんだね
> だからHTMLで構成されたwebアプリケーションをそのままスマホアプリ化できることをしらない
え？無理だよ 有名な話なのにねー
AirbnbがReact Nativeを諦めてネイティブアプリに方向転換したわけ
https://medium.com/@Roy_S_Kim/airbnb%E3%81%8Creact-native%E3%82%92%E3%82%84%E3%82%81%E3%81%9F%E3%82%8F%E3%81%91-802589f4ff44
うまくいってなかったこと
> JavaScriptCoreがプラットフォームごとに異なるので、
> それを原因とする問題のデバッグが大変。これも一回ハマると相当時間がかかる。
> ほとんどのエンジニアはiOSかアンドロイドのどちらかの環境には詳しいけど、
> 両方を熟知している人は少ない。React Nativeのオープンソースのライブラリは
> そのような人々によって作られている。結果的に安心して使うことはできない。テストも大変。
> 最初にレンダーリングする時にランタイムの初期化に数秒もかかる。
> アプリサイズが大きくなる。
> 複雑なジェスチャーが使えない。
> よくある勘違いはReact Nativeを使うとネイティブコードを書かなくて済むということだが、
> 現実はそうではない。品質のいいアプリを作るにはネイティブコードと
> React Nativeのコードのバランスを慎重に検討する必要がある。
> デバッグをする際にはネイティブコードを深追いしないといけない場合があるので
> ネイティブ開発の知識は必要。また、React Nativeとネイティブのどこをみれば
> いいかを判断することも容易ではない。結果的にエンジニアは全てのプラットフォームと
> React Nativeの知識を学習する必要がある。 まだクロスプラットフォームでできるという
理想を信じてるやつがいるのか？
結局ユーザーインターフェースは各プラットフォームごとに
用意しないとだめだって結論出てるだろ >>896
Airbnbの数倍以上の規模があるFacebookアプリで使われてるからそういうのはどうでもいい 実際にやってる人の言うことは違う
React Native開発のつらい点まとめ
https://mmiyauchi.com/?p=1526
大前提として「React Nativeは、Viewしか扱わないReactがベース」である
ことあるごとに、パッケージを追加していく開発スタイル
WebでのReactのライフサイクルメソッドがネイティブアプリにマッチしているとはいえない
よく使われる定番のパッケージすら安定していない・ハマる
気がついたらGithubのIssueを読んでいる。気がついたらソースの中身を読んでいる。気がついたら1?2年前のStack Overflowをじっくり読んでいる
デバッガの動作が不安定だし、重い
React Nativeで解決できない箇所は、React Nativeが吐き出したネイティヴ向けのコードをメンテナンスすれば良いと思っていたら、難易度高そうで諦めた
コンポーネント志向とか言いながら、オリジナルのコンポーネントの再利用が起きなくて、コンポーネントのメリットをあまり享受できた感じがしない
GUIでUIを編集できるツールがない・これというオンリーワンなIDEがない
アプリケーションのパフォーマンスは各端末上で動作するJavaScriptインタプリタの性能頼み
画面切り替えをすると、表示中コンポーネントがアンマウントされる。新しい画面が出現するとコンポーネントがマウントされる。
画面をアンマウントされなくて良く、バックグラウンドで動作するという選択肢はなく、画面の状態・処理状態を任意に保持・破棄することができない
画面間での情報の受け渡しに非常に弱く、基本的にはReduxなどの外部でstateを管理するシステムを使うことになる
プッシュ通知が公式では最新のv0.45でもiOSしかサポートされていない
総評: React Nativeでは、ネイティブアプリ開発に必要不可欠なものすら公式から提供されていない。
なので、色々とパッケージを盛りまくって、盛ったパッケージの英文資料を読みまくり、
JSXタグを打つのが開発の大半となってしまう。Androidについては気合いでなんとかする >>898
> Airbnbの数倍以上の規模があるFacebookアプリで使われてるからそういうのはどうでもいい
でもお前の会社Facebookよりも遥かに規模小さいじゃんｗ >>895
React Nativeはウェブで使うものじゃないぞ。
それはiOS/Android用だ。
ウェブで使うなら、React Native for Webを使わなければいけない
https://blog.nkzn.info/entry/2018/05/29/210030
> React Native for Webは、React NativeをWebに持ち込む試みです。
>
> ブラウザはGUIアプリケーションプラットフォームではない
> まず前提となっている思想として、 WebブラウザはGUIアプリケーションプラットフォームではない 、
> というものがあります。ブラウザは元々ドキュメントビューアであり、Webページで
> 情報を閲覧するためのソフトウェアであり、アプリケーションのランタイムではなかった、という立場です。
React Native for Web
https://github.com/necolas/react-native-web
↑これみてわかるか？ これは React Nativeの一部ではない ウェブ版があるのに、それをそのまま
アプリにしたって意味がない。
誰もやらないが正解 マルチプラットフォームはやっぱり、Cordova, Haxe に戻った方が良いかも このなかで一番美人なのって真ん中だよね？深キョンレベルだと思うのだが
ちなみに向かって右は目も鼻も整形してるって本人が公言してるけどそれ抜きにして誰が一番美人だと思う？
http://bigsta.net/media/1933567086757747003_3564907098 PWAとかフレームワークなんかで対応するもんじゃないよ
特にSWはアプリごとに調整しないといけないからね
キャッシュ廻りとか本当に難しい
最近色々FW出てるけどまだまだそれに任せっきりにできるレベルじゃない
後はインストールプロンプトとかライフサイクルの面倒もやっぱり
自前で見ないといけないからね そんなもんウェブサイトに必要なの？
どこに使うの？ PWAとRWDはレイヤが丸っきり違う概念だと思うが >>912
それはそうだけど、スマホ対応するには
スマホアプリにするしかないって思いこんでるやつがいるからさ
ウェブサイトをスマホ対応するには、単にRWDにするだけでいいって話
そうすりゃ>>907みたいなウェブサイトには無関係なことに時間を使わなくていい
ウェブサイトをReact化するとこんだけ大変なんだよっていう話さ なるほど。そういうことか。それなら納得だわ。
サイトを無理にウェブアプリ化しても何の意味もない アプリ向けだろ？
ウェブサイトはアプリではないと言ってる ウェブアプリはウェブサイトじゃないなんて
そんなオレオレ定義聞いたことないぞ >>918
お前みたいなやつがいるから馬鹿にされるんだよ ハノイの再帰の中に
ajax建てるプログラムを作ってるんだけど
関数はネストはちゃんとするけどコールバックが機能せず
終了してしまう。どうすればいい インストールできたらアプリっていうのは狭い考えで
Webアプリなどと言うときのアプリって機能性での分類だと思うけどな それはそうだね。だからウェブサイトとウェブアプリは機能が違う
機能が違うからウェブサイトはウェブアプリになりえないわけで
それをインストールさせる意味もない（ブラウザで見れば良い） >>921
たぶん、コールバックは、その外側の関数が終了してから呼ばれる
外側の関数A を実行
callback A を登録
再帰の関数B を実行
callback B を登録
再帰の関数C を実行
callback C を登録
関数C が終了
callback C が呼ばれる
関数B が終了
callback B が呼ばれる
関数A が終了
callback A が呼ばれる >>923
いや、一部かぶってると思うよ
ニュースサイトだったり、Qiitaみたいのだったり、
そのWebサイトで集中して色々見たり、頻繁に閲覧するニーズがあるもの、
言い換えると雑魚サイト以外はインストールさせる意味があると思うよ
インストールと言っても、実際はブックマークみたいなものだもの そのサイトを見れるブラウザコンポーネントのっけてるだけのアプリとかもあるしな >>926
作るのは勝手だが、お前、入れてる？
ただのウェブサイトをアプリにしただけのものを。
入れてないでしょ せやな。ユーザーが作ったデータをアップロードするとかだな。
普通のサイトはせいぜいお問い合わせフォームがあるぐらいやで
お問い合わせアプリでも作るか？ｗ >>931
でも実際、日本の大企業の公式アプリはそんな感じ
トヨタは車種の検索とお問い合わせフォームがあるだけ。
今はもう少しマシになったかも知れないけど >>932
典型的な「間違った使い方」だなｗ
だから誰もそんなアプリいれない。 >>928
入れてるよ
chromestatus.com とか
気になったときにブラウザ立ち上げてブックマークからってのは結構面倒だもの
デスクトップのようにブックマークバーが無いと体験だいぶ違うからね
やっぱりそうだね、「ちょくちょく気になる」サイトはホーム画面に並べる価値があるってことだろうね
地味にオフライン対応ってのにも助かったことがある オフライン対応って実はブラウザでも出来る事なんだけどね
認知度は低いか >>935
認知度云々は関係なくて
PWAにする効果としてブックマーク的な側面はいいとして
ただのブックマークとは違って上で話題になったSWが必須
≒オフライン対応必須って点も意義があることもあるんだよという体験話 で、ほとんどのサイトはオフライン対応とかする意味ない 検索でたまたま訪れただけのサイトとか
キャッシュされても困る
どうせ他のページなんて見ないのに
サイト全体をダウンロードとか無駄に通信量増えるだけ
格安SIMで月3GBに抑えてるって言うのにさ 全体なり部分なり精密な調整が効くのがSWの有用性だと思うんだけど…
なんでほとんどのサイトとやらに固執するのさ
誰も使えなんて言ってないのに 質問してよろしいでしょうか？
onclick属性に関数を設定したい時にその時に引数の中身を渡すにはどうしたらいいんでしょう？
以下例ですが、piyoがある要素を指している状態で
var hoge=1
piyo.onclick=function(){alert(hoge)}
hoge=2
とすると、クリック時には2が表示されてしまうのですが、1を表示させたい、つまり
2行目の実行時点での変数の内容をonclickの命令の中に埋め込んでしまいたいのですが
どうしたらいいのでしょうか… ↑すみません変な文章でした
×onclick属性に関数を設定したい時にその時に引数の中身を渡すにはどうしたらいいんでしょう？
○onclick属性に関数を設定したい時にその時の変数の中身を渡すにはどうしたらいいんでしょう？
です function f(foo)
{
alert(foo);
}
document.getElementsByTagName("html")[0].onclick=f(1);
動かんｗ
無名関数だと楽勝なんだけど、なんか難しいのう >>941
piyo.onclick=function(){var hoge=1; alert(hoge)}
var hoge=2 いまいちやりたいことをわかってないが
こういうことなんだろうか
var hoge = 1
piyo.onclick =(function(a){return function(){alert(a);}})(hoge);
hoge = 2 しかしこれ設計ミスではなかろうか
DOM、特にinputのvalueかなんかをもって気体のでは？ >>943
<span id="hoge1" class="hoge" data-hoge="1"></span>
<span id="hoge2" class="hoge" data-hoge="2"></span>
$('.hoge').on('click', function() {
alert($(this).data('hoge'));
});
もしくは
function f(event) {
alert(event.data.hoge);
}
$('#hoge1').on('click', {hoge: 1}, f);
$('#hoge2').on('click', {hoge: 2}, f); >>947
いやjQueryやと楽勝やけどさ〜
生js難しいねぇ。こんなんもかけないとは、トホホ もうjQueryでいいじゃん
どうせ生jsにしたって長くなるだけなんだから >>945の別バージョン
var hoge = 1;
var makeonclick = (v) => (() => { alert(v); });
piyo.onclick = makeonclick(hoge);
hoge = 2; 生のJS で書くと、保守コスト・人件費が、大幅に上がる
書いたコードの説明も必要だし、ちょっとした事でバグるし ボタンを押したら画面更新せずに特定のUAに変更するってjavascriptで出来る？ >>954
できる
<link href="~css">
を書き換えレバ別のcssを適用できる
が普通こんなことやらんよ >>956
だれも別のcssにするなんて言ってない
ちょっと頭悪い人消えてくれないかな。じゃま みなさんありがとうございます、説明不足でしたが
このルーチンはループの中で実行されるもので、ループの中でhogeの中身は予測不可能に変化するんです
だからhogeの中身が1だと決め打ちするようなやり方はだめでして
あくまでも実行時点でのhogeの中身をDOMに移して埋め込むことが必要です
これから１つずつ試してどれが良かったか検証してきます
ありがとうございます >>943
document.querySelector('html').onclick=_=>(_=>alert(_))(1) だからサンプルリストとしてはこう表現すればよかったですね
var hoge=prompt("入れてー")
piyo.onclick=function(){alert(hoge)}
hoge=2
ではいってきます というわけでやってきましたが>>945でいけました
似たようなことはやっていたのですが。
しかも動いたのは良いのですが未だにどうしてreturnしたり無名関数で二重にくるむと変数を渡せるのか仕組みが分かってません
理屈を説明していただけると有り難いです 理屈は見たまんま
コードをほぐして
１つずつステップを追っていけばいいというか
自分でそれができない人に説明はできない jsは古い仕様と新しい仕様がごっちゃになってるけど人気なんだよな jsは全部オブジェクトで何でもかんでも渡せるっての知っておかないとしんどいかも 人気というよりクライアントサイドだと他にほぼ選択肢がないというね 初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017 >>941
普通に先に待避させればいいんじゃね
var hoge=1
var foo = hoge
piyo.onclick=function(){alert(foo)}
hoge=2 electronと組み合わせるなら
vueとreactどっちがいいの お前がエレクトロンで何をしたいのかもわからんのに答えろとか何様だよ フロントとバックエンドを微妙にどっちもやったことあるんだけどさ
絶対フロントからやった方がいいと思うんだよね
バックエンドやる上で、HTMLのタグや属性が大事になってくるもん
バックを最初やって繋ぎを探すときになんとなくHTML読んでた バックエンドはviewやtemplateはいじりません うっそ、うちのとこはviewはバックもやるんだけど
てかフレームワークでviewの話出てくるし みんなのとこは設計やる？
他のスレ見てるとweb業界は設計書なんて作らないぜーwみたいな人多くて
うちの会社はDB定義と、画面仕様(変数とか何もない)と、流れだけ書いた資料作ってから実装なんだよね
だから自分はプログラミングの実績つんだら設計からやりたいって上司に相談中
戻しがありすぎて効率悪いと思うんだけどな
一流プログラマー()は設計書とかなくても作れるんだろうか 設計というか仕様書とフローね。これは必須
DB定義書は当然あるけど上記次第で決まる
でも覆されるのがこの業界
いかに先方の真の欲求を最初に聞き出せるかがSEの腕の見せどころ
先方の言ってること以上の本当の仕様を聞き出せないと泥沼になるぞ スマホの切り欠きってCSSとかで対応できるけど
フォルダブル端末のサイドに表示できるようになるとかそういう情報知ってる人居る？
PWAのとき限定でも良いんだけど折りたたみ機構とサイドを使ったアイディアがいくつかあって試したい Reduxわかんないんですが死んだ方がいいですか？ reduxはreactの複雑なstateとpropsを使いやすくしたものなのでわからないというほうがおかしい
むしろ簡単になる reactはstateとpropsが複雑
もうReactやめたら良いんじゃないですかね（苦笑） なんでも適当にdispatchすりゃ勝手にstateに入れてくれてそいつをpropsにしてくれる
ついでにreduxのstateはあくまでもreduxのstate
reactのstateとは別扱い
これを区別しないと、なんでdispatchしたのにthis.stateに入らねえんだよ！ってなる
あと配列の更新はreactでは参照しかみてかいから更新されないことが多い
きちんと値の更新まで検索する必要がある
これにはlodashのisEqualを使って値が更新されたかチェックするといい
こういう細やかな管理をしないとreact使うのはきつい
jQueryで1行でdom変更しました！ってのとレベルがまったく違う >>993
わかんないってわかってるなら全然わるくないよ
わかってないのにわかってるつもりのやつよりよっぽどいい わからない理由は、なぜそれが必要なのかがわからないから
つまり、普段の仕事で、必要になってないからわからない。
使うメリットがわからない人は言い換えると
使ってもメリットがないってことだよ
そういう人は使わなくていいと言うか、使わないほうが良いものが作れる reduxなんか投げ捨ててcontext api使えばいいのに。大した規模でもなかろうに。 大した規模じゃないんでReact投げ捨ててHTMLとCSS、それにほんの少しjQuery使うよ + JavaScript の質問用スレッド vol.137 +
http://mevius.5ch.net/test/read.cgi/hp/1546773073/
次スレ立てたからテンプレ追加しといて このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 47日 1時間 23分 16秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
