Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Write CSS in JavaScript

mxstbr.com

Post reply on HN
Print view View original

101–110 of 255 posts

Re: Why I Write CSS in JavaScript

#101

Post by consolenaut »

As someone coming from a traditional strict separation-of-content-and-style background and now convert to Styled Components, CSS-in-JS felt unnatural to me when I first encountered it. The problems with styles in large applications are well known and I had a solid handle on them with BEM and other bits of tooling, namespacing styles to a particular React component to avoid collisions etc.

It took me helping my brother learn how to do web development to shake me out of that mindset. He's not from a traditional webdev background and he got quite far quite fast with React. When he showed me his code, I noticed he was inlining all of his styles in his relatively small React components. I was going to explain why its bad practice to do that, but when you're building small almost atomic components, that approach actually makes a lot of sense, its what the BEM methodology tries to do albeit in a poorer way. CSS-in-JS tools like Styled Components preserve the spirit of this approach and minimise the downsides.

I think CSS-in-JS lends itself quite nicely to atomic design. At my current company, one of the first things we did was build a component library of atoms & molecules that are shared across many applications, keeping our design language very consistent.

We also make heavy use of Styled Components' theming capabilities, so we wrap our React apps with a ThemeProvider and give it an object with theme variables that drive the look and feel of our components. This is super useful when you have to support whitelabeling like we do, but even if you don't, its nice to keep your mystery-meat colors and spacings all in one place similar to how you might with SASS.

One of the gripes a lot of people have with CSS-in-JS is portability, and while that is a drawback, I feel it's an anti-pattern to rely on shared CSS styles to enforce design consistency across many deployables. It's kind of a classic case of developers trying to solve a process issue with technology, which is admirable, but from experience styles go out-of-sync with eachother quite easily and its rare that you can drop a CSS file into another project and have styles just work without having to do rework, so the benefits of sharing CSS rather than writing new styles off a styleguide are marginal at best. Again, this is all my subjective experience, your mileage may vary.

We still have a couple of issues with Styled Components, no technology is perfect and SC is still relatively young, but so far the pros have far outweighed the cons to the point where none of us really feel the itch to go back to SASS or plain CSS. I'm definitively not a magpie developer by any stretch, I'm usually resistant to change for the sake of change, but CSS-in-JS makes a lot of sense when you use it how its intended

Re: Why I Write CSS in JavaScript

#102

Post by jimmaswell »

LocalPCGuy wrote: post #19

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

How is it better to have only one of something and give it a class that nothing else uses than to use IDs how they're intended?

Re: Why I Write CSS in JavaScript

#103

Post by antihero »

therealmarv wrote: post #9

In my opinion this is a workaround for a language flaw in the React concept. Look at this beauty for comparison: https://vuejs.org/v2/guide/single-file-components.html

To me this seems really implicit and magical and strange.

Where is template getting assigned to the code inside the script tag?

Does OtherComponent somehow mysteriously map to other-component? How does one pass arguments to it? Is a .vue file actually HTML or is it parsed somehow to be HTML?

The thing I like about React is the explicitness of it. This is a source code file that exports component X. Component X uses style Y as defined above because it's explicitly passed in as a prop, etc etc.

Re: Why I Write CSS in JavaScript

#104

Post by antihero »

preommr wrote: post #78
akuji1993 wrote: post #22

Earlier quoted context omitted.

Hm, I don't share your opinion on this matter, to be honest. You can easily avoid this in both Angular (which does it out of the box) and React by including CSS Modules ( https://github.com/css-modules/css-modules ) which, if you use create-react-app to build your projects, is a 5 minute change to your architecture. So there really is no reason to write that down as a con for React.

I have so many small components that I would loathe to have a separate stylesheet. Yes, it's a small thing to just switch tabs, but this is a small problem. And these small problems add up and can be a huge pain. I really really like the SFCs in vue and compare it to a bit of butter on toast. It might be a small thing, but it seems like it makes a big difference.

So you can just use styled-components as in the OP

Re: Why I Write CSS in JavaScript

#105

Post by iaml »

preommr wrote: post #87
cageface wrote: post #65

Earlier quoted context omitted.

You can do this with styled-components in react too. https://www.styled-components.com/

Yea, but this isn't out of the box. This is some 3rd party solution for a pretty major part of an application.

You are complaining about react's philosophy itself, which is they don't want to make any choices for you.

