ep.194『ソロ活動でネイティブコンパイラに挑む！VueとSvelteの次世代ツールチェーンを作る日本人たち』 | UIT INSIDE

2026/10/20 に公開69 views

このエピソードについて

@TheoSteiner が、@ubugeeei と @baseballyama と一緒に、Vue と Svelte のツールチェーンを Rust で作る Vize と rsvelte について語りました。

ゲスト

@ubugeeei
- Vue.js コアチームメンバー、Vize の作者
- Vue Fes Japan コアスタッフ
@baseballyama
- 株式会社フライル VP of Technology
- Svelte コアチームメンバー、eslint-plugin-svelte のメンテナ、rsvelte の作者

Vize と rsvelte

Rust でツールチェーンを書く理由

JavaScript 製の既存ツールは性能を前提に設計されていない
Svelte ファイルの Lint の遅さ。Oxlint は速いが Svelte ファイルを扱えない
AI で並列に実装する時代、フィードバックの速さが開発速度に直結

Oxc があるのに専用の実装が要るわけ

Vue / Svelte のファイルは JS でも TS でもない
Oxc・Vite+ はフレームワークに依存しない立場。フレームワーク側はサードパーティーとして連携
JavaScript に変換して渡すとフレームワーク固有の意味論が落ちる
tsgo の Content Mappers、Vite の変換パイプラインの RFC

2つのプロジェクトのアプローチの違い

Vize: AST をやめ、MLIR のような多層 IR へ。VDOM と Vapor を共通の IR から
rsvelte: 本家との互換性を重視したポート。SvelteKit でも vite-plugin-svelte の差し替えで利用可能
Vize は本家コンパイラのフィクスチャーを大量に作り、それに一致するよう Rust で書き直した

ひとりと AI で作る OSS

「ひとり＋AI」で作る OSS とコミュニティの役割
ubugeeei-redundancy.md
AI 時代に Vue や Svelte のような抽象度の高いフレームワークは要るのか

告知

Vue Fes Japan 2026: 10月24日（土）開催。うぶげさんが「The Vue Toolchain, Reimagined」で登壇
Svelte Summit 2026: 11月19〜20日、リュブリャナで開催（オンライン配信あり）。山下さんが「Svelte and oxc: Where Things Stand, and Where They Could Go」で登壇

関連リンク

Vize: https://github.com/ubugeeei-prod/vize
rsvelte: https://github.com/baseballyama/rsvelte
rsvelte: Rebuilding the Svelte Toolchain in Rust for the AI Era: https://blog.baseballyama.com/posts/20260721-rsvelte
Oxc: https://oxc.rs/
Vue Fes Japan 2026: https://vuefes.jp/2026/
Svelte Summit: https://sveltesummit.com/
ep.166『運営メンバーに聞くVue Fes Japan 2024の舞台裏』: https://uit-inside.linecorp.com/episode/166
ep.164『コアメンバーと語る！Svelte 5の革新』: https://uit-inside.linecorp.com/episode/164

採用について

使用素材・クレジット

BGM&SE

音声書き起こし

1. オープニング 00:00

@TheoSteiner 00:08
こんにちは、UIT の theo です。ユーザーインターフェースとテクノロジーを愛する開発者のためのポッドキャスト、UIT INSIDE、今回もやっていきたいと思います。今回は、うぶげさんとベースボール山さんと一緒に、2026年の Vue Fes を盛り上げるエピソードを収録させたいと思います。

@TheoSteiner 00:29
よろしくお願いします。

@baseballyama 00:31
よろしくお願いします。

2. ゲスト自己紹介 00:32

@TheoSteiner 00:32
早速、自己紹介してもらってもいいですか?じゃあ、どっちか。

@ubugeeei 00:38
うぶげです。UIT INSIDE は、多分、3回目くらいの出演で、普段何やってる人かと言うと、Vue.js コアチームメンバーして、いろいろツールチェーン作ったりとか、仕事でも Vue たくさん書いてたりとか、Vue Fes のコアスタッフをやってたりします。

@TheoSteiner 01:01
今年の Vue Fes は登壇もする感じ?

@ubugeeei 01:04
一応ゲストスピーカーで登壇するのと、後でちょっと話すかもしれないですけど、chibivue っていうやつを今年ハンズオンでやるらしいんで、ハンズオンの方に顔を出したりとかすると思います。

@TheoSteiner 01:16
chibivue っていうとコミュニティですか?

@ubugeeei 01:19
あの、あれです。あの、利用確保。一緒にみんなでやる。

@TheoSteiner 01:24
えー、楽しそう。

@ubugeeei 01:25
ぜひ、ぜひ。まあ、ちょっともうチケットないんですけど、VTで撮ってみて。

@TheoSteiner 01:29
はい、ぜひ。チケットゲットした人で。

@ubugeeei 01:31
はい、よろしくお願いします。

@TheoSteiner 01:34
で、続いて山さん。

@baseballyama 01:36
あ、山下と申します。仕事は、株式会社フライルというところで、VP of Technology という職種をやっていますと。で、Svelte のコアチームに一応いて、メインは、一応 ESLint とかのメンテナンスをやっているということになってますけど、最近は、Svelte のコンパイラーとか、フォーマッターとか、そういうのを Rust で書いてみようかなっていうプロジェクトを少しやってみたりとかしてます。

@baseballyama 02:05
よろしくお願いします。

@TheoSteiner 02:06
よろしくお願いします。

3. Rust でツールチェーンを書く理由 02:08

@TheoSteiner 02:09
で、その Rust でコンパイラーとか Linter とかを書くみたいな話が、今回のメインのテーマになるんですけど、なんか最近 Vue Fes で JavaScript より Rust でなんかツールを変えたとか、そういう発表が多いと思うので。

@TheoSteiner 02:28
なんかその、うぶげさんと山さんが2人とも、なんか最近フレームワークの Rust の何かを作ってるんですけど、うぶげさんだったら、Vize?

@ubugeeei 02:42
はい、Vize は、Vize っていうプロジェクトを作ってて、Vue.js のコンパイラーとか、タイプチェッカーとか、フォーマッターとか、Linter とか、もろもろ含めたツールチェーンを Rust で最近書いています。

@TheoSteiner 02:56
山さんも Svelte のコンパイラーとかフォーマッターとかを Rust で書いてるんですけど、ここでめっちゃ雑に投げるんですけど、なんでですか?

@ubugeeei 03:07
なんで?どっちから話しますか?

@baseballyama 03:09
どうぞ。

@ubugeeei 03:10
めちゃくちゃ、端的に言うと、Rust で書くと、まあ頑張って書くと、ちょっと語弊のないように頑張って書くとと言いますけど、頑張って書くとすごく速く書けるからっていう感じですかね。

@ubugeeei 03:26
既存のツールチェーンが、まだ JavaScript で書いてたりとか、そもそもパフォーマンスを念頭に置いた設計からスタートしてるものじゃないものが今の、かなりほとんどのもので、本当にこう、めちゃくちゃ速いことを書くぞと思い切って。

@ubugeeei 03:43
書きやすいのが Rust で、実際めっちゃ速いから。

@TheoSteiner 03:48
ネイティブのパフォーマンスなんですね。

@ubugeeei 03:50
はい、ネイティブもそうだし、言語機能的にもメモリーアロケーション周りの最適化とか、コンパイル時計算の最適化とか、よりやりやすい。TypeScript と比べると、より低レベルなチューニングしやすい。

@ubugeeei 04:04
あとは、言語のコンパイラーの時代の成果がすごい良くて、めちゃ速いっていうのも思っているけど、まあでも、山さんも同じ感じ?

@baseballyama 04:14
まあ基本的には同じだと思いますけど、もう少し違うアプローチからの説明をしてみるとすると、僕、eslint-plugin-svelte ってやつとかのメンテナンスをやってたりとかもするんですけど、やっぱり Svelte ファイルの Lint、結構時間かかるっていうのは昔から自分でも思ってるし、Issue とかでも来るようなことがあって、Oxlint とかを会社のプロジェクトとかで結構大きいプロジェクトとかでも入れてみても異様に速い。

@baseballyama 04:42
だけど結局 Svelte ファイルはネイティブにサポートできないので、結局 eslint-plugin-svelte が必要になっています。せっかく Oxlint がすごく速いのに、すごいもったいないなって思ったっていうのがまず1個あります。加えて、AI ですごいコーディングができるようになったことで、今までだったら一生懸命実装して、ちょっとコーヒーとか飲みに行くような時間に Lint とか回しておこうみたいなのが良かったんですけど、すごい並列で実装されることになったので、フィードバックのループをいかに速くするかみたいなのも実装の速度に直結するような時代になってきたのかなと思って、Rust で Svelte も乗っていけるといいんじゃないかっていうところでちょっとやってみようかなと思ったっていうそんな背景ありますかね。

@TheoSteiner 05:27
なんか今の AI の使用のところすごい自分の中で響いてて、個人開発で MacBook Air の M1 のやつを使ってるんですよ。しかも RAM が 8GB なんで、めちゃくちゃ弱い端末なんですよ。

@TheoSteiner 05:43
で、そこで並列でVibe Codingしたら、もう秒でスワップファイルとかいっぱい出ちゃって、なんかこれ辛いなってなってるんですけど、ネイティブでフォーマッターとかコンパイラーとかリンターとか動かすと、なんかそこのメモリー利用とかもちょっと効率的になるから、確かにそこも。

@TheoSteiner 06:05
なんかすごい大事になってくる観点だなって思いました。でも、なんかさっきもちょっと触れたと思うんですけど、1年、2年、3年前ぐらいから、ツールチェーンをネイティブに移動しようみたいな動きは多分あると思うんですけど、JavaScript の世界の中で。

4. Oxc があるのに Vue と Svelte に専用の実装が要るわけ 06:10

@TheoSteiner 06:23
で、そこで、Oxlint とか Oxc とか TypeScript のバージョン7の tsgo とかが、あるのに、なんで Svelte とか Vue とか特有の実装が必要になるんですか?っていう、めっちゃ軽く投げてるんですけど、多分だいぶ複雑な回答になるんじゃないかと思います。

