Live data from Hacker News

How we rebuilt Next.js with AI in one week

blog.cloudflare.com

171–180 of 252 posts

Re: How we rebuilt Next.js with AI in one week

#171
post #128
post #45

Earlier quoted context omitted.

Next is the worst framework I’ve ever used next to rails. It’s pure overhead for most apps.

If Rails is considered a worse framework, then I'm pretty much speechless. Not everything has to be about performance. Security is a thing too.

I miss Rails so much when working with any of the top JS frameworks.

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…

Re: How we rebuilt Next.js with AI in one week

#172
post #4

This is pretty fascinating and comes with some complicated AI-world incentives that I've been ruminating on lately. The better you document your work, the stronger contracts you define, the easier it is for someone to clone your work. I wouldn't be surprised if we end up seeing open source commercial work bend towards the SQLite model (open core, private tests). There's no way Cloudflare could have pulled this off wi…

> The better you document your work, the stronger contracts you define, the easier it is for someone to clone your work. 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…

> Then once things are fairly stable and well-understood, another person can just yoink it.

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.

Re: How we rebuilt Next.js with AI in one week

#177
post #171
post #128

Earlier quoted context omitted.

If Rails is considered a worse framework, then I'm pretty much speechless. Not everything has to be about performance. Security is a thing too.

I miss Rails so much when working with any of the top JS frameworks. 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…

Shilling a bit but maybe check out wasp.sh, we are conceptually very similar to "Rails for JS"! Just don't tell Claude to completely copy us hehe (pls)

Re: How we rebuilt Next.js with AI in one week

#178

This is probably the most interesting AI experiment I've seen yet. Looking through the codebase has me wondering where all the code is. I don't know if anyone has had the displeasure of going through the next.js codebase, but I estimate it's at least two orders of magnitude more code than this reimplementation. Which makes me wonder, does it actually handle the edge cases or does it just pass the tests. Like compare…

(to be transparent - I'm a Cloudflare engineer) 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 fo…

Why is parity a non-goal? The blog post states:

> 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?

Re: How we rebuilt Next.js with AI in one week

#179
post #25

I find it interesting that they bought Astro ( https://blog.cloudflare.com/astro-joins-cloudflare/ ), which from my definitely-not-a-frontend-person perspective seems to tackle a similar problem to Next. A month ago. 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…

[deleted]

Re: How we rebuilt Next.js with AI in one week

#180
post #12

Here's what is buried a bit in the text: --- 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 funct…

> The real achievement is human-built Vite (and it is an amazing project). 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…

> Are you saying those frameworks aren't impressive because they are also powered by Vite?

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.

Post reply on HN