EvanYou

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.

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.

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.

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

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

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

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.

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.

$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).

This is (surprisingly) almost identical to the Reactivity Transform explorations we did in Vue: https://vuejs.org/guide/extras/reactivity-transform.html

  let count = $ref(0)

  const double = $computed(() => count * 2)

  watchEffect(() => {
    console.log(double)
  })

- First take (ref sugar), Nov 2020: https://github.com/vuejs/rfcs/pull/228

- Take 2, Aug 2021: https://github.com/vuejs/rfcs/pull/368

- Take 3, Nov 2021: https://github.com/vuejs/rfcs/discussions/369

We provided it as an experimental feature and had a decent number of users trying it out in production. The feedback wasn't great and eventually decided to drop it. https://github.com/vuejs/rfcs/discussions/369#discussioncomm...

Author of Vue here - as many have pointed out, the article contains a number of comparisons that are incorrect.

I have written a post clarifying them: https://blog.vuejs.org/posts/on-migration.html

This analogy is plain wrong. The blog post lists multiple non-Vue frameworks/tools using Vite as their default build tool. Compare that to the number of non-JS languages (excluding ones that compile to JS) using NPM as their default package manager (0).

I do know Henry personally and Henry actually consulted me when he was debating whether he should quit his job to work on Babel full time. We also occasionally talk about the burdens of OSS maintenance so I know first hand how hard he's been trying to keep Babel afloat.

That said, a statement from the current most active paid contributor to Babel is probably more convincing: https://news.ycombinator.com/item?id=27116357

