The Changelog: Software Development, Open Source - The state of CSS in 2019 (Interview)

Episode Date: June 14, 2019

We’re talking with Sacha Greif to discuss the State of CSS survey and results. CSS is evolving faster than ever. And, coming off the heels of their annual State of JavaScript survey, they've decided to take on the world of styles and selectors to help identify the latests patterns and trends in CSS. We talk through the history and motivations of this survey, the methodology of their data collection, the tooling involved to build and run the survey, and of course we dig deep into the survey results and talk through the insights we found most interesting.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash Changelog. This episode is brought to you by Linode, our cloud server of choice. It is so easy to get started with Linode. Servers start at just five bucks a month. We host Changelog on Linode cloud servers and we love it we get great 24 7 support zeus like powers with native ssds

a super fast 40 gigabit per second network and incredibly fast cpus for processing and we trust linode because they keep it fast they keep it simple check them out at leno.com slash changelog. All right, welcome back, everyone. This is the Changelog, a podcast featuring the hackers, leaders, and innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, we're joined by sasha grief to discuss the state of css survey and the results css is evolving faster than ever and coming off the heels of their annual state of javascript survey they decided to take on the world of styles and selectors to help identify the latest patterns and trends in css we talked to the history and the motivations of the survey the methodologies of their data collection, the tooling involved to build and run this survey. And of course, we dig deep into the survey results and talk through the insights we found most interesting.

Sasha, we're here to talk about the state of CSS survey results. But before this survey was the state of JS survey, which has been going on for a little while now. And it seems like you're enjoying that or at least getting benefits from that in the community. So you're expanding to CSS now. Why don't you help us understand the history of these surveys, why you started doing them and what's going on? Sure. So I think like a lot of people, like especially a couple years back, I was a bit confused about the JavaScript world there was a lot of things going on react angular Redux relay flux whatever and so the main reason why I started these surveys was to help myself figure

things out and especially know what to focus on next, what to learn next. Because, I mean, when you read Hacker News or whatever, it seems like there's a new thing coming out every week and everybody's learning all these things all the time. But the reality is it takes, you know, weeks, months or more to get good at something like React or Angular. So you have to be careful about what you pick and what you invest your time on. And so that was really the main reason,

like just figure it out. And I decided to do it as a survey because I thought if I'm in that position and I kind of spend a lot of time online, I try to keep up. So if I'm confused, I bet there's other people who don't have as much free time as I do, who are probably even more confused, and they could use the help. And they

could use the data, especially. So that was kind of the reason for the first state of JavaScript survey like back in 2016. And so last year, 2018, we had the third edition. And now this year, 2019, we're going to have another state of JS. But before that, we're having the first ever state of CSS. So have you ever done surveys before? Because as you've learned throughout this process, I'm sure if you haven't done them before, is that it's very hard to do a survey well. And I'm sure it's been a learning process. But before that, have you done surveys in your work or in your experience previously?

Not really, at least not on that scale. I've definitely done some really small-scale data collection, asking people, I don't know, book readers or whatever for feedback. So those are kind of like surveys in a way, but nothing where I would really analyze the data and publish the results and so on. So that was actually brand new for me, yeah. So one of the things that's happened is that there's been some criticism

and even some criticism from us here on the ChangeLog network, on JS Party, about the methodology of the collection really around the transparency of the data and trying to get representative demographics. So you can go back and listen to JS Party episode 54 where we discussed these things. And Sasha, you heard that show and then you wrote up a nice post on FreeCodeCamp

all about who took the state of JS 2018 survey. Maybe review that scenario from your perspective. I hope that our criticism was constructive and we weren't trying to take shots at you, just trying to talk about the results. One of the reasons why I think we thought it was worth talking about is because of the way that you do these surveys is so high quality, my eyes, at least, that they seem like because it's the state of JS and because you put up such a polished result that it comes with authority. And so there's, you know, because of that comes some responsibility. And so that's why we thought

it was worth talking about is that this is not a survey that is put on by, you know, professional survey takers. It's put on by some community members. Yeah, so just tell us about that post you wrote. We'll put it in the show notes. But from your side, how has that kind of criticism happened? Yeah, so I think the criticism in that podcast, a lot of it was very valid. So for me, there's like two kinds of criticism. There's one about the lack of transparency,

not knowing where the data comes from or methodology, and that's 100% valid. And I'm going to come back to it. But then the criticism that's always kind of getting on my nerve is when people look at the results and it doesn't match their preconceived notion of what it should be. And they're like, oh like oh wow React did really well in the survey so the survey must be biased towards React or you know maybe

oh these guys used React to build a site so how could they not be biased and that's kind of annoying because we really do our best not to introduce any bias and beyond that it's you know it's not something that we can necessarily control like if somebody is like well the only reason why let's say Amber did to introduce any bias. And beyond that, it's not something that we can necessarily control. If somebody is like, well, the only reason why, let's say, Ember did poorly is because Ember devs didn't take the survey. Well, it's not like we were turning away Ember developers, right? We always do our best to get as many people as we can to take the surveys. And if it doesn't reach such or such community,

we're really limited in what we can do because we don't have a budget or we don't have advertising or anything like that. So it's just us begging people to take the survey. Let's talk about that then. Let's dive into sort of the processes that you use to attract the community that it's supposed to represent. What are some of the ways that you do that? Do you do blog posts, podcast appearances? Obviously, you're doing one here today. What are some of the ways? Yeah, so the launch for a survey,

basically, we rely on the community. We get in touch with people who are influential, like Wes Boss or Peter Cooper, who runs the JS Weekly newsletter, Chris Coyier from CSS Tricks. So people like that who have a wide audience, which obviously also introduces its own set of bias because to take a practical example,

Wes Boss, he's done courses on React, among other things. So maybe his audience is a bit biased towards React. So that's a fair criticism in a way, but it's just about the fact that, well, what else can we do? Yeah, it's a hard problem to solve in a really decisive way. We can only do our best, basically. But yeah, it's a lot of writing posts. One thing I really try to do is reuse the byproducts of running the surveys.

So for example, last year I wrote a post about how to evaluate a JavaScript library and kind of tying it in with the questions that we ask in the survey to try and explain, well, both give people this system for evaluating a library and also explain the questions that are in the survey. Do you ever reach out directly to framework authors and library authors, let them know? For example, if the Angular community

feels underrepresented in the demographics who took the survey and therefore believe that Angular is underrepresented, because of that, it seems like it would be beneficial for them from the leadership perspective to know, hey, here comes the state of JS for this year. We know all the frameworks will be there. Angular is going to be there. We want to get this out to our community

so that Angular is well represented in the demographics. Is that something you've done to talk to library authors, framework teams? Because they have vested interest in helping spread the word. Yeah, that's not something I've done. First of all, it's not always that easy to know who is in charge of Angular or React. There's people who are very visible online, but they might not be the actual people who

