2018 Staff Favorites

Last year, the team here at CSS-Tricks compiled a list of our favorite posts, trends, topics, and resources from around the world of front-end development. We had a blast doing it and found it to be a nice recap of the industry as we saw it over the course of the year. Well, we’re doing it again this year!

With that, here’s everything that Sarah, Robin, Chris and I saw and enjoyed over the past year.


Sarah

Good code review

There are a few themes that cross languages, and one of them is good code review. Even though Nina Zakharenko gives talks and makes resources about Python, her talk about code review skills is especially notable because it applies across many disciplines. She’s got a great arc to this talk and I think her deck is an excellent resource, but you can take this a step even further and think critically about your own team, what works for it, and what practices might need to be reconsidered.

I also enjoyed this sarcastic tweet that brings up a good point:

I’ve been guilty myself of commenting on a really clean pull request just to say something, and it’s healthy for us as a community to revisit why we do things like this.

Sophie Alpert, manager of the React core team, also wrote a great post along these lines right at the end of the year called Why Review Code. It’s a good resource to turn to when you’d like to explain the need for code reviews in the development process.

The year of (creative) code

So many wonderful creative coding resources were made this year. Creative coding projects might seem frivolous but you can actually learn a ton from making and playing with them. Matt DesLauriers recently taught a course called Creative Coding with Canvas & WebGL for Frontend Masters that serves as a good example.

CodePen is always one of my favorite places to check out creative work because it provides a way to reverse-engineer the work of other people and learn from their source code. CodePen has also started coding challenges adding yet another way to motivate creative experiments and collective learning opportunities. Marie Mosley did a lot of work to make that happen and her work on CodePen’s great newsletter is equally awesome.

You should also consider checking out Monica Dinculescu‘s work because she has been sharing some amazing work. There’s not one, not two, but three (!) that use machine learning alone. Go see all of her Glitch projects. And, for what it’s worth, Glitch is a great place to explore creative code and remix your own as well.

GitHub Actions

I think hands-down one of the most game-changing developments this year is GitHub Actions. The fact that you can manage all of your testing, deployments, and project issues as containers chained in a unified workflow is quite amazing.

Containers are a great for actions because of their flexibility — you’re not limited to a single kind of compute and so much is possible! I did a writeup about GitHub Actions covering the feature in full. And, if you’re digging into containers, you might find the dive repo helpful because it provides a way to explore a docker image and layer contents.

Actions are still in beta but you can request access — they’re slowly rolling out now.

UI property generators

I really like that we’re automating some of the code that we need to make beautiful front-end experiences these days. In terms of color there’s color by Adobe, coolors, and uiGradients. There are even generators for other things, like gradients, clip-path, font pairings, and box-shadow. I am very much all for this. These are the kind of tools that speed up development and allow us to use advanced effects, no matter the skill level.


Robin

Ire Aderinokun’s blog

Ire has been writing a near constant stream of wondrous articles about front-end development on her blog, Bits of Code, over the past year, and it’s been super exciting to keep up with her work. It seems like she’s posting something I find useful almost every day, from basic stuff like when hover, focus and active states apply to accessibility tips like the aria-live attribute.

“The All Powerful Front-end Developer”

Chris gave a talk this year about the ways the role of front-end development are changing… and for the better. It was perhaps the most inspiring talk I saw this year. Talks about front-end stuff are sometimes pretty dry, but Chris does something else here. He covers a host of new tools we can use today to do things that previously required a ton of back-end skills. Chris even made a website all about these new tools which are often categorized as “Serverless.”

Even if none of these tools excite you, I would recommend checking out the talk – Chris’s enthusiasm is electric and made me want to pull up my sleeves and get to work on something fun, weird and exciting.

Future Fonts

The Future Fonts marketplace turned out to be a great place to find new and experimental typefaces this year. Obviously is a good example of that. But the difference between Future Fonts and other marketplaces is that you can buy fonts that are in beta and still currently under development. If you get in on the ground floor and buy a font for $10, then that shows the developer the interest in a particular font which may spur more features for it, like new weights, widths or even OpenType features.

It’s a great way to support type designers while getting a ton of neat and experimental typefaces at the same time.

React Conf 2018

The talks from React Conf 2018 will get you up to speed with the latest React news. It’s interesting to see how React Hooks let you “use state and other React features without writing a class.”

