Zoe’s Amaryllis, January 2022Zoe’s Amaryllis, January 2022

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.

I'm moving the backend of this site to the sanity.io headless CMS. The old backend used markdown files in a git repository, and I wanted something I could easily use on my phone. (This site's frontend is still using next.js, which has been great.)

More importantly, I wanted to explore using sanity as the backend for some other sites I've been building and hosting for other people. I've been looking at a few candidates for replacing Perch, and so far sanity seems to be a great alternative. I also (mostly) love the idea of using a SaaS so I don't have to host it myself.

So far I've been really impressed with sanity. It's definitely a developer-focused CMS, so it requires coding to get up & running, but it's been incredibly easy to get started with. And querying for data from my nextjs frontend has been refreshingly straightforward.

Finally switched this site to Tailwind CSS. I've been using tailwind at work for about 2 years now, and it has been great. Have been wanting to switch this site, too. Finally did it.

If you take average risks you will, by definition, get average results.

Instead of minimizing risk, I instead like Jeff Bezos’ pursuance of regret minimization. Of the paths that you can take, which path will most likely result in the least regret later in life?

-- Steph Smith

Ferns unfolding outside of Lake George, NYFerns unfolding outside of Lake George, NY

Interesting new game development library, kaboom.js. Aimed at making it easy for kids & other beginners to learn game development, but looks really nice for general use as well. Or at least for prototyping game ideas.

I can't wait to try it out!

Found via twoseparate posts on Hacker News.

"Small b blogging" from Tom Critchlow:

As Venkatesh says in the calculus of grit - release work often, reference your own thinking & rework the same ideas again and again. That’s the small b blogging model.

At work I keep seeing cases where there is overlap in common behavior but not completely. Special cases take a simple routine and wrench it through with conditions.

With React components, it’s often easy enough to split out the separate cases as their own components or, more recently, maybe push the differing behavior into individual hooks.

Some of the uglier cases are in Redux reducers, action creator functions, or async API-calling code. These functions start small and simple, but as the requirements grow and change over time these streamlined functions quickly grow branches, and those conditions then grow their own complexities in due time. Eventually it becomes a dense forest of possible code paths where bugs grow freely.

I’ve been trying to tame some of those areas recently by simply trying to separate what is common from what is different. A wonderful benefit of doing that is being able to clearly see what is different just from how the code is structured.

I’ve come to look at significant branching as a code smell, and try to refactor so that the branching happens once, up front, where you pick from a handful of top-level functions or objects that themselves are focused & single-purpose. I think that insight came from Sandi Metz & her 99 Bottles book; it’s an enormously powerful tool, and so far has been a great help.

Interestingly, Javascript’s prototypal inheritance is quite well suited for this kind of thing.

< Older