Is Turbopack really 10x faster than Vite?

Glad to see that Evan You has stepped up with a response. When these 10x improvements were presented without a release of the benchmark code I was very sceptical. Vercel, do better! You champion yourself as a leader in the OSS React ecosystem, so please act accordingly. This has eroded my trust and excitement for your products.

"There were number rounding issues in the original numbers for the 1k component case - Turbopack's 15ms was rounded down to 0.01s while Vite's 87ms was rounded up to 0.09s. This further got marketed as a 10x advantage when the original numbers were close to 6x."

It happens again and again, never believe benchmarks by original author&#x2F;owner. They are misleading in most cases.<p>Deno vs bun was same case, each showed their runtime as faster

My concern with NextJS is that they aim to do work that&#x27;s good for Vercel and not for developers. That&#x27;s why we see such a push for faster build times while severally restricting flexibility of the framework, so they can save money on VMs running user&#x27;s builds.

I wonder if we reached the point these new changes aren&#x27;t actually practical any more.<p>Like most of the nextjs 13 changes seem like a lot of extra work for not much benefit.

The negative perception of Vercel in these comments is surprising to me. I&#x27;m not very familiar with them but was about to take my first dive, as I had been on Netlify but Vercel seems to offer much more functionality.<p>Honest question - can anyone ELI5 why I should avoid them? The only concrete things I have seen are &quot;they&#x27;re exaggerating the 10x figure&quot;, and &quot;they collect metrics and it&#x27;s hard to turn it off&quot;. Both aren&#x27;t great, but seems an overreach at first glance to avoid them for those reasons.

&gt;The Vite implementation is still using the default, Babel-based React plugin.<p>What do you mean &quot;still&quot;? Everyone setting up Vite is supposed to NOT use the default configuration?

The frontend tooling debacle has got to the point where I&#x27;m not only leaving frontend development, but tech entirely. To not have to think about this endless nonsense anymore is such a massive weight off my shoulders.

vercel is a startup that strangely wants to monopolize the open source ecosystem. this is a really big different paradox. they will probably do in other libraries what they did for react ecosystem. but i&#x27;m not sure what good it does to anyone other than themselves.

&gt; Turbopack&#x27;s 15ms was rounded down to 0.01s while Vite&#x27;s 87ms was rounded up to 0.09s. This further got marketed as a 10x advantage when the original numbers were close to 6x.<p>Do any developers actually care&#x2F;notice this level of HMR delta anyway, whether it&#x27;s 80ms or 72ms? Is it really important for a HMR to be 80ms faster?

“You either die a hero, or live long enough to become the villain”

TLDR: Vercel team agressively shat on Vite devs just for $$$. Come on Vercel team, that was unnecessary.

Another reason to avoid NextJS or Vercel. Especially as there are much better products by more honest companies available.

Sorry for OT but am I the only one who hates this new &quot;X times faster&quot; or &quot;X times less than&quot; wording that has started to appear recently? I get that &quot;finishes in 1&#x2F;10th the time&quot; is a little clunky, but &quot;ten times faster&quot; is both wrong <i>and</i> awkward sounding.

Vercel and the VC money they generated is probably one of the worst things to happen to FE OSS. I avoid next like the plague.<p>To make matters worse, now the react and next teams are actively colluding with each other, effectively allowing vercel to have a competitive advantage on feature development for react.<p>It might seem great now but this is the hairline crack that will destroy the react ecosystem.<p>I wouldn’t be surprised if vercel tries to buy react and its team.