James

It's felt for a while like software engineering is shifting towards highly technical product management with AI. I've been thinking about this a lot over the past few weeks. Had to write up some of my thoughts - eli.cx/blog/the-role-…

@anaisbetts @ZackMaril @GeoffreyHuntley In all fairness, you could ask the same question for why Bun didn't look at solving the problem in a way that aligns with the work Zig was already doing towards the same goal. They've been rebuilding their type system for several months - it was a big part of the 0.16.0 release

@James_Elicx @ZackMaril @GeoffreyHuntley You're missing the bigger point - the technical reasons are true but the thing they Chose not to do, is to try to work together to make something better. Instead they need to justify why They're Right and No One Else Is

bun being ported from zig to rust? github.com/oven-sh/bun/bl…

@anaisbetts @ZackMaril @GeoffreyHuntley Why would an implementation that has a chance of giving you non-deterministic builds be viable to be upstreamed? Type resolution in bun's zig version is closely linked to ordering in sema. fwiw, I dont agree with their general AI stance either, but I like deterministic builds.

@James_Elicx @ZackMaril @GeoffreyHuntley Nah this reply really gives away the real game here - they've decided to view Bun as competition, rather than someone who was actively trying to help them out, and their constant painting of Bun as "sloppy hacked in changes" shows how they intend to work with others

@ZackMaril @GeoffreyHuntley @anaisbetts That's mostly nonsense if you read Matthew's reply on the topic - ziggit.dev/t/bun-s-zig-fo… The actual explanation as to why their changes wouldn't be easily upstreamable makes a lot of sense when you consider the implications of the quick fix rather than a long-term solution

@GeoffreyHuntley @anaisbetts Bun tried to upstream some LLM generated code last week to Zig, Zig authors rejected on the ground of absolutely no LLM code, Bun said they now have an internal fork of Zig. So, assuming Rust doesn’t have a no LLM clause, then makes sense to at least explore a switch.

@ryanjhunter @threepointone @wireless_anon Do you have a reproduction you can share for this one? Haven't heard of a wasm chunks issue before

@threepointone @wireless_anon yea I was getting a ton of issues w/ wasm_ chunks last night, trying to port an old vercel project to pages. wasn't able to make heads or tails of it since all wasm and waaay too late in the night to go down a wasmhole

I was suspicious that next.js was duplicating modules inside generated chunks for edge-functions/middleware so I asked chatgpt to write a script that would find the longest common string inside a file ran it on the generated chunk and it spit out the minified code for react 😳 looks to be fixed v15, but definitely a problem in v14 also damn chatgpt, you'd pass an interview in a "legacy" tech company so easily

@wireless_anon @threepointone Ah, I remember this. There was actually an issue opened a couple weeks ago about it too, and a user left a response yesterday about the multiple version problem... Dario was trying a hack around it with a mutex, but it ended up not working for the issue opener. Good old Next.js.

@flybayer @nextjs I disagree with the ratings you gave for complexity. It depends on where you're deploying. i.e. Managing infra for deploying Next.js to AWS is a lot more complex than Cloudflare Pages. They should be Low-High. Would be nice to see Cloudflare's adapter included in your blog post

NEW POST: Secret knowledge to self-host @nextjs "It's easy to host!" "No it's not!" It seems no one can agree, so I've put together a mostly comprehensive post to settle this once and for all. The Problems: 🔴 Serverless Next.js is not officially supported outside Vercel 🔴 Server hosting via 'next start' is not production ready out of the box This article covers everything you need to escape Vercel. Link in next tweet

After 2 years of research, two beta releases and countless hours of R&D, the @solid_js Team is proud to announce the release of SolidStart 1.0! 🚀🎉 SolidStart has already made an impact on the broader JS community. We’re excited to see what’s next. solidjs.com/blog/solid-sta…

@jonbeckman @kasvith @Cloudflare Our recommendation is to use the Next.js dev server (and this is mentioned in the docs as well). What is making the DX worse?

@kasvith @Cloudflare Yeah, but you have to use their next-on-pages cli which takes the magic out of using NextJS natively. Meaning the DX is worse. I switched my app to Nuxt in a day for a much better DX experience in Cloudflare.

Anyone tried @Cloudflare pages for NextJS deployment? (Non static)

@samgoodwin89 @HamedMamdoohii What problems were you running into?

@HamedMamdoohii Tried it, ran into all sorts of problems and went back to SST's OpenNext on AWS. Looking FWD to OpenNext on CF.

Tried SST Ion over the weekend. Looks good! Nice to not have CloudFormation in the way. Was surprised by no NextJS in CloudFlare. Thought that existed already. Not sure how I feel about straddling AWS and CloudFlare.

