Frontend development for a side project: choosing the right stack

Let's talk about web integration, HTML, CSS, and frontend development.

In this post, I'll detail the Coderwatch implementation choices, focusing only on the frontend.

So I'm going to talk about technology choices and frameworks.

To set the context, this post is part of a mini-series about creating a side project.

If you haven't read the first ones, my goal is to describe all the steps for creating a relatively simple application:

www.coderwatch.io: allowing you to learn programming languages and frameworks while playing. You can take quizzes, earn points, and gradually climb the rankings against other players while improving your knowledge.

From now on, each post will also include a status update on Coderwatch—the number of users and important metrics.

Posts in this series:

• How to build a side project, step 1: the idea
• How a developer tackles the design phase: my workflow with Figma and Procreate
• Frontend development for a side project: choosing the right stack

In the previous post, I created a model with Figma, and now we have to roll up our sleeves to integrate it into HTML/CSS.

HTML/CSS integration: with or without a framework?

EDIT 2025: It's really funny to reread this article with hindsight. We're now in 2025, and I approach these same problems so differently now. To see how I would do it today, I invite you to read the last chapter.

First, I'd like to say that I'm more of a backend developer and haven't developed my skills as an integrator in the past. So what I'm going to describe here is really the approach of a backend developer who wants to develop a side project and has to compromise between state of the art and learning curve.

Because the whole objective of this challenge is to touch every aspect of application creation while controlling costs and time.

For context, I follow Benjamin Code's YouTube channel, and he's rather in favor of doing without CSS frameworks, which have an unfortunate tendency to be quite heavy for sometimes little added value, or are even counterproductive because they don't use the latest language features.

You can find his full pitch here (sorry, it's in French): https://www.youtube.com/watch?v=77hwpuVHGps

So I tried to apply his advice by using TailwindCSS first. It's a framework that stands out from others because it only offers utility classes, no components.

(This isn't completely true though, because there's tailwindui.com which offers galleries of paid components.)

But the basic idea is that you can do anything with just the utility library.

To be honest, it was quite painful. It's rather unpleasant to pollute your HTML so much, and it requires some fundamentals that I didn't have at that time. Coding the responsive menu, using flexboxes—all that was too much for a start.

So I changed my mind pretty quickly.

However, I kept the idea of finding a fairly lightweight, component-oriented framework from which I could import only what interested me, without JavaScript and with simple responsive considerations.

And you know what? There are many of them, and trying them all can quickly become a time sink!

However, I ended up with Bulma:

• No JavaScript included
• Modular
• Has components
• Built to be customized through an intelligent variable system
• Has a large number of utility classes

A single-page application with Vue.js

Ideally, for a SaaS, the best dev setup in my opinion is a frontend made with a JS framework and a backend that only serves APIs. This isn't always possible for SEO reasons, and I'll come back to this in a future post dedicated to SEO. But for Coderwatch, it seemed completely suitable.

The choice of Vue.js was quite natural for me. I could certainly have looked at React, Solid, or Svelte, but we already use Vue.js at Malt with no regrets. The framework is very powerful, very easy to pick up, and has a strong online community for finding help.

However, I hesitated with Nuxt.js, which is a layer on top of Vue 3 with support for backend development and advanced features such as server-side rendering. However, backend development in JavaScript didn't appeal to me too much. I'll come back to this in a future post about the backend.

With Vue.js, I use:

• vue-router for page routing
• Pinia for state management (I had started with Vuex initially)

The build: a JavaScript stack pain point

I might make some JS experts cringe on this point, but for a non-specialist, the build is an indescribable pain to start with.

There are a multitude of tools in each category:

• Package managers: npm, pnpm, yarn
• Tooling: webpack, gulp, vite, parcel, etc.

Many tools have overlaps; some are sometimes used together.

And when you look for docs online, it's hell because you always find docs either on the wrong version that doesn't work, or docs with the wrong tool combination, or with a different tool.

To illustrate: I started at a time when Vue.js changed its official major version. I started with a config that officially changed the following week. Upgrading and finding the right documentation was a nightmare.

Another example: I didn't set up TypeScript support at first. I thought it would be easy to add later. I ended up spending 2 weeks struggling in a working branch to get TypeScript working.

And I'm not even talking about the number of times you have to struggle to figure out why an npm install doesn't work due to a conflicting library. It's manual work to understand the version expected by one library or another.

Personally, I come from the Java world with a tool that, in my opinion, changed things radically in 2004: Maven.

Maven came as a replacement for Ant and offers a standardized build. Ant allows you to do everything with a lot of flexibility (like Gradle today?), but at the expense of standardization.

When a dev goes from one Maven project to another, even with several versions apart, they're always comfortable. They don't have to learn much.

From my perspective, with a novice eye, JavaScript suffers from having very powerful tools, but too numerous, with rapidly evolving versions that very often aren't compatible, with so much flexibility that it becomes very complex to find the right configuration at the beginning—but above all, it's hell to evolve.

Positive personal experience with web integration

I probably wouldn't have said this a few years ago, but in the end, I really enjoyed this HTML/CSS integration phase.

I learned a lot about the flexbox system, clip paths, component modularization, CSS animations, positioning, etc.

This step lasted about a week (still in evening and weekend mode) for about twenty pages. At the end of this week, I felt much more comfortable and wanted to progress more.

If we forget the tooling, it was really fun to work on this part, to build pages and funnels, and to gradually see the result appear.

EDIT: How to approach frontend development in 2025

This section is an addition to the original article. I've progressed a lot, but the entire frontend ecosystem has also changed.

Today, I don't ask myself the question anymore. I systematically start with Nuxt 4 and Nuxt UI. Nuxt UI provides a set of reusable and customizable components. Tailwind is used by default and allows you to transform the base components.

It's now very simple to get a fairly professional rendering starting from a standard library.

The build is also simpler—or maybe I've just progressed a lot. That's also a possibility :)

Weekly metrics on Coderwatch

The official launch was 2 weeks ago. The player count is 33, and I saw an increase that day with the first article in this series. However, the rate of new users is quite low (and 99% are in France).

The number of quizzes played is 39, which implies that several players played only once without returning.

No users came via referral, and only 3 questions were created by players.

In short, for now the game has attracted almost only curious followers, and we can't say it has found its product-market fit.

But it's certainly not at this stage that we should give up—the reverse would have been a surprise.

Three users gave me precise and interesting feedback on their journeys, and I note a few limiting elements for properly introducing the game in the first moments of registration.

The question I'm going to have to decide from now on is: should I focus on improving the game to turn current users into regular players and get them to promote it, or do I need to focus on gaining traffic?

Wait and see.

See you soon.