13 ms·

Is Turbopack really 10x faster than Vite?

364 points by jjzhiyuan 4y ago

MalseMattie 4y ago
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.
- tipiirai 4y ago
  Same here. Vercel have always felt super commercial. Now even more. Hard to trust someone who puts so much money and effort to marketing and hyperbole.
  - MalseMattie 4y ago
    I feel conflicted, because the deep dive[0] into turbopack after all these misleading claims still has me excited for the future. The suggestion that JS bundling is very similar to native linking[1] on a previous thread has convinced me that the incremental execution strategy turbopack has chosen is the way forward. [0] https://www.youtube.com/watch?v=btqdaqEHw0A https://www.youtube.com/watch?v=btqdaqEHw0A [1] https://news.ycombinator.com/item?id=33334091 https://news.ycombinator.com/item?id=33334091
    - deleted 4y ago
      [deleted]
  - ostenning 4y ago
    When watching the Next.js Keynote it really felt as if I were watching an Apple keynote..
- anonyfox 4y ago
  I recently tried to deploy a next JS app to aws lambda and gave up after a few days. JS Framework that doesn’t support serverless (aside from the sponsoring company‘s walled garden) - won’t fly with me in charge for infra.
  - roci89 4y ago
    Give Remix a spin. I've deployed it to Lambda, Cloudflare Workers, & a long running express server. It's great
    - DoesntMatter22 4y ago
      Remix deploys to lambda wow
  - georgyo 4y ago
    You may like Sveltekit, it has adapters to be deployed lots of places! With the ability to write new adapters easily. https://kit.svelte.dev/docs/adapters https://kit.svelte.dev/docs/adapters https://github.com/yarbsemaj/sveltekit-adapter-lambda https://github.com/yarbsemaj/sveltekit-adapter-lambda
  - rhodysurf 4y ago
    I use it with google cloud run and its smooth as hell
  - cechmaster 4y ago
    I've deployed with this before on AWS without too many issues https://github.com/serverless-nextjs/serverless-next.js https://github.com/serverless-nextjs/serverless-next.js
  - pier25 4y ago
    Next definitely supports serverless. If you deploy a Next app to Vercel it will get deployed to AWS Lambda.
- mhoad 4y ago
  Vercel give me nothing but very suspect vibes. I don’t know what it is exactly but reminds me a lot of the cryptocurrency crowd.
  - deleted 4y ago
    [deleted]
  - begueradj 4y ago
    Vercel is like Youtube influencers
    - 411111111111111 4y ago
      It's still baffling to me that a profession called influencer can exist. How do people take anything from them serious when their job description is literally taking money in order to influence people... I guess that's just our society. We love to be told what we should feel/do/care about on a societal level, so people gobble it up even if the content is obviously just paid marketing
      - rjzzleep 4y ago
        It just tells you how broken the understanding of value in current society really is. When someone posting videos of themselves testing lipstick or 10 dollar dresses makes more money than dozens highly trained real engineers that build physical goods necessary for the betterment of society and the world as a whole, it does in fact explain, to some extent, why we have a child book author running the entirety of hard work of generations of people that built the German industry into the ground.
        cercatrova 4y ago
        The labor theory of value is not real, only the subjective theory of value is. People pay for what they like. Who are you to judge why people shouldn't value others testing lipstick over some engineers?
- lagrange77 4y ago
  Same here. I'm very happy with https://github.com/brillout/vite-plugin-ssr https://github.com/brillout/vite-plugin-ssr
  - simlevesque 4y ago
    This is some good stuff. Such a simple solution to a complex problem.
- brundolf 4y ago
  They make good tech, but their marketing department manages to over-sell it anyway, which makes it hard for me to take anything they say at face value. It's a bummer they can't just let the technology stand on its own merits. They should know that engineers won't respond well to hand-wavy or exaggerated marketing.
  - deleted 4y ago
    [deleted]
