I liked a lot about nextjs, but its fundamental page building & publishing model seemed awkward to me.

Specifically, the publishing workflow for non-developers just didn’t seem to be a good fit. That’s an important use case for me as I was hoping to use nextjs for some CMS-based sites for “normal” people (not developers).

I loved the great performance I got from a nextjs static site, but that depended on static builds. I knew it wouldn’t fly if I told normal users to wait for new builds after publishing. As leaky abstractions go, that’s a significant one.

I thought incremental static rendering (ISR) might be a good solution after that, but next's ISR caching model just wasn’t right for me, either. I want options like invalidating the whole cache at once when pages are published. Instead, ISR’s happy path is to use time-based invalidation. Not a good fit. I could write lower-level code to invalidate individual pages, but that’s also not quite what I need.

That left me with just a plain SSR solution and no built-in caching. That could have been ok, but it didn’t excite me that much -- and it meant accepting some of the awkwardness of next's page model without really getting more than its most basic benefits.

That awkwardness of not really fitting my needs was one of the weak spots I found in nextjs. It left me open to finding another solution that was a better fit.

I've switched the framework for this site to remix. I was using nextjs before, but I was frustrated by a couple of things and I think remix offers a better solution for my use case. I'll write more about those issues soon. So far I'm really liking remix, though.