know about these things. Maybe that would introduce some bias, because if for whatever reason, if I contact Angular or React, Ember, but not Vue, let's say, that's already a huge bias against Vue. You'd have to do all of them. You'd have to look at your actual survey and have, okay, here's my six frameworks that are on questions. I'm sure there's maybe another question. And so we're going to contact all six and go from there.

But not saying that that would necessarily solve the problem, but it seems like if there's underrepresentation in certain niches, then it could be up to the advocates or the dev rels in that niche to just at least get the word out that the survey exists. Now, if they start gaming it and stuff, you got a whole nother problem, right? Yeah. And also when you say under-representation, it's like, it's tricky because compared to what, it's not like there's a population count for Angular developers.

So the best we can do is compare our results to the Stack Overflow Developer Survey results. And so far, they've been pretty similar. There aren't major differences. So that tells us that we're in the right direction. But yeah, it's definitely a tricky problem. So to circle back to the transparency and methodology thing, what I started doing last year, in big part, thanks to your podcast and the feedback that I got there, is showing the sources. So how did people find the survey? Which websites? Was

it Twitter? Was it CSS Tricks or JS Weekly or whatever? Hack and use. And that's a mix of what people self-report. And also we can use different tags. So if it's on CSS Tricks, the links will be, you know, state of CSS slash question mark source, whatever. So we really try, at least this time, we really tried to keep the different sources distinct and make it easier to track them.

Yeah, that's excellent. And you have the data downloadable now in this new one right there at the top in a demographics section. I think specifically in the state of CSS 29, which we are looking at kind of a pre-release, which is maybe 98% done. By the time this show goes out, audience, you can go out to the website and check out the full results but right there you have the breakdown of sources which is really awesome as well as everything is downloadable that was another one of our the criticism I think Kevin

said on JS Party was if we could have the data maybe we could look at it and the community could do those kind of things. And so, I mean, it shows that this is a good faith effort. Absolutely. And we appreciate that, that you are adjusting and adapting and saying, well, let's make this better.

And so that means the surveys will get better every year. And that's ultimately what we're all after because they're so valuable. Yeah. And I think when I work on a project like that, I'm always doing my best. But the thing is, my best doesn't reach the same level in different areas. So my background is more as a designer, so doing my best on that level,

hopefully it gives something that looks pretty professional and that has a lot of credibility on that front. But then my best on a more like survey methodology front might not be as good because I'm still learning. So the end result is like kind of limited by what I and Raphael, my partner can do. So hopefully we'll improve like everywhere as we go. But definitely the first couple editions

are kind of have that mark of our strengths and weaknesses. And as we go, hopefully it gets more rounded out. What do you think the magic number is or a range of numbers that can represent a community's opinion? So if you are speaking of JavaScript, very large, CSS, I would potentially say even more larger because so many people touch it. I could be wrong. But, you know, what are the numbers of people giving their feedback, giving their survey results, so to speak, to curb this bias or even create this awareness of what is and is not popular in a community? Yeah, that's a good question.

It's really tough to answer. So for me, you know, I thought about that a lot after, especially last year where a lot of the criticisms, because the survey got bigger, so I got more criticism, which is fair. And so my philosophy is kind of, it's not really the number or whatever that matters. It's just people knowing what the data says and where it's not really the number or whatever that matters it's just people knowing what the data says and where it's from so you know if you survey you know 20 people that's fine as long as you say that it was 20 people and if it's 200 000 that's fine too and if it's uh you know

20 000 but they come from such and such sources which might introduce its own bias, it's fine as long as you disclose that. So that's really what we're trying to do. And for example, for stateofcss, since a lot of our respondents are coming from having done the stateofjs survey, I'm sure there will be a bias towards things like css and js or whatever. But I think that's fine because people can know that and see that and also then use the data critically.

For example, maybe the proportion of respondents who use CSS and JS libraries will be higher, but their opinion of these libraries will still be representative of the larger community. So it's really like, you know, I think in our daily life, when we see numbers like in surveys, we're kind of not thought how to analyze them. It's kind of, oh, this candidate has,

like Trump has 30% chance of winning or something. So you're like, well, okay, that's tiny. It's never going to happen. And then he wins and you're like, well, the polls were wrong because the polls said 30% and he still won. But obviously that's not how polls work. And I think there's kind of an effort on the part of the people reading the data as well to. A sample of 20 people even statistically is not enough to come up with any sort of conclusions. But at the end of the day, like you said, Sasha, if the data is out there and you provide the context, like this source, right now I'm looking at the results

and 23% of the people who participated in the state of CSS heard about it because of the email. I assume that's the state of JS mailing list. Is that the email it's referring to? Yeah, so they're coming from that place. And it's up to us as the consumer of these results to come to our own conclusions based on not just, hey, look at this one, it's number one, and then walk away.

That's a very shallow way to live life, right? That's not how it works. You have to do your own analysis. And as long as the data is there and there's a good faith effort and it's getting better over time versus getting worse, or there's no effort put in to get more respondents or more types of respondents, then that's a problem. But it's up to the reader to interpret the results. And you can't just take the top five and say here's the winner because i read it on a website that somebody did on that note too i would say if if you're that person out there listening right now who has you know has had some concerns i suppose about this or other surveys and given the fact that 22.9 percent of the people who found out about this survey learned about it through email, hey, maybe go sign up for the email.

That way you can contribute to its information rather than being upset by the results. I would also say that, Sasha, it seems to me that surveys, while may indicate positions of truth, are not exactly full truth. They're sort of indicators. And I would even rewind back to your original reason for doing it, which was to inform your own personal desires for the JavaScript community and essentially trudging your path. So it was a source of information, not a source of like this is the way it is. It was more like here's some data to make the next career decision you might make. For example, your, your meter JS book, for example, or folio things you're doing there or whatever, you need more information, more data. And I think that this is a way to get people more data to make accurate and more advisable choices rather than not having data, data-driven.

Yeah, it's one more data point which you can take into account or not. It's up to you. Now, I think it's fair to kind of say that because I called it the state of JavaScript, I'm kind of staking a claim in a way. This is what it's like, and I have the ultimate truth. But I think you have to take it more as a marketing thing in a way. Like, I thought it was a good name.

I thought it really communicated what I was trying to do. I'm not trying to say, like, I have the only truth about JavaScript or CSS or whatever. So you have to take it with a grain of salt. There's also, and I completely agree with that, it is a great name. And I said this on JS Party, I'll say it again because I'm back now on the 2018 State of JS.

The website's just really well done. Oh my gosh, it's so good. It's so good. And then you have the awards at the end. I think maybe this is the part that maybe tips people over. It's like, okay, here's the highest satisfaction library, here's the most mentioned thing. And of course people want to see their favorite library or framework

