Vue vs React vs Angular vs Svelte Part.11

2024/09/14(土) 20:18:06.43

Webフレームワーク未経験でVueが学習コスト低いと聞いたので本買ってきたけどさっぱりわからん
PHPでちょっとしたバックエンドは書いたことあるけれど
フレームワークってトレンドで次から次に変わっていくわけでしょ？
もうフロントエンドもバックエンドも一本のフレームワーク（言語）でできるやつを出してくれよ

2024/09/14(土) 20:18:19.74

Webフレームワーク未経験でVueが学習コスト低いと聞いたので本買ってきたけどさっぱりわからん
PHPでちょっとしたバックエンドは書いたことあるけれど
フレームワークってトレンドで次から次に変わっていくわけでしょ？
もうフロントエンドもバックエンドも一本のフレームワーク（言語）でできるやつを出してくれよ

2024/09/14(土) 20:31:55.73

>>204
Blazorやれば。

2024/09/14(土) 22:56:46.41

未経験だとvueが学習コスト低いってことはない
vueは従来の開発と似ていたから学習コストが低いと言われていただけ
従来のを知らないならべつに

2024/09/15(日) 00:20:21.09

js 一本でやればいいだけ

2024/09/15(日) 14:58:39.57

frontにjsは外せ無いから
backもjsでやるだけだろ

2024/09/17(火) 08:51:08.78

backはgolangでやりたい侍
前回のプロジェクトで採用したけど、あの言語の設計思想は大人数で開発するのにすごく向いてるわ
googleが作っただけはある
アサイン人数が数十人規模になって自己主張強めの問題児が入ってきてもコードが破綻しない

2024/09/17(火) 11:02:44.94

あとはバックエンドの処理時間の問題だけどDBの最適化がちゃんと出来てればPHP8みたいな速いとされる言語でもJS系のバックエンドでも変わんないのかなと思うようになってきた

2024/09/17(火) 12:44:47.46

元からかわんねーーだろ
大半の処理をDBでやってれば

2024/09/17(火) 12:51:30.76

DBのノードは単価が高いんで、処理内容によっては安いバックエンドのノードに寄せたほうが時間が延びても安く上がったりするよ
俺も新人の頃は速さのことしか考えてなかったけども

2024/09/17(火) 14:56:40.30

>>210
PHP8は従来のPHPと比べたら速いってだけでNodeと比べたら遅いぞ

2024/09/17(火) 15:12:06.30

pythonはc並に速くなるように改良中

2024/09/17(火) 16:15:34.56

最初からC並に速い言語使えばいいのでは？🤔

2024/09/17(火) 17:16:40.26

>>214
で、それが実現すんのはいつよ？

2024/09/17(火) 17:59:56.74

https://tadaup.jp/3ffc06661.png
pythonは元が遅すぎるからなあ
10倍高速化してもまだ遅い
素直に他の言語使ったほうがいい

2024/09/17(火) 19:17:35.92

>>217
Nodejs優秀すぎない？見くびってた

2024/09/17(火) 19:23:44.37

同じスクリプト言語でなんでここまで差が出るんだ？単に関わってる人材の差？

2024/09/17(火) 19:36:14.15

219がアホだからそう観える

2024/09/17(火) 19:46:27.46

>>217
javaやkotlinってもっと遅いのかと思っていた

2024/09/17(火) 20:07:13.25

PythonやRubyが足引っ張りすぎててこういうグラフになってるんであって、CとJavaだけで比較したら1割ほど遅いからまあ差はある

とは言え、大した差ではないから上位陣は言語の使いやすさで選定したほうがいい

2024/09/17(火) 22:46:45.77

>>219
JavaScriptは実装が複数あるからな
GoogleとAppleとMozillaが競争した結果最速のインタープリタ言語になってる

2024/09/18(水) 02:02:18.43

Elixir は、10万もの小プロセスを起動できる

Go の並行処理も、mattn の本に書いてあるけど、
C で、100スレッドを起動したら、
CPU 使用率が高く、12秒も掛かったが、

Goで100 goroutine を起動したら、
6スレッドしか起動せず、9秒で済んだ

Goの方が、CPUコアを効率的に使える

とにかく、スレッドを起動したらダメ！
CPU コアや時間の大半が、起動処理に使われるから

2024/09/18(水) 02:25:23.85

>>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 をコンパイルせず、
動的にスタイルを当てているだけとか

2024/09/18(水) 14:09:35.94

今日のNGword KENTA
明日のNGword KENTA
明後日のNGword KENTA