rs_rs_rs_rs_rs 4y ago
>The Vite implementation is still using the default, Babel-based React plugin. What do you mean "still"? Everyone setting up Vite is supposed to NOT use the default configuration?
- tommiegannert 4y ago
  The argument is that the Turbopack run had favorable non-default settings while the Vite run did not. Remember the context of your quote: > After reading the post and benchmark code, here are a few key takeaways: 1. The Vite implementation is still using the default, Babel-based React plugin. I.e. the "still", refers to the config used in Vercel's original benchmark. Since they had tweaked the Turbopack React config, yes, this is noteworthy. Whether this was ignorance about Vite (i.e. making a straw-man argument) or malice, we don't know. Since Vercel did publish their config, assuming ignorance is enough for me. My own conclusion was that defaults are tradeoffs, and that tweaking them can improve some aspect (performance) while negatively affecting another (disk space): >> The reason Vite currently defaults to Babel was a trade-off between install size and practicality. SWC's install size is quite heavy (58MB in node_modules whereas Vite itself is only 19MB), and many users still relied on Babel for other transforms, so a Babel pass was somewhat inevitable for them. However, that may change in the future.
  - Semaphor 4y ago
    > Since they had tweaked the Turbopack React config, yes, this is noteworthy. Did they? My understanding is, that Turbopack uses SWC by default. So without at least a confirmed intent to change the default on Vite’s part, I feel like that choice is valid (though it should be explicitly mentioned).
    - tommiegannert 4y ago
      The tweaking/optimization they did was about the RSC vs not, which Evan says drastically changes the outcome, the same way switching Vite to SWC would have. I don't think he suggests that Turbopack was tweaked regarding SWC. It looks like they cherry-picked a configuration pair that made Turbopack look better than what you would get if you either just followed defaults/beginner settings for both, or you optimized both.
smcl 4y ago
Sorry for OT but am I the only one who hates this new "X times faster" or "X times less than" wording that has started to appear recently? I get that "finishes in 1/10th the time" is a little clunky, but "ten times faster" is both wrong and awkward sounding.
- scapp 4y ago
  I don't see the problem. For example, if something finishes in 10 minutes, it has 6 completions per hour. If a competitor finishes in 1 minute, it has 60 completions per hour. It both finishes in 1/10 of the time (time per completion) and is 10 times faster (completions in a given amount of time). If you don't like the unit "completions per hour", consider that you don't have to drive for an hour or even go a mile to go 60 miles per hour.
  - smcl 4y ago
    That's actually a nice way to look at it, and helped me see why and in what cases I dislike this phraseology - I couldn't really articulate this before. So I think my issue is presenting something in time-units per action and talking about an optimisation of it as multiples of actions per time-unit faster. I hate it a little less now :)
    - mort96 4y ago
      Well, speed is distance/time. For the "speed" analogy to make sense when talking about performance, we have to translate "distance" to something more abstract, let's call it "work". That means we have speed = work/time. If you have 1 unit of work (say you think of "build the whole app" as one atomic operation) which used to take 20 seconds, and now it takes 2 seconds, you went from a speed of 1/20=0.05 to a speed of 1/2=0.5, which is a 10x increase. Hence, "it's 10x faster" is a valid way to write "it does the same work in 1/10 the time".
      - smcl 4y ago
        Yeah I get it - it just feels a bit clumsy to use the flipped units when summarising the optimisation. Just a personal taste thing though. I still think "X times less than" can GTFO though - as in 10,000 is "seven times less than" 70,000 - which is the kind of thing I'm seeing more recently. That wasn't mentioned in the article though, it was maybe a bit unfair to lump them together.
KingOfCoders 4y ago
"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."
- EastSmith 4y ago
  What an actual marketing BS is this?
  - Jasper_ 4y ago
    Sigfig manipulation is one of the oldest tricks in the "lying with numbers" book. It's usually a very stupid idea because most laymen can see the swindle once pointed out, let alone engineers (Vercel's target market). No clue who signed off on this marketing but they just outed themselves as untrustworthy to a whole segment now. What a stupid move...
    - deleted 4y ago
      [deleted]
- bdlowery 4y ago
  So it’s still faster, just not as fast as they make it seem.
  - KingOfCoders 4y ago
    No.
  - endorphine 4y ago
    That's not the point though. Read the sibling comments.
    - Kiro 4y ago
      What is the point?
joshxyz 4y ago
TLDR: Vercel team agressively shat on Vite devs just for $$$. Come on Vercel team, that was unnecessary.
qudat 4y ago
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. 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. It might seem great now but this is the hairline crack that will destroy the react ecosystem. I wouldn’t be surprised if vercel tries to buy react and its team.
- 0xblinq 4y ago
  Vercel is an evil company in disguise. I’ve understood this and stopped using Next with all the enabled by default and intentionally difficult to disable metrics collection system they have in Next. Having it enabled by default, without asking is already evil enough. Refusing to have a setting you can easily commit into the repository to turn it off is next level. They trick people with the “just set this env var” to turn it off, and rely on people doing it wrong, forgetting to do it in certain environments, etc. it’s intentionally complicated, when a frigging Boolean setting in next.config.is would be better. They refuse to do it. That’s what evil companies do.
  - Dork1234 4y ago
    So which framework should you use? It is easy to say XYZ is bad, but what do you use instead, ASP.NET?
    - o_m 4y ago
      Laravel looks like the most mature fullstack framework. .NET and Java might be nicer on the backend, but they are a decade behind the competition on the frontend. The javascript community doesn't seem to want a fullstack CRUD framework, the consensus seem to be that every project should make its own ad hoc framework, like the PHP community did 10+ years ago. This resulted in a lot of spaghetti code, and javascript, even with their advanced libraries, isn't much better. The downside of not betting on javascript is that "everyone" knows javascript by now.
