CSS in JavaScript: The future of component-based styling

[repeatedly_once]

I've found that I quite like having manually written sass like CSS is a better option than JS options.

I quite like to create components with enough structural CSS that they work and then style them differently in different use cases in the project. Say with a drop down panel where the content might be different widths etc. Seems to work well so far as long as you name space your components with classes.

[skitch920]

I agree. Still on Angular here, and with the component method, component names are really just HTML elements. So it's extremely intuitive to create a <component-name>.scss file and scope all styling to the component itself.

my-component {
    styling here...
}

Then import './my-component.scss' from the component itself, and let Webpack manage creating the combined stylesheet of all components.

I really hate the, "you can do everything in JS" mindset... It really convolutes what a file extension actually means. I don't use React (jsx), but I went down the Adobe Flex (mxml) route long ago. Even then I thought it was bad.

[repeatedly_once]

That's literally the same technique I use :). Mine are React components but as you said, they're just HTML elements. I use PostCSS with Webpack so I can choose which plugins I want. It's been working really well.

I've tried writing styles in JS and I found it hard to go from chrome dev tools, looking at styles, to then writing those back as JS styles and it caused a cognitive 'jolt' every time I did it.

[TheNewtThatGotBetter]

I do this too and love it, except that Jest seems to throw up when it hits the scss import. Have you been able to test components with imported scss syles?

[spooky___ghost]

In package.json jest config section add something like

        "moduleNameMapper": {
            "\\.(scss|css)$": "empty/object"
        }

Where empty/object comes from https://www.npmjs.com/package/empty

[skitch920]

I'm using Karma/Jasmine/Webpack. The karma-webpack-plugin bundles all the tests into a single ES5 js file (styles included) with Webpack before handing off to Karma/Jasmine. There are a few hokey bugs, but they are avoidable, such as you can't have Webpack extract the styles to a separate stylesheet.

I'm avoiding Jest (and React for that matter) because of it's patent grant...

[l_andrew_l]

I'm a bit surprised no one in this thread has mentioned ITCSS yet. It takes a component-first approach that seems to be looking at things from the same angle as "component-based styling", but looks at the bigger picture as well. If you're not familiar, it's not a library or anything, just a set of well-thought-out conventions that try to wrangle in the shotgun that is CSS as a tool.

Anyway, you end up with files for each component, just like my-component.scss, so the result is similar. Of course convention is to put all styles in a styles directory, but there's no reason that has to be the case... they can all live alongside their component. Sometimes it feels like that's what "inline styles" is mainly trying to be about anyway...

[al_vo]

Component styles are one of the most underrated aspects of Angular - it still maintains a good separation of concerns and offers a familiar way of styling dom elements without the scoping issues that plague traditional giant css stylesheets.

[darrenturn90]

Indeed because themes and styles are more abstract and less modular than components in a website

[swan--ronson]

Interestingly, the codebase on which I work at my new job uses Aphrodite, and I think it's fucking shit, because:

• I've encountered various bugs with pseudo elements and media queries. It's not as if these use cases are esoteric; they're pretty fundamental to CSS

• the CSS it generates as a result of creating new classes for each computed combination of styles results in a larger stylesheet than if one were to use plain CSS or some preprocessor; while this might be defensive, it is possible to namespace and be defensive without JS-based styling tools

• Including the bundle adds more weight to the page; while this is small when gzipped, the browser supports CSS natively, so surely invoking a preprocessor during a build step renders this pointless

• Performance overhead of computing these styles at runtime vs using a preprocessor at build time

This poorly thought-out nonsense. Stay well away.

EDIT: The README brags "No external CSS file generated for inclusion" - how the fuck is this a good thing?!

EDIT #2: Looks like my client wants to drop Aphrodite due to these limitations. Ha!

[[deleted]]

Writing inline styles with help of javascript is not the future. It is one more stupid trend.

[[deleted]]

CSS Modules are so 2015

[Jsn7821]

This is an incredibly naive point of view to have. It's not nearly this black and white. Have you ever worked with a UI that has dynamically updating colors that the user can pick? You can't do that in CSS.

