4 ms·

Everything you said is possible in Chakra thanks to emotion, which is also on the path to becoming industry standard on that aspect, unlike material. I made th

Everything you said is possible in Chakra thanks to emotion, which is also on the path to becoming industry standard on that aspect, unlike material. I made there an example matching yours: https://codesandbox.io/s/chakra-demo-upcrp?file=/src/app.js https://codesandbox.io/s/chakra-demo-upcrp?file=/src/app.js

shripadk 6y ago
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.
- crubier 6y ago
  The uniform API you are talking about is literally just nested CSS styles with emotion. It is possible to modify deep subcomponents style with emotion. It’s CSS Nothing more. 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.
  - shripadk 6y ago
    > The uniform API you are talking about is literally just nested CSS styles with emotion. It is possible to modify deep subcomponents style with emotion. It’s CSS Nothing more. 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.

shripadk 6y ago

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.

crubier 6y ago
The uniform API you are talking about is literally just nested CSS styles with emotion. It is possible to modify deep subcomponents style with emotion. It’s CSS Nothing more. 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.
- shripadk 6y ago
  > The uniform API you are talking about is literally just nested CSS styles with emotion. It is possible to modify deep subcomponents style with emotion. It’s CSS Nothing more. 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.