get that award, and so it's going to bring out the feels. I think it did, so some of that is, why is it Jest and it's not GraphQL or whatever those feels happen to be. So I love the idea of the awards, but I wonder if that particular section of the results, which I see you're doing again here for CSS in 2019, maybe drove any sort of the non-constructive criticism that was out there.

Yeah, maybe. But I think, so I'm a big Meteor.js user and Meteor gets really bad ratings every year. How does that make you feel? Makes me feel bad but you know it's like if I can take it others can probably as well. There you go I like that. This episode is brought to you by GoCD. With native integrations for Kubernetes and a helm chart to quickly get started, GoCD is an easy choice for cloud-native

teams. With GoCD running on Kubernetes, you define your build workflow and let GoCD provision and scale build infrastructure on the fly for you. GoCD installs as a Kubernetes native application, which allows for ease of operations, easily upgrade and maintain GoCD using Helm, scale your build infrastructure elastically with a new Elastic Agent that uses Kubernetes conventions to dynamically scale GoCD agents. GoCD also has first-class integration with Docker registries. Easily compose, track, and visualize deployments on Kubernetes. Learn more and get started at gocd.org slash kubernetes. Again, gocd.org slash Kubernetes. Again, go cd.org slash Kubernetes.

So let's talk about how you go about doing these results because it's a lot of work and we want to even hear about the process of getting it into this awesome form. First of all, we should probably mention that you aren't the only person doing this. You want to flesh out the team for us so we understand who's behind these surveys and the website and the charts and everything. Sure. Yeah.

So, I mean, I talk about I did this, I did that a lot. But that's because, you know, I take a lot of the decisions. But actually, behind the scenes, I'm held by Raphael Benit, who is, funnily enough, so I live in Japan, and I'm French, and I'm a JavaScript developer. And he also lives in Japan. He's also French, also a JavaScript developer. And he, so we met here at a tech event. And we, you know, really hit it off because we were both interested in the same things. And he has a charting library for React called Nevo, N-I-V-O-J-S, which is really, really cool. It powers all of our charts. And it's really amazing. It has so many chart types. It's really flexible. You can customize it in tons of different ways. So he was kind of the perfect person to help me with that project, especially because he's also pretty good with data processing.

So you asked me about the data processing stack. And we collect the data with Typeform. So it's like a hosted form service, which is pretty good. It kind of struggles with our surveys because they are so long and they have so many questions. One day, we would really like to build our own survey frontend so that we can really tailor it and work on the performance aspect and so on. But for now, we're happy with Typeform. So once we have all that data in, Raphael set up an Elasticsearch process, a database thing, which downloads all the data from Typeform, puts it in Elasticsearch, queries it, aggregates it, normalizes it, and that generates YAML files, just static YAML files, which go into Gatsby.

And we use Gatsby's GraphQL querying to use those YAML files as source and inject that data into the React site that serves as the front end. So we found your YAML files yesterday as we were poking around the open source code. Because Adam's like, how do they even build out a site like this in Gatsby? And I was just like, well, I'm sure there's just some data source somewhere. Maybe it's pulling from a back end that just serves up JSON or, oh, nope, here's the YAML files right down in there. And we started discussing just briefly, Adam,

you and I, just like, why YAML in this circumstance? Because that's what Typeform gives you? Is that a format that you would prefer? I mentioned well, at least you could put comments in YAML, even though it is auto-generated. Whereas JSON as a data file, you can't put comments in it.

If that was a choice of yours, if that was just like Typeform spits it out, or the data processing stuff spits that out? No, I much prefer YAML because it's less verbose, there's no curly brackets everywhere, there's no commas to deal with. JSON for that kind of use, if it's in a.js file and it's kind of permissive, that's fine. But like.json files are always horrible to deal with, in my opinion,

because the syntax is so strict. So yeah, YAML is really convenient. It's easy to understand. It's easy to edit even by hand. Yeah, YAML is really cool. So is Gatsby, is this your first run at Gatsby? Or have you used it for other websites curious your your thoughts on gaspy real quick before we dive into

the the actual results here yeah no i've used gaspy for a while um i think before version one yeah definitely when it was in beta so i don't remember what the first site i built with was maybe the first year of setup.js but since then i've kind of used it for everything I do. So as an aside, I also have my own JavaScript framework called Vulkan.js, which is based on Meteor. So it's not a static site generator. It's like a Rails-like framework. But for everything else I do that's more of a static site, I use Gatsby. So I've used it for the three state of JS, state of CSS. I use it for my own little homepage. I use it for a blog that I'm doing for my work.

I use it for a bunch of stuff. I think state of JS and CSS, though, that's the most, Gatsby stack that I'm dealing with currently. There's definitely a lot going on. But Gatsby is really cool. Like, I really like it. It's definitely not super easy. Like, it's more of a power user thing, I think. Like, well, I hope the Gatsby guys don't get mad at me for saying that.

Because they're really cool guys. But I think it really shines, let's say, when you have to aggregate lots of data sources and you want that flexibility, basically, that other static site generators don't really provide. Yeah, it's funny. When we had Jason Lengstorf on the show to talk about Gatsby, we were assuming, because it pitches itself

as the fastest static site generator, and they pitches itself as the fastest static site generator, and they don't like the term static site generator, but we'll just use it for now. We thought that meant it was the fastest build times, and I was like, well, that's kind of crazy, because what's the Go one? Hugo builds super fast, and so I thought it was developer-friendly in that regard.

It's going to build fast, it's going to be super easy to use. He's like, no, no, no. The point is the results, the output, the actual website at the end is optimized to be the most performant, the fastest. All the best practices on the results, but that doesn't necessarily mean it's the simplest, fastest, most developer friendly to use

because they're working on all that, but it's flexible, and the results are awesome, and so that's why it's worth it. Yeah, for sure. It does a lot for you behind the scenes. There's a ton of plugins. It's really, really powerful, and what's cool is once you do master it, you can do simple things with it. Like my own homepage actually removed the JavaScript from it. So it's all statically rendered. And there's no JavaScript on the client, basically.

So you can even do that. So of course, you don't get the performance aspect. But if you just want something that's 100% static, I guess we can do that too. I get curious about analytics. Are you doing server-side analytics, or do you still load a JavaScript file for tracking? I don't know. I think I might not have JavaScript, because it's just my own homepage. So while we're getting meta, before we get into the results, one last aspect that we find interesting,

and I think you'll find it interesting as well, listeners, is that there's actually a new thing this year, which is brand new, the t-shirt. So we've got to talk about the t-shirt before we get into the results. A CSS t-shirt. Support the survey and look good in the process. This is a very cool css logo shirt sasha

