Vue vs React vs Svelte Part.7

**デフォルトの名無しさん** · 2021/01/18(月) 01:41:17.84

実際どうなん？
※Angularは残念ながら全く話題にならなかったのでSvelteに差し替えました
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Svelte Part.6
https://mevius.5ch.net/test/read.cgi/tech/1603771745/

★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Angular, Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。

**デフォルトの名無しさん** · 2021/01/18(月) 02:46:11.50

いつの間にか出てたstateofjs
https://2020.stateofjs.com/en-US/

**デフォルトの名無しさん** · 2021/01/18(月) 10:21:56.14

>>2
GatsbyがややNegativeに動いてるのが意外。Svelteはみんな試し出してるのが分かるね。しかしReact圧倒的だな…
https://2020.stateofjs.com/en-US/technologies/arrows_overview

**デフォルトの名無しさん** · 2021/01/18(月) 10:27:15.86

Angularの落ちっぷりよ…
https://2020.stateofjs.com/en-US/technologies/front-end-frameworks/

**デフォルトの名無しさん** · 2021/01/18(月) 20:33:59.29

react、reduxあたりまではいいけどホンマにredux-sagaとか使ってんのか？ってのは思う。

**デフォルトの名無しさん** · 2021/01/18(月) 22:24:47.18

redux sagaの良さを理解できてない。thunkもそうだけど。

素直にサーバーからのレスポンス待ってdispatchすれば良いと思うけどね

**デフォルトの名無しさん** · 2021/01/19(火) 03:10:37.80

昔は使われた。
今はrecoilあるしわざわざ新しく始めることはない。

**デフォルトの名無しさん** · 2021/01/19(火) 05:50:12.77

reduxはオワコンだと思う
俺は前から現場でアクションをswitch caseで管理する
バカらしさを批判してきたが
なぜか誰も聞き入れることはなかった
あんなのアクションの爆発的増加を生んで管理できなくなるのは明らか
C言語かよ

**デフォルトの名無しさん** · 2021/01/19(火) 09:46:31.88

ReactやVueのアプリの設定値ってどこに設定するの？

Widowsネイティブアプリだとiniファイルとかconfigファイルの相当するファイルだけど。

**デフォルトの名無しさん** · 2021/01/19(火) 10:23:19.25

>>8
それはお前のアプリケーションではreduxが必要なかったってだけでしょ。

**デフォルトの名無しさん** · 2021/01/19(火) 10:23:39.51

>>9
環境変数の設定の仕方ってこと？

**デフォルトの名無しさん** · 2021/01/19(火) 11:25:44.48

>>11
意図としてはそうかもです。

ネイティブアプリの設定は外部設定ファイルに個別設定が多かったのですが、
それは出来ないのでしょうか？

(ネイティブアプリの場合)
xxxxx.exe
xxxxx.ini --- これに相当するもの

**デフォルトの名無しさん** · 2021/01/19(火) 11:30:20.28

>>12
.env が一般的かも

.env reactとかで調べてみると出てくると思う

**デフォルトの名無しさん** · 2021/01/19(火) 12:44:35.54

>>13
OK！

**デフォルトの名無しさん** · 2021/01/19(火) 21:39:30.50

ContextAPIを"正しく"扱うための学習コストを考えたらRedux toolkitで良くない？って思うんだけどなぁ

**デフォルトの名無しさん** · 2021/01/20(水) 00:04:43.78

>>15
そもそも目的が違うから何とも…

**デフォルトの名無しさん** · 2021/01/20(水) 01:16:07.15

>>4
vue.jsすごいな85%もあるよ

んで、その下に書いてある、vue.js 12ってのは何だ？
Backboneは18だぞ。jQueryは22だぞ

**デフォルトの名無しさん** · 2021/01/20(水) 03:18:29.28

>>17
そんなん俺に言われても…

**デフォルトの名無しさん** · 2021/01/20(水) 10:02:22.15

>>759
草

**デフォルトの名無しさん** · 2021/01/20(水) 21:20:12.99

今からreduxまじめに勉強するのめんどいから早くrecoilに殺されてくれ

**デフォルトの名無しさん** · 2021/01/20(水) 21:28:27.25

redux使って開発したけど面倒くさすぎる
こんなゴミクソ誰が考え出したんだか

**デフォルトの名無しさん** · 2021/01/20(水) 23:05:01.07

俺はjotai推し

**デフォルトの名無しさん** · 2021/01/20(水) 23:16:36.42

jotaiとrecoil何が違うのかいまいち理解してない

**デフォルトの名無しさん** · 2021/01/21(木) 11:00:16.76

除隊？女体？

