Why CSS in JS?
Borned with scoped style
One aspect of traditional CSS based on class selectors is that there is no local scope, and all styles are globally effective, which makes it extremely difficult to write and maintain CSS for large projects. In order to solve this problem, the front-end community has spent a lot of energy to solve this problem, such as BEM/SMACSS/OOCSS and other methodologies, such as CSS preprocessors such as Less/Sass/Stylus.
The disadvantage of BEM/SMACSS/OOCSS is that they are just conventions. It is difficult for team members to reach consensus on these methodologies and follow these conventions perfectly for a long time.
Less/Sass/Stylus tried to bring programming ability to CSS, but it didn't bring real programming ability. Instead, it made the tool chain more complicated, and the extended syntax was not easy to use.
What about CSS-in-JS? It is a natural scoped style, which solves the CSS scope problem mechanically, rather than relying on some difficult-to-observe conventions.
Dead Code Elimination
Since HTML and CSS are generally connected through class names, and there is an implicit relationship between them, it is usually difficult to track unused CSS styles. After deleting components, it is difficult to accurately delete the corresponding CSS. Because you will be afraid of using styles elsewhere, you will have no confidence in deleting CSS code and feel insecure.
With CSS-in-JS, the relationship between style and structure is explicit, and style and structure are bound. The addition, modification, and deletion of structure and style code are synchronized, and there is almost no dead code.
Especially for large front-end projects, it is easy to inflate useless CSS codes using traditional methods, and no one dares to modify these codes. With CSS-in-JS, there will be no dead code.
Dynamic style
The style of the component is controlled according to the state of the application, which we call dynamic style. One of the very powerful features of CSS-in-JS is state-based styles.
The traditional approach is to define multiple CSS class names, and use JS to change the CSS class names according to the application state. The biggest disadvantage of this approach: the state of the style is out of the context of the application (Context), it is related by the CSS class name hook, and the code writing in this way is very cumbersome.
With CSS-in-JS, style rules are directly produced according to the application state. The style is in the context of the state. You can understand it as Style=f(State). You don't need to use CSS class names to implicitly describe dynamic styles.
Componentization
Once web applications were based on pages. A page usually consisted of three files: HTML, JS, and CSS. At that time, separation of concerns was reasonable. Now, the front end has entered the era of componentization. A page is usually composed of multiple components. At this time, CSS in JS is more suitable for componentized scenarios.
Better development experience
You don't need to write CSS, you only need to write JS, which reduces your mental burden. And with TypeScript, type hints are more accurate. CSS-in-JS makes developers more expressive and makes the code more maintainable.
Consistent coding style
For many years, front-end developers have been struggling with various CSS methodologies, such as BEM/SMACSS/OOCSS, but it is difficult to implement and manage the exhibition without strict supervision. Fower provides a restrictive way of writing styles: Atomic Props, allowing everyone to use the same way to write styles.
Support non-browser, such as React Native, applet
Our team is a deep user of RN, using Fower can unify the UI development experience.