langsoul-com 4y ago
I wonder if we reached the point these new changes aren't actually practical any more. Like most of the nextjs 13 changes seem like a lot of extra work for not much benefit.
- therusskiy 4y ago
  Next being owned by Vercel has a perverse incentice to push for features that are good for Vercel, like fast build times and very specific caching strategies, not for the features that developers actually want.
  - cercatrova 4y ago
    I want those. Why would devs not want fast build times and incremental compilation through caching?
    - M4v3R 4y ago
      Same. I worked with a Vue 2 project that had cold start time of almost 2 minutes (and ~25s hot start after enabling hardSource plugin in Webpack), and each hot-module reload would take 10+ seconds. It was a real pain to work with. Having build times that are on the order of magnitude faster can really improve the developer experience and the way you work with code.
    - langsoul-com 4y ago
      At this point, vite is pretty damned good and doesn't warrant a replacement. From the article, the 10x improvement was more 6x and required 30k modules... Turbopack's 15ms was rounded down to 0.01s while Vite's 87ms was rounded up to 0.09s. isn't Android build level slow.
      - cercatrova 4y ago
        There's always room for performance. I want to use the full capacity of the hardware I bought, why would I intentionally use a slower tool, however slight the difference (all else being equal)? Aside, this kind of "good enough" attitude is what brought us the JS bundle behemoths, and abstractions on top of abstractions. Even if the difference is small, it adds up if everyone thinks that the performance of their one little library is just "good enough."
