This gives someone like me everything we want. Better performance is something the Next community has been begging for for years: the Next team ignored them, but not the Cloudflare team. Meanwhile Vite is a better core layer than the garbage the Next people use, but you still get the full Next functionality.
I wish Cloudflare the best of luck with this fork: I hope it succeeds and gets proven so I can use it at my company!
React was originally meant to be the 'V' in MVC. You can still use it that way and React becomes very simple when you only use it for UI. Why do data fetching in a React component?
I find the best DX with Adonis/nodejs and typescript.
Every time I run into an issue that Rails had a standardized solution for a decade ago just proves that most of the JS world spends their days metaphorically digging holes with sharp sticks, rather than using the appropriate tool.
But the industry values overpaying stick-diggers over results, therefore I gotta play along…
At this point, I'm convinced there's a secret global conspiracy to prank JS developers. For example 1 person maintaining 3 similar-but-distinct decimal libraries for Javascript, or the top 3 PDF processing libraries silently producing blank outputs.
I too have been very frustrated by this, and I made an "Astro for dynamic sites" TypeScript framework called Hyperspan ( https://www.hyperspan.dev ) that aims to fill the gap in the JS ecosystem for a modern fully dynamic option that, similar to Astro, makes dynamic islands easy. I have enjoyed using it in all my own projects. Check it out if you want.
Someone go make an AI rewrite of Apache+Mod-PHP and sell it to zoomers as the hip new thing already please
React, if you are judicious about what additional packages you use on top of it.
> I dropped out of the front end years ago, and it seems to just get worse every year with a profusion of confusion.
This has actually gotten somewhat better in recent years starting with esbuild which made it possible to use a simple single-binary tool for bundling.
also why do you need support? agents are the support
If the similarity is "they are both open source projects" then so are about a million others. 99.99% of them don't get any traction beyond the first week.
> You think you'll get better long-term support from an experiment that a single engineer did in his spare time?
Linus started it as an experiment. That's a single engineer doing it on his spare time.
Do you think Linux doesn't do long-term support right?
The one changing the goal post is you.
https://github.com/cloudflare/vinext It is MIT licensed. It can be used and maintained by anyone.
If it'll get adoption like Linux did, that's different. But the base is there.
If you're relying on webpack plugins heavily, I'd consider that a liability either way. It's going to seriously hamper your portability to other frameworks and build tools and even new versions of the current ones.
You can easily run turbopack for development / preview environments and webpack for production(-like) ones btw. as long as you don't rely on custom magic.
Everything just becomes a plugin.
Here's the first paragraph of Harry Potter and the philosopher's stone. I rewrote it from scratch, apparently:
Mr. and Mrs. Dursley, of number four, Privet Drive, were proud to say that they were perfectly normal, thank you very much. They were the last people you’d expect to be involved in anything strange or mysterious, because they just didn’t hold with such nonsense. Mr. Dursley was the director of a firm called Grunnings, which made drills. He was a big, beefy man with hardly any neck, although he did have a very large mustache.
If it is so cheap to make something that they recommend using (rather than a proof of concept), why buy Astro (presumably it was more expensive than the token cost of this clone?).
One conclusion is that, at the organisational level, it still makes sense to hire the “vision” behind the framework, rather than just clone it. Alternatively, maybe AI has improved that much in 1 month!
Maybe I'm wrong. We'll see what happens a couple of years from now.
Thanks
We use Astro for our internal dev documentation/design system and it’s awesome for that.
It does not. Astro is more for static sites not dynamic web apps.
Anyways, that's why it's a good fit for Cloudflare: that backend needs to be run somewhere and Astro is big enough to have some sort of a userbase behind them that Cloudflare can advertise its service to. Think of it more as a targeted ad than a real acquisition because they're super interested in the technology behind it. If that were the case, they could've just forked it instead of acquiring it.
From Astro's perspective, they're (presumably) getting more money than they ever did working on a completely open source tool with zero paywalls, so it's a win-win for both sides that Cloudflare couldn't get from their vibe-coded project nobody's using at the moment.
Like compare the two form implementations for example. Vinext is a completely different implementation compared to what the Next.js version does. Is their behaviour actually the same? The rewrite looks incredibly naive.
https://github.com/vercel/next.js/blob/b8cbaad24ca66ec673a7b...
https://github.com/cloudflare/vinext/blob/main/packages/vine...
Either way, pretty impressive.
The behavior isn't entirely the same and reaching 100% parity is a non-goal, but there are a few things to note.
This is still a very early implementation and there are undoubtedly issues with the implementation that weren't covered in next's original test suite (and thus not inherited) while not being obvious enough to pop up with all the apps we've tried so far.
As for why it's so much smaller, by building on top of Vite and their react + rsc plugins there is a whole lot of code that we don't need to write. That's where a significant portion of the LOC difference comes from.
> The result, vinext (pronounced "vee-next"), is a drop-in replacement for Next.js
"Drop-in" in my mind means I can swap the next dependency for the vinext dependency and my app will function the same. If the reality is that I have to spend hours or days debugging obscure edge cases that appear in vinext, I wouldn't exactly call that a drop-in replacement. I understand that this is an early version and that it doesn't have parity yet, but why state that it is a non-goal? For many of us, that makes vinext a non-choice, unless we choose to develop for vinext from the beginning.
Furthermore, if you're making a tool that looks almost like a well-known and well-documented tool, but not quite, how is gen AI going to be able to deal with the edge cases and vinext-specific quirks?
Woah.
Bugs like this are easy to happen and even easier to miss if you’re generating thousands of lines of code with AI.
The devil is in the detail.
So many edge cases unlikely to be there.
So many details or fine details unlikely to be there.
Years of bug fixes.
If it is literally a drop in replacement and it passes all the tests, and you're replicating something with and extremely thorough test suite, then sure I'll give you the benefit of the doubt.
Otherwise, I don't believe people "rebuilt X product in a week".
The most interesting aspect I see in all these examples is that extensive test suites make the work very straightforward. Maybe AI will produce a comeback of test-driven development.
If your stance is assuming we have an existing implementation of something in the training set, and we have a robust test harness already, and we have thousands of dollars to throw at tokens, and we're not at all concerned with "works" THEN this is viable then sure? But that doesn't seem to be what most boosters are saying.
Kind of a sloppy statement, but I don't think it's accurate to say abstraction or layering exists in software just because humans need help comprehending it. Abstractions often exist to capture the essence of some aspect of the real world, and to allow for software reuse. AIs will still find reusing software useful? Secondly, you equate "abstractions" with "layers" which aren't really the same thing. Layers are more about separation of concerns. Maybe it could be argued layering is a type of abstraction.
If you're a Next.js shop stuck on Vercel because self-hosting is painful, Cloudflare just gave you two exit ramps: Astro (for new projects) and vinext (for existing ones). Whether vinext is production-ready today matters less than what it represents for Vercel's pricing power.
The real question nobody's asking: if your framework's value can be replicated by targeting its test suite, what exactly are you paying for with Vercel's premium tiers? The answer used to be "the only place Next.js runs well." That moat is eroding fast.
Side note: this is also why SQLite's full test suite is proprietary / private
Hi next.js devs, we like to acknowledge the effort you put for writing good tests so we were able to rip it off. You know claude already has next's entire source code in it's training data?
If we accept this then we can do something about it. Without it no one will heed us.
If you or I copied and reimplemented nextjs in a better way, it doesn't feel as wrong. But when a large company does that and then brag about it, it's in poor taste.
Especially pointing out one developer and 1000 usd of tokens replacing the efforts of hundreds of talented developers. There's people on the other side of the screen.
The thing is feeling bad or complaining about this does nothing. What else then? Acceptance?
I don’t know what this means but it feels like yet another milestone moment.
- Node.js production server (vinext start) works for testing but is less complete than Workers deployment. Cloudflare Workers is the primary target.
So I kinda wonder, did they just create the framework that Next.js claims to be but never has been? And is Next.js without the hidden stuff actually a good framework? Who knows.
Vite just hangs when running vinext dev, with no output in logs whatsoever beyond printing`vinext dev (Vite 7.3.1)`.
looks like HN has finally defeated the cloudflare voting ring
Vercel may be bad, but they have been a net positive to the web landscape, so many projects are alive because of them. And I truly respect the hard work the next devs put into their code and test suites. I'm surprised any self respecting dev even votes this up.
If someone reproduced the Linux kernel would you feel the same way?
The last time Cloudflare vibe-coded something, it was a glorified proof-of-concept with TODOs up the wazoo.
I'm not sure who the hell you're talking about, but I'd guess from your comment that you have a pretty high opinion of yourself.
Except that the code completely and precisely defines the actual product. Bad code => bad product.
> code should be sacred and revered by itself
As a production of the hand and mind, code should be revered - if only as the mark of the human or groups of humans that made it.
> the wrong group of people
The group of people who care deeply about the world around them.
Wait a minute, can we at least wait until this dethrones next.js before making suck claims?
Without spending the time on reading through all the details for the umpteenth “look what we built with AI!” article, I assume this is as valid as Anthropic’s claim about building a C++ compiler a few weeks ago where, when you looked under the hood, it was still relying on existing compilers.
Like OK, I really don’t believe the claims to begin with, but even if I do take them at face value, you just recreated something already existing and working for years?
I use Liveview and Elixir for 2-3 home-lab related frontend services; but when I have to do something moderately complicated I have to reach out for a darn js library and hooks and phx-commands. Try using native drag and drop or even client-side markdown rendering. This also leads to memory leaks when you can't properly detach libraries.
I just say think about your goals; these frameworks/platforms that promise to remove JS from your life or minimize it do so by sacrificing something. There's no silver bullet for building on the web.
But whenever I do talk to people who are debating amongst frameworks SvelteKit and SolidStart are the two I recommend, it's easy to host anywhere (unlike Next), you can turn off SSR, just ship static files with very minor changes (exporting a variable in Svelte for ex). They're really quick, get the job done, actively being worked on, loads of resources, discussions and thriving communities.
I suppose that is you being overly retributive indeed.
[1] https://github.com/cloudflare/vinext/issues/22
[2] https://github.com/cloudflare/vinext/pull/31/changes#r284987...
Now, you will not develop it further, it will face the same fate as OpenNext and adaptors.
--- start quote ---
Something like 95% of vinext is pure Vite. The routing, the module shims, the SSR pipeline, the RSC integration: none of it is Cloudflare-specific.
--- end quote ---
The real achievement is human-built Vite (and it is an amazing project).
Since Next.js's API surface and capabilities are known, this is actually quite a good use of AI: re-implement some functionality using a different framework/language/approach. They work rather well with that.
From TFA:
Vite is the build tool used by most of the front-end ecosystem outside of Next.js, powering frameworks like Astro, SvelteKit, Nuxt, and Remix
Are you saying those frameworks aren't impressive because they are also powered by Vite?
Also from TFA: A project like this would normally take a team of engineers months, if not years. Several teams at various companies have attempted it, and the scope is just enormous. We tried once at Cloudflare! Two routers, 33+ module shims, server rendering pipelines, RSC streaming, file-system routing, middleware, caching, static export. There's a reason nobody has pulled it off.
That's the most important result of this experiment. They achieved something that they'd wanted to do but couldn't pull it off. Do you think they are lying?
That is not what I'm saying
> That's the most important result of this experiment. They achieved something that they'd wanted to do but couldn't pull it off. Do you think they are lying?
Once again, that is very explicitly and very clearly not what I'm saying or thinking.
You could try actually reading and understanding what I wrote instead of responding to words in your head.
The tool is hella useful. The messaging is ignorant. This should have been a "we built a tool to deploy NextJS on cloudflare natively" instead of this AI brag.
asdf was the hot shit for quite a while, with people (myself included) invoking all kinds of shell arcanum to make it faster - then mise (née rtx) came out, and it was game over. Compatible with asdf’s ecosystem, but infinitely faster.
Poetry was incredibly popular, along with various other competitors, and then uv came out.
I get what you’re saying about the AI angle, because it’s somewhat different when a human takes your crown by dint of pure skill, but it’s gotta sting either way.
> Rewrote your project
That project would die without user's adoption. Be appreciative. Nextjs is an open source project. What is it with HN that constantly praise the virtue of open source software, but downplay that fact the moment they don't like the outcome?
I'm here for it.
- could you rewrite next and react actually without using a virtual dom at all and use a compiler like svelte instead?
I actually was thinking on creating something similar. Congrats to the Cloudflare team
Does anyone have experiences with the EU alternative bunny.net?
let me add my own unqualified statement to that: no.
> Next.js has invested heavily in Turbopack but if you want to deploy it to Cloudflare, Netlify, or AWS Lambda, you have to take that build output and reshape it into something the target platform can actually run.
it's almost as if vercel had some kind of financial incentive to gear this towards their own platform.
> reimplemented the Next.js API surface on Vite directly
a clown car screeches to a halt; several burnt-out-bored oracle vs google lawyers climb out and, weirdly, i am there for it
all in all, it's definitely a good example of something we couldn't have done for $1100 pre-llms, but: should we have? did somebody consult the lava lamps?
Also looking forward to Vercel's version of https://matrix.org/blog/2026/01/28/matrix-on-cloudflare-work....
> And we already have customers running it in production.
Wouldn't be like Claude to maybe forget to implement half the library, would it?
I guess they can call themselves Claudeflare now ;)
The tone of the blog post is upbeat. What are the consequences? Is the new performance expectation at Clownflare to "port" one framework per week? Do you have to generate at least 20 kLOC per week? Aren't you redundant right now?
Google Gemini, at the time, created an SSG solution which I had spent the next 3-4 months fixing bugs for. Consequently, I had to understand the whole SSG build step and all the wrong design decisions the AI made that resulted in the site getting a horrible core web vitals score. In the end, I just put the site behind a white “div” that disappear when the page finally loads. SSR is way more complex than it sounds.
This project (along with the quantum post) is quite concerning. It’s not clear why Cloudflare has decided to take this direction. If you want to know why LLMs are completely unable to produce something even close to NextJS, a better solution would have been to ask the LLM to fix the opennext adapter rather than building a new framework from scratch.
Cloudflare also lost my support because their support is among the worst, rep evn sneered (cannot update my WHOIS, still, after months of emails). Strongly recommend avoiding their platform. You will find that you lose more time & money to dealing with the issue of parity. God help you if you ever need support, almost every question in Discord goes unanswered as well.
have fun.
So maybe the project is sort of maintainable, as long as people maintain Vite.
Gatsby? I used to use that one until the updates basically ceased to exist.
Vite with <insert your favorite here> - looks good, but at initial glance seems to favor just pure speed for any other feature support like MDX, advanced SEO, etc.
Roll your own with React and webpack? Good luck, and you'll probably end up with something that looks like the others I've mentioned above.
Just surprised many comments are just stating complaints about Next and not providing any counter examples, its very un-HN.
There is a similar vibe on the Next.js subreddit, just enormous amounts of shallow negativity. Very strange.
(I'm not saying there aren't valid reasons to dislike the framework or company but the way it's expressed is consistently incredibly juvenile for some reason)
Vite has plugins for MDX, SSR, etc. You can easily build your own framework if you want in a few hundred lines of glue code.
The criticisms of Next / React are so ubiquitous you can metaphorically gesture in their direction and most people know what's up. It's like wondering why someone said "ai slop" and didn't provide an expose on the quality of AI writing.
This one's a bit more clever in that it's not entirely new -- it's from 2016.
Here's some examples from 6 days ago:
https://news.ycombinator.com/threads?id=fdefitte&next=470679...
Comment 1: 2026-02-18T23:45:12 1771458312 https://news.ycombinator.com/item?id=47067991
Comment 2: 2026-02-18T23:45:32 1771458332 https://news.ycombinator.com/item?id=47067994
20 seconds between its comments.
--
or another example:
Comment 1: 2026-02-18T20:06:49 1771445209 https://news.ycombinator.com/item?id=47065649
Comment 2: 2026-02-18T20:07:12 1771445232 https://news.ycombinator.com/item?id=47065653
23 seconds between its comments.
The Traffic-aware Pre-rendering idea is genuinely clever. Instead of pre-rendering every possible route at build time (and waiting 30 min for large sites), they query actual Cloudflare zone analytics at deploy time and only pre-render the pages that get real traffic. Power law does the rest — a few hundred pages cover 90%+ of hits, everything else falls back to SSR + ISR.
The "$1100 in API costs" headline is catchy but I think the real takeaway is more subtle: this worked because all four preconditions happened to line up — Next.js is extremely well-documented in training data, it has a massive test suite you can port as a mechanical spec, Vite handles the genuinely hard bundler problems, and current models can sustain coherence across a codebase this size. It's not "AI can replace any framework in a week" — it's "given the right constraints, one person can move way faster than we assumed."
Curious to see how well it holds up as Next.js keeps shipping new APIs. The 94% coverage number is impressive today but compatibility is a treadmill.
Speaking more about the framework itself, the only real conclusion I have here is that I feel server components are a misunderstood and under-utilized pattern and anyone attempting to simplify their DX is a win in my book.
Next is very complex, largely because it has incrementally grown and kept somewhat backwards compatible. A framework that starts from the current API surface and grows can be more malleable and make some tough decisions here at the outset.
Crazy to see it's already being run on a .gov domain[0]. TTFGOV as a new adoption metric?
[0] https://www.cio.gov/
Well said; this is my thinking as well. One person or organization can do the hard work of testing multiple approaches to the API, establishing and revising best practices, and developing an ecosystem. Then once things are fairly stable and well-understood, another person can just yoink it.
I have little empathy for Vercel, and here they're kind of being hoist by their own petard of inducing frustration in people who don't use their hosting; but I'm concerned about how smaller-scale projects (including copyleft ones) will be laundered and extinguished.
That transparency & availability for community contributions or forks is the point of open-source.
If you're only using open-source as marketing because you're bad at marketing, then you should probably go closed source & find a non-technical business partner.
Whoever "yoinks" the package runs into the same problem because they now have to build credibility somehow to actually profit from it.
Anyone who yoinks an open-source package still has to present an argument about why their offering is better than the original maintainer's.
I'm very uncovinced. History showed us very complex systems reverse engineered without access to the source code. With access to the source code, coupled with the rapid iteration of AI, I don't see any real moat here; at best a slight delay.
I have a demonstrated process here on my blog (all hand written without AI).
This bit about how to brute force decompilation: https://reorchestrate.com/posts/your-binary-is-no-longer-saf...
And this about how to do the conversion and address the LLM hallucination problem: https://reorchestrate.com/posts/your-binary-is-no-longer-saf...
Yes, it is absolutely possible.
Its scary - once you get the differential testing harness set up it seems to be just a matter of time/tokens for it to stubbornly work through it.
I, in my own way, have discovered that recent versions of Claude are extremely (as in, super-humanly) good at rewriting or porting. Apparently if recently released coding agents have a predefined target and a good test suite then you can basically tell them that you want X (well-defined target w/ good suite of tests) written in Y (the language/framework you want X written in but it isn't) -- and a week or two later you have a working version.
I have spent the last month wrapping my head around the idea that there is a class of tasks in software engineering that is now solved for not very much money at all. More or less every single aspirational idea I have ever had over the last 20 years or so I have begun emabarking on within the last two months.
I hear you.
And if you just copy the source code or translate it one-to-one into a new language, rather than make a behavioral copy, there will be copyright issues.
Next.js is MIT-licensed. Cloudflare's rewrite is... also MIT licensed...
Wouldn't this just mean that actual open source is the tests? or spec? or ... The artifact which acts as seed for the program, what ever that ends up being?