It’s also worth calling out that a lot of folks really improved our Guide to React here on CSS-Tricks so that it now contains a ton of advice about how to get started and how to level up on both basic and advanced practices.

The Victorian Internet

This is a weird recommendation because The Victorian Internet is a book and it wasn’t published this year. But! It’s certainly the best book I’ve read this year, even if it’s only tangentially related to web stuff. It made me realize that the internet we’re building today is one that’s much older than I first expected. The book focuses on the laying of the Transatlantic submarine cables, the design of codes and the codebreakers, fraudsters that used the telegraph to find their marks, and those that used it to find the person they’d marry. I really can’t recommend this book enough.

Figma

The browser-based design tool Figma continued to release a wave of new features that makes building design systems and UI kits easier than ever before. I’ve been doing a ton of experiments with it to see how it helps designers communicate, as well as how to build more resilient components. It’s super impressive to see how much the tools have improved over the past year and I’m excited to see it improve in the new year, too.


Geoff

Buzz about third party scripts

It seems there was a lot of chatter this year about the impact of third party scripts. Whether it’s the growing ubiquity of all-things-JavaScript or whatever, this topic covers a wide and interesting ground, including performance, security and even hard costs, to name a few.

My personal favorite post about this was Paulo Mioni’s deep dive into the anatomy of a malicious script. Sure, the technical bits are a great learning opportunity, but what really makes this piece is the way it reads like a true crime novel.

Gutenberg, Gutenberg and more Gutenberg

There was so much noise leading up to the new WordPress editor that the release of WordPress 5.0 containing it felt anti-climactic. No one was hurt or injured amid plenty of concerns, though there is indeed room for improvement.

Lara Schneck and Andy Bell teamed up for a hefty seven-party series aimed at getting developers like us primed for the changes and it’s incredible. No stone is left unturned and it perfectly suitable for beginners and experts alike.

Solving real life issues with UX

I like to think that I care a lot about users in the work I do and that I do my best to empathize so that I can anticipate needs or feelings as they interact with the site or app. That said, my mind was blown away by a study Lucas Chae did on the search engine experience of people looking for a way to kill themselves. I mean, depression and suicide are topics that are near and dear to my heart, but I never thought about finding a practical solution for handling it in an online experience.

So, thanks for that, Lucas. It inspired me to piggyback on his recommendations with a few of my own. Hopefully, this is a conversation that goes well beyond 2018 and sparks meaningful change in this department.

The growing gig economy

Freelancing is one of my favorite things to talk about at great length with anyone and everyone who is willing to talk shop and that’s largely because I’ve learned a lot about it in the five years I’ve been in it.

But if you take my experience and quadruple it, then you get a treasure trove of wisdom like Adam Coti shared in his collection of freelancing lessons learned over 20 years of service.

Freelancing isn’t for everyone. Neither is remote work. Adam’s advice is what I wish I had going into this five years ago.

Browser ecology

I absolutely love the way Rachel Nabors likens web browsers to a biological ecosystem. It’s a stellar analogy and leads into the long and winding history of browser evolution.

Speaking of history, Jason Hoffman’s telling of the history about browsers and web standards is equally interesting and a good chunk of context to carry in your back pocket.

These posts were timely because this year saw a lot of movement in the browser landscape. Microsoft is dropping EdgeHTML for Blink and Google ramped up its AMP product. 2018 felt like a dizzying year of significant changes for industry giants!


Chris

All the best buzzwords: JAMstack, Serverless, & Headless

“Don’t tell me how to build a front end!” we, front-end developers, cry out. We are very powerful now. We like to bring our own front-end stack, then use your back-end data and APIs. As this is happening, we’re seeing healthy things happen like content management systems evolving to headless frameworks and focus on what they are best at: content management. We’re seeing performance and security improvements through the power of static and CDN-backed hosting. We’re seeing hosting and server usage cost reductions.

But we’re also seeing unhealthy things we need to work through, like front-end developers being spread too thin. We have JavaScript-focused engineers failing to write clean, extensible, performant, accessible markup and styles, and, on the flip side, we have UX-focused engineers feeling left out, left behind, or asked to do development work suddenly quite far away from their current expertise.

GraphQL

Speaking of powerful front-end developers, giving us front-end developers a well-oiled GraphQL setup is extremely empowering. No longer do we need to be roadblocked by waiting for an API to be finished or data to be massaged into some needed format. All the data you want is available at your fingertips, so go get and use it as you will. This makes building and iterating on the front end faster, easier, and more fun, which will lead us to building better products. Apollo GraphQL is the thing to look at here.

