Skip to content

Instantly share code, notes, and snippets.

@karlhorky
Last active December 25, 2023 19:14
Show Gist options
  • Star 6 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save karlhorky/50ea676507f87d2fcb245b089da56818 to your computer and use it in GitHub Desktop.
Save karlhorky/50ea676507f87d2fcb245b089da56818 to your computer and use it in GitHub Desktop.
CSS is Complex. We can do better.

CSS is Complex. We can do better.

Posted on https://twitter.com/karlhorky/status/1082622697325166592

Ok, thread time.

CSS is unnecessarily complex. And we can do better.

There have been side conversations here and there, but I want to consolidate the information and opinions here. This will be a running thread, and I'll add to it as new things crop up.

CSS is complex. What does that actually mean? Does it mean that it is hard to vertically center something? Does it mean that it's difficult to learn? Does it mean that there are simpler ways of doing things? Well, all of the above, to varying degrees.

Is it hard to vertically center something? Maybe, if you google for answers and pick something outdated, as @AdamRackis found out https://twitter.com/AdamRackis/status/1074057804896460803

But actually, with technologies like Flexbox, vertical centering gets a lot easier, as Adam followed up with! https://twitter.com/AdamRackis/status/1074346351578791937

Is CSS difficult for new developers? Although the base concept is easy and quick to grasp (property <-> value declarations on objects), I've seen a lot of people go through all stages of learning CSS, and I would have to say "yes, some parts will make you tear your hair out".

Sometimes this is also visible in the public space, such as @tomhockett's frustrations here https://twitter.com/tomhockett/status/1082526692990730240

Or @bevinhernandez's https://twitter.com/bevinhernandez/status/1074433389732749312

What are these unfortunate parts of CSS? Among other things, they are things like:

  • cascade
  • specificity
  • scaling
  • debugging

There are some tools and techniques that help with these things in various degrees. 👇

For instance, a couple of early techniques for dealing with the cascade and specificity problems while scaling CSS in large codebases were OOCSS by @stubbornella and BEM.

These techniques shifted the burden from debugging to manual, painstaking, error-prone naming of classes on components. Having used this for a number of years, it wasn't simple to learn or use. But it did help out with some of the nastier problems with CSS!

Also helpful was a class of tool that showed up earlier on - developer tools (Internet Explorer, Firebug, eventually Firefox and Chrome devtools). These tools helped (and continue to help) debugging and prototyping CSS.

But developer tools are still bound to CSS, for all of its strengths and weaknesses, so they can only go so far.

CSS Modules was an approach to solve similar specificity and cascade issues to OOCSS and BEM, but with an automated solution. No naming rules to learn or remember! This was a nice improvement.

Then came the paradigm of CSS in JS. In this approach, JavaScript logic can be mixed with and colocated with CSS, often along with similar automation to CSS Modules for specificity and cascade problems.

CSS in JS was originally presented by @Vjeux in 2014 along with his motivations https://twitter.com/antonycourtney/status/989158824132001792

A popular library for CSS in JS is styled-components. @mxstbr writes about the team's motivations: https://twitter.com/mxstbr/status/1049202268090847234

Astroturf is another CSS in JS library (with a slightly different approach avoiding a runtime): https://twitter.com/sophiebits/status/1079136144892190720

There have been countless criticisms of CSS in JS, with activity on both sides of the topic increasing rapidly in the last two years. Lots of new developers are adopting it, lots of developers are against it.

For example, this post by @rem questions the reasons behind it existing. https://twitter.com/rem/status/989069638553231360

A bit more nuanced is @ChrisFerdinandi's dismissal of the paradigm, with his analysis of what he believes are "legitimate" problems (and those problems which do not need to be fixed): https://twitter.com/radhikamorabia/status/1074653079058989057

.@bradleymeck thinks that the problems highlighted by CSS in JS can be solved more elegantly: https://twitter.com/bradleymeck/status/1059468052172103680

As for the supporters of CSS in JS, there has been activity on this side too.

For instance, some posts attempt to explain CSS in JS, such as @giuseppegurgone's blog post...

https://twitter.com/giuseppegurgone/status/1071499929028308994

...And @threepointone's gist:

https://twitter.com/threepointone/status/1071003875136569346

But I believe these posts incorrectly focus on one solution, instead of trying to figure out the best solution from first principles.

(this is aside from my critique that they are not trying to convince an audience with a CSS background)

I think that CSS in JS is just one step towards a better styling experience based on first principles https://twitter.com/karlhorky/status/1069888903577067520

I think with some analysis it is possible that we come up with better tools in the future. They may not look like CSS in JS and may change some things about CSS, but in the end they may offer a better way to style things.

For example, why can't we learn something from the error messaging experience of something like Elm?

Or from the way that native applications are styled?

https://twitter.com/AdamRackis/status/1074143316713897985

Or from the user experience that designers have in tools like @sketchapp or @webflow?

https://twitter.com/threepointone/status/1074145371276881921

Or maybe we can "curate" which parts of the language we would like to use and which to avoid? https://twitter.com/karlhorky/status/1074442611778379776

An example focusing on a concrete use case can be seen in @necolas' tweet showing tricks to write CSS at scale used at Twitter (although some opinions exist that this is "overengineered" - cc @ChrisFerdinandi)

https://twitter.com/necolas/status/1058949372837122048

Another example of something mixing local scoping of CSS and JS logic is @chriseppstein's CSS Blocks: https://twitter.com/tomdale/status/988817099895328768

.@bradleymeck provided some proposals further down in his thread, mentioning how @sveltejs and @vuejs handle it: https://twitter.com/bradleymeck/status/1069971184312336386

Along similar lines is @TheLarkInn's Unity Component Specification, which proposes a way forward with standardization of the single file component specification https://twitter.com/_pi0_/status/899007100952641537

This is still an area of active research with no standardized approaches in sight. I will continue watching this space and post here with anything interesting.

As in anything complex, there are experts with a vested interest in the language staying somewhat familiar. That's totally fine too, as long as there's not too much stifling of potential innovation.

Some experts are fine with going even further, to support explorations of new innovative ideas.

For example, how @SaraSoueidan supports innovations, although she personally sees weaknesses in CSS in JS https://twitter.com/SaraSoueidan/status/1074595409086111745

Sorry if I forgot to mention something or misrepresented anyone! Feel free to point out anything that should be included. This is a living thread and I will continue to update this.

cc @NikkitaFTW @sarah_edo @iamsapegin @ChrisFerdinandi @MoOx @snookca @mrmrs_ @bloodyowl @oleg008

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment