Tag: 2020

State of JavaScript 2020

We rounded up a bunch of published 2020 annual reports right before the year ended and compiled them into a big ol’ list. The end of the list called out a couple of in-progress surveys, one of which was the 2020 State of JavaScript. Well, the results are in and available to check out!

Just shy of 24,000 folks participated in this year’s survey… almost exactly 2,000 more than 2019.

I love charts like this:

Notice how quickly some technologies take off then start to gain negative opinions, even as the rate of adoption increases.

What I like about this particular survey (and the State of CSS) is how the data is readily available to export in addition to all the great and telling charts. That opens up the possibility of creating your own reports and gleaning your own insights. But here’s what I’ve found interesting in the short time I’ve spent looking at it:

  • React’s facing negative opinions. It’s not so much that everybody’s fleeing from it, but the “shiny” factor may be waning (coming in at 88% satisfaction versus a 93% peak in 2017). Is that because it suffers from the same frustration that devs expressed with a lack of documentation in other surveys? I don’t know, but the fact that we see both growth and a sway toward negative opinions is interesting enough that I’ll want to see where it goes in 2021.
  • Awwwww, Gulp, what happened?! Wow, what a change in perception. Its usage has dipped a bit, but the impression of it is now solidly in “negative opinions” territory. I still use it personally on a number of projects and it does exactly what I need, but I get that there are better build processes these days that don’t require writing a bunch of pipes and whatnot.
  • Hello, Svelte. It’s the most fourth most used framework (15%) but enjoys the highest level of satisfaction (89%). I’m already interested in giving it a go, but this makes me want to dive into it even more — which is consistent with the fact that it also garners the most interest of all frameworks (68%).
  • Javascript is sorta overused and sorta overly complex. Well, according to the polls. It’s just so interesting that the distribution between the opinions is almost perfectly even. At the same time, the vast majority of folks (80.6%) believe JavaScript is heading in the right direction.

Direct Link to ArticlePermalink

The post State of JavaScript 2020 appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, ,

CSS Snapshot 2020

I think it’s great that the CSS Working Group does these. It’s like planting a flag in the ground saying this is what CSS looks like at this specific point in time. They do specifically say it’s not for us CSS authors though…

This document collects together into one definition all the specs that together form the current state of Cascading Style Sheets (CSS) as of 2020. The primary audience is CSS implementers, not CSS authors, as this definition includes modules by specification stability, not Web browser adoption rate.

Remember “CSS3”? That was the closest thing we had to a “snapshot” that was designed for CSS authors (and learners). Because CSS3 was so wildly successful, we saw a short round of enthusiasm for CSS4, me included. There is zero marketing panache on that snapshot page, which is exactly what CSS4 would need to succeed. Remember, HTML5 and friends (including CSS3) even had fancy logos!

If someone were to say to me “Chris, when CSS3 came around, I boned up on all that, but I haven’t kept up with CSS since, what should I learn?” I’d say “That’s a damn fine question, developer that has a normal healthy relationship with technology.” But honestly, I might struggle to answer cohesively.

I’d say: Uhm, CSS grid for sure. Custom properties. Clipping and Offset paths I suppose. prefers-reduced-motion. I dunno. There are probably like 100 things, but there is no great single reference point to see them all together.

I’ll work on putting a list together. I don’t think I’ll have the gumption to call it CSS4, but at least I’ll be able to answer that question. Feel free to suggest ideas in the comments.

The post CSS Snapshot 2020 appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.



Thank You (2020 Edition)

Heck of a year, eh? Like we do ever year, I’d like to give you a huge thanks for reading CSS-Tricks, and recap the year. More downs than ups, all told. Here at CSS-Tricks, it was more of a wash. Allow me to me share some numbers, milestones, and thoughts with you about our journey of 2020.

Let’s do the basic numbers

The site saw 94m pageviews this year. Last year we lost a smidge of pageviews (from 91m to 90m), so it’s nice to see that number go back up again, setting a new high record. Now I don’t have to tell myself stories like “jeez usage of browser extensions that block Google Analytics must be up.” Hitting 100m pageviews will be a nice milestone some future year. This number, long term, climbs very slowly. It’s a good reminder to me how much time, money, and energy are required to just maintain the traffic to a content site, let alone attempt to drive growth.

I have Cloudflare in front of the site this year. I think that’s a good idea generally, but especially now that they have specific technology to make it extra good. I’m a fan of pushing as much to the edge as we can, and now it’s not only static assets that are CDN-served but the content as well.

I mention that because now I have access to Cloudflare analytics, so I can compare across tools. I can’t see a whole year of data on Cloudflare, but comparing last month’s unique visitors between the two services, I see 6,847,979 unique visitors on Cloudflare compared to 6,125,272 sessions (or 7,449,921 unique page views — I’m not sure which is directly comparable) on Google Analytics. They seem pretty close. Closer than I thought they would be, since Google Analytics requires client-side JavaScript and Cloudflare analytics are, presumably, gathered at the DNS level, and thus not blockable like client-side JavaScript. I’ve turned off the WordPress-powered analytics for now, as having three places for analytics seemed a bit much, although I might flip them back on because, without them, I can’t see top on-site search results, which I definitely like to have.

Traffic that comes from organic¹ search was 77.7% this year, versus 80.6% last year. A 3% swing feels pretty large, yet almost entirely accounted for by a 3% swing from 9% to 12% in “direct” traffic. I have no idea what to make of that, but I suppose I don’t mind a better diversification in sources.

I find these end-of-year looks at the numbers sorta fun, but I’m generally not a big analytics guy. Last year I wrote:

There is a bunch of numbers I just don’t feel like looking at this year. We’ve traditionally done stuff like what countries people are from, what browsers they use (Chrome-dominant), mobile usage (weirdly low), and things like that. This year, I just don’t care. This is a website. It’s for everyone in the world that cares to read it, in whatever country they are in and whatever browser they want to.