While front-end is having a massive love affair with JavaScript, there are plenty of front-end developers happily focused elsewhere

This is what I was getting at in my first section. There is a divide happening. It’s always been there, but with JavaScript being absolutely enormous right now and showing no signs of slowing down, people are starting to fall through the schism. Can I still be a front-end developer if I’m not deep into JavaScript? Of course. I’m not going to tell you that you shouldn’t learn JavaScript, because it’s pretty cool and powerful and you just might love it, but if you’re focused on UX, UI, animation, accessibility, semantics, layout, architecture, design patterns, illustration, copywriting, and any combination of that and whatever else, you’re still awesome and useful and always will be. Hugs. 🤗

Just look at the book Refactoring UI or the course Learn UI Design as proof there is lots to know about UI design and being great at it requires a lot of training, practice, and skill just like any other aspect of front-end development.

Shamelessly using grid and custom properties everywhere

I remember when I first learned flexbox, it was all I reached for to make layouts. I still love flexbox, but now that we have grid and the browser support is nearly just as good, I find myself reaching for grid even more. Not that it’s a competition; they are different tools useful in different situations. But admittedly, there were things I would have used flexbox for a year ago that I use grid for now and grid feels more intuitive and more like the right tool.

I’m still swooning over the amazing illustrations Lynn Fisher did for both our grid and flexbox guides.

Massive discussions around CSS-in-JS and approaches, like Tailwind

These discussions can get quite heated, but there is no ignoring the fact that the landscape of CSS-in-JS is huge, has a lot of fans, and seems to be hitting the right notes for a lot of folks. But it’s far from settled down. Libraries like Vue and Angular have their own framework-prescribed way of handling it, whereas React has literally dozens of options and a fast-moving landscape with libraries popping up and popular ones spinning down in favor of others. It does seem like the feature set is starting to settle down a little, so this next year will be interesting to watch.

Then there is the concept of atomic CSS on the other side of the spectrum, and interesting in that doesn’t seem to have slowed down at all either. Tailwind CSS is perhaps the hottest framework out there, gaining enough traction that Adam is going full time on it.

What could really shake this up is if the web platform itself decides to get into solving some of the problems that gave rise to these solutions. The shadow DOM already exists in Web Components Land, so perhaps there are answers there? Maybe the return of <style scoped>? Maybe new best practices will evolve that employ a single-stylesheet-per-component? Who knows.

Design systems becoming a core deliverable

There are whole conferences around them now!

I’ve heard of multiple agencies where design systems are literally what they make for their clients. Not websites, design systems. I get it. If you give a team a really powerful and flexible toolbox to build their own site with, they will do just that. Giving them some finished pages, as polished as they might be, leaves them needing to dissect those themselves and figure out how to extend and build upon them when that need inevitably arrives. I think it makes sense for agencies, or special teams, to focus on extensible component-driven libraries that are used to build sites.

Machine Learning

Stuff like this blows me away:

Having open source libraries that help with machine learning and that are actually accessible for regular ol’ developers to use is a big deal.

Stuff like this will have real world-bettering implications:

And this!

OK, OK. One more

You gotta check out the Unicode Pattern work (more) that Yuan Chuan does. He even shared some of his work and how he does it right here on CSS-Tricks. And follow that name link to CodePen for even more. This <css-doodle> thing they have created is fantastic.

See the Pen Seeding by yuanchuan (@yuanchuan) on CodePen.

The post 2018 Staff Favorites appeared first on CSS-Tricks.

The Most Hearted of 2018

We’ve released the Most Hearted Pens, Posts, and Collections on CodePen for 2018! Just absolutely incredible work on here — it’s well worth exploring.

Remember CodePen has a three-tiered hearting system, so while the number next to the heart reflects the number of users who hearted the item, each of those could be worth 1, 2, or 3 hearts total. This list is a great place to find awesome people to follow on CodePen as well, and we’re working on ways to make following people a lot more interesting in 2019.

Direct Link to ArticlePermalink

The post The Most Hearted of 2018 appeared first on CSS-Tricks.

WordCamp US 2018

I recently attended and had the chance to speak at WordCamp US 2018 in Nashville. I had a great time. I love conferences that bring people together around a tight theme because it’s very likely you’ll have something to talk about with every person there. Plus, I rather like WordPress and its community. The vibe was very centered around Gutenberg, as it was released in WordPress 5.0 just as the conference started.

