Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
Svelte
https://svelte.dev/
solid.js
https://www.solidjs.com/
※前スレ
Vue vs React vs Angular vs Svelte Part.8
https://mevius.5ch.net/test/read.cgi/tech/1621744952/
Vue vs React vs Angular vs Svelte Part.9
https://mevius.5ch.net/test/read.cgi/tech/1642316774/
Vue vs React vs Angular vs Svelte Part.10
https://mevius.5ch.net/test/read.cgi/tech/1646747836/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。 sveltekitは更新が頻繁になりすぎてJSDocが外れてる？ 今出てるといってるのはプレリリース版だよね？自分は補完とか機能してるよ。今使ってるのは多分1週間前ぐらいにでたやつ 1.0.0になってからcreate svelte@latestが極端に遅い… Reactはどんどんマニアックになってってるな。useEffectで開発モードは2回挙動
ふ、ざ、け、ん、な Reactは言うほど変わってる感無い。根っこの部分はブレないし。Nextは何なんすか いつのまにかVueの推奨Piniaになったのか
Vuexどこいった Vue使ったことないけどなんか3になって混乱が広がっているらしく、今後も使わなさそう そもそもVueもReactも落ち目だからな
誰も使っていない
バックエンドフレームワークに回帰してる バックエンドフレームワーク（Next,Nuxt）流行ってるな！ 結局VueかReactじゃんっていう
レンダリングがサーバかクライアントかってだけ Vueは3になってからかなり書きやすくなったよ
TSとの相性も良くなっからIDE補完もよく効くし 最初からVue3ならなんの問題もないけどPython2→3並の環境変化がいかんかった ReactもTS対応してるのね
どっちもやれって話だけど自分の頭のキャパ的に片方しかやれないだろうし迷うなあ とりあえずvue触ってるけど
まだcssで自由にレイアウトすることができない自分が大問題 初めてやるならReactにしなよ
わざわざマイナーなvueを選択する必要はない useEffectの依存関係をきちんとメンバー全員が
理解できるかどうかでreactでやるかvueでやるか
検討したいところ vueって重いイメージだったけど3試してみたらかなり軽くなってたわ
何か大きな変更でもあったのかな Vue3はベンチマークだけ見るとpreactやsvelteよりパフォーマンスが良いからな
solidには及ばないが Vueは2系までwebpack依存だったけど3からはviteもサポートされて、デフォルトもviteになって軽くなったよ
軽くなったって言うのが開発サーバーの速度じゃなくてレンダリング速度のこと言ってるなら知らん Svelte始めたらReactとかVueが辛くなってしまった
だけどシェアがあんまり広がらないので仕事はあんまりないんだろうなあ svelteをやってはいけない
悩むくらいなら知らないほうがいい svelte小さいサイトにはすごい適してるんだけど要素が増えていくとファイルサイズがとんでもなく肥大化していくんだよな
軽量なサイトを作るつもりでsvelte選んだのにいつの間にかReactより大きくなってしまうという
将来的に改善されたりするのだろうか 最近はRemixばかり使ってるなあ
シンプルなのに複雑なものを作るのも簡単で良い 病∞！！！！
魃∞！！！！！
害∞！！！！！！
雇∞！！！！！！！
期∞！！！！！！！！
傷∞！！！！！！！！！ 最近のフレームワークはどれもRemixの影響受けてるね
Next.jsのappルーターやsveltekitやsolidstartなんかどれもRemixと似たような設計してる Viteまじ神すぎる。Viteのお陰でフレームワークそのものの高速性よりビルドアップの高速性が10倍ぐらい変わった
お陰でアメリカでもVueとNuxtの知名度とシェア上がってきてるね
Vue3.2のscript setupは間違いなく改善。ボイラーテンプレート取っ払ったお陰で逆に初心者でも入りやすい記述になった
Angularも13でreactive forms、14でstandalone component、16でSignalsと汎用アプリにも対応しようと大きく動いてきてる
いい意味でReactのシェア寡占が他に刺激与えてるな Reactはifとループ周りとフォームの同期あたりが相変わらず冗長で煩雑な記述多い。まずその辺直してくれ
>>39
いつまでViteをReactに対応させるか気になるところだけどな。
Next開発したVercelがEvanさん怒らせてるし >>ループ周りとフォームの同期あたり
templateしろとかいう？そんな糞は要らんわ ループ周り煩雑かなぁ？
とても自然に書けると思うけど vueからreactに行って感動したところ
↓
コード書くようにタグが出力できる所 フォームの同期に関する冗長で煩雑な記述って
たとえばどんなのだろ >>45
全フォームにuseStateを紐付けるuseState地獄とか
デザイナー泣かせなカスタムコンポーネントによるJSX分離とか
ループも<>…</>、array.map、return(…)だらけで、ここもシンプルに式を埋め込みできるSvelteあたり見習えって思う ループに関しては関数型（風の）書き方に慣れてないだけでは？
Svelteのループ始めてみたけど何やこれ独自構文やん。どう考えてもJSのルールの延長で書けるReactの方がマシやんけ。 formなんて言うほどたくさん作らないからstate紐つけても問題なくないか >>48
svelteの書き方はあれでわかりやすいぞ、Laravel、cake、Django、Flaskらと同じ埋め込み式だし
VueやAngularのようにテンプレートに反復ディレクティブつけるか否か迷う必要もない
まあ、どれも慣れなんだろうけど >>51
慣れなのは確かにそうだろうね。
とはいえやっぱJavaScriptの『式』として使える利便性には負ける気がするなぁ phpと組み合わせようとするとreact微妙なんだよね PHPにREST APIと権限管理だけさせればええやん >>49
おう初心者が来てやったぞ
2日かけてVue3イジって出た結論が『これから初心者がやるならReactの方がマシ』だ
リリースから3年も経ってるのに主要なnpmパッケージがろくにバージョンアップされてない時点で終わってるの丸出しなんよ
せいぜいVue2の時はnpm経由でやれてたことをガチャガチャ書いててくんな
Vue3なんてVue2のEOLで頓死してるVueラーがバンザイ突撃するだけのもんで初心者が付き合うモンじゃねーわ Vueは明らかにjQuery利用者の後釜狙ってるのはわかる、vuetifyを整備したのはその布石。Reactと競合しようとは考えてないだろうな
競合考えてたら、ViteはReactサポート打ち切る
だが、いい加減CDNでscript setup使えるようにした方がいい。いつまで初心者にあのボイラープレート書かせる気だ >>55
Vue2？
あんなオブジェクトの分割代入もできない、イベントバス使ったAPIでしか兄弟コンポーネントにステート送れなかった
AngularJS時代のレガシーに毛が生えたもの使い続けても未来なんてなかったからな
けどな、Reactもクラスコンポーネントと関数コンポーネントの過渡期で、Reactは関数コンポーネント、React Nativeは
クラスコンポーネントで書かされたという二元管理強いられた、鬱陶しい過去があるからそこはお互い様だ svelte5でrunesとかいうのが追加されるみたい ワイ、おっさんなんやが、reactやって、vueやってからsvelteやったんだが、
1番わかりやすかったのがsvelteだった。
reactの時代は続くだろうけど、正直継ぎ足して機能が増えてる印象があるんやが、若い人は覚えていけるのすごいと思う。 react と vue を都合好く混ぜたのが svelte だと思っている。 ワイは、reactとvueを使った時、なんと言っていいかわからんが、なんか回りくどい感じがしてたんやが
svelte使って、すごい直感的やな、と思ったで。 残念ながらどこも使ってない
あくまでもスベルトはお遊び学習用 Svelteは柔軟に見えてJSへの制約ガチガチなんだよな。ストアやディスパッチ使ったらわかる。見た目以上の鬱陶しさが
>>59
useReducerすら使いこなせない人がReact触ってるからな。フックも今や21あるけど何人が全部マスターしてることやら フックは都度必要に応じて作るもんじゃないの？
うちのプロジェクトのフック置き場に山ほど転がってんだけど クラスの継承みたいにフックの多さが可読性やら何やら下げる要因にはならんのかい？ jsxの時代になってからweb開発始めたからsvelteの構文そんな馴染み無いんたよな Flutterと連動するWebアプリを開発しようとして、
Dartで書いたViewModelやModelをjavascriptに書き直しただけのコードをそのまま流用できるフレームワークを探したら、
Angularに行き着いた
Flutterの自由度が低いから、Angularの自由度が低くても釣り合うだろう(適当) Flutterと連動するWebアプリを開発しようとして、
Dartで書いたViewModelやModelをjavascriptに書き直しただけのコードをそのまま流用できるフレームワークを探したら、
Angularに行き着いた
Flutterの自由度が低いから、Angularの自由度が低くても釣り合うだろう(適当) Angularはstandalone APIになってから自由度めちゃくちゃ高くなったよ
もともと記述自体の自由度は高いフレームワークなんだけどね Angularって大きいSPAでもないと使う候補に挙がらないから使える人が増えないんだよね
Reactは小さいブログにも使われてるのに 業務はエンジニアのリクルートの都合でReactが優勢だと思う
Angularで求人をかけるとマジで人が集まらない 業務はエンジニアのリクルートの都合でReactが優勢だと思う
Angularで求人をかけるとマジで人が集まらない 5chでAngular.jsの質問したらVue.jsを薦められた
納得してそれ以降Angularは使ってない AngularよりVueを採用する最大のメリットはレンダリング速度かな
単純に開発者の数で言えばまだ互角だろうし しかし数年前のreduxってあれなんだったんだろうな。。今も使ってるやついるんか？ Next.jsが出てからだいぶ変わったからなReact環境は redux系の状態以上ライブラリ自体はまだ進化してるけど
reduxをそのまま使ってる人はもうそんなにいないだろう Next.jsとApache+Laravelってどっちのほうが処理速度速いの？
MySQLも使う やることによるのでは
ApacheはNextjsより速いだろうけどLaravelはNextjsより遅いよ Next13から覚えて使ってみたけど、Turbopackの再ロードの遅さなんとかならんのあれ
Viteに慣れるとあの遅さはストレスになる
>>79
ReduxにしろVuexにしろ、あれはコンテクスト遷移ができなかった頃のドリブル回避用データ管理アイテム
ReactとSvelteはcontext関係のメソッドあるし、VueとAngularはprovideとinjectがあるから
不要とまでは言い切らんがお役御免になってきた。データはフロントエンドで管理すること多いし どこかの開発系サイトでその表現を見たんだが単なる思い違いかも知れん。すまん
要はバケツリレーのような非効率なコンポーネント間のデータ受け渡し >>85
やっぱりルーティングって処理重くなるんだな
ルーティングを前提に設計されてるやつとはちがいあるのか >>88
バケツリレーの事か
しかしコントロールをキチンと設計して単体テスト入れると
おのずとそうなるから苦にはならんなーー 今のredux使ってるサービスの技術的負債感えぐい AppleのドキュメントやWebサービスはReactもVueもSvelteも使われてた ドキュメントなんてそんな複雑でもないしなんでもいいんだよは もうこのSPAフレームワークの形で今後30年は使いそう
React出てからすでに10年経過してるけど フロントエンドライブラリでtemplate要素って使うの？
表示するコンテンツの雛形自体をファイルで用意するイメージなの？ Million.jsってすごいね
仮想DOMでこのパフォーマンスが出せるものなのか Million.jsってすごいね
仮想DOMでこのパフォーマンスが出せるものなのか Vue.jsでやるにしてもJSXとstyled-components使いたい styled componentsなんてReactでも使われなくなってきてるのに… >>101
え、そうだったの！？
styled componentsかTailwindの二強だと思ってた >>101
え、そうだったの！？
styled componentsかTailwindの二強だと思ってた 剥がす前提なんだ
CSS Modulesが無難ってことか 最近のCSSinJSはEmotionがよく使われてるんじゃないの
RSCのせいでEmotionも使えなくなってくるからまた変わるだろうけど Emotionっていうのが流行りなんだ
勉強になります Vueって単純に出来が悪いわ
この書き方面倒だろうけどフレームワークの都合だから合わせてくれな！ってのが多すぎて気持ち悪い
ビジネスロジックに集中できん ref、reactiveとか.valueとか大変ですよね 記述の手間はReactも一緒だけどuseRefで変数定義すればいいのねって覚えたらそれで終わりなんだよな
Vueは思ってたのと違う挙動が多発して内部実装の都合を探る大冒険が待ってる >>111
思ってたのと違う挙動って例えばどんなのがある？ reactは言語ライブラリーの出力結果だから
言語的に知らん機能でもIDEのサジェスト機能とか効くし結果も予測できるけど
vueは決め事だから
そんなの誰が決めたねん！とか、何処にそんな機能あるねん！とかなる JSXもVueもエディタサポート必要だからそんなに変わらんぞ >>115
そりゃ概念的には違うと思うが、実用面で大きく違うとは思わないけどなぁ…
型チェックの話されるなら理解もできるが
そもそもそんなの誰が決めたって話になるとフレームワーク全般そうなるんよ 変数バインドできます
イベント処理できます
フレームワーク本体に求めてるのって結局これだけなんだよね
だけどVueはここがずっと迷走してるから辛いんよ すいませんVue3（options）で確認したいのですが
v-forで複製した要素（コンポーネント）に
個別にDOM操作をかけたいのですが
$refsにindex指定とかで取得できたりしますでしょうか。
コンポーネントにpropsでデータをbindして渡して
コンポーネント側で変更処理させる事は複雑だと思い
親側で子のDOM操作すれば良いと思いました。 一通りやったけど、Angular一択だと思う。
Vueは論外。
Reactは予想不能な動作が多すぎる。
OnLoad時にサーバにアクセスしてデータを受け取るのを待って描画っていう一番ありがちなシチュエーションを簡単に書けないのもReact
だいたいScriptの中にHTMLが入り乱れるJSXとかあり得ない。
完全に分離できてるのがAngular
さすがGoogle様や コード理屈わかって書けない人には
Reactは無理よ
UIライブラリーとかめちゃくちゃ作りやすい
プロ指向なのがReact
因みに日本人エンジニアにプロの割合はかなり低い Reactはデータが更新されたら画面も更新するっていうシンプルな設計だから
画面に表示されたときにデータを取得するような設計は本来の使い方とは違うんだよね 正直すまなかった。
そもそもAngularとReactを比べるのは間違いなのね
Angularと比べるならNextjsか。
Reactに相当するものはAngularには無い Angularとかvue.jsは
上位エンジニアの成果物を使って
下位エンジニアが作業するスタイル
が故に想定しているエンジニアの対象も異なる フレームワーク使わなくてもjsxは使いたいって言われる時代なのに jQueryの頃からライブラリで使われてる便利機能をバニラが落とし込む仕組みはやってるしね
prototypeでDOM操作はキツイ 俺はある程度の規模まではVueのoptions APIで良い派
規模がデカくなる場合はNuxtへ
間違っても単体のVueでコンポーネントは使うべきじゃない このスレでMillion.js知ったんだけどこれ使うだけでReactのパフォーマンスめっちゃ上がるんだな
もうpreactいらないやん React 19でやっとmemoしなくてよくなるみたいだな
ようやくsvelteに追いついたか options APIなんぞ捨てろ。次の3.4で非推奨になる可能性大だ。setup書けるようになっとけ。初代composition APIよりずっと書きやすいし
理屈もわかりやすい。あとprovideとinjectとuseRouteとuseRouterだけは覚えとけ
refとreactiveの用途の違いがわからん？そんな奴はrefだけ使っとけばいい
>>130
そのSvelteは5でKITメインになってデフォルトでSSG化するみたいだが。Rune試そうとしたら、まずそこから理解しなくちゃなんないのでかなり焦った >>128
むしろVueはLaravelのフロントで用いるケースが増えてる気がする。Vite+Vue+Vuetify+Laravel+αあたりが鉄板化してる。Laravelのフォーム制御、cakeよりショボいからうまく相互補完できてる
Reactは逆にNextのためのツールになりつつあるな。NextはViteにデフォルト対応していないのがむず痒いが（Turobopackはロードが遅くてモヤる） >>121
Angularも17になって脱テンプレートで、かなり書き方変わってますますAngularJS、Vue.jsとの血脈が薄くなったと思った
いよいよ、次の18でクラスコンポーネント解体に向かうんじゃないかと思ってる 規模を考えるような規模の時点でVueを使うこと自体がストレス要素にしかならんわ
コンポーネントって単語が頭を過ぎった時点で選択肢から外したほうが確実 規模を考えるほどのプロジェクトになったらもはやAngular一択では。Reactは少人数で開発するにはいいけど共同開発を考えて設計されてない
あとデザイナーから煙たがられてるし
Vueは自由度が高い反面、高すぎて素人がトンデモ開発して世界中から嫌われてた一時のPHPみたくなってる気もする
縛りが少ないから、設計能力のない人が触ると絶妙なスパゲッティになるのも共通してる >>132
Next使わないならReact使うメリットが薄くなってきたね
完全にサーバーサイドフレームワークになりつつある
エコシステムも周りに合わせる感じがなくなってきた >>135
テンプレート廃止マジ？
JSXみたいな感じになる訳？
うーむテンプレートの何が嫌なのか理解できない
サーバーサイドではテンプレートが至高という結論が出て実際それが1番描きやすいのに ほぼジジイだけどLaravel＋vueとReact＋NextでWebアプリ作ったらフリーランスで生きていけるかな？
サンプルとなるWebシステムのポートフォリオ作って応募に出せば採用してくれそう？ >>135
一択と言われてもな
新規にAngular採用してるの見たことないが >>137
JSXというよりSvelteとかLaravelみたいな式埋め込みになってる
ng-templateが煩雑だったからそこをスッキリさせてる。廃止というより脱却というスタンスだからどっちも使えるけどね 今まではお互いライバルだったけど、axios出てきてから完全に本来の本分を果たす独自進化の段階に入ってる
Vue→Laravelとタッグでフロントエンド専
React→Vercelと蜜月で、サーバーサイド専
Angular→単体アプリ専
【以下はチラシの裏】
Vue→フォーム制御がPHPでは限界があった。簡単にフォーム制御できるAngularJS作ったけど、ソースがスパゲッティ
Googleは大規模化したAngular2にしたけど、簡潔さがなくなった→開発者の1人がVueを作った
一時はReact、Angularに対抗して状態管理のVuexとか作ったけど、大規模化には限界がある
ECMA5に対応するためにcompositionAPI、TypeScriptに対応するためにsetup、
更にシェアを増やすためにVite作った。爆速起動ビルドすげえってことで欧米で、Vueも注目を浴び始めた
処理の遅いLaravelがVueに目をつけてタッグを組んだ（標準ライブラリ化）。他のバックエンドもVueと連携できるように
今のVueはLaravelだけでなくRails、DjangoにJAVAなどまで対応した万能フロントエンドツールへ
React→自社で作ってたFacebookの制御用、フォーム制御というより細かなステート管理用に作った。けど、ビルド遅かった
Next.jsが出てきてから遅い問題クリア。デプロイ不要なんでSSG最高や！Herokuとか最初からいらんかったんや！！
GatsbyにAstroも出てきて、サーバーサイド一択、React Nativeも過去の遺物になりつつある
Angular→AngularJSはもうあかん→JSフレームワークだけでフルスタック化→操作が複雑でReactにシェア奪われていく
12のバグで致命的に→13からリベンジ開始（13でフォーム制御改善、14でスタンドアロン化、15でインジェクタ実装、
16でシグナル、17で脱テンプレ）
モジュールの互換性uzee→最初から一通り揃ったAngular、実は悪くないんじゃね、という見直しの動きもちらほら
大規模な専用アプリ開発用に特化 vueとangularはいつからかパフォーマンスめっちゃ速くなってる
仮想DOMはオーバーヘッドなんて言われたりするけど仮想DOMを使ってるsvelteとかと大差無くなってきている
まあシェアナンバーワンのReactがまだ遅いんですけどね
React 19で改善するといいね >>143
文章見直した方が良いぞ
チラシの裏でももう少しまともな日本語を使う >>143
チラシの裏だから校正するのめんどかっただけ。まとめた結果が上の三行
ReactはNextで動かす分にはパフォーマンス問題ない気もする。特に13になってからすごいわかりやすくなった どのフレームワークもパフォーマンスはテンプレートエンジンのように使えば大差ないんだよな
問題はDOM操作よ
Reactはこれがとんでもなく重い
Million.JS使おうね このスレで Alpine.js 検討している人いる？
GitHubの星数すごいし
CDNでサクッと使える簡易版Vueみたいな印象。
個人的にはJQueryの後継になるのではと
期待している。 alpineは小さいだけでパフォーマンスは最悪だぞ
こんなんで大規模アプリなんて作るな ちなみに alpine linux もサイズを小さくしてるだけで、パフォーマンスはDebianなどより良いわけではない。
Debianならスリム版があるので通常ではコンテナはそちらを選ぶほうが良い。 まず使われているサイトを見たことがないsolid.js
litはそこそこ広まってきてるけれど 海外ではInferno.jsとかPreactとかVanillaとか日本ではあまり名前も見ないまま消えそうなものも多い。Alpineも二の舞になりそう
Laravelに全部駆逐されたPHPフレームワークみたいに、泡沫JSライブラリも山程
Solidも普及率がせめてSvelteぐらい数字出てこないと覚える気になれん
SvelteもSSGデフォルト化しようとしたり、Runeがα版のまま開発止まってたりで迷走してるし
日本だとR社がSvelteに力入れてたけど >>156
個人的に最強だと思ってるんだけど
なぜか全く流行らない 似たような語法のライブラリは覚えやすいどころか、知識が混濁するリスクがあるから手を付けにくい
Reactで得た知識と紛れやすいから自分はあまり手を出したくない
AstroとGatsbyも同じ理由で手を付けにくいんだよな スレチかもしれないんだけど良かったら答えてほしい
nodejsでWebAPI作る場合、Webフレームワークはなに使うのがいいと思う？
expressで作るのが一般的みたいだけどnestjsの方が機能も豊富だし応用効かせやすそうなので迷ってる
それともNextjsとかRemixみたいなフレームワークでWebAPIも作ってたりする？
単純なAPI機能だけを想定してる 個人的にはRemixが第1候補でnestjsが第2候補
理由は、今後Webアプリを作る時にRemixを使おうと思っていて、トータルの学習コストが低くなることを期待してWebAPIもRemixで作れると嬉しいということ
nestjsはRemixに比べて早いとかなにかメリットがあるならnestjsもありかと思ってるけど、なにかメリットデメリットあったら教えてほしいです nestjsはexpressの資産を使えるのがいいのかなと思って候補にあります
Remixがセキュリティをどうやって担保しているのかわかってないので迷っている感じです nestjsなんてもうほぼメンテされてないだろ
使うのはない
かと言って生expressもない
消去法でnextjsしかない
しかしこのフレームワークはWebAPI用のフレームワークではないから
気軽に使えるものではない
Reactを使う前提のフレームワークだ
WebAPIを簡単に作りたいなら他言語の方が良いのではないかと思う
どうしてもJSが良いのなら止めはしないが なるほど
JSでやるならNextjsか
Remixはまだ情報少なすぎる感じですか？
NextjsはWeb標準じゃないから気乗りしないんですよね Remixは流行るかどうかも未知数過ぎる
情報もnextjsに比べたら少ないので変なところハマるとキツイ Nextjsだとt3スタックとかtRPCとかもできるみたいだけどWeb標準じゃないのだけが本当にネック 確かにそれは大きいですよね
大人しくNextjsやるかな… nextjsですら致命的なバグがちょこちょこ見つかってるからな
どのフレームワークにしてもリスク込みで使うべし そうですね
Nextjsにします
ありがとうございました！ remixはもうsvelteと同じくらいには使われてそうだけどな これからNextjsやろうとするなら13以降と12以前は別ものと心得るべし。でないと混乱するぞ
>>171
RemixよりはまだGatsbyでは？ Gatsbyってもう新規に採用する理由が無い気がするけども
Remixより多いなんてことあるのかな
既存システムも含めるならそりゃGatsbyのほうが多いだろうけど NextのApp Routerがなんか合わなくてRemixに移行するってのが最近多い app routerでよく言われてるのはCDN使おうとすると微妙みたいな
勝手にキャッシュして制御できないから Nextは次のバージョンでキャッシュをデフォルト無効にするみたいだぞ SolidStartが遂にバージョン1.0になった
これでsolidが伸びてくるかもしれない angularのシェアがvueに抜かれたらしい
vueが伸びたというよりangularが落ちてるせいだが Angular はv18になって少しマシになった感じ
だが進化が遅すぎたな この手の言語は仕様がコロコロ変わって長期開発に向かないんだよなぁ
１〜２ヶ月で運用開始して１年以内に終了する様なサービスにしか使えない next使ってたけどremixの方が圧倒的に使いやすいわ フロントエンドはReactで良いと思うけどフルスタックでNextjsまで使おうと思うと将来性とかで不安覚える 将来性なんてどれ取っても１０年後には全く別のパラダイムが開かれてんだから気にすんな バックエンドは枯れた技術のasp.net core + C#で鉄板
フロントはReact。フロントエンドにフレームワークは要らない Vueまじ辛い
コンポーネント跨いだ時にひっそり変更検知死ぬパターンが多すぎる >>182
たとえばどんなところが?
両方使ってる人の意見を参考にしたい >>189
Remixはload, display, actionの流れが決まってるからそれに従うだけで良くて考える事が少なくなる
React側でデータ取得にuseEffectとかuseQueryとか使う必要がなくてuseLoaderだけ使えばHTTP処理のことをあまり考えなくて済む
またそれらの処理を画面単位で一つのファイルに記述するから画面単位の開発がかなり楽
これは一長一短あるけどファイルを分けたかったら別ファイルに処理を書いて関数呼び出しだけ画面ファイルに書けば良い
後は起動とかビルドが速いから開発が捗るとか、Vercel縛りみたいな機能とかがないのが良い
とりあえずパッと浮かんだのはこんな感じかな Remixが流行りだして、猫も杓子もSPAって流れが少し変わってきた気がする ニコ動の仮はRemixで3日で作ったらしいけどそういうのに向いてるの？とにかく開発スピード重視的な Remixは単純に覚えることが少ない
ReactでWEB開発したことかある人ならすぐに使えると思う tsのReact使う時に画像はどこに格納してる？
publicディレクトリ内かsrcディレクトリ内か、好みなんかな？ >>194
個人開発ですんません
静的SVGは全部コンポーネント化して管理してる。なので自動的にsrcフォルダ内。
機能関心で分類してるので、共通素材でなければ普通にその機能フォルダのコンポーネント、パーツの一つとして扱う
それ以外のpngだのjpgだのは、フレームワーク使ってると、そのまま静止画として使う機会はどんどん減るというか自動生成の割合も多いので、publicに入れて動的素材と同列に管理してます >>195
ありがとうございます、SVGだけsrcは頭になかったなあ 基本的には頻繁に更新しない静的ファイルはpublic、コンポーネントごとに管理したい画像はsrcに置くことが多い chatGPTがNext.jsからRemixになった Remix使ったことないんだけど、どうせキャッシュするんだしもう全部SSRの方が簡単だしよくね？っていうことなの？ vueの入門書いくつか読んだけどvue cliの解説ばっかで、vite系のcreate-vueの動作について解説してる本見たことない Webフレームワーク未経験でVueが学習コスト低いと聞いたので本買ってきたけどさっぱりわからん
PHPでちょっとしたバックエンドは書いたことあるけれど
フレームワークってトレンドで次から次に変わっていくわけでしょ？
もうフロントエンドもバックエンドも一本のフレームワーク（言語）でできるやつを出してくれよ Webフレームワーク未経験でVueが学習コスト低いと聞いたので本買ってきたけどさっぱりわからん
PHPでちょっとしたバックエンドは書いたことあるけれど
フレームワークってトレンドで次から次に変わっていくわけでしょ？
もうフロントエンドもバックエンドも一本のフレームワーク（言語）でできるやつを出してくれよ 未経験だとvueが学習コスト低いってことはない
vueは従来の開発と似ていたから学習コストが低いと言われていただけ
従来のを知らないならべつに frontにjsは外せ無いから
backもjsでやるだけだろ backはgolangでやりたい侍
前回のプロジェクトで採用したけど、あの言語の設計思想は大人数で開発するのにすごく向いてるわ
googleが作っただけはある
アサイン人数が数十人規模になって自己主張強めの問題児が入ってきてもコードが破綻しない あとはバックエンドの処理時間の問題だけどDBの最適化がちゃんと出来てればPHP8みたいな速いとされる言語でもJS系のバックエンドでも変わんないのかなと思うようになってきた 元からかわんねーーだろ
大半の処理をDBでやってれば DBのノードは単価が高いんで、処理内容によっては安いバックエンドのノードに寄せたほうが時間が延びても安く上がったりするよ
俺も新人の頃は速さのことしか考えてなかったけども >>210
PHP8は従来のPHPと比べたら速いってだけでNodeと比べたら遅いぞ https://tadaup.jp/3ffc06661.png
pythonは元が遅すぎるからなあ
10倍高速化してもまだ遅い
素直に他の言語使ったほうがいい >>217
Nodejs優秀すぎない？見くびってた 同じスクリプト言語でなんでここまで差が出るんだ？単に関わってる人材の差？ >>217
javaやkotlinってもっと遅いのかと思っていた PythonやRubyが足引っ張りすぎててこういうグラフになってるんであって、CとJavaだけで比較したら1割ほど遅いからまあ差はある
とは言え、大した差ではないから上位陣は言語の使いやすさで選定したほうがいい >>219
JavaScriptは実装が複数あるからな
GoogleとAppleとMozillaが競争した結果最速のインタープリタ言語になってる Elixir は、10万もの小プロセスを起動できる
Go の並行処理も、mattn の本に書いてあるけど、
C で、100スレッドを起動したら、
CPU 使用率が高く、12秒も掛かったが、
Goで100 goroutine を起動したら、
6スレッドしか起動せず、9秒で済んだ
Goの方が、CPUコアを効率的に使える
とにかく、スレッドを起動したらダメ！
CPU コアや時間の大半が、起動処理に使われるから >>203
文系のアホが唯一金持ちになれる、最強のチート職業はRuby on Rails である！
Linux, Docker, AWS Solution Architect、データベース設計も含む
筑波大学でも使っている、日本語版 Railsチュートリアルをやれば良い。
少し古いバージョンのRails 5 なら、サイトで無料で読める
KENTA, Runteq、デイトラなど、ほとんどのサロン・学校ではRailsを学ぶ。
KENTAは、PHPをオワコン認定した。
そして初心者のキャリアパスは、Rails → Go のみと言う
Vite は、Rails をコピーしたのかも？
foreman, webpack-dev-server で、hot reload するみたいな？
ファイルを修正したら、即ブラウザに反映されるとか
開発時には、CSS をコンパイルせず、
動的にスタイルを当てているだけとか 今日のNGword KENTA
明日のNGword KENTA
明後日のNGword KENTA 何このRuby on Railsって、布団押し売りか詐欺宗教団体みたい・・・
Ruby覚えるぐらいならRust覚えるわ Rubyなんて組み込みとバッチ系で息してるだけじゃん
Rustだと次期Linuxカーネル候補になったり、高速バックエンドとか色々ね
得手不得手があるのは判るがRuby使いたいか？ githubがRails使ってる限りRubyは無くならん なぜRubyを嫌うのかわからん
日本人が作った言語だろ
喜ぶべきじゃないか 品質の善し悪しじゃなくて馴れ合いで製品選ぶようなことをしてるから日本にはGAFAが生まれなかったんだろ
nodejsはGoogleとAppleは互いに競争し続けた結果
>>217
のような爆速へと進化した
rubyは進歩しない日本の象徴だわ 日本のITが遅れてるのは品質を名目にリソースも与えずにバグゼロを現場に押し付けてせいだよ。 >>234
そのグラフってだいぶ古いと思うぞ
今のRubyはJIT搭載されてかなり速い
進歩しちゃったね >>236
2024年の記事でもrubyは18倍遅いな
https://pcmatsumoto.com/2024/01/27/post-1328/?amp=1
このザマで本人だけは「早くなった」などと自画自賛するマヌケっぷりがまさに日本って感じだな >>239
でも数字は伸びてるやん
グラフより圧倒的に高速化されてるよね >>240
最下位から何番目かって立ち位置でどこが圧倒的なんだよｗｗｗｗ
そもそも最初からJITアリでの比較だろこれｗｗｗJITの有無の比較にしては差が少なすぎるわ
どっかでこの流れ見たと思ったら、停滞し続けて世界各国に次々と年収を置き去りにされてる中、言い訳にもならない言い訳並べて現実逃避し続けてる日本の恥部そのものだな Rustなんでこんなに早いねん
しっかし過去の日本人が自慢げに「COBOLは計算だったら負けんぞ」って言ってたがリストにすらないな コンパイル型言語は今や「コード全体の意図を読み取ってどれだけ効率的な機械語を自動生成できるか」の世界だからな
コードの1行1行とコンパイル後の機械語が対応してた時代とは全然違う
コンパイラが賢くなればなるほど速い あくまで論理的に等価な変換をやってるだけで、意図を汲み取ってるわけじゃないよ
まあそろそろAIを使って意図に基づいた最適化をやる言語や処理系は出てくるだろうな 日本人なら速度で戦うな
日本人ならRuby一択だろ あんな不出来な言語を日本代表みたいに扱うのはやめてくれ
日本人として恥ずかしいわ >>244
まあ、書かれてる事しか関知しないからな
そのコードが仕様をみたしているかなんて知らんがなだろうな CやJavaエンジニアからみたらRubyはすんなり入れるけどjavascriptはゴミ言語って言われるよな
ブラウザごとに仕様が違うしこれほど酷い言語はないと言われ続けてきたもっとも使いにくいのがjavascript >>248
20年ぐらい時間止まってる？
javascriptはとっくの昔にECMAで標準化されて国際規格が定まっただろ >>248
常に勉強し続けなければ生き残れないIT技術者の世界でその認識はヤベェな
あんたの技術者としての価値はもはや化石通り越して素人学生以下だろ
スレタイのVue vs React vs Angular vs Svelteだって一個も意味知らないんじゃないか？ どんだけ取り繕ってもjavascriptが糞だという事実に変わりは無い
rubyもperlも糞 どこにでもいる、サッカー代表どこが最強とか論議してる中、野球の方が面白いとか言い出す、社会の不適合者。人間フォーマットか脳みそデバッグ必要なアタオカは相手にするだけ無意味。さあ、俺もそろそろRemix勉強しようか >>204
Vueはもともとフォーム周りを簡潔にするために生み出された技術であって、決して初心者向けとは言い切れない。様々なステート管理にメソッドやら算出プロパティやら独自のライブラリを駆使するのと、それを駆使するにはある程度経験とコツがいる。なんだかんだで、複雑なフックの仕組みさえ極めればJavaScriptの延長線で書けてステート管理が一本線のReactの方が簡単という人もいる
スパゲッティ確実でパフォーマンス無視だが、Vueは実はメソッドだけで書けたりする >>204
javascriptが特殊な言語で使いにくいからどうしてもVueみたいになってしまうんだよ
他の言語ならもっと簡素で簡潔に書けるんだけど vueは2～3周りの変革がググらビリティ下げてて初心者に逆にキツくなってるのが良くない
時間が解決するとは思うけど、ねえ
optionsAPIで突き進むのも差別化的にはよかったろうに、けど時流に沿うのもわからなくもないからなあ Vueのググラビリティが低いのは中国が主戦場なせいだろう
我々日本人からするとコミュニティを置き去りにして大改造を続けてるように見えるけど、中華圏の中から見ればそうでもないのかもね vueは好きじゃないけどパフォーマンスの改革がすごい
今ではsvelteと変わらんくらいのパフォーマンスになってる
あとnuxtの話になるけどunjsが良い Next.jsよりHonoがすげえ伸びてるよな
開発者一人だけっぽいけど大丈夫なのか？ >>260
好きじゃないけど慣れちゃうとこれでいいかとなってしまう
フロントエンドなんてどうせ作り直す想定なんだし >>259
ググることなんてあるか？
ChatGPTで十分だろ >>257
多少面倒でもReactみたいに統一的な書き方ができる方が良いことに気がついた時には手遅れだった >>256
マジで超単純なフォーム系のWebをサクッと作る用途に向いてるよね
ちょっとややこしいことすると破綻する >>253
クソだけどあるものからしか選べないのよね そもそもAIの時代になってもはやUIというものが無くなるからjavascriptもだんだん使われなくなっていくだろうな 5年以内には画像から完全なフロントエンド実装を作るツールが生まれるのは間違いないだろうけど
フロントエンドもサーバーサイドに回帰してるから結局コード書けないとダメ wasm gcが入るとほとんどの言語がwasmコンパイル可能になるから
新たなエデンが生まれると思う >>274
そうか？
デスクトップソフトですらweb技術で作られることが多くなった時代なのに >>275
言語に縛られないからその点は良いよ
wasm対応の好きな言語を選べるようになると素晴らしい
まあ流行らなかったらキツいけど >>273
> フロントエンドもサーバーサイドに回帰してるから結局コード書けないとダメ
回帰ってのはどういう意味？ サーバーサイドレンダリングのことじゃねえの？
古のMVCから変わってクライアントサイドでレンダリングするようになっていったかと思えば今度はまたNextのAppRouterよろしくSSR(orSSG)になったりと忙しない業界よな >>279
単にWebベースのクライアントアプリの事を言ってると思う まさにサーバーサイドレンダリングのことだ
結局コンポーネントに必要なデータはサーバーで取得した方が早いよねということにフロントエンドの人が気がついて
サーバーサイドの人は今更何言ってるの？みたいなる空気感
コードの共有がそれほど意味があるとは思えないし
サーバーサイドは別の速い言語で作れば良くね？って思うけどね 最近はフロントエンドの人がサーバー側に口出ししてきて
今更ORMガーとか言ってて昭和かと
こっちはORM地獄を10年以上前に経験してウンザリしてるんだよ とサーバーしかしらん無知君が吠えてます
こいつ勘違いしてるというより無知だから今までのサーバーサイドレンダリングと同じだと思ってるらしい Twitterで騒いでるフロントエンドインフルエンサー()の方々はCSの知識がないのに調子乗ってるから本質が掴めてないんだよな
SSRなんて変な名前つけちゃってからに >>283
その発言はサーバーサイド何もわかってませんと言ってるようなもの >>285
何もわかってませんってなんだ？
ずっとサーバーサイドの開発も散々してきてるが
お前はフロントエンドを何も理解してねえから無知晒してんだろw
マジで恥ずかしいレスだったわww >>286
匿名掲示板でそんなイキリをして恥ずかしくないのか？
それをどうやって確認するんだよ
確認できないようなことでイキるな
発言内容だけしか見ないんだよ >>287
何度読み返してもこれほどの無知はこのスレにはいねえわw
久しぶりにサーバーサイドおじさんが勝ち誇ったと思ったら実際はただの無知でしたってオチだったww
少しは勉強してから来てくれるか >>279
フロントエンドが「これからはレンダリングはこっちでやりまっせ」みたいなノリでこっちはもうAPIだけ作ればいいのかラクチンだーと思ってたら
いきなりサーバーサイドに土足で踏み込んできて
NextダーRemixダー言い出してもうめちゃくちゃだよ ワイらがNext.jsの運用もやりまっせ！からの面倒だからVercel使いますと言われた日には我々の怒りもピークだよ 中身のないイキリレスだけしたいなら消えてくれないか？
不愉快だし境界知能のADHDに構ってるほど暇じゃないんだ
そもそもがレスバでも俺には勝てない
感情のコントロールもできないやつの発言なんて聞くわけがないだろう
何度もいうが発言の中身だけしかみない
匿名掲示板はそういうところだ なんだこいつ
レス連投のキチガイか
理解できないなら使わなきゃいいだろ 技術者なら中身のある批判をかけ
書けないなら黙ってろ あー、、
そもそも最近のSSRやらSSGは普通DB操作まではやらんでしょ？
最近の豪華絢爛なUIを何でもかんでもクライアント側でレンダリングできるようにすると、そのレンダリングのためのコードで転送量が爆裂する上、
クライアント側の処理能力も問題になってくるからサーバーでレンダリングした結果を渡した安定するよねって流れだと思うよ
だから相変わらずAPIは提供してやる必要がある
ぶっちゃけ、処理効率を突き詰めていくとjsonやらxml吐き出すAPI叩いて結果からレンダリングしてみたいなバケツリレーのようなマネするよか、そのままAPIから直接html吐き出した方が処理効率はいいけどね
職務分掌の意味合いが強いと思う >>298
>>299
こいつらも何もわかってなくてワロタw
そもそもコイツ↓のこのレスみて無知無能さがマジでわかるだろw
>>281
> コードの共有がそれほど意味があるとは思えないし
> サーバーサイドは別の速い言語で作れば良くね？って思うけどね
まさかのコードを共有してるだけだと思ってるらしいw
まっっったく理解してないどころかド素人通り越して知識ゼロで話にならんw
サーバーサイドは別言語で良くねって完全に自分は無知ですって言ってるようなもんだろwww
Next.jsとかのSSRとサーバーサイド言語のSSRが同じだと思ってんなら邪魔だからここから出ていけよwww >>299
コードはページ開いた初回だけだぞ
（かつコードもローカルにキャッシュする事も可能）
それ以降はREST API叩くだけだから
ネイティブアプリと遜色ないレベルで動く >>303
それがつまりはクライアントサイドレンダリングが持て囃されてた10年ぐらい前の思想でしょ
豪華になっていくにつれてそれじゃ問題が出てきたからAppRouterのSSR&SSGと言ったもんが出てきたわけよ >>299
cloudflare D1とか普通にやれるしむしろ積極的に使う方向性
サーバーレスDBだ
あと普通にpostgresqlサーバーへ接続できる(!)
もう何でもあり フロントエンドのPrismaに対する過剰な評価はなんなんだろう
そもそもORMなんて20年前にサーバーサイドで死ぬほど開発され全てクソという結論に至った技術なのに >>307
べつにPrisma以外のORMでもいいけど
TypeScriptから型安全に使えるのがいいんだよ >>308
RDBのインターフェースにおいて型安全という思想自体が間違ってる派だがそれは置いておいて
定義したスキーマに対して型安全に使いたいならそれこそJavaやC#でそれこそ海千山千レベルで作られた
しかしどれも使いやすくはなく最終的にはシンプルなクエリービルダー型のものだけが残った
必要なのはORMではなく単なるSQLクエリービルダーだったというのが結論
まあ歴史を繰り返すことが悪いとは言わないが
自分で実装したものもないのになんかレベル低いことやってるなあと
「wasmコンパイルした時のサイズが最小のクエリビルダーを作る」というのは技術的にかなり面白いと思うけどね フロントやってる人って強い言葉で極論語りたがるってことが、
顕著に表れてる数レスだなあって思った 極論ではなく以下の構成が最適なのはいうまでもない
DBマイグレーションツール
+
データベース接続を抽象化するアダプターモジュール
+
SQLクエリービルダー
これこそがモダンなインターフェースなのである 昔は、ローカルの開発環境ではsqlite、実環境ではDBMSとかあったからORMにもメリットがあった。
でも今ではローカルでも実環境と同じDBシステムを使えるようになってるし、調査では結局素のSQL見る必要もあるし、リプレースする際でもフロント、バックエンド、DBシステムのなかではDBシステムの変更が一番可能性は低い。
それならORM毎の違い覚えるより素のSQLを使いこなせるようになったほうが長く使えるスキルになる。
結局ほしいのは
>>311
で言ってるものだな。 PrimaはTypedSQLみたいなものも出してきてるし
結構面白いよ 20年ぐらいこの業界やってるけど最適化を進めて複雑なサブクエリやらWITHやらを使い始めると、
大抵ORMじゃ対応しきれなくなって結局生のクエリを実行させるようになるケースが多すぎたな ぶっちゃけJSONにaxiosあたり出てきてLaravelがガワ連携実装してから、他言語フレームワークもガワ連携前提がデフォ化して自己完結主義のAngular以外ガワツールと化してる感あるな。あとは複雑だが階層は浅いフォーム制御が得意（Vue）か、単純だが階層が深いステート管理が得意（React）かで選択肢が変わる
ヨーロッパだとSvelte（イギリス生）が人気になってきてるみたいだけど、日本というかアジアはVue強いし、まだまだ普及に時間かかりそう >>313
SQL理解できないのにORM使おうというのがそもそも間違いだからな
チューニングとか別の人がやるのか？って話
ふざけんなと
あと生成したSQLが本当に求めているものなのかのチェックも必要
SQL生成ごっこがしたいなら好きにしたらいいが
>>315
それと最近はデータ分析用にかなり複雑なSQLを投げることが増えた
別途バッチにすることも多いがどうしてもリアルタイムで実行しなきゃならんこともあったりして
これが厄介なんよね
彼らの実行するクエリはもう型とかぐちゃぐちゃ ORMしか使えない奴ら多いよな
バックエンドエンジニアでSQL書けず最適化もできない連中ばっか >>314
サーバーサイドが型合わせ不毛だよねと実質捨てた部分を今どのように再開発するのか楽しみではある
「先」に進めてくれるのだろうか
ちなみに改めてORMを調べてみたがやはり状況は大して変わっていない模様
SQLクエリービルダーは大抵の言語でかなり進化しているが型のマッピングは程々にするという妥協案
Haskellが1番面白かった
以下のようにモナディックで型安全なSQLが書ける
ここまでやれるやらありか？とは思ったが
select $ from $ \person -> do
where_ (person ^. PersonAge >. val 30)
return person SQL書けないからORMのtable単位で更新するレベルの機能で良しとするんですよ ちなみにJavaやC#のORMで出た型付けの結論は
「オブジェクトのプロパティと実行するSQLの型を手動でマッピングする」です
マッピングは動的に変えられるので汎用性がある
テーブルの型とプログラミング言語の型を直接マッピングしないというのがミソ 簡単に言うと実行するSQLごとに型付けをする感じ
これだと同じテーブルで型が変わる場合などでも対応できる
PrismaのTypedSQLもこれに近いものなのではないの？
Java界の奴らが10年以上かけてたどり着いた結論だから多分こうなると思うよ >>311
>>SQLクエリービルダー
ってGUIでクエリーを書く機能のこと？ SQL書けなくてどうやってデータ保存してるだ？
本当にSQL書けないならSQLite辺りで覚えていったほうが良いかもね >>324
違う
単にSQL生成を目的とするだけのモジュール
railsにおけるArelとか
以下のように複雑なSQLも構築可能
Task.where(
Arel::Nodes::NamedFunction.new(
'TO_CHAR',
[
Task.arel_table[:created_at],
Arel::Nodes.build_quoted('YYYY')
]
).eq('2023')
)
# => SELECT "tasks".* FROM "tasks" WHERE TO_CHAR("tasks"."created_at", 'YYYY') = '2023'
大抵の言語やフレームワークに似たようなモジュールが存在してそれを使ってSQLを作るというのがここ数年の流れ
もちろんN+1問題を容易に作ってしまうので結局実行時にどのようなSQLが生成されるか？は見なくてはならない >>317
いちばん有名な企業が楽天グループ、そこは公認パートナー企業にもなってる
>>325
ORMは便利だけどそっちしか知らない人が多いというか、各種フレームワークからデバッグ用にSQL吐き出せること知らない人も多い。だから結合とか副問い合わせで躓いてるのをよく質問サイトで見かけたな おぞましいことに、SELECT * FROM xxx WHERE yyy = zzzみたいな糞クエリのゴリ押しだけで全部解決しようとする新人がたまにいるのよ
明らかにJOINやサブクエリやウィンドウを使えば効率的に一度のクエリで解決する要件も、何回も何十回もクエリ発行して取りに行く
負荷試験が壊滅的だったプロジェクトに火消しを頼まれて助っ人で行ってみたらそんなザマで頭抱えたことがある
結局ほとんど俺が全部書き直した あんなDBの使い方しかしない（できない）からORMの弊害に気付かないんだと思うわ
型安全と言っても、それテーブルの全カラムを無加工で取得したい場合ぐらいしか有効に働かないだろうに >>326
ストレートーにSQL書けよと言いたくなるな
障害時に綺麗なSQLはけてないと復旧とか損害保証とかできるの？ >>328
昔DBAという役職があって
その人に使用するSQL全部チェック対象にされ... ストレートにSQL書くと、パラメーターとの文字列連結がカオスになるよ サブクエリに、with、一時table使ってSQL書いてるけどそんな事一度もなかったな 今回の調査で色々と調べたけど
javaのJOOQってORMやべーな
とんでないぞこのライブラリ
以下のように型がコロコロ変わる場合でもちゃんと書ける
Fieldクラスを抽象化することで静的な型チェックが可能になっている
この発想はなかった
DSLContext create = DSL.using(configuration);
Field<String> caseField = DSL.case_()
.when(field("age", Integer.class).gt(18), "adult")
.when(field("age", Integer.class).lt(18), "minor")
.otherwise("unknown");
create.select(caseField).from("users").fetch(); caseってデータ分析ではめちゃくちゃ使うのだけど
これがこんな感じで書ける
素晴らしい >>331
昔は社内にオラクルデータベースの番人みたいなおじさんがいたなあ >>328
select * from tableA join tableBとして、吐き出した全データを配列に格納、展開してたトンデモプログラムをデバッグしたことあるよ…。アスタリスクは百歩譲ってもせめて部分結合してくれ
データ数千件しかないのにフォーム処理クッソ重いと思ったらこれだよ >>332
一回のトランザクション処理につき一回だけSQL実行可とルールすればよい
おのづとサブクエリ、with、一時tableを使う事になって、SQL投げて結果でSQL投げみたいな処理を繰り返すヘボ実装が一掃される >>331
たいがいそこが開発進行のボトルネックになってたけど当時は必要悪だったと思うよ
あの頃のオンプレの商用環境（しかも大抵カツカツの構成）で、クソゴミクエリぶん回そうものなら即死してサービスダウンに陥ってたもんよ
今のクラウドのマネージドDBだったらただ遅いor費用が嵩むだけで落ちるとこまで行くことはそうそうないけど、昔は死活問題だった 一つの処理を一つのSQLクエリならアトミックになって問題無いけど
一つの処理を複数のSQLクエリで時間差が出来るから他所からデータ割り込まれたら困るケースがあるだろ
そこまで考慮してないアホばっか 一番早いのは個々のSQL連結したをストアドなんだよなー
JOINもINNNERとRIGHTは遅いからLEFTのみ >>341
inner使ってたけどleftのが速いんだ？ そもそも得られる結合結果が違うし、INNERのほうが効率的なケースもLEFTのほうが効率的なケースも存在するから思考停止せずにしっかり実行計画確認しろ
「何にでも～～を使う！」ってのはバカの一つ覚えってんだ left と right で速度が違うとか言ってる奴の話を真に受けんな 本読んでたらNextすげーいいじゃんと思ってきた、なんか学習コストは高そうな気がするけど
remixは調べてない 最近はremixの方が優勢になってきてる
ChatGPTもnext.jsだったのにremixに移行した ただしremixはフルスクラッチで作り直すから
大幅に変わりそう
だから今手を出すべきかは微妙 まあフロントエンドなんて作り直すのは基本だし
まともなCTOがいたら予算も出るからその時の流行でよろしい
画面の動きを全部サーバーサイドの結果で判断できるように作っておけば問題なし プロダクトの性質次第だろう
SaaSだとページ数多いしビジネス要件実装のウェイトが大きいから作り直しは難しい >>345
ねーわ。どっちも outer join で駆動表が右か左か違うだけ。
クエリを書き換えて実行計画が変わったのを勘違いしただけだろ。 leftと等価なrightへの書き換え、あるいはその逆の書き方を知らないだけでは？🤔 345は20年前のOracle8iみたいなルールベースの知識からアップデートできていないだけな気がする Nextはビルドツールが自前なのがな
RemixもsveltekitもNuxtもVite使ってるからそこでエコシステムの差が出てきそう
それが進んだらNextも厳しくなってくる JSはいつまでエコシステムとかやるんすかね
いい加減デファクトをみんなで作ろうよってならないのかね
主に政治的思惑で一つにしたくないのだろうけど right joinを使うと右から左へ、下から上へ読むようなクエリになるからな
読みづらいからrightは基本使わない
「遅いからrightは使わない」とか言ってる人は意味不明だけど 昔のDBでそういうのがあったんじゃないの？
知らんけど HR系のシステムにおける従業員(主)と部署(従)のように、あるビジネスドメインにおいて着目する主体ってのはだいたい決まっているものだ
なので、SQLを書くときもそのメンタルモデルに倣って主側に置くものをある程度固定したほうが読みやすいという考え方もある
ある条件を満たす従業員と所属部署の一覧を表示する際に、従業員不在の部署も表示したいという要件があったとして、
そのようなちょっとしたビュー要件によって主従関係が逆転してしまうのは好ましくない、ということだ
俺はそれでもLEFT統一の方が読みやすいと思う派だが、考え方としては理解できるものだろう svelte5のmilestoneが98%まで回復 release
[[email protected]](/cdn-cgi/l/email-protection) svelteで作っていたサイトはもうastroにしたんだよなあ
svelteの強味がよくわからなかった EchoAPIは、テストが私のReactアプリに動力を提供するAPIを容易にし、開発を強化するための迅速な応答を提供。試してみてね EchoAPIの直感的なインタフェースは、ReactアプリケーションでAPI応答を迅速に検証し、デバッグを容易にするのに役立つ。おすすめ！ Angularが久しぶりに盛り返してる
今年のアプデでかなり改善されたからだろうか
あと特筆すべきことはAstroの伸びかな
https://2024.stateofjs.com/ 本当だVue抜いてるじゃん
Astroは絵に描いた餅感のイメージ強いんだけど、
この間bolt適当に弄ってたら何故かASTROでコード吐いてきたので
AIの力も借りて遊びでなんか作ってみようかなぁ jsx使ったことある人ならAstroは簡単に習得できると思う >>373
Angular17以降爆速になったからな、Vite＋esbuildというチートで19は起動が6秒ぐらい
それでいてフルスタックのまま。スタンドアロン標準実装、Signal、ビルトインコントロールフロー
ようやく他と戦える体勢整ってきた
>>370
SvelteはAppleが協賛に入って脱TS目指して、アプリ特化になりつつある
Runeもまだ、既存技術をわかりやすくマーキングしただけだし >>373
Viteの伸びもえぐいな、とうとうWebpack超えてしまったか
Reactも19になってようやく不満要素だった、テンプレート周りの改善とフォームのリアクティブ制御を実現してきた
ただReact普及に貢献してきたNextだけが、案の定Viteから爪弾き状態になってるのが気がかり
Remix、Astroはしっかり公式連携になってるのに あとAngularはCSR、SSG、SSRをミックスした使い方ができる。これはフルスタックならではの強みであり芸当でもある Angularってどう学べばいいの？
書籍は古いバージョンしか出てないし
公式サイト（日本）のはじめてのAngularだかも
今のバージョンでは動かなかったりして当てにならなかったわ >>380
やっぱり本家のチュートリアルかねえ英語だけど
日本語の書籍は古すぎてオススメできない >>380
ZennかQiitaあたりの使える記事を探すのが手っ取り早いかな
英語読めたらdev communityにも役立つ記事がいっぱいあるけど
Angularも14以降とそれ以前でReactの16.8以降と以前ぐらい別物の記述になってるから注意
あとAngular19からはstandalone標準だから、過去の動かしたい場合はstandalone: falseにしないと動かない AngularはFCP遅いのがな
一度読み込んだら速いけど 最近の業務待機時間多いから、その合間にここ数年の流行りに取り組んでいるんだけど
solidJSがかなり書きやすくていい。Vueのようなライフサイクルフックもあるし、JSXのループ周りに対しても面倒なmap地獄に遭わなくて済む。Reactかじってたら多分すぐ覚える
システム複雑じゃなくていいけど、JSXでさっと書きたいって人にはおすすめ
RemixとAstroもいい感じだ
RemixはNextほど複雑さがないし
AstroはJSX、Vue、Svelte、Solidどの書き方も通るのが便利そう ネットうろうろしてるとNextどころか
まだまだVue、Nuxt多いなぁ
Astroとか日本の商用サイトで採用してるとこあるの？ どこで何が役立つかわからん業界だし（今年はまさかのPerl大活躍）
>>386
Astro採用企業の有名どころはAmazon、ネトフリ、クックパッド（ここはかなり日和るが）とか
Microsoftもスポンサーになってるのが大きいかな、あとVite公認 GoogleとかトリバゴもAstro使ってるはず
国内企業は知らんけど Remix良いとは思うんだけど
こういうフレームワークを更にラップしたようなのって流行過ぎた頃に困る予感しかしないんだよな
バックエンド含んでるから古くてもまぁ動けばええじゃろでサボることもできんし >>389
どのフレームワーク使ってもその問題は付きまとうから気にしても意味ないような create-react-appが非推奨になったとかなんとか フルスタックものはだいたいそのリスクあるでしょ
堅牢なシステムを長期的に運用したいとかなんとかなら
結局愚直にバックエンドapi実装 フルスタックのリスク回避でapiは別に設けるのもアリだよねって思ってもいる
Remixイジり始めたばかりだけど 海外ではQwikも人気出てきてるみたいだし本当に群雄割拠だ
自分は今、Svelteのrune触りまくってるけど、一層proxy制御ガチガチになってて
堅牢性と拡張性は大幅に改善されてたけど、あれじゃもう、Vueと並び初級者向けとは言えんぞ Reactみたいに汎用的なフレームワークは消えると思ってる
やっぱり個別にコンポーネントをコンパイルした方が効率いいのは間違いないのだし
サーバーサイドありきにするならこの考えが自然なのよね >>397
いや基本的にはサーバー側でオンザフライにコンパイルされることが基本となると思う
svelteやqwik、solidを融合したような形になると思う >>396
ReactとVueはあくまでライブラリだからな。だからガワ（フロントエンドツール）として売り出す手段にも出てるわけで。それだけにReactもそろそろ使いやすさ重視しないと離れていくだろうな
特に、今後のエコシステム次第ではSolidに乗り換えられる可能性は大いにある
VueはdefineModelがチート性能すぎてある意味今後が怖い spaとか糞なUIはそろそろ消えると予想。
画面リロードに対応できない仕組みでUI構築すべきではないと気付き始めるだろ。 SSGもCORS問題が鬱陶しすぎる（ローカルで環境開発しにくいから開発コスト大）
のと、あとデータ量に比例して重くなっていく問題をなんとかせんと >>400
むしろView Transitions APIとか出てきてSPAは手軽に作れるようになってきてるから消えないよ
>>401
ReactだともうSSGは縮小方向だな
今はReactでマトモにSSGやろうとしたらAstroが一番の選択肢になりそう react難し過ぎるだろ。
フックの伝播複雑過ぎて、メンテナンスできない説。 コールバック関数、分割代入、proxy この３つを把握すればJSフレームワークはどれも同じ reactでShift選択するui作ったけど
自分で作ってもう触りたくない。
クリックのフックは子がハンドリングして親に返して、選択範囲の再描画は親が制御するみたいな。
これに余計な子は再描画しないようメモ化するとか入れると、頭こんがらがってくる。
どのフックで何のパラメータが変わってどれが再描画されるか解らなくなる。
設計書書かずに作ってるせいなんだが。 Shift選択のUIってこんな感じの挙動？
ttps://codepen.io/rkeqkdzm-the-reactor/pen/wBvWpyp ReactのMemoはマジでゴミだけどReact Compilerでやっと解決するらしいから Reactでゴミなのはコントロールフロー系
Solidはそこをしっかり解決してる
もう一つのゴミだったルーター系も
Solidインスパイアしてるならそっちも真似したらいいのに
Solidにストア系実装されたらまじでシェア流れかねんぞ >>411
何言ってるんだ？
Solid RouterはReact Routerにインスパイアされて作られたって公式のドキュメントに書いてあるのに >>411
React Router Domが6からSolid Router（旧solid-app-router）の記法をまんま真似してるんだよ
パクったというより連携だけど >>407
だけどreactで作ったchrome拡張の審査通った。
苦労して作ったから使ってみて欲しい。
適当なブログ開いて拡張のアイコンクリックすると画像一覧表示するから
欲しいの選択してダウンロードボタンでzipにできる。
スライダーで拡大縮小できるのがreactっぽい。
ttps://chromewebstore.google.com/detail/kakeaonncmnkigiijohfhlnondeaanii?utm_source=item-share-cp 誰が作ったのかもわからん怪しいextensionなんかインストールしてはいかんよ
簡単に情報抜かれる みんなReactでフォーム作るときってinputタグ単位でコンポーネント作るの？ コンポーネントって再利用しやすいように作るのであって
無駄に細分化すると面倒なことになる
必要になったら後からでもコンポーネント分けられるし 描画のタイミング自由に制御できるようになると、react楽しいねぇ。
それまでは糞だけど。 Reactのranderを封じて、
自前のタイミングで再描画する楽しさよ Reactはmillion.js使えばsvelteやsolidよりレンダリングのパフォーマンスが良くなるよ >>422
コンポーネントというより、質問のニュアンスだとフォーム部品ごとの出力オブジェクトか
制御フックのこと言ってるっぽいが
Reactはフォーム処理に関してSvelte、Vueにくらべたら糞性能というか、もともとが
深層ステート管理のためのライブラリだしな。複数のフォームを一発制御できる
useStateフックの書き方ググるかカスタムフックで作る
それかReact捨てて、簡単にリアルタイム制御できるVueかSvelteで作るかだな
どっちもストアライブラリ使わないとスパゲッティまっしぐらだがな >>386
商用サイトじゃないけど、学研グループの勉強サイトはAstroで書かれてるね
https://manabitimes.jp Astro触ってみたけどすごいなこりゃ
こんなのできるならよほど大規模なサービスでも無ければNext.jsは要らないのでは Astroまだちゃんと触ったことないけど
Reactコンポーネントを将来、全く別のフレームワークのコンポーネント、例えば引数とレンダリング結果が同等の動きをする、コンパイルされたバイナリなんかに差し替えたりとか出来たら面白いな どうせAI任せになるから関係ない
近いうちにAIが直接SSGしたりWeb Assemblyを直接生成するようになるからフレームワークなんか消滅する Remix v3が大改造するみたいだな
従来のRemixはReact Router v7になってRemix v3はpreactベースになるということか スレチだったらごめん
オンライン麻雀ゲームを作成しようと構想(妄想)してるんだけど、
いまから新規に作るならフロント側にはReactかVue.jsか、あるいは他のライブラリのどれを使えばいい?
先駆者 (書籍も出してる) は
> jQueryでないと美しく実装できない
https://blog.kobalab.net/entry/2021/03/25/205151
って言ってるけど、Webゲームのクライアントは特殊ってこと? その記事の人はReact使ったことがないから知識ゼロなんだろ
そもそも状態管理をして宣言的にUIを構築するんだからむしろReactのほうがスッキリ書ける
jQueryおじさんという化石思考に惑わされてはいけない > 宣言的アプローチでは「打牌中」の状態を描画できない
いや、Reactでは描画のための状態はUIコンポーネント内部に保持することでコアロジックを汚染することなく打牌中のような中間状態を美しく描画することができる Reactは宣言的UIは最終的な状態だけを表現するということではない
アニメーションやユーザー操作に伴う一時的な状態、ここでは打牌中もコンポーネントの内部状態やコンテキストAPIとかで管理できる
isPlayingAnimationのようなブーリアン型の状態を用意し、アニメーション中はtrueに設定し、アニメーションが終了したらfalseに戻す
打牌中の牌の位置や動きに関する情報を状態として持ち、その状態に基づいてCSSアニメーションを適用する > Majiang.ShoupaiはAIの思考ルーチンでも使用します。ここに描画の都合の「打牌中」などという状態を持ち込むとしたら、それは設計として誤っています
Reactでも描画に関わる状態とアプリケーションのコアロジックに関わる状態は分離して管理するのが一般的
コアロジックの麻雀の牌姿やルール進行を司る部分は、Reactコンポーネントからは独立した純粋なJavaScriptクラスや関数として実装するのが普通 > イベントハンドラ設定は描画処理と分離すべきである
Reactの設計思想はコンポーネントが自身の描画とそれに関連するイベントハンドリングをカプセル化すること
「対戦相手の手牌にイベントハンドラは不要だし、牌譜再生にも打牌のためのイベントハンドラは不要」という点についてはReactのコンポーネント設計で柔軟に対応できるからまったく問題なし
isInteractive: booleanなどを渡すことでイベントハンドラの有無を制御できる
牌譜再生時にはイベントハンドラが不要なモードでコンポーネントを描画すればいいだけだし > JSXを使う局面がない
> HTML に雛形として埋め込まれた「牌を表現するDOMノード」をコピーし差し込むことで実現しています。
Reactをまったく知らないからこんな恥ずかしことを堂々と言えるんだろう
こいつのもっとも無知なところだな
Reactは宣言型だからコピーするというコードを書くことすら不要なわけ 牌なんてCanvasに直接描画すりゃエフェクトも自在だし変にエレメントにデータ持って
重くなることもなくていいんじゃね？って思うのは俺だけなのか >>446
俺もこう思う
そもそも牌をhtml要素とCSSで描画すること自体が微妙だよね
そういう意味だとjQueryでもReactでもなくてCanvas系のフレームワーク使ったほうが良いんじゃないかな 宣言的UIに慣れるとCanvas全体を命令的に描画するのがあまりにもダル過ぎる Canvas上の各表示オブジェクトを
Reactやビューで
あたかもHTMLの要素の様に操作できる（CSSプロパティ設定できる）
ライブラリってあるのかな。 実際のゲーム開発で宣言的UIが採用されることってあるの？ 設定画面とかチュートリアルなら、まあ宣言的UIを使うもアリ。 Remixが謎方向に進んでいる
Reactを捨てるのか React捨ててReactもどきを新しく作ったのか
流石にもういらんだろ Reactは迷走してるって言ってるけど『お前もじゃい！』って感じだな
しかしReact前提のフルスタック全滅したらバックエンドはどうしてくのが良くなるのかねぇ 今さらPugやEJSやThymeleafJSが再流行するとも思えんよなあ >>458
やりたいことまとめてAIに投げれば開発環境の構築方法から実際のソースまで全部、書いてくれるよ。 Reactやってる人多いけど重いし環境選ぶしメリットある？
Nuxt4とCapacitorでフロント組んだ方が楽だと思うんだけどトレンドころころ変わるから最近しんどいわ 特定サービス依存はHerokuみたいなことにならんか心配 reactを選ぶ理由はライブラリが揃ってるから
react自体が好きで選んでることはない 信頼できるフレームワークは生き残るが
信頼できるフレームワークに依存する信頼できないライブラリはAIに淘汰されると思う NextでパフォーマンスチューニングしてもNuxtに適わないな
今後AIである程度フロント技術はAIのルール付けに集約していく気がする。ClaudeOpsもSonnetも単純なアプリならそこまで間違えないし勉強には良いね reactはすごいよく考えられてると思ったよ
オブジェクト指向で絵に描いた餅だった再利用性が本当に使い物になるし、
圧倒的に他人のコードが読みやすい
Nextは嫌いだけど仕方なく使っている Reactで原子レベルでコンポーネントを設計みたいな記事を読んだんだけどボタン一つからコンポーネントにするとかそういう意味？ Atomicデザインだろ
そうだよ複数の要素を組み合わせたものがコンポーネント
しかし原子はその中の文字だけとか、border、border-radiusとかpaddingとか細かく共通化を前提に設計していく >>472
ありがとう、CSSまで設計で決めるんだね
まあFigmaとか使ってたらCSS生成出来るから普通なのか AIでAtomicデザイン任せられるのは本当に楽。ここ５年ぐらいの苦労が何だったのかわからなくなるぐらい
UI周りだけはClaudeでもまともに動いてくれる Evan Youがなんか出した
https://void.cloud/
cloudflare専用らしいけど、別にそれでも良いのかもしれん cloudflare workersをvite+に合わせたやつでしょう 
