Vue vs React vs Angular vs Svelte Part.11

2024/09/29(日) 18:05:01.99

おぞましいことに、SELECT * FROM xxx WHERE yyy = zzzみたいな糞クエリのゴリ押しだけで全部解決しようとする新人がたまにいるのよ
明らかにJOINやサブクエリやウィンドウを使えば効率的に一度のクエリで解決する要件も、何回も何十回もクエリ発行して取りに行く
負荷試験が壊滅的だったプロジェクトに火消しを頼まれて助っ人で行ってみたらそんなザマで頭抱えたことがある
結局ほとんど俺が全部書き直した

2024/09/29(日) 18:20:31.60

あんなDBの使い方しかしない（できない）からORMの弊害に気付かないんだと思うわ
型安全と言っても、それテーブルの全カラムを無加工で取得したい場合ぐらいしか有効に働かないだろうに

2024/09/29(日) 18:29:40.63

>>326
ストレートーにSQL書けよと言いたくなるな
障害時に綺麗なSQLはけてないと復旧とか損害保証とかできるの？

2024/09/29(日) 18:36:09.04

>>328
昔DBAという役職があって
その人に使用するSQL全部チェック対象にされ...

2024/09/29(日) 18:38:11.33

ストレートにSQL書くと、パラメーターとの文字列連結がカオスになるよ

2024/09/29(日) 18:41:51.91

サブクエリに、with、一時table使ってSQL書いてるけどそんな事一度もなかったな

2024/09/29(日) 18:43:50.27

今回の調査で色々と調べたけど
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();

2024/09/29(日) 18:45:39.57

caseってデータ分析ではめちゃくちゃ使うのだけど
これがこんな感じで書ける
素晴らしい

2024/09/29(日) 18:47:22.71

>>331
昔は社内にオラクルデータベースの番人みたいなおじさんがいたなあ

2024/09/29(日) 19:00:17.50

>>328
select * from tableA join tableBとして、吐き出した全データを配列に格納、展開してたトンデモプログラムをデバッグしたことあるよ…。アスタリスクは百歩譲ってもせめて部分結合してくれ

データ数千件しかないのにフォーム処理クッソ重いと思ったらこれだよ

2024/09/29(日) 19:25:17.35

>>332
一回のトランザクション処理につき一回だけSQL実行可とルールすればよい
おのづとサブクエリ、with、一時tableを使う事になって、SQL投げて結果でSQL投げみたいな処理を繰り返すヘボ実装が一掃される

2024/09/29(日) 19:26:59.25

>>331
たいがいそこが開発進行のボトルネックになってたけど当時は必要悪だったと思うよ
あの頃のオンプレの商用環境（しかも大抵カツカツの構成）で、クソゴミクエリぶん回そうものなら即死してサービスダウンに陥ってたもんよ
今のクラウドのマネージドDBだったらただ遅いor費用が嵩むだけで落ちるとこまで行くことはそうそうないけど、昔は死活問題だった

2024/09/30(月) 14:16:26.25

一つの処理を一つのSQLクエリならアトミックになって問題無いけど
一つの処理を複数のSQLクエリで時間差が出来るから他所からデータ割り込まれたら困るケースがあるだろ
そこまで考慮してないアホばっか

2024/09/30(月) 16:35:49.13

一番早いのは個々のSQL連結したをストアドなんだよなー
JOINもINNNERとRIGHTは遅いからLEFTのみ

2024/09/30(月) 16:59:05.93

>>341
inner使ってたけどleftのが速いんだ？

2024/09/30(月) 22:19:31.77

そもそも得られる結合結果が違うし、INNERのほうが効率的なケースもLEFTのほうが効率的なケースも存在するから思考停止せずにしっかり実行計画確認しろ
「何にでも～～を使う！」ってのはバカの一つ覚えってんだ

2024/09/30(月) 22:31:07.26

left と right で速度が違うとか言ってる奴の話を真に受けんな

2024/09/30(月) 23:41:53.43

>>344
結構あるで

2024/10/01(火) 10:17:07.05

リスト構造なら違いは無いよな？

2024/10/01(火) 16:04:12.61

本読んでたらNextすげーいいじゃんと思ってきた、なんか学習コストは高そうな気がするけど
remixは調べてない

2024/10/01(火) 16:46:36.79

最近はremixの方が優勢になってきてる
ChatGPTもnext.jsだったのにremixに移行した

2024/10/01(火) 16:47:26.48

