CSS Is an Interface | Hacker News Reader

CSS Is an Interface

ericwbailey.design

31 pointsedent18 comments

Proper CSS is starting to become a lost art at this point due to CSS-In-JS, the literal coronation of inline-styles. The ship has sailed on this, and the days of writing a few simple classes, and adding a top level parent class like <div class=“dark”> and having all child selectors pick up on that is long gone. Now you’ll import a <DarkButton>, or whatever the fuck way they pass in that theme variable. It’s a massive whatever-the-fuck and fuck-it solution across the board with css-in-js at this point.

But, it makes sense when you realize why the solution is a fuck-it solution. People are not great at CSS, got tired of it, and said fuck-it. And voila, now we have a fuck-it solution.

CSS-in-JS doesn't render inline styles (usually), and many convert these JS declarations to plain CSS files to deliver to the browser. Writing CSS inside JS is convenient for many reasons but I'm unsure if you want to hear why.

Into actual css files or just <style> tags? It’s kind of the same idea, you scope down to such a granular level that the style literally applies to that one element. It bypasses CSS and forces style composition to occur at a programmatic level (Component-first thinking).

It’s one thing to utilize the convenience of css-in-js as needed, but we have, as usual, gone to the extreme and just wholesale ditched css lol.

It depends, some solutions generate atomic css, some normal css rules, and a couple generate inline styles.

CSS-in-JS is similar to React abstracting away HTML, as well as solving global issues etc.

React Native Web abstracts both the view and style layer, you work with a RN stylesheet based interface that generates atomic css on web and RN stylesheets on native. Similar to how React generates HTML on web and native controls on other platforms.

Personally CSS is too bloated, I love working with a subset that includes flexbox and the core styling properties.

> Into actual css files or just <style> tags?

Either, it depends on the library. It's becoming more popular to extract into regular css files as opposed to style tags. This is usually referred to as 'zero runtime css-in-js' as it doesn't depend on any JS for styles to load but you still get the composability and benefits of writing it in js.

> you scope down to such a granular level that the style literally applies to that one element.

It applies to that component (and any instance of that component), css-in-js also supports all standard css composition so it's very easy to do something like target all spans tags inside FancyButtons, you don't only have to target components.

At the end of the day it's a superset of css, all normal css is valid so no css has been ditched. This has come about because css requires you to manually keep styles and components in sync and css-in-js couples them together in a way that removes that management while also making it impossible to accidentally cause conflicts e.g. multiple components defining their own Container will never touch each others css unless you explitly import that definition and use it.

I have nothing against regular css and I'm a big fan of SCSS and CSS modules but css-in-js has a lot of advantages.

This seems overly pessimistic. I work on a React codebase that uses only plain CSS files (no CSS-in-JS), and have never encountered any problems with that.

Sure, there are certainly people who exclusively used CSS in JS, but I would hardly say that they are even a majority of frontend devs.

This is laughable. Theming is done thru CSS variables in any legit shop, not inheriting some dumb set of rules that will never work generically without specific rules.

CSS-in-JS is also able to compile to non-inline styles in some situations if I’m not mistaken, but I do agree this is something of an anti pattern

For the majority of my React projects I just import a single index.scss file in index.ts, and it has all the imports for my /style folder. It's not much different to the old school approach and is pretty pragmatic IMO.

For my last project I went with CSS in JS. It has some shortcomings and I don't think it would work very well if I use a lot of components from NPM, but it was really nice at encapsulating the component to a single file.

I don't think either approach is more or less proper. Inline styles had obvious large shortcomings in 2010, but not so much in the current context of front-end development.

Wow. I mean I’ve seen some outlandish takes about CSS-in-JS but this is pretty surprising to me.

Most, not all but most, CSS-in-JS is written as plain CSS or a Sass-like superset, in a tagged template literal. Where it’s not that, it’s typically written as the equivalent but with camelCase in a POJO. Effectively the same thing with minor syntax differences. In a few other cases it’s written in literal style tags.

In nearly all cases, the styles are not inlined at all. They produce one or more classes which can be applied to an element.

None of that is a fuck-it solution. You might not agree with the benefits, but to people who prefer it those are:

- Colocation of styles and usage, which aids understanding how or whether styles are applied (and could help correct cases like the example early in this article)

- Composition with clear semantics

- Language and tooling integration of various levels beyond referencing arbitrary CSS

- Build-time optimizations that allow extraction or inlining or code splitting, as appropriate for the project

I have no ill will toward Tailwind or any other “atomic CSS” solution, but I suspect more of your points apply to that particular approach than anything to do with CSS-in-JS. (Except Fela, which I quite like for some use cases, but by default has output similar to the complaints raised by the article.)

I still hand-write my CSS with no preprocessor. This isn't always sensible and I wouldn't do it at work, but it forces me to keep my classes neat and tidy.

I often fiddle with CSS of sites that I visit to make them work better for me. Sometimes I save the custom styles if I'm likely to visit the site again (I use Stylebot).

Usually just blogs and stuff, though, trying to mess with a React or Angular app is usually futile.

E.g. this snippet mostly fixes my system's abysmal default typography on sites like https://danluu.com :

  p {
    font-family: Charter;
    font-size: 16pt;
    line-height: 1.4;
    max-width: 36em;
    margin: 2em auto;
  }

The real problem in the screenshot is that none of the options are the correct answer. It should be たべ, but the buttons say フル, ユウベ and ユキ.

came here for this, thank you

Well no, ゆうべ (ユウベ) is right, see for instance https://dictionary.goo.ne.jp/word/%E5%A4%95%E3%81%B9/

It's the 夕 kanji, which reads as either "せき" or "ゆう", it's not the タ katakana.

Oh darn, you're right! They look so similar.

It's not wrong, it's 夕べ with the 夕 kanji instead of the た katakana letter

I often use uBlock rules to remove distracting elements. This includes removing the entire feed sometimes. For that you need reasonable CSS classes.

The text on this site is huge because it is set in the body to “150%”. This seems like an odd choice. Is there any good reason to do this?

Reply on news.ycombinator.com