2024/09/18(水) 21:06:37.69

🤦‍♂

2024/09/18(水) 23:45:43.00

何このRuby on Railsって、布団押し売りか詐欺宗教団体みたい・・・
Ruby覚えるぐらいならRust覚えるわ

2024/09/19(木) 00:14:43.71

今更Rubyやるやつおらんやろ

2024/09/19(木) 02:10:42.24

RubyとRustを同一に語るおじさん草

2024/09/19(木) 09:28:29.71

Rubyなんて組み込みとバッチ系で息してるだけじゃん
Rustだと次期Linuxカーネル候補になったり、高速バックエンドとか色々ね
得手不得手があるのは判るがRuby使いたいか？

2024/09/19(木) 11:10:37.49

githubがRails使ってる限りRubyは無くならん

2024/09/19(木) 15:02:00.98

なぜRubyを嫌うのかわからん
日本人が作った言語だろ
喜ぶべきじゃないか

2024/09/19(木) 15:14:40.50

品質の善し悪しじゃなくて馴れ合いで製品選ぶようなことをしてるから日本にはGAFAが生まれなかったんだろ
nodejsはGoogleとAppleは互いに競争し続けた結果>>217のような爆速へと進化した
rubyは進歩しない日本の象徴だわ

2024/09/19(木) 16:28:25.79

日本のITが遅れてるのは品質を名目にリソースも与えずにバグゼロを現場に押し付けてせいだよ。

2024/09/19(木) 20:22:09.61

>>234
そのグラフってだいぶ古いと思うぞ
今のRubyはJIT搭載されてかなり速い
進歩しちゃったね

2024/09/19(木) 20:39:21.20

>>236
2024年の記事でもrubyは18倍遅いな
https://pcmatsumoto.com/2024/01/27/post-1328/?amp=1
このザマで本人だけは「早くなった」などと自画自賛するマヌケっぷりがまさに日本って感じだな

2024/09/19(木) 21:05:14.98

>>237
jit有効化してないだけやん

2024/09/19(木) 21:19:19.21

>>238
ほんっと何も知らない井の中の蛙だな

上位陣が一桁secsで鎬を削り合ってる中Ruby yjitはどこにいるかわかるか？
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html
Ruby yjit #2 139.05
まさかの3桁だぞ

2024/09/19(木) 21:30:27.66

>>239
でも数字は伸びてるやん
グラフより圧倒的に高速化されてるよね

2024/09/19(木) 21:38:53.78

>>240
最下位から何番目かって立ち位置でどこが圧倒的なんだよｗｗｗｗ
そもそも最初からJITアリでの比較だろこれｗｗｗJITの有無の比較にしては差が少なすぎるわ

どっかでこの流れ見たと思ったら、停滞し続けて世界各国に次々と年収を置き去りにされてる中、言い訳にもならない言い訳並べて現実逃避し続けてる日本の恥部そのものだな

2024/09/19(木) 21:48:32.54

Rustなんでこんなに早いねん
しっかし過去の日本人が自慢げに「COBOLは計算だったら負けんぞ」って言ってたがリストにすらないな

2024/09/19(木) 21:53:27.66

コンパイル型言語は今や「コード全体の意図を読み取ってどれだけ効率的な機械語を自動生成できるか」の世界だからな
コードの1行1行とコンパイル後の機械語が対応してた時代とは全然違う
コンパイラが賢くなればなるほど速い

2024/09/20(金) 00:47:51.66

あくまで論理的に等価な変換をやってるだけで、意図を汲み取ってるわけじゃないよ
まあそろそろAIを使って意図に基づいた最適化をやる言語や処理系は出てくるだろうな

2024/09/20(金) 01:06:06.52

日本人なら速度で戦うな
日本人ならRuby一択だろ

2024/09/20(金) 01:30:15.81

あんな不出来な言語を日本代表みたいに扱うのはやめてくれ
日本人として恥ずかしいわ

2024/09/20(金) 09:43:55.00

>>244
まあ、書かれてる事しか関知しないからな
そのコードが仕様をみたしているかなんて知らんがなだろうな

2024/09/20(金) 11:10:40.93

CやJavaエンジニアからみたらRubyはすんなり入れるけどjavascriptはゴミ言語って言われるよな
ブラウザごとに仕様が違うしこれほど酷い言語はないと言われ続けてきたもっとも使いにくいのがjavascript

2024/09/20(金) 11:15:56.65

すげえな、こんな人現存するんだ、という気持ち

