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.
source https://css-tricks.com/change-vs-inertia/
No comments:
Post a Comment