2023/10/28に、Vue.jsのカンファレンスであるVue Fes Japan 2023に参加してきました。
こういった技術カンファレンスに参加するのは、（エンジニアとしては）初めてなので、学んだこと、感じたことを皆さんに共有できれば良いかな、と思います。
また、このような記事を書くのも初めてなため、至らない部分あるかと思いますが、暖かい目で見てもらえると幸いです。
目次
参加したセッション
まず、今回私が参加したセッションは以下の表になります。
| セッション名 | Speaker |
|---|---|
| キーノート | Even You氏 |
| 走りながらエンジンを交換する〜大規模プロダクトを成長させつつVue 3にするには〜 | 篠田 貴大氏 |
| 社内UIコンポーネントライブラリがエンジニアチームにもたらした本当の価値 | 山本 一将氏 |
| Nuxt 3ではじめるテスト導入戦略と初手 | 野崎 才門氏 |
| A New Nuxt | Daniel Roe氏 |
| Vue Language Serverから生まれたVolar.jsと、それが秘める可能性 | mizdra氏 |
| Deep Dive to UnJS and Nuxt 3 | Nozomu Iluta氏 |
| マルチスレッドフレンドリーなJavaScriptを求めて | 翠 / sapphi-red氏 |
| eslint-plugin-vueの現状と今後 | 太田 洋介 / ota-meshi氏 |
私が聞いたものはすべてセッション方式で、Speakerの話を聞く、というものでした。
別の会場では、ハンズオンやパネルディスカッションもありました。
海外Speakerの方の場合は、同時通訳も行なってくれ、トランシーバーのような同時通訳機を使って聞くことができました。
そのため、英語のリスニングができない自分でも、内容を理解することができました。
各セッションについて
では、これ以降、各セッションでお聞きしたことをかいつまんで、まとめていきたいと思います。
（ここでお話し（記載）されていないことは、私がうまくまとめられなかったものです。本当はもっと魅力的で有用なお話をされています。私の力不足により記載できなかったことが多々あることを前提にお読みください🙇♂️）
キーノート
Even You氏にとって、この2-3年は大変な年だったようです。
そして、その筆頭に上がるのが、Vueのアップグレードのようでした。
このセッションでは、そのアップグレードの際の反省点と良かった点を話してくれました。
間違いであった点
- 多くの小さい変更が重なってしまった。そして、それらを一度にすべて取り込んでしまったこと。
- deprecated → opt-in → reware という段階を踏むべきだった
- インパクトを過小評価していた。
- 内部ライブラリ依存が思ったより多かった。
- Vue3 coreとして、すべて一緒のリリースとしてしまった。
- これにより大きな変更が入ってしまい、印象が悪くなってしまった。
- そして、成果物の質をもっと高くしてからリリースをすべきだった。
良かったこと
- TypeScriptの導入
- composition APIを使うこと
- DXを改善することができた
そして、Even You氏はこう結論づけました。
Vue3は拡張性、パフォーマンスなど、よりよく成長しています。
もちろんエコシステムやUI Libraryもです。
今後については、安定性について重要視していみたいでした。
そして、Vue4, Vue5へと続く時に、移行を大変にしないようにしたい、ともおっしゃっていました。
このほかに、Viteの問題や、これからやっていきたいこと、ロードマップなども話してくれました。
ViteはRust化していきたいみたいですね。
走りながらエンジンを交換する〜大規模プロダクトを成長させつつVue 3にするには〜
内容としては、Vue2.7, @Vue/composition-apiを使っていて、絶賛機能追加もされているプロダクトを、影響を最小限に抑えて対応した、という話でした。
Vue2.7にバージョンアップする過程で@Vue/composition-apiを剥がすことになったのですが、さまざまな画面で呼び出されているため、単純に置き換えてしまうと特大P-Rになってしまいます。
そこで、解決策として、モジュールを作ることで影響を最小にし対応したとのことです。
ほかにもcreateAppの対応やmountの定義も変更されたようです。
（詳しい対応については、以下のリンクをご覧ください）
社内UIコンポーネントライブラリがエンジニアチームにもたらした本当の価値
内容としては、機能追加のためにフロントエンドエンジニアチームを結成したら、品質も高くなった、というものかと思いました。
プロダクトを開発している中で、UI/UXを加味しなければならない新たな機能追加が必要になったみたいです。
既存の開発では、フロントエンド専門のエンジニアがおらず、正しいコンポーネント設計ができていなかったようです。
そこで、これらコンポーネントの統制を取るために社内UIライブラリを作成しました。
この社内UIライブラリの開発によって、以下の点で開発に価値をもたらした、と発表していただけました。
- フロントエンド専用チームを作ったことで、妥協のないプロジェクト運営ができた。
- スタイルガイドに沿った、品質の高い実装を行えた。また、スタイルガイドがリファレンスにもなっていった。
- Storybookによるドキュメンテーションができた。これが、各チームの開発に浸透していき、そのような文化ができて行った。
感想としては、専門の職種を持つことで、そこに集中でき、注力することで成果物の品質向上や当事者の意識改革も行えることができたのかと思いました。こういった専門職は業務の細分化を招き、管理しづらい、役割が曖昧なままだと陳腐化してしまう、という欠点があると思いますが、上記のような利点もあるのだな、と思いました。
また、Storybookがデザイン確認だけでなく、コンポーネントのドキュメンテーションとして成り立っている例を知れたのも良かったです。
Nuxt 3ではじめるテスト導入戦略と初手
composablesにユニットテストを行った話かと思います。
"知識"単位で分割していたcomposablesに対して、テスト不足が露呈したため、nuxt-vitestを用いてユニットテストを行ったようです。
このライブラリを入れてみて、以下利点があったようです。
- 修正に対する心理的な負担が小さくなった
- フロントエンドでもテストを書く機運が高まった
- テストピラミッドの構築がやりやすくなった（つまり、今後のテスト運用がやりやすくなった、という意味かと思います）
A New Nuxt
Nuxt3開発を中心にお話ししてくれたと思います。
まず、Nuxt3は、書き直すことから始まったようです。 scope（何を書き直すのか）とtime（どれくらいかかるのか：工数）を決めることから始まり、エコシステムの重要性について考えていたようです。
Nuxtのエコシステムは、多くのモジュールとメンテナによって支えられており、NuxtをNuxtたらしめているものでもあります。
そして、内部コードに大きく依存していました。これももっとシームレスにしたいと思っていたようです。
そして、nuxt/bridgeの話に移り、nuxt/bridgeでは以下の対応されます。
- options → composables
- webpack → Nitro
- connect → Nitropack
- vue-meta → unhead
次は安定性の話です。
nuxt/ecosystem-ciによって、エコシステムを極力壊すことなく修正することができるようになったようです。
Speakerは、nuxt/telemetoryも開発しており、インタラクティブ性のあるserver componentsの対応やマルチアプリケーションへの対応などを最低限の哲学としているようです。
（nuxt/telemetoryついては以下参照です。）
そして、Nuxt v3.8についてです。
ここで聞き取れたのは、以下だけでした。。（すみません）
- nuxi modeの対応
- app manifest
- datafetcihg cashing
また、開発者体験にフォーカスを当てると、以下の点で向上しているようです。
nuxt/cliをnuxiで開発nuxt/devtoolsではタグごとでできるようになったnuxt/test-utilsでは、nuxt/nuxtリポジトリから外し、vitestと連携できるようにしたnuxt/connectnuxt/image- UIライブラリ
さらに、Nuxtのベストプラクティスも増えつつあるようです。
nuxt/a11ynuxt/authnuxt/assetsnuxt/scriptsnuxt/fonts
Vue Language Serverから生まれたVolar.jsと、それが秘める可能性
エディタの言語機能についてお話ししていただきました。
vscodeのコーティングの補助には以下機能があります。
- コード補完
- 定義移動
では、この言語機能はどのように実装されているのでしょうか。
この言語機能は、LSP(Language Server Protocol)に則った方法が周流となっています。
このコンセプトは、IDEがサポートしている各機能の標準化です。
つまり、LSPに従ってさえいれば、どの言語、IDEでも動くことを意味します。
では、Vue.jsではどのようなLSPとなっているのでしょうか。
Vue.jsはSFCなので、独自のLSPを持ちます。これをよしなにやってくれるのが、Volar.jsとなります。
（以前はvetur（ベター）でした。）
あるファイルの中に組み込まれている言語をEnbedded (programming) Language（組み込み限度）という。
vscodeのLSP実装資料より、2つのアプローチ方法があります。
その一つが、Language Servicesによるアプローチです。
（詳細は、下記リンクを見ていただきたいのですが、ここでサラッと説明すると、そのファイルを組み込み言語ごとのブロックに分けて、その各言語向けの「Service」というロジック部分で処理を行い、コード補完として結果を出す、ということになります。）
そして、このLanguage Serverを用いて、Vue.jsのLanguage Serverは実装されています。
ここで、登場してくるのが、Volar.jsです。
Volar.jsはveturとは別実装のLanguage Serverとして作られ、このコア機能がVolar.jsとしてOSSに切り出されました。
Volar.jsは組み込み言語のツールを作るためのフレームワークです。なので、Vue.jsによらず、やろうと思えば、様々な言語に対して適応ができます。
そして、Volar.jsのコアメンバーには、Astro.jsというWeb Frameworkを開発している方も参画されているので、Astro.jsにも使われています。
Deep Dive to UnJS and Nuxt 3
UnJSについて、お話ししていただきました。
UnJSとは、「unified javaScript」のことです。
（unifiedとは、一つにまとめられた、という意味です。）
エコシステムであり、1つのパッケージに対して1つの機能を持つため高品質です。
そして、哲学として、どちらかの言語しか使えない、というものは提供しない、としています。
そして、そのそれぞれが独立した開発が行われています。
では、そのUnJSがNuxtとどのように関わっているのでしょうか。
以下、見出しごとに記載していきます。
（GitHubリンクを貼っておきますので、興味のある方は見てみてください！）
CLI
citty（まだstableではない）
configuration
Nuxtlayersを実現しています。
server
どこでも動くWebサーバーです。
Nuxtをビルドすると、.output/serverが生成されますが、それがnitroの成果物になります。
minimal H(TTP) Framework
サーバー通信。
Fetch
better fetch API。
nuxt2ではaxiosやkyを使っていたかと思いますが、nuxt3ではofetchを使えば良いです。
SEO
マルチスレッドフレンドリーなJavaScriptを求めて
JavaScriptでマルチスレッドを実現させる方法についてお話ししていただきました。
まず、マルチスレッドとは、処理を並列にすることで、処理時間を短くすることができます。
JavaScriptでの利用方法ですが、そもそもJavaScriptはシングルスレッドで実行されるため、マルチスレッドはできません。
ということで、マルチスレッドとして動作させるには、回避策が必要になります。
この回避策には、以下2点があります。
- JavaScriptエンジン外で実行する
- 複数のJavaScriptエンジンのインスタンスを実行する
単純に別プロセスを実行します。
- Node.js: cluster, worker threads
- ブラウザ/Deno/Bun: Web Worker
今回は2について説明してくださいました。
この2には、難点があり、参照の共有ができません。
これにより、以下のデメリットがあります。
- スレッド間のやり取りのたびに、コピーによるオーバーヘッドが発生してしまい、逆に処理時間が長くなってしまう。
- スレッドの境界を超えた後では、参照での比較ができない。
- コピーできないもの（関数、クラスの情報など）あやり取りできない
- ArrayBuffer/SharedArraybufferが扱えるのはバイト列のみ
ということで、これらを考慮した場合、理想的な設計とするには、スレッド間の依存を減らすことが重要になります。
以下3点での依存を減らす必要があります。
- グローバルで共有する状態への依存
- 関数を持つオブジェクトへの依存
- 参照での依存
既存プロジェクトへの適用箇所
（メモできなかったです。。。💦）
マルチスレッドは高速化に必須となります。
eslint-plugin-vueの現状と今後
eslint-plugin-vueは、v3でカスタムパーサー使うようになり、大きく変わりました。
フォーマッターとして使う場合、Vueのスタイルガイドに従っているかがチェックできます。
eslintを使ってチェックができるため、移行ツールとしても使えます。
v10の計画では、nuxtサポートを強化していくようです。
将来的には、TypeScriptの型情報を使用したチェックをするようです。
そして、ESLintの書き直し計画があり、「make ESLint project-aware」というissueが上がったようです。
これは、ESLintがチェックする前に、全ファイルを解析するべきなのか、という内容のようです。
以上、参加したセッションの内容でした。
感想
以下、参加させていただいた感想を書きます。
Vue, Nuxtの知見を深めることができました。全世界で使われているような開発者の方の声を聞くことができ、さらに開発状況を聞けたのは、私にとって新鮮で、非常に貴重な経験となりました。
（私もこういったOSSへの貢献に興味を持つようになりましたw）
私がまだまだ知らないNuxtのエコシステムや機能について、名前だけでも知れて良かったです。内容については、追々調べて勉強します。。
そして、まだまだ私が勉強不足であり、学び続けなければいけないな、と思った1日でした。
Vue Fes Japanに関わった皆様に感謝しつつ、終わりにしたいと思います。
ここまでお読みいただきありがとうございました🙇♂️
