Vue vs React vs Angular vs Svelte Part.10

■ このスレッドは過去ログ倉庫に格納されています
2022/03/08(火) 22:57:16.85ID:D77bZcWT0
!extend:on:vvvvv:1000:512

Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
Svelte
https://svelte.dev/

※前スレ
Vue vs React vs Svelte Part.7
https://mevius.5ch.net/test/read.cgi/tech/1610901677/
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/

★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured
2022/07/02(土) 15:36:48.98ID:P5MS37aDM
アロー関数とかasyncとかモダンなJavaScriptの構文ってだいたいMS主導の提案だろ？
そもそもTypeScriptはJavaScriptを改善していくためのPoCの役割を担っている言語で、TypeScriptが必要なくなるのはMSにとっても望ましいことなんだよ
2022/07/02(土) 15:46:38.12ID:vAnwNkKL0
>>741
それ分からないって頭弱くね？ｗ
そもそもjsのライブラリなのにjsで書けないってｗ
あ、書けないじゃなくて書かないって言いたいんだろうけど
お前みたいなのは書けないと同義なんだよなｗ
2022/07/02(土) 15:50:51.08ID:MgQFVCuv0
>>744
なんかぼんやりした話だな。tsserver事態のメンテはvscodeチームとは関係ないだろうし何の話だろう。
仮にそれが事実だとしても嫌になったのはvscodeチームがであってMS自身がってことじゃじゃないよな。

「別の提案」ってのがまた話の脈絡がわからないが、こっちはTypes as Commentsの話？
2022/07/02(土) 16:12:03.29ID:2I3j8zDtM
支離滅裂な文章でも文末にｗ付けりゃ人を煽れると思ってるんだろうか…
2022/07/02(土) 16:49:58.49ID:eKS9e1d80
Types as Comments なんてまさにTSの発展形なわけで、TS学んで有利になりこそすれ、損は無いよなぁ。

TSは言語仕様を見れば必要以上に便利な演算やマクロ化は避けてあるから、ある程度で解析打ち切りってのは異常でもなんでも無いように感じる。
2022/07/02(土) 17:01:32.19ID:2BlFAt+M0
>>745
モダンにアロー関数使って変数の値が極力変わらないスクリプト書いてもIEさんが挙動おかしくなってましたね…
2022/07/02(土) 17:28:41.92ID:3dhQ5vPf0
自分もフロントで型を使って何をするか分かってない
ビジネスロジックは書いたらだめだよね
2022/07/02(土) 17:32:40.41ID:XBJNDAlwa
NaNしたことない者だけが型を捨てなさい
2022/07/02(土) 17:43:54.69ID:MgQFVCuv0
>>751
べつにプレゼンテーションロジックでも役に立つんじゃね？
フロントにビジネスロジック置いたらダメなんて法もないし。
2022/07/02(土) 18:21:20.76ID:eKS9e1d80
プレゼンテーション層で型エラー出して遷移が発生しなかったり変なデータ表示したらユーザが誤解して結果的に間違った操作するから、どっちも大事だよね。
つかビジネスロジック一切触れなかったら何も操作できないじょん
2022/07/02(土) 19:34:36.69ID:3dhQ5vPf0
>>753
ビジネスロジックがフロント側やいろんなところにあるのは悪手だと思うけどな…
でもたしかに日本国憲法には書いてないから言い返せないわ
2022/07/02(土) 19:47:59.60ID:npQqWWfDM
どこまでがビジネスロジックにあたるか分からんのでなんとも
ソシャゲガチャの確率をフロントで捌くことは無いってのは分かるが
2022/07/02(土) 21:03:21.42ID:MgQFVCuv0
悪手ってのは管理的な意味でかねぇ？
同じロジックのコードが分散したりしなければべつに困らんと思うが。
2022/07/02(土) 21:17:45.97ID:3dhQ5vPf0
>>757
レイヤードアーキテクチャの考えだと、
ビジネスロジックはドメイン層に書きましょうでしょ
でも、この話ってそもそも何のシステム作るかで左右されるよな
2022/07/02(土) 21:41:40.49ID:BrGj2XHMM
いつの間にかフロントにビジネスロジックを書くかどうかの議論になってるけど
ビジネスロジックを書くなら型必要、そうでないなら不要って合意がされたんだろうか
そうでないならそこを議論しても意味ない気がするけど
2022/07/02(土) 21:46:38.78ID:MgQFVCuv0
>>758
その境界をクライアント-サーバー間に引かなきゃならん理由はないだろ。SPAとかなら特に。
2022/07/02(土) 22:33:24.13ID:QFi+cmDT0
フロントだけでアプリ作れるよ系のサービスは存在そのものが悪になるの？
2022/07/03(日) 00:14:35.00ID:eO2MvCIb0
フロントだけでアプリが作れるように見えるFirebase/Firestoreも実はセキュリティルールとかあるし、本気で活用するならFunctionsとの連携が必要とかもあって、フロントだけでもない
2022/07/03(日) 00:39:44.39ID:95K4DRnu0
フロントだけってなんやねん、気もするけどな
2022/07/03(日) 02:57:16.56ID:anFeH3zOr
そんなこといったらデスクトップアプリはフロントだけじゃん
単にコンパイルされて中間ソースがあるだけでツールで簡単に逆アセできてしまう
そのために高い難読化サービスがあるわけで
2022/07/03(日) 08:09:23.22ID:8+Zm1fQX0
>>760
フロントにドメイン層があるの？
サーバーはインフラストラクチャ層だけか