I feel even more apathetic toward generalized analytics numbers this year. I think analytics are awesome when you have a question in mind you want an answer to, where the numbers help find that answer. Or for numbers that are obviously important and impactful to your site that you determined for yourself. Just poking around at numbers can fool you into thinking you’re gathering important insights and making considered decisions when you’re kinda just picking your nose.

One question that does interest me is what the most popular content is by traffic (we’ll get to that in a bit). Looking at the most popular content (by actual traffic) gives me a sense of what brings people here. Bringing traffic to the site is a goal. While we don’t generally sell sponsorship/advertising based on page views directly, those numbers matter to sponsors and fairly correlate directly to what we can charge.

Another bit of data I care about is what people search for that bring them to the site. Here’s how that breaks down:

  • Top 10: Various combinations of terms that have to do with flexbox and grid layout
  • Mixed into the top 20: Various alterations of the site’s name

From there, 10-100 are “random specific CSS things.” Beyond 100 is where SVG, JavaScript, design stuff, and CSS are sprinkled into the mix. The 251st ranked search term is the first time React shows up. The insight here is that: (1) our layout guides continue to do very well, (2) a lot of people like to get to the site first, then find what they need, and (3) searches for library-specific content isn’t a particularly common way to land here.

Top posts of the year

Thanks to Jacob, we can look at analytics data based on the year the content was written (and a few other bits of metadata).

Here’s an interesting thing. In 2019, articles written in 2019 generated about 6.3m page views. Those same articles, in 2020, generated 7.3m page views. Neat, huh? The articles drove more traffic as they aged.

Articles written in 2020 generated 12m pageviews. Here’s the top 10:

  1. CSS-Only Carousel
  2. Fluid Width Video (cheat, as this was written a few years ago as a stand-alone page, and I only moved it to the blog in 2020)
  3. How to Create an Animated Countdown Timer With HTML, CSS and JavaScript
  4. A Complete Guide to Links and Buttons
  5. The Hooks of React Router
  6. A Complete Guide to Dark Mode on the Web
  7. Neumorphism and CSS
  8. A Complete Guide to Data Attributes
  9. Why JavaScript is Eating HTML
  10. Front-End Challenges

Interesting backstory on that list. I dug into Google Analytics and created that Top 10 list based on the data it was showing me in a custom report, which Jacob taught me to do. Serendipitously, Jacob emailed me right after that to show me the Top 10 that he calculated, and it was slightly different than mine. Then I went back and re-ran my custom report, and it was slightly different than both the others. Weird! Jacob knew why. When you’re looking at a huge dataset like this in Google Analytics, they will only sample the data used for the report. It will show you a “yellow badge” and tell you what percentage of the data the report is based on. 500,000 sessions is the max, which is only 0.7% of what we needed to look at. That’s low enough that it accounted for the different lists. Jacob had already done some exporting and jiggering of the data to account for that, so the above list is what’s accurate to 100% of all sessions.

The top articles on the entire site from any year:

  1. The Complete Guide to Flexbox
  2. The Complete Guide to Grid
  3. Using SVG
  4. Perfect Full Page Background Images
  5. The Shapes of CSS
  6. Media Queries for Standard Devices
  7. Change Color of SVG on Hover
  8. CSS Triangle
  9. How to Scale SVG
  10. Using @font-face

Nothing from the Almanac made the top 10, but interestingly, right after that, the next 20 are so are heavily sprinkled with random articles from there. All told, the Almanac is about 14.8% of all traffic.

Two other things that I think are very cool that we did with content is:

  1. Published Jay Hoffman’s series on Web History, which include audio adaptations from Jeremy Keith that are served as a podcast.
  2. Published our end-of-year series like we did last year.

One of the many reasons I love being on WordPress is how easy it is to spin up series like these. All we did was toss up a category-specific template file and slapped on a little custom CSS. That gives the posts a cool landing page all to themselves, but are still part of the rest of the “flow” of the site (RSS, search, tags, etc.).


Perhaps the slight increase in traffic was COVID-related? With more people turning to coding as a good option for working from home, maybe there are more people searching for coding help. Who knows.

What we definitely found was that nearly every sponsor we work with, understandably, tightened their belt. Add in advertising plans with us that were reduced or canceled and, as a rough estimate, I’d say we’re down 25% in sponsorship revenue. That would be pretty devastating except for the fact that we try not to keep too many eggs in one basket.

Feels like a good time to mention that if your company is doing well and could benefit from reaching people who build websites, let’s talk sponsorship.

I’m trying to diversify revenue somewhat, even on this site alone. For example…


We’ve been using WooCommerce here to sell a couple of things.

Posters, mainly. A literal physical bit of printed paper sent through the post to you. The posters are unique designs made from the incredible illustrations that Lynn Fisher created for the flexbox and grid guides. We essentially “drop ship” them, meaning they are printed and shipped on-demand by another company. So, you buy them from this site, but another company takes it from there and does all the rest of it. That’s appealing because the amount of work is so low, but there are two major downsides: (1) Customer support for the orders becomes our problem and I’d say ~20% of orders need some kind of support, and (2) the profit margin is fairly slim compared to what it would be if we took on more of the work ourselves.

We also sell MVP Supporter memberships, which are great in that they don’t require much ongoing work. The trick there is just making sure it is valuable enough for people to buy, which we’ll have to work more on over time. For now, you basically get a book, video downloads, and no ads.

Loose math, eCommerce made up 5% of the lost revenue. Long way to go there, but it’s probably worth the journey as my guess is that this kind of revenue is less volatile.

I’m also still optimistic about Web Monetization in the long-term (here’s the last post I wrote on it). But right now, it is not a solution that makes for a significant new revenue stream. Optimistically, it’s something like 0.05% of revenue.

Social media

