My Tech Stack for 2024

This is my preferred tech stack for 2024 when it comes to new web projects. It is completely opinion-based after years of actively using a lot of different options in real yet bootstrapped web applications with small teams of developers, where overall simplicity is essential to limit the bus factor.

These are the layers I’m dividing the stack into. For every layer I’ll list my preferred alternatives:

Note: I mostly created this division based on relevance and ease of writing, and not necessarily on technical aspects. Some frameworks or libraries expand to several layers.

Layer 1: CSS framework / UI component library

  • Tailwind CSS: Perfect to simplify the CSS gibberish if you are not a fan of CSS. Widely used too and promotes consistency through the use of custom UI components.
  • Flowbite: Nice addition to Tailwind CSS when basic UI components (buttons, forms, etc.) are needed. For some of them you don’t even need any dependency, you can just copy-paste the HTML with the long list of easily customizable Tailwind classes, just like with HyperUI.
  • daisyUI: Also based on Tailwind CSS, it’s a great alternative to Flowbite if you prefer fully pre-made component classes that abstract you from Tailwind classes (i.e. you can use <button class="btn">Button</button> directly and it will look great).
  • Quasar: Quasar includes an extensive list of incredibly feature-complete UI components based on Vue, so when a complex interactive UI is needed where I can use pre-made components, and the rest of the required stack is feasible, Quasar is my productivity hero. It negates the need for any other dependency for layers 2 and 3, as Quasar covers layers 1 to 3.

Layer 2: Front-end framework

  • Astro: Not every project needs React, Vue or Svelte. When the client is not highly interactive or an MPA is acceptable, I leverage Astro’s native components with standard Web Components. Together with View Transitions, you can even make it feel like an SPA.
  • Vue: I find React unnecessarily complex, so I tend to avoid it if I can. Both Svelte and SvelteKit are moving towards being more similar to React and Next, so my interest on them is decreasing. I find that Vue has the best balance between ease of use, innovation and stability.
  • Quasar: As mentioned on layer 1, Quasar uses Vue for the front-end, and you can use it both in SPA or SSR mode with hydration.

Layer 3: Back-end / meta-framework

  • Astro: If the project architecture is simple enough, Astro also works well for both Static Site Generation and Server Side Rendering, and it’s easy to create API endpoints. It also serves as an essential DX CLI tool (npx astro dev).
  • Quasar: With Quasar it’s also easy to create Node/Express-like API endpoints in the same codebase, although you’ll need to configure API proxying. Similarly to Astro, it also serves as an essential DX CLI tool (npx quasar dev).

Both Astro’s and Quasar’s CLI tools are based on the excellent Vite build tool by Evan You, creator of Vue (yet another reason in my books to choose Vue for layer 2 🙂).

Layer 4: Authentication

  • No library: I have to admit that I have used my own implementation for basic email and password authentication before. It’s not difficult to implement it safely if you follow best practices such as the Password Storage Cheat Sheet.
  • Lucia: The reason I used no auth library in the past is because Auth0 and Clerk are expensive, Passport had undocumented quirks that didn’t instill any confidence in me, and Next Auth was similarly messy. Thank goodness that now Lucia exists to fill the great void.

Layer 5: Database and ORM

  • MongoDB: I have used NoSQL for so many applications where SQL was objetively better, yet I still didn’t encounter any ocassion where using MongoDB had any negative impact on the final user experience.
  • Drizzle: However my preferred choice these days is to use a managed MySQL or PostgreSQL wrapped with Drizzle ORM. I prefer it over Kysely because of Kysely’s stubborness to not support relationships, and Prisma is so cool yet it introduces so much latency.

Layer 6: Hosting / infrastructure

  • Github: Git and Github are just the obvious choice to host your codebase, specially now with free private repositories.
  • Vercel: Vercel is also the obvious choice right now for deploying any backend framework or static site because of both its pricing and ease of use, including support for basically all libraries, framework and services mentioned in this article. They also now provide a wide amalgam of services such as databases and cron jobs, which is very convenient if you are already using Vercel and want to simplify the amount of providers you are using.
  • MongoDB Atlas: Obvious choice to host the database if using MongoDB, free pricing available etc., and it includes serverless options.

Other alternatives worth mentioning:

  • Render: All-in-one service to deploy any runtime, framework or database. Free tier available.
  • Railway: Similar to Render but maybe more modern and slick. No free tier available though.
  • Fly: Closest alternative to Heroku with a free tier.
  • PlanetScale: Managed serverless MySQL. Very performant but doesn’t support foreign keys (on purpose).
  • Neon: Managed serverless PostgreSQL. Also availabe through Vercel Postgres.
  • Upstash: Managed serverless Redis. Also availabe through Vercel KV.
Published on Feb 5, 2024. Updated on Jun 4, 2024.