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

111–120 of 255 posts

Re: Why I Write CSS in JavaScript

#111

Post by Rapzid »

LocalPCGuy wrote: post #93
dmitriid wrote: post #71

Earlier quoted context omitted.

> 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?

Because one is an extension of the underlying technology, and the other one changes the technology out altogether. I still believe CSS is a vital part of the web ecosystem, and we should work to fix the underlying issues rather than just try to work around it via JS.

The underlying technology is the same, only the interface has been changed out(CSS files for JS).

Re: Why I Write CSS in JavaScript

#112

Post by latronic_notron »

dmitriid wrote: post #76
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.

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

Vue Templates are a very thin DSL on top of HTML. It's just markup.

Once you understand that, everything falls into place.

Re: Why I Write CSS in JavaScript

#113

Post by nek4life »

dmitriid wrote: post #91
nek4life wrote: post #90

Earlier quoted context omitted.

> and has a very wierd concept of how objects work in JS. What is so weird about it? I personally find Vue vastly more approachable than React is, especially once you have to start writing all the plumbing to get all the libraries you need to go along with it to write a real world app. > ] It's a templating system with its own rules and mini-DSLs that ends up being compiled into JS. Vue has the option to use Webpack…

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

https://vuejs.org/v2/guide/syntax.html

"Vue.js uses an HTML-based template syntax that allows you to declaratively bind the rendered DOM to the underlying Vue instance’s data. All Vue.js templates are valid HTML that can be parsed by spec-compliant browsers and HTML parsers."

> JSX is a very thin DSL on top of Javascript. It's just function calls: https://reactjs.org/docs/react-without-jsx.html

IMHO only the simplest of components featuring JSX that don't read like a spaghetti PHP coding nightmare to me. For the small number of times you actually need the full power of JavaScript you could also use JSX in Vue with a render function if necessary. I personally prefer to keep my templates and logic separate when possible.

> It's not a webpack add-on. It's a part of Vue's templating engine that is essentially CSS-in-JS, they just give you a template to work in.

No, it's not part of the template engine, it's part of vue-loader which is used by Webpack to create single file components.

https://github.com/vuejs/vue-loader

Re: Why I Write CSS in JavaScript

#114

Post by iaml »

vehemenz wrote: post #17

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

What's the problem, you just use them. If you need to reference component itself you can use & selector, works exactly like sass or less. If you want to reference another styled component you import it and ${Component} will reference autogenerated class. Also nobody stops you from writing nested css rules. You can also write cool media query helpers like this https://www.styled-components.com/docs/advanced#media-templa...

Re: Why I Write CSS in JavaScript

#115

Post by LeonM »

Be very aware that most popular CSS-in-JS libraries (such as JSS) will completely break CSP (Content Security Policy). The default reaction is usually "Just allow unsafe-inline in your CSP header", but this is dangerous advise as it will disable CSP! I've even seen 'experts' advising to use webpack to set a static value as a CSP nonce during build-time...

If you want to use CSS-in-JS, you'll either have to use server-side rendering to inject CSP nonces in your index.htm [0], or set up a complex build system to extract the CSS from your JS so you can serve them as .css files.

Using server-side rendering to inject nonces into your single-page client side rendered webpage is such an ugly hack. I'd prefer the second solution but I have not been able to find a solution like that, nor do I have the time to dive into the webpack rabbit-hole to do so.

[0] https://github.com/cssinjs/jss/blob/master/docs/csp.md

Re: Why I Write CSS in JavaScript

#116

Post by alangpierce »

antoineMoPa wrote: post #25

The down-side with this is very high coupling between UI logic and style. If style becomes out of fashion, you have to modify files that contain logic. If framework (react/vue) becomes out of fashion, keeping styles will be difficult. The other down-side is thousands of web developers having to re-learn CSS and the tooling behind your app instead of just changing CSS files.

You don't need to use different languages to decouple things. A common pattern in React is to decouple logic and style using presentational components and container components (there are lots of articles on it if you Google those two terms), and I find that split to be much more natural than trying to split up HTML, JS, and CSS (which often need to cooperate with each other). One good practice with CSS-in-JS is to only use CSS in presentational components.

Re: Why I Write CSS in JavaScript

#117

Post by antihero »

Why is it that whenever anyone posts anything about React, there's a horde of Vue users trying to convince us that they are doing it better? It feels a bit desperate.

The great thing about React is it is purely JS (or JSX, which is effectively a macro for the underlying JS). Which means it is explicit, and predictable. Perhaps that means there's less sugar, but any sugar and magic comes at a price.

I'm going to have a look at Vue more anyway, out of curiosity, though.

Edit: I note that some of the anger at React has been "Why does it need Redux/MobX if it is so good?". But Vue has Vuex to solve the same problem?

Re: Why I Write CSS in JavaScript

#118

Post by bastawhiz »

GordonS wrote: post #107
bastawhiz wrote: post #27

Earlier quoted context omitted.

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.

You can define a "theme" object, which you can inject into your styles (with an expression inside the template literal). Other libraries support variables more directly.

Re: Why I Write CSS in JavaScript

#119

Post by zeroname »

lousken wrote: post #89
zeroname wrote: post #50

Earlier quoted context omitted.

This is a requirement that most sites can simply dismiss these days. The distinction between an app and a website is blurry, a lot of interaction simply works far better with Javascript. Supporting "no Javascript" can be costly. It's possible with server-side React and careful engineering, but why bother? What's the impact on the business?

I don't know what the real impact is, but if your site shows me blank page without javascript(I have it off by default) I am closing the tab. I don't think supporting noscript version is costly because for me that's how it supposed to be by default. 90% sites that are currently on the internet would work just fine without any js and 95% would work with as little as hackernews has. Modern CSS allows to create most of…

> I don't know what the real impact is, but if your site shows me blank page without javascript(I have it off by default) I am closing the tab.

I can show you "this site requires Javascript" instead, but let's just say you're not part of the target audience and that's fine.

> I don't think supporting noscript version is costly because for me that's how it supposed to be by default.

That highly depends on the site, of course.

> 90% sites that are currently on the internet would work just fine without any js and 95% would work with as little as hackernews has.

99.9% of websites are not actually businesses that employ developers. If that's your standard, I agree. A simple webpage does not require Javascript.

Re: Why I Write CSS in JavaScript

#120

Post by jancsika »

jmull wrote: 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 potential problem I could see is that changes which would have been easy with a cascade would require lots of changes to copypasta in this approach. Like, "take the spinach out of this ravioli and replace it with mushrooms." Everything is scoped properly and the task is obvious at a glance-- it's just annoying.

Post reply on HN