i assume that's you on the website they're uh wearing it tell us about this idea what you're doing with it and what you hope people do which i assume is buy it but i'll let you speak to that yeah well so i'm a big believer that any project needs to be like sustainable um so even though like state of JS is not something I'm necessarily doing to get rich or anything like that, I do want to always experiment on ways to monetize it, as long as it's not intrusive. I'm never going to put ads that track you for unrelated products or anything like that. But if we can find partners or sponsors that also provide value by giving you access to resources or whatever,

that's something we've done in the past. And now this year, I had this idea to do a t-shirt. So actually, I did a t-shirt for State of JS last year as well. But I did it in partnership with the Dodge JS Conference in Paris, where I presented the results. So it was only available to people there. But the attendees really liked the shirt.

So this year, I decided to try again and this time make it available to everybody. And see, you know, if it turns out that that's a viable way to monetize the survey, that would be awesome because it means we can remain completely independent. A shirt is something that you can keep selling as time goes by. It's not a one-time thing. And then also what I wanted to do is make a shirt that actually teaches people something. So listeners can go check it out on the survey page. But it basically has our survey logo, which itself is built with CSS.

And then the shirt has annotations that tell you the CSS properties that were used to build the logo that's on the shirt. What's cool about this is it's not really self-branded even. It's on the line of, like you said, more educational and well-designed rather than simply saying, hey, state a CSS survey. It's more just like CSS agnostic in general. More CSS, focus on

CSS, but not on the survey agnostic. The survey is not part of the shirt. It's not a survey shirt because nobody wants to wear a survey shirt. So you're smart enough to make it about CSS, right? Which is timeless, interesting, and very well designed. As you'd expect from the stuff you put out, Sasha, the websites are always very well designed. This is no exception. So the shirt is very, very easy on the eyes. So yeah, definitely let us know how the results go with the t-shirt listeners out there. If you like these surveys, if you get benefit out of them,

and if you want a cool tee, definitely support this effort by getting out there and buying the state of CSS. So if this goes well, Sasha, this will be something that will be a JS t-shirt down the road. Maybe there'll be specific things. If you do different surveys, you might do a t-shirt per survey. Is that the idea?

Yeah, yeah, that would be awesome. So I don't know yet if it would be the same t-shirt per survey is that the idea yeah yeah that would be awesome so i don't know yet if it would be the same t-shirt every year or because you know coming up with a new design every year is gonna still a lot of work even if it's once per year usually we're already short on time and we're already trying to wrap everything up so i don't know but we'll see definitely one per survey would would be cool. So I'm curious, you seem to have this touchy-feely way about approaching the monetization of it. So you're concerned or you want it to be sustainable, but you want to approach the monetization of it in a way that respects, obviously, the community. What's your outlook on this front?

I don't know how much you can share about the financial behind the things, but just curious how sustainable it has been, how much money you've had to put in your personal, from your personal pocket, and has it simply been a labor of love, or has it been a labor of love and some profit? So when it makes some profit, I don't remember the exact figures,

but at least a couple thousand dollars last year, maybe, you know, four or five thousand. And that comes mostly from sponsorships and then affiliate links. So, you know, we have affiliate links to courses like West Bosses courses or a couple others. And well, it's not even a question of like ethics or anything. It's just I think most advertising doesn't work online. And the only reason it can work is when it provides actual value to the, you know, customer or user or reader or whatever, if it's just unrelated or I think so. I think what happened is the more the worse the ad, the more you have to add tracking and unwanted things to kind of make up for the ad not adding value. And so on the other hand, if the ad itself can have value, you don't need all this extra tracking stuff or unethical stuff.

I think you probably want to be more in the line of partnerships where there's a mutual benefit. The folks that would be or are willing to partner with you on the State of JS survey or the State of CSS survey, you want people who care about that community and want to partner with you and sustaining it, for one. But then they also get the representation of caring about the community. And that's part of what your design would illustrate is how do they care? You know, how are they relevant? Why should you care about X brand or whatever? Yeah, I think, you know, you get a very small amount of, goodwill from the community. And you don't want to waste it on, you know, making a bad impression with, you know, just random Google ads or like shady business practices,

especially if you're in it for the long run, which we are. So for us really, you know, even if we just don't monetize at all and we skip a year, it's fine because our main goal is just getting the survey out there and getting good data and establishing it as a brand. Maybe that's also the designer in me speaking. I really think the brand is the most important and and the profits are kind of secondary after that. So one other idea that you could do, and maybe this is just generating more work, so it's not great,

but what I think of is now that you have state of CSS and JS, and you have this process down, like you said, you may develop your own front end, every year you get a little bit better at it. You could go to specific organizations that have vested interests in specific communities that don't have surveys. So you could have State of Rust 2020, and it's not that there's advertisers, it's that maybe Mozilla funds

your entity to run the survey for them. And so it's brought to you by Mozilla just because Mozilla wants to know what the state of Rust is or maybe the state of Go. And it's brought to you by Google. It's not that they're advertising. It's just that they're the ones that are funding the effort and maybe those contracts could be large enough

that it actually makes the other ones where you could do without funding for those. Is that something you've considered or is that too far down the road or just too much work? I think I would love to do that. We both would love to do that. But I think practically speaking, a lot of the value I think we bring to the thing is the ability to get the data and know what to do with it and then publicize it. And if you come into a community where you don't have any ties or any expertise like Rust, I don't know anything about Rust, I'm not sure I would be able to replicate that. And then on the other hand, if I leave it all up to Mozilla to do that, then I'm not sure how much value we provide.

You know, we're kind of like, kind of like regular contractors at this point. We just make some React code. I think we would have to explore exactly where we come in, under what terms. Especially since you're putting in your own personal thoughts, conclusions, etc. A lot of this isn't simply just the data back. It's some insights. So there's some personal flair to it, so to speak, using TGIFriday's terms. So I got one last monetization idea before we move on.

So one thing that I think is new this time around is that there's actually, under the resources section, there is a podcasts question. And so I just want to point out that the changelog, despite not even being specifically about CSS or front end, is the number three most listened to podcast, right behind Syntax and Shop Talk, which are great shows. So we're in good company there. Sadly, JS Party is not on this list, so that means we have some work to do to get the word out.

So here's my monetization idea we give you money and then you put gs party at number one and then everybody's happy well i i was gonna say yes but now that you've talked about it publicly i can't really accept it touche yeah so i'll confess that the main reason why we have all these podcasts in there is so that people talk about us. So far it seems it's working, right? It's word of mouth. It's how it works. We'll never fall for that.

This episode is brought to you by our friends at Rollbar. Move fast and fix things like we do here at Changelog. Check them out at rollbar.com slash changelog. Resolve your errors in minutes and deploy with confidence. Catch your errors in your software before your users do. And if you're not using Rollbar yet or you haven't tried it yet, they want to give you $100 to donate to open source via Open Collective. And all you got to do is go to rollbar.com slash changelog,

