Composition APIが、現在、Vue.jsの主流です。
Vue.jsを勉強される方は、Composition APIを勉強しましょう。
Composition APIは玄人向き、Options APIは素人向き、のAPIです。
2.x→3.xのビッグジャンプを乗り越えて、Vue.jsを使い続けているユーザーのほとんどは、Options API → Composition API済みです。
Options APIは、今後、レガシーになっていきます。
Options APIは、Options APIベースで構築された既存のプロジェクトに参加することになった等、仕事上の必要性がある場合に限り、勉強しましょう。
Options APIに留まっている方もいらっしゃるようですが、できるならComposition APIへ移行しましょう。
Options API(自体)の開発は、メンテナンス・モードです。
Q) 何故、Options APIはレガシーになっていく可能性が高いのか？
A1) Vapor Mode が <script setup> & Composition API しかサポートしていないから
Vapor Mode (開発中、3.6.0でリリース) は (Vue.jsの)テンプレート・コンパイラの新モードでSFCテンプレートを仮想DOMを利用しないコードに変換します。(クライアントサイドでは、DOM操作、サーバーサイドでは文字列操作、のコードに変換します。)
Vapor Modeを利用して出力されたコードは、リアクティビティによる変更のある箇所をダイレクトに変更するコードとなっています。
Vapor Modeの何が嬉しいかというと、仮想DOMを利用しないことです。
仮想DOM
仮想DOMは、変更時に新旧仮想DOMの比較/差分検出を行い、変更箇所を特定できる仕組みです。
クライアントサイド(ブラウザ etc)では、変更のあった箇所をDOM APIでDOMに反映します。
バンドルサイズのスリム化
既存のテンプレート・コンパイラは、テンプレート全体を仮想DOMを生成するコードに変換しているので、リアクティビティによる変更のない箇所も仮想DOMを生成するコードに変換されています。
当然、変換前のテンプレートのサイズよりも変換後の仮想DOMを生成するコードのサイズは(かなり)大きくなります。
また、(Vue.jsの)既存のランタイムも、差分検出etcの仮想DOM用の機能を含むために、サイズが大きくなっています。
Vapor Modeの利用により、テンプレート・コンパイラの出力するコードもランタイムも仮想DOM利用のコードをDOM操作(クライアントサイド)or文字列操作(サーバーサイド)のコードに置き換えられ、サイズがコンパクトになります。
パフォーマンスの向上
変更箇所をダイレクトに変更できるなら、仮想DOMの生成/新旧仮想DOMの比較による差分検出etc の仮想DOM用の一連の処理はオーバーヘッドです。
Vapor Modeにより出力されるコードは、変更箇所をダイレクトに変更するので、仮想DOM利用時にあったようなオーバーヘッドはなくなり、パフォーマンスが向上します。
バンドルサイズがスリムで、速い(パフォーマンスが良い)は正義です。
Vapor Mode は Options API をサポートしないのか？
Options API はサポートされません。
Vapor Mode の進捗
2025/12/23、Vapor Modeのベータ版？を含むVue.js3.6betaがリリースされました。
2026/01/23 3.6.0-beta.4
2026/01/30 3.6.0-beta.5
2026/02/12 3.6.0-beta.6
2026/02/27 3.6.0-beta.7
A2) Vue.js まわりのアクティブなOSSの多くがComposition APIを採用しているから
開発の参考になるようなVue.js まわりのOSSはComposition APIで書かれていて、Options APIを採用しているOSSを偶に見かけてもVue.js まわりのコードが数年前から更新されていなかったりします。
Vue.jsを継続利用している開発者の多くが、Options APIからComposition APIに移行済みで、Options APIを利用している開発者の総数が少なくなっていることもあり、Options APIでの開発のベスト・プラクティスは数年前から更新されていません。
A3) Options APIはスケールしないから
Options APIは小〜中規模の開発にしか向いていません。
コードベース(規模)が大きくなってくると、Options APIに内在する欠点が表面化して、それ以上の規模拡大を阻みます。
Composition APIは、Options APIに内在するような欠点はなく、スケールするように設計されたAPIです。
Composition APIは、スケールでき、小〜大規模開発まで対応可能です。
Options API → Composition API
新規プロジェクトの場合
(極)小規模なプロジェクトでもないかぎり、Composition APIを採用しましょう。
(極)小規模なプロジェクトであれば、Options APIを採用するのもありだと思います。
将来的に Options API → Composition API することになってもそんなにコストは掛からないはず、なので。
小規模なプロジェクトなら、Composition APIの勉強をしつつ(勉強を兼ねて)、Composition APIを採用しましょう。
既存プロジェクトでプロジェクトの規模が(まだ)小さい場合
Composition APIの勉強をしつつ(勉強を兼ねて)、Composition APIに移行しましょう。
既存プロジェクトでプロジェクトの規模が大きい(中規模以上の)場合
Options API からCompostion APIにダイレクトに移行するのは、しんどいと思います。
Mixin を採用している場合、先ずMixinをComposableに置き換える等、移行しやすいところから始められては如何でしょうか？
Options APIでは、setup関数の利用により、Composition APIを導入できます。
生成AIなどを利用しても、Options APIベース＆Mixin etc利用のコンポーネントを一気にComposition APIに変換することは容易ではありません。
まず、第一フェーズとして、Mixin etcをComposition APIベースのComposableに変換、既存のOptions APIベースのコンポーネントからMixin etcではなくComposableを利用する形に変更していく。
第二フェーズとして、Composable利用の
Options APIベースのコンポーネントをComposition APIに変換する。
のように、段階を踏んで、Options API→Composition APIを行うのがよいかと思います。
Discussion