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

71–80 of 255 posts

Re: Why I Write CSS in JavaScript

#71

Post by dmitriid »

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

> using something like SCSS > adopt a simple naming structure

and suddenly

> I still don't see CSS-in-JS as more of a bandaid for people that like CSS

Why are SCSS or poor-man's-substitute-for-modularity in the form of naming conventions fine, and why JS-in-CSS is bad?

Re: Why I Write CSS in JavaScript

#72

Post by haukur »

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

What you linked is "CSS-in-JS" (in the sense that the library/framework you use transforms the output for you, for convenience, i.e., you're not writing BEM or whatever - same as in the original article). Vue scopes the styles by adding a data attribute.

https://vue-loader.vuejs.org/guide/scoped-css.html#scoped-cs...

Inspect the result here: https://codesandbox.io/s/3v0pjzoy7q

Re: Why I Write CSS in JavaScript

#73

Post by iSnow »

mxstbr wrote: post #2

Author here, happy to respond to any questions. AMA!

Honestly, it sounds like you now have a write-only site, as you will have a hell of a time 5 years down the road when the CI changes.

Personally, I find the Vue.js concept much nicer, but even given that, I define my styling in LESS (SASS...) to benefit from inheritance/mixins on the level of styling. Semantic approaches like BEM or Bulma make a lot more sense to me.

It seems to me React has made a feature out of a flaw, much like the intermingling of code and HTML back in the days with ASP/JSP/PHP.

Re: Why I Write CSS in JavaScript

#74

Post by LaserToy »

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 use cascading part, nobody was brave enough to own styles for the whole product. So, We ended up with so many styles we had to split them in couple files as we reached a limit in IE on number of styles in one file. Last time I checked GA is loading 3 of them... Is it a time for some other way of doing it?

Re: Why I Write CSS in JavaScript

#75

Post by cynicalreason »

dictum wrote: post #38
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.

You're right, but community support around a certain pattern often makes it the de-facto practice, so defaults matter even for a non-opinionated library (where "defaults" are essentially what tutorials and thought leaders point to)

I always thought css-modules is the de-facto practice

Re: Why I Write CSS in JavaScript

#76

Post by dmitriid »

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

> a language flaw in the React concept.

What language are you talking about? React is Javascript

> Look at this beauty for comparison

Meanwhile Vue is neither HTML [1], nor strictly speaking CSS [1], and has a very wierd concept of how objects work in JS.

[1] It's a templating system with its own rules and mini-DSLs that ends up being compiled into JS.

Re: Why I Write CSS in JavaScript

#77

Post by loz220 »

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…

Poorly designed code is possible with any language. Was it unmaintainable because of something fundamental to css in js?

Re: Why I Write CSS in JavaScript

#78

Post by preommr »

akuji1993 wrote: post #22
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

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.

Re: Why I Write CSS in JavaScript

#79

Post by jmull »

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 of it. For for the general developer, perhaps a roughly equal effort would provide a similar level of mastery in each. So why not invest in the standard?

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

"Enhanced Teamwork" - I don't see the connection here. The discussion in this section seems to be about mastery of the tools again. The team can learn how to manage styles though CSS-based techniques or they can learn through techniques based on coding Javascript and the capabilities of this library.

Not that CSS doesn't have its issues. IMO, it's too low-level to use directly for many cases. There are two main problems: (1) missing the tools to manage complexity, like scoping, variables, and modules. (2) allows you a lot of freedom to do bad things. But there are libraries that address these that don't throw out the fundamental design of CSS, as styles-in-code does.

To me it seems like a better approach to build on CSS to address its weaknesses rather than throw it out.

The design of CSS itself came out the recognition that the tight coupling of style and content has drawbacks, and this is signing back up for those drawbacks. And you better neatly divide your presentation code from your business logic code and data access code or you'll get all that coupled tightly as well.

I'm not dismissing this out-of-hand -- I haven't dug into styles-in-code approach so I don't have a deep understanding of it.

But I'm not convinced it's worth the time to look more closely at it. Really, not even close.

Post reply on HN