akmittal 4y ago
It happens again and again, never believe benchmarks by original author/owner. They are misleading in most cases. Deno vs bun was same case, each showed their runtime as faster
- franciscop 4y ago
  Nah, read a bit of the Deno vs Bun thing and it's pretty clear. Bun said that Bun was way faster (on 1 thread), and it is. But Deno were butt-hurt for these claims and said they were way faster (in 2-4 threads, vs Bun's 1 thread), and they are. But that's a ridiculous comparison for multiple reason: - Bun does recognize they don't have multi-processor yet, so yeah cannot compare that (remember it's still alpha software!). So they compared what they had so far with a similar setup in Deno, pretty fair for that stage IMHO! - In real-life you'd have either 1 thread for smaller apps, or setup a proxy with multiple instances if the program was single-threaded, so the comparison Deno made was in no way realistic.
  - pier25 4y ago
    > or setup a proxy with multiple instances if the program was single-threaded Not having to do that is quite an advantage for Deno though regardless of the perf claims.
  - pierrebai 4y ago
    You are claiming that if your product A does not have feature X that could make it faster, it is okay to claim that your product A is faster than product B by hampering B under the impediment of not using X? "My database A is is faster than B! (When B is not using indexes, because my database A does not have indexes, so it would be unfair to let B uses indexes..." is the equivalent here.
    - franciscop 4y ago
      Oh cmon no I'm not at all. I'm saying: "I'm building a new product. It's half-way there, but so far I've finished single-threaded processing! Look, at single-thread it's faster than anything else by a large margin". That's it. Indexes in a DB are like the main thing to do, while many/most servers that are run online are still single-threaded, so not a good comparison.
swe_dima 4y ago
My concern with NextJS is that they aim to do work that's good for Vercel and not for developers. That'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's builds.
- geewee 4y ago
  This seems sorta weird to me. Do you as a developer not enjoy having faster builds? I sure do.
  - CharlieDigital 4y ago
    The problem is that particular type of slippery slope mindset. What if some next big change doesn't align with the best interest of the community? You can see some future parallel to Microsoft and the `dotnet watch` debacle[0] where the dotnet team introduced a feature to allow hot reload then some executive neutered it except for Visual Studio because "it wasn't stable yet". No one will know the true reasons why it was pulled (and then re-released after community outcry), but it left a sour taste in the community. And in the case of Microsoft, I think they have even smaller incentives to pull this kind of stuff (VS is a very tiny, tiny portion of their revenue compared to Azure and Office) whereas Vercel is much more tightly bound to Next.js so it seems inevitable that there will be a point in time when Vercel's interests comes to loggerheads with the community's best interest. It may seem far-fetched right now, but all you need to do is look at the HTML source for Target.com and Walmart.com and see how a corporation has created tremendous leverage under the guise of OSS. The obvious outcome is to use that leverage at some point in the future to extract capital. The fact that they built something novel instead of embracing an already really good community solution (Vite) smacks of creating leverage in the same way that Apple has been empowered by their walled garden platform ownership. I trust Evan You far, far more than I do Vercel to make decisions in the interest of the community. [0] https://dotnetcoretutorials.com/2021/10/23/the-hot-reload-debacle/ https://dotnetcoretutorials.com/2021/10/23/the-hot-reload-de...
  - bryanrasmussen 4y ago
    depends, if like say one build is 3 seconds and the other build is 1 second, I prefer the 1 second, but if it turns out that the 3 second build is more easily debuggable and understandable then I would gladly sacrifice 2 seconds. If one build is .75 of a second and the other build is 1.5 seconds I probably wouldn't consider the .75 of a second a significant improvement because I would probably not gain anything from the slight improvement. I'm sure you can construct lots of other examples whereby one my prefer a less faster build over a faster build or just feel that it was not actually important either way.
trhoad 4y ago
The frontend tooling debacle has got to the point where I'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.
- agumonkey 4y ago
  What field are you going to ?
- halfmatthalfcat 4y ago
  No one is forcing you to listen to or even use these tools. You are causing your own stress here.
  - dmix 4y ago
    And both of these tools are basically drop in replacements for each other with very little configuration. This blog post is saying the performance difference is negligible. So I guess it’s bad that instead of radically different configs and performance of Webpack vs Rollup vs Parcel vs etc, compared to the future of choosing between a much more mature build tool market with Vite and Turbopack is a bad thing?
  - zmxz 4y ago
    Amazing, you helped the person in question with a single sentence. I can feel their stress disappearing. Mere fact that we're at the point where we have transpiler upon transpiler upon transpiler, where "wRiTtEn iN rUsT" is used as quality/performance control, where people throw term performance around as if it's a hot potato and no one mentions environments/hardware and actual real world use scenarios and where apparently everyone are building World of Warcraft scale apps in frontend is what's making a mockery out of entire frontend world. It's no wonder that entry is difficult and that so many impostors are trying to build a name for themselves by producing yet another useless library that's gazillion times faster than the other useless library. Frontend is a joke because of self-proclaimed developers building tools which they themselves can't use or explain to wide audience and that causes negative feeling when one has to deal with frontend manure.
nicksiscoe 4y ago
“You either die a hero, or live long enough to become the villain”
danielvaughn 4y ago
The negative perception of Vercel in these comments is surprising to me. I'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. Honest question - can anyone ELI5 why I should avoid them? The only concrete things I have seen are "they're exaggerating the 10x figure", and "they collect metrics and it's hard to turn it off". Both aren't great, but seems an overreach at first glance to avoid them for those reasons.
- aniforprez 4y ago
  I think I'm of the same mentality. IMO a lot of the comments here are histrionics that they misrepresented (and outright lied in some cases) the gap in efficiency of their tool. But it's still somewhat better than the existing tooling. All of this also has very little to do with Vercel as a product which is still pretty good and can run almost anything without needing to use their framework NextJS. I don't use Vercel myself and am perfectly content with Netlify which does what I need and more but I don't think any of this dissuades me from using Vercel Vercel simply has a lot of VC funding and is using marketing to sell their tooling and their platform. It's not unique to them, nor is it particularly egregious especially when Evan You himself clearly admits Turbopack is, in fact, slightly more performant than Vite. They lied about some benchmarks. Very dumb of them. I will move on and will not really avoid Vercel unless I have much more immediate concerns like their pricing or other ethics concerns that have more drastic effects
  - apineda 4y ago
    I guess what irks people is when a big dog tries to gain "market share" with half truths, which may perhaps unjustly and negatively affect highly regarded open source efforts. I get that it sounds good though, better than "6% faster at the 30k module threshold".
- brundolf 4y ago
  You don't need to avoid them (at least their OSS projects). They mostly make good stuff. They just have an overzealous marketing department that clouds the waters, so wait for a second opinion on any claims they make.
jrochkind1 4y ago
> 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. Do any developers actually care/notice this level of HMR delta anyway, whether it's 80ms or 72ms? Is it really important for a HMR to be 80ms faster?
- 0xCAP 4y ago
  Yeah, the whole thing was totally uncalled for IMHO. I couldn't care less about HMR speed atm, when there are far worse plagues infesting the ecosystem.
newbieuser 4y ago
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'm not sure what good it does to anyone other than themselves.
leo_s_makes 4y ago
Another reason to avoid NextJS or Vercel. Especially as there are much better products by more honest companies available.

364 points by jjzhiyuan 4y ago

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.

tipiirai 4y ago
Same here. Vercel have always felt super commercial. Now even more. Hard to trust someone who puts so much money and effort to marketing and hyperbole.
- MalseMattie 4y ago
  I feel conflicted, because the deep dive[0] into turbopack after all these misleading claims still has me excited for the future. The suggestion that JS bundling is very similar to native linking[1] on a previous thread has convinced me that the incremental execution strategy turbopack has chosen is the way forward. [0] https://www.youtube.com/watch?v=btqdaqEHw0A https://www.youtube.com/watch?v=btqdaqEHw0A [1] https://news.ycombinator.com/item?id=33334091 https://news.ycombinator.com/item?id=33334091
  - deleted 4y ago
    [deleted]
- ostenning 4y ago
  When watching the Next.js Keynote it really felt as if I were watching an Apple keynote..
anonyfox 4y ago
I recently tried to deploy a next JS app to aws lambda and gave up after a few days. JS Framework that doesn’t support serverless (aside from the sponsoring company‘s walled garden) - won’t fly with me in charge for infra.
- roci89 4y ago
  Give Remix a spin. I've deployed it to Lambda, Cloudflare Workers, & a long running express server. It's great
  - DoesntMatter22 4y ago
    Remix deploys to lambda wow
- georgyo 4y ago
  You may like Sveltekit, it has adapters to be deployed lots of places! With the ability to write new adapters easily. https://kit.svelte.dev/docs/adapters https://kit.svelte.dev/docs/adapters https://github.com/yarbsemaj/sveltekit-adapter-lambda https://github.com/yarbsemaj/sveltekit-adapter-lambda
- rhodysurf 4y ago
  I use it with google cloud run and its smooth as hell
- cechmaster 4y ago
  I've deployed with this before on AWS without too many issues https://github.com/serverless-nextjs/serverless-next.js https://github.com/serverless-nextjs/serverless-next.js
- pier25 4y ago
  Next definitely supports serverless. If you deploy a Next app to Vercel it will get deployed to AWS Lambda.
mhoad 4y ago
Vercel give me nothing but very suspect vibes. I don’t know what it is exactly but reminds me a lot of the cryptocurrency crowd.
- deleted 4y ago
  [deleted]
- begueradj 4y ago
  Vercel is like Youtube influencers
  - 411111111111111 4y ago
    It's still baffling to me that a profession called influencer can exist. How do people take anything from them serious when their job description is literally taking money in order to influence people... I guess that's just our society. We love to be told what we should feel/do/care about on a societal level, so people gobble it up even if the content is obviously just paid marketing
    - rjzzleep 4y ago
      It just tells you how broken the understanding of value in current society really is. When someone posting videos of themselves testing lipstick or 10 dollar dresses makes more money than dozens highly trained real engineers that build physical goods necessary for the betterment of society and the world as a whole, it does in fact explain, to some extent, why we have a child book author running the entirety of hard work of generations of people that built the German industry into the ground.
      - cercatrova 4y ago
        The labor theory of value is not real, only the subjective theory of value is. People pay for what they like. Who are you to judge why people shouldn't value others testing lipstick over some engineers?
lagrange77 4y ago
Same here. I'm very happy with https://github.com/brillout/vite-plugin-ssr https://github.com/brillout/vite-plugin-ssr
- simlevesque 4y ago
  This is some good stuff. Such a simple solution to a complex problem.
brundolf 4y ago
They make good tech, but their marketing department manages to over-sell it anyway, which makes it hard for me to take anything they say at face value. It's a bummer they can't just let the technology stand on its own merits. They should know that engineers won't respond well to hand-wavy or exaggerated marketing.
- deleted 4y ago
  [deleted]

rs_rs_rs_rs_rs 4y ago

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

tommiegannert 4y ago
The argument is that the Turbopack run had favorable non-default settings while the Vite run did not. Remember the context of your quote: > After reading the post and benchmark code, here are a few key takeaways: 1. The Vite implementation is still using the default, Babel-based React plugin. I.e. the "still", refers to the config used in Vercel's original benchmark. Since they had tweaked the Turbopack React config, yes, this is noteworthy. Whether this was ignorance about Vite (i.e. making a straw-man argument) or malice, we don't know. Since Vercel did publish their config, assuming ignorance is enough for me. My own conclusion was that defaults are tradeoffs, and that tweaking them can improve some aspect (performance) while negatively affecting another (disk space): >> The reason Vite currently defaults to Babel was a trade-off between install size and practicality. SWC's install size is quite heavy (58MB in node_modules whereas Vite itself is only 19MB), and many users still relied on Babel for other transforms, so a Babel pass was somewhat inevitable for them. However, that may change in the future.
- Semaphor 4y ago
  > Since they had tweaked the Turbopack React config, yes, this is noteworthy. Did they? My understanding is, that Turbopack uses SWC by default. So without at least a confirmed intent to change the default on Vite’s part, I feel like that choice is valid (though it should be explicitly mentioned).
  - tommiegannert 4y ago
    The tweaking/optimization they did was about the RSC vs not, which Evan says drastically changes the outcome, the same way switching Vite to SWC would have. I don't think he suggests that Turbopack was tweaked regarding SWC. It looks like they cherry-picked a configuration pair that made Turbopack look better than what you would get if you either just followed defaults/beginner settings for both, or you optimized both.

smcl 4y ago

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

scapp 4y ago
I don't see the problem. For example, if something finishes in 10 minutes, it has 6 completions per hour. If a competitor finishes in 1 minute, it has 60 completions per hour. It both finishes in 1/10 of the time (time per completion) and is 10 times faster (completions in a given amount of time). If you don't like the unit "completions per hour", consider that you don't have to drive for an hour or even go a mile to go 60 miles per hour.
- smcl 4y ago
  That's actually a nice way to look at it, and helped me see why and in what cases I dislike this phraseology - I couldn't really articulate this before. So I think my issue is presenting something in time-units per action and talking about an optimisation of it as multiples of actions per time-unit faster. I hate it a little less now :)
  - mort96 4y ago
    Well, speed is distance/time. For the "speed" analogy to make sense when talking about performance, we have to translate "distance" to something more abstract, let's call it "work". That means we have speed = work/time. If you have 1 unit of work (say you think of "build the whole app" as one atomic operation) which used to take 20 seconds, and now it takes 2 seconds, you went from a speed of 1/20=0.05 to a speed of 1/2=0.5, which is a 10x increase. Hence, "it's 10x faster" is a valid way to write "it does the same work in 1/10 the time".
    - smcl 4y ago
      Yeah I get it - it just feels a bit clumsy to use the flipped units when summarising the optimisation. Just a personal taste thing though. I still think "X times less than" can GTFO though - as in 10,000 is "seven times less than" 70,000 - which is the kind of thing I'm seeing more recently. That wasn't mentioned in the article though, it was maybe a bit unfair to lump them together.