>>759
そりゃ必要でしょう
ビジネスロジックって足し算引き算だけじゃないよ
2022/07/03(日) 08:42:03.81ID:BunJQVPiM
>>765
ちゃんと読んでレスしてくれよ
ビジネスロジックを書くとき型は必要か？なんて質問をしたわけじゃない
767デフォルトの名無しさん (ﾜｯﾁｮｲ 3aba-d8E0)
垢版 |
2022/07/03(日) 09:33:34.86ID:8+Zm1fQX0
>>766
ビジネスロジックなしでも型は必要でしょってことね
プレゼンテーションロジックでも型が必要なのは納得しました
2022/07/03(日) 19:39:30.15ID:SOqg0ON00
単に型があればVisualStudioCodeなどでインテリセンスが働いて楽とかそんなもんで
そもそもフロントエンドなら大抵はサーバー側とjsonでやり取りするだろうけど
それを表示するだけのフロントで全てのAPIのjsonをクラス化するのかよｗって所がねｗ
ツール使えば自動で吐き出されるとか言うのかも知れんがｗ
C#(Unity)とかだとクラス化した方がコードは書きやすいけど
769デフォルトの名無しさん (ﾜｯﾁｮｲ 035f-9ZeA)
垢版 |
2022/07/03(日) 20:00:04.80ID:dvm8Yx0S0
クラスというよりはインタフェースを定義するって感じかな
ただそれだと結局型安全じゃないキャストをすることになるから
io-tsとかライブラリを使ってAPIがそれを満たしてるかを動的検証できる型情報を定義してる
2022/07/03(日) 20:00:41.12ID:4SpX/mYh0
>そもそもフロントエンドなら大抵はサーバー側とjsonでやり取りするだろうけど
>それを表示するだけのフロントで全てのAPIのjsonをクラス化するのかよｗって所がねｗ

なんか、「フロント」の認識に大きな隔たりがあるのを感じた。
2022/07/03(日) 20:17:50.40ID:eO2MvCIb0
クラス≒型って認識の人は大体クラスベースオブジェクト指向しか知らない人
2022/07/03(日) 20:26:41.79ID:yZSstosFM
ECサイト構成するのとメモ帳なり実用アプリ作るのを同列に語ろうとしても無理だよね
2022/07/03(日) 22:46:24.69ID:v7SLZgpRM
>>771
そういう認識の人は数値や文字列にも型があることの恩恵には気づけないのかもね
2022/07/03(日) 23:02:35.18ID:R2Xlh7GwM
>>771
狭い特定なパターンの型とクラスを持つプログラミング言語だけしか知らないとそこに陥りやすいかもね
例えばWebに身近なところだとWebAssemblyを書くのに最も使われている言語Rustあたりを理解すると何もかも新鮮で一気に視野が広がるかな