ただしremixはフルスクラッチで作り直すから
大幅に変わりそう
だから今手を出すべきかは微妙

2024/10/01(火) 16:48:32.91

どっちにしろ新規プロジェクトだからNextかなあ

2024/10/01(火) 16:49:20.05

じゃないRemix

2024/10/01(火) 18:54:14.07

まあフロントエンドなんて作り直すのは基本だし
まともなCTOがいたら予算も出るからその時の流行でよろしい
画面の動きを全部サーバーサイドの結果で判断できるように作っておけば問題なし

2024/10/01(火) 22:29:45.75

プロダクトの性質次第だろう
SaaSだとページ数多いしビジネス要件実装のウェイトが大きいから作り直しは難しい

2024/10/01(火) 22:30:17.57

>>345
ねーわ。どっちも outer join で駆動表が右か左か違うだけ。
クエリを書き換えて実行計画が変わったのを勘違いしただけだろ。

2024/10/01(火) 22:41:15.98

>>354
あるで調べてみ

2024/10/01(火) 22:45:51.49

leftと等価なrightへの書き換え、あるいはその逆の書き方を知らないだけでは？🤔

2024/10/01(火) 23:53:40.67

right joinを使う必要があるとは思えんな

**デフォルトの名無しさん** (JP 0Hdf-GCHr) · 2024/10/02(水) 07:12:03.51

345は20年前のOracle8iみたいなルールベースの知識からアップデートできていないだけな気がする

2024/10/02(水) 08:15:16.76

>>355
あるっつうならその実例出して

2024/10/02(水) 12:21:12.06

>>358
そーーかも

2024/10/02(水) 12:40:19.74

なんとなくいつもleftだわ

2024/10/02(水) 15:21:28.65

Nextはビルドツールが自前なのがな
RemixもsveltekitもNuxtもVite使ってるからそこでエコシステムの差が出てきそう
それが進んだらNextも厳しくなってくる

2024/10/02(水) 16:20:33.61

JSはいつまでエコシステムとかやるんすかね
いい加減デファクトをみんなで作ろうよってならないのかね
主に政治的思惑で一つにしたくないのだろうけど

2024/10/02(水) 17:16:13.23

right joinを使うと右から左へ、下から上へ読むようなクエリになるからな
読みづらいからrightは基本使わない
「遅いからrightは使わない」とか言ってる人は意味不明だけど

2024/10/02(水) 17:22:06.79

昔のDBでそういうのがあったんじゃないの？
知らんけど

2024/10/03(木) 00:02:27.79

まあ特に理由がなければleftだよなあ

2024/10/05(土) 12:16:43.81

HR系のシステムにおける従業員(主)と部署(従)のように、あるビジネスドメインにおいて着目する主体ってのはだいたい決まっているものだ
なので、SQLを書くときもそのメンタルモデルに倣って主側に置くものをある程度固定したほうが読みやすいという考え方もある
ある条件を満たす従業員と所属部署の一覧を表示する際に、従業員不在の部署も表示したいという要件があったとして、
そのようなちょっとしたビュー要件によって主従関係が逆転してしまうのは好ましくない、ということだ
俺はそれでもLEFT統一の方が読みやすいと思う派だが、考え方としては理解できるものだろう

2024/10/19(土) 07:55:36.48

svelte5のmilestoneが98%まで回復

2024/10/20(日) 20:29:57.78

release svelte@5.0.0

2024/10/28(月) 10:56:23.79

svelteで作っていたサイトはもうastroにしたんだよなあ
svelteの強味がよくわからなかった

**デフォルトの名無しさん** (JP 0H63-gQDg) · 2024/10/29(火) 22:21:02.13

EchoAPIは、テストが私のReactアプリに動力を提供するAPIを容易にし、開発を強化するための迅速な応答を提供。試してみてね

**デフォルトの名無しさん** (JP 0H63-gQDg) · 2024/10/29(火) 22:22:48.45

EchoAPIの直感的なインタフェースは、ReactアプリケーションでAPI応答を迅速に検証し、デバッグを容易にするのに役立つ。おすすめ！

2024/12/27(金) 03:32:05.43

Angularが久しぶりに盛り返してる
今年のアプデでかなり改善されたからだろうか
あと特筆すべきことはAstroの伸びかな
https://2024.stateofjs.com/

2024/12/27(金) 20:34:35.48

