[root_axis]

I downvoted it. I did so because, IMO, the comment is superfluous noise seen on every js thread. A tool exists to solve a problem, if you don't understand why it was built or don't like it, that's ok, but the hackneyed complaining about open source software merely existing deserves to be at the bottom of the thread.

[SOLAR_FIELDS]

I'm not the grandparent poster but I'll ask the question in a non-superflous way:

Is this actually better than Webpack and esbuild/Parcel/Rollup/whatever that came before it? Or is it just another opinionated way of packaging stuff up that's faster because it doesn't support 10% of the feature set the other tools do yet?

Looking at the "Why Vite" page, most of the blurbs are basically saying "Existing tools are slow". Well, I bet those existing tools are probably capable of doing 10x of what Vite can do currently. And how much faster IS Vite when bundling a large project? Nothing on that, only some charts with lines saying that they do it differently. They say 10-100x speedup on "prebundling", but if that part of the build is only a small portion of the overall build it might be negligible. Also, they say it's faster because Go. Well I kind of like the dogfooding of all the build tools for JS being written in JS - why introduce a whole new ecosystem here?

Not trying to be a naysayer here, I'm just asking why mindshare should be devoted to yet another project that looks like reinvention of the wheel and starting the cycle anew again when we could instead contribute mindshare to existing mature projects - the reasoning given on the site doesn't seem to be very compelling.

[doomroot]

The reason frontend dev moves "So quickly" is because of new browser developments & capabilities. Esbuild & vite are currently popular because they are one of the first build tools to fully utilize browser ES Modules. This is fundamentally different than what webpack does. Webpack was solving a Pre-ESM problem, "how do we modularize frontend code?" and as such as taken on a lot of bloat to solve this problem which has largely been solved by browser ESM.

[cercatrova]

> Well I kind of like the dogfooding of all the build tools for JS being written in JS - why introduce a whole new ecosystem here?

You might find this answer helpful, about Rome which is like Vite but in Rust rather than Go [0], crucially:

> This justification -- Rome should be written in JS otherwise Rome users are less likely to contribute -- irresponsibly focuses on a secondary goal of the project, at the cost of the primary goal, which is to be a end-to-end toolchain for one of the most popular languages in the world.

Speed matters. It is not a sideline consideration, it should be one of the main considerations, over and above a tool being in the same language. In fact, many say that rewriting JS tools in non-JS faster languages will be the future [1].

[0] https://news.ycombinator.com/item?id=28609474

[1] https://leerob.io/blog/rust#the-future-of-javascript-tooling (https://news.ycombinator.com/item?id=29192088)

[SOLAR_FIELDS]

I think it's a fair argument but I guess time will play it out to see if it succeeds. It's a bit of a chicken and egg thing, like with most newer open source projects intended to replace older ones. To take off, you need contributors. If you can't get contributors, it won't take off. The value add needs to be strong enough to attract enough developers to overcome the Rust/Go hurdle. I'd wager more on Go in this regard, for your average developer not having to worry about garbage collection is probably going to be a significant plus.

[EarthLaunch]

It is better. Why are so many people determined to dismiss it on the basis that "things are so bad that we shouldn't try anything new"? That's totally backwards. In a situation of many bad alternatives, searching for new alternatives is the solution, not the problem.

Complaining about bad frontend tooling would be more appropriate to do in a thread that's not about a tool that practically solves it.

Instead of complaining about other tools, these people who don't know what Vite is should be curious and asking what it is, or what it has that's new. That is easy to find out.

> Well, I bet those existing tools are probably capable of doing 10x of what Vite can do currently.

Good luck with your bet.

[SOLAR_FIELDS]

I'm not against new tools, we should absolutely embrace innovation. But show me how it's better, don't just make some claims with no evidence and expect me to buy into it.

[tonetheman]

It is not superfluous noise. It is js sadly.

Js is an ever changing mass of stuff. I feel bad for frontend guys for this reason. Always writing for a language that does not even exist... always changing how you shove it all together.

Even worse as soon as you put a foot down and pick something you are behind.

It is exhausting even to watch much less to be in it.