Discussion: Migrate Away from styled-components Due to Package Entering Maintenance Mode

[cherylli]

What do we need to build or fix?
We need to discuss and plan the migration away from styled-components, which is now in maintenance mode.
Although there's no immediate need to migrate away from it, continuing to rely on it poses long-term risks in terms of support, compatibility with new React/Next.js features, and community adoption.

Technical details
The goal is to identify and adopt a styling solution that:

• Works seamlessly with our current tech stack (e.g. Next.js, App Router)
• Provides better developer experience (DX), performance, and maintainability

Approach suggestions
Please research alternative styling solutions that are actively maintained and align with our tech stack and long-term goals.

Bring your findings to this discussion, including pros and cons of options like Tailwind CSS, CSS Modules, Panda CSS, Vanilla Extract, etc.

We’ll use this issue to weigh trade-offs and agree on a direction before starting any migration work.

Acceptance criteria

This is a discussion issue

[cherylli]

@Satoshi-Sh @LuSilvaDeveloper @Web-Dev-Path/project-managers-and-scrum-masters

[cherylli]

Safest option is probably back to CSS Modules with sass (what we had before), but we need to figure out theming with it (or do we need theming? since we really only have 1 theme)

[Satoshi-Sh]

I personally enjoy using Tailwind.css, but it makes more sense to go back to the CSS Modules with Sass here. Maintaining a project is quite a task. 😅

[oluwatobiss]

Here are some advantages Tailwind and CSS Modules have over one another:

Tailwind

• Faster development: Tailwind allows style composition on the go (while developing the UIs).
• Faster UI maintenance: Having styles directly on each UI makes understanding and maintaining each element’s style faster than switching between files to find the styles.
• No names to invent: Tailwind allows you to focus on creating beautiful designs rather than considering the name to assign to an element.
• Predefined designs: Tailwind’s inbuilt design features make moving from concept to implementation faster.

CSS Module

• Future proof: There’s that essential confidence that we are using a tool that will not suddenly go into maintenance mode.
• Reusability: CSS modules allow using the same style in multiple modules or for various elements. (The Tailwind workaround for this can be messy and strenuous to maintain).
• Neater: The separation of concern between markup and styling prevents clustering components with multiple utility classes.
• Control: CSS modules give total control of every aspect of the design. There is no marketing agenda luring you to purchase pro features. You have total control over how you want to move from concept to implementation.

I have recently been having fun exploring Tailwind’s possibilities. However, since Web Dev Path is transitioning to the service phase, using CSS Module looks appropriate for the website. CSS Module is a safe and stable option that could help developers devote more time to new projects rather than keeping up with the latest version of styling tools for the Web Dev Path website.

[cherylli]

I guess another advantage of going back to what we have is we could just "reverse" what we did here #159 #162

[cherylli]

Maybe we can do both at the same time, file by file -
convert back to CSS modules
add typescript to the file

First we will start with setting up typescript #236 , then using typescript, CSS modules in the new service page, then migrating the older pages

[LuSilvaDeveloper]

Adding to the discussion, since @oluwatobiss already mentioned CSS Module and Tailwind, I'd like to add another library to the discussion, which is:

Emotion CSS

Pros:

• Similar API to Styled-Components, making migration and adoption easy.

• Improved performance: smaller bundle and faster runtime than Styled-Components, with built-in SSR support and caching.

• Flexible styling methods (string or object syntax, css prop) to suit different preferences.

• Good TypeScript support and theming capabilities.

• Widely used in industry, ensuring good community support and longevity.

Cons:

• Still has runtime overhead – injecting styles via JS, which is less optimal than pure CSS for initial load.

• Requires some setup for Next.js App Router SSR (no one-line config; you must implement a server-side style collection similar to SC’s)

• If overused, it can increase bundle size due to styles included in JavaScript (though using the Babel plugin can mitigate this by extracting some static styles).

Debugging styles might require looking at generated class names (Emotion adds labels to help, but it’s not as straightforward as just inspecting a CSS file).

My personal opinion:

Tailwind has some stability, a huge community, and it is easy to set up with TypeScript. It has easy integration with Next.js and App Router. If we are looking for faster development, in my opinion, Tailwind is an excellent choice.

The CSS Module is a great choice if we are looking for a future-proof solution with great performance, thanks to the JS runtime for styles, static CSS extraction at build, and built-in support for Next.js and App Router.

[cherylli]

Tailwind has some stability, a huge community, and it is easy to set up with TypeScript. It has easy integration with Next.js and App Router. If we are looking for faster development, in my opinion, Tailwind is an excellent choice.

Tailwind is nice and very popular but we'll have to rewrite everything, with Emotion and other js-in-css, the migration would be a lot more straightforward. This would be a big factor for consideration.

[LuSilvaDeveloper]

Yes. Probably for our case, my opinion is to go for CSS Modules. In that way, we won't have to worry about migrating away from it again in the future

[briangesteban]

Next.js is not my area of expertise, I am currently learning and adapting to it. I am not entirely sure why CSS Modules and styled-components are the preferred choices for styling in the project. However, based on my research, experimentation, and understanding, I believe it is because, in collaborative environments, especially for larger projects, class name collisions can occur. That’s why CSS Modules are utilized, while styled-components are used to manage theming feature (dark/light).

If I may suggest, we could just use Global SCSS + BEM(Blocks, Elements, and Modifiers) Methodology instead. I believe this approach will effectively prevent class name collisions and support theming. Additionally, it aligns with our current goals.

Global SCSS + BEM Methodology

Pros

• Easy to learn and adapt: No need to learn new technologies, and only needs knowledge of CSS/SCSS.
• Supports Component Theming.
• Non-verbose Class Assignment and Names: Uses plain, short, and descriptive class names without the need of CSS modules syntax.
• Clarity: Maintains separation of concerns, as all styling is contained in an SCSS file.
• Independent of other libraries, packages, or frameworks: Only SCSS is required.
• No installation needed: BEM is simply a naming convention for HTML classes.
• BEM Methodology works well with SCSS.

Cons

• Initially might be confusing to some developers, but it's less likely to occur.
• No pre-defined classes, unlike using other UI Libraries or frameworks.

This method allows us to implement theming using a hybrid of CSS and SCSS variables. It could be applied to a Client Component Wrapper or by individual components. Additionally, it could be implemented sooner without the risk of TypeScript compatibility issues as it's just a regular pre-processed CSS.

This approach is completely customizable, scalable, and maintainable. The only major downside(for me) is, there's no pre-defined classes to help fast-track the project development, if we are aiming for that.