4 ms·

The down-side with this is very high coupling between UI logic and style. If style becomes out of fashion, you have to modify files that contain logic. If fram

The down-side with this is very high coupling between UI logic and style. If style becomes out of fashion, you have to modify files that contain logic. If framework (react/vue) becomes out of fashion, keeping styles will be difficult. The other down-side is thousands of web developers having to re-learn CSS and the tooling behind your app instead of just changing CSS files.

tobr 8y ago
In practice, I think a lot of people have found that you can rarely do a complete overhaul of a website’s design using only CSS. Even if you could, it would be impossible to feel confident that your changes look reasonable across all uses of said CSS. So if you’re doing a big redesign you will usually have to work with logic anyway. I think there’s truth to your second point though - reusing styles in parts of a project that does not use the same framework. Something like Tailwind CSS can be a good option then.
- gedy 8y ago
  > you can rarely do a complete overhaul of a website’s design using only CSS Full design yes, but branding/theming is much easier if you use an external styling framework like Bootstrap 4 or Foundation and use their component and utility classnames. We have a 300+ page app and tried the one stylesheet per component thing with theme and layout all combined in the past, and was a huge mistake. Banning most custom CSS in place of using the Bootstrap component and util classes has been so much easier.
antris 8y ago
Your styles are coupled to your UI logic anyway, even if you go out of your way to make them implicit by separating the CSS and JS into their own files. It's better to have the relationship explicitly defined in code instead of hiding it. That's the whole reason why CSS sometimes breaks in unexpected ways: you fail to realize the implicit coupling of the styles and the UI logic, so you fail to reason what changes need to be made both to styles and the UI logic to make your change.
realharo 8y ago
>If style becomes out of fashion, you have to modify files that contain logic. So just put the styles in separate .js files and import them.
overgard 8y ago
Ok, but, the average startup web dev stays at a company for like two years? And then the thing eventually gets rewritten anyway in the latest flavor of the week, because nobody is using the same tools as two years ago. I guess the concern for longevity most devs have is amusing when most software, if its not like systems level stuff, or problems most devs dont want to solve, tends to get disposed pretty frequently. By the way, most of the software that actually sticks around was written in C and generally solves a problem most people wont tackle. Like zlib or sqlite or nginx or the linux kernel. You can almost pretty much judge the longevity of a piece of software based on how hard the problem it tackles is. Like encryption or compression? Those libraries are going to be around forever, because how many coders do you know that can write a semi compitent encryption library? And how manu coders can write a templating engine? Like most of web dev is throwaway code. It just is. Arguments based on like "will they be able to restyle it in 10 years?" Well are they even going to be around?
- antoineMoPa 8y ago
  I agree, but it is not really an excuse to write bad code.
  - overgard 8y ago
    Absolutely. But im not sure "bad code" is the same thing as code written for a purpose at a particular time. I think something can be good code if its lifespan is understood in the context of the business goals. I just get cynical when I hear people apply these principles to something that may live five years. Not every project is going to be maintained for 30 years
- svnpenn 8y ago
  > encryption or compression both of these are pretty bad examples, as several modern developments have surfaced in both cases - here are 2 examples - https://wikipedia.org/wiki/Curve25519 https://wikipedia.org/wiki/Curve25519 - https://github.com/google/brotli https://github.com/google/brotli
alangpierce 8y ago
You don't need to use different languages to decouple things. A common pattern in React is to decouple logic and style using presentational components and container components (there are lots of articles on it if you Google those two terms), and I find that split to be much more natural than trying to split up HTML, JS, and CSS (which often need to cooperate with each other). One good practice with CSS-in-JS is to only use CSS in presentational components.
tracker1 8y ago
If you're building a complex UI that uses components as a cohesive library, there will always be some coupling. Even with the classic bootstrap example, once you've built an application and introduced any number of third party components, it gets messy to change things. Better to have a cohesive set of theme/rules and get them to work together as best possible. I've been a big fan of material-ui and react-jss and is imho about the best option I've used in over two decades of working on web based applications.
JetSpiegel 8y ago
And now you know why "dark mode" is touted as a feature, instead of being a 5 line css file with some "!important" rules.

