22/01/21 13:16:50.88 6I3Of8sH.net
>>76
状態を呼び出されたインデックスで管理してるんだからむしろわかりやすいと思うが
「副作用の内容」は全く意識しなくて良いのよ
そこはreactに丸投げできる
これこそHooksの素晴らしさ
わかりにくいと感じるのは副作用を意識してなさすぎるから
react難しいと言ってる人は関数型言語などの副作用、参照透過性、冪等性、(できればモナド)などその辺りを勉強し直した方が良い
84:デフォルトの名無しさん
22/01/21 13:20:29.63 cMXeDUr/.net
>>80
そういう意見もわからんでもない。
ただ、俺はそういう制約はあえてやってると感じるな。一見不便な制約だけど、それがある事によってコードが統制される。React的に正しい書き方に矯正される。
85:デフォルトの名無しさん
22/01/21 13:46:47.17 sORVJkOm.net
ドキュメントにフックがトップレベルでしか呼び出せない理由って説明されてるけどな
86:デフォルトの名無しさん
22/01/21 13:58:56.69 JF8FJvk5.net
CommentListも再利用前提ならプレフィックスを付けてArticleCommentListにしたらいい
ファイル数は増えていくが、コンポーネントをシンプルに保つ恩恵の方が圧倒的にでかい
87:デフォルトの名無しさん
22/01/21 14:04:37.79 sORVJkOm.net
結局はチームで統一されてれば良いって話ではあるけどね
88:デフォルトの名無しさん
22/01/21 20:32:48.44 mtDqJL7w.net
>>68
axios で投稿一覧取得して vue で表示する処理を書いたけど、
サーバ側でphpのforeachで回してた時htmlspecialcharsでエスケープしたり文字列操作したりしてたことをvue側でせないかんってことだよな？
なかなかめんどくさい気がしてきたがこのあたりどうしてるんだろうか
89:デフォルトの名無しさん
22/01/21 21:17:44.47 x9mhjTMm.net
マスタッシュ構文ならふつうにエスケープしてくれるはずだが
90:デフォルトの名無しさん
22/01/21 21:24:06.47 6I3Of8sH.net
>>87
逆に今時それを自動でやらないフレームワークなんてあるのか？
91:デフォルトの名無しさん
22/01/21 21:57:20.08 cMXeDUr/.net
dangerouslySetInnerHTMLとかいう長くて物騒なパラメータ名大好き
92:デフォルトの名無しさん
22/01/21 23:16:24.74 2Ya+eSMz.net
>>69
>サーバーにアクセスするAPIのほうが遅くて
そりゃ、データベースの外部キーとか、インデックスの張り方による。
N + 1 問題とか
Ruby on Rails の単一テーブル継承とか、多対多・1対多・1対1 とか、
高度資格のdatabase specialist みたいな国家資格とか
>>76
>配列の1要素を変更しただけで配列全体が変更されたとみなされて
Vue.js では、key を付ければ、他の要素に影響がないけど、
React には、そういう機能が無いの？
93:デフォルトの名無しさん
22/01/22 01:22:23.25 ug6tBrwm.net
>>77
まったくないじゃなくて
殆どないって言ってるんだから
あるのは最初からわかってるだろ
お前ゆとり蚊？
94:デフォルトの名無しさん
22/01/22 06:18:54.77 pRWoUPFR.net
はいはい、そうだね。がんばってね
95:デフォルトの名無しさん
22/01/22 07:19:40.45 SSulEqfs.net
NextAuth.jsって使ってる人いる？
96:デフォルトの名無しさん
22/01/22 09:02:27.22 ug6tBrwm.net
>>93
もう終わったよｗ
ほんと有名な事例だけ上げて
それが全てだと思ってるからアホやで
97:デフォルトの名無しさん
22/01/22 09:08:30.48 f0z1Aqc4.net
日本語でおk
98:デフォルトの名無しさん
22/01/22 17:28:48.01 nygG3ujp.net
最近はReact優勢らしいけど個人での小規模開発でもVueオワコンなの？
転職用のポートフォリオの為にGoとVueでウェブアプリケーション作ってるんだけど今からでも変えた方がいいのかしら
99:デフォルトの名無しさん
22/01/22 17:30:01.75 yOBcCnZH.net
>>97
優勢というかほぼ決着はついた
Reactにしとけ
vueは未来がない
100:デフォルトの名無しさん
22/01/22 20:09:13.48 63g4vstf.net
Vueは結局一回も触らんでオワコンなった
我ながら良い選択をしたね
今後メンテナンスしなきゃならん人はご愁傷様
101:デフォルトの名無しさん
22/01/22 20:19:21.52 gpkanxFS.net
今からVueとか罰ゲームかよ
102:デフォルトの名無しさん
22/01/22 21:56:09.98 xUvzS2fG.net
URLﾘﾝｸ(zenn.dev)
↑
reactばっか使ってるわしはこれ読んで良さようやんって思ってんけどな
vueは具体的に何がオワコンなんだい
103:デフォルトの名無しさん
22/01/22 22:36:32.62 5qbRq3WR.net
アジア圏でしか使われてない
Angularとずっとシェアがトントン
104:デフォルトの名無しさん
22/01/22 22:56:29.72 yOBcCnZH.net
>>101
現在のvueのベストプラクティスと言われてる書き方を見てみな？
ほぼReactでしょ
つまりそういうこと
105:デフォルトの名無しさん
22/01/22 23:09:14.68 FWl1ZFNo.net
>>101
そもそもbetter angularというコンセプトの元
人気が出たvueだがその記述方法がオワコン化するに従って
Reactの機能を取り入れ始めた
そして全てがReactになる
106:ｼ無しさん
22/01/22 23:18:25.01 mmM8IstB.net
別にvueでもいいと思うぞ
ここでオワコン言ってるやつは、そいつがそうなってほしいだけ
まあ、時間がそのうち決めるだろうさ
107:デフォルトの名無しさん
22/01/23 00:34:43.39 Ywyyr4ki.net
単一ファイルコンポーネントはわりと好きだった
108:デフォルトの名無しさん
22/01/23 00:38:59.45 TuoOb8rP.net
これからはSvelteが流行るって聞いて勉強してるんだがそろそろReactもオワコン扱いしていかないか？
109:デフォルトの名無しさん
22/01/23 00:58:41.28 L5G2SnD6.net
Svelteが殺してしまうのは多分ReactじゃなくてVueなんだろうな……
110:デフォルトの名無しさん
22/01/23 01:07:55.47 5LuXaMWA.net
>>108
多分そうなると思う
結局Reactの素晴らしさはコンポーネントとHooksとJSXの連携なのだから
そこを避けようとするフレームワークはどこまでいってもReactになれない
111:デフォルトの名無しさん
22/01/23 01:13:47.61 /7F6TbfS.net
laravelとVueは中国語のドキュメントが充実している
112:65
22/01/23 05:44:45.01 G94fcmHV.net
日本は特殊で、YouTube で有名な、雑食系エンジニア・KENTA のサロンでも、
未経験者の転職用にはReactよりも、Vue.js を使うように指示している
誰か、Vue.jsがオワコンかどうか、KENTAに聞いてみてくれ
PHP, Scala は、KENTAがオワコン認定したから、もう新規プロジェクトは無い。
ZOZO はLaravel だけど、創業者の前澤が、会社の株を孫正義に2千億円で売って逃げた
113:デフォルトの名無しさん
22/01/23 05:51:50.36 1P4fHIMN.net
KENTA？
誰？
114:デフォルトの名無しさん
22/01/23 07:22:45.53 sJJCSXxo.net
ケンタはフロントが絶望的にできないからお呼びではない
115:デフォルトの名無しさん
22/01/23 17:21:31.55 z9Jick6I.net
中国人ならvue
それ以外ならreact
116:デフォルトの名無しさん
22/01/23 17:25:00.77 yoD8olQP.net
これからはvue3 x Nuxt 3だよ
Reactなんて外国にカブれてる奴が使ってるだけだろ
117:デフォルトの名無しさん
22/01/23 18:37:17.60 cVkgikFr.net
中国被れがなんか言ってるぞ
118:65
22/01/24 04:23:26.19 VeWznQkJ.net
KENTA・勝又健太は、YouTube のRuby on Rails 初心者向け有料サロンの主。
月千円で、日本6位の3千人が入っている。
1位は、キングコング西野の数万人
Vue.js 日本ユーザー会も3千人で、1つのRailsサロンと同じ人数
KENTAは、日本にプログラミング教育革命を起こした。
1年ぐらいの勉強で、10年以
119:上のプログラマーよりも上 最も短時間の勉強で、給料を上げる方法を見つけた人。 それが、Rails のバックエンドエンジニアになる事 KENTAの普及により、今じゃ未経験者でも、 Bootstrap, Heroku, Docker, CircleCI が当たり前 今や、AWS Fargate, GitHub Actions, Terraform, TypeScript, React, Vue.js 出来ないと差別化できない 今の未経験者は、それぐらいハイレベルな領域で戦っている。 10年以上の化石プログラマーは、太刀打ちできない。 使っている道具が違うから ツルハシで掘っている土方と、巨大なメカで、トンネルを掘っているのとの違い。 それに初めて気付いて、教育革命を起こした
120:デフォルトの名無しさん
22/01/24 08:40:30.54 lXb0w+3k.net
いつもKENTAの宣伝しにくる人のレベルを見るとKENTAのレベルの低さが如実にわかる
121:デフォルトの名無しさん
22/01/24 20:21:01.57 MA2v7tDv.net
svelteはvueの正当進化系
vue3の中身がsvelteでもおかしくないはずだった
122:デフォルトの名無しさん
22/01/24 20:38:11.48 bH48I66w.net
じゃあvue君次はsvelteにすり寄ればええやんけ
123:デフォルトの名無しさん
22/01/24 20:56:17.77 XwWsIA6P.net
vueって仮想DOM使ってないんだったっけ？
マイナーだからよく知らんが
124:デフォルトの名無しさん
22/01/24 21:27:03.91 vireAt4B.net
この指摘は結構的確
URLﾘﾝｸ(www.youtube.com)
125:デフォルトの名無しさん
22/01/24 22:04:02.46 AqugRa0+.net
フロントは各自が好きなもの使えばいい
そのためにバックエンドと切り離したんだからね
明日オワコンなってもすぐに乗り換えられる安心感
126:デフォルトの名無しさん
22/01/24 23:08:34.60 VeWznQkJ.net
KENTA の天敵・モローは消えた
モダンな自社開発系Ruby on Rails のKENTA vs
旧態依然のJava 土方を集める、SES のモロー
みずほ銀行の2千億円・統合プロジェクトも終わって、Java土方の仕事が無くなった。
それで、みずほ銀行はバグってばかり
可読性も悪いし、巨大すぎて直せない
127:デフォルトの名無しさん
22/01/24 23:48:28.66 WeU5fM2j.net
サーバーサイドはPHPが一番分かりやすい
Rubyなんて論外ｗ遅いし見にくいｗ
128:デフォルトの名無しさん
22/01/25 06:21:43.12 LH8v1+14.net
わかりやすい≒使いやすい、ではないと思う。それはそれとしてPHPもすごく進化して昔とは別物らしいな。使ってないから知らんけど。
129:デフォルトの名無しさん
22/01/25 06:24:38.49 9iAikC29.net
>>126
いいなぁ
130:デフォルトの名無しさん
22/01/25 06:56:38.55 zGY28tNX.net
Rubyは遅いし世界的に廃れているしな
イキってた残りカスがそこら中でケンタと一緒に宣伝してるがそもそも言語として論外
131:デフォルトの名無しさん
22/01/25 08:00:40.58 DsUuhEjU.net
いつものRubyガイジがやたらとKENTAに言及してるのなんでだろう？と思ってたんだが
そのKENTAとやらがRubyを推してるっていう理由だけなのか
この板についてはRubyもKENTAもNGWordに突っ込んでおけば万事解決だな
132:デフォルトの名無しさん
22/01/25 10:03:27.07 6PEgrqex.net
ReactのHookはsvelteのstoreの
133:デフォルトの名無しさん
22/01/25 10:03:42.67 6PEgrqex.net
ことかな？
134:デフォルトの名無しさん
22/01/25 11:16:11.38 n4f4CMvM.net
フック船長はなんでもありな感じ
Reactの純粋さにとって都合が悪いものをまとめて隠蔽するヤバい奴
135:デフォルトの名無しさん
22/01/25 11:39:52.80 6PEgrqex.net
当方、svelteでwebアプリのフロントエンドを学んでいるが
javascriptの型無し && スレッド意識せず && 引数の参照渡し && エラーマネジメント皆無
で、すぐ迷宮になりそう。
こんな言語仕様でよくチームで組めますね…怖い
136:デフォルトの名無しさん
22/01/25 12:03:18.55 VN0kea3O.net
TSにすること
入力を常に信用しないこと(型が付いてても)
出力も信用しすぎないこと
OSSライブラリは間違っている前提でラップする事
関数を盲信せず普通にオブジェクト指向すること
typeフィールドで望まないダックタイピングを抑制すること
これがフロントエンド開発のコツやね
137:デフォルトの名無しさん
22/01/25 12:58:53.71 LH8v1+14.net
>>133
大丈夫、JavaScript怖くないよ！
> javascriptの型無し
TypeScriptとバリデーションで解消
> スレッド意識せず
WebWorker使わなきゃスレッド関係ない。非同期の話なら他の言語でも使われてるから慣れた方がいいかと。
> 引数の参照渡し
なんか問題ある？
> エラーマネジメント皆無
TypeScript使ってれば殆どの実行時エラーは潰せるので、あとはサーバとの通信時くらいになる。そのへんはPromiseなのでcacheメソッドで処理する（RustのResultみたいに）
138:デフォルトの名無しさん
22/01/25 13:53:10.77 Q8c0uB3k.net
ReactとMaterialUIを昨日から始めたんだけど
既に挫折しそう…
URLﾘﾝｸ(i.imgur.com)
ボタンの色を変えたいだけなんだけど
色んなページを見ながらやっていて
これで色は変わったんですが
ボタンを押したら指定した色ではなく
白色にボタンが変化してしまいます
なんか設定が間違ってるんでしょうか？
139:デフォルトの名無しさん
22/01/25 13:57:11.19 Q8c0uB3k.net
ちなみにvariant="contained"を消した場合
ボタンを押したらボタンが消滅します
リロードすればまた緑色のボタンとして復活します
140:デフォルトの名無しさん
22/01/25 13:57:29.19 Q8c0uB3k.net
jQueryでやりたい…泣
141:デフォルトの名無しさん
22/01/25 14:04:28.53 Q8c0uB3k.net
結構色んなサイトを見て
やり方とかimportする内容が違ったりするんですが
色々なパターン試してみた結果
色を変える事が出来るんですが
やっぱりボタンを押すと色がトンチンカンな色になります
sxプロパティで赤色に変えた時は
クリック後に青色になります
もう意味が分からない…
142:デフォルトの名無しさん
22/01/25 14:18:52.87 Q8c0uB3k.net
これ消えてるわけじゃないのか
materialUIってもしかして背景が黒の場合が
全く想定されていないUIなのか…
143:デフォルトの名無しさん
22/01/25 14:46:05.04 g1NUIKPr.net
個人的な意見だけど見た目をカスタマイズしたい要件があるときはサードパーティコンポーネントは使わずにゼロから作る方が楽だと思う
便利な機能を持ったサードパーティコンポーネントが使えなくなるのは残念だ
だけど見た目の変更の仕方がわからなくなって何時間もハマるのはもっといやだ
サードパーティコンポーネントでやると決めたら拘りは捨ててコンポーネントを並べるだけで最後まで突っ走る
この見た目の定義がコンポーネントに隠蔽されてるのでカスタマイズしにくい問題をreactの達人はどうやって解決してるんだろう？
144:デフォルトの名無しさん
22/01/25 15:04:21.85 Q8c0uB3k.net
>>141
ほんとそうかもしれない…
普通のやり方でやれば5分で終わる作業なのに
何時間もかけるのはアホらしい…
145:デフォルトの名無しさん
22/01/25 15:16:41.58 Vpr7pdMG.net
Reactの達人では無いけど、
俺はわりとプレーンなコンポーネントを使うし、デザイン面は愚直に書けるTailwindCSSだより。
複雑なコンポーネントはデザイン用のインターフェイスだいたいある気がする
146:デフォルトの名無しさん
22/01/25 15:59:12.23 vaBsc+P3.net
下に記述してるstyleの宣言を上のSenderより上で宣言しないといけないんじゃないの？
147:デフォルトの名無しさん
22/01/25 16:21:49.50 H/nIVFN9.net
>>141
特にB2Bな案件だと自前で作るしかないねえ
ライブラリの罠に嵌まりたくもないし
メンテされなくなった時のリスクもでかい
148:デフォルトの名無しさん
22/01/25 16:36:07.84 TQ9E9Mb0.net
いきなりreactとUIライブラリの学習はキッツイだろ
reactに慣れてきてからUIライブラリ使いなよ
149:デフォルトの名無しさん
22/01/25 16:42:44.81 Q8c0uB3k.net
ちょっとmaterial UIは諦めます
reactを覚えるだけでも大作業だわ…
親から子コンポーネントに
関数を渡すのに1時間30分かけて進展がない…
もう全部捨ててjQueryでやろうかしら…
Action Script、C/C++、Swift、SwiftUI、
processing、openFrameworks、
AVR(c)、とやってきたけど
初歩的なところでこんなつまづいたの初めてかもしれん…
やってられん…
Facebookが作るものはやっぱりFacebookクオリティか…
150:デフォルトの名無しさん
22/01/25 16:45:43.61 H/nIVFN9.net
>>147
context使えよ
151:デフォルトの名無しさん
22/01/25 17:23:44.90 AcFVm5mX.net
1時間半で諦める人には向いてないかも
152:デフォルトの名無しさん
22/01/25 17:30:42.61 aL9hRZfU.net
>>147
マテリアルUIは使ったこと無いから知らないけど、親から子に関数渡す超初歩的なことならドキュメントに書いてあると思うよ
153:デフォルトの名無しさん
22/01/25 17:42:37.67 vaBsc+P3.net
さすがにヘボすぎだろ
154:デフォルトの名無しさん
22/01/25 18:38:47.07 4LvgZIvr.net
Reduxほんとに使うこと無くなったね
もう2度と関わりたくないよ
155:デフォルトの名無しさん
22/01/25 19:01:34.68 qx8rIKSM.net
ゆうてまあここはReactについて答えられないやつばっかだしな
口だけなのよみんな
156:デフォルトの名無しさん
22/01/25 19:17:30.98 EaWfnOTy.net
React使えば凄いもの作れるかといったらそうでもないし
そもそもそんな凄いインターフェースなんか求められていない
インターフェースなんかHTMLとCSSで作ればいいんだよね
HTMLとCSSは随分と高機能になったから
そこにちょっとjQueryで動きをつければ十分なことが多い
イラストレータやCADソフトみたいなものはReactみたいなものが
便利だと思うけど、普通の管理画面インターフェースとかだとjQueryで十分
157:デフォルトの名無しさん
22/01/25 19:26:48.23 FhpLBFKD.net
>>136
ボタンを押したら白くなる……がちょっと意味わからんけど
&:hover {
}
を用意すればいいって話だったりするのかな
158:デフォルトの名無しさん
22/01/25 19:31:01.82 LH8v1+14.net
>>153
上の方見ると詳しい人もいるし、単に余計な捨て台詞吐くから反感買ったんだと思う。
>>154
jQuery使うくらいならバニラの方が楽だな。
159:デフォルトの名無しさん
22/01/25 21:42:48.67 EaWfnOTy.net
jQueryはバニラと混ぜて使えます。
バニラよりも簡単にかけるところだけ
jQueryを使えばいいのでバニラが簡単というのは
理論的にありえません。
160:デフォルトの名無しさん
22/01/25 21:45:15.73 EaWfnOTy.net
>>155
> &:hover {
> }
>
> を用意すればいいって話だったりするのかな
ありそうな話だな。CSSが苦手なくせに
CSSを勉強しないから、無駄なJavScriptコードを書く人が多い
そういうやつに限ってCSSをけなして
使えない自分を擁護している
161:デフォルトの名無しさん
22/01/25 21:55:05.28 Gc3NttG8.net
はいはい。自分で立てたスレでやってね
162:デフォルトの名無しさん
22/01/25 21:56:02.66 EaWfnOTy.net
ここでやるよ
163:デフォルトの名無しさん
22/01/25 22:01:21.44 TQ9E9Mb0.net
CSSの勉強とかする奴いるの？
164:デフォルトの名無しさん
22/01/25 23:02:59.34 5lVpkzkK.net
管理画面や業務システム系にはReactがベスト
165:デフォルトの名無しさん
22/01/25 23:04:55.60 5lVpkzkK.net
フロントエンジニアなのにcss設計ができないならReact使う意味ない
166:デフォルトの名無しさん
22/01/25 23:19:08.31 LH8v1+14.net
>>162
わかる。fetch待ってあっちの状態を拾いつつこっちに同期して副作用見ながらElement差し替えて……とか考えずにサクッと組めてほんと楽
167:デフォルトの名無しさん
22/01/25 23:42:58.03 Vpk3TLE1.net
漏れは、CSS は分からない。
Ruby on Rails で、SASS・Bootstrap しか
168:知らない >>136 Railsでは、React, Bootstrap, Bulma, Tailwind が多い Material-UI, ElementUI は、あまり聞かない
169:デフォルトの名無しさん
22/01/26 00:10:14.89 WZ6d76Ox.net
最近のシングルページアプリケーション大嫌いだから早く廃れてほしいわ
170:デフォルトの名無しさん
22/01/26 06:29:00.55 HVcJWVLp.net
いちユーザとしての嗜好をここに書かれてもなぁ。
SPAなんて15年位前からあるわけだし、スレタイのライブラリやフレームワークはSPA以外も作れるし。
171:デフォルトの名無しさん
22/01/26 10:46:32.23 iN8tMMZ/.net
SPAがいいというか最初のロードで終わるから便利なのであって
今時ページ毎に読み込みとかダサいでしょｗ
172:デフォルトの名無しさん
22/01/26 11:25:39.57 qAyrcykq.net
ページごとに読み込んでくれた方がリセットされる安心感がある
あと遷移前のページとは基本的に切り離して考えて操作すればいいのねということがよくわかるからマルチページのほうが良いと思う
マルチページのほうがハイパーリンクやRPAとの相性もいい
これはあくまでユーザー目線になった時にどっち使いたいか？って考えたときにそう思うってだけね
開発者の目線だとSPAの方がアーキテクチャが綺麗に階層化されててメンテしやすく実装が簡単なのでいいと思う
173:デフォルトの名無しさん
22/01/26 11:26:22.51 MBxJE5i4.net
安心感w
174:デフォルトの名無しさん
22/01/26 11:29:29.66 bON6Y6/t.net
>>168
ダサいとかいうお前の主観で判断するなや
175:デフォルトの名無しさん
22/01/26 11:30:21.31 bON6Y6/t.net
>>169
マルチページだと、それそれが担当する範囲が分離されていて
複数の人が並行で開発しやすくなる
大規模システムに向いてる
176:デフォルトの名無しさん
22/01/26 11:31:05.53 bON6Y6/t.net
ユーザー目線になった時SPAは「マルチページであるかのように見せる」
ということを徹底しなければいけない
本末転倒ｗ
177:デフォルトの名無しさん
22/01/26 11:32:34.74 qAyrcykq.net
>>170
草生やしてるけど安心感ってめちゃくちゃ重要だと思うんだが？
特にエンドユーザーはITのことなんてよく知らんから安心感が何より大事
「あっ、これはよくある普通の素朴なホームページだ、これなら簡単に使えそうだ。ホッとするね」って思ってもらえたら勝ちよ
逆に「な、なんだこれは。ブラウザなのにまるで業務用のデスクトップツールみたいに複雑だぞ。ひえ～、動かし方が想像できない。う～ん、こりゃ困ったぞ」って思われたら負け
178:デフォルトの名無しさん
22/01/26 11:38:28.35 87bPqnWg.net
spaを何だと思ってるんだ？
twitterが複雑で使いづらいとか聞いたことないが
179:デフォルトの名無しさん
22/01/26 11:46:40.80 HVcJWVLp.net
ひょっとしてSPAだとルーティング出来ないと思ってるのでは？
180:デフォルトの名無しさん
22/01/26 11:53:28.56 xGOCvJmU.net
>>174
お、そうだなおじいちゃんw
181:デフォルトの名無しさん
22/01/26 11:55:32.37 Z2vFvGMM.net
>>175
一例だけで全体を押し測るのはどうかと思う
>>176
従来のページ遷移に見せかけてるだけであって別の概念
やっぱり全てリセットほどの安心感はないね
182:デフォルトの名無しさん
22/01/26 11:56:49.13 Z2vFvGMM.net
>>177
俺はまだおじいちゃんじゃないけど、世の中おじいちゃんおばあちゃん、おじさんおばさんがどんどん増えてるんだから、彼らに最適化したシステムを作るべきなんだよな
183:デフォルトの名無しさん
22/01/26 11:57:50.70 bZeln90B.net
>>174
それは見た目(デザイン)の問題であって
シングル/マルチとは関係なさそう
184:デフォルトの名無しさん
22/01/26 11:59:54.06 MBxJE5i4.net
IE使ってそうなおじいちゃんだなw
185:デフォルトの名無しさん
22/01/26 12:01:00.51 HVcJWVLp.net
>>178
概念が違っても見かけが同じなら気づかなくね？
186:例えば、ユーザーはTwitterのタイムラインとツイート単独画面を別のページだと思ってるでしょ
187:デフォルトの名無しさん
22/01/26 12:03:56.46 Q9+f1WtF.net
>>180
デザインの違いじゃなくてあの遷移するときのいったんリセットしてロードし直してる感が良いんだよ
あれがあるとすごく安心するんだ
188:デフォルトの名無しさん
22/01/26 12:04:33.05 Q9+f1WtF.net
>>181
Chrome、EDGE、時々Safari使ってる
189:デフォルトの名無しさん
22/01/26 12:10:01.72 Q9+f1WtF.net
>>182
気付いてはいるだろう
あれリロードされないぞって
190:デフォルトの名無しさん
22/01/26 12:16:09.14 HVcJWVLp.net
それ、ただの遅いサイトでは……。
じゃあロード画面でも表示しますか
191:デフォルトの名無しさん
22/01/26 12:16:30.19 uZbDoYzf.net
現代の大半の人間はYouTubeやTwitterとかLINEやTikTokとかのアプリを長い時間使ってるし、それらのアプリはSPAの動きするから現代の人間にとってはSPAの方が慣れていると思うぞ
ゆえにページ移動の度に画面が一瞬真っ白になるのって「なんやこれ？」ってなる
192:デフォルトの名無しさん
22/01/26 12:23:35.09 Q9+f1WtF.net
>>186
ロード画面はいいかもね
あとは上から徐々にレンダリングされていくあの感覚
あそこまで再現できれば安心感を演出できるかも
193:デフォルトの名無しさん
22/01/26 12:25:11.75 Q9+f1WtF.net
>>187
ないない
そんなのごく一部の例外だって
世の中のほとんどはまだSPAになってないし今後もならないだろう
ユーザーはよく使うマルチページのほうが親しみがある
194:デフォルトの名無しさん
22/01/26 12:28:05.87 HVcJWVLp.net
どこまでネタかわからん
195:デフォルトの名無しさん
22/01/26 12:28:56.83 Q9+f1WtF.net
あとね
SPAに慣れるってことは基本的にないんだ
SPAで作った特定のアプリに慣れることはある
だけどそれに慣れたとしても別のアプリには慣れない
だってSPAのアプリは個性的でそれぞれ違う動きをするから
これとは対照的にマルチページアプリはどれもウェブの作法を守ってるので異なるアプリでも共通点が多い
なのでマルチページアプリに慣れるってのは大いにあり得る
196:デフォルトの名無しさん
22/01/26 12:34:01.00 uLc6Vrba.net
慣れるも慣れないも時代によって使われる技術は変わるだろ
頭カッチコチの老人かよ
197:デフォルトの名無しさん
22/01/26 12:34:24.78 8nn+xAqB.net
視野が恐ろしく狭い
198:デフォルトの名無しさん
22/01/26 12:40:35.07 uZbDoYzf.net
>>189
スマホ持ってないの？
お年寄り用とか子ども用のスマホなら持ってる？
それならYouTubeとかTwitter使えないかもしれないけども
言うてもネイティブアプリってSPAになってるやつしか見たことないな
199:デフォルトの名無しさん
22/01/26 12:41:06.07 qAyrcykq.net
>>192
変わるものもあれば変わらないものもある
HTML、HTTPはず～～～っと昔からあってあまり変わってない
SPAの方が異端なんだよ明らかに
200:デフォルトの名無しさん
22/01/26 12:41:39.99 uLc6Vrba.net
親しみのあるガラケー使ってんだろ
201:デフォルトの名無しさん
22/01/26 12:42:31.75 xGOCvJmU.net
前にいたjqueryおじやろw
202:デフォルトの名無しさん
22/01/26 12:42:53.80 qAyrcykq.net
>>194
ネイティブの話はしてないよ
203:デフォルトの名無しさん
22/01/26 12:44:09.89 uLc6Vrba.net
>>195
HTMLもHTTPも時代に合わせて変わってるけど？
変わってないのはお前の頭だけな
204:デフォルトの名無しさん
22/01/26 12:47:38.52 qAyrcykq.net
>>196
流石にモバイルはとっくにスマホだよ
三輪車と自動車ぐらい差がつく物なら流石に自動車を選ぶ
それは当然の選択だろう
でもSPAとマルチページアプリってそこまで差がないと思うなー
普通の自転車とロードバイクぐらいの差かなー？
つうか差がないどころか使い勝手はマルチページアプリの方が良いとすら思ってるよ
自転車の例えで言うと「あのー速いのはわかったんですけど、ロードバイクのハンドル持ちにくいんでね。普通のハンドルにしてくれませんか？」みたいな感じ
205:デフォルトの名無しさん
22/01/26 12:48:21.26 qAyrcykq.net
>>199
あまり
206:、って言葉が見えなかった？
207:デフォルトの名無しさん
22/01/26 12:49:54.45 bON6Y6/t.net
>>175
> twitterが複雑で使いづらいとか聞いたことないが
え？スクロールした後、進むとか戻るで
スクロール位置がリセットされて使いづらいって聞いたこと無いの？
208:デフォルトの名無しさん
22/01/26 12:50:10.88 qAyrcykq.net
>>197
いや開発者の立場だったらreactおじさんだよw
ユーザー目線の使いやすさはともかく開発するだけならSPA途轍もなく簡単だからね
開発者なら楽な方を選ぶのが正解だ
209:デフォルトの名無しさん
22/01/26 12:50:45.25 bON6Y6/t.net
Googleの検索なら、ページがあるから
10件単位ぐらいで位置を覚えてくれるから便利
210:デフォルトの名無しさん
22/01/26 12:51:23.72 HVcJWVLp.net
個人の感想過ぎる
211:デフォルトの名無しさん
22/01/26 12:51:54.58 bON6Y6/t.net
不便でもそれに慣れてしまうと、不便だって気づかない良い例だな
212:デフォルトの名無しさん
22/01/26 12:53:39.85 uZbDoYzf.net
>>198
①アナリティクスとかアドセンス使ってればユーザーがアクセスしているデバイスが分かるけど、多くのWebサイトやWebアプリはスマホユーザーがめっちゃ多い
②スマホユーザーってのはYouTubeとかTwitterとかのLINEとかのネイティブアプリを長い時間かけて使っていると考えられる
③ネイティブアプリってのはほぼSPAな動きをするから、ネイティブアプリを長い時間使ってるユーザー＝SPAの挙動に慣れてる、と推測できる
よってWebサイトにせよWebアプリせよSPAの方が、スマホユーザーにとっては体験がいいんじゃないの、ってことよ
ただ、②のスマホユーザーが「ネイティブアプリ触ってる時間は1日の内わずかです、割合で言うとWebサイトを閲覧してる時間の方が多いです」ってなったら上の理論は成り立たないよ
213:デフォルトの名無しさん
22/01/26 12:53:51.96 qAyrcykq.net
>>206
SPAに慣れちゃったらそうなるのかなー？
214:デフォルトの名無しさん
22/01/26 12:56:24.92 qAyrcykq.net
>>207
さっきも言ったけどSPAに慣れるってことはないんだよ
共通の作法がないからアプリごとに固有の見た目と動きがある
なのでネイティブのアプリに慣れたとしてもそれでSPAに慣れたということにはならない
SPAの個々のアプリについてそれぞれ練習が必要で習熟には時間がかかる
215:デフォルトの名無しさん
22/01/26 12:58:31.67 qAyrcykq.net
>>207
続き
君が言ってることはつまりこういうこと
「YouTubeやLINEのネイティブのアプリに慣れたらVSCodeにも慣れたことになるよね」
そうはならんやろ？
216:デフォルトの名無しさん
22/01/26 12:58:49.67 bON6Y6/t.net
SPAでMPAの動作を苦労して作る
なら最初からMPAを使えば？
217:デフォルトの名無しさん
22/01/26 13:01:08.23 qAyrcykq.net
>>211
苦労したくないからSPAで作る
ユーザーには御免なさいだけど使いにくいものを使ってもらう
仕事だからね
信念とは違うこともやらんといかんのよ
218:デフォルトの名無しさん
22/01/26 13:01:30.33 MBxJE5i4.net
頭が固かったり、自分だけの意見を曲げられなくなってて意固地になったり、
長文だったり、連投したり、例えをしだしたり、
典型的な前時代のおっさんじゃんw
ずっとブラウザリロードしてろよw
219:デフォルトの名無しさん
22/01/26 13:03:09.96 nBTyT1HY.net
SPA大嫌いジジイを見てると、日本が何で発展しないかよく分かるわ
既存のやり方に固執して、変化する世界には目を背けて「今までこれでうまくやってきたからいいんだよ！」と開き直る
日本の中枢にいるやつらってこんなんばっかりだもんな
220:デフォルトの名無しさん
22/01/26 13:03:33.05 qAyrcykq.net
>>213
中身への言及がない時点でお察しのレス
221:デフォルトの名無しさん
22/01/26 13:04:07.74 MBxJE5i4.net
>>215
そういうとこw
222:デフォルトの名無しさん
22/01/26 13:06:20.85 111KcgMU.net
なんか最近やたらNuxtからNextに移行しましたみたいな人増えたけど、これただreact使いたいだけだよねえ
223:デフォルトの名無しさん
22/01/26 13:08:51.44 qAyrcykq.net
>>214
日本は世界でも有数の先進国だが？
国内にいると世界が見えないとよく言うがまさにそれだね
良いものは良いものとして長く使う
本当に良いものは取り入れて改良する
日本は今も昔もそうやって世界をリードしてきたんだよ
SPAだと開発が簡単なところは評価している
なのでうちもSPAを開発に取り入れている
発展はしているのだ
それがユーザーの利便性に繋がるかはまた別の話
全てはコスト・パフォーマンス
224:デフォルトの名無しさん
22/01/26 13:11:54.93 HVcJWVLp.net
jQueryおじさんと芸風が同じだな
225:デフォルトの名無しさん
22/01/26 13:12:25.00 bON6Y6/t.net
>>213
MPAはリンクをクリックした時にページが自動的にロードされる
わざわざブラウザをリロードなんかしない
そんなことも知らないのか？
226:デフォルトの名無しさん
22/01/26 13:31:42.79 MBxJE5i4.net
>>220
ん？ID:qAyrcykqと同じ人？
MPAがどうだなんて絡んだつもりないぞw
IEでjqueryおじがブラウザリロードしてそうだからw
227:デフォルトの名無しさん
22/01/26 13:44:37.41 27MgWQmu.net
4〜5年前からSPA前提の案件しかやならくなったけどなー
てかMPAで済むような案件安くて割りに合わなくない？
Nuxt使って開発中の機能プレビュー出来るようにしたら
客が気に入っちゃって毎回Nuxt指定で発注くるわw
228:デフォルトの名無しさん
22/01/26 13:54:40.62 MBxJE5i4.net
単価は分からんけどちょっとそこはなんとも言えない気もする
大規模ECのPC版サイトはいわゆるMPAが多い気もしていてそこが安いとも思えない
あと古い業務システム（の保守とか）はまだ多くて、人こないから高くなってそう
後者の会社の人にSPAバリバリのページ見せると目が輝くw導入はまた別の話だけどもw
229:デフォルトの名無しさん
22/01/26 14:32:09.32 6uX2dnfy.net
このおじさんに名前つけようぜ
230:デフォルトの名無しさん
22/01/26 14:36:23.23 SY+BWxpR.net
結局Reactが一番無難？
231:デフォルトの名無しさん
22/01/26 16:11:57.51 OSgOrRx4.net
またこいつ暴れてるのかよ
まあ好きにしろ
それでジョーカーを防げるなら安いものだ
232:デフォルトの名無しさん
22/01/26 17:07:36.34 111KcgMU.net
>>225
Reactがしっくりくるならreactでいいんじゃない
初学者が独学でフロントエンド学ぶってならユーザーフレンドリー強調してドキュメントとかに力入れてるvueでいいと思うけど
233:デフォルトの名無しさん
22/01/26 17:17:45.06 HVcJWVLp.net
表題のフレームワーク・ライブラリは全部ドキュメント充実してると思う。良い時代だ
234:デフォルトの名無しさん
22/01/26 18:21:10.66 WZ6d76Ox.net
なんか荒れてて草
235:デフォルトの名無しさん
22/01/26 22:43:34.74 22BwQ0lP.net
>>224
レガシーに縛られてるしかなりの石頭な上に自分から動くことももうできないみたいだから、化石とか？
236:デフォルトの名無しさん
22/01/27 04:10:57.05 Vqcphqwz.net
angularでプログレスバーの進捗率を操作してやってる良いサンプルコード無いですかね？
237:デフォルトの名無しさん
22/01/27 23:44:42.37 v/5cAqmG.net
ReduxやRecoilはコンポーネントの凝集度を上げ、疎結合とすることに意味があるのに
すぐバケツリレーの是非の話に置き換えて議論してるのを見かける
本質はそこじゃないだろって毎回思う
バケツリレーが辛いとか辛くないとかどうでもいいんよ
238:デフォルトの名無しさん
22/01/28 12:25:41.63 g6bFcMDa.net
コンポートがreduxやらrecoilといったインフラストラクチャに依存してたら嫌だな
疎結合を謳うならコンポートは純粋にして全ての副作用をpropsで渡すのが正解
239:デフォルトの名無しさん
22/01/28 13:08:31.65 bb5RMoJH.net
reduxとかは再描画抑えるってのが重要なのでは
240:デフォルトの名無しさん
22/01/28 13:34:23.09 nMKXYZ48.net
Hooksが当たり前になってから状態管理ライブラリそのものが必要なくなってきたけどね
241:デフォルトの名無しさん
22/01/28 13:45:11.84 YWAMkj5y.net
redux持ち上げてたやつ反省しろ
242:デフォルトの名無しさん
22/01/28 14:21:14.42 /PNsDlHJ.net
パフォーマンスに取り組もうとするとuseCallback地獄になってコードの見通しが最悪
依存性指定は間違えやすいのに間違えるとデバッグしにくいバグになって現れる
困ったものだ
243:デフォルトの名無しさん
22/01/29 07:46:05.80 PT9fjyp1.net
こういうパターンがあるのか。良さげ
コンポーネントをカスタムフックで提供する
URLﾘﾝｸ(engineering.linecorp.com)
244:デフォルトの名無しさん
22/01/29 08:42:38.68 Alu86MyQ.net
普通のカスタムフックに見えるけど
うちのにもuseが大量に転がってるぞ
カスタムフックだらけだ
245:デフォルトの名無しさん
22/01/29 08:55:48.59 PT9fjyp1.net
結構使われてるのか～
246:デフォルトの名無しさん
22/01/29 09:12:06.81 Alu86MyQ.net
>>240
関数が関数を帰す事をやってない人からみたら
目新しく見えるだけ
247:デフォルトの名無しさん
22/01/29 09:16:48.65 PT9fjyp1.net
>>241
いや、高階関数には親しんでるけど、カスタムhookには詳しくなくてね。
勉強になりました。ありがとう
248:デフォルトの名無しさん
22/01/29 09:17:07.12 7vtiEs09.net
ロジックと外観が密結合していてなんかもやもやするがこれが正解なのか？
249:デフォルトの名無しさん
22/01/29 09:20:42.85 Alu86MyQ.net
>>243
笑
フック入門としては分かりやすくて良いけど
250:デフォルトの名無しさん
22/01/29 09:43:05.22 7vtiEs09.net
renderは分けたほうがいいよ
const useChecks = (labels: string[]) => {
const [checkList, setCheckList] = useState(labels.map(x=>false));
const handleCheck = useCallback((index: number) => {
setCheckList((checks) => checks.map((c, i) => (i === index ? !c : c))) }, []);
return {
labels, checkList, onCheck: handleCheck,
isAllChecked: checkList.every(x=>x) }
const App = () => {
const checks = useChecks(["a", "b", "c"]);
return <div>
<Checks {...checks} />
<button disabled={!checks.isAllChecked}>next</button>
</div>
}
251:デフォルトの名無しさん
22/01/29 09:52:17.20 7vtiEs09.net
>>244
理解できるかどうかでなく良し悪しの問題な
フックは元々コンポートから状態・副作用を抽出するためのものなのにrender hookパターンじゃあ取り除けてないどころかさらに強固に結び付いてるじゃないか？
俺が書いたごく普通のフックなら完全に見た目と振る舞いが分離してるので再利用性が抜群に高く、デフォルトの動作を提供するのも簡単だろ
252:デフォルトの名無しさん
22/01/29 11:30:56.31 Alu86MyQ.net
抽出？
笑
253:デフォルトの名無しさん
22/01/29 11:39:03.04 BkpHeBcG.net
>>245
どちらかというと俺もそんな感じに書くな
選択肢や選択状態というデータと
チェックボックスという見栄えは
分離させておきたいかもってことで
254:デフォルトの名無しさん
22/01/29 14:54:58.79 +jFhk8/e.net
>>136
useStyleってv5ではあんま使わなくなった印象
255:デフォルトの名無しさん
22/01/29 15:13:12.86 +jFhk8/e.net
>>136
お前そもそもBootstrapすら使った事ないだろ
256:デフォルトの名無しさん
22/01/29 15:14:57.47 +jFhk8/e.net
>>235
useContex使うよりはrecoil使う方が楽だと思うけどなあ
257:デフォルトの名無しさん
22/01/29 19:12:41.17 xQSF1qR+.net
SuspenseってFlatListでどうやって使えばいいんだ？
258:デフォルトの名無しさん
22/01/29 21:25:26.99 864llvBj.net
Flatlistに組み込まれないと無理なんじゃねーかな
259:デフォルトの名無しさん
22/01/29 21:29:33.14 hu0dsptD.net
hooks、逆に混乱する要素増やしただけじゃん
260:デフォルトの名無しさん
22/01/29 21:43:32.60 xaAFpCmk.net
だよな
svelteの巻き返しあるかも
261:デフォルトの名無しさん
22/01/29 22:31:16.11 ZBsBaXWY.net
>>253
やっぱそうか
Microsoftが.netにasync awaitを導入した時みたいにライブラリ側も一気に対応してくれんと困るよね
そのあとサードパーティのライブラリも対応時間かかりそうだし
しばらくは混乱が続くのかなー
262:デフォルトの名無しさん
22/01/30 03:50:00.39 r2LSfyqT.net
ReactからSvelteに移行する人は元からReactでやる必要のない事をReactでやってた人だろうな
自称Reactヘビーユーザーとか言ってたのとかまさにそれ
263:デフォルトの名無しさん
22/01/30 11:11:15.26 tCzC1fsY.net
reactは場面場面で最適な書き方がガラッと違ってて統一感なくなるのがしっくりこない
非同期読み取り専用ならSuspense
入力系なら別の書き方、FlatListなら読み取りだけでもまた別の書き方、複合的な画面はカオス、みたいな
264:デフォルトの名無しさん
22/01/30 12:41:32.79 pNxj8sgR.net
それは何使っても一緒では？
さまざまなライブラリを組み合わせる都合上仕方ないことかと
265:デフォルトの名無しさん
22/01/30 12:53:14.17 LWsZFFBD.net
Reactのコードって
ゴミゴミしいんだよなーー
可読性に難がある
266:デフォルトの名無しさん
22/01/30 12:58:54.46 LRHiyQzP.net
Reactはデータ構造がスッキリするから全体としては見通しが良くなる
267:デフォルトの名無しさん
22/01/30 13:06:36.70 Yv8lfaOV.net
大規模サービスを構築するならReactの方が良いけど
ちょっとした画面表示くらいならVueのほうが書きやすいんよね結局
だから日本企業に合ってるのはVueなんよ
268:デフォルトの名無しさん
22/01/30 13:11:05.43 DgfUQ907.net
svelteのREPL SZVg viewBox animationのHTML部
{#each Array(4) as row, row}
がある。
javascriptでは解釈されるのに、typescriptではrow,rowの重複が問題になると警告が出る。
この回避方法って分かります？
269:デフォルトの名無しさん
22/01/30 14:01:02.68 ptxVZ4lJ.net
>>262
日本企業ディスりすぎだろw
270:デフォルトの名無しさん
22/01/30 19:25:52.18 ZU13Jy4b.net
>>262
ちょっとした画面だと思ってたものが壮大な画面になるのは日本企業あるある
yahooのトップページをみろ
いまだにあの古臭いデザインだぞ
271:デフォルトの名無しさん
22/01/30 19:56:11.11 BnqgoCwE.net
担当のお客さま複雑だと使ってもらえないって自分で言っときながら要件はめちゃくちゃ複雑なの出してくるんで呆れた
reactだと簡単に実装できちゃうから要件のんでそのまま作るけどMVCでシンプルな設計にした方がエンドユーザーは喜んだだろうな
272:デフォルトの名無しさん
22/01/30 20:12:24.88 F79hzdqm.net
ReactだろうがMVCだろうがエンドユーザーにはシンプルに使えるようにするのがお前の仕事だろ
273:デフォルトの名無しさん
22/01/30 20:36:25.75 Mi/4eGx6.net
そりゃ無理だね
複雑に使いにくく作るのがユーザー要件だから
274:デフォルトの名無しさん
22/01/30 20:54:46.23 F79hzdqm.net
そっか
じゃあ問題ない
275:デフォルトの名無しさん
22/01/31 02:25:23.43 27zEm3X2.net
そこでサードライブラリを入れないで使えるAngularですよ
誰がやってもフレームワークの書き方
276:デフォルトの名無しさん
22/01/31 02:44:02.27 kjCw75+R.net
何も考えたくないならangularだね
Googleで使われてるし少なくとも数年後に捨てることはまずないし
捨てたとしても移行ツールは用意されるはず
277:9
22/01/31 05:14:19.99 Ph6Okw9C.net
>>263
このスレは、荒らしが立てたスレです。
まともな人は、移動してください！
>>9-10
を参照
278:デフォルトの名無しさん
22/01/31 05:26:45.90 vLgC5D68.net
そのスレお前すら使ってないじゃん
先にお前が移動しろよ
279:デフォルトの名無しさん
22/01/31 06:59:29.82 f5fZPWiB.net
このスレになってから明らかに内容が良くなったし、あっち行く理由がない
280:デフォルトの名無しさん
22/01/31 20:04:14.52 ckOFtcve.net
>>233
使い回さないページ固有のコンポーネントにContainerやカスタムフックで分離して注入する
あと、propsですべてを渡すのは変更や修正に弱い
影響範囲なんて狭いに越したことはないだろ？
>>237
だから結局は小規模でもRedux(RTK)やRecoil使って上位で疎結合にしたら良い
下位は使い回すこと前提だから純粋な状態を保つようにする
281:デフォルトの名無しさん
22/01/31 20:21:33.23 FSK5xZBq.net
上位に副作用を集約して下位に流し込んでくだけ
特に変更に弱かった事例にもあたったことないな
これが変更に弱かったらreact以外の関数型も全部変更に弱いってことになる
282:デフォルトの名無しさん
22/02/01 10:33:40.98 GQYMskmN.net
URLﾘﾝｸ(engineering.linecorp.com)
↑
みなさまこれは読まれまして？
jおじが喜びそうな内容になっておりますわよ
283:デフォルトの名無しさん
22/02/01 11:01:39.02 EriX4J2e.net
簡易で軽いサイトほど低機能や低レベルなライブラリ、プラグイン等で事足りてるってことは普通じゃないか
284:デフォルトの名無しさん
22/02/01 12:08:16.92 oWcgNNz/.net
だから僕はPreact！
285:デフォルトの名無しさん
22/02/01 13:07:04.03 7mffSkDW.net
WebはMVCでいいじゃん
VSCodeのような複雑なブラウザアプリケーションを作るときだけSPAを使えばいい
SPAを使うこと自体が目的になってちゃダメだ
286:デフォルトの名無しさん
22/02/01 13:26:35.91 ibhv2tch.net
また何もわかってないゴミクソが吠えてるのか
287:デフォルトの名無しさん
22/02/01 14:52:45.60 0IOClaGB.net
ちょっと複雑なフォーム作ることになった時点でもうReact使った方が楽
288:デフォルトの名無しさん
22/02/01 15:49:19.28 6mdcUfy4.net
すまんが当社ではうちのフレームワークで作ってもらう規則なんだわ
物ができればいいってだけの10画面程度の小規模じゃないんだし好きにやってもらっちゃ困るよ
289:デフォルトの名無しさん
22/02/01 16:08:54.24 XW1MHiMg.net
>>283
ダメェ？
290:デフォルトの名無しさん
22/02/01 16:37:39.30 oWcgNNz/.net
>>283
うちのって言ってるあたり独自で不便で何なら遅いやつなんだろうな……
291:デフォルトの名無しさん
22/02/01 16:41:51.56 7wJjRtdC.net
なんかesbuild使うのがこれからの常識になるのかな
まだプラグイン周りが充実してないから
足りない部分自作しなきゃいけないのが辛い
292:デフォルトの名無しさん
22/02/01 18:34:14.71 pHWNICOb.net
このご時世にjQueryで金になる仕事なんてほとんど無いでしょ
293:デフォルトの名無しさん
22/02/01 19:59:39.42 J5v9RpnE.net
>>282
その時点でUX見直す方が楽
294:デフォルトの名無しさん
22/02/01 20:02:21.79 mlgA7CGA.net
う～んこの気配。おじさんの加齢臭を感じる
295:デフォルトの名無しさん
22/02/01 20:04:00.94 yOt4tsPX.net
いつでも見てるぞ
296:デフォルトの名無しさん
22/02/01 20:04:17.79 p8SdLc2x.net
エコシステム変わりすぎ多すぎ問題ははやく解決してほしいんだが
JS系のコミュニティって俺が俺がって感じで協調性ないから永遠に無理なんだろうな
297:デフォルトの名無しさん
22/02/01 20:13:22.91 oWcgNNz/.net
かと言って某言語みたく15年位ずっと同じフレームワークが第一線なのもそれはそれでちょっと……
298:デフォルトの名無しさん
22/02/01 20:19:05.28 p8SdLc2x.net
15年使われなくてメンテされてないのと
15年使われて磨かれてるのは全く別なのだがまあいいや
299:デフォルトの名無しさん
22/02/01 20:22:04.52 oWcgNNz/.net
それはそうだな。そういうニュアンスではなかったんだけど、すまんかった。
300:デフォルトの名無しさん
22/02/01 21:16:04.68 YoI1IuIQ.net
これ使っときゃテッパンっしょってのも楽っちゃ楽だよね
springとかmojoliciousとかlaravelとか
phpは必ずしもそうではないかもだが
301:デフォルトの名無しさん
22/02/01 21:36:15.98 VJwfpr2F.net
エンジニアリングをエンターテイメントとして捉えてるかどうかの違いかな
陽キャエンジニアにとってはそれを使って自分達がエキサイトできるかどうかが最も大事なこと
302:デフォルトの名無しさん
22/02/01 21:55:31.92 zbeL2VVW.net
モチベーションは開発における無視できない大きな要素って意味なら同意
303:デフォルトの名無しさん
22/02/02 00:12:35.92 mqKZfb5h.net
>>291
それを楽しめないと無理
最近だとまたviteというwebpackを置き換えるものが現れた
しかも作者はevan you
まさかのwebpackがオワコンになる可能性が
304:デフォルトの名無しさん
22/02/02 17:20:02.77 PSdK9kaF.net
日本でReact使ったまともなWebシステムがゼロなんだよなあ
海外はたくさんあるが
305:デフォルトの名無しさん
22/02/02 18:25:52.36 4K/CuUGk.net
大きなシステムになるともう共通部品とかは他で作ったものがあるからそれ使うべきってなるし、
大きなシステムは外からの個人事業主とかの派遣さんにも来てもらうことになるけど
個人とかのいわゆる派遣さんに求められるのは皆と同じものを作ることであるという事実からReactなんか求めないからなぁ
306:デフォルトの名無しさん
22/02/02 19:12:52.57 shmGW+AQ.net
>>299
好きだよね。海外はー、海外はーっていうのｗ
307:デフォルトの名無しさん
22/02/02 19:17:46.89 0QTWcy7E.net
Reactのコンポーネントって並べるだけなら楽なんだけどデザイン変更したり動作をカスタマイズしようとすると途端に難しくなる
オブジェクト指向でプライベート変数にアクセスしたくなったときに似てる
308:デフォルトの名無しさん
22/02/02 19:39:44.60 VFBcmn4C.net
逆じゃね？
並べるのは手間だけどカスタマイズや連携は楽
309:デフォルトの名無しさん
22/02/02 19:39:49.84 wjF+5Nwm.net
>>301
比較が海外しかないじゃん
好きとかの問題じゃない
>>300
他ってなんだ
オレオレフレームワーク？
>>302
日本のプログラマーはアホしかいないから難しいらしいよな
俺には難しい理由がわからん
310:デフォルトの名無しさん
22/02/02 19:52:19.45 4K/CuUGk.net
>>304
他っていうのは他の業務でだよ
何百画面もあるようなデカい仕事受けるような会社だけじゃなく
しょっぱいシステム屋とかでもたぶん流用がデフォやで
例えば文字を数値に変えて変えれないなら0を返すToIntegerとか
そういう共通関数群が大量にあるからそれ使ってもらうってのはそれなりの大きさの業務では基本やで
311:デフォルトの名無しさん
22/02/02 20:32:36.99 wjF+5Nwm.net
>>305
そんな共通ユーティリティみたいなことは言ってない
フレームワークレベルでコレ使えってなってるのか？
デカい仕事ってバックエンドがゴミ部屋のようにめちゃくちゃな管理してフロントはショボいっていう仕事だよな
312:デフォルトの名無しさん
22/02/02 20:56:20.06 F1Bh9Mbh.net
おじさん芸風変えたの？
313:デフォルトの名無しさん
22/02/02 20:56:23.20 shmGW+AQ.net
>>304
海外ってどこですかー？
北朝鮮も海外ですが？
具体的なことを知らんから
海外ってひとくくりにする
314:デフォルトの名無しさん
22/02/02 20:57:41.24
315:4K/CuUGk.net
316:デフォルトの名無しさん
22/02/02 21:05:19.17 wjF+5Nwm.net
>>309
ルックアップコンポーネントみたいな奴だな
で、このスレと何の関係があるんだ？
317:デフォルトの名無しさん
22/02/02 21:11:40.10 4K/CuUGk.net
ん？日本でReact使ったまともなWebシステムがゼロなんだよなあ
からの流れだよ
結局のところ全体のフレームワークとしてバックエンドにまで絡めて既存の資産を捨てるほど大きなプロジェクトでReact使うことでの価値は無いってだけで
小規模のホームページとかそういうのならぜんぜん使ってもいいんじゃないっていう話だよ
318:デフォルトの名無しさん
22/02/02 21:19:45.20 VFBcmn4C.net
まぁクソデカSSRシステムに組み込めとか言われたらそうなるかもしれん。でも今後は変わるんじゃね？
319:デフォルトの名無しさん
22/02/02 21:36:33.87 wjF+5Nwm.net
いやほんとまともにReactとかで規模の大きめのシステム作れるやつがまったくいない
日本のプログラマーがゴミクソばかりで世界一のIT後進国だからな
320:デフォルトの名無しさん
22/02/02 21:45:08.40 kAVlvH6X.net
webじゃないがSikiっていう専ブラはreactだったはず
321:デフォルトの名無しさん
22/02/02 21:53:49.27 FnKL8+UX.net
ここの連中集めればReact技能者は集まりそうだけど技術選定と設計ですげー揉めそうw
322:デフォルトの名無しさん
22/02/02 22:18:45.71 /mav0pKx.net
好きなフレームワークで1人1ページ担当してがっちゃんこしよーぜ！
323:デフォルトの名無しさん
22/02/02 22:37:51.13 4K/CuUGk.net
じゃあおれバックエンドをVBScriptでやるわ
おまえらフロントすきにしていいぞ
324:デフォルトの名無しさん
22/02/02 22:39:20.46 mqKZfb5h.net
>>317
ごちゃごちゃと障がい者みたいにつぶやいてないで
一回自分でやれ
325:デフォルトの名無しさん
22/02/02 22:58:02.85 U4FYar4x.net
じゃぼく「それjQueryで良くない？」って言う係
326:デフォルトの名無しさん
22/02/02 23:36:32.04 lahnM78W.net
技術選定だとReact、Nextjsを選んだ以上にCSSどうするかはかなり悩んだな。
結局CSS Modulesが最良と判断したが。
327:デフォルトの名無しさん
22/02/03 16:23:18.14 lgiX7Hgc.net
個人的にはUtility Firstなやつが楽かな
クラス名考えるの面倒だし
328:デフォルトの名無しさん
22/02/03 17:35:40.81 ebvxhmMF.net
いやもうnuxtで良くない？
329:デフォルトの名無しさん
22/02/03 18:48:10.96 6Dh6mPMN.net
今更vueって
330:デフォルトの名無しさん
22/02/03 19:47:20.12 7n8GI//Z.net
React/Next.js系がデファクトスタンダードだよな
331:デフォルトの名無しさん
22/02/03 20:28:23.89 Vl/Cta+D.net
>>324
それってデータあるんですか？
332:デフォルトの名無しさん
22/02/03 20:31:10.87 MXZ4rICE.net
wasmでdomが扱えるようになったらrustで書けるフロントエンドが流行るはず
たぶんrustで書けるreactがそのまま出てくるから結局react覇権になりそうだが
rustはtypescriptの利便性保ちつつより堅牢で高速だから欠点無い
333:デフォルトの名無しさん
22/02/03 20:34:08.26 Vl/Cta+D.net
マイナスが0になったら
流行るはずって思ってるやつ多いよな
LinuxでWindowsアプリが動いたら
流行るはずとかさ
334:デフォルトの名無しさん
22/02/03 20:43:12.09 MXZ4rICE.net
rust版reactとjs版reactの機能が同等になったら
新規プロジェクトでみんなrust版を選ぶようになるはずから
そうなったときがjs/tsの将来性が無くなる瞬間かもしれない
reactがrust版を出すんだったらvueとかsvelteもrust版出すはずで
結局今とフロントエンドライブラリの選定は変わらないのかな
335:デフォルトの名無しさん
22/02/03 20:48:01.47 Vl/Cta+D.net
rustの方が冗長なんだから、
そんなことにはならないって言ってるんだがｗ
336:デフォルトの名無しさん
22/02/03 20:48:33.70 Vl/Cta+D.net
なぜ劣る言語に変えると思うんだろうかね
337:デフォルトの名無しさん
22/02/03 21:19:21.75 6wgPHS5H.net
wasmからjsをバインディングしてdom操作すんの？
馬鹿じゃね？
338:デフォルトの名無しさん
22/02/03 21:45:39.19 H8+FjILX.net
Rustは素晴らしく洗練された言語だけど、それはそれとしてフロントを書きたいかと言われると、パフォーマンス上の問題が出ない限りそうは思わない。ライフタイムとhookを並行して思考したりしてると著しく生産性落ちそう
339:デフォルトの名無しさん
22/02/03 21:57:49.98 6VHScWxj.net
>>326
もうあるよ
dioxusのweb版
まんまreact
これはパラダイムシフトは確実な気がする
フロントエンドは面白くなるぞー
340:デフォルトの名無しさん
22/02/03 22:05:06.01 XqWYVslw.net
>>333
これか
URLﾘﾝｸ(dioxuslabs.com)
なんだこれは？
rustでフロントエンドしちゃってるよ
ヤバタニエン過ぎる
もしもだがdenoランタイムでこれができるようになったらマジでやべーぞ
341:デフォルトの名無しさん
22/02/03 22:11:48.24 H8+FjILX.net
>>334
別に（JSの立場は）ヤバくはないと思うけど、確かに面白いなこれ
342:デフォルトの名無しさん
22/02/03 22:12:16.95 P8bKJ2XT.net
よく分からんけどフロントをRustで書くメリットってなんかあるの？
343:デフォルトの名無しさん
22/02/03 22:17:40.45 XqWYVslw.net
>>336
今の所はなさそう
ただ数年後となるとわからない
344:デフォルトの名無しさん
22/02/03 22:30:20.41 NmvkwNbB.net
Rustってjsとかphpとかより低級言語よね
したらもうコード書けませんってエンジニア溢れそうだね
345:デフォルトの名無しさん
22/02/03 22:32:58.03 XqWYVslw.net
>>335
denoランタイムとの接続がキーポイントになると思う
denoから使えればtsと相互変換が可能になり
さらにdenoのv8 bindingを使って様々なメタプログラミングが可能になる
とんでもないことになるぞ
346:デフォルトの名無しさん
22/02/03 22:39:30.35 OJ3iv254.net
謎のdeno推し
347:デフォルトの名無しさん
22/02/03 22:44:37.55 LSqlUgGP.net
こんなんただのBlazorのフォロワーじゃん
348:デフォルトの名無しさん
22/02/04 00:52:08.94 RnDcYufQ.net
rustフロントエンドの選定スレがほしいな
349:デフォルトの名無しさん
22/02/04 01:31:33.73 53s+UEIz.net
なんでウェブでわざわざゲーム作ろうとするの？
作っても別にいいけど、
rustとかでゲーム以外作るわけ無いだろ
350:デフォルトの名無しさん
22/02/04 02:51:53.60 +vSJkZcg.net
wasmには期待してるけど
wasmが完成した時に覇権を握るのがrustかどうかは別の話
351:デフォルトの名無しさん
22/02/04 05:29:04.98 fFPBICL2.net
ちょっとした部分をrustで書くのはよくても本格的なやつはrustで書きたくないな
rust難しすぎる
352:デフォルトの名無しさん
22/02/04 07:09:02.77 TJijcGq5.net
>>341
設計としてReactに寄せてるし、C♯ランタイムまで入るBlazorとは明確に違うでしょ。
>>343
ゲーム要素ゼロじゃん。
Reactの3倍位の容量にはなるみたいだし、JSの立場を脅かす事は無いだろうけど、選択肢が増えるのは歓迎かな。
Rustたしかに難しいけど、TSで型パズルするのと難易度的には同じくらいに感じる。
353:デフォルトの名無しさん
22/02/04 07:31:25.17 BQuGIDqq.net
>>345
俺も最初そう思ってたけどオライリーのプログラミングrust第2版読んだらそんなに難しくなかったよ
これまで日本人作者の書いた本読んでいまいち理解できなかったけど
単に説明が下手すぎただけだったよう
354:デフォルトの名無しさん
22/02/04 07:40:26.56 AnkvGdl6.net
rust難しいって言ってる人って単にCSを理解してないだけな気がする
rustの仕様ってゼロコスト抽象化なのだからCSを理解してない状態で使えるわけないんだよね
355:デフォルトの名無しさん
22/02/04 08:21:16.73 TJijcGq5.net
難しいかどうかと使いたいかどうかはまた別問題じゃないかな
356:デフォルトの名無しさん
22/02/04 09:10:35.79 Smp2NQSE.net
rustはlodashのようなライブラリはあるのかな？
357:デフォルトの名無しさん
22/02/04 10:55:16.98 9ReE07B3.net
rustは実行時型情報はあるのか？
C++やTypeScriptみたいにコンパイル時と違う形のデータが入ってくるようなら使い物にならんが？
358:デフォルトの名無しさん
22/02/04 11:35:10.38 Q8cReFta.net
tsでwasmするのが正解
359:デフォルトの名無しさん
22/02/04 11:35:16.43 4uRUsxbH.net
静的かつ強い型付けなので実行時にはないしキャストもない
ていうかwasmはRustではないしRustがブラウザで実行される訳でもないので開発環境はTypeScriptでも他の言語でも全然構わない
360:デフォルトの名無しさん
22/02/04 11:36:32.22 TJijcGq5.net
TypeScriptで型が化けるのはバリーションできてない時だけ。
Rustで型が化けるのは余程変なコード書いた時だけ。
361:デフォルトの名無しさん
22/02/04 12:00:18.20 HXjUaEaN.net
Rustは未履修だが意図的に破壊しなければ型エラーが出ないと言う話だったら間違いなく今後はRustに置き換えが進むだろうね
Blazorがその地位に来るかと思ったがRustにしてやられたか
いやいやまだわからんか
速度と安全性を重視するときはRust
実行時型情報による高い安全性と開発コスパを重視するときはBlazor
老害懐古厨はJsTsって感じで棲み分けが進むかもしれん
362:デフォルトの名無しさん
22/02/04 12:08:13.07 TJijcGq5.net
Blazorおじさんまだ生きてたのか……。老害って言われて悔しかったんだね。強く生きてね。
363:デフォルトの名無しさん
22/02/04 12:11:44.09 HXjUaEaN.net
老害？それはJsTs厨のほうだろ
何十年前のポンコツ仕様でいつまで使い続けてるんだって話
JsTsはクソ仕様のオンパレードだから排除できるなら速やかにそうすべき
364:デフォルトの名無しさん
22/02/04 12:20:02.95 SayXLRD/.net
はいはい、ご苦労さん
365:デフォルトの名無しさん
22/02/04 12:44:19.41 DHy3OTYQ.net
Vue.js! Vue.js! Vue.js!
366:デフォルトの名無しさん
22/02/04 13:09:29.21 TJijcGq5.net
Rust勉強して良かったなと思うことの一つは、Promiseのcatchメソッドの有用性に気づけた事。fetchのResponseのjsonメソッドがPromiseなのもすげえ腑に落ちた。
367:デフォルトの名無しさん
22/02/04 14:42:39.19 BQuGIDqq.net
rustできないと落ちこぼれる時代
フロントエンドも大変なことになってきたな
死ぬ気で勉強しないとな
368:デフォルトの名無しさん
22/02/04 14:50:43.17 6pbPJPPX.net
SNSフォローしてるハイレベルなフロントエンジニアもrustはオプションでなく必須になりつつあるって考えて学習始めてたな
まあそれも結構前の出来事だけど
乗り遅れんようにせんとあかんね
JsTsにしがみついてたらこの先どうなることやら
369:デフォルトの名無しさん
22/02/04 14:59:54.77 KTKsC+8x.net
文章に癖があるからすぐわかるなぁ
370:デフォルトの名無しさん
22/02/04 15:05:23.64 LfvkydUx.net
コンポーネントは再利用性やテスタビリティにこだわらん方が実務レベルだと上手く行くようだ
純粋関数は理想ではあるがバケツリレーで脳のスタックを食い潰すのでよくないな
ライブラリ化する時が来たらじっくり考えよう
371:デフォルトの名無しさん
22/02/04 15:12:51.48 YwBxMIRS.net
rustやるならvacodeでいいの？
372:デフォルトの名無しさん
22/02/04 16:18:07.30 BQuGIDqq.net
rust使うメリットを薄っすら考えてたけどやはりあった
rust使えばフロントとバックエンドで真のisomorphicができるんだよな
このメリットはあまりにもでかいよ
サーバーサイドのエンジニアからしたらむしろrustがいいし
373:デフォルトの名無しさん
22/02/04 17:16:47.18 0C4OdyPC.net
フロントエンドの重たい処理をRustをWasmにして代替するってのはいいけどReactみたいなのを代替するとは思えない
374:デフォルトの名無しさん
22/02/04 17:25:44.41 UcZDSf
375:4b.net
376:デフォルトの名無しさん
22/02/04 17:29:47.06 M/Njut39.net
>>367
この人そう言うの分かんないんだよ
wasmがjsを代替するものだと勘違いしてるっぽい
wasmでのdom操作は遅いっての普通に考えたら理解できるはずなんだけど
377:デフォルトの名無しさん
22/02/04 17:33:21.11 UcZDSf4b.net
普通に考えたらDOM操作も今後高速化するとわかりそうなものだが…？
なぜwasmでのDOM操作が将来にわたってずっと遅いままだと確信してるのか逆に聞きたいぐらいだ
378:デフォルトの名無しさん
22/02/04 18:18:05.18 gXiY9Nvg.net
このおっさん、芸風変わんねぇな
379:デフォルトの名無しさん
22/02/04 18:25:48.22 rJLYpiyJ.net
C#おじさんにRustが使いこなせるとは到底思えん
380:デフォルトの名無しさん
22/02/04 18:36:16.21 AaYt2jqF.net
"ポンコツ"の大部分はDOM APIやブラウザAPIに由来するものであってwasmだから逃げれるものじゃない
他言語での使い勝手を良くしようとすると結局ランタイムデカくなってパフォーマンスに影響するし
381:デフォルトの名無しさん
22/02/04 18:38:45.89 YCcbq7KP.net
C++より簡単な言語なら問題ないよ
382:デフォルトの名無しさん
22/02/04 18:39:05.35 DxKU+JL2.net
一般ピーポーはjsでさえヒーヒー言ってんのにrustなんてキモオタ以外できるわけないだろ
383:デフォルトの名無しさん
22/02/04 18:50:23.93 C++bHSDs.net
wasmでdom操作が高速になればreactをwasmで実行するようになるだけじゃない
そうなればJS/TSで書いてwasmに書き出すだけでしょ
馬鹿じゃないのかなこの人
384:デフォルトの名無しさん
22/02/04 19:04:23.24 YCcbq7KP.net
>>373
DOMもブラウザAPIもクソなのはそうだが、それ以上にJS言語もクソ
なので、言語だけでも別の選択肢が生まれるのは素晴らしいこと
主要な言語のランタイムは同梱、キャッシュ、トリミング、対策の余地は十分にある
>>376
速度問題が解決したら、欠陥だらけのJSを積極的に使う理由がない
TSはJSよりマシってだけだから、これも使う理由なくなる
既存のライブラリはその通り、WASMをハブにして全ての言語から使えるようになる
JSの方が優位になるシチュエーションがあったとしても、そこだけJSで実装して別言語からインポートするって形になる
385:デフォルトの名無しさん
22/02/04 19:05:28.33 Kw3bx10X.net
なんだ、RubyやろうがこんどはRustにいったのか？w
386:デフォルトの名無しさん
22/02/04 19:21:53.51 WaQ4tboY.net
>>374
C++で生ポインタ使ってそう
387:デフォルトの名無しさん
22/02/04 19:28:09.68 YCcbq7KP.net
>>379
時と場合による
当たり前
388:デフォルトの名無しさん
22/02/04 19:35:41.10 MjhRzkm0.net
自分はRust使えないのにRust叩き棒にして自分が使えないフロント技術スレで妄想垂れ流して暴れるおじいさん。可愛そうな人
389:デフォルトの名無しさん
22/02/04 19:40:37.30 a0r3/Mhc.net
いるよな
いい加減なことしか言えない底の浅い人
390:デフォルトの名無しさん
22/02/04 19:44:17.15 WiWwfmg4.net
意見をぶつけあうのは結構なことだが人格攻撃をしたらその場で最底辺に落ちるので自分からはしないように心がけてる
391:デフォルトの名無しさん
22/02/04 19:47:07.68 Nf7lGIz+.net
>>377
速度問題が解決したrust
vs
最初から速度問題がないjs
rust使う意味ねーだろｗ
392:デフォルトの名無しさん
22/02/04 19:48:56.01 yJ0Rj
393:5uF.net
394:デフォルトの名無しさん
22/02/04 19:49:04.33 WiWwfmg4.net
>>384
速度が同じか負けてるなら他に優位性ないJSを使う理由がない
JSは"仕方なく使うもの"
395:デフォルトの名無しさん
22/02/04 19:50:17.04 WiWwfmg4.net
反論ができず人格攻撃も封じられたら確かに無視するしか選択肢がないのかも
396:デフォルトの名無しさん
22/02/04 19:51:06.61 yJ0Rj5uF.net
尻尾出すのはぇえ……
397:デフォルトの名無しさん
22/02/04 19:51:37.71 Nf7lGIz+.net
>>386
JavaScriptはウェブ技術に適した言語
398:デフォルトの名無しさん
22/02/04 19:53:18.50 Nf7lGIz+.net
自分が仕方なく使ってる、いや使えないのかｗからって
他の人も仕方なく使ってるって思い込むのは何なんだろうねｗ
rustなら、rustならって言ってるだけなんだよ
399:デフォルトの名無しさん
22/02/04 19:54:02.94 WiWwfmg4.net
>>389
それはブラウザベンダーが他言語を排除し続けてきた結果
それを撤廃したらどうなるかは容易に想像がつくだろう
JavaScriptでLinux実装できるか？
アップデートしていこうぜ！
400:デフォルトの名無しさん
22/02/04 19:57:09.55 WiWwfmg4.net
>>390
たしかにその通りだな
好きで使ってる人も中には居るだろう
401:デフォルトの名無しさん
22/02/04 19:57:49.14 AaYt2jqF.net
ウェブ屋がそれ言っちゃ終わりでしょ
今以上に混沌とした戦国時代に戻るだけ
402:デフォルトの名無しさん
22/02/04 19:59:21.55 Nf7lGIz+.net
rustに置き換えるよりも
JavaScriptを改良したほうが早いんだよなぁ
403:デフォルトの名無しさん
22/02/04 20:08:56.93 BQuGIDqq.net
フロントエンドエンジニア達の"焦り"は感じるね
rustもしくはGo書けるのがイケてるフロントエンドエンジニアの条件みたいになってるし
最近もvercelの人がtscをGoに移植したというブログ書いてた
もはやtsとreact書けるだけでイケてる扱いされる時代は終わったし
hooksの登場でコモディティ化が進んでその辺の素人でもreact書けるようになってしまった
そりゃ焦るよ
404:デフォルトの名無しさん
22/02/04 20:10:09.63 TJijcGq5.net
dioxusも別にJSや既存Webを置き換えようってものじゃないしねぇ
405:デフォルトの名無しさん
22/02/04 20:11:32.37 Nf7lGIz+.net
> rustもしくはGo書けるのがイケてるフロントエンドエンジニアの条件みたいになってるし
この間までCoffeeScriptだったぞ
そうイケてるというのは
イケてる雰囲気しかないのさね
406:デフォルトの名無しさん
22/02/04 20:12:01.17 Nf7lGIz+.net
そういやhaml？とかいうのもあったなぁ
407:デフォルトの名無しさん
22/02/04 20:14:18.25 BQuGIDqq.net
一方でもう一つのイケてる条件のフロントエンドdevopsだけど
こっちはこっちでk8sやdocker、ネットワークや分散処理のデザインパターンの知識などさらに幅広いインフラ力が求められる
もちろんフロントの人がこの領域をできるわけもない
408:デフォルトの名無しさん
22/02/04 20:18:03.07 BQuGIDqq.net
>>397
それ流行ったの5年以上前でしょ
下回りのツールに高速性が求められた結果rustとGoが必要になったのよ
フロントエンドdevopsという領域よ
時代は進化する
409:デフォルトの名無しさん
22/02/04 20:51:56.38 F4TRm9tu.net
すげー間違ってるじゃん。フロントdevツールの快適さの為のGoやRustであってフロントそのものの為じゃないんですけども
410:デフォルトの名無しさん
22/02/04 20:52:09.20 6JT6alO1.net
jQueryとかRustとか忙しないおじさんだな
そもそもここSPAスレだぞ
411:デフォルトの名無しさん
22/02/04 21:01:05.39 lN+66zOu.net
spaフレームワークに挫折したじじいが恨みつらみを垂れるスレだから
412:デフォルトの名無しさん
22/02/04 21:54:56.43 YlDtSICZ.net
Rustに興味はあるが本腰入れるとしたら、
まずCとかC++のシェア食いだして、それらに匹敵する位になってからかなぁ。
413:デフォルトの名無しさん
22/02/05 00:52:13.34 Ou/2xTbs.net
Rustのspaフレームワークスレたててやってろ
せめてスレタイのフレームワークと同じくらいのシェアになったらまた来ればいいよw
414:デフォルトの名無しさん
22/02/05 01:01:57.99 oefKcIWd.net
ここまで書いといて本人がrustを触っても無いのがお�
415:ﾎいポイント
416:デフォルトの名無しさん
22/02/05 06:57:41.45 5Q5TSOsH.net
しかも、話の発端のdioxusはReactの影響受けまくったライブラリで、Web屋がRust方面にも進みやすくなったって要素もあるのに、ソース読めないから（読んでないから）それに気づかないという
417:デフォルトの名無しさん
22/02/05 07:22:21.46 YlicbvMs.net
皆がrustを使用してweb開発をするなんて世界は来るとは思えんけど・・・
wasmが主流になったとしたらrustよりもassemblyscriptが流行る気がする
418:デフォルトの名無しさん
22/02/05 08:09:01.76 HidR246T.net
その辺は例えばwasmのGCが実装されるか頓挫するかでも大きく変わってくる
今からrust覇権とか.net覇権とか言われても将来の夢語ってるのと同じレベル
419:デフォルトの名無しさん
22/02/05 08:22:18.51 5Q5TSOsH.net
あんな奴のせいでRustのイメージが悪くなるのが辛い
420:デフォルトの名無しさん
22/02/05 08:51:04.62 HidR246T.net
rustは悪くないので安心して
URLﾘﾝｸ(www.publickey1.jp)
421:デフォルトの名無しさん
22/02/05 10:30:44.12 ez5HK1gV.net
いつまでもJavaScriptにしがみついて知識をアップデートするの拒んでちゃ仕事なくなるかもしれん
土日はrust勉強しよっと
422:デフォルトの名無しさん
22/02/05 10:32:07.32 rTFVZ3lx.net
はいはい
423:デフォルトの名無しさん
22/02/05 10:40:16.67 ez5HK1gV.net
>>411
すげーな
プロトタイプの段階で10倍～25倍も高速でメモリ消費もガクッと減るんだ
これはもう既に勝負見えたんじゃない？
チャリンコでレースしてるところにモーターカーが参戦するようなものだよね？
424:デフォルトの名無しさん
22/02/05 10:48:49.72 Yk9mrR51.net
なんでそうなんねん
425:デフォルトの名無しさん
22/02/05 10:50:14.63 9ZFgLhOl.net
いうほどwasmの方が速度出るシーンはない
JavaScriptだと速度が出ない場所を書き換えるだけ
426:デフォルトの名無しさん
22/02/05 11:05:11.61 ez5HK1gV.net
いつまでその楽観論を語れるか見ものだわ
427:デフォルトの名無しさん
22/02/05 11:26:03.89 3Et5qgRk.net
せめてシェア取ってからRustがどうの言ってくれ
スレタイ関係ないやろ、勝手にスレ立てて自分で普及して
428:デフォルトの名無しさん
22/02/05 11:43:34.83 BxzSu3Nl.net
一日ここでグダって勉強しないんですね、わかります
429:デフォルトの名無しさん
22/02/05 11:53:17.67 SJYMgDqv.net
「社長！rust使えます！」
「rustってなに？それより早くリリースしろ」
「」
430:デフォルトの名無しさん
22/02/05 11:54:13.25 BHjhYtcZ.net
Vue.js!vue.js!
431:デフォルトの名無しさん
22/02/05 12:23:18.94 4kv9IAdN.net
・wasmの高速化が進み適用範囲を問わずJavaScriptと同等かそれ以上になる☜時間の問題
・wasmを前提とした他言語のビルド最適化が進む☜時間の問題
・wasmを前提とした他言語のライブラリ、フレームワークの開発が進む☜時間の問題
rustは有力な候補だがrustになるかどうかはわからん
でも他の言語が台頭してくるのはもう避けようがない未来に思えるが？
いつまでもJavaScriptとReactの天下が続くと思ってる連中はちょっと楽観視しすぎじゃないですかねー？
正常性バイアスかかってないかじっくり考えてみるといいんじゃないかな
432:デフォルトの名無しさん
22/02/05 12:25:41.91 c17AURfn.net
絵空事語ってないで実際に案件が増えてきてから書き込めよ
433:デフォルトの名無しさん
22/02/05 12:27:33.96 1QTlOctu.net
議論したいならコテハン付けてくれ。ID変わり過ぎなんよ
434:デフォルトの名無しさん
22/02/05 12:42:08.00 1vBq/t05.net
異論はないかな？
435:デフォルトの名無しさん
22/02/05 13:10:47.31 rCDY/5gX.net
そうですね時間の問題ですね
なので時間になってからまた来てどうぞ
436:デフォルトの名無しさん
22/02/05 16:04:46.37 M9g6zC+X.net
rsxっていうJSXみたいにかけるマクロがあるのか
こりゃ凄い
しかもJSXみたいなトランスパイルせずにマクロでやってる
オシャレだ
437:デフォルトの名無しさん
22/02/05 16:23:41.61 Uw9UrpVu.net
マクロもトランスパイルみたいなもんだけどな。いや、JSXがマクロと言うべきか
438:デフォルトの名無しさん
22/02/05 17:06:46.26 M9g6zC+X.net
rustのマクロはASTインジェクションだから型の支援も得られるからだいぶ安全だよ
439:デフォルトの名無しさん
22/02/05 17:25:51.70 5Q5TSOsH.net
ASTインジェクションはBabelにもあるし、JSXも型情報扱えるよ
440:デフォルトの名無しさん
22/02/05 17:40:04.13 6UyuV0MG.net
型ヒントだろ？
ちょっと信頼性に欠けるかな
441:デフォルトの名無しさん
22/02/05 17:42:18.34 M9g6zC+X.net
rustを倒して追っておいで
フロントエンドエンジニアとして生きるなら
JSの手はいらん
必要なのはwasmのみ！
442:デフォルトの名無しさん
22/02/05 17:48:01.72 eZbTpHL4.net
ワッチョイつけてスレ建て直したほうが良いな
443:デフォルトの名無しさん
22/02/05 18:52:09.56 5Q5TSOsH.net
>>433
ワッチョイスレは既にあるから再利用かな
【ﾜｯﾁｮｲ有】Vue vs React vs Angular Part.5.5
ｽﾚﾘﾝｸ(tech板)
444:デフォルトの名無しさん
22/02/05 18:59:15.48 SJYMgDqv.net
ワッチョイって意味あんの？
445:デフォルトの名無しさん
22/02/05 19:07:05.33 qMuygQA0.net
意味あるぞ。
お前〇〇だろ！荒らすな！が
お前○○だな！荒らすな！に変わる
荒らしている相手を文面を読まなくても、ある程度的中させられる
446:デフォルトの名無しさん
22/02/05 19:07:32.79 FZ71u15X.net
IDより寿命が長いし変えにくいからNGしやすいよ
447:デフォルトの名無しさん
22/02/05 19:12:06.12 qMuygQA0.net
NGにするのって意味あんの？
448:デフォルトの名無しさん
22/02/05 19:22:19.87 5Q5TSOsH.net
荒らしが見えないのは快適だぞ
449:デフォルトの名無しさん
22/02/05 22:10:41.77 RF8U0Fb+.net
今のフロントエンド界隈は
react vs vueから、typescript vs rustの対立軸に変わってきたな
こういう賑わいは久しぶりじゃないか
450:デフォルトの名無しさん
22/02/05 22:44:11.21 zQC1Tig7.net
企業からすればwasm化すれば解析されづらくなるし
逆コンパイルすることを利用規約で禁止できるようになるのかな
だから企業は全部wasm化するのが当たり前になりそうじゃない？
451:デフォルトの名無しさん
22/02/05 22:50:07.75 V3JENpQi.net
wasmはバイナリだけど分類はプログラミング言語だぞ
さらに言えばwasmdecのようなc言語に変換するツールもあるしそんな簡単にはいかない
452:デフォルトの名無しさん
22/02/05 22:53:52.33 CuLJWGHk.net
荒らしに構うな
453:デフォルトの名無しさん
22/02/06 00:41:16.85 UpadUQRd.net
rust難しいという人に向けてrustのコツを教えるよ
社内の勉強会のネタなんだけどね
まずrustではほとんどのデータがスタック領域におかれる
スタック領域は関数を呼び出した時に確保される
ローカル変数の値もこのスタック領域に確保される
変数の代入はこのスタック領域の変数の場所へ値を書き込むことでデータのやり取りをすることになる
関数から戻る時スタック領域のデータは全て消え失せる
ローカル変数の領域も解放されるからGCが必要ない
まずこの理解が大前提
この動きは変数をクロージャなどでキャプチャしてしまえば永遠に生きるJSとは真逆なのだ
スタック領域のデータは何があっても関数が終わると消滅する
まずこの前提が違うことを意識しよう(続く)
454:デフォルトの名無しさん
22/02/06 00:51:59.86 ck6epuuD.net
死ねよキチガイジジイ
455:デフォルトの名無しさん
22/02/06 00:55:50.14 UpadUQRd.net
難所として上げられる所有権だがこれはプリミティブ型だとスタック上のローカル変数の領域に値がコピーされるだけ
これはJSと同じ
プリミティブ型以外のデータ(StringやVecなど)は代入元の変数が使えなくなるだけ
これが所有権の正体
なんのことはないデータ自体は何も移動してないのよ
データはただスタック領域に佇んでいる
そういう絵を思い浮かべることが大事
rustではデータは常に1人ぼっちなのだ
これをムーブセマンティクスと呼ぶがデータは何も移動していない
この名前をつけたやつ(C++の人たち)は反省しろ(続く)
456:デフォルトの名無しさん
22/02/06 00:58:01.33 pqH7h29b.net
>>444
たしかにヒープは遅いからなぁ～
457:デフォルトの名無しさん
22/02/06 01:08:05.17 UpadUQRd.net
>>447
とりあえず初心者はヒープとか使わなくていいと思うね
リファレンスだけ覚えりゃOK
ヒープが登場するとRcだとかRefCellの概念が出てきて
絶対に挫折するから
それよりもまず基本的なrustの機能を勉強すべき
基本的にヒープは使わずにやる、というのがrustの設計思想としても正しいと思う
とりあえずヒープは忘れる
458:デフォルトの名無しさん
22/02/06 01:44:14.81 nUMC3oJh.net
Rust厨うぜぇな。スレチにいい加減に気付け。
ここはJavascriptのフレームワークの長所・短所を話し合うスレだ。
459:デフォルトの名無しさん
22/02/06 02:02:51.89 iDV922kv.net
wasmはフレームワークを動かすための基盤になると考えれば話題の範疇だろう
純粋にフレームワークの話をしたいならそもそもJavaScriptの話題も禁止にすべきだ
でも実際はそうなってない
ならwasmの話題も可とすべきでは？
460:デフォルトの名無しさん
22/02/06 02:26:10.37 UpadUQRd.net
気持ちはわかるけどtsの型パズルの馬鹿馬鹿しさにそろそろ人類が気がつくころなんじゃないかと思ってる
そんなことに時間を使うくらいならrustで書いた方が遥かにストレスフリー
ちなみにtsはあくまでjsを余すことなく型付けできるようにしているからあのような型システムになっているわけで
理想的なものではないのよ
そういう意味ではassemblyscriptのほうが遥かに筋が良い
461:デフォルトの名無しさん
22/02/06 02:36:05.18 UpadUQRd.net
ただassemblyscriptはあまりにもプリミティブなんだよな
これならrustで書いた方がよくね？という感じでしょう
だから流行らない
まあこれはwasmがローレイヤー過ぎるのも原因
wasmがもう少し発展してコンパイラインフラストラクチャー的なツール群が増えれば状況は変わるのだろうけどね
どちらにしてもここ数年目まぐるしく流行は変わると思うからフロントエンドは面白いよ
462:デフォルトの名無しさん
22/02/06 06:21:24.67 s6RMLxsg.net
付け焼き刃知識の荒らしに構うな
463:デフォルトの名無しさん
22/02/06 14:01:56.99 CDb/upuN.net
ん？Javascriptを動かすフレームワークのスレというのなら
ASP.netMVCのフレームワーク語っていいのか？
464:デフォルトの名無しさん
22/02/06 16:16:37.66 dR0rLG41.net
さてここまでのまとめ
rustの変数はスタック領域に確保される
スタック領域は関数が呼び出されたタイミングで確保され
関数から戻るときに開放される
ローカル変数はスタック領域に確保される
つまりローカル変数は関数から戻るときに全て開放される
（GCがいらない理由）
ヒープ領域とは関数に関係なく確保されるメモリ領域のこと
データをヒープに確保することもできるが初心者には不必要なので
スタック領域のみ使うように意識する
CS勉強したことがある人は当たり前過ぎてなにを今更？と思うかもしれないが
この辺はちゃんとした大学のCS学科でないと習わないし
コンピュータアーキテクチャの教科書に全部載ってるけど
いまどきこの分野を独学する人も少なくなってきた（続く）
465:デフォルトの名無しさん
22/02/06 16:34:15.95 9s7o4Y86.net
あんたStringもVecも使わないでRust書くわけ？
466:デフォルトの名無しさん
22/02/06 16:40:07.33 dR0rLG41.net
所有権とは変数に代入したときの代入元の変数が無効になるということ
これを所有権の移動という
変数が無効になるだけで別にデータ自体は何も変わっていないし
移動もしていないのだがこれをムーブセマンティクスと呼ぶ
ちなみに関数呼び出しのときに変数を渡すとその変数の所有権が移動する
これがなぜかわからない人が多いが
関数呼び出しは呼び元の関数のローカル変数を呼び出された関数の
ローカル変数の領域にコピーするという処理が走る(これをCSでは値渡しと呼ぶ）
アーキテクチャによって渡し方は様々だが概念的には変数のコピー処理を行うのだ
このコピーが代入なので所有権が移動する
なので呼び出し元の変数が使えなくなる（続く）
467:デフォルトの名無しさん
22/02/06 16:59:14.87 dR0rLG41.net
>>456
君のその発言を見る限り理解していないようだ
VecそのものとVecが保持しているデータを区別して考えよう
Vecそのものはスタックに確保され
Vecが保持しているデータはヒープに確保される
468:デフォルトの名無しさん
22/02/06 17:02:08.38 dR0rLG41.net
なぜお前はそんなにスタックやらヒープやら所有権にこだわるのか？という人がいると思うが
この概念をきちんと理解していないと絶対にrustを書けるようにはならないから
469:デフォルトの名無しさん
22/02/06 17:03:59.43 CDb/upuN.net
というかさ、Rustなんかじゃなく、
Cという全ての言語の長の正統後継者であるC#こそが正しいといえるんじゃないか
Rustみたいなサンピンのことは知らんけど、
どうせポインタすら使えない程度の言語なんしょ
470:デフォルトの名無しさん
22/02/06 17:04:35.30 OsFqEGw4.net
そういうの語りたいならもっと適切なスレあるだろ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
ｽﾚﾘﾝｸ(tech板)
Rust part13
ｽﾚﾘﾝｸ(tech板)
471:デフォルトの名無しさん
22/02/06 17:21:58.45 Jv9jz309.net
30分調べればわかるような表面的な知識と曖昧なCS知識がキメラ合体したような酷い感想文だな
472:デフォルトの名無しさん
22/02/06 17:30:23.37 dR0rLG41.net
どうやらVecやStringがヒープに確保されると思っている人がいるようだ
確かにそう思いがちなのは理解できる
C/C++を書いたことがないとこの理解は難しいのだが
先取りになるが簡単に説明しておく
Vecの実態はstruct Vec<T>という構造体なのだ
URLﾘﾝｸ(doc.rust-lang.org)
Vec<T>はptr、len、capacityから構成される
ptrの先に実際のデータがallocateされこれはまさしくヒープに確保される
しかしptr、len、capacityはスタックに確保されるのだ
ptrのデータはrust側がよしなにやってくれるのでユーザーが気にする必要はない
理解できただろうか？
この構造体という入れモノとその中身を区別するという概念は非常に重要なのだ
473:デフォルトの名無しさん
22/02/06 17:47:00.20 dR0rLG41.net
ちなみにGoも同じようなものだが、スタックで確保された構造体の参照を
関数から返すと自動的にその領域をヒープに確保してくれるという機能がある
これがとんでもなく便利なのだ
GoがJSチックに書ける理由はこれ
VercelがなぜtscをrustではなくGoで移植したかなんとなく理解できたのではないか
474:デフォルトの名無しさん
22/02/06 18:01:10.54 fslw3BZl.net
C++のmoveコンストラクタがデフォルトみたいな感じなんだ？
安全かつ高効率なわけだね
475:デフォルトの名無しさん
22/02/06 18:13:58.06 dR0rLG41.net
>>465
rustのソース見たわけじゃないがほぼその理解でいいと思う
構造体のガワだけがコピーされて中身のデータはコピーしない
その代わり代入元の変数を使えなくすることで安全性を担保する
理想的なC++というべきか
476:デフォルトの名無しさん
22/02/06 18:26:06.53 cfXPTZCD.net
本スレで構ってもらえないからってここに来んなよ
ほんま陰キャってゴミだわ
477:デフォルトの名無しさん
22/02/06 18:34:07.31 dR0rLG41.net
俺の思いはフロントエンドエンジニアたちにrustを理解してもらうこと
そして日本のレベルを上げること
rustの人たちって翻訳のゴタゴタみればわかるけど
人間性に問題ある人が多いし完全に村になってて
勉強会に参加とかしにくいのよ
478:デフォルトの名無しさん
22/02/06 18:37:22.39 Z3do3DkZ.net
オンライン勉強会のある時代に参加しにくいとかww
Rust界隈でも鼻つまみ者なんですね。わかります。
479:デフォルトの名無しさん
22/02/06 18:40:20.96 dR0rLG41.net
少なくとも今のrust界隈がフロントエンジニアに歩み寄ることはないし
webにも興味がないだろう
掲示板で俺�
480:｢じめたいだけならいじめてもらっても結構だが 日本のレベルを上げることには必死だから
481:デフォルトの名無しさん
22/02/06 18:49:33.02 f9pVup8O.net
でもRust界隈もフロント界隈も君に興味ないよ
482:デフォルトの名無しさん
22/02/06 19:00:18.43 nrGDC2eu.net
Rust界隈やフロント界隈が興味がある人なんているのか？
そもそも"界隈"が興味を持つって日本語としておかしいんだが
483:デフォルトの名無しさん
22/02/06 19:16:50.54 FULcIoNE.net
Rustスレ立ててやればいいだろ
キモいけど
484:デフォルトの名無しさん
22/02/06 19:26:06.43 OsFqEGw4.net
>>470
とりあえずお前のプレゼン全く面白そうに聞こえないからそこから見つめ直す必要があると思うよ
次世代言語スレ一時期は結構賑わってたんだからそこを再燃させれればいいだけだと思うがな
話題のゾーニングができないのってプログラマとしてどうかと思うしRustのプログラマとしてスレ違いの話題を延々と語るとか所有権システム全く分かってないようなもんじゃね？