Matt’s State of the Word gets into all that:

I took the opportunity to give a brand new talk I’ve been working on I’ve called, “Thinking Like a Front-End Developer”:

There were loads of wonderful people there and loads of wonderful talks. Here’s a playlist!

The post WordCamp US 2018 appeared first on CSS-Tricks.

The Elements of UI Engineering

I really enjoyed this post by Dan Abramov. He defines his work as a UI engineer and I especially like what he writes about his learning experience:

My biggest learning breakthroughs weren’t about a particular technology. Rather, I learned the most when I struggled to solve a particular UI problem. Sometimes, I would later discover libraries or patterns that helped me. In other cases, I’d come up with my own solutions (both good and bad ones).

It’s this combination of understanding the problems, experimenting with the solutions, and applying different strategies that led to the most rewarding learning experiences in my life. This post focuses on just the problems.

He then breaks those problems down into a dozen different areas: consistency, responsiveness, latency, navigation, staleness, entropy, priority, accessibility, internationalization, delivery, resilience, and abstraction. This is a pretty good list of what a front-end developer has to be concerned about on a day-to-day basis, but I also feel like this is perhaps the best description of what I believe my own skills are besides being “the person who cares about component design and CSS.”

I also love what Dan has to say about accessibility:

Inaccessible websites are not a niche problem. For example, in UK disability affects 1 in 5 people. (Here’s a nice infographic.) I’ve felt this personally too. Though I’m only 26, I struggle to read websites with thin fonts and low contrast. I try to use the trackpad less often, and I dread the day I’ll have to navigate poorly implemented websites by keyboard. We need to make our apps not horrible to people with difficulties — and the good news is that there’s a lot of low-hanging fruit. It starts with education and tooling. But we also need to make it easy for product developers to do the right thing. What can we do to make accessibility a default rather than an afterthought?

This is a good reminder that front-end development is not a problem to be solved, except I reckon Dan’s post is more helpful and less snarky than my take on it.

Anywho, we all want accessible interfaces so that every browser can access our work making use of beautiful and consistent mobile interactions, instantaneous performance, and a design system teams can utilize to click-clack components together with little-to-no effort. But these things are only possible if others recognize that UI and front-end development are a worthy fields.

Direct Link to ArticlePermalink

The post The Elements of UI Engineering appeared first on CSS-Tricks.

Multi-Line Inline Gradient

Came across this thread:

My first thought process was:

But it turns out we need a litttttle extra trickery to make it happen.

If a solid color is fine, then some padding combined with box-decoration-break should get the basic framework:

See the Pen Multiline Padding with box-decoration-break by Chris Coyier (@chriscoyier) on CodePen.

But a gradient on there is gonna get weird on multiple lines:

See the Pen Multiline Padding with box-decoration-break by Chris Coyier (@chriscoyier) on CodePen.

I’m gonna credit Matthias Ott, from that thread, with what looks like the perfect answer to me:

See the Pen Multiline background gradient with mix-blend-mode by Matthias Ott (@matthiasott) on CodePen.

The trick there is to set up the padded multi-line background just how you want it with pure white text and a black background. Then, a pseudo-element is set over the whole area with the gradient in the black area. Throw in mix-blend-mode: lighten; to make the gradient only appear on the black area. Nice one.

The post Multi-Line Inline Gradient appeared first on CSS-Tricks.

Jetpack

My favorite way to think about Jetpack is that it’s a WordPress plugin that brings a whole heap of features to your site. I’ve documented the features that we use here on CSS-Tricks, which isn’t even all of them (yet).

Some of Jetpack features are essentially connecting it to the powers of WordPress.com. For example, of course, WordPress.com has some amazing way to optimize and serve images. They can build a service that millions of sites on WordPress.com can benefit from, which really benefits everyone, including them, because optimized images reduce bandwidth costs. Then Jetpack steps in and can offer that same power to you on your self-hosted WordPress site. Here’s a video I did showing how that works.

Other features are things like real-time backups of your site to VaultPress, which is incredibly important to me knowing I have every bit of this site backed up and under my control.

Because your site now lives within your WordPress.com dashboard, you get features there. I quite like the analytics dashboards, which seem more accessible to me than trying to poke around Google Analytics.