@oljimenez @ImSh4yy @MattIPv4 @rauchg @nextjs The problem with Next.js ISR is that it can only be built to Node.js functions and doesn't support outputting as edge functions, so it would not be possible to deploy and use them purely on Cloudflare in their current state. see our docs for more context: #incremental-static-regeneration" target="_blank" rel="nofollow noopener">github.com/cloudflare/nex…

@ImSh4yy @MattIPv4 @rauchg @nextjs Seems like ISR need durable objects + tag cache control revalidation. In theory you could achieve the same in Cloudflare Enterprise and some custom configuration.

This is not a Cloudflare problem. A less black-boxed framework would let you set granular cache control headers for ISR. Most CDNs also provide a purge endpoint that can be used for on-demand revalidation. Web standards usually get you most of the way there and aren’t locked to a specific platform.

@AdamRackis D1 is another option with a free tier. Looks like it'll be a promising bet after beta, although it probably still needs to prove out its reliability in production workloads over extended time periods. The only thing that has me a little uneasy is the database size limits...

You're using Serverless now. Yay! You need a db that's available via http. Choices are: PlanetScale for MySQL (no free plan) Neon for Postgres (past uptime problems, and apparently it cold starts sometimes?!?!) Mongo Atlas And probably others but ... fuck.

The PlanetScale thing really put a damper on Serverless for me. Using PlanetScale for a side project is like chartering a G-4 for a 2 hour flight to Key West for you and your wife. Nice but, kinda overkill. So why would you? You need http drivers. But why? Because Serverless.

@wesbos We're actually injecting the ALS logic and then wrapping the entry point for the worker we build as we're doing this in the next-on-pages adapter. So it's all something that we've implemented under the hood in the adapter. #L36" target="_blank" rel="nofollow noopener">github.com/cloudflare/nex… #L14" target="_blank" rel="nofollow noopener">github.com/cloudflare/nex…

@James_Elicx oh that's a great idea - then you don't have to even modify the function from what it would be in Node. Do you expose them via a middleware like I did?

I find it sort of annoying that cloudflare workers doesn't have globally available environmental variables. Having to pass worker context into every function that needs an API key is a bit slow. I fixed it AsyncLocalStorage in a middlware. Is this a good idea?

@codingtomato @housecor IIRC, Next.js changed RSC payload requests to use a search param in order to fix the `vary` header issue with CDNs.

@housecor If it's for a client, traditional SPA with Next.js benefits as the support for Pages router is more mature. I had an awful experience with next-intl and the App Router because Cloudflare didn't handle the vary http header as Next.js was expecting.

Imagine you’re building a React app. How do you decide between these two options: 1. Traditional SPA 2. React Server Components (RSC) SPA benefits: ✅ Proven and mature. ✅ Lets us use more of the React ecosystem of third party libraries. ✅ Simple. Easy to understand. ✅ Cheaper and easier to host. RSC benefits: ✅ Likely renders the first page faster. ✅ Likely saves bandwidth (each RSC adds zero K to bundle). ✅ Use heavy libraries solely on the server to save bandwidth ✅ Requires less code for data fetching (may even call the DB directly instead of hitting an API). Given these tradeoffs, if we already have a REST/GraphQL API, or we want cheap, simple hosting, I lean toward SPA. If we don’t have a web API, or performance is critical, I lean toward RSC.

@armandodlvr86 @CloudflareDev It already is.

@CloudflareDev When are you planning to support NextJS 14? (app dir / RSC)

Deploying a Next.js site with Cloudflare Pages? Here's all you need to get started: npm create cloudflare@latest my-next-app -- --framework=next Check out our updated guide with updated instructions to help you develop full-stack Next,js apps! cfl.re/3SohRlw

Finally got around to writing my first blog post -- An Introduction to Component Composition, by Example. eli.cx/blog/an-introd…

@samgoodwin89 @thdxr @devagrawal09 @dougmoscrop Have you opened a GitHub issue with your problem on the next-on-pages repo? It's generally helpful when people flag issues they run into so we can investigate and try to fix them...

@thdxr @devagrawal09 @dougmoscrop Also, I tried their Next JS tooling and it failed miserably. Went back to SST. Are you also working on OpenNext for CF?

@samgoodwin89 @devagrawal09 @dougmoscrop i’ve been doing everything through iac and it’s been good so far but haven’t gone deep my perspective is going to be off because the surface area is so much smaller than aws that it immediately feels 100x better by comparison

@FivesTech Please open an issue in the next-on-pages Github repository with a reproduction if they aren't working for you...

そういえばCloudflare PagesでNext.jsのServer Actionsが動かなかったんだよな... Next.jsをフルサポートできるエッジランタイムってVercel以外無いんじゃね？

In the next version of Bun bun:test gets support for expect(...).toHaveBeenCalledWith(...) and expect(...).toHaveBeenLastCalledWith(...), thanks to @James_Elicx