Rustはクラスも継承もない
それなのにメジャーな各言語よりも強力で便利で速い静的な型安全を実現している
C/C++と同じ速さで動くのに即時自動メモリ解放なのでミスは起きず安全でガベージコレクションが必要なく高速な初のプログラミング言語
実行前にメモリ安全性からデータ競合の無さそして全ての型安全まで全てをコンパイラが静的に保証してしまう言語がRust

フロントエンドでJS/TSメインで補助的にWasmを使う従来のスタイルから
フロントエンド全てをRustで記述してWasmで動く新たなスタイルまで登場してきているので
今後のフロントエンドの進化でも注目点
775デフォルトの名無しさん (ｱｳｱｳｴｰ Sa82-5Nuq)
垢版 |
2022/07/04(月) 13:41:23.28ID:jO1cee2ga
関係ない話を突然ぶっこむ人っているよね
2022/07/04(月) 22:42:34.12ID:RYfceo1ir
見事に話の腰を折っていったな
2022/07/05(火) 09:10:46.05ID:1P4+UDaA0
Wasmに関してはWasm公式が直々にJSを置き換えるようなものではないと明言してるんだよなぁ
https://webassembly.org/docs/faq/#is-webassembly-trying-to-replace-javascript
2022/07/05(火) 09:27:05.92ID:7ktCWAiNM
>>777
そう言っとかないと炎上して面倒だからでしょ
世間で実際に置き換わるかどうかと置き換えとして使用できるかどうかは別問題で、
少なくとも後者についてはwasmの公式及び信奉者達は実現するつもりだろうな
2022/07/05(火) 09:47:12.59ID:1Na6iR4Vr
名前がダサいし読みにくいから流行らんのだろ
かっちょええ名前にすりゃいいのに
2022/07/05(火) 10:01:45.25ID:1P4+UDaA0
>>778
公式の言うことを全く信じないとか、陰謀論者みたいなこと言いますね……
2022/07/05(火) 10:05:49.50ID:1P4+UDaA0
訂正、信じなくてもいいとは思うけど、公式の言ってることを頭から否定するのはちょっとどうかと思うね
2022/07/05(火) 10:16:35.79ID:wYawBH+gr
なんでも斜に構えるのが格好いいと思ってるお年頃なんだろう
2022/07/05(火) 12:07:20.02ID:yTnwAAWuM
そうなって欲しいという気持ちはわかるけど
現状ワナビが夢語ってるのと変わらん
784デフォルトの名無しさん (ｱｳｱｳｴｰ Sa82-YLMx)
垢版 |
2022/07/05(火) 17:15:47.11ID:qwaP2fx0a
wasmおじさんまだいるのかよ
wasmスレでやりなよ
785デフォルトの名無しさん (ﾜｯﾁｮｲ c718-n3Js)
垢版 |
2022/07/05(火) 23:36:47.01ID:vcOl+iQ90
TS型パズルのせいで終業遅れて趣味の時間が削られまくったわ
地味にイライラする
786デフォルトの名無しさん (ﾜｯﾁｮｲ c718-n3Js)
垢版 |
2022/07/05(火) 23:42:50.14ID:vcOl+iQ90
Nextjsは細かくサーバー処理とクライアント処理分けられるけどここまでやる必要あるのかね
無駄に突き詰めすぎな気がする
せいぜいLaravelとVue程度で良いだろ
2022/07/05(火) 23:57:05.76ID:1P4+UDaA0
なぜ自分を棚に上げて他所に原因を求めてしまうのか
2022/07/05(火) 23:59:36.80ID:8EE7RMvOM
>>777
その通りでWasmはJavaScriptの機能を代替しない
例えばDOM操作をWasmから直接することはできない
そのため各種プログラミング言語で書かれたWasmのプログラムいずれにも補助となるJavaScriptのプログラムが付随している
したがってWasmからは間接的にDOM操作を含めて任意のことができる状況となっている

