Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vite+ – Unified toolchain for the web

viteplus.dev

Post reply on HN
Print view View original

131–140 of 151 posts

Re: Vite+ – Unified toolchain for the web

#131

Post by collingreen »

whstl wrote: post #125
collingreen wrote: post #107

Earlier quoted context omitted.

"Ok you directly addressed one of my hand picked examples, clearly showing your point and why my example wasn't a good one. Now address all my other ones before I consider your perspective might be valid!" This is like the comment version of the gish gallop.

No, that's an answer to a cherry-picked reply. It was one package that had a version migration. I don't necessarily agree but I'm trying to move the discussion forward rather than staying at the "it's all shit" lane. And I gave three other examples, and I can give others: React itself has been around for 12 years, leading. Vue has been super stable too. Migrating versions of frameworks is several magnitudes harder th…

I'm not even against you in general but "react for 12 years" is another really bad example with the complete paradigm change from classes to hooks. I even think hooks are better, but I'm not going to sit and tell people their fatigue isn't valid when even your argument is "some of these aren't as bad as babel or webpack".

Re: Vite+ – Unified toolchain for the web

#132

Post by EvanYou »

yencabulator wrote: post #115

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.

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.

Re: Vite+ – Unified toolchain for the web

#133

Post by EvanYou »

hv42 wrote: post #46

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?

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.

Re: Vite+ – Unified toolchain for the web

#134

Post by yencabulator »

EvanYou wrote: post #132
yencabulator wrote: post #115

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.

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 pro…

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.

Re: Vite+ – Unified toolchain for the web

#135

Post by EvanYou »

yencabulator wrote: post #134
EvanYou wrote: post #132

Earlier quoted context omitted.

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 pro…

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.

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.

Re: Vite+ – Unified toolchain for the web

#136

Post by yencabulator »

EvanYou wrote: post #135
yencabulator wrote: post #134

Earlier quoted context omitted.

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.

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 fin…

The line between Vite and Vite+ exists mostly inside your head. From the outside, Vite is the open core and some set of features are only in Vite+.

Best of luck with your commercial project. History has not been kind to open core projects.

Re: Vite+ – Unified toolchain for the web

#137

Post by romanovcode »

yurishimo wrote: post #57
romanovcode wrote: post #34

Earlier quoted context omitted.

Using Java/.NET with server side rendered HTML + webpack/react for dynamic components (which nearly are non-existent with modern CSS). Works great.

It entirely depends on the type of application you are building. Boring CRUD app that is rarely updated? Yea, server rendering is probably enough. But the requirements of "modern" software are always changing. Sure, the static table might be enough, but then some business person says, "It sure would be nice if I could check a little box in the table row or assign this user here..." and now you're adding little JS hac…

Hmm but that table would be actually what I would write in React most likely. Considering most tables want pagination, filtering and so on it would be dumb to use query-string params and reload the page. So this would actually fit perfectly.

I have this set-up where .NET ViewHelper would do `RenderReactComponent('complexTableComponent', '.complex-table-component')` and it would load bundled react as 1st script and then this component as second script. If page does not need no react components it does not load any. If you have more than one it will still load the react itself only once. It is really amazingly working very, very well.

And yes, if I would to build some kind of dashboard/email client or something I would say use React or Angular and API. But for regular website rendered HTML is king.

Re: Vite+ – Unified toolchain for the web

#138

Post by romanovcode »

whstl wrote: post #83
pjmlp wrote: post #79

Earlier quoted context omitted.

Same here, since 2001. It pains me that so many SaaS go for Next.js based SDKs, but at least it is the closest to Spring/Quarkus/ASP.NET in spirit.

If I had my way I would still be writing ASP.NET WebForms, but the market decided to move. I don't even know if it still works. Hot take but: it took 20 years for Next.js to catch up to 10% of WebForms offered. But if people want whatever Next.js offers to build their copycat SaaS with shadcn/ui, so who am I to argue.

> if people want

You mean many developers want. Actual customers, the ones who pay for your work don't even know what Next.js is and are extremely happy with whatever works. The hard part is to sell the idea that - no, next.js is not the best for your SEO heavy website :)

Re: Vite+ – Unified toolchain for the web

#140

Post by rk06 »

hv42 wrote: post #69
thiht wrote: post #48

Earlier quoted context omitted.

Familiarity I guess? I've never heard of rsbuild before. In comparison, the "Vite" name directly brings me joy and makes me think of high quality, enjoyable tooling.

They seem to have less marketing for sure. If you are migrating from webpack or create-react-app, rspack/rsbuild is a no brainer. (at least worth a try IMO)

if you are heavily on custom webpack config, then rspack would be your only practical option. for all other use cases like CRA migration, vite is much better and supported option as vite unlocks entirely different migration paths for your project
Post reply on HN