DEV Community

loading...

CSS for large projects

Neha Sharma
UI Engineer ,I love Web,JavaScript, Design System, A11Y, HTML5, CSS3 ,React; Community Advocate and enjoy giving talks and codelabs at the Meetups and conference. I am self-taught calligrapher too.
Updated on ・4 min read

CSS for large projects

This is the content I prepared for my youtube channel's video.

Here is the link

Agenda:

  1. Why CSS Architecture matter?

  2. What are the options

  3. How to decide?

  4. Explanations

Why CSS architecture matters?

Most developers just focus on JavaScript or its family. As a result, they ignore the styling of the application. Yes, logic is important but look-n-feel is also equally important. As a result, developers end up with messy CSS code which is non-maintainable and non-scalable.

What are the options?

and many more.

How to decide?

In the end, all the above options produce CSS at the build time. To explain how to architect the CSS for bigger projects I will skip all the frameworks and libs such as tailwind, bootstrap, etc. otherwise I will end up offending someone :).

To understand the architecture, I will go with SCSS (as developers can use SCSS in HTML/JS, Angular, React, Vue, anywhere.)

So, how do decide which way to go? Look for:

1) Maintainability

2) Scalability

3) Reusability

4) Ease to learn, and setup (basically DX)

Pre-work, before writing a single line of code (or checklist):

[ ] Which Naming convention to followed?

[ ] List of browsers with their version, operating systems, mobile and tablets with their operating system to support

[ ] List of breakpoints

[ ] Which font-units: rem, em, px to followed?

[ ] Format of the color code to follow

[ ] Any 3rd party style to be used for: base.css, or any other modules?

[ ] What to use - flex, grids, float?

[ ] How long the class name should be?

[ ] How deep the SCSS nesting should be?

[ ] What is the color palettes

[ ] What is the font-scale

[ ] What is the space-scale

[ ] Identify the common patterns/components/modules. Eg: there are 2 types of buttons

[ ] Identify the reusable patterns/components/modules

[ ] Identify the pages

Every decision should be documented and make it part of your team's onboarding process. This will help the new developers to onboard easily and understand the code guidelines.

This will also give you a clear understanding of the project's UX and will bring consistency to the project.

Eg: If on one page the font size of a heading is 24px but on another page the same level heading font size is 14px then it is inconsistent.

Flag this to the UX team to rectify this.

With consistency developers can easily implement reusability.

How? Let's again go back to the heading example.

Due to the consistency of font size and style of the same level of headings in the application, the developer will write the code once and will reuse it. Also, in the future, if any developer will add the same level of heading the developer doesn't need to add any style code. As the style is already written for it.

Structure of the CSS

Always keep your style files into a dedicated folder - style/css. Do not just put it on the root. I have seen this as a very common mistake in ReactJS developer. Reason is CRA does this 😊

Next, is to understand how to organise your style. It is important that instead of writing whole project's code in one file. We should organise it into multiple files (as per the requirements).

Why? Dividing your project code into multiple and meaningful separate folders and files will helps you to follow SOLID principal of programming.

Now, we will get into the details:

1) Base

2) variables

3) mixins

4) breakpoints

5) layouts

3) common components/modules

4) pages

5) themes

6) vendors

Which framework to use?

Well, this depends a lot on the project ( I know you will be annoyed by this answer. But this is the fact). But a few things to consider while selecting framework/lib:

1) Knowledge of CSS

Is your team or you has strong knowledge of CSS. If yes, then you have loads of options. But if you doesn't know CSS then you can go for the any CSS lib. It will be very helpful.

PS: There are many backend developers who are responsible to make UI too for them going with CSS libs is very useful.

2) Timeline of project

If the timeline is too tight and you are not sure about how the writing CSS form scratch will come out then anyway go with a CSS lib.

(If you are confident that you can manage writing the project's CSS from scratch in tight timeline. Then go ahead.)

But please do consider timelines.

3) Complexity of the project

If the project is complex you need to evaluate writing the styles from scratch vs going for CSS libs.

A few developers prefer to write the CSS to have total control vs going for the libs/framework. Whereas a few developers prefer to offload the complexity to the libs/framework.

This is one point which you need to consider before writing the code as changing this later in the project development life cycle would be very costly for your team, and project.

4) Scalability

Is the solution you are going to pick is scalable or not and how easy it would be to onboard the project on it or scaling to other tech stack?

How fast a developer can add new features?

Eg: If you are going with CSS lib/framework how soon it is taking in new release properties of CSS?

These are the questions to be asked and consider while picking the solution.

5) Maintainability

Next, one needs to consider about maintainability. How time-expensive it would be for a developer to fix a bug, or adding new line of code. How many files would the developer is going to change for say for adding a theme.

Also, if you are going with the lib/framework do consider the future upgrades from creators.

6) Compatibility

What is the Browser, OS, devices, support of libs and frameworks.

Phew!! I hope now you know it is not as easy you think to pick a styling solution for your project.

You can follow me on Twitter

Happy learning!!

Discussion (1)

Collapse
cfecherolle profile image
Cécile Fécherolle

Nice article, well-put and clear! It's quite rare to see people writing about this specific side of CSS and I think the checklist can be useful for a lot of devs.