7 ms·

We built a relatively large social media management platform, and for one of our major features (a streams page that shows social media activities from differen

by Yabood 8y ago

We built a relatively large social media management platform, and for one of our major features (a streams page that shows social media activities from different sources), we put a lot of our css in JS including all the logic for stream sizing/resizing and page responsiveness. I can honestly say that this approach is terrible. It is a maintenance nightmare. Even the smallest changes require a ton of time. We're now rebuilding the page from the ground up because it has gotten so messy, no one on the team is interested in touching it.

therealmarv 8y ago
... especially web designers.
- pluma 8y ago
  What are you trying to say?
loz220 8y ago
Poorly designed code is possible with any language. Was it unmaintainable because of something fundamental to css in js?
abderrahmane 8y ago
Why can't we see more of these stories surfacing on the internet. All I see when I search for CSS-in-JS on google is how, CSS-in-JS is so great. Why don't we have more : "We tried it, it is the worst, especially for products which lifespan is more than two months"
- black-alert 8y ago
  > Why don't we have more : "We tried it, it is the worst, especially for products which lifespan is more than two months" Because that last sentence is just rubbish, CSS in JS is great. I'm using it for large projects already 4 years. If your experience is bad you must be doing something wrong. CSS in JS is almost the same as working with (S)CSS, except for extra power to control dynamic elements without having to juggle with classnames.
  - YorickPeterse 8y ago
    Clearly when somebody has a bad experience, they are just doing it wrong. Or perhaps there's something to it, and the idea is not as good as one might claim it to be.
    - pvorb 8y ago
      Or they are solving other problems and that's the reason why one believes a solution is bad and another one thinks it's the best.
  - abderrahmane 8y ago
    Juggling pre-compiled gpu stuff (css classes) exists for a reason. Scss is like css. Jss is css + unnecessary abstraction on top of css + unnecessary memory and cpu cycles + writing part of css rules inside flow control (which can turn into js in css in js. GPU facing languages have always been ugly and not just in this industry. But they are like that because of their nature. Making them friendlier is always welcome, but replacing them with cpu stuff defeats the whole purpose of a gpu.
  - lwhi 8y ago
    > CSS in JS is almost the same as working with (S)CSS, except for extra power to control dynamic elements without having to juggle with classnames. I completely disagree. Time and effort creating frontend design systems, will result in a set of CSS files .. but will also enable efficiency, flexibility, accessibility, maintainability and extensibility. These qualities just aren't going to be as available if you use CSS in JS.
    - tracker1 8y ago
      There's nothing expressly better about SCSS over CSS in JS that you have demonstrated. CSS In JS is mostly using similar structure, but often the JS dom interface naming... so fontFamily instead of font-family. It's also far easier to introduce codified variant functions or variable injection in JS than it is in SCSS. I'm not saying don't use SCSS if it fits your model better... I've been very happy using react-jss via material-ui ... I've extended the baseline theme and that gets used throughout the application with each component defining its' styles that get injected. Sharing can be a little more awkward, but it's easy enough, just call the same style method(s), or extend the baseline theme that gets injected. The only thing you mention that might be better with (S)CSS directly would be efficiency and even that's relative. You can absolutely do all the rest with CSS in JS.
- 1_player 8y ago
  At my company, I made the executive decision to drop CSS-in-JS because none of those libraries support PostCSS, and most have their own from-stratch, half-baked CSS transformation pipeline, not 10% as powerful as the PostCSS ecosystem. I love PostCSS, and I'll happily consider CSS-in-JS again when somebody writes a library that doesn't try to reinvent the wheel.
felxh 8y ago
I am curious, what made it a maintenance nightmare?
simplify 8y ago
Why did small changes require a ton of time?

by Yabood 8y ago

therealmarv 8y ago

... especially web designers.

pluma 8y ago
What are you trying to say?

loz220 8y ago

Poorly designed code is possible with any language. Was it unmaintainable because of something fundamental to css in js?

abderrahmane 8y ago

Why can't we see more of these stories surfacing on the internet. All I see when I search for CSS-in-JS on google is how, CSS-in-JS is so great. Why don't we have more : "We tried it, it is the worst, especially for products which lifespan is more than two months"

black-alert 8y ago
> Why don't we have more : "We tried it, it is the worst, especially for products which lifespan is more than two months" Because that last sentence is just rubbish, CSS in JS is great. I'm using it for large projects already 4 years. If your experience is bad you must be doing something wrong. CSS in JS is almost the same as working with (S)CSS, except for extra power to control dynamic elements without having to juggle with classnames.
- YorickPeterse 8y ago
  Clearly when somebody has a bad experience, they are just doing it wrong. Or perhaps there's something to it, and the idea is not as good as one might claim it to be.
  - pvorb 8y ago
    Or they are solving other problems and that's the reason why one believes a solution is bad and another one thinks it's the best.
- abderrahmane 8y ago
  Juggling pre-compiled gpu stuff (css classes) exists for a reason. Scss is like css. Jss is css + unnecessary abstraction on top of css + unnecessary memory and cpu cycles + writing part of css rules inside flow control (which can turn into js in css in js. GPU facing languages have always been ugly and not just in this industry. But they are like that because of their nature. Making them friendlier is always welcome, but replacing them with cpu stuff defeats the whole purpose of a gpu.
- lwhi 8y ago
  > CSS in JS is almost the same as working with (S)CSS, except for extra power to control dynamic elements without having to juggle with classnames. I completely disagree. Time and effort creating frontend design systems, will result in a set of CSS files .. but will also enable efficiency, flexibility, accessibility, maintainability and extensibility. These qualities just aren't going to be as available if you use CSS in JS.
  - tracker1 8y ago
    There's nothing expressly better about SCSS over CSS in JS that you have demonstrated. CSS In JS is mostly using similar structure, but often the JS dom interface naming... so fontFamily instead of font-family. It's also far easier to introduce codified variant functions or variable injection in JS than it is in SCSS. I'm not saying don't use SCSS if it fits your model better... I've been very happy using react-jss via material-ui ... I've extended the baseline theme and that gets used throughout the application with each component defining its' styles that get injected. Sharing can be a little more awkward, but it's easy enough, just call the same style method(s), or extend the baseline theme that gets injected. The only thing you mention that might be better with (S)CSS directly would be efficiency and even that's relative. You can absolutely do all the rest with CSS in JS.
1_player 8y ago
At my company, I made the executive decision to drop CSS-in-JS because none of those libraries support PostCSS, and most have their own from-stratch, half-baked CSS transformation pipeline, not 10% as powerful as the PostCSS ecosystem. I love PostCSS, and I'll happily consider CSS-in-JS again when somebody writes a library that doesn't try to reinvent the wheel.

felxh 8y ago

I am curious, what made it a maintenance nightmare?

simplify 8y ago

Why did small changes require a ton of time?