Hacker News new | ask | show | jobs
by sod 850 days ago
Vite and webpack (and thus turbopack, which is advertised as a webpack successor) are two different beasts.

While vite is perfect for most users, there are just some usecases that are not doable with meaningful performance. Without boring you with details why, let me assure you that having a performant webpack replacement for those 10% who need it, helps vite staying lean, as they are not bothered with feature creep.

If you want a small detail why: Vite is built on esbuild. Esbuild is carried by a single developer (https://github.com/evanw/esbuild/graphs/contributors) thus every nut and bolt that vite does for you on top is built in javascript, so you are in slow-land again.

webpack and turbopacks promise (and complexity) is that it treats these extras (plugins and loaders) as first class citizens and thus tries to make them as fast as possible by applying tons of caching. E.g. if you'd throw a webpack workflow at vite, you might end up with a slower build then webpack. And this is where turbopack tries to improve.

2 comments

    > Esbuild is carried by a single developer 
The right answer is to support that developer and contribute to the project.

The VC answer is to build something entirely novel and then fail to deliver.

They did exactly that. Just not esbuild.

They sponser https://github.com/kdy1 (see the vercel in his profile), who spearheads swc, which is very similar in goals and scope to esbuild. swc may ring a bell, as it's the parser/compiler that is used by deno and bun.

Deno uses swc, but Bun does not, it uses its own parser/transpiler written in zig.

Source: check the language breakdown on zig's repo: 0% rust (what swc is written in).

LOL. One best a replies I’ve read in HN in a long time.
You can swap esbuild out for swc in vite and get whatever swc plugins you need. There's not a ton available, but more then enough for my needs at least.