4 ms·

The initial example immediately drove me away. Attributes for font size, -weight and the like? There was a reason we stopped using inline styles...

xmorse 6y ago
And what is the reason? So you can have a global css file difficult to maintain and update? So you can give a stupid class name to every single tag you use in your markup? So that every time you include third party css there is the risk of confilicts?
- saagarjha 6y ago
  > And what is the reason? So you can use CSS the way it was designed? > So you can have a global css file difficult to maintain and update? You know you can have multiple CSS files, right? Plus the code is all in one place and you can refactor it. > So you can give a stupid class name to every single tag you use in your markup? No, you give it a good class name. If something is a button, you call it a button rather "grey-rectangle width-500 clickable" > So that every time you include third party css there is the risk of confilicts? That's why you name your classes so this doesn't happen?
  - jacobr 6y ago
    I am sure there are plenty of cases where this approach works just fine. I assure you that those of us who work on projects where this would not work are not simply bad at naming things and that’s the only reason we picked component based styles.
  - player2121 6y ago
    > So you can use CSS the way it was designed? css was designed to style HTML documents. It was never designed to build rich and scallable apps thus we have all these libraries which fixes a lot of underlining problems.
    - saagarjha 6y ago
      What problems do they fix? How do they deal with refactoring?
      - cutemonster 6y ago
        Refactoring: I suppose one then just refactors js instead of css. And even simpler/safer? If using typescript to make the js and refactorings type safe
  - mmm_grayons 6y ago
    Using something the way it was designed isn't an inherent virtue nor a reason to do so. Nothing is designed perfectly. > "grey-rectangle width-500 clickable" Oof, this is starting to feel like working with a Microsoft product.
  - ggregoire 6y ago
    > And what is the reason? >> So you can use CSS the way it was designed? This is not a reason why people should not use inline style. Also, CSS was designed 23 years ago. A few things happened in web development since 2 decades. > No, you give it a good class name. If something is a button, you call it a button It just doesn't work when your app has 100 buttons. You can introduce a naming methodology like BEM but naming conventions are hard to enforce, annoying to follow, and there are always guys on your team who disagree with them (for bad and good reasons).
    - deckard1 6y ago
      > conventions are hard to enforce This seems to be a thing in the past 5 years or so. I've seen developers refuse to follow the existing coding style simply because there was no lint or prettier rule for it. Like, how fucking hard is it to match the style of the existing code base and not be a dick about it. These are lead and seniors I'm talking about. This is the type of thing junior devs should have learned their first month on the job. I can't even imagine contributing to an open source project in the '90s or early 2000s and not matching the existing code with whatever I'm doing. I don't care if it's tabs or spaces or whatever variation of if-branch nesting you prefer. When I'm working on code that already exists, I leave my ego at the door and try to make the codebase uniform and coherent. Hell, the whole reason prettier exists is because we think we can fix these anti-social developers with technology. And of course that doesn't work, so now you need tailwind or whatever.
- holoduke 6y ago
  nah. what about theming? you cannot do that with inline styles. I think external CSS files for layout is always better than inline. it's very hard to debug and fix UI issues. nowadays you fix stuff on the fly with your browser inspector. you copy the result and paste it in your CSS file. cannot be simpler than that
  - player2121 6y ago
    > nah. what about theming? you cannot do that with inline styles. Nobody is utilizing inline styles in that example. It _looks_ like inline styles but it not. It generates css class name behind the hood which you can override in multiple ways. Starting from the ThemeProvider or just like this: const Footer = styled.div` ${PrimaryButton} { color: red; } ` I strongly suggest to look at https://styled-system.com/ https://styled-system.com/ to better understand the mechanics.
Vinnl 6y ago
Note that you're not directly setting the size and the like. Instead, you're selecting items from a scale that should compose well together. They could advertise this better; I've read a post in the past that explained it well, but unfortunately I couldn't find it any more. https://styled-system.com https://styled-system.com might be a good place to start if you want to investigate why there might be more to it than you might assume at first. Edit: I think this was the one: https://jxnblk.com/blog/mathematical-web-typography/ https://jxnblk.com/blog/mathematical-web-typography/
saagarjha 6y ago
Yeah, it's the new "utility CSS" thing that is basically just inline style with a bit less boilerplate. It's quick to get started with, hence its popularity, but it's not really great after that.
- ericwood 6y ago
  I'm not a huge fan of atomic CSS, but part of the idea behind it is it solves the "ever-inflating CSS bundle" as well as the "where do I put this CSS" problems, both of which are issues on large projects.
ggregoire 6y ago
> There was a reason we stopped using inline styles... A few things happened between the 2000's and today tho. Practices evolve along with tools and technologies. We started styling our React components with CSS years ago at my job and we have been keeping doing so until today. While it works (if everybody on your team agrees to follow the same methodology and conventions, which is hard to enforce), it provides 0 benefits for us. We just went this way because it has always been the way to go while developing web stuff with Java, PHP, Django and friends. Separating the style from the structure while composing presentational components (Text, Box, etc) in a page doesn't actually make much sense and CSS maintenance, class naming and conflicts prevention is a real burden. I've been following the "CSS-in-JS" solutions (which have been developed to solve these exact issues) during the last years and it seems like they could help us focusing on what actually matters.

