Post

the premise is either "nothing happens" or "show the next page's loading shell" - but there exist other ways to solve the problem without either of those (imo) flawed approaches. this is one core motivation of my upcoming rsc framework.

@ricky.fm put a lot of effort into solving and communicating this problem with the async client stuff (hint: pending states!), so I know I'm not alone in feeling this way.

0 reposts1 like

i see! i’d say the post intro describes two ends of the spectrum, but the actual model described in the post is more flexible. it’s more like ability to enforce which navigations have no async gap. having a guarantee like this is important, especially if routes need to work offline or w/ bad latency

I agree, the instant navigation is an interesting mechanism – this is effectively closing the "SPA" gap that the app router hasn't historically supported (where the whole router is navigable without internet). But it's still focused on shells and loading states, when I think that's missing the mark

Next and my framework are ultimately building for ever so slightly divergent use cases and mental models. I'm excited to share my ideas though, I believe I have some interesting stuff packed in here.

note re: shells, they can have real content with "use cache"d stuff. it tags along, extending the shell