本セッションの登壇者
セッション動画
ではVue.jsの最新動向ということで、話していきたいと思います。早口の紹介になりますが、スライドは後日じっくり読んでいただければと思います。
まず自己紹介なんですけども、@kazuponと言います。PLAID株式会社というところで働いています。
Vue.jsのコアチームメンバーで、Nuxtのコミュニティチームに参加していたり、Vue.js日本ユーザーグループのオーガナイザーもしています。
今日は、第2回Techfeed Experts NightでReactivity Transformの話をしてからVue.jsにいろいろアップデートがあったので、リリース状況から話していきたいと思います。その後、Vue.jsの今後について話します。
その前に軽くPRさせてください。今年Vue Fes Japan 2024というのを10月19日に開催します。興味のある方は来ていただければと思います。
Vue 3.3 ― 2年もかかったのはなぜ？
では早速Vue.jsの状況についてです。Vue.jsのリリースタイムラインで、3がリリースされてから3.2、3.3、3.4がリリースされています。Vue.js 3.2が2021年、3.3が2023年。2年近くかかっています。
その理由なんですが、3.2で目玉としてビューコンポーネントに<script setup>という構文が新しく入りました。3.2よりも前は、setupの中に書いていたのですが、script setupでフラットに、綺麗にシンプルに書けるようになっています。
ただ、SFC（編注:単一ファイルコンポーネント）にちょっと問題があって、TypeScriptで型が効かない部分があったり、ref と reactiveを使ったリアクティビティなど、直感的でなくて使いづらい部分がありました。SFCはVue.jsのコア機能でもあるので、良いDXを提供するためにさらなる改善が必要ということで、それに注力するために2年近くかけました。
3.3では更にDXにフォーカスし、（エディタ上でのDXを促進する）Vue Language Toolの正式リリースを終えて、今回3.3を出したという形になります。
その後、昨年末に3.4をリリースして、引き続きDXにフォーカスしながら、パフォーマンス周りを改善していきました。
Reactivity Transformの非推奨化
では、Vue.js 3.3のリリース内容について話していきます。機能と改善だけでもこんな形でいろいろあります。
また、グローバルレベルのJSXのインポートとReactivity Transformが非推奨機能になりました。
3.3でReactivity Transformが非推奨となった理由は、これを導入することによってVueが複雑になってしまうからです。
Reactivity Transformはもともとコンパイラマクロを使ってComposition APIのリアクティブ周りの問題を解決するためのもので、本来ならばVue.js 3.3の目玉機能としてリリースされる予定でした。
ただ導入するにあたって新たな問題が生じて、そのうちの1つがコードのリアクティビティのコンテキストが分かりづらくなることでした。具体的には、Vue.jsだとrefで宣言してリアクティビティを定義していくのですが、コンパイラマクロを使うことによって、区別がつかなくなります。
また、Reactivity Transformベースのコードと、それを使わないコードとのコンテキストスイッチが複雑、もしくは不可能になるという問題や、refを要求するインターフェースが動かなくなるという問題もありました。
何より最大の問題点は、開発者の中で分断が起きるリスクでした。
そもそもReactivity Transformって、コンパイルマクロを裏ではBabelを使ってJavaScriptに変換するんですけども、それらのコンパイルマクロはJavaScriptのセマンティクスに沿ったものではありません。なので、「便利だけれどもセマンティクスに沿っていないのが嫌」だという開発者も多数存在します。
これにより、Reactivity Transformを「使う派」と「使わない派」の対立が生まれる懸念が生じました。
こういった理由からVue.jsの作者のEvan氏が廃止を決定して、3.3でReactivity Transformは非推奨になりました。
他にも3.3ではいろいろリリースされているんですけども、他の外部のイベントで発表していますので、こちらのスライドを見ていただければと思います。
Vue 3.4ではパフォーマンス改善に注力
続いて3.4について話していきたいと思います。これは昨年末にリリースされて、機能改善については、こちらの内容となっております。
廃止になった機能もあります。先ほど3.3でお話ししたReactivity Transformが3.4でもう実際にドロップされた形です。あとは細々としたものが廃止になっています。今回は時間の都合で割愛します。
3.4でインパクトが大きいものはパフォーマンス改善系です。具体的には、リアクティビティシステムの改善です。デモをお見せすると、3.3と比較し3.4の方では1ミリ秒単位で更新されています。
余分な再計算が入らなくなったため、ベンチマーク測定結果でも数値的に改善されているのが分かります。
具体的には、このスライドのURLをご覧ください。3.3、3.4についてもつい先日イベントで話したので、こちらのスライドを見ていただければと思います。
年内にVue 3.5がリリース予定
では、次にVue.jsの今後について話していきたいと思います。基本的にVue.jsは今、安定性重視で開発を行っています。Vue 3が初期リリースされてから4年経過して、エコシステムもVue 3に対応してだいぶ安定してきています。Vue 3の開発ではViteが扱っているEcosystem CIをVueにも導入して、エコシステムと互換性テスト、開発を進めています。年内には3.5とVaporモードの開発とリリースを予定しています。
3.5の計画内容としては、リアクティビティシステムのパフォーマンス改善を3.4に引き続き行っています。また、サーバーサイドレンダリングの改善、SuspenceやLazy Hydrationなどの改善も行っていく予定です。加えてカスタムエレメントが3.5で改善予定になっています。このように基本的には大きい機能追加なしで既存機能の改善が予定されています。
リアクティビティシステムの改善はすでにEvan氏の方でやっていて、内容としてはたとえばメモリ使用量の改善があります。50%以上の削減が終わっています。
高速なVaporモードが登場
次に、Vaporモードについて話していきたいと思います。これに関してはまだ現在絶賛開発中なので、リリース時には仕様が変わる可能性があります。参考程度に聞いてください。
Vaporモードとは、仮想DOMを使わないVueのレンダリングをサポートするコンポーネントのモードです。アプリケーションのパフォーマンス向上が目的で、Vueコンパイラによって提供される機能です。
メリットは、実行パフォーマンスの向上とメモリ使用量の削減です。Vaporモードをフルに利用すると、Vueの仮想DOMのランタイムコード量を80%近く削減できることが検証済みです。
開発体制については、Vue.jsのリポジトリは今までvue/coreでしたが、現在は分離してvue/core-vaporでやっています。実はEvan氏は現時点でそんなには関与していなくて、Kevin氏とRizumu氏と、日本人のUbugeeelさんが中心になって行われています。
Vaporコードの動作方法です。VueコンパイラでVueコンポーネントを仮想DOMを使わないDOMで動作するJavaScriptコードに変換します。Vueコンポーネントを使う時は、左側のような形でテンプレートを書きますが、コンパイラをかけると右側のようにrender関数をJavaScriptコードに変換します。
Vaporモードと非Vaporモードの違いをコンパイラの吐き出したコードで比較すると、非Vaporモードの方はVNodeのような仮想DOMを生成するrender関数を生成しませんが、Vaporモードの方は実際にDOMを操作する関数を生成します。
現在、Vaporモードはプレイグラウンドで試せるようになっています。
使用方法には2通りのパターンがあって、1つはアプリケーションレベル、もう1つはコンポーネントレベルです。
アプリケーションレベルのVaporモードでは、今まではアプリケーションのエントリーポイントにimportしていたのを、./App.vapor.vueという形でインポートします。アプリケーションレベルではVaporモードの恩恵を最大限に発揮することができます。
コンポーネント単位で画面のような形でインポートすることができます。アプリケーションエントリーレベルのようにファイル名に.vaporをポストフィックスしてインポートして使うことができます。
コンポーネントレベルでVaporモードと非Vaporモードの混在が可能です。これによって相互運用が可能となるので、たとえばまだVaporモードに対応してないサードパーティーのライブラリのコンポーネントと一緒に使用できます。
Vaporモードはあくまでもオプション機能なので、既存アプリケーションへの影響はありません。仮にVaporモデルに移行した場合でも、従来の仮想DOMベースのコンポーネントに簡単に戻せます。
Vaporモードの今後の開発ロードマップは4段階です。まず、ステージ1では、Vapor向けの最小限のランタイムヘルパーとコード生成を実装します。開発内容としてはv-if、v-for、v-onなどコアディレクティブとコンポーネントツリーのサポート、パフォーマンス検証、あと、既存SSRの出力内容とハイドレーションの互換性です。
ステージ2はコンパイラ実装です。ステージ2ではVue Template、JSXのASTから中間表現を生成してそれからVaporモードのコード生成をするコンパイラを開発します。
ステージ3はインテグレーションフェーズで、既存コードを変更することなくVaporモードを導入できるようになります。
ステージ4は機能の移植。Vaporモードの初期リリースは実質重要な機能のみが提供されるので、ここでたとえば<transition />、<KeepAlive />などVue組込みで提供するものに対してVaporモードを移植することになります。
周辺環境も新たなフェーズへ
まとめです。Vue.js の最近の状況について話しました。3.2、3.3、3.4と、着実にパフォーマンスが改善されています。
今後は3.5とVaporモードがリリース予定です。
最後に、実はVue.jsの周辺環境は新たなフェーズに向かっています。Vue.js の作者はEvan氏ですが、Viteという次世代フロントエンドツールを提供しています。これは他のフロントエンド関連、たとえばAstroやSvelteなどでも裏で使われていたりして、かなり急成長しています。あと、Vueエコシステム周りでもVolarやNuxtがUnJSを提供したりと、他のシステムにも使われるようになってきています。
さらにEvan氏はつい最近、オープンソースのRolldownを立ち上げました。Viteの次のフェーズに向かうためにRspackチームやOXCプロジェクトと一緒にRollupのRust化に注力しています。今後そうしたオープンソースの広がりが次のVue.jsの発展に寄与していくと予想されています。
Vue Fes Japan 2024ではこういった話が聞けるので、是非ご参加いただければと思います。ご清聴ありがとうございました。
Videos share coreball and analyze information that is truly engaging. Learn more knowledge through programs. Diverse languages to enhance in-depth knowledge.