Channel
Interviewed Person
Various
Throughout history, there have been some rivalries that have shaped our lives as developers. Rails vs Django, sequel vs no sequel, web components vs feeling the love and embrace of a woman. And just a few days ago, we got another update in one of my favorite niche tech rivalries, Vercel vs Cloudflare. If billionaires passive-aggressively having a downtime measuring contest on your timeline isn't your thing, you may have missed that Guillermo from Vercel and Matthew from Cloudflare really don't like each other. And that rivalry got amped up even more last week when Cloudflare released vNext, a reimplementation
of the Next.js API built on V, essentially freeing up your Next.js app to be deployed anywhere. In this video, we'll break down how they did it, what it may mean for other open source projects in the future, and find out if it actually works. It is March 2nd, 2026, and you're watching The Code Report. Love it or hate it, Next is still the most popular way to create a React app. But despite that, historically, its biggest weakness has had nothing to do with its API, but rather its lack of deployment targets. If you have a Next app and you want to deploy it on Vercel, cool.
Everything will work nice since Vercel essentially provides a bespoke runtime for things like routing, middleware, ISR, and image optimization. But if you have a Next app and you want to deploy it somewhere not on Vercel, like Cloudflare or Netlify, it gets a little trickier. If you've had this constraint, odds are you've used the OpenNext project to get around it. The way OpenNext works is it takes the traditional output you get from running Next build, and then repackages it to run on whichever platform you'd like. And as you might imagine, this process of needing to reverse engineer and build on top
of Next output is fragile and prone to errors as the build output changes over time. So the crazy folks at Cloudflare got together and thought, what if instead of building on top of the output, we just entirely rebuilt the Next framework from scratch on Vite? Now this isn't a novel idea, and it's not the first time it's been tried. Cloudflare themselves had even tried it in the past and failed. So what makes this time different? Well obviously, AI. It took them just one day to get basic SSR, middleware, server actions, and streaming
to work. By day three, they were able to deploy two Cloudflare workers with full client hydration. And then they spent the rest of the week fixing edge cases, expanding the test suite, and bringing API coverage up to 94% of the Next API. All for about a grand total of $1,100 in AI tokens. And because it's built on Vite, it can take advantage of Vite's architecture, which includes Rolldown, the Rust-based bundler for improved performance. So what does Vercel think about all this? As you can imagine, they're not the biggest fans.
The Vercel CTO tweeted about it being a, quote, slop fork, and Guillermo himself tweeted a Cloudflare to Vercel migration guide and some critical vulnerabilities that they found in the project. Those vulnerabilities make it feel like a true Next.js clone, but since I know you don't have any actual users, that doesn't matter. So let's find out if it actually works. Here's the app for our newsletter, bytes.dev. It's a pretty generic Next app that allows people to sign up for the newsletter and displays an archive of our past issues, which it gets from disk. We also have an endpoint that spits back HTML that we can paste into our email platform
for sending. For basic apps, you could probably just install vNext and swap out the next command for it in your package.json and it may work. For this one, though, we'll need some refactoring to get it working with V. Thankfully, Cloudflare also built an agent skill to make it pretty simple. Since I'm using cursor, I can install it with this command, and then once it's installed, the agent can use it when it helps migrate the project to vNext. The biggest thing to look out for is compatibility with V. For example, it'll add type module in our package.json so that all the JS files in the
project will be treated as ES modules, and it'll refactor any JS files that have JSX in them to use the .jsx extension since it's required by V. And my favorite part is when it says it's done even though half the app is still broken. But after some follow-up begging, it did eventually figure it out, and we now have our next app running entirely on V. The big question is, was it worth it to switch? To be honest, probably not yet. Always remember, when it comes to bleeding edge software, you're the one who bleeds. Beyond the slopped narrative, though, I think the more interesting part is how great V is.
