Notes

Revisiting Remix

OK, Remix, I feel seen:

I’m certain there are a lot of you out there who are seeing the excitement around Remix and thinking: “Ugh, I’m not ready for something new … stuff changes too fast!” Learning how to solve the same problems but with a different API is exhausting. The worst part is feeling like all the deep knowledge I have with my current tools is now obsolete, and I’m a beginner all over again. That is exhausting.

I voiced just this sentiment late last year, when I first learned about Remix. One of my frustrations with the current JavaScript-dominated frontend landscape is just how disposable our tooling, and by extension, or knowledge, is. I’ve gained a deep understanding of Next.js over the last couple years. Some of that is transferable, like learning how server-side rendering and hydration work, but mostly I’ve just memorized proprietary APIs. And when we move on to the next framework? That’ll all be left behind.

But Remix sounds a bit different:

When you work in Remix, you’re mostly working with standard web APIs. […] This knowledge will not just help you build great user experiences in Remix, but it will help you outside of Remix today and in the future.

I love this! Learn Remix and you’ll learn the web platform.

Ryan frames the benefits in terms of personal knowledge. But your future self will thank you in more ways than one. Tools that align themselves with web standards have a lower “cost of opinion”, which means in turn that the cost of shedding them, which you will invariably do, is lower. More on that in a future note.

Site design: Media queries

One thing I wanted to try with this site was to build it without any media queries. (Specifically, without ones testing viewport size.) Binding layout to screen dimensions is usually an anti-pattern, and in 2021 it’s more-often-than-not just unnecessary. (Jen Simmons, Andy Bell, and Heydon Pickering demonstrate these points beautifully.)

I didn’t quite succeed. The header bar occupied too much of the screen on small devices as a sticky container, so I positioned it statically under such conditions. But that’s it. Otherwise, this site rearranges and scales elements based on just a few suggestions I’ve passed to the browser via display: flex; flex-wrap: wrap; and clamp(). 😊

More on Matt Webb’s Rules for Blogging

Elsewhere Matt says: “do write regularly, otherwise each post becomes an event”. When you have a baby in your life, any time invested in yourself feels like an event! I’m not sure it’ll be otherwise for some time, so I’ll just have to accept this one for now and post what I can, when I can. Calling these “notes” was for just this reason: there shouldn’t be pressure to ever say anything substantial. Just jot a quick thought down and publish it.

Matt Webb’s Rules for Blogging

Posting here regularly is hard. Matt Webb’s personal rules for blogging are a hand on my shoulder and a push out the door:

No hedging, no nuance. If I’m getting in a twist about a sentence, take it out. […] Give up on attempting to be right. […] Give up on trying to be popular. […] Only write what’s in my head at that exact moment. It’s 10x faster. […] If it’s taking too long to write, stop.

The dream of the post beloved by all is a regular nemesis of mine. Individual posts to any online platform—even to one with an audience of exactly one—carry the twin weights of permanence and exposure. If I don’t bury any idea I share in qualifiers, won’t opinions be affixed to me forever, assumed to be held with complete certainty? Neither my genuine inquisitiveness nor my unfortunate craving for the approval of others makes me comfortable with strong, potentially controversial, statements. And so, without care, every other sentence begins with “But” or “That said”.

Lots of Matt’s rules are around giving yourself permission to take an inchoate idea, run with it for awhile, then just publish it and move on. Like many people, I write to think, but doing so for myself and doing so when I think there’s an audience yields very different writing styles. A blog should be somewhere in between, but closer to the former. A place to loosely and regularly process ideas, but also a place where this is done in the open on the off-chance that a kindred spirit may some day pass through and find value.

JavaScript churn

It’s come up at work that we need to evaluate Remix soon. It looks compelling, no doubt, but I can’t help but sigh. It was only a year ago that we moved to Next.js. There is so much churn in the JavaScript world, where the one right way to do things today is the absolute wrong way to do things tomorrow. As JavaScript has come to consume the entire stack for many frontend developers, we’ve had to accept change as a constant with our tools and obsolencense as an ever-present threat if we aren’t constantly upgrading dependencies. This is dramatically different from the pace at which the web platform changes, and the mirror opposite of how browsers (are supposed to) treat outdated features of frontend languages. (Consider the community response to Chrome’s surprise deprecation of alert().)