KingOfCoders 4y ago

"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."

EastSmith 4y ago
What an actual marketing BS is this?
- Jasper_ 4y ago
  Sigfig manipulation is one of the oldest tricks in the "lying with numbers" book. It's usually a very stupid idea because most laymen can see the swindle once pointed out, let alone engineers (Vercel's target market). No clue who signed off on this marketing but they just outed themselves as untrustworthy to a whole segment now. What a stupid move...
  - deleted 4y ago
    [deleted]
bdlowery 4y ago
So it’s still faster, just not as fast as they make it seem.
- KingOfCoders 4y ago
  No.
- endorphine 4y ago
  That's not the point though. Read the sibling comments.
  - Kiro 4y ago
    What is the point?

joshxyz 4y ago

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

qudat 4y ago

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. 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. It might seem great now but this is the hairline crack that will destroy the react ecosystem. I wouldn’t be surprised if vercel tries to buy react and its team.

0xblinq 4y ago
Vercel is an evil company in disguise. I’ve understood this and stopped using Next with all the enabled by default and intentionally difficult to disable metrics collection system they have in Next. Having it enabled by default, without asking is already evil enough. Refusing to have a setting you can easily commit into the repository to turn it off is next level. They trick people with the “just set this env var” to turn it off, and rely on people doing it wrong, forgetting to do it in certain environments, etc. it’s intentionally complicated, when a frigging Boolean setting in next.config.is would be better. They refuse to do it. That’s what evil companies do.
- Dork1234 4y ago
  So which framework should you use? It is easy to say XYZ is bad, but what do you use instead, ASP.NET?
  - o_m 4y ago
    Laravel looks like the most mature fullstack framework. .NET and Java might be nicer on the backend, but they are a decade behind the competition on the frontend. The javascript community doesn't seem to want a fullstack CRUD framework, the consensus seem to be that every project should make its own ad hoc framework, like the PHP community did 10+ years ago. This resulted in a lot of spaghetti code, and javascript, even with their advanced libraries, isn't much better. The downside of not betting on javascript is that "everyone" knows javascript by now.

