I agree my example is simpler than yours, but you will also agree that it is functionally equivalent.

My example takes 8LOC of customization. Yours use 45LOC. That matches my experience with customizing styles on larger project, Chakra is 80% simpler to customize.

Material UI in general is more complex and more opinionated (why do Input boxes Have to have this weird animated description? That’s opinionated) Which is why I prefer Chakra. KISS.

Since your contention was the LOC and ability to use nested CSS styles, I have taken your own example and matched it. Line to line. Using Material UI. Updated the above demo:

https://codesandbox.io/s/material-demo-d2vmn?file=/demo.js:1...

8 LOC of customization. Same styles you applied to your demo with a few syntactic changes.

Hope this convinces you that you can do exactly the same thing in Material UI as you can in Chakra. Because both use CSS-in-JS. What you can't do in Chakra is ability to change styles of nested components (note I am saying components instead of HTML elements) without worrying about implementation detail.

We are not changing CSS alone here. You can do nested CSS styles through Material UI too. But that doesn't make any sense when you have complex components.

If you are relying only on CSS styling then you are tightly coupling the implementation with presentation. Say you have a nested button that is an <input type="button"> in one component. So your nested CSS style in another component that includes this button component would be: "> input[type=button]". Now tomorrow, some developer on your team decides to change the implementation to <button> instead as it is more semantic. Then what happens? All places that have your CSS nested style goes out of whack because of this one change. Because you have hardcoded your nesting. You will then have to change all references from "> input[type=button]" to "> button" just to meet the change in the implementation detail.

What is the point of CSS-in-JS if you are going to use CSS nested selectors for inner components? You might as well just use CSS modules instead. If you want to do CSS-in-JS do it the right way. Use JS to expose APIs for your components and CSS to style those components by reference. That way your components are truly independent of each other. Right now with Emotion, changing styles for your nested component implies using nested selectors which makes your components tightly coupled.

Now let us make it more complex: What if you want to introduce a <div> in between your parent component and the nested <button> component, as a wrapper? Not only do you have to change your JS implementation but also change all nested selectors from "> button" to "> div > button". It is a big mess at this point!

With Material UI it doesn't matter what your implementation is. Your component can use an input[type=button] or button or heck a div that behaves like a button using ARIA roles. It can even be nested 10 levels deep. You can even swap it out with links and it won't fail. Because styling is applied through a JS interface rather than CSS nested selectors. The implementation takes care of where to apply the styles. For the person outside he is just changing the style of the inner component without knowing how it is implemented. That is the real beauty of CSS-in-JS. Not knowing implementation detail ahead of time.

We are using CSS-in-JS because of limitations of CSS: you can't define custom components in CSS. If you are going to do traditional CSS with nested selectors using CSS-in-JS then you are just doing it wrong! You don't even need CSS-in-JS at this point apart from it being just a convenience. You can just use CSS modules or regular stylesheets.

https://styled-system.com/variants

you can use it in Chakra or in anything else that supports this spec.

Variants are defined by the implementor of the component in question. What I am talking about is overriding styles by the user of the component. One way to do it is through the ThemeProvider. But that does so globally. If I want to override a style for a particular component only in one place (and the nested components within it) then I will have to use CSS nested selectors or a nested ThemeProvider (which is hacky and ends up slowing down the app depending on how it is implemented). Then I am tightly coupling the implementation with the presentation. There is no API as such to change the nested component styles directly. That is the area where I feel Material UI does better. It has standardized how inner components are exposed to the World for styling. That standardization should happen at the library level instead of at application level. So whenever you import the library you know you have that option available to you too.

It looks like Material UI has its own implementation of styled-system which is great! They should have started with something like that from the start :-)

Please take a look at theme spec where variants become part of your theme object. You use theme.js to provide custom variants to components. This is how you would let users to customize your components via well defined expressed API (typed with TS if you want) :-)

> One way to do it is through the ThemeProvider. But that does so globally.

You can have as many nested ThemeProviders as you want. This is not a hacky way but is the way if for some reason it's not enough for you to have 1 global theme object.

Material UI is great for what it does (implements said kind of design) but if material design is not what you want then using this library with its own layers of abstraction is a no go to me.