In the era before the concept of front-end development, CSS as a relatively simple DSL is relatively adequate, but as front-end projects become more and more complex, front-end development modes are constantly evolving with the needs of the project scale. For example, in the front-end service, we changed from the server end to the simple separation of the front and back ends and then gradually upgraded to the serverless integration of the front and back ends. For example, in the writing of JS, we gradually introduced various modular schemes from the original single file script to today’s componentalization. The same evolution will certainly take place with CSS development.

CSS as a (once) global-scoped DSL was never really suitable for large projects. After all, HTML was invented to write documents, and CSS was designed for simple styling rather than for rich applications. But as front-end projects have grown in size, CSS has had to adapt to this historical process. Before and after The invention of Node, when front-end engineering was not very mature, engineers tried to mitigate this contradiction, such as BEM, OOCSS, SMACSS and other naming schemes to separate concerns. For example, less, Sass and other tools to enrich the SYNTAX of CSS and can have a build process to make CSS have the primary modularity ability. But the problem remains that CSS is not suitable for large projects. In a 2014 speech, Vjeux, Facebook’s development manager (and one of Prettier’s authors), summed up several pain points about CSS not being suitable for large projects.

Why CSS modules

CSS Modules were invented to address these pain points by compiling globally unique class names without worrying about clashing class name styles. It is a good solution to the problem of project scale increase, with less or Sass preprocessor can also achieve a considerable degree of engineering, for most scenarios it is enough to use. But CSS Modules have their own disadvantages:

  • If you heavily use preprocessors like Less or Sass, introducing variables, mixins, functions, etc., it will create a disconnection between the engineered ecology of JS and CSS.
  • Hard to delete code: on the one hand, as long as the CSS file makes people have copy-paste desire, it is easy to cause code redundancy, and on the other hand, CSS file classes can not be associated with the JS code outside, need to use additional tools to introduce the type system. Although it does not necessarily affect the final code size (PurgeCSS), it does pollute the readability and maintainability of the project.

One thing I personally hate about CSS Modules is that once you use CSS modules you have to score two files. The impact on readability can add up to a lot, and when you encounter a slightly more complex component you have to change it back and forth. Modern component-based Web development is better suited to putting templates, logic, and styles together as much as possible, preferably in one file.

Why CSS in JS

In fact, compared with CSS modules, CSS in JS was proposed earlier by Vjeux. Of course, the original CSS in JS basically can be understood as simply putting in-line styles into objects. This is very different from the current popular CSS in JS solution based on Tagged Templates.

Thanks to the popularity of componentization, developers are no longer concerned with the specifics of HTML and CSS, and reusable components are simply installed and used with NPM packages. CSS in JS is a good fit for this development mode. Developers do not need to introduce CSS, do not need to deal with the bundle and prefix of CSS, all are JS, and do not need to configure various CSS preprocessors, which greatly reduces the development cost.

CSS in JS is actually quite a drool topic, because there is a lot to be said in terms of development concept, project cost, development scenario adaptation and so on. Since this article is mainly About Amway Tailwind, I won’t expand on it. For the style Styled Components, the most popular CSS in JS scheme is styled- Components, and for the style Emotion, which I think is more powerful, there are also many users.

Why Tailwind CSS

tailwindcss.com/

Tailwind CSS is actually the atomic CSS in the modern engineering framework to do the ultimate CSS framework. Atomic CSS has been around for a long time, most classic ones like Clearfix, and many early Web projects have atomic CSS in one form or another. But the early atomic CSS was not considered a best practice, or a poor solution. The era advocated the so-called “separation of concerns,” in which AN HTML class should have its own semantics and not attach style or logic to it. But over time, in the days of componentization we don’t really care much about the semantics of HTML (it’s not even HTML, it’s called JSX), and the semantic functionality has been replaced by components. For each div tag, all we care about is its style. Atomic CSS is useful in this context.

Using a uniform “system” variable can greatly reduce the mental burden.

If I now needed to change the background color of this button to “that” blue, what would you say?

In today’s more serious front-end projects, there is a so-called “Design language” (even if it is directly applied to an existing one) that regulates the “Design tokens” of various elements on the page, such as blue for which blue, red for which red, rounded corners for how much spacing. Now let’s say I want to change the background color of this button to blue, what would you say? There are a lot of silly ways to just fulfill requirements, but we should actually maintain the “Design Token” of the Design language we use in our projects. Tailwind naturally supports this.

// BAD
.button {
  background: #3370ff; } // GOOD.button {
  @apply bg-blue-500; // blue-500Is the positive blue specified in our design language.Copy the code

Another example is that there are often mysterious numbers in the CSS of our project, such as 17px, 27px and 35px. The accumulation of such magic numbers is actually quite a mental burden, because you do not know which number to choose and you can only watch the tune. This can be mitigated to a large extent by specifying “Design tokens” with tailwind. In fact, for designers, 4PX based design scheme is also a good choice.

// BAD
.sliceContainer {
  padding: 24px 24px 13px; // why 13 ?
}
// GOOD
.sliceContainer {
  @apply px-6 pt-6 pb-3;
}
Copy the code

Using atomic classes can greatly reduce the number of scenarios that need to be named

Naming can be one of the hardest things to do in development, especially given the popularity of componentized development, there’s no need to give your divs a meaningful name. Pages that use this component don’t care if the top of your component is called header and the bottom is called footer (unless you’re a basic component that needs to be reused), you just put the style on it.

How many wrapper, container, Content, box, section, fragment classnames have you had?

The same code without a name can save a lot of hair

Some might find a large number of inline style classes difficult to maintain, but in our experience with several large projects, inline styles are actually more maintainable than CSS Modules.

Inline with components to better achieve “high cohesion and low coupling”

One problem with any solution that uses CSS (including CSS Modules) is that it’s hard to delete code: you can’t tell if a style is really useless until it crashes. With tailwind CSS you can make styles follow components to the death, as components remove styles, reducing the possibility of redundant code at almost zero cost.

Utility-First, not Utility-Only

Finally, tailwind is not an option, it works well with other solutions and costs almost nothing to use. For those with a more radical need for atomic styles or “Design tokens” consider the Chakra, which is almost tailwind’s React/Vue version.

Refer to the reading

React: CSS in JS – NationJS

CSS Modules Welcome to the Future

CSS Utility Classes and “Separation of Concerns”

Why Tailwind CSS