本当だVue抜いてるじゃん
Astroは絵に描いた餅感のイメージ強いんだけど、
この間bolt適当に弄ってたら何故かASTROでコード吐いてきたので
AIの力も借りて遊びでなんか作ってみようかなぁ

2024/12/28(土) 02:05:29.96

いやもうReactでいいよ…

2024/12/28(土) 06:54:44.06

jsx使ったことある人ならAstroは簡単に習得できると思う

2025/02/08(土) 10:31:21.71

>>373
Angular17以降爆速になったからな、Vite＋esbuildというチートで19は起動が6秒ぐらい
それでいてフルスタックのまま。スタンドアロン標準実装、Signal、ビルトインコントロールフロー
ようやく他と戦える体勢整ってきた

>>370
SvelteはAppleが協賛に入って脱TS目指して、アプリ特化になりつつある
Runeもまだ、既存技術をわかりやすくマーキングしただけだし

2025/02/08(土) 11:14:27.65

>>373
Viteの伸びもえぐいな、とうとうWebpack超えてしまったか

Reactも19になってようやく不満要素だった、テンプレート周りの改善とフォームのリアクティブ制御を実現してきた
ただReact普及に貢献してきたNextだけが、案の定Viteから爪弾き状態になってるのが気がかり
Remix、Astroはしっかり公式連携になってるのに

2025/02/09(日) 16:00:36.64

あとAngularはCSR、SSG、SSRをミックスした使い方ができる。これはフルスタックならではの強みであり芸当でもある

2025/02/09(日) 18:38:29.52

Angularってどう学べばいいの？
書籍は古いバージョンしか出てないし
公式サイト（日本）のはじめてのAngularだかも
今のバージョンでは動かなかったりして当てにならなかったわ

2025/02/09(日) 23:00:29.93

>>380
やっぱり本家のチュートリアルかねえ英語だけど
日本語の書籍は古すぎてオススメできない

2025/02/11(火) 10:22:24.86

>>380
ZennかQiitaあたりの使える記事を探すのが手っ取り早いかな
英語読めたらdev communityにも役立つ記事がいっぱいあるけど

Angularも14以降とそれ以前でReactの16.8以降と以前ぐらい別物の記述になってるから注意
あとAngular19からはstandalone標準だから、過去の動かしたい場合はstandalone: falseにしないと動かない

2025/02/11(火) 17:22:38.85

AngularはFCP遅いのがな
一度読み込んだら速いけど

2025/02/15(土) 10:10:33.69

最近の業務待機時間多いから、その合間にここ数年の流行りに取り組んでいるんだけど
solidJSがかなり書きやすくていい。Vueのようなライフサイクルフックもあるし、JSXのループ周りに対しても面倒なmap地獄に遭わなくて済む。Reactかじってたら多分すぐ覚える
システム複雑じゃなくていいけど、JSXでさっと書きたいって人にはおすすめ

RemixとAstroもいい感じだ
RemixはNextほど複雑さがないし
AstroはJSX、Vue、Svelte、Solidどの書き方も通るのが便利そう

2025/02/15(土) 14:53:40.95

でも案件ないからね

2025/02/16(日) 01:34:44.13

ネットうろうろしてるとNextどころか
まだまだVue、Nuxt多いなぁ
Astroとか日本の商用サイトで採用してるとこあるの？

**sage** (ﾜｯﾁｮｲ 6d44-ot0k) · 2025/02/16(日) 08:57:51.89

どこで何が役立つかわからん業界だし（今年はまさかのPerl大活躍）

>>386
Astro採用企業の有名どころはAmazon、ネトフリ、クックパッド（ここはかなり日和るが）とか
Microsoftもスポンサーになってるのが大きいかな、あとVite公認

2025/02/16(日) 09:40:54.74

GoogleとかトリバゴもAstro使ってるはず
国内企業は知らんけど

2025/02/19(水) 06:48:32.03

Remix良いとは思うんだけど
こういうフレームワークを更にラップしたようなのって流行過ぎた頃に困る予感しかしないんだよな
バックエンド含んでるから古くてもまぁ動けばええじゃろでサボることもできんし

2025/02/19(水) 07:02:57.77

>>389
どのフレームワーク使ってもその問題は付きまとうから気にしても意味ないような

2025/02/19(水) 07:36:49.70

create-react-appが非推奨になったとかなんとか

2025/02/19(水) 13:07:51.68

