> ## Content Index > Fetch the complete content index at: https://broddin.be/llms.txt > Use this file to discover other available public pages before exploring further. # My 2022 (mostly frontend) programming stack - URL: https://broddin.be/my-2022-mostly-frontend-programming-stack/ - Published: 2022-05-23T11:54:17.000Z - Updated: 2026-07-19T19:05:06.000Z - Author: Tim Broddin - Tags: javascript, programming, stack, #wordpress, #Import 2024-02-03 13:15, #broddin, #Migrated-1784487752640, #wp, #wp-post, #Import 2026-07-19 19:02 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](https://nextjs.org/?ref=broddin.be) ever since I saw [Guillermo Rauch](https://twitter.com/rauchg?ref=broddin.be) 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](https://swc.rs/?ref=broddin.be)), and fast for the user (thanks to the static generation). Look at [Woordje](https://www.woordje.be/?ref=broddin.be) & [Wannabes](https://www.wannabes.be/?ref=broddin.be). Both load **instantly**, even though Wannabes has a very slow Meteor backend powering it (though a GraphQL bridge). I’ve been watching [Remix](https://remix.run/?ref=broddin.be) closely, but I’ve yet to find a real advantage to using it over Next.js. I’ve also dabbled with [SvelteKit](https://kit.svelte.dev/?ref=broddin.be) 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](https://www.typescriptlang.org/?ref=broddin.be) 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. ### CMS: DatoCMS There are tons of headless CMS’es, but about a year ago, I settled on [DatoCMS](https://www.datocms.com/?ref=broddin.be). 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](https://wannabes.be/?ref=broddin.be) backend, but it’s just too expensive, even with the 50% price reduction for non-profits. I’ve been eyeing [Strapi](https://strapi.io/?ref=broddin.be) 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](https://redux-toolkit.js.org/?ref=broddin.be), 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](https://github.com/immerjs/immer?ref=broddin.be) 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](https://github.com/rt2zz/redux-persist?ref=broddin.be). 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](https://github.com/pmndrs/zustand?ref=broddin.be) and [jotai](https://jotai.org/?ref=broddin.be) on my radar, but Redux does the job. ### GraphQL: graphql-request, swr & graphql-codegen I love the **versatility** of GraphQL. I’ve used **apollo-clien**t 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](https://www.graphql-code-generator.com/?ref=broddin.be) auto-generate the proper TypeScript types and [SWR](https://swr.vercel.app/?ref=broddin.be) hooks. [It’s magic](https://www.the-guild.dev/blog/graphql-codegen-plugin-typescript-swr?ref=broddin.be). 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](https://woordje.be/?ref=broddin.be)), I jumped ship to stitches. [NextUI](https://nextui.org/?ref=broddin.be), 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](https://stitches.dev/?ref=broddin.be). 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](https://www.framer.com/motion/?ref=broddin.be) 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](https://web.dev/progressive-web-apps/?ref=broddin.be) **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](https://vercel.com/?ref=broddin.be). 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](https://www.hetzner.com/?ref=broddin.be) 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](https://www.prisma.io/?ref=broddin.be), an ambitious JS/TS **ORM**, together with [PlanetScale](https://planetscale.com/?ref=broddin.be). 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](https://copilot.github.com/?ref=broddin.be), 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](https://plausible.io/?ref=broddin.be). It’s not free, but your users’ privacy is worth it. ## Conclusion 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.