Which CSS-in-JS library?

[verekia]

Let's discuss which CSS-in-JS library should be in the tutorial :)

[amilajack]

styled-components

[skynode]

Just checked out style-components, great work over there! Good candidate too.

[gaitat]

google material design

[gfortaine]

styletron

[verekia]

Styletron looks amazing. It seems to be the best of the 3 worlds between JSS / Aphrodite, Styled Components, and Atomic CSS. I'm really impressed!

[verekia]

My problem with Styled Components is the style string. Using a plain string instead of a structured language like JS – or even CSS for that matter – is a big weakness in my opinion.

[kof]

JSS is going to allow template strings syntax soon using a separate package for those who needs dashes and autocompletes/highlighting, but using a babel-plugin instead of doing it on the client.

[Sharlaan]

JSS

[gfortaine]

Hello,

To enrich the current thinking, I would greatly appreciate to invite you to a further reading of the following post : CSS in React The Good, the Bad, and the Ugly

@verekia styled-components v2 with SSR + babel-plugin seems highly promising also praised

[rbrtsmith]

Might be worth reading Harry Roberts response to a question about CSS in JS here csswizardry/ama#24.

I'm in agreement with him here that these don't solve anything that isn't already attained by a sound CSS/Sass architecture. But they are cool and damn handy for developers who are less comfortable scaling large CSS codebases. I just don't think there's anything out there that gives a significant improvement over regular Sass/PostCSS and a developer who knows it well... Yet!

[verekia]

If your entire CSS codebase is maintained by one or a few top front-end engineers like Harry Roberts is, and no one else writes CSS in your company, and there is no legacy code that is getting in the way and causing collisions with new code, then yes – a naming convention approach works okay. But let's be clear: naming conventions are a crutch. They are the best way we've come up with to not fuck up with pure CSS, a language that is extremely prone to making mistakes. This is in no way a great solution. It's just an okay compromise we had to make.

Just like Harry, I have been advocating naming conventions for years in my companies and at conferences, so I definitely know where that argument is coming from. But we now do have options that make CSS less prone to mistakes, and that allow less-expert developers to write CSS without making a mess. CSS-in-JS is a great example of "tools, not rules". Tools can enforce quality, rules not so much. I don't think CSS linters are good enough to make sure there is no collision whatsoever in a CSS codebase, and even if they were, I still think CSS-in-JS is a cleaner way to do it. It is not a "hack", it's the solution we've been badly needing for a decade.

[rbrtsmith]

I really don't think it requires a top front-end engineer. While CSS is not easy to master I personally found it far easier to get good at than JavaScript, I really don't think it's too much to ask that a front-end developer knows CSS well, especially if they are in a lead position - this should be mandatory; they can guide the less senior developers and review PRs to ensure that things remain clean and devs can gain valuable feedback.

I would agree that these offer a solution to teams that have little CSS experience, though ideally a strong dev team would have a broad range of specialist skills, CSS being one of them - Accessibility another that is often missing from a teams skillset and thus overlooked.

I do agree that CSS is prone to error and requires diligent and disciplined developers to structure well; however, I'm with Harry on this and I'm not convinced by any CSS in JS solution yet. That could change in the future, I'm just not sold yet.

[kof]

I think there is a common misunderstanding. There are different things in CSS that cause different complexities.

1. Layouts and co. - one needs to understand different layout engines and all possible css props and values. I don't know all of them and probably nobody does.
2. Selectors and specificity.

JSS and others fixes the 2. part. It makes the mapping between css rules and dom nodes explicit. It can be done manually and its not a rocket science, but its a pain in the ass, because you need to rely on people following the conventions across one or multiple teams.

Wether it is a problem or not highly depends on the project size and the amount of time you are willing to invest into fixing class names in code reviews or collisions in production.

[gfortaine]

Maybe should we look at other alternatives than CSS in JS ? Especially, there could some interesting elements of answers in CSS Custom Properties, cf this enlightening post: CSS Custom Properties as your API

[verekia]

Also, the new Glamorous is similar to Styled Components without the CSS string (and therefore an equivalent / competitor of Styletron).

[gfortaine]

Lots of talk about different CSS solutions for React. This gist attempts to shed light on pros/cons of approaches.

[gfortaine]

Better CSS with JavaScript

[tyler-reitz]

@rbrtsmith “ideally a strong dev team would have a broad range of specialist skills, CSS being one of them - Accessibility another that is often missing from a teams skillset and thus overlooked.”

You're assuming an ideal world…

[verekia]

Hi everyone,
The V3 of the tutorial will use Material UI, which integrates JSS, so that's what I'll use :)
It will be out next month. Thanks for the discussion! #255