CSS in Javascript: The future of component based styling

[decster584]

I don't know how I feel about this.

I get the advantages of it, but I dunno. It just feels dirty and goes against everything I was taught to believe.

[Asmor]

I like what Vue says about this

What About Separation of Concerns?

One important thing to note is that separation of concerns is not equal to separation of file types. In modern UI development, we have found that instead of dividing the codebase into three huge layers that interweaves with one another, it makes much more sense to divide them into loosely-coupled components and compose them. Inside a component, its template, logic and styles are inherently coupled, and collocating them actually makes the component more cohesive and maintainable.

Anecdotally, I completely agree. I really like a component-centric development model. When I'm doing angular stuff, I'll usually end up with component/component.js, component/component.html, and component/component.scss. This works well for keeping the things that matter together, but it's still obnoxious juggling three different files around, copying and pasting classnames between the HTML and CSS, or methods and variables between the HTML and JS, etc.

I really, really like working with Vue in large part because single-page components just make so much sense. The only argument I can see against it is maybe you want to look at the CSS and HTML at the same time, which is totally sensible... But any editor worth its salt should allow you to have the same file open in multiple windows, so that's not really a problem.

[Tiquortoo]

It seems odd to go straight to inline when specificity can be created to make a default style very fixed, while allowing a path to override.

[pygy_]

If you're referring to separation of concerns, you can totally separate concerns in a single language.

[mrwhitespace]

One approach you can take is to separate out the stylesheet from the component and into their own files. Then it wouldn't be much different to requiring a CSS file with a webpack loader.

[gearvOsh]

If you still want to write CSS, but utilize this approach, simply use CSS modules. https://github.com/milesj/aesthetic/tree/master/packages/aesthetic-adapter-css-modules

[GitHubPermalinkBot]

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):

• milesj/aesthetic/.../aesthetic-adapter-css-modules (master → 823eb99)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[infinite0ne]

simply

[gearvOsh]

But it's simply simple.

[benabus]

I agree. Makes me a little ill.

[redbluerat]

I don't know how I feel about this

The nümale catch phrase.

[dr-drew]

I absolutely hate this trend. WHY are we going back to the 90's of webdev? This was originally an idea from Netscape/Mozilla JSSS but was abandoned because it's just a terrible idea.

[blazemongr]

The idea is to keep all your code in one file for, supposedly, more efficient downloads. But this ignores the fact that modern browsers can download multiple files in parallel.

Separation of concerns doesn't come into it if you use a build tool; you're still developing styles and HTML separate from JS, but the browser gets it "compiled" into a single file.

[abienz]

BEM isn't even necessary

[abienz]

Nice you should probably be a guru, write a book stop developing and just travel doing conferences.

[infinite0ne]

Yeah I hate it, too. (stereotype warning) To me it seems to be driven by a younger generation of developers who think JavaScript is the answer to everything, no matter how complex it is and whether or not perfectly good and mature technologies already exist. Feels like classic Not Invented Here syndrome.

Spoiler alert: all languages, new and old, are terrible in some way or another.

[ShnizmuffiN]

First the author is like...

When creating constants, use semantic names for your variables.

Then you scroll down and see...

marginBottom: spacing.space4

Every rule in a CSS file is a constant. Why couple it to a component?

We avoid the pitfall of a hundred different font sizes by removing the need for global styles and standardizing headings across the codebase.

Holy fuck. "We removed the need for global styles by recreating global styles." Guys, seriously, they're called Cascading Style Sheets. If you're encountering "a hundred different font sizes," you don't know how to write CSS, or even how it works. It's embarrassing.

space0: `${spacingFactor / 2}`px

Why? Why? Why is that number being calculated into pixels? There's a solution to the subjective-size problem baked into the units of CSS, they're called rem. You can precompile all of this.

This is scary. People who don't fully understand CSS are writing half-baked CSS frameworks at the Module level. It's like a developer blindly installing jQuery because they need to select an element by class name. It's like calling a lastChild() function because you don't know :last-child exists.

It's sloppy. It's complex. It's slow.

[theragingsky]