2024/09/20(金) 11:47:13.71

地縛霊みたいなもんだよ

2024/09/20(金) 12:28:30.66

>>248
20年ぐらい時間止まってる？
javascriptはとっくの昔にECMAで標準化されて国際規格が定まっただろ

2024/09/20(金) 12:44:35.83

>>248
常に勉強し続けなければ生き残れないIT技術者の世界でその認識はヤベェな
あんたの技術者としての価値はもはや化石通り越して素人学生以下だろ
スレタイのVue vs React vs Angular vs Svelteだって一個も意味知らないんじゃないか？

2024/09/20(金) 14:18:57.18

どんだけ取り繕ってもjavascriptが糞だという事実に変わりは無い
rubyもperlも糞

2024/09/20(金) 15:32:49.35

スクリプト自体が糞だから仕方ない

2024/09/22(日) 09:48:00.74

どこにでもいる、サッカー代表どこが最強とか論議してる中、野球の方が面白いとか言い出す、社会の不適合者。人間フォーマットか脳みそデバッグ必要なアタオカは相手にするだけ無意味。さあ、俺もそろそろRemix勉強しようか

2024/09/22(日) 10:26:35.95

>>204
Vueはもともとフォーム周りを簡潔にするために生み出された技術であって、決して初心者向けとは言い切れない。様々なステート管理にメソッドやら算出プロパティやら独自のライブラリを駆使するのと、それを駆使するにはある程度経験とコツがいる。なんだかんだで、複雑なフックの仕組みさえ極めればJavaScriptの延長線で書けてステート管理が一本線のReactの方が簡単という人もいる

スパゲッティ確実でパフォーマンス無視だが、Vueは実はメソッドだけで書けたりする

2024/09/22(日) 10:55:33.23

>>204
javascriptが特殊な言語で使いにくいからどうしてもVueみたいになってしまうんだよ
他の言語ならもっと簡素で簡潔に書けるんだけど

2024/09/23(月) 12:45:02.08

vueは2～3周りの変革がググらビリティ下げてて初心者に逆にキツくなってるのが良くない
時間が解決するとは思うけど、ねえ
optionsAPIで突き進むのも差別化的にはよかったろうに、けど時流に沿うのもわからなくもないからなあ

2024/09/23(月) 13:39:10.98

Vueのググラビリティが低いのは中国が主戦場なせいだろう
我々日本人からするとコミュニティを置き去りにして大改造を続けてるように見えるけど、中華圏の中から見ればそうでもないのかもね

**デフォルトの名無しさん** (JP 0Hdf-cIDa) · 2024/09/23(月) 13:53:57.31

vueは好きじゃないけどパフォーマンスの改革がすごい
今ではsvelteと変わらんくらいのパフォーマンスになってる
あとnuxtの話になるけどunjsが良い

2024/09/23(月) 18:01:38.02

Next.jsよりHonoがすげえ伸びてるよな
開発者一人だけっぽいけど大丈夫なのか？

2024/09/24(火) 12:53:38.69

>>233
pythonでいいし

2024/09/24(火) 12:53:56.13

>>261
趣味ならいいんじゃね？

2024/09/24(火) 12:54:47.28

>>260
好きじゃないけど慣れちゃうとこれでいいかとなってしまう
フロントエンドなんてどうせ作り直す想定なんだし

2024/09/24(火) 12:55:15.04

>>259
ググることなんてあるか？
ChatGPTで十分だろ

2024/09/24(火) 12:55:32.57

>>258
ChatGPTで困らない

2024/09/24(火) 12:57:04.04

>>257
多少面倒でもReactみたいに統一的な書き方ができる方が良いことに気がついた時には手遅れだった

2024/09/24(火) 12:57:43.99

>>256
マジで超単純なフォーム系のWebをサクッと作る用途に向いてるよね
ちょっとややこしいことすると破綻する

2024/09/24(火) 12:58:18.09

>>255
Remixもビミョー

2024/09/24(火) 12:58:46.23

>>253
クソだけどあるものからしか選べないのよね

2024/09/24(火) 12:59:11.60

>>248
ゴミでもやるしかないんだよ

2024/09/24(火) 14:46:15.54

そもそもAIの時代になってもはやUIというものが無くなるからjavascriptもだんだん使われなくなっていくだろうな

2024/09/24(火) 15:46:19.24

5年以内には画像から完全なフロントエンド実装を作るツールが生まれるのは間違いないだろうけど
フロントエンドもサーバーサイドに回帰してるから結局コード書けないとダメ

