Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we rebuilt Next.js with AI in one week

blog.cloudflare.com

Post reply on HN
Print view View original

111–120 of 252 posts

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

#111

Post by rovr138 »

IgorPartola wrote: post #108
thousand_nights wrote: post #33

Earlier quoted context omitted.

at my job we have some 7+ year old nextjs apps that don't receive new features but still do their jobs perfectly fine, and they keep changing random shit around for no reason, we've had to waste time on multiple refactors already for major nextjs version bumps once the older ones are no longer supported

Is there any reason to keep upgrading if the apps keep doing their jobs perfectly fine? Pull in a stable version of the framework and the associated docs and stay there.

Security.

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

#112

Post by rovr138 »

paxys wrote: post #91
hungryhobbit wrote: post #87

Earlier quoted context omitted.

Actually, that's exactly how it started: read Linus Torvalds' "Just for Fun".

Was Linux owned by a large company? Was the maintainer getting paychecks from that company? Was it profit motivated? Was it released as an AI experiment? 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.

The similarity is to,

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

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

#113

Post by vlucas »

qudat wrote: post #45
hungryhobbit wrote: post #16

Man, I love Next ... but I also love Vite ... and I hate the Next team, because they focus on fancy new features for 0.1% of their users, at the complete expense of the other 99.9% of the Next community (who they basically ignore). 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. M…

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

The basic premise of Next is good, but it definitely has more overhead that in should, has odd "middleware", and is very hard to optimize. I view this mostly as a React problem though since any page requires full hydration and ships everything to the client. RSCs are... not my favorite for sure.

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.

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

#115

Post by switz »

vlucas wrote: post #113
qudat wrote: 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.

The basic premise of Next is good, but it definitely has more overhead that in should, has odd "middleware", and is very hard to optimize. I view this mostly as a React problem though since any page requires full hydration and ships everything to the client. RSCs are... not my favorite for sure. I too have been very frustrated by this, and I made an "Astro for dynamic sites" TypeScript framework called Hyperspan ( ht…

RSC by design does not ship everything to the client. That's one of its basic premises. It ships markup, composed in client interactivity, but you can shed a lot of the code required curate that markup.

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

#117

Post by lioeters »

general_reveal wrote: post #78
slopinthebag wrote: post #57

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…

It is the most passive aggressive thing I’ve ever seen. Cloudflare team had issues with the Next team? And they responded with ‘we can do your whole product with an intern and AI’, lol. Woah.

Recreate your competitor's product with an intern + AI over a weekend. Hilarious!

I hope this becomes common practice. It might even work as an interview question for hiring new candidates.

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

#118

Post by nicoburns »

mikestorrent wrote: post #106
thousand_nights wrote: post #33

Earlier quoted context omitted.

at my job we have some 7+ year old nextjs apps that don't receive new features but still do their jobs perfectly fine, and they keep changing random shit around for no reason, we've had to waste time on multiple refactors already for major nextjs version bumps once the older ones are no longer supported

Is there any front end framework that doesn't do this? I dropped out of the front end years ago, and it seems to just get worse every year with a profusion of confusion. Doesn't anyone yearn for back when we didn't have to build the front end at all?? Just emit some HTML and serve up some JS files from the backend, and everything just flows from there? Someone go make an AI rewrite of Apache+Mod-PHP and sell it to zo…

> Is there any front end framework that doesn't do this?

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.

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

#119

Post by nicoburns »

aleksandrh wrote: post #92
hungryhobbit wrote: post #16

Man, I love Next ... but I also love Vite ... and I hate the Next team, because they focus on fancy new features for 0.1% of their users, at the complete expense of the other 99.9% of the Next community (who they basically ignore). 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. M…

Weird, I hate Next and I love Vite. We have a big (I mean _really_ big) production app that runs on Next.js at work and it's the slowest thing I've ever worked on. I had to upgrade my machine to an M4 Pro just to get local dev compile times down from 5-8 minutes to ~30-60 seconds per route. And my hot refreshes are down from ~15-20 seconds to 5-10. It's _bad_. All the Next.js team does is give you the run-around and…

Damn, that's bad. You can compile C++ faster than that!

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

#120

Post by moviedo »

dmix wrote: post #98
JustSkyfall wrote: post #83

Earlier quoted context omitted.

Rails 8 is surprisingly good nowadays. It absolutely still has its share of problems (e.g. Bundler being slow, the frontend story being crappy without Inertia, lack of types which is a biggie, memory) but it is still a fantastic framework imo.

Why Inertia.js? I quite enjoy not using JS heavy frontends in Rails by leaning on Turbo and light Stimulus JS controllers where needed. My experience going hard into Vue+Rails was full of pain and I've rediscovered why server first makes everything easier to reason about instead of duplicating tons of logic + dealing with constant async issues (particularly around automated testing and complex data loading).

Inertia because it’s a plug-in replacement for ruby html templating aka erb. Try it out, it’s basically the same stuff you get from erb, without the need for Turbo’s web sockets. You get server side rendering, all the great BE stuff like server side validation, but no SPA headache.

I find the best DX with Adonis/nodejs and typescript.

Post reply on HN