Running a developer survey like the State of CSS is a multi-stage process. First, you need to collect the data. Then, you process it into a usable shape. Finally, you come up with nifty ways to visualize it and release it to the world.
But then, once the dust settles and the traffic dies down comes my favorite part: actually thinking about the data. By taking a deeper look at our data, as well as observing how the community discussed our findings, three unexpected trends ended up coming into focus.
But first, some background for those not already familiar with the project.
I first started the State of JavaScript survey three years ago in 2016 as a way to answer my own uncertainties about the future of web development. At the time, JavaScript fatigue was running wild and I thought a comprehensive developer survey could prove itself the antidote.
Turns out I hit a nerve: that first survey turned out to be very popular, and our audience has grown each year since, along with the scope of the survey. (I was also joined by Raphael Benitte, creator of the Nivo.js dataviz library, to help me with data processing and visualization.) This year marks the first time we’re pivoting out into a new dimension, namely the not-so-simple world of CSS.
Prediction 1: CSS still has a lot of unexplored territory
One of the things we wanted to quantify with the survey was how much of CSS was still left “unexplored.” In other words, what CSS features are developers either unfamiliar with, or else hadn’t yet used. For that reason we decided early-on to focus our Features section on new CSS properties, like shapes, masking, or scroll-snap rather than “boring” floats or tables.
The resulting data paints an interesting picture: it turns out that when you look at it this way, CSS morphs from a familiar landscape to a wild, unexplored jungle.
A look at comparing Flexbox vs. CSS Grid provides a good illustration of this trend. While nearly everybody who’s heard of Flexbox has also used it, only 55% of developers who are aware of CSS Grid have actually tried it. That’s a big gap, especially for a technology as important as CSS Grid!
Or take CSS Shapes: 68% of developers are aware of them, only 31% of that group has actually used the feature.
This all points at a big gap between what we collectively want to learn and what we actually know. It’s that potential for growth that is exactly what makes CSS so exciting in 2019.
Prediction 2: Functional CSS will keep rising
If you’re old enough to remember the CSS Zen Garden — or to have actually learned CSS through it (in which case I know how you feel, my back hurts when I get up in the morning as well) — then this next trend might seem weird, or even downright wrong.
Functional CSS rejects the platonic ideal of pure, untainted markup free from any styling concerns and embraces “functional” (aka “atomic” or “utility”) classes. Think <div class="text-red text-medium border-1">...</div>.
Adopting this approach means you can’t magically update your stylesheet and change your entire design without modifying a single line of markup. But be honest, how often does this happen anyway? Compared to the often theoretical elegance of the Zen Garden philosophy, libraries like Tailwind and Tachyons provide tangible, real-world benefits, which explains why they’re so highly regarded. In fact, those take the #1 and #4 spots, respectively, in terms of satisfaction ratio in the CSS Framework category.
Tailwind especially seems to be picking up speed, at least judging by the Twitter engagement from its community in response to the survey results. Having just hit version 1.0, it’s definitely a project to keep an eye on!
Prediction 3: The battle for CSS has just begun
Looking at our data, I can’t help but wonder if “JavaScript fatigue” will soon be replaced by “CSS fatigue.”
When evaluating technologies, it’s important to look not just at raw usage numbers, but also at user satisfaction. After all, you don’t want to jump on the latest bandwagon just to find out its current occupants can’t wait to hop off it.
This scatterplot chart that’s divided into quadrants is perfect for this. It plots usage against satisfaction, making it easy to isolate popular, high-satisfaction tools into their own quadrant.
What’s apparent in this chart is that the most densely populated area is the “Assess” quadrant. In other words, the low-usage, high-satisfaction technologies that are still battling it out for supremacy. This is exactly the state that the JavaScript ecosystem finds itself in as well. Many contenders, but few decisive winners as of today.
This is not necessarily a bad thing: yes, it does make the average developer’s life harder when it comes to picking the right tool, but hey, this is why we do what we do! Additionally, competition can only be good for the ecosystem as a whole. Once the dust settles, we’ll hopefully end up with the best possible options having survived!
CSS in 2019
Overall, the State of CSS survey shows that this is not your grandpa’s CSS anymore. For years, we developers have loved to complain about the inadequacies of CSS and its lack of powerful features. But in 2019, CSS is challenging us to put our money where our mouthes are: here’s all the features you’ve always wanted. Now what are you going to do about it?
I, for one, am very excited to dive even deeper into this new world of styling. And, of course, to tune back in 2020 to see what new trends we find then!
I personally do not get why “Prediction 2: Functional CSS will keep rising” is gaining in popularity.
Can someone explain to me the benefit of writing a million different class names in every HTML element to represent every possible CSS property/value pair is more productive then just using proper element selectors combined with well named classes on a web site.
What if latter on I want every single “h1″ tag on the web site to have more top margin. Does this mean I have to do a search and replace on every single” h1″ tag on my web site and replace the “m-top-20” or whatever class with say “m-top-10” class or something…I just don’t get it…
I’m with you on this. A co-worker keeps trying to convince me how great Tailwind is. His best reason is that he has people on his team who aren’t really web people and this keeps them from screwing up — not a good enough reason for me. Functional CSS reminds me of the bad old days of font tags and FrontPage. And after having had to modify sites by going through them and removing each and every font tag and inline style, I never want to go back.
The only place where it might work is if a site is template-driven and you only have to modify a few templates. That still isn’t a good enough reason for me to want to use it.
It’s a dream on component-based sites, like a modern Javascript project or anything using Twig/Handlebars/Blade etc. If I want to change my H1, I edit my heading component, and it changes every heading on the site because they all reference that heading partial. If your site isn’t built this way, then it’s not going to work for you at all, and I can understand your skepticism.
https://frontstuff.io/in-defense-of-utility-first-css is a really good read on this topic.
Once you need a component (so you can change the myriad of classes it needs) to output a heading, I think you’ve gone full circle. I predict tables and inline styles are coming back next.
Its a result of component based UIs combined with real world scenarios.
In practice, CSS is entirely dependent on the DOM structure. Even when working with a content management system where you can’t predict the exact markup, you would know when a paragraph tag will be placed versus a table tag etc. CSS Zen Garden worked because the markup never changed, that’s why it was such a great testing ground for demonstrating how flexible CSS is.
This is a subjective observation, but I’ve also never seen a designer request a broad change that wasn’t accompanied by a myriad of additional smaller changes. (This is largely due to how hue and value work in concert.) The reality is you would never want to make a wide reaching change to CSS without checking your work. Since components are often maintained as a whole anyway, using descriptive tag names makes the DOM to CSS relation more obvious.
If you’re NOT using a component based approach however, more generic class names may work in your favor.
Tailwind advocates are bewildering. Tailwind rejects decades of industry best practices and recommendations for architecture and programming; its existence is regressive and counter-intuitive to browser and device technology.
Outside the small bubble of Tailwind advocates and a handful of misguided bloggers, the broader industry is avoiding it (as seen in the “Satisfaction vs. Usage” chart above).
“Tailwind especially seems to be picking up speed, at least judging by the Twitter engagement from its community in response to the survey results.”
Well, yeah – of course, a small community will seem larger if they’re louder.
That all sounds fine and dandy, but the reason we are not using grid and all the other fancy things is…. The friggin’ IE :/
Disregarding older browsers might work for “Codepen-Developers” (devs that only code for fun and themselves) but where I work it’s gonna take another couple years ’till we rock grid.
So no, we’re not lazy or stupid, we are bound by contracts.
You can support IE and still use CSS Grid. You can use CSS @supports. You write legacy code (float or display table layout) for IE and the wrap your modern Grid code inside
@supports(grid: auto){ ... }. The modern browsers get Grid and IE gets legacy layout. Then in a few years when IE finally dies of its slow and painful death you just remove the legacy code.On a side note, I bet once Microsofts ends-of-life’s Windows 7 in January 2020, IT departments are going to quickly migrate to more a modern OS with MS Edge. Running old non-supported operating systems combined with old browsers is a security nightmare. With all the data breaches and ransomware floating around all businesses will want their computer systems secure otherwise it could cost them millions.
“libraries like Tailwind and Tachyons provide tangible, real-world benefits”
Like what? The downside is explained well; you can’t update your stylesheet. But what are these tangible benefits? I have read about this a few times, but still clueless why I should consider this.
If you’d like to find out more you can start with these two near-classic posts:
https://mrmrs.cc/writing/scalable-css
https://www.smashingmagazine.com/2013/10/challenging-css-best-practices-atomic-approach
If you’re still interested then there are a lot more (and more recent) articles linked from here: https://johnpolacek.github.io/the-case-for-atomic-css
I’ve been using tailwind for the past year and a half. I can’t imagine writing css any other way. I’ve been working on a big ole design system, probably about 100 unique components. The purged css out is 6kb gzipped… It would be impossible to achieve results like that with BEM or any other non utility first framework. And it’s so rapid to work with… I don’t have to think of class names, I don’t have worry about repeating myself…
display: flexis defined 3 times in my entire site. One for each breakpoint… Bloooody love itInteresting article. The first prediction, which talks about CSS still being a territory not very well explored by professionals themselves, is something that I quite identify with and mirrors my way of working – my addictions, my attachments.
When flexbox came along, it efficiently solved so many design issues that I got attached. To get started with CSS GRID, which is a sleeker, sophisticated and considerably simpler solution – I needed to do a deliberate exercise on my projects. I had to deal with many mistakes, few hits and delays. Often resorted to the comfort of the already dominated flexbox.
The second prediction of functional CSS is something I will never adapt to. Functional CSS looks to me like a joke. It’s almost like doing inline CSS with classes. The code looks awful. I don’t know if it’s for freshness or pure aestheticism, but I support and defend the Platonic idea of the greatest possible separation between HTML file and style file.