Another one I really like is the ability to manage WordPress plugins from there. I’m happing doing that in the admin of my own site as well, but from here, I can tell certain plugins to auto-update, which just saves me the minor hassle of doing it myself.

The post Jetpack appeared first on CSS-Tricks.

Quicklink

We’re in the future now so, of course, we’re working on ways to speed up the web with fancy new tactics above and beyond the typical make-pages-slimmer-and-cached-like-crazy techniques.

One tactic, from years ago, was InstantClick:

Before visitors click on a link, they hover over that link. Between these two events, 200 ms to 300 ms usually pass by (test yourself here). InstantClick makes use of that time to preload the page, so that the page is already there when you click.

Clever, but not as advanced as what can be done in these modern times. For instance, InstantClick doesn’t take into account the fact that someone might not want to preload stuff they didn’t explicitly ask for, especially if they are on a slow network.

Addy Osmani wrote up a document calling this “predictive fetching”:

… given an arbitrary entry-page, a solution could calculate the likelihood a user will visit a given next page or set of pages and prefetch resources for them while the user is still viewing their current page. This has the possibility of improving page-load performance for subsequent page visits as there’s a strong chance a page will already be in the user’s cache.

Just think: we could feed analytics data into the mix and let machine learning chew away at it. Addy also points to other prior attempts, like Gatsby’s Link and a WordPress plugin.

Another contender is Quicklink by Google:

Quicklink attempts to make navigations to subsequent pages load faster. It:

  • Detects links within the viewport (using Intersection Observer)
  • Waits until the browser is idle (using requestIdleCallback)
  • Checks if the user isn’t on a slow connection (using navigator.connection.effectiveType) or has data-saver enabled (using navigator.connection.saveData)
  • Prefetches URLs to the links (using <link rel=prefetch> or XHR). Provides some control over the request priority (can switch to fetch() if supported).

No machine learning or analytics usage there, but perhaps the most clever yet. I really like the spirit of prefetching only when there is a high enough likelihood of usage; the browser is idle anyway, and the network can handle it.

Direct Link to ArticlePermalink

The post Quicklink appeared first on CSS-Tricks.

Storing and Using the Last Known Route in Vue

There are situations where keeping a reference to the last route a user visited can come in handy. For example, let’s say we’re working with a multi-step form and the user proceeds from one step to the next. It would be ideal to have the route of that previous step in hand so we know where the user left off, in the event that they navigate away and come back later to complete the form later.

We’re going to cover how to store the last known route and then fetch it when we need it. We’ll be working in Vue in this example and put vue-router to use for routing and localStorage to keep the information about last visited route.

Here’s an example of what we’ll be working with:

First, let’s outline the route structure

Our example has a grand total of three routes:

  • /home
  • /hello
  • /goodbye

Each route needs to be assigned a name property, so let’s add that to our router.js file:

// router.js import Vue from "vue";
import Router from "vue-router";
import Hello from "@/components/Hello";
import Goodbye from "@/components/Goodbye"; import { HELLO_URL, GOODBYE_URL
} from "@/consts"; Vue.use(Router); const router = new Router({ mode: "history", routes: [ { path: "/", name: "home" }, { path: HELLO_URL, name: "hello", component: Hello }, { path: GOODBYE_URL, name: "goodbye", component: Goodbye } ]
}); export default router;

Next, let’s go over the requirements

We know the first requirement is to store the last visited route in localStorage. And, secondly, we need to be able to retrieve it. But what conditions should the route be fetched and applied? That gives us two additional requirements.

  • the user enters the main route (/home), navigates away from it, then wants to return to it.
  • the user has been inactive for a specific time period, the session expires, and we want to return the user to the last screen they were on after restarting the session.

These four requirements are what we need to meet in order to proceed with the redirection.

Now let’s jump into the code.

Requirement 1: Save the last route name in localStorage

We want to keep the reference to our last visited route in localStorage. For example, if a user is at /checkout and then leaves the site, we want to save that so the purchase can be completed later.

To do that, we want to save the route name when the user enters any new route. We’ll use a navigation guard called afterEach that’s fired each time the route transition is finished. It provides a to object which is the target Route Object. In that hook, we can extract the name of that route and save it in localStorage using a setItem method.

// router.js const router = new Router( ... ); router.afterEach(to => { localStorage.setItem(LS_ROUTE_KEY, to.name);
}); ...
export default router;

Requirement 2: Fetch the last route name from localStorage and redirect