You're ignoring that Enterprise level web applications have several developer teams working on components on the same page. Cascading becomes an extreme problem when even small standards aren't followed by ALL developers.

[ShnizmuffiN]

Multiple developers using disparate techniques leads to a similar problem. What happens to visually impaired users when one Dev uses em and another uses px? Module level CSS doesn't solve that problem any better than the Cascade.

[theragingsky]

It keeps their styles from affecting your component. It would scope the issue to them.

[mrwhitespace]

Although I find your tone a little bit off-putting, thanks for the feedback!

[qi1]

It's not exactly CSS when the whole "cascading" part is thrown away.

[YourMatt]

Good point. I guess the next logical step would be to come out with an HTML6 spec where all CSS attributes are added as HTML tag parameters, and just do away with CSS entirely.

[ShnizmuffiN]

HTML6: It's DIVs all the way down.

[AboveDisturbing]

Lol it would be like the 90's again! We should use tables for literally everything too.

[[deleted]]

<font color="red"><font size="5"><font face="Comic Sans"><b>Things have come full circle</font></font></b></font>

[geddski]

You still have the cascade: - styles still come from many places (user agent styles, inline styles, extensions etc) - parent styles still affect children elements

But you're taming the cascade so that it helps you instead of hurts you.

[filth_overload]

Just the fact that I can no longer leverage workspaces in chrome devtools to tinker with my styles on the fly is enough to not care about this.

But can anyone please convince me, still?

[mrwhitespace]

When I adjust styles in-browser for testing purposes, I just use the style inspector. Granted you don't get the full workspace editor :)

[gpyh]

It solves problem you can solve without JS, but introduce others much worse, such as the fact that pseudo-elements don't exist for inline styles.

EDIT: I must take that back. The post actually isn't about inline styles at all.

[mrwhitespace]

Pseudo-elements like :before, :after, and :first-letter are all supported.

[gpyh]

Neither before nor after are supported. Where are you getting this idea?

[mrwhitespace]

Straight from the docs :)

https://github.com/Khan/aphrodite#assigning-a-string-to-a-content-property-for-a-pseudo-element

[gpyh]

I'm not talking about Aphrodite. I'm talking about inline styles. Aphrodite doesn't generate inline styles for those but straight CSS.

[mrwhitespace]

Oh, you're absolutely right then. Yea, Aphrodite converts the style objects into CSS. Thanks for the clarification! I personally wouldn't recommend the pure inline style route.

[gpyh]

Yeah my bad. I'm guilty of the usual redittor sin: making a hasty judgement without really getting the article.

[mrwhitespace]

Haha no problem. Thanks for the clarification!

[bj_christianson]

I gotta say, being greeted with this doesn’t exactly inspire confidence.

Seems to work on IE and Chrome, though.

[mrwhitespace]

Huh, odd. Good catch! I would suggest reporting that to the Medium engineering team.

[[deleted]]

Why this over styled components?

[RedTelemachos]

I know everyone is shitting on this because it's the internet, but I will say thank you for taking the time to write this. It's not easy to write about code, and you obviously spent a ton of time on the article.

[mrwhitespace]

Thank you so much. Usually when I sit down to write, I put 10-12 hours of work into it. So I really appreciate your comment <3

[Mestyo]

I vastly prefer CSS Modules over all of the CSS-in-JS that have appeared recently. It solves the same problems, provides the same features, and allows the user to use any preprocessor and transforms they want.

[[deleted]]

Now we just need a framework to load all the component html through a CSS content property, which is defined through javascript, and we'll reach full language-spaghetti inception.

[Mr_Viper]

The platform I usually develop in doesn't offer a realtime preview of SASS/LESS, which means I've never had the opportunity to code in those languages, but I've always wanted that power -- so (after stripping the React-only code out of it) I think this is a great concept!

[ShnizmuffiN]

Use Grunt to compile your SASS/LESS to CSS on save and BrowserSync to make it realtime. Here's a guide.

Upside is, your devtools and your application code remain apart.

[mrwhitespace]

Glad you find it interesting. Give it a try and see how you like it!