Frontend Predictions for 2022
Thoughts on what we might see in the coming year, including the return of micro-frontends, functional JavaScript & the demise of the Jamstack as we know it.
I’m a software engineer living and working in East London. I’m currently helping to build a one-stop-shop for the digitisation of alternative assets over at Daphne. Although once strictly front-end, today I work across the whole stack, including dipping my toes into DevOps and writing Rust & Go.
Over the last few weeks we’ve heard all kinds of predictions about the upcoming year, including those given by podcasts ShopTalk and Syntax. Instead of re-iterating what’s already been said, here’s a few extras I think we’ll be hearing more about throughout 2022.
The return of micro-frontends
You’d be forgiven for thinking micro-frontends were a flash in the pan, one that started and ended sometime back in 2019. However, after attending several frontend conferences this year (such as React Advanced), I actually found the opposite. [1]
Speaking to colleagues and others in the industry, it seems as though everyone’s spent the last few years actually implementing micro-frontends, exploring the pain points and working on libraries, tooling and standardisation. [2] Now, several years on, everyone’s ready to share (or commiserate).
Even if you don’t see it by name, the idea of tech-agnostic frontends being conjoined in a spec-defined manner (i.e. web components, the fabled HTML imports etc.) is definitely in the water.
Thoughtworks has even suggested we might see a renewed interest in the mobile space, with a lean towards React Native apps, despite the largely unsuccessful attempts by frameworks such as Atlas and Beehive in the past.
I suspect throughout 2022 we’ll start hearing a lot more about micro-frontends again, especially now they’ve enjoyed some time in the wild.
The death of the Jamstack
Don’t panic, the Jamstack isn’t going anywhere. After all, an entire market has been built around it, complete with services, conferences and even specialist agencies.
Like most jargon that came before it (see PWA), the Jamstack is about marketing. Every decision, be it technological or architectural, needs to be sold to someone, and naming something builds momentum and eases adoption.
Unfortunately, today the term is so meaningless I’m convinced it does more harm than good. Even Matt Biilmann, co-founder of Netlify, has remarked on the ever creeping scope:
As the Jamstack evolves, new features like dynamic server side rendering, rehydration, tiered CDN caching, and stale while revalidate seem to be creeping us back towards all the complexity we fought to escape.
The popularity and adoption of techniques such as incremental-static-regeneration (ISR) and serverless functions continue to muddy the waters — after all, if your 11ty site can have dynamically built server-rendered pages (potentially using non-deterministic data) is it a Jamstack site? Or, as Zack himself has joked, is it just PHP?
Some claim that immutability is the secret-sauce, and that ISR — aside from pushing compilation to the edge — results in disqualification. Others claim that a static site isn’t a Jamstack site unless it’s hosted on a CDN. Some, such as Chris Ferdinandi, suggest a more permissive definition, but ultimately come back to it being a primarily client-side affair.
I think in 2022 we’ll see the confusion and exhaustion culminate in a gradual retreat from the term — at least by those without a vested financial interest.
A refocusing on progressive enhancement
Throughout 2021 we’ve seen JavaScript frameworks shift their focus from strictly client-side experiences to becoming invisible implementation details.
Remix prides itself on working (interactivity and all) without JavaScript, leveraging a traditional form-based approach over client-side shenanigans. Similarly, frameworks such as Astro have been encouraging partial hydration and the islands architecture, preferring to lazily ‘enhance’ components and fall back to sensible no-JS defaults.
All this while Server-Components continue to bubble away in the background.
It’s great to see a return to web-fundamentals, and I’m confident we’ll see this continue throughout 2022.
A cautious return to functional JavaScript
A couple of years ago libraries such as Ramda, Folktale and the fp variant of Lodash were all the rage. Curries and Maybe’s galore.
While the devout still swear by them, a lack of first-class support and a less-than-stellar debugging experience led to a gradual weaning for many.
It’s early days, but I think in late-2022 we’ll start to renewed interest in more traditionally ‘functional’ concepts due the advancement of the new pipeline operator, which promises to bring a more approachable and native version of pipe/flow/compose.
Check out James DiGioia’s excellent overview for more details.
In summary
Last year was full of exciting developments, including our first look at container queries and the evolution of frameworks such as Next.js and Remix (something I’d hoped we’d see). After what felt like a period of JavaScript stagnation, it’s great to see a refocusing on web fundamentals and the platform continue to evolve.
Despite the inevitable outpouring of new tools and libraries, it’s beginning to feel as though the ecosystem is finally starting to converge on a set of best-practises and architectures, taking learnings from ideas both new and old.
I can’t wait to see what’s next.
Specific talks included those by Ruben Casas from American Express and Alex Lobera from Hopin, but the subject was broached far more than the schedule suggests.↩︎
In reality it’s a small (but vocal) minority. In the same way that most small/medium projects don’t need microservices, micro-frontends are likely to remain a niche technique for the large and vertically-sliced.↩︎