As far a website traffic driver goes, social media isn’t particularly huge at 2.2% of all traffic (down from 2.3% last year). That’s about where it always is, whether or not we put much effort into it over the course of a year, which is exactly why I try not to spend energy there. What little effort we do expend, 95% of it is toward Twitter. We lean on Jetpack’s social automation features, mostly. It is still cool to have @css as a handle, and we are closing in on half a million followers. You’d think that would be worth something. We’ll have to figure that out someday.

When we hand-write Tweets (rare), those are still the ones with the most potential. I only do that when it feels like something fun to do, because even though they can get the most engagement, the time/value thing still just doesn’t make it worthwhile.

Example hand-written tweet

Most of our tweets are just auto-generated when a new post is published. And we’ve been doing that for so long, I think that’s what the Twitter followers largely expect anyway, and that’s fine. We do have the ability to customize the Tweet before it goes out, which we try to, but usually don’t.

Example Auto-Generated Tweet

The other 5% of effort is Instagram just because it’s kinda fun. I don’t even wanna think about trying to extract direct value from Instagram. Maybe if we had a lot more products for direct sale it would make sense. But for now, just random tips and stuff to hold an audience.

Example Instagram Post


I did 22 screencasts this year. That’s a lot compared to the last many years! I’m not sure if I’ll be as ambitious in 2021, but I suspect I might be, because my setup at my desk is getting pretty good for doing them and my editing skills are slowly improving. I enjoy doing them, and it’s an occasional income stream (my favorite being pairing up with someone from a company and digging into their technology together). Plus, we got that cool new intro for our videos done by dina Amin.

The screencasts are published on the site and to iTunes as a videocast, but the primary place people watch is YouTube. I guess we could consider YouTube “social media” but I find that screencasts are more like “real content” in a way that I don’t with other social media. They are certainly much more time-consuming to produce and I hope more evergreen than a one-off tweet or something.


We hit 81,765 subscribers to the newsletter. On one hand, that’s a respectable number. On the other, it’s far too low considering how gosh darn good it is! I was hoping we’d hit 100k this year, but I didn’t actually do all that much to encourage signups, so that’s on me. I don’t think we missed a single week, so that’s a win, and considering we were at 65,000 last year, that’s still pretty good growth.


Y’all left 4,322 comments on the site this year. That’s down a touch from 4,710, but still decent averaging almost 12 a day.

I rollercoaster emotionally about comments. One day thinking they are too much trouble, requiring too much moderation and time to filter the junk. The vitriol can be so intense (on a site about code, wow) that some days I just wanna turn them off. Other times, I’m glad for the extra insight and corrections. Not to mention, hey, that’s content and content is good. We’ve never not had comments, so, hey, let’s keep ’em for now.

I absolutely always encourage your helpful, insightful, and kind comments, and promise to never publish rude or wrong comments (my call).

The forums completely shut down this year (into “read only” mode), so commenting activity from that didn’t exactly make its way over to the blog area. Closing the forums still feels… weird. I liked having a place to send (especially beginners) to ask questions. But, we just do not have the resources (or business model) to support safe and active forums. So closed they will remain, for now.

Goal review

  • 100k on email list. Fail on that one. That was kind of a moonshot anyway, and we never executed any sort of plan to help get there. For example, we could encourage it on social media more. We could attempt to buy ads elsewhere with a call to action to sign up. We could offer incentives to new subscribers somehow. We might do those things, or we might not. I don’t feel strongly enough right now to make it a goal for next year.
  • Two guides. We crushed this one. We published 9 guides. I consider this stuff our most valuable content. While I don’t want to only do this kind of content (because I think it’s fun to think of CSS-Tricks as a daily newspaper-style site as well), I want to put most of our effort here.
  • Have an obvious focus on how-to referential technical content. I think we did pretty good here. Having this in mind all the time both for ourselves and for guest posts meant making sure we were showcasing how to use tech and less focus on things like guest editorials which are, unfortunately, our least useful content. I’d like to be even stricter on this going forward. We’re so far along in our journey on this site. The expectation people have is that this site has answers for their technical front-end questions, so there is no reason not to lean entirely into that.
  • Get on Gutenberg. We also crushed it here. I think in the first month of the year I had us using Gutenberg on new content, and within a few months after that, we had Gutenberg enabled for all posts. It was work! And we still have a long way to go, as most posts on the site haven’t been “converted” into blocks, which is still not a brainless task. But, I consider it a fantastic success. I think Gutenberg is largely a damn pleasure to work with, making content authoring far more pleasurable, productive, and interesting.

New goals

  • Three guides. I know we did nine this year, but the goal was only two. I actually have ideas for three more, so I’ll make three the goal. Related side goal: I’d like to try to make mini-books out of some of these guides and either sell them individually or make it part of the MVP Supporter subscription.
  • Stay focused on how-to technical content around our strengths. Stuff like useful tips. Technical news with context. Advice on best-practices. I want to reign us in a bit more toward our strengths. HTML, CSS, and JavaScript stuff is high on that list of strengths, but not every framework, serverless technology, or build tool is. I’d like us to be more careful about not publishing things unless we can strongly vouch for it.
  • Complete all missing Almanac entries. There are a good 15-20 Almanac articles that could exist that don’t yet. Like we have place-items in there, but not place-content or place-self. Then there is esoteric stuff, like :current, :past, and :future time-dimensional pseudo-classes which, frankly, I don’t even really understand but are a thing. If you wanna help, please reach out.

Wrapping up

Thank you, again, for being a reader of this site. I hope these little peeks at our business somehow help yours. And I really hope 2021 is better than 2020, for all of us.


  1. I actually prefer my search grass-fed in addition to organic, but ok. ↩️

The post Thank You (2020 Edition) appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, ,

2020 Roundup of Web Research

It’s December! Lots of things are published this time of year, like developer advent calendars and organizations reflecting on the past year. We have even our own end-of-year series where we asked folks what they learned in 2020. But we also see lots of research come out around this time. Some of it we’ve already linked up. But let’s round up what we’ve seen so far.