langsoul-com 4y ago

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

therusskiy 4y ago
Next being owned by Vercel has a perverse incentice to push for features that are good for Vercel, like fast build times and very specific caching strategies, not for the features that developers actually want.
- cercatrova 4y ago
  I want those. Why would devs not want fast build times and incremental compilation through caching?
  - M4v3R 4y ago
    Same. I worked with a Vue 2 project that had cold start time of almost 2 minutes (and ~25s hot start after enabling hardSource plugin in Webpack), and each hot-module reload would take 10+ seconds. It was a real pain to work with. Having build times that are on the order of magnitude faster can really improve the developer experience and the way you work with code.
  - langsoul-com 4y ago
    At this point, vite is pretty damned good and doesn't warrant a replacement. From the article, the 10x improvement was more 6x and required 30k modules... Turbopack's 15ms was rounded down to 0.01s while Vite's 87ms was rounded up to 0.09s. isn't Android build level slow.
    - cercatrova 4y ago
      There's always room for performance. I want to use the full capacity of the hardware I bought, why would I intentionally use a slower tool, however slight the difference (all else being equal)? Aside, this kind of "good enough" attitude is what brought us the JS bundle behemoths, and abstractions on top of abstractions. Even if the difference is small, it adds up if everyone thinks that the performance of their one little library is just "good enough."