xmorse 6y ago

And what is the reason? So you can have a global css file difficult to maintain and update? So you can give a stupid class name to every single tag you use in your markup? So that every time you include third party css there is the risk of confilicts?

saagarjha 6y ago
> And what is the reason? So you can use CSS the way it was designed? > So you can have a global css file difficult to maintain and update? You know you can have multiple CSS files, right? Plus the code is all in one place and you can refactor it. > So you can give a stupid class name to every single tag you use in your markup? No, you give it a good class name. If something is a button, you call it a button rather "grey-rectangle width-500 clickable" > So that every time you include third party css there is the risk of confilicts? That's why you name your classes so this doesn't happen?
- jacobr 6y ago
  I am sure there are plenty of cases where this approach works just fine. I assure you that those of us who work on projects where this would not work are not simply bad at naming things and that’s the only reason we picked component based styles.
- player2121 6y ago
  > So you can use CSS the way it was designed? css was designed to style HTML documents. It was never designed to build rich and scallable apps thus we have all these libraries which fixes a lot of underlining problems.
  - saagarjha 6y ago
    What problems do they fix? How do they deal with refactoring?
    - cutemonster 6y ago
      Refactoring: I suppose one then just refactors js instead of css. And even simpler/safer? If using typescript to make the js and refactorings type safe
- mmm_grayons 6y ago
  Using something the way it was designed isn't an inherent virtue nor a reason to do so. Nothing is designed perfectly. > "grey-rectangle width-500 clickable" Oof, this is starting to feel like working with a Microsoft product.
- ggregoire 6y ago
  > And what is the reason? >> So you can use CSS the way it was designed? This is not a reason why people should not use inline style. Also, CSS was designed 23 years ago. A few things happened in web development since 2 decades. > No, you give it a good class name. If something is a button, you call it a button It just doesn't work when your app has 100 buttons. You can introduce a naming methodology like BEM but naming conventions are hard to enforce, annoying to follow, and there are always guys on your team who disagree with them (for bad and good reasons).
  - deckard1 6y ago
    > conventions are hard to enforce This seems to be a thing in the past 5 years or so. I've seen developers refuse to follow the existing coding style simply because there was no lint or prettier rule for it. Like, how fucking hard is it to match the style of the existing code base and not be a dick about it. These are lead and seniors I'm talking about. This is the type of thing junior devs should have learned their first month on the job. I can't even imagine contributing to an open source project in the '90s or early 2000s and not matching the existing code with whatever I'm doing. I don't care if it's tabs or spaces or whatever variation of if-branch nesting you prefer. When I'm working on code that already exists, I leave my ego at the door and try to make the codebase uniform and coherent. Hell, the whole reason prettier exists is because we think we can fix these anti-social developers with technology. And of course that doesn't work, so now you need tailwind or whatever.
holoduke 6y ago
nah. what about theming? you cannot do that with inline styles. I think external CSS files for layout is always better than inline. it's very hard to debug and fix UI issues. nowadays you fix stuff on the fly with your browser inspector. you copy the result and paste it in your CSS file. cannot be simpler than that
- player2121 6y ago
  > nah. what about theming? you cannot do that with inline styles. Nobody is utilizing inline styles in that example. It _looks_ like inline styles but it not. It generates css class name behind the hood which you can override in multiple ways. Starting from the ThemeProvider or just like this: const Footer = styled.div` ${PrimaryButton} { color: red; } ` I strongly suggest to look at https://styled-system.com/ https://styled-system.com/ to better understand the mechanics.

Vinnl 6y ago

Note that you're not directly setting the size and the like. Instead, you're selecting items from a scale that should compose well together. They could advertise this better; I've read a post in the past that explained it well, but unfortunately I couldn't find it any more. https://styled-system.com https://styled-system.com might be a good place to start if you want to investigate why there might be more to it than you might assume at first. Edit: I think this was the one: https://jxnblk.com/blog/mathematical-web-typography/ https://jxnblk.com/blog/mathematical-web-typography/

saagarjha 6y ago

Yeah, it's the new "utility CSS" thing that is basically just inline style with a bit less boilerplate. It's quick to get started with, hence its popularity, but it's not really great after that.

ericwood 6y ago
I'm not a huge fan of atomic CSS, but part of the idea behind it is it solves the "ever-inflating CSS bundle" as well as the "where do I put this CSS" problems, both of which are issues on large projects.

ggregoire 6y ago

> There was a reason we stopped using inline styles... A few things happened between the 2000's and today tho. Practices evolve along with tools and technologies. We started styling our React components with CSS years ago at my job and we have been keeping doing so until today. While it works (if everybody on your team agrees to follow the same methodology and conventions, which is hard to enforce), it provides 0 benefits for us. We just went this way because it has always been the way to go while developing web stuff with Java, PHP, Django and friends. Separating the style from the structure while composing presentational components (Text, Box, etc) in a page doesn't actually make much sense and CSS maintenance, class naming and conflicts prevention is a real burden. I've been following the "CSS-in-JS" solutions (which have been developed to solve these exact issues) during the last years and it seems like they could help us focusing on what actually matters.