Now that the name of the last route is saved, we need to be able to fetch it and trigger a redirect to it when it’s needed. We want to check if we should redirect before we enter a new route, so we will use another navigation guard called beforeEach. This guard receives three arguments:

  • to: the target route object
  • from: the current route navigated from
  • next: the function that must be called in the guard to resolve the hook

In that guard, we read the name of the last visited route by using a localStorage.getItem() method. Then, we determine if the user should be redirected. At this point, we check that the target route (to) is our main route (/home) and if we do indeed have a last route in localStorage.

If those conditions are met, we fire the next method that contains the name of the last visited route. That, in turn, will trigger a redirect to that route.

If any condition fails, then we’ll fire next without any arguments. That will move the user on to the next hook in the pipeline and proceed with ordinary routing without redirection.

// router.js const router = new Router( ... ); router.beforeEach((to, from, next) => { const lastRouteName = localStorage.getItem(LS_ROUTE_KEY); const shouldRedirect = Boolean( to.name === "home" && lastRouteName ); if (shouldRedirect) next({ name: lastRouteName }); else next();
}); ...
export default router;

That covers two out of four requirements! Let’s proceed with requirement number three.

Requirement 3: The first visit condition

Now, we need to check if the user is visiting the main route for the first time (coming from a different source) or is navigating there from another route within the application. We can do that by adding a flag that is set to true when the Router is created and set it to false after first transition is finished.

// router.js const router = new Router( ... ); let isFirstTransition = true; router.beforeEach((to, from, next) => { const lastRouteName = localStorage.getItem(LS_ROUTE_KEY); const shouldRedirect = Boolean( to.name === "home" && && lastRouteName && isFirstTransition ); if (shouldRedirect) next({ name: lastRouteName }); else next(); isFirstTransition = false;
}); ...
export default router;

OK, there is one more requirement we need to meet: we want to redirect the user to the last known route if the user has been inactive for longer that a specific period of time.

Requirement 4: The activity time condition

Again, we will use localStorage to keep the information about user’s last visited route.

In the beforeEach guard, we will get the route from localStorage and check if the time passed from that moment is within our threshold (defined by hasBeenActiveRecently). Then, in our shouldRedirect, we’ll determine whether a route redirect should happen or not.

We also need to save that information, which we will do in the afterEach guard.

// router.js const router = new Router( ... ); let isFirstTransition = true; router.beforeEach((to, from, next) => { const lastRouteName = localStorage.getItem(LS_ROUTE_KEY); const lastActivityAt = localStorage.getItem(LS_LAST_ACTIVITY_AT_KEY); const hasBeenActiveRecently = Boolean( lastActivityAt && Date.now() - Number(lastActivityAt) < MAX_TIME_TO_RETURN ); const shouldRedirect = Boolean( to.name === "home" && && lastRouteName && isFirstTransition && hasBeenActiveRecently ); if (shouldRedirect) next({ name: lastRouteName }); else next(); isFirstTransition = false;
}); router.afterEach(to => { localStorage.setItem(LS_ROUTE_KEY, to.name); localStorage.setItem(LS_LAST_ACTIVITY_AT_KEY, Date.now());
}); ...
export default router;

We met the requirements!

That’s it! We covered all four of requirements, namely:

  • We store the last visited route in localStorage
  • We have a method to retrieve the last visited route from localStorage
  • We redirect a user back to the main route if they’re coming into the application on an initial visit
  • We provide the user with a redirect to the last known route within a certain time period

Of course, we can extend this further by adding more complexity to the app and new conditions to the shouldRedirect variable, but this gives us more than we need to have an understanding of how to keep the last visited route persistent and retrieve it when it’s needed.

The post Storing and Using the Last Known Route in Vue appeared first on CSS-Tricks.

Thank You (2018 Edition)

Another year come and gone! As we do each year, let’s take a look at the past year from an analytical by-the-numbers perspective and do a goal review. Most importantly, I’d like to extend the deepest of thanks to you, wonderful readers of CSS-Tricks, for making this place possible.

This site has a new design, doesn’t it? It does! I’ll write something more about that soon. If you have something to say about it right now, feel free to use our new public community on Spectrum. If it’s a bug or thought that doesn’t really need to be public, our our contact form would be great.


I can count the times I pop into Google Analytics per year on my two hands these days, but we’ve had the basic snippet installed since day one around here, so it’s great for keeping an eye on site traffic and usage over the long term. Especially since CSS-Tricks has been a fairly basic WordPress install the entire time with little by the way of major infrastructural changes that would disrupt how these numbers are gathered.

