search

csswizardry / ama

Ask me anything!
57 stars 4 forks source link

CSS architecture & web components best practices #22

Closed koffetar closed 7 years ago

koffetar commented 7 years ago

What are your thoughts on the future of CSS in terms of architecture and the way we write it, considering the fact that we are now working with components. I am currently working on React project and I came across heated discussions about ‘CSS in React’ best practices. One side of the isle is defending traditional approach while the other side is advocating that CSS should be written in JS (as JS).

I guess everyone is trying to solve their problem and overall I think is very good to have this discussions. Do you have any experiences with components and good practices in general? Is traditional (IT)CSS architecture sufficient for large scale projects with many different vendors contributing to CSS codebase? I am really interested to hear this from you.

In the mean time, I am reading this article: https://medium.com/maintainable-react-apps/journey-to-enjoyable-maintainable-styling-with-react-itcss-and-css-in-js-632cfa9c70d6#.k4vff7nd7

Cheers!

csswizardry commented 7 years ago

Okay, huge question, but lemme try give a concise answer:

I’m not a fan of CSS in JS for a number of reasons, but the shortest way of explaining it is that CSS already works as long as people just attempt to do it properly. People less well versed in CSS start cramming it into other languages because that fits their view of things, as opposed to investing the time in learning how to do things correctly.

CSS is far from perfect, sure, but to start writing it in a whole new way is—to my mind at least—throwing the baby out with the bathwater.

That said, I am a huge fan of encapsulation, and Web Components proper will be amazing. Collocation of code, but with everything written in its proper, purpose-built language is a great sounding future as far as I’m concerned.

Do you have any experiences with components and good practices in general?

I worked with a huge (I mean, huge) company who were using ITCSS/inuitcss inside of Polymer in order to serve 40,000 software engineers who would need to begin implementing their own UIs. The paradigm sat very well, with a layer of global CSS written very ITCSSy, then components inside of Polymer took over from there.

One of the temptations with Web Components/Shadow DOM is that we can start writing more traditional looking CSS, like so:

.widget {}

.widget h1 {}

.widget ul {}

…which theoretically works thanks to our newfound encapsulation, but can still leave us open to subtree collisions further down the line, but it also means that that CSS will only ever work if we are in a Shadow DOM context.

This means that you can’t quickly reuse those styles on any other projects that might have a different view layer, which could pose a problem. Ideally your CSS wouldn’t be that dependent on your choice of view library. Even if I was using Shadow DOM, I’d still write my CSS as good CSS:

.c-widget {}

  .c-widget__title {}

  .c-widget__nav {}

I can still repurpose this CSS pretty confidently anywhere I like, encapsulation or not.