Evan You, creator of Vue and Vite, brings a design background to open source tooling. His philosophy of simplicity and minimal APIs shapes Vite's evolution, from its plugin system to the Rust-based Rolldown rewrite.
Evan You, người tạo ra Vue và Vite, mang nền tảng thiết kế vào các công cụ mã nguồn mở. Triết lý đơn giản và API tối giản của ông định hình sự phát triển của Vite, từ hệ thống plugin đến việc viết lại Rolldown bằng Rust.
Welcome to Syntax.
Chào mừng đến với Syntax.
Today we have the goat, the man who has made web development easier for the entire world.
Hôm nay chúng ta có một huyền thoại, người đã làm cho việc phát triển web trở nên dễ dàng hơn cho toàn thế giới.
Um probably kept people in the career uh before they had Rage Kit.
Ừm, có lẽ đã giữ chân mọi người trong sự nghiệp trước khi họ có Rage Kit.
We have Evan Yu on.
Chúng ta có Evan Yu.
He's a creator of Vue.
Anh ấy là người tạo ra Vue.
Um creator of Vit, which probably everybody listening to this podcast has used many times and it probably powers many of your businesses.
Ừm, người tạo ra Vite, thứ mà có lẽ mọi người nghe podcast này đã dùng nhiều lần và nó có lẽ đang vận hành nhiều doanh nghiệp của các bạn.
So stoked to have him on.
Rất hào hứng khi có anh ấy tham gia.
Welcome, Evan.
Chào mừng, Evan.
Thanks for coming on.
Cảm ơn vì đã đến.
- Yeah, excited to be here.
- Vâng, rất hào hứng được ở đây.
- So, real quick before we get into it, for the like six people who haven't done it, g give us an introduction of who you are and what you do and kind of your background.
- Vậy, nhanh thôi trước khi chúng ta bắt đầu, cho khoảng sáu người chưa biết, hãy giới thiệu cho chúng tôi bạn là ai, bạn làm gì và sơ lược về xuất thân của bạn.
- Sure.
- Chắc chắn rồi.
Yeah.
Vâng.
Um, so I had been a independent open source developer for over a decade like since 2015 16ish.
Ừm, tôi đã là một nhà phát triển mã nguồn mở độc lập hơn một thập kỷ, kiểu từ khoảng năm 2015, 2016.
Two years ago, I founded a company called Voice Zero, which is centered, you know, with a with a mission to uh to build open source tool chains for JavaScript.
Hai năm trước, tôi thành lập một công ty tên là Vue Zero, tập trung, bạn biết đấy, với sứ mệnh xây dựng các chuỗi công cụ mã nguồn mở cho JavaScript.
Yeah, before that I created Vue, Vit.
Vâng, trước đó tôi đã tạo ra Vue, Vite.
Uh probably some people use it, some people know it, but um - yeah, now I'm mostly focusing on uh Voy Zero and the feed side of things.
Ừm, có lẽ một số người dùng nó, một số người biết nó, nhưng ừm - vâng, hiện tại tôi chủ yếu tập trung vào ừm Vue Zero và phần feed.
- Yeah.
- Vâng.
So I think the one of the um interesting things for me was that you were primarily known as like a framework author uh prior to VIT.
Vậy tôi nghĩ một trong những điều ừm thú vị với tôi là trước Vite, bạn chủ yếu được biết đến như một tác giả framework.
Uh - did you see yourself making that change from working on the UI code tool chain?
Ừm - bạn có thấy mình thực hiện sự thay đổi đó từ làm việc với chuỗi công cụ mã UI không?
- Um not really.
- Ừm, không hẳn.
So I would say a lot of the decisions of like what do I do next just kind of I never really planned it ahead of time like before I started even doing JavaScript development I thought I was going to be a designer.
Vậy tôi muốn nói rằng nhiều quyết định kiểu như tôi làm gì tiếp theo chỉ là, tôi chưa bao giờ thực sự lên kế hoạch trước, kiểu như trước khi tôi bắt đầu làm phát triển JavaScript, tôi nghĩ mình sẽ trở thành nhà thiết kế.
- Mhm.
- Ừm.
- I wanted to be a designer and then after I designed some stuff I was like I want to actually build it but I couldn't find anyone to build it for me so I had to learn how to build it myself.
- Tôi muốn trở thành nhà thiết kế và sau khi thiết kế một số thứ, tôi nghĩ mình muốn thực sự xây dựng nó nhưng tôi không tìm được ai xây dựng cho mình nên tôi phải tự học cách xây dựng.
um and somehow got more into uh actually building stuff.
Ừm và bằng cách nào đó tôi ngày càng tập trung vào việc thực sự xây dựng mọi thứ.
And then as I built stuff, I'm like these tools kind of, you know, it's kind of clunky.
Và rồi khi tôi xây dựng mọi thứ, tôi nghĩ những công cụ này, bạn biết đấy, khá là vụng về.
What about I build a framework for myself?
Sao mình không tự xây dựng một framework cho chính mình nhỉ?
And as I built frameworks, I just kind of dig duck deeper and deeper.
Và khi tôi xây dựng các framework, tôi cứ đào sâu hơn và sâu hơn.
It's a wormhole.
Nó là một cái hố sâu.
Yeah, - you just kept solving your the problems that you had until you're uh one day you wake up and you're you're writing
Vâng, - bạn cứ tiếp tục giải quyết những vấn đề bạn gặp cho đến khi ừm một ngày bạn thức dậy và bạn đang viết
low-level Rust to solve all your problems.
Rust cấp thấp để giải quyết mọi vấn đề của mình.
- And this might be a weird comment, but uh there's something about the aesthetic of not just like the visual aesthetic, but like the things that you make that makes it kind of obvious that you wanted to be a designer.
- Và đây có thể là một nhận xét kỳ lạ, nhưng ừm có điều gì đó về thẩm mỹ không chỉ là thẩm mỹ thị giác, mà là những thứ bạn tạo ra khiến rõ ràng rằng bạn từng muốn trở thành nhà thiết kế.
Like Vue is a beautiful uh looking JavaScript framework, right?
Kiểu như Vue là một framework JavaScript trông đẹp đẽ, đúng không?
like yeah it's it's hard to describe many JavaScript frameworks as like looking nice just in
Vâng, thật khó để mô tả nhiều framework JavaScript là trông đẹp chỉ trong
a code context but I that I wonder like how much of that is informed just by your aesthetic awareness.
Ngữ cảnh mã, nhưng tôi tự hỏi liệu bao nhiêu phần trong đó được định hình chỉ bởi nhận thức thẩm mỹ của bạn.
- It definitely played a role cuz uh I think I probably put more effort into the documentation than the average developer who made frameworks.
- Nó chắc chắn đóng một vai trò vì ừm tôi nghĩ mình có lẽ đã dành nhiều công sức cho tài liệu hơn so với nhà phát triển trung bình tạo ra framework.
- Um so that probably helped with definitely helped with the initial adoption of view.
- Ừm, vậy điều đó có lẽ đã giúp ích, chắc chắn đã giúp ích cho việc tiếp nhận ban đầu của Vue.
We were asking that um when we had the Daniel from KNX on.
Chúng tôi đã hỏi điều đó ừm khi chúng tôi có Daniel từ KNX tham gia.
We're just like why is everything in this whole view kind of associated ecosystem?
Chúng tôi chỉ thắc mắc tại sao mọi thứ trong toàn bộ hệ sinh thái gắn với Vue lại như vậy?
Why is everything so polished and so simple and even to extend it um the API design as well is really really simple.
Tại sao mọi thứ đều được trau chuốt và đơn giản đến vậy, và ngay cả khi mở rộng nó ừm thiết kế API cũng thực sự rất đơn giản.
So, I'm I'm curious if you have any like core philosophies as to like just designing stuff in general, whether it's what it looks like or whether how the what the API design looks like.
Vậy tôi tò mò liệu bạn có triết lý cốt lõi nào về việc thiết kế mọi thứ nói chung không, dù là nó trông như thế nào hay thiết kế API trông như thế nào.
- Yeah.
- Vâng.
I think um interestingly because I initially got into web development from a non-engineering back background, right?
Tôi nghĩ ừm thú vị là vì ban đầu tôi bước vào phát triển web từ một nền tảng phi kỹ thuật, đúng không?
So, uh, a lot of people probably know that when I started to work on Vue, I was working at Google and we worked on some projects that used Angular and I could tell that Angular was created by someone very engineer-minded and it came with a lot of concepts and u like
Vậy ừm, nhiều người có lẽ biết rằng khi tôi bắt đầu làm việc với Vue, tôi đang làm ở Google và chúng tôi làm một số dự án dùng Angular và tôi có thể thấy rằng Angular được tạo ra bởi một người rất thiên về kỹ thuật và nó đi kèm với rất nhiều khái niệm và ừm như
terminology to me back then was like why do I even need to know this when I just want to put some interactive stuff on the web page, right?
Thuật ngữ với tôi hồi đó kiểu như tại sao tôi lại cần biết điều này khi tôi chỉ muốn đặt một số thứ tương tác lên trang web, đúng không?
So in a way this like not having prior experience in serious engineering actually allow me to just focus on the minimal subset of things that I really cared about like what is the simplest API that I can design for myself to you know do what I
Vậy theo một cách nào đó, việc không có kinh nghiệm trước đó trong kỹ thuật nghiêm túc thực sự cho phép tôi chỉ tập trung vào tập hợp tối thiểu những thứ tôi thực sự quan tâm, kiểu như API đơn giản nhất mà tôi có thể thiết kế cho chính mình để bạn biết đấy, làm điều tôi
want to do right and turns out that probably uh you know aligns with a lot of people who um come into web development from other backgrounds too because uh one thing I found interesting is web development is you know it's a very big tent there are people building different kind of things people coming from different backgrounds and I think you know the simplicity and just focus
Muốn làm, đúng vậy, và hóa ra điều đó có lẽ ừm bạn biết đấy, phù hợp với nhiều người ừm bước vào phát triển web từ các nền tảng khác vì ừm một điều tôi thấy thú vị là phát triển web, bạn biết đấy, là một cái lều rất lớn, có người xây dựng những thứ khác nhau, người đến từ những nền tảng khác nhau và tôi nghĩ bạn biết đấy, sự đơn giản và chỉ tập trung
on doing something with the easiest way possible probably echoed with a lot of people - I agree with that but like if I were to go off and maybe create Vit um like I like I feel like I know the entire V API you know, I've I've built several lower level plugins in it.
Vào việc làm gì đó theo cách dễ dàng nhất có thể có lẽ đã cộng hưởng với nhiều người - Tôi đồng ý với điều đó nhưng kiểu nếu tôi đi và có lẽ tạo ra Vite ừm kiểu như tôi cảm thấy mình biết toàn bộ API của Vite, bạn biết đấy, tôi đã xây dựng vài plugin cấp thấp trong đó.
I've built very complex um like I've migrated old apps that were in parcel and Webpack and brought it into one.
Tôi đã xây dựng những thứ rất phức tạp ừm kiểu như tôi đã di chuyển các ứng dụng cũ từng ở parcel và Webpack và đưa nó vào một cái.
And I use
Và tôi dùng
the websocket proxy API.
API proxy websocket.
Like I feel like I know the entire Vit API, but like I don't know that I could design something so simple and beautiful.
Giống như tôi cảm thấy mình biết toàn bộ API của Vit, nhưng tôi không nghĩ mình có thể thiết kế được thứ gì đó đơn giản và đẹp đẽ như vậy.
And also just like upgrading from major version to major version, there's never really any major like thrashing changes, you know?
Và cũng giống như việc nâng cấp từ phiên bản chính này sang phiên bản chính khác, không bao giờ thực sự có bất kỳ thay đổi lớn nào gây xáo trộn, bạn biết không?
was just like, "Oh, the new version's out.
Chỉ kiểu như, "Ồ, phiên bản mới ra rồi.
- Stuck to it." - Yeah.
- Cứ bám theo nó." - Ừ.
Made most - uh funny story, we made the biggest breaking change between V1 and V2 cuz uh if if you followed along the early days of Vit like we came all the we went all the way to like 1.0 RC on the initial design based on the first prototype I made.
Đã tạo ra hầu hết - ừ, câu chuyện buồn cười, chúng tôi đã tạo ra thay đổi phá vỡ lớn nhất giữa V1 và V2 vì ừ nếu nếu bạn theo dõi những ngày đầu của Vit, kiểu như chúng tôi đã đi tất cả các bước đến tận 1.0 RC trong thiết kế ban đầu dựa trên nguyên mẫu đầu tiên tôi làm.
So here I gotta give credits to two people Jason Miller Rich Harris because uh Rich was the original
Vậy nên ở đây tôi phải ghi công cho hai người Jason Miller và Rich Harris vì ừ Rich là tác giả gốc
author of Rolup which a lot of the Vit's plugging API is based on top of right - and uh V1 did not have a plug-in system the view logic in V1 was like hardcoded - it was around that time I started to think about like production build we were using rollup so we were using rollup plugins I was like can we make the rollup plugins work for the dev server too.
của Rollup, thứ mà rất nhiều API plugin của Vit dựa trên đó, đúng không - và ừ V1 không có hệ thống plugin, logic view trong V1 kiểu như được mã hóa cứng - vào khoảng thời gian đó tôi bắt đầu nghĩ về kiểu như bản build production, chúng tôi đang dùng rollup nên chúng tôi đang dùng các plugin rollup, tôi tự hỏi liệu chúng ta có thể làm cho các plugin rollup hoạt động cho cả dev server không.
And then I found out uh
Và rồi tôi phát hiện ra ừ
Jason Miller actually did it in his project called WMR.
Jason Miller thực ra đã làm điều đó trong dự án của anh ấy có tên là WMR.
He did this like rollup plug-in simulator that is able to just run rollup plugins without actually running rollup itself.
Anh ấy đã làm cái kiểu như trình mô phỏng plugin rollup này, thứ có thể chạy các plugin rollup mà không thực sự chạy chính rollup.
So that inspired me to essentially say okay let's use this for Vit so we can have the same plug-in system for the dev server and the production build right.
Vậy nên điều đó truyền cảm hứng cho tôi để về cơ bản nói rằng được, hãy dùng cái này cho Vit để chúng ta có thể có cùng một hệ thống plugin cho cả dev server và bản build production, đúng không.
Um, I had to rewrite the whole thing and that became
Ừm, tôi đã phải viết lại toàn bộ và nó trở thành
V2.
V2.
So, we never actually shipped V1.
Vậy nên, chúng tôi thực ra chưa bao giờ phát hành V1.
- Oh, and if you want to see all of the errors in your application, you'll want to check out Sentry at centry.io/sintax.
- Ồ, và nếu bạn muốn xem tất cả các lỗi trong ứng dụng của mình, bạn sẽ muốn xem Sentry tại centry.io/sintax.
You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it.
Bạn không muốn có một ứng dụng production ngoài kia mà, à, bạn không có khả năng quan sát gì cả trong trường hợp có gì đó nổ tung và bạn thậm chí có thể không biết.
So, head on over to centry.io/sintax.
Vậy nên, hãy truy cập centry.io/sintax.
Again, we've been using this tool for a long time and it totally rolls.
Một lần nữa, chúng tôi đã sử dụng công cụ này trong một thời gian dài và nó hoàn toàn tuyệt vời.
All right, let's talk a little bit about the whole roll up and roll down um and how that works.
Được rồi, hãy nói một chút về toàn bộ roll up và roll down ừm và cách nó hoạt động.
So, like Vit is built on top of another tool um and then you have recently rewritten that tool.
Vậy, kiểu như Vit được xây dựng trên một công cụ khác ừm và rồi gần đây bạn đã viết lại công cụ đó.
- Yep.
- Đúng vậy.
- So, it's it's no longer technically a rewrite because uh originally the name is rowdown because we're like, okay, this is going to be a role port.
- Vậy nên, về mặt kỹ thuật nó không còn là một bản viết lại nữa vì ừ ban đầu tên là rowdown vì chúng tôi kiểu như, được, cái này sẽ là một bản port của rollup.
We're just gonna straight up port it.
Chúng tôi sẽ port thẳng nó luôn.
- Yeah.
- Ừ.
- Turns out, you know, Rust works very differently from JavaScript.
- Hóa ra là, bạn biết đấy, Rust hoạt động rất khác so với JavaScript.
So, a port is like you can you can never straightforwardly port dynamic JavaScript code to Rust, right?
Vậy nên, một bản port kiểu như bạn không bao giờ có thể port thẳng mã JavaScript động sang Rust một cách đơn giản, đúng không?
So, we ended up actually uh going with an architecture that's more similar to ES build than rollup.
Vậy nên, cuối cùng chúng tôi thực ra ừ đã đi theo một kiến trúc giống ES build hơn là rollup.
Um and the feature scope also is more like ES build than rollup.
Ừm và phạm vi tính năng cũng giống ES build hơn là rollup.
So um rollup itself the core is
Vậy ừm bản thân rollup, phần lõi
very lean.
Rất tinh gọn.
It relied mostly on plugins.
Nó chủ yếu dựa vào các plugin.
So let's say if you want to do resolve node modules if you want to transpile TypeScript or JSX you all need plugins right ES build kind of just does all of this out of the box.
Vậy giả sử nếu bạn muốn resolve các node module, nếu bạn muốn transpile TypeScript hoặc JSX, bạn đều cần plugin, đúng không, ES build kiểu như làm tất cả những thứ này ngay từ đầu.
You don't need to use a plug-in just to transpile TypeScript.
Bạn không cần dùng plugin chỉ để transpile TypeScript.
So uh rowdown is essentially uh implemented in Rust.
Vậy ừ rowdown về cơ bản ừ được triển khai bằng Rust.
It a lot of stuff work out of the box.
Nó, rất nhiều thứ hoạt động ngay từ đầu.
TypeScript, JSX, uh, Node module resolving, but the
TypeScript, JSX, ừ, resolve node module, nhưng
API is roll-ups.
API là của rollup.
So, we support rollup plugins.
Vậy nên, chúng tôi hỗ trợ các plugin rollup.
It's a Rust bundler, but we support JavaScript plugins.
Nó là một bundler Rust, nhưng chúng tôi hỗ trợ các plugin JavaScript.
So, if you have a rollup plug-in that's written in JavaScript, it will actually just work in ROA.
Vậy nên, nếu bạn có một plugin rollup được viết bằng JavaScript, nó thực ra sẽ hoạt động ngay trong ROA.
So, yeah, - how does that work?
Vậy ừ, - điều đó hoạt động như thế nào?
- It relies on something called uh a project called uh NAPI RS.
- Nó dựa vào một thứ gọi là ừ một dự án có tên là ừ NAPI RS.
So, uh, Node.js has this thing called N API that allows you to basically do cross language calls.
Vậy, ừ, Node.js có thứ gọi là N API cho phép bạn về cơ bản thực hiện các cuộc gọi xuyên ngôn ngữ.
So - native API, right?
Vậy - native API, đúng không?
That's what the N is.
Đó là ý nghĩa của chữ N.
- Yeah.
- Ừ.
So NAPI RS is a project that's uh that's a that aims to make it easier for you to write some Rust code and uh auto automatically generate the binding so you can call the Rust code from JavaScript and vice versa.
Vậy NAPI RS là một dự án ừ nhằm mục đích giúp bạn dễ dàng hơn khi viết một số mã Rust và ừ tự động tạo ra các binding để bạn có thể gọi mã Rust từ JavaScript và ngược lại.
- Okay.
- Được rồi.
and we had the TypeScript folks on um and so we have to ask this question of like why didn't you use Go versus Rust.
Và chúng tôi đã có những người từ TypeScript ừm và vậy nên chúng tôi phải hỏi câu hỏi kiểu như tại sao bạn không dùng Go mà lại dùng Rust.
Um and the reason the TypeScript folks gave us is because that like it's much easier to port JavaScript to Go because they're literally just going function by function rewriting the entire thing.
Ừm và lý do mà nhóm TypeScript đưa ra cho chúng tôi là vì việc chuyển JavaScript sang Go dễ dàng hơn nhiều vì họ thực sự chỉ cần viết lại từng hàm một.
But you said you just said it's not the same with Rust.
Nhưng bạn vừa nói rằng điều đó không giống với Rust.
So what's
Vậy thì
the why didn't you pick Go for that?
Tại sao bạn không chọn Go cho việc đó?
- Yeah.
- Ừ.
So there are a few pretty practical reasons, right?
Vậy có một vài lý do khá thực tế, đúng không?
because I don't so it like you know different projects have different constraints it's not a purely a technical decision for us it's mostly because we had a group of people who are already proficient with rust who are interested in working on this right second the rust ecosystem is already pretty mature for when it comes
Bởi vì tôi không... bạn biết đấy, các dự án khác nhau có những ràng buộc khác nhau, đó không phải là quyết định thuần túy kỹ thuật đối với chúng tôi, chủ yếu là vì chúng tôi đã có một nhóm người đã thành thạo Rust và quan tâm đến việc làm việc này, thứ hai là hệ sinh thái Rust đã khá trưởng thành khi nói đến
to like tooling forjs there's there are a lot of crates uh and uh people have worked on things like swc and oxc ox These are like low-level language tool chains that gives you like parsers and transformers uh stuff like that.
Công cụ cho JS, có rất nhiều crate và mọi người đã làm việc trên những thứ như swc và oxc. Đây là những chuỗi công cụ ngôn ngữ cấp thấp cung cấp cho bạn các parser và transformer, những thứ như vậy.
So when we build a bundler, we got to think about like what do we build on top of and in terms of like this layer uh rust actually has a better ecosystem compared
Vì vậy, khi chúng tôi xây dựng một bundler, chúng tôi phải nghĩ xem chúng tôi xây dựng dựa trên cái gì và về lớp này, Rust thực sự có hệ sinh thái tốt hơn so với
to go.
Go.
And a final important consideration is uh we actually do still want our tools to be able to run in the browser and the web assembly story of Rust is much better than Go's.
Và một cân nhắc quan trọng cuối cùng là chúng tôi thực sự vẫn muốn các công cụ của mình có thể chạy trong trình duyệt và câu chuyện WebAssembly của Rust tốt hơn nhiều so với Go.
- Oh, okay.
- Ồ, được rồi.
- Yeah.
- Ừ.
- Interesting.
- Thú vị.
Yeah, I never thought about that, but yet it needs to run in a JavaScript runtime - and you do that with web assembly - when we run it with Node.js or bun, you know, it's actually the Rust compile rust binary, but if you want to run in the browser, it has to be web assembly.
Ừ, tôi chưa bao giờ nghĩ về điều đó, nhưng nó cần chạy trong môi trường JavaScript - và bạn làm điều đó với WebAssembly - khi chúng tôi chạy nó với Node.js hoặc Bun, bạn biết đấy, thực ra đó là binary Rust được biên dịch, nhưng nếu bạn muốn chạy trong trình duyệt, nó phải là WebAssembly.
So that's the distinction.
Vậy đó là sự khác biệt.
So the row down web assembly build runs in the browser.
Vậy bản build WebAssembly của Rolldown chạy trong trình duyệt.
actually uh I think quickjs they just migrated their playground from rollup to roll down - it's it runs in the browser and it made their playground through to four times faster.
Thực ra tôi nghĩ QuickJS họ vừa chuyển playground của họ từ Rollup sang Rolldown - nó chạy trong trình duyệt và làm cho playground của họ nhanh hơn từ ba đến bốn lần.
- Wow.
- Ồ.
With rolldown so since it is a a port to an extent a rewrite or evolution you could say I' I've been seeing a lot of the blog posts and mentions about just how much faster it is in various regards.
Với Rolldown, vì nó là một phần chuyển đổi, có thể nói là viết lại hoặc phát triển, tôi đã thấy rất nhiều bài blog và đề cập về việc nó nhanh hơn bao nhiêu ở nhiều khía cạnh.
Can you talk a little bit about the speed that comes with moving to something like rolldown in uh where that speed shows up and then what choices that you made actually uh
Bạn có thể nói một chút về tốc độ đi kèm khi chuyển sang thứ như Rolldown, tốc độ đó thể hiện ở đâu và những lựa chọn bạn đã thực hiện thực sự
allowed that speed to take place?
Cho phép tốc độ đó diễn ra?
Is it just Rust or can you can you go into some of that?
Chỉ là Rust hay bạn có thể đi sâu vào một số điều đó?
- Yeah.
- Ừ.
Um so it boils so first of all it goes all the way down to like what parser do you use, right?
Ừm, vậy nó bắt nguồn từ việc bạn dùng parser nào, đúng không?
So uh one decision we made very early on is we bet on OXC.
Vậy một quyết định chúng tôi đưa ra rất sớm là đặt cược vào OXC.
uh OXC is - the language tool chain um it's an alternative to S SWC essentially right so it has its own parer and I was evaluating the existing solutions and I just found OXC to be very fundamentally performanceoriented in its
OXC là - chuỗi công cụ ngôn ngữ, về cơ bản nó là một giải pháp thay thế cho SWC, đúng vậy, nó có parser riêng và tôi đã đánh giá các giải pháp hiện có và tôi thấy OXC rất định hướng hiệu suất về cơ bản trong thiết kế của nó
design in a lot of aspects actually uh we decided to bet it on OXC before the author Bian joined the company so he joined us like a like you I think like half a year later I tried to - convince him to join earlier but uh he was like I need to think about this but he eventually joined so uh that's a good thing.
Ở nhiều khía cạnh, thực ra chúng tôi quyết định đặt cược vào OXC trước khi tác giả Bian gia nhập công ty, anh ấy tham gia với chúng tôi khoảng nửa năm sau đó, tôi đã cố gắng thuyết phục anh ấy tham gia sớm hơn nhưng anh ấy nói cần suy nghĩ, nhưng cuối cùng anh ấy đã tham gia, vậy đó là điều tốt.
Um so oxc you know there's there are a few design decisions at this
Ừm, vậy OXC, bạn biết đấy, có một vài quyết định thiết kế ở cấp độ này
level for example uh memory allocation because it's actually all about like how do you allocate memory efficiently like oxy uses something called arena allocator which means the whole a is like allocated in a con consecutive chunk of memory so you have like less fragmentation and you can drop the whole thing all together instead of being having to like more fine grain
Ví dụ như cấp phát bộ nhớ, vì thực ra tất cả là về cách bạn cấp phát bộ nhớ hiệu quả, OXC sử dụng thứ gọi là arena allocator, nghĩa là toàn bộ được cấp phát trong một khối bộ nhớ liên tục, vì vậy bạn có ít phân mảnh hơn và bạn có thể giải phóng toàn bộ cùng một lúc thay vì phải quản lý bộ nhớ chi tiết hơn
management agement of the memory.
Quản lý bộ nhớ.
- So I'm actually like less familiar with this layer because it's mostly motion domain.
- Thực ra tôi ít quen thuộc với lớp này vì nó chủ yếu thuộc lĩnh vực chuyển động.
Uh but on top of that we are also debated a lot on you know some of the architectural decisions like do we want to use a stringbased uh bundle generation strategy or more a generated but most of the gains comes from a clean architecture that allows optimal parallelization you know uh and
Nhưng trên hết, chúng tôi cũng tranh luận nhiều về một số quyết định kiến trúc như liệu chúng tôi muốn sử dụng chiến lược tạo bundle dựa trên chuỗi hay tạo nhiều hơn, nhưng hầu hết lợi ích đến từ kiến trúc sạch cho phép song song hóa tối ưu, bạn biết đấy, và
the raw power of rust itself some of that is indeed uh you know inspired by how uh ES builds the design the pipeline design S build allows you to essentially kind of divide the different phases of work and parallelize them as much as possible.
Sức mạnh thô của chính Rust, một số điều đó thực sự được truyền cảm hứng từ cách ESBuild thiết kế pipeline, thiết kế của ESBuild cho phép bạn chia các giai đoạn công việc khác nhau và song song hóa chúng càng nhiều càng tốt.
So that definitely helps.
Vậy điều đó chắc chắn giúp ích.
So yeah, so when it's speaking to some numbers, usually you would see if it's just like a simple JavaScript bundle
Vậy ừ, khi nói đến một số con số, thường bạn sẽ thấy nếu chỉ là một bundle JavaScript đơn giản
compared between say rollup versus rolldown is like 20 to 30 times faster uh is the uh the ballpark.
So sánh giữa Rollup và Rolldown thì nhanh hơn khoảng 20 đến 30 lần, đó là khoảng ước lượng.
And when it when you put it into a real world project, we've seen anywhere from like three to four times to 16 times faster in production apps.
Và khi đưa vào dự án thực tế, chúng tôi đã thấy nhanh hơn từ ba đến bốn lần đến 16 lần trong các ứng dụng production.
- That's nuts.
- Điều đó thật điên rồ.
And we had um why am I forgetting his name?
Và chúng tôi đã có, ừm, tại sao tôi lại quên tên anh ấy?
The author of uh the Webpack Rust.
Tác giả của Webpack Rust.
Why am I blanking on his name?
Tại sao tôi lại quên tên anh ấy?
Zack.
Zack.
Um we had we had Zach um who is writing the Webpack port Rust and he was RSpack.
Ừm, chúng tôi đã có Zach, người đang viết bản chuyển Webpack sang Rust và anh ấy là RSpack.
That's what it is.
Đúng rồi.
Thank you.
Cảm ơn.
Um, and like I don't I don't necessarily want to talk about that, but I just love hearing the stories of the builds that you encounter.
Ừm, và tôi không nhất thiết muốn nói về điều đó, nhưng tôi thích nghe những câu chuyện về các bản build mà bạn gặp.
Like he was telling us about the builds at Bite Dance that are just hours, you know, they're just gargantuan, you know, cuz like my our little websites, they build in a minute or so, you know, and that's that's relatively fast.
Anh ấy kể cho chúng tôi về các bản build tại ByteDance chỉ mất hàng giờ, bạn biết đấy, chúng thật khổng lồ, vì những trang web nhỏ của chúng tôi build trong khoảng một phút, bạn biết đấy, và đó là tương đối nhanh.
But like
Nhưng như