例えばC#だけでSPA含めたフロントエンドを記述できるフレームワークBlazorや
同様にRustだけで記述できるフレームワークYewなど
様々な各言語だけで記述できるフロントエンドのフレームワークがJavaScriptのフレームワークの競合となりつつある
特にRustで書かれたものはガベージコレクションや重い(or大きい)実行ランタイムを必要としないため
ダウンロードサイズの点でも実行速度の点でも従来のJavaScriptと比べてほぼ同等となっている
2022/07/06(水) 00:12:04.30ID:mL802MxZ0
>>788
WasmからJSを呼び出すオーバーヘッドやGCの無いRustで書いてすらJSで書いた場合よりダウンロードサイズが増えることを意図的に無視してない？
まして所有権に気をつけながらRustで書くのと平坦にJSで書いたものが等速では意味がない。つまりWasmを使うべき場面はそこじゃない。
「その通りで」と言いながら元の文章の意味を都合よく無視した持論を展開するのは詭弁だよ。
790デフォルトの名無しさん (ﾜｯﾁｮｲ 1ea7-8lRc)
垢版 |
2022/07/06(水) 00:47:45.67ID:hw0Myq7K0
next.jsってvercelとの抱き合わせ？
2022/07/06(水) 04:05:40.23ID:iRwSwPVx0
Google Cloudつかってこ？
2022/07/06(水) 23:36:06.51ID:1TXPug1l0
Wasm開発側がJSの代用にはならんって言ってるしな、既存のライブラリが使えるとか得もあるけど
793デフォルトの名無しさん (ﾜｯﾁｮｲ 1e10-SGjz)
垢版 |
2022/07/07(木) 13:52:13.98ID:Q+wrLXon0
案件でReactとVueどっちも触ることがあるんだけど、Reactなんか好きになれないなあ

なんかref使ってDOMを意識しなきゃいけないこと多くない？
案件の性質の違いでたまたまそうなんかなあ
depsとかもバグの温床だし書き方冗長だし
それが好きな人もいるんだろうけど

あとVueのtemplateはいいよね。HTMLそのままだし
tsと相性良ければなあ
2022/07/12(火) 14:55:23.91ID:xMX52/DP0
>>793
refよりはstateの方が使う
ref使わなくてもいい場面で多分ref使ってる
canvasとか埋め込みプレーヤーとかwysiwygのエディターとか操作するときはref使う
depsはhooksのlintのパッケージがあってそれ使えばバグは余裕で回避できる
2022/07/13(水) 01:59:12.26ID:41tA/9He0
ずーっと業務でGoとかのバックエンドやってて最近Vue始めたんだけど書き方多すぎないかこれ...？
まずOptionsAPI、CompositionAPI、script setupと3つある時点で意味わからん。ネットで検索してもコードが読めん。慣れてないだけ？
2022/07/13(水) 03:16:08.34ID:gUCl+Swj0
script setupはComposition API書くためのシンタックスシュガーで、新規コードは全部script setupでいいと思うよ
2022/07/13(水) 08:47:39.64ID:yxy6SFg9a
歴史的経緯があるから書き方が増えるのは仕方ないにしてもドキュメントの整備が追いついてないのが困る
2022/07/13(水) 09:27:13.93ID:uixzy4W8r
３つの書き方の名前を認識できるまで調べてるなら経緯も分かりそうなもんだけどね
あとネットの記事漁るときは日付ぐらいチェックした方が
799デフォルトの名無しさん (ﾜｯﾁｮｲ 9b4a-jCtK)
垢版 |
2022/07/13(水) 10:37:48.05ID:izDlcYF60
ref使わなくていいとこで使っちゃう人はvue使っても同じことになりそう
2022/07/13(水) 23:04:39.43ID:fYvgJCBx0
やっぱReactなんやなって

> Reactに有利なベンチマークを作ってみた
https://qiita.com/uhyo/items/35cb243557df5e1a87fc
2022/07/14(木) 14:01:25.86ID:4YPASV41a
https://qiita.com/tronicboy/items/18c36cb713f77af627d8