tobr 8y ago

In practice, I think a lot of people have found that you can rarely do a complete overhaul of a website’s design using only CSS. Even if you could, it would be impossible to feel confident that your changes look reasonable across all uses of said CSS. So if you’re doing a big redesign you will usually have to work with logic anyway. I think there’s truth to your second point though - reusing styles in parts of a project that does not use the same framework. Something like Tailwind CSS can be a good option then.

gedy 8y ago
> you can rarely do a complete overhaul of a website’s design using only CSS Full design yes, but branding/theming is much easier if you use an external styling framework like Bootstrap 4 or Foundation and use their component and utility classnames. We have a 300+ page app and tried the one stylesheet per component thing with theme and layout all combined in the past, and was a huge mistake. Banning most custom CSS in place of using the Bootstrap component and util classes has been so much easier.

antris 8y ago

Your styles are coupled to your UI logic anyway, even if you go out of your way to make them implicit by separating the CSS and JS into their own files. It's better to have the relationship explicitly defined in code instead of hiding it. That's the whole reason why CSS sometimes breaks in unexpected ways: you fail to realize the implicit coupling of the styles and the UI logic, so you fail to reason what changes need to be made both to styles and the UI logic to make your change.

realharo 8y ago

>If style becomes out of fashion, you have to modify files that contain logic. So just put the styles in separate .js files and import them.

overgard 8y ago

Ok, but, the average startup web dev stays at a company for like two years? And then the thing eventually gets rewritten anyway in the latest flavor of the week, because nobody is using the same tools as two years ago. I guess the concern for longevity most devs have is amusing when most software, if its not like systems level stuff, or problems most devs dont want to solve, tends to get disposed pretty frequently. By the way, most of the software that actually sticks around was written in C and generally solves a problem most people wont tackle. Like zlib or sqlite or nginx or the linux kernel. You can almost pretty much judge the longevity of a piece of software based on how hard the problem it tackles is. Like encryption or compression? Those libraries are going to be around forever, because how many coders do you know that can write a semi compitent encryption library? And how manu coders can write a templating engine? Like most of web dev is throwaway code. It just is. Arguments based on like "will they be able to restyle it in 10 years?" Well are they even going to be around?

antoineMoPa 8y ago
I agree, but it is not really an excuse to write bad code.
- overgard 8y ago
  Absolutely. But im not sure "bad code" is the same thing as code written for a purpose at a particular time. I think something can be good code if its lifespan is understood in the context of the business goals. I just get cynical when I hear people apply these principles to something that may live five years. Not every project is going to be maintained for 30 years
svnpenn 8y ago
> encryption or compression both of these are pretty bad examples, as several modern developments have surfaced in both cases - here are 2 examples - https://wikipedia.org/wiki/Curve25519 https://wikipedia.org/wiki/Curve25519 - https://github.com/google/brotli https://github.com/google/brotli

alangpierce 8y ago

You don't need to use different languages to decouple things. A common pattern in React is to decouple logic and style using presentational components and container components (there are lots of articles on it if you Google those two terms), and I find that split to be much more natural than trying to split up HTML, JS, and CSS (which often need to cooperate with each other). One good practice with CSS-in-JS is to only use CSS in presentational components.

tracker1 8y ago

If you're building a complex UI that uses components as a cohesive library, there will always be some coupling. Even with the classic bootstrap example, once you've built an application and introduced any number of third party components, it gets messy to change things. Better to have a cohesive set of theme/rules and get them to work together as best possible. I've been a big fan of material-ui and react-jss and is imho about the best option I've used in over two decades of working on web based applications.

JetSpiegel 8y ago

And now you know why "dark mode" is touted as a feature, instead of being a 5 line css file with some "!important" rules.