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/03/10(水) 19:38:51.19

>>399
アホすぎる

**デフォルトの名無しさん** · 2021/03/10(水) 19:40:59.28

人はそれを同期と呼ぶ

**デフォルトの名無しさん** · 2021/03/10(水) 20:08:18.94

>>399
それがasync awaitでしょ

**デフォルトの名無しさん** · 2021/03/10(水) 20:12:42.31

非同期だけど同期的に見せたいっていうのは
やっぱり同期的な方が人間にはわかりやすいってことなんだよな

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

そらそうよ。
並行して二つ仕事やるよか、一つづつこなす方が明らかに仕事の精度が高い。

**デフォルトの名無しさん** · 2021/03/10(水) 20:24:24.08

>>389
The history of threads http://www.faqs.org/faqs/os-research/part1/section-10.html
コピペ＆略

1965年にはBerkeley Timesharing Systemでと呼んでいた。しかしそれまでに並行性の概念
がなかったのではなく、当時は「プロセス」と呼ばれていた。

1970年にMax SmithがMultics上でスレッドのプロトタイプを作っていて、これは1つの重量
プロセスに複数のスタックを持たせる試みだった。
プログラミング言語における「スレッド」の創始者はおそらくIBMによるPL/I(1965〜)
TASKコールはプロセスにマップされないし、スレッド間どうしはメモリが丸見え。

そしてUnixが出現する。Unixは「プロセス」という言葉を「スレッド＋仮想アドレス空間」の
意味に使った。そういうわけで、Unix的な意味での「プロセス」は仮想アドレス空間の切り替え
を伴う重たいものになってしまった。プロセスはそれぞれが個別にアドレス空間を持ってるから
メモリを共有することはできないがパイプやシグナルを使って相互作用することはできた。共有
メモリの機能が追加されるのはもっと後の話。

**デフォルトの名無しさん** · 2021/03/10(水) 20:29:47.08

>>405
つづき

しばらくすると、Unixユーザーは、メモリを共有できる古いプロセスを懐かしむようになりました。
これがスレッドの「発明」につながった。つまり、1つのUnixプロセスのアドレス空間を共有する
古いスタイルのプロセスである。重い」Unixプロセスとは対照的に、「軽い」とも呼ばれていました。
この区別は、70年代後半から80年代前半、つまり最初の「マイクロカーネル」
（Thoth（V-kernelとQNXの前身）、Amoeba、Chorus、RIG-Accent-Machファミリーなど）にまでさかのぼります。

**デフォルトの名無しさん** · 2021/03/10(水) 20:30:26.48

UNIX屋はスレッドは後からメモリを共有できる改良版として作られたものと考えるが、元々は
時分割処理をするシステムの発想があったから、貴重な計算リソースを時分割するだけのOSが
最初です。これがユーザー側で使えるようになった段階をスレッドと呼びたいならそうしたら
ええですが、伝えたいことは以上です

**その1** · 2021/03/10(水) 20:32:13.92

全部最初から訳したほうが良さそうｗ

[93-04-21-13-32.11] [92-01-27-17-05.54] 逐次的な制御の流れとしてのスレッドの概念は、
少なくとも1965年のBerkeley Timesharing Systemにさかのぼります。
ただ、当時はスレッドとは呼ばれておらずプロセスと呼ばれていました[Dijkstra, 65]。
プロセスは共有変数、セマフォ、および同様の手段によって相互に作用しました。
マックス・スミスは1970年頃、Multics上でスレッド実装のプロトタイプを作っていました。
アックグラウンドコンパイルをサポートしていました。

**その2** · 2021/03/10(水) 20:32:59.92

