Cloudflare Experiment Ports Most of Next.js API in 'One Week' With AI (theregister.com) 29
An anonymous reader shares a report: A Cloudflare engineer says he has implemented 94% of the Next.js API by directing Anthropic's Claude, spending about $1,100 on tokens. The purpose of the experimental project was not to show off AI coding, but to address an issue with Next.js, the popular React-based framework sponsored by Vercel.
According to Cloudflare engineering director Steve Faulkner, the Next.js tooling is "entirely bespoke... 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."
The Next.js team is addressing this following numerous complaints that deploying the framework with full features on platforms other than Vercel is too difficult, with a feature in progress called deployment adapters. "Vercel will use the same adapter API as every other partner," the company said when introducing the planned feature last year.
According to Cloudflare engineering director Steve Faulkner, the Next.js tooling is "entirely bespoke... 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."
The Next.js team is addressing this following numerous complaints that deploying the framework with full features on platforms other than Vercel is too difficult, with a feature in progress called deployment adapters. "Vercel will use the same adapter API as every other partner," the company said when introducing the planned feature last year.
Jamstack folks, just use Deno already. (Score:5, Insightful)
No need for all this Next.js cruft to patch up Nodes shortcomings. Deno [deno.com] is the official successor to Node and has been around for quite long already. Secure by default, native TypeScript (no transpiling needed), Browser API fully supported, no context switching required or SSR stunts required ... etc. I'm using Deno in my Jamstack stuff exclusively. Working with Node stuff feels like a throughback to PHP 3 now.
Re: (Score:2)
I have no idea what any of that is, but my first question is if this AI port is actually secure and performs well. Anything for web needs to be very carefully developed.
Re: (Score:3)
The obvious second question is how much of Next.js went into Claude's training corpus and thus might have gotten regurgitated in the process of this "re-"implementation.
Re: (Score:2)
Secure by default....
Cos you know.....
Windows NT was also secure by default.....
You have to deliberately allow for ... (Score:2)
... any external access. Annoying to quickly get results, but generally regarded as "secure by default". This entails that any decision about access has to be deliberately made by the programmer. The progger can still screw up, but then it's his/her fault, not the fault of the software used.
Re: (Score:3)
It exists to extend React.js to the server side for SSR, the need for which is not removed by Deno. This would still be done, whether you're using Deno or Node.js.
Re: (Score:1)
Re: (Score:2)
This is a bit of an oversimplification, but Deno tried to do everything differently from Node, then realized that was a colossal mistake, and remade everything more or less the Node way.
Bun just started out trying to build a better Node ... and they largely succeeded. However, they still have a lot of rough edges (eg. you can't autocomplete bun commands at the command line, because the Bun people don't think that's important enough to fix).
Re: (Score:2)
That's the problem with Javascript frameworks. There are three new per week and after at most a year people start telling you "It's your fault if you are still using (1 year old framework)"
Re: (Score:2)
There is a framework for all that: http://vanilla-js.com/ [vanilla-js.com]
And your numbers sound wildly too large. Ajax needs 20 lines? Did you see the fetch API? Want to do something asynchronous when it returns? Fetch gives you a promise, you can just define an anonymous function, that then inserts the scripts. That's more like 5 lines of code. The thing is, that newer Javascript standards include what people had to implemented in frameworks, because they recognized that these things obviously were missing.
You mean plagiarized? (Score:2)
Sounds like they just ripped off Next code to create their own version.
Re: (Score:2)
This sounds exactly like how Oracle attempted to extort money out of Google when they re-created the Java API for Android.
Good thing that was ultimately deemed fair use.
Re: (Score:2)
You mean they leveraged open source tests (not even OSS code) to build a better fork of Next (or at least a potentially better one; we'll have to wait and see)?
And here I thought forking good software (that was poorly managed) so that you could do a better job of it, was a big part of what OSS was all about!
Re: (Score:2)
Why would you not leverage open source software in this way? That's the whole point, right? "I don't like the direction this thing is going, I'm forking this thing, and fixing all the problems I see with it". It's no accident the "fork" feature on github is so prominent.
94% (Score:5, Funny)
Getting any work to 90% is easy. Well-known code, low-hanging fruit etc. It's the last 10% that takes exponentially more time. And the last 1% takes forever because that's where you actually test stuff, realise all the issues and fix subtle and difficult to spot bugs.
In short, 94% is as good as nothing. Anyone who brags about it, is just an AI show-off.
Re: (Score:2)
> is just an AI show-off.
Isn't that a pleonasm?
Re: (Score:3)
for something like Next.js on Node.js I don't think that is the case at all.
Honestly 94% is probably as good as 100% for quality projects that have good unit tests. It should be as simple as deploying to the new environment changing a handful of lines or [ctrl]-[r]'ing your way to using stuff from the new name space, and running your tests. If all the tests come up green because you don't use that 6% missing - off to QA testing..
If some tests do fail you probably are not looking at a huge effort to replace
Re: (Score:2)
Guess we need to know *which* 94%. If it were ordered by instances of invocation of a codebase to port, then sure, probably 6% of the surface of a library might have as few as zero actual users.
But if it were 'the 94% the codegen happened to get to pass tests', well then it's more of a crapshoot as to whether that 6% was actually important and needed bespoke attention.
That said, again we have another example of codegen being able to generate an alternative implementation of an existing open source implemen
Re: (Score:2)
However there is rarely a particularly good reason to do that.
That is both true and also never stopped anyone in the world of frameworks/libraries/languages and stuff that is for programmers by programmers for the most part.
Re: (Score:2)
Usually they at least have a concept of a different interface, either more flexibility because the thing they are 'ripping off' hard codes some expectations, or more usability by simplifying an overly complex interface provided by a framework or language.
Here we are talking about creating verbatim, exactly the same calls/arguments/syntax as an existing implementation. Which is a pretty rare occurrence for specific reasons. Off hand things like FreeDOS, Dosbox, Wine, a popular scenario of making open source
Re: (Score:2)
94% is an extremely good start. It can take a long time to get 94% complete. It's true, that that last 6% is normally a lot harder, though. But often 94% is "good enough to start with". Only a few of the planned features are missing.
OTOH, I'm not sure I trust a claim that it's actually 94% complete.
During this effort (Score:2)
Did they even think about asking if they needed Next.js (or a clone) in the first place?
Re: (Score:2)
They presumably didn't *want* next.js anymore, but wanted it because between porting their codebases to an alternative or making a knockoff of next.js, the latter is actually easier for LLM to pull off.
Porting a codebase to do the same functionality with a different dependency is also something LLMs are.... kind of useful for, but far less good at that than making knock-offs of an existing open source projects with some twists applied.
\o/ (Score:1)
Another solution is:
* Switching to Bun+Solid.js
Escaping the React+Next pain ftw
Re: (Score:2)
Yes, but an LLM is only kind of useful for that sort of switch. It can do a bit, but it screws up a fair amount still (currently going through exactly that scenario now, it is much faster with LLM as it is kind of in its wheelhouse, but it's still a slog). Codegen maybe has a success rate of 75% for that sort of chore.
Making a knockoff implementation of an existing open source project with a very good existing suite of test cases... Well codegen goes over 90%, between likely having been trained on the prio
I want to know howl ong (Score:2)
It will take to get to 100%.