@baseballyama 06:44
いや、なんでかって、一言で言えば Svelte ファイルは JavaScript でも TypeScript でもないからっていうところですよね、まず。Svelte ファイル、Vue も同じだと思いますけど、Svelte ファイルとか Vue ファイルっていうのはまず、テンプレート部と、スクリプト部と、スタイル部みたいなところ、まず、Vue もそうなのかな、正規表現とかで、ざくっとこう、まず切っちゃったりとかして、で、その後に各言語ごとのパーサーみたいなものが走って、それでこう、各3つのパーツっていうのはそれぞれ関連性があるんで、その意味みたいなものを分析して、それで最後いい感じにコンパイルしたりとか、それをリントにしたりとかフォーマットしたりとか、いろいろしていくと、非常にざっくり言うとそんな流れになってると思うんですけど、

@baseballyama 07:26
Oxc とかそういうツールチェーンっていうのは、JavaScript と TypeScript、一部 HTML とか他の言語もサポートできるようになってると思いますけど、Svelte とか Vue みたいなフレームワーク特有の言語っていうのは、そもそも理解すること自体ができないというところで、それを理解するための何かしらの方法が必要になってくるというのがまずあります。

@baseballyama 07:49
現状の Oxc とかだと、JavaScript を経由してパーサーなり何なりを呼んで、最終うまいこといくみたいな、JavaScript のエコシステムを活用する前提でエコシステムを作られているという風になっているんですけど、そうなると、結局 JavaScript に降りちゃって、そこで性能が出ないみたいなことになったりとか、ややもすると、非常に細かい話ですけど、ややもすると、Rust と JavaScript の間で、いろいろとデータをやり取りしなきゃいけないんで、結局片方が速くなっても、やり取りのオーバーヘッドで全てが台無しなこととかがある。

@baseballyama 08:23
そんな状況なんじゃないかなとは思います。

@ubugeeei 08:27
あとは、Oxc とか Vite+ の話でいくと、あの辺のツールはすごいフレームワークアグノスティックなものを目指して、特定のフレームワークに寄らないというか、もっとジェネリックな JavaScript とか Web のツールチェーンを目指しているので、彼らが Vue とか Svelte を Oxc のビルトインに…なんかするというのも、多分、思想がちょっと違うというところもあって、一部 Vue のルールとかあるんですけど、結構トレードオフなところもあって、統合ツールチェーンとはいえ、世界中のあらゆるフレームワークをバンドルしてたりすると、当然サイズもでかくなるし、実装も大変だし、何より、実装する人のリソースとかもとんでもないことになるんで、ちょっと住み分けがあるから、

@ubugeeei 09:24
実際に僕、Vue のツールチェーンを書いてるんですけど、Oxc チームが Vue にリソースを割かないのは、こいつが Vue ツールチェーンをやってるからだと言われるぐらい、結構リソースというかバウンドリー数が全体的に足りてない節があって、コミュニティの方からサードパーティーでうまく連携できるような形で作るっていうポジションを、多分、山さんも一緒ですけど、取ってる感じですかね。

5. 出口戦略 — Oxc とどう連携していくか 09:51

@baseballyama 09:52
これね、難しい話かなぁと思ってて、ちょっと細かな話が入ってきちゃうんですけど、ぜひうぶげさんとかにも意見をお伺いしたいなと思っていることがあって、まず、Rust と JavaScript が並行で走るって、今の状態で、Svelte とか Vue をすごく速くするって、僕らが思っているような。

@baseballyama 10:12
世界というのはまず実現できません。これは前提として言っていいと思うんですよね。なので、Rust で、Rust じゃなくてもいいんだけど、何かしら速い方法というのは見出す必要があるというのはまずあると思います。ただ、例えば、Oxc ってこれネイティブにコンパイルされる実行可能ファイルになるわけなので、そこからそこには Svelte とか Vue とかのファイルが入っていない。

@baseballyama 10:34
理解できる機能が入っていない。そうすると、何かしらの方法で Svelte とか Vue を理解できるようにする必要があるわけなんですけど。動的呼び出しっていうのかな。例えばそういうもので、例えば ABI みたいに呼ばれるものを定義したとしても、例えば Oxlint とかだと AST ノードのタイプっていうのは決められているわけだから Svelte 特有のノードとかは理解できなくて、うまく処理結局できないんだと思うんですよね。

@baseballyama 11:02
だから本当にネイティブに組み込もうとすると、結局 Oxc のコアとかそれに近いレイヤーにも Svelte とか Vue のノードの知識を多かれ少なかれ持たないと結局うまくいかないんじゃないかなとかって思うんだけど、そうすると結局 Oxc 側に Svelte とか Vue を理解するコードを入れてもらわざるを得ないような気がしてて、なんかこれって、まあ Oxc とかにも RFC 出てたけど、あの RFC って結局、Svelte とか Vue 一旦 JavaScript の形式にして、そっからうまくやってくださいみたいな。

@baseballyama 11:32
そんな RFC だったように、僕なんか理解したんだけど、それだと結局、Svelte とか Vue の特有の意味論全部落ちちゃうし、なんか、結局一生懸命、Vize とか rsvelte とか作ってるけど、出口戦略どういう風にするといいんだろうな、みたいなのは結構悩んでるようなところっていうのがあるなと思って。

@baseballyama 11:51
そこら辺で、うぶげさんはどういう風に考えてるのかみたいなことは伺ってみたかったですね。

@ubugeeei 11:55
いい、結構ディープな話。すいません。

@TheoSteiner 11:59
一回そこに入る前に、専門外の人から、そもそも理解できてるかどうかをちょっと確認したくて。で、Oxc っていうのが JavaScript の AST とか、Abstract Syntax Tree とかを作るためのツールシステムであって、その上で Oxlint とか Oxfmt とかが動いて、フォーマッティングとかリンティングができます。

@TheoSteiner 12:25
でも、あくまで JavaScript のツールシステムなので、JavaScript のスーパーセットである Vue とか、Svelte にはそのまま使えなくて、それはなぜかというと、Svelte とか Vue のテンプレートに、HTML っぽい何かの中に JavaScript が入っているから、そのまま使えなくて、それは HTML パーサーとかが Oxc に含まれていないから、Oxc がそれを理解しようがないという話ですよね。

@TheoSteiner 12:58
で Oxc のチームからすると Svelte とか Vue を処理したい場合は、1回 Svelte とか Vue 特有のツール、例えば Vize とか rsvelte で、そのテンプレートを JavaScript に変換して、JavaScript のそれっぽい何かのものに書き換えて、それを Oxc に渡したらいいじゃんっていう設計案になってるんですけど。

@TheoSteiner 13:25
それだったら、せっかくのネイティブのパフォーマンス改善が台無しになっちゃうんじゃないかなっていう指摘ですか?

@baseballyama 13:33
まあ、最後の一文以外は僕と同じ理解をして、まずそれ合ってるかっていうのはうぶげさんとかにも確認したいけど、最後の部分に関しては、仮に Svelte とか Vue ファイルを JavaScript にして、全部うまくいくんだとすれば、その JavaScript に変換するところだけ動的呼び出しで、ネイティブからネイティブ呼び出せるようにさえできれば、多分、スピードは全部出るはずだと思うんですよね。

@baseballyama 13:58
だけど、実際には JavaScript にした時点で、Svelte とか Vue 特有の情報が落ちてしまうので、実際に正しく、例えば、ESLint のルールとかだと、Svelte とか、Vue の時は、例えば、Svelte とかの let を使った時に特有のこう、あの、条件があったりするわけですけど、特に Svelte 4 以前とか。

@baseballyama 14:18
そういうのとかは、また考慮されずに Lint されちゃうので、正しく Lint できない。そういう Svelte とか Vue 特有の情報が全部落ちてしまうので、その方法は実際にあんまり採用できないんじゃないかっていう。性能以前の問題。

@TheoSteiner 14:30
フレームワークによって JavaScript の解釈自体が変わるから、Oxc の汎用的な JavaScript の解釈で足りないんじゃないかな

@baseballyama 14:38
っていうふうに僕としては思ってる。

@TheoSteiner 14:41
一回、一般人訳、挟まないですけど。じゃあ、うぶげさんからすると、どうなるんですか?

@ubugeeei 14:47
そうですね、いくつかポイントは、ちょっと先人リスペクトじゃないですけど、あるとすると、さっきから Oxc とかの話が出てますけど、Rust で JavaScript のツールチェーンを書くっていうのを先に始めたのは SWC で、SWC とかはその辺をうまく Dynamic Link とかで、プラグインを Rust で書くんですよね。

@ubugeeei 15:13
あいつらとか言っちゃう。いや、別にいいですけど、大丈夫ですけど。あ、彼らは Rust で、結局利用者はでも JavaScript のユーザーだから、JavaScript でプラグインとかを書きたいみたいなところで、Oxc はそこのトレードオフ、あとは既存のプラグインの互換性をそのまま動かしたいとか、そういうトレードオフで選択をしているところがあるというので、なんか一部仕方ないところはあると思うんですよね。

@ubugeeei 15:45
ネイティブでプラグインをなんか、みんなが書けるわけじゃないから、まぁちょっとそこは息を飲んでおく。あと、で、さっきのそのフレームワーク特有の問題を結局 Oxc 側とかに理解してもらわないと、なんかうまくいかないんじゃないかとか、あと ABI がどうちゃらこうちゃらみたいな話で、僕もちょいちょい Vite とか Oxc の会社で Evan とかとたまに話したりするんですけど、結論言うと、多分これといった解決策は今のところなくて、競合するルールとかは普通にビルトインのものをオフにして、Vue 側とかそういうのエコシステム側で。

@ubugeeei 16:39
まあ、巻き取る。まあ、多分、AI のコーディングとは思いましたけど、物理的にも多分、まあ、やろうと思えばできるんで、まあ、僕はそんなに、そこをすごく問題には思ってない。多分、なんかこう、無駄はある。やっぱ、せっかく本家の方に実装されてるのに、ちょっと違うから使えないみたいな、ちょっと無駄がある部分はあるんですけど、まあ、こっちで作っちゃえば、まあ、なんとかなるだろうという、結構楽観的な。

@ubugeeei 17:02
なんか感じをしているっていうのと、あともう2つぐらいポイントあって。大丈夫かな、この話。