Reactオワコンってマジ？
2022/07/14(木) 15:05:14.14ID:gqaZzHXf0
>>801
あんた日本人？
2022/07/14(木) 18:30:18.24ID:H3yOuDPs0
>>801
この記事の主が表層的にしかReact理解してないから、コメントで突っ込まれまくってるな。しかも後半は技術じゃなくてMetaが嫌いって話してるし。
まぁでも、こういうやんちゃな奴がいる界隈は活気があって良いですよ。石頭でさえなければね。
2022/07/14(木) 19:47:30.86ID:JGI4j5iF0
フェイスブックが嫌いってのはかなり多いだろうな実際
2022/07/14(木) 19:52:38.14ID:sdF0D0vF0
>>803
しかも匿名ならわかるけど会社名出してるのが凄いな
806デフォルトの名無しさん (ﾜｯﾁｮｲ 0d01-Juit)
垢版 |
2022/07/17(日) 09:41:45.81ID:SW0KkSnM0
普段Vueディスってんのにreactディスられたとたん発狂する奴多くない？
2022/07/17(日) 10:13:01.49ID:k8G1Xh4yM
記事にツッコミどころが多いだけでしょ
VueはReactに比べるとコンセプトがstraightforwardなので、良くも悪くも「そういう設計を選んだんだからそうなるよね」で議論が済んでしまう
だからこの記事みたいな設計思想に対するディスはあまり見かけない印象
2022/07/17(日) 11:24:22.33ID:vN6ol9NM0
仮想DOMにオーバーヘッドがあるの事実だしな
だからsvelteやsolidが生まれた
普段からパフォーマンスにうるさいフロントエンドエンジニアが
そこには目を瞑るのはおかしいだろうのは痛いところ突っ込まれた感じ
2022/07/17(日) 11:37:33.93ID:D8ZilbuM0
仮想DOMとuseMemoでパフォーマンス的に困ることほぼ無いんよ。使ったことない人にはわかんないかもだけど『早すぎる最適化は諸悪の根源』だよ
2022/07/17(日) 14:40:24.11ID:vN6ol9NM0
そもそものReactの当初の発想は
「クライアント側でのPHP」を目指してたんだぞ
今の人は知らんだろうけど
本質的な面で効率が良くなるわけはないんだよ
2022/07/17(日) 15:06:51.43ID:K5laegAfr
Webの技術って欠陥だよな
2022/07/17(日) 15:17:25.63ID:D8ZilbuM0
XHPというPHPのライブラリが元になった部分があるだけで「クライアント側のPHP」を目指したなんて事実は無いぞ。
仮に「クライアント側のPHP」という機能を目指したとして、実装としてのパフォーマンスに何の関係があるんだ？
自分の言いたいことのために都合の良い過去を作り出した上に変なこじつけをするな。完全に詭弁じゃないか。
2022/07/17(日) 15:24:26.00ID:SZhCYswta
>>812
PHPみたいにというのはつまりカスタムタグ使って
ページを毎回再レンダリングしているように作りたいってことだよ
サーバーサイドがそうしているようにね
その副産物として仮想DOMやJSXが生まれた
2022/07/17(日) 15:32:09.77ID:D8ZilbuM0
>>813
そういう意味なら確かにそうだね
2022/07/17(日) 16:30:58.35ID:zDUNQKdi0
>>813
でなんでそれがPHPになんの？
2022/07/17(日) 18:40:14.41ID:SZhCYswta
まずPHPといってるがfacebookの人がPHPと言ってるからそう言ってるがサーバーサイドと言い換えるべきものだよ(ご存じの通りfacebookはPHPのヘビーユーザー)

クライアントからリクエストを受けたらサーバーサイドは
HTMLを全て「生成し直して」レスポンスを返す
前回の状態など意識せず全て情報を取り直してHTMLを生成する
当たり前だが前回の状態との差分を取って部分的にHTMLを返すなどということはしない
常に丸ごと返す
このモデル(HTTPだが)の良いところはHTML生成といううコンテキストにおいては前回の状態と言ったものは意識しないで済むこと
最新の状態を取ってそれをもとにHTMLを生成すればよろしい

当時のフロントエンドはDOMに状態を持たせてajaxはその状態を更新して対応するDOMを更新するというアプリが大多数だった
フロントエンドもサーバーサイドのように状態を意識せずに関連するDOMを毎回全部生成できないか？という発想が生まれる
React誕生の瞬間である

