Placeholder Image

字幕表 動画を再生する

AI 自動生成字幕
  • The first stage of VEET really was like, let's just make things work and make it better than the status quo, but underneath there might be a lot of, you know, hacks and things we want to improve in the future.

    VEETの最初の段階は、とにかく現状より良くしよう、うまくいくようにしようという感じだったが、その下にはハックや将来的に改善したいことがたくさんあるかもしれない。

  • And now it's the proper time to do it.

    そして今、それを実行する適切な時なのだ。

  • Hello, welcome to DevTools FM.

    こんにちは、DevTools FMへようこそ。

  • This is a podcast about developer tools and the people who make them.

    このポッドキャストは、開発者用ツールとそれを作る人々についてのポッドキャストです。

  • I'm Andrew.

    僕はアンドリューだ。

  • And this is my cohost, Justin.

    そしてこちらは私の共同司会者、ジャスティン。

  • Hey everyone.

    やあ、みんな。

  • We're really excited to have Evan Yu joining us again.

    またエヴァン・ユーに参加してもらえることを本当にうれしく思っている。

  • Evan, you were with us on episode 12 back a few years ago talking about VUE and VEET.

    エヴァン、君は数年前のエピソード12でVUEとVEETについて話してくれたね。

  • And we are now like 119 as of recording.

    そして今、レコーディングの時点で119人になっている。

  • So over a hundred episodes ago.

    だから100話以上前だ。

  • Wow.

    すごいね。

  • That's, that's a lot of episodes.

    それは、それはたくさんのエピソードだ。

  • We've been doing it a while, but it's, it's so fantastic to have you back.

    しばらくやっていたけど、君が戻ってきてくれて本当に嬉しいよ。

  • We are continually big fans of your work and how it shapes the ecosystem.

    私たちは、あなたの仕事とそれがエコシステムを形成する方法の大ファンであり続けている。

  • So excited to chat again.

    またおしゃべりできるのがとても楽しみ。

  • And we're going to talk about what you're up to these days.

    そして、あなたの近況について話すつもりだ。

  • But before we dive into that, would you like to tell our listeners a little bit more about yourself?

    その前に、あなた自身についてもう少しお聞かせいただけますか?

  • Sure.

    もちろんだ。

  • Hi, I'm Evan.

    やあ、僕はエヴァンだ。

  • I am, I have been an independent open source developer since 2016.

    私は、2016年から独立したオープンソース開発者です。

  • And I worked on VUE.

    そして私はVUEで働いた。

  • I still actually still work on VUE.

    実はまだVUEで働いているんだ。

  • I work on VEET.

    私はVEETで働いている。

  • And just recently we started a company called Void Zero and focus a bit deep, even deeper that goes into, you know, the full JavaScript tool chain, starting from servers, no, no, no, starting from parsers to linters, formatters, bundlers, transformers, everything that supports higher level tooling.

    そしてつい最近、私たちはVoid Zeroという会社を立ち上げ、サーバーから始まり、いやいや、パーサーから始まり、ライナー、フォーマッター、バンドラー、トランスフォーマーなど、より高度なツーリングをサポートするすべてのJavaScriptツール・チェーンに、少し深く、さらに深くフォーカスしています。

  • So the bundler we're building called Rodan is going to support VEET in the future.

    だから、僕らが作っているロダンというバンドラーは、将来的にVEETをサポートする予定なんだ。

  • And VEET is now supporting a lot of other frameworks.

    そしてVEETは現在、他の多くのフレームワークをサポートしている。

  • So essentially we're trying to build this vertical unified tool chain that can support all the frameworks that depend on VEET today and hopefully make everyone's development experience better.

    そのため、基本的に私たちは、現在VEETに依存しているすべてのフレームワークをサポートできる垂直統合ツールチェーンを構築しようとしています。

  • So back, back on that old episode, a long ago, you had actually just released VEET.

    昔、VEETがリリースされたばかりでしたね。

  • And since then it's really become like a pillar of the industry.

    それ以来、業界の柱のような存在になっている。

  • Like many a meta framework is based on it now.

    現在、多くのメタ・フレームワークがそれに基づいている。

  • And it's like the starter pack for everything.

    すべてのスターターパックのようなものだ。

  • What was the journey from getting, going from VEET to, oh, we actually have to rebuild most of what's below the surface level and form a company around that?

    VEETの設立から、表面レベル以下のほとんどのものを再構築し、それを中心に会社を設立するまでの道のりはどのようなものだったのでしょうか?

  • Yeah.

    そうだね。

  • I think the idea started at one point because when I first started VEET, I was just doing a prototype, honestly, right?

    というのも、VEETを始めた当初は、正直なところ、プロトタイプを作っただけだったんだ。

  • So I pretty much just took whatever that's available out there and try to fulfill the goals.

    だから僕は、そこにあるものは何でも取り入れて、目標を達成しようとしたんだ。

  • And there were a lot of trade-offs and nowadays I consider them kind of hacks because I didn't have the, you know, the bandwidth to do all the things myself.

    そして、多くのトレードオフがあり、今となってはハックのようなものだと考えている。

  • So I have to use what other people have built.

    だから、他の人が作ったものを使わなければならない。

  • And that's, I think that's typically what we've been doing in the Java ecosystem because we feel like, okay, like we don't want to necessarily reinvent the wheels.

    Javaのエコシステムでは、車輪を再発明する必要はないと考えているからだ。

  • Why not just use things people have already done?

    すでに人々がやっていることを使えばいいじゃないか。

  • So in the beginning we were, I was using Rollup because I've always liked Rollup's

    当初はロールアップを使っていた。

  • API and then we ran into performance issues because, so the first step of VEET was to have a native ESM dev server, right?

    VEETの最初のステップは、ネイティブのESM開発サーバーを持つことでしたね。

  • That sounds simple.

    簡単なことのように聞こえる。

  • And then we use Rollup to try to handle the dependencies because some dependencies are in CJS.

    そして、依存関係がCJSにあるため、ロールアップを使って依存関係を処理しようとする。

  • We want to convert them to ESM so they can load in the browser.

    それらをESMに変換し、ブラウザで読み込めるようにしたい。

  • But Rollup was actually quite slow if you have large dependencies.

    しかし、Rollupは依存関係が大きい場合、実際にはかなり遅かった。

  • And so we started using ESBuild for that purpose.

    そのためにESBuildを使い始めた。

  • And then we tried using ESBuild for production bundling and it was not satisfactory because it has no control over how the chunks are split.

    そして、ESBuildを本番のバンドルに使ってみたが、チャンクの分割方法を制御できないため、満足できるものではなかった。

  • And the way ESBuild splits code is just a bit counterintuitive if you're building applications.

    また、ESBuildがコードを分割する方法は、アプリケーションをビルドしている場合、ちょっと直感に反する。

  • So we're like, okay, now we need to think about, okay, we use ESBuild for development and pre-bundling, but we use Rollup for production bundling.

    開発用とプリバンドル用にはESBuildを使い、本番用バンドルにはRollupを使う。

  • And we kind of smoothed over the surface to make them work kind of the same way.

    そして、同じように機能するように表面を滑らかにしたんだ。

  • Right?

    そうだろう?

  • And later on when people started building real applications with VEET, for example, when people are using VEET with React and previously everyone was using Babel because Babel was supported.

    その後、人々がVEETを使って実際のアプリケーションを作り始めたとき、例えば、人々がReactでVEETを使っているとき、以前はBabelがサポートされていたので、誰もがBabelを使っていた。

  • Interestingly, if you use VEET by default and you write JSX in TypeScript, they are transformed using ESBuild, which is quite fast.

    興味深いことに、デフォルトでVEETを使い、TypeScriptでJSXを書くと、ESBuildを使って変換される。

  • But the moment you want hot module replacement for React, now you need to use Babel because ESBuild does not support hot module replacement transforms.

    しかし、Reactのホットモジュール置換をしたい場合、ESBuildはホットモジュール置換トランスフォームをサポートしていないため、Babelを使用する必要がある。

  • So then Babel, again, made everything slow.

    だからバベルは、またしてもすべてをスローにした。

  • So people also came up with an SWC version of the React plugin.

    そこで、ReactプラグインのSWCバージョンも開発された。

  • So you see the problem here is there are great tools out there, but some of them do this, some of them do that.

    つまり、世の中には素晴らしいツールがあるけれど、あれもこれもできるものがあるということだ。

  • And now some of the things they both do, they decide to do them differently.

    そして今、2人がやっていることのいくつかは、違うやり方でやることにした。

  • And that's the reality that we're kind of dealing with in a JavaScript tooling ecosystem.

    それが、JavaScriptツールのエコシステムで私たちが直面している現実なのだ。

  • I'm pretty sure if you've worked with custom build stacks long enough, you understand what I'm saying, right?

    カスタムビルドのスタックに長く携わってきた人なら、私の言っていることが理解できるだろう?

  • So in a lot of ways, the reason people love VEET is because we kind of hide this complexity away from them and try to give you a very smooth and consistent entry point so that you don't need to think about these things.

    つまり、VEETが人々に愛されている理由は、このような複雑なことを隠蔽し、非常にスムーズで一貫したエントリー・ポイントを提供することで、このようなことを考える必要がなくなるからなのです。

  • But we're kind of, for me, I think we achieved this goal with the initial version of VEET, but long term wise, when people are starting putting more and more dependence on VEET, right, we've seen more and more frameworks moving over to use

    しかし、VEETの初期バージョンでこの目標は達成できたと思うが、長期的には、人々がVEETにますます依存するようになり、より多くのフレームワークがVEETを使用するようになる。

  • VEET as the base layer, I kind of start to worry because I feel like, you know, the internal is not as pretty as it should be.

    VEETをベースレイヤーにすると、なんだか心配になってくるんだ。

  • And we kind of just swept all the deeper problems under the rug and pretend everything is great.

    そして私たちは深い問題をすべて水に流し、すべてが素晴らしいかのように装ってきた。

  • So I guess deep down, you know, along with VEET's growth and adoption, I've always had this, like, inner urge to say, like, is it really up to the task of being the future of all these, like, next generation frameworks serving as the infrastructure?

    VEETが成長し、採用されるにつれて、私はいつも心の奥底で、VEETは本当にインフラとして機能する次世代のフレームワークの未来にふさわしいのだろうか?

  • Will VEET be able to live up to that expectation?

    VEETはその期待に応えられるだろうか。

  • And I don't think it will if we just keep using this sort of fragmented internals and try to stitch things together and smooth all of the inconsistencies.

    そして、このような断片的な内部構造を使い続け、物事をつなぎ合わせ、すべての矛盾を解消しようとしても、そうなるとは思えない。

  • In a way, the tool chain we're building right now at Voice Zero is an attempt to kind of attack this problem more fundamentally.

    ある意味、私たちが今Voice Zeroで構築しているツールチェーンは、この問題をより根本的に攻撃する試みなのだ。

  • Let's say, like, if we want to solve all the problems we want to fix in VEET, what do we need? We need a bundler that actually is designed for it.

    例えば、VEETで解決したい問題をすべて解決しようと思ったら、何が必要だろう?実際にそのために設計されたバンドラーが必要だ。

  • And we need this bundler to be also built on top of a tool chain that can, you know, handle all the different concerns, like starting from the AST all the way to minification and production, bundling, right, through a consistent system.

    そして、このバンドラーは、ASTから始まり、最小化、生産、バンドルまで、一貫したシステムを通して、すべての異なる懸念を処理できるツールチェーンの上に構築される必要がある。

  • And at the same time, we also want to make each part of this tool chain individually usable.

    そして同時に、このツールチェーンの各パーツを個別に使えるようにしたい。

  • So let's say you want to just take the parser and do something crazy with it.

    では、パーサーを使って何かクレイジーなことをしたいとしよう。

  • You can totally, you should be able to do that, right?

    全然できる、できるはずだよね?

  • This tool chain, although it's unified and it's a coherent system, it should not be a black box, right?

    このツールチェーンは、統一された首尾一貫したシステムだが、ブラックボックスであってはならない。

  • You should not have to say, like, you either take it all or you can never use it.

    全部取るか、絶対に使えないか、などと言うべきではない。

  • So I think that's, these are the two main premises that we're sort of centering the tool chain around is unification, but without sacrificing the ability to, of composability.

    つまり、この2つの大前提があるからこそ、ツールチェーンの中心は統一されたものでありながら、コンポーザビリティを犠牲にすることはないのです。

  • We'd like to stop and thank our sponsor for the week, Mux.

    今週のスポンサーであるMuxに感謝の意を表したい。

  • If you haven't heard of Mux, Mux is an awesome platform that makes adding video to your product easy as adding a few libraries.

    Muxをご存じない方もいらっしゃるかもしれないが、Muxは製品にビデオを追加する際に、いくつかのライブラリを追加するだけで簡単にできる素晴らしいプラットフォームだ。

  • If you never had to add video to a product, you don't know how many pits of failure there are, whether it's file formats, delivery, uploads, or even playback.

    製品にビデオを追加したことがない人は、ファイル形式、配信、アップロード、あるいは再生など、どれだけの失敗の落とし穴があるかわからない。

  • There's so much to worry about and so much that will bog your team down while trying to ship a stellar product.

    優れた製品を出荷しようとしている間に、心配しなければならないこと、チームを停滞させることがたくさんある。

  • So that's where Mux comes in.

    そこでMuxの登場だ。

  • They have a set of APIs and components that make adding video playback to your app or platform super easy.

    APIとコンポーネントのセットがあり、アプリやプラットフォームに動画再生を追加するのがとても簡単になる。

  • And since there are a bunch of experts that know video inside and out, they'll have so many different features that your team would never have the time to get to.

    また、ビデオを知り尽くした専門家が集まっているため、あなたのチームでは到底手が回らないようなさまざまな機能を備えているはずだ。

  • One of those things being metrics, they have all sorts of different fancy metric dashboards to understand how people are consuming video in the apps that you ship.

    そのひとつがメトリックスで、アプリ内で人々がどのようにビデオを消費しているかを理解するための、さまざまな種類の派手なメトリックス・ダッシュボードがある。

  • Recently, they've been adding even more capabilities to their platform.

    最近では、そのプラットフォームにさらに多くの機能を追加している。

  • Now you can see when viewers dropped from your videos, so you can gain better insight into how people are consuming those videos.

    視聴者がいつ動画から脱落したかを確認できるようになり、人々がどのように動画を消費しているかをより深く知ることができる。

  • So if you want to add video to your platform and you don't want to spend weeks to months doing it, head over to Mux.com.

    あなたのプラットフォームにビデオを追加したいが、そのために数週間から数ヶ月を費やしたくないなら、Mux.comに行こう。

  • And with that, let's get back to the episode.

    それではエピソードに戻ろう。

  • So you've been a independent developer for a while and probably one of the most successful, being able to work on a lot of open source projects and produce a lot of very successful open source projects while working mostly on your own.

    ですから、あなたはしばらくの間、独立した開発者であり、おそらく最も成功した開発者の一人で、多くのオープンソースプロジェクトに携わることができ、ほとんど自分ひとりで仕事をしながら、非常に成功したオープンソースプロジェクトを数多く生み出してきました。

  • And now you're going this route of, so you've raised some VC, you're forming Void

    そして今、あなたはVCを調達し、ヴォイドを設立している。

  • Zero, you have a few people coming to join you to like work on this ecosystem tooling.

    ゼロ、このエコシステム・ツールの作業をするために、何人かがあなたに加わることになる。

  • So why did you decide to make that transition from independent developer to starting a company?

    では、なぜ独立系デベロッパーから起業に踏み切ったのですか?

  • And like, what about the timing or the circumstances made this a different choice?

    そして、そのタイミングや状況が、この選択を違ったものにしたのか?

  • So I think overall, I would actually consider myself a pretty risk averse person.

    だから全体的に見れば、僕はかなりリスクを嫌う人間だと思う。

  • Some of the biggest decisions I'd made in my life, I kind of feel like I just swinged it, but like going fully independent to work on Vue, I didn't really know what that would entail. Luckily, I think I built a lifestyle entrepreneurship, kind of lifestyle business thing around Vue.

    私の人生で最も大きな決断のいくつかは、まさにそれをしたような気がする。しかし、ヴューに取り組むために完全に独立するようなもので、それが何を意味するのかよくわからなかった。幸運なことに、私はVueを中心にライフスタイル起業家精神、ライフスタイル・ビジネス的なものを築き上げたと思う。

  • So that is enough to sort of support me and make my life sustainable.

    だから、それだけで僕の生活を支え、持続可能なものにしている。

  • So on top of that, right, I'm not starting a company because like, oh, we need to make more money. So that situation.

    それに加えて、もっとお金を稼がなきゃいけないから会社を始めたわけじゃない。だから、そういう状況なんだ。

  • It's more about starting the company is the more realistic way to essentially fulfill the vision that I'm trying to achieve.

    それよりも、会社を設立することが、私が達成しようとしているビジョンを本質的に実現するための、より現実的な方法なんだ。

  • So it's also partly based on the experience of working as an independent developer.

    だから、独立した開発者として働いてきた経験に基づいている部分もある。

  • I kind of know where the limit of the current model can go.

    現行モデルの限界がどこにあるのかはなんとなくわかっている。

  • I think a lot of people kind of use Vue and use me as a success story example for sustainability of any kind of projects.

    多くの人がヴューを利用し、あらゆる種類のプロジェクトの持続可能性の成功例として私を利用していると思う。

  • But at the same time, if you consider the scale, the scope of Vue, like we have more than two million users supported by, I think at max, we had like three people working full time on Vue related stuff.

    しかし同時に、Vueの規模や範囲を考えると、200万人以上のユーザーをサポートし、最大で3人がフルタイムでVue関連の仕事に従事していたと思います。

  • Like now it's probably still around three people that's actually full time on Vue.

    現在でも、Vueにフルタイムで携わっているのは3人程度だろう。

  • And then a bunch of part time contributors that we sponsor.

    そして、私たちがスポンサーになっているパートタイムの貢献者たち。

  • So it's sustainable.

    だから持続可能なんだ。

  • But at the same time, we don't really see it growing, say, to the scale where we can have like a team of 10 people working on it full time, right?

    しかし同時に、例えば10人のチームをフルタイムで働かせるような規模にまで成長するとは考えていない。

  • Because I intentionally try to build the business around Vue to be as passive and carefree as possible as a lifestyle choice.

    というのも、私はヴューを中心としたビジネスを、ライフスタイルの選択としてできるだけ受動的で気楽なものになるように意図的に構築しようとしているからだ。

  • But also that means the conversion rate, because it's not a for-profit business, like we don't do aggressive marketing or we don't push features to sort of drive profit or revenue.

    営利事業ではないので、積極的なマーケティングを行ったり、利益や収益を上げるために機能を押し出したりすることはありません。

  • So in a lot of ways, the conversion rate compared to the user kind of view is extremely slow, extremely low, right?

    だから、多くの点で、コンバージョンレートはユーザーの見方に比べて非常に遅く、非常に低いんだ。

  • And I'm not saying that's a bad thing.

    それが悪いことだとは言っていない。

  • For me, there's no sort of this or that in terms of open source sustainability or monetization.

    私にとっては、オープンソースの持続可能性や収益化に関して、あれもこれもということはない。

  • I think it all comes down to the goal you're trying to achieve.

    すべては、あなたが達成しようとしている目標に起因すると思う。

  • For me, Vue is a lifestyle business thing, and I think that's working very, very well for me, right?

    僕にとって、ヴューはライフスタイル・ビジネスなんだ。

  • I'm happy about that.

    それは嬉しいね。

  • But on the other hand, when I think about where Vite is going and thinking about the potential that Vite has and thinking about how we can actually maximize that potential and make the thing, you know, we hope it can be.

    しかしその一方で、ヴァイトの行く末を考え、ヴァイトが持っている可能性を考え、その可能性を最大限に引き出し、私たちが望むようなものにするにはどうすればいいかを考える。

  • And I don't see it happening with this sort of more passive model of like just hoping people donate, helping people sponsor, or hoping someone comes up with a business and decides to donate back to Vite, right?

    そして、人々が寄付してくれることを期待したり、人々がスポンサーになるのを手伝ったり、誰かがビジネスを立ち上げてヴァイトに寄付することを決めたりするような、このような受動的なモデルでは、それが実現するとは思えない。

  • That actually has a lot to do with, I think, partly with luck.

    それは実際、運も関係していると思う。

  • It takes time.

    時間がかかる。

  • It also has a lot to do with what layer the project stands on.

    また、そのプロジェクトがどのようなレイヤーの上に立っているのかにも大きく関係してくる。

  • For example, because Vue is a very user-facing framework, so most of the income that's generated by Vue is due to the exposure, due to the high exposure and documentation.

    例えば、Vueは非常にユーザーフレンドリーなフレームワークなので、Vueが生み出す収入のほとんどは、露出度の高さとドキュメンテーションによるものです。

  • And because when people use frameworks, they would likely interact with the documentation very, very constantly.

    そして、人々がフレームワークを使用する際、ドキュメントと常に接することになるだろうからだ。

  • BuildTools is quite different, right?

    BuildToolsは全く違いますよね?

  • It usually sits one layer below the framework.

    通常、フレームワークの1層下に位置する。

  • And also, when you set up BuildTools, once you get it working, you're happy with it.

    また、BuildToolsをセットアップする際も、一度動作させれば満足できる。

  • You really have to actually look at the docs every day.

    本当に毎日ドキュメントを見なければならない。

  • So when we go even lower, say like we're building parsers and toolchains like that,

    例えば、パーサーやツールチェーンを構築するような場合だ、

  • I've seen how projects like Babel struggle with funding despite such wide, almost universal adoption across the ecosystem.

    バベルのようなプロジェクトが、エコシステム全体で幅広く、ほとんど普遍的に採用されているにもかかわらず、資金繰りに苦労しているのを私は見てきた。

  • So I don't think that model is going to work for the things we want to build.

    だから、私たちが作りたいものにはそのモデルは通用しないと思う。

  • But at the same time, this is quite an ambitious goal.

    しかし同時に、これはかなり野心的な目標でもある。

  • So I can't imagine it being done with part-time efforts from just contributors who are like, oh, we want to work on this together.

    だから、一緒にやりましょうというような貢献者のパートタイム的な努力だけでは、実現するとは思えない。

  • I don't think that's going to happen, or at least it's not going to happen soon enough.

    そうなるとは思えないし、少なくともすぐにはならないだろう。

  • So I think the only realistic way for us to actually do it is to have enough resource, capital, to get people paid properly to work on a full-time and as a team, right?

    だから、私たちが実際にそれを実現するための唯一の現実的な方法は、フルタイムでチームとして働くために十分なリソース、資本、適切な報酬を得ることだと思う。

  • So we have a common mission, a common goal, and it's much more serious than your, let's contribute to open source after work on weekends, right?

    だから僕らには共通の使命があり、共通の目標がある。それは、週末に仕事が終わってからオープンソースに貢献しよう、というようなことよりもずっと真剣なことなんだ。

  • It's different.

    違うんだ。

  • So that also inevitably brings in a question of expectations from investments and returns.

    そのため、必然的に投資やリターンへの期待も問われることになる。

  • And I think one of the other goals of starting the company is because I always felt like it's a bit sad that the JavaScript ecosystem is relying on a lot of critical infrastructure that's maintained by people that's either underpaid or just as labor of love, right?

    会社を設立したもうひとつの目的は、JavaScriptのエコシステムが、低賃金で、あるいは愛の労働として、人々によって維持されている多くの重要なインフラに依存しているのは、少し悲しいことだと常々感じていたからです。

  • In a way, the ideal situation is we hope, okay, like big companies using these open source projects, making a lot of money, they should donate back, they should sponsor.

    ある意味、理想的な状況としては、大企業がオープンソースプロジェクトを利用し、大金を稼ぎ、寄付をしたり、スポンサーになったりすることだ。

  • And I think it's difficult because there is so much logistics that you have to go through to actually set up the proper organization like a foundations and align the incentives.

    財団のような適切な組織を設立し、インセンティブを調整するためには、非常に多くのロジスティクスが必要だからだ。

  • And there's a lot of lobbying, a lot of like just talking to people and getting people on the same page and to make things like that happen.

    そして、ロビー活動や、人々と話し、同じ考えを持つように仕向けることがたくさんある。

  • And smaller open source project authors really don't have the leverage or the time and the energy to make that kind of thing happen.

    そして、小規模なオープンソースプロジェクトの作者には、そのようなことを実現するための影響力も時間もエネルギーもない。

  • And it's uphill battle before you absolutely become kind of the critical infrastructure the entire ecosystem relies on, right?

    エコシステム全体が依存する重要なインフラになるまでには、苦しい戦いを強いられることになる。

  • So I think Voice Zero is also a different attempt where the end goal we hold is we have a sustainable business model that's mostly coming from bigger companies, enterprise, that's paying money that allows us to keep improving these open source parts and keep it free and open source for individual users, for smaller companies, startups, so that more people have, more JavaScript developers have free access to high quality tools.

    だから、Voice Zeroもまた違う試みだと思います。私たちの最終的なゴールは、持続可能なビジネスモデルがあることで、そのほとんどは大企業やエンタープライズからお金をいただいて、私たちがオープンソースのパーツを改良し続け、個人ユーザーや中小企業、スタートアップのために無料でオープンソースを提供し続けられるようにすることです。

  • At the same time, the tools should also be well sustained and maintained.

    同時に、道具は十分に維持・管理されなければならない。

  • So is your plan for monetization, like charging bigger companies to use the tools and then like letting it be open source free for everybody else?

    マネタイズの計画としては、大企業にツールの使用料を請求し、それ以外はオープンソースで無料にするといった感じですか?

  • Not exactly.

    正確には違う。

  • So we want to draw a line where if the code runs on your machine, it should be open source and free, right?

    だから、もしそのコードがあなたのマシン上で動くなら、オープンソースでフリーであるべきだという線を引きたいんだ。

  • We don't want to do things like, so one thing we definitely don't do is to ship something as open source and change the license later and hope people pay for it.

    だから、オープンソースとして何かを出荷し、後でライセンスを変更して、人々がそれにお金を払ってくれることを期待するようなことは絶対にしたくない。

  • That's just not the plan.

    それは計画外だ。

  • The plan is likely to build, so we do have plans on building associated services that's tied into each step of the way, because when you have a toolchain, you have natural tie into a lot of metadata every step of the way.

    というのも、ツールチェーンがあれば、当然、すべてのステップで多くのメタデータに関連付けなければならないからだ。

  • And how do you get deeper insights from these metadata?

    そして、これらのメタデータからどのようにしてより深い洞察を得るのか?

  • And how can we get higher quality metadata for each task you're performing on your code base, right?

    そして、コードベースで実行している各タスクについて、より質の高いメタデータを得るにはどうすればいいんだろう?

  • Overall, I think there's good opportunity to have, to improve upon what we're currently doing. For example, like how deep, how much deeper insights can we get from our bundles?

    全体的には、現在行っていることを改善する良い機会があると思う。例えば、バンドルからどれだけ深い洞察を得られるか?

  • Like, is your tree shaking accidentally failing?

    例えば、木が揺れて失敗したとか?

  • Is your chunk cache invalidation working consistently?

    チャンクキャッシュの無効化は一貫して機能していますか?

  • Are you bundling things that shouldn't really be in the production bundle?

    プロダクション・バンドルに入れるべきでないものをバンドルしていないか?

  • And is your code, after your code is transformed by all these tools, is it still as secure as the source code pretends to be?

    そして、あなたのコードは、これらのツールによって変換された後でも、ソースコードが見せかけているように安全なのだろうか?

  • There are a lot of questions that's hard to answer if you don't actually own the toolchain and be able to look at the source code from start, all the way back, all the way to minified in production that you actually ship to the users.

    実際にツールチェーンを所有し、ソースコードを最初から最後まで、そして実際にユーザーに出荷する本番でミニファイされたものまで見ることができなければ、答えるのが難しい質問がたくさんある。

  • So I think there's quite a bit of opportunity here, and we're intended to essentially build services that center around this space.

    だから、ここにはかなりのチャンスがあると思うし、私たちは基本的にこの分野を中心としたサービスを構築するつもりだ。

  • I can't do, I don't want to be too specific right now because there's obviously a lot of things that can change.

    今はあまり具体的なことは言いたくないんだ。

  • There's obviously, you know, some details we're still working on.

    まだ詳細については検討中だ。

  • But the idea here is there will be, if we make money, it's from services.

    しかし、ここでの考え方は、もし私たちがお金を稼ぐとすれば、それはサービスによるものだということだ。

  • It's not going to be from the open source stuff that we built directly.

    私たちが直接構築したオープンソースのものではありません。

  • And the open source toolchain obviously serves as the funnel and the mode for the services that we built. And that's the ideal outcome.

    そして、オープンソースのツールチェーンは明らかに、私たちが構築したサービスのためのファネルやモードとして機能する。それが理想的な結果だ。

  • I think that makes a lot of sense.

    それはとても理にかなっていると思う。

  • There is this like real thing of like big companies using open source tooling.

    大企業がオープンソースのツールを使っているという現実のようなものがある。

  • It usually doesn't scale super well.

    通常、規模はそれほど大きくない。

  • And if you've worked in a semi-large company and you've used Webpack, for example, and you know, like, oh, we have like a five to ten minute Webpack build.

    もしあなたが準大手企業で働いていて、例えばWebpackを使っていて、5分から10分のWebpackビルドがある。

  • Well, like most people don't experience that because their apps are too small.

    まあ、アプリが小さすぎるから、ほとんどの人が経験しないようにね。

  • But like if you're a really large organization and you're doing, you're bundling a lot of code and you're like running a lot of transforms and doing a lot of custom stuff, you start hitting in those things.

    しかし、もしあなたが本当に大きな組織で、たくさんのコードを束ねていて、たくさんのトランスフォームを実行したり、たくさんのカスタムなことをやっているような場合、そのようなことにぶつかり始めるでしょう。

  • So I think it makes sense to a large degree to say, hey, you've just got more needs and we have tools to sort of solve those needs, whereas, you know, 80 percent of people won't ever hit that scaling point.

    80%の人はスケーリングポイントに到達することはないだろう。

  • Totally.

    まったくだ。

  • Yeah.

    そうだね。

  • What a part of the part of the reasons we believe there is a market for this is because half the team is have worked at ByteDance on their Web Infra team, and they support some of the largest scale JavaScript applications that we have ever heard of in the industry.

    私たちがこれの市場があると考える理由のひとつは、チームの半数がByteDance社のWeb Infraチームで働いた経験があり、業界で聞いたことのないような大規模なJavaScriptアプリケーションをサポートしているからです。

  • And, you know, some code bases with a hundred hundred thousand lines of JavaScript code and takes half an hour to to build.

    そして、JavaScriptのコードが10万行あり、ビルドに30分かかるコードベースもある。

  • So scale that not every developer would have to ever deal with.

    そのため、すべての開発者が対処する必要のない規模だ。

  • And but, you know, that's that's why a lot of the tools that we are building, like the starting from the OXC parser is like we are obsessed with the highest level of performance so that these tool can still handle the scale.

    OXCパーサーを始めとして、私たちが開発しているツールの多くは、スケールに対応できるように最高レベルのパフォーマンスにこだわっています。

  • The biggest scale application you can throw at it should be able to still do it with decent development experience.

    あなたが投げられる最大のスケールのアプリケーションは、まともな開発経験があればまだできるはずだ。

  • So speaking of the OXC parser, I kind of find it funny that it seems like that project in itself started in the same way where like you were just creating a thing to for a side project.

    OXCパーサーについて言えば、あのプロジェクト自体が、あなたがサイドプロジェクトのために何かを作っていたのと同じように始まったように思えるのが、ちょっと面白いですね。

  • And I think Ocean, the guy behind OXC, was just kind of creating a reference implementation of a parser in Rust.

    OXCの開発者であるオーシャンは、Rustでパーサーのリファレンス実装を作っただけだと思う。

  • So how do we get from there to this is now like that one little Lego block at the bottom of the big structure that is void zero?

    では、ボイド・ゼロという大きな構造物の底にある小さなレゴブロックのようなものから、どうやってこれを得るのか?

  • Yeah, I think a lot of it is me when we when I was thinking about, OK, we need to we need to write our own bundler for Vite.

    ええ、その多くは、私たちがViteのために独自のバンドラーを書く必要があると考えたときのことだと思います。

  • And what do we base the bundler on top of?

    バンドラーは何をベースにしているのか?

  • And we looked at so there are multiple ways of thinking about this, right?

    そして、このことについて複数の考え方があることを確認したんだ。

  • So rewriting JavaScript, no, because it's going to be too slow.

    JavaScriptを書き換えるのは、遅すぎるからダメだ。

  • So we want to do it in a comparative native language.

    だから比較母国語でやりたい。

  • And we looked at Go, there's already ESBuild, which is a great project.

    Goも検討したし、ESBuildもすでにある。

  • I think the downside of ESBuild is in order to achieve the maximum performance, ESBuild is architected in a way where many different concerns are layered across as few AST passes as possible.

    ESBuildの欠点は、最大のパフォーマンスを達成するために、ESBuildはできるだけ少ないASTパスで多くの異なる関心事を重ねるように設計されていることだと思う。

  • So it's like it's minification logic is actually spread across multiple passes.

    つまり、ミニ化のロジックが複数のパスにまたがっているようなものだ。

  • And it's not like minification is minification.

    ミニフィケーションはミニフィケーションではないしね。

  • It's like in the same AST pass, you would see some branches dealing with minification, some branches dealing with transforms.

    同じASTパスでも、ミニフィケーションを扱うブランチもあれば、トランスフォームを扱うブランチもある。

  • And that making external contribute making like basically extending ESBuild in a reasonable way quite difficult, because you're going to be adding more branches in these AST passes.

    そして、基本的にESBuildを合理的な方法で拡張するような外部貢献をすることはかなり難しい。なぜなら、これらのASTパスでより多くのブランチを追加することになるからだ。

  • And it's going to be very difficult for for us to manage it.

    そして、それを管理するのは非常に難しいだろう。

  • Like Evan Wallace is obviously brilliant, and he has everything in his brain, and he can sort of improve ESBuild with this architecture, because that's his intentional decision.

    エヴァン・ウォレスは明らかに優秀で、彼の頭脳にはすべてが備わっている。そして、このアーキテクチャでESBuildを改良することができる。

  • But we just feel like it's not a good foundation for us to if we want to ever extend on top of it.

    ただ、その上にさらに上を目指すとなると、私たちにとっては良い土台にはならないと感じているんだ。

  • And also, we do want to make each part sort of well isolated so that people can use it as individual dependencies instead of having to opt into the whole thing at once.

    また、各パーツをうまく分離することで、一度に全部を選択するのではなく、個々の依存関係として利用できるようにしたい。

  • So then we turn to Rust.

    そこでラストに目を向ける。

  • And so Fortune actually also contributed to RSPack at Bidens.

    そしてフォーチュンは、実はビデンスのRSPackにも貢献していた。

  • And there are some technical decisions in RSPack that made it essentially too late for them to switch to RxE, because it's already kind of built on top of SFC for a very long time before RxE was even usable.

    RSPackには、RxEに切り替えるには遅すぎた技術的な決定がいくつかある。RxEが使えるようになるずっと前から、すでにSFCの上に構築されていたようなものだからだ。

  • But I have been keeping an eye on RxE for a very long time.

    しかし、私は非常に長い間RxEを見守ってきた。

  • And I think it is important that for the new toolchain to be based on something that kind of learns from a lot of the things that we've done in the past.

    そして、新しいツールチェーンは、我々が過去に行ってきた多くのことから学ぶようなものをベースにすることが重要だと思う。

  • Because when Boxu worked on RxE, he had contributed to Roam slash Vilem in the past as well.

    というのも、箱秀がRxEに携わっていたとき、彼は過去にローム・スラッシュ・ヴァイレムにも貢献していたからだ。

  • They had to contribute to sRubyC and deal with sRubyC during RSPack development as well.

    彼らはsRubyCに貢献し、RSPackの開発中もsRubyCに対応しなければならなかった。

  • So the team at WebInfra has a lot of experience dealing with, you know, Rust language toolchains and systems.

    だからWebInfraのチームは、Rust言語のツールチェーンやシステムを扱った経験が豊富なんだ。

  • And I think he distilled a lot of the learnings into the development of RxE initially as a proof of concept.

    そして、彼は多くの学びをRxEの開発に集約し、当初は概念実証として開発したのだと思う。

  • And when it became a bit more production ready, it showed that, okay, all these things did pay off, like both sRubyC and RxE are written in Rust, but there is a pretty significant performance advantage that RxE has.

    sRubyCもRxEもRustで書かれているが、RxEにはかなり大きなパフォーマンス上の利点がある。

  • And there are some other design decisions that's a bit more detailed.

    他にも、もう少し細かい設計上の決定事項がある。

  • For example, when using this language toolchain to support the bundler, there are a lot of semantic analysis that we have to do, for example, like determining whether this variable is referenced in this current scope, or is it, you know, shadowing the outer variable, or is it used and exported by and used in another module?

    例えば、バンドラーをサポートするためにこの言語ツールチェーンを使用する場合、この変数が現在のスコープで参照されているのか、それとも外側の変数をシャドーイングしているのか、あるいは別のモジュールで使用され、エクスポートされているのか、など、多くの意味解析をしなければならない。

  • A lot of these kind of things, you have to do the analyzation, right?

    こういったことの多くは、分析が必要なんだ。

  • So in JavaScript, most of the parsers just, like, stops at giving you the AST, and they're done.

    だからJavaScriptでは、ほとんどのパーサーはASTを渡すだけで終わってしまう。

  • So when we are dealing with, say, I think Babel probably provides a bit more infrastructure for that.

    バベルはそのためのインフラをもう少し提供してくれるだろう。

  • But in my own work, for example, in the Vue compiler, we have to do a lot of these semantics analysis ourselves.

    しかし、私自身の仕事、例えばVueコンパイラーでは、これらのセマンティクス分析の多くを自分たちでやらなければならない。

  • I think in Excel, Rich Harris has also written quite a few tools around this.

    エクセルでは、リッチ・ハリスもこのあたりのツールをかなり書いていると思う。

  • But I believe that should be a first-party concern of a language toolchain.

    しかし私は、それは言語ツールチェーンが第一に考えるべきことだと考えている。

  • So RxE actually comes with a semantic analysis API that allows you to query this information after the parsing is done, because as you parse, it also collects and stores this information already.

    つまり、RxEにはセマンティック解析APIが付属しており、解析が完了した後で、この情報を照会することができる。

  • So you don't have to do the traversal yourself to figure out this information.

    だから、この情報を把握するために自分でトラバーサルをする必要はない。

  • You can just ask, right?

    聞けばいいんでしょ?

  • So this is also slightly different from, say, you know, the way SWAC works.

    だからこれは、例えばSWACのやり方とも少し違う。

  • In a way, like, I don't want to bash SWAC, because it is the first JavaScript Rust toolchain, right?

    ある意味、SWACはJavaScript初のRustツールチェーンだから、SWACをバッシングしたくないんだ。

  • And I think it serves its purpose really, really well.

    そして、その目的は十分に果たされていると思う。

  • A lot of people are still using it.

    多くの人がまだ使っている。

  • It's great.

    素晴らしいよ。

  • But I think there are things we can learn from it.

    でも、そこから学べることもあると思う。

  • Learn from the past efforts.

    過去の取り組みから学ぶ。

  • And we believe RxE is just a better foundation if we want to build more ambitious features on top of it.

    そして、その上にさらに野心的な機能を構築するのであれば、RxEはより良い基盤になると信じている。

  • So yeah, so Rodown essentially started out with RxE as the base.

    そうそう、ロダウンは基本的にRxEをベースにしてスタートしたんだ。

  • And so far, we are happy that the performance is turning out to be, you know, living up to our expectations.

    そして今のところ、期待に応えるパフォーマンスになっていることに満足している。

  • Something I've always admired about your approach to projects is that very iterative style.

    あなたのプロジェクトに対するアプローチでいつも感心するのは、非常に反復的なスタイルです。

  • So I remember when I first discovered Vue, you were just making the transition from Vue 1 to Vue 2, introducing virtual DOM, learning a lot of lessons from React.

    私が初めてVueを知ったとき、ちょうどVue 1からVue 2への移行を進めていて、仮想DOMを導入し、Reactから多くのことを学んでいたのを覚えています。

  • And that always struck me, and I feel like you've sort of had a pattern doing that over the years.

    私はそのことにいつも驚かされるし、あなたには長年にわたってそのようなパターンがあるように感じる。

  • So I'm curious to tie into the sort of incremental approach that you're taking now.

    だから、あなたが今取っている漸進的なアプローチと結びつけて考えてみたいんだ。

  • What have you learned from projects like Biome and Roam, for example, who have tried to tackle somewhat similar problems, but maybe from a different angle?

    例えば、『Biome』や『Roam』のようなプロジェクトからは何を学びましたか?

  • And SWC probably is in the same category.

    SWCもおそらく同じカテゴリーだろう。

  • They're trying to tackle some performance problems.

    彼らはパフォーマンスの問題に取り組もうとしている。

  • What are the big lessons and takeaways and things that you're trying to do differently than those projects might have tackled?

    大きな教訓や収穫、それらのプロジェクトが取り組んだであろうこととは違うことをやろうとしていることは何ですか?

  • I think in terms of the end vision, it's very obvious that Void Zero has a lot of similarity to what Roam wanted to do.

    最終的なビジョンという点では、『ヴォイド・ゼロ』が『ローム』がやりたかったことと似ているのは明らかだと思う。

  • I think there are two major differences.

    大きな違いは2つあると思う。

  • First is, we decided to work on the toolchain for Void Zero, mostly because we already have

    まず、我々はヴォイド・ゼロのツールチェーンに取り組むことにした。

  • Vite serving as sort of a point of convergence.

    ヴァイテはある種の収束点として機能している。

  • If we don't have Vite as the leverage, then the chance of success will be much slimmer.

    ヴァイテをテコにしなければ、成功の可能性はかなり低くなる。

  • And Roam really didn't have anything like that.

    ロームにはそういうものがなかった。

  • They started out with something that's completely from scratch.

    彼らは完全にゼロから始めたんだ。

  • So for Roam, I think the biggest challenge is just going from zero to one.

    だからロームにとって最大の挑戦は、ゼロからイチになることだと思う。

  • How do you make people adopt it?

    どうやって人々にそれを採用させるのか?

  • They started out with a formatter, which kind of makes sense because formatter is probably the least intrusive piece of task in the overall development flow.

    彼らはまずフォーマッターから始めたが、これはある意味理にかなっている。なぜなら、フォーマッターはおそらく開発フロー全体の中で最も邪魔にならないタスクだからだ。

  • In a way, it's completely coupled from everything else.

    ある意味、他のすべてから完全に切り離されている。

  • That makes it easier for people to switch to and adopt.

    そのため、人々が乗り換え、採用しやすくなる。

  • The downside of that is it's also not a strong leverage to have, because it's not really related to the rest of the tasks people are doing.

    その欠点は、人々が行っている他の仕事とはあまり関係がないため、強力なレバレッジにはならないということだ。

  • I think the angle where you get the adoption from, this is more like a strategic difference,

    これは戦略的な違いに近いと思う、

  • I think.

    私はそう思う。

  • Another more technical difference is, I think Roam's implementation or Biome's Rust codebase was initially designed to be more intended for an IDE use case scenario.

    もう一つの技術的な違いは、Roamの実装やBiomeのRustコードベースは、当初はIDEのユースケースを想定して設計されていたと思います。

  • They focused a lot on the IDE story.

    彼らはIDEのストーリーにかなり重点を置いていた。

  • So they essentially built something, they used something called CST, Concrete Syntax

    そこで、彼らは基本的にCST(Concrete Syntax)と呼ばれるものを使った。

  • Tree, because they want to preserve the shape of the original code as much as possible, and they want to be resumable and more error resilient.

    ツリーは、元のコードの形状をできるだけ維持し、リジューム可能で、よりエラーに強いものにしたいからだ。

  • A lot of these are great for IDE use cases, but not necessarily best if you want to do the other tasks, for example, get the fastest possible transforms, and also basically be able to use the AST for multiple tasks along a long pipeline.

    これらの多くは、IDEの使用例には最適だが、他のタスク、例えば、可能な限り最速の変換を行いたい場合や、基本的に長いパイプラインに沿って複数のタスクにASTを使用できるようにしたい場合には、必ずしも最適ではない。

  • So when we, I think Boschian could probably share more insights on this front, but I think the difference between the AST and CST was also a major reason where Boschian was like, we don't really want to do that in OXC.

    ASTとCSTの違いは、ボスキアンがOXCではあまりやりたくないと言った大きな理由でもあると思う。

  • But I think it's unfortunate that Roam didn't get to actually keep going beyond what it is now.

    しかし、ロームが今以上に前進し続けることができなかったのは残念なことだと思う。

  • But I think it still showed people that it's possible to write high quality tooling for

    しかし、それでもなお、次のような高品質のツールを書くことが可能であることを人々に示したと思う。

  • JavaScript in Rust, because a lot of people are happy with Biome as a flowmatter nowadays.

    JavaScriptをRustで。最近は多くの人がBiomeのフローマターに満足しているからね。

  • And it's also part of the reason why we're not in a hurry to work on flowmatter, because it already kind of fills that gap.

    フローマターがすでにそのギャップを埋めているようなものだからだ。

  • We will probably eventually have an OXC based flowmatter just for complete sake, but for us, that's just going to be down the road.

    いずれはOXCベースのフローマターも作るだろうが、それはまだ先の話だ。

  • Your first point reminds me of the saying, make it work, make it right, or make it, yeah, make it work, make it right, make it fast.

    あなたの最初の指摘は、"make it work, make it right"、あるいは "make it, yeah, make it work, make it right, make it fast "ということわざを思い出させる。

  • Like you made it work, Vite, we already have like the grand vision and just all of this work now is like truly like making it right and being able to like make sure the pipes make it fast.

    私たちはすでに壮大なビジョンのようなものを持っていて、今、この作業をすべて、本当に正しいものにし、パイプが早く完成するようにすることなんだ。

  • Yeah.

    そうだね。

  • Yeah.

    そうだね。

  • In a lot of ways.

    いろんな意味で。

  • Yeah.

    そうだね。

  • I think the first stage of Vite really was like, let's just make things work and make it better than the status quo.

    ヴァイテの最初の段階は、とにかく物事をうまくやり遂げよう、現状より良くしようという感じだったと思う。

  • But underneath, there might be a lot of, you know, hacks and things we want to improve in the future.

    でもその下には、ハックや将来的に改善したいことがたくさんあるかもしれない。

  • And now it's the proper time to do it.

    そして今、それを実行する適切な時なのだ。

  • So I've developed a little bit of a few Vite plugins as I've gone along.

    だから、Viteのプラグインを少しずつ開発してきたんだ。

  • I've done a lot of static site generation and I've rebuilt Storybook a few different times.

    私は静的なサイト生成をたくさんしてきたし、Storybookも何度か作り直した。

  • And most of those things usually come down to like, I need to make a very intense plugin for the system.

    そして、そのようなことのほとんどは、システムのために非常に強力なプラグインを作る必要がある、というようなことに行き着く。

  • And the one thing that kind of trips me up a lot of the time is the plugin API for Vite is the same as Rollup, but it only has like a select few hooks.

    ViteのプラグインAPIはRollupと同じなのだが、いくつかのフックしかない。

  • And I feel like those hooks are probably excluded because like we have like speed concerns in the mix.

    そして、そのようなフックはおそらく除外されるような気がするんだ。

  • With the advent of like Rolldown, will we see the plugin API start to like open up a little bit?

    RolldownのようなプラグインAPIが登場したことで、プラグインAPIも少しずつオープンになっていくのでしょうか?

  • Will the speed unlock more power that we can give to plugin devs?

    スピードが上がれば、プラグイン開発者により多くのパワーを与えることができるようになるのだろうか?

  • I'm curious, what are the hooks you were looking for, but doesn't work indeed?

    興味津々なのですが、あなたが探していて、実際に機能しなかったフックは何ですか?

  • There's just like a handful, like four or five of them that like I've always want to use, but they just don't run in dev mode because they're not there.

    ほんの一握り、4つか5つ、いつも使いたいと思っているようなものがあるんだけど、開発モードでは動かないんだ。

  • So yeah, just wondering, will the new power expand to more stuff for us to do?

    そうそう、ちょっと気になったんだけど、新しいパワーは、僕らができることをもっと広げてくれるのかな?

  • So this is an interesting one because, so first of all, with Rolldown and in a future version of Vite, dev and prod will become more consistent.

    というのも、まず第一に、ロールダウンとヴァイトの将来のバージョンでは、デベロッパーとプロダクションがより一貫したものになるからだ。

  • They will be using the same plugin pipeline and so the plugins will work exactly the same between dev and prod.

    彼らは同じプラグイン・パイプラインを使用するので、プラグインは開発チームとプロダクションチームでまったく同じように機能する。

  • But the interesting part about having JavaScript plugins running in a Rust-based tool is there is the overhead of sending data back and forth between the two languages because they don't share memory by default.

    しかし、JavaScriptのプラグインをRustベースのツールで実行する際に興味深いのは、デフォルトではメモリを共有しないため、2つの言語間でデータをやり取りするオーバーヘッドが発生することだ。

  • So in most cases, when you send things across the wire, you have to clone them in memory.

    そのため、ほとんどの場合、電線を伝ってものを送るときは、メモリ上にクローンを作らなければならない。

  • And that's probably one of the biggest bottlenecks for speed.

    それがスピードの最大のボトルネックのひとつだろう。

  • So let's say if you use raw Rolldown without any JavaScript plugins to bundle 20,000 modules, you can do it in 600 milliseconds.

    つまり、JavaScriptプラグインを使わずに生のRolldownを使って20,000のモジュールをバンドルする場合、600ミリ秒でできることになる。

  • But if you add a couple of JavaScript plugins, you can slow it down by maybe two to three times.

    しかし、JavaScriptプラグインをいくつか追加すれば、2〜3倍遅くすることができる。

  • And this is directly correlated to the number of modules because we have to, for every hook of every plugin, you have to call it once for every module.

    なぜなら、プラグインのフックごとに、モジュールごとに1回呼び出さなければならないからだ。

  • So let's say you have a plugin with three hooks, then we're doing 60,000 Rust to JS calls.

    例えば、3つのフックを持つプラグインがあるとしよう。

  • And that's not cheap.

    そしてそれは決して安くはない。

  • Even if you don't do anything in a hook, it's still quite a bit of a cost.

    フックで何もしなくても、かなりの出費になる。

  • So we're looking for ways to optimize that.

    だから、それを最適化する方法を探しているんだ。

  • So first of all, base layer compatibility is we want all the existing Vite plugins to be able to continue to work the same way.

    まず、ベースレイヤーの互換性ですが、既存のすべてのヴァイト・プラグインが同じように機能することを望んでいます。

  • It might compromise the ideal performance to a certain extent, but let's make things work first.

    理想的なパフォーマンスはある程度損なわれるかもしれないが、まずはうまくやろう。

  • And then the next step is for Vite itself internally, we've actually already ported some of the Vite internal logic over to Rust.

    そして次のステップは、Vite自体の内部的なもので、実はすでにViteの内部ロジックの一部をRustに移植しています。

  • So right now it's only for builds.

    だから今はビルド用だけだ。

  • So when you do the production build, you can enable the native equivalent of some Vite internal plugins.

    そのため、本番ビルドを行う際に、いくつかのVite内部プラグインのネイティブ版を有効にすることができる。

  • So that allows us to essentially get Vite build speed down to maybe two to 2.2 and a half times slower than raw Rodan without any JavaScript plugins, which I think is actually decent.

    その結果、Viteのビルド速度は、JavaScriptプラグインを使用しない生のRodanの2倍から2.2倍半に短縮された。

  • And in fact, that's already kind of on par with other pure Rust sponsors.

    そして実際、それはすでに他の純粋なラストスポンサーと肩を並べるようなものだ。

  • And then we are doing a few things to essentially, there are two different ways you can think about this.

    そして、私たちは本質的にいくつかのことを行っている。これには2つの異なる考え方がある。

  • One is reduce unnecessary Rust to JS calls.

    ひとつは、不必要なRust to JSの呼び出しを減らすことだ。

  • So in typical Rust rollup plugins, we do a lot of things like in the transformer hook, we look at the ID.

    典型的なRustのロールアップ・プラグインでは、トランスフォーマー・フックでIDを見るなど、さまざまなことを行う。

  • If the ID ends with a certain extension, we do this, otherwise we just return early.

    IDが特定の拡張子で終わっていればそうするが、そうでなければ早めにリターンする。

  • This is actually wasteful if you're using the plugin in a Rust bundler, because the bundler essentially does a Rust to JS call, figure out it actually doesn't need to do anything, but it already paid the cost.

    Rustバンドルでプラグインを使用している場合、これは実に無駄なことだ。バンドルは基本的にRustからJSへの呼び出しを行い、実際には何もする必要がないことを理解するが、すでにコストを支払っているからだ。

  • This is why ESBuilds plugin actually requires to have a filter outright before it is ever applied.

    このため、ESBuildsプラグインは、実際にフィルターを適用する前に、フィルターが完全に適用されている必要がある。

  • And we're going to essentially introduce something similar.

    そして、我々は本質的に似たようなものを導入するつもりだ。

  • So it's going to be an extension on top of the current rollup syntax.

    つまり、現在のロールアップ構文の上に拡張されることになる。

  • It's going to be compatible because when you use the object format for your hooks, so you specify a logic in the handler property, and then you can have a filter property to say, only apply this hook if the ID matches this regex or something like that.

    フックにオブジェクト・フォーマットを使用する場合、ハンドラー・プロパティでロジックを指定し、フィルター・プロパティで、IDがこの正規表現にマッチした場合のみ、このフックを適用するといったことができるからです。

  • So we can essentially determine whether this hook even needs to be called for a certain module before we even call it.

    つまり、フックを呼び出す前に、あるモジュールに対してこのフックを呼び出す必要があるかどうかを判断することができるのだ。

  • So we don't even need to cross the Rust to JS bridge.

    だから、ラスト・トゥ・JSの橋を渡る必要もない。

  • That's one thing.

    それも一つだ。

  • The other thing is we're seeing a lot of plugins in the wild doing very similar things.

    もうひとつは、似たようなことをやっているプラグインがたくさんあることだ。

  • For example, in the transform hook, a lot of plugins take the incoming source code, parse it using a JavaScript parser in the hook, and then do their own semantic analysis or AST traversal, and then use something like magic string to alter the code and generate a new code and also need to generate the source map and then pass it back to the bundler.

    例えば、transformフックでは、多くのプラグインが入力されたソースコードを受け取り、フック内でJavaScriptパーサーを使って解析し、独自のセマンティック解析やASTトラバーサルを行い、マジックストリングのようなものを使ってコードを変更して新しいコードを生成し、さらにソースマップを生成してバンドラーに渡す必要がある。

  • So a lot of work done in JavaScript, not leveraging the Rust parts.

    そのため、多くの作業はJavaScriptで行われ、Rustの部分は活用されていない。

  • And then also the Rust needs to now need to take the source map and do the source imagine.

    そして、ラストはソース・マップを受け取って、ソースを想像する必要がある。

  • And source maps are also quite heavy to pass across the boundary because it's bigger objects than source code.

    また、ソースマップはソースコードよりも大きなオブジェクトであるため、境界を越えるにはかなり重い。

  • So we're trying to design APIs to essentially make this kind of standard AST-based simple transforms to be as efficient as possible.

    そこで私たちは、このような標準的なASTに基づく単純な変換を可能な限り効率的に行うためのAPIを設計しようとしている。

  • So imagine instead of getting the string of the code, you actually get the pre-parsed

    つまり、コードの文字列を取得する代わりに、事前にパースされた

  • AST directly.

    ASTが直接。

  • And instead of manipulating the code and generating the source map in the JS side, you still do the same kind of magic string-like operations, say like append some code here, remove the code here.

    そして、JS側でコードを操作してソース・マップを生成する代わりに、同じような魔法の文字列のような操作を行う。

  • But these operations are kind of buffered and send as very compact instructions back to Rust.

    しかし、これらの操作はバッファリングされ、非常にコンパクトな命令としてRustに送り返される。

  • And the heavy lifting of code manipulation, string manipulation, and source map generation is actually done by Rust on the Rust side.

    そして、コード操作、文字列操作、ソース・マップ生成などの重労働は、実際にはRust側でRustが行う。

  • So the only work you're doing on the JS side really is looking at the AST and record the operations you want to do, and then tell the Rust side to do it.

    つまり、JS側で行っている作業は、ASTを見てやりたい処理を記録し、それをRust側に指示することだけだ。

  • So I think this, in fact, can cover a very wide range of custom transform needs.

    だから、これは実際、非常に幅広いカスタム・トランスフォームのニーズに対応できると思う。

  • Because we're actually able to build views, single file component transform entirely using this model in JavaScript.

    というのも、実際にJavaScriptでこのモデルを使って、ビューや単一ファイルのコンポーネント変換をすべて構築することができるからだ。

  • And if we get this API natively from the bundler, then we can actually offload a lot of the heavy lifting to the Rust toolchain instead of doing it in JavaScript.

    そして、このAPIをバンドラーからネイティブで取得すれば、JavaScriptで行う代わりに、Rustツールチェーンに多くの重労働を任せることができる。

  • I don't even need to install a parser dependency myself.

    パーサーの依存関係を自分でインストールする必要もない。

  • So this is the second part of it.

    これがその第2部だ。

  • And then if we go a bit deeper, this is further down the line, we're also investigating whether it's possible to send ASTs from Rust to JavaScript as little memory cost as possible.

    そして、もう少し深く掘り下げると、これはさらに先の話になりますが、RustからJavaScriptにASTを送信する際に、できるだけメモリコストを少なくできないかどうかも調査しています。

  • So this is something called like zero cost AST transfer.

    つまり、これはゼロコストAST移籍と呼ばれるものだ。

  • Theoretically, it's already possible using a shared array buffer.

    理論的には、共有配列バッファを使えばすでに可能だ。

  • And then we need a custom deserializer on the JavaScript side that understands the memory layout and be able to lazily read the AST from the flat array buffer as you need.

    そして、JavaScript側には、メモリレイアウトを理解し、必要に応じてフラット配列バッファからASTを読み出すことができるカスタムデシリアライザが必要だ。

  • One of our team members, Overlook Motel, actually has a proof of concept of this working already.

    私たちのチームメンバーの一人であるオーバールック・モーテルは、すでにこのコンセプトの実証実験を行っている。

  • But getting this properly into XE is going to be quite challenging.

    しかし、これをXEにきちんと取り込むのはかなり難しいだろう。

  • So this is something we're eventually going to do down the road.

    だから、この先いずれはそうするつもりだ。

  • But the proof of concept shows that this is possible, right?

    しかし、概念実証はそれが可能であることを示しているよね?

  • And there are some exciting things in the JavaScript specs.

    そして、JavaScriptの仕様にはエキサイティングなものがある。

  • For example, there's a share struct proposal.

    例えば、株式構造に関する提案がある。

  • That's quite new.

    かなり新しいね。

  • That's still stage one.

    まだ第1段階だ。

  • It also is kind of exciting if you can use share structs to essentially properly share state across virtual threads and maybe Rust.

    また、共有構造体を使って、仮想スレッドやRustの間でステートを適切に共有できれば、ちょっとエキサイティングだ。

  • So what this unlocks is proper parallelization of JavaScript plugins.

    つまり、JavaScriptプラグインの適切な並列化が可能になるのだ。

  • Right now, when you use JavaScript plugins with a Rust bundler, because the JavaScript plugin still runs in Node.js process, it's still single threaded.

    現在、JavaScriptプラグインをRustバンドルで使用する場合、JavaScriptプラグインは依然としてNode.jsプロセスで実行されるため、シングルスレッドです。

  • One thing we've done is trying to use multiple worker threads to parallelize the workload.

    ひとつは、複数のワーカースレッドを使ってワークロードを並列化する試みだ。

  • But the downside of this is, for example, if the plugin uses a heavy dependency like

    しかし、この欠点は、例えば、プラグインが次のような重い依存関係を使用している場合です。

  • Babel, each worker thread needs to initialize with Babel and allocate the memory for it.

    Babelの場合、各ワーカー・スレッドはBabelで初期化し、そのためのメモリを確保する必要がある。

  • And in a lot of cases, the gain is smaller than you might think.

    そして多くの場合、その利益は思っているよりも小さい。

  • Because the initializing cost of each worker thread just offsets so much of the performance gains you get.

    なぜなら、ワーカースレッドごとの初期化コストが、得られるパフォーマンス向上の多くを相殺するだけだからだ。

  • It's challenging.

    挑戦的だ。

  • There are some things we played around with.

    いくつか遊んでみたことがある。

  • For example, instead of spawning the worker threads through a Node.js main process and then get the data back and send it back to Rust, we let the worker threads directly send the data back to Rust.

    例えば、Node.jsのメインプロセスを通してワーカースレッドを生成し、データを取得してRustに送り返す代わりに、ワーカースレッドに直接データをRustに送り返させる。

  • I think some of this might be useful, but applying them blindly for every plugin may not end up being as beneficial as we think.

    しかし、すべてのプラグインにやみくもに適用しても、結局は私たちが考えているほど有益ではないかもしれない。

  • So there's still a lot of work that we're exploring in this area.

    だから、この分野ではまだ探求していることがたくさんある。

  • But I'm kind of optimistic that for a long-term goal for us is to tackle this, still allow users to easily write JavaScript plugins, but without severely compromising the overall performance of the system.

    しかし、私たちの長期的な目標は、この問題に取り組み、ユーザーがJavaScriptプラグインを簡単に書けるようにしつつ、システム全体のパフォーマンスを大きく損なわないようにすることだと、私は楽観視している。

  • Yeah, I do think that this is one of the hardest areas for all the reasons you've outlined.

    ああ、君が説明したような理由から、この分野は最も難しい分野のひとつだと思う。

  • And the temptation is real to just say, sorry, no more plugins in JavaScript.

    そして、JavaScriptのプラグインはもういらない、と言いたい誘惑に駆られる。

  • It's also, you know, there's a big ecosystem churn cost there, which is a pretty big downside.

    また、エコシステムには大きな解約コストがあり、これはかなり大きなマイナス面だ。

  • Yeah, I kind of want to mention there's also, we do want to start with getting the plugins work, right?

    プラグインを使えるようにすることから始めたいんだ。

  • Then we start having a recommended subset or a recommended best practice for writing performant JavaScript plugins for Rust.

    そして、Rust用のパフォーマンス高いJavaScriptプラグインを書くための推奨サブセットや推奨ベストプラクティスを持つようになる。

  • So maybe we'll have linked rules to help guide you writing these plugins, or we can have runtime warnings.

    そのため、プラグインを書く際のガイドとなるようなリンクされたルールを設けたり、実行時の警告を出したりすることもできるだろう。

  • Like, one thing we actually did is we use OXC to implement a small tool that can look at your plugin source code and, you know, look at, for example, look at your transform hook and notice that you're doing something like if id.test.regex.return, right?

    例えば、プラグインのソースコードを見て、例えばtransformフックを見て、if id.test.regex.returnのようなことをしていることに気づくような小さなツールをOXCを使って実装しました。

  • So this is a sign of early return, it shows that this transform hook is actually eligible for filter optimization.

    つまり、これは早期復帰の兆候であり、このトランスフォーム・フックが実際にフィルター最適化の対象であることを示している。

  • So detect such cases and actually give you a soft recommendation, say like this plugin hook can be refactored to use the filter API to make it more performant.

    そのようなケースを検出し、例えば、このプラグインフックをフィルターAPIを使うようにリファクタリングすることで、よりパフォーマンスが向上するような、ソフトな推奨を行うことができる。

  • So it kind of sounds like there's going to be kind of a divide here at some point where there's like, there's a bunch of legacy rollup plugins that still work in the new architecture.

    つまり、新しいアーキテクチャーでも機能するレガシーなロールアップ・プラグインがたくさんあるということだ。

  • But then as we go on, kind of like a recommended V2 of all of those that use these new APIs to make things really fast.

    しかし、さらに進むと、これらの新しいAPIを使い、物事を本当に速くするための推奨V2のようなものが出てくる。

  • Yeah, and in a lot of ways, we do also want to make most of the common things you need to do built in.

    ええ、そして多くの点で、私たちはあなたが必要とする一般的なことのほとんどを作り込みたいと考えています。

  • For example, if you use rollup, rolldown today, you don't need common JS plugin because it just works out of the box.

    例えば、今日ロールアップやロールダウンを使用している場合、一般的なJSプラグインは必要ありません。

  • You don't need the node resolve plugin because it just works out of the box.

    ノード解決プラグインは必要ありません。

  • You don't need TypeScript transforms, you don't need JSX transforms.

    TypeScriptトランスフォームは必要ないし、JSXトランスフォームも必要ない。

  • All of these things just work without plugins.

    これらはすべて、プラグインなしで動作する。

  • So in a lot of ways, it's similar to rollup's abstraction level is a bit, rolldown's abstraction model is a bit more like ES build slash leaps, right?

    つまり、ロールアップの抽象化レベルは少し似ていて、ロールダウンの抽象化モデルはESビルド・スラッシュリープに少し似ているということですね?

  • It's a bit more battery included because that's also the most pragmatic way to get the best possible performance.

    可能な限り最高のパフォーマンスを得るための最も現実的な方法でもあるからだ。

  • Yeah, it makes a lot of sense.

    ああ、とても理にかなっている。

  • I'm really interested to see what y'all end up coming up with, with the AST transforms, because I feel like this is a pretty common problem is like, if you need to do very performant

    というのも、これはかなり一般的な問題のような気がするからだ。

  • AST transforms, I mean, you have the added problem of like going across language boundaries.

    AST変換は、つまり、言語の境界を越えるという問題が加わるんだ。

  • This just reminds me of a random project that I saw the other day called like render from this guy named Eric Mann.

    これは、先日見たエリック・マンという男のレンダーというランダムなプロジェクトを思い出させる。

  • And it's like, it's a byte code that runs in JavaScript that like is a rendering engine or whatever.

    JavaScriptで実行されるバイトコードで、レンダリングエンジンか何かのようなものだ。

  • And it's just like, I don't know, there's like a lot of interesting things in the space when you start thinking about like, how can we make like marshalling and serialization very, very, very fast.

    どうすればマーシャリングやシリアライゼーションをとてもとても速くできるのか、ということを考え始めると、興味深いことがたくさん出てくる。

  • So this will be really cool.

    だから、これは本当にクールだろう。

  • I'm excited.

    ワクワクしているよ。

  • Well, maybe as we're getting close to wrapping up the episode, let's think about or talk a little bit about what the future looks like.

    さて、このエピソードも終わりに近づいたところで、未来がどのようなものなのか、少し考えてみようか、話してみようか。

  • So you're saying earlier that Vite is already pretty prolific.

    つまり、ヴァイテはすでにかなり多作だということを先に言っているわけだ。

  • So it is your starting point, you have sort of this broad baseline that, you know, say

    つまり、これが出発点であり、ある種の大まかな基準線である。

  • Rome when it was starting was missing.

    ローマが始まろうとしていた頃、ローマは行方不明だった。

  • But there's still a lot of work to do.

    しかし、まだやるべきことはたくさんある。

  • So what do you like think the priorities going into the project will be?

    では、このプロジェクトにおける優先事項は何だと思いますか?

  • And you know, what is your like time horizon that you're sort of anticipating for, you know, say some of your first products when you release, like, what does that look like for you?

    また、最初の製品をリリースするまでの時間的な見通しを教えてください。

  • Yeah.

    そうだね。

  • So this is obviously going to be a quite long process.

    だから、これはかなり長いプロセスになるのは明らかだ。

  • I think right now our priority is getting rolled down to sort of a beta status.

    今、私たちが優先しているのは、ベータ版のような状態までロールダウンすることだと思う。

  • There's a lot of alignment work that we need to do right now, because with the goal of being able to swap out ESBuilder rollup, right, we need to make sure, like, because the sort of the mission of rolldown is to unify the two.

    というのも、ESBuilderのロールアップを入れ替えられるようにするという目標があるからです。

  • So in terms of how they handle, for example, CJS, ESM, Interop, how they handle a lot of the edge cases, they need to be as consistent as possible.

    そのため、例えばCJS、ESM、インターロップ、多くのエッジケースの扱い方に関しては、可能な限り一貫性を持たせる必要がある。

  • And we need to basically enable the test cases of both bundlers, run rolldown against those test cases and try to pass as many of them as possible.

    そして、基本的には両方のバンドラーのテストケースを有効にし、それらのテストケースに対してロールダウンを実行し、できるだけ多くのテストケースをパスするようにする必要がある。

  • And then for the ones that's not passing, we need to analyze them and see each whether this is just an output difference or is it more like a correctness issue, right?

    そして、パスしていないものについては、それぞれを分析して、これが単なる出力の違いなのか、それとも正しさの問題なのかを確認する必要がありますね?

  • So we kind of have to label them one by one.

    だから、ひとつひとつラベルを貼っていくしかない。

  • And if there are inconsistencies between the two, we need to make a call on which one do we go with.

    そして、この2つの間に矛盾がある場合、どちらを取るか判断する必要がある。

  • So this is just a lot of grunt work, but it's necessary before we can consider it, you know, production ready.

    だから、これは大変な作業なんだ。でも、生産準備が整ったと考える前に必要なことなんだ。

  • Once that is completed, I think rolldown.

    それが終われば、ロールドダウンだと思う。

  • In parallel, OXC is also trying to finish the syntax down leveling transforms.

    それと並行して、OXCはシンタックスのダウンレベリング変換も終えようとしている。

  • Like some of the hardest ones are like the async generators and stuff like that.

    一番難しいのは、非同期ジェネレーターとか、そういうものだね。

  • But it's well underway.

    しかし、それは順調に進んでいる。

  • So I think by end of this year, we're hoping to get rolldown to beta status and have the transforms also more or less completed.

    だから、今年の終わりまでにはロールダウンをベータ・ステータスにし、トランスフォームもほぼ完成させたいと思っている。

  • So that's a good milestone to hit.

    だから、これはいいマイルストーンだ。

  • So that also primes the entire toolchain for general testing into Vite itself.

    その結果、ツールチェーン全体がヴァイトへの一般的なテストのための素地となる。

  • So rolldown-based Vite already has a working progress branch where we pass over 90% of the tests.

    そのため、ロールダウンベースのヴァイトには、すでに90%以上のテストに合格した進行ブランチがある。

  • Some of the tests that's not passing are actually more or less blocked by tests like legacy mode, which we were kind of like intentionally pumping on because I'm not sure how many people will still be using legacy mode by the time we actually release the thing that's stable.

    レガシー・モードのようなテストに多かれ少なかれ阻まれているものもある。

  • So in a way, rolldown-Vite is somewhat usable.

    だからある意味、ロールダウンバイトはある程度使える。

  • Like we are actually already able to use it to power Vite trust to build the Vite docs.

    ヴァイトのドキュメントを作るために、ヴァイトの信頼性を高めるために、私たちはすでにそれを使うことができる。

  • But we want to wait until rolldown is ready.

    しかし、ロールドダウンの準備が整うまで待ちたい。

  • We have all the transforms ready.

    すべてのトランスフォームを準備している。

  • Then we have an alpha or slash beta release for rolldown-based Vite and have people test it.

    その上で、ロールダウンをベースとしたヴァイトのアルファ版かスラッシュ・ベータ版をリリースし、みんなにテストしてもらう。

  • So this version of rolldown-based Vite is strictly just replacing esbuild and rollup with rolldown.

    つまり、ロールダウンベースのヴァイトのこのバージョンは、厳密に言えば、エスビルドとロールアップをロールダウンに置き換えただけなのだ。

  • So feature equivalence, not really many new things.

    だから、機能的には同等で、新しいことはあまりない。

  • It's mostly like we want to make sure the transition is smooth, frameworks can move over to the new one.

    移行がスムーズで、フレームワークが新しいものに移行できるようにしたいんだ。

  • So that will probably also take some time.

    だから、それも時間がかかるだろう。

  • So in that same process, we do eventually want to move Vite over to a full bundle mode that's entirely powered by rolldown.

    ですから、同じプロセスで、最終的にはヴァイトを完全にバンドル・モードに移行させたいと考えています。

  • As nice as unbundled ESM is for smaller projects, we've run into scaling issues in larger projects.

    バンドルされていないESMは小規模なプロジェクトにはありがたいが、大規模なプロジェクトではスケーリングの問題に直面した。

  • Especially when you have, say, more than 3,000 unbundled modules as a dev server.

    特に、例えば開発サーバーとして3,000以上のバンドルされていないモジュールがある場合。

  • So we believe a fully bundled mode is still necessary.

    だから、完全にバンドルされたモードがまだ必要だと考えている。

  • And it also allows us to get rid of some of the issues, for example, optimized depths.

    また、例えば最適化された深度などの問題を取り除くこともできる。

  • It can be completely eliminated.

    完全に排除できる。

  • So all your dependencies in your source code will go through the exact same transform pipeline for dev and for production.

    そのため、ソースコードに含まれる依存関係はすべて、開発用と本番用でまったく同じ変換パイプラインを通ることになる。

  • So consistency will improve greatly.

    だから、一貫性は大きく向上するだろう。

  • And for the metaframeworks, the one important API for metaframeworks is SSRLoggedModule.

    そして、メタフレームワークにとって重要なAPIはSSRLoggedModuleです。

  • In the new environment API, it's called environment.runModule, something like that.

    新しい環境APIでは、environment.runModuleというような名前になっている。

  • So internally, it's currently still using a JavaScript-based transform.

    だから内部的には、まだJavaScriptベースのトランスフォームを使っている。

  • That will also be replaced by a Rust-based implementation that's exported by rolldown.

    これはまた、rolldownによってエクスポートされるRustベースの実装に置き換えられる。

  • So that you'd use the same bundling mechanism for your code running in the browser and running other environments, for example, Node.js SSR.

    そうすれば、例えばNode.jsのSSRのように、ブラウザで実行するコードと他の環境で実行するコードに同じバンドル・メカニズムを使うことができる。

  • That also gets rid of the configuration needs for SSR externals.

    また、SSRエクスターナルのコンフィギュレーションの必要性もなくなる。

  • So removing optimized depths, removing SSR externals are the two major goals of the full bundle mode and also greatly improving page load performance in larger projects.

    そのため、最適化された奥行きを削除し、SSRの外部を削除することが、フルバンドルモードの2つの主要な目標であり、また、大規模なプロジェクトにおけるページの読み込みパフォーマンスを大幅に向上させます。

  • So that's kind of down the road, probably Q2 next year.

    おそらく来年の第2四半期になるだろう。

  • And we will likely kick off some product development in parallel once we get the rolldown-based Vite into beta status.

    そして我々は、ロールダウン・ベースのヴァイトをベータ・ステータスにした後、並行していくつかの製品開発に着手することになるだろう。

  • Well, that sounds like a whole mountain of work that you guys have to do.

    まあ、それはあなたたちがやらなければならない仕事が山のようにあるように聞こえる。

  • So I wish you guys luck on that.

    だから、君たちの幸運を祈るよ。

  • That also wraps it up for our questions for this week's episode.

    これで今週のエピソードの質問は終わりです。

  • Thanks for coming on, Evan.

    来てくれてありがとう、エヴァン。

  • It was a pleasure to have you back on.

    また来てくれて嬉しいよ。

  • And it's exciting to see how much progress both the projects have had and what the new project holds.

    そして、両方のプロジェクトがどれだけ進展したか、そして新しいプロジェクトが何をもたらすかを見るのはエキサイティングなことだ。

  • Thank you.

    ありがとう。

  • Over to Chad.

    チャドのところだ。

  • Yeah, super excited for what y'all do.

    君たちの活躍に期待しているよ。

  • We had a few other episodes where we talked to people building infrastructure tooling.

    他にも、インフラストラクチャー・ツールを作っている人たちに話を聞いたエピソードがいくつかある。

  • We had the Biome team on a little while back.

    少し前にBiomeチームに出演してもらったんだ。

  • We had Charlie Marsh talking about RUF and UV in the Python ecosystem.

    チャーリー・マーシュにPythonのエコシステムにおけるRUFとUVについて話してもらった。

  • And this really seems like of the bets that we've taken in this space, this seems like the one that's most likely to succeed in my case.

    そしてこれは、私たちがこの分野で取った賭けの中で、私の場合、最も成功する可能性が高いもののように思える。

  • It's always a big bet.

    常に大きな賭けだ。

  • But I have a lot of faith in y'all.

    でも、僕はみんなを信じているよ。

  • So really excited to see what you do and wish you all the best.

    あなたの活躍を楽しみにしています。

  • Thank you.

    ありがとう。

The first stage of VEET really was like, let's just make things work and make it better than the status quo, but underneath there might be a lot of, you know, hacks and things we want to improve in the future.

VEETの最初の段階は、とにかく現状より良くしよう、うまくいくようにしようという感じだったが、その下にはハックや将来的に改善したいことがたくさんあるかもしれない。

字幕と単語
AI 自動生成字幕

ワンタップで英和辞典検索 単語をクリックすると、意味が表示されます