- Not possible to have project specific overrides of variables
- CSS modules not specific enough to override Grab UI (Semantic UI) classes as CSS modules only apply one class where Semantic UI applies two classes (.ui.) and has higher specificity.
- Import theme variables from Grab UI theme configs to use in project-specific components
- No build requirements
- Small and lightweight
- Supports global CSS
- Supports entirety of CSS
- Colocated
- Isolated
- Easy to override
- Theming
- SSR
- No wrapper components
1. React CSS in JS: https://speakerdeck.com/vjeux/react-css-in-js
React inline styles solve the following problem:
- Global namespace
- Dependencies
- Dead code elimination
- Minification
- Sharing constants
2. React Inline Styles are Fundamentally Flawed: https://byjoeybaker.com/react-inline-styles
Problems with (React) inline styles:
- No property fallbacks such as when vendor prefixes are needed. Can't declare two
displaystyles in a JS object. - No media queries or element queries.
- If you render on server, you can't find out window/element size and initial styling sent to clients is likely to be wrong.
- No cascading styles
- Debuggin is a pain. Impossible to see changes made to one component affect all other similar components.
- Inline styles have the highest specificity and you can't override styles on those elements.
- Huge payload for server-side rendered markup with inline-styles for repeated components.
- Performance
- Browsers need to parse all the inline styles which is slower as compared to parsing a stylesheet.
- Loading CSS in can be parallelized and doesn't necessitate downloading duplicate markup for (potentially many) similarly styled elements.
3. Benefits of JSS: https://github.com/cssinjs/jss/blob/master/docs/benefits.md
- Scoped selectors:
- Unique class names are generated and ensures no collision.
- Rules isolation:
- Prevents elements from inheriting properties from parent elements.
- Fast selectors
- Non-nested selectors are faster than deeply nested ones.
- Rules Sharing
- CSS rules can be shared for a list of items.
- All CSS features included.
- Faster performance than inline styles.
4. Component Style: https://medium.com/@dbow1234/component-style-b2b8be6931d3#.7en4pyam9
- CSS is, as Mark Dalgleish points out, “a model clearly designed in the age of documents, now struggling to offer a sane working environment for today’s modern web applications.”
- If your stylesheets are well organized and written with best practices, there is no bi-directional dependency between them and the HTML. So we do not need to solve the same problem with our CSS that we had to solve with our markup. — Keith J. Grant
- The foundational issue with CSS is fear of change. "You must have an intimate knowledge of both in order to safely make any substantive changes to either."
- That said, I like to minimize cognitive effort whenever possible. Things like naming strategies require a lot of discipline and “are hard to enforce and easy to break.”
- Smart people on great teams cede to the fact that they are afraid of their own CSS. You can’t just delete things as it’s so hard to know if it’s absolutely safe to do that. So, they don’t, they only add. I’ve seen a graph charting the size of production CSS over five years show that size grow steadily, despite the company’s focus on performance. ~ Chris Coyier
- You only include CSS classes that are actually used because your build system / module bundler can statically analyze your style dependencies.
- You don’t worry about the global namespace. The class “default” in the example above is turned into something guaranteed to be globally unique. It treats CSS files as isolated namespaces.
- You are more confident of exactly where given styles apply.
5. The end of global CSS: https://medium.com/seek-developers/the-end-of-global-css-90d2a4a06284#.vamt40rk6
- Any time we make a change to a CSS file, we need to carefully consider the global environment in which our styles will sit. No other front end technology requires so much discipline just to keep the code at a minimum level of maintainability.
- We’ve worked around the issues of global scope with a series of naming conventions like OOCSS, SMACSS, BEM and SUIT, each providing a way for us to avoid naming collisions and emulate sane scoping rules.
- Writing maintainable CSS is now encouraged, not by careful adherence to a naming convention, but by style encapsulation during development.
6. Against CSS in JS: http://keithjgrant.com/posts/2015/05/against-css-in-js/
- The relationship between CSS and JavaScript is not like the relationship between HTML and JavaScript. With HTML, a true separation of concerns between the markup and the corresponding component code is impossible. With CSS, this separation is possible and is in fact vital to clean code organization.
- If your stylesheets are well organized and written with best practices, there is no bi-directional dependency between them and the HTML. So we do not need to solve the same problem with our CSS that we had to solve with our markup.
- We had better have a damn good reason before we go down that road. Christopher Chedeau, in the original slidedeck that introduced this idea, outlines seven “problems” with CSS. The thing is, they are solvable problems. If we as web developers just understand CSS better, and take the time to learn modern best-practices like SMACSS and BEM, these issues almost entirely dissolve, especially at the scale most of us work at.
7. Please, Please Don’t Use “CSS in JS”: https://medium.com/@ajsharp/please-please-don-t-use-css-in-js-ffeae26f20f#.gqi58wlt8
- CSS hasn’t been designed to fit into components based architecture.
- CSS in JS represents a fundamental change in how web apps get written — it throws away CSS in favor of a complex Javascript-based build chain that you’d be forced to use to implement CSS in JS.
8. CSS in JS is like replacing a broken screwdriver with your favorite hammer. :https://zendev.com/2017/09/11/css-in-js.html
The reason JSX provides an improvement in productivity is that structure and behavior are tightly linked - a large amount of JavaScript logic has to do with manipulating HTML structure, so separating the two creates more cognitive overhead, not less. Contrast this to graphical properties, which are a very large percentage of what is being manipulated by CSS. Rather than being tightly linked to structure, these are very loosely coupled - this is why one can often wireframe an entire application out before styling it! Moving your CSS into your logic introduces unnecessary coupling, leading to more cognitive overhead not less.
Contrast this to your visual output - if each and every component is completely isolated visually from one another, your site or application will be a disastrous mess! Certainly every component has unique properties, and those properties should be isolated so as not to leak, but there is also a tremendous need for visual consistency across your site. This is one of the core reasons for the CSS cascade, and while a misunderstood and uncontrolled cascade can be disastrous, used properly it is an incredibly powerful tool.
This means that if every component is itself responsible for its own styling, you will end up with tremendous amounts of duplication!
Publish 1 month ago: "A Unified Styling Language" - deep dive into CSS in JS from the creator of CSS Modules
https://medium.com/seek-blog/a-unified-styling-language-d0c208de2660
Mark Dalgleish's top stories on medium are: