はじめに
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、になっていく感があります。
SSR(Server Side Rendering)に手を出すと、更に
学習コストが嵩みます。
Next.js やRemixを採用することで、SSRの学習コスト
をある程度 抑制可能です。
コンポーネント、一つとっても、Reactでは、クラス
コンポーネントと関数コンポーネントの２種類あります。
Reactのクラスコンポーネントと関数コンポーネント は
別物であり、ライフサイクルetcが異なる仕様となって
います。
https://zenn.dev/yodaka/articles/7c3dca006eba7d
Reactのクラスコンポーネントと関数コンポーネント は
挙動が異なります。
Reactでは、実行時に、(ランタイム上で)クラス
コンポーネントはオブジェクトとして振る舞い、
関数コンポーネントは関数として振舞います
(そのハズ)。
また、Reactでは、関数コンポーネントの記述に、
React.FCで定義する/定義しない の ２パターン、
あります。
React Hooks 登場前は、クラスコンポーネントが主流、
React Hooks 登場後は、関数コンポーネントが主流、
と なっているようです。
React Hooks は、関数コンポーネントからReactの機能を
利用するための機能(関数群)であり、React Hooks登場前
までクラスコンポーネントでしか利用できなかったReactの
機能群を関数コンポーネントで利用できるようにしました。
関数コンポーネント記述用の API に Hooks...。
React Function API とかの命名のほうが、名が体を表して
いたのでは...。
React Hooks 登場後、Reactのクラスコンポーネントは
後方互換用と化しています。
公式には 関数コンポーネントが推奨されていますが、
Reactでの 関数コンポーネント or クラスコンポーネントの
選択はユーザー次第です。
基本、関数コンポーネントのみ勉強すればよいですが、
クラスコンポーネントについても知っておく必要は
ある ようです。
React Hooksが登場してから、React に機能の追加etcが
行われる度に(React Hooksに)関数が追加されていっている
ので、学習コストが改善される方向には向かっていない
ようです。
関数コンポーネントを採用している(React Hooks登場後
からの/React Hooks登場後 書き換えた)プロジェクト、
クラスコンポーネントを採用している(React Hooks登場
前からの)プロジェクト、関数コンポーネントとクラス
コンポーネントが混在しているプロジェクト、が存在
している状況(のよう)です。
(プロジェクト内で、基本、関数コンポーネントに統一
していても、外部のコンポーネント(集)がクラス
コンポーネントを利用している(外部のコンポーネント
(集)がプロジェクトの方針とは合致していない)ケースも
想定。
(別プロジェクトで作成されたコンポーネントの流用も...。)
React: 周辺ライブラリの充実とデファクトの欠如
React、周辺ライブラリが充実しているのは結構なこと なの
ですが、車輪の再発明も多く同じ用途に複数のライブラリが
存在していて、更に、そこに、React Hooks / 制御 / 非制御
コンポーネントetcも絡んでくるので、カオスな感じです...。
フレームワーク+周辺ライブラリ(状態管理ライブラリetc)の
組み合わせ、で、学習コストが変動し、追加の学習コストも
発生します。
Reactベースのフレームワーク
Next.js、Remix etc があります...。
Next.js と Remix、どちらもReactベースのFWですが、
書き味は(それなりに)異なります。
Next.js は SSR/CSR/SSG/ISR、Remixは、デフォルト
SSR、SSR/SPA(2.5.0にてSPAモードを導入
(experimental))、設計思想自体、異なります。
似て非なる感じです。
Next.js、Remixのシンプルさをみて？ ver.13 でApp
Routerを導入、デフォルトにして、デフォルトSSRの
方向に舵を切っています。
状態管理ライブラリ
(独自の?)Redux/Zustand、React Hooks
ベースの Jotai/Recoil etc、があります。
デファクトは存在せず、Redux/Zustand/Jotai etcの何れかが
Reactを採用したWEBアプリの開発チーム(会社)毎の(のコア・
メンバーの)好みで採用されている状況のようです。
Metaのエンジニアによる開発でMeta発であること
から、RecoilがReactの状態管理ライブラリの
デファクトになるのではないかと思っていた時期も
ありましたが、実験的なライブラリとして開発され
続け、安定版(1.0)に達しないまま、現在は開発が
停滞しています。
Recoil、主たる開発者を含め、開発メンバーが全員？
Metaからレイオフされたので、検討されていた外部
コントリビュータの受け入れも暗礁に乗り上げ、
プロジェクトとしては死に体のようです。
https://github.com/facebookexperimental/Recoil/discussions/2171#discussioncomment-7979532
React: トータルの学習コスト
後述のAngularJS(1.x) より、ReactのほうがWEBアプリを
構築する上での トータルの学習コストは高いと思います。
世の中には「学習コストが高いモノを態々選んで勉強
する(複雑な***を理解できている俺・私って偉いと
思っている？)方もいらっしゃるようですが、必要も
ない(＆自分の好みにフィットしているわけでもない)
のに学習コストが高いモノのほうを選ぶのは時間の
ムダです。
React の開発チームは、初心者or初級ユーザー(利用開発者)に
とって理解し易く扱い易くする方向には向いていないようです、
ドキュメント・サイトをみてもそんな感じです(無駄に小難しく
書かれている箇所があります)。
[比較]
Vue.js には、関数(で定義する)コンポーネントのみが
あります。
Vue.js の 関数コンポーネントには、Options API での記述、
Composition APIでの記述、の２種類があります。
Options API は、(現状の)Vue.jsのコンポーネントの内部表現
(データ構造)をそのまま表出させた感じのAPIで、
コンポーネントと密結合していて、柔軟性に欠けていましたが、
Composition API は、コンポーネントとは疎結合の柔軟性＆
自由度の高いAPI となっています。
Composition API/Options API、どちらで記述しても
コンポーネントの挙動に違いはありません。
Vue.js のコンポーネントは実行時に(ランタイム上で)
オブジェクトとして振舞います。
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 は 後方互換性のために
残されている印象です。
周辺ライブラリも、コンポーネント・ライブラリを除けば、
車輪の再発明は少なく、それらのどれかの採用に伴う学習
コストも、微々たるモノな感じです。
Vuejs2.xのクラスコンポーネントは JavasScriptの
Class が シンタックスシュガーであるのと同様に、
Options APIによるコンポーネント定義のシンタックス
シュガーでした。
2.xでは、クラスコンポーネントが公式にサポート
されては いたものの、Vue.js 本体とは別に提供
されているライブラリ (Vue Class Component
(+ Vue Property Decorator)) を利用する
必要がありました。
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ベースのフレームワーク同等に
なっています。
Nuxt3は、根本的なアーキテクチャの見直し(再設計)が
行われ、また、その開発と並行して、足回りとなる
ライブラリの開発も 行われた結果、3.0.0のリリース
までに時間が掛かりました。
3.0.0以降は、インクリメンタルな開発へとシフトして
います。
状態管理ライブラリ
Vue.jsは状態をコンポーネントが持っていて、コンポーネント間
での状態の(値の)受け渡しもできるので、必ずしも、状態管理
ライブラリを利用する必要はありません。
グローバルに 状態を管理したい/管理する必要のある 場合には、
Pinia (orVuex(for Vue.js2.x)) or useState (Nuxt3を
利用している場合、React の useState とは別物) があります。
Pinia が状態管理ライブラリのデファクト・スタンダード
となっています。
React: 複雑さのインクリメンタルな増大
React も、Anguar(JS)同様、クライアントサイドに、サーバー
サイドの設計(思想)を持ってきている気がしています。
React は、JSセントリックで、WEB標準 の上に WEB標準 とは
異なる React独自の世界(React World)を構築している感が
あります。
React は、Vuejs の 2.x→3.x での Composition API 導入の
ような大きな変更はなく、漸進的(インクリメンタル)な変更が
続けられているものの、漸進的であるが故？に、段々、(周辺
ライブラリを含めた上での)複雑さが 増していっている気が
しています。
シンプルさがウリ だったはずが、WEBアプリ構築における様々な
要件にインクリメンタルに対応しているうちに、表面上、シンプル
に見えるけれど、中身はそれなりに複雑で、その挙動をある程度、
ユーザーが把握しておかないと、思わぬハマりどころがある、に
なってしまっている感じがしています。
発表から2年以上経つにも関わらず、未だ開発フェーズの
最適化コンパイラ React Compiler(旧 React Forget)、
Meta社内の一部で試験導入(テスト)が行われていて、
先日、開発途中ではあるもののオープンソース化されたので、
上手くいけば、一年以内に正式版がリリースされ、Reactの
煩雑さの解消 に一役買うようになるかもしれません。
React Compiler、Vaporwareに近い印象です、複数人
のプロフェッショナルがフルタイム？で数年間 開発して
実用できるレベルに未だ達していない...。
React Compiler、Babelプラグインとして実装されて
いて、ビルド時にコンパイラで静的解析→ useMemoや
useCallbackを利用すべきコードをuseMemoや
useCallbackを利用したコード相当のコードに変更する
形になっています、「言うは易し行うは難し」
ですね...。
変更する適切な箇所を実行時情報なく、静的解析のみで
判断するのは難しい気がします...(Gemini(旧Bard)
etcの)AIを利用しても、適切でない箇所が変更される
過剰な変換or誤変換をゼロにはできないような...。
[比較]
2.x→3.xでのビッグジャンプ(Options API→Composition API)以降、
Vue.js まわりで 複雑さの上昇はないように思います。
2.x→3.xでのビッグジャンプ(Options API→Composition API)は、
ユーザー(利用開発者)に痛みを強いるモノでしたが、2.xではできなかった
(コードの)最適化etcが可能となり、2.xに較べて3.xは大幅にパフォーマンス
が向上しています。
Vue.js の 2→3 での Composition API の導入を伴う
変更は、2系の設計時点ではみえていなかった 設計の問題
点/２系が利用されること(&２系のメンテナンス)でみえて
きた課題 を解決するために ライブラリの再設計が行われた
結果だと考えています。
Vue.jsの開発チームは、3系で、2系をインクリメンタルに
改善していく方向ではなく、今後を見据え、再設計/再実装
を選択しました。
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以降、
ビッグバン・リリースは行わず、段階的に変更を行っていく方向へと
シフトしています。
3.x以降は、新機能はまず、フラグにより有効化しないと
利用できない機能として試験的に導入され、十分に安定
した時点で新(マイナー)バージョンにてデフォルトで利用
できるようになります。
Vue.jsを採用したプロジェクトでの2.x→3.xへの移行が
Vue.jsまわりのエコシステムを構成する各種プロダクトの
3.x対応を待たなくてはならない状況も発生していました。
Composition API は、Options API と較べて、一見、複雑に
みえますが、慣れてしまえば、Options API より自由度が高く
柔軟に書け、コードの見通しもよくなります。
インクリメンタルな改善ではインクリメンタルに複雑さが
増大してしまう懸念があるor インクリメンタルな改善で
インクリメンタルに複雑さが増大してきている 場合には、
大きな変更を伴うビッグバンリリースで、インクリメンタ
ルな複雑さの上昇を避ける or インクリメンタルな改善で
上昇してきた複雑さをリセットするのもありなのではない
かと個人的には思います。
React: RSC(React Server Component) & Actions
React の RSC、Actions の登場もReact の(周辺ライブラリ
を含めた上での)複雑さの上昇に拍車を掛けています。
サーバーコンポーネントであるRSCは、サーバーサイド
でコンポーネントの組み立てを行い、クライアント
サイドでは描画のみを行います。
サーバーサイドでは、DOMはないので、比較・差分抽出→
差分のみの反映のステップ自体、(必要)ありません。
サーバーコンポーネントの場合、クライアントサイドでは、
サーバーサイドで組み立てた結果を受け取り、その描画
のみを行います。
クライアントサイドではなく、サーバーサイドで
コンポーネントの組み立てを行うことで、
クライアントサイドは軽くなります。
サーバーコンポーネントは、クライアントサイド/
サーバーサイドの双方で利用できます。
RSC、Reactのオフィシャルでは unstable(α or β扱い)なのに、
RSCを採用した Next.js の App Directory (App Router)
では stable になってるのもカオスな感じです。
Actions も、Reactのオフィシャルでは unstable、
Next.js14では Server Actions が stable
になっています。
RSC / Actions自体、発展途上の仕様/実装のように思えます。
Actions は Next.js由来?のServer Actionsを拡張し、
クライアントサイドにも対応させた 機能で、React19で
stableになる予定です。
既存のReactの状態管理ライブラリは、クライアントサイドでの
状態を管理するモノで、サーバーサイドでの状態を考慮した
モノはないので、RSCの状態も？管理できる？新しいライブラリ、nrstate/nrstate-client etc が登場してきています。
RSCまわりを含めた状態管理にまだ定番(デファクト)がなく、
当分、カオスな状態が続くように思います。
RSCを、現状、実装している有名どころのReactフレームワークは
Next.js のみで、その実装(App Routerまわり)も、stable
扱いになってはいるもののパフォーマンス上の問題が残っていて、
こなれているとは言えない状況のようなので、RSCの本番投入は、
パフォーマンスetcの計測を行った上で判断するのがよい状況の
ようです。
RSCの仕様、Next.js開発元のVercel社が仕様策定に
関わっていて、Remix開発チームは関わっていないこと
もあり、Remix開発チームのメンバーが試してみると、
RSCがRemixの現行の実装よりも遅いことがわかった、
ので、RSCが安定する(実装/仕様がこなれてくる)まで、
Remixでの採用は見送られていました。
下記は、2021/12時点でのRemix開発チームメンバーに
よるRSCの評価記事です。
https://remix.run/blog/react-server-components
RSC、サーバーサイド/クライアントサイド、それぞれで
動作するコンポーネントを、Reactのコンポーネント・
ツリー上でどちらも扱えるように、サーバーサイドで
動作するコンポーネントについて規定した仕様のような
ので、デフォルトSSRのフレームワークであるRemixに
とって優先順位が高くはなかったようです。
v2 のリリースアナウンス(公式ブログ)にてRemixの
RSC対応に関する続報がありました。v3でのRSC
サポートに向けて開発が開始されているようです。
Remix開発チームはRSCの安定化に向けて協力していく
とのこと。
Remixのloader/action まわりはv3でのRSCサポートで
見た目が多少変わる模様。
[比較]
Vue.js3ベースのNuxt3では、クライアント(サイドのみで動作
する)コンポーネントか、サーバー(サイドのみで動作する)
コンポーネントか、クライアントサイドとサーバーサイドの双方
で動作するコンポーネントか、を意識してコードを書く必要は
ありますが、ReactのRSCまわりのような煩雑さはありません。
React: CSSの扱い
Reactを採用したプロジェクトでは、様々なスタイリング手法
が利用されています。
CSS、CSS Modules、CSS in JS、CSSフレームワーク
(Tailwind etc) です。
その１つである CSS in JS では、JavaScript に CSSの
プロパティを記述します。
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)も
勿論利用できます。
参加するプロジェクトで経験のないCSSフレームワーク
が採用されている場合には追加の学習コストは発生
します。
CSSを知ってさえいれば、CSSフレームワークの学習
コストはそんなに掛からないはずです。
Pinceau や Panda CSS を用いることで、CSS in JS/TS を採用
することは可能です。
仮想DOM(vDOM)高速道路時代の終焉
ブラウザのUIレンダリングまわりetcの改良もあり宣言的UI
を仮想DOMを用いずDOMのみで実装する Svelte/Solid.js が
ベンチマークで Vue.js同等以上/React以上 の性能を叩き出す
状況になっていて、vDOMツリーの比較・差分抽出により差分
のみをDOMに反映する技術であるvDOMのパフォーマンス面
での優位性は、現在、なくなっています。
ベンチマーク結果は Solid.js公式サイトのトップページに
あるのが ほぼ最新で参考になる かと思います。
React開発チームは、現在、(脱仮想DOM etcによる)
クライアントサイドでの高速化を目指すのではなく、
React Server Component(RSC) / Server Actions
による SSR強化の方向に注力してい(るようにみえ)ます。
React開発チームからは、現在、クライアントサイド(CSR)
での高速化(性能強化)に関する何の方向性も公には
示されていません。
[比較]
Vue.js開発チームは、現在、脱仮想DOMによる高速化を目指し、
仮想DOMを利用しないSFC(Single File Component)
コンパイラの新モードVapor Modeを開発中です。
Vapor Mode は、CSR/SSR の両方に対応しています。
Vue.js本体ではありませんが、Nuxt3 において、
サーバーコンポーネントに対応しています。
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の戦略的に重要な
プロダクトではなくなっている可能性が高いです。
Metaにとって Reactは 外部に公開しているものの
あくまで内製ライブラリ であり、外部に公開する
メリットは(Metaにとっては)あまりない(という
個人的な)印象です。
強いてメリットを挙げるなら、Metaの技術力のアピール
くらい？(外部ユーザー(利用開発者)からのフィード
バックを重視している感じがしないので。)
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(本体)の開発を主導する感じに
なるのがユーザーにとってはベター？
Vercel、Svelteの原作者である Rich Harris氏を雇用
していて、氏はフルタイムでSvelteの開発を行って
います。
Vercel、(会社として)React(本体)の開発の主導権を
握りにいける状況になっても握るつもりはないような気
もします。
握った場合に掛かるコストにメリットが見合っていない
気がしますし。
Meta は、PHPのパフォーマンスetcに満足できなくて、PHP似の
別言語Hackを開発・採用するくらい、パフォーマンス重視な企業
文化があるので、パフォーマンスでの優位性がないに等しくなって
いるReactへの社内でのコミットメント・リスペクトが低下して
いても何ら不思議ではありません。
Reactが社外で広く利用されていることもあり、React
を社内利用することによる他社に対する優位性はなく、
また、MetaはReactから何ら収益を得てはいないので、
パフォーマンスでの優位性がなくなっている現在、
MetaがReactの改良に積極的に投資し続ける
メリットはないに等しくなっています。
Metaが、今後、Reactの改良に積極的に投資(資金投入)
することはないように思えます。
Metaの今後のReactへの投資はReactを採用した社内
既存プロジェクトのためのメンテナンス・モードでの
消極的投資に留まるのではないかと。
シンプルさがウリだったハズが、トータルすると
シンプルとは言えなくなってきているReactまわりの
現状もあります。
シンプルではないということは、WEBアプリに採用
した場合の開発コストが嵩む、ということでも
あります。
開発コストが嵩む上にパフォーマンス上の優位性もない
に等しい、では、MetaがReactの開発にコミットし
投資し続けることは難しいハズ。
Metaのような企業がOSSの開発を主導している場合、
経営上の決定により、社内の開発チームが縮小/廃止
となる可能性があるので、注意が必要です。
Metaが社内で React に代わるライブラリ(React
互換？)を内製し(はじめ)ていても何ら不思議では
ないです。
大企業が開発/後援しているからといって盤石では
ありません、ハシゴを急に外される可能性を意識
しておく必要があります。
Meta は 社内で開発した GraphQL の推進団体GraphQL
Foundation から離脱済みです。(GraphQLから手を
引いているor距離を置いている印象です。)
Mataの公開しているオープンソースに、Go製のOR
ラッパent etcがあることからわかるように、
MetaはサーバーサイドでGo etcも採用していて、
ReactのRSC & ServerActionsを全社的に推して、
JS(TS)でサーバーサイド(全て)を構築する気はない
ようです。
Remix を開発している会社を買収した Shopify も、
バックエンドフレームワークとしてのRails(Ruby)の
改良に投資していることからもわかるように、全社的に
Remixを推して、React + JS(TS)でサーバーサイド
(全て)を構築する気はないでしょう。
Meta も Shopify も フロントエンド(+ BFF) +
バックエンド(WEB API)の構成から踏み込んで、
サーバーサイドを含め(全て)JS(TS)で構築する方向
には向いていないのです。
vs Angular(JS)
設計の古さ of 1.x
AngularJS は、クライアントサイドに サーバーサイドの設計を
そのまま持ってきている感があります。
データをグローバルな変数で扱うスコープ($scope)がその証左
の一つだと考えています。
AngularJS(1.x)のCotroller駆動より、Vue.jsのModel駆動、
のほうがクライアントサイド(UIアプリ)では、理に適っています。
AngularJS(1.x)は中・大規模開発には適さない と思っています、
大規模開発を指向してはいるものの、中・大規模開発に向いていない
のです。
AngularJS(1.x)は、2009年に発表され、発表時の設計で、
2012年に1.0.0がリリースされたFWです、2009年当時とは、
2012年にあったWebComponents仕様のW3Cでの策定開始、
でもわかるように、WEB開発の世界的な潮流が変化しています、
AngularJS(1.x)の設計は 既に現在のニーズとは乖離している
のです。
Railsに例えられること への疑問
AngularJSはRailsによく例えられますが自分はそうは
思いません。
似ているのは、フルスタック・フレームワークである点、
そのぶん勉強が大変な点、だけです。
Rails、初期学習コストはそれなりに大きいですが、それを
乗り越え、レールにのってしまえば、劇的？に開発時間を短縮
できます。
対して、AngularJS はそうではありません、初期学習コストを
乗り越えてもレールが敷かれていないため、劇的な開発時間の
短縮は望めない のです。
Railsは、2.xまでは、AngularJSと同様に１から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駆動 なんです。
個人的には、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)をステていたかもしれません。
Lit Element(Polymerの後継)に"Powered by Google"
の文字はありませんが、こちらもGoogle I/Oで発表された
Googleの戦略的？プロダクトで、Google駆動です。
Googlerが開発しているからGoogle駆動、
なのではありません。
Googleにより(戦略的意図のもと？)後援され
ユーザーコミュニティから切り離して開発され、
製品(情報を含め)がβテスト・フェーズになるまで
公開されないから、Google駆動、なのです。
Google駆動のOSSプロダクト は基本的に
βテスト・フェーズに入るまで(情報含め)
公開されません、このフェーズでは、設計は
既に固まって おり、OSSコミュニティが設計に
フィードバックを行うことは、まずできません。
Googleは秘密主義なので、Google駆動なら、
Google I/O等で(大々的？に)発表されるまで、
外部に情報が漏れることはまずありません。
Googleにとって、OSSコミュニティはテスター・
デバッガーに すぎないのではないか、と
思っています。
(GoogleはOSSに対して非常に理解があるように
思われていますが、 プロダクトをOSSとして
公開している他の企業と何ら変わりはありません...。)
企業が主導しているOSSは安心だと思っている方がいるよう
ですが、企業は営利目的なので、主導していたにしても
経営判断により手を引くケースは往々にしてあり、
そして、手を引かれたOSSは開発・メンテナンスする
人材がおらず、衰退･消滅していきます。
比較
Vue.jsの開発者である Evan You氏 は元Googlerですが、
Vue.jsの開発は、元々、氏の個人プロジェクト、であり、
現在は、チームでの開発体制となっています。
Vue.jsが個人プロジェクトであったことを引き合いに出して、
その将来に不安があるかのように文章を書く方もいらっしゃる
ようですが、Linuxが、元々、個人プロジェクトであったことを
知らないのか、と思います。Evan You氏に何かがあった、と
しても、開発を引き継ぐ個人なり企業なりが現れる、と
思っています。
2.0開発の迷走
2.0発表時の設計資料から察せられる通り、Angular(JS)
は2.0でかなり手が入り、1.xとはだいぶ変わること、が
確定していました。
既に大きなフルスタックフレームワークであり、2.0の
開発が どうなるかは未知数、革新ではなく下位互換に
重点を置きすぎる、と開発が停滞する可能性も
ありました...。
Angular2.0は、ES6＋ES7の一部＋α という、当時まだ
フル実装の存在していないJS仕様をターゲットに開発が
行なわれていたため、Angular(JS)の開発者にとっては
挑戦として面白かったのかもしれませんが、リリース
までには長い時間が必要となる懸念がありました。
ES6の実行環境の実装によっては、ある程度、実装が
進んだ段階で 大きな手戻りが必要になるリスクも
懸念されていました。
ES6→ES5の Traceur Compiler はあったものの、
ES6の実行環境が存在しなかったこともあり、実用
レベルには達しておらず、ES6 をフル？実装した
主要ブラウザが出揃うまで、正式版がリリース
されない可能性を高めていました。
ES6、仕様自体はfreezeされていたものの、仕様の
発行がレビュー及び実装からのフィードバックを反映
するため2015/06 に延期されたりもしました。
Object.oberve等、ES6では入らずES7以降へ持ち越し
となっていた機能のいくつかが、前倒しになる可能性が
限りなく低いです がありはしました。その後、
Object.oberve は仕様から取り下げられています。
フルスタックでありながら、ほんの数人のエンジニア
だけで開発されていることも開発の長期化を予感
させました。
2.0では、Web Comopnents仕様対応かつ自律した
UIコンポーネントを作成できることがGoogleブランドで
あり続けるためには外せないであろうことも、開発期間
の長期化を予感させました。
発表時点でリリース時期未定 となっていたことからも、
1.xとは大幅に変わるのは ほぼ確実でした が、
Angular(JS)2.0を1.xとそれほど大きく変えず、
早期リリースの実現を目指すことも考えられました。
その場合、Angular(JS)2.0は淘汰され消えていた
でしょう、変化を許容できないFWは生き残れません。
2015/03に Angular2.0の開発において大幅？な変更が
ありました。
当初、Traceur Compiler ベースでの ES6→ES5 変換を
利用してのES6ベースでの開発が予定されていましたが、
Traceurが期待するほどの変換能力を実現できていない
ことから、AtScriptという名前でES5ベースにES6の
一部機能をツッコんだAltJSを開発する方向に方針を
変更、更に、独自に開発していては開発に時間が掛かる
上に枯れて問題なく利用できるレベルに達するのにも
時間を要するためか、AtScriptの開発をMS主体で開発が
進められているTypeScriptに合流することが決定
されました。
Traceur Compiler(Google) → AtScript(Google) ⇨ TypeScript(MS)...。
Angular2.0開発における一番？の懸念材料であった
ES5・ES6両対応のための足回りの問題がこれで解消に
向かいました。
この開発方針の変更に合わせ、Angular2.0のリリース
時期も2015/03時点で来年と発表されました。
他の懸念材料は残っていましたが、GoogleがAngularに
投入している人的リソースから考えると、妥当な判断
だったのではないかと思います。Angular2.0はそれまで
大風呂敷を広げすぎていて、人的リソースから考える
と、開発期間が長期化せざるをえない状況に
ありました。
Angular2.0は、この発表時点で、設計段階か初期
プロトタイプ・フェーズにあったようなので、
この発表以降もリリース時期を守るためには予断を
許さなかった のではないかと思います。
AngularJS(1.x)のように、マニアックで場当たり的な
(そのようにみえる)設計にしてしまうと、もたらされる
恩恵に比べて 学習コストが非常に高くつくモノ、と
なってしまいます。
(以前書いた)上記の懸念もありましたが、2016/09/14、
Angular2.0がリリースされました。
2.0での開発の迷走が大きく影響しているのか、Angularは
2.0以降、革新的な機能の追加はないようにみえます。
2.0の仕様案？では予定されていた？vDOMの導入は、
早期リリース のために？見送られました。
Angularでは、結局、vDOM対応は行われず、代わりに、
バージョン9（2020/12リリース）から
Incremental DOMが導入されています。
Incremental DOM は 仮想DOM 同様、変更のみ
(DOMに)反映するための技術です。
Angular16(2023/05/03リリース)にて Solid.jsの
Signalにインスパイアされた機能 Angular Signals
も導入されています。
学習コストの費用対効果
学習コストが高いこともAngular(JS)のネックの１つです。
Angular(JS)は囲い込み型のFWなので、学習コストを掛けても
Angular(JS)を離れるとAngular(JS)の勉強で得た知識は
ほとんど役に立ちません。
Angularは、2.0以降、AngularJS(1.x)と別物であり、
1.xの知識やノウハウがほとんど役に立たない、ので、
移行コストは高くついたことでしょう。
既にAngularで仕事してるor仕事することが決まっている、
のでもなければ、今からAngularを勉強するのは時間の
ムダです。
これから仕事に活かすために勉強するのなら、Angularを勉強
するのではなく、別のことを勉強しておいたほうがずっと有意義の
はず。
Angularは高い学習コストを掛けることに見合うほどに
魅力的では最早なくなっています。
世の中には「学習コストが高いモノを態々選んで
勉強する (複雑な×××を理解できている俺・私
って偉いと思っている？)方もいらっしゃるよう
ですが、必要もない(＆自分の好みにフィット
しているわけでもない)のに学習コストが高い
モノを選ぶのは時間のムダです。
そこで Vue.js
現在、人気の面で、Vue.js が Angular(JS)を追い越しています。
そこで Vue.js
ライブラリとしてのデザインが好みであり、AngularJSライク
で、AngularJS や React より、開発者 or 開発チームが
コミュニティ・フレンドリーに感じる、React とは異なり、
デザイナー・フレンドリーな、Vue.jsを 応援しています。