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(水) 06:35:18.79

推奨ＮＧワード： Ruby

**デフォルトの名無しさん** · 2021/03/10(水) 07:05:12.33

CUIが割り込み無いとか、何言ってんだよ。割り込みなんてコンピュータの基礎じゃん。
sleepも割り込み、ネットワーク応答も割り込み。OSなくたって割り込みは存在するのに

**デフォルトの名無しさん** · 2021/03/10(水) 09:43:04.13

JavaScriptが非同期を意識したコードを書かないといけないというのが根本的な問題
しかも常に非同期なのではなく同期的に処理される場合もある

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

例えばファイル読み込みで非同期処理は必要か？
SQLのフェッチで非同期は必要か？
その辺りを考えれば俺のいってることは理解できるだろう

**デフォルトの名無しさん** · 2021/03/10(水) 11:55:06.47

シングルスレッドのJavaScriptは非同期にせざるを得ない
他の言語であればマルチスレッドで実行するので非同期はいらない

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

DBアクセスとかマルチスレッドこそ非同期要るじゃん。
同期処理と非同期が混ざってるのが良くないってのは確かにそう。ただ、現在の環境では希少かと。

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

>>373
いらんよ。どうせデータベースから値を取得しないとその次の処理はできないんだから

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

イマイチわからんのだけど、node.jsってプロセスが一つだからリクエストあってもグローバル変数は共有されるよね
サーバーレスだとアクションのたびにプロセスが立ち上がるからグローバル変数は共有されないの？
となるとnode.jsのメリットってどうなるんですか？

**デフォルトの名無しさん** · 2021/03/10(水) 14:57:43.23

>>375
お前がいいたいのは何だ？
グローバル変数の有無がどうメリットの話に結びつくんだ？
そもそもお前はnode.jsのメリットがなんだと思ってたんだ？

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

>>375
プロセス間でどうやって変数を共有するんだよ

**デフォルトの名無しさん** · 2021/03/10(水) 15:07:14.67

>>375
狂ってる

**デフォルトの名無しさん** · 2021/03/10(水) 15:27:36.16

>>376
メリットはプロセスが一個ってこと
グローバル変数はどうとかは知らん

>>377
知らんけどメリットあるっていろんなnode説明にあるけど

>>378
まあな

**デフォルトの名無しさん** · 2021/03/10(水) 16:45:19.70

>>375
調べてみたら確かにそうなんだね。勉強になった。

シングルスレッドだとプロセスが独立してないからグローバル変数が共有されるんだ。

**デフォルトの名無しさん** · 2021/03/10(水) 16:52:28.79

> サーバーレスだと独立してプロセスが走る
リソースは有限で、無限にプロセスが走るわけではないから、メリットはあると思うよ
https://www.grandream.jp/blog/understanding-aws-lambda-container/

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

>>379
> 知らんけどメリットあるっていろんなnode説明にあるけど

じゃあお前がnodeのメリットを勉強しろってだけの話だろ

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

>>380
> シングルスレッドだとプロセスが独立してないからグローバル変数が共有されるんだ。

マルチスレッドでもグローバル変数は共有されるが？
そもそも一部のメモリを共有したいという要求があって
マルチスレッドが登場したというのに

それから共有されるからなんだっていうんだよ？
なんにもデメリットはないだろ

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

>>383
スレッド間では共有されないでしょ？

**デフォルトの名無しさん** · 2021/03/10(水) 18:16:52.69

Next.jsに手を出したけども、始めるまで勝手にイメージしてたSSR vs SSGの図式は間違ってた。
そこはハイブリッドで良いし、結構簡単に切り替えられるんやな

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

グローバル変数はマルチスレッドで「不完全に共用」される。（ロックや排他制御しなければ）
他のスレッドから見られない共有されない変数は「スレッドローカル」変数。
スレッドはそもそも時分割処理をするために生まれたのであって変数を共有するためじゃない。
また物理的なメニーCPUコアが最初でもない。

>>373
当然ながら非同期はマルチスレッドじゃない。

Vue vs React vs Svelte vs Angularとかもう飽きたわ根本的にJSX系はいい加減にしてほしい

**デフォルトの名無しさん** · 2021/03/10(水) 18:23:50.16

>>384
スレッドはメモリを共有できるという特徴があるんだよ
勉強しなおしてきな

**デフォルトの名無しさん** · 2021/03/10(水) 18:25:28.51

マルチスレッドの地獄に比べたら非同期なんて大したことないだろ

**デフォルトの名無しさん** · 2021/03/10(水) 18:26:11.44

>>386
> スレッドはそもそも時分割処理をするために生まれたのであって変数を共有するためじゃない。

時分割処理をするなら複数プロセスを起動することで実現していた。
それが古来のUNIXのマルチタスク機能
スレッドは後からメモリを共有できる改良版として作られたもの

**デフォルトの名無しさん** · 2021/03/10(水) 18:28:47.74

>>388
マルチスレッドは地獄だから、局所的に使用する
グローバル変数を含むは共有メモリ
特別注意してコーディングすることになる

そしてマルチスレッドに関する局所的なコードを
除く、大部分のコードは同期的な処理で書きやすい
つまりマルチスレッドの地獄はごくわずかしかない

JavaScriptの非同期は、プログラム全体にわたって広く使われる

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

スレッドとプロセスの違いくらい勉強しとけよ

**デフォルトの名無しさん** · 2021/03/10(水) 18:43:09.23

ああ俺がTwitterで嫌いな部分ってルビーだったんだ

**デフォルトの名無しさん** · 2021/03/10(水) 18:45:43.38

プログラムなんだからメモリに展開されるから、共有される可能性はあるだろうけどね。

ある程度ライブラリで安全性を担保しようと頑張って実装してるでしょ、多分。

libuvはシングルスレッドだから、設計的にそこら辺の安全性を担保するのが難しいって話をしているよ

**デフォルトの名無しさん** · 2021/03/10(水) 18:55:38.86

ファイバとかコルーチンがトレンド入りですよ。

**デフォルトの名無しさん** · 2021/03/10(水) 18:58:10.99

繰り返すが、マルチスレッドもシングルスレッドもメモリは共有される

マルチスレッドの場合は複数のスレッドが同じ変数（グローバル変数）を
参照する必要があるから注意が必要。シングルスレッドはその必要がない
からシングルスレッドの方が簡単

それと非同期の話は関係ない
シングルスレッドの方が簡単だが、そうすると同時に一つの処理しか行えないから
シングルスレッドの問題を解決するのが非同期

非同期でシングルスレッドの問題を解決出来るが
同期と非同期のコードが混ざることになりややこしくなる
シングルスレッド＋非同期で頑張るよりも、マルチスレッドの方が簡単になることも多い

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

ストランドとか知ってる？

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

あわしろ氏が提案して、いまC++ Networking TS で標準化中だけど。

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

よしよし

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

非同期ではなく
完了まで待って次に移行するメソッドを
コールバックを一切排除して
関数定義側のみで定義する方法はないのか。
呼び出し側に特殊な構文が必要なのは無しにしてくれ
呼び出し側をそもそも関数で囲む必要がある
というオチはやめにしてくれ。
メソッド内で呼び出される非同期処理も
その内部の非同期呼び出しも
全部完了まで待つようにしてくれ

**デフォルトの名無しさん** · 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技術勉強してれば普通に満たせるやんけ