renderとstateを使って状態が更新されたらどの部分を更新するか一切意識することなく常に一枚岩のDOMを返すようにかける
見事サーバーサイドをクライアントに持ち込めた
ただしこの動きを実現するためには差分を内部的に検出する仕組みが必要不可欠
本当に毎回DOMを全部生成してたらパフォーマンスが終わる
ユーザーはDOMを意識せずに全部返すように書くが
裏で差分を検出してこっそり部分的にDOMを書き換えるようにしよう
仮想DOMの爆誕である
そうなるとJSXみたいなものが必要だよねとなってJSX爆誕
これがReactの歴史である
知らんけど
2022/07/17(日) 19:22:31.49ID:HJLgMN7zM
パフォーマンスが実用に差し障るほど悪いという話には繋がらないわけだ
2022/07/17(日) 19:36:10.36ID:R88kcvl50
そりゃ、前提条件を決めなきゃそんな話はできないからな。
用途や規模によっちゃWeb自体「実用に差し障る」し。
2022/07/17(日) 19:49:44.56ID:SZhCYswta
仮想DOMのオーバーヘッドを許容しても
丸ごと全部DOMを返すようにかけるメリットがあまりにも大きい
お前らも大規模アプリにおいてはこの書き方がいかに素晴らしいかわかってるよな？
facebookクラスになると何千という状態があるだろうし
それを宣言的にかけるメリットの方が遥かに優先される
仮想DOMがゴミと言ってるやつはデメリットだけを見過ぎ
上に書いたようなメリットがデメリットを上回るのよ
ギャーギャー騒いでる奴らはしょぼい管理画面とかしか実装してないだろうからデメリットばかり見えるんだろう
2022/07/17(日) 19:57:05.90ID:wMKh8j6l0
Facebookを作るわけじゃないならゴミってこと？
2022/07/17(日) 20:06:33.34ID:D8ZilbuM0
結局仮想DOMのパフォーマンスに文句言ってんのがReact書いたこと無さそうな人ばかりなのよね。こういうシステム書くと何秒かかってユーザー体験が悪い、みたいな具体的な話が無い。
2022/07/17(日) 20:07:30.57ID:SZhCYswta
上に書いた歴史を踏まえればなぜReactは毎回コンポーネントをレンダリングしようとするの？とか
仮想DOMのオーバーヘッドが無駄じゃね？と思ってる人は
その理由が全部理解できたと思う
2022/07/17(日) 20:50:04.60ID:FtkU6BrHr
おれは業務基幹システムのフロントをReactで作ってる
業務では全国の数百人が一日中ガシガシ操作するのだがReactで作ってよかったと思ってる

数百のコンポーネントを俺一人で作り上げた
画面の中には多数の分割されたコンポーネントやモーダルウィンドウが表示され、格コンポーネントがリアクティブに反映され、さらにcssやcanvasで視覚的に描画もしてる

