DEV Community: Ben Holmes

Understanding single page apps & client-side routing

Ben Holmes — Wed, 07 Jul 2021 22:12:02 +0000

This entry comes from my web wizardry newsletter, where I explore evergreen solutions to common web dev problems (no matter your favorite framework). If you like what you see, go sign up for free 🪄

"SPA" has been a hot topic ever since "modern" JS frameworks like React hit the scene. They promise all sorts of benefits like dynamic user interactions, lightning-fast load times, solving world hunger, etc. (okay that last one is a stretch...)

But have you ever stopped to wonder what's actually going on behind the scenes? And if you're not using an SPA, are you stuck in the past? Well, let's explore:

🤔 How non-SPAs work + how they perform on the modern web (spoiler, they're a great choice as always!)
⚙️ The key benefits and inner workings of an SPA
🍔 A side-by-side visual comparison feat. juicy burgers

Onwards!

🤔 First off, how do non- SPAs work?

Web development has been soaking in acronym soup lately, so I think it's worth clarifying what isn't an SPA first 🙃

If your site isn't an SPA, you're likely using what's called "server-based routing." A metaphor is in order here. Say you're at a formal, sit-down restaurant with a waiter (a server if you will 😉). If you want food, you'll have to:

Ask the waiter for the food you want
Wait a moment for the dish to get prepared
Receive your finished plate once it's done

This is how all websites work when you first visit them. You ask for what you want (visiting a URL like https://breakfast.club), wait for the server to get back to you (loading spinner), then enjoy your "meal" once it's ready (the page is done loading! 🎉)

But what if you want to order dessert? Heading back to our restaurant scenario, you'll go through the same flow as last time:

Ask the waiter for the yummiest dessert
Hand them your dirty plates
Wait a moment for the dish to get prepared
Receive a shiny new bowl with your ice cream sundae 🍨

There's an important bit I want to reiterate there: you hand over your dirty plates, and get back a brand new one. This is why you'll see a little loading bar re-appear every time you jump to a new page. Here's an example of 11ty's documentation using server-based routing:

Watch the loading bar engage whenever we click a link

At first, it looks like you're still on the same page whenever you click those navigation links, and the browser's only refreshes the bits that change (the documentation).

🚨 But that's not really the case! Whenever you click a link, your browser is "clearing your plate" (removing everything from the page) and pulling in a fresh meal, navigation and all. So you're really reloading all those pieces of navigation every time you visit a new page, even if they were already on your plate to begin with.

Wait, is that wasteful?

It may sound like the browser's doing a lot of extra work here! Although this is still an issue that SPAs can help with, it's not as problematic as it used to be. Here's a few efficiency points to consider:

1. HTML is super cheap to load and render

Even though the browser is "re-painting" the page from scratch every time, it only takes a few milliseconds to load that HTML skeleton. The truly expensive bits are the styles, scripts, and images the browser needs to fetch, which leads us to...

2. Shared resources don't need to get re-loaded

For instance, say every documentation page pulls in the same CSS file: <link rel="stylesheet" href="documentation.css">. When you click another link that also pulls this CSS, the browser's smart enough to say "oh, I loaded this already! I'll just use that and apply it to the page." The same goes for images and fonts as well.

💡 Note: This is all thanks to caching. If you want to go deeper, the Remix team has an excellent walkthrough on caching documents, resources, and more over here 😄

So the actual loading of these shared resources isn't a problem. But what about painting those resources to the page over and over again? This brings us to...

3. The next page only appears when it's ready

Back in the day, there was a risk you'd see a flash of white nothingness between "clearing the plate" and "receiving the new one." But modern browsers have pretty much resolved this! In short, web browsers wait for the signal that the next page isn't just "done loading," but is also ready for you to view and interact with. Think of this like bringing out your plate when it's ready to eat, instead of bringing you a plate of ingredients you have to assemble yourself.

Hibachi rendering: showing you the page painting process before it's ready to eat (it's less cool when browsers do it) 😉

This especially helps out pages that rely on blocking resources like JavaScript to render everything on the page. Here's a quick before-and-after shot by the Chrome team when they launched this concept 🚀

Source article by Addy Osmani

Disclaimer: The browser won't always wait for the next page to be interactive before showing it; It'll still show the half-finished page if you're on a slow internet connection and the browser decides it's waited too long. Still, for snappier sites like that 11ty documentation from earlier, it shouldn't be a problem!

💁 Now, let's talk single page apps

So how do SPAs compare? Well, let's revisit that restaurant example from before. When you first visit a site using the SPA approach, everything works pretty much the same:

Ask the server for the food you want (visit https://spa-breakfast.club)
Wait a moment for the dish to get prepared (browser loading spinner)
Receive your finished plate once it's done (the page is done loading! 🎉)

Now the interesting part comes when you go back for seconds. When you click a link on an SPA, it replaces the typical, server-based routing with client-side routing 😮 In other words, we process all link requests using JavaScript we wrote ourselves, instead of sending those requests to the server right away.

Here's a code snippet to get your brain moving 🧠

<a href="/desert">Go eat desert</a>
<script>
    document.addEventListener('click', (event) => {
      if (
        // if you clicked on an A-nchor tag (link)
        event.target.tagName === 'A' &&
        // and you're going to a page on this domain (like /desert)
        event.target.origin === location.origin
      ) {
        // don't ask the server for that resource!
        event.preventDefault()
        // instead, we'll go fetch the resource ourselves
        const response = fetch('https://buffet.table/desert')
        // ...convert that response to something we can work with
        const htmlString = await response.text()
        const desert = new DOMParser()
          .parseFromString(htmlString, 'text/html')

        // ...and do something with that desert element
        // ex. append desert to our "plate" in the DOM
        document.querySelector('.my-plate').appendChild(desert)
      }
    })
</script>

Pretty weird, right? This is the super-simplified crux of an SPA: you never truly "leave" the page you started on. Instead, you intercept all future requests (link clicks) and handle the fetching yourself. You'll often do this using the fetch API native to all modern browsers as demo-d above.

This is why I'd think of SPAs and clientside routing like a buffet. Instead of ordering your meal and waiting for it to get prepared, you can get out of your seat and grab that pre-prepared food yourself!

Key benefits to this approach

There are 2 major benefits to single page apps that clientside routing unlocks 🔓

First, load-time efficiency can go up 🚀 I say "can" because of all the serverside routing optimization I mentioned previously (which may cancel out any performance gains). But there is a noticeable difference for resource-hungry frameworks like React, Vue, and Svelte. All of these use some form of clientside routing to keep JavaScript load times to a minimum.

For instance, if I went from one page of a React app to another using serverside routing, the browser would re-parse and re-render the whole page using JavaScript! This can severely impact your "time to interactive," an accessibility concern you can learn more about here.

Second, you can now build dynamic, app-like interactions ⚙️ Animated page transitions are the easiest to point out here. Since you're fully in control of loading new content and applying it to the page, you can pull off all sorts of CSS trickery like cross-fades, pop-up modals, tab sliders, and more. Here's an example from my personal site using clientside routing:

🍔 A juicy visual comparison

Now that we've introduced SPAs + clientside routing as a concept, lets see a side-by-side comparison with serverside routing.

Say you receive your order for a juicy burger that's cooked medium rare, but would rather have a patty that's well done.

We'll imagine this moment as "clicking a link," requesting to go from /medium-rare-burger to /well-done-burger.

Here's what that "click" may do with a server-based approach:

Animation showing the 3 step rendering process

Then, here's how clientside routing may handle the request:

Animation showing our new 4 step rendering process

Notice that we never clear our page in the SPA approach! We just request the resource (a well-done burger), pick out the pieces we want to add to our page (the patty), and perform the DOM manipulation with JavaScript.

This doesn't have much performance benefits when we're talking HTML files. But if that HTML has some JavaScript and styles attached to it that we can also fetch (like, say, a React component), there's a lot of room for performance gains.

Wrapping up: so which should I choose?

Although SPAs seem like the "silver bullet" for any website, there's a case to be made for either approach.

The most obvious win for server-side routing is, well, it's just simpler. No need to write and maintain all those click listeners; just let the browser do the serving for you. Yes, you'll often use a framework-specific library for SPAs like React Router, but learning and updating JS libraries is always more overhead.
The second win for server-side is no accessibility worries. When you handle all the routing clientside, you run the risk of hurting screenreader and keyboard experiences. For instance, you'll need to alert screenreader users that new content has appeared on the page whenever they click a link. And for keyboard-ists, you need to make sure their focusing the right element when something new swipes into view.

☝️ But if you're addressing these concerns confidently (or using a robust library to do it for you), SPAs are a great way to go!

Learn a little something?

Glad to hear it! If you want more universal solutions like this, you can sign up for the web wizardry newsletter for some bi-weekly web sorcery 🔮

Grabbing subsets of JS object properties with... GraphQL?

Ben Holmes — Tue, 08 Jun 2021 13:38:41 +0000

Messing with JavaScript objects is pretty easy these days. Destructuring syntax is convenient and the spread ... operator helps with merging objects together. But what about grabbing just... a portion of an object?

This question deserves some visuals. Let's jump into the problem we're trying to solve, and a flexible solution we can add to any existing JavaScript project 💪

What we want

Say I have a big document of structured data. Without manually writing a new object by hand, I just want to pull the little slices that I actually care about.

Here's one such scenario:

In this case, we want a copy of our original fridge, but we only care about those isEdible subkeys.

My gut reaction is to reach for some declarative tools in my ES6 arsenal. Object destructuring comes to mind at first:

const whatsInMyFridge = {
  weekOldPasta: {
  ...
}
const { weekOldPasta: { isEdible: pastaIsEdible },
    panSearedSalmon: { isEdible: panSearedSalmonIsEdible }
    } = whatsInMyFridge

There's a few issues with this:

We can't easily destructure keys of the same name. Notice I had to convert each isEdible variable to the verbose pastaIsEdible and panSearedSalmonIsEdible
Destructuring leads to some pretty gnarly code as it gets more complex. Just with a few keys, we're already hitting multi-line { curly hell }.

And most of all, we still have to build our new object at the end! Our destructuring statement actually just made some one-off variables for each key in the object. We'll still have to do this:

const whatsEdible = {
  weekOldPasta: {
    isEdible: pastaIsEdible,
  },
  panSearedSalmon: {
    isEdible: panSearedSalmonIsEdible,
  }
}

...which is hardly better than just writing the object from scratch 😢

What we really want is some magical syntax for just the keys we want to retrieve. Something like this really:

whatsInMyFridge.giveMeTheseKeys({
    weekOldPasta {
        isEdible
    },
    panSearedSalmon {
        isEdible
    }
}) // -> a beautiful formatted JS object

📈 Enter: GraphQL

If you've worked with GraphQL before, you probably noticed how close that example comes to a GraphQL query!

A brief rundown for those unfamiliar: GraphQL is a "querying" language originally built for API calls. It was mainly born from the frustrations with REST requests, as API endpoints had to predict all the data a client might want to retrieve.

GitHub recently migrated to GraphQL because of this. Imagine this scenario:

User A wants to get information about their GitHub profile. They want to send off a username and get back the accounts name and profile picture
User B also wants some GitHub profile info. However, they're looking for a different set of info: the list of user recovery emails and their personal bio.

As you could imagine, User C might want a new combination of fields, as might users D-Z. So instead of returning a massive JSON payload to satisfy everyone, GitHub exposed a GraphQL API for you to describe exactly which fields you want.

Here's how User A might request a name and profile picture as part of their request body
This is from demo purposes, and won't actually work if you send to GitHub

{
    userProfile(email: '10xengineer@genius.club') {
        name
        picture {
            src
            alt
        }
    }
}

...And GitHub will "fill in the blanks" by providing values to those requested keys. As you can imagine, this syntax is flexible enough to use on any blob of JSON you want to filter down 👀

📖 Applying GraphQL to reading JSON objects

💡 TLDR: If you want the final solution without all the walkthrough, jump down to the finished product!

Let's figure out how to use that fancy syntax for our use case. The biggest question to resolve is "how do we interpret a GraphQL query in JS land?" Sadly, there isn't a nice "plain JS" solution, so we will be reaching for a library here.

Go ahead and install this graphql-query-to-json package. It does have a fair amount of sub-dependencies like the core graphql package and the complimentary json-to-graphql-query, so if that bothers you... my apologies 😢

Let's see what we get from our old "what's edible in my fridge" request:

const { graphQlQueryToJson } = require("graphql-query-to-json")
// or if you prefer: import { graphQlQueryToJson } from 'graphql-query-to-json'

const asJson = graphQlQueryToJson(`{
  weekOldPasta {
    isEdible
  }
  panSearedSalmon {
    isEdible
  }
}`)
console.log(asJson)
/* 👇
{
  query: {
    weekOldPasta: { isEdible: true },
    panSearedSalmon: { isEdible: true }
  }
}
*/

Neat! Toss in a string, get back a JS object. You'll notice that it wraps our requested object with the query key. This would be useful if we were sending this request to an API, but for our purposes, we'll just ignore that key in our helper function. It also stubs out any unknown key values with true, which we'll use to track down unfilled values later 👀

Traversing our query

With this JS object in hand, it's time to walk through all the keys and figure out which values to fill in. Let's start with a simple example that only goes 1 level of keys deep:

const myFridge = {
    numEggs: 5,
    pintsOfIceCream: 3,
    degreeUnits: 'celsius',
}
const whatIWant = `{
    numEggs
    degreeUnits
}`
// grab the ".query" straight away, since we won't need that nested key
const whatIWantAsJson = graphQlQueryToJson(whatIWant).query
// 👉 { numEggs: true, degreeUnits: true }

Now we have our set of keys (numEggs and degreeUnits) each with a value of true. To assign our actual values in place of those true flags, we can

loop through all the object keys in whatIWantAsJson, and
assign values from the same key in myFridge.

// loop over the object keys...
for (const key of Object.keys(whatIWantAsJson)) {
    // and if that key has a value of "true"...
    if (whatIWantAsJson[key] === true) {
        // replace "true" with the value from myFridge
        whatIWantAsJson[key] = myFridge[key]
    }
}
console.log(whatIWantAsJson)
// 👉 { numEggs: 5, degreeUnits: 'celsius' }

Handling nested objects

This basic loop handles 1 level of nesting. But what if we have a request like this?

{
  // level 1
  weekOldPasta {
    // level 2
    isEdible
  }
  ...
}

For this, we'll need a way to run our loop over Object.keys for every level of keys in our object. Get ready to put on your computer science hat, because we're using recursion 😨

Pay attention to this new else statement we're adding:

// wrap our loop in a function we can call
function assignValuesToObjectKeys(whatIWant, myFridge) {
    for (const key of Object.keys(whatIWant)) {
        if (whatIWant[key] === true) {
            whatIWant[key] = myFridge[key]
        } else {
            // if the value isn't "true", we must have found a nested object
            // so, we'll call this same function again, now starting from
            // the nested object inside whatIWant
            assignValuesToObjectKeys(whatIWant[key], myFridge[key])
        }
    }
}

This is a classic example of a recursive function. We have 2 clauses here:

The base case: When we hit a value of true, we stop looking for nested objects
The recursive function call: When we haven't hit the "base" of our nested object, keep drilling down the chain of nested keys using the same function

With this in place, we have a reusable JS function for anywhere in our codebase 🥳

const myFridge = {  
    weekOldPasta: {  
        noodleSogginess: “high”,  
        numMeatballs: 4,  
        isEdible: false,  
    },  
    panSearedSalmon: {  
        oilUsed: “avocado”,  
        numSpices: 3,  
        isEdible: true,  
    }
}

const whatIWant = graphQlQueryToJson(`{
  weekOldPasta {
    isEdible
  }
  panSearedSalmon {
    isEdible
  }
}`).query

assignValuesToObjectKeys(whatIWant, myFridge)
console.log(whatIWant)
/* 👉 {
    weekOldPasta: {
        isEdible: false,
    },
    panSearedSalmon: {
        isEdible: true,
    },
}
*/

Cleaning this up a little

You'll notice that our assignValuesToObjectKeys function doesn't return anything; it just modifies the whatIWant object we passed in. For added readability, we might add a wrapper function to handle the graphQlQueryToJson call and actually return our requested object:

function grabPartialObject(originalObject = {}, query = "") {
    const whatIWant = graphQlQueryToJson(query).query
    assignValuesToObjectKeys(whatIWant, originalObject)
    return whatIWant
}
...
const whatsEdible = grabPartialObject(myFridge, `{
  weekOldPasta {
    isEdible
  }
  panSearedSalmon {
    isEdible
  }
}`)
console.log(whatsEdible) // gives us the same object as before!

Handling arrays

So we've conquered nested objects. But what if we have an array of objects that we want to filter?

For instance, say our fridge data was structured just a bit differently:

const myFridge = {
  food: [
    {
      name: 'Week old pasta',
      noodleSogginess: 'high',
      numMeatballs: 4,
      isEdible: false,
    },
    {
      name: 'Pan Seared Salmon',
      oilUsed: 'avocado',
      numSpices: 3,
      isEdible: true,
    },
  ],
}

...and we just care about the name and isEdible keys for every object in that array. Following how GraphQL requests normally work, we'd expect this sort of syntax to work:

{
    food {
        name
        isEdible
    }
}

In other words, treat food like it's a regular object in the request, and we'll be smart enough to handle arrays of data.

This answer is a bit more involved than our previous examples. So, I'll leave you with a thoroughly commented codeblock:

function assignValuesToObjectKeys(whatIWant, myFridge) {
  for (const key of Object.keys(whatIWant)) {
    if (whatIWant[key] === true) {
      ...
      // 👇 If the fridge data happens to be an array...
    } else if (Array.isArray(myFridge[key])) {
      // first, keep track of the object they requested
      const originalRequest = whatIWant[key]
      // then, create an array where that request used to be
      // for us to "push" new elements onto
      whatIWant[key] = []
      // loop over the items in our array of food...
      for (const fridgeItem of myFridge[key]) {
        // make a variable to store the result of assignValuesToObjectKeys
        // we use { ...originalRequest } here to create a "copy"
        const requestedItem = { ...originalRequest }
        // grab the keys we want out of that array element
        assignValuesToObjectKeys(requestedItem, fridgeItem)
        // then, push our shiny new object onto our running list
        whatIWant[key].push(requestedItem)
      }
    } else {
      ...
    }
  }
}

That's a fair amount of code! To briefly summarize, you'll need to:

Check when our actual data is an array, rather than a simple object
Loop over the actual data and assignValuesToObjectKeys for each one
Push the results onto a running array in whatIWant, with necessary helper variables to keep track of your original request

🚀 The finished product

Here's how our finished product looks! I've renamed myFridge 👉 actualObj and whatIWant 👉 requestedObj so our naming conventions are more universal. I also added a hasOwnProperty check to assert we're requesting a key that actually exists. If not, raise an exception.

Remember, you'll need to add the graphql-query-to-json package package to your project for this to work.

const { graphQlQueryToJson } = require("graphql-query-to-json")

function assignValuesToObjectKeys(requestedObj, actualObj) {
  for (const key of Object.keys(requestedObj)) {
    if (!actualObj.hasOwnProperty(key)) {
        throw `You requested a key that doesn't exist: ${key}`
    } else if (requestedObj[key] === true) {
      requestedObj[key] = actualObj[key]
    } else if (Array.isArray(actualObj[key])) {
      // keep track of the object they requested
      const originalRequest = requestedObj[key]
      // then, create an array where that request used to be
      // for us to "push" new elements onto
      requestedObj[key] = []
      for (const actualItem of actualObj[key]) {
        // make a variable to store the result of assignValuesToObjectKeys
        // we use { ...originalRequest } here to create a "copy"
        const requestedItem = { ...originalRequest }
        assignValuesToObjectKeys(requestedItem, actualItem)
        requestedObj[key].push(requestedItem)
      }
    } else {
      console.log(requestedObj[key])
      // if the value isn't "true", we must have found a nested object
      // so, we'll call this same function again, now starting from
      // the nested object inside requestedObj
      assignValuesToObjectKeys(requestedObj[key], actualObj[key])
    }
  }
}

// 👇 Function you'll actually `export` for others to use
function grabPartialObject(actualObj = {}, query = '') {
  const requestedObj = graphQlQueryToJson(query).query
  assignValuesToObjectKeys(requestedObj, actualObj)
  return requestedObj
}

Usage example

const { grabPartialObject } = require('./some/helper/file')

const myFridge = {  
    weekOldPasta: {  
        noodleSogginess: “high”,  
        numMeatballs: 4,  
        isEdible: false,  
    },  
    panSearedSalmon: {  
        oilUsed: “avocado”,  
        numSpices: 3,  
        isEdible: true,  
    }
}

const whatsEdible = grabPartialObject(myFridge, `{
  weekOldPasta {
    isEdible
  }
  panSearedSalmon {
    isEdible
  }
}`)
console.log(whatsEdible)
/* 👉 {
    weekOldPasta: {
        isEdible: false,
    },
    panSearedSalmon: {
        isEdible: true,
    },
}
*/

Learn a little something?

Glad to hear it! If you want more universal solutions like this, you can sign up for the web wizardry newsletter for some bi-weekly web sorcery 🔮

Sexy, accessible show-hide animations in any web framework

Ben Holmes — Mon, 24 May 2021 23:18:22 +0000

Using JS to show and hide something is a web dev rite of passage. Heck, it's the first demo that comes to mind when you think about "state management" (just behind building a counter 😆).

But when you do the classic "hide whenever X variable is false," there's some accessibility concerns you might be forgetting:

can keyboard users still access that hidden element?
do screen readers actually know what your button is trying to show and hide?

Don't worry, I have the answers for you! Let's explore a universal solution you can bring to React, Svelte, Vue, etc, along with some debugging tips using a real screen reader 🚀

Starting with a naive solution

Okay, wait, why isn't this post a 2 minute read? I just whipped up this fade transition in a CodePen and it works great!

If you don't recognize this meme, go culture yourself

I'll admit that a simple opacity shift works pretty well for non-interactable elements like this img. But what if you're showing and hiding clickable elements, like a navigation bar of links?

This can spell problems for those using keyboard navigation or screenreaders. It's (embarrassingly) a problem across some of my own sites that I'm working to fix, but it can be tricky to debug.

Here's an example of hitting the tab key through our Hack4Impact.org site. I've adjusted the dropdown overlay to opacity: 0.1 to show which items are focused, but you can expect the same behavior for opacity: 0:

Follow either the focus ring around the elements, or the activeElement query in the console view (which prints the element being focused)

Uh oh, I'm still able to focus and select these links! What's more, our opacity solution poses a problem for visually impaired users, since they won't know that our visual opacity shift really means showing and hiding a dropdown.

What we really want is the best of all worlds:

A nifty fade in-and-out animation for sighted users
The ability to focus interactable links and buttons only when the element is revealed
A callout for screenreaders whenever we show and hide something

⌨️ Let's accommodate keyboard users

Note: This section only applies when showing / hiding interactable elements like a list of links.

Focusing on that tab key first, we need to find a way to make sure that a not-so-visible element can't be accessed at all.

You might remember a nifty property for this already: display: none. This makes element nonexistent in the document, right?

Well it's worth a shot! Let's toggle to display: none when our element is hidden, and add display alongside opacity in our list of transitions.

We'll be using this basic navigation dropdown as fuel for the rest of our code examples. Nothing fancy on the JS + HTML sides! The important piece are those .dropdown and .dropdown.expanded selectors in our CSS. That's where we toggle between our display states like so:

.dropdown {
    opacity: 0;
    display: none;
}
.dropdown.expanded {
    opacity: 1;
    /* since we're using flexbox in our dropdown */
    display: flex;
    /* to (hopefully) fade from expanded to collapsed in 0.2 seconds */
    transition: opacity 0.2s, display: 0.2s;
}

Full example:

But wait, where's our fade transition? Sorry to say this is the big limitation of the display property: it cannot be used in CSS transitions ( full list of animatable CSS properties here) This means, when we toggle off our expanded class, it immediately switches to display: none (ignoring our 0.2s transition) before our opacity has time to sexily fade out 😥

What we need is a way to toggle off display only after our element fades out of view. And no, we can't use keyframes to set up this sequence (here's the code you were probably about the try 😉). But fear not! There's a neat property called visibility that can do exactly what we want. Just hot swap display: none for visibility: hidden and update the transition:

And BAM! Our fade animation remains in-tact, but we've successfully hidden our element from keyboard-ists 👍

You can click on that CodePen preview above and start hitting tab to test our solution. Your focus should immediately jump from the hamburger button to the CodePen zoom controls, instead of trying to focus those invisible links. And once you focus the button, hit space, and start tabing through, those links become selectable.

💡 Note: There is 1 subtle difference between display: none and visibility: hidden. When using the former, an element gets completely removed from the document, so any elements next to it will shift to take up the space it left behind. By contrast, visibility: hidden just hides the element visually, while leaving the gap for where it used to sit. This prevents your website layout from shifting around when you toggle elements on and off.

👁 Let's accommodate screen readers

Okay, so we know what our website looks like... but what does it sound like? 🤔

Well, I'd recommend breaking out a screen reader for this next part! You can reach for the VoiceOver tool if you're running MacOS, but there's also a screen reader for Chrome you can try on any computer.

If you're interested, you can follow along with this video walkthrough to see the VoiceOver tool in action 👇

Communicating toggle states with `aria-expanded`

Our navigation toggle button is the first issue to address. If you try expanding and collapsing our menu as-is, the screenreader won't read anything new to the user. This is because, well, it's a plain old button at the moment. We need to tell our reader that it's actually an on-off toggle.

We can pull this off by adding an aria-expanded attribute to our button. This boolean should call out whether our menu is in the "expanded" or "collapsed" state. Just set the initial state in our HTML:

<!-- collapsed by default -->
<button aria-expanded="false" aria-label="Nav toggle" class="toggle-dropdown">

And keep that value up-to-date wherever we're tracking button clicks. Here's a basic version for plain-JS:

const toggle = document.querySelector(".toggle-dropdown");
toggle.addEventListener("click", () => {
  // toggle our CSS class
  dropdown.classList.toggle("expanded");
  // and if our "expanded" class is turned on...
  if (dropdown.classList.contains("expanded")) {
    // set aria-expanded to true
    toggle.setAttribute("aria-expanded", "true");
  } else {
    // otherwise it's false
    toggle.setAttribute("aria-expanded", "false");
  }
});

VoiceOver output as we toggle our button. Notice we get a new announcement for every click saying either "expanded" or "collapsed"

You can also add the attribute aria-haspopup="true" to your button. This will just added the word "popup" to the screenreader output to make behavior just a bit more understandable. Optional, but recommended!

Focusing our dropdown on expanded

Note: This should only be used when showing / hiding interactable elements. If you're just revealing images or paragraphs, the aria-expanded piece should be sufficient!

So now we're telling the user that they're expanding and collapsing something. But what is this something their actually toggling?

Sadly, there's no straightforward way to tell the user "you just expanded my fancy dropdown!" There is an aria-controls attribute you can try, but it's only supported by the premium JAWS screen reader (which many users don't have access to).

So, we're going to offer the next best thing: just focus the first element in our dropdown to read out the contents immediately. This means shifting keyboard focus (yes, visually impaired users tend to navigate navigate using a keyboard) from our menu button to our first link whenever aria-expanded="true". Of course, this only applies when revealing interactable elements like buttons or links, so it should

Should be simple enough! Just add a call to focus() whenever we expand the element, right?

toggle.addEventListener("click", () => {
  if (dropdown.classList.contains("expanded")) {
    // use firstElementChild to grab the first link
    dropdown.firstElementChild.focus()
    toggle.setAttribute("aria-expanded", "true");
  } else {
      ...
});

Well, this doesn't work super reliably when we have our fancy CSS transition. There's a chance we'll try to focus the first link while visibility is still hidden, which prevents our focus() call from going through 😕

Luckily, there's an easy way to "wait" on our CSS transition to finish before setting focus. We just need to listen for the transitionend event on our dropdown like so:

dropdown.addEventListener('transitionend', () => {
  if (dropdown.classList.contains("expanded")) {
    // instead of calling focus() in our 'click' listener,
    // we'll call it from here!
    dropdown.firstElementChild.focus()
  }
})

With this in place, we should get reliable link focusing with a matching screen reader output 👍

Finished product

⚙️ Applying this to your favorite framework

We've covered a lot of ground using plain JS, but it's quick-and-easy to apply to any component framework!

We just need a couple pieces:

an expanded state variable to keep track of showing / hiding
a callback to focus() our first dropdown element on transitionend. For most frameworks, we can just attach a callback function to an element's onTransitionEnd attribute.

A simple React solution

import { useState } from "react";

export default function DropdownExample() {
  const [expanded, setExpanded] = useState(false);
  const focusFirstDropdownLink = ({ target }) => {
    // if we apply this function to our dropdown,
    // the "target" should be a reference to the dropdown itself!
    target.firstElementChild.focus();
  };
  return (
    <>
      <nav>
        <button
          className="toggle-dropdown"
          aria-expanded={expanded}
          aria-haspopup="true"
          aria-label="Nav toggle"
          onClick={() => setExpanded(!expanded)}
        >
          ...
        </button>
      </nav>

      <div
        {/*toggle our "expanded" CSS class*/}
        className={expanded ? "dropdown expanded" : "dropdown"}
        {/*trigger our focus() once the dropdown's fade effect finishes*/}
        onTransitionEnd={focusFirstDropdownLink}
      >
        <a href="/">Home</a>
        <a href="/about">About</a>
        <a href="/projects">Projects</a>
        <a href="/contact">Contact</a>
      </div>
    </>
  );
}

Pretty straightforward rewrite! The ability to bind our focus() function to the onTransitionEnd listener saves us a lot of work. We don't even need a useRef to grab the element, in fact.

Here's a working sandbox demo for you to try 🚀

Svelte example

This should be equally trivial in Svelte:

<script>    
    let expanded = false;

    const focusFirstDropdownLink = ({ target }) => {
        // again, "target" should be a reference to our dropdown
        target.firstElementChild.focus()
    }
</script>

<style>
...
</style>

<nav>
    <button class="toggle-dropdown" aria-expanded={expanded} aria-haspopup="true" aria-label="Nav toggle" on:click={() => expanded = !expanded}>
        <svg viewBox="0 0 448 512" width="100" title="bars">
      <path d="M16 132h416c8.837 0 16-7.163 16-16V76c0-8.837-7.163-16-16-16H16C7.163 60 0 67.163 0 76v40c0 8.837 7.163 16 16 16zm0 160h416c8.837 0 16-7.163 16-16v-40c0-8.837-7.163-16-16-16H16c-8.837 0-16 7.163-16 16v40c0 8.837 7.163 16 16 16zm0 160h416c8.837 0 16-7.163 16-16v-40c0-8.837-7.163-16-16-16H16c-8.837 0-16 7.163-16 16v40c0 8.837 7.163 16 16 16z" />
    </svg>
    </button>
</nav>

<!--Note we can use class:expanded to bind our "expanded" CSS class to the "expanded" state variable-->
<div class="dropdown" class:expanded on:transitionend={focusFirstDropdownLink}>
    <a href="/">Home</a>
    <a href="/about">About</a>
    <a href="/projects">Projects</a>
    <a href="/contact">Contact</a>
</div>

Here's another working sandbox demo for you to try 🚀

Learn a little something?

Glad to hear it! If you want more universal solutions like this, you can sign up for the web wizardry newsletter for some bi-weekly web sorcery 🔮

Want CSS variables in media query declarations? Try this!

Ben Holmes — Wed, 12 May 2021 13:59:51 +0000

If you're like me, you've probably been stretching CSS variables / custom properties to their limits while building your own design systems. But this "silver bullet" can lead to a nasty roadblock: you can't use them in media query declarations.

To clarify, this is the behavior you might be after:

:root {
    --mobile-breakpoint: 600px;
    --tablet-breakpoint: 900px;
}

@media(max-width: var(--mobile-breakpoint)) {
    .obligatory-hamburger-menu { visibility: visible }
}

...which sadly won't work 😣

🙅 Why var() can't work in a @media declaration

This may seem confusing at first. If our variables are available at the :root of the page, why can't a media query access them?

Well, it comes down to what the :root element actually means: the root element of the HTML document. But conceptually, media queries aren't attached to HTML elements at all. These declarations are processed while your CSS is being parsed, so it won't know to look to the :root and pull in the variable values.

If this seems confusing, let's consider a CSS variable like this one on the body element:

body {
    --mobile-breakpoint: 600px;
}
@media(max-width: var(--mobile-breakpoint)) {...}

Clearly, our @media query doesn't know about this --mobile-breakpoint variable since it doesn't "belong" to the body element. Heck, it doesn't belong to any element in your HTML, which explains why our :root solution won't work either.

Sass / SASS can make this even more confusing by allowing @media blocks to be "nested" inside other rulesets. Don't be fooled! When your lovely Sass gets compiled, those media queries float right back out to the base of your CSS document.

Hope on the horizon for CSS "environment" variables

As luck would have it, the W3C isn't happy about this limitation either. Their proposal for "environment" variables is at the earliest stage right now (phase 1 as of May 2021), but it seems to tackle this very issue!

I'll avoid showing you the syntax since it'll likely change overtime. Just know it's meant to address variables that exist beyond the HTML element level for use cases like @media declarations.

🤔 Workarounds you can try

If you want media query variables and want them now, there's a few options available to you.

For Sass / SCSS users

The first is what I'd recommend to existing Sass users: fall back to Sass variables for media queries, and use CSS variables everywhere else.

This is because, unlike CSS variables, Sass variables don't "belong" to CSS rulesets under-the-hood; They're just a piece of syntactical sugar for SASS to pick up and "paste" in the correct value. Just know that you'll need to fall back to Sass for math calculations as well instead of using the calc() function (because this isn't valid either!)

/* ✅ good */
@media(max-width: $mobile-breakpoint + 50px) {...}
/* ❌ bad */
@media(max-width: calc($mobile-breakpoint + 50px)) {...}

For anyone else

If you either don't use Sass or don't want 2 different syntaxes for your variables, there's a neat PostCSS plugin you can try too. Just tack this onto an existing CSS build step (or introduce a build step against your will 😣) and BAM! CSS variables and the CSS calc() function will work in your media query declarations 👍

⚠️ Word of caution on this solution though. You'll be writing invalid CSS by current browser standards and making it valid, which can look pretty confusing to new codebase contributors. At least be sure to document this plugin in your project README if you decide to go this route.

Learn a little something?

Glad to hear it! If you want more universal web dev solutions like this, you can sign up for the web wizardry newsletter for some bi-weekly knowledge nuggets 🧠

Picture perfect image optimization for any web framework

Ben Holmes — Wed, 05 May 2021 14:03:35 +0000

If you've been building websites for a while, "optimize your images" probably sounds like "eat your veggies." It's good for your website's health, it'll make your SEO big and strong... but compressing every image by hand doesn't sound appetizing to me 🤢

So we're going to talk easy wins for 1) optimizing image file formats and sizes with the picture element, and 2) an automation process using 11ty that you can take with you to your build setup of choice 💪

💁 Intended audience: This is meant for developers building "template-driven" static sites (11ty, Jekyll, Hugo, plain HTML) or "component-driven" web apps (NextJS, Gatsby, etc). If you're working with site builders like Wordpress or Shopify, this probably isn't the article for you!

🥦 So what's wrong with my images right now?

To show what's at stake, here's the lighthouse rating from one of my recent blog posts (images compressed with tinyJPG mind you!)

Yikes! 10 seconds to grab all those images? Chromium definitely does some throttling to test on "slower" internet connections, but it's clear those KB rating are quite high (especially for mobile users).

This just to show that there's much more to image optimization than compression! There's also:

Serving the right format, with JPGs preferrable and .webp or .avi especially so
Serving the right size, ideally with multiple copies of the same image at different widths and heights
Loading at the right time, reaching for "lazy" loading when we can
Heck, even including alt text can affect your site from both accessibility and SEO standpoints!

I learned a bit about addressing those format and size problems using picture elements, and my lighthouse definitely thanked me for it 😄

// Detect dark theme var iframe = document.getElementById('tweet-1378869249930842116-45'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1378869249930842116&theme=dark" }

🌅 Fixing format + size problems with the `picture` element

So how can we deliver different image files for the right people? Well, let's start with a humble image element like this one:

<img src="/assets/mega-chonker.jpg" width="1000" height="600" alt="A perfectly sized cat" />

Refer to this handy chart for understanding "chonk" levels

Now, say we've opened our image editor and saved a smaller version for mobile users sitting at, say, 600 pixels wide. You could probably set up some CSS to hot-swap your images depending on your screen width:

<img class="desktop" src="/assets/chonker-1000w.jpg"
    width="1000" height="600" alt="A perfectly sized cat" />
<img class="mobile" src="/assets/chonker-600w.jpg"
    width="600" height="300" alt="A perfectly sized cat" />

@media(max-width: 600px) {
  .desktop { display: none; }
}
@media(min-width: 601px) {
  .mobile { display: none }
}

...But this isn't very scalable. What if we're, say, working in a markdown file where we can't append class names? Or we have different formats we want to switch between depending on browser support (JPEG vs WEBP for example)?

This is where the picture element comes in. Take this example here:

<picture>
  <!-- List out all the WEBP images + WEBP sizes we can choose from -->
  <source type="image/webp"
    srcset="/assets/chonker-600w.webp 600w, /assets/chonker-1000w.webp 1000w"
    sizes="100vw">
  <!-- In case a browser doesn't support WEBP, fall back to this set of JPG sources -->
  <source type="image/jpeg"
    srcset="/assets/chonker-600w.jpg 600w, /assets/chonker-1000w.jpg 1000w"
    sizes="100vw">
  <!-- The actual, style-able img element that "receives" these sources -->
  <!-- Also includes a default src in case no <source> can be applied -->
  <img src="/assets/chonker-600.png" alt="A perfectly sized cat" />
</picture>

Some big takeaways:

We can wrap our image tags in a picture to unlock a "switch" case of sorts, with your browser picking the first source element that it's able to render. But admittedly, most modern browsers will reach for those shiny .webp files listed under type="image/webp" without needing the JPG fallbacks (current browser support here).
Each source has a srcset property, which takes in a list of source URLs for a given image format. These sources are comma-separated, plus a pixel-value width using that w on the end. The browser will then decide which source to use based on the sizes property (more on that in the next section)
Picture elements are not images themselves! This is an interesting gotcha when you start trying to style those images. So, you'll want to keep putting all your image-specific CSS (ex. object-fit) on that img element instead of the picture.

The `sizes` attribute

Sizes is an interesting beast. It almost looks like CSS actually, with some small syntax differences.

Remember those mobile and desktop helper classes from earlier? Well, sizes let us do something rather similar.

Key takeaways from the video:

In general, the sizes attribute is a way to tell the browser which image to use for a given screen size.

Let's say we have a banner image that takes up the full width of the screen for mobile users, but we have a table of contents that takes up half the width at 500px wide and above.

Putting on our CSS hat, this means our image is 100vw (100% screen width) below 500px, and 50vw when we hit @media (min-width: 500px). This perfectly translates to sizes 👉 sizes="(min-width: 500px) 50vw, 100vw"

And in the context of a picture element:

<picture>
  <!--stack up your media queries as sizes, delineated by commas ","-->
  <source type="image/webp"
    srcset="/img/6dfd7ac6-600.webp 600w, /img/6dfd7ac6-900.webp 900w..."
    sizes="(min-width: 500px) 50vw, 100vw">
  <img alt="Blue and purple cluster of stars" src="/img/6dfd7ac6-600.jpeg">
</picture>

As a rule-of-thumb, you should probably use 100vw as a "base case" for smaller devices, and rack up media queries on top depending on how your layout changes. This does mean sizes will be different depending on the context your images are living in, so look out for that if you're using a component-based framework!

Note: You may be wondering why browsers can't do all this work for us. Well, this comes down to the unpredictable nature of "width" when you're throwing around CSS everywhere. If you're like me, you tend to use a lot of percentages like width: 100% for image blocks, which may adjust depending on the container, padding, margins, etc that get applied. If the browser tried to decipher all this styling before loading an image, you'd be waiting a lot longer than you might want!

Respecting HD displays

Note that our screen's pixel density can also affect which image gets picked from a given srcset. For high-density mobile displays, it'll actually choose an image that's roughly double the width you specify! Say we have a simple picture declaration like this for instance:

<picture>
  <source type="image/webp"
    srcset="/img/galaxy-600.webp 600w, /img/galaxy-1200.webp 1200w"
    sizes="100vw">
</picture>

We're using 100vw here, so the browser should match the image source's width to the width of the display. Intuitively, we'd think that a 600px wide display would receive /img/galaxy-600.webp... but for HD displays like Macbooks or modern smartphones, it'll actually reach for an image at 600 x 2 pixels wide (/img/galaxy-1200.webp 1200w in this case). So when you're generating multiple image sizes, always reach for those higher values 💡

🔨 Applying this to your site with 11ty image

Alright, so we see how useful the picture element can be... but it's only as powerful as the pictures we can supply to it. Do we really want to create all those beautifully resized, optimized, multi-format images by hand?

Luckily, there's a lot of tools to handle this process for us, and I'm going to hone in on the simplest I've found: 11ty's image plugin.

🚨 Now before you start scrolling to the next section, no, you don't need to build your site with 11ty to use this. Playing around with this tool, I realized it's perfect for generating optimized images on-the-fly for any use case, no command line prowess required 🔥

Generating optimized images

Let's play along at home! Seriously, drop everything and go open your code editor 🧑‍💻 Then, make a fresh directory / folder and create a basic package.json. We'll be installing the @11ty/eleventy-img dependency:

mkdir woah-11ty-image-is-cool && cd woah-11ty-image-is-cool
npm init -y # Make a package.json with defaults for everything
npm i @11ty/eleventy-img

Now make a random JavaScript file for us to play with (I'll call mine image-generator.js). Inside, just paste the example code at the top of 11ty's documentation:

const Image = require("@11ty/eleventy-img");

(async () => {
  let url = "https://images.unsplash.com/photo-1608178398319-48f814d0750c";
  let stats = await Image(url, {
    widths: [300]
  });

  console.log(stats);
})();

Hm, this looks pretty straightforward. Let's run it from our terminal and see what happens:

node ./image-generator.js

With any luck, you should see a couple new faces appear:

A /img directory with 2 images inside: 1 JPG picture of a galaxy that's 300 pixels wide, and a matching webp image of the same size. Notice how this matches up with our widths array from the code snippet 👀
A /cache directory with some strings of characters. Think of this like a note-to-self for the plugin about the image we downloaded. It's expensive to download images off the internet, so to avoid loading it every time we run the script, 11ty checks the cache to see if we've already loaded the image in the past 👍

You'll also see a blob of "stats" logged to your console. Most of these properties are self-explanatory, and some should look familiar from our picture walkthrough earlier on (namely the sourceType and srcset attributes). We even get the output size of the image in bytes, in case you want to inspect the differences between formats and sizes.

But wait, there's more! Let's try experimenting with different widths and formats:

...
let stats = await Image(url, {
  widths: [300, 1000, 1400],
  formats: ['jpg', 'webp', 'gif']
});
...

We should get a plethora of resolutions inside that img directory. As you can imagine, this is perfect for our picture element from earlier. You can whip up all the sources and size attributes by hand as a learning exercise...

Automating our picture elements

...Or let the plugin do this for us! Along with that handy array of stats, 11ty image will splice everything into a valid <picture> element. All we need is a call to the generateHTML helper:

const Image = require("@11ty/eleventy-img");

(async () => {
  let url = "https://images.unsplash.com/photo-1608178398319-48f814d0750c";
  let stats = await Image(url, {
    widths: [300, 1000, 1400]
  });
  const html = Image.generateHTML(stats, {
    alt: "A blue and purple galaxy of stars", // alt text is required!
    sizes: "100vw" // remember our training with "sizes" from earlier...
  })

  console.log(html);
})();

With any luck, we should see a beautiful picture we can use anywhere on our site:

<picture>
    <source type="image/webp"
          srcset="/img/6dfd7ac6-300.webp 300w, /img/6dfd7ac6-1000.webp 1000w,
                  /img/6dfd7ac6-1400.webp 1400w"
          sizes="100vw">
    <source type="image/jpeg"
          srcset="/img/6dfd7ac6-300.jpeg 300w, /img/6dfd7ac6-1000.jpeg 1000w,
                  /img/6dfd7ac6-1400.jpeg 1400w"
          sizes="100vw">
    <img alt="A blue and purple galaxy of stars" src="/img/6dfd7ac6-300.jpeg" width="1400" height="1402">
</picture>

Going further

This plugin has a whole host of extra options to explore too, like

messing with cache options for faster build times
generating image stats + picture elements synchronously, so you don't have wait for the images to actually get generated
fine-tuning the Sharp image processor to tweak the output to your needs

📣 Using 11ty image with any framework

If all this <picture> madness excites you, go throw this 11ty image plugin at your own /assets directory! I wrote this handy little script to crawl all the images in a directory (not recursively mind you) and spit out some optimized files:

const Image = require('@11ty/eleventy-img')
const { readdir } = require('fs/promises') // node helper for reading folders
const { parse } = require('path') // node helper for grabbing file names

;(async () => {
  const imageDir = './images' // match this to your assets directory
  const files = await readdir(imageDir)
  for (const file of files) {
    const stats = await Image(imageDir + '/' + file, {
      widths: [600, 1000, 1400], // edit to your heart's content
      filenameFormat: (id, src, width, format) => {
        // make the filename something we can recognize.
        // In this case, it's just:
        // [original file name] - [image width] . [file format]
        return `${parse(file).name}-${width}.${format}`
      },
    })
    console.log(stats) // remove this if you don't want the logs
  }
})()

If you happen to use 11ty on your personal site (or at least want to try), you can automate the picture element insertion as well. Their guide covers building your own "shortcode" function to insert the right picture for every unoptimized image on your site.

Even without this luxury though, this script is a great addition to any JS-based build step. Here's a basic Image component I could slap into any React app based on that script above:

// consider using TypeScript for checking all these props!
const Image = ({ fileName, sizes, ...imageProps }) => (
    <picture>
      <source
        type="image/webp"
        srcSet={`/img/${fileName}-600.webp 600w, /img/${fileName}-1000.webp 1000w, /img/${fileName}-1400.webp 1400w`}
        sizes={sizes}
      />
      <source
        type="image/jpeg"
        srcSet={`/img/${fileName}-600.jpeg 600w, /img/${fileName}-1000.jpeg 1000w, /img/${fileName}-1400.jpeg 1400w`}
        sizes={sizes}
      />
      <img src={`/img/${fileName}-600.jpeg`} {...imageProps} />
    </picture>
)

Assuming all my images get generated with this file naming convention (and I always have images at 600, 1000, and 1400 widths), this should pull all our optimized images no problem 👍

Here's a brief rundown on applying these learnings to create-react-app:

Go try it yourself

You can check out a running example of create-react-app + 11ty image in this CodeSandbox 🪄

This version will listen for new images during development as well. Feel free to fork the source code to try in your own project (and find the edge cases I inevitably missed 😉).

Other options for Next, Nuxt, Gatsby and more

As cool as 11ty image can be, I should definitely highlight some "native" options for popular meta-frameworks:

For Next, their built-in Image component is perfect. They'll also cover our sizes, formats, and image compression automatically, plus some neat props for eagerly loading images that are "above the fold" using priority.
For Nuxt, their <nuxt-img> and <nuxt-picture> components should have you covered. These offer most of the same benefits as our 11ty image plugin, letting you specify different formats, a sizes attribute, and background image compression. Just be sure to use nuxt-picture if you want to allow multiple image formats instead of just one!
For Gatsby, you've got the gold standard of image optimization 🏆 Their image plugin was actually my main reason for using the framework a few years back, and it's only gotten better. The nicest feature (beyond matching everything we've talked about) is their loading animations for images. You can fade in over vector traces of an image, use a blur effect, and a lot more. The only downside is the hefty JS bundle it loads into the browser to pull this off, which I've given my opinions on over here.
Beyond the framework, you can optimize remotely using something like Cloudinary. This is a great option if you don't own the build process for your website, or don't want to store your images inside your code repository. For example, you can point all your Wordpress images to a cloudinary bucket and pull different image widths and formats for there. The only downside is the cost, since Cloudinary is doing all this image processing and storage for you.

Learn a little something?

Glad to hear it! If you want more universal web dev solutions like this, you can sign up for the web wizardry newsletter for some bi-weekly knowledge nuggets 🧠

How ES Modules have redefined web development

Ben Holmes — Wed, 07 Apr 2021 21:01:18 +0000

You know the inspirational phrase "skate to where the puck is going?" Well, in web development... it feels like the puck is teleporting across the rink at Mach 30 sometimes.

That's how I felt diving into how ES Modules work. Turns out, there's been some huge shifts right under my framework-laden nose these past few years. After discovering that this is valid JS across all major browsers...

const js = await import('script.js')

...I had to make a post about it. So let's explore

🥞 My misconceptions about what bundlers do these days
🧩 What ES Modules + dynamic imports can do
🚀 How build tools are evolving for the post-IE era

Onwards!

Foreward: Personal delusions in a webpack world

What I'm sharing here is probably common knowledge to some. Heck, import-able JavaScript modules have lurked in the ECMAScript standard since 2017! But if you've been using "traditional" project configs like create-react-app for a long time, you might think that old-school bundling is how the world works.

So let me ahem unpack the traditional definition of "bundling." In short, it's the concept of taking a chain of JS files like this:

// toppings.js
export {
  blueberries: async () => await fetch('fresh-from-the-farm'),
  syrup = "maple",
}

// ingredients.js
export { flour: 'white', eggs: 'free-range', milk: '2%', butter: 'dairy-free' }

// pancake.js
import { blueberries, syrup } from './toppings'
import { flour, eggs, milk, butter } from './ingredients'

const pancake = new Pancake()

pancake.mixItUp([ flour, eggs, milk, butter ])
pancake.cook()
pancake.applyToppings([ blueberries, syrup ])

And "flattening" the import / export chains into a big bundle pancake 🥞

// bundler-output-alksdfjfsadlf.js
const toppings__chunk = {
  blueberries: async () => await fetch('fresh-from-the-farm'),
  syrup = "maple",
}

const ingredients__chunk = { flour: 'white', eggs: 'free-range', milk: '2%', butter: 'dairy-free' }

const { blueberries, syrup } = toppings__chunk
const { flour, eggs, milk, butter } = ingredients__chunk
const pancake = new Pancake()

pancake.mixItUp([ flour, eggs, milk, butter ])
pancake.cook()
pancake.applyToppings([ blueberries, syrup ])

So we're compressing all the JavaScript files we're developing into a single file for the browser to consume. Back in 2015-era web development, this really was the only way to pull off "importing" one JS file into another. import wasn't even valid JavaScript! It was just some neat trickery that build tools like webpack could pick up and understand.

But silently, in the depths of the ES spec, import and export syntax did become valid JavaScript. Almost overnight, it became feasible to leave all your import and export statements in your code or even gasp ditch your JS bundler entirely 😨

This innovation became what we call modules.

ES Modules

There's an in-depth article from MDN on this topic that's well worth the read. But in short, "ES Modules" (sometimes denoted by .mjs files) are JavaScript files with some exported values for others to import and use. As long as you load your "entry" files with the type="module" attribute:

<script type="module" src="pancake.js"></script>

That file is ready to import all the other scripts it wants! Well, as long as those other scripts exist in your project's build of course (we'll ignore CORS issues for now 😁).

This concept of importing what's needed over "flattening all the things" has some nice benefits:

You don't need to load and parse everything up front. By default, anything imported is "deferred" for loading as needed. In other words, your computer won't turn into a fighter jet trying to load JS when you first visit your website.
The need for tooling like webpack can (one day) disappear ✨ Bringing browsers closer to how humans write their code is a huge win for newbies and pros alike 🏆

Dynamic imports take it a step further

Dynamic imports are the spicier side of ES Modules that really make things interesting. As this article from the V8 team describes (creators of Google Chrome's rendering engine), a dynamic import is an asynchronous fetch for some JavaScript whenever you need it.

It's very similar to the fetch API in a way! But instread of grabbing some JSON or plain text, we're grabbing some real, executable code that we want to run.

All you need is a humble one-liner:

const lookAtTheTime = await import('./fashionably-late.js')

...and you just grabbed all the exports from that file. Loading JS on-the-fly like this has a ton of benefits if you're working with single page apps like NextJS or create-react-app. The V8 team offered this elegantly simple take on client-side routing, only loading the JS you need when you click on a link:

const links = document.querySelectorAll('nav > a');
for (const link of links) {
  link.addEventListener('click', async (event) => {
    try {
      // go grab whatever JS the route may need
      const module = await import(`${event.target.href}/script.mjs`);
      // The module exports a function named `loadPageInto`,
      // Which might render some HTML into the body
      module.loadPageInto(document.body);
    } catch (error) {
      document.body.innerHTML = `
        <p>404 page not found</p>
      `
    }
  });
}

I basically just implemented a router in 10 lines of code. (yes, that's a serious overstatement, but it's closer than you might think).

This falls into code splitting, aka loading "components" (or modules) of code whenever the user needs them. Back in the dark ages of bundle all-the-things, you'd have to load all these components up front. This could mean thousands of lines of dead code!

So wait, it's 2021... why does all my tooling look the same?

This was certainly my first question when I read up on this. I recently graduated from create-react-app to NextJS as my React boilerplate go-to, but there's still that same webpack configuration + bundle process to think about 🤷‍♀️

A lot of this is just the curse of abstraction. Looking under the hood, these tools have made great strides since ES modules hit the scene. Namely, tools like NextJS can magically "split" your React app into bite-sized chunks that get loaded as-needed. This means:

only load the JS for a page when you actually visit that page
only load React components when they actually need to display
(bonus) pre-fetch JS when someone is likely to need it. This is a more advanced feature (documented here), but it lets you do all sorts of craziness; say, grabbing resources for a page when you hover over link

There's also the benefit of backwards compatibility when using a bundler. For instance, Internet Explorer has no concept of "modules" or "import" statements, so any attempt to code split will blow up in your face 😬 But with a meta-framework like NextJS by your side, you can polyfill such use cases without having to think about it.

Approaching the post-IE age

If you haven't heard, a major announcement sent ripples through the web dev community recently: Microsoft will officially drop IE 11 support for its products in August 2021 😱

Many are treating this as the ticking timebomb for legacy browser support. When it goes off... we might be safe to lose our polyfills for good. Yes, certain sites for governments and internal business operations will probably stick to their PHP-laced guns. But for us bleeding-edge developers, we may have a whole new frontier to explore 🚀

A world of bundlers that... don't bundle

The tides have certainly shifted in the JS bundler community in the past year. With the prospect of dropping polyfills and aggressive bundling for good, people started turning to the real reasons you want a bundler:

To process all your fanciness that isn't valid JS. Think JSX for React components, TypeScript for type checking, Styled Components and CSS modules for CSS-in-JS, etc etc.
To spin up your app locally. You could always open HTML files in your browser directly, but you'll loose all that immediate feedback! You should see all your new JS and CSS the millisecond you hit "save."
To optimize code for production. You'll probably want some last-minute stripping for added speed, like removing console.logs, minifying everything, linting, and so on.

Because of this refined feature set, the new wave of JS processors are just calling themselves "build tools" to stay more generalized.

Snowpack is really what got the ball rolling from my perspective. They promise all the selling points I listed above, plus the absolute fastest live-reloading in the biz. This is mainly because of that code splitting I mentioned earlier. Since they leave all those modules and dynamic imports in-tact, they avoid re-processing the JavaScript that didn't change. So if you just updated a single React component, it'll reprocess those 10 lines of code and blast it onto the page in a flash ⚡️

Vite is a major contender to note as well. This one was spearheaded by Evan You (the overlord of VueJS) to tackle a similar feature set to Snowpack. It's far too early to say whether I'd prefer this setup to Snowpack, but here's a nice comparison piece if you're considering either for serious apps.

There's also the crazy world of using different programming languages to process your code. ESBuild is a big contender right now, using GoLang to process JavaScript in no time flat.

Call to action: explore these new build tools!

It's definitely worth your time to whip up a sandbox and start compiling some code. Vite's create-app tool is a great one for it's beginner friendliness, with options to use any major framework out-of-the-box (React, Vue, Svelte, and even Lit Element!).

I was caught off guard to find there's no build directory when working in development. The code your write gets mapped to the browser directly, processed on-the-fly whenever you save ❤️

So go forth and see what the future is like! With any luck, we'll get to have our bundle pancake and eat it too 😁

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

This thing tackles the "first principles" of web development. In other words, what are all the janky browser APIs, bent CSS rules, and semi-accessible HTML that make all our web projects tick? If you're looking to go beyond the framework, this one's for you dear web sorcerer 🔮

Subscribe away right here. I promise to always teach and never spam ❤️

I'm building a new home outside of DEV. Here's why (and where to find me!)

Ben Holmes — Wed, 31 Mar 2021 20:50:07 +0000

Greetings fellow members of the DEV community! If you're one of my followers or someone new looking for excitement, thanks for clicking 👋

Before getting to the good stuff, I want to sing some praises for the DEV platform. I've been a blogger over here since early 2019, and I can't believe how much this community has helped me grow. If it wasn't for their willingness to promote and retweet new authors, I probably would've drowned in the sea of Medium and Hacker News algorithms long ago. This is why I believe that DEV is the reason I'm so passionate about blogging today.

That said, I think I've reached a point where I need start hosting all this content on my own domain as well. I've advertised my personal site a few times on here, and I'm super excited to be bringing a blog component into the mix 🥳

Why self-host at all?

Fair question! I've found quite an audience here on the DEV platform, and my SEO certainly hasn't suffered by hosting on here.

But there's a few consequences to not owning all your web content I want to address:

SEO for your personal site suffers. It's pretty simple really: the more popular webpages there are attached to a domain, the more popular that domain becomes. But as it stands... my personal site has no association with my popular posts! So no matter how many views I may get, searching "Ben Holmes" still comes up a baseball player and a saxophone player long before https://bholmes.dev 😬 (and yes, I know Ben Holmes is as basic a name as they come. So I have quite the uphill battle)
Having a "home base" helps with cross-posting. By having a base domain to share from, you can cross-post to any number of extra platforms for free using canonical URLs. These let you claim all that SEO goodness for your own domain while people read on the platform of their choice.
If the platform dies out, so do you. Don't get me wrong here; I'm rooting for DEV's future as a platform more than anyone! But if you've seen what's happened to the Medium developer community over the years, you know that the brightest stars can die out for any reason. So it's good to have somewhere that you own so you can quickly pivot between platforms at a moment's notice.

This advice isn't unique to me by the way! I'd say these are compelling reasons for anyone to start self-hosting.

So wait... are you leaving DEV?

Absolutely not! In fact, I'll probably keep posting content that's specific to the DEV platform.

Discussion threads using the #discuss tag are a big one for me. I won't have a comments section on my personal site (for now at least), so quickly polling the DEV community for ideas is a huge win I won't be giving up.

I also learn a lot from the comments community members leave on here. I've received multiple requests to edit and clarify certain points further which I wouldn't expect to receive on other platforms.

Lastly... I love that unicorn button. How could I abandon that? 🦄

So what's to come?

Well I'll tell you one thing: I won't keep writing the same old content on this new home. Expect some new features and experiments going forward:

A newsletter to share out my learnings across more mediums than a static post. This could be video snippets I record, podcasts / blogs / talks / random projects I find interesting, scrappy notes that aren't quite blog-ready, and more. I also want a outlet to share some music recs, so get ready for some bangers 🎧
Exploration of interactive posts. Though I don't have immediate plans, it would be sweet to join the MDX bandwagon and start embedding code + components right in the post you're reading. I'm deeply inspired by teachers like Josh Comeau in this area, and love the flexibility my personal platform could bring.
A place for scrappier ideas and drafts. I experimented with sharing my notes with you directly over on my 4 Conference Talks post, and I'm really encouraged by the warm response! But I have so many more notes to share that don't fit into the "super inspirational" bucket. I'm hoping I can take my personal notebook (using Foam + VS Code by the way) and turn it into a public garden of my learnings you can browse. It's a pretty new idea I've seen creators like Swyx pick up; could be worth a shot!

Call to action: join the newsletter 📫

To my 7137 followers on this platform (I still can't believe I can say that 😨), don't worry! The content will keep rolling your way over here.

But if you're interested in getting the full Ben Blog Experience (TM) or just want to support me on this new journey, I'd really appreciate the newsletter subscription.

No, I will not be flooding your inbox with mindless content. I plan to keep updates short, informative, and relatively infrequent (once every 2-3 weeks is my target right now). I'll also be sure that unsubscribe button is within reach should you need it 😁

I've also written a shiny new post over here that you won't want to miss: how ES Modules have redefined web development. I'm keeping this post exclusive to my personal site until next Wednesday (when I'll cross-post over here). So to grab this top-secret-early-access preview, go give it a read 👀

✨ Sign up for the newsletter ✨

📝 Explore the shiny new blog 📝

Thanks as always for your readership, and have a great day!

4 Git shortcuts that define my workflow

Ben Holmes — Thu, 18 Feb 2021 23:38:56 +0000

I started my first full-time job as a programmer this year, which means I've been picking up a lot of new tricks in a pretty quick timeframe. Naturally, I started automating the workflows I use day-in and day-out 😁

Stop me if you've seen this workflow before:

I picked up a ticket on JIRA
I need to pull the latest main branch
I need to checkout a new branch
I need to push that branch to origin before opening my PR

I'll probably do this 5+ times in one day if we're in a bug-squashing flow. But when I'm hurrying, it's so easy to either a) work off an old "main" branch, or b) do the copy-paste of shame before your PR:

To push the current branch and set the remote as upstream, use

    git push --set-upstream origin crap-not-again

You know you cringe a little every time this pops up 😬

So let's discuss:

🍾 The importance of pushing and popping your stash

🙈 The joys of upstream HEAD

🧶 Writing aliases for your terminal to tie it all together

Onwards!

The fantastic 4 aliases

Alright, let's do the big reveal. Here's my 4 shortcuts for slamming through daily tasks 💪

# Stash what I'm working on and checkout the latest master
alias gimme="git stash push -u && git checkout main && git pull -r"

# Grab the latest master and come back to the branch I was on (with stashing!)
alias yoink="gimme && git checkout - && git stash pop"

# Checkout a new branch and push it to origin (so I don't forget that set-upstream)
woosh() {
  git checkout -b $1 && git push -u origin HEAD
}

# ALL TOGETHER NOW
# Stash my current WIP, checkout a new branch off the latest master, and push it to origin
alias boop="gimme && woosh"

These commands are written in bash. So if you want to use these in your own terminal, go find your bashrc and paste away! This is usually found in your user directory: ~/.bashrc. And for all you windows users out there: you'll probably need to install the Git Bash terminal (included with Git) and create the file like so.

✋ But wait! Before you blindly copy these, let's unpack each of them a little.

`gimme` ✊

alias gimme="git stash push -u && git checkout main && git pull -r"

This is my "return to home base" command. It assumes you might not be on the main branch just yet, so it'll stash everything you're working on using the stash command. It also saves "untracked" / new files with the -u flag.

Next, it checks out your main branch and pulls the latest contents. That -r flag will be sure to "rebase" onto the latest, preventing unecessary merge conflicts.

This is the simplest command of the bunch, but it's also my most-used! On my team, we run a lot of automated scripts on pull for installing dependencies and pulling content from our CMS. So, it's super useful to return to main and grab all this new content in one go.

`yoink` 🎣

alias yoink="gimme && git checkout - && git stash pop"

This phrase is certainly a close relative to gimme. For some etymology, I'll include the urban dictionary entry on what it means to yoink:

An exclamation that, when uttered in conjunction with taking an object, immediately transfers ownership from the original owner to the person using the word regardless of previous property rights.

...In other words, we are grabbing the main branch and bringing it back to the branch we're on 😁 We pull this off using the git checkout - command after running gimme. This is super convenient for grabbing the latest changes to force rebase the branch we're working on.

💡 Note: is easy to achieve with a fetch command as well:

git fetch origin master:master

...but if your team runs automated scripts whenever you pull, you'll probably want the original command I described.

Clarification on using `stash` vs `stash push`

You also may be new to using push and pop on your stash, instead of apply and clear (as I often used to do). Here's the distinction:

Whenever you run "vanilla" git stash, you're merging your current changes with all the other changes in the stash. Think of this like throwing all your belongings in a bag, and git stash apply is like dumping everything out onto the floor.
Whenever you run git stash push, you're putting your current changes in a separate compartment from all the other changes in the stash. Think of this like choosing a different bag pocket every time you go to "stash" something. Then, when you pop, you pull from the last pocket you just used.

This is the reason we use push inside the gimme command, and pop inside the yoink command. It guarantees that we grab the same thing we just stashed, without getting mixed up with anything already in your stash. If you've ever dug around your bag trying to find one tiny thing stuck at the bottom, you know what I'm talking about here 😁

`woosh` 💨

woosh() {
  git checkout -b $1 && git push -u origin HEAD
}

This is the solution to your --set-upstream woes. Instead of pushing to origin later, this lets you check out a new branch and push right away so you don't forget.

Yes, there's some cases when you don't want your local branch on the remote just yet, but this is pretty rare in my experience. I often create a branch corresponding to a given task on our Kanban board that I'm ready to push up right away.

And if you've never seen the HEAD parameter before... remember that one! It's a super slick way to auto-fill the name of your current branch instead of typing it out by hand 🔥

`boop` 👇

alias boop="gimme && woosh"

Shout out to "lord of boops" Jason Lengstorf for the inspiration

This command goes full-circle. If you're somehow too lazy to check out the latest main branch before starting anew, this will let you gimme and woosh all in one go!

Not much to explain with this one. Just go forth into perfect boop-dom.

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

Subscribe away right here. I promise to always teach and never spam ❤️

4 Conference talks that changed my perspective as a web dev

Ben Holmes — Wed, 10 Feb 2021 21:44:22 +0000

I've resolved to make 2021 my biggest year of learning yet. My blogging game has been pretty sporadic up until now... but I've finally decided to go all-in on the learning in public mantra with 1 post a week!

I used to believe blog posts had to be shining nuggets of wisdom only I could find. But with all the notes I take on a weekly basis, why not share my journal with the world too? 😁

So, here's some of the most impactful conference talks I've found in the last year or so. I hope to check-in with more entries in the future, and I'd love to hear your own favorite talks in the comments!

Rich Hickey - Simple Made Easy 🧶

🎥 View the talk + transcript here

If you've ever heard the someone say that something is "easy, but not simple," this is probably the talk they're referencing. This is an easy recommend to programmers in general (not just web devs). That said, I think this talk is especially relevant to frontend-ers nowadays with all the tools at our disposal.

It feels like web frameworks and "best practices" are moving towards some powerful new opinions:

Everything is a component
Functional programming is king
State management is complex and deserves a rethink (hello state machines 👋)

☝️ These are the points Rich was getting at with this talk a decade ago! This is why I've resisted this talk multiple times throughout my web dev journey. As a junior getting comfortable with enterprise-grade React apps, it's helped me understand the why behind my team's architectural decisions.

Personal notes

Simple is an objective measure, no matter the person, reflecting how many interwoven pieces (complexity) there are in a given system
Easy is relative to every individual, reflecting how "familiar" or "near at hand" something feels
Agile programming encourages us to move fast without taking a step back
- Complexity and tech debt pile up when we ignore signs of bad abstraction
- Favorite quote of the talk: "But programmers fire the starting pistol every 100 yards and call it a (new) sprint!"
Replace complecting (knotted-up code with lots of interdependent pieces) with composing (modularity a la modern frontend frameworks)
- Think building a castle from Legos instead of a "knitted castle" from interweaving
- Separate horizontally, stratify vertically
Concrete improvements to make
- "Stateful" variables complect values with change overtime; make transition from one state to another predictable (see state machines
- Stay close to what the system does; consider the behavior over implementation details
- Example: Declarative over imperative programming
- Example: test-driven-development done right (incredible talk by Ian Cooper here)
- Work with rules over conditional / switch case spaghetti
- Given some data X, here's some rules to make it become Y
- Lean on pure functions, which give you a consistent output for a given input

Dan Abramov - The Wet Codebase 🌊

🎥 View the talk + transcript here

Here's another architecture-y talk that also reaches far beyond web development. If you're unfamiliar with Dan Abramov, he's one of the most prolific members of the React core team from a teaching standpoint alone. So if you want advice on architecting your web apps, this is your guy 😁

This talk goes hand-in-hand with Kent C Dodd's post on "AHA programming". Generally, they're both addressing the biggest pitfall of component-based thinking: copy / paste feels like bad practice, so you abstract every piece of logic to its own little file.

Sure there's a place for abstraction, but there's also a place for duplication! This talk has a lot of examples and funny quotables to keep things light; definitely worth the watch.

Personal notes

If left unchecked, abstractions can become Frankenstein code overtime
- An abstraction almost fits are use case, but not quite 👉 we wittle away that round hole to fit our square peg
- When bugs arise for one use case, we introduce fixes affecting tons of other use cases
👍 When abstraction is good
- Makes your code more declarative / focus on a specific intent (see that Rich Hickey talk above 😉)
- Avoids missed bug fixes 👉 fix it once, fix everywhere
👎 When abstraction is bad
- Creates coupling - when it doesn't quite fit, you can create a monster of refactors
- Adds indirection - creates layers and layers overtime; "We avoid spaghetti code, but we create lasagna code" 🇮🇹
Ways to improve going forward
- Test code that uses an abstraction, not the abstraction itself
- If you remove that abstraction later, your tests explode!
- Abstractions are just another implementation detail (again, TDD is king)
- Don't commit to abstraction layers until you need them; "If a girl is into the same obscure bands as you are... that doesn't mean you're meant to be together"
- Be ready to remove abstractions later; Be the one asking "Please inline this abstraction!" in a PR review!

Rich Harris - Rethinking Reactivity ⚛️

In my opinion, this is the biggest bombshell to drop since React was first revealed 💣

A trigger warning is probably in order here: if you're a diehard React follower, this talk questions many practice React holds dear (including the virtual DOM itself!).

But even if you disagree with Rich's points, this talk is a serious landmark in the web framework canon. It also exposes what "bundlers," "compilers," and "reacting to change" all really mean under the hood. If you aren't convert to a Svelte fan after this, you'll at least understand where the web has been, and where it might be heading!

Personal notes

What is reactive programming?
- It all started with spreadsheets
- I change a value in one cell, and other cells "react" to those changes with formulas
- Earliest example of only re-rendering values that change
- It's 1) about tracking values and 2) updating dependents on that value
Problem with React's model
- When state changes in a component, that whole component re-evaluates itself from the top
- Treats your HTML like a black box; apply the change, then diff against the previous chunk
- Really, React doesn't know about your "state values" or how they affect the DOM!
- Bad signs for efficiency: I shouldn't need useMemo, useCallback, shouldComponentUpdate, etc
Instead of opting out of reevaluating state (a la useMemo), we could opt in by flagging state variables that depend on other state variables
- Much like a spreadsheet; write formulas that flag which variables affect a given value
- Svelte uses a custom $: operator to "flag" state that is computed from other state (example here)
Svelte is a compiler, not a runtime
- In other words, a "Svelte" component compiles to JS your browser understand
- No "runtime" (like React's virtual DOM) needs to get imported
- Also means Svelte can bend the JS language to its will
- Evan You, creator of VueJS - Svelte is too magical, since it lets you write JavaScript that isn't totally valid
- Rich Harris' response - this opinion is like believing HTML, CSS and JS should live in separate files. CSS-in-JS is weird too, so what's wrong with this?
Some other cool demos of Svelte
- CSS scoping by component just by using a <style> tag
- Transition directives with sensible out-of-the-box options

Shawn "swyx" Wang - Getting Closure on React Hooks 🎣

This is a fast-paced and code-heavy talk, so you'll probably want 1x speed on this one.

That said... this is the most enlightening talk I've seen on React. Period. It's only 30 minutes long, but it gave me holistic understanding on how React hooks, state management, and re-rendering all work together. It also shows some huge use cases for "closure" in JS. If you have a web dev interview coming up, point to this! 😉

Personal notes

Hard to write a succinct, bulleted list for this one. So, I just annotated the finished product to explain how everything works. Fair warning: it's a lot to take in!

🚀 Functioning codepen to see it in action

const React = (function () {
  // create an array for all the state variables in our "React app"
  let stateValues = [];
  // start our state index at 0. We'll use this
  // to throw state into that array ☝️ everytime someone calls "useState"
  let index = 0;
  function useState(initValue) {
    // state should be set to either:
    // 1. the initial value (aka React.useState(initValue))
    // if this is the first time our component rendered
    // 2. the value from the *last* render
    // if we're re-rendering our component (aka stateValues[index])
    const state = stateValues[index] || initValue;
    // "freeze" our index to this particular useState call with _index.
    // prevents the index from changing before we try to call setState later!
    const _index = index;
    const setState = (newValue) => {
      stateValues[_index] = newValue;
    };
    // increment index so our next useState call doesn't override the state
    // we just stored above
    index++;
    return [state, setState];
  }
  function render(Component) {
    // every time we re-render our app,
    // update all our state variables starting from the top
    index = 0;
    const C = Component();
    // "render" the component (which calls the useState function)
    C.render();
    return C;
  }
  // return all our functions from this foe React "module"
  return { useState, render };
})();

function Component() {
  const [count, setCount] = React.useState(2);
  return {
    // whenever we "render" this component with React.render, 
    // just log the value of our state variable
    render: () => console.log({ count }),
    click: () => setCount(count + 1)
  };
}

let App = React.render(Component) // logs { count: 2 }
App.click() // sets the state at stateValues[0] to 3
App.click() // sets the state at stateValues[0] to 4
React.render(Component) // logs { count: 4 }

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

Subscribe away right here. I promise to always teach and never spam ❤️

Another way to understand JavaScript's array.reduce

Ben Holmes — Fri, 05 Feb 2021 16:26:05 +0000

If you've run the guantlet of array methods in JavaScript, you've probably hit this roadblock a few times:

Wait, how do I use the reduce function again?

I actually led a JS bootcamp with this topic for my college's Hack4Impact chapter (material 100% free-to-use here!). Questions on reduce have come up so many times, and I think I've finally found an explanation that clicks 😁 Hope it works for you too!

🎥 Video walkthrough

If you prefer to learn by video tutorial, this one's for you. You can fork this CodePen for the source material to follow along 🏃‍♂️

📝 Step-by-step cheatsheet

Let's walk our way to reduce by using what we know: good ole' for loops.

Here's an example. Say we have our favorite album on a CD (remember those? 💿), and our stereo tells us the length of each track in minutes. Now, we want to figure out how long the entire album is.

Here's a simplified approach for what we want to do:

// make a variable to keep track of the length, starting at 0
let albumLength = 0
// walk through the songs on the album...
album.songs.forEach(song => {
  // and add the length of each song to our running total
  albumLength += song.minutesLong
})

No too bad! Just loop over the songs, and accumulate the album runtime while we walk through the songs. This is basically the process you'd use in real life, tallying up the album length as you skip through the tracks on your stereo.

That word "accumulate" is pretty significant here though. In essence, we're taking this list of track lengths, and reducing them to a single accumulated number: the albumLength. This process of reducing to an accumulator should set off a light bulb in your head: 💡 we can use array.reduce!

Going from `forEach` to `reduce`

Let's try reduce-ifying our function from earlier. This is a simple, 4 step process:

Change forEach to reduce:

let albumLength = 0
album.songs.reduce((song) => {
  albumLength = albumLength + song.minutesLong
})

Move albumLength to the first parameter of the loop function, and the initial value (0) to the second parameter of reduce

// accumulator up here 👇
album.songs.reduce((albumLength, song) => {
  albumLength = albumLength + song.minutesLong
}, 0) // 👈 initial value here

Change albumLength = to a return statement. This isn't too different conceptually, since we're still adding our song length onto our "accumulated" album length:

album.songs.reduce((albumLength, song) => {
  // 👇 Use "return" instead of our = assignment
  return albumLength + song.minutesLong
}, 0)

Retrieve the result of our reduce loop (aka our total album length). This is just the value returned:

const totalAlbumLength = album.songs.reduce((albumLength, song) => {
  return albumLength + song.minutesLong
}, 0)

And that's it! 🎉

So wait, why do I even need `reduce`?

After all that work, reduce might feel like a slightly harder way of writing a for loop. In a way... it kind of is 😆

It offers one key benefit though: since reduce returns our total, function chaining is a lot easier. This may not be a benefit you appreciate right away, but consider this more complex scenario:

// Say we have this array of arrays,
// and we want to "flatten" everything to one big array of songs
const songsByAlbum = [
  ['Rap Snitches Knishes', 'Beef Rap', 'Gumbo'],
  ['Accordion', 'Meat Grinder', 'Figaro'],
  ['Fazers', 'Anti-Matter', 'Krazy World']
]
let songs = []
songsByAlbum.forEach(albumSongs => {
  // "spread" the contents of each array into our big array using "..."
  songs = [...songs, ...albumSongs]
})

This isn't too hard to understand. But what if we want to do some more fancy array functions on that list of songs?

// Ex. Make these MF DOOM songs titles all caps
let songs = []
songsByAlbum.forEach(albumSongs => {
  songs = [...songs, ...albumSongs]
})
const uppercaseSongs = songs.map(song => song.toUppercase())

All caps when you spell the man name. Rest in piece MF DOOM

This is fine, but what if we could "chain" these 2 modifications together?

// grab our *final* result all the way at the start
const uppercaseSongs = [
  ['Rap Snitches Knishes', 'Beef Rap', 'Gumbo'],
  ['Accordion', 'Meat Grinder', 'Figaro'],
  ['Fazers', 'Anti-Matter', 'Krazy World']
]
// rewriting our loop to a "reduce," same way as before
.reduce((songs, albumSongs) => {
  return [...songs, ...albumSongs]
}, [])
// then, map our songs right away!
.map(song => song.toUppercase())

Woah! Throwing in a reduce, we just removed our standalone variables for songsByAlbum and songs entirely 🤯

Take this example with a grain of salt though. This approach can hurt the readability of your code when you're still new to these array functions. So, just keep this reduce function in your back pocket, and pull it out when you could really see it improving the quality of your code.

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

Subscribe away right here. I promise to always teach and never spam ❤️

A shiny-on-hover effect that follows your mouse (CSS) ✨

Ben Holmes — Thu, 28 Jan 2021 17:40:13 +0000

Hover states are probably the most fun a developer can have when a designer isn't looking. You've seen the basics at this point; fade-ins, growing and shrinking, color shifts, animated rainbow gradients, etc etc etc.

But there was one animation that inspired me recently (props to Keyframers for shouting it out!)

// Detect dark theme var iframe = document.getElementById('tweet-1278384065087893505-154'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1278384065087893505&theme=dark" }

This isn't some "static" hover state that always looks the same. It actually tracks your mouse moment to make the page even more interactive. This seemed like such a cool idea... that we threw it all over our Hack4Impact site 😁

So let's explore

🎈 Why CSS variables can help us
✨ How we style our button
🪤 How we map mouse movements to a metallic shine
🔨 How to adapt this animation to any UI framework

Onwards!

Our end goal

The effect is pretty simple on the surface. Just shift the color a little bit whenever you hover over the button, plus a little circular gradient for a "metallic" sheen.

But there's a bit of added spice that CSS can't pull off on its own: We need to track your cursor position to make this interactive! Luckily, this has gotten a lot easier over the years; You won't even need a UI framework or state management to pull it off 👀

🎈 Brief primer on CSS variables

In case you haven't heard, CSS variables are kind of taking web development by storm right now. They're a bit like those $ variables preprocessors like SASS and LESS let you pull off, but with one huge benefit: you can change the value of these variables at runtime using JavaScript 😱

Let's see a simple example. Say we want to make a balloon pump, where you hit a button as fast as you can to "inflate" an HTML-style balloon.

If we didn't know anything about CSS variables, we'd probably do some style manipulation straight from JavaScript. Here's how we'd pump up a balloon using the transform property:

const balloon = document.querySelector('.balloon');
// make the balloon bigger by 50%
balloon.style.transform = 'scale(1.5)';

Or, to make the balloon just a little bit bigger on every button click:

...
const pump = document.querySelector('.pump')
// keep track of the balloon's size in a JS variable
let size = 1;
pump.addEventListener('click', () => {
  size += 0.1;
    balloon.style.transform = `scale(${size})`;
})

There's nothing wrong with this so far. But it has some growing pains:

We need to keep track of a CSS property (the balloon's scale size) using a JS variable. This could ahem balloon into a suite of state variables overtime as we animate more elements throughout our app.
We're writing our CSS using strings. This leaves a sour taste in my mouth personally, since we loose all our syntax highlighting + editor suggestions. It can also get nasty to maintain when we want that size variable in other parts of our styles. For example, what if we wanted to change the background-position as the balloon inflates? Or the height and width? Or some linear-gradient with multiple color positions?

CSS variables to the rescue

As you may have guessed, we can store this size from our code as a CSS variable!

We can use the same .style attribute as before, this time using the setProperty function to assign a value:

let size = 1;
pump.addEventListener('click', () => {
  size += 0.1;
    balloon.style.setProperty('--size', size);
})

Then, slide that variable into our transform property from the CSS:

.balloon {
  /* set a default / starting value if JS doesn't supply anything */
  --size: 1;
  ...
  /* use var(...) to apply the value */
  transform: scale(var(--size));
}

Heck, you can ditch that size variable entirely and make CSS the source of truth! Just read the value from CSS directly whenever you try to increment it:

pump.addEventListener('click', () => {
  // Note: you *can't* use balloon.style here!
  // This won't give you the up-to-date value of your variable.
  // For that, you'll need getComputedStyle(...)
    const size = getComputedStyle(balloon).getPropertyValue('--size');
  // size is a string at this stage, so we'll need to cast it to a number
  balloon.style.setProperty('--size', parseFloat(size) + 0.1)
})

There's some caveats to this of course. Namely, CSS variables are always strings when you retrieve them, so you'll need to cast to an int or a float (for decimals) as necessary. The whole .style vs. getComputedStyle is a little weird to remember as well, so do whatever makes sense for you!

Here's a fully working example to pump up your confidence 🎈

✨ Let's get rolling on our shiny button

Before putting our newfound CSS variable knowledge to the test, let's jump into the styles we'll need for this button.

Remember that we want a smooth gradient of color to follow our mouse cursor, like a light shining on a piece of metal. As you can imagine, we'll want a radial-gradient on our button that we can easily move around.

We could add a gradient as a secondary background on our button (yes, you can overlay multiple backgrounds on the same element!). But for the sake of simplicity, let's just add another element inside our button representing our "shiny" effect. We'll do this using a pseudo-element to be fancy 😁

.shiny-button {
  /* add this property to our button, */
  /* so we can position our shiny gradient *relative* to the button itself */
  position: relative;
  /* then, make sure our shiny effect */
  /* doesn't "overflow" outside of our button */
  overflow: hidden;
  background: #3984ff; /* blue */
  ...
}

.shiny-button::after {
  /* all pseudo-elements need "content" to work. We'll make it empty here */
  content: '';
  position: absolute;
  width: 40px;
  height: 40px;
  /* make sure the gradient isn't too bright */
    opacity: 0.6;
  /* add a circular gradient that fades out on the edges */
    background: radial-gradient(white, #3984ff00 80%);
}

Side note: You may have noticed our 8-digit hex code on the gradient background. This is a neat feature that lets you add transparency to your hex codes! More on that here.

Great! With this in place, we should see a subtle, stationary gradient covering our button.

🪤 Now, lets track some mouse cursors

We'll need to dig into some native browser APIs for this. You probably just listen for click 99% of the time, so it's easy to forget the dozens of other event listeners at our disposal! We'll need to use the mousemove event for our purposes:

const button = document.querySelector('.shiny-button')
button.addEventListener('mousemove', (e) => {
    ...
})

If we log out or event object, we'll find some useful values in here. The main one's we're focusing on are clientX and clientY, which tell you the mouse position relative to the entire screen. Hover over this button to see what those values look like:

This is pretty useful, but it's not quite the info we're looking for. Remember that our shiny effect is positioned relative to the button surrounding it. For instance, to position the effect at the top-left corner of the button, we'd need to set top: 0; left: 0; So, we'd expect a reading of x: 0 y: 0 when we hover in our example above... But this definitely isn't the values that clientX and clientY give us 😕

There isn't a magical event property for this, so we'll need to get a little creative. Remember that clientX and clientY give us the cursor position relative to the window we're in. There's also this neat function called getBoundingClientRect(), which gets the x and y position of our button relative to the window. So if we subtract our button's position from our cursor's position... we should get our position relative to the button!

This is probably best explored with visuals. Hover your mouse around to see how our mouse values, boundingClientRect values, and subtracted values all interact:

💅 Pipe those coordinates into CSS

Alright, let's put two and two together here! We'll pass our values from the mousemove listener:

button.addEventListener("mousemove", (e) => {
  const { x, y } = button.getBoundingClientRect();
  button.style.setProperty("--x", e.clientX - x);
  button.style.setProperty("--y", e.clientY - y);
})

Then, we'll add some CSS variables to that shiny pseudo-element from before:

.shiny-button::after {
  ...
  width: 100px;
  height: 100px;
  top: calc(var(--y, 0) * 1px - 50px);
  left: calc(var(--x, 0) * 1px - 50px);
}

A couple notes here:

We can set a default value for our variables using the second argument to var. In this case, we'll use 0 for both.
CSS variables have a weird concept of "types." Here, we're assuming we'll pass our x and y as integers. This makes sense from our JavaScript, but CSS has a hard time figuring out that something like 10 really means 10px. To fix this, just multiply by the unit you want using calc (aka * 1px).
We subtract half the width and height from our positioning. This ensures that our shiny circle is centered up with our cursor, instead of following with the top left corner.

Fade into our effect on entry

We're pretty much done here! Just one small tweak: if we leave this animation as-is, our shiny effect will always show in some corner of our button (even when we aren't hovering).

We could fix this from JavaScript to show and hide the effect. But why do that when CSS lets you style-on-hover already?

/* to explain this selector, we're */
/* selecting our ::after element when the .shiny-button is :hover-ed over */
.shiny-button:hover::after {
  /* show a faded shiny effect on hover */
  opacity: 0.4;
}
.shiny-button::after {
  ...
  opacity: 0;
  /* ease into view when "transitioning" to a non-zero opacity */
  transition: opacity 0.2s;
}

Boom! Just add a one-line transition effect, and we get a nice fade-in. Here's our finished product ✨

🔨 Adapt to your framework of choice

I get it, you might be dismissing this article with all the eventListeners thinking well, I'm sure that JS looks much different in framework X. Luckily, the transition is pretty smooth!

First, you'll need to grab a reference to the button you're shine-ifying. In React, we can use a useRef hook to retrieve this:

const ShinyButton = () => {
  // null to start
  const buttonRef = React.useRef(null)
  React.useEffect(() => {
    // add a useEffect to check that our buttonRef has a value
    if (buttonRef) {
      ...
    }
  }, [buttonRef])

  return <button ref={buttonRef}>✨✨✨</button>
}

Or in Svelte, we can bind our element to a variable:

<script>
  import { onMount } from 'svelte'
  let buttonRef
  // our ref always has a value onMount!
  onMount(() => {
    ...
  })
</script>

<button bind:this={buttonRef}>✨✨✨</button>

Aside: I always like including Svelte examples, since they're usually easier to understand 😁

Once we have this reference, it's business-as-usual for our property setting:

React example

const ShinyButton = () => {
  const buttonRef = React.useRef(null)
  // throw your mousemove callback up here to "add" and "remove" later
  // might be worth a useCallback based on the containerRef as well!
  function mouseMoveEvent(e) {
    const { x, y } = containerRef.current.getBoundingClientRect();
    containerRef.current.style.setProperty('--x', e.clientX - x);
    containerRef.current.style.setProperty('--y', e.clientY - y);
  }

  React.useEffect(() => {
    if (buttonRef) {
      buttonRef.current.addEventListener('mousemove', mouseMoveEvent)
    }
    // don't forget to *remove* the eventListener
    // when your component unmounts!
    return () => buttonRef.current.removeEventListener('mousemove', mouseMoveEvent)
  }, [buttonRef])
  ...

Svelte example

<script>
  import { onMount, onDestroy } from 'svelte'
  let buttonRef
  // again, declare your mousemove callback up top
  function mouseMoveEvent(e) {
    const { x, y } = buttonRef.getBoundingClientRect();
    buttonRef.style.setProperty('--x', e.clientX - x);
    buttonRef.style.setProperty('--y', e.clientY - y);
  }
  onMount(() => {
        buttonRef.addEventListener('mousemove', mouseMoveEvent)
  })
  onDestroy(() => {
    buttonRef.removeEventListener('mousemove', mouseMoveEvent)
  })
</script>

The main takeaway: 💡 don't forget to remove event listeners when your component unmounts!

Check out our live example on Hack4Impact

If you want to see how this works in-context, check out this CodeSandbox for our Hack4Impact site. We also added some CSS fanciness to make this effect usable on any element, not just buttons ✨

To check out the component, head over here.

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

Subscribe away right here. I promise to always teach and never spam ❤️

Mocking browser APIs (fetch, localStorage, Dates...) the easy way with Jest

Ben Holmes — Tue, 19 Jan 2021 22:48:29 +0000

I hit a snag recently trying to test a localStorage helper written in React. Figuring out how to test all my state and render changes was certainly the easy part (thanks as always React Testing Library 🐐).

But soon, I found myself wondering... is there an easy way to "mock" a browser API like storage? Or better yet, how should I test any function using X API?

Well, hope you're hungry! We're gonna explore

🚅 Why dependency injection doesn't feel like a silver bullet
📦 How we can mock localStorage using the global object
📶 Ways to go further mocking the fetch API
🔎 An alternative approach using jest.spyOn

Onwards!

Let's grab something to eat first

Here's a simple (and tasty) example of a function worth testing:

function saveForLater(leftoverChili) {
  try {
        const whatsInTheFridge = localStorage.getItem('mealPrepOfTheWeek')
    if (whatsInTheFridge === undefined) {
      // if our fridge is empty, chili's on the menu 🌶
        localStorage.setItem('mealPrepOfTheWeek', leftoverChili) 
    } else {
      // otherwise, we'll just bring it to our neighbor's potluck 🍽
      goToPotluck(leftoverChili)
    }
  } catch {
    // if something went wrong, we're going to the potluck empty-handed 😬
    goToPotluck()
  }
}

This is pretty straightforward... but it's got some localStorage madness baked-in. We could probably start with the inject all the things strategy (TM) to address this:

function saveForLater(leftoverChili, {
  // treat our storage calls as parameters to the function,
  // with the default value set to our desired behavior
  getFromStorage = localStorage.getItem('mealPrepOfTheWeek'),
  setInStorage = (food) => localStorage.setItem('mealPrepOfTheWeek', food) 
}) => {
  try {
    // then, sub these values into our function
    const whatsInTheFridge = getFromStorage()
    ...
    setInStorage(leftoverChili)
        ...
}

Then, our test file can pass some tasty mock functions we can work with:

it('puts the chili in the fridge when the fridge is empty', () => {
  // just make some dummy functions, where the getter returns undefined
  const getFromStorage = jest.fn().mockReturnValueOnce(undefined)
  // then, make a mock storage object to check
  // whether the chili was put in the fridge
  let mockStorage
  const setInStorage = jest.fn((value) => { mockStorage = value })

    saveForLater('chili', { getFromStorage, setInStorage })
  expect(setInStorage).toHaveBeenCalledOnce()
  expect(mockFridge).toEqual('chili')
})

This isn't too bad. Now we can check whether our localStorage functions get called, and verify that we're sending the right values.

Still, there's something a bit ugly here: we just restructured our code for the sake of cleaner tests! I don't know about you, but I feel a little uneasy moving the internals of my function to a set of parameters. And what if the unit tests move away or get rewritten years down the line? That leaves us with another odd design choice to pass onto the next developer 😕

📦 What if we could mock browser storage directly?

Sure, mocking module functions we wrote ourselves is pretty tough. But mocking native APIs is surprisingly straightforward! Let me stir the pot a little 🥘

// let's make a mock fridge (storage) for all our tests to use
let mockFridge = {}

beforeAll(() => {
  global.Storage.prototype.setItem = jest.fn((key, value) => {
    mockFridge[key] = value
  })
  global.Storage.prototype.getItem = jest.fn((key) => mockFridge[key])
})

beforeEach(() => {
  // make sure the fridge starts out empty for each test
  mockFridge = {}
})

afterAll(() => {
  // return our mocks to their original values
  // 🚨 THIS IS VERY IMPORTANT to avoid polluting future tests!
    global.Storage.prototype.setItem.mockReset()
  global.Storage.prototype.getItem.mockReset()
})

Oh, take a look at that meaty piece in the middle! There's some big takeaways from this:

Jest gives you a nice global object to work with. More specifically, Jest gives you access to JSDOM out-of-the-box, which populates global (a standard in Node) with a treasure trove of APIs. As we've discovered, it includes our favorite browser APIs as well!
We can use the prototype to mock functions inside a JS class. You're right to wonder why we need to mock Storage.prototype, rather than mocking localStorage directly. In short: localStorage is actually an instance of a Storage class. Sadly, mocking methods on a class instance (i.e. localStorage.getItem) doesn't work with our jest.fn approach. But don't fret! You can mock the entire localStorage class as well if this prototype madness makes you feel uneasy 😁 Fair warning though: it's a bit harder to test whether class methods were called with toHaveBeenCalled compared to a plan ole' jest.fn.

💡 Note: This strategy will mock both localStorage and sessionStorage with the same set of functions. If you need to mock these independently, you might need to split up your test suites or mock the storage class as previously suggested.

Now, we're good to test our original function injection-free!

it('puts the chili in the fridge when the fridge is empty', () => {
    saveForLater('chili')
  expect(global.Storage.prototoype.setItem).toHaveBeenCalledOnce()
  expect(mockStorage['mealPrepOfTheWeek']).toEqual('chili')
})

There's almost no setup to speak of now that we're mocking global values. Just remember to clean the kitchen in that afterAll block, and we're good to go 👍

📶 So what else could we mock?

Now that we're cooking with crisco, let's try our hand at some more global functions. The fetch API is a great candidate for this:

// let's fetch some ingredients from the store
async function grabSomeIngredients() {
  try {
    const res = await fetch('https://wholefoods.com/overpriced-organic-spices')
    const { cumin, paprika, chiliPowder } = await res.json()
        return [cumin, paprika, chiliPowder] 
  } catch {
    return []
  }
}

Seems simple enough! We're just making sure that the Cumin, Paprika, and Chili Powder get fetched and returned in an array of chili spices 🌶

As you might expect, we're using the same global strategy as before:

it('fetches the right ingredients', async () => {
  const cumin = 'McCormick ground cumin'
  const paprika = 'Smoked paprika'
  const chiliPowder = 'Spice Islands Chili Powder'
  let spices = { cumin, paprika, chiliPowder, garlicSalt: 'Yuck. Fresh garlic only!' }

  global.fetch = jest.fn().mockImplementationOnce(
    () => new Promise((resolve) => {
      resolve({
        // first, mock the "json" function containing our result
        json: () => new Promise((resolve) => {
          // then, resolve this second promise with our spices
          resolve(spices)
        }),
      })
    })
  )
  const res = await grabSomeIngredients()
  expect(res).toEqual([cumin, paprika, chiliPowder])
})

Not too bad! You'll probably need a second to process that doubly-nested Promise we're mocking (remember, fetch returns another promise for the json result!). Still, our test stayed pretty lean while thoroughly testing our function.

You'll also notice that we used mockImplementationOnce here. Sure, we could have used the same beforeAll technique as before, but we probably want to mock different implementations for fetch once we get into the error scenarios. Here's how that might look:

it('returns an empty array on bad fetch', async () => {
    global.fetch = jest.fn().mockImplementationOnce(
      () => new Promise((_, reject) => {
        reject(404)
      })
    )
    const res = await fetchSomething()
    // if our fetch fails, we don't get any spices!
    expect(res).toEqual([])
  })
  it('returns an empty array on bad json format', async () => {
    global.fetch = jest.fn().mockImplementationOnce(
      () => new Promise((resolve) => {
        resolve({
          json: () => new Promise((_, reject) => reject(error)),
        })
      })
    )
    const res = await fetchSomething()
    expect(res).toEqual([])
  })

And since we're mocking implementation once, there's no afterAll cleanup to worry about! Pays to clean your dishes as soon as you're done with them 🧽

🔎 Addendum: using "spies"

Before wrapping up, I want to point out an alternative approach: mocking global using Jest spies.

Let's refactor our localStorage example from before:

...
// first, we'll need to make some variables to hold onto our spies
// we'll use these for clean-up later
let setItemSpy, getItemSpy

beforeAll(() => {
  // previously: global.Storage.prototype.setItem = jest.fn(...)
    setItemSpy = jest
    .spyOn(global.Storage.prototype, 'setItem')
    .mockImplementation((key, value) => {
      mockStorage[key] = value
    })
  // previously: global.Storage.prototype.getItem = jest.fn(...)
  getItemSpy = jest
    .spyOn(global.Storage.prototype, 'getItem')
    .mockImplementation((key) => mockStorage[key])
})

afterAll(() => {
  // then, detach our spies to avoid breaking other test suites
  getItemSpy.mockRestore()
  setItemSpy.mockRestore()
})

Overall, this is pretty much identical to our original approach. The only difference is in the semantics; instead of assigning new behavior to these global functions (i.e. = jest.fn()), we're intercepting requests to these functions and using our own implementation.

This might feel a little "safer" to some people, since we're not explicitly overwriting the behavior of these functions anymore. But as long as you pay attention to your cleanup in the afterAll block, either approach is valid 😁

Learn a little something?

Awesome. In case you missed it, I launched an my "web wizardry" newsletter to explore more knowledge nuggets like this!

Subscribe away right here. I promise to always teach and never spam ❤️

DEV Community: Ben Holmes

Understanding single page apps & client-side routing

🤔 First off, how do non- SPAs work?

Wait, is that wasteful?

1. HTML is super cheap to load and render

2. Shared resources don't need to get re-loaded

3. The next page only appears when it's ready

💁 Now, let's talk single page apps

Key benefits to this approach

🍔 A juicy visual comparison

Wrapping up: so which should I choose?

Learn a little something?

Grabbing subsets of JS object properties with... GraphQL?

What we want

📈 Enter: GraphQL

📖 Applying GraphQL to reading JSON objects

Traversing our query

Handling nested objects

Cleaning this up a little

Handling arrays

🚀 The finished product

Usage example

Learn a little something?

Sexy, accessible show-hide animations in any web framework

Starting with a naive solution

⌨️ Let's accommodate keyboard users

👁 Let's accommodate screen readers

Communicating toggle states with aria-expanded

Focusing our dropdown on expanded

⚙️ Applying this to your favorite framework

A simple React solution

Svelte example

Learn a little something?

Want CSS variables in media query declarations? Try this!

🙅 Why var() can't work in a @media declaration

Hope on the horizon for CSS "environment" variables

🤔 Workarounds you can try

For Sass / SCSS users

For anyone else

Learn a little something?

Picture perfect image optimization for any web framework

🥦 So what's wrong with my images right now?

🌅 Fixing format + size problems with the picture element

The sizes attribute

Respecting HD displays

🔨 Applying this to your site with 11ty image

Generating optimized images

Automating our picture elements

Going further

📣 Using 11ty image with any framework

Go try it yourself

Other options for Next, Nuxt, Gatsby and more

Learn a little something?

How ES Modules have redefined web development

Foreward: Personal delusions in a webpack world

ES Modules

Dynamic imports take it a step further

So wait, it's 2021... why does all my tooling look the same?

Approaching the post-IE age

A world of bundlers that... don't bundle

Call to action: explore these new build tools!

Learn a little something?

I'm building a new home outside of DEV. Here's why (and where to find me!)

Why self-host at all?

So wait... are you leaving DEV?

So what's to come?

Call to action: join the newsletter 📫

4 Git shortcuts that define my workflow

The fantastic 4 aliases

gimme ✊

yoink 🎣

Clarification on using stash vs stash push

woosh 💨

boop 👇

Learn a little something?

4 Conference talks that changed my perspective as a web dev

Rich Hickey - Simple Made Easy 🧶

Personal notes

Dan Abramov - The Wet Codebase 🌊

Personal notes

Communicating toggle states with `aria-expanded`

🌅 Fixing format + size problems with the `picture` element

The `sizes` attribute

`gimme` ✊

`yoink` 🎣

Clarification on using `stash` vs `stash push`

`woosh` 💨

`boop` 👇

Going from `forEach` to `reduce`

So wait, why do I even need `reduce`?