Live data from Hacker News

Why I Write CSS in JavaScript

mxstbr.com

41–50 of 255 posts

Re: Why I Write CSS in JavaScript

#41

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.

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.

Re: Why I Write CSS in JavaScript

#42
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.

Re: Why I Write CSS in JavaScript

#43
post #28
post #7

Earlier quoted context omitted.

I know this will be unpopular, but after a certain point, noscript users just get a bad experience and that can't be helped. If a developer wants to provide a rich experience, then there will always be certain platform requirements. Without them, you will have a lacklustre experience. It's like saying "I want to have all the whizzy functionality of your app, but I want to access it using a standard, run of the mill,…

I know how the sausage is made, so I know that making a full web app work without JS isn't at reach for most teams/products. By knowing how the sausage is made, I'm also aware that the line marking the aforementioned certain point is often drawn too early, at informational (i.e. document) stuff where HTML and CSS are fully capable on their own.

You underestimate developers; they can make it work without JS if they have to. But why should we constrain ourselves?! I mean, there is nothing wrong with JS when used properly.

In fact, JS is extremely useful in the browser. It adds to the richness and interactivity of webpages. We must collectively appreciate this, and stop denying this! Even HN is a better experience with JS.

Some sites do give JS a bad name, and poorly used JS is something I hate too, but JS as a concept is something that I wholeheartedly support. Thankfully, the web is mostly opt-in - if you don't like the way a site employs technology, just don't visit it. Simple.

Re: Why I Write CSS in JavaScript

#44

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

That's also what we do here on a dozen of apps and it works.

Each component has its own folder with its own css file and each rule starts with .name-of-the-component.

For dynamic properties, we either create conditional classes (e.g. 'success', 'error') or pass the rules through 'style' (e.g. dynamic height).

For dynamic themes, we create an object at the root of the app

  const theme = { header: { backgroundColor: black }, button: { backgroundColor: black }, ... }
Then pass it down to the related components

  
  
That being said, I tried styled-components once and don't really have negatives about it. It's a viable option.

Re: Why I Write CSS in JavaScript

#45
post #7

Earlier quoted context omitted.

I know this will be unpopular, but after a certain point, noscript users just get a bad experience and that can't be helped. If a developer wants to provide a rich experience, then there will always be certain platform requirements. Without them, you will have a lacklustre experience. It's like saying "I want to have all the whizzy functionality of your app, but I want to access it using a standard, run of the mill,…

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 sure after reading the article.

Re: Why I Write CSS in JavaScript

#46

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

> 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 file, co-locating css files with the js, I much prefer using `styled-components`. It provides a ton of flexibility, it opens doors for dynamic css by leveraging js (the hacks I've seen, had to write to get css dynamic is astounding), and I don't have to look very far to see how it's being used because the CSS is literally attached to the component I'm using. All I do in VSCode is cmd+click and bam, I can see the CSS for this component. There's no need for naming convention, there's no worry about global css variables getting into your styles, and there's no digging around looking for css that might be influencing your component. The best part for me is: when I delete the component, the CSS is gone as well. There's no thought put into scouring the FS to find lingering CSS that used to be used.

I love `styled-components` and most of the designers I work with also enjoy it.

Re: Why I Write CSS in JavaScript

#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 rebuilding the page from the ground up because it has gotten so messy, no one on the team is interested in touching it.

Re: Why I Write CSS in JavaScript

#48
post #7

Earlier quoted context omitted.

I know this will be unpopular, but after a certain point, noscript users just get a bad experience and that can't be helped. If a developer wants to provide a rich experience, then there will always be certain platform requirements. Without them, you will have a lacklustre experience. It's like saying "I want to have all the whizzy functionality of your app, but I want to access it using a standard, run of the mill,…

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.

There isn't much that can make an in-flight connection seem quick, but we've tried with our PWA (https://usebx.com/app) and to a certain extent, succeeded.

Ok, we do assume that you have visited our webpage at least once in an area of strong signal, however, once you've done that, all the JS is cached and all we transmit back and forth are lightweight, gzipped json payloads, often less than a kilobyte.

I use my own PWA regularly, and found it actually quite usable in-flight.

Re: Why I Write CSS in JavaScript

#49
post #46

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

> 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.

Re: Why I Write CSS in JavaScript

#50
post #33

If you make sure your site works without javascript as well(unless it's actually an app) it's fine by me.

This is a requirement that most sites can simply dismiss these days. The distinction between an app and a website is blurry, a lot of interaction simply works far better with Javascript.

Supporting "no Javascript" can be costly. It's possible with server-side React and careful engineering, but why bother? What's the impact on the business?

Post reply on HN