Yes, friends, once again we’re going to go through a few instances of folderol, borderline fulmination, and perhaps foolishness about developing stuff for Ye Olde Webbe.
Update, 2021-04-15: After an initial miscommunication gave me the wrong impression about the thinking higher up, I learned that I won’t be doing the Next.js-related Day Job work mentioned below, after all. However, I’m leaving this post as-is for archival purposes and for the sake of transparency.
Uniform CSS: Sass + utility-first
No sooner did I write my most recent post, which was about the continuing appeal of the Sass CSS preprocessor even in this time when the utility-first CSS approach seems to be exploding in popularity, than I discovered to my surprise that there’s about to be a marriage of the two . . .
Uniform CSS looks very similar to the highly touted Tailwind CSS, but the interesting part is that Uniform CSS is built entirely in Sass. It’s promoted as producing smaller final CSS than most other competing frameworks. Note that the Uniform CSS website, GitHub repo, and documentation are all in pre-release form at this writing (e.g., the npm package isn’t up to date with what’s in the repo). In the meantime, Uniform CSS has a Codepen playground where you can give it a try.
Speaking of Tailwind, more on that in a bit.
Next.js needs Vercel
In the Day Job, I’ve begun work on rebuilding my employer’s websites in Vercel’s Next.js framework (yes, I got approval for what I mentioned in “Next steps?”). A word to the wise: while Next.js is superb and getting better all the time, you should use it with Vercel’s website hosting if at all possible. Some of Next’s coolest features, notably the image optimization features introduced last year, really need Vercel’s special back-end tooling to work their best — or, in some cases, at all.1 (You’ll find a disquieting number of related posts on Stack Overflow, among other places.)
Since the environment I’m using for the Day Job work is based in a very-much-not-Vercel hosting platform and that choice (not mine) is non-negotiable, that leaves me somewhat higher and drier than I’d hoped to be. For now, I’m running the image processing through Cloudinary’s free tier and excellent React component. Whether we can stay within the free tier once we go to production is TBD, but I’ll cross that mined bridge when I come to it.
Major algorithm change due in May from Google
Just a quick reminder for you: sometime next month, Google will make a significant change in its search algorithm, as first announced last November. I suggest you read that linked article to learn not only (a.) how this change will focus Google even more on “rewarding” better-performing sites but also (b.) some ways you can make sure your site is (and/or remains) one of them.
The utility of . . . utility
Oh, yes, about Tailwind . . .
In “Speaking up for Sass,” I (foot)noted that one of the reasons I’d moved this site off Tailwind CSS and back to Sass was because, in that aforementioned Day Job web dev work, I’d picked Sass for the styling and didn’t want to be jumping back and forth between one method at work and another at home. The reason I’d selected Sass was because I felt that, when my inevitable successor takes over the code base, it would be better for him/her if we hadn’t chosen a Styling Flavor of the Month.
However, in the days since, I’ve continued to research the choice. I’ve found that, increasingly, dev team leads are encouraging adoption of utility-first CSS, exactly for the purpose of making it easier for successors to take over existing code. These advocates’ shared point is that, for someone new to a code base, it’s easier to figure out how to make changes if one doesn’t have to worry about all the existing interrelationships among the base’s various web pages and styling cascades.
While my choice of Sass combined with CSS Modules was intended to minimize such problems, I re-considered it in light of this argument and realized that I’d best listen to the experts. So I’m refactoring the Next.js-based work to use Tailwind — especially with the new JIT functionality that’s now built into Tailwind core — and, thus, have also taken this site back to Tailwind.2
I guess they’re not kidding around with that top-of-screen message in the Next.js website: “Deploy on the platform made for Next.js.” ↩︎
Or, at least that was the case as of the original publication of this post. However, after the Day Job’s about-face that I mentioned at the top, I no longer had that as a reason to use Tailwind; so I reverted the site’s styling to Sass, which I find easier to manage. I know Tailwind fans will find that hard to believe, but that’s how it is. ↩︎