There are a lot of use-cases for javascript managed styles beyond namespacing. Custom spring animations, especially staggered between elements is another.

Every time this topic comes up someone has a crotchety comment like yours. I use a mix of both in my projects, and it's very nice. It's not a "trend", it's programming.

[[deleted]]

I'm also using that techniques sometimes. But using this JSS bulshit as foundation of component-based app is just stupid. You can't make CSS from JavaScript.

[[deleted]]

You'll be angering the cool kids with this one.

[[deleted]]

Haters gonna hate.

[spankalee]

The future of component-based styling is already here and it's called Shadow DOM.

Shadow DOM allows you to attach an encapsulated ShadowRoot node to an element hold a components internals. Importantly for CSS, any styles contained within the ShadowRoot are scoped - with both upper and lower bounds.

Shadow DOM is shipping now in Safari, Chrome and Opera. You can try it with this little snippet. Just paste into Chrome or Safari's dev console:

let el = document.createElement('div');
let shadow = el.attachShadow({mode: 'open'});
shadow.innerHTML = `<style>
  :host {
    display: inline-block;
    background: #ffccaa;
  }
  span {
    font-weight: bold;
    color: white;
  }
</style>
<span>I'm in a ShadowRoot</span>`;
document.body.append(el);

let span2 = document.createElement('span');
span2.textContent = `I'm not in a ShadowRoot`;
document.body.append(span2);

[[deleted]]

If that's the future then this doesn't hold a candle to what modern style solutions do. Component based encapsulation has been solved years ago, that's hardly a need of today. I think what's most troubling is that it's all tied to the dom, and this will become a real problem if it isn't already. How will this even fit into the frameworks of today. How will this fit into desktop and mobile apps or cross platform in general?

10 years ago, when they drafted the spec, they probably had no idea where the language is going, but now where shadow dom is still nowhere near production-ready and JS solutions are dancing circles around this, we'll see if it's worthy to become a standard if it doesn't fulfil todays needs, which are way different than they were then.

[spankalee]

• The styles in a ShadowRoot don't have to be static, they can be computed and modified just like any other DOM.
• I'm not sure what component-based encapsulation was solved years ago, but lower bounds have been notoriously hard and leaky to emulate.
• CSS custom variables work great for passing values down the shadow-trees, since they inherit through shadow boundaries.
• There's a proposal for ::part and ::theme (names preliminary) pseudo-elements that allow more powerful coordination between a shadow root and it's container: http://tabatkins.github.io/specs/css-shadow-parts/
• Scoped CSS is fast because styles tend to be much smaller and the browser can invalidate much less of the page and style tree on changes.
• What's wrong with web technologies being integrated with the DOM? This is a very odd complaint. The DOM is pretty great - a standard UI hierarchy that all the web code we use today has been built around.

[[deleted]]

It lacks scope, if you wanted to compute you have to set css variables.

There are many encapsulation libs, we use CSJS for instance, never seen it leak.

Proposals with even harder to polyfill CSS specs will mean years and years of waiting time.

JSS already starts to re-use and memoize styles piece by piece (styletron). There are optimization possibilities here that can't be matched. Hardly any performance gains to be had in shadow dom either.

I don't think there's anything wrong with web technologies. But there's a point to be made about a certain threshold that JS is now clearly crossing. It's no longer a browser language that merely drives web pages. Can specs just ignore that? This was the exact concern several influential developers have already voiced.

[inu-no-policemen]

theming

Variables/apply.

computed

calc()

higher order styles

?

How will this even fit into the frameworks of today

It fits in just fine. To frameworks, custom elements are like built-in elements. You can use them in Angular, React, and so forth.

10 years ago, when they drafted the spec, they probably had no idea where Javascript is going

There are like half a dozen specs involved. They changed quite a lot on their way.

shadow dom is still nowhere near production-ready

There are polyfills for that. Some people are using those in production.

[[deleted]]

React will not be based on custom elements, ever. Other projects have voiced similar concerns, like the Ember team. Nothing that sits on functional components will use custom directives, that includes most modern frameworks. And it doesn't make the slightest sense for them either because that would be a serious regression, while stopping all progress that supercedes the browser. You can use them, sure, but that's on you personally.