Page views over the entire lifespan of CSS-Tricks.

We had 91 million page views this year, up from 75 million last year. That’s great to see, as we were at 75 in 2017, 77 in 2016, and 72 in 2015. We’ve managed to do a bigger leap this year than perhaps we ever have. I’d love make a go at 100 million next year! That’s based on 65 million sessions and 23 million users.


Perhaps some of that traffic could be attributed to the fact that we published 636 Posts this year, up from 595 last year. I’d like to think they are higher quality too, as we’ve invested much more in guest writing and had a more thorough editing process this year than we ever have. We’ve had Geoff Graham as lead editor all year and he’s doing a phenomenal job of keeping our content train rolling.

For the last few years, I’ve been trying to think of CSS-Tricks as this two-headed beast. One head is that we’re trying to produce long-lasting referential content. We want to be a site that you come to or land on to find answers to front-end questions. The other head is that we want to be able to be read like a magazine. Subscribe, pop by once a week, snag the RSS feed… whatever you like, we hope CSS-Tricks is interesting to read as a hobbyist magazine or industry rag.

We only published 25 new pages this year, which are things like snippets, almanac entries, and videos. I’d really like to see that go up this year, particularly with the almanac, as we have lots of new pages documented that we need to add an update.

I almost wish our URLs had years in them because I still don’t have a way to scope analytic data to only show me data from content published this year. I can see the most popular stuff from the year, but that’s regardless of when it was published, and that’s dominated by the big guides we’ve had for years and keep updated.


Interestingly, flexbox is still our #1 guide, but searches for the grid guide are only narrowly behind it. It depends on the source though. I can see data for on-site search through WordPress.com (via Jetpack) which show grid searches at about 30% less than flexbox. Google Analytics have it about 60% less, which would be Google searches that end up on CSS-Tricks. Nevertheless, those are the two most popular search keywords, on-site and off. From #3 onwards: svg, border, position, animation, underline, background, display, transition, table, button, uppercase, css, bold, float, hover, transform.

I love that! People are landing on the site looking for fundamental CSS concepts, and hopefully finding what they need.

Site search has been a bit of a journey. Native WordPress search isn’t good enough for a site this big. For a long time I used Google Custom Search Engine, which is nice because it’s as good as Google is, but bad because it’s a bit hard to style nicely and is covered in ads that don’t make enough money to be worth it and are too expensive to remove. Last year I was using Algolia for a while, which is a fantastic product, but I needed to give it more development effort than I was able to at the time. Now I’m back on WordPress search but powered by Jetpack, which brings the power of cloud-hosted Elasticsearch, which is pretty sweet. It means I have native WordPress template and styling control, and lots of tweakability.


Search is also fascinating as it represents 81% of how people get to CSS-Tricks. That’s particularly interesting in it means that the growth in page views wasn’t necessarily from search, as we had 86% of traffic from search last year, down a full 5%. Growth came from other areas so strongly it pushed down search.

All of social media combined is 2%. I’m always reminded this time of year how much time and energy we spend on social media, and how perhaps the smart move is refocusing some of that energy toward on-site content, as that is far better for helping more people. Not that I don’t enjoy social media. Surely we’ve gotten countless ideas for posts and content for those posts from social media participation.


An interesting uptick was in direct traffic. 9% of visits this year were direct, up from just 5% last year. And referral traffic at 7% up from 5%. Social media remained steady, so really we have more people coming directly to the site and more links from other sites to thank for the uptick in traffic.


Speaking of social media, we got @CSS on Twitter this year, and that’s been fun. I would have thought it would have increased the rate of growth for followers, but it doesn’t appear to.

Chart from SocialBlade. I imagine that downblip was some sort of Twitter spam purge.

We hardly do anything with Facebook, beyond making sure new content is posted there. That sometimes feels like a missed opportunity since there are more people there than any other social network on Earth. But it doesn’t seem particularly huge in developer communities as best I can tell. Not to mention Facebook is constantly revealed to be doing sketchy things, which steers me away from it personally.


We’ve had a remarkably consistent year of the CSS-Tricks Newsletter, publishing it every single week. Robin Rendle works hard on that every single week. We started the year with 31,376 subscribers and ended with 39,655. So about an 8.5k increase, down from the 10k increase last year. It’s still good growth, and I suspect we’ll see much better growth next year because the new site design does a lot better job promoting it and we have some plans to make our authoring of it and displaying it on this site much better.