6. Content Mappers と Vite の RFC — 型チェックやリントの行方 17:05

@TheoSteiner 17:08
お願いします。

@ubugeeei 17:09
最近、これはなんかもう、かなり最先端の話というか、世界でも定まってないし、まだリリースされてないんですけど、tsgo でいくと、Content Mappers っていう取り組みがあったりとか、あと。

@ubugeeei 17:26
ちょうど今日、9月25日なんですけど、今週に、なんか、Rolldown チームの人が個人的に、あの、Vite のトランスフォームパイプラインみたいなものの API をちょっと変えないかみたいな RFC を立ててて、それはまさしく、なんか結構、こういう Vue とか、まあ、もちろんその RFC、詳しく読んでみればわかるんですけど、Vue とかも例に挙げられてて、今の Vite のコンパイルのパイプラインって本当にトランスフォームの連鎖でしかなくて、トランスフォームのパイプライン自体の JavaScript がどのように作られたかとかを、Vite とか既存のエコシステムに教える術がないっていう、もうなんかちょっと宣言的に合成可能にしようみたいな RFC が立ってるんで、まあ多分… Vue とか Svelte そのものを、Vite とか Rolldown とかが解釈するってことはないと思うんですけど、もうちょっと抽象的な、この JavaScript はどういうのが由来でできたから、内部的には処理するとか、もう処理しないとか、Vite のビルドに任せるとか、そういう取り組みはあって、たぶんそこを…少なくとも、Vite に関しては、そこが結構肝になってくるんじゃないかなと思っているのは一つ。

@ubugeeei 18:48
これはあくまで Vite とか Rolldown の話なんで、Linter とかフォーマッターとかはまだこれから定まってないというのがあると。TypeScript の連携に関して言うとまあ、それこそ、Svelte とか、Vue のために、Content Mappers っていう実装が入って、確か次のマイナーリリースで出るが、まあ、多分10月とか11月以降になるんで、まだリリースはされてないんですけど、まあ、そういう機能で、それも結構 Vite のトランスフォーマーと同じくらいの流れで、こう。

@ubugeeei 19:23
Vue とか Svelte とかそのものを理解するというよりかは、中間表現として生成する TypeScript はこういう意味で作られましたみたいなものを宣言したりとか、そういう API なんで、なんかはそれぐらい、フレームワークアグノスティック、中立を保ちつつ、もうちょっと今の、なんて言ったらいいですか、既存の API じゃない、もうちょっと。

@ubugeeei 19:49
どういう由来、JavaScript とか、TypeScript が来たかとか、そもそもそれを想定した API にしようとか、方向に寄ってくるので、ちょっとそれの様子見をしているという感じがあるなというのが、今のステータスですね、という感じですが、伝わってるのか?

@baseballyama 20:10
まあ、だから、型検査、Vite のバンドリング、あと、Linter、フォーマッター、ここら辺はまず分けて考えましょう。っていうのが、うぶげさんがおっしゃったことですよね。で、型に関しては、Content Mappers はかなり僕も期待しているし、7.1出たら。

@baseballyama 20:27
会社のやつも全部、tsgo に。たぶん、乗り換えられると思う。svelte-check も今、Content Mappers 対応する PR が出てて、マージされてないのかな?わかんないけど。

@TheoSteiner 20:36
今実際にブロックされてますよね。

@baseballyama 20:38
それにブロックされてます。だからそれマージされたら、とうとう会社のプロジェクト、Svelte のプロジェクトも全部、tsgo にできると思います。これ結構、素晴らしい。あと、Vite の話は僕も同じようなことも思ってて、毎回結局、一回ソースコードに毎回トランスフォームコードになるっていう。

@baseballyama 20:57
AST、せっかく毎回やってるのに毎回パースするの何なんだろうって結構昔からもったいないなと思ってたんですけど。今週出てたって言ってた?その RFC は僕知らなかったんだけど、それは素晴らしい取り組みだなと思った。それをネイティブで JavaScript を全く経由せずにネイティブで呼び出せるようになったら非常にいいんじゃないかななんていうのも思いましたと。

@baseballyama 21:19
やっぱり、Lint だよね。Lint が、うぶげさんのバイズとかは、すいません、Vize、Vize ですね。Vize とか、あと、うぶげさんとちょろっとやってる oxlint-plugins みたいなプロジェクトが、かすかにあるんですけど。

@baseballyama 21:38
ああいうプロジェクトってのは、プラグインごとに毎回、まず Oxlint でパースして検査して、1回終わり。で、このプラグインでまた全部パースして検査して終わり。Oxlint 自体がすごく速いから、まあいいんですけど、ただ非常に非合理的だなって個人的には思うので、Oxlint 側でもう少しエレガントな解決策とかだったら、もうもっといいのにな、なんてことは少し思ったりしてます。

@baseballyama 22:05
あと、フォーマットはね。フォーマットは今、うぶげさんからあんまり言及なかったけど。フォーマットはどうだろうね。まあ、でも、Lint とかに比べたらすごく速いんで、優先順位としては多少劣後するかなって言うので。今の Vize とか、rsvelte も同じようなやり方ですけど、Oxfmt を少しラップするような形で提供するっていうので、まあ、しばらくはいいんじゃないかなと思ったりしますけどね。

7. Vize の多層 IR — AST をやめるという選択 22:31

@ubugeeei 22:33
はい、なんか僕、これはちょっと Vize の結構エクスペリメンタルの話になるんですけど、さっきから AST とか中間表現としての JavaScript、TypeScript を、いわゆる他のツールチェーンというか既存のツールチェーンをインターフェースにするみたいな考え方で、AST を何回も操作したり、タイプチェッカーとかフォーマッターなどにそれぞれ発表するのは

@ubugeeei 22:57
どうなんだ?みたいな話があったと思うんですけど、Vize は実は最近ですね、AST をやめようとしていて、これちょっとどこまで?どこまで話せばいいかわからないんですけど、思想と、わかる人に向けて。

@ubugeeei 23:18
そういった説明をすると、Vue.js 版の MLIR みたいなものを作ろうとしていて、これはもっと抽象的な中間表現で、AST でもないし、CST でもないし、Biome みたいなレッドグリーンツリーみたいなものでもない。

@ubugeeei 23:40
もっと Vue の意味論とか構造を含むんですけど、フォーマットアップルーベンのスタイリングのやつとかも含むんですけど、多層の IR を持って、それでユニファイしようとしています。結局 Oxc とかの方、Oxc とかにそれぞれ処理入っちゃうみたいなところは解決できてないんですけど、フォーマッター、リンター、タイプチェッカーみたいな、その Vue のパートは、そこ。

@ubugeeei 24:09
無駄を省くというか、そういう取り組みは最近してて、AST を毎回パースしたりとか、フォーマッターのための AST を別で持ったりとか、そういうもんを排除を頑張ってしようと最近頑張っています。

@TheoSteiner 24:27
かなりコンパイラーっぽい。

@ubugeeei 24:29
本当にコンパイラー話になったんですけど、

@TheoSteiner 24:32
AST を直接 JavaScript とかに変換するより、それを扱う Vue 特有の抽象的なレプレゼンテーションを作って、それで処理するから、何回も行き来することは発生しない。

@ubugeeei 24:54
ちょっとだけ補足をすると、一つの中間表現に全部の情報を載せてるわけじゃなくて、MLIR ってレイヤーごとに中間表現があって、ローイングっていう概念で、一個、さらに何回落としながらこせる。

@ubugeeei 25:11
ローワリング。はい、ローワリングをする。だからそう、フォーマッターとかに必要なレイヤーと、意味解析に必要なレイヤーと、タイプチェッカーとかに必要なレイヤーとか、あとは、これはちょっと実験的ですけど、JavaScript 以外の言語を方言として取り入れるための多層の IR を使って、Vue のパートに必要なツールとかは、ユニファイドしてしまおう。

@ubugeeei 25:36
多分その先は、Rolldown とかをバッてやったりとか、Oxlint とかバッてやったりとかすると思うんですけど、そこの微調整というか、さっき言ったビルトインのやつ使えないやつは、こっち側でオフにしながら巻き取るとか、そういう微調整をやりながら、大まかにそういう流れでパフォーマンスとか無駄を省こうかなと今考えて、考えて実装もしてるんです。そういう感じですかね。

@TheoSteiner 26:02
課題を全部 Vize 側で、レプレゼンテーションで完結しよう。

@ubugeeei 26:08
そうですね。

@TheoSteiner 26:09
JavaScript ツールチェーンの汎用的な何かの解決を待たずに。

@ubugeeei 26:14
そうですね。

@baseballyama 26:16
その場合の処理フローって、Vue ファイルがあって、そしたら1回だけパースをして、その後にそのプロセスの中で、フォーマッターとかリンターが呼ばれていって、全部が終わるみたいなことになるということですか?

@ubugeeei 26:32
ちょっと違うのは、あんまりこう、既存のパイプラインみたいな考え方ではなくて、もうちょっとアドホックに、最適化パスの合成とかもあればやっちゃうんですけど、まず AST して、AST を IR に変換してみたいな感じじゃないんです。

@ubugeeei 26:51
どっちの方がいいっていうのは、エクスプレッションのパースみたいなのって、ところどころで出てくるじゃないですか。最初に全部パースしきる前に、そこに到達するまでに、Vue の意味論とかを持ってくれば、例えばバインドが来たらバインドのところは JavaScript の式としてパースされてる、結構連鎖的というか、あんまりまず Vue、JavaScript って感じじゃなくて、一体規定するんで、そこをうまく針の穴に糸を通すというか、シュッとする感じ。

8. Vue Fes の登壇とフレームワークをまたぐ IR 27:28

@TheoSteiner 27:29
これ、Vue Fes の登壇に出てきますか?

@ubugeeei 27:33
これはちょっと話そうと思うんですけど、Vue Fes の登壇は、そもそも Vize、まあ、Vize のこと、そもそも Vize で聞いたことねーよ、みたいな層がいっぱい来ると思うんで、もうちょっとジェネリックな話です。すごいディープなところまでは30分しかないんで、あんまりする予定はないですけど、そういう感じの取り組みをしてます、みたいなのが、あと1ヶ月くらいあるんで、また進展とプラスして、なんか話せるんじゃないかなと思う。