2020 MDN Web Developer Needs Assessment

What it is: An annual, global survey that researches developer needs and how to address them. It surveys 30 stakeholders representing board member organizations including browser vendors, the W3C, and industry.

What it found: Chris Mills summarized the survey’s findings. This the second edition of the annual survey, and this year’s results show that the list of top developer needs hasn’t changed much year-over-year. Things like outdated documentation, cross-browser support, and keeping current with a constantly changing landscape headline the feedback. But it’s worth looking at the raw data because they’re so much of it!

HTTP Archive’s annual state of the web report

Source: HTTP Archive

What it is: A study that looks at 7.5 million websites and analyzes how they were made, breaking things up into sections including page content, user experience, content publishing and content distribution.

What it found: Robin summarized his highlights, which include CSS gaining more page weight, and that the average site contains three <style> elements as well as six remote stylesheets. That’s just the tip of the CSS iceberg though, because there’s a whole lot more data just on that, not to mention sections on JavaScript and markup.

State of CSS 2020

What it is: An annual look at CSS, surveying developers on the features they use, as well as their understanding of and satisfaction with them. Survey co-founder Sacha Greif rounded up his own findings last year, which was the first year of results.

What it found: Tailwind CSS is getting popular! calc() is in the mainstream! position: sticky; is being used more in layouts! Grid is being used roughly 20% more than last year! It’s way too easy and fun to geek out on this stuff.

GitHub’s 2020 State of the Octoverse

What it is: This is sort of GitHub’s internal review of activity, providing status on the number of users, repos, languages, and whatnot. But those numbers sort of reveal interesting things about our work-life balance, communities, and general activity.

What it found: It’s neat to see 60+ million new repos and 1.9 billion contributions in the past year, but the insights that arise from developer activities on GitHub are the most interesting thing in this report. For example, GitHub saw a huge spike in activity in February and March as the Covid pandemic became widespread, with developers putting in more time and working longer hours — possibly a sign that more side projects were born. They also reported a decrease in work activity on weekends, while seeing a rise in open source activity — again, possibly pointing to side projects.

What it is: A report that the search giant releases each year highlighting top search terms, breaking them down into categories, including News, People, Actors, Definitions, Recipes, and more.

What it found: Sure, this report isn’t directly related to front-end development, but it’s sort of nice to be in touch with the zeitgeist of such an odd year. The video that accompanies the report sorta views like a Google commercial, but it’s still a good look back at what people cared about most (or most often?) in the year — sorta like a high school yearbook.

Stack Overflow Developer Survey 2020

What it is: A survey of 65,000 developers that looks at the technologies they use and how they use them.

What it found: TypeScript surpassed Python as the second most beloved language after Rust. Roughly 90% of respondents say they visit Stack Overflow when they’re stuck on something (which seems right for a Stack Overflow survey). More than 15% of folks say Stack Overflow is more welcome this year compared to last year, which is an interesting metric. Lots more is in there, of course!

Angular Developer Survey 2020

What it is: A survey of 30,000 developers about they experience with the framework.

What it found: This report was interesting to me, not because I use Angular on lots of projects (I don’t), but because the folks who responded indicated better documentation as a top need, which seems to follow that HTTP Archive’s annual state of the web report.

JetBrains State of Developer Ecosystem 2020

What it is: A survey of nearly 20,000 developers by JetBrains, maker of the popular PhpStorm IDE.

What it found: They state the key findings up front. JavaScript is the most widely used programming language, Python is the most studied, and websites re the most common type of app that people are building.

The WebAIM Million 2020

What it is: An evaluation of the accessibility of the top 1 million and over 100,000 additional interior pages. What are those top million sites? The include ones from the Majestic Millions list with additional page analysis coming from the Open PageRank Initiative and Alexa Top Sites.

What it found: The report literally uses the word “dismal” to describe the results. And the report only analyzes detectable accessibility issues — there’s no qualitative assessment that would certainly reveal more insights. The study detected 60,909,278 errors, or roughly 60.9 errors per page. Yikes. Brushing up on the data and its findings is a good idea so we can all help improve that bleak picture.

CodinGame 2020 Developer Survey

What it is: A survey of 20,000 developers, covering learning, skills, languages, and demographics.

What it found: This report measures a lot of the same stuff as other surveys in this compilation, but it also has a “Work & Happiness” section that’s super interesting. For example, developers tend to be happier with their jobs if they have either a PhD or no formal education at all — all other forms of education fall flat after that. Also, developers in the U.K. (7.4), Canada (7.38), and the U.S. (7.33) report the highest levels of work satisfaction on a scale of 1 to 10. Developers who work in the manufacturing, aerospace, and finance sectors tends to be least happy.

LinkedIn 2020 Workplace Learning Report

What it is: A voluntary survey of 6,607 working professionals that evaluates their career priorities, challenges, and motivations.

What it found: Again, not exactly a web-focused study, but it found that folks rated “mobile coding and development,” “engineering and coding” and “cloud computing” as the lowest priority skills across all industries. The fact that LinkedIn Learning has a deep library of material and the ability to track the things people are watching and learning makes this feel pertinent. But maybe it’s nothing. Either way, those results gave me a little pause.

HackerRank Developer Skills Report

What it is: Insights on developer skills based on feedback from 116,648 developers — exactly what it says on the tin.

What it found: There’s some interesting stuff in here, like results on what coding language people first learned to write. But it’s the finding that “full-stack” developers are this year’s “most in-demand talent pool” that catches my eye. We talk a lot about what it means to be “full-stack” in this industry, and given the ongoing murkiness of the term, I’m just not sure what not means when 38% percent of hiring managers cited it as their top priority.

Microsoft IoT Signals Report

What it is: A study on the growth, evolvement and use of the Internet of Things, a term used to describe physical objects taking on Internet capabilities, say a watch, lightbulb, refrigerator, or whatever. The study polled about 3,000 people with a 20-minute online survey.

