Postponing the App Router adoption by Cardinal

[ernestoresende]

I’ve tried to make this work for Cardinal as long as possible, but it’s got to a point where is really hard to justify App Router adoption as the primary recommendation for Next.js scaffolded apps at this moment.

While I’m still not doing any word spreading about the project other than eventually mentioning it in some developer community circles, shipping production ready software has been one of the core tenants of the project from the very start. After dealing with the App Router adoption history for the largest part of the last two months, I cannot responsibly recommend and/or endorse the usage of the new router pattern. At least not yet.

This seems to be a common theme between library authors. GraphQL clients still haven’t completely figured out how the Server Component story plays out for them. The same is true for tRPC. Pilcrow has been constantly jumping over hoops to make Lucia's Next.js middleware work with all of the Route Handler and Route Segment limitations. On the developer usage side, we already have well known bottlenecks in development performance, and platitude of reported bugs on the next issues panel.

Next.js felt like a very natural first step for Cardinal as it encompassed the description of a framework that handles both server and client tasks, but trying to provide a good base point for Next.js apps with the App Router is actively blocking me from moving on to work on supporting other frameworks and deployment providers.

Calling the App Router and the underlying implementation of React Server Components “stable” from the state it was in 13.4.0 until now was, in my personal opinion, a mistake. I don’t hate the concept, nor do I completely hate the implementation. I truly believe in a future where this architecture can play a very importante role on the way we build for the web. But the entire ecosystem (React, Next.js/Vercel, library authors and app developers) still has to cover a lot of ground before we can do that with acceptable levels of trust that our entire ecosystem can stand on its own feet without suffering of death by a thousand cuts. As it is now, supporting the App Router means dedicating an unrealistic ammount of time at making sure these patterns work on their entirety, and it will only get worse as I aim at other deployment options that are not called Vercel.

The work on Next.js based apps scaffolded by Cardinal will now be focused on normalizing app behavior for the Pages Router, and setting the ground for revisiting the App Router in the (hopefully near) future. This will also give us the opportunity of segmenting the scaffolding offer, meaning users will get the choice between scaffolding their apps using React Server Components or not. And giving users the choice about technologies that their apps get scaffolded with aligns very tightly with Cardinal’s vision, so I'll count this aspect as a net positive.