If the news about Edge going Chromium made you worry that Chrome would become too dominant of a browser… well, Edge hasn’t actually done that yet and Chrome is already pretty darn dominant already, particularly on this site. 77% of traffic is Chrome, 11% Firefox, 6% Safari, about 1.5% each for IE and Edge, and then the rest sprinkled out through 836 other identified browsers.

61% Windows, 22% Mac, 7% Linux, 7% Android, 3% iOS, and the rest sprinkled through 42 known operating systems.

Traffic geography has remained consistent. The United States has the lead at 22%, India at 13%, UK at 5%, Germany at 4%, Canada, France, and Brazil at 3%, Russia, Australia, Netherlands, Spain, Poland, Italy, Ukraine, China, Philipines at 2%, and the rest over 240 other identified countries.

Another surprising turn this year was mobile traffic. Internet-wide, I believe we’re past the tipping point of more than half of all traffic being from mobile devices. On this site, we hovered at just 2 or 3% for many years. It was 6% last year, a big jump, and now 10% this year. I always suspected the main reason for the low numbers was the fact that this site is used in conjunction with doing active development, and active development is still a desktop-dominant task. Still, it’s growing and the rate of growth is growing too.


There were 3,788 approved comments this year, down from 5,040 last year. We’ve been hand-approving all comments for a while now. We’ve always moderated, but having to approve them before they appear at all slows down commenting activity and leads to less overall. I’d estimate maybe 50-60% of non-spam comments get approved. Absolutely worth it to me to maintain a positive vibe here. I also suspect the main reason for lower comments is just that people do a lot more of their conversing over social media. I’m sure if we tracked conversations on social media in relation to things we’ve published (somehow) that would be up.

Our commenting system is also dreadfully old-timey. I’d love to see a system that allows for accounts, comment editing, social login, a fancy editor, Markdown, the whole nine yards, but I’ve yet to be swooned by something.

The contact form on site is up to ID #21458, so we got 1,220 messages through that this year.


Goal Review

Publish something in a new format. Behind the scenes, we actually did some foundational work to make this happen, so I’m optimistic about the possibilities. But we didn’t get anything out the door. The closest thing we’ve been doing is organizing content into guides, which is somewhat of a new format for us that I also want to evolve.

More editorial vision. I think we got close enough to call this a success. We did a bunch of themed weeks. We were always grouping content together that is thematically related. Our link posts got better at being referential and topical. We still covered news pretty well. I think I’d like to see us to more far-ahead planning so we can bring bigger ideas to life.

Interesting sponsorship partners. I think we nailed it here.

Create another very popular page. We’re at our best when we’re creating really strong useful referential content. When we really nail it, we make pages that are very useful to people and it’s a win for everybody. I’m not sure we had a run-away super popular page this year, so we’ll gun for it next year.

New Goals

Polish this new design. This is easily the most time, effort, and money that’s gone into a redesign since the big v10 design. There are a lot of aesthetic changes, but there was also quite a bit of UX work, business goal orientation, workflow tweaking, and backend development work that went along with it. I’d like to get some mileage out of it by not just sitting on it but refining it over a longer period.

Improve newsletter publishing and display. We sent our newsletter out via MailChimp, which is a great product, but over the years it has been good for us to bring as much under the WordPress umbrella as we can. I think we can create a pretty sweet newsletter authoring experience right within WordPress, then continue to send it via MailChimp via a special RSS feed. That’ll take some work, but it should make for a better newsletter that is more comfortable to produce and easier to integrate here on the site.

Raise the bar on quality. I’d be happy to see the number of posts we publish go down if we could make the quality go up. Nothing against any of our authors’ work that is already out there, but I think we all know super high-quality articles when we see them and I’d like to hit that mark more often. If that means posts spending more time in editing and us being a bit more demanding about what we’d like to see, we’ll do it.

Better guides. There are two sorts of guides: “complete guides” like our flexbox and grid guides (to name a few) and “guide collections” which are hand-chosen, hand-ordered, and hand-maintained guides along a theme, like our beginner guide. As a site with loads of content from over a decade, I really like these as a way to make sure the best stuff has a proper home and we can serve groups of people and topics in a strong way.

THANK YOU!

💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜

Again, you make this place possible.

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