What it found: This report is kinda fun because it tracks the IoT customer lifecycle, from learning and trying to purchasing and using. This study found that 91% of companies are adopting are using and producing IoT products, compared to 85% in 2019. The report also sheds light on the emerging use of AI and Edge Computing, including some considerations and implications for using them.

Developer Economics Survey

What it is: You know, they seem to do lots of surveys — like two a year — then break those out into several individual reports. It looks like 30,000 developers participated recently and they glean insights about developer trends and tools.

What it found: To be honest, I didn’t look. You’ve gotta be a member of the community just to get in, and even then, it’s more of a push to take the survey than actually view the results. Whatever. Maybe the findings are awesome and you feel like going through the process.

UpWork’s Freelance Forward 2020

What it is: The very first survey by UpWork to check on the current state of freelancing, including the effect Covid has had on it, and what we might be able to expect in the future.

What it found: Out of 59 million freelancers (across all industries), 10% paused work as a result of the global pandemic, where 61% of those still freelancing have the amount of work they want or more. The report also concluded that freelancers are actually better equipped to weather the pandemic than non-freelancers. As a freelancer myself, this not only resonates with me personally but rings true with my own experience this year.

UXTools.co 2020 design tools survey

What it is: Taylor Palmer personally surveyed more than 4,000 designers to find out what sort of tools they’re this year to bridge the physical gaps left by the rise of working from home.

What it found: Some obvious things of course, like Zoom and Slack. But the report breaks things down into categories, showing the top tools for certain work. Like, whoa, Figma sure is a big player for everything from user flows to UI design. I knew it was big (and I use it myself) but I still figured other tools were bigger, especially for Mac. It pretty much dominated every category measured by this survey, even which tools designers are most excited to use or try.

Postman’s 2020 State of the API Report

What it is: A survey of 13,500 developers that measures who is developing with APIs, what sort of work they’re doing with them, and how APIs are evolving.

What it found: Basically, the state of API usage is super duper strong. I had a hunch that was the case without looking at the report and I’d bet my bologna sandwich that you did too. It also found that 70% of developers consider documentation to be one of the top four criteria for adopting a particular API, which goes back to MDN’s findings. Documentation is a big need!

Ionic Framework 2020 Developer Survey

What it is: Ionic polled it’s own customer base to get insights on how the developers who use the framework (1) actually use the framework, and (2) what sort of things are important to them and the way they work.

What it found: Well, it confirmed Angular’s own report that Angular grew year-over-year and is the most popular app framework — it’s interesting to see just how much it’s used compared to newer frameworks, like React and Vue, both of which saw near identical growth and usage according to this survey. It’s the newer things that get talked about most, right?

Mailchimp’s 2020 Annual Report

What it is: A look at the company’s stats for the year.

What it found: Well, this is all data related directly to Mailchimp and its customers. But still cool to see numbers like 33,635,013,935 emails sent by customers., and that $ 314,646,819 was generated from automated abandoned cart emails. Og, and 😍 was the most popular emoji used in email subject lines. Now you know.

Campaign Monitor’s Ultimate Email Marketing Benchmarks for 2020

Image credit: Campaign Monitor

What it is: Campaign Monitor’s updated benchmarks for email marketing, based on an analysis of 30 billion emails sent in 2019.

What it found: Tuesdays have the highest email open rates, but the highest unsubscribe rate as well. It also found that open rates declined across all industries (13.9% vs. 14.9%). In short, email benchmarks are largely the same.

Wrapping up

Phew, quite a list! But even so, there are many, many other reports out there. In fact, if you know of any not covered here, please leave a comment so we can link ’em up.

And there are more reports to come! You can actually participate in the 2020 State of JavaScript survey and the 2020 WordPress Annual Survey now, or at least at the time of this writing.

The post 2020 Roundup of Web Research appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, ,

2020 was not a good year for learning

There, I said it.

What did I learn about building websites in 2020? A lot. But what I learned is not nearly as important as how I learned it. So instead, I want to share a couple of strategies I used to unblock learning in less-than-ideal times.

I spent almost a decade teaching design and, let me tell you, the conditions for curiosity were all wrong this year. You are not alone if you’ve found yourself battling brain fog, deep existential crisis, and long spans of nothingness instead of basking in a creative renaissance. I spent most of this year in a tiny apartment under a terrifying lockdown in epicenter-of-the-pandemic New York with my husband, two cats, and a very energetic toddler. I’ll save the details for a therapist, but let’s just say this year did not go as planned.

But then again, whose year did? The entire world plunged into crisis. I only feel deep gratitude for having weathered this storm and for having cultivated the skills I needed for my little family to thrive despite the chaos. 

I spent years speaking at conferences about mental models and growing creativity. This year, I’ve had to focus on the other side of that coin: helping people recover their creativity when it feels out of reach. The first thing I usually recommend to anyone feeling creatively blocked is that they start actively wasting their time.

Waste your time

I had ambitious plans for 2020, having plotted out a rigorous study plan for myself. That plan is now in the garbage next to my travel plans and willingness to wear anything but yoga pants.

What I am capable of after a good night’s sleep, coffee in hand, is one thing. What I can manage after a sleepless night followed by a full day of Zoom meetings while simultaneously trying to wrangle a toddler is another thing entirely.

The loss of childcare meant that the only time to indulge in learning was after a long day of work after my daughter was tucked into bed, and I was completely exhausted. The last thing I wanted was disciplined study in pursuit of a goal, so I changed my approach: focus on breadth, widen the scope of topics, let my mind wander, and feed my curiosity. As a bonus, this shift often kept me from losing the evening to bingeing Netflix or doom-scrolling the news late into the night.

When you’re low on motivation or approaching burnout, create the opportunity to “waste time” and play. Follow what interests you, not just the things you “should” be interested in. Do not let your velocity or productivity enter the equation – respect that a life of learning is much more complex than that. Practice curiosity and protect your ability to play, it is critical to learning and creating. If you’re curious about why that is, look up inquiry-based or constructivist learning. What you’ll learn will have nothing to do with building websites, and that’s the point.


