Live data from Hacker News

Why I Write CSS in JavaScript

mxstbr.com

131–140 of 255 posts

Re: Why I Write CSS in JavaScript

#131
post #79

I'm unconvinced. For one thing, it's not CSS in Javascript... there's no cascade and no sheet, so it's just "styles in Javascript". (And, actually, this article is only about a specific implementation.) The benefits listed are: - "confidence" - but I think that's a matter of understanding and mastering the tool, whether it's CSS or this library. As the co-creator of "styled-components" the author is no doubt a master…

> "Painless Maintenance" - I would have to use it deeply before I could say too much about this. But I would guess that the danger of creating spaghetti code and a spaghetti of .css are pretty much the same and have the same root causes. But as you pointed out, there is no cascade and no sheet. The styles apparently just apply to the stuff they are near in the code. No twisted logic to unwind, hence no spaghetti. The…

Copying and pasting code multiple times creates spaghetti code.

Why does copying CSS multiple times (once for each component) not also create spaghetti code?

Many elements share style in a normal webpage. Font, for example. Having to specify the font in every file seems crazily redundant.

And if you separate that out into a separate file that gets included in many places, you lose all the other benefits like "painless maintenance".

Re: Why I Write CSS in JavaScript

#132
post #128

Imagine a programming language that only had global variables. You have to carefully name your variables using complicated conventions in order to avoid any conflicts or unexpected behavior. Even your functions don't have local variables; there is no lexical scoping. Any function can overwrite or mutate what any other function is doing inside. There is no real encapsulation. After you've done this perfectly, your app…

CSS is not a programming language, and it shouldn't be viewed or compared as one.

It has different functionalities.

Re: Why I Write CSS in JavaScript

#133

In recent projects I tried 3 new approaches: React's CSS-in-JS, Vue's Scoped CSS and Tachyons/Tailwind Atomic CSS. All of those solutions were a huge improvement and scaled better than any of the previous pure-CSS techniques I was using before. BUT the key here is that those things only work when you rely on React/Vue/etc components. If you have have to rely on copy/pasting markup, things go wrong FAST and you lose t…

Those techniques work well for design systems. CSS in JS on its own, and Vue's Scoped CSS are a different thing than Tachyons, Tailwind or Styled System. Styled System is for CSS in JS what Tachyons is for CSS, you're using a design system, either the default values that are already present, or your own customizations.

This basically frees you from making style decisions while coding, depending on your design system, things will just work well together as you create your components, with spacing, colors etc. all being already figured out.

This means that you don't "translate" pixel perfect designs, you use design tools like Sketch or Figma to find the rules and scales that you then translate into the style sheet/design system.

Instead of doing the "configuration" in your CSS when you're coding, you basically have an intermediate step where you set up those rules in advance, and can just focus on composition.

Re: Why I Write CSS in JavaScript

#134
post #132
post #128

Imagine a programming language that only had global variables. You have to carefully name your variables using complicated conventions in order to avoid any conflicts or unexpected behavior. Even your functions don't have local variables; there is no lexical scoping. Any function can overwrite or mutate what any other function is doing inside. There is no real encapsulation. After you've done this perfectly, your app…

CSS is not a programming language, and it shouldn't be viewed or compared as one. It has different functionalities.

It's a language either way, whether you consider it "programming" is not really important. So, good luck with that.

I live in the real world where it's used almost exclusively by programmers.

Re: Why I Write CSS in JavaScript

#135

In recent projects I tried 3 new approaches: React's CSS-in-JS, Vue's Scoped CSS and Tachyons/Tailwind Atomic CSS. All of those solutions were a huge improvement and scaled better than any of the previous pure-CSS techniques I was using before. BUT the key here is that those things only work when you rely on React/Vue/etc components. If you have have to rely on copy/pasting markup, things go wrong FAST and you lose t…

Those techniques work well for design systems. CSS in JS on its own, and Vue's Scoped CSS are a different thing than Tachyons, Tailwind or Styled System. Styled System is for CSS in JS what Tachyons is for CSS, you're using a design system, either the default values that are already present, or your own customizations. This basically frees you from making style decisions while coding, depending on your design system,…

> Those techniques work well for design systems.

That's true! I find that enforcing a consistent and quickly-changing design system is way easier than when I was using old techniques.

> Instead of doing the "configuration" in your CSS when you're coding, you basically have an intermediate step where you set up those rules in advance, and can just focus on composition itself.

You summed it up perfectly

Re: Why I Write CSS in JavaScript

#136

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

All three of the points raised are just dismissing the root of the problem and offering a "solution" using plain CSS classes that relies on everybody following some bespoke convention to work around the problem rather than addressing it head-on like CSS-in-JS solutions do.

1. and 2. attempt to address the lack of modularity in CSS through convention when you can have guaranteed modularity through auto-generated CSS classes that are content-addressed and thereby globally unique by definition with CSS-in-JS. Not to mention you can use a real module system for sharing styles instead of being limited to sharing variables through some global context, which again opens up the possibility of name clashes.

3. recommends a solution for dynamic styles based on yet another CSS feature that relies on global namespacing, and then a fallback based on string concatenation that can't actually address all dynamic use cases. Then it goes on to dismiss the use case entirely, when in a single page application, all styles are inherently dynamic based on the state of the components that are currently being rendered, which is why there's such a painfully obvious impedance mismatch when implementing anything that's truly dynamic using CSS classes, when you have to resort again to concatenating lists of static classes together rather than mapping state to styles directly like you could with CSS-in-JS.

Of course, I'm not saying those approaches can't work at all, nobody is saying that. You can obviously make them work, and people have used those approaches for ages before CSS-in-JS came along. But using the existence of those approaches to dismiss a different approach that tangibly addresses the inherent flaws of those approaches doesn't feel like a particularly compelling argument.

Re: Why I Write CSS in JavaScript

#137
post #132
post #128

Imagine a programming language that only had global variables. You have to carefully name your variables using complicated conventions in order to avoid any conflicts or unexpected behavior. Even your functions don't have local variables; there is no lexical scoping. Any function can overwrite or mutate what any other function is doing inside. There is no real encapsulation. After you've done this perfectly, your app…

CSS is not a programming language, and it shouldn't be viewed or compared as one. It has different functionalities.

CSS is a tool used by web developers to style their websites.

Whether technically it's a programming language or not is tangential.

Re: Why I Write CSS in JavaScript

#138

Earlier quoted context omitted.

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

I agree, but it is not really an excuse to write bad code.

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

Re: Why I Write CSS in JavaScript

#139
post #128

Imagine a programming language that only had global variables. You have to carefully name your variables using complicated conventions in order to avoid any conflicts or unexpected behavior. Even your functions don't have local variables; there is no lexical scoping. Any function can overwrite or mutate what any other function is doing inside. There is no real encapsulation. After you've done this perfectly, your app…

CSS isn't a programming language, that is the fundamental difference and explains a LOT of the debate surrounding it.

Re: Why I Write CSS in JavaScript

#140
I'm of the opinion that CSS actually has more in common with logic-based programming languages (like Prolog, or more specifically ones based on defeasible logic) than with ordinary languages of the "imperative" or "functional" sort. I think that reading CSS with this in mind helps make sense of some of CSS's features (e.g. specificity, the way selectors work).
Post reply on HN