Skip to content

Latest commit

 

History

History
113 lines (66 loc) · 5.11 KB

benefits.md

File metadata and controls

113 lines (66 loc) · 5.11 KB
Raw

Benefits of using JavaScript Style Sheets

Compared to regular CSS

  1. Scoped selectors.

    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.

  2. 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.

  3. Slow selectors.

    Because JSS rules are collision free, there is no need to write deeply nested selectors. This leads to stable performance at scale.

  4. 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.

  5. Refactoring.

    Thanks to javascript modules and explicit code reuse, we can quickly locate dependencies during refactoring.

  6. Dead code elimination.

    If you put your styles into a component where they are used and use closure compiler.

  7. Vendor Prefixing.

    Using JSS vendor-prefixer plugin, prefixes added at runtime very efficiently, only for the required browser and do not increase download size.

  8. 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
    • JavaScript Compressors like Closure Compiler
    • Other at-runtime optimizations provided by plugins

  9. Code sharing.

    You can easily share constants and functions between JS and CSS.

  10. 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.)

  1. Aforementioned benefits.

  2. There is no build step, as a result - no dependency to build tools at all.

  3. Just one language, standardized by w3c.

    There is no need to learn new preprocessing languages. They all come with a burden of a new syntax for variables, functions, mixins, extends and others. At the same time there is nothing they can do JavaScript can't.

Compared to Inline Styles

  1. Rules caching.

    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.

  2. Rules sharing.

    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.

  3. 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

  4. Performance.

    Inline styles are slower than class names.

Compared to Radium

  1. Generates CSS, not inline styles like radium.
  2. Pseudo selectors are implemented by CSS, not using JavaScript.
  3. You can do everything you could do with CSS before. It is not limited to specific kinds of selectors.

Compared to Aphrodite

  1. Supports children, siblings and any other kinds of selectors.
  2. Has support for global styles, without auto namespacing.
  3. 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.
  4. No auto "!important" insertion. You can write a plugin for this though.

More details in the article.

Compared to any CSS in JS solution

  1. 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.

Related articles

https://byjoeybaker.com/react-inline-styles

https://medium.com/@dbow1234/component-style-b2b8be6931d3

More articles are welcome.