フルスタックものはだいたいそのリスクあるでしょ
堅牢なシステムを長期的に運用したいとかなんとかなら
結局愚直にバックエンドapi実装

2025/02/19(水) 14:31:22.96

大規模ならCOBOLかJAVAだろうね

2025/02/19(水) 14:34:20.07

フルスタックのリスク回避でapiは別に設けるのもアリだよねって思ってもいる
Remixイジり始めたばかりだけど

2025/02/20(木) 20:55:31.83

海外ではQwikも人気出てきてるみたいだし本当に群雄割拠だ

自分は今、Svelteのrune触りまくってるけど、一層proxy制御ガチガチになってて
堅牢性と拡張性は大幅に改善されてたけど、あれじゃもう、Vueと並び初級者向けとは言えんぞ

2025/02/21(金) 02:50:21.40

Reactみたいに汎用的なフレームワークは消えると思ってる
やっぱり個別にコンポーネントをコンパイルした方が効率いいのは間違いないのだし
サーバーサイドありきにするならこの考えが自然なのよね

2025/02/21(金) 05:02:26.87

>>396
litのこと言ってるのか？

2025/02/21(金) 18:42:50.18

>>397
いや基本的にはサーバー側でオンザフライにコンパイルされることが基本となると思う
svelteやqwik、solidを融合したような形になると思う

2025/02/21(金) 20:23:41.29

>>396
ReactとVueはあくまでライブラリだからな。だからガワ（フロントエンドツール）として売り出す手段にも出てるわけで。それだけにReactもそろそろ使いやすさ重視しないと離れていくだろうな
特に、今後のエコシステム次第ではSolidに乗り換えられる可能性は大いにある

VueはdefineModelがチート性能すぎてある意味今後が怖い

2025/02/22(土) 13:52:23.08

spaとか糞なUIはそろそろ消えると予想。
画面リロードに対応できない仕組みでUI構築すべきではないと気付き始めるだろ。

2025/02/23(日) 10:18:53.60

SSGもCORS問題が鬱陶しすぎる（ローカルで環境開発しにくいから開発コスト大）
のと、あとデータ量に比例して重くなっていく問題をなんとかせんと

2025/02/23(日) 11:27:58.14

>>400
むしろView Transitions APIとか出てきてSPAは手軽に作れるようになってきてるから消えないよ

>>401
ReactだともうSSGは縮小方向だな
今はReactでマトモにSSGやろうとしたらAstroが一番の選択肢になりそう

2025/02/23(日) 16:53:00.51

react難し過ぎるだろ。
フックの伝播複雑過ぎて、メンテナンスできない説。

2025/02/23(日) 20:10:37.18

まったく問題ないが

2025/02/23(日) 20:19:02.78

コールバック関数、分割代入、proxy　この３つを把握すればJSフレームワークはどれも同じ

2025/02/23(日) 22:02:12.64

笑

2025/02/23(日) 23:52:42.55

reactでShift選択するui作ったけど
自分で作ってもう触りたくない。
クリックのフックは子がハンドリングして親に返して、選択範囲の再描画は親が制御するみたいな。
これに余計な子は再描画しないようメモ化するとか入れると、頭こんがらがってくる。
どのフックで何のパラメータが変わってどれが再描画されるか解らなくなる。
設計書書かずに作ってるせいなんだが。

2025/02/24(月) 01:31:40.21

逆に生で作ることを考えたらまだマシとなる

2025/02/24(月) 02:07:21.52

Shift選択のUIってこんな感じの挙動？
ttps://codepen.io/rkeqkdzm-the-reactor/pen/wBvWpyp

2025/02/24(月) 05:09:50.45

ReactのMemoはマジでゴミだけどReact Compilerでやっと解決するらしいから

2025/02/24(月) 08:41:21.17

Reactでゴミなのはコントロールフロー系
Solidはそこをしっかり解決してる
もう一つのゴミだったルーター系も
Solidインスパイアしてるならそっちも真似したらいいのに

Solidにストア系実装されたらまじでシェア流れかねんぞ

2025/02/24(月) 09:31:11.82

>>410
どこ情報？

2025/02/24(月) 10:02:28.68

>>411
何言ってるんだ？
Solid RouterはReact Routerにインスパイアされて作られたって公式のドキュメントに書いてあるのに

2025/02/24(月) 10:30:53.78

>>411
React Router Domが6からSolid Router（旧solid-app-router）の記法をまんま真似してるんだよ
パクったというより連携だけど