2024/09/24(火) 15:47:43.57

wasm gcが入るとほとんどの言語がwasmコンパイル可能になるから
新たなエデンが生まれると思う

2024/09/24(火) 17:31:42.29

>>274
そうか？
デスクトップソフトですらweb技術で作られることが多くなった時代なのに

2024/09/24(火) 18:07:06.89

ガワはだいたいReactだね

2024/09/24(火) 18:49:58.49

>>275
言語に縛られないからその点は良いよ
wasm対応の好きな言語を選べるようになると素晴らしい
まあ流行らなかったらキツいけど

2024/09/24(火) 23:11:17.46

>>273
> フロントエンドもサーバーサイドに回帰してるから結局コード書けないとダメ

回帰ってのはどういう意味？

2024/09/25(水) 00:05:02.99

サーバーサイドレンダリングのことじゃねえの？
古のMVCから変わってクライアントサイドでレンダリングするようになっていったかと思えば今度はまたNextのAppRouterよろしくSSR(orSSG)になったりと忙しない業界よな

2024/09/25(水) 00:09:03.70

>>279
単にWebベースのクライアントアプリの事を言ってると思う

2024/09/25(水) 15:20:38.11

まさにサーバーサイドレンダリングのことだ
結局コンポーネントに必要なデータはサーバーで取得した方が早いよねということにフロントエンドの人が気がついて
サーバーサイドの人は今更何言ってるの？みたいなる空気感
コードの共有がそれほど意味があるとは思えないし
サーバーサイドは別の速い言語で作れば良くね？って思うけどね

2024/09/25(水) 15:22:37.11

最近はフロントエンドの人がサーバー側に口出ししてきて
今更ORMガーとか言ってて昭和かと
こっちはORM地獄を10年以上前に経験してウンザリしてるんだよ

2024/09/25(水) 15:45:33.76

とサーバーしかしらん無知君が吠えてます
こいつ勘違いしてるというより無知だから今までのサーバーサイドレンダリングと同じだと思ってるらしい

2024/09/25(水) 16:31:31.44

Twitterで騒いでるフロントエンドインフルエンサー()の方々はCSの知識がないのに調子乗ってるから本質が掴めてないんだよな
SSRなんて変な名前つけちゃってからに

2024/09/25(水) 16:35:31.76

>>283
その発言はサーバーサイド何もわかってませんと言ってるようなもの

2024/09/25(水) 16:39:07.42

>>285
何もわかってませんってなんだ？
ずっとサーバーサイドの開発も散々してきてるが
お前はフロントエンドを何も理解してねえから無知晒してんだろw
マジで恥ずかしいレスだったわww

2024/09/25(水) 16:41:31.67

>>286
匿名掲示板でそんなイキリをして恥ずかしくないのか？
それをどうやって確認するんだよ
確認できないようなことでイキるな
発言内容だけしか見ないんだよ

2024/09/25(水) 16:42:50.66

あ、名前と所属晒すなら信じてやるけど？

2024/09/25(水) 16:46:02.20

>>287
何度読み返してもこれほどの無知はこのスレにはいねえわw
久しぶりにサーバーサイドおじさんが勝ち誇ったと思ったら実際はただの無知でしたってオチだったww

少しは勉強してから来てくれるか

2024/09/25(水) 16:47:50.81

>>279
フロントエンドが「これからはレンダリングはこっちでやりまっせ」みたいなノリでこっちはもうAPIだけ作ればいいのかラクチンだーと思ってたら
いきなりサーバーサイドに土足で踏み込んできて
NextダーRemixダー言い出してもうめちゃくちゃだよ

2024/09/25(水) 16:48:40.15

>>289
何も言ってないのと同じ
やりなおし

2024/09/25(水) 16:50:33.98

ワイらがNext.jsの運用もやりまっせ！からの面倒だからVercel使いますと言われた日には我々の怒りもピークだよ

2024/09/25(水) 16:53:47.88

中身のないイキリレスだけしたいなら消えてくれないか？
不愉快だし境界知能のADHDに構ってるほど暇じゃないんだ
そもそもがレスバでも俺には勝てない
感情のコントロールもできないやつの発言なんて聞くわけがないだろう
何度もいうが発言の中身だけしかみない
匿名掲示板はそういうところだ

2024/09/25(水) 16:57:48.51

なんだこいつ
レス連投のキチガイか
理解できないなら使わなきゃいいだろ

2024/09/25(水) 19:02:29.97

連投ちゃん増えたな

2024/09/25(水) 19:06:11.81

