5 min read

My 2022 (mostly frontend) programming stack

My 2022 (mostly frontend) programming stack

This post is a post that’s been in my draft folder for way too long. I’ve wanted to write about my current programming stack for a while. This post is an overview of all the languages, frameworks, services, and tools I’ve been using in 2022.

Where I come from

More than 20 years ago, I started experimenting with PHP, HTML, and CSS. Since then, I’ve used and dismissed lots of technologies. I remember how a hassle it was to write (cross-browser) JavaScript before jQuery came along. I’ve also seen the rise and fall of some pretty big frameworks such as Angular and Meteor.

Damn, I’m starting to get old.

I was a big fan of Meteor, even with all its shortcomings. Meteor is a full-stack framework that offers real-time data updates out-of-the-box. I’ve yet to find a framework that makes it this easy to set up a proof-of-concept, complete with a backend database. But it’s a pain to deploy, it’s a pain to upgrade, and it’s way too slow.

I’ve been around long enough to start seeing some patterns. I’m now able to restrain myself from jumping on every hype train. But I still jump on quite some because progress still makes me excited like a little kid.

My 2022 stack

Framework: Next.js

I’ve been using Next.js ever since I saw Guillermo Rauch introduce it at ReactiveConf. It’s my go-to React framework. I love the routing, the incremental static regeneration, the serverless functions, and the fact that it leaves you free to plug in whatever other technologies you want to use (such as CSS-in-JS solutions).

And it’s fast. Very fast. Fast for me as a developer (thanks to SWC), and fast for the user (thanks to the static generation). Look at Woordje & Wannabes. Both load instantly, even though Wannabes has a very slow Meteor backend powering it (though a GraphQL bridge).

I’ve been watching Remix closely, but I’ve yet to find a real advantage to using it over Next.js. I’ve also dabbled with SvelteKit for a small project, and I loved it, but I guess I’m too invested in the React ecosystem.

Language: TypeScript

This one is new for me. For a long time, I didn’t think I needed type checking. I was under the impression that you only required type checking when working on big-ass projects with a giant team. I couldn’t be more wrong.

Since about two months ago (after Woordje), I started using TypeScript on all my new projects. The advantages TypeScript brings to DX are enormous. It saves me a lot of time.

Only disadvantage: I still have some learning to do. Thinking about stuff like generics still gives me a tiny headache. But all beginnings are hard.


There are tons of headless CMS’es, but about a year ago, I settled on DatoCMS. It allows you to create models (item types) easily and has rock-solid media management. Best of all: it makes a GraphQL API for you.

Too bad it’s pretty expensive for hobby projects. We’ve been thinking about using it to replace our aging Wannabes backend, but it’s just too expensive, even with the 50% price reduction for non-profits.

I’ve been eyeing Strapi for quite some time. It’s an open-source CMS that offers many of the same functionalities. They’re making good progress, so maybe next year, this section will say Strapi.

State management: Redux-toolkit + Redux-persist

When React introduced the useContext hook, many people assumed Redux would be done. But it kept evolving. They created Redux-toolkit, an opinionated framework on top of Redux that adds some default middleware (redux-thunk & devtools) and adds slices, which are reducers and action creators in one. It also uses Immer under the hood, which allows you to mutate your state without actually mutating it. Sweet.

In almost every project where I use Redux, I also use Redux-persist. This middleware persists the state to IndexedDB or localStorage so that the state is preserved across browser reloads and visits.

Middleware is what makes Redux still a viable option in 2022 for me. Middleware and the devtools, I love being able to time-travel through state updates.

There are some hip newer libraries such as zustand and jotai on my radar, but Redux does the job.

GraphQL: graphql-request, swr & graphql-codegen

I love the versatility of GraphQL. I’ve used apollo-client to talk to GraphQL servers in the past, but it’s just too complex. It tries to do too much, even wanting to store all your local state. While there must be use-cases for this added complexity, I’ve yet to face them.

My current workflow is writing my GraphQL queries and letting graphql-codegen auto-generate the proper TypeScript types and SWR hooks. It’s magic.

I still use apollo-server for setting up a GraphQL server since that still seems the best option.

CSS-in-JS: stitches

I’ve been using styled-components a lot in the past. Recently (with Woordje), I jumped ship to stitches. NextUI, the beautiful component library used by Woordje, uses it, and I didn’t want to ship two separate styling libraries.

By using it, I quickly saw the advantages of stitches. Using tokens and variants is much cleaner than injecting props in a string literal. And every property and value is type-checked, which is fantastic for someone who makes a lot of typos.

Animation: framer-motion

I’ve been using framer-motion for a couple of years now, and it does everything I need from an animation library.

Mobile: React Native / PWA

I’ve created some native mobile apps in the past, and I’ve mainly used React Native. It’s easy, cross-platform, and you don’t need to learn a new language.

Most significant pain: upgrading to new versions. I have a nice mobile app that’s 90% finished that’s sitting on my hard drive for over two years, and the biggest thing that’s keeping me from finishing it is the amount of work I have to put into just getting it to run again.

I hope and pray that Apple will one day make progressive web apps first-class citizens on iOS. There’s nothing modern web technology can’t do compared to native. The only thing that’s keeping it back is propper support from Apple.

Hosting: Vercel / Lambda / Docker

The most obvious choice to host when you create Next.js apps is Vercel. I like the ease of pushing to a Git branch and getting a preview deployment. Their free plan is also very generous.

For some (non-Next.js) projects, I use AWS Lambda and custom Docker containers deployed to a cheap Hetzner VPS.

Databases: Prisma & PlanetScale

I was forced to use MongoDB, a NoSQL database, during my Meteor days. At first, I was like, “woooohooo, no more database scheme!”. But as time went on, I started to miss many things from relational databases. I missed things like, well, proper relations, a powerful query language like SQL, and an enforced database scheme.

When I need to create a custom data store, I use Prisma, an ambitious JS/TS ORM, together with PlanetScale. The latter is a MySQL-compatible serverless database with a very generous free plan.

Editor: VSCode

I’ve tried many editors in the past, free and paid, but I stuck with VSCode. It’s fast and easily extendible.

I also use Github Copilot, an insane witchcraft magic AI that suggests code while I type. It’s insane how good the suggestions it makes can be.

Analytics: Plausible

I’m not too fond of cookie consent forms, and I’m not a big fan of Google Analytics. That’s why I use Plausible. It’s not free, but your users’ privacy is worth it.


I plan on doing a post like this every year from now on. I’m intrigued at how things will change in the near & not-so-near future.