EvanYou (u/EvanYou) - Readit News

EvanYou commented on Vite+ – Unified toolchain for the web viteplus.dev/... · Posted by u/sangeeth96

yencabulator · 5 months ago

Vite is now open core, where whatever you think belongs in the commercial part is not welcome as open source. Rugpull means building a community around an open source project, and then trying to transfer that community to a non-open source product.

EvanYou · 5 months ago

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 commented on Vite+ – Unified toolchain for the web viteplus.dev/... · Posted by u/sangeeth96

hv42 · 5 months ago

I am wondering what vite+ will have that will really make it worth it compared to the "rstack" (i.e. rspack, rsbuild, rstest, rslint, etc.) rsbuild is already excellent and things like remote cache are on their roadmap?

EvanYou · 5 months ago

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 commented on Vite+ – Unified toolchain for the web viteplus.dev/... · Posted by u/sangeeth96

yencabulator · 5 months ago

Two questions:

1. This is a Vite rugpull, right?

2. What the hell do I migrate to to avoid the rugpull, now?

Lots of stuff builds on top of Vite, and this is an incredibly bad move from the Vite people.

EvanYou · 5 months ago

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 commented on Vite+ – Unified toolchain for the web viteplus.dev/... · Posted by u/sangeeth96

whstl · 5 months ago

Not "a lot of those".

It used Rollup.

And it does so transparently, while the alternative, Rolldown, was being finished.

To me this sounds like a more than acceptable compromise in the interim.

EvanYou · 5 months ago

Not even Rollup. Vite+ uses Rolldown which is also developed from the ground up by VoidZero.

EvanYou commented on Vite+ – Unified toolchain for the web viteplus.dev/... · Posted by u/sangeeth96

joaohaas · 5 months ago

>and is much better than the mess of Webpack/Rollup/Brunch/Grunt...

You do know that Vite uses a lot of these behind the scenes right? Vite in general has much better defaults so that you don't have to configure them most of the time, but anything a bit out of the box will still require messing with the configs extensively.

Not like OPs Vite+ changes anything regarding that.

EvanYou · 5 months ago

Vite+ is built on top of the Rust stack (Rolldown / Oxc) developed by the same team and uses none of these.

EvanYou commented on Farm: Fast vite compatible build tool written in Rust farmfe.org/... · Posted by u/rk06

EvanYou · 2 years ago

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 commented on Rolldown: Rollup compatible bundler written in Rust rolldown.rs/... · Posted by u/bpierre

catlifeonmars · 2 years ago

The “Why Rolldown” section cites two reasons:

1) esbuild isn’t good at splitting 2) rollup is too slow

Why wasn’t it an option to improve esbuild’s splitting functionality or to improve rollup performance? Why is it the best option to introduce yet another tool?

EvanYou · 2 years ago

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.

EvanYou commented on Svelte 5: Runes svelte.dev/blog/runes... · Posted by u/benmccann

wentin · 2 years ago

In Svelte 4, the let counter = 0 syntax is already reactive by default, a feature enabled by the compiler. This has been the status quo for Svelte prior to the rune change. The introduction of the $state(0) rune actually provides more hints about its reactivity than before, and restore the original meaning of let counter = 0 (in rune mode). While it's true that the compiler's "invasion" into JS/TS syntax has been a point of discussion, this invasion has been happening for a while, and the initial shock wave has been well-absorbed by the community.

Interestingly, the new changes could be seen as a retreat from that initial invasion, likely triggering a different response from the community. In fact, the resistance I've seen (and my own as well) has been in the opposite direction—it's hating this retreat, complaining Svelte becoming less "magical." and more close to regular joe Javascript.

EvanYou · 2 years ago

I’m specifically taking about non-component context, i.e. plain JS/TS files.

Previously Svelte was able to get a pass on this because magic only happens in svelte files - but in the future, any JS/TS files in a rune-enabled Svelte project will technically be SvelteScript, this never happened before and I doubt the community has already “absorbed” how significant this change is.

EvanYou commented on Svelte 5: Runes svelte.dev/blog/runes... · Posted by u/benmccann

rich_harris · 2 years ago

Hi! First up — not that it matters, but since people will wonder — our design wasn't informed by the Reactivity Transform. We evaluated something close to 50 designs, some of them extremely wacky, before settling on runes, and it wasn't until after that time that the Reactivity Transform was brought to our attention.

Nevertheless, it's interesting and validating that we landed on such similar approaches. While the Reactivity Transform failed, it did so for reasons that I don't think apply to us:

- $state and $ref are quite different. $state doesn't give you access to the underlying object, so there's no conversion necessary between reactive variables and ref objects (either in your head or in code).

- There's strict read/write separation. Anyone with access to a ref has the ability to change its value, which definitely causes problems at scale. It's something that React, Solid and Svelte 5 get right.

- Reactivity Transform introduces things like $() for magic destructuring and $$() for preserving reactivity across boundaries. We're instead encouraging people to use familiar JavaScript concepts like functions and accessors

- There are already a lot of different ways to work with Vue — SFCs vs non-SFCs, template syntax vs JSX, composition API vs options API, `<script>` vs `<script setup>`... on top of that, adding a new compiler mode that needs to interoperate with everything else is inevitably going to be a challenge. This isn't the case with Svelte. While both runes and non-runes mode will be supported for the next two major versions, meaning there will be some short term fragmentation, we've made it clear that runes are the future of Svelte.

EvanYou · 2 years ago

> $state and $ref are quite different.

I wouldn't say they are "different" - they are fundamentally the same thing: compiler-enabled reactive variables backed by runtime signals! But yes, Vue already exposes the underlying concept of refs, so for users it's two layers of abstractions. This is something that Svelte doesn't suffer from at this moment, but I suspect you will soon see users reinventing the same primitive in userland.

> There's strict read/write separation

I'd argue this is something made more important than it seems to be - we've hardly seen real issues caused by this in real world cases, and you can enforce separation if you want to.

> We're instead encouraging people to use familiar JavaScript concepts like functions and accessors

This is good (despite making exposing state much more verbose). In Vue, we had to introduce destructuring macros because we wanted the transform to be using the same return shape with all the existing composable functions like VueUse.

> There are already a lot of different ways to work with Vue

This is largely because Vue has a longer history, more legacy users that we have to cater to, so it's much harder to get rid of old cruft. We also support cases that Svelte doesn't account for, e.g. use without a compile step. That said, the default way with a compile step is now clearly Composition API + <script setup>. Reactivity Transform also only really applied in this case so the point you raised is kinda moot.

Separate from the above points, the main reason Reactivity Transform wasn't accepted remains in Runes: the fact that compiler-magic now invades normal JS/TS files and alters vanilla semantics. Variable assignments can now potentially be reactive - but there is no obvious indication other than the declaration site. We had users trying Reactivity Transform on large production codebases, and they ended up finding their large composition functions harder to grasp due to exactly this (and not any of the points raised above).