Re: Why I Write CSS in JavaScript

#106

Post by LocalPCGuy »

jimmaswell wrote: post #102
LocalPCGuy wrote: post #19

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

How is it better to have only one of something and give it a class that nothing else uses than to use IDs how they're intended?

I take issue with your assertion about how IDs "are intended". I think that idea (and CSS being taught that way) is one of the reasons people have trouble with CSS.

There are quite a few reasons for preferring to not use IDs, here's two:

1- specificity of IDs always trumping things

2- having to change it from an ID to a class later on if it becomes a reusable item (which in a widget, is almost always the case). There is no reason a class cannot apply to just a single item, where an ID is by its nature limited.

Re: Why I Write CSS in JavaScript

#107

Post by GordonS »

bastawhiz wrote: post #27
vehemenz wrote: post #17

How do you handle advanced CSS Level 3/4 selectors, CSS grid, and media queries?

The idea with CSS-in-JS is that you don't use selectors. Since you are constructing DOM nodes individually, you don't need to select them. Styled components can accept props, which lets you style dynamically (e.g., using an array index to replace `:nth-child`). With regard to media queries, it depends on the library. For the library the author is using, the media queries are defined inline: https://www.styled-compone…

Does it use (shared) variables, like with SASS?

With SASS, I find it really convenient to define variables for common/brand colours, for example.

Re: Why I Write CSS in JavaScript

#108

Post by headcanon »

styled-components is not popular on HN it seems. Allow me to share my own positive experience:

I have built websites in a variety of different ways, with a variety of different CSS schemes. I've worked with SASS, LESS, BEM, every major css framework, in both SPA and SSR environments.

I have also built react SPAs with the above variety of CSS schemes, as well as CSS-in-JS libraries like Aphrodite and Styled Components.

I currently build and maintain a medium-to-large web app with a small team, right now ~200 components, 31k lines of js including test files.

Styled Components has been an immensely positive experience for us, and i would not want to use any other way I have mentioned, or has been mentioned in this thread, to manage our styles in our app.

The reason why is because of the simple fact that it allows us to think of our styles just like any other component. We do not need a separate way of managing styles that we need to keep track of, whether a style is used is 100% the same as whether a component is used or not, which makes eliminating dead code, dead styles, easily managed through tooling.

It allows us to define simple, semantically-named components like and , and allows us to compose these components together to build up styles just like any other react component.

Styles are easily overridden from their parents. We use Ant Design for our UI toolkit, which does not use Styled Components, but any styles we want to override, as well as styles in nested classes, are easily done by wrapping an antd component. All the parent component needs to do is accept a "className" property. This makes interop with other components simple.

Effectively what this means is that after awhile, we get to live in a world where I can add a component into any given part of application, and be very certain its going to look and behave the same way it does in every other part of the application. When I'm building new features I don't want to think about styles, except when adding styles is part of the feature itself. Styled Components is the only way so far I've found that does that sufficently.

Globally-available CSS is great for web pages, but not so much for widget-based GUI web apps, which creates leaky abstractions. Most ways of managing CSS are systems to get around that, or treat it as a feature.

In short, 10/10 would use again, even over other CSS-in-JS libraries like Aphrodite. Note this opinion is scoped purely to react apps. Vue's approach seems appealing as well but I have not used it before, but to be honest I do prefer being able to have everything in JS or JSX, but thats a different discussion.

Re: Why I Write CSS in JavaScript

#109

Post by BurningFrog »

ravenstine wrote: post #58
LocalPCGuy wrote: post #49

Earlier quoted context omitted.

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.

This is a losing argument.

Judge all you want, but you can only change technology, not human nature.

Good engineering is to find pragmatic solutions that work in the real world.

Re: Why I Write CSS in JavaScript

#110

Post by LocalPCGuy »

LaserToy wrote: post #74

CSS... sweet memories. For some reason I never was able to learn how the damn thing works. I worked for Google Analitics in 2011 and we rebuilt it using new in house built framework which championed an idea of a separate styles for an on screen component. Every dev was starting a new component with: clean_styles directive as nobody was brave enough to deal with what comes from the top. Even though it was possible to…

> I never was able to learn how the damn thing works

People not taking the time to learn is not a reason to throw an entire building block of the web out.

(Yes, I realize there are a lot of people who know CSS and still choose CSS-in-JS, but I'm specifically referencing the point re: not learning CSS.)

Post reply on HN