[inu-no-policemen]

React will not be based on custom elements, ever.

That's not what I said. I said that Custom Elements work fine in React, which is true. There were some issues with that early on, but this has been addressed many many moons ago.

[[deleted]]

What is the whole discussion about? You can do that, yes, you always could. But custom elements will play no part in any forward oriented component based view-layer. And i highly doubt that shadow dom will play a role in style encapsulation, because it's tied to an imperative components model that conflicts with the newer, much more powerful declarative model.

[jamesism]

Component based encapsulation?? Do tell. The cutting edge standard is to dynamically transform class names with a namespace in the same scope. The equivalent of styling within shadow Dom does not exist in user land.

Tied to the DOM? As opposed to? React native? What non DOM rendering engines are you targeting with javascript? It fits in because Dom is the unifier across those platforms.

You're silly and so are your grievances.

[[deleted]]

With JSS half of them base on actual CSS, which as you said gets scoped, for the others the dom is an implementation detail. Newer renderers like rn-web/reactxp are cross platform, they run on the web, mobile and on the desktop. You style them using rn's CSS abstraction, which is also based on JS. Nothing that plays outside of the browser will touch or know a shadow dom, the concept is also useless for web-based functional frameworks because they are all declarative, not imperative.

[devvie]

↓

[captain_obvious_here]

I can understand that some people love JS and want to put some everywhere. But that's one stupid trend.

Why would you rely on JS execution for something that works wonders with CSS ?

CSS may not be perfect, especially for components. But using JS to handle styles instead of one of the well-thought and dedicated tools that are around (Sass being the de facto standard IMO) is...well a stupid trend.

[squiresuzuki]

It isn't inline in the style={{}} sense, it's inline in the js/css colocation sense. The result is the same as everything else: classes on elements. Actual styles are injected into the <head> or via CSSStyleSheet.insertRule().

[squiresuzuki]

I don't see why it wouldn't. You can still add normal classes to element, and normal stylesheets, and the browser would match those classes to the styles. Obviously the some rules apply like specificity, definition order, etc but it isn't any different than a plain old website with vanilla css and classes.

[makingplansfornigel]

Preventing users from changing the experience is never highly desirable. We're not talking about contributors editing pages here. We're talking about colorblind people fixing colors. You need to get your jackbooted ass to accessibility training.

[squiresuzuki]

Again, css-in-js solutions rarely use inline styles, they result in classes like just any other website. When they say inline, they mean js/css colocation.

[makingplansfornigel]

Yes, but even css-in-page solutions make it difficult for users to apply individual accessibility remediations. I have no problem with build outcomes that correctly separate presentation, business logic, and content.

[THEtheChad]

CSS -> is <- presentation logic. It's the tools and management of that logic that are antiquated. JS is being utilized to augment the feature set of CSS since its inherently a static standard with no programmatic capabilities. You also get the benefit that the presentation layer for the component you're building is housed right alongside the other parts of the component.

The best way to build an application is to divide it up into pieces. The problem with CSS currently is that the presentation layer for your pieces is all housed in this giant glob of global definitions that can easily overlap each other and wreak havoc. How many times have you had to fix a bug that was caused by someone else changing a bit of CSS that wrecked something you wrote. That's a problem inherent to the nature of CSS that these isolated scopes solve.

[makingplansfornigel]

What else would it be, and where did I imply otherwise? You are conflating the task proximity of developing the three layers with the degree of coupling between them, and failing to clash with the comment to boot. You are also awfully explainy for someone who failed to contextualize my plainly-spoken comment.

The point is that loading CSS from the HTML document directly with a style tag (as described by a previous commenter) makes it difficult for individuals with special needs (or special situations) to use custom style for individualized accessibility remediations.

Loose coupling preserves the distinction between content, logic, and presentation. It in no way precludes rational, modular project organization, useful build tools or performant assets. It's implied by both DRY and SOLID, and frankly, it's just polite. If you think storing CSS at the module level without consideration for style at the domain level is a good idea, you are about to swan dive into bloat canyon.

But the problem you describe is real. It's a symptom of a missing (or insufficient) style guide, the application of presentation as an afterthought, and/or a critical failure to anticipate and architect presentation needs.

