Live data from Hacker News

Why I Write CSS in JavaScript

mxstbr.com

51–60 of 255 posts

Re: Why I Write CSS in JavaScript

#52

While Styled Components, Styled JSX or Linaria (which doesn't require a JS runtime for production) are nice solutions, the fact that I can no longer use the colour picker and other tools to live edit CSS from the styles pane in the Elements tab in Chrome Dev Tools, sometimes makes me want to go back to plain CSS to get this functionality back.

You can! I do this all the time.

With copy and paste? :)

Re: Why I Write CSS in JavaScript

#53
I write CSS in CSS and my JavaScript in JavaScript because at some point abstractions pile up into this massive cognitive burden for anyone adopting your code, especially when they didn't follow the exact same path as you technology-wise or if they're newcomers. I want my work to be pick-up-and-play, not RTFM x 20 abstractions and tools.

Re: Why I Write CSS in JavaScript

#54
post #2

Author here, happy to respond to any questions. AMA!

How do you plan to accommodate NoScript users?

They're economically irrelevant so they're ignored. Their demands tend to be edge cases.

NoScript users are like the customer that demands the most but pays least. After some rants of such customer, they're ignored.

Re: Why I Write CSS in JavaScript

#55
post #47

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 r…

... especially web designers.

Re: Why I Write CSS in JavaScript

#56

I understand the "pit of success" idea, particularly when it comes to more junior devs. But I don't necessarily agree that you need stringent processes to get most of the gains you cite from using something like SCSS or even regular CSS these days. It's really easier than ever. 1- append only? No, each module/feature/widget gets its own CSS file, imported to the main app CSS file. Delete the widget? Delete the file.…

> 2- Specificity issues? Never use IDs, stop using tag names and simple classes and adopt a simple naming structure

I have one exception to that in my own work, which is to only ever use IDs for styles that affect the layout of a block/component on a specific page. This makes sense since parts of a page layout are usually very specific and not that dynamic(in which case class names might be more appropriate). At the same time, component-level styles should never make assumptions about how they are positioned on a given page.

Let's say that we have a page `/blog/:entry_id`, and this page has a right-hand column to list related blog entries. This component would have an id `#blog-entry__entries-list`, which would control how the related-entries list appears on the blog-entry page(in this case, putting it in a column on the right), and a `.entries-list` class that controls the global appearance of the component.

This way, the entries-list can be used in different contexts without having weirdness caused by a margin working fine on one page but having to be negated on another page where the margin doesn't work. Try to add styles, but do as minimal overriding as possible.

In combination with BEM, primarily for the benefit of all selectors having the same specificity, I've found this separation of concerns between IDs and class names to be very powerful and simple to understand, especially since it doesn't require more verbosity.

Another part of my styling workflow is Sass mixins.

Let's say that we want the entries-list component to appear more compact on another page. Perhaps it appears somewhere on the site index, and takes up a little more room than we'd like.

Since component styles can't assume anything about their environment, and since layout styles(i.e. our ID selectors) can't know about the inner workings of their components, there needs to be a way for layouts to have a choice of component variations.

In this case, I would create a mixin `entries-list--compact` inside the entries-list Sass file, which would contain CSS properties that would make the entries-list smaller.

Back on in the index Sass file, I would include that mixin:

```

  #index__entries-list {

    @include entries-list--compact;

  }
```

But what if we only need the list to be compact at a specific page width?

```

  @media (max-width: 640px){

    #index__entries-list {

      @include entries-list--compact;

    }

  }
```

I've found this pattern of mixins to be very powerful. Any page can decide whether to use any mixin at any page-width. CSS for layout stays very lean, as the only properties it's concerned with 99% of the time is width, height, margin, and padding. A component can be completely replaced with new styles and behave properly on existing pages so long as it conforms to its existing "API" of mixins.

Re: Why I Write CSS in JavaScript

#57

Earlier quoted context omitted.

noscript users certainly signed up for a subpar internet experience, but its not just them that should be thought about. Slow internet connections are a reason to think about the experience when loading JS is slow and/or failed. It's not just 'poor people' who have slow internet - 'rich people' on inflight wifi or on the internet on the train can result in things not loading.

I think this is a big issue with such JavaScript and load heavy web-sites & apps. They forget that they have users without 1GB connections and who can't afford, weather financially or location based, the download the 500MBs of data required to load their web-site. That and hiding CSS inside of JS feels like a sneaky tactic to keep people from editing it? Or does it actually create the CSS on the fly? I wasn't quite s…

No regular JS only website/app required 500mb of data. Please stop exaggerating. It does not make your point valid.

Re: Why I Write CSS in JavaScript

#58
post #46

Earlier quoted context omitted.

> Delete the widget? Delete the file. This rarely happens. I would argue that creating an automated system to enforce "rules" should be favored over forcing every developer to know the rules and abides by them. It is much easier to understand the relationship between css and js when the css is just a js variable. Having built many large applications using the CSS file method, css modules, each widget gets its own fil…

Why wouldn't the CSS file be deleted? It should be co-located with the widget, so you just delete the entire widget folder.

Yeah, it's really not hard to delete a CSS file. People really are that lazy, but that's on them, not the technology.

Re: Why I Write CSS in JavaScript

#59

This sounds like an awful idea. Just put your CSS in a .css file where it can be cached, delivered by CDNs and can easily be edited in a single place. Separation of content and presentation has been around for a good reason. One should always avoid mixing logic and design because it will break some day, no matter how well you think you handle it.

> Just put your CSS in a .css file where it can be cached, delivered by CDNs

.js files are cached and delivered by CDNs too.

> can easily be edited in a single place

If you change the name of a class (or add a new one, delete another one, edit the structure of the component, etc...), then you have to open and edit 2 files. With author's solution you don't. The CSS is collocated with the component.

> Separation of content and presentation has been around for a good reason. One should always avoid mixing logic and design

Author is talking about putting the React component (presentation) and its CSS (presentation) in the same file. He's not mixing business logic and design.

Re: Why I Write CSS in JavaScript

#60
post #2

Author here, happy to respond to any questions. AMA!

Honestly, I think the CSS-in-JS approach is not for me and we haven't used it except for times where there was no other way to do something. Instead we have used CSS Modules ( https://github.com/css-modules/css-modules ), first by including it manually in webpack, now it's already built into create-react-app so I just have to install node-sass and call my Sass files ComponentName.module.scss and I can use them the sa…

Bonus point: you get hot reload while editing CSS.
Post reply on HN