Why I Write CSS in JavaScript • Hacker News Board

Re: Why I Write CSS in JavaScript

#251

Post by Risord » Tue, Feb 19, 2019, 9:47 PM UTC

exogen wrote: post #224

ahakki wrote: post #223

Earlier quoted context omitted.

stack for haskell nix package manager

Note that npm also supports having multiple versions of the same package installed just fine. The problem: I use X to create an object with library A v1.0. I use Y to create an object with library A v2.0. These objects are not necessarily compatible, so X and Y have problems communicating. I would be very surprised if you told me nix or stack inherently make objects from multiple versions of the same library magicall…

Hmm I think this should go something like this:

How would objects created from X and Y can reach each other and communicate when X is not dependent from Y or otherwise? You need global mutable state or your own code witch depends from both X and Y is somehow connecting them.

So one top thing FP movement argues against is global mutable state so of course you don't have that ...Unless you are wrapping some non-FP thing like QT...

And if it's your own code it shouldn't be different that Y creates B:s instead of A v2 since your code is aware from two different versions anyway.

Do you see any weak points?

Re: Why I Write CSS in JavaScript

#252

Post by charlieflowers » Wed, Feb 20, 2019, 1:23 PM UTC

smrq wrote: post #179

tokyodude wrote: post #177

Earlier quoted context omitted.

Not a solution for CSS I guess but if I was using a programming language that had only global variables I'd write a compiler to generate variable names.

It is a solution for CSS, and it's called CSS Modules.

and it counts as "css in js"

Re: Why I Write CSS in JavaScript

#253

Post by _ea1k » Wed, Feb 20, 2019, 8:01 PM UTC

pmlnr wrote: post #166

_ea1k wrote: post #154

Earlier quoted context omitted.

That limitation is why people like the article writer often replace it with a programming language.

It's not a limitation. It's different.

It is both. Whether you consider that a good or a bad thing is an entirely separate issue.

Re: Why I Write CSS in JavaScript

#254

Post by designingsean » Thu, Feb 21, 2019, 3:43 AM UTC

So reading this article made me have a bit of an epiphany: What is being described isn't CSS-in-JS. Instead, this is style properties in JS.

This is the equivalent of inline styles. We don't call it "inline CSS" because it isn't CSS. Nothing cascades with inline styles, just as they don't with "CSS-in-JS". And you don't have to worry about specificity with either implementation.

In other words - all the things that make CSS the powerful language it is are stripped away to just a listing of arbitrary properties.

So, CSS-in-JS, do yourself a favor and stop calling it that, because what you are coding is nothing even remotely close to CSS.

Re: Why I Write CSS in JavaScript

#255

Post by lwhi » Thu, Feb 21, 2019, 2:55 PM UTC

tracker1 wrote: post #206

lwhi wrote: post #124

Earlier quoted context omitted.

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

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

There have been many philosophical (and practical) conversations over the years that have lead to the development of a rich and varied frontend development ecosystem.

If you're building a frontend system, you need to consider the overall (macro) view, as well as the detail oriented (micro) view.

It's very difficult to do this with CSS in JS because of the compromises that need to be made to work in this way.