Skip to main content

Benefits of rewriting code to SPOT CSS

This article about benefits is complementary to the main article How to refactor (S)CSS code into SPOT CSS.

Refactoring to SPOT CSS in this way will benefit you in so many ways that I divided them into before, during and after the refactor.

Benefits that will convince you to start refactoring​

If you have doubts whether it is worth to start refactoring right now, whether it is the right time and whether it will slow down your development, here are some arguments:

  • it's FAST - this kind of refactoring can be done in a few hours or days for the whole project at once (depending on the size of the project and complexity of the components);
  • it can be done in increments - it can also be done component by component, where rewriting one component can take from 5 minutes to 3 hours (depending on the size and complexity of the component);
  • it's SAFE - you don't risk that something will be rewritten and changed in such a way that the current functionality of the stylesheet will be broken. The principle of this refactor is the fact that the resulting CSS output is not changed and therefore it is relatively easy to verify. Basically, you rewrite the code and you don't have to check the application and click through the screens to see if something has gone wrong;
  • a quick try out - it would certainly be a good idea to test a more complex component first. Not the most complex, not the simplest, but something in between. Just try and see the result. See more in Step 1: First component;
  • you can OUTSOURCE it - the biggest kicker of this approach is that you can outsource this refactor. You don't have to stop product development, you don't have to convince stakeholders that now it's most important to clean up the CSS. And it can be relatively cheap, fast and safe. More in the section Outsource it.
  • other benefits - after refactoring, you will find opportunities for further refactoring and optimization, because reorganizing your code will reveal things that are hard to see now. See section Benefits after refactoring and What is not solved by this kind of refactor.

Benefits during refactoring​

If you have already decided to take the plunge, you may be pleased with the following benefits:

  • no pressure - although this kind of refactor is very fast, the advantage is that you can do it in a separate GIT branch and that's why it doesn't block anyone and you don't have to be under time stress. The exact procedure for what to do with the CSS code that is added or changed in project during the refactor phase can be found below in this guide;
  • selectors are not changed - the main principle is that you don't change any selector (in the CSS output) and you can check and validate it so that you don't change any. The unique thing about this procedure is that it can be done very elegantly;
  • no CSS properties are changed - you don't edit the CSS declarations (the block with properties and values) of a given selector, you don't need to, just copy&paste to a new place. And as we mentioned in the point above, the selector is not changed in the CSS output either;
  • no new CSS needs to be written - you don't have to write any new CSS, refactor is done only on existing CSS code, basically you don't even have to be good in styling and flawless implementation of the design from the graphic designer;
  • easy to verify - by comparing the previous CSS output and the new one after the refactor you can unambiguously verify that you didn't screw anything up or missed/forgotten anything;
  • you can measure progress - after rewriting a few components and measuring the time you will be able to estimate the total workload and also measure progress and keep track of where you are right now;
  • speeding up in time - at the beginning you may be unsure and slow, but over time the actions will become very repetitive and the refactor will become a no-brainer;
  • the most satisfying feeling - doing a refactor this way is a very interesting experience (if you like CSS at least a bit) and seeing how everything is smoothed, untangled and simplified is very satisfying.

Benefits after refactoring​

After rewriting the CSS code to SPOT CSS you will get:

  • SPOT - Single Place of Truth, the order in the code, unified, consistent, organized by components and each element in one single place;
  • project standard - standardized way of writing CSS code on a project (or even in a company), formalized and documented, with tools like Cheat Sheet;
  • intuitive even for newcomers - increased the readability for newcomers. Even those who are not familiar with our methodology and framework understand the written code, because it has an intuitive and semantic syntax. And you can refer them directly to the documentation or at least to the Quick start guide or Tutorial, so they can study it quickly;
  • linter out of the box - SPOT CSS framework is actually a linter itself written in SASS, so it checks and enforces most of the rules on its own, which makes it easier to force developers to follow the rules verbally and code reviews are also easier, because it is obvious if someone does not write a style in the SPOT CSS way;
  • faster development - usually CSS development on projects works in such a way that when it starts, the development goes super fast because there is little code and only new code is added that does exactly what you want, but as the project grows over time, the CSS codebase grows, screens are added and components become more and more complex with many variations, then the development starts to slow down and in the worst case it gets stuck. With SPOT CSS this phenomenon will not bother you and the development will continue in a basically linear way even as the project grows;
  • unified naming convention - SPOT CSS also introduces its naming convention (directly in mixin names) such as component, element, mutations, state, variant, context, and this will make team communication more efficient as soon as you get the hang of it;
  • well-documented components - SPOT CSS implicitly forces to document each component in the register section and therefore does not allow to have this documentation outdated, because SASS would warn about it immediately during compilation. Therefore, it will not be possible that a component is not well documented;
  • brings certainty - this is a hardly transferable experience, but the one who experiences working with SPOT CSS knows how great it feels to know which file to open, how to find a given element and in one place to see its whole style with all its variants, states, context and responsiveness, to evaluate the overall situation and make an adjustment. Without worrying about what he hasn't seen, overlooked or misunderstood, and whether he can safely make the change he's thinking of;
  • specificity of selectors is not a problem anymore - since specificity is in the SPOT methodology is problem of selector specificity reduced only for single element (see Local specificity), managing styles becomes a lot easier;
  • usability of components - thanks to the documentation of each component in the register section, frontend developers can use these components much more efficiently, because they will have a perfect overview of what states, variants and contexts each element implements and supports;
  • developers' joy - hopefully at least some developers will want to deal with CSS after all, it will be fun again;
  • further refactor and optimization - after you complete this refactor procedure and clean up the code you can more easily identify remaining problems and make further optimizations easier (see What is not solved by this kind of refactor).

Have we convinced you?

Then check out more here: How to refactor (S)CSS code into SPOT CSS?


If you have a different opinion, if you disagree with something, or if I made a mistake somewhere, or if I don't see something according to you, let me know on our Discord - Johnny Seyd (@Seyd#6245).