sign up, integrate Rollbar into your app. And once you do that, they'll give you $100 to donate to Open Source. Once again, rollbar.com slash changelog. So let's look at some of the results of the State of CSS 2019 survey, what has come out of it and maybe talk about the findings, what we think about them, etc. The first one, Sasha, that we thought we'd bring up is under features, the layout. And the interesting thing here, first of all, you have an overview of the usage of layout tools. And this is an interestingly designed chart. It's kind of like a cell with different, almost like a Venn diagram, but there's no overlaps.

And we'll do a hard time explaining it audibly. So definitely check out the results for yourselves. But one thing that's interesting you have an outer circle and an inner circle and the outer circle is like how many people know about a feature and the inner one is how many actually use it which I thought was a very cool way of displaying and what's interesting you have grid and flexbox and they're both really big

there's a few other features, exclusions which I had personally never heard of writing modes and multi-column layout. But grid and Flexbox are the two big ones. And they're both large outer circles because everybody knows about them. But when it comes time to who's using what, Flexbox is in huge use and the grid is like 50% use. Was that interesting for you to find out? Yeah, so it's kind of what I expected because a grid is newer and it's maybe a little bit more complex to learn. So it makes sense that the adoption wouldn't be as high as Flexbox. And my personal story, at least, is that I had been using floats for years and I hated every

moment of it. And then when flex box came along, I kind of jumped on it right away because it saved me from ever having to like do float right. And then clear both or whatever overflow hidden clear fix. Oh, I'm getting PTSD just thinking about it. Me too. But then when grid came along,

I was more like, Oh, one more thing now I have to learn. And then it took me a long while to actually start using it. And now that I'm using it, I'm still not super comfortable, but I really love it. And it's actually probably better than Flexbox for most use cases. So I think that chart reflects that. And I really wonder what would have happened if Grid had came out first before Flexbox. I think Grid would have a much larger adoption for sure. Well, that begs the question then,

since you mentioned floats, floats isn't in the list. I'm sure there's people still out there using floats. Is it just not in the list because you assume it's not being used or because it's literally not being used by anybody? No, so it's not in the list because we assume it's not being used or because it's literally not being used by anybody no so it's not in the list because we assume everybody knows it and has used it or it might be still using it but we really wanted to focus on new uh features for the survey because otherwise you know we're not going to ask are you using a font size or are you using display block or there's no real point to that so So we consider that floats were in the same situation

where if you write CSS, I mean, that might not be true because you might have learned in the last couple of years, maybe you haven't used them, but otherwise it doesn't tell us much to know who is using floats. I think, unless, I guess you could argue that if there's like a downward trend

indicating that people are using them less and less, that would be interesting. That's what I look at. It's like the historical value of like knowing today. I mean, obviously this is 2019, so likely not many are using floats because it's older. Flexbox, as you mentioned, has been around. So even the old hats are probably transitioning, like you were pretty happy to be done with floats, and I'm sure anybody learning today is probably learning new states of things rather than older states of things. Yeah, it just comes down to having to make choices because otherwise we would have had too many questions, which we already had too many.

The survey was really long, but yeah, we removed some stuff and had to make some cuts moving on to animations and transforms this particularly stood out to me because of our desire as designers and potentially as users of the web or interfaces in general the the usage of animations or even subtle or very large animations to provide good feedback or whatever it might be to enhance the user experience. To me, that seems like a highly valued thing as a designer and as a user. And I was pleasantly surprised to see the transitions, transforms, and animations, as Jared mentioned before, the outer circle and inner circle, they're on all three of these they're very large so the kind of three primary ways you can provide a complex you know animated or motion-based

interface it seems that a lot of people are well aware and also using them very well which is super cool yeah definitely um i think it's cool like i think it's interesting that there's a small difference between transitions and animations. It took me a while before I started using animations. For a while, I was just doing transitions. Just to recap, transition is basically when there's a state change, like hovering, usually. And then animations can be more complex.

You can have keyframes, so it's not limited to just two states. It is more complex, which kind of shows up in the data. But to me, what I'm looking for in the feature section is really data points where there's a big delta between both circles. So like we were talking about grid. So in other words, many people have heard of something, but few are using it, because that means people are probably going to start learning it soon. So for me, those are kind of the up and coming technologies or features in this case. Or maybe they're like, hard to learn. So I feel those are the features where there's like a story behind it. When it's really almost overlapping, when almost everybody who knows about, let's say, transitions has used

them, kind of means that it's like a good solid feature. And there's not that much interesting stuff to say about that. I think it's interesting how you say probably going to start learning it because like in any environment, in being transparent with the data is very informative to provide a feedback loop to the community, both to see that grids are less used than Flexbox, that more people are aware of it, and likely about to start learning it, that's an indicator, and that's a good feedback loop. So let's talk units and selectors real quick, because I don't know, I kind of turned my nose up at first at this whole category.

I'm like, what's the value here? And now the more I stare at it, the more I start to think about it, I think there is value. And one thing that's worth pointing out is this is the first state of CSS. And Sasha, you mentioned that even on features, it'll be interesting to see trends over time. Like, well, maybe people are moving away from floats, for example. And it's not interesting right now, but it will be interesting in 2020, 2021. So it's worth noting that this is very much a snapshot just because it is the first one. But a lot of the really cool stuff that you can start to track is as this gets put out year by year trends in the industry.

And so when I'm looking at the units and selectors, I mean, how many people use PX versus M versus percentage in terms of sizing things? looking at the units and selectors i mean how many people use px versus m's versus percentage in terms of sizing things and at first i was like well of course everybody uses i mean because you can answer more than one like 99.5 percent of people use pics pixel or 96.9 percent use percent and i was like what what value does this provide But it seems like if you just want to check yourself, maybe you're just learning CSS or maybe you're wondering if you're doing it wrong and you come to something like this and you see,

maybe I feel like PX is the old school way and you're supposed to use M's or REM's or whatever. And I'm like, oh no, actually pretty much everybody's still using this. So I feel good about myself. Is that the idea with this whole section about units and pseudo elements and even selectors yeah i think so first of all i think a cool thing is just having a list of all these selectors and or units or whatever because all of, like even I have never heard of them. Like, I don't know what EX, but you can look it up. Maybe we can link those up to some documentation or something. But yeah, it's a lectures. There's lots of things that I learned just doing the survey. And then also because this was the first year, we weren't sure what we should ask. Like

we weren't sure which sections would turn out to be interesting. So some of this stuff, maybe we won't keep it for next year. Maybe we'll ask the questions differently or present the data differently. But this year, it's really just trying to collect as much as we can and see what people respond to and what they want more of. Another interesting aspect was the frameworks. Who doesn't love a framework, right? This is where the guns come out.

