Inertia

I’ve always like Jeremy’s categorization of developer tools:

I’ve mentioned two categories of tools for web development. I still don’t know quite what to call these categories. Internal and external? Developer-facing and user-facing?

The first category covers things like build tools, version control, transpilers, pre-processers, and linters. These are tools that live on your machine—or on the server—taking what you’ve written and transforming it into the raw materials of the web: HTML, CSS, and JavaScript.

The second category of tools are those that are made of the raw materials of the web: CSS frameworks and JavaScript libraries.

It’s a good way to think about things. There is nuance though, naturally. Sass is the first category since Sass never goes to users, it only makes CSS that goes to users. But it can still affect users because it could make CSS that is larger or smaller based on how you use it.

Jeremy mentions Svelte as a library where the goal is essentially compiling as much of itself away as it can before code goes to users. Some JavaScript is still there, but it doesn’t include the overhead of a developer-facing API. The nuance here is that Svelte can be used in such a way that all JavaScript is removed entirely. For example, SvelteKit can turn off it’s hydration entirely and do pre-rendering of pages, making a site that entirely JavaScript-free (or at least only opting in to it where you ask for it).

On React:

I know there are ways of getting React to behave more like a category one tool, but it is most definitely not the default behaviour. And default behaviour really, really matters. For React, the default behaviour is to assume all the code you write—and the tool you use to write it—will be sent over the wire to end users.

I think that’s fair to say, but it also seems like the story is slowly starting to change. I would think widespread usage is far off, but Server Components seem notable here because they are coming from the React team itself, just like SvelteKit is from the Svelte team itself.

And on Astro:

[…] unlike Svelte, Astro allows you to use the same syntax as the incumbent, React. So if you’ve learned React—because that’s what you needed to learn to get a job—you don’t have to learn a new syntax in order to use Astro.

I know you probably can’t take an existing React site and convert it to Astro with the flip of a switch, but at least there’s a clear upgrade path.

This isn’t just theoretically true, it’s demonstrably true!

I just converted our little serverless microsite from Gatsby to Astro. Gastby is React-based, so all the componentry is already built as React components. The Pull Request is messy but it’s here. I converted some of it to .astro files, but left a lot of the componentry largely untouched as .jsx React components. But React does not ship on the site to users. JavaScript is almost entirely removed from the site, save for some hand-written vanilla JavaScript for very light interactivity.

So there is some coin-flipping stuff happening here. Coin merging? Astro to me feels very much like a developer-facing tool. It helps me. It uses the Vite compiler and is super fast and pleasant to work with (Astro has rough edges, for sure, as it’s pre 1.0, but the DX is largely there). It scopes my styles. It lets me write SCSS. It lets me write components (in many different frameworks). But it also helps the user here. No more JavaScript bundle on the site at all.

I guess that means Astro doesn’t change the categories—it’s a developer-facing tool. It just happens to take what would be a user-facing tool (even Svelte) and makes them almost entirely developer-facing.

And just because I’ve had a couple of other Astro links burning a hole in my pocket, Flavio has a good intro tutorial and here’s Drew McLellan and Matthew Phillips chatting Astro on a recent Smashing Podcast.

CSS-Tricks

Change vs. Inertia

Recently, I’ve become more deeply aware of the inherent tension between change and inertia, as it applies to the evolution and use of web technologies. These forces have always been present and opposed to each other, but it seems to me that the side effects of these collisions are impacting web development more noticeably.

On one hand, we’ve never seen more progress in the expansion of the array of web platform capabilities; the web is powerful and mature in ways that our 10-year younger selves would be seriously envious of. But on the other hand, like the crisp fall winds signal a seasonal shift, there’s a chill in the air settling down the once feverish pace of new JavaScript features—hello, JavaScript fatigue!—and new JavaScript frameworks seemingly launching weekly.

Technology is a word that describes something that doesn’t work yet.

Douglas Adams

As Adams’s humorous quip might imply, the software (technology) we work on doesn’t work yet, because it (and everything around it!) is always changing and evolving to something better.

Or… so it has seemed for a long time. But from where I peek out at web community trends, I think our community is shifting from the rapid expansion of the past few years to a season of consolidation and establishment.

There seems to be an expected assumption that any web team or project must stack itself on top of Babel, Webpack, TypeScript, JSX for the markup, styled-components (or CSS-in-JS of some sort), and one of just a handful of JavaScript frameworks (like React, Vue, or Angular).

That’s not to say these are the only options. I know there’s the Jamstack crowd who’s increasingly embracing static-site generation, and I know there’s the upstart Svelte crowd who wants to compile away all that front-end framework complexity (or so they claim).

But let’s be honest: the “diversity” we see in front-end framework tech now is more surface than substance. They all use some flavor of component-oriented mechanics (based on some kind of virtualized DOM), and with each new release of each framework, the parity between them is only increasing. We’ll see this space continue its contraction over the next few years, I think, to where the best parts of Svelte are built into React, and vice versa.

What will all this consolidation mean for the pace of change of JavaScript, or CSS, or even HTML itself? Will the core web platform technologies keep growing as they have, or will the demand for these changes subdue as developers stop asking for more and focus instead on doing more with what they’ve already got.

Is front-end tech almost solved? For my whole career, we’ve been assuming that every few years we’ll see a wholesale reinvention of the front end, on that ever-constant search for the perfect framework that rules them all. Are we nearing that point?

What’s clear to me is that the community is favoring inertia over change right now. What does work works so well—why should we rock the ship and try to disrupt and re-invent? The sheer brilliance (paired with countless human decades of blood sweat and tears) that has created the amazing front-end tools and frameworks might have finally done a good enough job that we don’t collectively care to keep asking it to do more.

Can you imagine trying to launch a competitor to React or Vue right now? Can you imagine trying to build a different tool to unseat TypeScript¹? It sure seems like a daunting enough hill that’s probably not worth trying to climb.

The big players have drawn in all the attention of millions of web developers worldwide, and they survived the heated change-fest over the last five years. We’re now settling on those few options that are left, as plenty powerful enough to build what we want. These solutions may not be idealist absolute maximums, but they’re undoubtedly approaching (at least) local maximums.

With the craziness we’ve all faced down in this weird year of 2020, maybe deep down in our guts, we’re all just yearning for some boring, stable, predictable comfort. Maybe that’s at least in part reflecting in our technology choices!?

I’ve been betting on change for, quite frankly, nearly two decades of my career in web technology. But I think my bet might be shifting to the predictability of inertia. We should assume that the default will be to stick to what you know already works rather than constantly looking for what might be emerging next.

Where’s your bet?

In the case of TypeScript, I certainly can. I’ve been trying to do that for more than a year!

The post Change vs. Inertia appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

Design Lance

Latest trends in arts and design

Tag: Inertia

Change vs. Inertia