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

231–240 of 255 posts

Re: Why I Write CSS in JavaScript

#231

Post by austincheney »

exogen wrote: post #145
austincheney wrote: post #123

Story of my life as a front end developer... you can invent an abstraction to make life easier and simultaneously increase code size and complexity more than 10 fold. Easy is often an anti-thesis of simple. Basic front end code isn't that challenging, but it does take some actual practice (not half-ass practice followed by a million poorly considered short-cuts).

What about non-basic front end code?

Well I did spend this weekend trying figure out how to dynamically update keyframe rules with JavaScript only to discover the window.CSSKeyframesRule API is incomplete on most browsers so I found a different nonstandard way to solve that problem cross browser. I have not seen a failure to implement standards like that in many years.

Just about everything else on the frontend is absolutely solid cross browser with 5+ years of thoroughly tested support. People don’t write abstractions to fix weak technology, they do it to fix weak developers.

Re: Why I Write CSS in JavaScript

#232

Post by exogen »

austincheney wrote: post #231
exogen wrote: post #145

Earlier quoted context omitted.

What about non-basic front end code?

Well I did spend this weekend trying figure out how to dynamically update keyframe rules with JavaScript only to discover the window.CSSKeyframesRule API is incomplete on most browsers so I found a different nonstandard way to solve that problem cross browser. I have not seen a failure to implement standards like that in many years. Just about everything else on the frontend is absolutely solid cross browser with 5+…

No.

Re: Why I Write CSS in JavaScript

#233

Post by exogen »

kazinator wrote: post #229
exogen wrote: post #142

Earlier quoted context omitted.

Does not classifying it as a programming language help this situation at all?

LocalPCGuy may just be responding to the grandparent comment which claims that it is : > 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…

I am the grandparent, and never mentioned anything about state. Not sure why state matters. Declarative CSS rules have effects. The scope of those effects can be both unlimited and unintended, and you can't "opt out" of being affected by rules – if some rule is targeting you, you're out of luck, unless you anticipate it and apply everything with the greatest specificity possible.

Re: Why I Write CSS in JavaScript

#234

Post by barryvan »

exogen wrote: post #130
ravenstine wrote: post #58

Earlier quoted context omitted.

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

Nobody thinks it's hard to delete a file. It's hard to know when you can delete a rule . Are you positive that all the rules in your component's CSS file only affect that component? Then great, delete the whole file. What about the individual rules within that file? How do you know whether your app is still rendering any components with the `fancy` modifier anymore? Keep in mind any JS on the page could be be dynamic…

This is where something like CSS Modules comes into its own. You can have (nearly) absolute confidence that what's in the CSS file colocated with the component is only used by that component. Sure, there are escape hatches like `:global(...)`, but those should be considered a code smell.

The beauty of CSS modules over a convention-based approach like BEM is that you end up with cleaner, simpler CSS files -- with selectors like `.Widget .search.error` rather than `.Widget__search--error`. The downside is that there's a compilation step, but chances are that you already have _some_ sort of compilation going on -- even if just to bundle things up.

The way to handle "special" cases for buttons -- like when they appear in certain contexts -- is to allow the calling code to add a class to the button; a class which comes from the caller's own CSS module. Alternatively, use CSS variables:

Button.css

  .Button {
    background: var(--btn-background, turquoise);
    color: var(--btn-foreground, octarine);
  }
Nav.css

  .Nav {
    --btn-background: fuchsia;
    --btn-foreground: lime;
  }

Re: Why I Write CSS in JavaScript

#236

Post by kazinator »

exogen wrote: post #233
kazinator wrote: post #229

Earlier quoted context omitted.

LocalPCGuy may just be responding to the grandparent comment which claims that it is : > 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…

I am the grandparent, and never mentioned anything about state. Not sure why state matters. Declarative CSS rules have effects. The scope of those effects can be both unlimited and unintended, and you can't "opt out" of being affected by rules – if some rule is targeting you, you're out of luck, unless you anticipate it and apply everything with the greatest specificity possible.

Pardon me; I was thrown off by wording like "overwrite or mutate".

Re: Why I Write CSS in JavaScript

#237

Post by dmitriid »

nek4life wrote: post #113
dmitriid wrote: post #91

Earlier quoted context omitted.

> What is so weird about it? I go a bit in depth here: https://news.ycombinator.com/item?id=17471199 > Vue has the option to use Webpack to compile html compliant templates to JS functions just like JSX Vue's templates are not HTML-compliant. They are just that: templates. That get compiled to JS anyway. > JSX (which BTW is not JavaScript and not HTML compliant and is also a separate concept that needs to be learned…

