Material UI actually is a lot better when it comes to customization. You can just override the provided component styles by creating ad-hoc CSS-in-JS styles and passing it as classes. This is apart from what Chakra UI provides. Both uses some form of styled-system but Material UI implements it better. Material UI provides an API to modify the styles of core components in any depth that you like. You do it through the `classes` prop.

So for complex components like TextField which has an InputLabel, Input and FormHelper component you have corresponding props: InputLabelProps, InputProps and FormHelperProps which accepts a `classes` prop each. You can then create ad-hoc CSS-in-JS styles using makeStyle and pass them as classnames to the respective inner-components `classes` prop. You'll realize the advantage of this only when you try it out.

Here is a quick example I created for you to try: https://codesandbox.io/s/material-demo-d2vmn?file=/demo.js:2...

The left side is a normal TextField and the right side is a TextField with styles overridden. If you do not like the TextField component Material UI provides you can always create your own with InputBase component.

Edit: Hacker News isn't letting me post a comment to your comment so I am editing my comment here.

Your example doesn't match mine. It just styles the component itself. Not inner components. For that you need a uniform API which neither Emotion nor Chakra provide. Please see my example again. The TextField component is a complex component comprising of InputLabel, Input and FormHelper. The idea is to style those inner components without actually breaking apart the source. We need a uniform API for that and neither Emotion nor Chakra provide something along those lines. Which is the crux of the argument on why Material UI is superior. It not only provides CSS-in-JS styling options like Emotion but also provides a standard API to style inner components no matter how deep in the tree they are. If you want to replicate the same feature you would have to create your own abstraction. But then that abstraction is not on the library level but your application level.

So if someone wants to work on your app, they will have to learn your abstraction first. If they move on to another app they can't carry over your abstraction in case the other app doesn't have the same implementation. They will either have to learn the new implementation or create that abstraction from scratch leading to a lot of bloat.

If I know some project is using Material UI I feel comfortable knowing that the API to modify a component and its inner components will be the same. That gives me a lot of confidence.