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.
Is this way of showing, very similar to an Apple keynote in tone, form, timing, presentation, etc, that is really commercial, and we are a little used to (that's the vibe it's giving). Selling their products doing this 'keynotes' talking about new exciting stuff and 'performance' increase based on my ass metrics, just to build hype and fomo, for a JS framework, it just feels odd.
My main experience with their software is turborepo, which is IMO great. Don’t know much about their marketing or community, but turborepo is an excellent tool, much prefer it to nx and lerna (it’s main competitors).
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.
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.
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.
"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."
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...
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.
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.
I think you're underestimating the effort needed for parallelization here. Deno is written in a language that was built for "fearless concurrency" (Rust), whereas Bun is written in a language that barely has a concurrency story (Zig)
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.
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.
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.
Can you give examples of times NextJS was changed to solely benefit Vercel?
NextJS is an open-source framework under the MIT license, so if Vercel ever did anything to compromise NextJS, it could just be forked, but to my knowledge and experience with NextJS, they've provided and continue to provide an awesome framework/ecosystem around React.
Try deploying NextJS yourself over multiple instances, you are soon going to learn that cache NextJS provides isn't shared across them via something like Redis (I think it's mostly shared on Vercel, but I don't know how they do it).
Aside performance, this has consequences because of their stale-while-revalidate technique for static pages in incremental regeneration. If cache becomes obsolete on 1 instance and it's revalidate on the next request, it's not revalidated on other instances, so users accessing them are going to see stale data until that instance itself does revalidation. Having even a percentage of pages showing stale data can be painful for certain scenarios.
NextJS users been asking for more flexiable caching for some time.
I think it's a pretty good example.
As for forking it, how many companies have enough resources and are willing to go that distance?
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.
I just can't believe they went with the generically named "app" folder...
"pages" is such an obvious name indicating webpages go here. The new "app" directory is super ambiguous, might as well have named it the "code" folder...
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.
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.
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
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".
"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."
That is more than exaggeration, it's either incompetence or deceitful. They also did not even release a benchmark at first, and if you read Evan's writeup it could be argued the benchmark is not a fair comparison.
They are pushing the idea that they are doing revolutionary stuff when in actual fact they are copying existing projects that have been around for years:
Vercel is fantastic, they made a blunder, I guess. I don't really care. They're bringing JS tooling light-years past where it was originally. Webpack has needed to go away for the longest time, and Vercel might finally have done it by hiring Tobias. And it's objectively faster than Vite, not that I care.
Everyone is jumping on it, and accountability is good, but no reason to avoid Vercel.
You sound like you work for Vercel. Vercel is not the only company working on JS tooling and they are nowhere near replacing Webpack yet.
> And it's objectively faster than Vite, not that I care
From this submission:
"Since this is a composite benchmark that involves both Node.js and native Rust parts, there will be non-trivial variance on different hardware. The numbers I posted were gathered on my M1 MacBook Pro. Other users have run the same benchmark on different hardware and reported different results. In some cases Vite is faster in the root case, whereas in others Vite is significantly faster in both cases."
Right now, Vercel is making much ado about nothing.
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.
> 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).
Whether they are measuring "default" setup or optimised, both of the frameworks should follow same criteria.
Evan's criticism is that By default, Next use RSC(React server components) which is slower for HMR. in the benchmark, they disabled it for getting higher performance. At the same time, they are saying vite should use default setup for "fairness"
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.
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?
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.
Do you remember when we were stuck on Grunt? Options are good.
I wish you well in your new career as a professional sculptor but "the js ecosystem has too many options!" gets posted on every one of these threads with little specific relevance to the article at hand.
Are there companies that expect their developers to keep up with the latest developments so aggressively? At my job, things like Remix/Deno/Turbopack make the water-cooler conversations, but we only use established tools for projects. I think it would take several years for me to fall behind if I simply ignored new frameworks and tools.
I thought this too, working at a company mostly focused on jQuery/Rails as a foundation for a lot of the work I was doing.
I've been searching for a "full-stack" Web development job for the past 8 months this year, and aside from industry incompatibilities, the biggest headwind I'm facing finding an employer that recognizes front-end development is so much bigger than how you arrange your JavaScript to enable interactivity.
I have experience with React; my last career position allowed me to go from 0-100% confidence/competence with Svelte in 4 months. But employers want to see some equivalent of "3-5 years experience with React" and structure their shitty technical assessments similarly, and I've really had a problem trying to find the right way to show I'm just as qualified.
Build tools: when I interview candidates I ask them to explain what things like Webpack do. I don't care if they can write a config for it (but it's nice).
Runtimes: a lot of frontend JS engineers don't know what these are. Being able to explain them (and the difference between Node and Deno for ex) is a good answer. For backend jobs this is a hard requirement, but when I see "Node" in a frontend job listing I assume it means "can install packages from Node."
Frameworks: (like Next) it depends. If I'm hiring for an app already built in one, maybe. A general answer like "SSR is a problem with React" and "this framework solves that problem this way" is useful.
Readit News
Deleted Comment
Deleted Comment
[0] https://www.youtube.com/watch?v=btqdaqEHw0A [1] https://news.ycombinator.com/item?id=33334091
JS Framework that doesn’t support serverless (aside from the sponsoring company‘s walled garden) - won’t fly with me in charge for infra.
https://kit.svelte.dev/docs/adapters
https://github.com/yarbsemaj/sveltekit-adapter-lambda
I'm very happy with https://github.com/brillout/vite-plugin-ssr
No clue who signed off on this marketing but they just outed themselves as untrustworthy to a whole segment now. What a stupid move...
Deno vs bun was same case, each showed their runtime as faster
- 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.
"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.
Not having to do that is quite an advantage for Deno though regardless of the perf claims.
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-de...
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.
NextJS is an open-source framework under the MIT license, so if Vercel ever did anything to compromise NextJS, it could just be forked, but to my knowledge and experience with NextJS, they've provided and continue to provide an awesome framework/ecosystem around React.
Aside performance, this has consequences because of their stale-while-revalidate technique for static pages in incremental regeneration. If cache becomes obsolete on 1 instance and it's revalidate on the next request, it's not revalidated on other instances, so users accessing them are going to see stale data until that instance itself does revalidation. Having even a percentage of pages showing stale data can be painful for certain scenarios.
NextJS users been asking for more flexiable caching for some time.
I think it's a pretty good example.
As for forking it, how many companies have enough resources and are willing to go that distance?
Like most of the nextjs 13 changes seem like a lot of extra work for not much benefit.
"pages" is such an obvious name indicating webpages go here. The new "app" directory is super ambiguous, might as well have named it the "code" folder...
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.
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
From the submission:
"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."
That is more than exaggeration, it's either incompetence or deceitful. They also did not even release a benchmark at first, and if you read Evan's writeup it could be argued the benchmark is not a fair comparison.
They made a lot of noise about Next.js 13 when a lot of the new features are turbobroken. Ex: https://www.reddit.com/r/nextjs/comments/yj4r3q/migration_fr...
They are claiming turbopack is a webpack successor purely based off of having hired the creator of webpack: https://twitter.com/TheLarkInn/status/1584996270242148352.
They are pushing the idea that they are doing revolutionary stuff when in actual fact they are copying existing projects that have been around for years:
- turbopack using the same architecture as Parcel: https://twitter.com/devongovett/status/1585035737971724288
- "literally copy pasted Lage’s design and docs and branded it as Turborepo" https://twitter.com/jeffbcross/status/1583251710654283776
I strongly dislike the way they have gone about marketing their new tech.
Things like this also feel off: https://twitter.com/ascorbic/status/1585004156615479296
Everyone is jumping on it, and accountability is good, but no reason to avoid Vercel.
“Successors of webpack” is just more marketing as webpack isn’t going anywhere anytime soon.
Turbopack is just another packer among a sea of them.
> And it's objectively faster than Vite, not that I care
From this submission:
"Since this is a composite benchmark that involves both Node.js and native Rust parts, there will be non-trivial variance on different hardware. The numbers I posted were gathered on my M1 MacBook Pro. Other users have run the same benchmark on different hardware and reported different results. In some cases Vite is faster in the root case, whereas in others Vite is significantly faster in both cases."
Right now, Vercel is making much ado about nothing.
What do you mean "still"? Everyone setting up Vite is supposed to NOT use the default configuration?
> 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.
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).
Deleted Comment
Evan's criticism is that By default, Next use RSC(React server components) which is slower for HMR. in the benchmark, they disabled it for getting higher performance. At the same time, they are saying vite should use default setup for "fairness"
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?
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.
I wish you well in your new career as a professional sculptor but "the js ecosystem has too many options!" gets posted on every one of these threads with little specific relevance to the article at hand.
I've been searching for a "full-stack" Web development job for the past 8 months this year, and aside from industry incompatibilities, the biggest headwind I'm facing finding an employer that recognizes front-end development is so much bigger than how you arrange your JavaScript to enable interactivity.
I have experience with React; my last career position allowed me to go from 0-100% confidence/competence with Svelte in 4 months. But employers want to see some equivalent of "3-5 years experience with React" and structure their shitty technical assessments similarly, and I've really had a problem trying to find the right way to show I'm just as qualified.
Runtimes: a lot of frontend JS engineers don't know what these are. Being able to explain them (and the difference between Node and Deno for ex) is a good answer. For backend jobs this is a hard requirement, but when I see "Node" in a frontend job listing I assume it means "can install packages from Node."
Frameworks: (like Next) it depends. If I'm hiring for an app already built in one, maybe. A general answer like "SSR is a problem with React" and "this framework solves that problem this way" is useful.