@ubugeeei 28:01
だけど、そういうことにフィーチャーして、ずっと喋るとかはないです。

@TheoSteiner 28:05
ちなみに、2年前の Vue Fes で、Vapor の発表があって、そのタイミングもミドルエンドの話があって、MLIR みたいな、中間?中間?

@ubugeeei 28:20
MLIR っていうやつ自体は、LLVM Project の MLIR なんですけど、IR っていうのは Intermediate Representation で、中間表現。中間表現。

@TheoSteiner 28:33
中間表現。完全に、テオの日本語です。中間表現があって、Vapor のコンパイラーが使っている中間表現と、Vize が中で使っている中間表現って一緒ですか?

@ubugeeei 28:47
いい質問です。これはめちゃくちゃいい質問です。僕、そこも統一したいなと Vize 側では思っている。Vize ってコンパイラーも持っているんですけど、Vapor モードには IR があるんですけど、普通の VDOM 使う方のやつって IR みたいな概念は Vue.js 本家の実装にはないんですよ。

@ubugeeei 29:08
でも、そうやってよく考えたらちょっと気持ち悪いじゃないですか。共通した意味の Vue.js の IR があって、そしたら VDOM と Vapor みたいな綺麗に連携したりとかする方が綺麗だと思っていて。その辺も、もちろん包含しているというか、Vapor の IR と同じものかと言われたら、結局全然違うものになるんですけど、仕組みとしては、今の Vapor の IR の方に、アーキテクチャはどちらかというと近い。

@ubugeeei 29:36
VDOM の方もそっちに寄せたいという点がちょっとない。

@TheoSteiner 29:39
なんか、LLVM の強いところは、どの言語でも同じ IR 使ってるじゃないですか。

@ubugeeei 29:45
はい、そうですよね。

@TheoSteiner 29:47
で、なんか、どのフロントエンドフレームワークでも同じ IR。

@ubugeeei 29:50
はい。

@TheoSteiner 29:51
使う未来で来るのかなって、今ちょっと思ってて、rsvelte も IR 使ってますか?内部で。

@baseballyama 29:58
いや、rsvelte はあんまりそういう複雑なことはしてなくて、そこはね、Vize と少し考え方が違くて、Vize は結構、もっと先進的なことを試して、エクスペリメントなことを試して、いいものをコミュニティに還元していこうみたいな。

@baseballyama 30:14
そんな捉え方は僕はしてるんですけど、rsvelte はもっとシンプルに、Svelte のエコシステムを単純に置換する、Rust に置換してみるっていうところだけをスコープにしてて、そんな僕は先進的なことを考えられないっていうのもありますけど、やっぱり僕は実用レベルに持っていきたいので、実用レベルに持っていくためには、しっかりとした互換性、本家との互換性というのがないといけないと思うので、そこにどちらかというと力を入れて取り組んでいるというところはありますね。

@baseballyama 30:47
この IR の話は、Vue の人たちから何回かこういうのを聞いたことがありますけど、できたらすごいです。できたらすごいです。

@ubugeeei 30:57
やろうとしてるんです。細々と。なんかその

@TheoSteiner 31:02
IR があれば完全な表現が必要じゃないですか。どのフロントエンドフレームワークにある概念でも表すようなシンタックスとか考え方が必要になるんですけど、Vue だけにあるけど、Svelte にないとか、逆に Svelte だけにあって、Vue にないみたいなものもいっぱいあると思うんですけど、そこは。

@ubugeeei 31:28
これは、僕がさっき話した、MLIR の思想、まさにそれって感じなんですけど、さっきも言った通り、IR が一つじゃないんですよ。そもそも、MLIR って何かというと、マルチレイヤー・インターミディエイト・リプレゼンテーションなんですけど、

@ubugeeei 31:43
Dialect っていう、まあ、方言みたいな概念があって、Vue 固有のものはそっちで、まあ、巻き取る。で、共通の、多層な IR なんですよね。

@ubugeeei 31:54
なんで、まあ、僕が今 Vize の方が、こう、UI みたいな IR、まあ、多分、Svelte だろうが、Vue だろうが、Angular だろうが、多分、バインドとかはあって、derived state とかはある、みたいな、もっと抽象的な IR と、それこそ Vue とか Svelte とかにしかないものを、一応方言として受け入れる設計にはしていて、まだ Svelte パートは作ってないし、Vize に Svelte のパートを入れるかと言われると、多分入れないんですけど、そこにうまく繋げられるような、サードパーティーで、この IR まで落とせば、あとはコンパイルは、似合い大体 Vue から作っても Svelte から作っても同じような JavaScript になる、みたいなものを、まさに今目指しているというか、これは結構趣味の範囲ではあるんですけど、単純におもろそうだからっていうので、そういうのは、まさに、まさにというところです。

@ubugeeei 32:48
なんなら、なんか最近思っているのは、あと何個かあるんですけど、プリプロセッサーみたいなものってたまに使ったりしているプロジェクトとか、最近はあんま使うことないかもしれないですけど、昔からあるプロジェクトとか使いたいと思うんですよ。

@ubugeeei 33:04
例えば、Template というと Pug とか、あとは SCSSSUS とか、そういうのも、結局その Template 理解だって、Vue って実は lang イコール pug って書いて、Pug 入れると Pug で書けるんですけど、そういうのを問いできないんじゃないですか。

@ubugeeei 33:19
だから、そういう奴らのためにも、多層の IR、Pug で書いたとしても、普通にしないので、記法で書いたとしても、同じ意味を指す IR のレイヤーを持って、もっと、Qとかでやるとこで、IR もまた別で持ってみたら、多層 IR にして、頑張ってノーマライズしようとしていくという、何とは意気込みをおいて、

9. 2つのプロジェクトのアプローチの違い 33:41

@TheoSteiner 33:42
2つのプロジェクトを比べて、すごい差があるなと思っていて、本当に汎用的な解決方法と応用的な解決方法の2つの、Vize も応用的ではあると思うんですけど、そういう MLIR みたいなのを長時間、

@baseballyama 34:03
長い目で見たら

@TheoSteiner 34:05
そういう最終的なゴールがあるというのが。ちょっと違う。

@baseballyama 34:11
あと、僕がそれに取り組まない。これね、何が正解かって特にないし、面白いと思ったものをやって、それでいいものが広まっていくって話だけなんで、正解とかね、まずないっていう前提ですけど、僕はレイヤーが多くなると抽象化とかいろいろ考えることが増えるんで、やっぱり非常に難しくなるので、ですと。

@baseballyama 34:31
一方で今実装ってすっごい早くなったんで、そういう抽象とか考えずに、こういう、例えば UI フレームワークを作りたいと思ったら、作ればいいんですよね。シンタックスを決めて、コンパイラーピッて書いて、JavaScript にしたら、あとランタイム書いたらできるので、そんな抽象化とか考えなくてもストレートフォワードなパイプラインを1個作っちゃえば終わりなんですよね。

@baseballyama 34:55
そっちというよりは、そういうのは、もうすでに考えてくれてる人がいるからってのは一番大きいけど、僕はどっちかというと、最適なものを考えついた人がストレートフォワードのパイプラインを単に作るっていう。この方がシンプルなのかなとは思ったりもしている。

@ubugeeei 35:09
DHH。DHH。DHH。

@baseballyama 35:13
本当に Rust は読まなければ最高の言語ですから。

@ubugeeei 35:18
なんていうか、DRY がどうだみたいな概念をずっと言ってた。ああ、そうですか。AI でいっぱいコードを書けるようになったから、そこはもうそんなに問題じゃなくなった。もう普通にそれぞれで書いていいだろう。

@baseballyama 35:33
ああ、それです。

@ubugeeei 35:34
伸ばしなってましたね。

@TheoSteiner 35:35
ちょうど、今朝、X でバズったやつですね。話題、話題。コードが Vibe Coding によって消費物になってきたから、そんな IR とか考える必要もないんじゃないっていう、直接 AI が書けばいいじゃんっていう考え方ですよね。

@ubugeeei 35:57
水平スケールしやすくなったんですね。

10. コアチームと Rust — コミュニティの反応 36:01

@TheoSteiner 36:02
なんかそこでちょっと深掘りたいというか、ちょっとコミュニティからの反応気になる、コミュニティとか他のメンテナーからの反応気になっていて、Vue のメンテナーとか、Svelte のメンテナー。Rust みんな書けるわけではないと思うので、そこの反応とかどうですか?

@ubugeeei 36:22
そうですね。ちなみに、Vue.js の作者の Evan You は、Rust 書けないです。VoidZero の人たちは書けるけど、Evan 自体は、その、Rust を書いたことはないし、何なら一時期、TypeScript 派じゃなくて、JavaScript 派になったぐらいだ。

@ubugeeei 36:41
Rich Harris と似たようなところがあるけど。というのと、コアチームで言うとですね、今、Vue 界隈でアクティブに活動しているコアチームの中は、大体みんな Rust 書けない。

@ubugeeei 37:02
僕が Rust で書き始めて、Rust を書き始めた人がいるんですけど、実際に。その人ぐらいって、みんな書かない。

@ubugeeei 37:20
あと、これ、Rust もそうなんですけど、JavaScript ツールチェーンを作ってる人たち、SWC とか、VoidZero の Oxc とか、その人たちも逆に Vue とか Svelte とかあんまわかんないんですよ。あんまり専門家がいない。

@ubugeeei 37:36
なんで、ちょうどその間にいたからこそ、僕とか、山さんとかがやってるという方が、表現としては正しい気がしますね。Svelte チームにも、多分そんなにいない感じしているんですか?見合いさそうで。

@baseballyama 37:53
ああ、本当に聞いたことないですけどね。Rust、むちゃくちゃ書けるぜ。

@TheoSteiner 37:58
メンテナーのチャンネルの中で、rsvelte について話したりしてますか?