スレッドの最も重要な祖先は、1965年頃に開発されたプログラミング言語 1965年頃に開発されたプログラミング言語「PL/I」です。
IBMが定義したこの言語は IBMによって定義されたこの言語は、`CALL XXX (A, B) TASK;' という構文を提供していました。
これはXXXのスレッドをフォークするものです。 IBMのコンパイラがこの機能を実装していたかどうかは
定かではありませんがこの機能が実装されていたかどうかは定かではありませんが Multicsが設計されている間、
この機能は綿密に検討されました。定義されたTASKコールはプロセスにマッピングされませんでした。
定義されたTASKコールはプロセスに対応できないと判断されました。そこで、Multicsは別の方向へ
TASK機能はIBMによってPL/Iから削除されました。ABNORMAL属性やその他多くの奇妙なものと一緒にね。

**その3** · 2021/03/10(水) 20:34:15.57

その後、1970年代初頭にUnixが登場しました。 Unixの「プロセス」の概念は、制御のシーケンシャルなスレッドに加えて、
仮想アドレス空間を持つようになりました（ちなみに、Unixのプロセスの概念は、Multicsのプロセス設計[Saltzer, 66]から直接派生したものです）。
ですから、Unixの意味での「プロセス」は非常にヘビー級のマシンです。プロセスはメモリを共有できないので
（それぞれが独自のアドレス空間を持っている）、パイプやシグナルなどを通じて相互に作用します。
共有メモリ（これもかなり厄介なメカニズムです）はずっと後になって追加されました。

**その4** · 2021/03/10(水) 20:34:40.54

しばらくすると、Unixユーザーは、メモリを共有できる古いプロセスを懐かしむようになりました。
これがスレッドの「発明」につながった。つまり、1つのUnixプロセスのアドレス空間を共有する
古いスタイルのプロセスである。重い」Unixプロセスとは対照的に、「軽い」とも呼ばれていました。
この区別は、70年代後半から80年代前半、つまり最初の「マイクロカーネル」
（Thoth（V-kernelとQNXの前身）、Amoeba、Chorus、RIG-Accent-Machファミリーなど）にまでさかのぼります。

**デフォルトの名無しさん** · 2021/03/10(水) 20:35:30.03

>>407
> 元々は時分割処理をするシステムの発想があったから、
どこを見ていってますか？

**デフォルトの名無しさん** · 2021/03/10(水) 20:37:34.33

>>412
「スレッド」の創始者はおそらくIBMによるPL/I(1965〜)

**デフォルトの名無しさん** · 2021/03/10(水) 20:38:02.21

時分割処理をするシステムの発想があったがそれはスレッドと呼ばれておらず
プロセスと呼ばれていたそうです。

じゃあスレッドじゃなくてプロセスですよね

**デフォルトの名無しさん** · 2021/03/10(水) 20:39:13.88

>>413
それはスレッドと呼ばれておらず、実装もされなかったんですよね？

**デフォルトの名無しさん** · 2021/03/10(水) 20:39:27.40

そうしたいならそうすればええやん？UNIX屋はこれだから嫌だ、しつこい
そもそも別メモリアドレスに別処理を貼り付けるだけの処理で、メモリ共有が先という発想がおかしい
以上です。

**デフォルトの名無しさん** · 2021/03/10(水) 20:41:20.00

重要なのはここですね。

> しばらくすると、Unixユーザーは、メモリを共有できる古いプロセスを懐かしむようになりました。
> これがスレッドの「発明」につながった。つまり、1つのUnixプロセスのアドレス空間を共有する

メモリを共有できる古いやつ＝プロセス
スレッドの発明

**デフォルトの名無しさん** · 2021/03/10(水) 20:42:00.70

>>416
「メモリを共有できる古い”プロセス”」がどうかしたのでしょうか？

**デフォルトの名無しさん** · 2021/03/10(水) 20:47:21.16

この文章の主張は

1. 古いプロセスはメモリが共有されていた
2. でもメモリが共有されていたのだからスレッドの祖先だ
3. つまり、メモリの共有の有無が、プロセスとスレッドの違いである

という結論になりませんか？

**デフォルトの名無しさん** · 2021/03/10(水) 20:49:46.65

スレチはやめろっての

**デフォルトの名無しさん** · 2021/03/10(水) 20:51:45.16

スレッドを発明したのは、あわしろ氏の可能性もあるような気がするのだが。

**デフォルトの名無しさん** · 2021/03/10(水) 21:00:21.73

なんでそんな基礎レベルのとこをドヤ顔ではっぴょうかいしてんだか……

**デフォルトの名無しさん** · 2021/03/10(水) 21:04:56.19

Vueはなぜいかんのか
役割分担がしっかりしてて完璧にみえる

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

俺はvue好きだよ
仕事ではangularメインだが

**デフォルトの名無しさん** · 2021/03/12(金) 00:43:19.04

過去に３回ほどVueのプロジェクトやったけど、途中参加でもある程度作ってあって
画面追加するぐらいなら、他の画面の作りを見て大抵の人は出来てたので
理解のしやすさはかなり高いかと思う

何も無い所から作れというのは大変だろうけどね

**デフォルトの名無しさん** · 2021/03/12(金) 16:50:44.75

ある程度の規模まではvueがよくて規模が大きくなるとreactがいいとは聞くものの、具体的にどういいのか悪いのかのはっきりした答えを今まで聞いたことがない
みんな説明できずにモヤっとしかわからんの？

**デフォルトの名無しさん** · 2021/03/12(金) 17:25:11.02

Reactしか使ってないからなぁ。
でも大規模に向いてるのはわかる。状態をあんまり持たないし、疎結合にしやすいかんね

**デフォルトの名無しさん** · 2021/03/12(金) 17:43:30.08

俺も規模小さくてもわざわざvueに手は伸びないなｗ
ちょっとしたものならバニラjs
それ以上は全部reactだわ

**デフォルトの名無しさん** · 2021/03/12(金) 18:38:38.45

TypeScriptには生きて欲しいけど、Angularまじ死んで欲しい、誰得だよ

**デフォルトの名無しさん** · 2021/03/12(金) 19:19:12.20

HTMLのscriptタグの中で
require使えますか？
htmlからreactコードをどうやって読み込めばいいでしょうか？

**デフォルトの名無しさん** · 2021/03/12(金) 19:28:02.79

今ならscriptタグにmodule属性付けてimport使った方が楽なのでは？ボブは訝しんだ

**デフォルトの名無しさん** · 2021/03/12(金) 19:30:01.84

ごめん下の行読んでなかった。
公式チュートリアルに書いてあるよ。

**デフォルトの名無しさん** · 2021/03/12(金) 19:58:59.60

すっかり慣れちゃったから忘れてたけど、WebpackとReact覚えるのは初心者にはハードル高いな。場合によってはnpmも同時進行。
かといってcreate-react-appだと、普通運転免許も持ってないのにいきなり重機のハンドル握ってるみたいな感じで戸惑うし

**デフォルトの名無しさん** · 2021/03/12(金) 21:11:12.82

まあ初心者はバンドルとかは特にしなくてもいいでしょ
その辺でハマるのは目に見えてる

**デフォルトの名無しさん** · 2021/03/12(金) 21:24:59.62

webpackまわりはマジでどうにかしてシンプルにして欲しい

**デフォルトの名無しさん** · 2021/03/12(金) 22:18:41.64

webpakeから解放されたのがdeno
denoやってるやついる？

**デフォルトの名無しさん** · 2021/03/12(金) 22:25:06.87

今はLaravelを利用しているのでLaravel Mixで割と簡単に設定は書いている
フロントはVueを使ってる

Denoみたいに簡単に出来るようになれば良いのだけどもうちょっと様子見かな

**デフォルトの名無しさん** · 2021/03/12(金) 22:28:03.21

koaが流行らなかったのと同じ流れになりそう

**デフォルトの名無しさん** · 2021/03/13(土) 03:55:54.07

Ruby on Rails 6 の、Asset Pipeline では、
JavaScript は、Node.js, yarn, webpack がデフォルト

ただし、CSS は、Sprockets のまま。
webpack だと遅いから

**デフォルトの名無しさん** · 2021/03/13(土) 19:11:15.82

アコーディオンとかバーガーメニューとか
折りたたみ式のUI考えたやつ全般に殺意が湧く

**デフォルトの名無しさん** · 2021/03/13(土) 19:26:12.48

ゲームアプリみたいにXボタンを押したら
メニューが開くとかにしてほしかったんか？

**デフォルトの名無しさん** · 2021/03/14(日) 11:56:38.42

Reactで業務アプリをフロント1人で開発できる奴ってどのくらいいる？
大企業レベルのシステム
あらゆるシステムがAPI連携されつつデータをReactで管理してそれらが全て権限毎にcrudできるくらい

**デフォルトの名無しさん** · 2021/03/14(日) 11:57:31.87

他部署のエンジニアやインフラ・バックエンドエンジニアは含まない

**デフォルトの名無しさん** · 2021/03/14(日) 12:04:33.97

そんなん規模と要件次第だし、イントラ内かそれ以外かで全然……
と思ったらバックエンドは全部やってくれるのか、それならう～んどうなんでしょ

**デフォルトの名無しさん** · 2021/03/14(日) 12:50:12.53

Ruby on Rails, Bootstrap, React の方が、はるかに簡単だろ。
サーバーからHTML を返すから

これらをすべて、JavaScript で作ると思うと、ゾッとする

**デフォルトの名無しさん** · 2021/03/14(日) 13:15:40.25

>>444
規模が小さくても大きくてもやることは少ないか多いかの違い
ただGoogleAnalyticsみたいな独特なUIだときついかも？

**デフォルトの名無しさん** · 2021/03/14(日) 13:30:26.32

規模に合わせて納期がそのぶん伸びるならある程度の技術力があれば可能では？
業務アプリなら単一ページってわけにも行かないだろうし、React単体だとルーティングが面倒なので俺ならNext.jsとか使うけど

**デフォルトの名無しさん** · 2021/03/14(日) 13:56:01.15

要件がしっかりしてるなら、とか
複雑なスタイルが必要、とか
そういうのがなければいけるかもだけど、
大規模で１人てのが何かあったときに4ぬ

**デフォルトの名無しさん** · 2021/03/14(日) 15:12:49.26

>>447
単一ページではないからnext使ってもよいかな
さすがに素のReactだと厳しいからライブラリは使うけれども

>>448
提案してみたがReactできる人材がいなくてね

**デフォルトの名無しさん** · 2021/03/14(日) 22:35:33.91

>要件がしっかりしてるなら、とか
そんなプロジェクト見たことないわ

**デフォルトの名無しさん** · 2021/03/15(月) 00:44:00.58

>>447
ルーティングが面倒？？

**デフォルトの名無しさん** · 2021/03/15(月) 04:21:21.59

マジで今のフロントエンドは空き巣だと思う
サーバーサイドの人は今更フロントに来たがらないし
これまでフロントの人はReactとか触れるレベルの人が少ない
仕事多すぎて過労死するわ

**デフォルトの名無しさん** · 2021/03/15(月) 06:27:13.58

>>451
React Routerで頑張るのがめんどい。かといって1ページずつベタ書きはしたくない。読み込むデータも重複を避けて節約したい。
のでNext.jsでサクッとやりたい

**デフォルトの名無しさん** · 2021/03/15(月) 06:44:09.51

>>452
そうなの？勉強会とか見てる感じ、Reactと色々組み合わせてバリバリやってます～みたいな奴多くて、フロント専心だとReactできて当たりになりつつあるかと思ってた。
生DOMとJavaScriptを使いこなせていれば、React覚えるのなんてそれほどの苦じゃないと思うんだけどなぁ。

**デフォルトの名無しさん** · 2021/03/15(月) 07:37:14.65

>>454
そういう技術的なとこだけやってりゃいいって分野でもないだろ。
フロントはめちゃくちゃな要望言ってくるユーザーばっかな印象がある。

**デフォルトの名無しさん** · 2021/03/15(月) 07:54:10.63

>>455
452の言うこれまでのフロントの人は当然今までそれをこなしてきていると思うが。

**デフォルトの名無しさん** · 2021/03/15(月) 07:59:21.15

>>455
それはそうかもだけど。
それはフロントの顧客対応の話であって、技術であるReactは別の次元の話では？

**デフォルトの名無しさん** · 2021/03/15(月) 09:36:56.30

フロントでReactガッツリできる人はほとんどいないよな。
できるといって実際にはアプリ開発できない。

プログラミングできる＝アプリ開発ができる

わけではない。

**デフォルトの名無しさん** · 2021/03/15(月) 10:35:58.33

Next.jsはルーティング周りとかもろもろ親切過ぎて、アレから入ると基本的なところの理解が疎かになりそうな予感がする

**デフォルトの名無しさん** · 2021/03/15(月) 12:29:28.12

Next.jsはReact知ってる使ってる人が使うものだからあれで良いんじゃないかな。
React知らないならSvelteとか行く……と思うんだけど、いきなりNext.jsって人もいるの？

**デフォルトの名無しさん** · 2021/03/16(火) 08:24:55.46

reactのみで作ったあと
nextを知って
全部作り直したくなった思い出

**デフォルトの名無しさん** · 2021/03/16(火) 09:13:49.15

nextはssg使わないのならvercel使わなくていいの？
vercel使うとベンダーロックしそうで怖い

**デフォルトの名無しさん** · 2021/03/16(火) 10:24:27.59

Vercel使わなくてもSSG使えるよ。
画像最適化をSSGで使いたい場合はVercelなりCDNの利用が必要になるみたい

**デフォルトの名無しさん** · 2021/03/16(火) 13:45:05.91

なるほど！

**デフォルトの名無しさん** · 2021/03/17(水) 12:13:50.44

DOMとJavaScriptに精通しててReact使ってウェブアプリ作れるレベルならブルーオーシャンなの？

**デフォルトの名無しさん** · 2021/03/17(水) 13:02:08.38

はい
React使えますってだけで即採用の会社は多い
それほど難しい概念なのよ
ついでにサーバーサイドもできますってなったら年収1000万以上は確実か

**デフォルトの名無しさん** · 2021/03/17(水) 16:44:16.51

ははは、ご冗談を。
そんな条件鯖立ててWeb技術勉強してれば普通に満たせるやんけ

**デフォルトの名無しさん** · 2021/03/17(水) 16:53:53.04

Reactできる＝アプリ作れる
なわけない

プログラミングできる奴が全員アプリ作れるのか？

**デフォルトの名無しさん** · 2021/03/17(水) 17:32:19.45

Reactできる=Reactでアプリ作れるのつもりだが？
そんなのは当たり前だろ
アプリ作れないのにReactできるってなんだよそれは
嘘つきだろ

**デフォルトの名無しさん** · 2021/03/17(水) 17:59:21.26

アプリ作る以外にReactの勉強する方法を思いつかない

**デフォルトの名無しさん** · 2021/03/17(水) 23:44:18.65

>>468
ちょっと何言ってるか分からない

**デフォルトの名無しさん** · 2021/03/18(木) 12:50:28.19

reactできるもアプリ作れるも意味が広すぎるわ

**デフォルトの名無しさん** · 2021/03/18(木) 13:56:43.39

つまりツイッターやfacebookみたいなものちょい劣化版を一人で開発できるレベルがアプリ開発できるという

できるんだよな？

**デフォルトの名無しさん** · 2021/03/18(木) 14:06:15.16

時間は相応にかかるとして、まあできるだろうな

**デフォルトの名無しさん** · 2021/03/18(木) 14:10:20.37

まあ色んな前提を抜きにすりゃあなあ

**デフォルトの名無しさん** · 2021/03/18(木) 18:50:07.86

フロントは作れるけど、ああいう数千万ユーザの同時アクセスに耐える技術とか、ユーザを集める技術とかは無いです

**デフォルトの名無しさん** · 2021/03/19(金) 14:50:04.74

そりゃあreactはフロントサイドのフレームワークなんだし当たり前よな

**デフォルトの名無しさん** · 2021/03/19(金) 16:14:32.61

component.vueで「なんでこの変数undefinedなんだよ！」って小一時間やってたら、
途中で変数に$付けてるのに気付いた
消したら動いたのでコーヒー飲んでパソコンを落とした

**デフォルトの名無しさん** · 2021/03/19(金) 17:04:17.77

ガシャーン

**デフォルトの名無しさん** · 2021/03/19(金) 19:12:48.32

svelte触ってみた
意外と良いのか？
ReactとVueを同時に触っているような不思議な感覚

**デフォルトの名無しさん** · 2021/03/19(金) 19:15:55.21

大規模開発にはやはりreduxが一番なの？

**デフォルトの名無しさん** · 2021/03/19(金) 22:21:02.77

hooksでよか

**デフォルトの名無しさん** · 2021/03/19(金) 22:47:25.39

Next.jsのWebAPI機能って使ってる？
バリデーション無いのが嫌だからついついFastify使っちゃうけど、なんか良いやり方あんのかな？

**デフォルトの名無しさん** · 2021/03/20(土) 01:24:05.09

redux hooks便利だよな

**デフォルトの名無しさん** · 2021/03/20(土) 16:06:22.47

SSRをやりたい、かつVercel使いたくない場合はNextjsよりNuxtjsの方がいいんすかね？

**デフォルトの名無しさん** · 2021/03/20(土) 17:49:00.66

Naxtjs一択

**デフォルトの名無しさん** · 2021/03/20(土) 17:57:26.38

Nixtjs一択

**デフォルトの名無しさん** · 2021/03/20(土) 18:35:13.44

NextかNuxtかはVercel云々よりReactかVueかで選ぶものかと。Nodeさえ動けば動くし

**デフォルトの名無しさん** · 2021/03/20(土) 19:36:00.56

いろいろありすぎて何がなんだか

**デフォルトの名無しさん** · 2021/03/20(土) 21:57:21.68

最近のJSは落ち着いたとはなんだったのか
SSAの議論やHooksの登場で無限の可能性が出て
さらに混沌としてきた

**デフォルトの名無しさん** · 2021/03/20(土) 22:01:26.50

SSAて何？
Static Single Assignment？
さいたまスーパーアリーナ？

**デフォルトの名無しさん** · 2021/03/22(月) 22:20:24.58

ReactいろんなhookあるけどなんだかんだでuseStateとuseEffectとuseRefしか使ってない気がしてきた

**デフォルトの名無しさん** · 2021/03/22(月) 22:53:53.55

>>490
数年前の混沌と比べればかなり改善したと思うよ
とりあえずreactと指針決めやすいだけ随分マシ

**デフォルトの名無しさん** · 2021/03/22(月) 23:07:20.76

ブラウザに閉じ込められた世界なぞまっぴらだ

**デフォルトの名無しさん** · 2021/03/23(火) 00:06:38.01

>>492
useCallbackもなんかよく分からないけど使うだろ

**デフォルトの名無しさん** · 2021/03/23(火) 06:21:33.00

>>495
useCallbackは分かって使わないとメリット無くね？

**デフォルトの名無しさん** · 2021/03/23(火) 14:02:14.00

>>492
計算コストが高いものはuseMemoは必須

**デフォルトの名無しさん** · 2021/03/23(火) 14:37:00.87

useLayoutEffectとかuseImpなんとかとか使い所全く分からんな

**デフォルトの名無しさん** · 2021/03/23(火) 17:15:08.43

>>497
Nextに行ったので、計算コスト掛かりそうなのはなるべくSSGしちゃうからなぁ