**デフォルトの名無しさん** · 2021/01/21(木) 11:01:01.06

女体はにょたいと読むだろ普通

**デフォルトの名無しさん** · 2021/01/22(金) 05:45:13.61

redux toolkitはいいぞ

**デフォルトの名無しさん** · 2021/01/22(金) 14:08:50.42

reactみたいに使うライブラリが徐々に更新されるような軽いフレームが好きなんだが、
やっぱ趣味でいじってるのと仕事でやるのは違うかもな。

**デフォルトの名無しさん** · 2021/01/24(日) 11:27:05.70

皆ユーザ認証は何使ってるん？
やっぱりAuth0？

**デフォルトの名無しさん** · 2021/01/24(日) 12:30:44.24

仕事で使うのはfirebaseが多いなぁ

**デフォルトの名無しさん** · 2021/01/24(日) 14:33:43.27

Password

**デフォルトの名無しさん** · 2021/01/24(日) 16:50:55.93

recoilこれダメだろ。。reduxの100倍くらいデータの流れがわからなくなるわ。。

**デフォルトの名無しさん** · 2021/01/24(日) 18:36:32.85

>>29
firebaseも人気あるみたいだね。
使ったことあるけどライブラリがでかいイメージある

**デフォルトの名無しさん** · 2021/01/24(日) 23:44:21.06

auth0なんか覚えること多すぎて覚えるまでかなりしんどそう

**デフォルトの名無しさん** · 2021/01/25(月) 00:02:44.28

JWT一択
仕様としてはかなり簡単だし
この程度はフロントエンドの人でも自力で実装すべき

**デフォルトの名無しさん** · 2021/01/25(月) 00:31:18.66

いやJWTがバックエンドありきだろ…
それを何使ってますかって話。

**デフォルトの名無しさん** · 2021/01/25(月) 00:50:11.74

普通に自前実装だが何を使うとは？
ライブラリとかフレームワークのこと？

**デフォルトの名無しさん** · 2021/01/25(月) 01:05:43.46

自前実装は絶対にしない方がいい。
jwtの認証は簡単に作れるけど、セキュリティホールになりえるからセキュリティのプロの人たちが実装した　idaas使った方がいい

**デフォルトの名無しさん** · 2021/01/25(月) 01:12:25.03

まぁ、自分たちがセキュリティに精通してると胸張って言える人は自前実装でもいいと思うけど。

**デフォルトの名無しさん** · 2021/01/25(月) 01:13:35.44

https://www.google.co.jp/amp/s/auth0.com/blog/amp/jp-a-look-at-the-latest-draft-for-jwt-bcp/

ここでも書かれてるけど、専門家以外は自前実装するべきじゃないよ

**デフォルトの名無しさん** · 2021/01/25(月) 03:13:43.63

そのライブラリがセキュアだという保証は？
それにライブラリがない言語は自前しかないし
セキュリティはもうライブラリ作者の個人が担保するものではないよ
セキュリティ担当者がいないならすぐ雇うか
どこかに依頼すべき

**デフォルトの名無しさん** · 2021/01/25(月) 07:08:04.12

セキュリティに関しては、完璧な知識を持った上でシステムを隅々まで理解し、時節に変化があれば即時にキャッチし、情報が漏れたときに全責任を負う。自前でやるならそれぐらいの覚悟が必要だと感じてる。

**デフォルトの名無しさん** · 2021/01/25(月) 08:12:31.39

s/セキュリティ/ユーザ認証/

**デフォルトの名無しさん** · 2021/01/25(月) 09:18:54.69

セキュリティを専門とするエンジニア（コンピューターサイエンスに深い理解を待ってる人）を雇えるならいいよ。
でも大抵の企業がセキュリティ担当に1000マン以上出して雇おう！って感じではないでしょ

auth0とかfirebaseはセキュリティに精通しているエンジニアを雇ってるからね。どっちが信用できるかの問題だよ。自社のエンジニアを信用するならそれでいいと思う。

クリティカルな部分のセキュリティに関しては、専門家じゃないやつの理解って大切だけど、本質的にはあまり意味ないと思ってる。何故なら知識が浅いから

**デフォルトの名無しさん** · 2021/01/25(月) 09:20:17.82

>>41
これに関しては自社で実装しててもしなくても一緒だと思う

**デフォルトの名無しさん** · 2021/01/25(月) 18:10:27.05

まず自前実装ってどこからどこまでの話なのか
自社のバックエンド側で認証の仕様が決められてて
それに基づいてフロントエンド側を実装するって話なら分かるが

**デフォルトの名無しさん** · 2021/01/25(月) 19:18:20.55

ここでもう認証はこれにしろ！ってのを決着つけてほしい