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? 😉