akmittal 4y ago

It happens again and again, never believe benchmarks by original author/owner. They are misleading in most cases. Deno vs bun was same case, each showed their runtime as faster

franciscop 4y ago
Nah, read a bit of the Deno vs Bun thing and it's pretty clear. Bun said that Bun was way faster (on 1 thread), and it is. But Deno were butt-hurt for these claims and said they were way faster (in 2-4 threads, vs Bun's 1 thread), and they are. But that's a ridiculous comparison for multiple reason: - Bun does recognize they don't have multi-processor yet, so yeah cannot compare that (remember it's still alpha software!). So they compared what they had so far with a similar setup in Deno, pretty fair for that stage IMHO! - In real-life you'd have either 1 thread for smaller apps, or setup a proxy with multiple instances if the program was single-threaded, so the comparison Deno made was in no way realistic.
- pier25 4y ago
  > or setup a proxy with multiple instances if the program was single-threaded Not having to do that is quite an advantage for Deno though regardless of the perf claims.
- pierrebai 4y ago
  You are claiming that if your product A does not have feature X that could make it faster, it is okay to claim that your product A is faster than product B by hampering B under the impediment of not using X? "My database A is is faster than B! (When B is not using indexes, because my database A does not have indexes, so it would be unfair to let B uses indexes..." is the equivalent here.
  - franciscop 4y ago
    Oh cmon no I'm not at all. I'm saying: "I'm building a new product. It's half-way there, but so far I've finished single-threaded processing! Look, at single-thread it's faster than anything else by a large margin". That's it. Indexes in a DB are like the main thing to do, while many/most servers that are run online are still single-threaded, so not a good comparison.

swe_dima 4y ago

My concern with NextJS is that they aim to do work that's good for Vercel and not for developers. That'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's builds.

geewee 4y ago
This seems sorta weird to me. Do you as a developer not enjoy having faster builds? I sure do.
- CharlieDigital 4y ago
  The problem is that particular type of slippery slope mindset. What if some next big change doesn't align with the best interest of the community? You can see some future parallel to Microsoft and the `dotnet watch` debacle[0] where the dotnet team introduced a feature to allow hot reload then some executive neutered it except for Visual Studio because "it wasn't stable yet". No one will know the true reasons why it was pulled (and then re-released after community outcry), but it left a sour taste in the community. And in the case of Microsoft, I think they have even smaller incentives to pull this kind of stuff (VS is a very tiny, tiny portion of their revenue compared to Azure and Office) whereas Vercel is much more tightly bound to Next.js so it seems inevitable that there will be a point in time when Vercel's interests comes to loggerheads with the community's best interest. It may seem far-fetched right now, but all you need to do is look at the HTML source for Target.com and Walmart.com and see how a corporation has created tremendous leverage under the guise of OSS. The obvious outcome is to use that leverage at some point in the future to extract capital. The fact that they built something novel instead of embracing an already really good community solution (Vite) smacks of creating leverage in the same way that Apple has been empowered by their walled garden platform ownership. I trust Evan You far, far more than I do Vercel to make decisions in the interest of the community. [0] https://dotnetcoretutorials.com/2021/10/23/the-hot-reload-debacle/ https://dotnetcoretutorials.com/2021/10/23/the-hot-reload-de...
- bryanrasmussen 4y ago
  depends, if like say one build is 3 seconds and the other build is 1 second, I prefer the 1 second, but if it turns out that the 3 second build is more easily debuggable and understandable then I would gladly sacrifice 2 seconds. If one build is .75 of a second and the other build is 1.5 seconds I probably wouldn't consider the .75 of a second a significant improvement because I would probably not gain anything from the slight improvement. I'm sure you can construct lots of other examples whereby one my prefer a less faster build over a faster build or just feel that it was not actually important either way.

trhoad 4y ago

The frontend tooling debacle has got to the point where I'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.

agumonkey 4y ago
What field are you going to ?
halfmatthalfcat 4y ago
No one is forcing you to listen to or even use these tools. You are causing your own stress here.
- dmix 4y ago
  And both of these tools are basically drop in replacements for each other with very little configuration. This blog post is saying the performance difference is negligible. So I guess it’s bad that instead of radically different configs and performance of Webpack vs Rollup vs Parcel vs etc, compared to the future of choosing between a much more mature build tool market with Vite and Turbopack is a bad thing?
- zmxz 4y ago
  Amazing, you helped the person in question with a single sentence. I can feel their stress disappearing. Mere fact that we're at the point where we have transpiler upon transpiler upon transpiler, where "wRiTtEn iN rUsT" is used as quality/performance control, where people throw term performance around as if it's a hot potato and no one mentions environments/hardware and actual real world use scenarios and where apparently everyone are building World of Warcraft scale apps in frontend is what's making a mockery out of entire frontend world. It's no wonder that entry is difficult and that so many impostors are trying to build a name for themselves by producing yet another useless library that's gazillion times faster than the other useless library. Frontend is a joke because of self-proclaimed developers building tools which they themselves can't use or explain to wide audience and that causes negative feeling when one has to deal with frontend manure.

nicksiscoe 4y ago

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

danielvaughn 4y ago

The negative perception of Vercel in these comments is surprising to me. I'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. Honest question - can anyone ELI5 why I should avoid them? The only concrete things I have seen are "they're exaggerating the 10x figure", and "they collect metrics and it's hard to turn it off". Both aren't great, but seems an overreach at first glance to avoid them for those reasons.

aniforprez 4y ago
I think I'm of the same mentality. IMO a lot of the comments here are histrionics that they misrepresented (and outright lied in some cases) the gap in efficiency of their tool. But it's still somewhat better than the existing tooling. All of this also has very little to do with Vercel as a product which is still pretty good and can run almost anything without needing to use their framework NextJS. I don't use Vercel myself and am perfectly content with Netlify which does what I need and more but I don't think any of this dissuades me from using Vercel Vercel simply has a lot of VC funding and is using marketing to sell their tooling and their platform. It's not unique to them, nor is it particularly egregious especially when Evan You himself clearly admits Turbopack is, in fact, slightly more performant than Vite. They lied about some benchmarks. Very dumb of them. I will move on and will not really avoid Vercel unless I have much more immediate concerns like their pricing or other ethics concerns that have more drastic effects
- apineda 4y ago
  I guess what irks people is when a big dog tries to gain "market share" with half truths, which may perhaps unjustly and negatively affect highly regarded open source efforts. I get that it sounds good though, better than "6% faster at the 30k module threshold".
brundolf 4y ago
You don't need to avoid them (at least their OSS projects). They mostly make good stuff. They just have an overzealous marketing department that clouds the waters, so wait for a second opinion on any claims they make.

jrochkind1 4y ago

> 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. Do any developers actually care/notice this level of HMR delta anyway, whether it's 80ms or 72ms? Is it really important for a HMR to be 80ms faster?

0xCAP 4y ago
Yeah, the whole thing was totally uncalled for IMHO. I couldn't care less about HMR speed atm, when there are far worse plagues infesting the ecosystem.

newbieuser 4y ago

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'm not sure what good it does to anyone other than themselves.

leo_s_makes 4y ago

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