@baseballyama 38:04
してますね。まず、これ、Svelte コアチームっていってもいろんな人がいるんで、完全な総意というわけじゃないですけど、なんとなくメンテナーチャンネルを見ていると、概ねの方向性として、やっぱり AI を使いこなすっていう方向に行かざるを得ないだろうという、まずコンセンサスがあるように見受けられていて、あとはやっぱり、Oxc とか Rust のツールチェーンがすごく早いというコンセンサスも当然あると。

@baseballyama 38:34
ってなった時に、やっぱり Rust でツールチェーン書けるんだったら、その方がもちろんいいじゃん、というコンセンサスが、Rich Harris を中心に少しできてるかもしれないという状態になって。ただ、1個問題は、やっぱり、Rust を流暢に書けない人が非常に多いし、特にやっぱり新機能、例えば Svelte とかで、大きな新機能を追加したいとなった時に、例えば非同期 Svelte とかを追加したいとなった時に、Rust が流暢に書けないし、AI が…主となるコーダーになっている時に、どうやって実装していくとうまくいくんだ、みたいなところがやっぱり大きな課題になっていて、それを解決できないと、Rust を中心でいくっていうのは難しいんじゃないかって話はしていて、ここら辺は Svelte Summit の前の時にオフサイトのミーティングがあって、そんな時に少し議題として話したとかみたいな話をしたり。

@baseballyama 39:31
あと、Svelte のプロジェクトで AI と仲良くなっていこうというのは頑張ってて、Svelte のリポジトリのいくつかでは、最近 AI がバグのトリアージとか PR を作ったりとかして、たまに普通に間違えてリバートされている時ありますけど、そういうのとか結構一生懸命取り組んでいるのかなーって印象は最近受けます。

@ubugeeei 39:53
あと、なんだかんだ思うのは、みんな書いてこなかったから、今書けないというわけで、別に今ややるか、多分、結局 Rust だと、多分みんな Rust 書くし書けると思うんですよね。っていう、なんかね、楽観的なところもあって。

@ubugeeei 40:10
そもそもだって、Evan は Rust で JavaScript ツールチェーンを作る会社を立てているような本人は Rust を書けないけど、まあ、なんかあったらちょっと修正するとかぐらいはできるし、書ける人が書けばいいし、実際にこう、このチームは今 TS しか書けないから、TS しか使えませんみたいなと思い、まあ、ならない。

@ubugeeei 40:30
まあ、別になんか、悪く言えばプログラミング言語は道具でしかないので、まあ、みんな。Rust で書くといいかもねみたいな感じになって、実際に Rust になったらみんななんとなく Rust を書いたりはすると思う。

@ubugeeei 40:45
っていうのと、なんか属人、チームが使えるか使えないかみたいな話をすると、そもそも TypeScript であるから、なんて言ったんですかね、コアチームのメンバーで TypeScript めっちゃ書ける人がいっぱいいるから TypeScript が選定されているという流れでもない。

@ubugeeei 41:06
もっと、コアチームって言ってるけど実は結構属人的なもので、会社みたいにユース選定だったっていうよりは、そこで活動できる人がいるなら別にそれでもいいじゃないか、僕は結構楽観的なところは。

@ubugeeei 41:22
実際、Vue.js のコアチームって、コアチームって言うとすごいいっぱい人がいるように見えますけど、コンパイラー、Vapor をやっている、コアチームの中で実質的に一人。エジソンさんっていう人がめちゃくちゃやってるんですよ。そういう感じなんですよ。

@ubugeeei 41:37
他の人もいろいろやってるとか言うよりかは、別に Rust をめっちゃ書ける人が一人いるから、別に Rust を中心に回ってもいいと思うし、これは結構チームの方針によると思いますけど、そんなに…みんな Rust 書けないから、Rust 取り入れるなんて無理だよね、みたいな流れんような緊張がないような、じゃあ、ハイキンシーは、という、ジムスカード。

@ubugeeei 42:00
VoidZero にいる人、特に Vite チームとかはそうですけど、もともと、Rust を書いている人じゃないですかね、やっぱり。Vite ってもともと TypeScript で使われていて、TypeScript のチーム、でも、Rolldown-Vite とかになって、Rust とかに手を出さざるを得なくなって、Rolldown とかのコントリビュートを Rust でやるみたいな。

@ubugeeei 42:18
そうなってるの、実際。それと似たような感じになるんじゃないかなと思ってはいるかな。ちょっと喋りすぎる。いい感じに。

@baseballyama 42:29
なんか、すごい面白い。

@TheoSteiner 42:32
ちょっと別の方向に来たなって、今ちょっと思ってて。で、なんか今思ったのが。もっとアブストラクトな話になっちゃうんですけど、哲学的な話になるかもしれないんですけど、Vize も rsvelte も割と一人で作っちゃってるじゃないですか。

11. ひとりで作る OSS とコミュニティ 42:36

@TheoSteiner 42:51
一人プラスAIみたいなコントリビューションとかを見ると、そんな感じなんですけど、今後のOSSって、そうやって一人が作っちゃうものって、増えるのかなと思ってて、または、なんか、そのOSSのコミュニティってこれからいるのかなっていう、まあちょっと、結構でかい質問を投げたくて、そこの考え方どうなんだろうって、ちょっと今思いました。

@ubugeeei 43:21
山さん、今回行きますか?どっちでもいいですけど。

@baseballyama 43:25
え?うーん。そうですね。まずちょっと答えやすい方から言うと、コミュニティは絶対必要だとまず思います。なんでかっていうと、より良いものを作るためにはユーザーからの声がないと、自分にとって良いものはV1ぐらいまで行くまでだったらいいかもしれないけど、そこからV2、V3と成長させて仮に行きたいんだと思った時に、

@baseballyama 43:49
いろんなユースケースとかを知らないと、より良いもの、より役に立つものっては作れないので、それってコミュニティからやっぱりフィードバックを受けるしか方法はないと思うんですね。そういうのってやっぱり人がどう使いたいかが重要なんで、だからそういう意味でコミュニティってのは絶対に必要なものってのは変わらないんじゃないかなというふうには僕としては思います。

@baseballyama 44:13
で、OSS一人ですごい作っちゃうようなのが増えるんですかね、みたいな話は、どちらかと言うと今までもそうだったんじゃないかなって思ってて、異様に生産性の高い人が突然すごいものを作ってきて、

@TheoSteiner 44:27
Anthony とか。

@baseballyama 44:28
Anthony もそうだし、例えば…Git とか、ああいうのとかも、Linus Torvalds が突然作って、すぐ、10日くらいでできちゃったんですよね。

@ubugeeei 44:39
Evan、Rich Harris も似たような。

@baseballyama 44:42
Vite だって元々そうじゃない。Evan が夜にいいアイデアを思いついて、朝までコーディングして、最初のバージョンができたみたいな。だから、いいアイデアを持った、異常に生産性高い人が、何かやったらできて、それがいいものだったら世に広まった。

@baseballyama 45:00
そういう構造だと思うんですよね。だからあんまりそういう意味では本質的に構造は変わらないんじゃないかなと思います。ただ、一個違うことがあるとすれば、すごくいいアイデアを持ってました。だけど、例えば仕事とか家庭とかいろんな理由で忙しくて、時間を注げなかったような人たちが、そのいいアイデアを具現化しやすくなったという意味では、よりいいものが世の中に出てくる可能性が増えた。

@baseballyama 45:24
そんな風には考えられるんじゃないかなとは思いましたね。少しこれは問いからは離れるかもしれないですけど、やっぱりAIでコーディングする上で少なくとも2026年の時点で不安なのはやっぱり品質。すごく生産性の高い人が書いたコードっていうのは、だいたい早くコード書ける人はバグもなぜか少ないみたいな。

@baseballyama 45:43
そんなのたまに言われてた気もしますけど、AIとかだと、それから意図しないとこがえらいバグってるみたいなことって、なんか2026年の時点ではあるんじゃないかなっていう気がしてて、そうするとこう、どうやって品質を維持していくかみたいなプラクティスみたいなのは、もっとこう、世の中で標準化されていってもまあいいんじゃないかなみたいなのは、まあ思ったりするというか、そういうのがあるとより安心して、あの、AIで書かれたプロジェクトを使っていけるんじゃないかなっていうのは思ったりしますね。

@ubugeeei 46:13
これはもう本当に全く同じ。今までもね、結構そうだったっていうのは、もう全く同じで、別に Vue をほとんど一人で作ったのは Evan だし、あとは何かありますかね。まあ、Svelte もちろん Rich。

@baseballyama 46:28
まあ、Rollup だって。Rich Harris、最初の Rich Harris のとこはありつくことでし。

@ubugeeei 46:33
というのがあってまあそれがこうそのままこう1時間数じゃないですけど、すごい人がすごくやっていている。あんまり今までと変わらないんじゃないかというのが、もう一個、さっき言った品質を担保するための仕組みが持って簡単されるといいという話を山さんがしていたと思うんですけど、ただ Vize とかだとめちゃくちゃ今まで人手で書いてた以上のテストケースとフィクスチャーをめちゃくちゃ引っ張ってきて、めちゃくちゃテストを回すみたいなことをやっていたりとか、あとは、僕が最近、僕がやってOSSにほとんど書いているんですけど、なんか、ubugeeei-redundancy っていう、なんか、ubugeeei…そのものを冗長化するためのドキュメントを用意して、それを多分AIになれば、多めで似たようなことをやってくれるだろうという、ドキュメンテーションになってたりするんで。

@ubugeeei 47:34
っていうのと、あと、これはね、すごい無責任な言い方ですけど、サードパーティーって別に非公式で本体に取り込まれるわけでもないし。何か問題があったらフォークして自分で使うことはできるし、ライセンスがそういうふうに、なんか、MIT にしているし、というところがあって、なんか、そんなに、今、すごくわーっと作っている人が単一障害点になって、みたいなことで、今、それは課題を感じていないっていうのは、正直な感想です。

@ubugeeei 48:05
テストもめっちゃあるし、ドキュメントもあるし、別々、うまくいあるし、本体もそのままマージされるものでもないし、まあ、別にこのままやって、まあいいやって感じでやっていますかね。

12. 利用状況と Rust 歴 48:18

@TheoSteiner 48:19
アドプションはどんな感じですか?Vize とか rsvelte って。結構使ってるユーザーっていますか?