Many talented people felt their ability to create disappear this year, for a variety of reasons. I want to be clear — that’s a normal human reaction to all of this. There is no “one weird trick” for unblocking productivity when the world is on fire. But, if building websites brings you the joy and/or money you need, and you want some advice from someone trained in jump-starting learning, I’ll say this: revisit your foundations. Not the foundations, but your foundations. 

When things are this uncertain for this long, we reach for coping mechanisms. Why not use one to unblock learning? In a recent New York Times article, psychologists said that ‘conjuring nostalgia during stressful times is a healthy coping mechanism,” and I totally agree. Between re-watching 90’s movies and cooking comfort foods, I dove back into what brought me to tech: design, CSS, color functions, typography, design patterns. I played around in Illustrator, dusted off old repos, looked at happy projects, and remembered old trends. I avoided burning energy on the hot new thing. Instead, I revisited the foundations of my understanding through the lens of experience.

I’m not suggesting you stay in your comfort zone, but I am saying it’s okay to start there. The important thing is starting.

Routines and Structures

There is disruption on every level: global, national, and personal. I don’t know anyone who hasn’t experienced a disruption to their lives. When our routines are disrupted and our basic needs (including health and psychological) are threatened, we are unable to learn well. One of the most effective things a teacher can do in the classroom is to make sure their students eat breakfast, so focus on your needs. Getting a good night’s sleep contributes to learning. Caring for your mental health contributes to learning. Punishing yourself for struggling does not.

This year, as all of my support structures disappeared, there was not enough Natalya to do everything and be there for everyone. Accepting that was difficult. I spent a lot of energy shifting my focus from “the year I wished for” to the one I was experiencing. I used every trick in the teacher’s handbook on myself to keep my love of learning intact, feel some progress, and keep up. No matter how much I did, I still felt like I didn’t do enough. It was just the kind of year when everything felt like it took more energy (because it did). Setting up new routines and structures is work. Factor that into your equation when evaluating your progress.

This is where I would usually rant about how teaching and childcare are real skills and difficult jobs, dedicating several paragraphs on how important and valuable the work of teachers and caregivers is. But anyone who has been homeschooling or caring for someone this year is already well aware.

Creating the right conditions for effective learning is a lot of work, so give yourself credit if you’ve been taking it on.

This has been a deeply unsustainable year for so many. Showing up and making it through each day and making any progress is enough. Not giving up and trying again, day after day, is success.

What I learned…

Ah, the reason you’re reading this. I would love to talk about the cool design and tech stuff I learned this year, but I won’t. What I learned as an individual in 2020 is not nearly as important as what I hope we learned as an industry.

I hope we learned that the most important thing to know about building websites is that there are real people building them, and we need to make sure they can thrive.

Lunch perks and swag are cool, but what about childcare, accessibility, and support structures? What about flexible hours and remote-first practices? We should notice that the companies which supported people before the pandemic are doing better than the ones struggling to pivot to do the work they should have been doing all along.

I wish it didn’t take a global pandemic, but we need change. Let’s use this knowledge to build a better society with stronger principles and more thoughtful structures—not just better websites.

The post 2020 was not a good year for learning appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , ,

Announcing the 2020 State of CSS Survey

Last year’s State of CSS Survey yielded interesting results. There’s the quick adoption of features, like calc() and CSS custom properties. There’s also the overwhelming opinion that CSS is fun to write even as we see a growing reliance on CSS-in JS. We also saw some predictable results, like the proliferation of VS Code as a preferred code editor, the dominance of flexbox as a layout model, as well as BEM and Sass being the most adopted technologies with the highest rates of satisfaction.

Chris and Dave disussed the 2019 State of CSS results with co-creator Sacha Greif on ShopTalk Show and dive into many, many more of the results and what they tell us about our industry.

But hey, it’s been [checking my calendar] slightly over a year since that survey and it’s back with a 2020 edition. If you can take it, please do — the more years we have on record, the more interesting trends we can find. Plus, we’ve got a whole bunch of new features and technologies to evaluate, like subgrid, user preference media queries, logical properties, line-clamp(), min(), max(), yada, yada, the list goes on!

And if nothing else, check out the survey site for some bonafide CSS tricks. 😎

Direct Link to ArticlePermalink

The post Announcing the 2020 State of CSS Survey appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , ,

Comparing Styling Methods in 2020

Over on Smashing, Adebiyi Adedotun Lukman covers all these styling methods. It’s in the context of Next.js, which is somewhat important as Next.js has some specific ways you work with these tools, is React and, thus, is a components-based architecture. But the styling methods talked about transcend Next.js, and can apply broadly to lots of websites.

Here are my hot takes on the whole table-of-contents of styling possibilities these days.

  • Regular CSS. If you can, do. No build tooling is refreshing. It will age well. The only thing I really miss without any other tooling is nesting media queries.
  • Sass. Sass has been around the block and is still a hugely popular CSS preprocessor. Sass is built into tons of other tools, so choosing Sass doesn’t always mean the same thing. A simple Sass integration might be as easy as a sass --watch src/style.scss dist/style.css npm script. Then, once you’ve come to terms with the fact that you have a build process, you can start concatenating files, minifying, busting cache, and all this stuff that you’re probably going to end up doing somehow anyway.
  • Less & Stylus. I’m surprised they aren’t more popular since they’ve always been Node and work great with the proliferation of Node-powered build processes. Not to mention they are nice feature-rich preprocessors. I have nothing against either, but Sass is more ubiquitous, more actively developed, and canonical Sass now works fine in Node-land,
  • PostCSS. I’m not compelled by PostCSS because I don’t love having to cobble together the processing features that I want. That also has the bad side effect of making the process of writing CSS different across projects. Plus, I don’t like the idea of preprocessing away modern features, some of which can’t really be preprocessed (e.g. custom properties cannot be preprocessed). But I did love Autoprefixer when we really needed that, which is based on PostCSS.
  • CSS Modules. If you’re working with components in any technology, CSS modules give you the ability to scope CSS to that component, which is an incredibly great idea. I like this approach wherever I can get it. Your module CSS can be Sass too, so we can get the best of both worlds there.
  • CSS-in-JS. Let’s be real, this means “CSS-in-React.” If you’re writing Vue, you’re writing styles the way Vue helps you do it. Same with Svelte. Same with Angular. React is the un-opinionated one, leaving you to choose between things like styled-components, styled-jsx, Emotion… there are a lot of them. I have projects in React and I just use Sass+CSS Modules and think that’s fine, but a lot of people like CSS-inJS approaches too. I get it. You get the scoping automatically and can do fancy stuff like incorporate props into styling decisions. Could be awesome for a design system.

