Vue.js概要？ # Vue.jsを推す理由

# はじめに

[本文はこちら](https://qiita.com/asip2k25/items/bd4bdccd5201d542953c)

# Vue.jsを推す理由

## on Rails

Vue.js、初期学習コストはそれなりに掛かります、が、
それを乗り越えると、レールにのっているかのように、
劇的？に開発時間を短縮できてる感があります。

生産性が高い、と感じています。
(ハマりどころは少ない印象です。)

## Intuitive (直感的)

Vue.jsは、API含め、HTML/CSS/DOM の知識さえ ある程度
あれば 直感的に扱えるよう設計されている と感じています。

理解するための勘所をおさえれば、誰もが短期間で ある程度
使いこなせるようになります。

周辺ライブラリも、直感的に扱えるよう設計されているモノが多い
ので、基本を理解すれば、ある程度まで使いこなすことは容易です。

# Designer Friendly

Vue.jsは、意図しなくても、(変な記述をしない限り、)デザイン
とロジックを分離できます。

HTMLテンプレートには、(一部を除き)JSが入り込まないので
デザイナーの方に編集してもらうことが可能です。

CSSも CSSファイル or Styleタグ に記述するので、デザイナー
の方も容易に編集できます。

## vs React

### React: 潜む学習コスト

React、(React本体に含まれている)ごく基本的な機能を利用する  
だけなら、学習コスト、Vue.js >= React、な感じですが、  
ごく基本的な機能だけでは、SPA/MPAを作成するには不十分で、  
状態管理ライブラリ etc に手を出し始めると、途端に、学習
コストが増大し、Vue.js << React、になっていく感があります。

::: note info
SSR(Server Side Rendering)に手を出すと、更に
学習コストが嵩みます。

ReactでSSRが必要な場合には、Next.js or
React Route V7(旧Remix v2)を採用することに
なります。
:::

React Hooksが登場してから、React に機能の追加etcが
行われる度に、React Hooksに関数が追加されていっている
ので、学習コストが改善される方向には向かっていない
ようにみえます。

::: note info
React Hooks は、関数コンポーネントからReactの機能を
利用するための機能(関数群)であり、React Hooks登場前
までクラスコンポーネントでしか利用できなかったReactの
機能群を関数コンポーネントで利用できるようにしました。

関数コンポーネント記述用の API に Hooks...。  
React Function API とかの命名のほうが、名が体を表して  
いたのでは...。

React Hooks 登場後、Reactのクラスコンポーネントは
後方互換用と化しています。
:::
::: note info
Reactのコンポーネントは、クラスコンポーネントと
関数コンポーネントの２種類あり、React Hooks登場前
まではクラスコンポーネントが主流、登場後は関数
コンポーネントが主流、クラスコンポーネントは
後方互換用と化しています。

Reactのクラスコンポーネントと関数コンポーネントは
ライフサイクルetcの仕様や挙動が異なります。

Reactでは、実行時に、クラスコンポーネントは
オブジェクトとして振舞い、関数コンポーネントは
関数として振舞う、はずです。
:::

#### React: 周辺ライブラリの充実とデファクトの欠如

React、周辺ライブラリが充実しているのは結構なこと なの
ですが、車輪の再発明も多く同じ用途に複数のライブラリが  
存在していて、更に、そこに、React Hooks / 制御 / 非制御
コンポーネントetcも絡んでくるので、カオスな感じです...。

フレームワーク+周辺ライブラリ(状態管理ライブラリetc)の
組み合わせ、で、学習コストが変動し、追加の学習コストも
発生します。

##### Reactベースのフレームワーク

Next.js、React Router v7(旧Remix) etc があります...。

Next.js と React Router v7、どちらもReactベースのFW
ですが、書き味は(それなりに)異なります。

::: note info
Next.js は SSR(&CSR)/CSR/SSG/ISR、
Remix/React Router v7は、デフォルトSSR、
SSR(&CSR)/SPA(Remix 2.5.0にてSPAモードを導入)、
設計思想自体、異なります。似て非なる感じです。
:::
::: note info
Next.js、Remixのシンプルさをみて？ ver.13 でRSC
ベースのApp Routerを導入、デフォルトにして、
デフォルトSSRの方向に舵を切っています。

App Routerは 旧来の Pages Router とは挙動etcが
異なります。

(SSR選択時、Pages Routerは、デフォルトで SSR→CSR→
ハイドレーション していますが、App Routerは、
デフォルトでは SSRのみ、'use client;'でマーキング
したコンポーネント(クライアント・コンポーネント)(が
ページ内にある場合)のみ、SSR→CSR→ハイドレーションが
行われます。(そのハズ))

:::
::: note
Next.js は開発元Vercelの運営しているPaaS上で
動作させることが前提になっている機能があるので、
注意が必要です。

非公式のツールOpenNextを使用すれば、
AWS/Cloudflare/NetlifyでVercel
前提の機能を(制限はあるものの？)動作
させることができるようです。
:::
https://opennext.js.org

##### 状態管理ライブラリ

Reactでは、コンポーネントは状態を持たず、ビルトインor外部
ライブラリ(で提供)の関数の返値(セッター・ゲッターetc)を介して、
React or 外部ライブラリが管理している状態へのアクセスを
行います。

::: note info
ReactビルトインのuseStateフックでは、Reactが状態を管理
しているものの、コンポーネント間で状態を共有することは
できません。

また、useStateフックは、クライアントサイドで動作する仕組み
であり、RSC(サーバー・コンポーネント)では利用不可です。

React Hooksには、クライアントサイドのみで動作する関数が
いくつかあるため、注意が必要です。
:::

Reactでコンポーネント間での状態の共有を行う仕組みとして、
ReactビルトインのuseContext/useReducer、外部ライブラリ
の(独自の?)Redux/Zustand/(React Hooksベースの)
Jotai etc、があります。

デファクトは存在せず、Redux/Zustand/Jotai etcの何れかが
Reactを採用したWEBアプリの開発チーム(会社)毎の(のコア・
メンバーの)好みで採用されている状況のようです。

::: note info
Recoilが、Metaのエンジニアによる開発でMeta発で
あることから、Reactの状態管理ライブラリの
デファクトになるのではないかと思っていた時期も
ありましたが、実験的なライブラリとして開発され
続け、安定版(1.0)に達しないまま、現在は開発が
終了しています。

主たる開発者を含め、開発メンバーが全員？
Metaからレイオフされたので、検討されていた外部
コントリビュータの受け入れも暗礁に乗り上げ、
Recoilはプロジェクトとして死に体です。

https://github.com/facebookexperimental/Recoil/discussions/2171#discussioncomment-7979532
:::

#### React: トータルの学習コスト

後述のAngularより、ReactのほうがWEBアプリを
構築する上でのトータルの学習コストは高いと思います。

::: note info
世の中には「学習コストが高いモノを態々選んで勉強
する(複雑な***を理解できている俺・私って偉いと
思っている？)方もいらっしゃるようですが、必要も
ない(＆自分の好みにフィットしているわけでもない)
のに学習コストが高いモノのほうを選ぶのは時間の
ムダです。
:::

React の開発チームは、初心者or初級ユーザー(利用開発者)に
とって理解し易く扱い易くする方向には向いていないようです、
ドキュメント・サイトをみてもそんな感じです(無駄に小難しく
書かれている箇所があります)。

https://react.dev

#### [比較]

Vue.jsのコンポーネントは、関数で定義するコンポーネント
のみが存在します。

Vue.jsのコンポーネントには、Options API での記述、  
Composition APIでの記述、の２種類があります。

Options API は、(現状の)Vue.jsのコンポーネントの内部表現
(データ構造)をそのまま表出させた感じのAPIで、
コンポーネントと密結合していて、柔軟性に欠けていましたが、
Composition API は、コンポーネントとは疎結合の柔軟性＆
自由度の高いAPI となっています。

Composition API は、Options API と較べて、一見、複雑に
みえますが、慣れてしまえば、Options API より自由度が高く
柔軟に書け、コードの見通しもよくなります。

::: note info
Composition API/Options API、どちらで記述しても
コンポーネントの挙動に違いはありません。

Vue.jsのコンポーネントは実行時に(ランタイム上で)
オブジェクトとして振舞います。
:::
::: note info
Composition API は、3.0.0にて投入された API であり、  
3.0.0以降、利用が推奨されています、3.xへの移行を促す
ため、2.7.x にパックポートされてもいます。

3.0.0以降、Vue.js(本体の)Options API は
Composition API を用いて実装されています。

3.0.0以降、Options API は 後方互換性のために  
残されている印象です。
:::

周辺ライブラリも、コンポーネント・ライブラリを除けば、  
車輪の再発明は少なく、それらのどれかの採用に伴う追加の
学習コストも、微々たるモノな感じです。

::: note info
Vue.js 2.xでは、クラスコンポーネントが公式にサポート
されては いたものの、Vue.js 本体とは別に提供
されているライブラリ  (Vue Class Component
(+ Vue Property Decorator))  を利用する
必要がありました。

JavaScriptのClass が シンタックスシュガーであるのと
同様に、Options APIによるコンポーネント定義の
シンタックスシュガーでした。

3.0.0での、Options API とは異なる 新API、
Composition API の投入に伴い、3.0.0以降での
クラスコンポーネントの公式サポートは終了しています。

2023/03/23 正式に Vue Class Component の廃止が  
アナウンスされました。
https://github.com/vuejs/vue-class-component

Vue Class Componentは、Options APIベースであり、  
Composition API との親和性を実現できなかったことも
(開発停滞→)廃止の要因だと思います。

3.0.0の開発中に、クラスコンポーネントのVue.js本体
へのビルトインが検討されていましたが、React Hooksの
登場に影響される形で、Composition API が提案され、
その結果、クラスコンポーネントのビルトイン案は破棄
され、Composition API が正式採用となった経緯が
あります。
:::

##### Vue.jsベースのフレームワーク

フルスタックなフレームワークは、(ほぼ)Nuxt一択です。  

Vue.js3 + Composition API でオーバーホールされた  
Nuxt3 のリリース(2022/11/16)により、機能面および  
パフォーマンス面で、Reactベースのフレームワーク同等に  
なっています。

::: note info
Nuxt3は、根本的なアーキテクチャの見直し(再設計)が
行われ、また、その開発と並行して、足回りとなる
ライブラリの開発も  行われた結果、3.0.0のリリース
までに時間が掛かりました。  
3.0.0以降は、インクリメンタルな開発へとシフトして
います。
:::

##### 状態管理ライブラリ

Vue.jsは状態をコンポーネントが持っていて、コンポーネント間
での状態の(値の)受け渡しもできるので、必ずしも、状態管理
ライブラリを利用する必要はありません。

::: note info
コンポーネント間で状態を共有する(Vue.jsビルトインの)仕組み
provide/inject があります (from 3.0.0)。 

Vue.js/Nuxt の状態管理において、クライアントサイド/サーバー
サイドを意識することは(ほぼ)ありません。
:::

グローバルに 状態を管理したい/管理する必要のある 場合には、
Pinia (or Vuex(for Vue.js 2.x)) or useState (Nuxt3を
利用している場合、React の useState とは別物) があります。

Pinia が状態管理ライブラリのデファクト・スタンダード
となっています。

### React: 複雑さのインクリメンタルな増大

React も、Anguar(JS)同様、クライアントサイドに、サーバー  
サイドの設計(思想)を持ってきている気がしています。

React は、JSセントリックで、JS/WEB標準の上にJS/WEB標準
とは異なる React独自の世界(React World)を構築している感が  
あります。

React は、Vue.js の 2.x→3.x での Composition API 導入の
ような大きな変更はなく、漸進的(インクリメンタル)な変更が
続けられてきているものの、漸進的であるが故？に、段々、
(周辺ライブラリを含めた上での)複雑さが 増していっている気が
しています。

シンプルさがウリだったはずが、WEBアプリ構築における様々な
要件にインクリメンタルに対応しているうちに、表面上、シンプル
に見えるけれど、中身はそれなりに複雑で、その挙動をある程度、
ユーザーが把握しておかないと、思わぬハマりどころがある、に
なってしまっている感がしています。

::: note info
発表から2年以上経つにも関わらず、未だ開発フェーズの
最適化コンパイラ React Compiler(旧 React Forget)、
Meta社内の一部で試験導入(テスト)が行われていて、
先日、開発途中ではあるもののオープンソース化されたので、
上手くいけば、一年以内に正式版がリリースされ、Reactの
煩雑さの解消 に一役買うようになるかもしれません。

React Compilerが行う最適化は、現状、メモ化のみです。

React Compilerでは、Reactのルールを守っていないコードは
最適化の対象外です。
:::

https://dev.to/usulpro/how-react-forget-will-make-react-usememo-and-usecallback-hooks-absolutely-redundant-4l68

::: note info
React Compiler、Vaporwareに近い印象です、複数人
のプロフェッショナルがフルタイム？で数年間 開発して
実用できるレベルに未だ達していない...。
(先日(2025/04/21)、やっとRC版に...)

React Compiler、Babelプラグインとして実装されて
いて、ビルド時にコンパイラで静的解析→ useMemoや
useCallback(etc)でメモ化すべきコードをuseMemoや
useCallback(etc)を利用したコード相当のコードに
変更し(自動的に)メモ化する形になっています、
「言うは易し行うは難し」ですね...。
変更する適切な箇所を実行時情報なく、静的解析のみで
判断するのは難しい気がします...(Gemini etcの)
生成AIを利用しても、適切でない箇所が変更される
過剰な変換or誤変換をゼロにはできないような...。
:::

#### [比較]

2.x→3.xでのビッグジャンプ(Composition APIの導入)以降、
Vue.js まわりで 複雑さの上昇はないように思います。

2.x→3.xでのビッグジャンプは、ユーザー(利用開発者)に痛みを
強いるモノでしたが、2.xではできなかった(コードの)最適化etc
が可能となり、2.xに較べて3.xは大幅にパフォーマンスが向上
しています。

::: note info
Vue.js の 2→3 での Composition API の導入を伴う
変更は、2系の設計時点ではみえていなかった 設計の問題
点/２系が利用されること(&２系のメンテナンス)でみえて
きた課題 を解決するために ライブラリの再設計が行われた
結果だと考えています。

Vue.jsの開発チームは、3系で、2系をインクリメンタルに
改善していく方向ではなく、今後を見据え、再設計/再実装
を選択しました。
:::

https://increment.com/frontend/making-vue-3/

Vue.js は、2.x → 3.x での Composition API導入を伴う変更
は今後を見据えた場合、必要な変更ではあったものの、移行期間や
移行パスを十分に用意した段階的な移行ではなく、ビッグバン
リリースとして行ってしまったために、Vue.jsまわりのエコ
システムを構成する各種プロダクトが3.xリリース時点では
3.xに対応しておらず、3.x対応のプロダクトが出揃うまでに
時間が掛かってしまいました。

ビッグバン・リリースの結果、2.x→3.xでのエコシステムの追従
(Options API → Composition APIへの移行)に時間が掛かった
ことetc をVue.jsの開発チームは失敗と認識し、3.x以降、
ビッグバン・リリースは行わず、段階的に変更を行っていく方向へと
シフトしています。

:::note info
3.x以降は、新機能はまず、フラグにより有効化しないと
利用できない機能として試験的に導入され、十分に安定
した時点で新(マイナー)バージョンにてデフォルトで利用
できるようになります。
:::

::: note info
Vue.jsを採用したプロジェクトでの2.x→3.xへの移行が
Vue.jsまわりのエコシステムを構成する各種プロダクトの
3.x対応を待たなくてはならない状況も発生していました。

現在は、エコシステムCIが導入済みで、Vue.jsまわりの
エコシステムを構成する各種プロダクトの開発者と
協調して、対応待ちが発生しないor発生しても短期？の
状況になっています。
:::

:::note info
インクリメンタルな改善ではインクリメンタルに複雑さが
増大してしまう懸念があるor インクリメンタルな改善で
インクリメンタルに複雑さが増大してきている 場合には、
大きな変更を伴うビッグバンリリースで、インクリメンタ
ルな複雑さの上昇を避ける or インクリメンタルな改善で
上昇してきた複雑さをリセットするのもありなのではない
かと個人的には思います。
:::

#### React: 責務？(守備範囲)の拡大

Reactは、元々、クライアントサイド(CSR)でのコンポーネントの
作成(組立)/描画を行う機能のみをもつライブラリでしたが、
サーバーサイドでの作成/描画(SSR)を実現するために機能の拡張が
行われました。

サーバー(専用の)コンポーネント(RSC)を実現するための機能の
拡張も行われました。

ここまでの機能をみれば、クライアントサイド/サーバーサイドを
問わず、コンポーネントの作成(構築)/描画を行う機能のみをもつ
ライブラリといえ、責務？の拡大とはいえないと思います。

ここにActions / useフック etcを加味すると、変わってきます。

Actionsは、クライアントサイドからサーバーサイドの関数を
実行し、その結果をクライアントサイドで受け取ることを
可能にしています。

useフックは、コンポーネントの作成(構築)/描画を行うために
必要な機能ではなく、なくても同等のことを実現できるけれど
あればコードを簡潔に書ける便利系の機能です。

Actions etcの登場により、Reactは責務？の拡大に一歩踏み出した
といえると思います。

このReactの責務？の拡大により、Reactの複雑さは今後も増大
していくと考えられます。

##### [比較]

Vue.jsは、Reactと同様、クライアントサイド(CSR)での
コンポーネントの作成(構築)/描画を行う機能のみをもつ
ライブラリとして誕生し、サーバーサイドでの作成/描画(SSR)を
実現するために機能の拡張が行われました。

サーバー・コンポーネントを実現するための機能の拡張？も、
行われています。

Vue.jsは、クライアントサイド/サーバーサイドを問わず、
コンポーネントの作成(構築)/描画を行う機能のみをもつ
ライブラリであり続けていて、責務？の拡大には踏み出して
いません。

#### React: RSC(React Server Component) & Actions

React の RSC、Actions の登場もReact の(周辺ライブラリ
を含めた上での)複雑さの上昇に拍車を掛けています。

::: note info
サーバー・コンポーネントであるRSCは、サーバーサイド
でコンポーネントの組み立てを行い、クライアント
サイドでは描画のみを行います。

サーバーサイドでは、DOMはないので、比較・差分抽出→
差分のみの反映のステップ自体、(必要)ありません。
サーバーコンポーネントの場合、クライアントサイドでは、
サーバーサイドで組み立てた結果を受け取り、その描画
のみを行います。

クライアントサイドではなく、サーバーサイドで
コンポーネントの組み立てを行うことで、
クライアントサイドは軽くなります。

サーバーコンポーネントは、クライアントサイド/
サーバーサイドの双方で利用できます

サーバーコンポーアントは、SSRを補完するモノです。
:::

::: note info
RSC、サーバーサイド/クライアントサイド、それぞれで
動作するコンポーネントを、Reactのコンポーネント・
ツリー上でどちらも扱えるように、サーバーサイドで
動作するコンポーネントについて規定した仕様/実装の
ようです。
:::

RSC / Actions自体、発展途上の仕様/実装のように思えます。

::: note info
Actions は Next.js由来?のServer Actionsを拡張し、
クライアントサイドにも対応させた機能で、React19で
stableになっています。
:::

RSC/Actionsを、現状、実装している有名どころのReact
フレームワークはNext.js のみで、その実装(App Routerまわり)も、stable扱いになってはいるもののパフォーマンス上の問題が
残っていて？こなれているとは言えない状況のようなので、RSCの
本番投入は、パフォーマンスetcの計測を行った上で判断するのが
よい状況のようです。

::: note info
RSCの仕様、Next.js開発元のVercel社が仕様策定に
関わっていて、Remix開発チームは関わっていないこと
もあり、Remix開発チームのメンバーが試してみると、
RSCがRemixの現行の実装よりも遅いことがわかった、
ので、RSCが安定する(実装/仕様がこなれてくる)まで、
Remixでの採用は見送られていました。

下記は、2021/12時点でのRemixの開発チームメンバーに
よるRSCの評価記事です。

https://remix.run/blog/react-server-components

RSC、デフォルトSSRのフレームワークであるRemixに
とって優先順位が高くはなかったようです。

v2 のリリースアナウンス(公式ブログ)にてRemixの
RSC対応に関する続報がありました。RSCサポートに
向けて開発が開始中です。
Remix開発チームはRSCの安定化に向けて協力していく
とのこと。
:::

https://remix.run/blog/remix-v2#what-about-rsc

::: note info
Remixは 既存のコードを React Router に合流し、
v3? → React Router v7としてリリースされています。

loader/action まわりは React Router の
今後のバージョンでのRSCサポートで多少変わる模様。

2025/05/15、React Router のRSCプレビューが公開
されました。
:::
https://remix.run/blog/rsc-preview

::: note info
Remixは、Preactをフォークし、ベースをReactから
そちらに変更する方向で開発を開始しているようです。

その前段階として、Reactベースの既存コードを
React Routerに合流させた模様。
:::

https://remix.run/blog/wake-up-remix

##### [比較]

Vue.jsでサーバー・コンポーネントを利用するには、
Vue.js3ベースのフレームワークであるNuxt3を
利用する必要があります。

Nuxt3では、クライアント(サイドのみで動作する)
コンポーネントか、サーバー(サイドのみで動作する)
コンポーネントか、クライアントサイドとサーバーサイドの
双方で動作するコンポーネントか、を意識してコードを書く
必要はありますが、ReactのRSCまわりのような煩雑さは
ありません。

#### React: CSSの扱い

Reactを採用したプロジェクトでは、様々なスタイリング手法
が利用されています。

CSS、CSS Modules、CSS in JS、CSSフレームワーク 
(Tailwind etc) です。

その１つである CSS in JS では、JavaScript に CSSの
プロパティを記述します。

::: note info
CSS in JS は、CSSのJavaScript記法のようモノです。
CSS in JSライブラリを用いて、JavaScriptのコードに
CSSを埋め込みます。ランタイムによりビルド時or実行
時にCSSに変換されます。
:::

CSS in JS には、実行時にCSSを生成する ランタイム CSS in JS
(Emotion、Styled Components etc) と、ビルド時にCSS
を生成するゼロランタイムCSS in JS (Linaria、
vanilla-extract、StyleX etc)の2種類があります。

RSCでは、ランタイム CSS in JS は動作しないため、RSCを
採用する方向に舵を切ったプロジェクトでは、ランタイム
CSS in JSを採用している場合、ゼロランタイム CSS in JS
or 他のスタイリング手法に移行する必要があったりします。

デファクトのスタイリング手法は存在せず、どのスタイリング
手法を採用しているかは、開発チーム毎(のコア・メンバー)の
好みによります。

経験のないスタイリング手法を採用しているプロジェクトに
参加する場合、それなりに追加の学習コストが発生します。

##### [比較]
Vue.js では、CSS と JS は明確に分離されています。

CSS in JS を採用する必要はなく、CSSファイル or styleタグに
普通にCSSを書きます、CSSフレームワーク(Tailwind etc)も
勿論利用できます。

::: note info
参加するプロジェクトで経験のないCSSフレームワーク
が採用されている場合には追加の学習コストは発生
します。

CSSを知ってさえいれば、CSSフレームワークの学習
コストはそんなに掛からないはずです。
:::

Pinceau や Panda CSS を用いることで、CSS in JS/TS を採用
することは可能です。

https://blog.nekohack.me/posts/pinceau-usage-on-nuxt-3/

https://zenn.dev/gangannikki/articles/pandacss-using-cva

### 仮想DOM(vDOM)高速道路時代の終焉

ブラウザのUIレンダリングまわりetcの改良もあり宣言的UI
を仮想DOMを用いずDOMのみで実装する Svelte/Solid.js が
ベンチマークで Vue.js同等以上/React以上 の性能を叩き出す
状況になっていて、vDOMツリーの比較・差分抽出により差分
のみをDOMに反映する技術であるvDOMのパフォーマンス面
での優位性は、現在、なくなっています。

::: note info
ベンチマーク結果は Solid.js公式サイトのトップページに
あるのが ほぼ最新で参考になる かと思います。
:::

https://www.solidjs.com

React開発チームは、現在、(脱仮想DOM etcによる)
クライアントサイドでの高速化(性能強化)を目指すのではなく、
React Server Component(RSC) / (Server) Actions
の導入からわかるように サーバーサイド強化の方向に注力
してい(るようにみえ)ます。

React開発チームからは、現在、クライアントサイド(CSR)
での高速化に関する何の方向性も公には示されていません。

#### [比較]

Vue.js開発チームは、現在、脱仮想DOMによる高速化を目指し、
仮想DOMを利用しないSFC(Single File Component)
コンパイラの新モードVapor Modeを開発中です。

::: note info
Vapor Mode は、CSR/SSR の両方に対応しています。
:::

https://github.com/vuejs/core-vapor

https://vapor-repl.netlify.app/

Vue.js本体ではありませんが、Nuxt3 において、
サーバーコンポーネントに対応しています。

https://github.com/nuxt/nuxt/issues/19772

### React: Meta駆動？

React には、Angular(JS)のGoogle駆動 と同じ  
ニオイ、Meta(旧Facebook)駆動 を感じてきました。

Recact本体、Meta在籍のエンジニアと Meta出身のエンジニア
(MetaのReact開発チームの元メンバ(Vercel etcに在籍))が
開発していて、外部のエンジニアを巻き込んだ開発体制にはなって
いない感じです。

開発体制が内に閉じていて、外に向けては開いていない印象です。

React本体は、v16のFiber、v18のConcurrent Mode 以降、
改良(性能強化)に関する大きな方針表明はありません。

MetaのReact開発チーム、エンジニアが何人も、Metaのレイオフ
(人員削減)の対象になって同社を去っている(MetaがReactへの
投資を縮小している)ので、React はMetaの戦略的に重要な
プロダクトではなくなっている可能性が高いです。

:::note info
Metaにとって Reactは 外部に公開しているものの
あくまで内製ライブラリ であり、外部に公開する
メリットは(Metaにとっては)あまりない(という
個人的な)印象です。

強いてメリットを挙げるなら、Metaの技術力のアピール
くらい？(外部ユーザー(利用開発者)からのフィード
バックを重視している感じがしないので。)
:::

:::note info
Next.jsの開発元であるVercelにMetaからReact開発
チームのエンジニアが何人も流出している、ので、
Reactは近い将来、Vercel駆動になるのかも...。

RSC & Actions の開発、Vercel が主導している
ようにみえます。

Vercel開発のNext.js、自社のPaaSであるVercelを
(あからさまに)優遇していて(Vercel前提になっている
機能があって)、Vercelを使わせるためのFW感が
あリます。

Next.js組込みのTurbopack、汎用的なバンドラには
向かわない気がしています(Vercelにそのための投資を
行うメリットがないので)。

VercelがReact(本体)の開発を主導するようになるifを
歓迎するユーザーはあまりいないのでは？
(React(本体)がVercel駆動になるIFの場合、Vercelは
MetaほどReactに投資(資金投入)できないハズ。)

Metaが社内のReact開発チーム(Reactへの投資)をより
縮小する場合、ReactFoundation でも設立されて、
Metaを含む数社でReact(本体)の開発を主導する感じに
なるのがユーザーにとってはベター？
:::

::: note info
Vercel、Svelteの原作者である Rich Harris氏を雇用
していて、氏はフルタイムでSvelteの開発を行って
います。

Vercel、(会社として)React(本体)の開発の主導権を
握りにいける状況になっても握るつもりはないような気
もします。

握った場合に掛かるコストにメリットが見合っていない
気がしますし。
:::
https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte

Meta は、PHPのパフォーマンスetcに満足できなくて、PHP似の
別言語Hackを開発・採用するくらい、パフォーマンス重視な企業
文化があるので、パフォーマンスでの優位性がないに等しくなって
いるReactへの社内でのコミットメント・リスペクトが低下して
いても何ら不思議ではありません。

::: note info
Reactが社外で広く利用されていることもあり、React
を社内利用することによる他社に対する優位性はなく、
また、MetaはReactから何ら収益を得てはいないので、
パフォーマンスでの優位性がなくなっている現在、
MetaがReactの改良に積極的に投資し続ける
メリットはないに等しくなっています。

Metaが、今後、Reactの改良に積極的に投資(資金投入)
することはないように思えます。

Metaの今後のReactへの投資はReactを採用した社内
既存プロジェクトのためのメンテナンス・モードでの
消極的投資に留まるのではないかと。
:::

::: note info
シンプルさがウリだったハズが、トータルすると
シンプルとは言えなくなってきているReactまわりの
現状もあります。

シンプルではないということは、WEBアプリに採用
した場合の開発コストが嵩む、ということでも
あります。

開発コストが嵩む上にパフォーマンス上の優位性もない
に等しい、では、MetaがReactの開発にコミットし
投資し続けることは難しいハズ。
:::

Metaのような企業がOSSの開発を主導している場合、
経営上の決定により、社内の開発チームが縮小/廃止
となる可能性があるので、注意が必要です。

::: note info
Metaが社内で React に代わるライブラリ(React
互換？)を内製し(はじめ)ていても何ら不思議では
ないです。
:::

大企業が開発/後援しているからといって盤石では
ありません、ハシゴを急に外される可能性を意識
しておく必要があります。

:::note info
Meta は 社内で開発した GraphQL の推進団体GraphQL
Foundation から離脱済みです。(GraphQLから手を
引いているor距離を置いている印象です。)
:::

:::note info
Mataの公開しているオープンソースに、Go製のOR
ラッパent etcがあることからわかるように、
MetaはサーバーサイドでGo etcも採用していて、
ReactのRSC & ServerActionsを全社的に推して、
JS(TS)でサーバーサイド(全て)を構築する気はない
ようです。

Remix を開発している会社を買収した Shopify も、
バックエンドフレームワークとしてのRails(Ruby)の
改良に投資していることからもわかるように、全社的に
推して、React + JS(TS)でサーバーサイド
(全て)を構築する気はないでしょう。

Meta も Shopify も フロントエンド(+ BFF) +
バックエンド(WEB API)の構成から踏み込んで、
サーバーサイドを含め(全て)JS(TS)で構築する方向
には向いていないのです。
:::

## vs Angular(JS)

### サーバーサイド的設計

AngularJS(1.x)は、クライアントサイドに サーバーサイドの設計を
そのまま持ってきている感があります。

AngularJS(1.x)のCotroller駆動より、Vue.jsのModel駆動、
のほうがクライアントサイド(UIアプリ)では、理に適っています。

AngularJS(1.x)は中・大規模開発には適さない と思っています、
大規模開発を指向してはいるものの、中・大規模開発に向いていない
のです。

Angularは、大規模開発には向いていますが、小・中規模開発には
向いていないように思えます。

::: note info
AngularJS(1.x)はCotroller駆動、Angular(2.x以降)は
Component駆動となっています。

AngularJS(1.x) と Angular(2.x以降)は別物です。
:::

### Railsに例えられること への疑問

Angular(JS)は以前Railsによく例えられましたが自分はそうは
思いません。

似ているのは、フルスタック・フレームワークである点、
そのぶん勉強が大変な点、だけです。

Rails、初期学習コストはそれなりに大きいですが、それを  
乗り越え、レールにのってしまえば、劇的？に開発時間を短縮  
できます。

対して、Angular(JS) はそうではありません、初期学習コストを  
乗り越えてもレールが敷かれていないため、劇的な開発時間の  
短縮は望めない のです。

Railsは、2.xまでは、Angular(JS)と同様に１から10まで  
開発チームが面倒をみ、構成する各種モジュールと密接に  
結びついていましたが、3.0での軽量Railsと目されていたMerb  
とのDHHの英断による統合もあり、フルスタックであることは  
変わらないものの、プラガブルとなり、外部で開発されている  
モジュールとの柔軟な組合せ、構成するモジュールの取捨選択が  
可能 となっています、3.0以降、外部で開発されたライブラリが  
次々とRailsに採用されてもいます。

対して、Angular(JS) は 一枚岩 です、他のフレーム
ワークや  ライブラリと柔軟に組み合わせて、利用することは
想定されていません。

Vue.jsは、フル・スタックではありません、が、FWとしての  
スコープを絞り、Viewまわりにのみ、特化し、Viewまわり以外
については、目的に応じた専用のライブラリと組合せて使うこと
を前提にしていて、組み合わせるライブラリを柔軟に取捨選択
できます。

### Googleブランドかつコミュニティ駆動 という虚像

「神様、仏様、Google様」なGoogle信者がセンスの良さよりも  
ブランドで持ち上げている気がしてならないです。

Angular(JS) は、デバッグ以外1から10まで開発チームというか  
少数のGoogleエンジニアが面倒をみ、構成するモジュールも
基本的に少数のGoogleエンジニアが設計・開発を行っている、
Google製フレームワーク です。

つまり、Angular(JS)は コミュニティ駆動 ではなく
Google駆動 なんです。

::: note info
個人的には、Angular(JS)はGoogle社内で GWT(Java→JS)
の後継的位置づけ なのではないか？と思っていました。

Google IO 2014の基調講演から考えると、Google内
では、Polymer(Lit Element の前身？)がGWTの後継的
位置づけのようにもみえましたが、そうでもありません
でした。
:::

クローズドで仕様が決まった後、Google主催のカンファレンスで
プロダクトの情報が開示されるorプロダクト(ベータ版)がリリース
される まで、プロダクトの全体像/プロダクトの今後の方向性
がみえてきません、トップダウン型のアプローチのみを
採用していて、積極的に情報を開示してボトムアップ的に
利用(開発)者からのフィードバックを汲み上げる方向には
向いていないように感じています。

Angular(JS)2.0の設計資料が公開された時も、1.xの課題と2.0に
向けた 設計指針が示されているだけで、(利用)開発者コミュニティ
からのフィードバックを開発に反映しようとしているようには
感じられませんでした。

開発体制が内に閉じていて、外に向けては開いていない印象です。

2.x以降のバージョンでも、それは同様にみえました。
現在は、多少、変わっているかもしれません。

Angular(JS)の今後について、１つの懸念があります。

GoogleはAngular(JS)の自社内での位置づけを下方修正している  
ようにみえることです。

Angular(JS)はGoogleにとって、戦略的に重要なプロダクトでは  
なくなっているようにみえます。

Googleが、Angular(JS)の開発に(積極的に)リソースを投入する
ことは最早ない、と思われます。

Angular(JS)はGoogle駆動であり続けているようにはみえます。

Google IO 2014の基調講演での Web Components仕様  
プッシュを考慮すると、Angular(JS)が2.x以降で  
WebComponents仕様との親和性 を実現できていなければ、
GoogleはAngular(JS)をステていたかもしれません。

::: note info
Lit Element(Polymerの後継)に"Powered by Google"   
の文字はありませんが、こちらもGoogle I/Oで発表された 
Googleの戦略的？プロダクトで、Google駆動です。
:::

::: note info
Googlerが開発しているからGoogle駆動、
なのではありません。    
Googleにより(戦略的意図のもと？)後援され
ユーザーコミュニティから切り離して開発され、
製品(情報を含め)がβテスト・フェーズになるまで
公開されないから、Google駆動、なのです。

Google駆動のOSSプロダクト は基本的に
βテスト・フェーズに入るまで(情報含め)
公開されません、このフェーズでは、設計は
既に固まって  おり、OSSコミュニティが設計に
フィードバックを行うことは、まずできません。

Googleは秘密主義なので、Google駆動なら、
Google I/O等で(大々的？に)発表されるまで、
外部に情報が漏れることはまずありません。

Googleにとって、OSSコミュニティはテスター・
デバッガーに  すぎないのではないか、と
思っています。

(GoogleはOSSに対して非常に理解があるように
思われていますが、  プロダクトをOSSとして
公開している他の企業と何ら変わりはありません...。)
:::
::: note info
企業が主導しているOSSは安心だと思っている方がいるよう
ですが、企業は営利目的なので、主導していたにしても
経営判断により手を引くケースは往々にしてあり、
そして、手を引かれたOSSは開発・メンテナンスする
人材がおらず、衰退･消滅していきます。
:::

#### 比較

Vue.jsの開発者である Evan You氏 は元Googlerですが、  
Vue.jsの開発は、元々、氏の個人プロジェクト、であり、
現在は、チームでの開発体制となっています。

Vue.jsが個人プロジェクトであったことを引き合いに出して、
その将来に不安があるかのように文章を書く方もいらっしゃる
ようですが、Linuxが、元々、個人プロジェクトであったことを
知らないのか、と思います。Evan You氏に何かがあった、と
しても、開発を引き継ぐ個人なり企業なりが現れる、と
思っています。

### 学習コストの費用対効果

学習コストが高いこともAngular(JS)のネックの１つです。

Angular(JS)は囲い込み型のFWなので、学習コストを掛けても  
Angular(JS)を離れるとAngular(JS)の勉強で得た知識は
ほとんど役に立ちません。

Angularは、2.0以降、AngularJS(1.x)と別物であり、  
1.xの知識やノウハウがほとんど役に立たない、ので、  
1.x→2.xへの移行コストは高くついたことでしょう。

既にAngularで仕事してるor仕事することが決まっている、  
のでもなければ、今からAngularを勉強するのは時間の
ムダです。

これから仕事に活かすために勉強するのなら、Angularを勉強  
するのではなく、別のことを勉強しておいたほうがずっと有意義の  
はず。

Angularは高い学習コストを掛けることに見合うほどに  
魅力的では最早なくなっています。

::: note info
世の中には「学習コストが高いモノを態々選んで
勉強する  (複雑な×××を理解できている俺・私
って偉いと思っている？)方もいらっしゃるよう
ですが、必要もない(＆自分の好みにフィット
しているわけでもない)のに学習コストが高い
モノを選ぶのは時間のムダです。
:::

### そこで Vue.js

現在、人気の面で、Vue.js が Angular(JS)を追い越しています。

## そこで Vue.js

ライブラリとしてのデザインが好みであり、Angular(JS) や 
React より、開発者 or 開発チームがコミュニティ・フレンドリー
に感じる、Reactとは異なり、デザイナー・フレンドリーな、
Vue.jsを 応援しています。