I joined Mastodon. I’d read others hyping the early-days-of-Twitter energy there, the hum of an emerging community for web people. I didn’t want to miss out!
One week in though, it just hasn’t stuck. Maybe that shouldn’t come as a surprise: I never got into Twitter, so it’s not like I have some well of nostalgia to draw from.
I think what is comes down to is that, like Robin and Luke, I have timeline fatigue. I just don’t find an endless wall of unrelated posts energizing or inviting these days. I find it draining, in fact. (That I have a compulsive need to scroll through every post doesn’t help.)
I love my RSS feed. There are always new things to see there, yet I never feel overwhelmed. I can read as I am able, and if there are things I never get to, that’s just fine. Posts vary in length, but are always of substance, not proscribed to any arbitrary character limit.
I am still excited by the early 2000’s vibes afoot. It’s a unique moment to form new ways of relating online. Those who are enjoying Mastodon should absolutely continue do so, but, to echo Robin, I also hope we can think bigger than what is happening there. “Nothing is settled.”
For now, I’ll stick with RSS. Heck, everyone I follow on Mastodon already has a blog anyway!
Breaking up with CSS-in-JS
I’d been working and re-working a post for some time on my falling out with CSS-in-JS, particularly Emotion and Styled Components, but I think this article from Sam Megura says nearly everything I wanted to, and with data to back up their claims. Basically the cost to users (in runtime performance) of these libraries outweighs their DX benefits.
I would add one more general criticism, which is that these libraries are way too opinionated. It’s not just the wild idea of writing all your CSS in JS template literals. It’s that they dictate how CSS is loaded in the browser (e.g. as a bunch of <style> tags). And that they are incompatible with established configuration and build tools like browserslist, autoprefixer, postcss, and webpack. I’ve come to much prefer the humble tool that solve one or two problems and leave others to do the rest. (CSS Modules comes to mind as one example.) Such tools acknowledge implicitly that not all developers or projects have the same needs, that offramps are necessary and don’t have to be painful, and that gradual progress and consensus are preferable to moving fast and breaking things.
Priority of constituencies; or, one way to evaluate a library
When evaluating a library or framework for possible adoption, the “priority of constituencies” principle can be one useful frame. That’s the one from the HTML Working Group that states:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
The purpose of basically all frontend libraries is to make the developer’s life easier. Some gap exists between the intention and the actual implementation of the Web platform, and a library comes along that tries to fill it. (I’m riffing off of Dmitri Glazkov here.) This is all well and good—paving the cowpaths and whatnot—but a library created to impact the developer’s experience will invariably, whether directly or not, be felt by the user. And the more opinonated the tool, the more negative that impact is likely to be. That effect can come in the form of larger bundle sizes, more security vulnerabilities, or diminished reliability due to increased complexity.
I see manyfrontendlibraries that generate a ton of buzz for their DX either be silent on the issue of UX or suggest that their incredible DX will have trickle-down benefits for users. It’s important to be honest about who these tools are primarily for: developers. There is nothing inherently wrong with that fact. The priority of constituencies principle doesn’t say that DX is unimportant. It only states that the experience of the user matters more.
So if you’re trying out a new library or framework, take a hard look at what its impact on users will be. Is there actual benefit? Is the impact at least net neutral? Don’t assess based on the author’s word alone. (But do try to gauge where the author’s priorities are at; you’re going for a long ride with them, aren’t you?) And maybe choose something that’s not too opinionated. Your users (and your future self) will thank you.
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.