That's right. Okay, careful now, careful now. So it took us a little while at least to grok this. What was the term you used to describe this, Jerry? Was it... I call it a circuit board, but that was just because it looks kind of like one of those diagrams. I don't know exactly what this chart style is called. Is there a name for this style chart? Yeah, it's a bump chart.

So this bump chart, it's at the top, it's an overview, and then down beneath, so we're in the CSS framework section by the way, so if you're listening, follow along by doing that. You've got all the different frameworks mentioned, bootstrap, foundation, et cetera. What I find pretty interesting, it took me a little while to grok this, but you saw kind of left to right the kind of three attributes, awareness, interest, and satisfaction. So one, are you aware of it? Two, are you interested in it? And three, if you've used it, are you satisfied with it? And I think those are three good indicators of pretty much any technology, framework, whatever. What's interesting, though, is how you can sort of just look at the interest because that's the top.

It goes from top down in terms of interest, literally. But Tailwind being the most interested or having the most interest, but then you also see as a correlation, not many people aware. However, at the same time, just as many who are interested are also satisfied with it. So it would tell me that Adam Watham needs to get out there and market more or find more ways to do word of mouth because, hey, people are really liking this thing. They're interested in it. They're using it, but they're not very aware of it.

And I'm sure he's probably also aware that there's not many people aware of it. But yeah, but I think this is interesting to, you know, one, the folks behind each framework, but then two, the community of like, what's up and coming? You know, what should I be learning? What are people really satisfied with, you know, in terms of like top to bottom? And I think this really paints that picture very well. Yeah, so I should say that the chart may change a little bit

by the time listeners hear this. So we'll kind of improve it a bit to make it clearer. But yeah, I really like it as well. So we kind of arrived at this chart after many iterations. We were trying to kind of have this ranking of ratios. So it's not like absolute values, because Bootstrap obviously is going to have more people satisfied than Tailwind, just because more people have used it,

the community is much much larger. But then if you look at the ratio of satisfied versus non-satisfied, then you can actually compare them and then Tailwind takes the lead. And also, even though these charts are typically used more to show chronological data, so years, months, whatever, here it's kind of a snapshot in time, but at the same time it kind of corresponds to three stages of adoption. So first you become aware of a technology, then you are interested in learning it, then you actually use it, and you can be satisfied or not. So it's not chronological data in the sense that

it's all corresponding to a single point in time, but there is this aspect of an evolution for a single technology. Yeah, it's a very interesting chart because it starts off super confusing, and we even had to talk about it. We're like, what is this even trying to say to us? And then once you figure out, okay, this is how it's working, then when you look at it, it almost seems intuitive afterwards. You're like, okay, this makes a lot of sense.

So I can look down here and see that tachyons is near the bottom of awareness, but the interest is kind of in the middle, and then the satisfaction is top five. So it's very highly satisfying to those people who are using it. It's got a decent amount of interest. People want to learn about it, but of the whole, it doesn't have much of an awareness. So other people who are aware of it, they do want to try it out.

Yeah, it's a very interesting chart. Yeah, we always try to include a few like puzzle charts in a way where it's not obvious right away how to read them or what they're saying, but then you can kind of decode them and then it becomes very easy to read. So I think maybe the overall technologies chart is a little bit like that as well. And we have the scatterplot, the quadrants chart. So there's a few, or it's not just, you know, not just bars or whatever. It's kind of a little bit of upfront work, but then it's rewarding because you get it.

You definitely need an explainer for how to read the chart. Unless you're, you know, a chart master. And in such case, you know, you know exactly how it works. For me, it took me about five minutes. So I'm not a chart master, and in such case, you know exactly how it works. For me, it took me about five minutes, so I'm not a chart master. Admittedly. And Adam had to describe it to me, so I'm even lower on the rung there. Before we move on, I just want to point out my favorite framework, semantic UI, is struggling a little bit. Fourth highest in awareness, so pretty highly aware. Very much interest, second interest, but then the satisfaction is down.

It's down more towards the middle of the pack. At this point, unfortunately, it's deserved because semantic UI has been falling behind in terms of maintenance. It's just the pure weight of the number of issues and people using it have really bogged it down. And we've had Jack on the show a couple of times trying to talk about that. I've even reached out to him and said,

what can we do about semantic UI and helping you out? And it just seems like it's one of these things that's a victim of its own success, perhaps. So sometimes that's the way things go. Yeah, I think you can look at bootstrap as well, which is number one in awareness, but last in interest. Yeah. Kind of makes sense, but then also pretty low in satisfaction.

Right. So, yeah, sometimes just being the number one in terms of sheer size doesn't guarantee like a good ratio. Yeah, it can harm your satisfaction even because of someone. Exactly. And what's interesting too is if you rewind, like a good ratios in the other areas. Yeah, it can harm your satisfaction even because of so much. And what's interesting too is if you rewind, probably I'm guessing just seven years-ish, maybe five to eight years, somewhere in that range,

Bootstrap and Foundation were sort of the raid to the time because they were not two designers who would rather design their own thing. But for a lot of people, it's like, wow, I can launch them faster. And it's funny that these two correlate very well in terms of their satisfaction. Like Bootstrap is just one notch above Foundation. And roughly the same in terms of interest. So lots of people super aware of both Bootstrap and Foundation, which sort of parallel one another in terms of what they aim to achieve as a framework. But, you know,

the interest and satisfaction, you know, to me, this is, it's good that you can see that these two, not so much they're in the place they are, but you can see from anybody's point of view, what is something worth investing your time into? And potentially what people have found interest in are interest in and satisfaction in, but isn't that aware of so let's move on to methodologies these ways of writing your your css or architecting it bem smacks oo css atomic css etc seems like for the most part bem isEM is dominant, highest awareness, pretty high interest, highest satisfaction. 52% of respondents have used it before versus the next following up, which is Atomic CSS, which is at 20% have used that architecture. Did this surprise you or was this as a CSS guru, Sasha, are you at all surprised by these results,

or is it pretty much what you would expect? I feel I'm going to get in trouble if I call myself a CSS guru. Oh, I called you that. You didn't call yourself that. Okay. Yeah, no, it kind of matches what I expected. Like BAM, I feel it kind of benefits from being really clear and the concept at least is really simple.

The other methodologies, I feel it's kind of a bit muddier what exactly they involve. I'm curious about itCSS or itCSS. I hadn't really heard of it, but looking it up, it kind of looks interesting and it has a good satisfaction rating as well. But I think methodologies, you know, we wanted to have them because it's something that's kind of unique to CSS.