これを俺一人でAtomicデザインからコンポーネント、ビジネスロジックまですべて設計して開発した
2022/07/17(日) 20:57:54.95ID:HqESQyZt0
>>823
すげぇ！
2022/07/17(日) 21:02:05.70ID:Apu5q5Ct0
>>823
使ったライブラリとか教えて欲しい
2022/07/17(日) 21:15:44.80ID:FtkU6BrHr
>>825
すまん身バレするから詳細までは言えん
開発初期にはsveltもsolid.jsもなかった（あったのかもしれないが知らなかった）から候補にはならなかった
2022/07/18(月) 00:34:30.15ID:U2Tzu0Bd0
>>825
特段不要じゃね？
2022/07/18(月) 02:55:33.23ID:hrLDmHJy0
>>823
cssで視覚的に描画とは？
2022/07/18(月) 06:22:36.79ID:VnhjZgbs0
>>828
animationとかじゃないかな。
2022/07/18(月) 11:06:46.58ID:0LWcwOair
>>828
簡単に言うと業務に関するフロー図のようなグラフィカルな表示をするためにhtmlとcssとcanvasを使っている
2022/07/18(月) 17:57:02.34ID:7ni5jFGl0
React Native、Flutter、Vueを触ってきて最近Svelteでサクッとアプリ作ったけどSvelte一番好きだわ
Vue3のComposition APIをさらに簡潔にした感じでマジでわかりやすいReactのJSXやFlutterのWidgetが大嫌いだから余計にそう感じる
ただ一番マイナーでエコシステムが弱いんだよな特にコンポーネントライブラリでデザインが良いのがSvelteUIくらいしかないんだがまだ始まったばかりでぜんぜん実用に耐えない
2022/07/18(月) 19:50:28.15ID:7HaFqkS9a
むしろサクッと作る場合こそReactがベスト
関数作ってuseStateで状態作ってJSXをreturnすれば終わり
フォームもcreateRefとか使えば深く考える必要もない
何も考えなくて良い
833デフォルトの名無しさん (ﾜｯﾁｮｲ f6db-q6UQ)
垢版 |
2022/07/18(月) 22:09:27.02ID:Ggy5Lh6B0
>>831
SvelteKitが1.0に到達したらもっとエコシステム等が充実すると思う。
2022/07/19(火) 09:45:05.85ID:tLF1kVqmr
>>832
その文面だけではどうしてReactがベストなのか理解できないわ
もうちょっと具体的に比較を頼む
2022/07/19(火) 10:06:20.35ID:oBRFDG2+0
>>832
同意
2022/07/19(火) 11:50:07.11ID:Ah8Bn+D60
ちょっとしたフォームを考えてみる。大項目A中項目B小項目Cがある。項目リストはRESTで取得する。
Aが選択されたときBのdisabledが外れoptionがセットされる。BとCの関係性も同様。Bが変更されたとき、Cのselectedはキャンセルされ、optionは再度セットさせる。ではCが選択された後にAを変更するとどうなるか。BとCのoptionが再セットされCはdisabledになる。A～Cは他の項目にも影響を与える。今後Cの下に項目Dが追加されるかもしれない。
見た目は簡単なフォームだが既に面倒くさい。こんなのグローバルな状態を使って管理したくない。俺はReact(Preact)を使って楽をする。
2022/07/19(火) 12:02:11.23ID:YENIBnXc0
SvelteのTemplate Syntaxとバインドでも簡単に作れるんだが
俺Reactしか知らないけどイキリ散らかすわとしか読めない
2022/07/19(火) 12:28:49.83ID:Ah8Bn+D60
あぁごめん。他のライブラリでも全然良いよ。React程は詳しくないから書かなかっただけで。
何も無しよりはずっと楽だからライブラリ使っちゃうよね、ぐらいに思ってくれ。
2022/07/19(火) 13:48:12.52ID:EJF9eOI8r
間違ってたら指摘してほしいんだけどReactで開発してて一番嫌なのが状態管理をMeta(Fb)が実装しないでコミュニティに丸投げしてるところなんだよね
なによりReduxってどこがいいのかまったくわからない
冗長なボイラープレート満載かつどこをロジックの場所にするかプログラマーによって解釈が異なるし
結局Viewでhook使いまくりになって疎結合とは？になる
2022/07/19(火) 15:08:50.18ID:oBRFDG2+0
>>839
Reactはバカチョン機能を提供しない

いやそんなミドルウエア的なの
押し付けられても困るの!!(;´Д`)
2022/07/19(火) 17:40:32.76ID:qBIBPRGnr
>>838
>>836ってどの話からつながってるの？
2022/07/19(火) 18:59:17.30ID:CnRmwysFa
>>839
いまだにそこに文句を言ってるのが凄い
状態管理に銀の弾丸はないのよ
「Hooksを用意したからお前らで適切なものを作れ」

これがMetaが行き着いた結論であるし
実際これはすごく良く機能してる

とりあえず生useStateでサクッと作る
→複雑になってきたからカスタムフックをつくる
→コンポーネント化出来そうだからコンポーネントに切り出す

この開発サイクルがどのフレームワークより優れているのよ
実際ここまで拡張しやすいのはHooksとコンポーネントとJSXの親和性良さ故なのだが
2022/07/20(水) 00:44:50.38ID:vmAGDFkA0
>>839
MetaがRecoilってやつ出してるよ
結構浸透してる
2022/07/20(水) 07:25:51.14ID:0ymUel2Or
>>840
Recoilがあるんだが？知ったかおバカさん？

>>842
そもそもViewが状態を持たないから依存関係がなく疎結合でReactすごい！って信者の常套句だったのだが？
結局Reduxのストアという状態管理の煩雑さ・スコープの問題からContext APIでよくね？ってウェブあるあるの先祖返り起こす一派もいるけどそっちはそっちでやっぱり問題あって
そして出てきたRecoilはHooks API使ってコンポーネント単位で小さく状態管理するからViewががっつり状態持ってて疎結合とは？になる
しかもRecoilってまだ実験段階の代物でウェブ特有のいつツールチェインが移り変わるか頭を悩まされるのが嫌だからOSSにしてもメーカーが主導すべきなのに遅すぎる
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況