>>281
それはないね

2024/09/25(水) 20:19:06.11

>>294
ケンカを売ってきたのはお前だろ

2024/09/25(水) 20:19:58.50

技術者なら中身のある批判をかけ
書けないなら黙ってろ

2024/09/25(水) 20:28:21.84

あー、、
そもそも最近のSSRやらSSGは普通DB操作まではやらんでしょ？

最近の豪華絢爛なUIを何でもかんでもクライアント側でレンダリングできるようにすると、そのレンダリングのためのコードで転送量が爆裂する上、
クライアント側の処理能力も問題になってくるからサーバーでレンダリングした結果を渡した安定するよねって流れだと思うよ
だから相変わらずAPIは提供してやる必要がある

ぶっちゃけ、処理効率を突き詰めていくとjsonやらxml吐き出すAPI叩いて結果からレンダリングしてみたいなバケツリレーのようなマネするよか、そのままAPIから直接html吐き出した方が処理効率はいいけどね
職務分掌の意味合いが強いと思う

2024/09/25(水) 21:10:16.58

>>298
>>299
こいつらも何もわかってなくてワロタw

そもそもコイツ↓のこのレスみて無知無能さがマジでわかるだろw
>>281
> コードの共有がそれほど意味があるとは思えないし
> サーバーサイドは別の速い言語で作れば良くね？って思うけどね

まさかのコードを共有してるだけだと思ってるらしいw
まっっったく理解してないどころかド素人通り越して知識ゼロで話にならんw

サーバーサイドは別言語で良くねって完全に自分は無知ですって言ってるようなもんだろwww
Next.jsとかのSSRとサーバーサイド言語のSSRが同じだと思ってんなら邪魔だからここから出ていけよwww

2024/09/25(水) 21:54:30.34

>>300
もうお前は黙ってろ

2024/09/25(水) 21:57:22.46

>>300
何も言ってなくて草

2024/09/25(水) 22:11:30.78

>>299
コードはページ開いた初回だけだぞ
（かつコードもローカルにキャッシュする事も可能）
それ以降はREST API叩くだけだから
ネイティブアプリと遜色ないレベルで動く

2024/09/25(水) 22:26:15.23

>>303
それがつまりはクライアントサイドレンダリングが持て囃されてた10年ぐらい前の思想でしょ
豪華になっていくにつれてそれじゃ問題が出てきたからAppRouterのSSR&SSGと言ったもんが出てきたわけよ

2024/09/26(木) 02:02:17.79

>>304
ばか

2024/09/26(木) 12:39:43.01

>>299
cloudflare D1とか普通にやれるしむしろ積極的に使う方向性
サーバーレスDBだ
あと普通にpostgresqlサーバーへ接続できる(!)
もう何でもあり

2024/09/28(土) 21:18:59.88

フロントエンドのPrismaに対する過剰な評価はなんなんだろう
そもそもORMなんて20年前にサーバーサイドで死ぬほど開発され全てクソという結論に至った技術なのに

2024/09/28(土) 22:18:23.73

>>307
べつにPrisma以外のORMでもいいけど
TypeScriptから型安全に使えるのがいいんだよ

2024/09/28(土) 23:08:59.38

>>308
RDBのインターフェースにおいて型安全という思想自体が間違ってる派だがそれは置いておいて
定義したスキーマに対して型安全に使いたいならそれこそJavaやC#でそれこそ海千山千レベルで作られた
しかしどれも使いやすくはなく最終的にはシンプルなクエリービルダー型のものだけが残った
必要なのはORMではなく単なるSQLクエリービルダーだったというのが結論
まあ歴史を繰り返すことが悪いとは言わないが
自分で実装したものもないのになんかレベル低いことやってるなあと
「wasmコンパイルした時のサイズが最小のクエリビルダーを作る」というのは技術的にかなり面白いと思うけどね

2024/09/29(日) 01:13:04.48

フロントやってる人って強い言葉で極論語りたがるってことが、
顕著に表れてる数レスだなあって思った

2024/09/29(日) 01:47:21.26

極論ではなく以下の構成が最適なのはいうまでもない

DBマイグレーションツール
+
データベース接続を抽象化するアダプターモジュール
+
SQLクエリービルダー

これこそがモダンなインターフェースなのである

2024/09/29(日) 02:23:06.66