Proper Jest integration is blocked by async transformers (https://github.com/facebook/jest/pull/9889) which should land as part of Jest 27, so we are mostly waiting on that.

In the meanwhile, you can also consider:

- @web/test-runner (https://modern-web.dev/docs/test-runner/overview/)

- Cypress (both e2e and unit testing via its component test runner https://www.cypress.io/blog/2021/04/06/introducing-the-cypre...)

- Check out https://github.com/sodatea/vite-test-example for an example using the above.

At this point I don't think I really want to "sell" it to anyone. I've got enough things to maintain so I'd rather just have users who use Vite because they actually like it rather than people switching from webpack just out of FOMO.

FWIW that plugin does not make your existing webpack-based code magically work in snowpack. It's just using webpack to bundle your snowpack-based code.

Author of Vite here. I see many people evaluating Vite as a webpack replacement, so I want to clarify the goal of the project here:

It is NOT Vite's goal to completely replace webpack. There are probably a small number of features/capabilities that some existing webpack projects rely on that doesn't exist in Vite, but those features are in the long tail and are only needed by a small number of power users who write bespoke webpack configuration. Some of the commenters here probably belong in this group. If you do (e.g. you tried to migrate and found roadblocks, or evaluated and concluded that Vite doesn't suite your needs), use webpack by all means! You are not Vite's target audience by design - and you should absolutely pick the right tool for the job.

However, in the context of the general web dev population, 90% of existing devs and 100% of beginners don't need or care about these long tail features. This is an estimation made based on years of experience working on vue-cli, which is webpack-based. (context: I'm also the author of Vue.js and vue-cli is downloaded more than 3 million times per month on npm). Vite is optimized for these common use cases, and we've heard many success stories of painlessly moving from vue-cli/CRA to Vite.

This is also why Vite is a good fit for Repl.it where majority of its use cases overlap with the target use cases of Vite.

That said, we are also seeing frameworks like Svelte/Solid/Marko building SSR meta frameworks on top of Vite, projects that were previously webpack-based offering alternative modes running on top of Vite (e.g. Nuxt, Storybook), so we believe Vite does cover quite a lot even for power users.

So - try it, and if it doesn't work for you, stick to webpack (specially if you have an existing project relying on specific webpack behavior). As many people said, webpack 5 has made decent performance gains, and if you are targeting modern browsers, consider replacing Babel/TS with esbuild. These should already get you pretty far.

Having to write two type definitions for Component Props: one TS interface/type, and one as the JS object sucks.

Uh, you don't have to? TS inference works with the JS objects. There's no need to provide the generic argument here.

Also check out this: https://github.com/vuejs/rfcs/blob/sfc-improvements/active-r... (auto-generating runtime types from TS interface)

It's not that we can't implement it like that, the real challenge is in minimizing breakage from v2. We decided it's better to not completely alter how props are declared because that would be too much breakage.

Instead, there's the compiler-based approach with `<script setup lang="ts">`: https://docs.google.com/presentation/d/1VjBM6ae-fuawK1TltYLX... (runtime props definitions auto-generated from TS interface)

AFAIK there is currently no plan to replace existing php rendering with Vue SSR. They just wanted to make sure the framework they went with supports SSR so they are not locking themselves out of the possibility.

The HN implementation renders the comments on the client side because it was using the Firebase HN API which doesn't provide a friendly API for fetching the entire comment tree. Notably, some other HNPWA implementations were using a custom API endpoint. We didn't switch to it because the Vue HN was built as an educational demo rather than a benchmarking subject.

Team lead of Vue.js here. Clarifying a few points being raised in this thread:

- This does not mean Wikipedia is becoming an SPA. One of the reasons they picked Vue is because Vue can be used to progressively enhance a statically rendered page (just like jQuery, but with a declarative development paradigm), and it allows you to do so without a build step (while keeping the going-full-build-step option open).

- Wikimedia is not just Wikipedia. There are many other use cases across the Foundation where heavy interactivity is needed. Even within Wikipedia, there are cases like the editor / edit mode which can be considered non-trivial JavaScript applications.

- Adopting a new framework !== More JavaScript. Wikimedia already has an in-house framework which has become outdated and difficult to maintain. Adopting Vue allows the team to implement the same features with less code. It will shave off instead of adding to the bloat.

Who said they are going to make the entire page SPA? They picked Vue specifically because Vue allows them to progressively enhance parts of the page with interactivity without going full SPA (AND without hard reliance on a build step).

Let's get the logic straight here:

- The Vue project has more than 20 core team members and hundreds of contributors from all over the world. There are currently TWO active core team members working for big companies in China.

- These two core team members make their contributions to Vue on their own will. The companies they work for do not dictate how they contribute to Vue, nor do these companies have any control over how the project evolves.

- These Chinese companies do have to comply with local government regulations to be able to operate in China. Does that make every business in China evil? You have to realize that the Chinese government !== everything China. People in China needs to live and work, that means they have to grow their economy and start businesses regardless of what kind of government they have to put up with. Equaling running a successful business in China to supporting totalitarian politics is like equaling being successful in America to supporting patriarchy and white supremacy.

Yet here we are: "Avoid the project because evil China." - quite a stretch, isn't it? By the same logic, projects directly owned and controlled by a company that has been the most significant contributor to political misinformation probably should be avoided at all cost too. Yet to you it seem to be no big deal. Just gotta love the double standards here.

First of all, this new API has relatively little to do with performance. The main performance gain in Vue 3 comes from a new template compilation strategy invisible to users.

Second, I think it is over-simplifying the issue by equaling the new API with Complexity. The RFC can be tough to grok because it is dense; but actually looking at some examples will probably show you that the new API really isn't about "complexity": https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f...

Vue has a wide range of users. I honestly don't quite get how introducing an optional API can be an insult - because we clearly see some use cases we ran into can be more elegantly solved with the new API. Maybe you haven't run into them personally, but that doesn't mean your use case is "inferior" - we are all dealing with different types of applications. However, I think it would be a real insult if you think Vue will never have a use case that is complex enough to warrant these advanced APIs.

Regarding your question: feel free to stay with the current API for as long as you wish. As long as the community feels there's a need for the old API to stay, it will stay. The only one that can make the decision to switch to the new API is yourself.

Vue team lead here.

There is a lot of FUD in this thread so we need to clarify a bit:

- This API is purely additive to 2.x and doesn't break anything.

- 3.0 will have a standard build which adds this API on top of 2.x API, and an opt-in "lean build" which drops a number of 2.x APIs for a smaller and faster runtime.

- This is an open RFC, which means it's not set in stone. The whole point of having an RFC is so that users can voice their opinions. It's not like we are shipping this tomorrow.

For more details, we added a Q&A section at the top of the RFC to avoid further confusions: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs...

Author here - this was just a weekend hack and didn't really expect it to show up here, but thanks for the security related feedback. The setup now uses environment variables.

FWIW, the GitHub age isn't entirely accurate because both React and Vue had major rewrites and the current default branch doesn't hold the entire development history. Vue's first public release was Feb of 2014 and React is just celebrating its 5th birthday.

Not sure why this is the primary concern but... did you even try it? Webpack is really an internal implementation detail for VuePress and not visible at all in most use cases.

The Vue-based version is already in good progress and we plan to ship a beta early 2017: https://github.com/weexteam/weex-vue-framework/issues/9

Did you follow the official guide, step by step? Honestly, I think Vue's official guide is a better starting resource than ANY of the tutorials out there, please don't ignore the official docs and reach for "easy" tutorials.