@ubugeeei 48:25
あ、そう。あ、違うですか。

@baseballyama 48:28
多分ね、Vize の方が多いんじゃないかな。rsvelte って、例えば、Mochi っていうメタフレームワークで使われてたりとか、あとは、たまに使ってる人いるみたいで、Issue とか飛んできたりとかするので、まあ、どこまでプロダクションで使ってるかっていうと、よくわからないですけど、使ってるか使ってないかというと、使われているところはなんかちょこちょこあるみたいではありますね。

@TheoSteiner 48:51
なんか、SvelteKit と一緒に使うとか、そういうことってできますか?

@baseballyama 48:56
SvelteKit と一緒に使いますね。rsvelte の vite-plugin-svelte ってのがあるんで、それを使うと、あの…多分ね、それ一行を書き換えるだけで、コンパイラーがすげえ変わるっていう感じには。

@TheoSteiner 49:06
ここが、さっきおっしゃった互換性、どっちかというと、リライトっていうより、ポート。

@baseballyama 49:12
ポートですね。すると、コンパイラーのポート。

@TheoSteiner 49:14
で、Vize は割と広まってる感じですかね。

@ubugeeei 49:18
いや、そんなにこう…ファーストチョイスになるほどには広まってはないですけど、実績みたいなものでいうと、まあ使われて、で、これ面白いのが、体感半分ぐらいフォークで使われてるんですよ。今までは、npm で配布してっていう、なんか、こう作るんですけど、みんなこう、Vize がまだ実験的なやつできないってことももちろんあるんで、でも、各々がフォークして、別に Rust のコード読めなくても一部挙動を変えていくとか、すごくやりやすくなったから、そういう面白さっていうか、新しさはちょっと感じている。

@ubugeeei 49:56
どっちもありますね、普通に npm パッケージで使われていることもあるし。フォークで使われたりもするし、リンターもコンパイラーもタイプチェッカーも一気にするって感じ。まあ、企業で使ってもらっているところも一部あるし、自分の会社でも使っているところもあるし。

@ubugeeei 50:14
そんな感じ。

@baseballyama 50:16
JavaScript と違って、pnpm patch でここだけちょっと修正ができないですからね。

@ubugeeei 50:20
そうなんですよ。

@baseballyama 50:21
もう、ちゃんと変えたかったら、フォークして自分でビルドするしかない。

@ubugeeei 50:25
本当に。

@TheoSteiner 50:26
Vice Start と Rust の大変さ。

@baseballyama 50:28
ちょっと大変ですよね、そこはね。

@ubugeeei 50:30
そこはね、それはあるよね。

@TheoSteiner 50:32
ちなみに、お二方は以前から Rust を書いてたんですか?

@ubugeeei 50:38
僕は割と入っています。まあ、この Oxc の波が来るより前から、なんか Rust が…結構好きな言語の一つで、ずっと Rust で言語処理とか Vue 周りのことをやれたらいいなというのは、2022年とか2023年くらいから思っていて、そこから Oxc とかが発達したりとか、実はAIがそれほど今ほど…弱まってなかった時期ぐらいなんですけど、ずっと思っていたが、このAIで、それこそさっき山さんも言った通り、アイデアがあるとすぐ実現できるような、発達していったんで、今年からガッとやり始めたんで。

@ubugeeei 51:33
まあ、構想自体はずっと前からあって、Rust、Rustよりも前から結構トライトはいたっていう感じですね。

@baseballyama 51:40
僕はそんなに Rust は書いてなくて、その Oxc が出てきて会社でも使いたいなと思ったときに、ちょっとどんなツールなのか少し理解したいなと思ったときに、僕の場合は理解するためにはプルリクエストを送っていくっていう方法が個人的にあっているんで、コードとかドキュメントとか読んでプルリクエストをいくつか送ったときに、多分それ、全くの初めてではないけど、ほとんど初めてみたいな感じでしたね。

@baseballyama 52:11
ただ、基本それぐらいしかやったことはないんで、非常にこう、流暢に。例えばJavaScript がすごく流暢にある程度、もうAI で普段書いてるから、書けなくなっちゃったかもしれないけど、ある程度流暢にJavaScript が書けたかもしれないけど、それと比べると、まだ少しおぼつかないとか、コンパイルエラーとか、苦闘するときは普通にあるんで。

@baseballyama 52:30
そんな感じではあったかなと思います。

@ubugeeei 52:32
それぞれTypeScriptより、Rust 書いてる時間のほうが長いから。普通にやってみてほしい。

@baseballyama 52:40
僕は99% Rust 以外の言語ぐらいの感じですね。

13. AI 時代に人はどの抽象度でコードを書くか 52:46

@TheoSteiner 52:47
最後なんですけど、Vibe Coding で、割と今 Vize とか rsvelte とかを作ってるじゃないですか。

@ubugeeei 52:56
そうなんですよ。Vibe Coding。

@baseballyama 52:59
私は Vibe Coding。Vibe Coding とかAIでね。

@TheoSteiner 53:04
うぶげさんは違いますか?

@ubugeeei 53:05
割と、まあ、コンテというか、規定は割と自分で、なんか書いたところは結構あるし、今も、まあ、なんかそんなにめちゃくちゃこう、雰囲気でコーディングしているというか、僕はない。そんなにないと言えばない。

@TheoSteiner 53:22
Vibe Coding っていう、ちょっとよくない単語かもしれないんですけど、コードの大半をAIが書いて、それが作者がレビューする感じをイメージしてましたけど。

@ubugeeei 53:39
コードリーディングはめちゃくちゃやってる。その都度はレビューしてるのではないですが、ただこれは正直僕はそれ以外の時間は仕事してますけど、仕事も一緒で、別にチームメンバーの他の人が実装して、リードの人は、すごい細かいところまでは見てないという構造は別に変わってないと思ってて、僕はまだそこの範疇を超えてはないんですよ、自分の中では。

@ubugeeei 54:03
別に多分これより多いですけど、別に自分がそのチームを抱えていると考えている程度には多分理解はするし、見てるんで、丸投げという感じではない。それこそ本当にあんまり変わってないんです。

@ubugeeei 54:21
単にそれがお金を払って人に書いてもらってたのか、自分であれを払って、生成AIに生成できるようになったかの違いで、なんかそういう、元々の話は何の質問です?

@baseballyama 54:34
Vibe Coding してますかみたいな。

@ubugeeei 54:36
やばい、わずに。いや、あ、だから…まあ、だから…

@TheoSteiner 54:39
あの、Vibe Coding が、すごい今、Vibe Coding じゃなくても、AI を使ってコードを書くという時代になってきたと思うんですけど、その時代で、なんで、Vize とか、rsvelte とか、それより抽象的な Vue とか Svelte をそもそも挟むのかっていう質問ちょっとしたくて。

@TheoSteiner 55:04
もうAIが直接JavaScript書けばいいじゃんって。それの方がAIの精度次第なんですけど、パフォーマンスがいいケースもあると思うんですけど、人が読みやすいためのフレームワークだと思うんですけど、それを今でも保つ必要ってあるのかなーって。

@ubugeeei 55:24
うわーこれ難しい。

@ubugeeei 55:30
1個多分共通してあるのは、普通に意地みたいなのがある。普通に Vue とか Svelte を好きだから、普通にそのツールチェーンを作っているという、それが1個あると思うんですけど、山さんは何かありますか?

@baseballyama 55:45
あれですよね、JavaScriptを直接書くっていうのは、document.appendChild みたいなやつをしていくってことですよね。読めなくないですか?

@ubugeeei 55:55
別に読めなくてもいい。AIで普通にフロントエンド、僕たちUIを作る人たちは別にフレームワークとか使わずに、AIでJavaScriptを書かせれば、その。

@ubugeeei 56:10
今までは、JavaScript をちゃんと読んで、JavaScript を変えてしないといけないけど、その手間を、ある種のフレームワークにやっていた一種の仕事を、一部、巻き取れるんじゃないか。

@baseballyama 56:21
僕的には、これ結構、アセンブリとか機械語を直接AIに書かせればいいじゃんって言ってる方たちいらっしゃると思うんですけど、それと同じような話ですよね。僕としてはまずね、仕事と趣味で分かれるかなと思って。仕事の場合って結局最終責任は自分で取らなきゃいけないので、結局自分が読めるコードに、自分がその本気になればちゃんと理解できるコードには少なくともなってなきゃいけないっていう風に思うんですけど、

@baseballyama 56:51
僕の能力だと、プロダクションで使うほどの大量のコードが全部 document.appendChild みたいな、コンパイル後の Svelte コードみたいなのに書かれてたら、正直僕は理解できない。そうすると最終責任は自分が取れないので、

@baseballyama 57:04
もっと人間工学的なというか、読みやすい言語で書かれている必要があるというのがまず仕事においては思うことです。趣味においては確かにそれでもいいのかもしれないが、趣味の中でもいくつかに分かれる気がしていて、本当に動けばいい。

@baseballyama 57:22
本当にホビーアプリで動いたらそれでOKみたいなものは正直それでもいいと思う。ビルドとかも不要だし、簡単にデプロイできるだろうし、便利だからそれはそれでいいと思う。ただメンテナンスしていきたいとかオープンソースにして、いろんなコミュニティに使っていってもらいたいみたいな、反映させたいっていうふうに思う場合は、どこかのタイミングで、多かれ少なかれ、品質みたいなところも、MITライセンサーとしても多少責任感は持つもんだと思うんですよね。

@baseballyama 57:49
そうなったときに、全くメンテナンスのできないコードだと、結局仕事の話と一緒で、全く責任が持てないってことになっちゃうと、それはちょっとプロジェクトとしてどうなんだっていうのは個人的には思うので、SvelteとかVueとか、React でもなんでもいいんだけど、非常に人間にとって読みやすいもの。

@baseballyama 58:05
書かざるを得ないんじゃないかなと、意見ですかね。

@ubugeeei 58:09
あと、それももちろんあるし、結局、AIも別にコンパイル後のJavaScriptの方が読みやすいかと言われると、別に読みやすくないと思う。例えば、ミニファイされた min.js みたいなものをひたすら生成してきて、それをAIが読んで理解することってめっちゃ時間かかりそうだなと思うと思う。

