24/09/23 13:53:57.31 ZAvpVZgFH.net
vueは好きじゃないけどパフォーマンスの改革がすごい
今ではsvelteと変わらんくらいのパフォーマンスになってる
あとnuxtの話になるけどunjsが良い
263:デフォルトの名無しさん
24/09/23 18:01:38.02 kRT830++0.net
Next.jsよりHonoがすげえ伸びてるよな
開発者一人だけっぽいけど大丈夫なのか？
264:デフォルトの名無しさん
24/09/24 12:53:38.69 25SVKRoU0.net
>>235
pythonでいいし
265:デフォルトの名無しさん
24/09/24 12:53:56.13 25SVKRoU0.net
>>263
趣味ならいいんじゃね？
266:デフォルトの名無しさん
24/09/24 12:54:47.28 25SVKRoU0.net
>>262
好きじゃないけど慣れちゃうとこれでいいかとなってしまう
フロントエンドなんてどうせ作り直す想定なんだし
267:デフォルトの名無しさん
24/09/24 12:55:15.04 25SVKRoU0.net
>>261
ググることなんてあるか？
ChatGPTで十分だろ
268:デフォルトの名無しさん
24/09/24 12:55:32.57 25SVKRoU0.net
>>260
ChatGPTで困らない
269:デフォルトの名無しさん
24/09/24 12:57:04.04 25SVKRoU0.net
>>259
多少面倒でもReactみたいに統一的な書き方ができる方が良いことに気がついた時には手遅れだった
270:デフォルトの名無しさん
24/09/24 12:57:43.99 25SVKRoU0.net
>>258
マジで超単純なフォーム系のWebをサクッと作る用途に向いてるよね
ちょっとややこしいことすると破綻する
271:デフォルトの名無しさん
24/09/24 12:58:18.09 25SVKRoU0.net
>>257
Remixもビミョー
272:デフォルトの名無しさん
24/09/24 12:58:46.23 25SVKRoU0.net
>>255
クソだけどあるものからしか選べないのよね
273:デフォルトの名無しさん
24/09/24 12:59:11.60 25SVKRoU0.net
>>250
ゴミでもやるしかないんだよ
274:デフォルトの名無しさん
24/09/24 14:46:15.54 4ZTe9NQw0.net
そもそもAIの時代になってもはやUIというものが無くなるからjavascriptもだんだん使われなくなっていくだろうな
275:デフォルトの名無しさん
24/09/24 15:46:19.24 25SVKRoU0.net
5年以内には画像から完全なフロントエンド実装を作るツールが生まれるのは間違いないだろうけど
フロントエンドもサーバーサイドに回帰してるから結局コード書けないとダメ
276:デフォルトの名無しさん
24/09/24 15:47:43.57 25SVKRoU0.net
wasm gcが入るとほとんどの言語がwasmコンパイル可能になるから
新たなエデンが生まれると思う
277:デフォルトの名無しさん
24/09/24 17:31:42.29 jWNJpVja0.net
>>276
そうか？
デスクトップソフトですらweb技術で作られることが多くなった時代なのに
278:デフォルトの名無しさん
24/09/24 18:07:06.89 FmaiGP410.net
ガワはだいたいReactだね
279:デフォルトの名無しさん
24/09/24 18:49:58.49 25SVKRoU0.net
>>277
言語に縛られないからその点は良いよ
wasm対応の好きな言語を選べるようになると素晴らしい
まあ流行らなかったらキツいけど
280:デフォルトの名無しさん
24/09/24 23:11:17.46 vg4kYONk0.net
>>275
> フロントエンドもサーバーサイドに回帰してるから結局コード書けないとダメ
回帰ってのはどういう意味？
281:デフォルトの名無しさん
24/09/25 00:05:02.99 rLLrPC9L0.net
サーバーサイドレンダリングのことじゃねえの？
古のMVCから変わってクライアントサイドでレンダリングするようになっていったかと思えば今度はまたNextのAppRouterよろしくSSR(orSSG)になったりと忙しない業界よな
282:デフォルトの名無しさん
24/09/25 00:09:03.70 UXiRrgGj0.net
>>281
単にWebベースのクライアントアプリの事を言ってると思う
283:デフォルトの名無しさん
24/09/25 15:20:38.11 KipVgYfg0.net
まさにサーバーサイドレンダリングのことだ
結局コンポーネントに必要なデータはサーバーで取得した方が早いよねということにフロントエンドの人が気がついて
サーバーサイドの人は今更何言ってるの？みたいなる空気感
コードの共有がそれほど意味があるとは思えないし
サーバーサイドは別の速い言語で作れば良くね？って思うけどね
284:デフォルトの名無しさん
24/09/25 15:22:37.11 KipVgYfg0.net
最近はフロントエンドの人がサーバー側に口出ししてきて
今更ORMガーとか言ってて昭和かと
こっちはORM地獄を10年以上前に経験してウンザリしてるんだよ
285:デフォルトの名無しさん
24/09/25 15:45:33.76 EcYO77Ak0.net
とサーバーしかしらん無知君が吠えてます
こいつ勘違いしてるというより無知だから今までのサーバーサイドレンダリングと同じだと思ってるらしい
286:デフォルトの名無しさん
24/09/25 16:31:31.44 KipVgYfg0.net
Twitterで騒いでるフロントエンドインフルエンサー()の方々はCSの知識がないのに調子乗ってるから本質が掴めてないんだよな
SSRなんて変な名前つけちゃってからに
287:デフォルトの名無しさん
24/09/25 16:35:31.76 KipVgYfg0.net
>>285
その発言はサーバーサイド何もわかってませんと言ってるようなもの
288:デフォルトの名無しさん
24/09/25 16:39:07.42 EcYO77Ak0.net
>>287
何もわかってませんってなんだ？
ずっとサーバーサイドの開発も散々してきてるが
お前はフロントエンドを何も理解してねえから無知晒してんだろw
マジで恥ずかしいレスだったわww
289:デフォルトの名無しさん
24/09/25 16:41:31.67 KipVgYfg0.net
>>288
匿名掲示板でそんなイキリをして恥ずかしくないのか？
それをどうやって確認するんだよ
確認できないようなことでイキるな
発言内容だけしか見ないんだよ
290:デフォルトの名無しさん
24/09/25 16:42:50.66 KipVgYfg0.net
あ、名前と所属晒すなら信じてやるけど？
291:デフォルトの名無しさん
24/09/25 16:46:02.20 EcYO77Ak0.net
>>289
何度読み返してもこれほどの無知はこのスレにはいねえわw
久しぶりにサーバーサイドおじさんが勝ち誇ったと思ったら実際はただの無知でしたってオチだったww
少しは勉強してから来てくれるか
292:デフォルトの名無しさん
24/09/25 16:47:50.81 KipVgYfg0.net
>>281
フロントエンドが「これからはレンダリングはこっちでやりまっせ」みたいなノリでこっちはもうAPIだけ作ればいいのかラクチンだーと思ってたら
いきなりサーバーサイドに土足で踏み込んできて
NextダーRemixダー言い出してもうめちゃくちゃだよ
293:デフォルトの名無しさん
24/09/25 16:48:40.15 KipVgYfg0.net
>>291
何も言ってないのと同じ
やりなおし
294:デフォルトの名無しさん
24/09/25 16:50:33.98 KipVgYfg0.net
ワイらがNext.jsの運用もやりまっせ！からの面倒だからVercel使いますと言われた日には我々の怒りもピークだよ
295:デフォルトの名無しさん
24/09/25 16:53:47.88 KipVgYfg0.net
中身のないイキリレスだけしたいなら消えてくれないか？
不愉快だし境界知能のADHDに構ってるほど暇じゃないんだ
そもそもがレスバでも俺には勝てない
感情のコントロールもできないやつの発言なんて聞くわけがないだろう
何度もいうが発言の中身だけしかみない
匿名掲示板はそういうところだ
296:デフォルトの名無しさん
24/09/25 16:57:48.51 EcYO77Ak0.net
なんだこいつ
レス連投のキチガイか
理解できないなら使わなきゃいいだろ
297:デフォルトの名無しさん
24/09/25 19:02:29.97 5Vhwl/nZ0.net
連投ちゃん増えたな
298:デフォルトの名無しさん (ﾜｯﾁｮｲ 1f64-L8o3)
24/09/25 19:06:11.81 UXiRrgGj0.net
>>283
それはないね
299:デフォルトの名無しさん
24/09/25 20:19:06.11 W1zkzLQM0.net
>>296
ケンカを売ってきたのはお前だろ
300:デフォルトの名無しさん
24/09/25 20:19:58.50 W1zkzLQM0.net
技術者なら中身のある批判をかけ
書けないなら黙ってろ
301:デフォルトの名無しさん
24/09/25 20:28:21.84 Mp8Xmxrz0.net
あー、、
そもそも最近のSSRやらSSGは普通DB操作まではやらんでしょ？
最近の豪華絢爛なUIを何でもかんでもクライアント側でレンダリングできるようにすると、そのレンダリングのためのコードで転送量が爆裂する上、
クライアント側の処理能力も問題になってくるからサーバーでレンダリングした結果を渡した安定するよねって流れだと思うよ
だから相変わらずAPIは提供してやる必要がある
ぶっちゃけ、処理効率を突き詰めていくとjsonやらxml吐き出すAPI叩いて結果からレンダリングしてみたいなバケツリレーのようなマネするよか、そのままAPIから直接html吐き出した方が処理効率はいいけどね
職務分掌の意味合いが強いと思う
302:デフォルトの名無しさん
24/09/25 21:10:16.58 EcYO77Ak0.net
>>300
>>301
こいつらも何もわかってなくてワロタw
そもそもコイツ↓のこのレスみて無知無能さがマジでわかるだろw
>>283
> コードの共有がそれほど意味があるとは思えないし
> サーバーサイドは別の速い言語で作れば良くね？って思うけどね
まさかのコードを共有してるだけだと思ってるらしいw
まっっったく理解してないどころかド素人通り越して知識ゼロで話にならんw
サーバーサイドは別言語で良くねって完全に自分は無知ですって言ってるようなもんだろwww
Next.jsとかのSSRとサーバーサイド言語のSSRが同じだと思ってんなら邪魔だからここから出ていけよwww
303:デフォルトの名無しさん
24/09/25 21:54:30.34 EyxmHrtR0.net
>>302
もうお前は黙ってろ
304:デフォルトの名無しさん
24/09/25 21:57:22.46 W1zkzLQM0.net
>>302
何も言ってなくて草
305:デフォルトの名無しさん
24/09/25 22:11:30.78 /fsA69Ud0.net
>>301
コードはページ開いた初回だけだぞ
（かつコードもローカルにキャッシュする事も可能）
それ以降はREST API叩くだけだから
ネイティブアプリと遜色ないレベルで動く
306:デフォルトの名無しさん
24/09/25 22:26:15.23 Mp8Xmxrz0.net
>>305
それがつまりはクライアントサイドレンダリングが持て囃されてた10年ぐらい前の思想でしょ
豪華になっていくにつれてそれじゃ問題が出てきたからAppRouterのSSR&SSGと言ったもんが出てきたわけよ
307:デフォルトの名無しさん
24/09/26 02:02:17.79 O7j1NTfr0.net
>>306
ばか
308:デフォルトの名無しさん
24/09/26 12:39:43.01 58bl5mE90.net
>>301
cloudflare D1とか普通にやれるしむしろ積極的に使う方向性
サーバーレスDBだ
あと普通にpostgresqlサーバーへ接続できる(!)
もう何でもあり
309:デフォルトの名無しさん
24/09/28 21:18:59.88 ndtOzxxh0.net
フロントエンドのPrismaに対する過剰な評価はなんなんだろう
そもそもORMなんて20年前にサーバーサイドで死ぬほど開発され全てクソという結論に至った技術なのに
310:デフォルトの名無しさん
24/09/28 22:18:23.73 XHRbCS6j0.net
>>309
べつにPrisma以外のORMでもいいけど
TypeScriptから型安全に使えるのがいいんだよ
311:デフォルトの名無しさん
24/09/28 23:08:59.38 XzOFonI/0.net
>>310
RDBのインターフェースにおいて型安全という思想自体が間違ってる派だがそれは置いておいて
定義したスキーマに対して型安全に使いたいならそれこそJavaやC#でそれこそ海千山千レベルで作られた
しかしどれも使いやすくはなく最終的にはシンプルなクエリービルダー型のものだけが残った
必要なのはORMではなく単なるSQLクエリービルダーだったというのが結論
まあ歴史を繰り返すことが悪いとは言わないが
自分で実装したものもないのになんかレベル低いことやってるなあと
「wasmコンパイルした時のサイズが最小のクエリビルダーを作る」というのは技術的にかなり面白いと思うけどね
312:デフォルトの名無しさん
24/09/29 01:13:04.48 YuH+Iogz0.net
フロントやってる人って強い言葉で極論語りたがるってことが、
顕著に表れてる数レスだなあって思った
313:デフォルトの名無しさん
24/09/29 01:47:21.26 xSeXse3x0.net
極論ではなく以下の構成が最適なのはいうまでもない
DBマイグレーションツール
+
データベース接続を抽象化するアダプターモジュール
+
SQLクエリービルダー
これこそがモダンなインターフェースなのである
314:デフォルトの名無しさん
24/09/29 02:23:06.66 EGkJuPay0.net
昔は、ローカルの開発環境ではsqlite、実環境ではDBMSとかあったからORMにもメリットがあった。
でも今ではローカルでも実環境と同じDBシステムを使えるようになってるし、調査では結局素のSQL見る必要もあるし、リプレースする際でもフロント、バックエンド、DBシステムのなかではDBシステムの変更が一番可能性は低い。
それならORM毎の違い覚えるより素のSQLを使いこなせるようになったほうが長く使えるスキルになる。
結局ほしいのは >>313 で言ってるものだな。
315:デフォルトの名無しさん
24/09/29 06:12:44.91 4S/kVkYa0.net
昔、SQL使えないアホの選択肢がORMだったのよ
316:デフォルトの名無しさん
24/09/29 08:21:21.24 Acvl9FUC0.net
PrimaはTypedSQLみたいなものも出してきてるし
結構面白いよ
317:デフォルトの名無しさん
24/09/29 08:29:21.92 IdcZrtIu0.net
20年ぐらいこの業界やってるけど最適化を進めて複雑なサブクエリやらWITHやらを使い始めると、
大抵ORMじゃ対応しきれなくなって結局生のクエリを実行させるようになるケースが多すぎたな
318:デフォルトの名無しさん
24/09/29 08:41:41.79 8BzfSqEJ0.net
ぶっちゃけJSONにaxiosあたり出てきてLaravelがガワ連携実装してから、他言語フレームワークもガワ連携前提がデフォ化して自己完結主義のAngular以外ガワツールと化してる感あるな。あとは複雑だが階層は浅いフォーム制御が得意（Vue）か、単純だが階層が深いステート管理が得意（React）かで選択肢が変わる
ヨーロッパだとSvelte（イギリス生）が人気になってきてるみたいだけど、日本というかアジアはVue強いし、まだまだ普及に時間かかりそう
319:デフォルトの名無しさん
24/09/29 09:28:52.49 Acvl9FUC0.net
svelteを採用してる企業を見たことがない
320:デフォルトの名無しさん
24/09/29 13:04:00.66 xSeXse3x0.net
>>315
SQL理解できないのにORM使おうというのがそもそも間違いだからな
チューニングとか別の人がやるのか？って話
ふざけんなと
あと生成したSQLが本当に求めているものなのかのチェックも必要
SQL生成ごっこがしたいなら好きにしたらいいが
>>317
それと最近はデータ分析用にかなり複雑なSQLを投げることが増えた
別途バッチにすることも多いがどうしてもリアルタイムで実行しなきゃならんこともあったりして
これが厄介なんよね
彼らの実行するクエリはもう型とかぐちゃぐちゃ
321:デフォルトの名無しさん
24/09/29 13:08:53.67 sHRcN5PC0.net
ORMしか使えない奴ら多いよな
バックエンドエンジニアでSQL書けず最適化もできない連中ばっか
322:デフォルトの名無しさん
24/09/29 13:16:26.30 xSeXse3x0.net
>>316
サーバーサイドが型合わせ不毛だよねと実質捨てた部分を今どのように再開発するのか楽しみではある
「先」に進めてくれるのだろうか
ちなみに改めてORMを調べてみたがやはり状況は大して変わっていない模様
SQLクエリービルダーは大抵の言語でかなり進化しているが型のマッピングは程々にするという妥協案
Haskellが1番面白かった
以下のようにモナディックで型安全なSQLが書ける
ここまでやれるやらありか？とは思ったが
select $ from $ \person -> do
where_ (person ^. PersonAge >. val 30)
return person
323:デフォルトの名無しさん
24/09/29 16:05:49.23 4S/kVkYa0.net
SQL書けないからORMのtable単位で更新するレベルの機能で良しとするんですよ
324:デフォルトの名無しさん
24/09/29 16:25:50.06 xSeXse3x0.net
ちなみにJavaやC#のORMで出た型付けの結論は
「オブジェクトのプロパティと実行するSQLの型を手動でマッピングする」です
マッピングは動的に変えられるので汎用性がある
テーブルの型とプログラミング言語の型を直接マッピングしないというのがミソ
325:デフォルトの名無しさん
24/09/29 16:38:12.07 xSeXse3x0.net
簡単に言うと実行するSQLごとに型付けをする感じ
これだと同じテーブルで型が変わる場合などでも対応できる
PrismaのTypedSQLもこれに近いものなのではないの？
Java界の奴らが10年以上かけてたどり着いた結論だから多分こうなると思うよ
326:デフォルトの名無しさん
24/09/29 17:18:57.60 4S/kVkYa0.net
>>313
>>SQLクエリービルダー
ってGUIでクエリーを書く機能のこと？
327:デフォルトの名無しさん
24/09/29 17:35:45.85 rGDHQpvA0.net
SQL書けなくてどうやってデータ保存してるだ？
本当にSQL書けないならSQLite辺りで覚えていったほうが良いかもね
328:デフォルトの名無しさん
24/09/29 17:47:58.09 xSeXse3x0.net
>>326
違う
単に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が生成されるか？は見なくてはならない
329:デフォルトの名無しさん
24/09/29 17:54:18.58 8BzfSqEJ0.net
>>319
いちばん有名な企業が楽天グループ、そこは公認パートナー企業にもなってる
>>327
ORMは便利だけどそっちしか知らない人が多いというか、各種フレームワークからデバッグ用にSQL吐き出せること知らない人も多い。だから結合とか副問い合わせで躓いてるのをよく質問サイトで見かけたな
330:デフォルトの名無しさん
24/09/29 18:05:01.99 /6K/Gjr+0.net
おぞましいことに、SELECT * FROM xxx WHERE yyy = zzzみたいな糞クエリのゴリ押しだけで全部解決しようとする新人がたまにいるのよ
明らかにJOINやサブクエリやウィンドウを使えば効率的に一度のクエリで解決する要件も、何回も何十回もクエリ発行して取りに行く
負荷試験が壊滅的だったプロジェクトに火消しを頼まれて助っ人で行ってみたらそんなザマで頭抱えたことがある
結局ほとんど俺が全部書き直した
331:デフォルトの名無しさん
24/09/29 18:20:31.60 /6K/Gjr+0.net
あんなDBの使い方しかしない（できない）からORMの弊害に気付かないんだと思うわ
型安全と言っても、それテーブルの全カラムを無加工で取得したい場合ぐらいしか有効に働かないだろうに
332:デフォルトの名無しさん
24/09/29 18:29:40.63 4S/kVkYa0.net
>>328
ストレートーにSQL書けよと言いたくなるな
障害時に綺麗なSQLはけてないと復旧とか損害保証とかできるの？
333:デフォルトの名無しさん
24/09/29 18:36:09.04 4S/kVkYa0.net
>>330
昔DBAという役職があって
その人に使用するSQL全部チェック対象にされ...
334:デフォルトの名無しさん
24/09/29 18:38:11.33 1Tb71lk/0.net
ストレートにSQL書くと、パラメーターとの文字列連結がカオスになるよ
335:デフォルトの名無しさん
24/09/29 18:41:51.91 4S/kVkYa0.net
サブクエリに、with、一時table使ってSQL書いてるけどそんな事一度もなかったな
336:デフォルトの名無しさん
24/09/29 18:43:50.27 xSeXse3x0.net
今回の調査で色々と調べたけど
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();
337:デフォルトの名無しさん
24/09/29 18:45:39.57 xSeXse3x0.net
caseってデータ分析ではめちゃくちゃ使うのだけど
これがこんな感じで書ける
素晴らしい
338:デフォルトの名無しさん
24/09/29 18:47:22.71 xSeXse3x0.net
>>333
昔は社内にオラクルデータベースの番人みたいなおじさんがいたなあ
339:デフォルトの名無しさん
24/09/29 19:00:17.50 8BzfSqEJ0.net
>>330
select * from tableA join tableBとして、吐き出した全データを配列に格納、展開してたトンデモプログラムをデバッグしたことあるよ…。アスタリスクは百歩譲ってもせめて部分結合してくれ
データ数千件しかないのにフォーム処理クッソ重いと思ったらこれだよ
340:デフォルトの名無しさん
24/09/29 19:25:17.35 Ck7eDstu0.net
>>334
一回のトランザクション処理につき一回だけSQL実行可とルールすればよい
おのづとサブクエリ、with、一時tableを使う事になって、SQL投げて結果でSQL投げみたいな処理を繰り返すヘボ実装が一掃される
341:デフォルトの名無しさん
24/09/29 19:26:59.25 /6K/Gjr+0.net
>>333
たいがいそこが開発進行のボトルネックになってたけど当時は必要悪だったと思うよ
あの頃のオンプレの商用環境（しかも大抵カツカツの構成）で、クソゴミクエリぶん回そうものなら即死してサービスダウンに陥ってたもんよ
今のクラウドのマネージドDBだったらただ遅いor費用が嵩むだけで落ちるとこまで行くことはそうそうないけど、昔は死活問題だった
342:デフォルトの名無しさん
24/09/30 14:16:26.25 5Q41gUpla.net
一つの処理を一つのSQLクエリならアトミックになって問題無いけど
一つの処理を複数のSQLクエリで時間差が出来るから他所からデータ割り込まれたら困るケースがあるだろ
そこまで考慮してないアホばっか
343:デフォルトの名無しさん
24/09/30 16:35:49.13 eyZN3jLh0.net
一番早いのは個々のSQL連結したをストアドなんだよなー
JOINもINNNERとRIGHTは遅いからLEFTのみ
344:デフォルトの名無しさん
24/09/30 16:59:05.93 90xjyaJO0.net
>>343
inner使ってたけどleftのが速いんだ？
345:デフォルトの名無しさん
24/09/30 22:19:31.77 x8UwNGco0.net
そもそも得られる結合結果が違うし、INNERのほうが効率的なケースもLEFTのほうが効率的なケースも存在するから思考停止せずにしっかり実行計画確認しろ
「何にでも～～を使う！」ってのはバカの一つ覚えってんだ
346:デフォルトの名無しさん
24/09/30 22:31:07.26 2/RvbFVp0.net
left と right で速度が違うとか言ってる奴の話を真に受けんな
347:デフォルトの名無しさん
24/09/30 23:41:53.43 6IhSUC9Z0.net
>>346
結構あるで
348:デフォルトの名無しさん
24/10/01 10:17:07.05 tNPrHSB3p.net
リスト構造なら違いは無いよな？
349:デフォルトの名無しさん
24/10/01 16:04:12.61 20pFp1ah0.net
本読んでたらNextすげーいいじゃんと思ってきた、なんか学習コストは高そうな気がするけど
remixは調べてない
350:デフォルトの名無しさん
24/10/01 16:46:36.79 Ig6Tf0ue0.net
最近はremixの方が優勢になってきてる
ChatGPTもnext.jsだったのにremixに移行した
351:デフォルトの名無しさん
24/10/01 16:47:26.48 Ig6Tf0ue0.net
ただしremixはフルスクラッチで作り直すから
大幅に変わりそう
だから今手を出すべきかは微妙
352:デフォルトの名無しさん
24/10/01 16:48:32.91 20pFp1ah0.net
どっちにしろ新規プロジェクトだからNextかなあ
353:デフォルトの名無しさん
24/10/01 16:49:20.05 20pFp1ah0.net
じゃないRemix
354:デフォルトの名無しさん
24/10/01 18:54:14.07 gaoRlfpT0.net
まあフロントエンドなんて作り直すのは基本だし
まともなCTOがいたら予算も出るからその時の流行でよろしい
画面の動きを全部サーバーサイドの結果で判断できるように作っておけば問題なし
355:デフォルトの名無しさん
24/10/01 22:29:45.75 V2w3Ucz+d.net
プロダクトの性質次第だろう
SaaSだとページ数多いしビジネス要件実装のウェイトが大きいから作り直しは難しい
356:デフォルトの名無しさん
24/10/01 22:30:17.57 7hV/Zxp/0.net
>>347
ねーわ。どっちも outer join で駆動表が右か左か違うだけ。
クエリを書き換えて実行計画が変わったのを勘違いしただけだろ。
357:デフォルトの名無しさん
24/10/01 22:41:15.98 PxjtxeQz0.net
>>356
あるで調べてみ
358:デフォルトの名無しさん
24/10/01 22:45:51.49 GFljMLhp0.net
leftと等価なrightへの書き換え、あるいはその逆の書き方を知らないだけでは？🤔
359:デフォルトの名無しさん
24/10/01 23:53:40.67 Ig6Tf0ue0.net
right joinを使う必要があるとは思えんな
360:デフォルトの名無しさん
24/10/02 07:12:03.51 H5d/PPBcH.net
345は20年前のOracle8iみたいなルールベースの知識からアップデートできていないだけな気がする
361:デフォルトの名無しさん (ｽﾌﾟｯｯ Sd1f-PqsP)
24/10/02 08:15:16.76 L5vBX47Zd.net
>>357
あるっつうならその実例出して
362:デフォルトの名無しさん
24/10/02 12:21:12.06 XNBCv0lf0.net
>>360
そーーかも
363:デフォルトの名無しさん (ﾜｯﾁｮｲ 6fcd-fhRs)
24/10/02 12:40:19.74 VhOKxDCS0.net
なんとなくいつもleftだわ
364:デフォルトの名無しさん
24/10/02 15:21:28.65 ntIVC1snM.net
Nextはビルドツールが自前なのがな
RemixもsveltekitもNuxtもVite使ってるからそこでエコシステムの差が出てきそう
それが進んだらNextも厳しくなってくる
365:デフォルトの名無しさん (ﾜｯﾁｮｲ 63f0-bFHd)
24/10/02 16:20:33.61 TLprtWVf0.net
JSはいつまでエコシステムとかやるんすかね
いい加減デファクトをみんなで作ろうよってならないのかね
主に政治的思惑で一つにしたくないのだろうけど
366:デフォルトの名無しさん
24/10/02 17:16:13.23 BpVEd4dp0.net
right joinを使うと右から左へ、下から上へ読むようなクエリになるからな
読みづらいからrightは基本使わない
「遅いからrightは使わない」とか言ってる人は意味不明だけど
367:デフォルトの名無しさん
24/10/02 17:22:06.79 xvxi+lxb0.net
昔のDBでそういうのがあったんじゃないの？
知らんけど
368:デフォルトの名無しさん
24/10/03 00:02:27.79 fliyUvHO0.net
まあ特に理由がなければleftだよなあ
369:デフォルトの名無しさん
24/10/05 12:16:43.81 RBSjgErc0.net
HR系のシステムにおける従業員(主)と部署(従)のように、あるビジネスドメインにおいて着目する主体ってのはだいたい決まっているものだ
なので、SQLを書くときもそのメンタルモデルに倣って主側に置くものをある程度固定したほうが読みやすいという考え方もある
ある条件を満たす従業員と所属部署の一覧を表示する際に、従業員不在の部署も表示したいという要件があったとして、
そのようなちょっとしたビュー要件によって主従関係が逆転してしまうのは好ましくない、ということだ
俺はそれでもLEFT統一の方が読みやすいと思う派だが、考え方としては理解できるものだろう
370:デフォルトの名無しさん
24/10/19 07:55:36.48 kXgKzXcr0.net
svelte5のmilestoneが98%まで回復
371:デフォルトの名無しさん (ﾜｯﾁｮｲ 1923-pdRO)
24/10/20 20:29:57.78 XEBgqfIg0.net
release svelte@5.0.0
372:デフォルトの名無しさん (ﾜｯﾁｮｲ 1901-h/XG)
24/10/28 10:56:23.79 MeMed5MX0.net
svelteで作っていたサイトはもうastroにしたんだよなあ
svelteの強味がよくわからなかった
373:デフォルトの名無しさん
24/10/29 22:21:02.13 yFBNIKKHH.net BE:629052145-2BP(1000)
URLﾘﾝｸ(img.5ch.net)
EchoAPIは、テストが私のReactアプリに動力を提供するAPIを容易にし、開発を強化するための迅速な応答を提供。試してみてね
374:デフォルトの名無しさん
24/10/29 22:22:48.45 yFBNIKKHH.net BE:629052145-2BP(1000)
URLﾘﾝｸ(img.5ch.net)
EchoAPIの直感的なインタフェースは、ReactアプリケーションでAPI応答を迅速に検証し、デバッグを容易にするのに役立つ。おすすめ！
375:デフォルトの名無しさん
24/12/27 03:32:05.43 hxF8JUMM0.net
Angularが久しぶりに盛り返してる
今年のアプデでかなり改善されたからだろうか
あと特筆すべきことはAstroの伸びかな
URLﾘﾝｸ(2024.stateofjs.com)
376:デフォルトの名無しさん
24/12/27 20:34:35.48 YxIFlKOGd.net
本当だVue抜いてるじゃん
Astroは絵に描いた餅感のイメージ強いんだけど、
この間bolt適当に弄ってたら何故かASTROでコード吐いてきたので
AIの力も借りて遊びでなんか作ってみようかなぁ
377:デフォルトの名無しさん
24/12/28 02:05:29.96 PwEyBlKD0.net
いやもうReactでいいよ…
378:デフォルトの名無しさん
24/12/28 06:54:44.06 e4Tyi2oC0.net
jsx使ったことある人ならAstroは簡単に習得できると思う
379:デフォルトの名無しさん
25/02/08 10:31:21.71 hJvS4i6R0.net
>>375
Angular17以降爆速になったからな、Vite＋esbuildというチートで19は起動が6秒ぐらい
それでいてフルスタックのまま。スタンドアロン標準実装、Signal、ビルトインコントロールフロー
ようやく他と戦える体勢整ってきた
>>372
SvelteはAppleが協賛に入って脱TS目指して、アプリ特化になりつつある
Runeもまだ、既存技術をわかりやすくマーキングしただけだし
380:デフォルトの名無しさん
25/02/08 11:14:27.65 hJvS4i6R0.net
>>375
Viteの伸びもえぐいな、とうとうWebpack超えてしまったか
Reactも19になってようやく不満要素だった、テンプレート周りの改善とフォームのリアクティブ制御を実現してきた
ただReact普及に貢献してきたNextだけが、案の定Viteから爪弾き状態になってるのが気がかり
Remix、Astroはしっかり公式連携になってるのに
381:デフォルトの名無しさん
25/02/09 16:00:36.64 G+MTHt9S0.net
あとAngularはCSR、SSG、SSRをミックスした使い方ができる。これはフルスタックならではの強みであり芸当でもある
382:デフォルトの名無しさん
25/02/09 18:38:29.52 wFwap3vs0.net
Angularってどう学べばいいの？
書籍は古いバージョンしか出てないし
公式サイト（日本）のはじめてのAngularだかも
今のバージョンでは動かなかったりして当てにならなかったわ
383:デフォルトの名無しさん
25/02/09 23:00:29.93 XCB8NOLW0.net
>>382
やっぱり本家のチュートリアルかねえ英語だけど
日本語の書籍は古すぎてオススメできない
384:デフォルトの名無しさん
25/02/11 10:22:24.86 jvkFh9pY0.net
>>382
ZennかQiitaあたりの使える記事を探すのが手っ取り早いかな
英語読めたらdev communityにも役立つ記事がいっぱいあるけど
Angularも14以降とそれ以前でReactの16.8以降と以前ぐらい別物の記述になってるから注意
あとAngular19からはstandalone標準だから、過去の動かしたい場合はstandalone: falseにしないと動かない
385:デフォルトの名無しさん
25/02/11 17:22:38.85 nxcjaTzm0.net
AngularはFCP遅いのがな
一度読み込んだら速いけど
386:デフォルトの名無しさん
25/02/15 10:10:33.69 HGo6DyGJ0.net
最近の業務待機時間多いから、その合間にここ数年の流行りに取り組んでいるんだけど
solidJSがかなり書きやすくていい。Vueのようなライフサイクルフックもあるし、JSXのループ周りに対しても面倒なmap地獄に遭わなくて済む。Reactかじってたら多分すぐ覚える
システム複雑じゃなくていいけど、JSXでさっと書きたいって人にはおすすめ
RemixとAstroもいい感じだ
RemixはNextほど複雑さがないし
AstroはJSX、Vue、Svelte、Solidどの書き方も通るのが便利そう
387:デフォルトの名無しさん
25/02/15 14:53:40.95 yHUAMZfW0.net
でも案件ないからね
388:デフォルトの名無しさん
25/02/16 01:34:44.13 T2962Blt0.net
ネットうろうろしてるとNextどころか
まだまだVue、Nuxt多いなぁ
Astroとか日本の商用サイトで採用してるとこあるの？
389:sage
25/02/16 08:57:51.89 l718zIOz0.net
どこで何が役立つかわからん業界だし（今年はまさかのPerl大活躍）
>>388
Astro採用企業の有名どころはAmazon、ネトフリ、クックパッド（ここはかなり日和るが）とか
Microsoftもスポンサーになってるのが大きいかな、あとVite公認
390:デフォルトの名無しさん (ﾜｯﾁｮｲ 4501-990B)
25/02/16 09:40:54.74 TK5HkbV90.net
GoogleとかトリバゴもAstro使ってるはず
国内企業は知らんけど
391:デフォルトの名無しさん
25/02/19 06:48:32.03 Z9GTaoqfa.net
Remix良いとは思うんだけど
こういうフレームワークを更にラップしたようなのって流行過ぎた頃に困る予感しかしないんだよな
バックエンド含んでるから古くてもまぁ動けばええじゃろでサボることもできんし
392:デフォルトの名無しさん
25/02/19 07:02:57.77 tFpAjYQB0.net
>>391
どのフレームワーク使ってもその問題は付きまとうから気にしても意味ないような
393:デフォルトの名無しさん
25/02/19 07:36:49.70 cyNyT1yf0.net
create-react-appが非推奨になったとかなんとか
394:デフォルトの名無しさん
25/02/19 13:07:51.68 3+8LLoUvd.net
フルスタックものはだいたいそのリスクあるでしょ
堅牢なシステムを長期的に運用したいとかなんとかなら
結局愚直にバックエンドapi実装
395:デフォルトの名無しさん
25/02/19 14:31:22.96 mGrw3aeq0.net
大規模ならCOBOLかJAVAだろうね
396:デフォルトの名無しさん
25/02/19 14:34:20.07 cyNyT1yf0.net
フルスタックのリスク回避でapiは別に設けるのもアリだよねって思ってもいる
Remixイジり始めたばかりだけど
397:デフォルトの名無しさん
25/02/20 20:55:31.83 NisJn+800.net
海外ではQwikも人気出てきてるみたいだし本当に群雄割拠だ
自分は今、Svelteのrune触りまくってるけど、一層proxy制御ガチガチになってて
堅牢性と拡張性は大幅に改善されてたけど、あれじゃもう、Vueと並び初級者向けとは言えんぞ
398:デフォルトの名無しさん
25/02/21 02:50:21.40 y9XPTlRE0.net
Reactみたいに汎用的なフレームワークは消えると思ってる
やっぱり個別にコンポーネントをコンパイルした方が効率いいのは間違いないのだし
サーバーサイドありきにするならこの考えが自然なのよね
399:デフォルトの名無しさん
25/02/21 05:02:26.87 9D9p9cHN0.net
>>398
litのこと言ってるのか？
400:デフォルトの名無しさん
25/02/21 18:42:50.18 y9XPTlRE0.net
>>399
いや基本的にはサーバー側でオンザフライにコンパイルされることが基本となると思う
svelteやqwik、solidを融合したような形になると思う
401:デフォルトの名無しさん
25/02/21 20:23:41.29 xhvBpgKe0.net
>>398
ReactとVueはあくまでライブラリだからな。だからガワ（フロントエンドツール）として売り出す手段にも出てるわけで。それだけにReactもそろそろ使いやすさ重視しないと離れていくだろうな
特に、今後のエコシステム次第ではSolidに乗り換えられる可能性は大いにある
VueはdefineModelがチート性能すぎてある意味今後が怖い
402:デフォルトの名無しさん
25/02/22 13:52:23.08 IP1R//230.net
spaとか糞なUIはそろそろ消えると予想。
画面リロードに対応できない仕組みでUI構築すべきではないと気付き始めるだろ。
403:デフォルトの名無しさん
25/02/23 10:18:53.60 EtTS1kqD0.net
SSGもCORS問題が鬱陶しすぎる（ローカルで環境開発しにくいから開発コスト大）
のと、あとデータ量に比例して重くなっていく問題をなんとかせんと
404:デフォルトの名無しさん
25/02/23 11:27:58.14 SIbO7j//0.net
>>402
むしろView Transitions APIとか出てきてSPAは手軽に作れるようになってきてるから消えないよ
>>403
ReactだともうSSGは縮小方向だな
今はReactでマトモにSSGやろうとしたらAstroが一番の選択肢になりそう
405:デフォルトの名無しさん (ﾜｯﾁｮｲ 31a5-c6km)
25/02/23 16:53:00.51 hoXt0H0e0.net
react難し過ぎるだろ。
フックの伝播複雑過ぎて、メンテナンスできない説。
406:デフォルトの名無しさん (ﾜｯﾁｮｲ 31f6-dlJU)
25/02/23 20:10:37.18 NHXxiQzh0.net
まったく問題ないが
407:デフォルトの名無しさん (ﾜｯﾁｮｲ b1ba-8jxH)
25/02/23 20:19:02.78 EtTS1kqD0.net
コールバック関数、分割代入、proxy この３つを把握すればJSフレームワークはどれも同じ
408:デフォルトの名無しさん
25/02/23 22:02:12.64 VD63caIp0.net
笑
409:デフォルトの名無しさん
25/02/23 23:52:42.55 SCNJLFbC0.net
reactでShift選択するui作ったけど
自分で作ってもう触りたくない。
クリックのフックは子がハンドリングして親に返して、選択範囲の再描画は親が制御するみたいな。
これに余計な子は再描画しないようメモ化するとか入れると、頭こんがらがってくる。
どのフックで何のパラメータが変わってどれが再描画されるか解らなくなる。
設計書書かずに作ってるせいなんだが。
410:デフォルトの名無しさん
25/02/24 01:31:40.21 BUsCxVnh0.net
逆に生で作ることを考えたらまだマシとなる
411:デフォルトの名無しさん (ﾜｯﾁｮｲ 3174-W5vA)
25/02/24 02:07:21.52 9ouheju+0.net
Shift選択のUIってこんな感じの挙動？
URLﾘﾝｸ(codepen.io)
412:デフォルトの名無しさん (ﾜｯﾁｮｲ 9501-phV/)
25/02/24 05:09:50.45 Mu/PIHkN0.net
ReactのMemoはマジでゴミだけどReact Compilerでやっと解決するらしいから
413:デフォルトの名無しさん (ﾜｯﾁｮｲ b1ba-8jxH)
25/02/24 08:41:21.17 ApFSqceQ0.net
Reactでゴミなのはコントロールフロー系
Solidはそこをしっかり解決してる
もう一つのゴミだったルーター系も
Solidインスパイアしてるならそっちも真似したらいいのに
Solidにストア系実装されたらまじでシェア流れかねんぞ
414:デフォルトの名無しさん (ﾜｯﾁｮｲ d505-FQm1)
25/02/24 09:31:11.82 ESLDFy060.net
>>412
どこ情報？
415:デフォルトの名無しさん
25/02/24 10:02:28.68 Mu/PIHkN0.net
>>413
何言ってるんだ？
Solid RouterはReact Routerにインスパイアされて作られたって公式のドキュメントに書いてあるのに
416:デフォルトの名無しさん
25/02/24 10:30:53.78 ApFSqceQ0.net
>>413
React Router Domが6からSolid Router（旧solid-app-router）の記法をまんま真似してるんだよ
パクったというより連携だけど
417:デフォルトの名無しさん
25/02/27 01:30:31.68 5g/Kzzkv0.net
>>409だけどreactで作ったchrome拡張の審査通った。
苦労して作ったから使ってみて欲しい。
適当なブログ開いて拡張のアイコンクリックすると画像一覧表示するから
欲しいの選択してダウンロードボタンでzipにできる。
スライダーで拡大縮小できるのがreactっぽい。
URLﾘﾝｸ(chromewebstore.google.com)
418:デフォルトの名無しさん (ｽｯﾌﾟﾌﾟ Sdfa-/AOM)
25/02/27 14:33:11.76 0d0Ldapzd.net
気が向いたらソースコード公開して
419:デフォルトの名無しさん
25/02/27 15:23:22.00 C53SLMw00.net
なんでこんなところで宣伝してるんだよ…
420:デフォルトの名無しさん
25/02/27 17:26:15.56 5g/Kzzkv0.net
reactらしいアプリ作ったから見て欲しかった。
421:デフォルトの名無しさん
25/02/27 17:40:04.07 5g/Kzzkv0.net
作ったのほとんどAIなんだけどね・・・
422:デフォルトの名無しさん (ﾜｯﾁｮｲ 8dbf-dlJU)
25/02/28 01:45:11.43 GlQ+7ZAn0.net
誰が作ったのかもわからん怪しいextensionなんかインストールしてはいかんよ
簡単に情報抜かれる
423:デフォルトの名無しさん
25/02/28 11:51:23.66 xWWtZGU60.net
公式でもザルだから入れない
424:デフォルトの名無しさん
25/03/02 15:42:07.55 AnJsL6nW0.net
みんなReactでフォーム作るときってinputタグ単位でコンポーネント作るの？
425:デフォルトの名無しさん
25/03/02 16:48:38.61 YYvymA+Y0.net
>>424
いや
426:デフォルトの名無しさん
25/03/02 17:33:25.66 Zv8rdJ2Y0.net
コンポーネントって再利用しやすいように作るのであって
無駄に細分化すると面倒なことになる
必要になったら後からでもコンポーネント分けられるし
427:デフォルトの名無しさん
25/03/03 02:31:46.94 VRiiOt5H0.net
>>424
reRenderの単位かな
428:デフォルトの名無しさん
25/03/03 18:58:09.18 Smhsplev0.net
描画のタイミング自由に制御できるようになると、react楽しいねぇ。
それまでは糞だけど。
429:デフォルトの名無しさん
25/03/03 19:53:09.42 s56BTABZ0.net
Reactのranderを封じて、
自前のタイミングで再描画する楽しさよ
430:デフォルトの名無しさん
25/03/03 23:50:14.94 uSk7XRpe0.net
Reactはmillion.js使えばsvelteやsolidよりレンダリングのパフォーマンスが良くなるよ
431:デフォルトの名無しさん
25/03/04 12:24:56.86 hfrti5Ii0.net
randerて
432:デフォルトの名無しさん
25/03/09 10:22:31.29 4G6sVQNz0.net
>>424
コンポーネントというより、質問のニュアンスだとフォーム部品ごとの出力オブジェクトか
制御フックのこと言ってるっぽいが
Reactはフォーム処理に関してSvelte、Vueにくらべたら糞性能というか、もともとが
深層ステート管理のためのライブラリだしな。複数のフォームを一発制御できる
useStateフックの書き方ググるかカスタムフックで作る
それかReact捨てて、簡単にリアルタイム制御できるVueかSvelteで作るかだな
どっちもストアライブラリ使わないとスパゲッティまっしぐらだがな
433:デフォルトの名無しさん
25/03/16 20:48:29.74 tTfhwjnK0.net
>>388
商用サイトじゃないけど、学研グループの勉強サイトはAstroで書かれてるね
URLﾘﾝｸ(manabitimes.jp)
434:デフォルトの名無しさん
25/03/17 14:00:57.63 jWjXnHtA0.net
芳根京子の公式サイトはNextだった
435:デフォルトの名無しさん
25/03/17 21:32:57.57 wrJsj8Yz0.net
SvelteKitとても好きです。
436:デフォルトの名無しさん
25/03/21 06:23:05.04 /97bZQtT0.net
Astro触ってみたけどすごいなこりゃ
こんなのできるならよほど大規模なサービスでも無ければNext.jsは要らないのでは
437:デフォルトの名無しさん
25/03/21 08:43:51.55 oycs/B450.net
Astroまだちゃんと触ったことないけど
Reactコンポーネントを将来、全く別のフレームワークのコンポーネント、例えば引数とレンダリング結果が同等の動きをする、コンパイルされたバイナリなんかに差し替えたりとか出来たら面白いな
438:デフォルトの名無しさん
25/03/22 21:59:34.30 amqAprOd0.net
どうせAI任せになるから関係ない
近いうちにAIが直接SSGしたりWeb Assemblyを直接生成するようになるからフレームワークなんか消滅する
439:デフォルトの名無しさん
25/03/22 22:19:49.62 1zuGIIBA0.net
>>438
おまえの方が早く消滅しそう...
440:デフォルトの名無しさん
25/06/10 00:46:00.18 YuUkDZe90.net
Remix v3が大改造するみたいだな
従来のRemixはReact Router v7になってRemix v3はpreactベースになるということか
441:デフォルトの名無しさん
25/06/30 02:27:29.14 34cw/UqT0.net
スレチだったらごめん
オンライン麻雀ゲームを作成しようと構想(妄想)してるんだけど、
いまから新規に作るならフロント側にはReactかVue.jsか、あるいは他のライブラリのどれを使えばいい?
先駆者 (書籍も出してる) は
> jQueryでないと美しく実装できない
URLﾘﾝｸ(blog.kobalab.net)
って言ってるけど、Webゲームのクライアントは特殊ってこと?
442:デフォルトの名無しさん
25/06/30 03:09:35.81 6K91Vfp30.net
その記事の人はReact使ったことがないから知識ゼロなんだろ
そもそも状態管理をして宣言的にUIを構築するんだからむしろReactのほうがスッキリ書ける
jQueryおじさんという化石思考に惑わされてはいけない
443:デフォルトの名無しさん
25/06/30 03:19:10.31 6K91Vfp30.net
> 宣言的アプローチでは「打牌中」の状態を描画できない
いや、Reactでは描画のための状態はUIコンポーネント内部に保持することでコアロジックを汚染することなく打牌中のような中間状態を美しく描画することができる
444:デフォルトの名無しさん
25/06/30 03:23:08.67 6K91Vfp30.net
Reactは宣言的UIは最終的な状態だけを表現するということではない
アニメーションやユーザー操作に伴う一時的な状態、ここでは打牌中もコンポーネントの内部状態やコンテキストAPIとかで管理できる
isPlayingAnimationのようなブーリアン型の状態を用意し、アニメーション中はtrueに設定し、アニメーションが終了したらfalseに戻す
打牌中の牌の位置や動きに関する情報を状態として持ち、その状態に基づいてCSSアニメーションを適用する
445:デフォルトの名無しさん
25/06/30 03:27:13.20 6K91Vfp30.net
> Majiang.ShoupaiはAIの思考ルーチンでも使用します。ここに描画の都合の「打牌中」などという状態を持ち込むとしたら、それは設計として誤っています
Reactでも描画に関わる状態とアプリケーションのコアロジックに関わる状態は分離して管理するのが一般的
コアロジックの麻雀の牌姿やルール進行を司る部分は、Reactコンポーネントからは独立した純粋なJavaScriptクラスや関数として実装するのが普通
446:デフォルトの名無しさん
25/06/30 03:33:46.29 6K91Vfp30.net
> イベントハンドラ設定は描画処理と分離すべきである
Reactの設計思想はコンポーネントが自身の描画とそれに関連するイベントハンドリングをカプセル化すること
「対戦相手の手牌にイベントハンドラは不要だし、牌譜再生にも打牌のためのイベントハンドラは不要」という点についてはReactのコンポーネント設計で柔軟に対応できるからまったく問題なし
isInteractive: booleanなどを渡すことでイベントハンドラの有無を制御できる
牌譜再生時にはイベントハンドラが不要なモードでコンポーネントを描画すればいいだけだし
447:デフォルトの名無しさん
25/06/30 03:43:00.60 6K91Vfp30.net
> JSXを使う局面がない
> HTML に雛形として埋め込まれた「牌を表現するDOMノード」をコピーし差し込むことで実現しています。
Reactをまったく知らないからこんな恥ずかしことを堂々と言えるんだろう
こいつのもっとも無知なところだな
Reactは宣言型だからコピーするというコードを書くことすら不要なわけ
448:デフォルトの名無しさん
25/07/01 16:48:29.62 SIBQ1DK00.net
牌なんてCanvasに直接描画すりゃエフェクトも自在だし変にエレメントにデータ持って
重くなることもなくていいんじゃね？って思うのは俺だけなのか
449:デフォルトの名無しさん
25/07/03 12:01:40.42 +b4ZnWKa0.net
>>448
俺もこう思う
そもそも牌をhtml要素とCSSで描画すること自体が微妙だよね
そういう意味だとjQueryでもReactでもなくてCanvas系のフレームワーク使ったほうが良いんじゃないかな
450:デフォルトの名無しさん
25/07/06 06:18:05.39 GxvgQzqn0.net
宣言的UIに慣れるとCanvas全体を命令的に描画するのがあまりにもダル過ぎる
451:デフォルトの名無しさん
25/07/06 11:52:25.82 77BphujQ0.net
Canvas上の各表示オブジェクトを
Reactやビューで
あたかもHTMLの要素の様に操作できる（CSSプロパティ設定できる）
ライブラリってあるのかな。
452:デフォルトの名無しさん
25/07/06 12:44:53.42 8Iwql4w40.net
flutterでよくね
453:デフォルトの名無しさん
25/07/09 16:01:11.75 2rb1ksuv0.net
実際のゲーム開発で宣言的UIが採用されることってあるの？
454:デフォルトの名無しさん
25/07/20 07:51:42.37 SQq4ZXml0.net
設定画面とかチュートリアルなら、まあ宣言的UIを使うもアリ。
455:デフォルトの名無しさん
25/10/14 01:38:41.26 gsFi4uI80.net
Remixが謎方向に進んでいる
Reactを捨てるのか
456:デフォルトの名無しさん
25/10/14 08:36:28.99 ADcABZ0f0.net
React捨ててReactもどきを新しく作ったのか
流石にもういらんだろ
457:デフォルトの名無しさん
25/10/14 12:34:52.90 oZQKX5Mj0.net
Reactは迷走してるって言ってるけど『お前もじゃい！』って感じだな
しかしReact前提のフルスタック全滅したらバックエンドはどうしてくのが良くなるのかねぇ
458:デフォルトの名無しさん
25/10/14 18:50:59.98 gsFi4uI80.net
バックエンドは今でもRailsが大人気だぞ
459:デフォルトの名無しさん
25/11/16 09:40:05.17 FZVYRGsX0.net
今さらPugやEJSやThymeleafJSが再流行するとも思えんよなあ