2025/02/27(木) 01:30:31.68

>>407だけどreactで作ったchrome拡張の審査通った。
苦労して作ったから使ってみて欲しい。
適当なブログ開いて拡張のアイコンクリックすると画像一覧表示するから
欲しいの選択してダウンロードボタンでzipにできる。
スライダーで拡大縮小できるのがreactっぽい。
ttps://chromewebstore.google.com/detail/kakeaonncmnkigiijohfhlnondeaanii?utm_source=item-share-cp

2025/02/27(木) 14:33:11.76

気が向いたらソースコード公開して

2025/02/27(木) 15:23:22.00

なんでこんなところで宣伝してるんだよ…

2025/02/27(木) 17:26:15.56

reactらしいアプリ作ったから見て欲しかった。

2025/02/27(木) 17:40:04.07

作ったのほとんどAIなんだけどね・・・

2025/02/28(金) 01:45:11.43

誰が作ったのかもわからん怪しいextensionなんかインストールしてはいかんよ
簡単に情報抜かれる

2025/02/28(金) 11:51:23.66

公式でもザルだから入れない

2025/03/02(日) 15:42:07.55

みんなReactでフォーム作るときってinputタグ単位でコンポーネント作るの？

2025/03/02(日) 16:48:38.61

>>422
いや

2025/03/02(日) 17:33:25.66

コンポーネントって再利用しやすいように作るのであって
無駄に細分化すると面倒なことになる
必要になったら後からでもコンポーネント分けられるし

2025/03/03(月) 02:31:46.94

>>422
reRenderの単位かな

2025/03/03(月) 18:58:09.18

描画のタイミング自由に制御できるようになると、react楽しいねぇ。
それまでは糞だけど。

2025/03/03(月) 19:53:09.42

Reactのranderを封じて、
自前のタイミングで再描画する楽しさよ

2025/03/03(月) 23:50:14.94

Reactはmillion.js使えばsvelteやsolidよりレンダリングのパフォーマンスが良くなるよ

2025/03/04(火) 12:24:56.86

randerて

2025/03/09(日) 10:22:31.29

>>422
コンポーネントというより、質問のニュアンスだとフォーム部品ごとの出力オブジェクトか
制御フックのこと言ってるっぽいが

Reactはフォーム処理に関してSvelte、Vueにくらべたら糞性能というか、もともとが
深層ステート管理のためのライブラリだしな。複数のフォームを一発制御できる
useStateフックの書き方ググるかカスタムフックで作る

それかReact捨てて、簡単にリアルタイム制御できるVueかSvelteで作るかだな
どっちもストアライブラリ使わないとスパゲッティまっしぐらだがな

2025/03/16(日) 20:48:29.74

>>386
商用サイトじゃないけど、学研グループの勉強サイトはAstroで書かれてるね
https://manabitimes.jp

2025/03/17(月) 14:00:57.63

芳根京子の公式サイトはNextだった

2025/03/17(月) 21:32:57.57

SvelteKitとても好きです。

2025/03/21(金) 06:23:05.04

Astro触ってみたけどすごいなこりゃ
こんなのできるならよほど大規模なサービスでも無ければNext.jsは要らないのでは

2025/03/21(金) 08:43:51.55

Astroまだちゃんと触ったことないけど
Reactコンポーネントを将来、全く別のフレームワークのコンポーネント、例えば引数とレンダリング結果が同等の動きをする、コンパイルされたバイナリなんかに差し替えたりとか出来たら面白いな

2025/03/22(土) 21:59:34.30

どうせAI任せになるから関係ない
近いうちにAIが直接SSGしたりWeb Assemblyを直接生成するようになるからフレームワークなんか消滅する

2025/03/22(土) 22:19:49.62

>>436
おまえの方が早く消滅しそう...

2025/06/10(火) 00:46:00.18

Remix v3が大改造するみたいだな
従来のRemixはReact Router v7になってRemix v3はpreactベースになるということか

2025/06/30(月) 02:27:29.14

スレチだったらごめん

オンライン麻雀ゲームを作成しようと構想(妄想)してるんだけど、
いまから新規に作るならフロント側にはReactかVue.jsか、あるいは他のライブラリのどれを使えばいい?

先駆者 (書籍も出してる) は

> jQueryでないと美しく実装できない
https://blog.kobalab.net/entry/2021/03/25/205151

って言ってるけど、Webゲームのクライアントは特殊ってこと?

2025/06/30(月) 03:09:35.81

