Compared to regular CSS
CSS has just one global namespace. It is impossible to avoid selector collisions in non-trivial applications. Naming conventions like BEM might help within one project, but will not when integrating third-party code. JSS generates unique class names by default when it compiles JSON representation to CSS.
True rules isolation.
Scoped selectors are not enough. CSS has properties which are inherited automatically from the parent element, if not explicitly defined. Thanks to jss-isolate plugin, JSS rules will not inherit properties.
Avoids slow selectors.
Because JSS rules are collision free, there is no need to write deeply nested selectors. This leads to stable performance at scale.
Code reuse, expressiveness.
CSS is limited to applying multiple selectors to the same node in its code reuse capabilities. JSS allows you to compose rules from multiple sources. You can reuse existing rules, you can use functions to generate rules and to calculate values. This way we can avoid repetitions in a very explicit way.
Dead code elimination.
If you put your styles into a component where they are used and use closure compiler.
Using JSS vendor-prefixer plugin, prefixes added at runtime very efficiently, only for the required browser and do not increase download size.
JSS styles size is up to 50% smaller, you can save a bandwidth and increase site performance if you generate CSS at runtime:
- Better code reuse
- No pregenerated vendor prefixes
- No selectors
- Other at-runtime optimizations provided by plugins
You can easily share constants and functions between JS and CSS.
Adoption to environment.
You can generate styles according the environment requirements at runtime, for e.g. you can express any complex condition considering for e.g. pixel density, resolution and device type at the same time. You can compose new Style Sheets based on settings and environment out of existing once.
Compared to server-side preprocessing languages (stylus/less/sass/css-modules and co.)
There is no build step, as a result—no dependency to build tools at all.
Just one language, standardized by w3c.
Compared to Inline Styles
Inline styles can not be cached, they need to be applied to an element once they needed. CSS rules generated by JSS are created once and used during the complete application lifecycle.
Inline styles are applied to every element directly and can not be shared between multiple elements. This becomes important when you have a list of items styled equally. In JSS a CSS rule is shared for all items. Inline styles are a good fit for state dependent styles and animations.
All CSS features included.
Unlike inline styles, JSS gives you all CSS features:
- Media queries
- Keyframes animation
- Font face
- Pseudo selectors
- Fallbacks: you can define the same property multiple times, like you know it from CSS.
- Automatic vendor prefixing
Inline styles are slower than class names.
Compared to Radium
- Generates CSS, not inline styles like radium.
- You can do everything you could do with CSS before. It is not limited to specific kinds of selectors.
Compared to Aphrodite
- Supports children, siblings and any other kinds of selectors.
- Has support for global styles, without auto namespacing.
- Renders styles before component is rendered. It gives you an access to computed styles right after render and avoids additional recalcs and repaints, which can cause flickers and general performance overhead.
- No auto "!important" insertion. You can write a plugin for this though.
More details in the article.
Compared to any CSS in JS solution
Extensible core architecture.
Small core, everything else is a plugin. It is similar to postcss at this point. It allows you to create your own setup with selected plugins, which fix your problems. Also it allows you to create your very specific custom modifiers.
More articles are welcome.