JavaScript community trends in 2022

David Bonnemaison
iAdvize Engineering
6 min readJul 19, 2022

I was lucky enough to be part of the team sent by iAdvize to the 2022 editions of the JSNation and ReactSummit conferences, in Amsterdam. Over there, we listened to dozens of talks, discussed with developers from around the world, and got a good sense of where the community was headed this year — and maybe the few next years, too. Here are five of the topics that were discussed the most, and got our attention.

Inside the JSNation hangar

1. The rise of meta-frameworks

Meta-frameworks, sometimes referred to as “full-stack frameworks”, seem to be very popular. They are built around the major “frontend frameworks” : React has Next.js and more recently Remix, Vue has Nuxt, Svelte has SvelteKit, ... They all provide solutions to common problems, such as routing or server-side rendering with client-side hydration. Interestingly, they are all able to run on the edge, even if the main targeted runtime is NodeJS. Their major selling points are performance and developer experience, which are, admittedly, usually at odds.

At iAdvize, we mostly rely on static assets served on CDNs : we measured that for most of our web apps, the cost and complexity of server side rendering was not worth the potential performance gain. One exception is the Aploze team, who uses Next.js for their live shopping web app.

Noteworthy talks :

The JSNation hangar : no cloud, not even on the edge

2. Dev tools in the cloud

The general idea of dev tools in the cloud is that dev tools don’t have to run on the developer’s machine. Builds, for instance, can be run on a remote server, then cached for all users for a given version (Nx calls it “Computation Caching”, turborepo “Remote Caching” — both are also monorepo tools).

Whole dev environments can also be run remotely : that’s what CodeSandbox is trying to achieve with Projects. When an environment is run remotely, it becomes easier to add real-time collaboration on the codebase and instant deployments for every branch. CodeSandbox Projects run in VMs in the cloud, and have an interface either in the browser, or integrated into VSCode.

There is another way to start a dev environment in the browser : StackBlitz and their WebContainers. That’s what the Svelte team decided to go with for their online tutorial, where you can have a server-side rendered Svelte app that runs entirely in your browser, server included, with instant reload. As long as you have an internet connection, you could even have a full dev environment on an iPad or a Chromebook.

Noteworthy talks :

3. JavaScript evolution and TypeScript hegemony

There were interesting discussions about the language itself. The excellent talk about JS Modules by Yulia Startsev (Mozilla) confirmed that even though browser support is good, JS Modules alone are not a viable option for large applications, due to network latency (every module is fetched at runtime). The Record and Tuple proposal feels very natural, especially for those like us who like to work with immutable data structures in a functional way. At iAdvize, we rely on fp-ts for functional programming in TypeScript.

Although there wasn’t any talk focused on TypeScript, we could feel that it was on everyone’s mind. Interestingly, TypeScript seems to be the obvious, default choice for everyone — but it still looks to be a bit scary to many of us. Some talks had types in their coding examples, and the speakers didn’t feel the need to explicitly explain what they were : types are now ubiquitous and expected.

Noteworthy talks :

TypeScript can still be slightly misused

4. Design Systems and React component libraries

One could think that components and component libraries are a solved problem : they definitely are not. Usually part of a larger Design System, they are still hard to implement : discussions revolved around the ideas of composition vs. configuration, flexibility vs. consistency, or whether a Design System was needed at all. The “spectrum of flexibility” concept is interesting :

I really liked the idea of “not ejecting” expressed by Sid Kshetrapal (Github) , which I understood as “not giving up control” over what is allowed to be rendered. Instead of allowing any component as a prop (in his example, a renderItem: React.ComponentType), we can leverage composition to achieve the same level of flexibility. From his slides :

❌ Using inversion of control for maximum flexibility, “ejecting” from the responsibility of what can be rendered
❌ Using a very strict API, predictable but limiting
✅ Using composition, allowing some flexibility while remaining predictable enough

iAdvize has its own Design System. On the flexibility spectrum, I think we are near the middle, leaning on the left (strict) side. It makes sense that a private component library is more strict and closed than a public one, as we favor predictability (easy to work with, easy to onboard new developers) over flexibility (we are our only client).

Noteworthy talks :

5. Core skills

Not all talks were focused on technical implementation : two of them were notably about Core skills — a term coined by Iris Schaffer (Spotify), to refer to what we usually call “soft skills”. Iris talked about how we can grow as engineers, how to keep expanding the value we add to the company, while still growing as individuals. Kyle Simpson (“You don’t know JS” author) refreshingly talked to us about his impostor syndrome, stating that we are all professional impostors in some way, and that it is okay. It reminded me of this 2018 blog post by Dan Abramov : we sometimes need to remember that we don’t have to be experts at everything.

Noteworthy talks :

Kyle Simpson, on being a professional impostor

Huge thanks to everyone at iAdvize who made attending these conferences possible.

--

--