その記事の人はReact使ったことがないから知識ゼロなんだろ
そもそも状態管理をして宣言的にUIを構築するんだからむしろReactのほうがスッキリ書ける
jQueryおじさんという化石思考に惑わされてはいけない

2025/06/30(月) 03:19:10.31

> 宣言的アプローチでは「打牌中」の状態を描画できない
いや、Reactでは描画のための状態はUIコンポーネント内部に保持することでコアロジックを汚染することなく打牌中のような中間状態を美しく描画することができる

2025/06/30(月) 03:23:08.67

Reactは宣言的UIは最終的な状態だけを表現するということではない
アニメーションやユーザー操作に伴う一時的な状態、ここでは打牌中もコンポーネントの内部状態やコンテキストAPIとかで管理できる
isPlayingAnimationのようなブーリアン型の状態を用意し、アニメーション中はtrueに設定し、アニメーションが終了したらfalseに戻す
打牌中の牌の位置や動きに関する情報を状態として持ち、その状態に基づいてCSSアニメーションを適用する

2025/06/30(月) 03:27:13.20

> Majiang.ShoupaiはAIの思考ルーチンでも使用します。ここに描画の都合の「打牌中」などという状態を持ち込むとしたら、それは設計として誤っています
Reactでも描画に関わる状態とアプリケーションのコアロジックに関わる状態は分離して管理するのが一般的
コアロジックの麻雀の牌姿やルール進行を司る部分は、Reactコンポーネントからは独立した純粋なJavaScriptクラスや関数として実装するのが普通

2025/06/30(月) 03:33:46.29

> イベントハンドラ設定は描画処理と分離すべきである
Reactの設計思想はコンポーネントが自身の描画とそれに関連するイベントハンドリングをカプセル化すること
「対戦相手の手牌にイベントハンドラは不要だし、牌譜再生にも打牌のためのイベントハンドラは不要」という点についてはReactのコンポーネント設計で柔軟に対応できるからまったく問題なし
isInteractive: booleanなどを渡すことでイベントハンドラの有無を制御できる
牌譜再生時にはイベントハンドラが不要なモードでコンポーネントを描画すればいいだけだし

2025/06/30(月) 03:43:00.60

> JSXを使う局面がない
> HTML に雛形として埋め込まれた「牌を表現するDOMノード」をコピーし差し込むことで実現しています。
Reactをまったく知らないからこんな恥ずかしことを堂々と言えるんだろう
こいつのもっとも無知なところだな
Reactは宣言型だからコピーするというコードを書くことすら不要なわけ

2025/07/01(火) 16:48:29.62

牌なんてCanvasに直接描画すりゃエフェクトも自在だし変にエレメントにデータ持って
重くなることもなくていいんじゃね？って思うのは俺だけなのか

2025/07/03(木) 12:01:40.42

>>446
俺もこう思う
そもそも牌をhtml要素とCSSで描画すること自体が微妙だよね
そういう意味だとjQueryでもReactでもなくてCanvas系のフレームワーク使ったほうが良いんじゃないかな

2025/07/06(日) 06:18:05.39

宣言的UIに慣れるとCanvas全体を命令的に描画するのがあまりにもダル過ぎる

2025/07/06(日) 11:52:25.82

Canvas上の各表示オブジェクトを
Reactやビューで
あたかもHTMLの要素の様に操作できる（CSSプロパティ設定できる）
ライブラリってあるのかな。

2025/07/06(日) 12:44:53.42

flutterでよくね

2025/07/09(水) 16:01:11.75

実際のゲーム開発で宣言的UIが採用されることってあるの？

2025/07/20(日) 07:51:42.37

設定画面とかチュートリアルなら、まあ宣言的UIを使うもアリ。

2025/10/14(火) 01:38:41.26

Remixが謎方向に進んでいる
Reactを捨てるのか

2025/10/14(火) 08:36:28.99

React捨ててReactもどきを新しく作ったのか
流石にもういらんだろ

2025/10/14(火) 12:34:52.90

Reactは迷走してるって言ってるけど『お前もじゃい！』って感じだな
しかしReact前提のフルスタック全滅したらバックエンドはどうしてくのが良くなるのかねぇ

2025/10/14(火) 18:50:59.98

バックエンドは今でもRailsが大人気だぞ

2025/11/16(日) 09:40:05.17

今さらPugやEJSやThymeleafJSが再流行するとも思えんよなあ