Switch Bud to Vite

[acalvino4]

Agreement

• [X] This is not a duplicate of an existing issue
• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This is not a personal support request that should be posted on the Roots Discourse community

The feature

Vite is the new standard for dev server and build system.

I'm sure its a big lift, but this request is to migrate from Webpack to Vite.

Use case

This feature will improve developer experience and speed.

Notes

No response

[patrickdorival]

This would see a huge improvement to performance while reducing complexity

[kellymears]

This doesn't really make sense. bud.js wraps webpack; vite wraps rollup.js. Are you asking for bud.js to wrap rollup as vite does? I'm not going to write that implementation but it's possible to do that and release it as a replacement for the bud.compiler service. bud.js wrapping vite is one wrapper over the line, for me.

If it's not about rollup v. webpack then is it a preference for esbuild > babel? If you install @roots/bud-esbuild or @roots/bud-swc they will be preferred (even if babel is bundled in another extension, lke @roots/sage).

And, if it's for the API -- why not just use vite directly?

In the end, I think the real world gains for this overhaul are negligible. I'm thinking on average 1-2 seconds for an initial compilation (because vite is configured to do it on-the-fly, while webpack handles it upfront and then caches the results). Dev builds might speed up by a couple hundred ms in a large project?

The work will be thankless and in six months time someone will ask why you didn't just do it with turbopack. Meanwhile, most users will still be spending 90% of their time waiting on sass and sharp to finish.

[acalvino4]

As I understand it, Roots exists to provide an ecosystem for making it possible and easy to follow development best practices while developing wordpress sites. Bud fits into this ecosystem by easing the integration of what has been the standard build/dev tool (webpack) for years. Nowdays, Vite is largely recognized as the best build tool for most web projects (if you haven't already read it, check out why vite and vite features understand the improvements it makes before dismissing the idea). Combining these two reasons, I and many others would conclude that the roots ecosystem should include a tool to wrap vite.

As such this feature request would be for bud to wrap vite instead of wrapping webpack. It is possible this amounts to just developing a completely new tool/wrapper, and that this would better be thought of as a new project than as a feature request for this one.

To answer a couple points you made.

• "90% of their time waiting on sass" - It's hard to gather an exact percentage, but a lot of new projects are using tailwind these days, which builds in under a half second with the new JIT mode, so it works perfectly with vite's live reload. The tool would still of course need to support other people, but ideally would give the large sector of people using modern tooling such as tailwind to have live reload.
• "in six months time someone will ask why you didn't just do it with turbopack" - valid concern, as the js ecosystem moves fast. However, this can't mean we never update tooling or libraries used. In this particular case turbopack doesn't add nearly as much as they advertised they do, and there are some independent blogs and benchmarks demonstrating as much. Turbopack is not to be ignored, and I think we could be totally open to discussing it as an option, but the fact that multiple options exists doesn't mean we should never evaluate our choices and at least ask the question of whether there is a benefit to be gained (again, refer to "why vite" article to understand the benefits for my proposal)

At the very least I think we should just see how many upvotes this post gets to gauge interest in the feature.

[retlehs]

There's quite a bit of pros and cons for the webpack vs Vite argument. One of the biggest advantages for using webpack is that the ecosystem is much more mature — there's a larger community, more libs/plugins available, and due to it's age, there's an incomparable amount of resources available.

Nowdays, Vite is largely recognized as the best build tool for most web projects

I don't think anyone would doubt that Vite has the most hype right now. Saying it's the best seems a bit much. There's not really any facts or proof to back up that claim. Providing links to Vite's features/docs don't help your argument.

It's hard to gather an exact percentage, but a lot of new projects are using tailwind these days

Absolutely. There's also still a lot of folks using Sass these days. I don't use it anymore, but it's still widely used in our community.

However, this can't mean we never update tooling or libraries used.

I don't think that's what @kellymears was implying.

In this particular case turbopack doesn't add nearly as much as they advertised they do, and there are some independent blogs and benchmarks demonstrating as much.

Based on the benchmarks that folks in the JS community have been doing lately, Vite isn't as fast as Turbopack or Parcel.

[acalvino4]

webpack ... is much more mature

Absolutely. For complex configurations it may be necessary, but for the 90% use case vite does the job and is much easier to configure. If bud requires those complex configurations, then maybe it is a conversation for later when vite (or turbopack) is more mature. But I think there should be a conversation.

Providing links to Vite's features/docs don't help your argument.

If was just a quick reference in case anyone wasn't familiar. As such I think it does make an argument to someone who is unaware. If you are all familiar with vite already, so much the better.

Vite isn't as fast as Turbopack or Parcel

I don't disagree with that, and am totally open to turbopack or parcel. My point was more that the 10x improvements advertised in some vercel posts was a combination of biased rounding and very specific configurations/use cases. This, in the end, makes the speed improvement from webpack to vite a big desire, but the improvement from vite to turbopack negligible to me.

Again, I just want to start a conversation, gather feedback from other users, and see how desired a migration from webpack might be. Perhaps this would best be retitled as "Consider webpack alternatives such as vite and turbopack"

[retlehs]

Are you a Sage user? If so, you should be using whatever build tool that you prefer — it's a starter theme. No one is forcing you to use bud.js.

bud.js absolutely considers webpack alternatives, and will continue to evaluate the alternatives as they mature over time. @kellymears and I have spoken about this countless times, including recently while there's been discussions surrounding create-react-app that have been fueled by certain folks on Twitter.

Again:

One of the biggest advantages for using webpack is that the ecosystem is much more mature — there's a larger community, more libs/plugins available, and due to it's age, there's an incomparable amount of resources available.

At this time, we will not be making any changes. I'd like to also point out that this is not something that is going to be decided by the users of bud.js, it is going to be decided by the maintainers of bud.js based on the moves that the JS ecosystem makes.

[acalvino4]

this is not something that is going to be decided by the users of bud.js, it is going to be decided by the maintainers of bud.js

Of course, just as decisions for any project are made by the maintainers. For good libraries those decisions are also made with user feedback. This was the best place I knew of to submit such feedback, and I think the place many others go as well.

[retlehs]

My apologies for being a bit harsh. The second commenter on this issue was banned from our forum today after saying several incredibly rude things specifically targeted at the author of this library.

[kellymears]

Yeah, sorry if I came off as dismissive.

To contextualize: I work as a developer on a pretty large app built with vite and am familiar with it in that capacity. I've enjoyed using it. And, bud.js uses vitest because of vite's first class support for esmodules. Vitest is 300% slower than jest but it works really well and has saved me more time than I've lost for sure.

Ultimately, I wouldn't begrudge anyone for using vite over bud.js to build their app. I also maintain that:

• vite is not a replacement for webpack. It is a build tool that uses rollup instead of webpack.
• bud.js wrapping vite is unnecessary. you can just use vite!
• In other words, the issue presupposes vite is a lower-level tool than bud.js. But, I think they are actually different tools that do the same thing:
  • [choice of transpiler] => webpack => bud.js => project
  • esbuild => rollup => vite => project

If this issue was about bud.js using rollup instead of webpack I wouldn't have closed it. If this issue was about bud.js somehow exhibiting a preference for babel over esbuild I wouldn't have closed it. If this issue was about finding a way to replicate vite's method of hot module reloading in @roots/bud-server/@roots/bud-client I wouldn't have closed it.

But, I think the specific suggestion is not actionable as it stands for the reasons outlined above.

[acalvino4]

Thanks, I appreciate hearing the rationale.