+ JavaScript の質問用スレッド vol.136 +
レス数が950を超えています。1000を超えると書き込みができなくなります。
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」から解離した議論はよそでやること。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。
【条件】期待する回答の条件を書いてください。
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです 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 で書くと、保守コスト・人件費が、大幅に上がる
書いたコードの説明も必要だし、ちょっとした事でバグるし レス数が950を超えています。1000を超えると書き込みができなくなります。
