
CSS in JavaScript is like replacing a broken screwdriver with your favorite hammer - kbal11
https://zendev.com/2017/09/11/css-in-js.html
======
hacker_9
The argument here is that CSS should be kept seperate because it is just the
design and doesn't affect the behaviour. But this really isn't true. Want to
create dropdown menus or tabcontrols? HTML just isnt enough, you need a whole
set of styles in order to even create these controls. Additionally why am I
able to do animation in CSS? Or insert new HTML elements?? This thing has
grown far beyond simple colour switching and changing font sizes.

In fact the seperation causes so much mental overhead, that we need
interactive browser dev tools just to be able to find what styles are applied
to what element. So ultimately the idea of putting everything in one spot, per
component, is actually pretty reasonable.

~~~
look_lookatme
By far the most elegant solution I've found for this is TypeStyle [0].
Composable typed JS objects-as-CSS are a revelation and lend themselves to the
kind of abstraction/extraction that most devs do everyday.

In contrast, inline parsed CSS such as styled-components seems nuts to me.

[0] [https://typestyle.github.io](https://typestyle.github.io)

~~~
charrondev
I’ve very glad you posted this. After trying and hating styled-components,
this seems like exactly the solution I was looking for.

~~~
cmbsw
What do you hate about styled-components?

~~~
choxi
Not the op, but the big thing is that the styles are just strings instead of a
JS object so you lose a lot of the modularity and composability benefits of
writing it "in" JavaScript.

The syntax was also awkward to me at first:

    
    
      const StyledLink = styled(Link)`
        color: palevioletred;
        font-weight: bold;
      `;
    

I thought in JS you couldn't invoke a function without the parenthesis, but
apparently you can if you interpolate the string with backticks first? I've
done a lot of JS development and I've never seen that before, so while it's
nice that it's cleaner it just got in my way of understanding what's going on.
I'd rather just do:

    
    
      const StyledLink = styled(Link)({
        color: "palevioltred", 
        fontWeight: "bold" 
      })
    

It looks basically the same but is immediately intuitive and much more
powerful since the styles are objects instead of a string.

(Edited for some formatting)

~~~
cmbsw
Styled components uses tagged template literals so they aren't just strings
and are very flexible. This blog post is a great explanation
[http://mxstbr.blog/2016/11/styled-components-magic-
explained...](http://mxstbr.blog/2016/11/styled-components-magic-explained/).
For example

const Button = styled.button` font-weight: {props => props.active ? 'bold' :
'none'} `; <Button active > This will be bold </Button>

I've found it to be very handy.

~~~
choxi
Interesting. Totally possible that I just never learned the power of tagged
template literals, I only tried styled-components for a couple weeks.

------
ddoolin
I think Vue's single-file component approach is a good solution here, allowing
you to keep all three separate but in the same file with the additional option
to keep the CSS scoped and add a preprocessor to it.

[https://vuejs.org/v2/guide/single-file-
components.html](https://vuejs.org/v2/guide/single-file-components.html)

About CSS in JS, though, it mostly just seems like a different way of getting
the same thing on the page, changed only by the idea of scoping it to some
component and maybe some needed flexibility when building dynamic CSS rules.
I'm still not convinced any of those CSS approaches propped by the author are
necessary or even necessarily that helpful. They can be confusing to
developers not familiar with it and burdensome when truly not needed. I'm open
to other opinions, though.

~~~
codegeek
I am really digging Vuejs and its single file components. The <style scoped>
part makes it even better for me. No more searching through codebase for where
the css came from vs. where the JS is coming from.

~~~
madeofpalk
Just going to chime in with 'CSS Modules' \- this approach of scoped-css
generalised to use with whatever framework (but most commonly, React)

------
Wintamute
I don't think this guy gets it.

In real life large web apps CSS is very coupled to behaviour and DOM
structure. A large part of the advances towards _adaptable_ component-based
code comes only when you let go of principles like DRY.

Let me put it this way, if I come along to change a feature in one of the 100s
or 1000s of components in a project I _only_ want to think about the JS and
CSS in that component's folder. I don't want to think about how that component
exists in a vast web of generic CSS utilities and abstracted decoupled code.
Copy and pasting CSS properties is cheap. Conversely overly abstracting your
presentational code is a short cut to expensive CSS spaghetti.

It's about component encapsulation, which intimately includes its visual
presentation. If you can't think of your component as encapsulated single unit
then you might as well not be using components. And if you're not using
components, then for the love of God don't use CSS in JS.

~~~
chriswarbo
> A large part of the advances towards _adaptable_ component-based code comes
> only when you let go of principles like DRY.

> I don't want to think about how that component exists in a vast web of
> generic CSS utilities and abstracted decoupled code. Copy and pasting CSS
> properties is cheap. Conversely overly abstracting your presentational code
> is a short cut to expensive CSS spaghetti.

You probably know this, but based on your phrasing I just wanted to point out
that DRY isn't for mechanically compressing source code; it's for removing
'out of sync' issues, like causing bugs when we forget to update _this_ copy
of a procedure when we altered _that_ copy.

Removing such 'conceptual repetition' makes life easier, since (a) we don't
need to remember any couplings that need to be kept in sync (this is the
"obvious" benefit), but equally importantly (b) if there are multiple copies
of something, we don't have to worry about the other ones since they're not
related.

It's perfectly fine if many similar chunks of code are scattered around a
project, as long as they don't have to be 'kept in sync'. The whole point of
"components" (/modules/packages/etc.) is to be self-contained, so it's
perfectly reasonable to avoid coupling them together in a "vast web".

    
    
        Wrong abstraction < Redundancy < Elegant abstraction

~~~
Wintamute
You're right. I think we're on the same page. I was trying to get across the
idea that CSS and visual presentation is a special case, peculiarly unsuited
to DRY. Often visual features are only superficially similar ... e.g. at a
certain stage in development the "Foo" component is superficially visually
similar to the "Bar" component. If we then couple them together by both using
the same CSS, but the implementation diverges as new features are added then
we've given ourself a headache.

------
santoriv
> Keeping things 'DRY' and having reusable code rather than constantly
> repeating yourself is generally considered a good practice in software
> development. It enables fixes and changes to occur in one place, rather than
> having to be replicated a multitude of places throughout a codebase. It
> baffles me then, when CSS in JS advocates argue for essentially the "copy
> and paste" methodology when it comes to styling.

DRY means different things in different contexts - if you are writing a
utility function that is pure and has no side effects, then of course you want
to write the function once. The CSS cascade, however, has a tendency to spew
side effects all over your application views (e.g. one style that affects a
ton of different components), which you then need to override by adding new
styles. But be careful, because your new styles have side effects also! Ad
infinitum....

For this reason, I regard the CSS cascade as an anti-pattern in most
situations. I think that ideally, you want to isolate most of your view
specific css to a module attached to the view - so that you are pretty
confident that it doesn't have any side effects AND it's easy to know when you
can safely delete it. That way you can avoid specificity wars and doing a
paranoid but justifiable 'Search in All Files' every time you want to change a
style.

~~~
woah
What? It's very easy to be DRY in js by copying properties from style modules
into the objects containing the styles of a particular component.

------
onion-soup
Oh stop bashing on CSS in JS already. It's not CSS in JS, it's CSS in
component files which are -- surprise surprise -- VIEW FILES. I see nothing
wrong with having dimensional and visual definitions in view files, their
whole point of existence is to serve as such. You are trying to solve a
problem that doesn't exist.

~~~
vlunkr
I don't think you've contested any of the authors arguements here. They argue
that inline styles are difficult to maintain and refactor, because of the
tendency to copy-paste.

Also to implement hover or other styles, you have to go back to CSS or use JS
which is much worse.

Also, it's not CSS, it's inline styles, and you lose the cascading advantage.
Say I want every anchor tag on my site to be the same color, without CSS I
have to go stick that style on every one individually. Realistically you would
make it component, but it's a component that wouldn't need to exist with just
one line of CSS.

I'm sure it's possible to write in this way correctly, but every time I've
seen it it's been awful. But that probably has more to do with the fact that
the devs writing it really didn't care much to write clean styles.

I'm not saying CSS is definitively better, that's just my opinion. But if you
are going to advocate inline styles you have to know the trade offs and be
able to justify them.

~~~
onion-soup
>you lose the cascading advantage

What? Components and cascading? Only inline styles make sense if we are
talking components. Each component must be self-contained, pure and
predictive. Why the hell do we want 90s technology again?

~~~
Pxtl
This. You can have global styling, or you can have properly-encapsulated
components. The more you try to have it both ways, the more they step on each
other's toes.

And for me personally, at least for heavy-duty web applications, modular
components are far more useful.

------
madeofpalk
This looks like it was written by someone who hasn't really used a 'CSS in JS'
approach. The complaints are actually non existent. Any CSS-in-JS approach is
going to have a way to standardize styles across your application.

Regardless, I'm not a huge fan of these CSS-in-JS techniques anyway (although
I don't mind Styled Components if I have to use it). CSS Modules, to me, is a
far better approach and it sits there in the middleground between 'Pure CSS'
and 'CSS-in-JS'

> OOCSS, SMACSS, BEM, ITCSS, and ECSS.

The beauty of CSS Modules is that it basically merges _naming conventions_
like BEM into CSS 'master'. You don't need a convention because the language
just sorts it out for you.

Imagine arguing against variable scope in any other language with just saying
"hey, just manually namespace your variables!"

~~~
michaldudek
This! I feel like everyone forgot about CSS Modules, while I think this is the
cleanest and nicest solution to all CSS problems and doesn't make you cringe
like CSSinJS or styled components and others.

~~~
breeny592
CSS modules is pretty clean, but disagree that JSS/styled-components are
"cringeworthy". They're very powerful, especially when combined with React
component props - i.e. let's say when a component has a prop active, that when
true we want to change the color on something. A traditional way to handle
that would be by toggling some active class, however this creates coupling
from the prop to a class, and then the style to that class as well. With
styled-components, you can remove one step from that with the classes, one
less thing to think about (the developer doesn't need to think what classes
are needed with what props, and then what styles apply on those classes).

------
enkay
In practice, DRY in CSS ends up making code very hard to maintain. It creates
ghost side effects where you change something on one page and break something
on another page unknowingly.

With the exception of a few elements that don't really change at all from one
page another like buttons, doing a little bit of copy pasting or search and
replace between files is easier.

Sure, you might forget to update one page or component here and there, but at
least it won't be broken. Better a component is inconsistent in style but
functional than broken.

Using a few variables for things like color and spacing can also help minimize
this problem.

Keeping most of my CSS components encapsulated and "namespaced" has worked a
lot better in practice than trying to make everything reusable and coupled
together in ways that you'll forget about when you have to come back to that
project a few months later.

~~~
kingkool68
Couldn't agree more. I finished some refacotring of a CSS done with the DRY
mantra and there were so many hidden gotchas. When I changed one thing it
would end up breaking a number of unrelated things.

------
jakelazaroff
Best compromise I've found: CSS modules [1] (commonly implemented with
Webpack) which have you write a separate CSS file but modularizes it by
exporting hashed versions of the classnames for you to use in your components.

It's the best of both worlds: you don't have to give up CSS tooling like Sass
or postcss, but you gain modularity (which is really the only problem CSS-in-
JS solves).

[1] [https://github.com/css-modules/css-modules](https://github.com/css-
modules/css-modules)

~~~
illamint
CSS Modules have been revolutionary for us. I agree, it's a great compromise.
I don't really see any reason to go to CSS-in-JS from here. It's scaled very
well with our team and applications.

------
Kiro
> OOCSS, SMACSS, BEM, ITCSS, and ECSS

I've been writing CSS since IE6 and I was a big proponent of BEM for a long
time. In the end it didn't cut it and CSS-in-JS is the first time I've
actually felt that the CSS problem is solved. To hear "you should be using BEM
instead" feels like someone telling me to go back to ES5.

~~~
breeny592
Some developers at my workplace are very resistant to change ("why learn ES6
when ES5 works fine" is a classic line we used to get). Trying to move onto a
module based CSS approach (whether thats CSS modules, CSS-in-JS etc), and
literally one of them went "but you can handle that with namespaces, why not
just do that".

Don't understand why people will willingly do far more work, with more risk,
and more prone to error and bugs, than "learn" (using that liberally given how
trivial it is to pick up) a modern approach that solves problems for you, so
you can get back to making features, rather than dealing with quirks of older
approaches.

------
lilactown
Every time "separation of concerns" and HTML, CSS and JS come up, I want to
scream. I don't think I've ever seen so many people have such a shallow
understanding of what a term means. It's practically a trigger at this point.

Everyone who is confused: _HTML, CSS and JS are not concerns._ They do not
represent an intelligent way of separating your application code. Every time
you write the ID of an HTML tag, or a component- or feature-specific class
name, you are violating "separation of concerns."

~~~
seanwilson
I think the phrase "thought terminating cliche" is a good summary of this
concept...

I always hear things like separating everything out that way can make it
easier for non-technical people to edit the HTML which is rarely going to be a
practical idea.

> Every time you write the ID of an HTML tag, or a component- or feature-
> specific class name, you are violating "separation of concerns."

Yes, you can separate out a lot of the behaviour and presentation between
HTML, CSS and JS but there's always some overlap you just can't get away from.
Frequently you want to change the structure of the HTML just to make the
styling easier for example because there isn't a practical alternative.
Jumping around between files to edit the HTML, add a class, styling the class
in CSS, modifying the HTML to help with the styling and then adding click
behaviour in JavaScript, then trying to figure how it all works again later
involves a lot of context switching.

------
dgreensp
The arguments don't pertain directly to writing CSS in JS, in my mind. Writing
CSS in JS doesn't force you to couple your styles to your components, or reuse
code or not reuse code, or be consistent or inconsistent with your styles. If
anything, it gives you more options.

The appeal of CSS in JS to me is one less language to think in -- one less
syntax to worry about and format and lint and forget semicolons in. Also,
modules and defining constants. Most web developers seem to use a compile-to-
CSS language and a module system these days anyway, rather than vanilla CSS.

~~~
xxxdarrenxxx
Same.

The only thing that intrigues me is that you can make pretty website for the
paranoids who run hard script blockers.

------
HugoDaniel
How many of people that argument in favor of the CSS in JS know about the
Atomic CSS approach ?

It is currently the best of both worlds, you can control it with JS in a
proper semantic way (through class setting) while keeping 0% replication and
loose coupling between concepts.

It also is easily extensible and composes very well. The downsides are that
your CSS file is going to be a bit bigger than usual (tachyons.io with all
modules goes about 84KB uncompressed, 17KB gziped). But that can be quite
irrelevant in big JS oriented projects where most of the size is occupied by
big libs.

~~~
haukur
If you're interested in this approach, check out Pete Hunt's jsxstyle or Kent
C Dodds' glamorous. Both allow you to pass in props that map to css rules
(e.g., `<Flex justifyContent="center" />`).

~~~
HugoDaniel
Doesn't it break the separation of concerns ? JSX is already a big red flag in
that respect.

~~~
barryhoodlum
The separation of concerns is an illusion anyway. See hacker_9's comment.

~~~
HugoDaniel
So are most things in life. While we want to explain how everything is a
different thing let's not forget that breaking most abstractions entails a
valid point is being raised. I don't agree with almost all of the hacker_9's
opinion, but that is just my opinion, which does not automatically make it a
valid opinion.

A single thing covered in names.

------
encoderer
Most apps should have two things:

1) A style guide or component library that is used by both design and
engineering for any commonly-used component. In some projects this could just
be vanilla Bootstrap.

2) An inline style strategy -- there are now several good options to choose
from (Styled components, glamorous, etc). A cool idea here that an engineer on
my team implemented recently is using a webpack loader to convert our SASS
variables into javascript variables so they can be shared with your styled
components.

~~~
Raphmedia
> A cool idea here that an engineer on my team implemented recently is using a
> webpack loader to convert our SASS variables into javascript variables so
> they can be shared with your styled components.

What I do is set my variables in a YAML file and inject those into both my JS
and CSS files at build time.

------
throwawayReply
If your solution is "better practices", you don't have a solution.

In the real world, people will migrate to what _works_ for keeping people
inline. Appealing to better practice will be mowed down by actual practice.
Instead write tools which encourage better practice.

------
ng12
> It baffles me then, when CSS in JS advocates argue for essentially the "copy
> and paste" methodology when it comes to styling.

This is incorrect. Even if you're using JS for styles you still follow best
abstraction practices -- just instead of importing your colors and mixins from
another LESS file you're importing them from another JS file. It's no
different then designing a styling framework in pure CSS.

What the author is missing here is the biggest single problem with pure CSS --
reusability. Frameworks like React make it incredibly easy to reuse a widget's
logic, but what happens when I want to change the styles? JS-in-CSS allows you
to do that as part of the widget's API.

------
drcode
Please stop saying "CSS is for appearance, Javascript is for behavior."

Not since the 1990s has it been feasible to write a nontrivial app in which
javascript doesn't impact the appearance of a web application.

The real choice is whether one does 50% of the "graphical stuff" in CSS and
the other 50% in javascript... Or, instead, one just does 100% of the
"graphical stuff" in javascript (independent of the merits of either approach-
It may still make more sense to leverage CSS as much as possible, though I'm a
skeptic of that viewpoint as well.)

------
joshribakoff
This is like when everyone complained when angularjs put ng-click in the
template instead of an .on(click) in the js. It increased productivity because
I no longer had to do searches of the codebase to check if there are event
listeners. I can just see that by looking at my template

------
tarikjn
> If you're new to this space, some of the practices to check out include
> OOCSS, SMACSS, BEM, ITCSS, and ECSS.

These practices sound a bit outdated to be recommended to someone new to the
space. Forget any of these and just use CSS Modules, it guarantees you not
only namespacing but explicit dependency between your CSS, which most of these
conventions -- which require developer effort and compliance -- can't really
offer.

~~~
codebeaker
There's nothing on caniuse.com about CSS Modules, perhaps you could share a
resource?

[http://caniuse.com/#search=css%20modules](http://caniuse.com/#search=css%20modules)

I don't need any fancy tools or precompilers/processors/etc to use BEM or
SMACSS, so I think you may be mistaken about how Css Modules are comparable to
the list given.

~~~
tarikjn
The idea that a best practice should be usable without a pre-processor has
sailed. The fastest people give up on that, the better Web development will be
for it.

------
swyx
Are we dumbing CSS-in-JS down just to attack it? CSS-in-JS doesnt mean you
have to sacrifice visual consistency or DRY principles. you can still create a
central system of CSS properties and import them to be used while being
explicit and scoped about the stuff that is not shared. I feel like this is
being debated more than its worth. As with everything, pick the right tool for
the job.

~~~
mmmeff
amen

------
K0nserv
There are concerns with CSS in JS, but the arguments in this blog post are all
very weak or non existant.

Structural/Behavioral Vs Graphical

The introduction of component based tools changes how we design and build our
application. No longer is the fact that you can wireframe your whole
application valuable instead being able to build individual components and
later compose those is valuable. This means that the graphical properties
being tightly coupled to a component is actually good.

Loose coupling vs tight coupling

Component based systems can be built with loosley coupled components, but that
doesn't mean the components themselves should loosely coupled to their own
implementation. This is more analgous to the native platforms too.

Visual Consistency

Claiming that CSS in JS produces visual incosistency is about as true as
claiming that CSS does the same. In both cases you can be more or less
inconsitent based on your chosen implementation method. In both cases you can
move the lowest level design tokens[0] to a single places/system. Arguably
Javascript being a more expressive programming language is actually better at
achieving consistency via the more powerful variable system.

Code Reuse

Again with a design token system in place changing the design language etc is
as easy as changing a few variables.

Personally I think the more interesting problems with CSS in JS is the
inability to extract the CSS out into css files to be shipped along the
application and how that pertains to server side rendering.

0: [https://developer.salesforce.com/docs/atlas.en-
us.lightning....](https://developer.salesforce.com/docs/atlas.en-
us.lightning.meta/lightning/tokens_intro.htm)

~~~
curioussavage
The issue with shipping server side CSS is solved in frameworks like styled
components too.

------
ambewas
> Rather than being tightly linked to structure, these are very loosely
> coupled - this is why one can often wireframe an entire application out
> before styling it!

Here's one of the premises on which the article was written - and I must
wholeheartedly disagree.

If you're looking to write clean, maintainable CSS - you MUST consider DOM-
structure of the thing you're styling as well. Too often, quirky CSS selectors
are written, only because someone failed to foresee how HTML and CSS work
together to create a visual.

This decoupling of the HTML that's written, and a CSS "theme" being
written/applied after the fact, is also where things like negative margins
(ugh) and the like tend to come from.

Now, I've been working on a very large component library in React, and keeping
our CSS maintainable has not been an issue. We've got one (S)CSS file per
component, and it resides in that component folder.

And while the file is separate, we absolutely do not allow anyone to develop
any component anymore, without having any knowledge of how to style the thing.

We used to do exactly that: other devs would develop component, we would try
to style them afterwards. This always results in either us writing messy CSS
with crazy selectors or - and more often - we simply opted to re-write the
entire HTML, to suit our styling needs.

At this point in time though, I would love to write some CSS-in-JS here. Too
often we need to use variables based on JS logic; And it ends up as an inline
style right now, anyway...

All in all, if the writer believes HTML and CSS can be written separately,
without resulting in a terrible mess, I'm having a lot of difficulty accepting
that they know what they're talking about. Sounds like they never had to work
on, or maintain, a large application.

------
n0us
[https://github.com/styled-components/styled-
components](https://github.com/styled-components/styled-components)

strikes a really nice balance here imo. I use Radium every day and in general
it has been easier to maintain and use in comparison to all css but if I could
do it again I would go with styled-components.

------
adamnemecek
"As the lead for ZURB Foundation, I've trained hundreds of people on frontend
frameworks and best practices."

Ok, this kinda explains everything.

~~~
dmitriid
Funnily enough, it's impossible to properly style many of ZURB's components,
as their CSS is tightly coupled with the DOM

------
adamsea
Most of the author's concerns about reusability, maintainability, and
separation of concerns can be addressed by thoughtfully structuring your
JavaScript application project. For example, using React/Redux and JSS, the
JSS (a CSS-in-JS technology which uses CSS modules among other things) goes in
the "dumb" component files, not the "smart" (or "linked") container components
which pass Redux state and various functions to the "dumb" component. And then
creating a styles.js file (or multiple files if appropriate) is a simple way
to create shared JSS styles which can then be imported into various component
files as needed.

------
ttctciyf
Very readable article. My favourite line:

> Please enable JavaScript to view the comments powered by Disqus.

------
err4nt
I agree that often times CSS-in-JS forfeits some of the expressive power that
makes CSS powerful, in the attempt to gain some muscle from JavaScript.

Instead of CSS-in-JS I think a better pattern for extending CSS with
JavaScript is 'event-driven virtual stylesheets', which I call JS-in-CSS.

I'm writing a website dedicated to JS-in-CSS techniques, plugins, and theory.
It's still a heavy WIP right now, but there are ~20 plugins that can be used
and code samples and links to their documentation which is good to go already:
[http://responsive.style/](http://responsive.style/)

I'm trying to write down and share the results of what I've found trying to
combine JavaScript styling with CSS for years, and the patterns and techniques
that make the two useful.

You should be able to take full advantage of 100% of CSS's expressive power
_and_ still augment it with JavaScript logic. You can have the best of both,
and this JS-in-CSS pattern works in every browser you can imagine (I recently
got it working in IE7 and IE6 just for fun!(

------
curioussavage
I think the best answer to this is three questions.

Is the browser being used to make dynamic "apps" instead of static web pages?

How do app frameworks/toolkits on other platforms style their apps?

And finally:

Do you think the people who designed all of those frameworks were stupid?

Seems to me like the web is finally catching up with the only sane way of
styling the widgets in an app. It's done in the same language and it's per
component/ widget.

------
bcarroll22
> JavaScript used to do this, and we fixed it by encapsulating everything in
> modules and using tools like webpack to stitch everything together.

We've done the same with CSS, and CSS modules work extremely well. For us,
they've even eased the need for SCSS.

------
colek42
I have started using and evangelizing styled-components in our react projects.
Hard to explain, but it just feels like it is the right way to do CSS. Having
everything to do with the view for a component in one file works well for the
way I work.

------
tomelders
CSS is for a print paradigm. But it makes very little sense in a web app
paradigm. So in lieu of anything better, we encapsulate CSS with hashes, and
write it in Javascript so we can have dynamic styling.

What we really need is a better way to style web apps.

------
nathan_f77
I've been trying out CSS modules in my new project. I've also set up a library
that generates Flow type definitions, so I get static type checking and
autocomplete for my CSS classes [1]. It's pretty awesome, and works with SASS
too. I love having every React component self-contained. It makes refactoring
and reusing code so much easier.

[1] [https://hackernoon.com/type-safe-css-modules-with-flow-
dd95e...](https://hackernoon.com/type-safe-css-modules-with-flow-dd95e761bbe5)

------
JoshMnem
Elm CSS looks interesting:
[https://www.youtube.com/watch?v=W4Xnas3exk0](https://www.youtube.com/watch?v=W4Xnas3exk0)

------
DonHopkins
Why can't people just not go out of their way to write crap CSS in the first
place?

There seems to be this trend to show off all the possible different ways you
know of addressing a single element somewhere, by pointlessly combining them
together in brittle ways that depend on each other and accidental document
structure, using haphazard random inconsistent naming conventions.

If there's only one of them, then use a fucking id.

~~~
breeny592
Context: I work on a large CMS powered site

We have a company wide rule of no IDs in styles - we actually lint for them.
As a front end team, we can't be certain that there will only ever be one of a
component on a page at a time. Sometimes we can be mostly certain, but the
content authors can theoretically do anything, and our job is to provide them
flexibility whilst keeping the site looking good.

Modular CSS would be a God send for us, would be able to handle a lot of
things much cleaner but sadly the current build of the CMS doesn't allow for
it.

In small sites, or anything with static content, IDs are more than valid. But
it becomes a lot harder when dynamic content, especially dynamic components,
come into play.

------
dmitriid
> The Real Answer: Better CSS Practices... > If you're new to this space, some
> of the practices to check out include OOCSS, SMACSS, BEM, ITCSS, and ECSS

This is not a real answer. It's an attempt to fix the broken screwdriver with
ducktape, bird poo, and spit.

~~~
talmand
But that's how web apps are built.

~~~
dmitriid
It is. But it's not the real answer.

------
thinbeige
'Broken screwdriver?'

Don't get OP's analogy. Does he mean CSS?

While CSS can sometimes be nerve-racking it's the most modern layouting
system. There was a reason that the React Native team chose CSS' Flexbox for
their layouting system.

------
yuchi
This article is a little bit flawed and a little click-bait-y also.

CSS-in-JS is more or less enforced-CSS-modules + some sugar + a different way
to author your styles.

Most of the arguments there are against CSS modules, or “isolated styles”.

~~~
breeny592
And it does a poor job in that regard too.

\- CSS modules promote more re-use if structured correctly - BEM and the like
exist to do the literal opposite, to isolate styles to minimise regression and
site wide issues at scale.

\- Visual consistency is enforced in CSS usually through variables to make
sure spacing, colours etc. are the same, with a default set of global styles.
There is literally no difference in a modular approach - you can easily have
global styles to theme, and then isolate and import the more specific rules as
needed.

This article reads as "I learnt how to do CSS this way so anything new is
scary and wrong"

~~~
yuchi
> This article reads as "I learnt how to do CSS this way so anything new is
> scary and wrong"

Yes. A little bit sad…

------
nikolay
Very well-put! In trying to solve one problem, we create tons more. So much
more added complexity! The React stack is growing out of control with the
flavor of the day changing daily per se!

------
enturn
Like religion there's no one true way but I hope people agree that using
analogies in technical discussions adds to confusion and is best avoided.

------
AJStacy
The Shadow DOM solves all of CSS's scoping problems.

------
nkkollaw
What's wrong with web components? They solve the problem very elegantly, and
thanks to Polymer and others we can use them today.

------
k__
I even use CSS in JSX, while some people would consider JSX alone madness
already, but it feels really nice to write it that way.

------
azr79
Tell that to ReactJS devs, those mad men include even HTML in their JS files,
how insane do you have to be.

------
devsmt
not all CSS is equal: if you define global styles like h1{color:#000;} you
want them outside components, in components you want the minimum of css needed
to render correctly your date picker or whatever you are trying to accomplish
and you want minimize external dependency on the global css.

------
hfourm
I have highly been enjoying "CSS" in JS with React and things like Radium and
AphroditeCSS

------
xXinVeRteDx
LESS/SASS takes care of this with nesting (ie. scoping css rules).

------
megamindbrian
I've worked on many different codebases. CSS and script tags add to the mess
something awful. For cleaning CSS I take an existing site open with developer
console and click through every HTML element in the tree looking for
alignments offsets, centering madness before flexbox, font size and color
corrections are all stripped away. These settings belong in the top level body
or global part of the CSS. I flatten out the HTML and CSS alike so all my
elements are at most 4 levels deep.

This is a process that takes about 1 day per product page. It's a horrible
pain to clean up a site but the payoff is easier maintenance in the future and
hopefully some acknowledgement that the page loads better. This skill can
easily be trained in to developers. I hope this reminds everyone that
computing is a skill that must be practiced.

It isn't normal to use tables for layout these days, just like it is no longer
normal to use JavaScript for centering elements vertically. This is fixed with
flexbox. Please learn and use it!

~~~
jacobr
Try doing this in a team of 5-500 developers continously adding features all
over the site.

Then try adding an isolated component in a sidebar somewhere with 0% risk of
visual regression elsewhere.

------
megamindbrian
HEY LOOK, NO ONE CARES ABOUT YOUR PROBLEMS! [http://caniuse.com/#feat=style-
scoped](http://caniuse.com/#feat=style-scoped)

------
naraniano
Image macro memes in 2017 is like putting fingers down my throat.