@ubugeeei 58:30
しっかりなっていく。AIも読めないから、等しく。僕はむしろ、より高レイヤーで、速くて賢くて決定的で、リッチなやつがあればあるほど、むしろAIが書くスピードは上がると思っていて作ってるし、さっき言ったようにすごい冒頭に、山さんの検証

@ubugeeei 58:53
とかのサイクルが速い方がいいみたいなことを言ってたと思うんですけど、そこがめちゃくちゃ機能が豊富でっていう方が、AIにとってもいいはずなんです。AIで何かを作るとき、それは React なのか Vue なのかみたいなのは、もちろん好みの差が結構あると思いますけど、そういうところがあるんで、AIだからっていうのもあんまりなさそうだなって思っている。

@ubugeeei 59:20
って感じをしていますね。

@baseballyama 59:23
なんかさ、ASIとか言われて、すごい強能力になって、2030年に人類滅亡しちゃうんでしょ?ああ、いいです。

@ubugeeei 59:33
僕は本当に心待ちにしている。

@baseballyama 59:37
それぐらいすごいね、AIなんだとすれば、まあそこは非常に彼らにとって、AIを彼らと呼びましたけど、非常にさまつな議論である可能性はあるかなと思う。

@ubugeeei 59:48
最近のAIモデル、急にチューニングで、人間が理解できない言葉を中間性カウントとして遊んでるみたいな、最近Twitterに出ました。途中経過を見せると言っているわけのわかりません。

@TheoSteiner 60:04
そうですね。結局、頭いい人が、みんな低レベルで考えてるわけでもないですよね。頭いい人が雑で書くプログラムをアセンブリーで書いてるわけではないから、頭いいAIも抽象度の高い言語の方が考えることが多分低くて、もっと大事にしたいところに注目を注げるみたいなことができるから、意外と同じかもしれません。

@ubugeeei 60:36
スケールと使いどころの使い分けと話で、結局それは今までも一緒という感じになります。先ほども言ったら、山さんみたいに、どれくらいのプロダクトの規模を見押されているのかわからないですけど、あのぐらいの規模をそのJavaScriptで考えると困るなぁ。

@ubugeeei 60:51
フレームワークも欲しいよねみたいな。そういうところももちろんあるなぁ。普通に個人のウェブサイトとかを作れるんだったら、もちろんいらない可能性もあるし、なんか普通に使い分けとか、どれくらいスケールしたいかとか。なんかどれくらい責任を持たないといけないかとかいうところに寄ってきて、これという銀の弾丸があるわけじゃなくて、結局使い分けだから、まあどっちも発達してる方が良いという結論かもしれない。

@baseballyama 61:15
ちなみにちょっと話戻りますけど、rsvelte は、さっきあの、Vize、rsvelte で、Vibe Coding してるんですか?みたいな質問にちょっと戻るんですけど、rsvelte は、まあ今の話はちょっと関わりあるんですけど、意図的に AI に任せる範囲を広くしてるんですよね。

14. AI と進めるポートの実際 61:16

@baseballyama 61:35
さっき言ったように、仕事って自分でやっぱり責任を取らなきゃいけないので、AI に任せるって言っても、設計とかはすごく入念に考えるし、出てきたコードも構造的におかしくないかとか、あと特にデータベースのマイグレーションとかすごくよく見るし、それ以外のところも正直言って全部のコードが見れてるとは言えないけど、仕事として責任を果たせるようにできる限り努力している、ですけど。

@baseballyama 62:00
ただ、AIがどんどん能力が上がっていくんで、それがどこまで必要とされるのかっていうのは正直、懐疑的。AIを不必要に信じてなさすぎるみたいな可能性も全然あるわけで、そこのバランスはどこにあるべきかっていうのは結構難しい問題だなと思います。

@baseballyama 62:14
だけど仕事は責任を取らなきゃいけないから、リスクを取りすぎることはできないので、AIに任せっきりっていうのはできない。なので、そのリスクをrsvelteで、とってみようっていうのが、1個コンセプトとしてあります。非常に矮小化して、実際には違うんだけど、非常に矮小化して言うと、rsvelteは最初、SvelteのコンパイラーをRustに移植したいです。

@baseballyama 62:35
で、コンパチビリティを取りたいので、Svelteのプロジェクト、コンパイラーのプロジェクト、同じディレクトリ構成で同じ感じで実装してくださいってだけ言って、それで非常に極端に言えば、今まで来ているんですよね。ただ、それで、もう100プロジェクト以上の実際のSvelteファイルで、比較、本家のSvelteファイルとの互換性をとって、ほぼ100%互換性がある状態まで来ていて、それだけ互換性があると、正直、だいぶ安心感はある。

@baseballyama 63:02
大体のプロジェクトは動くし、安心感はあって、だから、動くものはある程度できたし、Svelteでバージョンが上がっていくって、それにも準リアルタイムで追従しているんですけど、追従も、それなりにちゃんとできている。だから、AIに完全に任せっきりのプロジェクトとしては、ある程度動くもの、使えるものができつつあるっていう成果は得られているんですよね。

@baseballyama 63:23
次、問題は、これはちょっとさっきの話に戻りますけど、新しい大機能とかを実装したいとなったときに、AIが書いた、ある種の謎コードに対して、どうやって新しい機能を入れていけばいいか、みたいなのが問題になったりとか、あと複数人でやっていくときに、コードの内部が誰もわからないみたいな状態のときに、本当にメンテナンスできるのかっていうのは次の問題としてある。

@baseballyama 63:41
で、仮にrsvelteをSvelteのオーガニゼーションに移植するんだとしたら、もう少し改めて内部のところを見て、設計どうするかとかをしっかりとやった上で、リファクタリングをしっかり入れて、で、ある程度人間的にも読みやすいコードにした上で移植するみたいなことは、最初はしなきゃいけないと思ってるんだけど。

@baseballyama 64:00
どこまでAIに実際に任せられるのか、みたいなことを検証してみたいっていうのもあって、僕は意図的にVibe Coding の比率を上げて、rsvelteで取り組んでるっていうのはある。そこは少しVizeとスタンスが違う。

@ubugeeei 64:14
このプロセスの話、もうちょっとすればよかったです。

@baseballyama 64:18
まだできますよ。時間切れっていう概念はない。

@ubugeeei 64:21
いや、なんかそうなんですよね。これなんか、結構AIって、まあ、AIに限らずですけど、既存のツールチェーンを置き換えるときのアプローチの違いが結構あって、最近流行ってるのは、ポート。AIでこう、ファイルでも本当に1対1対応ぐらい。

@ubugeeei 64:38
それをAIでやるか、人の手でやるか、決定的なツールを使うのか、いろんなプロジェクトによると思うんですけど、手法としてのポートっていうやつと、普通に自分から作るってやつ。Vizeはどうやって最初作ったかっていうと、実はそのどちらでもなくて、本家のコンパイラーから大量のフィクスチャーを生成、頑張ってAIを使いながらして、そのフィクスチャーと完全一致するように、普通にRustで書き直したっていう。

@ubugeeei 65:07
フィクスチャーを間に合流している感じで、ファイル単位のTypeScript の実装をRustにポートしたわけでもないし、普通にVue Compilerを作れないですみたいなところからRustで書いたわけでもなくて、めちゃくちゃ大量のフィクスチャーを事前にめっちゃ作って、それを目指して、ゼロからRustでコードを書かせる。

@ubugeeei 65:31
それをアプローチだっていうのは結構…rsvelte とプロセスが違って面白いなと。

@baseballyama 65:38
rsvelte は比較的長い間、JS側が本家であり続けるという状態が続くというのは簡単に予想できることなんで、そうするとJavaScript でこういう変更があったから、例えば、Svelte のコンパイラーって、ステップが3つにとりあえず分かれてて、Parse して、Validate して、Transform するっていう風になってるんですけど、どのレイヤーでやるかっていうのは、微妙に曖昧になってる時もあるんですよね。

@baseballyama 66:02
どのレイヤーでやるかによって、エラーの出方が違ったりとか、これは単にバグかもしれないけど、この場合に普通にコンパイルできちゃうとか、そういうのが起きる可能性がある。同じ実装するにしても、どのレイヤーで何をやってるかっていうのが多少重要になってくることがあるんですよね。

@baseballyama 66:20
そうなってくると、JavaScriptで実装した、このレイヤーでこれやった、このレイヤーでこれやった、それをそのままポートすると、そういう問題は起きづらいっていうので、それがいいかなと思ってやってみた。

@TheoSteiner 66:33
割と忠実にポートしてる感じ?

@baseballyama 66:36
実際に見ると、ディレクトリ構造の大きいところ、Svelteのコンパイラーは1、Parse、2、Validate、3、Transformとか確かなと思うんですけど、その中は結構違う。忠実に、One File to One File みたいな感じでポートできてるわけでは実際にはないんですけど、おおむね、そういう風なポートになってるっていう。

@TheoSteiner 66:58
まあ、RustとJavaScriptも結構違うから忠実にポートできるともちょっと思えない。

@baseballyama 67:04
だし、あとライブラリ、例えばesrapみたいなライブラリとかを使ったりしますけど、当然esrapもRust版はなかったりとか、あと、パースのところでもOxcのパーサーを使うところはあるわけですけど、そことかも少しJavaScript のエコシステムが違ったりとか、エコシステム自体の使えるライブラリ自体の違いとかも結構あるので、完全に忠実に移植というのは当然できないわけですけど。

@TheoSteiner 67:29
ちなみに、HTMLのパースはどうして、HTMLっていうかテンプレートのところのパースはどうしてるんですか?

@baseballyama 67:34
テンプレートのパースは自力でやってます。

@ubugeeei 67:36
自力です。

@baseballyama 67:38
Vue も自力でやらなきゃいけない?

@ubugeeei 67:40
え?何が?

@baseballyama 67:42
Vue のテンプレートって、JavaScript で HTML、parse5 でパースできるけど、Rustは自力でやったほうがいい。