If you want to hear some other hot takes on this spectrum, the Syntax FM fellas sounded off on this recently.

The post Comparing Styling Methods in 2020 appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , ,

State of Jamstack 2020: Data Deep Dive

(This is a sponsored post.)

The Jamstack, a modern approach to building websites and apps, delivers better performance, higher security, lower cost of scaling, and a better developer experience. But how popular is it among developers worldwide, and what do they love and hate about it?

We at Kentico Kontent decided to take a closer look at the current state of Jamstackʼs adoption and use. Surveying more than 500 developers in four countries, we wanted to find out how long they’ve been working with the Jamstack, what they’re using this architecture for, where they typically deploy and host their projects, and more.

Based on the findings, we created The State of Jamstack 2020 Report that provides an overview of the results and comments on the most interesting facts. Now we’ve released something just as exciting:

Our free interactive data visualization page lets you dive into the data from our survey and discover how the web developers’ answers varied according to age, gender, primary programming language, and other factors.

Do you know where the majority of US developers working for large companies store their content? Or what’s their favorite static site generator? The answers may surprise you—click below to find out:

Direct Link to ArticlePermalink

The post State of Jamstack 2020: Data Deep Dive appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

A Look at What’s New in Chrome DevTools in 2020

I’m excited to share some of the newer features in Chrome DevTools with you. There’s a brief introduction below, and then we’ll cover many of the new DevTools features. We’ll also look at what’s happening in some other browsers. I keep up with this stuff, as I create Dev Tips, the largest collection of DevTools tips you’ll find online! 

It’s a good idea to find out what’s changed in DevTools because it’s constantly evolving and new features are specifically designed to help and improve our development and debugging experience.

Let’s jump into the latest and greatest. While the public stable version of Chrome does have most of these features, I’m using Chrome Canary as I like to stay on the bleeding edge.


Lighthouse is an open source tool for auditing web pages, typically around performance, SEO, accessibility and such. For a while now, Lighthouse has been bundled as part of DevTools meaning you can find it in a panel named… Lighthouse!

Screenshot of DevTools open on a CSS-Tricks page. The Lighthouse panel is open showing a best practices score of 100 out of 100.
Well done, Mr. Coyier. 🏆

I really like Lighthouse because it’s one of easiest parts of DevTools to use. Click “Generate report” and you immediately get human-readable notes for your webpage, such as:

Document uses legible font sizes 100% legible text


Avoid an excessive DOM size (1,189 elements)

Almost every single audit links to developer documentation that explains how the audit may fail, and what you can do to improve it.

The best way to get started with Lighthouse is to run audits on your own websites:

  1. Open up DevTools and navigate to the Lighthouse panel when you are on one of your sites
  2. Select the items you want to audit (Best practices is a good starting point)
  3. Click Generate report
  4. Click on any passed/failed audits to investigate the findings

Even though Lighthouse has been part of DevTools for a while now (since 2017!), it still deserves a significant mention because of the user-facing features it continues to ship, such as:

  • An audit that checks that anchor elements resolve to their URLs (Fun fact: I worked on this!)
  • An audit that checks whether the Largest Contentful Paint metic is fast enough
  • An audit to warn you of unused JavaScript

A better “Inspect Element”

This is a subtle and, in some ways, very small feature, but it can have profound effects on how we treat web accessibility.

Here’s how it works. When you use Inspect Element — what is arguably the most common use of DevTools — you now get a tooltip with additional information on accessibility.

Screenshot showing DevTools open on a CSS-Tricks page. An element is highlighted on the page and a tooltip with a white background is above it providing information on the element's color, font, contrast, name, role, and whether it is keyboard-focusable.
Accessibility is baked right in!

The reason I say this can have a profound impact is because DevTools has had accessibility features for quite some time now, but how many of us actually use them? Including this information on a commonly used feature like Inspect Element will gives it a lot more visibility and makes it a lot more accessible.

The tooltip includes:

  • the contrast ratio of the text (how well, or how poorly, does the foreground text contrast with the background color)
  • the text representation
  • the ARIA role
  • whether or not the inspected element is keyboard-focusable

To try this out, right-click (or Cmd + Shift + C) on an element and select Inspect to view it in DevTools.

I made a 14-minute video on Accessibility debugging with Chrome DevTools which covers some of this in more detail.

Emulate vision deficiencies

Exactly as it says on the tin, you can use Chrome DevTools to emulate vision impairments. For example, we can view a site through the lens of blurred vision.

Screenshot of DevTools open on a CSS-Tricks page. The Rendering panel is open and the blurred vision option is selected. The CSS-Tricks page is blurry and difficult to read.
That’s a challenge to read!

How can you do this in DevTools? Like this:

  1. Open DevTools (right click and “Inspect” or Cmd + Shift + C).
  2. Open the DevTools Command menu (Cmd + Shift + P on Mac, Ctrl + Shift + P on Windows).
  3. Select Show Rendering in the Command menu.
  4. Select a deficiency in the Rendering pane.

