Vue vs React vs Angular vs Svelte Part.8
レス数が1000を超えています。これ以上書き込みはできません。
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Svelte Part.7
https://mevius.5ch.net/test/read.cgi/tech/1610901677/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。 次スレここでええんか？
Reactのダメなところは
html的なタグ表記が変わってないこと
せっかくフレームワーク化するなら
jade(pug)的な書き方でも良かった angular復活させたのか。
だれか話題にしてやれよｗ Babelでそういう（HTMLタグじゃなくてjadeをReactの関数に変換する）マクロ書いてみれば良いんじゃない？
でも、インデントが意味を持つ構文だとJavaScriptに組み込みにくいし、HTMLとjadeならHTMLの方が断然皆知ってると思うな アンギャー、ブーは名前が悪い
リアクトは名前がイケイケ Reactって開発スピードあんま早くないよな
ConcurretモードとかRecoilとかいつstableになんのよ 俺もとくに不都合なくrecoil使ってる
あまり使い倒してはいないけども 変化が早すぎると言われたり、遅すぎると言われたり。皆それぞれだな！ 初期は早いほうがいいけど、ある程度したらゆっくりでいいよ 頼むからリアクト以外は消滅しろ
入れ代わり激しくてもなんも嬉しくない
安定が最も大事 vueの方が生産性高いんだからreactが滅ぶべき Reactが無くなったら1番困るのはvueだけどな パクリ元がなくなったらバブル後の日本みたいに停滞するだろうなｗ もしかしてVueでもHooksみたいなの搭載されたりしたの？ 結局のところvueとreactの技術的な違いはテンプレートvsJSX(TSX)で、テンプレート方式の方が優れてるんだからもうvueの圧倒的な勝ちってことでいいか？
vueで大きいものを作るとぐちゃぐちゃになるとかは迷信やろ？ 結局はhtmlの中にjsを書きたいかjsの中にhtmlを書きたいかの違い それはみんなわかってる
どっちが優ってるか決めようぜ フロントエンドの大規模開発はReactが適してるとか言われてるけど、
趣味だしフロントエンドで大規模とか意味わからんし読みづらいしVue使ってる classコンポーネントが主流だった頃はReactも劣勢だった感があったけどHooks実装されてアロー関数コンポーネントが主流なってからは
一気に差を付けてReactが優勢になったと思う > アロー関数コンポーネントが主流なってからは
> 一気に差を付けてReactが優勢になったと思う
それはあるね
vueもパクって似たようなことするんじゃなくて、別方向に進化したら面白かったのに
再利用はコンポーネント単位でやるんだぞ！的な何かを コンポーネントのデザインの仕方と覚えるというか慣れはかなり必要
昔自分が書いたコードとか見たら相当非効率なコードを沢山書いてたと気付く vueってangularの必要なところだけ抜き出そうで始まったはずなのに
最低限必要なものを付け足し続けた結果劣化angularになってる気がする 劣化Angular かつ 劣化React ってなかなかやるな 新しく作り直す！ってプロジェクトは大体そんな感じになるわ >>30
がんばれよ！
俺も使ってるけどAngularは堅牢で良いフレームワークだよ
前評判で身構えるけどすぐ慣れるし難しくない 元々ビルド不要のJavaScriptに
ビルドとという概念とかサーバサイドのコマンド必須というゴミ
要素を追加したリアクトはゴミもいいところ
ネイティブのJSこそ至高
ビルド型の言語とか、わざわざクラスみたいなもの作らなきゃいけなかったり
開発環境の構築から面倒な言語とかそういうの大嫌いだわ >>39
考え方が違うんだよ
その頭じゃ理解出来ないのだろうけど ビルドは少なくともAngularJSの時点で既にあったよね
勝手にリアクトの手柄にするなよ npm run watch
さえやってればビルドの煩わしさなんて皆無なのにね Ruby, Elixir の偽は、false, nil だけだから、型なしでもバグらない
一方、他の言語では、各型に偽があるから、
型なしでは、バグの可能性が高すぎる
偽が10個以上あるから、組み合わせ爆発が起こる。
空文字列、空配列・空辞書、0・0.0 など
それで、TypeScript・コンパイルが必須。
一方、Ruby, Elixir は、型なしでもバグらない サッカー競技中に空からパラシュートで緊急着陸して来るような頓珍漢レス Rubyガイジと呼ばれてる、いろんな板で四六時中おんなじことしてる有名な糖質だよ。 ActiveSupportのpresent?/blank?は害悪認定と >>44
お前は馬鹿だ
ビルド言語か糞なのは
ビルド自体だけでなく
ビルド環境を構築すること自体が糞
だと言ってるんだ。
自動化すれば関係ないって話じゃないんだよ。
ビルド言語は ちょっとしたコーディングをコピペして
試すのにも、環境構築が面倒で糞だと言ってるんだ
フロントサイドの言語で本来ブラウザだけで
動作するはずのものを
いちいちサーバに入って試さなきゃなならなくしてるのが
糞だと言ってるんだ。
動作環境のサーバが複数あったら
同じ数だけ環境構築が面倒なんだよ
だからjavaやgoやReactみたいなのは全部糞だと言ってるんだ
ネイティブのJavaScriptこそ至高で
次にPythonが優れた言語だ
RubyはPythonの劣化版みたいなものだから
どーでもいいわ RailsやLaravelならバックエンドの開発環境でそのままできるよ >>50
テキストファイルコピべしてnpm installするだけが面倒くさい？ 山浦清透、1/15
Docker超入門講座 合併版 | ゼロから実践する4時間のフルコース
www.youtube.com/watch?v=lZD1MIHwMBY
Windows 10 Home 版, WSL2, Ubuntu 20.04 LTS,
Docker Compose, VSCode, Heroku, Ruby on Rails, Git, CI/CD, CircleCI
YouTube で有名な、雑食系エンジニア・KENTA のサロンでも、
初心者用コースに、CircleCIも入っている
最近は誰でも、Docker出来るから、
さらに、AWS Fargate, Terraform, React, Vue.js, TypeScript も入ってきた
だから、AWSのくろかわこうへいのサロンにも、入る必要がある。
今では、1年の未経験者が、10年以上のプロよりも技術力が上になってる！ vueはbootstrap-vueがどうやらメンテ止まりつつあるようでvue3が出て結構経つのにvue3のサポートの実装がまだかなりかかりそう
現状maintenerは１人しかいないようだ
vue/compatを使えばvue3でも動くっていう投稿もあるけど正直これならReactのほうがいい気がする
https://github.com/bootstrap-vue/bootstrap-vue/issues/5196 Vueが悪いんじゃなくてVueでがっちりしたものを作ろうとする奴が悪いんだと思うわ
この程度ならts使う必要もないかってものをサクっと作るなら確かに楽 正直reactやvueみたいなフレームワーク自体は
自分では使いたくない
reactやvueで構築済みの汎用的なUIパーツだけくれや
jquery UIやbootstrapみたいな奴な >>59
技術力あるところは各部分を機能別にパーツ化して使い分けしてるね
next/nuxt相当の部分もさらに機能別ごとにパーツ化
一方で技術力ないところはreact/nextやvue/nuxtを使ってる 質問いいでしょうか？
npm run して http://localhost:3000/ を開いた場合と、
work/myapp1/build/index.html を直接ブラウザのアドレスバーに
貼り付けた場合で結果が異なるのってなぜでしょうか？ >>63
1ヶ月前にAngular始めた俺がエスパーで回答
index.html開いた後、実行に必要なJS等をサーバに問い合わせてダウンロードする仕組みになってるので
裏でWebサーバが動いていないといけない。
npm runはnode.jsが裏で動いてWebサーバの代わりをしてくれるが
index.html直実行はこれらがいないため挙動が異なる URL が file:/// になるくらいで相対 URL で見にいかないか
js の URL が http://localhost:3000/ になるわけじゃないっしょ 最近のブラウザでfileスキームだとクロスオリジンに引っかかるんじゃないの VSCode の拡張機能、open in browser では、ローカルファイル・アクセスだから、CORS 制限あり
file:///C:/Users/Owner/Documents/test.htm
一方、Live Server では、サーバーを立てているから、CORS にならない
http://127.0.0.1:5500/test.htm
同様に、コマンドプロンプト・PowerShell から、
1-liner で、Ruby で作られた遅いウェブサーバー、WEBrick を起動すると、
ruby -run -e httpd . -p 8080
これも、サーバー経由だから、CORS にならない
http://localhost:8080/test.htm
Ruby on Rails では、Node.js のwebpack-dev-server を使っている たにぐちまこと、7/1
Next.js超入門 セットアップから Vercelへの公開まで
https://www.youtube.com/watch?v=YoIQ_FIBlYY
1時間13分の動画 vueのフロントエンド以外って何が良いの？何が便利？ お断りします
ハハ
(ﾟωﾟ)
／ ＼
((⊂ ) ﾉ＼つ))
(＿⌒ヽ
ヽ ﾍ |
εﾆ三 ﾉノ Ｊ >>75
『MVCはオワコン! RESTはダメ! 時代はSPA!!』の末路
ttps://www.youtube.com/watch?v=gd2lMIPUSBU&t=1020s >>77
なんじゃ？
この滅茶苦茶な理論まがいの話しは？ めちゃくちゃだな
MVC→SPA
は進化の道筋として判らんでもないが
RESTを間に挟む理由が全く無い >>79
いやいやSPAでMVC使ってもいいと思うけど リンゴはダメ！コタツよりダイソン！
みたいな話だからな。訳が分からん ほとんどのSPAがREST頼ってるのにRESTがオワコンになる意味が分からない 最近はSSRやSSGじゃないの？
うちはいち早くServerSideGaichuを取り入れて時代の最先端技術を進んでいる vue(Laravel上)でsass-loaderのバージョンに起因してそうなエラーにハマった
なんとかなったけど、ある程度長い目で使いたくても難しいかなあ >>86
SSRからSSGヘ
ttps://www.youtube.com/watch?v=3VMCYRTLMOo&t=471s Next.js超入門 セットアップから Vercelへの公開まで
www.youtube.com/watch?v=YoIQ_FIBlYY >>88
いやいや今はSSGの次、ISRだよ
なんて言うのは簡単なんだけど、どうも胡散臭さが抜けないね
なんかひと昔のフレームワーク乱立時代の感覚と似てる
シンプルなものをシンプルに作りたいだけなのにって 技術的には延長線上にあるから、そこまでの乱立感はないかな むしろSSRしかしない昔からの遅く不便なサイトや
CSRしかしない最初の表示が遅くて重いダメなサイトが
どちらも時代遅れでかつ利用者の体感悪すぎなことに気付かず大量に残っている現状を SPAで構築するようなサイトはアプリのような動きを期待しているのに
SEOガーとかそもそも話が合っていないんだよね
企業サイトみたいなのを無理やりSPAにするのがそもそもの間違い 俺の仕事だとガチのアプリ開発だから、
SSRとかSSGとか全く興味がない。
そもそもinstall以外でサーバー使わん。 そらもうCやRustで書いた超高速ネイティブアプリやろなあ >>95
サーバーはサービスAPIだけだよ
UI要素はゼロだ サーバは使わないけどAPIは使います。
日本語へのコンパイルエラーが出てるんだけど。 SaaSとかのサードパーティ製のAPI使うって意味じゃねえの？
サーバーレスというワードと同じで、自分で管理するサーバーは持たないってだけなんだろ、多分 >>93
それは違う
SPA/PWAにするのはユーザーの体感向上と通信減少とサーバー負荷減少など総合的な目的がある
企業サイトでも何でもその目的で有利となる
企業に限らず検索によるトップページやそれ以外の途中ページ流入も欲しいのは当たり前
そしてSSRはSEOのためだけでなくユーザーの体感向上が第一だ YouTube で有名な、雑食系エンジニア・KENTA のサロンの初心者用コースが、
Ruby on Rails, Linux, Docker Compose, Node.js(Webpack, Babel), Bootstrap
VSCode(Remote Container, WSL2 ならRemote WSL), Heroku, CircleCI、データベース
今までは、Docker Compose までが初心者用コースだったが、
最近は誰でも、Docker出来るから、
AWS Fargate, Terraform, React, Vue.js, TypeScript が加わった
EC2 ではなく、サーバーを管理しない・サーバーレスのFargate。
他にも、AWS サーバーレスのLambda, Aurora, Elastic Beanstalk など
だから、AWSのくろかわこうへいのサロンにも、入る必要がある。
今では、1年の未経験者が、10年以上のプロよりも技術力が上になってる！ >>101
宣伝お疲れ
未経験が見てると思えないけどこれを浅く覚えても意味ないからな
フロントもバックも浅い知識しか持たない奴なんてお荷物でしかないから所詮インフラ要員止まりだろうしでしさっさとAWS一択に絞ったほうがいいよ クラウドは正直Firebaseしか理解してない。青天井怖いもん。
VPSはわかるけど、フロント向開発者向けのナウでヤングなクラウドでは無いだろうし…… 仕事なら別に金払うの俺じゃないし客からの指定が無い限りは99%AWSだよ
個人でAWSは確かに高くつくかもしれないが今はAWSでもLightSailやら
安いサービスはあるし、小規模なら十分安く抑えられそう Fastly、Compute@Edge の JavaScript 対応を発表
https://www.fastly.com/jp/press/press-releases/fastly-launches-new-era-of-highly-secure-serverless-javascript-with-zero
>Fastly は、セキュリティを考慮し、WebAssembly でコンパイルされた JavaScript から個々のリクエストに対してサンドボックスを生成または破棄する、独自の高セキュリティな分離技術を開発しました。
米国 RedMonk 社のアナリスト兼共同設立者である James Governor 氏は次のように述べています。"JavaScript は、最も人気のあるプログラミング言語で、普及が進んでいます。サーバーレス・プラットフォームは、新しい JavaScript のワークロードにとって自然な環境です。一方、パフォーマンスとセキュリティは依然として重要な懸念であり、速度は何よりも重要な要素となっています。攻撃対象が減り、コールドスタートがなくなることは、最先端の Web 開発者にとって非常に魅力的です。"
Fastly は Compute@Edge の開発者の体験向上に注力しており、最近ローカルテスト環境の提供開始を発表しました。これにより、開発者は本番レベルと同様の環境でテストコードを実行し、サーバーレス コンピューティング環境でスケールとパフォーマンスを追求しながら、問題の発見と修正を迅速に行うことができます。 企業が求めているのは、バックエンド技術者。
Rails, Linux, Docker, AWS、データベース
だから、AWSのくろかわこうへいのサロンにも、入る必要がある。
AWS Solution Architect 資格とか、この本を読むとか
Amazon Web Services パターン別構築・運用ガイド 改訂第2版、2018
サーバー構築運用は難しいから、Amazon はサーバーを管理しない・サーバーレスを勧めている。
EC2 ではなく、Fargate, Lambda, Elastic Beanstalk など
Amazon Linux, Aurora も管理不要。
Amazonがセキュリティー更新してくれる
>>102
KENTA は基本、マナブ・マコなりなどの高額学校などに噛みつく
>>101
の内容は、80万円も払わなくても勉強できると言うこと。
今は、200万円の学校をぼったくりと言ったから、業務妨害で訴えられている
KENTAのサロンは、日本6位の2千人も入っているから、
売名目的で、高額学校がKENTAを訴えてくる 古い技術者だから技術ってのは本と公式ドキュメント、時々現場で学ぶものだと思ってる。オンライン勉強会に参加することもあるけど、あれは知見を広げるってだけで身に付く勉強じゃねーわな 本は古い遅い検索できない
どの言語もどのフレームワークも公式サイトがベスト
金を払うのはバカ え、TypeScriptの本とか買わない？ マジ？ なるほど、おまいらと差をつけるには本を読めば良いんだな！ 本は有用だよ
だけど悲しいことに、日本語で最近のweb界隈のナウい本をあまり見ない
ハロワから毛のはえたくらいのしかコード載ってないしね
昔からある言語やアーキとかSQLあたりとかなら本もいいと
まあ結局コードをgithubあたりからDLするってなるしね。。 確かに素人ぐらいしか釣れなさそうな公式マニュアルをかなり簡略化したような本は多いかも。出版社と題名見ればだいたいわかるけど。
言語とかHTTPとかRESTみたく歴史があって基盤になってるようなものは本に頼るなぁ。
スレタイにあるようなものは公式マニュアル頼り やっと明日vuexとかいうゴミから解放される
しばらくフロントはいいやｗ
ところで、意識高い系の人は何に困ってあんなゴミ作ったの？ｗ reactは今の状態でもう完成形なの？
さらに改善されそうな部分ってあるの？ RecoilはHooksに最適化されてるから遥かに使いやすいよな ReactはHooksもあるしコマンド一発で環境作れるようになったし、
Vueは応援してたけどなんか迷走してるみたいだし
毛嫌いしてたけどなんかもうReact覚えればいいっぽいね React.js Examplesってところで部品漁りするのが結構楽しい オライリーのReactハンズオンラーニングって買う価値ある？
すでに大規模ECサイト作れるくらいの実力はあるが お、なんか良さげな本じゃん。いい事聞いたわ、サンキュ！ と思って目次読んだけど……これは……2年前に読みたかった内容だな タイトルの4つでそこそこ踏み込んでてナウい本ある？ オライリーの本ってどれも初心者向けではないイメージ
全部読んだわけじゃないから個人的なイメージでしかないけど
めっちゃぶ厚かったりするからねえ オライリーの本はかなり信用できる。半端な本を5冊買うより価値がある。リファレンスとして手元においておきたい。
もちろん変化の速い分野だと陳腐化はあるけど、それは本という媒体の問題であってオライリーの問題ではないしね。 どれ使うかは好みだけど、Vueが迷走したのでデファクトがReactから揺らぐことはないのでは フロントWASM化するまでReactのままのような気がしてる。 基礎から学ぶ Vue.js、mio、2018/5
React の古い本では、Stoyan Stefanov の、2015, 2017 の本がある WEB+DB PRESS総集編[Vol.1~120] (WEB+DB PRESSプラスシリーズ)
￥2,970
>年6冊を発行し続け,読者の皆様に支えられて20年を迎えた『WEB+DB PRESS』。本書はご好評いただいた節目のVol.120を含む「20年分の記事PDF」をまとめた総集編です。
付属DVD(+パスコードでのデータダウンロードも可能)にはVol.1~120のPDFに加え,総集編第1弾~第6弾に掲載された書き下ろし記事のPDFも一挙収録。 オライリーに求める様な事は公式リファレンス見ればいいからオライリーってあんまアドバンテージない気がする アーキテクチャとかそういうレイヤーの本なら読む価値はあるけど、言語詳細とかは
今はもう本じゃ追いつかんだろ。 Angularで
const user = { ...this.user, status }
のような宣言がありますが、このthis.userの前にある3つのコンマってどういう意味でしょう？ 失礼、自己解決
AngularでもTypescriptでもなくJavascriptの構文でした >>139
restはあるあるやな
他言語から来た当初は俺も分からんかったわ >>140
似ていますがrestではありません
spreadと言います
たまたま同じ...を用いますが明白に区別されています ...みたいな記号は、ググラビリティーが悪いから調べにくいんだよ。
そのような書き方は結局ネットだけでは分からずじまいになってしまうことも多い。
本だとまとまって書いてあるから読んでいるうちに出てくることがあるが。 >>142
どのプログラミング言語でも同じですが公式ページが最も良いです
正しい最新の情報がまとまって載っています
本では情報の不足があったり古かったりありえます
今回ならばJavaScriptの演算子なので
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators
ここを見ると演算子の一覧が載っています
...objは展開記法(スプレッド記法)として詳細ページへのリンクがありますね >>143
いや、だから...がJavaScriptの文法だっていうことすら分からないのよ。
特に今までバックエンド専門で急遽フロントエンドやれとか言われた場合、
Javascriptとか触ったこと無い状態でAngularとかVueとか始めるわけよ。
もうググりまくるしか無いわけだが、上で言われている通り記号演算子は検索しにくい >Javascriptとか触ったこと無い状態でAngularとかVueとか
無茶しやがって… >>144
AngularもVueもReactもプログラミング言語部分は全てJavaScript(またはその拡張のTypeScript)です
まずはJavaScriptを一通り勉強しましょう
プログラムコードでわからないことがあったら先程のようにJavaScriptの公式に情報が一番まとまって載っています ＞const user = { ...this.user, status }
何気に二つ目のも新しい省略記法なんだよね。 GoogleChromeのUserAgentが段階的に廃止になる件について、Angularへの影響を確認したいです。
AngularライブラリでもUserAgentを使用していると思われるのですが、影響内容は公開されているかわかりますでしょうか。 今どきUserAgentなんか気にしてるのは
お前ぐらいなもんだろ バックエンドでも、Ruby on Rails では、
jQuery, Node.js, Webpack, Babel, React, Vue.js, Bootstrap も、知っているのが常識だけど >>152
Rubyは不要
JavaScriptだけで完結できる サーバーサイドだとORMで何度も型を書くのが面倒くさいのだけど、Prisma2とやらを使えば幸せになれる？ なんでRubyガイジだと一秒でわかってしまう文章なんだろうか jsxをきもいと思うのはエンジニアの本能だよね
jQueryの用に近い将来、技術的負債化しそう jQueryはいうてもJavascriptやHTMLとしてvalidだったんよ。
Vueもそういう使い方もできる。
(俺はそういう風に良いjQueryとして使うこともある位)
Reactは無理だからな。
jsxはコンパイラが絶対に必要という所が異常。 そもそも今の時代は生のJavascriptよりTypescriptを使うのが主流だからコンパイラ云々は気にしなくなった 標準のWeb Componentsだけで困る事が分からない、技術的に分断が起きてる気がする
もちろんVueなどは親和性があるが・・・ 標準のWebComponents使いにくいんだよね。あとリアクティブだと状態管理が単純化して設計難度とバグが減るのが大きい JSXはやったことない人からみたらガバガバに見えるかもしれないけど実際に使ったらめちゃくちゃ厳格で
逆にガバイ書き方してるhtmlが許せなくなるよね >>162
書けるのとそれが普通なのは別では？
特に関数コンポーネントとhooksが主流になってからは、もはやほぼ不可能だと思ってる。 JSXといううんこをひねり出さなければいけなかった理由が知りたい
それを知ればReactが気に入るかもしれない >>168
実際に書いてみたら分かると思うよ
JavaScriptの中にタグが書けるからと言って何でもかんでも許されるわけじゃないから
結構ロジカルな作りになってる あくまでもマクロなんだから普通に書けるし、長くなるのが嫌ならエイリアス関数作って書けばいいだけなわけで…… むしろJSXは自由に書けない（分岐とか）のが使いづらさだという印象。
でもこの話題がいつも不思議で、JSXに嫌なところがあったとて、結論Reactでしょ
なんで敢えてVue? React以降をしてるプロジェクトをよく聞くし、Vueがいいというのは単にサンクコストじゃないの
日本はVueのがひろまってたから、つまりざっくり言って国内業界全体として技術選定ミスったんでしょ ちょっとreactはじめてみようとおもってドキュメントの最初の
hello world表示するだけのコードを開いてみたのですがレスポンスが悪くて勉強するか悩んでます
https://raw.githubusercontent.com/reactjs/reactjs.org/master/static/html/single-file-example.html
reactで作ったものはどうしてもレスポンスが悪くなってしまうのでしょうか？
JSXを使わなければ少しはまともになるのでしょうか？ そのソースにコメントで書いてある通り、その使い方では遅いんだよ。
とりあえずnpmでcreate-react-appしてからレスポンスを語れ reactってフォームが糞だったが
今はましになったかな フォーム用のReactライブラリ使うとすげー楽だぞ >>173
ありがとうございます。コメント見てませんでした。
コンパイル的な作業が必要になるんですね。
10年ぶりぐらいにWebやっていて、npmは使ったことがなく、
まだnpmのくだりはでてきてないので読みすすめて行こうと思います。 >>172
最初の読込みに時間が掛かるのは仕方ないと割りきらなきゃいかんが
ちゃんと作れば初回ロード以外のページ遷移は軽くできる
あとプロダクションビルドすれば初回ロードも多少速くなる レンダリング前の画面が一瞬チラッとするのがムカつく事はあるけど、初回含め遅いと思ったこと無いなぁ。 Vueが使い込むと辛いことになるとか言われ始めてるけど
そんなん言い出したらWeb技術全般がつr(ry Reactは慣れてきたらコンポーネント定義が楽しくなってくる >>180
3年前からAngular使ってるが、破壊的な変更や
根本的な概念の更新がほぼ無いので安心してる
一番辛いのが流行り廃りに翻弄される事だしな
もちろんマイナーだし今後は分からんけど
一つの意見として聞いてくれれば Reactのが長いことやるのにいいと思うよ
Vue使ってる会社は、騙されたと思って書き換えた方がいい
したら意味わかる
メンバーも喜ぶ 破壊的な変更で人がゴッソリ減ったのがAngularなんだが version5以降くらいからの話じゃない？知らんけど ずっとAurelia使ってるけど情報が少ないことと2が出るまでバグが放置されてること以外は辛くないな そりゃ辛そうだな…
金と女に縁がないこと以外は幸せ、みたいなｗ 人の気持ちが分からなくてすぐ手が出ちゃうだけで根はいい子 Material-UIがいつの間にかv5になってた
スタイルが書きやすくなってるね Webpackがわからんレベルならそこからまとまってて最近充実してきた書籍を買う。そうでなければ、公式のドキュメントを読む。そして何か（ベタにToDoアプリとか）作ってみる。
クラスコンポーネントで解析してるようなものは慣れるまで避けろ Webpackって分かりにくいけど
今後も生き残るものなのだろうか？ 仮にWebpackが死んでも似たような物に変わるだけじゃね？
ECMAのimportだけじゃminifyできないし Webpackは出来るだけいじらないようにして
Webpackの時代が終わるのを待ってるかんじ
必要なら当日するけど
其処まで踏ん切りつかん状況 似たような後続はあるにはあるが大幅に良くなることは無いしなぁ
nodejs自体から変わらないと革新的なものはでなさそう Webpackは設定ファイル書き書きするだけでそんなに難しくない。ただバージョンアップで苦しむこともあるし、0からReactと並行して始めると辛いので本の導線があると楽かなって思う。 押しつけの難解な設定より
普通のコードで設定書くほうが良いんだけどな
そんなのなかったっけ？ 押しつけじゃない簡単な設定ならもっと良いんじゃない？ 今の主流ってzero-configだしな
あとコンフィグなんて基本は使い回しよ
webpackがrollupがesbuildがーって頭悩ましてる記事とか見掛けるけど
そのあたりのファイルを現場で直に触ることなんてほとんどない そうか？
ターゲットとか指定したいし、ライブラリ入れたら弄らないと駄目なこともあるくね？ >>205
そういう場合も特定の人だけが触るからな
ざっくりと何をしているのかが分かっていれば十分よ
ターゲットやバージョンもほぼ固定だし
弄らないとダメなライブラリはよっぽどの理由がない限りは選定されない
個人やフリーランス、めちゃくちゃ裁量権のある立場は知らん LaravelMix使うとwebpackの設定は割と簡単に書けるからオヌヌメ >>206
ざっくり理解すれば十分ってのは同意。よほど踏み込まない限りWebpackも難しいものでない Laravel使う現場って実在するのかよ
プログラミング教室でしか使わんだろと思ってたわ ParcelでWebpack要らなくなるとか言われてたけど結局こんなもんだな。 laravelは割と主流派だぞ。
laravelmixは信者しか使っていないと思うが。 ホームページ屋さんが頑張って使ってるミドルウェアな印象 おまえらPage Insightの結果はどのぐらい当てにしてる？
SPAは評価悪くなるよな
評価上げるためにリファクタリングするのに疲れちゃったよ >>214
SSRとハイドレーションやろう
サイトによるがそもそも気にしないという選択肢は十分あり CSRだけだとページ表示ユーザ体感が悪すぎるしSEOも不利なので一般向け情報ページならば
SSR/SSG＋プログレッシブリハイドレーションが良いでしょう 規模によるとしか
旧来のサーバーサイドのルーティングで十数ページに渡るような内容をSPAにしてCSRにした場合等はえらいことに
まあ継ぎ足しロードとかにするんだろうけど そこまでするならそもそもSPAという選択が間違ってるような
よくあるコーポレートサイトやブログってSEO命なのにそれを犠牲にするってのは本末転倒 それはそう
コーポレートサイトやブログのようにほとんど変化ない情報が掲示されるようなサイトはSPAの恩恵はほとんど受けられず悪い影響は被っていいとこない
向き不向きあるとは前から言われてたのに人は金づち持てば全部釘に見えるようで… 逆にログインして操作する業務システムでSSRはあんまり意味無いと思うんだがやりたがる人結構居る、 単純にSEOとページインサイトを考慮するならspaじゃなくて静的ページジェネレーターがベストだろうね
動的サイトとの間をとってgatsbyとかで自動化するのが今風な感じする >>221
逆にSPAを知らないんだろうね
何ができるか
なぜSPAなのかを Nuxtはじめた＾＾
なんか注意事項とかあったらレスくださいね＾＾ >>222
Gatsbyやってみたけどなんか…
電球一個取り替えるのに椅子に乗ってその椅子を４人で回すみたいな大ごとになってなんだかなぁと思ったわ
それほんとにGraphQL介す必要あるの？とか 草
俺はなんかしっくり来ないなと思ってNextに行った。まぁ最終的には同じような事するわけだが react周りserver componentsだっけ？
なんかそういう頑張って良いとこどりしようとしてるけど、
開発者が追いきれてない感じがして混迷しつつあるように見える
やりたいこととやり方はわかるけど、結局自分らがどう選択していくの？がまとめずらい
選択肢が無尽蔵に増えそうで二の足を踏み続けそう ○ 俺が追いきれてないので気に入らない
○ やりたいこともやり方も分からない
○ 俺が二の足を踏み続けている >>229
マジか、みんな迷わず選択できてんのか。。 素直にVueやっとけばいいのにな
対して難しい事しなくてもやりたい事は大抵出来るし
新参にも教えやすい そういう用途だとSvelteの方がよくね？
と思ったけど、情報とか使える人が少ないかな？ 結局全部試すくらいの覚悟がないならフロントフレームワークなんて使うべきじゃないと思うよ 今はある程度選択肢は固まってるし
まあReactで、と言えるだけ随分楽になったよ
ただ、根底にある思想みたいなのは
スレタイにあるvue,react,angulaのどれも共通部分が多いよ
実装が違うだけで結局やることはそう変わらん 個人的にはApollo clientでの状態管理が一推し SPAでもそんな複雑な管理をクライアントでやったりするのかなぁ SPAではせざるを得ないってとこだよね
本来は誰もやりたくない ただ小規模なサイトであっても何かしらのフレームワーク使う事が大前提になった。以前のもメンテはするが JWTやマイクロサービスを踏まえるとクライアントで状態を持つのが前提になってきてるもんね
クライアントでの状態管理は必須 Reduxは最近出ているReactの技術書では全く取り上げられなくなったな 狂信者はいるけどみんな大嫌いだったもんな
Context APIで全部解決出来れば楽なんだけどね
選択できる自由があって贅沢な悩みではあるけど useCentextよりもRecoidの方が明解でいいと思うけどな このへんはredux一強から戦国時代に入った感じかな。大勢が決まるまでは情報収集しつつ様子見。 このままrecoil一強になってreduxの息の根止めた方が世界の為
Reduxのあれをするにはあれやこれやが追加で必要でもっと勉強して下さいとかニートじゃないと対応出来ないって Reactの入門ググったら未だにRedux Toolkitとか勧めてる輩いるもんな ReactってTypescriptじゃないと人権ないの？ typescriptはjavascriptに吸収されるんじゃね 使ってない、RESTで事足りてしまう。
いつかGraphQLがバシッとマッチする用途でシステム組んでみたい RESTの倍ぐらいSQLクエリ走るの見ると使う理由あるのかな？って思っちゃう
リクエストは減るんだろうけど
プロジェクトによるんかね 聞いてるとRDBと相性悪そうだね
ドキュメント型DBならどう？ GraphQLの好き勝手なクエリに対応するのはドキュメント型じゃかえって厳しいだろ。 カラム指向DBって最適化の方向が違うだけでデータモデル的にはRDBと変わらんじゃん。 >>257
TypeScriptの型は少量で滅茶苦茶雄弁なコメントみたいなもの。おかげで新しいライブラリもサクサク使えるし、バグに震えることなく安眠できる。 >>263
どれも一長一短
テーブル結合ではなく複数のサービスからのレスポンスをjoinする目的の物だからどんなデータベース使おうが総クエリ数は増える
ただマイクロサービスには最適だしフロントエンド開発も楽
GraphQLに合わせるんじゃなくて各サービスに合わせたデータベースの選択が最適解じゃないかと >>268
どこで妥協するかだけの話
普通の強い静的型付け言語をしてきた人たちから見ればTypeScriptはヌルくて甘いとなるし
型なし言語をしてきた人たちから見ればTypeScriptは面倒くさい
公平に見ればTypeScriptは中途半端な妥協の産物 >>269
あとは更新よりも読み出しが多いケースならば
読み出し毎に各DB各サービスに問い合わせるよりも
読み出しに合わせた複合DBを保持してそこも常に更新維持するなど
無駄なクエリを減らして高速化の方向もありますね TypescriptはAltJSとして生まれたもの
実際JSより格段に安全に組みやすくなったしそれで十分
TSが選べる環境ならJSを使う理由は一切ない
生のCSS組んでる奴なんてとっくに全滅してるやろ >>273
Wasm上でのフレームワークも進化していてJavaScriptを使わずにフロントエンドが組める時代になりつつあるので
中途半端な立ち位置のTypeScriptをいずれ使わなくなるかもね というか他の言語使おうが結局DOMを触る必要があって、余程上手にラップしないとJS的なフワフワ世界に突っ込む上にオーバーヘッドが出る。それなら最初からTS|JSでええやんってなる（なってきた）。
今後のことはわかんないけどね wasm自体が未完成だから未来の覇権は誰にも読めない
それこそTS→wasmが可能になってるかも知れんし TS使っても現状anyだらけで、意味あるんかいなって思う >>278
そうはならんやろ……。たまにas使ったりはするけど >>275
既にWasmだけで完結できるようになっている
JavaScript部分はWasm呼び出す固定コード
>>276
もちろんDOM操作のみだとVanilla (生JavaScript)がWasmより速い
ところがDOM操作以外の処理が多いと逆転してしまいWasmが速い
さらにVanillaではなく仮想DOM系フレームワーク(ReactやVueなど)と比べると実DOM操作以外の処理が多いためWasmが圧勝になっている ベンチ
https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html
を見ると素のJSが一番速い
ついでなんだかよく分からんフレームワークを2つ挟んで、
solidっていう非vDOM系のJSフレームワーク、
ついでやっとwasm-bindgen
wasm-bindgenってのはRustでwasmやる基礎ライブラリだからフレームワークまで行かない（素で使うのはキツイ）
Rustスレでドヤ顔で貼られてたdominatorってフレームワークはそれよりずーっと右（遅い）
DOMのAPIがwasm側に提供されてない現状でUIフレームワークにwasmベースのものを選ぶのはバカのすること
DOMの関わらない演算ヘビーな処理に特出しでwasmモジュールを使う、といったやり方が当面は賢いだろう >>282
ありがとう。
しかしえらいプリミティブな内容だな。
並んでるフレームワークも機能がバラバラ過ぎてWasmが速いとは一概に言えないよ……。
てか普通にVanillaが最速じゃないか >>282
Reactがあまりにも遅すぎなんだな
しかしそれでもReactがこれだけ使われてるということはDOM操作の速さは気にしなくて良いってことか
つまりWasmでも全く問題ないという結論になってしまうな >>286
いや、ベンチマークテストの内容見ればわかるけど、Reactでそんな処理しないだろみたいな内容あるよ。苦手な処理がいくつか刺さった感じ。コードの小ささに降ったPreactより結果が悪い事からもそれが読み取れる。
遅いWasmで問題無いという結論の持って行き方もちょっと筋道立ってないように感じる。 どういうDOM操作を行うかあらかじめわかっているならよけいなオーバーヘッドがないvanillaが速いのが道理だけど
このベンチマーク自体はどういう意味があるんかね。 >>287
なるほど
Wasmで問題ないと思ったのはそのReactの件だけでなくて
素のJSであるVanillaとWasmの差がわずか6%しかない点も含めてそう思った
DOM操作のオーバーヘッドがあるからWasmは使えないという意見が嘘だと分かったことが大きい そうなんだよ
DOMの操作でのWasmの不利は誤差範囲
もちろん歴史の深さの差があるから今すぐではないけれどTypeScriptの天下は長く続かない可能性大 wasm使ったWebアプリが未だに実用的に見たことがないんだが バニラJSはえぇえ
やっぱ最強のフレームワークやな >>289
あぁそうか、Wasmに速度を求めるわけでなくてオーバーヘッド食ってでもJS|TS以外の言語で使いたいって視点なら、それはそうか。
まぁでも、まだまだこれからだね。
現状では他の言語使うモチベーションがフルスタックフレームワークぐらいしか無さそう。 >>294
SSR/SSGをCSRと同一コードでDOM生成(HTML生成)させる言語も
JavaScript/TypeScriptよりRust等の方が圧倒的に速くてサーバーコストも下がりそうね
もちろん強力な静的型付け言語を使えて今よりさらに開発効率と質も上がるメリットもあるけれど 流石にRustでWeb系を書きたくないなぁ（パフォーマンスが求められる局所なら良いけど）。平衡して考えなきゃいけないレイヤーが増えすぎる。
静的型付け言語のメリットはTSで十分補えてるから俺は要らないかな。 c#でいいじゃん
VS使えばアホみたいに簡単に作れる 流石にC#で作るとオーバーヘッドが半端ない事になるなぁ .NET, Web, Flash...!!
Silverlightは死んだんだ
いくら呼んでも帰っては来ないんだ
もうあの時間は終わって、
君も人生と向き合う時なんだ Silverlightは死んでもいいけど光るちゃんは残して ブラウザ自体が根本的に変化しないとこれ以上は無理やろ
結局はDOM JS CSSが最小単位でフレームワークが力技で現代風な開発環境を整えてくれてるだけだし ブラウザは頑張ってるよ。あんな複雑なアプリケーションなかなか無い。現代的な開発環境ってのは常に変化するからいちいち対応してたらブラウザのさらなる肥大化を招きそうに思う。
鳴り物入りで導入されたWebComponentsに関しては妙に使いにくくなっちゃったね感はあるけど……。 へーーWebComponentsってどの辺りがダメ？ 継承やShadowDOMとかでコードが長く複雑になって気軽にコンポーネントを作りにくい。
気軽に作るのに役立ちそうなtemplateタグがHTML importが無くなっちゃった関係で疎結合化し難く使いにくい。
他にも使っててなんかあったけど忘れた。
まぁその代わり強力なカプセル化出来るし、ネイティブだから速いしどこでも使えるとかって利点も強いけどね。 >>308
普通React使ってるだけだから良くわからんけど、
WebComponentsってネイティブとか関係あるの？wasmじゃなくて？ いずれreactがラッパーになりそう
ある意味なってるのか既に >>309
DOM APIのラッパー＝jQuery
WebComponentsのラッパー＝React ユーザの権限管理とか、セキュリティとか、スケールするシステム構築とか、キャッシュ管理とか、データ破損に備えたりとか、いっぱいあるんじゃね？ >>314
あるねーー
クライアントにlogic持ち込みたくないわー！ バックエンドこそSPAの根幹でしょ
いわゆるホームページならSPAだけで成り立つけど >>313
こいつの作ったSPAはセキュリティー保ててんのか？
dev toolsでゴニョゴニョしたら
見えちゃいけないものも見えたりすんじゃね？ まぁFirebaseとか使えばセキュリティとバックアップの類以外はフロント側に持ってこれるけど SaaS使ったところでバックエンドのロジックをフロントエンドに持ってくる訳ねーだろ
どんな設定だよ >>320
究極的にはフロントエンドで直接DB読み書きリクエストしてロジック全てをフロントで持つケースもある
現実のサービスのほとんどが様々な理由でその体系を取っていないというだけに過ぎない
・企業サービスロジック問題
・セキュリティ問題
・効率問題など >>320
お前が知らないだけ
フロントでロジック組むシステムはいくらでもある 作れるのはもちろんそう
ただバッドノウハウで
作ってるやつがバカというだけ FirebaseのFirestore使うとクライアント側でDB（非SQL）のコード書くのよ。セキュリティルールと特殊なケース（Cloud Functions）だけサーバ側に書く。
ここに来る連中ならFirebase知ってるかと思ったけど意外と知名度低いのね。 >>326
フロントのコードは改変実行される前提に立たないといけないからセキュリティ関係だけはサーバーで持たざるを得ないね
あとは公開したくないDBや公開したくないロジックがある時
それと複数DBアクセス多くて効率悪い時で例えばGraphQLなど挟んで解決 デスクトップアプリだって解析されれば同じ話
webだろうがなんだろうがサーバー側とクライアント側で独立したアプリケーションが動くだけ >>327
Firesroreはセキュリティルールをかなり複雑に書けるからユーザIDをごまかす手段がなければセキュリティ関係もフロントに書ける
DB自体に権限情報を持っておいてそれに従った読み書きができる
正直ルールがややこしいし普通にサーバサイドに置いたほうがいいと思うことも多いが Firebaseエンジニアになりたいん？
おれ(´・д・｀)ﾔﾀﾞなーー 外部サービスに依存しといてバックエンドは必要無いとか笑うわ
そもそもfirebaseっていうバックエンドを使ってることに気づいてないんかな >>329
それはサーバー側で頑張ってくれている、と同じ 出来るよって話しただけだよ。別にならなくても良いよ ログインありならログイン等認証サーバは必須としても
そのサーバ自体にはここで言うロジックは直接関係ないので他は全てブラウザ側というのは可能だし実際にあるよね >>313
POSTを受け取ってJSONを返すんだよ >>318
まぁ無くなるって事はないだろうけどGoogleだけしか提供してないインフラに頼るってのは一抹の不安があるなぁ できるかできないかの話だったからできるよって話しただけなので、皆好きなもの使えば良いと思うな フロントにDB置けないかなと真面目に検索した事はあるけどな
一時的なキャッシュ程度でもいいから
結局データ自体壊れる事がある(特にsafari)のが分かって全面的に諦めた ブラウザのキャッシュストレージを1サイトで100MBとか使ってもいいものなのか？
みんなが使いだしたらやばいよね そんなん保守として扱いきらんやろ、エンドユーザが少数で決まってるならともかく キミたちは最先端でかつこの世に数少ない貴重なSPAフロントエンジニアなわけだが当然年収は1000万超えてるよね？
安売りしてる奴がいたら今すぐ転職して1000万未満は断ってくれ >>340
SPAてかWEB自体が最先端でも何でもないよw
アプリもWEBも単にフロントでしか無いし
最適な選択できる人はどんな時代でも給料も高いと思うけどね 現実社会では多重下請けの末端の派遣がプログラミングしてることが多いから
貴重でもなんでもないんだなｗ これは完全に偏見なんだけど、ITドカタと言われると多重下請け業者が集まる出向先で、社内向けシステムをJavaとか.NETとか使ってドリンクガブ飲みしつつ作ってるイメージ。
いや、流石に古いか ただ常に人手不足なのは確かなんだよなあ
こんな時代でも仕事には困らんから幸せなんだと思う
ITは確かに体力勝負の土方ぽい部分もあるけど、学ぶ環境も稼ぎ方も選択肢が多くて恵まれてる方だよ SPA/PWAに時代が変化したことで
ちゃんとしたプログラミングが出来ない旧フロントエンドの人たちがついていけなくなったり
フロントエンドを食わず嫌いしてたサーバーサイドの人たちが一部関わらざるを得なくなったり
Web界だけに限っても大きな変化が起きつつあるから アプリは顧客に使ってもらうから画面が命
バックエンドエンジニアやこれまでの古いタイプのプログラマーたちは、画面にあるべきボタンやフォーム類が正しく配置して正しく動作させることができない
こんなゴミどもにフロントを作らせることは不可能だ
美しく60fpsを超えるインタラクションやアニメーションとかどうあがいても作れないよな 昔よりアニメーションは簡素化と（ライブラリの助けもあって）デザインの統一が進んでる。16ms毎に処理呼び出してた頃に比べれば雲泥の差。ある意味ではとても楽に、ある意味では大変になった。 >>351
もうゴテゴテにアニメーション効かせればいいって時代でもないんだがなぁ >>353
その程度の思考しかできないから安月給なんだろうな
ゴテゴテなんて誰も言っていない
Material Youすら理解できないだろう
インタラクションの何かも理解できないならフロントやめたらどうかね まあクソアニメーション動かすだけのサイトだったら阿部寛のホームページのが１００倍価値あるわな。 フロントエンドしか作ったことないひとってこういう極端な考え方するよね
知り合いのデザイナにもいるわ >>358
そんなゴミみたいな奴ってここにいるのか？
バックエンドもDBも普通にできるわ
むしろできないほうがおかしい Appleがフラットデザイン推して10年経ったが、すっかり浸透して今更フロントのデザイン揉める事もほぼ無いけどな
常識的に分かるでしょって最低ラインはどのライブラリもカバーしてるしむしろ下手なもん作る方が難しい フラットデザインに関しては、ボロクソ言われながらもしつこく普及を頑張ったMSが先駆者だと言わざるを得ない。
個人的にWindows8のデザインは衝撃だった。 SignalrRとかWebSocketのUI側テストってどのようにやってる？
双方向通信のコネクションはった後プッシュ的にサーバから送られてくるデータのテストで悩んでる。
テキトーなボタンつくってぽちぽちするとデータ流し込むのを作ってるけど何か違う気がする >>364
なんのテストかによると思うが
あと自動化はするべき SPAの方が好きだが
SPAで頑張るとjsの逆汗等でリバエンクラックされやすくなるリスクは増えるんじゃね >>366
秘密ロジックだけフロントに持ち込まなければ大丈夫
あとはフロントでもWasm使えばネイティブアプリのバイナリ配布レベルと同等になるかな なんだこの低レベルスレ
クライアントのjsなんてクラッキングし放題だろ
Firebaseアプリがクラッキングされまくってんの知らんの？
wasmにしたって一緒
バカじゃねーの？ 一応Firebaseの名誉のために言うと、Firebaseがクラックされるのはあんだけ警告されるのにセキュリティ設定をガバガバにした奴が悪いのだ firebaseに問題があったとしてそれJS関係なくね 置いたユーザに落ち度がなくてクラックされたことってあるの？ firebaseの責任ではないけど
穴のある設定にしがちなユーザと適切に警告なり検出していないfirebase双方の未熟さが合わさって起きた事件があった
特にFirestore周り
だったと記憶してるがゴメン正確にはググって いや、普通にフロントとバックくらい両方やるだろそんなところで役割分担とか無駄でしかない 分業と言えばデザイナとの付き合いは変わったね
今でもdreamweaver使ってる現場ってあるのかな
10年前から追いかけてないが今でもCCに入ってるの見ると需要はあるんだろな 秘密ロジックってなんすか？秘密データじゃなくて？ wasmにしたって一緒なのはその通りｗ
低レベルスレww Google謹製ソフトウェア使っとけばセキュリティ問題が自然と解決すると思ってたり
mBaaS使っときながらバックエンド必要ないとか言ってみたり
バイナリがデコンパイルされること知らなかったり
そのくせフロントエンド開発者はバックエンド開発者より上だとか言ってみたり
なんか色々と察してしまうわ なぜかフロントだけがセキュリティリスクあるみたいな流れ これより一子相伝、門外不出の秘密ロジックを伝授する！用意は良いかケンシロウよ！ 型はいらない派も笑うよな
小規模プロジェクトしかやったこと無いのが丸わかりで
一人でシコシコ最強秘密ロジック書いとけって話 仕事でvue使ってるけど自由すぎてしんどい
angularのがライフサイクル固まってて間違いないように見えるが不人気なんだよな vueうちの会社でも使ってたけど、
一覧生成とかをvueにして基本Jqueryと併用したほうが早い からの、結局Jqueryでいいになって
今じゃ使われなくなったわ >>389
俺もangularの方が好きだよ
色んな意味で最初抵抗あるのはよく分かるから仕事じゃ無理に勧めないけどね let $ = document.queryselector;とかこの業界まだやってんの？ >>388
いらんでしょw
javascriptで書けませーんwとか言いそうw Intへの変換とDecimalへの変換とStringへの変換のメソッドつくっときゃ一緒やで 一体いつjQueryの利用が減少に転じるんだろうね
まだjQueryの利用者は増え続けてるからね
現在78.3%、このペースだと2年後に80%超えても不思議じゃないな
https://w3techs.com/technologies/history_overview/javascript_library/all/y レベルが低い奴がいたっていい。山が高くなるには裾野が広くなくちゃいけないからな。
それにレベルが低くたってC#おじさんとjQueryおじさん、あるいはフロント見下しおじさんがスレ違いの事ばかり言ってるのに比べれば100倍生産的なんだなw >>388
一般的に秘密ロジックとはセキュリティロジックやビジネスロジックのうち公開したくないもののことだね
それをフロントエンドに持って来ると難読化でもバイナリ化でも解読されうるからサーバーサイドに持つという話かと
だから全てをフロントエンドに持ってくることはなくサーバーサイドに少なくとも秘密ロジック部分が残るという話の流れと理解 サーバーにあるべきロジックが
いくらSPAになったとしても
クライアントにもってこれるわけねーーだろ！
ってはなし それ教えてあげてもフロントエンド開発を見下してるとか言い出すしな
訳がわからない オープンソース隆盛の時代に、秘密ロジックおじさんの長文ってなんで言い訳に聞こえるんだろ（笑 フロントエンドは「データ取ってきて表示する」ぐらいにしとかないと破綻するよ
何でも出来るから何でもして良いってわけじゃない リスクとパフォーマンスを天秤にかけて個別に判断するだけ
SPAがどうとかぶっちゃけ関係ない いまエンジニア転職市場ではまともな開発ができるSPAフロントエンドエンジニアが求められている
なぜならどの業界もエンジニアが欲しくてたまらないから
しかしフロントエンドエンジニアは圧倒的に少ない
安売りするなよ 日本のゴミのようなシステムのフロントに変革をもたらすんだ reactはhooksのおかげで価値が数倍になったな
よくjavascriptにこんな機能乗せたもんだ 無い無い。ちょっとでも複雑なもの作るならReactの方が断然楽だし、ドシンプルなもの作るならバニラJSの方が良い。
jQueryは環境に付属してる場合以外、積極的に採用する理由はない。 >>419
バニラJSを使うことってあるんですか？
そのバニラJS vs jQueryで比較しましょう Reactがダメな所はバニラJSと組み合わせられないところなんだよな ReactはJSの上に構成されているので組み合わせれるも何もないよ。それとややレアケースではあるけど（仮想ではない）生DOMとも組み合わせられるよ。特殊なイベントを扱いたい時にcurrentTarget経由で使ったりとかね。 >>415-415
youtuber ですねわかります バニラJSを使うような人は、jQueryを使ったほうがいいだろうな
開発しやすさが段違い >>394
let $ = document.querySelectorAll;だろ、、常考 日本はreactとvueの分断が酷いね
またガラパゴス化してしまうのか 日本だとvueが人気って嘘だと思うんだよな
日本のツイッターの言及数でもreactの方が2、3倍多い >>435
それは二年以上まえの話
既に逆転してるから 世界で比較するとvueが結構reactに迫ってるんだな
あくまでgoogle trendでの比較だけど
USでも倍か。もっと差があると思ってたわ
Angularはまあ、安定してるw Vue良いぞ。Reactも良いけど、フォームアプリとなるとつい俺はVue選ぶ。
あと、jQueryで良いような小さいツールでもDOMいじりしたくなくて、コンパイルせずにVue使ったもできるのかVueの強み。 >>436
日本でReactとVueが絶賛競い中だな。2020年末ぐらいからは若干Reactの方が多いし増加傾向に見える。
中国といえばVueというイメージあったけど55%か、意外と少ない。 >>438
USだと4〜5倍差に見えるんだけど、俺は見方を間違えてる？ 未だにvue押してる老害がいるから日本はガラパゴスって言われるんだよな react一強ですな
日本のエンジニア求人も一年前からreactに傾いてます 日本のWebフロントエンドはまだガラパゴスにすらなって無い vue.js 日本ユーザーグループが、3千人だろ
YouTube で有名な、雑食系エンジニア・KENTA の、
転職用Ruby on Rails サロンは、月千円と有料だけど、3千人
単に、1人の有料サロンと同数w そもそも日本のバックエンド人口とフロントエンド人口が圧倒的な差がある
ガチフロントはバックエンド100に対して1すらない でも、最近のKENTA のサロンの、
Ruby on Rails 初心者用コースには、フロントエンドも入っている
Rails, Linux, Docker Compose, Node.js(Webpack, Babel), Bootstrap
VSCode(Remote Container, WSL2 ならRemote WSL), Heroku, CircleCI、データベース
今までは、Docker Compose までが初心者用コースだったが、
最近は誰でも、Docker出来るから、
AWS Fargate, Terraform, Vue.js, React, TypeScript も入っている
だから、AWSのくろかわこうへいのサロンにも、入る必要がある。
今では、1年の未経験者が、10年以上のプロよりも技術力が上になってる！ >>447
フロントしかいじれない人とか需要ないよ
よくいるワードプレス屋さんみたいな人だろ？ Preact使ってる人はどれくらいいるのかな？
Reactの大半の機能が使えて十数KBくらいのフットプリントで済むから気に入ってるけど 以前遊びで使ってみてこれでいいじゃん！ってなったけど外部ライブラリの対応で死んだ >>450
お前がバカだから知らんのだろう
このスレでwordpress屋とかほざいて脳みそ大丈夫か？ >>452
preact/compatでは駄目だった？ >>454
普通のjsライブラリはそれで良いんだけどReact系のライブラリだと型が合わなくなるでしょ
その対応がめんどくさくてreactで良いやーって
今は楽に行けるのかもしれんけど >>455
preact/compatはReact依存ライブラリ用だぜ ややスレ違いなんだけど、みんなクラウドでREST生やすときは何使ってる？
LambdaとDinamoDBとか？ >>458
いやapiは互換だけど型はそれぞれ違うじゃない？ >>460
う〜ん、TypeScriptで使ってるけど特に問題なかったけどな。昔はそういうのがあった、とか、ライブラリによっては影響が出るのかな >>461
2、3年前の話だしね
軽くて最高だーとノリノリでいつくかのライブラリの定義して力尽きた
今は型定義整ってきてるとは思うけどね
追ってないから分からないけど >>459
ぼくはCloud Functions！
でもクラウドよりVPS派！ Vueの方が直感的だしこれを理解出来ないなら今すぐ引退したほうが良い
reactはjsxがキモい Javascriptのくせにコンパイルとか勘違いしてるよな正直 >>463
正直俺もVPS(Linux)の方が慣れてて楽なんだよね。
クラウドだと可用性でメリットあるかなとか思って使い始めたけど、止まる時は何使ったって止まるわけで、スケールさせる事とか考えなきゃVPSで十分かな…… そのスケールさせるのがVPSだと一番大変なわけで・・・
VPSでスケールできたらいいのに >>465
2000年代に基本情報とか勉強して世代ならジェネレートじゃんって思うよね オーケストレーション前提でまずはスケールアップできるVPSで良いんじゃない？ あまり詳しくないけども。
K8s使うまでもなくnginxをロードバランサに使えばロジックはスケールしない？
スケール面での問題はDBだと追うんだけど あとスケール前提で組もうとするとスモールスタートにならないという問題もあるな
その点googleとかならヒットしなかったら無料でいける おまいらインフラまで担当してるの？
その辺はインフラエンジニア任せだ GCPやAWSは基本的にインフラをGoogleやAmazonが提供していて
アプリケーションエンジニアはそのインフラを使うものだよ
GCPやAWSを知らずしてクラウドアプリは開発できない >>475
趣味とか勉強でバックエンド欲しいときあってインフラもやるやん？
そゆことやってると多少詳しくなる >>477
開発環境くらいは構築出来るけど
本番やそれに関するjenkins等の設定は完全にノータッチだな 本番でJenkinsなんて今でも使われてるの？
Jenkinsの開発者は今はTerraform作って業界標準くらいヒットしてるけどビジネス展開してるだけあってTerraformは24hサポートとかも付けられる
対してJenkinsはもう放置状態でもともとサポート付けたビジネスも展開してないでしょ？
トラブル時不安じゃないの？ >>479
素人さんかな？あちこちの現場いけばわかるよ なるほど派遣で回ってる現場ね
そりゃ環境古臭そう
秀丸でコーディングしてそう笑 >>481
独立して法人成りしたコンサルだよ
現場に席もらっても常駐はしない
日中は外出多いし
そもそも請負だから ぶっちゃけ自分で環境構築できないような奴にはフロントフレームワークとか使いこなせんやろ >>296
なんて言ってたけど、最近Rustでバックエンド書いてみてわかった。ちょっと面倒くさいしとっつきにくいとこあるけど、意外と生産性高い。
記法や思想でモダンJavaScriptに近い部分もあって、書いてて妙にしっくりくる。C#よりはるかに書いてて気持ちいい言語だわw >>485
同感
全く似ていない言語なのに
Node.jsでの心地良さがRustでさらに心地良く感じてRustを気に入ってしまった どっちも関数型言語の考え方を取り入れているから似ていると感じるのは自然な気が Javascript知らないしコールバック見ると吐き気がするんですが異動で来年度からフロントやらされることになりました…
まだ何使うか決まってないから取り敢えずなんかフレームワーク勉強しとけって言われたんですが、、vueとReactってどっちが勉強のコスト低いですか？
PythonとC++ならやったことあります javascript知らないならまず生を勉強しないとreactとかおまじないだらけに見えるぞ angulerなんか使われていないからやめとけ
>>488
たぶん挫折する
javascriptもバックエンドからみたらなんじゃこれ？みたいになる
コールバック地獄はもうないけど
Reactも初めてみたらワケわからんだろうしコンポーネント思考でデータストリームで何度もレンダリングされるとか、コンポーネント増えたらバケツリレーどうすんのとか
何よりバックエンドエンジニアが最も苦手なhtmlとcssがjsxとstyle Componentとかでjavascriptの中に入ってくる
cssできなかったらデザイナーと共同作業になる >>488
まずここで現代のJavaScriptを学べ。
https://jsprimer.net/
とりあえずの生産性を求めるなら古いJSを知る必要はない、混乱の元になるだけ。
モダンな言語使ってれば高階関数は使ってるだろうし、現代のJSならコールバック地獄になることは（余程設計が不味くない限り）無いから安心するといいよ。 あ、C++使えるのか、それならJSは簡単に感じると思うよ。 >>488
コールバックってクロージャだぞ
クロージャを見ると吐き気がするプログラマーなのか
クロージャの理解ができない？ Nuxtをずーっと今まで「ぬくすと」って読んでましたごめんなちゃい >>495
じゃあ何？
大昔からC言語ですら関数のポインタ渡しは普通に行われてきたし
吐き気がする意味がわからない コンポーネントと再レンダリングとjsxとcssとかもろもろキモいだろ
こんな言語とフレームワークは他にはない そのへんは単に思想の違いだから。
安い挑発には乗らないよ コールバックで吐き気って、関数を関数に渡すのが意味わからんとかってことじゃね？
そのレベルだとフロントかなりきつい気がするけど 高階関数や関数型プログラミングが嫌いな人たまにいるけど
狭い世界でしかやっていけないプログラマーだね 一昔前のコールバック地獄知ってるんでしょ
あんなスパゲティコードみたら誰でも吐き気するって
他人の書いたそんなコードとか読みたくも無いわ
あ、お前ら一人で書いてるんだったね
ならお好きに >>502
コールバックとコールバック地獄は全く別の話
一方でJavaScriptは継続渡しプログラミングとしてもコールバックを多用してきたがそこには非同期プログラミングも許容する柔軟性こそJavaScriptの強みの一つ
もちろん同期プログラミングしかできない人はasync/awaitのみによる限定的な使い方に徹するしかない
例えばその元となる非同期にresolveやrejectをするPromiseを返す関数などを自分で作れないだろうから JSに慣れてくると非同期前提の設計って結構便利だなと感じ始めるよね >>505
そういうのは例えば『XMLHttpRequestとPromiseとJSONのマニュアル見ていいからそれらを使ってURLを与えるとJSONオブジェクトを返すasync関数を作りなさい』
とか課題を与えるとまともなJavaScriptプログラマーか駄目プログラマーかすぐに判別できる >>510
XMLHttpRequestはもう随分使ってなくて細かいとこ忘れちゃったな。
とりあえず200以外はエラーで良いですか？ って試験出した人に聞いちゃう >>511
そこはマニュアルを見ていいから大丈夫
あと題材としてはXMLHttpRequestでなくてもよくて
コールバックする関数からPromiseを返す関数を複雑な場合でも作れるプログラマーか
それともそれを使ってawaitするだけのプログラマーか
その違いがわかればOK >>513
なるほど。
setTimeoutを使って早期終了もできるasync sleep関数を作れ、とかいう課題でも面白いかもね 皆さん色々とありがとうございます
取り敢えず>>492さんのサイトで学習から始めてみようと思います
Javascriptがあまり受け付けないのは引数の中に関数をそのままぶち込むっていう
今までやってきた常識とは異なるコードを割とよく見るので…
理屈が分かれば簡単なんだろうとは思いますが前提知識無しでちょっとデバッグしようかなレベルの時にこういうの見るとちょっと辛いですね
https://pastebin.com/pgmkMw1Q >>515
JavaScript以外でもモダンな言語なら（無名）関数を引数にするのは日常茶飯事だよ。慣れた方が良いかも。
頑張ってね。 >>511
それよりもJSON.parseでエラー出た時にPromiseをrejectするのを忘れずにｗ
>>515
今どき関数型プログラミングをしたことないとは化石のような方で驚く
関数に関数を渡すのを覚えるとプログラミングが捗りますよ
あとイテレーターを使ったり作ったり慣れるとよいでしょう Rustいじってるけど良いねこれ
継承が無いってのが凄く良い >>521
あんまり言うとスレ違いになっちゃうけど。
implがオブジェクトの実装に寄り添ってたり、return無しで値が返せたり、ifとmatchが式だったり、デフォルトでimmutableだったり、エラー処理やOption周りのワンライナーっぷりだったり、所有権周りの合理性だったり、コンパイル時の親切さだったり、ほんとにモダンだし、洗練された言語設計哲学を感じるし、書いてるとな〜んて美しい言語なんだろうって惚れ惚れする。
まぁJavaScript|TypeScriptも大好きなんだけどねw JSフレームワークもぐぐること多いんだけど
技術系記事の日付はこれでもかっていうくらいに目立たせてほしくなるな
いつの記事かによって見る見ないがガラリと変わる 間違ってる記事多いもんな
せめてドキュメント読んでから書けよって突っ込みたくなる 最近はもう誤用のほうも辞書に載り始めてるとは言え、
そもそも統計学を翻訳するときに成立した造語だからな母数って
統計用語としてのparametersの訳だよ
それさぁ…「分母」じゃダメなの？
もし統計用語としての「母数」を意図してます、と言うなら「JSは母数が多い」は文意が通らないよ
まぁ分母なんだろうけど
どうして小学校で習う分母ではなく母数を使いたがるのだろう？
少しでも頭良く見せたいとか？
逆効果だと思うが >>527
それは本末転倒で
parameterの訳語を母数したところからおかしい
parameterは特性とかでいいだろ
一方で母数は誰もが母集団の数や分母の数と認識するのは当たり前 >>528
悪訳語であるとは俺も思うがそれとこれとは話がdifferent >>529
明らかに『母集団や分母の数として母数』が使われている状況で
わざわざ『馬鹿げた訳語である母数』を持ち出す人がバカだと言ってるだけです >>530
馬鹿げた訳語をわざわざ使ったのはなぜ？
分母ではダメだった？
なぜ小学校で習う分母ではなく、「馬鹿げた訳語」である母数を、その訳語の創出の意図と違った誤用である分母の意味でわざわざ使ったの？
頭良く見られたかったの？
バカなのにｗ 悪法も法なりではないが、統計学を日本に導入する際に創出され、それ以降差し替えられず、現在でも統計用語としてのParametersの唯一の訳語なわけよ
それを小学校で習う分母の代わりごときに流用する必要なんてないわけ
そもそも小学校で習う単語である分母で誤解の余地なく正確に言い表せるものをなんで本来その意味を持っていない母数で言い表したがるわけ？
特にプログラミングなんてどんなに気に入らなかろうが利用する言語・APIの仕様に沿ってコーディングしなきゃ動かんのに、
オレオレ解釈で書いておいて、本末転倒だ！仕様がおかしい！馬鹿げている！俺の思った通りにコンピュータは理解するべきだ！
と言っているようなもの >>533
それ誤用だよで済ませとけばいいのに。
それを人を馬鹿にしたみたいに「頭良く見せたいの？」とかつけるからいらぬ論争になるんでしょ。
多分使った本人は誤用である認識すらないでしょ。そうやって誤用が広まって行くんだし。
まぁ煽り合いが文化なら違う場所でやってよ >>535
超怖い。俺も母数を誤用してた口だからまじかってなったわ。明日から会社でマウント取りいくわ 誤用ではありません
複数の意味があるだけです
そして片方がパラメーターを母数と失敗誤訳してしまったというだけにすぎない
全ての常識人に母数は全体の数の意味で通じます 良く考えてみなよｗ
少なくとも統計の文脈では母数は全体の数には使えないじゃんｗ
そして母数は一義的には統計のためにひねくり出された言葉でしょ
分母の意味が後づけなんだよ。
偉い人が勘違いしてムキーっ！俺の意味も正しいの！って言って辞書に分母の意味足したんだろうなｗ >>538
言葉には正しい形も定義もなくその形も意味も用法も時間とともに常に変化してきたナマモノ
そして多義性こそ最も盛んに行われてきたものだから何かに一つにこだわっちゃダメ
一番重要なことはその時代に通じてきたかどうか
現代のほとんどの日本人は母数を全体の意味で用いて通じるからOK
少なくとも誤用ではないですね 技術的な事は具体的な事何も語れないのに言葉の誤用についてはこの有様 ま、俺も誤解を生じやすい失敗訳語だとは思う
だからバカが釣られる
糞にたかる蠅のようだ >>541
ら抜き言葉は以前から使われてきた西日本方面の正しい方言
しかも可能と受け身尊敬表現とを分離できる優れた用法
たまたま標準語として採用した東京地方の方言ではラ抜き言葉がなく区別できず劣った状態であったため
区別できる優れたラ抜き言葉を採り入れる人が全国的にも増えたに過ぎない >>545
それどころか総務省統計局の初心者用統計講座の資料チェックしてた時も間違って使ってやがったので厳重に注意しといた
どこの誰が間違えてもお前は間違うなと 伸びてるとおもえば母数警察とかしょーもなww
こういうのいちいち指摘するやつって、
コード書かないくせにレビューだけ文句言ったりするんだよなw
指摘するだけじゃなくてわざわざ語りだして煙たがられるやつw 言葉の形や意味用法は通じるかどうかが全てなので通じていたら誤用ではないのよ
そして本来の形や本来の意味が使われなくなった言葉も多数 >>546
たしかにら抜き言葉は可能/受け身尊敬を分けられる(分けれるｗ)というメリットがあるね。
分母と違ってparameterかmodulusかtotal numberか分からんくなる挙げ句にメリットとしてはナンダカカシコソウニミエルくらいしかない母数の誤用と比べるのは失礼だったかもｗ 発端はこれ
>>526
> JSは母数が多いからねえ
母数が多い、と用いているから
そこに紛らわしさは全く無く
parameterやmodulusの意味ではなく
全体数の意味であると日本人なら誰でもわかる
この状況で失敗訳語の母数を持ち出して語りだすのはキチガイくらいだ なぜフロントエンド技術者が馬鹿にされるのかよく分かるスレですね こんなところで日頃のウサを晴らしてるより勉強した方が良いですよ 2019年まではVueとNuxtが優勢だったけど2020年あたりから一気にReactが盛り返した印象があるんだけどその頃何があった? もう、React Hooks 無しでは考えられない
JSX も 開発ってさ、新規開発だけじゃないじゃん
例えばそういう場合にReactを追加するよりもVueを追加するほうが断然合理的じゃないかな Vueのほうが日本語ドキュメントが豊富(だった)じゃん はじめにVueを書いてしまった為にVueで書いてるとかあります。 >>567
日本ってかアジア圏じゃねえの？特に中心にあるのは中国だろ っていうかぶっちゃけさ、
ReactやVue使わないほうが作り終わるの速いよね WebサイトならReactはいらん
業務システムとかWebアプリ系なら必須 Webサイトなら（構成によるけど）Next.js使っちゃうかな〜 Reactは冗長すぎる
よほど大規模でリッチなクライアントでない限り
使用するメリットがない どんな書き方といか、最低限の処理をするのに大変といった感じだろうな
例えば特定のフィールドに値を入れるだけでも大変 react嫌いすぎでwasmが全てを吹き飛ばしてくれる日を心待ちにしてる >>582
DOMなら一行よ？
$("#id").va(123);
vs Reactやってよｗ そうでしょ？
あとさAスタイルのときとBスタイルのときみたいに
CSSでデザインを切り替えるからさ
DOMの書き換えなんてほとんど不要なんだよね
DOMゴリゴリっていう発想が
そもそも間違ってるんだよ
Reactとかさ、なにそんな単純なことを
JavaScriptで頑張っちゃってるの？って思う あ！ そういう人ね。現状で困ってないなら、他所でやってどうぞ フレームワークってたいてい規模が大きいほど恩恵があって、
小規模のうちはデメリットの方が大きいもんだよ >>586
そもそもコイツは何もわかっていないからスルーしていい 入力フォームとか多用するサイト作らんならそりゃ要らんやろ
元々そういう区分けだって言ってるやん Ruby on Rails では、若い娘が1人で起業する場合は、
Heroku, CircleCI, React, Bootstrap, jQuery が定番
大企業では、AWS で、
REST の代わりに、Facebook 製のGraphQL, Relay とか。
Bootstrap も含めて、すべて米国のFacebook 製で揃える
YouTube で有名な、雑食系エンジニア・KENTA のサロンでは、
転職用にReact よりも、Vue.js が必須
でも、米国人は中華を使わない >>593
ホワイトハウスのサイトはガッツリVue使ってるだろ。 Webアプリは入力を多用するから入力フォームだらけだ >>595
まずWebアプリの定義が曖昧だが
突き詰めていくと例えばUIがJavaScriptで動くものがWebアプリでそうでないものがWebページとするしか分類できなくなる
すると「入力フォームがWebアプリでない」ものはHTMLのformをそのままsubmitボタンでページ遷移するWebページのみとなる
もちろん現在もこれをベースとする形が正しい作り方として明確になっている
JavaScriptがない環境ではそのままで動き、JavaScriptがあれば修飾する形で高度なUI提供や必要ならページ遷移無し等にするのが正しい
したがって「入力フォームがウェブアプリだったら嫌だな。」というよりも「上述のような正しい作り方をしていない入力フォームはダメだな。」とした方がベターかもしれない 現在中３でjavascript勉強してます。モチベが低下してきたのでここまで勉強できてたら案件受けれるみたいな目安みたいなのがあればお聞きしたいです >>598
俺は中高はひたすらゲームと音楽（DTPとか）作ってたわ 中学生なら勉強していい大学に入ろう、それが一番将来に役に立つ 案件受けれるかどうかはプログラミング能力以外の部分が大きい
仕事に使える能力あってもクラウドソーシングだと競争率高くてきつかったりする
なんでモチベ低下してるか考えるところからだな 本当に中学生ならクラウドソーシングでの価格競争力はあるんじゃないの
でもワーカーとしての審査が通るか? 親にちゃんと話して名義借りでやるとかかな
もし通るとしてもそのサービス上で実績が0だとなかなか仕事を取れないらしいね
よって、知り合いに頼んでわざとクラウドソーシング経由で仕事出してもらって実績にするという裏ワザがあるそうな
話が逸れたけど、クラウドソーシングで募集してる仕事内容は自分が金を稼げるか否かの一つの目安にはなるんじゃないかな 秘密ロジックはサーバーサイドに持つからReactもVanillaもどちらも関係ない >>598
何か一つサービス立ち上げて実績作ろう
あと誰かも書いてたけど学業も両立しような >>603
"秘密ロジック"で検索したら全然見つからない
お前が誰か特定できちゃうぞｗ Reactってなんでこんなにバージョンアップ早いん >>601
ありがとうございます！
モチベ低下の理由は自分でも理解しているのでなるべく早く回復できるようにがんばります！ >>602
高校までは案件受けるつもりはありませんがどんな内容なのかとかは今のうちにある程度見ておこうと思います >>605
一応lp？みたいなものは作っています。勉強の方は、親と相談して高校までは勉強最優先。
高校からは最低限の勉強をしていればあとは自由にやっていいよということになりました >>614
がんばれー良い親御さんで良かったね
或いは余計なお世話かもしれんが高校入っても高校の3年間でしか学べない事を優先して欲しい
ほとんどの場合それが最短距離だから どうでもいい自分語りだけど、
高校で友達とあれこれPCいじったときが一番プログラミングのモチベ高かったわ
Javascriptを無効にするような時代の前だったけど、自由だったな。いろんな意味で 今となっては古すぎる本だけど学生時代に JavaScript: The Good Parts に出逢った事で俺の方向性は決まってしまった。あの本を読んでプログラミングの美しさ面白さに取り憑かれた 【悲報】ホロライブ6期生のｽｰﾊﾟｰｴｰｽVtuber沙花叉クロヱさん、初収益化配信1時間で1000万稼いでしまうｗ
https://krsw.5ch.net/test/read.cgi/ghard/1639158137/ reactサイトのcms として久しぶりにWordPress使う事になったんだけどこれ全然進歩してないのね WordPressのエディタにReact使ってるから進化してる WordPressをheadles cmsで使うってのは良くある
運用側がWordPressに慣れてるってのが理由
けど開発から見たたら今時PHPかよっていう心理的負担が大きい
WordPress REST APIもウンコ 無料だから対費用効果を考えたらwordpressでいいじゃんってこと 昔は流行ったが今WYSIWYGエディタなんて使わんだろ
全く追ってないから分からんがスマホ対応すら罠がありそうで怖いぞWordpress YouTube で有名な、雑食系エンジニア・KENTA のサロンでは、
Ruby on Rails のポートフォリオで転職する
キャリアパスも、Rails → Go のみ
PHP は、一生やらなくて良いと言ってる
たぶん転職できても低給料で、文句ばかり言われるから、
Java とか、そういう低給料を目指す人は、サロンへ入れないのだろう
サロンで給料の文句ばかり言われると、
サロンの評判が悪くなり、廃れていくから
そういうサロンを運営したくない。
だから、モダンな会社で、ちゃんと給料がもらえる、Rails, Go のみに絞っている railsってモダンに入るのか？
今となっちゃphp/laravelの下位互換だと思った
そもそもマトモなエンジニアは日本限定のクソサロンとか作らずに英語圏向けに発信するし、OSSなりカリフォルニアなり目指すんじゃないのかな KENTA がいつも言ってる
Rails を使っている会社は、社風・開発環境がモダンだからって。
最も最先端
例えば、伊藤淳一がCTO のソニックガーデンは、全社員がリモートとか
逆に、Java は絶対にモダンじゃないw Railsはオワコンなのにモダンってなんだよ
Ruby自体がもはや見向きもされていないし Goはインフラ界隈で広まり始めたけど雲行きは怪しいな WordpressとReactの組合せってイマイチターゲ層が分からんな Reactヘビーユーザーが思うSvelteの良いところ
https://qiita.com/tonio0720/items/88e62e6beffa9adc1a7f
Reactを使う上で特に不満があったわけでもないですが、Svelteに乗り換えてみると無駄が多かったことに気付かされました。 そもそもReactからSvelteに乗り換えられるような規模感って、それ技術選定の段階でミスってるんよ・・・
てか、Recoilのおかげで固有コンポーネントの凝集度が高くなるから
変更時の影響範囲が狭くてかなり楽になったわ Reactが使える範囲はすごく小さいって話だな
jQueryが今も王者である理由
さて現在は・・・jQueryのシェアは4ヶ月連続で0.1%増加し続けて
78.5%にまで到達、なお一年前は77.1%でした。
これが現実やで wordpressインストールするだけでjqueryシェア増えるからな
詐欺サイトが自動量産されてるからシェアが増えると詐欺も増えるだけ
つまりjqueryは詐欺のためにシェアを拡大している
これを自慢するアホは詐欺以下の存在 同じ東アジア人が作ったVueに決まってるだろ。
東洋の神秘が感じられるし。 >>647
「最近は○○をよく書いてます」
この○○に入れたい方 >>645
React使って何かを作るよりもWordPressを使う方を選ぶってことやろｗ こんにちは、初心者デス！
家のWindowsにReact nativeをセットアップしましたが
エミュレータがフリーズします（うまく行けば10分以上かかってやっと表示されます）。
プロセッサーが悪いのですか？
AMD A4-9125 RADEONR3,4 COMPUTE CORES
2C+2G 2.30GHz
皆さんはもっと良いものを使って作ってますか？ >>651
そんなレベルのやつがReactを使うな
jQueryを使うべき
基礎から始めろ >>652
後でやります！めっちゃ急ぎで性能的に大丈夫かどうか知りたいです。
大丈夫でないなら今から買いにいかなきゃならないので。 >>653
急いているふりをするな
自分が無能であることを知ることから始めろ
そして自分で調べろ
それが今すぐにやるべきことだ >>651の再掲
家のWindowsにReact nativeをセットアップしましたが
エミュレータがフリーズします（うまく行けば10分以上かかってやっと表示されます）。
プロセッサーが悪いのですか？
AMD A4-9125 RADEONR3,4 COMPUTE CORES
2C+2G 2.30GHz
皆さんはもっと良いものを使って作ってますか？ 性能が悪いんで100万ぐらい用意して
新しいパソコン買え
他の人は20万とか10万とか5万とか3万とか
騙してくるだろうな すでに答えました。
他の人もどうぞ
それっぽい回答をよろしくおねがいします（笑） >>652
React NativeとjQueryを比較するとか正気か！？ 使えるフィールドが全然ちゃうやん
>>651
CPU性能もさることながら、メモリ足らんのちゃうか。まずタスクマネージャー見ろ。
つか、スレチ jQueryとか言ってるやつが言うことは全部ウソだから >>661
ありがとうございマス！メモリも足りません！
数年前のものです。
新品の高性能のやつ買ってきます。ではではスレチ失礼しました！ >>651
うーん、やっぱりGPUの性能が足りんのではないですかな？ Headless CMSとしてWordPressを使う案件って結構あるけどそれ以外使ってる人って何使ってる？ ヘビーユーザーって言うか単にjQueryで作ってもいいような感じのモノを無理やりReact使って作ってたんだろうなとしかね… >>651
A4-9125ってCeleron相当やんそら重いやろ 未だにFCやVFCで型付けしてんの多いのが良く分からん
ジェネリクス使えないし、余計な非推奨の含まれたpropsが渡ることになるし
そもそも公式のCRAやDocusaurusとかを見たら使ってないし https://kentutorialbook.github.io/functionalprogramming2022/
| 5.2. オブジェクト指向時代の終焉
|
| JavaScriptはES2015(ES6)時代になり、オブジェクト指向そのもののClass（クラス）が新たに導入されました。
| これに伴い、Reactでも、フレームワークの根幹となるコンポーネントをClassで表現するように標準化されました。
|
| 筆者などは「いくらJavaScriptが根強いオブジェクト指向ファンの要請から、後方互換性のようなクラスが導入されたからといって、
| Reactのようなメジャーな外部ライブラリまでそれに習うのは困ったことになった、時代の逆行だ」と、まったく歓迎していませんでした。
|
| 案の定、オブジェクト指向のクラスを標準コンポーネントとして利用するというReactのアプローチは失敗し、
| 実質クラス実装のコンポーネントは破棄し、関数型に近いHooksという仕組みが導入されることになりました。 そんな経緯じゃなくね？
それはともかく、JSにおいてclassの存在意義が大きく無いのには同意。 スクリプト言語だし、必要に応じて呼び出されるだけのサブシステムだからClassは馴染まないよね。
クラスって入口から出口まで完全にその言語で実現される比較的大きめのプログラムには有効だよ Reactのソースみたことないけど関数なのに値はどうやって保持してるんだろ？
中身はクロージャーなのかな？ >>676
全く違います
JavaScriptはクラスインスタンスベースのオブジェクト指向ではなく
プロトタイプベースのオブジェクト指向なので
かなり後になって最近ようやく後付けでクラスが導入されたという経緯があります 擬似クラスでも恩恵には預かれる
ダメなのは理解なく使った場合の弊害
要するにアホガードを搭載したのがhooks apps そもそも現行のAngularはクラスベースでうまく機能してるし（以前はゴタゴタしてたけど）
結局は使い方次第
つーか、言語はかくあるべし、みたいなしょーもないこだわりは個人開発だけにして欲しいわ
チームに持ち込まれると鬱陶しくてかなわん 郷に入っては郷に従え、という言葉の通り、長い目で見ればモダンJS,TSという郷に従ったほうが利がある。
モダンJS,TS使いは、classがわからんからclassを使わんわけではなく、classを知ってるから必要な時しかclassを使わんのだ。 新しいことを覚えたくないから、覚えなくて良い逃げ道を探しがち
はてブのコメ欄とか見てるとつくづくそう思う もうそろそろ新しいのも出なくなってReactと状態管理とNextさえマスターすればくないか？ これ本当？
学習コスト高そうでReactとか敬遠してたんだけど手軽に学習出来るならSvelte.jsっての触ってみようかな
Svelte.jsは、React.jsなどのライブラリと比べて複雑ではないため、フロントエンド開発初心者でも学習ハードルは高くありません。
また、手軽に開発することができるため、小規模アプリを個人開発したい人におすすめです。https://udemy.benesse.co.jp/development/app/svelte-js.html >>61
技術力ないところはvue/nuxt っていうのはめっちゃ合ってるわ >>689
日本語が読めない人かね？
誤読して全く異なる意味になっているぞ ReactもWeb技術やJSの基礎さえ出来てれば別に難しくはない。元々Web開発やってない人には多分難しい。 jQueryを使っていれば
JSやWebの基礎ができてる
基礎ができてる人は多い jQueryはルールが独特なのでjQueryが生み出すのはjQueryだけ使える人です……。そういう可哀想な人をたくさん見てきました。 jQueryはDOM APIを簡略化してかけるようにしただけですよｗ
そもそもjQueryはJavaScriptで作られています。
基礎ができてないから、そんなこともわからない。 >>59
jquery UIとか今でも欲しがってるゴミクソがいたとは驚きだわ jQueryのイテレータとか特殊じゃん。jQueryおじさんが一番jQueryわかってない疑惑 >>687
Reactは最適化しようとすると大変なだけ
Recoilやv18で来るConcurrentModeとかが
実現したいことに当てハマる場合はおススメ
ただ無理に使うものではないし、ほんとそこに書いてある通り規模感次第 >>696
それはお前が関数型言語の考え方や高階関数を理解してないから
jQueryのイテレーターはJavaScriptのmapなんかにそっくりだ
links = [{name: "A", href: "a"}, {name: "B", href: "b"}, {name: "C", href: "c"}];
const hrefs1 = links.map(ary => ary.href);
console.log(hrefs1);
const hrefs2 = $("a").map((index, element) => element.href).get();
console.log(hrefs2);
お前がjQueryをわかってない jQueryは
mapとeachで引数順違ったり
DOMがthisにバインドされたり
明らかに設計ミスってるからね
もし今同等の機能のライブラリ作るならこんな作りにしないでしょ >>700
> DOMがthisにバインドされたり
それはDOM APIの仕様に準拠した動作
やっぱり基礎を知らないんだな（苦笑） イテレータの話してるんだからmap引数の関数のthisが配列内の要素（上のコードのケースではa要素）を指すのがおかしいって話してるんでしょ。
わかんない？ イテレータの話だったらthisのことになるの？
そもそもthisなんて曖昧なもの使わなければ済む >>703
ツッコミどころ満載で、恥ずかしすぎるレベルだなｗ
やっぱりJavaScriptの基礎を知らねーのはお前じゃねーか
> thisが配列内の要素（上のコードのケースではa要素）を指すのがおか
上のコード（>>968）のケースではコールバック関数ではなく
アロー関数なのでthisがa要素になることはない
> イテレータの話してるんだから
jQueryは基本的にDOM APIの拡張なんだから
イテレータの話ではなく、まずはDOMが大前提だ
jQueryではDOM APIとの互換性のためにthisが要素になっている
jQueryはJavaScriptにmapがない時代に作られたもの
そのためJ汎用ユーティリティとしてDOMとは無関係の汎用のイテレータも用意されてる
汎用ユーティリティの方のmapはthisにならない
https://js.studio-kingdom.com/jquery/utilities/map
> 各値を変換する関数を指定します。 この関数内でのthisはwindowを参照します。 上のコード（>>698）のケースではコールバック関数ではなく >>705
イベント用関数のthisがDOMをbindするのは別に普通だよ。
>>700 の言い方からしてイベントの話じゃないし、（thisが出てくるんだから）アロー関数の話でもないのは明らかじゃん。
> jQueryはJavaScriptにmapがない時代に作られたもの
だから古くて独自なんだよね。あとはjQueryスレでやろうか。 jQuery は、this を使えるようにしたのが功績
JavaScript では、thisが狂う。
thisがwindow を指してしまうので、あらかじめthisを、that に代入したりして使っていた jqueryがなかったらReactもvueもなかった
jqueryがjavascriptを変えた
感謝しろ thisがwindowとかstrictモードすら知らんのかしら 環境構築、vuecli(vue3)で、tailwind css3を使いたい。
npmでtailwindcssインストールするとエラー出るpostcss8周りでエラーが発生
tailwindcss2(postcss7)のパッケージは入るやり方は調べたが‥
vuecli+tailwind css3を使えるやり方求む。
tailwindcss2が入るやり方だとこんな感じでした。
npm install tailwindcss@npm:@tailwindcss/postcss7-compat @tailwindcss/postcss7-compat postcss@^7 autoprefixer@^9
代替案としては、vuecliで作ったプロジェクトフォルダー内でtailwindcssをインストールせずに、
別フォルダーに npm install -D tailwindcssで構築して、
tailwind.config.jsでvuecliで作ったプロジェクトフォルダーを指定して
npx tailwindcss -i input.css -o output.css とかで環境構築するしかないかなぁ >>711
> npmでtailwindcssインストールするとエラー出るpostcss8周りでエラーが発生
tailwindcss3を普通にinstallするとどんなエラー出るの？ vue createで作ったフォルダでnpm install -d tailwindcss をやると
npm WARN tailwindcss@3.0.7 requires a peer of autoprefixer@^10.0.2 but none is installed. You must install peer dependencies yourself.
npm WARN tailwindcss@3.0.7 requires a peer of postcss@^8.0.9 but none is installed. You must install peer dependencies yourself.
npm WARN postcss-nested@5.0.6 requires a peer of postcss@^8.2.14 but none is installed. You must install peer dependencies yourself.
…省略…
こんな感じですね。 >>707
昔に作られたからだめという考え方が終わってる
C言語なんかもっと昔に作られたもの
なぜ今も使われてるかを理解できないでしょｗ >>707
> イベント用関数のthisがDOMをbindするのは別に普通だよ。
ならDOM用のイテレータのthisもDOMであるべきってわかるだろｗ
DOMイベント用の例えばclickとかにデイジーチェーンでeachなどを
つなげるようにするためってわからないか？
clickはthisでアクセスするのにその次のeachはthisじゃないとか一貫性がないだろ
もう少し基礎というか設計能力を鍛えたほうがいい
オレオレフレームワークを自分で作ったこともないだろ
オレオレは使うものではないが、自分で作ることで技術を理解できる
おまえはまだまだってことだ >>713
vue create hogeでvue3を選択してインストールした後hogeに移動してtailwindcss3インストールしてみたけどエラー出ないな。
npm更新してもう一度0から構築してみては？ >>716
npm アップデートしたけどダメでした。
postcss.config.jsとか設定する前は、npm run serveはエラーでないんですけどね
これ見ながらやってました。
tailwndcss2と3の tailwind.config.js 設定違いは自分で修正してます
ttps://qiita.com/inainainariinainari/items/8050d9e431523d3b0135
npm run serveすると…
ERROR Failed to compile with 1 error 16:39:46
error in ./src/assets/tailwind.css
Syntax Error: Error: PostCSS plugin tailwindcss requires PostCSS 8.
Migration guide for end-users:
ttps://github.com/postcss/postcss/wiki/PostCSS-8-for-end-users
@ ./src/assets/tailwind.css 4:14-166 15:3-20:5 16:22-174
@ ./src/main.js
@ multi (webpack)-dev-server/client?http://xxx.xxx.xxx.xxx:8080&;sockPath=/sockjs-node (webpack)/hot/dev-server.js ./src/main.js
別フォルダーでtailwndcss3、autoprefixer、cssnanoの出力設定までは作ったので諦めてこっち使うかな＞＜ >>717
postcss8以上使えってモロに書いてあるだろ
エラーメッセージを読め >>718
入れたけどダメだったから質問してるんだよ これは試した。
npm install -D tailwindcss postcss autoprefixer --force
package.jsonはこんな感じ。
"devDependencies": {
"@vue/cli-plugin-babel": "~4.5.0",
"@vue/cli-plugin-eslint": "~4.5.0",
"@vue/cli-service": "~4.5.0",
"@vue/compiler-sfc": "^3.0.0",
"autoprefixer": "^10.4.0",
"babel-eslint": "^10.1.0",
"eslint": "^6.7.2",
"eslint-plugin-vue": "^7.0.0",
"postcss": "^8.4.5",
"tailwindcss": "^3.0.7"
},
.\node_modules\postcssを見ても
"name": "postcss","version": "8.4.5",となってる 前になったなそれ
グローバルにpostcss-cliとかpostcss-loaderとかの古いのが入ってるとか他のpostcssプラグインが8に対応してないとか
そんなんだった気がする 最近Reactで関数コンポーネントしか使ってないからthisってどう使うんだっけってレベル >>721
なるほどそういうことか。
俺はVue使ってないから最新の@vue/cliをインストールした上でnpx vue createした。
だから711の状況を再現できなかったのか。スッキリしたぜ とりあえず、jQuery使いが嫌がられてる理由がよく分かる流れだった😅
こんなのチームやそれこそPMにいたら地獄だろうな…😭😭 >>724
技術で反論できないからって
それはないだろｗ >>724
隔離して約款ページでも作らせるしか無いなw 認証はもうFirebase Authenticationとかで良いよね？ オンプレはどうするんや。
最近、オンプレへの回帰も多いで >>673
チートシート見たらわかるけど使うなっていってるだから俺は宣言文でやってるわ 関数型のarrow は状態を持たない、
computed property・計算値アクセスみたいなもので、this を持たない
ネスト内の無名関数も、this が無意味になって、window を指す。
callback の文脈が分からない。
異次元空間アクセス
だから、あらかじめ、that, bind で関連付けしないと使えない Ruby on Rails の作者・David Heinemeier Hansson(DHH)の、9/8 の動画ある。
もう、Rails 7
Alpha preview: Rails 7 w/ esbuild + Tailwind CSS
https://www.youtube.com/watch?v=JsNtLiph87Y どういう神経してたらこのスレにrailsがくるんだろう vuejsも最近は｢reactのこの機能、vuejsでもできるようにしました！｣ばっかりで｢それだったらreactでよくね？｣って感じることが多くなってきたな
htmlとjs部分をはっきり分ける形式のフレームワークだったら最近はsvelteがreactとは違う方向性を目指してていいと思った
今後はjsxが嫌だったらsvelte、そうでなければreactって感じになりそう はー、Reactだけ追ってるけど他は今そんな感じなのか〜 JSX最初は嫌いだったけどここで突き抜けて便利になるともはやこれでいいやってなるわ Vueは少ない学習で楽にSPAを組めるのがウリだったはずなんだけどただのジェネリックreactになってる
理想としたポジションはsvelteにとられちゃったね まあSPAはいうても使われる用途がホームページとかそういうレベルの低いところに限られてくるし
それ以上のレベルってなるとやっぱreactもしくは単純にjQueryのみで分かりやすくってなるからしゃーない 静的HPもNext.js使うしもうReactにどっぷりですわ reactはhooks推奨してからもう2、3年くらいたって
hooksの記事やサンプルも充実してるし
classコンポーネントから完全に移行できたけど
vueは今触り始めるのは最悪の時期だろうな 他の言語からjsとReactを初めて見る奴らはこの気持ち悪さに嫌気がさすらしい
その前に奴らはhtmlとcssすらまともに使えないんだが Next使うようになってReactがめちゃくちゃ楽しくなったわ
React単体だとかえって面倒なことになりかねない next.jsってシンプルなSPAでは必要無いように思うんだけど
どの時点から使うメリット出てくるんだろう むしろシンプルなSPAこそnext使うべきだよ
SPAといってもサーバーサイドを無視することはできないからね Ruby on Rails の埋め込みテンプレートERB では、
HTML, JavaScript も、a.html.erb, b.js.erb に、ERBで書いている
<% 〜 %>, <%= 〜 %>
だから、JSX の方が可読性が高い うろ覚えだけどNext.jsのREST部分ってExpressみたいな感じだっけ？ 型に厳格にできるFasify使いたくなる。 Fastify
https://www.fastify.io/
Node.js用の高速でオーバーヘッドの少ないWebフレームワーク そういうみんなReactとかいうこと言うと、
そもそもみんなReactやVueじゃなくてjQueryがほとんどじゃん
いや、煽ってるわけじゃないよ、念のため事実として言ってるだけね もちろんそうだが文字通り利用者数が多いだけで実体は
フロントにベタ貼りみたいな使い方がほとんどだから多いだけじゃないの 面接でjQueryの良さを語る奴がいたら秒でお疲れしたって言うね >>747
ルーティングの設定がいらないから、複数ページある場合はNextにした方が楽よ
あとは外部API叩きたいかつAPIキー隠したい場合なんかも、Next.jsでAPI書けるからいいんでないかね >>754
お前の知ってる様なそういうパブリックなWebサイトとかじゃなく
もっとクローズな用途なクラウドサービスのコンパネとか >>1にも話題禁止て書かれてるように
jqueryて、いやそりゃjquery便利だよ、でもそういうことじゃなくて・・
みたいな立ち位置だからな >758
面接でゲームプログラミングの技術の話をしたら
大人になってもゲームするようなやつは・・・なんて
言うやつもいるからなｗ
お前が正しく技術を判断できないだけやで >>760
なぜReactはパブリックには使えないのかって話だよね >>762
はぐらかすなよ
jQueryを使う人間はクソだと言う話をしてるだけだぞ 「jQueryを使う人間はクソだと言う話をしてる」アホがいるってだけだろ？
それとも78%以上のサイトがアホだという証明でもあるんですか？
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/ 詐欺サイトやゴミサイトのWordPressが自動量産されていくからこれからもjqueryはシェアを拡大していく >>759
SGでよければ外部APIキー使うときにgetStaticProps使えばAPI書くまでもないしね。
>>763
はぁ、Facebook, Salesforce, Paypal, Cloudflare, Twitter, Amazon 等そうそうたるメンバーがパブリックでも利用してますけども。
https://jp.quora.com/React-wo-shi-tsu-ta-daikibo-na-uebusaito-ha-nani-ga-arima-suka そうそうたるメンバーしか、パブリックで利用していない 面接でjQueryの良さを語る人が来ても別にお祈り確定はしないけど、ここで暴れてるjQueryおじさんみたいなの来たら即お祈りするわ >>767
重要なのはReactのシェアが増えないことだろう？
このグラフは100%を振り分けたものではなく
ウェブサイトで使われてる割合を示すグラフなんだから
jQueryのシェアが増えたからって別にReactの
シェアが下がるわけじゃないってわかってる？
Reactはウェブサイトで2.5%しか使われてないんだよ >>759
ディスプレイサイズに合わせて画像のリサイズとかwebp変換とかもやってくれるのも追加で
逆に素のReact使うメリットが見当たらんな
どっちも1回コマンド叩けばすぐに使えるし Nextってかssr、ssgできるようなフレームワークはライブラリによってはドキュメント通りに設定してもエラーになることがデメリットやな
Firebaseとかリッチテキストエディターとかエラったわ >>769
そら伝統的なほーむぺーじの進化系としての今のモダンなWebページと
AccessやVBやVC++で作られてたフォームアプリの汎用化としてのWebアプリじゃ求められるものが違うからやん
結局リテラシーが低いからそんな事も分からんのやろ？ >>775
AccessやVBやVC++で作られてたフォームアプリの汎用化としてのWebアプリ
は同じマイクロソフト系のASP.netMVCで作るっしょあれサーバーサイドレンダリングもコンポーネントもRaserで作れるし ReactからNextって簡単に移行できるもの？
何も知らん状態からReactで作ってる途中なんだけどメリットしかないなら移行する >>775
そうか、考えてみると昔の人はVB(非.Net)とかVC++なんかでアプリ組んでたのか……ひたすら辛そう。まぁ今のwebアプリより考える事圧倒的に少ないんだろうけど。 >>778
まぁアプリの方が作りはシンプルだけどトラブルあった時毎回現地に行かなきゃいけないみたいな不要な手間が相当あるからね Webにできるようなアプリを単体で配布したところでそんな手間がかかったりするかねぇ。
現場じゃないとできないサポートってどんなんだろ？ 昔地図系のアプリ開発やったあとの保守で定期的にデータ更新しにいろんなところ回ったりしてたで
当時はネットワークでアップデートって時代じゃなかったから当たり前だったわ Accessとかだとデータ破損がよくあるっぽい
自分が担当じゃないがそれでよく現地行ってる人が居る >>775
そんなこともわからんから
自分たちがReact使っだけで
ウェブ全体からjQueryがなくなるなんて勘違いしてるアホがいるんやで
現状はjQueryが78%以上使用されていて
しかもまだ増え続けてるんや >>784
別にjQueryがある事自体は否定してないよ
そらWebサイトは増え続けてるんだから利用実績は増えるやろ jQuery使いがjQuery使ってるのは好きにすれば良いよ。用途が違うからシェアがどれだけあっても関係ないし、俺たちも住み分けできて快適だ。
ここで暴れてる理由はまるでわからん 初期の頃用途が違う事が理解できずにVue民とかがjQuery民にマウント取りに行ったのを今でも根に持ってるんだろうな 脱jQueryとかアホなことを言ってるアホに
現実を教えてるだけだよ >>787
用途が違うのに最初に脱jQueryとか言って
使い物にならないものを普及させようとしたアホは誰かって話だ 一時期ブームになった脱jQueryは
すっかり鳴りを潜めてしまったしな
ようやく用途が違うって理解したんだろう
80%近くの人にはjQueryの方が適切だったんだよ >>789
スマンなその頃俺もjQuery民やったしウザかったのも覚えてるが
その後に実際にAngular、Vue、Reactそれぞれある程度使ってみて検討した結果自分の用途にはReactが合ってるっていう結論に達したんや >>791
アンケート結果
Reactスレに居る住民の100%はReactを使っていました
みたいな話か？ｗ >>792
出来合いの認証機構一式（ログイン、登録、パスワード再発行辺りの機能）をそれぞれのフロントFWで置き換え実装してみた感じだが オーケーわかった。用途が違うしシェアも大きい。納得したから帰ってどうぞ jQueryっていうか昔ながらのMVCがなんだかんだで一番ユーザーに受け入れられるってことなんだろうな
なのでMVCにCDNのreactってスタイルを洗練させて普及すれば数年でjQuery駆逐できると思う >>795
Reactはあらゆるものの部品化を洗練していくことで開発効率が上がるパターン >>796
そうだね
じゃあそれでMVCを洗練させていくのがシェア伸ばす近道だと思うよ そもそも使ってるところは使ってるんだから無理にシェアを増やす必要なんて更々ない シェアの大きさはライブラリの寿命に直結するから多いにこしたことはない
10年間メンテなしで安定して動くツールと頻繁にメンテしないといつ動かなくなるかわからないツール
ビジネスって常にコストパフォーマンスだから内容自体が相当に良いものじゃないと後者が勝つことはまずない >>799
シェアは比率であって絶対数じゃないんだから分母が大きい分仮に5%とかでも他の言語の規模に比べたら相当な数になるんだが それだけライバルの絶対数も増えるということだよ
経営判断をするときには統計、割合のほうが重視されるのは当たり前のこと >>777
わりと簡単に移行できるけど、React覚えてからの方が混乱は無いと思うなぁ。Next.jsはあくまでもReactの延長線上にあるし gatsbyちゃんはお亡くなりになったのかしら…？ jQueryは時代遅れの産物
JavaScriptによる操作が弱くて不十分だった時代そしてブラウザ互換性が弱かった時代に有用であった
今はjQueryは不要
一方でReact万能主義の人もおかしい
Reactが適しているのはある規模のある用途での利用のみ
規模や用途が外れればReact以外が適していたり効率良かったりする >>805
やっぱり理解してないねｗ
jQueryはブラウザDOM APIを改良したもの
DOM APIを使うぐらいならjQueryを使う >>807
仮想DOMを用いるため直接DOM操作と無縁なReactやVueの方々がいるこのスレで
「DOM APIを使うぐらいならjQueryを使う」の主張は滑稽
とはいえ仮想DOMはベストではなく今では無駄な方法とみなされている
仮想DOM方式が敗北した原因は差分検知を実行時に行なっているため無駄が多く重くて遅いこと
Svelt等の仮想DOMを用いない方式では差分検知をコンパル時点で行なっているため軽くて速い
もちろんSveltでもjQueryのような昔の遺物は当然使わない
例えば以下の記事などを見ればjQueryがいかに無駄なのかすぐに理解できるであろう
Hey！そこの君！ jQueryからSvelteへ乗り換えてみない？
https://qiita.com/oekazuma/items/4d7035437e96850c6666
【Svelte入門】jQueryでよく作る機能を新しいJavaScriptフレームワーク「Svelte」で再現してみた
https://canvaspace.xyz/blog/301 >>771
君頭が悪いの？
シェアとかなんの関係があるんだよ
お前が使う分には何も止めないし使えばいいよ
それを押し付けるなと言う話をしている jQueryUIとjQueryMobileはメンテナンスモードになったし衰退は明らか
jQuery自体もshadowDOMやslot向けのAPI無いから直接DOM触るしか無いからな
機能不足が目立ってきたし役目を終える日は近いだろう >>809
シェアは評価だからね
世間の評価、俺とかお前が使ってるなんて狭い話じゃなくて
世間の評価を見ましょうって話 >>808
jQueryからの移行記事があふれるってことは
移行してない人が今も多いってことだよ
Backbone.jsから乗り換えましょうとか
聞かないだろ？ >>810
> jQuery自体もshadowDOMやslot向けのAPI無いから
追加すりゃいいじゃん？
アホなの？ >>811
じゃあgithubのスター見ようか？
評価なんて人によって違うんだよ
だから言ってるの YouTube で有名な、雑食系エンジニア・KENTA のRuby on Rails 初心者用サロンは、
月千円と有料だけど、日本6位の3千人
一方、Vue.js の日本ユーザー会も、3千人
単なる1個人の有料Railsサロンと、日本全体のVue.jsが同じ人数。
React は、もっと少ない。
つまり、そういうのを使う所がない
Railsでは、React, Vue.jsも使うけど、
Bootstrap, jQuery だけで済ます規模もある
Railsでは、2億レコード・取引先が2万社ぐらいでも、大丈夫。
2021年10月には、Railsを使い続ける宣言をしている、GitLab が上場し、時価総額は約1.9兆円！
つまり、時価総額1兆円ぐらいまでは、Railsで行ける
Rubyの女神・池澤あやかは、Ruby biz Grand prix 2020の大賞を取ってるけど、
その時に、他のフレームワークでは開発者がいなくて、
結局、Railsで作る事にしたと言っていた
Rails以外のフレームワークは難しいから、まともに作れる開発者は少ない。
可読性も悪いし、開発者を集めにくい >>810
jQueryUI絶賛してたバカが職場にいて
結構なところで使ってる
そのコードをReactに移行したいが相当厳しい
何も楽しくない上にテストもない
マジでクソ厄介なもん入れやがったわ >>810
jQueryUIって今となってはかなり旧式の外観だしな
jQuery使うにしてもUI/UXコンポーネントにjQueryUIを使うってのは今となってはナシだよな
見た目に関してはBootstrapとか使った方がいいしな >>814
じゃあ、評価じゃなくて
実際にどれだけ使われてるかで話をしましょう jQueryおじさんやRailsおじさんは人の話聞かないんだからほっときゃ良いのだ。ページ数が開発者の支持を示してるなんて言ってるあたり業界人ですら無いんだし >>808
Svelteってlet多用するんだなぁ。シンプルだからWebに慣れてないうちは良さそうだけど、本格的なアプリとか作るには辛そう。 >>821
どういうこと？let多用が危険そうって事？
コンポーネントに閉じるものしかletにしなかったら大丈夫だよ。
Svelteの良いところはまさにそういう「小回りが利く」部品が作れるところだと思う。
超大作SPAも作れんことは無いと思うけど。 >>822
あぁコンポーネントに閉じれるのか、なら全然良いや Svelteはどーもやる気せんわ
モバイル開発でrn、fltに並ぶようになってからだな手つけるのは >>820
何いってんの？開発者の指示と現実は違うってことだよ
昔CoffeeScriptとか人気だったじゃないｗ
でも現実は廃れた
もっと現実を見ようよ。人気でも使われてないんだよ。 CoffeeScriptとかあったな〜。JSが進化して不要になっちゃった >>826
reactもいずれこうなるのかな？
シェア低いとどうしても不安よね Reactの機能がブラウザに取り込まれでもしない限り（そしてそんな事は標準としてはやり過ぎなので）無いんじゃないかな。
仮にReactが死んでもポストReactが出てくるだけだろう そうなると載せ替えがまた面倒そうだな
それが仕事になって金が貰えると考えると労働者としては悪くない話だが モバイル開発でのRNは終わりつつあるだろ。
むしろWebViewがどんどん安定してるしWebでの画面構成があまりにも楽なので、PC版はelectron、モバイル版は自家版WebViewアプリとかCapacitorみたいな組み合わせ増えてない？
Flutterでアプリ公開してるけど、次作はWebViewアプリに原点回帰しつつある。
Cordovaは早すぎた。 なんだかんだで品質も生産性もネイティブのが数段上だよ
WebViewは品質は二の次でウェブ開発者しか居ないときの選択肢
ストアで一流のアプリを眺めて見ればわかる
WebViewメインなんてほとんどない 逆にもう大概確定シェア層があるんだから今更廃れるとか気にする必要ない
もっといいと思えるものが出たんであればその時乗り換えればいいだけ >>833
その乗り換えコストが嫌なんだよ
だからウェブ世界の中心であるMVCのサポートを手厚くしてReactの地位を盤石のものにしてほしい
SPAにこだわってたら未来ないよ 定期的に現れるMVC大好きマンは一体何なのだ。いつの時代から来たのだ。 >>834
いや、お前は無理して使わなくていいよjQueryでも使ってなよ >>835
JUST NOWだよ
君のいる平行世界ではSPAが世界シェアの大部分を占めているのかい？ >>832
気づかんレベルになってるだけでは？
ノートアプリのObsidianとかWebViewベースだけどサクサクだぞ。 >>837
SPAとMVCは直接関係ない概念では？ >>810
jQuery使うメリットとして唯一存在していたjQueryUIもオワコンなのかよ
ついにReactやるしかないかー
でも独自UI作るのしんどいんだよなー >>841
jQueryUIが使う理由ってやっぱりわかってないじゃないかｗ
jQueryUIは昔から使う意味がなかった
jQueryはDOM APIの改良版だから意味がある DOMの改良版だったのは昔の話で、DOMが改善された今では劣化版じゃね >>842
ゼロからUI作るのが面倒だから使ってるんでしょ
あとIEが死んだ今DOM APIは統一的に書けるのだが >>843
比較記事ならたくさんあるでしょ？
jQueryをDOM APIで書いてみた＝数倍に行数が膨れ上がってしまった
これが結論ですよ
DOM APIは改善されてない
機能が追加されただけで
互換性がある＝昔のまま >> あとIEが死んだ今DOM APIは統一的に書けるのだが
あはは、jQueryは生産性の改善なのに
まーた的はずれな批判してるｗｗｗ 昔jQuery使ってた頃もajax関連の処理かセレクターで属性変更系の処理が大半だった記憶があるが
それなら今となっては素のjsでもそんなに困らんがなんかそれ以外で重要な恩恵ってなんだっけ？ React使えば数行どころの改善じゃないしバグも減る。目先の数行で一喜一憂するような、小さいプログラムしか組んだこと無いうちは理解できないだろうけど >>846
ちゃんと>>808の記事を見た？
Svelteで書かれた同等のものをjQueryで書いてみた→数倍に行数が膨れ上がってしまった
これが結論ですよ
jQueryは完全に時代遅れ >>850
Svelteがいいか悪いかは別として高々数十行数の例題の行数の増減に拘るヤツは無能やろ >>848
jQueryの恩恵は生産性の向上
DOM APIで書くよりも数倍シンプルに書くことが出来る >>850
$('.class').on('click', function() { alert("ok"); })
これをSvelteで書いてみて >>851
うっわｗｗｗ
Promiseって、jQuerryの方が先にDeferredとして採用した機能で
その後にPromiseが標準化された後はDeferredはPromise互換になってるんやで
調べてみたらjQuery 1.5でリリースされた機能だから2011年、もう10年以上も前から使ってる機能
お前はそんなことも知らんのや。最近Promise知って自慢気にでもなってんのか？ >>857
jQuery自体はまだまだ現役だけど
jQuery〜って派生モノが結構終わってきてる jQueryの派生物って結局デザインの部分で
そこはCSSを使えばいいだけなんだよね
jQueryはクラスとか属性を操作するもの
で、そのデザインは変わりやすいもので
Reactとかは結局CSSのアップデートで不要になっていく なんでjqueryの話になってんの？
専用スレでやればいいっていうかそっちいけ >>856
実質されてないみたいなもん
進化も退化もないからメンテは要らんと思うけどね
オリジナルの作者がもう違うことやってるし投げ出した
今思えば酷いコードだ
彼とは昔shibuya.jsってところで会ったことがあるのだけど jQueryの作者についてググったら、2016年にはもうReactに乗り換えてるじゃん >>855
それを言えば元々はpythonのイベント駆動のフレームワークが起源だよ
それを取り入れた >>864
そういうのって結構多いんよね
Pythonの作者もPythonコミュニティ抜けたし
Delphiの作者もMicrosoft行ったし >>864
本人に取っても黒歴史だろうね
こんなきちがい信者まで産んじゃってw >>866
Pythonの作者は「ヲタク君たち見てる〜？ 次のリリースはMSのみんなのおかげでぇ、超早くなりま〜す♡」とかMicrosoftからNTRビデオレターみたいなの出してたぜw IT分野は言語でもフレームワークでも何でも同じだけど
出来る人たちはある程度の期間が経ったら新しいものへちゃんと乗り換える
細かく見ればそれぞれの期間でも適材適所で複数を使い分ける
一方でダメな人たちは一つのものに依存 >>854
短さにこだわる割にfunction使うのか…… そもそもReact/Vue/Svelteのどれもイベントハンドラの為にわざわざセレクタなんか使わないからね
jQueryに囚われすぎて思考が狭くなってるよ
もう少し勉強した方がいい
それにjQueryのonで登録したハンドラはoffで開放しないとリークするけど
他のライブラリは管理不要になってるからね
半端な欠陥コードの真似をしろと言われても困るよw 小規模では、jQuery は圧倒的
これを素のJS で書いたら、コードが数倍になって、バグだらけで使えない。
生産性が悪く、長時間労働になるから、
コストが高くなって、時給が減る
Deferred, Promise もある。
Ajax も皆、jQuery を使っていた。
それを最近は、axios に分離した
LoDash も良い >>874
jQueryは地味に罠が多いし、独特だし、インターフェース設計古いし、ネット上の解説コードの品質が低いし、なんでも文字列だし、 バグ増える印象ある。
歴史が長いし、作られた当時は何もなかったから仕方ないんだけども。 >>870
thisが使えるから、こっちのほうが短くなりやすい
>>871
DOM APIとの互換性 >>875
何もしないでokって出せるのか凄いなｗ
いいから動くもの出せよ >>877
自分が無能なものをライブラリのせいにするな >>872
> それにjQueryのonで登録したハンドラはoffで開放しないとリークするけど
なんでいちいちボロを出すんだｗｗｗ
最初からリークしないように設計されたんだが
歴史の話をしてやろうか？
古くかIEでattachEventでハンドラを登録した時ページ移動しなければ
メモリリークしてしまう問題をjQueryは解決したのが売りの一つだった
DOM APIの先はJavaScriptの領域外のブラウザのAPI（ActiveX？）だったため
JavaScriptの参照ポインタが機能しないのが根本的な原因
だからそれを解決するため、俺の記憶が間違っていなければ
オブジェクト（イベントハンドラ）を直接参照するのではなくIDを使った
ウィークポインタのような仕組みを使ってハンドラを管理した
DOM APIに直接登録するのはjQuery自身のイベントハンドラ一つで
いくつ登録しても、内部のハンドラマネージャーがうまいこと
転送するという仕組みで実装されたからメモリリークしないのがjQuery >>865
ちゃんと書けよ
それを言えば元々はpythonのイベント駆動のフレームワークが起源だよ
それをjQueryは取り入れた
だからPromiseと同等のものにJavaScriptプログラマ触れたのはjQueryが先で
jQuery使ってるプログラマがPromiseを知らないとかありえないだろ
お前が知らんだけじゃんかｗｗｗ
って話の流れだろ jqueryジジイさんは会社や開発でjqueryすごい！Reactクソ！って言ってjqueryのみで仕事してんの？
それともWebサイトしか作れない底辺？ >>878
たった4行でここまで無能を晒せるとか凄い奴だな >>883
DOM APIは互換性が高くなった。だから
DOM APIでやればいいって言ってるやつがいるだろ？
DOM APIだけでやってるよ。ただしjQueryという便利なライブラリでラップして。
わざわざ自分でDOM APIを簡単に使えるラッパーを自作するなんてアホでしょう？ >>881
それIE固有のリーク回避処理でしょ
IEサポート外した時にIE対処コードは除去されてるよ
しかも上位ノードでイベントバブリングを捕捉した後のコールバック管理の話とごちゃ混ぜになってるし
記憶の整理もできてないのにどうしてそんなに自信満々なんだろうか >>887
は？jQueryがリークするって言ったのお前じゃん
じゃあIEのリーク以外にイベントハンドラでリークするっていう
デマ（笑）はどこから持ってきたのか言えよ
まず最初にお前が記憶（捏造）をはっきりと書き出せ
IEの時点でリークが回避されてるっていうのに
on使うだけでリークするわけがないって、少し考えればわかるやろ しかも上位ノードのイベントバブリングとか
全く話に出てきてないことを言い出すし
な？こういうことだよ。jQueryをわかってないで批判してる > IEサポート外した時にIE対処コードは除去されてるよ
IEサポート外なら、メモリリークしないということになるだろｗ
IE以外ではメモリリークしないんだろ？ >>882
いやだからお前が無知って話なんだが？
本当の起源を知らないでjQueryが起源だ！と言ってる無知なあなたを咎めてる 「jQueryが起源だ」でこのスレを検索しても何も見付からない
自分で嘘つきであることを証明した瞬間ｗ jQueryおじさんはどんなアプリ作ってるか（仕事してるか）とか、大きいアプリ作った事ない疑惑に関してはきっちりスルーするね JavaScriptよりも先にjQueryの方が
Promise（Deferred）を採用したって俺が言ったから、
それにムカついてるのか？
起源なんて書いてないがｗ >>895
誰もが知ってる超大規模ウェブサイトだな >>893
メモリリークするIEが死んだんだから
jQueryもメモリリークしないで終わる話
お前がいい出したんだぞ >>896
それを起源って言うんだよw
日本語もわからないの？ >>898
いやそれは俺じゃないぞw
お前みたいに自演などしない >>899
なるほど
JavaScriptよりも先にjQueryの方が
Promise（Deferred）を採用したって俺が言ったから、
「jQueryが起源」という意味に勘違いして
あらしてたのかｗｗｗ
な？こういうやつなんだよ >>902
起源に論点ずらしてるがまずその認識が間違ってるのよ
jQueryのはtwistedを参考に作られたの
それを知らなかったよね？と言う話
あなたが無知を論点にしてたからそれを咎めたの
わかる？
起源の話はしてない
jQueryは凄くないと言う話をしてる >>888
うーん文意読み取れない？
onのリークとIE固有のリークは別物だよ
さらにその2つとも関係ないjQueryの実装の話も混じってるよ
と補足したらわかるかな？
リークはonとremoveChild繰り返しで簡単に確認できるよ 891 返信：デフォルトの名無しさん[sage] 投稿日：2022/01/11(火) 12:21:35.79 ID:P6YErMSE [3/7]
> >>882
> いやだからお前が無知って話なんだが？
> 本当の起源を知らないでjQueryが起源だ！と言ってる無知なあなたを咎めてる
899 返信：デフォルトの名無しさん[sage] 投稿日：2022/01/11(火) 12:28:28.28 ID:P6YErMSE [5/7]
> それを起源って言うんだよw
903 返信：デフォルトの名無しさん[sage] 投稿日：2022/01/11(火) 12:36:39.36 ID:P6YErMSE [7/7]
> 起源の話はしてない
わろたｗｗｗ >>904
> リークはonとremoveChild繰り返しで簡単に確認できるよ
reactとDOM APIを混ぜて使って
reactはメモリリークするって話をしてるんですね
「お前がアホ」で終わるよねｗｗｗ 恣意的な編集して論破とか言ってる恥ずかしい人がいる…… いつもの勝利宣言だから、もう書き込まないでしょうｗ あ、間違えた。論破してる人と恣意的編集してる人は別だわ。
論破は確かにしてるわ >>910
IDを見ずに内容から、こいつキチガイだって判断したんだろ？ｗ
それが事実だよ >>911
恣意的な編集してる方が普通にキチガイだよ >>912
自分の判断に素直になれよｗ
誰も起源なんて言ってないのに
「恣意的な編集して起源って言ったニダ！論破したニダ！」
って言ったほうがキチガイに決まってるじゃんかｗ ここのスレタイとテンプレみて居座る奴がまずキチガイ >>913
突然ニダニダ言い出してどうしたの？
もうすぐ超大規模ウェブサイトの端っこで惨めに数行減らす作業の時間だよ？ >>915
jQuery使ってるから、すでに最小の労力で
プロジェクトは完遂してるぞｗ >>916
jQuery以外には何使ってるの？ jQuery以外の部分は触らせてもらえないんだろうけどさ >>917
それに答えたらなにかいいことでもあるのか？
GCP使ってるけど？ >>918
執拗に回答を避けてるからなんでかなと思って。GCPとか全然回答になってない事言うし はぁ？やってることってプログラミング環境全てじゃん
RubyとかPythonとか言えばいいのか？ >>920
普通GCPの〜を使ってるって言い方するでしょ。GCPって言い方は変だよ、明らかに reactその他と良し悪しを比較するなら意味があるだろうが、じぇーくえりーしか知らん奴のゴリ押しは無価値なんだよなぁ jQueryくんはなんかそっち系のスレ出来てるからそっちいって Ruby on Rails 6 でも、Bootstrap 4 を使うと、jQuery が自動的にインクルードされている。
React, Vue.js, Bootstrap 4 で、jQueryも使う
Bootstrap 5 で、jQueryは削除されたけど、まだpopper.js は使っている
Rails 7 では、外人のYouTuber のRailsのすべての学校・サロンは、
ここ3か月で、脱webpack のesbuild の動画を一斉に上げた！
すごい。全員が最先端を攻めている Railsはどうでもいけどesbuild使うとビルド速くなる以外にメリットあるのかな？ ★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。 Rails7がもつフロントエンドへの「答え」、2021/9
https://zenn.dev/kenzan100/articles/0f9b100655a4bf
Rails 7 をちょこっと試す（さらば、Webpacker 編）、2021/9
https://qiita.com/suketa/items/837eb97bdb48dd8c4688
規約だけのフレームワーク・Stimulus が入った。
React, Vue,js, Stimulus の選択
Foreman が入った。
JavaScript のbundle には、esbuild, rollup.js, webpack の選択
Bootstrap, Bulma, Tailwind, PostCSS, Dart Sass をサポート。
DartSass 以外の、Ruby Sass, node-sass(LibSass)は滅んだ
SASSでは、グローバルスコープの@import を廃止して、
ファイルスコープの@use へ変わる NextとFirebaseでSNSっぽいの作ってみて思ったんやが、NextとかNuxtとかのフロントエンドのフレームワークって、フロントエンドの技術メインで全部やろうとしたら有用やなとは思ったが、バックエンドちゃんと書けたり書ける人おるんやったら、いらんかもと思ったんやがどう思うよ
古い感覚なんかもしれんがロジックは基本バックエンドで書いて隠蔽して、フロントはjson要求したりjsonの色付けだけの方が、構成として綺麗かなーとは思ったんや
フロントでゴリゴリとロジック書いてて、これええんか…？って思ってまう
Railsみたいなフルスタックから、フロントやバックとかを分離する方向に時代は向かっとるとは思うが、Nextもフルスタックになりつつあるし
フロントがSPAとかSSGになってんのは体感速度爆上がるからそこはええと思うんやがな ユーザーが何でも変更可能なクライアントのコードで
全部やったら不正しまくりだろ
フロントエンドで重要なことをしたらだめに決まってる Nextは別にフロントバックエンドがゴッチャにはならんでしょ、シームレスにも出来るってだけで。バックエンド好きなもの使えるし。
FirebaseというかFirestoreはたしかにそんな傾向あるけど、そこは考え方を転換すればセキュリティを担保できるし、必要なとこはFunctionsでやればいいのだ。 >>931
要らんと思う
フロントはあくまでAPIクライアント フロントしか開発したことない人が使うには良いんだろうね
バックエンドも触ってる人からみれば分離した方が開発も運用も楽っての当たり前に理解しているし jQuery時代の人なら普通にバックエンドも
プログラミングしてたんだけどね
派手なものを簡単に作れるから
基礎技術ができてない人が多い 別にReactとかじゃなくてもフロント改変なんていくらでもできる
なんならパケット直いじりツール使えばどんなシステムでも変更できるし ちょこちょこNext.jsやFirebaseやった事ないのかズレた事言ってる奴が居るな…… >>931自体がNextを要らないと言っているのかSPAを要らないと言っているのかポイントが絞れてないからじゃね？ ついにnext.jsを使うプロジェクトを開始したぞ
ちな俺はサーバーサイドもフロントもガッツリやったことがある
その俺が評価してやんよ
ミスったら俺の首が飛ぶ 利用者の体感利便性を考えたら
まずはページ再送出をしないCSR/SPA化が今では必須でしょう
更に最初のアクセスページのためにCSRだけではダメで最低限SSR併用か可能ならSSGが必要
バックエンド開発者もこの変化についてこれない人は
CSRのためのAPI対応しか出来なかったり
もっと古い人はCSR未対応の古きSSRオンリーしか出来なかったりで
なぜ「CSRとほぼ同じコードをSSR/SSGする必要があるのか」さえも理解できていないようです SPAで利便性がよくなるか？という問題は場合によるとしか言えんからなー
シンプルなMPAのほうが使いやすいと感じるケースは未だに多い
SPAが必須と考えるのは開発側の独りよがりだよ まあでもSPAのほうが余分なもの読み込まないぶん若干ページ遷移早いよな
そこだけは褒めてやるべきだとおもうわ
まあ作り手の面倒は増えてるし回線速度が速い現在に本当に必要なのかは疑問だけど >>942
SPAは毎回ページまるごと送出しなおしのMPAよりも以下の利点がある
・サーバーの負荷減少
・トラフィックの減少
・ブラウザ側での表示書き換え減少
・ユーザーの待ち時間減少 (体感の向上)
つまり全てにおいてエコで優れている
もちろんSPAに加えて前述のように最初のページアクセス待ち時間減少のためにSSR/SSG併用
デメリットは「技術の低い人たちは提供できない」 ユーザー目線で言うと非SPAはリロード時、遷移時に画面がしっかりリセットされる安心感があるんだよな
なんか動きが変な気がしたらとりあえずリロード、戻る、適当にハイパーリンククリック
それでまあまあ具合がよくなると経験的にわかってる
これは非常に重要なんじゃないかな
たぶん何も知らんユーザーからするとSPAは巨大でミュータブルなオブジェクトに見えてるんじゃないかとおれは考えてる
逆に非SPAはほとんどイミュータブルな関数に見えてる
もちろんプログラミングの素人であるユーザーがイミュータブルとミュータブルの違いを認識してるはずは無いんだが
ぼんやりと感覚的にその違いを使い勝手という形で体感してるんじゃないかな >シンプルなMPAのほうが使いやすいと感じるケースは未だに多い
MPAの方がシンプルってそれこそ開発側の視点じゃね？
ユーザーから見てシンプルだというなら仕様が違うものを作っていることになるわけで、そもそも比較にならない。 場合によってはSPAのほうが想定すること少なくて楽。
それはそれとしてSPAが適するかどうかは用途次第。なんだけど、最近MPAはSSGとSPAのハイブリッドばかりでSSR作って無いなぁ >>945
一般ユーザーはそこまで考えてないと思うし、そう思わせるならUIが悪いと思うな。個人的な意見だけども >>944
・サーバーの負荷減少はユーザーでなく運用側のメリットで今はユーザー視点のメリットについて議論しているのでは？
・トラフィックも同様
・表示書き換えは、、、SPAのほうが増えてないか？
・ユーザーの待ち時間は減る傾向が見られるね
・技術力が低い人に提供できないのはユーザーにとってはデメリットだね
つまりそれだけ利便性の高いサイトが少ないということだから
こうして一個一個深堀していくとやっぱりユーザー目線ではデメリットのほうが大きい気がするなー
ウェブIDE、オフィス文書編集、BPMエディタ、、、この手の従来デスクトップでしかできなかった超複雑なツールをブラウザで提供出来るようになったのは凄い発明だけど
何でもかんでもSPAってのは典型的なミステイクだね
未だに世の中のほとんどのサイトは従来の非SPAがマッチしてるよ >>946
ユーザー目線でも開発者目線でもどっちもシンプルということだね >>945
それはそのサイトのバグです
>>949
普通に正しくSPAが作られていれば
ユーザーにとって見た目やUI自体は同じです
その上で反応速度の向上による体感の良さをユーザーは得られます
一方でSPAはサイト提供側にもメリットが大きく
サーバーの負荷減少と送出トラフィック減少により支出コスト(費用)を減らせます >>950
そうじゃなくて、同じ機能、同じ画面仕様のものをMPAとSPAで作ったのに
ユーザーから見て一方がシンプルに見えるのはどのへんが違うのかという話。 バックエンドがどれだけ地獄になろうが知ったこっちゃない
って話なら確かにフロントエンドは何の機能も持たせず極限にシンプルに出来るね >>954
やっぱりフロントエンドしかできないやつはこの程度ｗ >>954
それやるとjsonを装飾するだけのフロントになるねw
>>955
jQueryおじさんはフロントもバックエンドもわかってないじゃん。どんな技術使ってるか尋ねられてGCPとか答えてたしw 現代の多くのユーザーとこれからのほとんどのユーザーはネイティブアプリ触りまくってるから、ネイティブアプリっぽい動きできるspaの方がユーザー体験いいやろな >>956
使ってる技術なんだからGCPは間違いない
普通はデータベースなんかも使うだろう
まさかお前フロントJavaScriptしかやったことないのか？ >>957
はっはっは、思考停止
現代の多くのユーザーが触りまくってるというのなら
ウェブサイトを触りまくってる
Amazonがゲームみたいなインターフェースだったら
使いづらくてしょうがない >>958
尻尾出すの早いよw
Linuxバリバリ使えるしそれこそクラウドも使えるよ。ちょっと年季入ったフロント屋ならバックエンド書けるのなんて普通じゃん。
さて、どんなDB使ってるのかな？ >>959
ゲームみたいなインターフェースの是非は話してへんでおっちゃん
あとAmazonのネイティブアプリはおっちゃんが作れるウェブサイトみたいにベージ遷移の度にベージ全体読み込まへんで
一回Amazonのアプリをスマホにインストールして確かめてみたらええで笑
おっちゃんはスマホアプリでゲームしかしてへんのは分かったわ笑笑 >>962
百花繚乱な今から考えるとスゲー長かったなぁ…… おめえらゴミクソでまったくSPAの利点を理解してなくて萎えた Ruby on Rails 5 からは、デフォルトでTurbolinks を使って、SPA, Pjax。
他にも、API モードもある
Turbolinksは、リンクのクリックイベントやWebブラウザのナビゲーションイベント（進む/戻る）を監視し、
通常の遷移イベントをキャンセルします
代わりに非同期通信（XMLHttpRequest/Ajax）で遷移先のページを取得し、
現在のページのheadとマージし、bodyを差し替えることで、ページ遷移したように見せかけます SPA の利点は、JavaScript のパース時間が無くなる事だろ >>960
人に聞く前に自分で答えろよ
お前ひろゆきか？相手に喋らせて
ボロをだろうとするやり方だってバレバレなんだよ
で、お前は何使ってんの？ >>968
SPAはJavaScriptが複雑で巨大になるんです。
だからJavaScriptのパース時間を少なくしないといけないんです。
こんな感じだよなｗ >>969
さんざ人の揚げ足取っといて（取れてなかったけど）自分が取られるとそんな事言い出すのか、惨めだな〜 MPAでもSPAでも速い配信は（技術があれば）やり方次第で可能だし、見せ方次第で違いなんてわからなくなる。要はコンテンツや技術に合わせてスマートな設計をする事が肝要じゃないかな。ハイブリッドでも良い。
仮にECサイト作れと言われて、規模等にもよって設計は変わるだろうし、ここの住民でもみんなそれぞれ違う設計するでしょ。 >>972
いや、だからお前がSPAを根本的に理解してないからそんなゴミクソみたいな判断しかできないんだよ >>973
急にどうした？
別にSPA否定してないし、反論あるなら具体的にね？ SPAってもうクライアントアプリじゃん
普通のWEBアプリしか理解してなさそう まあSPAってぶっちゃけ使えるのホームページレベルぐらいで
大規模なのになってくると画面数が多すぎてMPAになるからねー >>976
ホームページしか作れない無知のゴミクソは黙ってろ 安い喧嘩売るだけじゃなくてさぁ、もうちょっと内容で語りなよ >>976
SPAはアプリですよ
代表例としては Google mail とか
自分も数年前から普通にキオスク端末を
PWA(SPA)で設計してリリースしてますし
今もみなさんも店頭で使うことできます >>976
OSがWindows7でブラウザはIE使ってそうなおじさんだね TwitterもSPAなんだよね。知らないとそうは見えないだけで >>971
なんで、人に何使ってんのって聞いておいて
自分が同じ質問をされると答えられないの？
おかしいよね >>982
仕方のない人だな……DBで良いんだよね？
場合によるけどFirestoreやPostgreSQL使う事が多いよ、Postgre使うのはjsonbがあるからだけど。
さて、君は何使ってるのかな？ MPAて未だに鯖でHTML生成してんの？
React開発経験した後だと非効率過ぎて嫌にならん？ >>983
PostgreSQLとかMySQLとか使うけど
で、何のためにそんな質問したの？ >>984
なんでHTMLを生成する場所が
サーバーからクライアントに移動しただけで
効率が変わると思ってんだ？ >>987
GCPだとCloud SQLっていいますね。
それで？
何のために聞いたのさｗ な？結局こういうことなんだよ
揚げ足を取るために質問してるから
答えても何も言い返せない jQueryを使ってる人は、フロントエンドだけで全てが作れるなんて
思ってないからサーバーも含めて幅広い知識を有している >>988
最初からそう言えば良いのにGCPとか漠然とした事言うから確認しただけじゃん >>991
で、その質問に答えると黙るのはなぜってこと
揚げ足を取るのに失敗したねぇｗｗｗ 答えが漠然なのはそもそも質問が漠然だから
React以外に何を使ってるかなんて聞かれたら
そりゃそれ以外のいろんな事を言うに決まってる >>992
じゃあもっと聞こうか？
CloudSQLと何組み合わせてるの？ >>994
俺は質問に答えたんだから、次はお前。
何のために質問したのか答えろ。
もっと言えばお前がFirestoreやPostgreSQL使ってるんだろ
それと何を組み合わせてるの？
そしてそんなことを聞いてどうするの？
お前が質問に答えた上で
俺の質問に答えろや
話はそれから ほんともう揚げ足取ろうとするのがバレバレなんだよ
まじ劣化版ひろゆき屋でｗｗｗ >>986
やっぱお前ガチで何もわかってねえじゃん
その間違った知識しかないからSPA使えないんだよ
レベル下がるからあっちいけ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 238日 2時間 21分 45秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
