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 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.
Full gist: gist.github.com/karlhorky/50ea…
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 in his tweet which prompted a bit of a firestorm
But actually, with technologies like Flexbox, vertical centering gets a lot easier, as Adam followed up with!
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
Or @bevinhernandez's
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. 👇
- 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
A popular library for CSS in JS is styled-components. @mxstbr writes about the team's motivations:
Astroturf is another CSS in JS library (with a slightly different approach avoiding a runtime):
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.
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):
.@bradleymeck thinks that the problems highlighted by CSS in JS can be solved more elegantly:
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...
For instance, some posts attempt to explain CSS in JS, such as @giuseppegurgone's blog post...
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)
(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
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?
Or maybe we can "curate" which parts of the language we would like to use and which to avoid?
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)
Another example of something mixing local scoping of CSS and JS logic is @chriseppstein's CSS Blocks:
.@bradleymeck provided some proposals further down in his thread, mentioning how @sveltejs and @vuejs handle it:
Along similar lines is @TheLarkInn's Unity Component Specification, which proposes a way forward with standardization of the single file component specification
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
For example, how @SaraSoueidan supports innovations, although she personally sees weaknesses in CSS in JS
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.
Update: @michlbrmly mentions how the Angular community is not as concerned about this due to built-in style encapsulation (maybe similar to approach taken by Vue / Svelte?)
Update: @isocroft wonders if the devtools can offer better, guided hints as to why our styles are not being applied.
Update: @johncarroll30 criticizes the inability of CSS in JS to cater to multichannel development workflows (google ads banner, html email, AMP). Maybe new framework compilation targets would help...?
Update: @iamsapegin posits that well-designed UI component systems need JavaScript
Update: Clarification of @iamsapegin's position on UI component systems
Update: @bjankord uses CSS Modules to achieve scalable and modular CSS and pass along expertise via tooling
Update: I missed mentioning @jevakallio's nice overview of at least parts of the CSS discussions in late 2018
Update: @birkirgudjonson rightly mentions that I missed Shadow DOM as one solution for scoping/encapsulation
Update: Really thorough analysis of the state of CSS and very nice proposals from a slightly different perspective:
