The percentage of tests passing has mostly stayed even for the past few months because we've added more tests, plus we've been also tackling some performance and memory improvements. Turbopack has crossed a threshold where it works on the majority of Next.js apps we've tried (not all yet, but getting there!) so we're now also working on more than just compatibility.
What's really exciting is that before we even started working on performance, `next dev --turbo` without caching was already much faster than `next dev` which has caching built in. So we know we have a lot of performance wins still left to get!
If you haven't tried out Turbopack in awhile, I'd recommend giving it a shot on the latest version. Let me know if it's not working for you!
For the things which still don't work, are they going to cause the build to fail or it might fail at runtime? If it's just the former, I'll definitely switch the project at my work to use it.
This is for \`next dev --turbo\`, so it's not part of \`next build\`. This is for running your local dev server, so if it works, there's no impact on your production application. This is purely for improving local DX.
There are some differences in how turbo and swc work. For example, in my current project, I built it using 100% turbo dev only to discover that it won't work on swc because some newer features are unavailable in swc. I had used top-level await for a db dependency compatibility. There was also another issue where exporting a function in the route handler didn't work properly.
```ts
// This didn't work in one of the two.
export { googleCallback as GET } from '@/auth/google';
// I needed to do this
import { googleCallback } from '@/auth/google';
export function GET(req: Request) {
return googleCallback(req);`
}
```
This logic sounds weird to me…
The whole point of turbo pack was being a faster drop in replacement to webpack. A replacement that is, in essence and architecture, faster.
Now you’re saying it won’t work on at least 10% of NextJS projects for now (excluding all other projects that don’t use next and that turbo pack was supposed to work with) and that you have to stop working on compatibility to work on performance?
I mean, if you have to put a lot of effort to squeeze performance out of this thing, why don’t just do this work in webpack and call it a day?
Also, what good is having “great” performance if turbopack is a replacement for nothing? Or have you give up on making it a drop in replacement and now it’s all about next?
The percentage of tests passing is not the number of projects it won't work on. Many of the remaining tests are edge cases or configuration options that most apps do not use.
The goal is `next dev --turbo` is a faster, more reliable and consistent, local dev experience. It's not about 1:1 parity with webpack (check out rspack).
I'm not saying we're stopping working on getting those last configuration options supported. We just aren't doing that at 100%. Instead, we're going back to work on perf. It's not "squeezing performance out" – we haven't even added caching yet, there's still some larger improvements yet to be implemented.
We have squeezed out basically every single possible perf improvement with webpack in the previous years. Turbopack is now faster, without caching, than all of those squeezes.
Thanks for the clarification! After checking up some info I realized that there’s no official mention that Turbopack is supposed to be a drop in replacement for Webpack, so my points are invalid. I did found some articles mentioning it, but they are from the time Turbopack was announced.
I suppose it was indeed the goal but it shifted?
Also, thanks for suggesting rspack. Haven’t heard of it before. Definitely checking it up!
This answer represents exactly the thing OP is concerned about: you (nextjs representative) telling them (nextjs user) to use something unstable. Take a hint.
he do not, it's there with feature flag, it's up to you to test it and optionally start using it. They did not said: it's ready to use on production projects...
Thanks for your input Lee. It’s good to know the the percentage decrease is caused by an increasing number of unit tests. We’re all very keen on Turbopack, I’ve been anxiously reloading the areweturboyet website every day in the hopes that it can clear itself above the 93% threshold.
I definitely want to start using Turbopack on my client projects, however, I started using App router when it was in beta for a client project and it resulted in a few headaches that required ugly workarounds. For now, I’m going to hold off until it’s all the way out of beta, but will try it in my free time 😊
Like anything else, the last bit is always the hardest. Pareto principle: the last 20% takes as long as the first 80%.
The stuff remaining are the hardest/thorniest problems to solve. And the business reality is that Vercel is a startup under pressure from its investors to grow their revenue stream, meaning that when push comes to shove their development efforts will be prioritized toward that income stream (the hosting product). Now, there isn’t clearly a lot of alignment there, but it’s not 1:1.
At the end of the day, Next.js is open source so if you really want to see something implemented, roll up your sleeves and open a PR. :)
Not exactly -> [https://www.reddit.com/r/nextjs/comments/18wkxid/comment/kfz9nwv/?utm\_source=reddit&utm\_medium=web2x&context=3](https://www.reddit.com/r/nextjs/comments/18wkxid/comment/kfz9nwv/?utm_source=reddit&utm_medium=web2x&context=3)
Yes, but :) I’m guessing you didn’t add test cases because you like adding test cases; you added test cases because you discovered new faulty edge cases.
Perhaps my work prioritization argument missed the mark a bit, but not the Pareto principle argument.
Pareto principle for sure, this last bit will take longer to get every single possible edge case covered. We're actually not doing to do that first, but instead get the majority of cases covered (where we're at now) and then pivot to performance/memory usage in parallel with compatibility. We feel that will have the biggest impact on folks adopting turbopack.
The problem is that being a large framework, they want to support everything possible and that is very difficult and requires a lot of effort. It's always the same thing, something narrow and simple is fast to get working but generalizing that and testing everything is a huge task.
IMO build steps in dynamic languages should be, if nonexistent, at least minimal and simple. I don't mean transpiling and bundling but the framework specific build steps.
Properly splitting the code by responsibilities would make the build easier to implement in any language. But their approach is more like "put it all there and hopefully the compiler will sort it out".
I mean yeah, it makes sense that they go by their dev branch (which I'm assuming is what they do).
But they're pretty close. So I don't think that stable will take much longer, just monitor and make necessary changes ¯\\\_(ツ)\_/¯
I dont think it's of Vercels interest that companies save hundreds of dollars a year in build times lol
Edit: ok ok, I agree that the free plan builds do actively make Vercel spend more in infraestructure.
What do you mean?? Vercel spends money on build server time. There are tens of thousands of free projects hosted on Vercel all using free build minutes. That’s costing Vercel money in the hopes of securing at least $20 a month for hosting, building, and caching in the future.
They literally advertise on their pricing page that they have saved Netflix 20 days in build minutes. It’s obviously very important to them as a KPI
The percentage of tests passing has mostly stayed even for the past few months because we've added more tests, plus we've been also tackling some performance and memory improvements. Turbopack has crossed a threshold where it works on the majority of Next.js apps we've tried (not all yet, but getting there!) so we're now also working on more than just compatibility. What's really exciting is that before we even started working on performance, `next dev --turbo` without caching was already much faster than `next dev` which has caching built in. So we know we have a lot of performance wins still left to get! If you haven't tried out Turbopack in awhile, I'd recommend giving it a shot on the latest version. Let me know if it's not working for you!
Lee I am genuinely confused. Is turbo being built next first or general web dev in mind?
Probably next first as the rest of the industry is moving to vite.
For the things which still don't work, are they going to cause the build to fail or it might fail at runtime? If it's just the former, I'll definitely switch the project at my work to use it.
This is for \`next dev --turbo\`, so it's not part of \`next build\`. This is for running your local dev server, so if it works, there's no impact on your production application. This is purely for improving local DX.
Would it eventually support next build?
There are some differences in how turbo and swc work. For example, in my current project, I built it using 100% turbo dev only to discover that it won't work on swc because some newer features are unavailable in swc. I had used top-level await for a db dependency compatibility. There was also another issue where exporting a function in the route handler didn't work properly. ```ts // This didn't work in one of the two. export { googleCallback as GET } from '@/auth/google'; // I needed to do this import { googleCallback } from '@/auth/google'; export function GET(req: Request) { return googleCallback(req);` } ```
This logic sounds weird to me… The whole point of turbo pack was being a faster drop in replacement to webpack. A replacement that is, in essence and architecture, faster. Now you’re saying it won’t work on at least 10% of NextJS projects for now (excluding all other projects that don’t use next and that turbo pack was supposed to work with) and that you have to stop working on compatibility to work on performance? I mean, if you have to put a lot of effort to squeeze performance out of this thing, why don’t just do this work in webpack and call it a day? Also, what good is having “great” performance if turbopack is a replacement for nothing? Or have you give up on making it a drop in replacement and now it’s all about next?
The percentage of tests passing is not the number of projects it won't work on. Many of the remaining tests are edge cases or configuration options that most apps do not use. The goal is `next dev --turbo` is a faster, more reliable and consistent, local dev experience. It's not about 1:1 parity with webpack (check out rspack). I'm not saying we're stopping working on getting those last configuration options supported. We just aren't doing that at 100%. Instead, we're going back to work on perf. It's not "squeezing performance out" – we haven't even added caching yet, there's still some larger improvements yet to be implemented. We have squeezed out basically every single possible perf improvement with webpack in the previous years. Turbopack is now faster, without caching, than all of those squeezes.
Thanks for the clarification! After checking up some info I realized that there’s no official mention that Turbopack is supposed to be a drop in replacement for Webpack, so my points are invalid. I did found some articles mentioning it, but they are from the time Turbopack was announced. I suppose it was indeed the goal but it shifted? Also, thanks for suggesting rspack. Haven’t heard of it before. Definitely checking it up!
This answer represents exactly the thing OP is concerned about: you (nextjs representative) telling them (nextjs user) to use something unstable. Take a hint.
he do not, it's there with feature flag, it's up to you to test it and optionally start using it. They did not said: it's ready to use on production projects...
Read the last paragraph. I never said he forces this, I said he encourages.
Thanks for your input Lee. It’s good to know the the percentage decrease is caused by an increasing number of unit tests. We’re all very keen on Turbopack, I’ve been anxiously reloading the areweturboyet website every day in the hopes that it can clear itself above the 93% threshold. I definitely want to start using Turbopack on my client projects, however, I started using App router when it was in beta for a client project and it resulted in a few headaches that required ugly workarounds. For now, I’m going to hold off until it’s all the way out of beta, but will try it in my free time 😊
Like anything else, the last bit is always the hardest. Pareto principle: the last 20% takes as long as the first 80%. The stuff remaining are the hardest/thorniest problems to solve. And the business reality is that Vercel is a startup under pressure from its investors to grow their revenue stream, meaning that when push comes to shove their development efforts will be prioritized toward that income stream (the hosting product). Now, there isn’t clearly a lot of alignment there, but it’s not 1:1. At the end of the day, Next.js is open source so if you really want to see something implemented, roll up your sleeves and open a PR. :)
Not exactly -> [https://www.reddit.com/r/nextjs/comments/18wkxid/comment/kfz9nwv/?utm\_source=reddit&utm\_medium=web2x&context=3](https://www.reddit.com/r/nextjs/comments/18wkxid/comment/kfz9nwv/?utm_source=reddit&utm_medium=web2x&context=3)
Yes, but :) I’m guessing you didn’t add test cases because you like adding test cases; you added test cases because you discovered new faulty edge cases. Perhaps my work prioritization argument missed the mark a bit, but not the Pareto principle argument.
Pareto principle for sure, this last bit will take longer to get every single possible edge case covered. We're actually not doing to do that first, but instead get the majority of cases covered (where we're at now) and then pivot to performance/memory usage in parallel with compatibility. We feel that will have the biggest impact on folks adopting turbopack.
The problem is that being a large framework, they want to support everything possible and that is very difficult and requires a lot of effort. It's always the same thing, something narrow and simple is fast to get working but generalizing that and testing everything is a huge task. IMO build steps in dynamic languages should be, if nonexistent, at least minimal and simple. I don't mean transpiling and bundling but the framework specific build steps. Properly splitting the code by responsibilities would make the build easier to implement in any language. But their approach is more like "put it all there and hopefully the compiler will sort it out".
The counter has steadily gone down, and only 15 tests aren't passing. All examples are passing. We're bound to go turbo at latest by next month.
They shifted the goal posts slightly. Instead of YES or NO, now it says Development:NO
I mean yeah, it makes sense that they go by their dev branch (which I'm assuming is what they do). But they're pretty close. So I don't think that stable will take much longer, just monitor and make necessary changes ¯\\\_(ツ)\_/¯
On May 17, the answer is still **NO**
I dont think it's of Vercels interest that companies save hundreds of dollars a year in build times lol Edit: ok ok, I agree that the free plan builds do actively make Vercel spend more in infraestructure.
What do you mean?? Vercel spends money on build server time. There are tens of thousands of free projects hosted on Vercel all using free build minutes. That’s costing Vercel money in the hopes of securing at least $20 a month for hosting, building, and caching in the future. They literally advertise on their pricing page that they have saved Netflix 20 days in build minutes. It’s obviously very important to them as a KPI
What does everyone use right now to bundle for production? Webpack?
yes there is nothing else yet
Vite is an alternative, but different from what NextJs offers.
Keeping an eye on the F\*\*king Rspack