> I go a bit in depth here: https://news.ycombinator.com/item?id=17471199 I've read this before. Vue is a framework. It also has a templating system that is not JavaScript, it's valid HTML with attributes that tell Vue how to bind to it. It's really not that difficult. > Vue's templates are not HTML-compliant. They are just that: templates. That get compiled to JS anyway. Sorry, but you're wrong here. They are valid…

> it's valid HTML with attributes that tell Vue how to bind to it. It's really not that difficult.

You mean it has at least three JS-like DSLs (which are not JS, and have different rules depending on which context they are in). In addition it has a very weird binding system which I described at length in the linked comment.

Yup. "Not that difficult".

Meanwhile JSX is a single consistent DSL that directly maps to function calls:

   
      other tags, strings, or valid Javascript expressions
That's it. Even "html-like" attributes that people seem to not like... are exactly what HTML attributes are in actual Javascript DOM APIs [1] [2]

The amount of custom attributes, custom DSLs and gotchas just in the "HTML" part of Vue is staggering in comparison: https://pbs.twimg.com/media/DbVEoKOX0AEEen6?format=jpg&name=...

And funnily enough it ends up being compiled to what React is in the first place (here's the output of a Hello World app in Vue):

    var render = function() {
      var _vm = this
      var _h = _vm.$createElement
      var _c = _vm._self._c || _h
      return _c(
        "div",
        { attrs: { id: "app" } },
        [
          _c("img", {
            attrs: { alt: "Vue logo", src: require("./assets/logo.png") }
          }),
          _c("HelloWorld", { attrs: { msg: "Welcome to Your Vue.js App" } })
        ],
        1
      )
    }
Look, it's exactly what React without JSX is [3]. Only in React you don't need to invent a custom scripting language and binding rules.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Element/att...

[2] And I'm really sad to see React team seriously discuss caving in to mob and considering replacing className with class etc.

[3] https://reactjs.org/docs/react-without-jsx.html

Re: Why I Write CSS in JavaScript

#239

Post by 1_player »

abderrahmane wrote: post #82
Yabood wrote: 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…

Why can't we see more of these stories surfacing on the internet. All I see when I search for CSS-in-JS on google is how, CSS-in-JS is so great. Why don't we have more : "We tried it, it is the worst, especially for products which lifespan is more than two months"

At my company, I made the executive decision to drop CSS-in-JS because none of those libraries support PostCSS, and most have their own from-stratch, half-baked CSS transformation pipeline, not 10% as powerful as the PostCSS ecosystem.

I love PostCSS, and I'll happily consider CSS-in-JS again when somebody writes a library that doesn't try to reinvent the wheel.

Re: Why I Write CSS in JavaScript

#240

Post by nek4life »

dmitriid wrote: post #237
nek4life wrote: post #113

Earlier quoted context omitted.

> I go a bit in depth here: https://news.ycombinator.com/item?id=17471199 I've read this before. Vue is a framework. It also has a templating system that is not JavaScript, it's valid HTML with attributes that tell Vue how to bind to it. It's really not that difficult. > Vue's templates are not HTML-compliant. They are just that: templates. That get compiled to JS anyway. Sorry, but you're wrong here. They are valid…

> it's valid HTML with attributes that tell Vue how to bind to it. It's really not that difficult. You mean it has at least three JS-like DSLs (which are not JS, and have different rules depending on which context they are in). In addition it has a very weird binding system which I described at length in the linked comment. Yup. "Not that difficult". Meanwhile JSX is a single consistent DSL that directly maps to func…

> That's it. Even "html-like" attributes that people seem to not like... are exactly what HTML attributes are in actual Javascript DOM APIs [1] [2]

The attributes / DOM properties in JSX are also a mixed bag and not consistent. See https://github.com/facebook/react/issues/13525#issuecomment-...

> Look, it's exactly what React without JSX is [3]. Only in React you don't need to invent a custom scripting language and binding rules.

JSX is a custom extension to JavaScript. It's not part of JavaScript or intended to be part of the spec or implemented in browsers. In fact, you have to use some sort of transpiler in order to use it. So, it's not just JavaScript.

> https://pbs.twimg.com/media/DbVEoKOX0AEEen6?format=jpg&name=....

There's really nothing that complicated in here, if you're familiar with Vue. In fact, it's really easy for me to see what's going on at a glance in one place, which is my personal preference. From my own experience, that's rarely the case when working with React the way JSX tends to get broken up because it doesn't have something as simple as a standard if conditional statement within JSX itself.

I've never claimed you do not need to learn anything when working with Vue templates, you need to understand how the system works, but it took me all of a few hours to understand. The features and benefits that I prefer over React/JSX make that worth it to me.

Post reply on HN