My reaction to hearing about Remix stemmed partly from it coming on the heels of migrating 27,000 lines of SCSS to CSS-in-JS on a large React application. I’d been reluctant to take this on though it’d been under discussion for a couple years, but we’d liked using component styles on more recent projects and it felt necessary to keep the codebase current and more approachable to junior developers. It may turn out to be the right (or at least necessary) decision yet. But Sass was arguably the most stable part of the codebase. As we’ve done more generally by adopting CSS-in-JS, we traded away a language we’ve worked in for close to a decade, and that has hardly changed in that time, for a rotating cast of novel attempts to ”solve” CSS for JavaScript applications.

The feature sets and APIs of some of these libraries—we tried out Styled Components, Emotion, and Linaria—is similar enough that one could probably move between them easily if needed. But if you’re gonna do CSS-in-JS you really have to commit to it; unlike with writing in Sass, which could involve as much or as little actual Sass as you wanted and could just be CSS, there’s no way to casually move between vanilla CSS and JavaScript strings or objects. You’re stuck with how the library tells you to write styles.

The endless churn of JavaScript-based tooling has me hankering for the stability found in working with the raw materials of the web—HTML, CSS, and vanilla JS. No dependencies. No build tools. It’s a pipe dream, I know. (But maybe not so far from reality?) I have a nagging urge to at least rescue what parts of the stack I can from all this “disruption”. Beginning with CSS. Maybe our team can solve the problems that we need solving with just CSS Modules. And with @layer and scoped styles coming down the pike, maybe CSS will solve these things itself soon enough. #usetheplatform—isn’t that what the Remix folks say anyway? 😉

ANUSTART

WTF is The Dana Zone?? This whole business started a year ago when I traded in my old phone. Typically impulsive, I failed to do due diligence before handing over the device and didn’t back up my 2FA accounts. (For those who don’t know, these are tied to just one physical device.) Fortunately you can usually use some other means to recover access to your online accounts and the re-set up 2FA, which is what I painstakingly proceeded to do. Except when I went to recover access to Amazon Web Services and saw that I needed to receive a code at my old Sloop Creative email address, and remembered that that address hadn’t successfully received an email in at least a year. Probably just a misconfigured MX record, but I’d never actually looked into it.

AWS was where I managed the domain and hosting for my personal website and numerous other sites and files as well. Realizing that losing access to my account would mean being unable to renew these domains, I reached out to AWS support hoping for another solution. But numerous emails and phone calls later, I’d accomplished nothing, just a ping pong ball being swatted back and forth between the security folks and the account folks because neither actually had any authority to address the issue at hand. Ultimately I just decided to abandon the account—no mere mortal was going to navigate this bureaucratic labyrinth.

I’m really not sure what all will disappear from the web when the bills stop getting paid. danajohnson.co will be gone. But I’m fine with that. I never really liked the domain name anyway. Every time I looked at it, I was just reminded that the domain I’d actually wanted—just a single letter away—wasn’t available. And I’d stopped updating it two years back, stuck in the middle of a Jekyll-to-Eleventy migration and with a stodgy and dull design I’d grown bored of. Maybe it was time for a shot in the arm to finally finish the migration and update the design. And that’s where dana.zone was born. The design’s not quite there, but I’ve migrated the old content over and shifted the focus from trying to get work to just being a space to think, write, and share dumb screenshots. It feels nice to finally be able to put finger to key again and throw a quick note up on ye old personal website.

Using the platform

I really like this post by Elise Hein on trying to build a stackless website. We’re so used to transpilers these days that how many of us really know how far we can get just using ES6 modules? I like that Elise is enthusiastic about the potential here without showing a hint of puritanism or naïveté. In most cases, we still need to transpile code. And web components just aren’t where they need to be yet to really challenge the dominant UI frameworks. But there’s value in returning to the bare platform to see and appreciate just how much we get for free nowadays.

Trying out variable fonts

The site update felt like a good opportunity to finally try out variable fonts.

I’ve gone with a lovely open-source one called Recursive, which besides the standard axes like weight and slant has a custom sans-to-mono axis and one called “casual”. Fantastic!

Micropublish

Set up a micropub endpoint for my site today using indiekit! I’m up and running as well with Micropublish, a simple client for posting notes to that endpoint. With that, I no longer need to open a markdown editor, compose a note (with proper YAML frontmatter), commit it, and push that commit to my GitHub repo (all of which more or less requires me to be at my computer). Now I just open Micropublish from anywhere, compose a note, and post it 🙌

Tadanori Yokoo

Tadanori Yokoo print going up in the apartment.

A framed print depicting stills of actor Ken Takakura from four films.