Frontend styling, moving from CSS to a better solution

[kgelpes]

We're using pure CSS right now, without naming conventions like BEM or dividing style files into CSS modules.
The problem with our approach right now is that is hard to maintain, hard to scale, hard to theme, can have naming conflicts, has a bigger bundle size and it's a worse dev experience.

I propose we consider some solutions like:

• SCSS
• CSS modules
• CSS-in-JS (styled components, emotion, etc)
• Keep using CSS, but enforce naming conventions like BEM
• CSS utility libraries like tailwind

If we agree that this is a problem, we can then decide what is the best solution for our needs. Personally I'm partial to CSS-in-JS with emotion, but of course all of the solutions have their pros and cons.

[0x4007]

BEM seems interesting. I haven't heard about it before

I actually deliberately removed tailwind sometime ago when we were axing several technologies from our stack (including hardhat, and many other frameworks) in order to simplify things.

It's really important to maximize developer onboarding speed given the nature of our project (the DevPool) so we err on the side of less prerequisite technologies to master before one can contribute.

Perhaps I'm biased but I feel that raw CSS is the fastest for quick changes because the changes can be done directly in the inspect tools UI and then saved/written to disk

If it is an issue to scale the UI design, then I think we should aim to keep the embedded UI within this monorepo to be minimal and then maybe eventually in the future create a separate UI that's more fancy. In this way, perhaps we can get by without adding more prerequisite technologies to master to contribute to the UI, aside from TypeScript/React.

More on the idea related to making the UI code minimal, but some time ago I experimented with dynamic UI generation based on contract ABIs. Perhaps that could be a useful tool for rapid development.

[kgelpes]

Taking into account that onboarding devs and not adding unnecessary complexity to the project I believe our best option is to use SCSS modules and enforce BEM naming conventions for class names.

SCSS is supported by default on NextJS, just need to yarn add the package.

Doing this change wouldn't affect our current styles, and we can still copy paste from the browser inspector.

Ideally I think the folder structure would look like this for components:

Button/
├── index.tsx
└── ButtonStyles.module.scss

The Button's index.tsx file would import ButtonStyles.module.scss. All the specific styles for the button would be contained there so we don't risk having styles in other parts of the application clashing. NextJS will minimize and split to always serve the least only the necessary code to the client.

Additionally, SCSS allows us to use CSS variables, nesting, etc. Just overall a better development experience, can save us from visual bugs.

We can also go the CSS modules route, without SCSS, if we want to keep just pure CSS on our codebase.

[0x4007]

This looks like a well thought out response; I appreciate your consideration.

enforce BEM naming conventions for class names.

Perhaps we could use a linter for enforcing this.

We can also go the CSS modules route, without SCSS, if we want to keep just pure CSS on our codebase.

I am partial towards pure CSS unless if I hear from a handful of other active UI developers on our project to consider another framework.

[kgelpes]

It would be a great start to move to css modules, by dividing css up into different files it will be much better organized and less prone to collisions. Also gives us the advantage of having less merge conflicts.

Then we can create another task to move to BEM conventions use stylelint to enforce them

[0x4007]

I'm still not convinced on the necessity of this initiative. Surely its nice to organize the CSS but ubiquity.css, the main stylesheet, is only 653 lines of code, which is about 122 selectors.

You're free to propose a split into modules but I'd imagine that it could be more tedious for the next UI developer to sift through tens of files with only a few selectors in each.