You know, JavaScript doesn't, you know, you can have functional programming or object-oriented, but it's not codified like CSS. So I think it's interesting that CSS does have these. But at the same time, I don't think most developers are that rigid about observing a methodology. Even myself, I use BAM, but in a very flexible way where as soon as it's too much work, I just stop using it and just write random classes. So I suspect a lot of people do the same it's interesting to see that SMAX was sort of the leader of this sort of methodology

instead of frameworking how to write or rules for writing CSS being sort of flatlined in terms of awareness, interest and satisfaction and BIM being the highest in awareness and satisfaction but just one dip down in terms of interest. But, you know, hey, that's how it works out. Yeah, I think, you know, honestly, I think CSS, it had a lot of holes, like a lot of things that were missing,

and that's why the methodology is developed as a way to kind of fill out the language. But then the more stuff we have, CSS Grid, Flexbox, the less we need those methodologies. And in some cases, it doesn't make a difference. Like having good classes is always a good idea. But I think the more we can do in the language itself,

it's also with preprocessors like SAS and stuff like PostCSS. So I do think the more you leverage these tools, the saner your code looks and the less you need the methodologies. And CSS can become more like another programming language like JavaScript where you can have your own style, but everything kind of makes sense

because the language is powerful enough. Let's open up the can of worms then. Probably the most highly debated, not really sure how to describe it, but the CSS in JavaScript argument has been fought and won and lost and re-fought again. There's a lot of opinions here. What are we learning from what you've gathered in the survey? Style components are number one in terms of awareness. Second, interest. Third, satisfaction. Overall, pretty high. and number one in terms of awareness, second interest, third satisfaction,

overall, you know, pretty high. The one that's really interesting to me is emotion, low awareness, pretty high interest, and number one in terms of satisfaction. So anytime, you know, the number one satisfaction ratio has low awareness, it kind of indicates like an up-and-coming technology, where few people know about it, but the ones who use it are very happy with them and might become like evangelists for that technology. So that's the kind of thing I like to keep my eye on.

And I've used, of all these, I've only used styled components. And actually for state of CSS, we just use SAS. So we don't use CSS and JS at all. Not for any particular reason, more like we haven't had time to kind of make the switch. Personally, I like the concept. I think the most valuable thing, I think I say that in the introduction to that section, is that the more new ideas we have, and the more new ideas we have and the more new people we have writing CSS or CSS and JS the better overall because you know I'm not an expert but I'm sure if it hasn't happened already some ideas from CSS and JS will make their way into plain CSS as has happened with SAS and stuff like

variables or maybe nesting at some point and And you don't have to use those if you want to, but I think having a more powerful language, especially for CSS, which started off as pretty limited, I think it's probably a good thing on the whole. Whether you like CSNJS or not, whether you use it or not, I think overall it's probably a good thing for CSS itself. Yeah. That's how I saw pre-processors, post-processors. When Compass and Sass had come along, it was the first time I'd seen the idea of a programming language like Ruby in the

case. Now it's since moved on from Ruby, I believe, to other languages to do the stuff. The pre-processing stuff. Yeah, exactly. You know, you got these higher order, you know, not limited to simply using CSS itself to produce a CSS file. At the time, this is many years ago, I'd blown my mind. And I was like, this is anarchy. This is crazy.

This cannot happen. Then I was like, no, this is amazing. As I looked into it further. And I see the same thing happening here with CSS and JS, is that what you're going to see is the language get pushed forward. And in a lot of ways, CSS itself is the language it is today and has some of the features it has because of the pre- and post-processors.

And I would assume that similar things would happen by pushing it in the way that CSS and JavaScript will push it. Yeah, and maybe CSS and JS might be a trend for a couple of years and then CSS will catch up and start using CSS and JS less and less. And I think that might happen with Sass actually because we think like grid, which lets you not use breakpoints, which means you don't need mixins as much with variables, with, you know, calc, all these things are kind of eating up like the things that Sass was so good at. So it's really

interesting to me to see how, yeah, CSS is kind of making all these other tools obsolete by by just evolving in the right direction so let's just hit a couple of real quick ones in the other tools and environments and then i want to move on to opinions but uh text editors vs code uh 73.8 percent of respondents using vs code sublime 35 sorry to the Vim party chat room in our Slack, only 18% of people responding to this particular survey are using Vim for development. Browsers, we have Chrome dominant, 92.2% of people are using that browser,

specifically during initial development in the Firefox with 53 not seeing brave anywhere on the list i must have not taken the the survey because i'm a brave user even during development environments um chrome during oh is this the same one browsers which browsers to develop yeah so that that's a mistake on the version you're seeing. This is actually which browsers do you test in. Right. Not so much the one you're most at home in, but the one you make sure everything works. Gotcha.

So yeah, much more people doing other browsers. That's a good thing, right? So we have people testing in browsers that they're not using on a daily. So much more representative. Safari Edge, Safari iOS, IE, Chrome, Android etc. Which form factors do developers test on? Pretty much everybody tests on desktop

99.7% that's only a few hundred people are not even using a desktop at all to test which, what's wrong with you folks? You've got to test it on desktop 91.6% so it drops off a little bit for smartphones but still pretty good penetration in terms of testing on phones tablets 70% and so on

you can read those results for yourselves let's get to this opinion section I thought this was cool so we'll close with this one here I guess and maybe have you state some of your conclusions Sasha as we tail off the call but this is a section which is basically like, you answer, do you agree with this?

Do you strongly agree? Kind of a sliding scale. Do you strongly disagree? And it has a bunch of statements about CSS. And so I thought this was a very cool section of the survey. The learning curve for CSS. So the statement is CSS is easy to learn. And pretty high agreement so 35 percent agree and then 20 another 25 percent rounding strongly agree pretty much nobody or by nobody i mean 340 people strongly disagree with that

statement so css still even though it's evolved and added a bunch of stuff and people get caught up with how to select your precedents and all that stuff there are things but overall it seems like people are thinking it's easy to learn speaking of evolvement css is evolving too slowly this is one that i thought i would see more agreement on but most people are pretty much neutral on this did this surprise you s, or does this reflect what you think about the evolving pace of CSS? Yeah, I also thought the agreement would be higher. Maybe that's because I've been using CSS for a long time and I'm still kind of used to this glacial pace of change. Well, maybe I shouldn't say that. But for a while, we didn't have as obvious as...

The improvements weren't as visible, maybe. That's it. I know a lot of work was going on behind the scenes, on browsers and stuff. But I think especially compared to the last couple of years with Flexbox Grid, the pace has really picked up. So I think if you've started you know, started using CSS in those years, you probably feel like it's evolving just fine. If you're more used to, you know, 10

years ago, or whatever, maybe you agree with that statement more. The question that I also enjoyed CSS is a programming language. This is one that the folks like to argue about on Reddit and whatnot. But most people strongly disagree, 31%. And then another 18% disagree, 23% neutral. So most people are either neutral on this or disagree or strongly disagree that CSS is a programming language. What's your take on that one? I don't know.

