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