昔は、ローカルの開発環境ではsqlite、実環境ではDBMSとかあったからORMにもメリットがあった。
でも今ではローカルでも実環境と同じDBシステムを使えるようになってるし、調査では結局素のSQL見る必要もあるし、リプレースする際でもフロント、バックエンド、DBシステムのなかではDBシステムの変更が一番可能性は低い。
それならORM毎の違い覚えるより素のSQLを使いこなせるようになったほうが長く使えるスキルになる。
結局ほしいのは >>311 で言ってるものだな。

2024/09/29(日) 06:12:44.91

昔、SQL使えないアホの選択肢がORMだったのよ

2024/09/29(日) 08:21:21.24

PrimaはTypedSQLみたいなものも出してきてるし
結構面白いよ

2024/09/29(日) 08:29:21.92

20年ぐらいこの業界やってるけど最適化を進めて複雑なサブクエリやらWITHやらを使い始めると、
大抵ORMじゃ対応しきれなくなって結局生のクエリを実行させるようになるケースが多すぎたな

2024/09/29(日) 08:41:41.79

ぶっちゃけJSONにaxiosあたり出てきてLaravelがガワ連携実装してから、他言語フレームワークもガワ連携前提がデフォ化して自己完結主義のAngular以外ガワツールと化してる感あるな。あとは複雑だが階層は浅いフォーム制御が得意（Vue）か、単純だが階層が深いステート管理が得意（React）かで選択肢が変わる

ヨーロッパだとSvelte（イギリス生）が人気になってきてるみたいだけど、日本というかアジアはVue強いし、まだまだ普及に時間かかりそう

2024/09/29(日) 09:28:52.49

svelteを採用してる企業を見たことがない

2024/09/29(日) 13:04:00.66

>>313
SQL理解できないのにORM使おうというのがそもそも間違いだからな
チューニングとか別の人がやるのか？って話
ふざけんなと
あと生成したSQLが本当に求めているものなのかのチェックも必要
SQL生成ごっこがしたいなら好きにしたらいいが

>>315
それと最近はデータ分析用にかなり複雑なSQLを投げることが増えた
別途バッチにすることも多いがどうしてもリアルタイムで実行しなきゃならんこともあったりして
これが厄介なんよね
彼らの実行するクエリはもう型とかぐちゃぐちゃ

2024/09/29(日) 13:08:53.67

ORMしか使えない奴ら多いよな
バックエンドエンジニアでSQL書けず最適化もできない連中ばっか

2024/09/29(日) 13:16:26.30

>>314
サーバーサイドが型合わせ不毛だよねと実質捨てた部分を今どのように再開発するのか楽しみではある
「先」に進めてくれるのだろうか
ちなみに改めてORMを調べてみたがやはり状況は大して変わっていない模様
SQLクエリービルダーは大抵の言語でかなり進化しているが型のマッピングは程々にするという妥協案
Haskellが1番面白かった
以下のようにモナディックで型安全なSQLが書ける
ここまでやれるやらありか？とは思ったが

select $ from $ \person -> do
where_ (person ^. PersonAge >. val 30)
return person

2024/09/29(日) 16:05:49.23

SQL書けないからORMのtable単位で更新するレベルの機能で良しとするんですよ

2024/09/29(日) 16:25:50.06

ちなみにJavaやC#のORMで出た型付けの結論は
「オブジェクトのプロパティと実行するSQLの型を手動でマッピングする」です
マッピングは動的に変えられるので汎用性がある
テーブルの型とプログラミング言語の型を直接マッピングしないというのがミソ

2024/09/29(日) 16:38:12.07

簡単に言うと実行するSQLごとに型付けをする感じ
これだと同じテーブルで型が変わる場合などでも対応できる
PrismaのTypedSQLもこれに近いものなのではないの？
Java界の奴らが10年以上かけてたどり着いた結論だから多分こうなると思うよ

2024/09/29(日) 17:18:57.60

>>311
>>SQLクエリービルダー

ってGUIでクエリーを書く機能のこと？

2024/09/29(日) 17:35:45.85

SQL書けなくてどうやってデータ保存してるだ？
本当にSQL書けないならSQLite辺りで覚えていったほうが良いかもね

2024/09/29(日) 17:47:58.09

>>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が生成されるか？は見なくてはならない

2024/09/29(日) 17:54:18.58

>>317
いちばん有名な企業が楽天グループ、そこは公認パートナー企業にもなってる
>>325
ORMは便利だけどそっちしか知らない人が多いというか、各種フレームワークからデバッグ用にSQL吐き出せること知らない人も多い。だから結合とか副問い合わせで躓いてるのをよく質問サイトで見かけたな

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が一番の選択肢になりそう