I think it probably all depends on your definition of programming language. What's your take on that one? I don't know. I think it probably all depends on your definition of programming language. But I would say yes, just because I don't know what else it is. What else is it? Well, it's basic definition. It is, you know, you are programming a machine to do something and it is a language.

So at its basic core, it is a programming language. Are you programming the machine though? Well, you're programming, I suppose. I mean, it depends. Yeah, there's some really interesting things you could do with CSS. But you're declaring. Well, yeah, that's where the debate is.

Right. And they're in the debate. So I would agree with that, that there's a debate. It's obvious. So we have 100% agreement that there's a debate about whether or not it's a so we have a hundred percent agreement that there's a debate about whether or not it's a programming well that brings me to my point here is that the statement is css is a programming language right i always find it kind of hard because it's like is it agreeing or not agreeing when you say strongly disagree because it's like you disagree with the statement right

exactly but it's hard to grok it you have to sort of like process it one or at least me i have to process a couple times to be like, are they agreeing or disagreeing that it is or it isn't? And then I have to like, okay, good, good. So most of the people disagree that it is a programming language. That's the point we're making here. 30.95% if the numbers are the same.

That's strong disagreement. So add in the disagree, and you got almost 60%. 30 plus 18. Yeah, that's 47. Yeah, roughly 50% either agree or strongly disagree or disagree. Well, whether or not it's a programming language, that's just kind of a fun meta debate.

But let's finish on this one. Enjoyment. I enjoy writing CSS. Now we're not going to have much controversy here because these are people who like CSS because they're taking the CSSss survey to a certain degree and of 48.67 strongly agree 27 agree 14 neutral 6 roughly disagree and then only 442 respondents strongly disagree that they enjoy writing css so despite all of its what do you call that glacial uh evolve involvement and uh glacial change and the debates about it being a programming language and

the the tooling and the where to put it do i put it in its own file do i put it in my in my javascript for the most part people do enjoy writing it so that's a good thing well okay let me just say a disclaimer that i think the pace of change is much faster now and also i think uh you know because a lot of people from like the css uh uh writing group like the css development group helped us plus you're a css guru now so your your opinion really matters now yes guru i have uh official business cards you can put that on your linkedin but uh yeah so one thing i learned actually by working with the working group people some of them is that css like does so much more than what we typically think let's say that you need to display your website on a smartwatch, and that smartwatch has a round face,

so there's people who are tasked to figure out how CSS works on circular screens, or fridges, or really all kinds of devices, all kinds of environments. And yeah, it's a really tough job, especially when you see how wellss works at the end of the day across browser across devices there's really nothing else like it there's no other way of styling visually styling your content like anywhere like it's like kind of unique and the fact that at the same time it's still kind of easy to learn and enjoyable to write i think it really says a lot about the quality of the work of the css people

so um that i mean i i've always had my you know annoyances about css but at the end of the day i think it's important to really value uh the work that's gone into it. Yeah, I think that there's times when we've brought CSS up on this show in particular with designers coming on the show sharing, I'm thinking in particular the most recent one, which was like design thoughts for developers. I can't recall the title. Jeremy, you can help me out with that one. But there's always this, if you bring up CSS, there's always sort of like this cringe, but there is still some enjoyment in writing it.

It's just very hard. It's a hard language, in my opinion, to really master. It takes a lot to really master it. And even when you think you've mastered it, you have just begun to scratch the surface of mastery. And unless you're Eric Meyer or somebody like that, then of course, or whoever wrote the book, CSS Mastery, right? They're the masters.

That's how you master it. That's right. That's right. I want to mention, too, we would have covered awards here in this call because that's something we love to give praise to, either for the frameworks out there or those leading the way. However, those details are not finalized just yet, so we couldn't quite cover those. But one thing you do say, if this is accurate in the current state of CSS website, is if we had to pick a theme for this year, CSS or JavaScript, then I would encourage you to get to know Sasha better or subscribe to the email list, whatever it takes to put your perspective into this story. Because without your perspective, we don't really have a quality feedback loop. So it's important to have everybody's voice. And more importantly, it's important to have

a wide spectrum of opinions on what's being used out there. It's going to inform the larger users of CSS. It's going to inform the larger perspective and future of CSS and future technologies to enjoy even more so this sometimes love-hated language, at least from my opinion. So Sasha, any closing thoughts from you? I mean, since you have a conclusion here and you've done so much work behind this, you

and Rafael have put so much effort into this and we appreciate that. Is there anything you want to close with or share with the audience before we say goodbye? Well, I just want to thank you guys for having me on. And yeah, basically, I hope people will find this valuable and will enjoy it. It was a lot of fun to build. And we always have fun with the design. And it's always interesting for us to look at the data. And I really hope that this can become just like the state of JS, like a yearly thing. And we can see how the trends evolve over time. And what I would really like to do even more is just keep expanding this to

different domains, so JavaScript, CSS, maybe React, GraphQL. There's a lot we can do before we can run out of things, even that we use ourselves, like Node, Gatsby. There's so many things. And so, yeah, who knows? Maybe next year we'll have even more surveys to talk about. I don't know at which point I'll start losing my sanity. I don't know how many surveys I can run at the same time, but I definitely want to try. Well, worst case scenario, you have more clothes.

If there's a t-shirt for every survey and every year, then hey, that's an easy way to outfit your closet. Oh yeah, so I need at least seven surveys so I have one t-shirt for every day of the week. You're a minimalist, that's good. I want to remind folks, stateofcss.com and stateofjs.com are the two places you can go to sort of catch up on past results and just play your part. And right now the survey is over for State of CSS. So you don't have to come back next year if there's an extra course. But those are two places you can go. And from there, there's lots of links out to Twitter, out to Facebook, out to the email list.

Sasha, thank you so much for joining us today. It was awesome to get a behind-the-scenes look at the survey and all the things you're up to. The details behind things like this are really interesting to us. So thank you for your time. Yeah, thanks. All right, thank you for tuning in to this episode of The Change Log. Hey, guess what?

We have discussions on every single episode now. So head to changelog.com and discuss this episode and if you want to help us grow this show reach more listeners and influence more developers do us a favor and give us a rating or review in itunes or apple podcasts if you use overcast give us a star if you tweet tweet a link if you make lists of your favorite podcast include us in it and of course thank you to our sponsors linode go cd and rollbar also thanks to fastly our bandwidth partner rollbar our monitoring service and linode our cloud server of choice this episode is hosted by myself adam stachowiak and jared santo and our music is done by Breakmaster Cylinder. If you want to hear more

episodes like this, subscribe to our master feed at changelog.com slash master, or go into your podcast app and search for changelog master. You'll find it. Thank you for tuning in this week. We'll see you again soon. Bye.