We used blurred vision as an example, but DevTools has other options, including: protanopia, deuteranopia, tritanopia, and achromatopsia.

Like with any tool of this nature, it’s designed to be a complement to our (hopefully) existing accessibility skills. In other words, it’s not instructional, but rather, influential on the designs and user experiences we create.

Here are a couple of extra resources on low vision accessibility and emulation:

Get timing on performance

The Performance Panel in DevTools can sometimes look like a confusing mish-mash of shapes and colors.

This update to it is great because it does a better job surfacing meaningful performance metrics.

Screenshot of DevTools with the Performance panel open. A chart showing the timeline of page rendering is above a row of Timings, including DCL, FP, FCP, L, and LCP. Below that is a summary that provides a time range for the selected timing.

What we want to look at are those extra timing rectangles shown in the “Timings” in the Performance Panel recording. This highlights:

  • DOMContentLoaded: The event which triggers when the initial HTML loads
  • First Paint: When the browser first paints pixels to the screen
  • First Contentful Paint: The point at which the browser draws content from the DOM which indicates to the user that content is loading
  • Onload: When the page and all of its resources have finished loading
  • Largest Contentful Paint: The largest image or text element, which is rendered in the viewport

As a bonus, if you find the Largest Contentful Paint event in a Performance Panel recording, you can click on it to get additional information.

Nice work, CSS-Tricks! The Largest Contentful Paint happens early on in the page load.

While there is a lot of golden information here, the “Related Node” is potentially the most useful item because it specifies exactly which element contributed to the LCP event.

To try this feature out:

  1. Open up DevTools and navigate to the Performance panel
  2. Click “Start profiling and reload page”
  3. Observe the timing metrics in the Timings section of a recording
  4. Click the individual metrics to see what additional information you get

Monitor performance

If you want to quickly get started using DevTools to analyze performance and you’ve already tried Lighthouse, then I recommend the Performance Monitor feature. This is sort of like having WebPageTest.org right at your fingertips with things like CPU usage.

Screenshot of DevTools with the Performance Monitor pane open. Four timeline charts are stacked vertically, starting with CPU Usage,followed by JavaScript Heap Size, DOM Nodes, and JavaScript Event Listeners.

Here’s how to access it:

  1. Open DevTools
  2. Open up the Command menu (Cmd + Shift + P on Mac, Ctrl + Shift + P on Windows)
  3. Select “Show performance monitor” from the Command menu
  4. Interact and navigate around the website
  5. Observe the results

The Performance Monitor can give you interesting metrics, however, unlike Lighthouse, it’s for you to figure out how to interpret them and take action. No suggestions are provided. It’s up to you to study that CPU usage chart and ask whether something like 90% is an acceptable level for your site (it probably isn’t).

The Performance Monitor has an interactive legend, where you can toggle metrics on and off, such as:

  • CPU usage
  • JS heap size
  • DOM Nodes
  • JS event listeners
  • Documents
  • Document Frames
  • Layouts / sec
  • Style recalcs / sec 

CSS overview and local overrides

CSS-Tricks has already covered these features, so go and check them out!

  • CSS Overview: A handy DevTools panel that gives a bunch of interesting stats on the CSS your page is using
  • Local Overrides:  A powerful feature that lets you override production websites with your local resources, so you can easily preview changes 

So, what about DevTool in other browsers?

I’m sure you noticed that I’ve been using Chrome throughout this article. It’s the browser I use personally. That said, it’s worth considering that:

  • Firefox DevTools is looking pretty great right now
  • With Microsoft Edge extending from Chromium, it too will benefit from these DevTools features
  • As evident on the Safari Technology Preview Release Notes (search for Web Inspector on that page), Safari DevTools has come a long way 

In other words, keep an eye out because this is a quickly evolving space!


We covered a lot in a short amount of space!

  • Lighthouse: A panel that provides  tips and suggestions for performance, accessibility, SEO and best practices.
  • Inspect Element: An enhancement to the Inspect Element feature that provides accessibility information to the Inspect Element tooltip
  • Emulate vision deficiencies: A feature in the Rendering Pane to view a page through the lens of low vision.
  • Performance Panel Timings: Additional metrics in the Performance panel recording, showing user-orientated stats, like Largest Contentful Paint
  • Performance Monitor – A real-time visualization of performance metrics for the current website, such as CPU usage and DOM size

Please check out my mailing list, Dev Tips, if you want to stay keep up with the latest updates and get over 200 web development tips! I also have a premium video course over at ModernDevTools.com. And, I tend to post loads of bonus web development resources on Twitter.

The post A Look at What’s New in Chrome DevTools in 2020 appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , ,

Improving Chromium’s browser compatibility in 2020

This is exactly what I love to hear from any browser vendor:

When it comes to browser compatibility, there are still too many missing features and edge-case bugs. But it doesn’t have to be this way. Things can and will get better, if browser vendors can understand what is causing the most pain, and take action to address the causes. In Chrome we’re doing our best to listen, and we’re doing our best to address what we’re hearing. We hope it helps, and we’re looking forward to a more compatible 2021.

I love the nod to that super clever div that looks different in every browser. This is a solid list from Stephen McGruer. My favorite:

Like Flexbox, CSS Grid is an important component of modern layout. Looking at the early survey results it seems like the story for CSS Grid support in Chromium is fairly good (we have our friends from Igalia to thank for that!). There is one clear exception – Chromium still doesn’t support subgrid.

Hopefully, it won’t be an exception for much longer. It’s still early days, but I’m excited to share that a team at Microsoft Edge are working on rearchitecting Chromium’s Grid support to use the new LayoutNG engine – and as part of this are intending to add subgrid support!

Not that anyone should relax, but I think right now is probably the best level of browser compatibility we’ve ever seen.

Direct Link to ArticlePermalink

The post Improving Chromium’s browser compatibility in 2020 appeared first on CSS-Tricks.


, , , ,