HackerTrans
TopNewTrendsCommentsPastAskShowJobs

EvanYou

no profile record

Submissions

VoidZero: Building a Unified Toolchain for JavaScript

voidzero.dev
34 points·by EvanYou·vor 2 Jahren·6 comments

comments

EvanYou
·vor 9 Monaten·discuss
Wrong - Vite is not open core, Vite+ is. This differentiation is important because even if a feature benefits Vite+, if it needs to be shipped via Vite then it has to be open source.

Companies willing to pay for Vite+ help sustain and improve the open source parts powering it, including Vite. Even if you only use Vite and not Vite+, you’d benefit from the success of Vite+, not the other way around.

I don’t really find anything inherently wrong with your definition of “rugpull”. If some people in the community are happy to pay for it and the rest also benefit because of it, that’s a win-win in my book.
EvanYou
·vor 9 Monaten·discuss
Good question.

The first and most important distinction is obviously which ecosystem you are more familiar / invested in (webpack vs. vite). It does make sense for projects deeply coupled to webpack to consider rspack first.

Putting that aside:

- Vite+ is a commercial offering with a company that can provide paid support. Rstack is a big corp by-product where their primary customers are internal teams.

- The Vite ecosystem provides way more options in choice of meta frameworks (Nuxt, Astro, React Router, Tanstack Start, SvelteKit, SolidStart...), and 3rd party tooling integrations

- While both written in Rust, our tools in general perform significantly better than rstack. With the upcoming full bundle mode, Vite 8 will be at least 2x faster than rsbuild across all categories (dev server start up, HMR, production build)

- Vitest and Oxlint are mature and widely used in production. rstest and rslint are both quite new and not even feature complete.
EvanYou
·vor 9 Monaten·discuss
A rugpull means taking back something that was given.

Before Vite+, we maintain Vite, Rolldown, Oxc, all of which are open source and widely used. These remain open source - nothing changes about existing projects.

Vite+ is an entirely new product built on top of our own open source, with additional features that are entirely new. You don't need to use Vite+. You can keep using all the open source that we already provide.

The revenue generated from Vite+ flows back into the development of both its proprietary features the underlying OSS. So if you are a user of our OSS, you'd benefit from Vite+ even if you don't use it, because it allows us to keep improving the OSS you are using.
EvanYou
·vor 9 Monaten·discuss
Not even Rollup. Vite+ uses Rolldown which is also developed from the ground up by VoidZero.
EvanYou
·vor 9 Monaten·discuss
Vite+ is built on top of the Rust stack (Rolldown / Oxc) developed by the same team and uses none of these.
EvanYou
·vor 2 Jahren·discuss
Note in the benchmark, it is comparing a React JSX project using @vitejs/plugin-react (Babel based) instead of @vitejs/plugin-react-swc (SWC based).

I made the exact same point two years ago when Turbopack came up with a similar benchmark: https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussi...

The point is if we want to compare bundler performance, we should keep all the non-architectural variables consistent across all implementations. Otherwise we are not comparing apples to apples.

PR submitted to update the benchmark: https://github.com/farm-fe/performance-compare/pull/11
EvanYou
·vor 2 Jahren·discuss
For esbuild: We know other teams that have attempted to improve code splitting based on esbuild and found it very difficult. A big part of it is that in order to be fast, esbuild applies multiple features (bundle, treeshaking, transforms) in as few AST visits possible, but that comes at the cost of the logic of different features not being layered / decoupled nicely. It is difficult for anyone other than Evan Wallace himself to add non-trivial new mechanisms to esbuild, and although we didn't directly talk to Evan about this, we felt it would be too much to ask for a substantial refactor of esbuild in order to get what we need. In addition, the people interested in making Rolldown happen has much more experience in Rust than in Go - and there is a lot more to leverage (e.g. napi-rs & Oxc) in the Rust-for-JS ecosystem.

For Rollup: the Rollup team itself has been trying to incrementally improve Rollup's performance, e.g. by swapping acorn with a Rust-based parser. But there's only so much you can gain starting from a pure JavaScript base, especially considering multicore utilization. Another aspect of the performance is in the back-and-forth between Rollup (on the JS side) and native transforms (swc, esbuild) - there is a lot of overhead repeatedly parsing / serializing ASTs and then passing strings across JS/native. By building on top of Oxc (which will ship transforms in the future) we hope to be able to stay on the native-side as much as possible to avoid such overhead.