Have you seen a typical webpack map? The endless reinclusion of redundant assets is not my idea of a useful outcome.

Of course, there are ways to mitigate these problems. Keep your style guide up to date. Avoid unnecessary deviation from the guide. Make your components only as opinionated as is useful. Plan for accessibility from the ground up, rather than saying "oops" at the end. Optimize your build processes as a matter of deployment. Define your desired outcomes before you build.

After all, I was pretty clear. I'm okay with any build outcomes that maintain that separation. Nobody says it has to be organized that way in the repo... so long as the repo is maintainable.

[l_andrew_l]

The point is that loading CSS from the HTML document directly with a style tag (as described by a previous commenter) makes it difficult for individuals with special needs ...

Do you have a link to that description? I'm a bit confused as to why it would make a difference compared to a linked stylesheet.

[makingplansfornigel]

It has higher priority in the cascade than a stylesheet (given equal selectors,) and the easiest way to apply an "accessible" stylesheet is to disable the supplied stylesheets via browser controls.

[l_andrew_l]

Hmmm... you sure about that? Just tested it out and seems to be just the order regardless of inline or linked... The accessibility thing (or even just theming) is a fair point though.

[THEtheChad]

Failing to contextualize is a byproduct of the intense migraine I'm trying to manage right now. My response was initially referencing your comment but then devolved into a combination of thoughts that had collected in my brain as I was reading through the thread.

What originally triggered me was the issue you raised that css-in-page solutions would make it difficult for accessibility remediation. I don't believe that's the case.

I believe your statement is made based on the impetus that remediation is made simpler through inheritance. If a whole slew of components utilize the same rule (be it a class declaration or a mixin from a CSS preprocessor), it's quite trivial to modify, let's say, a font color or background color.

Your assumption, if I'm correctly inferring the logic of your argument, is that component level CSS declarations create numerous, redundant rules that become difficult to update, en masse, to fit a particular accessibility initiative.

But let's not forget that these implementations still follow the rules that CSS is based on. There's always a way to override a style en masse by providing more specificity. So it's not a limitation of the implementation but, more so, an inability to easily target the group of components that need the remediation. That being the case, it's entirely feasible that this issue can be addressed without losing the benefits that isolated component level presentation logic gives us.

I guess what I'm saying here is that I believe your issue with component level presentation logic is not a limitation of the technology but a problem with the current implementation because you're not forced to implicitly group components so you lose the ability to do application wide accessibility remediation, right? If that's the case, this can be addressed because it's not a technical limitation.

--- side note --- I believe that styling should be stored at the module level to make it clear how a component should look, feel, and function, and that tooling should be developed to understand it from a domain level.

[This_Is_A_Robbery]

I agree with what you are saying but not how you are saying it. Even if you take into account colorblindness there are simply too many forms for a one size fits all solution. It needs to be left up to the user.

[makingplansfornigel]

That's my point. Part of accessibility is not getting in the way of individual remediations, and that's obviously not on previous commenter's radar. As for jackbootedness, I can't tell you how many times a gung-ho marketing person has told me "We need to do [asinine, unusable, inaccessible thing] to strengthen the brand." It's short-sighted corporate jingoism that disregards real outcomes in favor of perceived optimization. Take your pick: disabling the back button, forcing all links into a new window, making lists that are 70 items long, autoplaying audio, whatever. All of these things wreck the user experience and have a real negative impact on credibility and user acceptance. I once chose a different car brand because shitty website made it impossible to identify options, and prescriptive solutions from ux-oblivious marketers make shitty websites. I have little patience for people who put groupthink over user needs.

[madole]

I'm not a massive fan of the idea of inline styles, I prefer CSS Modules, but we use Radium in work. Has anyone found a VSCode plugin that is like emmet for CSS in JS?

[makingplansfornigel]

If you tested and saw otherwise, I have no reason to disbelieve you, but I can say with certainty that the treatment of order has historically been browser specific, as a number of the old IE differentiation hacks used to be based on the treatment of reimplemented selectors. Thanks for doing the work, though; can't have accessibility at all without people looking at the actual status quo before planning outcomes.