@ubugeeei 67:51
Vue も実は、結局最適化とかのことを考えると、汎用パーサーを使うよりも、Vue の…特化したパッチ当てたものを使うという、今の実装もそうなっていて、htmlparser2というライブラリがあるんですけど、それをフォークしてインターポレーションを拡張したやつをフォークして結局使った方が使うとすごいパフォーマンスがいいみたいなことで、結局そうなってあんまり…結局自力なんですよ。

@ubugeeei 68:24
結局自力でやってますっていうことは。

15. 本家コンパイラとの距離感 68:28

@ubugeeei 68:28
あと、さっきちょっと話を戻ると、山さんと明確に、結構スタンスが違うなと思っているところは、僕はVue.jsのコンパイラーの今の本家の実装をなんかすごくいい実装だと思っていないという、なんか、ありがて、言語、まあ僕結構言語処理系みたいなところのなんか、あのとか、すぐやったりじゃないですけど、そこがすごいこう、よくできた言語処理系かと言われると、全然そうではなくて、結構アドホックにワークアラウンドっぽい実装になってる部分とかがあって、そこをこう、もっとこう、フォーマット、さっきも言ってたように、フォーマットとか、もろっと丸めて、なんて言ったらいいですかね、ちゃんと、ちゃんとするって言ったら変ですけど、垂直統合をちゃんと設計からやって言語処理系としての、すごいいい実装をしたかったっていう、そもそも、本家のコンパイラーのことをそんなにめっちゃ気に入ってるわけでもないかなって。

@ubugeeei 69:26
そこも目指してないみたいなところが、結構スタンスとして明確に違う。実際にこういう仕組みになっていれば、こういう新しい機能とかもうちょっと簡単に実装できるのになとか、結構いっぱいあって。めちゃくちゃわかりやすいところで、コンパイラーマクロとかも本当にコンパイラーマクロとして解析しているというよりかは、普通にJavaScriptのASTをパースして、ファンクションコーリングと同じゲームを取り入れて、ごちゃごちゃごちゃやってるんですけど、まあまあ、なんか、Vueの概念としてはコンパイラーマクロはコンパイラーマクロって、ちゃんとオーバーアイルさせた方がいいだろうみたいな。

@ubugeeei 70:00
IRとか持った方がいいだろうっていう、設計をそもそも僕は変えたかったというか、まあ、なんで、結構そこは明確に、何か山さんとは違うなって思って。

@baseballyama 70:12
あんまりこういうのも言うのもあれかもしれないけど、Svelte 4までだったら、もしかしたら同じことをやってたかもしれない。やっぱSvelte 4までって、あれはSvelte 1の時からずっと同じコードベースだったのかわかんないけど、まあ、Rich Harrisも、コンパイラーを書くのは、多分、Svelteが初めてだったんじゃないかな。

@baseballyama 70:36
だから、よかったんだけど、やっぱり、だんだんと積み上がってきたものだったりとか、あとは、どうしてもね、イシューとかで、どうしてもちょっとソースコードが理解するのが難しくて、貢献しづらいですって、イシューはたまにあったんですよね。

@baseballyama 70:54
で、まあ、非常にわかりやすいコードかと言われると、まあ、手放しでそうとも必ずしも言えないような場面っていうのもあったんですけど、まあ、Svelte 5 っていうのは、あれは実はDominic GannawayというReactチームだった人とか、あとはInfernoとかを作った人で、今、RippleとかOctaneとかを作ってらっしゃる方ですけど。

@baseballyama 71:14
TSRX。TSRX。

@TheoSteiner 71:16
OpenAIにいる方。今、OpenAIにいる方ですね。

@baseballyama 71:19
非常に広範の実装、広い範囲の実装をやられていて、彼はコンパイラー周りとJavaScript のツールチェーンを非常によく書いていたので、全く一から作り直したので、そういう意味で非常にわかりやすくなったのと、Svelte 5 でRunesが入って、Svelte 4 まではコンパイラーでやってたレイヤーのことが一部ランタイムに移植されたことで、そもそもコンパイラー自体の難易度っていうのも下がったっていうのもあって、Svelte 4 の時に比べると非常にシュッと。

@baseballyama 71:50
オーガナイズされたっていうのはあったんですよね。まあ、ていうのは背景としてあるかもしれないですね。

@ubugeeei 71:55
でも、それで言うと、実際、VueもV2からV3に書き直されたりとか、随時リファクターもされてるんで、別に読みづらいコードかって言われると、そんなことないです。だから、ちゃんとソースコードが設計されてるんだけど、僕が書きたい言語処理系ではなかったという方が適切かもしれないですね。

@ubugeeei 72:14
なんか、そんな感じ。ちょっとだけ弁明みたいな感じがしたけど、別にVueの実装はあれはあれで、別に特に問題ないというか、そんなにすごい無法なことをやりまくって読みづらいとかってところがあるわけじゃないけど、ちゃんと整理されてはいるんだが、Vue.js Core のところって本当にコンパイラーとしてしかそれをやられていない。

@ubugeeei 72:38
ツールチェーンとか、Vue.js っていうひとつの、プログラム言語とかを考えるときに、他のRustとか、いろいろ他の言語とかでやってるような、ちゃんと言語処理系としての設計がちゃんとされているかと言われると、別にそうでもない。

@ubugeeei 72:55
タイプチェッカーとかもそうですけど、タイプチェッカーはタイプチェッカーで別のパーサーというか、別の中間表現で生成していないとか、別のこねくり回し方を教えて、そこをうまく一つの言語としてユニファイしたくて、設計から自分で考えたと言ったらいいですけど、そういうところがありかなって感じ。

@ubugeeei 73:13
コンパイラー、Vue もね、コンパイラー、コンパイラーだけで見るなら別に問題のあることではないと思います。

16. Vue Fes・Svelte Summit の告知 73:21

@TheoSteiner 73:22
いや、本当に今日、お二方呼んでよかったなと思ってて、なんか割と似た目的で、アプローチが全然違うなっていうことが分かってきて、で、なんかソースコードを読むだけで、ちょっと準備で斜め読みしてみたんですけど、なんかそこまで分からなかったので、なんかあえてこうやって比較して終わったなと思います。

@TheoSteiner 73:44
で、なんかそろそろ時間も1時間超えてきたので、なんかちょっと…終わりにしたいと思うんですけど、お二方がそれぞれのプロジェクトについて登壇すると思うので、その登壇のアピールと、もし何かあれば最後の言葉お願いできたらなと思います。

@ubugeeei 74:03
確かに、Vue Fesの話をすると序盤に言うたけど、全然Vue Fesの話してない。

@ubugeeei 74:10
アピールしたいことは、ああ、まあ、ないと言えばない。僕、一応、スピーカーではあるけど、スタッフもやっているので、ぜひ、まだチケット買ってない人は買ってくださいと、すごいオフィシャルな宣伝で、あと自分の、なんかあれは販売ないかも。

@ubugeeei 74:28
山さんの方があると思いますか。なんか、スピーカーとしてもアピール。山さんの方が実は多いかもしれない。僕結構、運営目線で。そうですね。

@baseballyama 74:40
まあ、Vue Fes、技術イベントっていうと、僕のすごい、僕の中の昔のイメージとか、大学とかに行って、教室でこうやっているような、Google のやつとか、なんかそんなイメージが僕、あったんですけど、Vue Fes って、フェスっていう名前がついているんですけど、まああの、講演を聞くことももちろん楽しいんですけど、まあ、なんだろうな、その場自体が結構テンションが上がると言ったら、非常に楽しめる場。

@baseballyama 75:18
特に、去年くらいからかもしれないですけど、Vueだけじゃなくて、Oxcを中心としたエコシステム。VoidZero社が、今、買収されてCloudflareになりましたけど、そういうエコシステムの最先端みたいな話とかも聞けるんで、勉強にもなるし、場として単純に楽しいみたいなのがあるのかなと思います。

@baseballyama 75:37
なんでまあ、ぜひチケット買ってね。まあ、僕、運営でもなんでもないんで、ただ言わされてるだけなんですけど。チケットはぜひ買っていただけると、すごくいい時間にはなるんじゃないかなと、個人的には。

@ubugeeei 75:50
はい。運営よりも素晴らしい、Vue Fesの紹介をありがとうございました。

@TheoSteiner 75:54
いや、でも、本当にまさにその通りだなと思ってて。本当に祭りで、発表も面白くて。あと、発表以外のホールウェイトラックっていう英語だとそういう言い方があるんですけど、廊下のトラックっていうんで、Vue Fes 特有のものとかじゃなくて、カンファレンスにはホールウェイトラックっていうものがあって、そこは単純に廊下で会う人と話したり、そこで新しい学びとかあったりすると思うので、Vue Fes はそういう技術にパッションを持つ人が結構集まるようなイベントなので、ぜひ行ってほしいな。

@TheoSteiner 76:30
で、山さんが、Vue Fes と関係ないんですけど、僕ちょっとSvelteかぶれなんで、そこの応援っていうか、報告も入れたいなと思ってるんですけど、Svelte Summit。

@baseballyama 76:44
そうですね。11月の19日と20日の2日間ですね。Svelte Summitは。スロベニアのリュブリャナっていうところであって、ちょっと気軽にはいけない。直通便もないんで乗り継ぎで行くっていう感じであるんで、ちょっと気軽に行ける感じではないんですけど、そこで2日間Svelte Summitっていうのがあります。

@baseballyama 77:05
で、あの僕もこのrsvelteでちょっと発表してみようかなと思ってます。これはおそらくオンラインの配信とかはある。あると思います。はい。オンラインとかで聞いたりとかできるかなと思います。もちろんRich Harrisさんとかも出ると思うので、そういう発表とかも楽しみにできるかなと思いますし、非常に時間とお金がある方は、ぜひリュブリャナに来ていただけると、日本人勢としてはちょっと嬉しいなと思います。

@ubugeeei 77:33
山さんは現地で喋るんですか?

@baseballyama 77:35
僕は現地に行きます。

@TheoSteiner 77:38
僕はちょっと、今回は行けなさそうだけど、山さん頑張ってください。ありがとうございます。

17. クロージング 77:44

@TheoSteiner 77:46
というわけで、今回のUIT INSIDE Podcast を終わりにしたいと思います。また、ありがとうございました。

@ubugeeei 77:54
ありがとうございました。

@baseballyama 77:54
ありがとうございました。