If you build an app in the Atmosphere, you're likely to bump into a question: how should I handle profile information for my users? It's an open network, so your users probably already have a profile somewhere. Maybe on Bluesky, maybe on another ATProto app. Shouldn't you be able to use that?

The short answer is yes. The obvious approach is to pull from Bluesky. Most ATProto users have a Bluesky account, so grab their `app.bsky.actor.profile` and prefill from there. That works fine today. It's what I do on [Cartridge](https://cartridge.dev).

ATProto isn't Bluesky, though. It's a protocol, and Bluesky is just one application built on it. As more apps come online, the assumption that every user has a Bluesky profile gets shakier. New users might onboard through a completely different app and never touch Bluesky. Once you start thinking about that future, the question gets more interesting.

I've been noodling on this for a while, and a series of conversations with other folks in the ATProto community helped me land on something that I think is worth sharing.

## The Problem, by Way of Ariel

[Ariel](https://bsky.app/profile/byarielm.fyi) is building [AtLast](https://bsky.app/profile/atlast.byarielm.fyi), a tool to help people migrating from closed platforms find folks they used to follow on ATProto. Her challenge is a sharper version of the same question: she needs to present profile information for users across the entire network. She can't assume any particular app's profile record exists for any given user.

Our conversation started with Ariel pitching the idea of a base profile: a default, shared profile record that every ATProto account would have, and that any app could read from. It sounds clean, but I think the UX falls apart pretty fast.

If apps can write to a base profile, does editing my bio on one app update it everywhere? How do you communicate that to users? I wouldn't love discovering my gaming bio had silently become my professional networking bio.

If the base profile is read-only, now I have to leave the app I'm using to go edit my profile on some other property. That's just a bad experience.

Then there's the staleness problem. A profile that exists for the sake of being a profile, with no app experience around it, will go stale. This is the Gravatar problem. Every time I encounter Gravatar in the wild, it's after not touching it for years. The avatar is from a different era. The bio is aspirational fiction from 2016.

Either way, apps still need their own profile lexicons. A gaming bio is not a professional networking bio is not a dating profile. The context matters, and flattening all of that into one shared record loses the nuance that makes profiles useful.

## Reframing the Question

The real problem isn't "users don't have a default profile." It's discoverability. Apps need a way to say, "this lexicon has profile-like data in it, and here's how to read it." Other apps need a way to find and understand that declaration without hardcoding knowledge of every profile lexicon on the network.

[Ted Han](https://bsky.app/profile/knowtheory.net) pushed me further on this. He was describing an identity management service that aggregates all your profiles and lets you manage them as cards, syncing or not syncing however you want. Not Gravatar, not a base profile. Just an index of your identities across the network.

That conversation helped me see it clearly: the network-level solution isn't a new record type that carries profile data. It's metadata that describes *existing* records. A way for a lexicon to declare, "I'm a profile, and here's where my fields are."

The pieces for that already exist in ATProto.

## Putting the Pieces Together

If you're familiar with ATProto, you know the building blocks. Lexicons are schemas that define the shape of a record. Sidecars are records that add data to another record. If a record with an rkey of `23` defines a username, bio, and avatar, another application could create a sidecar with the same rkey (`23`) that just adds a `websites` field, without modifying the original lexicon.

None of that is new. The idea I've been calling "lexicon generics" is just a specific way of combining these things: a sidecar record that declares a lexicon's role and maps its fields to common concepts.

Here's how it would work. When you publish a profile-type lexicon, you'd also publish a sidecar record using a shared lexicon like `community.lexicon.lexType.profile`, created with the same NSID as your profile lexicon. Its existence says, "this lexicon is used as a profile somewhere." Its contents say, "here's which fields correspond to common profile concepts."

Roughly, the sidecar's lexicon schema might look like this:

```json
{
  "$type": "com.atproto.lexicon.schema",
  "lexicon": 1,
  "id": "community.lexicon.lexType.profile",
  "defs": {
    "main": {
      "type": "record",
      "description": "A set of key-value mappings for a profile-type lexicon.",
      "key": "nsid",
      "record": {
        "type": "object",
        "required": ["mappings"],
        "properties": {
          "mappings": {
            "type": "object",
            "properties": {
              "avatar": {
                "description": "The key of the profile's avatar.",
                "type": "string"
              },
              "displayName": {
                "description": "The key of the profile's display name.",
                "type": "string"
              },
              "description": {
                "description": "The key of the profile's description or bio.",
                "type": "string"
              },
              "pronouns": {
                "description": "The key of the profile's pronouns.",
                "type": "string"
              }
            }
          }
        }
      }
    }
  }
}
```

To make this concrete: on Cartridge, I have the [`games.gamesgamesgamesgames.actor.profile`](https://pdsls.dev/at://did:plc:il7eua5zbt4s2ly2jskjfz2t/com.atproto.lexicon.schema/games.gamesgamesgamesgames.actor.profile) lexicon. A sidecar record for it would look like this:

```json
{
  "$type": "community.lexicon.lexType.profile",
  "mappings": {
    "avatar": "avatar",
    "displayName": "displayName",
    "description": "description",
    "pronouns": "pronouns"
  }
}
```

The mappings are simple here because Cartridge's profile fields happen to share names with the common concepts. That won't always be the case, though. Some lexicons might use `bio` instead of `description`, or `preferredName` instead of `displayName`. The sidecar handles that translation.

If a lexicon doesn't support a field, you leave it out. `dev.npmx.actor.profile` doesn't have an avatar or pronouns field, so its sidecar would be:

```json
{
  "$type": "community.lexicon.lexType.profile",
  "mappings": {
    "displayName": "displayName",
    "description": "description"
  }
}
```

A missing mapping is a signal too. It tells consumers not to bother looking for that field because there's no analog.

The lexicon generic record would live in the same source repo as the target lexicon, right next to it, using the same NSID as their rkeys. Publishing a lexicon and publishing its generic declaration are part of the same workflow.

## What Could This Enable?

If this pattern holds up, it's both a **discovery mechanism** and a **translation layer**.

For discovery, an indexer could crawl the network for `community.lexicon.lexType.profile` records and build a map of which lexicons carry profile data and where their fields live. No hardcoded assumptions about Bluesky. No guessing. Just follow the sidecars. This is exactly what Ariel would need for AtLast, and it's the kind of thing that could support Ted's identity management concept too. An identity manager app could aggregate all your profile sidecars, show you your profiles as cards, and let you manage them, without needing to create or own any profile data itself.

For profile autofill, it could formalize what's currently a manual process. When a user creates a profile on your app, you don't want them staring at empty fields if they've already filled out something similar somewhere else. On Cartridge right now, when a user creates their gaming profile, I autofill from their `app.bsky.actor.profile` if it exists. I pull their display name, avatar, and bio so they're not starting from scratch. The field mappings are hardcoded, and Bluesky is the only source.

Something like lexicon generics could make that more robust. Here's the thing, though, and I think this is important: the autofill should still be **developer-curated**. In the majority of cases, you shouldn't be falling back to every profile-type lexicon on the network. You curate the ones that are good analogs for your app, prioritize them from best to worst, and use the sidecar mappings to pull the right fields. `HyperGamer.com` profiles could prefill from `SuperGamer.com` profiles, and that's a great analog. `TotallyProfeshNetwork.com` profiles could prefill from `LinkedOut.com` profiles. `TotallyProfeshNetwork.com` profiles *should not* prefill from `HyperGamer.com` profiles. Context matters, and the developer is the one who understands their app's context. If the user doesn't have any of your curated analogs? Don't prefill. That's fine.

## This Probably Generalizes

Profiles are the obvious first use case, but there might be other generic types worth thinking about.

Reactions, for instance. Is a Bluesky "like" the same kind of thing as a reaction on a different app? That's for smarter people than me to figure out, but the mechanism for declaring it could look similar. A `community.lexicon.lexType.reaction` sidecar that maps fields to common concepts like `target`, `emoji`, or `sentiment`.

Long form content is another one. Right now the Atmosphere has records from apps like `pckt.blog` and `leaflet.pub`, and plenty of applications using `standard.site` lexicons. If those apps published `community.lexicon.lexType.longFormPost` sidecars with their field mappings, aggregators wouldn't need to manually track every new long form post lexicon that appears on the network. They'd just follow the generics.

## Open Questions

This is early-stage noodling. I literally got out of the shower to write the first draft of that schema. It's illustrative, not a spec. There are real questions I don't have answers to yet. How do you handle versioning? How do you prevent spam sidecar records? What's the governance model for the shared `community.lexicon.lexType.*` namespace?

ATProto's strength is that it doesn't force every app into the same mold. If this idea has legs, it's because it leans into that. It doesn't try to unify profiles into one record. It just tries to make the diversity legible.

If you're building on ATProto and have thoughts, I'd love to hear them. If you can poke holes in it, even better. That's how it gets good.

3 generic profile cards hover next to each other.

User Profiles (animated)

ATProto Has a Profile Problem. Lexicon Generics Could Help.

Yesterday, The Verge published an article about Discord's upcoming global rollout of age verification, and the internet did what the internet does: it panicked. Within hours, several of my communities were already planning their exodus. People were talking about migrating to Matrix, to Signal, to whatever the Next Thing™ might be. I get it — I really do. The knee-jerk reaction to "a corporation wants to tie our anonymous online identities to a physical government persona" is totally valid.

But I think we're angry at the wrong target.

## Read the actual announcement

Here's the thing that frustrated me the most about yesterday's discourse: almost nobody seems to have read Discord's actual press release. The Verge article — which I normally think of as a solid publication — painted a picture that was more alarming than the reality. If we go read [Discord's own announcement](https://discord.com/press-releases/discord-launches-teen-by-default-settings-globally), the picture gets a lot more nuanced.

The changes boil down to this: Discord is making teen-appropriate settings the default for everyone. That means content filters are on, age-restricted servers and channels are locked, DMs from strangers get filtered into a separate inbox, and stage channels require age verification to speak. That's it. If our server isn't age-restricted, if we're not running age-gated channels, if we're not using stage channels — our day-to-day experience on Discord isn't really changing.

Honestly? Some of these changes are ones I'm actually excited about. The updates to DMs and friend requests — flagging and separating unfamiliar senders — address a problem I've been dealing with on Discord for years. If we've spent any time on the platform, we know the drill: unsolicited DMs from randos, spammy friend requests from bots, the whole mess. If age verification means that stuff dries up, I might deliberately play some extra Roblox just to keep the inference model from auto-verifying me, because that feature alone is *chef's kiss*.

Discord is also rolling out an age inference model that analyzes metadata like what games we play, our activity patterns, and behavioral signals. If the system is confident we're adults based on how we already use Discord, we may never have to verify at all. No selfie, no ID, nothing. The escalation to facial age estimation or ID submission only kicks in if we need access to explicitly age-gated content, or if the inference model can't confidently bucket us.

Is it perfect? No. It's a hell of a lot more measured than "Discord is going to scan everyone's face."

## The real problem is in the legislation

Here's where I need y'all to zoom out. Discord isn't doing this because some product manager woke up one morning and thought, "face scans sound fun!" Age verification legislation is rolling out worldwide, and platforms are scrambling to comply.

The EU's [Digital Services Act (DSA)](https://digital-strategy.ec.europa.eu/en/policies/digital-services-act-package) — in force since 2024 — requires online platforms to implement "appropriate and proportionate" measures to protect minors. Simple self-declaration (you know, the "click here if you're 18" checkbox we've all been lying to since we were 12) is no longer sufficient. The European Commission has been actively building a [white-label age verification app](https://digital-strategy.ec.europa.eu/en/news/commission-makes-available-age-verification-blueprint) and published [guidelines under the DSA](https://www.epr.eu/the-european-commission-unveils-child-online-safety-guidelines-and-an-age-verification-app-prototype/) in mid-2025 specifically aimed at tightening how platforms handle minors. France has gone even further with [laws that can fine non-compliant platforms](https://www.euronews.com/next/2025/11/17/the-age-verification-era-which-eu-countries-are-restricting-access-to-adult-sites) up to €300,000 or 4% of global turnover.

On this side of the Atlantic, it's arguably worse:

- As of mid-2025, [25 US states have passed laws](https://avpassociation.com/4271-2/) requiring age verification to access adult content online.
- [At least 13 states have passed laws](https://www.route-fifty.com/management/2025/11/how-states-can-enforce-social-media-age-limits-without-sacrificing-privacy/409622/) restricting minors' access to social media.
- In June 2025, the Supreme Court upheld Texas's age verification statute in [*Free Speech Coalition v. Paxton*](https://www.supremecourt.gov/opinions/24pdf/23-1122_3e04.pdf), giving states a green light to keep pushing.

The Electronic Frontier Foundation (EFF) — hardly a corporate shill — [called the ruling](https://www.eff.org/deeplinks/2025/06/todays-supreme-court-decision-age-verification-tramples-free-speech-and-undermines) "a direct blow to the free speech rights of adults" and warned that it would "deter adult users from speaking and accessing lawful content."

[Nearly 30 additional state bills were introduced in 2025 alone](https://natlawreview.com/article/new-age-verification-reality-compliance-rapidly-expanding-state-regulatory), and lawmakers are already proposing ID checks for things beyond social media and adult content — [skincare products in California, diet supplements in Washington](https://www.eff.org/deeplinks/2025/12/year-states-chose-surveillance-over-safety-2025-review), and some states are even trying to ban VPNs to prevent people from bypassing these laws.

The fundamental problem is that politicians are mandating technical solutions for a problem that humanity hasn't actually solved: tying physical identity to digital identity in a way that's both accurate and privacy-respecting. Every method available — facial estimation, document checks, financial records, parental consent — [falls somewhere on a spectrum](https://www.eff.org/deeplinks/2025/12/10-not-so-hidden-dangers-age-verification) from "dangerous in one way" to "still dangerous, but in a different way." They [create surveillance infrastructure](https://www.eff.org/deeplinks/2025/12/age-verification-coming-internet-we-built-you-resource-hub-fight-back), increase the risk of data breaches (and as we've already seen, that's not a hypothetical concern), and threaten the anonymity that lets people seek support, explore communities, and exist online without a government-issued identity card stapled to their forehead.

We can be mad at Discord for the specific implementation choices they make, and that's fair. But the reason this is happening at all? That's on legislators. Let's direct our energy there.

That said, I want to be honest about something: the legislation argument doesn't fully explain what Discord is doing here. A Canadian reader correctly pointed out that if Discord were only rolling this out where required by law, it wouldn't be a *global* rollout. Canada hasn't passed age verification legislation yet, though it may be heading that direction. [Bill S-209](https://en.wikipedia.org/wiki/Protecting_Young_Persons_from_Exposure_to_Pornography_Act) is actively working through the Senate with broad support, Canada published a [national standard for age assurance technologies](https://dgc-cgn.org/new-national-standard-published-for-age-assurance-technologies/) in August, and their [Justice Minister has signaled upcoming legislation](https://globalnews.ca/news/11542365/meta-app-store-age-verification/) targeting online exploitation. The writing is on the wall in a lot of countries, and Discord is clearly getting ahead of it rather than waiting for a patchwork of compliance deadlines. That's a business decision, not a legal requirement — and it's fair to call that out, even if the underlying pressure is still coming from governments.

I'd much rather see a platform try to find a reasonable middle ground and help shape the legislation into something less horrible than sit back and watch a bunch of politicians — most of whom couldn't explain the difference between a server and a cereal box — dictate the technical requirements.

## Discord's implementation has exit ramps, and that matters

Of the implementations I've seen so far from various platforms, I prefer the approach Discord is taking here. Before anyone accuses me of being a corporate apologist: fuck corporations. I have no particular love for Discord as a company. I don't own their stock. I'm not on their payroll. Admittedly, I have some connections at Discord, but for the most part I'm just a person who uses the platform.

What I like about Discord's approach is that it's layered. The majority of the application remains fully accessible without identity verification. We can chat in our servers, DM our friends, share memes, organize game nights — all without ever touching the age verification flow. The process only escalates when we need access to something that's explicitly age-gated. Even then, the first layer is a passive inference model that might just wave us through based on our existing behavior.

That means most of us can continue using Discord exactly as we do today without engaging in identity verification at all. The sucky parts — the selfie, the ID — are behind doors that most people will never need to open. Will that change in the future as politicians push for stricter rules? Maybe. Probably. But that's a bridge to cross when we get to it, not a reason to burn the one we're standing on.

I do need to address the 800 pound breach in the room. In October 2025, hackers [compromised 5CA](https://discord.com/press-releases/update-on-security-incident-involving-third-party-customer-service), a third-party vendor Discord used for customer service, and approximately 70,000 users had their government ID photos exposed — the exact kind of data that age verification requires people to hand over. Discord has since dropped 5CA and says they're using a different vendor for the global rollout. They've also stated that ID documents are now deleted immediately after verification and that facial estimation selfies never leave the user's device. Those are the right things to say. But "trust us, we fixed it" is a tough sell four months after a breach involving *this exact data*. The EFF has been warning about precisely this scenario — [that age verification creates honeypots of sensitive identity documents that become irresistible targets](https://www.eff.org/deeplinks/2024/06/hack-age-verification-company-shows-privacy-danger-social-media-laws) — and Discord accidentally proved them right. This doesn't change the fact that the legislation is the root cause, but it does mean Discord has to earn back trust on the implementation, and we should hold them to that.

## The exodus problem

Here's what worries me about the reaction I saw yesterday: the rush to migrate. I've been part of enough community migrations to know how this goes. Someone says "we should move to [Platform X]," a chunk of people agree, another chunk doesn't, and suddenly our community is scattered across three different apps that everyone opens less frequently. The sense of community erodes. Connections fade. The vibe dies.

Unless the majority of Discord's user base collectively agrees on a single replacement — and let's be real, that hasn't happened yet — an exodus right now is cutting off our nose to spite our face. We're not just punishing Discord; we're punishing the communities we've built there.

Am I opposed to migrating? Not at all. If something comes along that genuinely replaces Discord in its entirety — fun text chat with cool features, quality voice and video, easy to structure servers, bots, integrations, a critical mass of actual humans using it — I'm in. But right now? That thing doesn't exist. Fracturing communities across a handful of half-baked alternatives because of a policy that, for most users, won't actually change their daily experience? That feels like a bad trade.

That said, the exodus conversations yesterday weren't all bad. I learned about a few alternatives worth keeping an eye on. [Roomy](https://roomy.space/) and [Stoat](https://stoat.chat/) are both interesting newcomers. [Spacebar](https://github.com/spacebarchat/server) paired with [Fermi](https://github.com/MathMan05/Fermi) is a cool self-hosted option for anyone into that. The old guard is still out there — [Ventrilo](https://www.ventrilo.com/), [TeamSpeak](https://www.teamspeak.com/), and [Mumble](https://www.mumble.info/) are all still kicking. I'd encourage everyone to experiment with these. Get familiar with what's out there. Just don't nuke our existing communities in the process.

## Where this leaves us

I don't love that we're here. The anger is valid — nobody should have to hand their face or their government ID to a corporation just to use a chat app. The point of this article isn't to defend Discord; it's that Discord isn't the one writing these laws. Governments worldwide are mandating age verification, and every platform we use is going to have to figure out how to deal with it.

I also want to acknowledge that for some people, this isn't a future concern — it's an immediate one. For anyone whose safety depends on keeping their identity separate from their online presence, the introduction of any identity verification system is a real threat, not an inconvenience. That reality should be front and center in every conversation about these laws.

If we're in the US, the [EFF's Age Verification Resource Hub](https://www.eff.org/age) is a great place to start. They track active legislation, provide tools to contact representatives, and are actively fighting these laws in court. Save our anger for the legislators writing them. Channel it into something productive.

In the meantime, let's protect what we've built. Experiment with alternatives, hold platforms accountable, but don't shatter the communities we care about in the process.

Discord

Discord Isn't Requiring a Face Scan — Your Legislators Are

That’s right, I’m in Minnesota with my girlfriend visiting her family for the holidays. It’s a snowy wasteland outside and I have been informed that it will be getting worse between now and Saturday. Saturday, the day we were supposed to leave. Crap.

Since I’m stuck inside with no design software I decided that I would update with my latest typography rant… on how much I hate Papyrus.

No, not the old Egyptian material from which we derive the English word for paper, but rather the display font of the same name. Notice I said DISPLAY FONT. That’s important.

What sparked this? James Cameron’s visual masterpiece “Avatar”. What it lacked in a slightly dated story it made up for in beautiful CG and strangely appealing, scantily-clad alien women. So where does Papyrus and my disdain for it come in? In the subtitles, that’s where.

As stated by Wikipedia, Papyrus was designed in 1982 by graphic designer [Chris Costello](https://chriscostello.design/fonts/) when he was fresh out of college. Chris bit off a pretty big chunk with his first font, too… It took him 6 months with a calligraphy pen and textured paper to create it, and that was just the upper case set! Chris also mentioned in a [2007 interview](http://www.iheartpapyrus.com/2007/05/interview-with-papyrus-creator-chris.html) with [IHeartPapyrus.com](http://www.iheartpapyrus.com) that he now has to hide his face in public due to the scathing the font receives these days.

So let’s break this down and figure out just why it is that Papyrus sucks so very much.

As stated earlier, Papyrus was meant to be used as a display font. What that means is that it’s meant to be used at larger sizes (usually 36 points or higher) for things such as newspaper headlines or book titles. What they’re not meant to be used for is **EVERYTHING ELSE**. The major problem is that at some point Papyrus was added to the list of Mac OS system fonts and is now accessible to everybody, including good designers, bad designers, and non-designers. As designer Costello stated in the interview, “After she was released into the wild, her design career was finished.”

It’s latest uses include text on the side of Arizona Iced Tea cans, the Lamb of God logo and all of their album covers, and the (as stated earlier) subtitles in the new James Cameron movie “Avatar”. Beyond that it’s also used on pretty much every homemade business card, health and wellness shops, greeting card shops, amateur brochures and church flyers.

Ultimately I agree with the font designer about the reason this font is no longer usable in design… It’s not that it’s ugly, as a matter fact it’s quite the contrary. The font itself is aesthetically sound. The problem is with the overuse and misuse of the font by anyone with a computer. It can be found anywhere and everywhere as illustrated by [IHatePapyrus.com](https://web.archive.org/web/20111102161343/http://ihatepapyrus.com:80/) and IHeartPapyrus.com. Due to it’s ubiquitous nature many graphic designers and typographers rip into the font and it’s designer like they’re something to be spat on and thrown in the dump… Rather I think it’s a stigma with the function, not the form, that’s causing the problems found with Papyrus these days.

So if you care about the happiness of Chris Costello (or any good designer for that matter), do us and yourself a favor and don’t use Papyrus. Rather, look for a better font. There are some great resources to find plenty of FREE fonts that could easily fit your purpose. Here are some links to make sure you can find other fonts to help us creative minds maintain our sanity:

* [Misprinted Type](https://www.misprintedtype.com/)
* [DaFont](https://www.dafont.com/)
* [Font Squirrel](https://www.fontsquirrel.com/)
* [Fonts.com](https://fonts.com)
* [MyFonts.com](https://myfonts.com)

It's Christmas Time... With Papyrus

Searching through Dev Documentation Straight from Discord, Powered by Algolia

I created [this tweet thread][Tabs vs Spaces Twitter thread] a while back about the <kbd>Tab</kbd> vs <kbd>Space</kbd> debate and I've had to share it _a lot_ since then. I decided it's finally time to get into this for real, and help people understand the impact that their "personal preference" is having on those around them.

## TL;DR

The short version is that you can configure the width of <kbd>Tab</kbd> characters. You cannot, however, configure the width of <kbd>Space</kbd> characters. This may not affect you, but the ability to adjust the width of a tab is extremely helpful for folx that use assistive technologies while writing code. Stop using spaces and switch to tabs if you actually care about other people. If not, feel free to continue being an inconsiderate butthole. Just know that I've seen your IP address and **I am judging you.**

## What's the difference between Tabs and Spaces?

Many people are under the impression that these two characters are basically the same thing, and nobody could blame you for thinking as much. Let me assure you, however, that they are *very* distinct. A Tab isn’t just a bunch of Spaces; it is its own, distinct character. The <kbd>Tab</kbd> KEY can be configured in most editors to produce either a Tab character _or_ a number of Space characters, but they *are not interchangeable.*

While the Space is a natural part of most written languages, the Tab actually comes from a bit of keyboard history...

### The History of the Tab key

As with most keyboard quirks, the <kbd>Tab</kbd> key comes from the days of the typewriter. See, when typists wanted to create a table on a document, they would smash the <kbd>Space</kbd> and <kbd>Backspace</kbd> keys a bajillion times to get things to line up. This sucked.

To solve this problem, a guy named Fredric Hillard invented — well... he at least filed a patent for — a horizontal bar that could be added to the typewriter. On this bar were a series of clips that could be adjusted which were known as Tab Stops. Pressing the <kbd>Tab</kbd> key on the typewriter would advance the carriage (the typey thingy) to the next Tab Stop. This made it a gazillion times easier for typists to align their tabular data!

![Robert Downey Junior as Tony Stark in "Avengers: Age of Ultron." He's approaching a wall in hopes of it being a secret door, then quietly exclaims, "Yay!" when it turns out that it is, in fact, a secret door.](https://media.giphy.com/media/jUAFYkw2OA1KtqqsWT/giphy.gif)

The Tab key has evolved a lot since then, but its original purpose remains: _to allow users to control the size of whitespace in a document._

## Okay, but back to why this matters to you...

The reality is that it may not matter to you directly. If you like 2 Spaces or 4 Spaces or 12 Spaces, that's great for you. The issue is that your teammates may not like that same configuration. Beyond just not liking it, they may be _directly harmed by it._ You may work best with 2 Spaces for indentation, but do you really want to be the jerk on the team that makes it harder for somebody else? Ian Coldwater nailed it in their tweet:

<Tweet id={'1344061670742654977'} />

### How could spaces possibly cause harm?

There are at least a couple groups _I know of_ that are directly impacted by this (note that there may be others I'm not familiar with): people with dyslexia, and people using braille readers.

#### How indentation affects dyslexics

If you're not familiar with Dyslexia, then you may not understand how it actually impacts people. Dyslexia is commonly thought of as being associated with things like mirror writing (writing and reading words and letters backwards), but it's much more complex. It's a disconnect in how the brain processes written words and text (the medical term for this is "decoding"). Most people with Dyslexia have it from birth, though there's also Alexia (not the voice assistant) which occurs as a side-effect of neurological trauma.

Wanna take a guess at one thing that makes it easier for people with Dyslexia or Alexia to read code? **Larger indentation.** By adding more significant indentation, it becomes easier for dyslexic brains to differentiate between content and helps to prevent mixing of lines.

Alright, maybe you don't know anybody with Dyslexia or Alexia (you probably do and they don't tell people because they don't want to hear another person say, "It's so cool that you can write backwards!" 😠), but do you know anybody with Attention Deficit Hyperactivity Disorder, more commonly known as ADHD? Once again, if the answer is "no" then it's really yes and you're too daft to realize it, but people that suffer from ADHD can *also benefit from larger gaps in indentation.* Breaking lines up more makes it easier for ADHD readers to focus on the current line, rather than being distracted by multiple lines being bunched together.

#### You're making things harder for braille readers

Assistive technologies are _incredible_ tools that make it easier for disabled people to access things that are originally designed for non-disabled people. [Refreshable braille displays](https://en.wikipedia.org/wiki/Refreshable_braille_display) (RBDs) are one such technology, and they're commonly used by blind programmers. RBDs have some number of cells — squares with eight little holes — and they work by extending or retracting small pegs through the holes of each cell. One cell === one character. The RBD then updates depending on where the user's focus is on the screen. For example, if they're focused on a line of code the display will update so that the cells represent the characters in that line of code.

These readers can have anywhere from 10 to 80 cells, with the most common ones being between 20 and 40 cells. The more cells, the higher the cost. I'm willing to bet you know where I'm going with this.

If your code uses 4 spaces for indentation and a programmer is using a 20 cell RBD, on the third level of indentation — `4 ⨉ 3 = 12` spaces — they only get 8 usable cells. The rest is all wasted space because you wanted to feel superior in enforcing your code style on your teammates. Tabs, however, only take a single cell. At the third level of indentation the RBD still has 27 usable cells.

#### How about that personal preference thing?

Personally, I like small indentation. I prefer it to be no larger than 2 spaces, because anything larger actually makes it *harder for me to follow the code,* so I can't help out with my friends' projects if they really like to indent their code with 8 spaces. As far as I'm aware, I don't suffer from any reading or learning disorders, and the way other people indent their code *still affects me.*

The point _in case you haven't gotten it yet_ is that **it's not about you.** It's about everybody else that will ever look at your code.

### But nobody will *ever* look at *my* code

Think again.

**That tiny side project you've been working on that's published to Github?**
Somebody has probably seen it and taken some nifty tricks away.

**That private repo that you created for the project you want to make money off of?**
If you ever need to scale that project, other people _will_ be working in your codebase.

**That chatbot you made that nobody will ever see because it'll expose all of your deepest, darkest secrets?**
One day, you may let it fall by the wayside, and that's okay! If this happens, you should open source it so others can learn from it. When you do, *other people will look at your code.*

## Conclusion

If you haven't seen it impact others, it's easy to dismiss things like this. The way that it impacts you feels inconsequential, and the debates where you can be right without anybody actually being right can even be fun sometimes. The reality here, though, is that accessibility issues aren't fun for disabled people, and invisible disabilities are just as real as physical ones — they're just harder to handle when you aren't already accounting for them.

## BONUS: Making the switch

This script will convert all of your JavaScript files to tab indentation. Please use it and show your colleagues that you give a damn. If you need to adjust indentation in other types of files, just update `'*.js'` to `'*.ts'` or `'*.css'` or `'*.rs'` or whatever other file extension.

```bash
#! /bin/bash
for i in `find . -name '*.js' ! -path '*/node_modules/*'`; do
  echo $i;
  cat $i | unexpand -t2 > $i.converted;
  mv $i.converted $i;
done
```

If you're looking for a one-liner then you can drop this into your terminal:

```bash
for i in `find . -name '*.js' ! -path '*/node_modules/*'`; do echo $i; cat $i | unexpand -t2 > $i.converted; mv $i.converted $i; done
```

If you're looking to make it easier to keep using tabs in your projects, install the [EditorConfig][EditorConfig] extension for your editor and put this in a `.editorconfig` file at the root of your project:

```editorconfig
[*.{js,css,scss}]
charset = utf-8
indent_style = tab

# YAML sucks and requires Spaces.
[*.yml]
indent_style = space
indent_size = 2
```

This will make it so that everyone's editors will use the correct type of indentation, but they can configure it to look the way that they prefer.

### A few parting thoughts...

#### Prettier
[Prettier](https://prettier.io/) has a long-running issue (since 2020) for [making Tabs the default](https://github.com/prettier/prettier/issues/7475) over Spaces. The team seems to have decided to leave the issue open and ignore, but you can always go add a comment in support of the change!

#### Biome
Since I originally published this article, [Biome](https://biomejs.dev/) has become quite popular as an alternative to Prettier. The best part is that it enforces tabs by default! 🥳

#### VS Code
[An issue](https://github.com/microsoft/vscode/issues/156304#issue-1318328510) was opened on the VS Code repo to set indentation to tabs by default, but it was shot down. 😞

[EditorConfig]: https://editorconfig.org/
[Tabs vs Spaces Twitter thread]: https://twitter.com/TrezyCodes/status/1292473686021177344

Refreshable Braille Display by Elizabeth Woolner via Unsplash

There's only one option, and it's not about your "personal preference."

"Tabs vs Spaces" Is All Sorts of Messed Up

Today [yoav-lavi][Yoav Lavi Github] announced [Melody][Melody Repo], a language that compiles down to ECMAScript RegEx. Now, I write _a lot_ of RegEx, so this project immediately piqued my interest.

Since the project was only released a couple days ago, it's lacking several important features. For example, you can't...

* set flags (`i` for case insensitivity, `u` for unicode support, `g` for global search, etc)
* ~~negate ranges (e.g. `/[^A]/`)~~ (turns out this is possible with Melody's [`raw`][Melody Raw] functionality)
* create arbitrary multi-ranges (e.g. `/[a-c1-3]/`)
* pass in variables (JavaScript, not RegEx)

All that said, the syntax is pretty slick. Here's a simple example from the docs for finding a hashtag in a string:

```js
"#";
some of <word>;
```

Here's the RegEx that's output:

```regex
/#(?:\w)+/
```

The syntax is interesting, but I'd argue that if you didn't know RegEx then you'd find the Melody version to be **infinitely more readable.**

## Interesting Syntax

Let's talk about some of the ways Melody makes RegEx more human readable and less like using blood to draw runes into the dirt for the purposes of enacting an arcane incantation.

### Symbols

[Symbols][Melody Symbols] are Melody's way of simplifying a lot of common RegEx tasks. For example, if you want to capture any normal Latin character in any case, you might write `[a-zA-Z]`. With Melody, though, you can use the `<alphabetic>` symbol! There are ~16 symbols as of this writing, but here are some of my favorites so far:

* **`<char>`**
    An alternative to the wildcard (`.`) character, which matches _anything_. `<char>` takes all the guess work out of figuring out if `\\\.` is a wildcard or a literal period character. 🙃
* **`<word>`**
    RegEx escape codes are _extremely_ useful, but it's not always clear what they're doing. The `<word>` symbol matches any word character. This is the same as the `\w` escape code in RegEx.
* **`<alphanumeric>`**
    Matches any Latin character (`A-Z`) in any case (`a-z`), as well as numbers (`0-9`). This is the same as using `[a-zA-Z0-9]` in RegEx.

#### Special Symbols

As of this writing, there are two special symbols: `<start>` and `<end>`. These symbols correlate to the `^` and `$` characters, respectively. They're used to indicate that the search must start at the beginning or the end of the string, or if the search should be all-inclusive (when using both symbols).

### Quantifiers

[Quantifiers][Melody Quantifiers] allow us to, uh... well, they allow us to _quantify_ our expressions. For example, you might use something like this to check for a UUID with RegEx:

```regex
/^\w{8}-\w{4}-\w{4}-\w{4}-\w{12}$/
```

Here, `{8}`, `{4}`, and `{12}` are all quantifiers. They indicate that you want exactly 8, 4, and 12 respectively of the preceding search. With Melody, this would be handled with the `... of ...` quantifier:

```js
<start>;
8 of <word>;
"-";
4 of <word>;
"-";
4 of <word>;
"-";
4 of <word>;
"-";
12 of <word>;
<end>;
```

If you need a number of characters within a certain range, you can use `{min,max}`. For example, `\d{1,2}` would indicate that you want between 1 and 2 digits. Melody provides the `... to ... of ...` quantifier:

```js
1 to 2 of <digit>;
```

Melody also provides alternatives for the `*` (zero or more), `+` (one or more), and `?` (zero or one) quantifiers:

```js
// \d*
any of <digit>;

// \d+
some of <digit>;

// \d?
option of <digit>;
```

### Character Ranges

When searching for something within a known character set you need to use a character range (hexadecimal, for example, would be `[0-9a-f]`). Declaring ranges is handled by the `... to ...` expression.

```js
// [a-f]
a to f;

// [1-5]
1 to 5;
```

### Groups

One of the most vital features of RegEx is groups! Capturing and non-capturing groups make it possible to create extremely complex searches. Melody enables these `capture`, `match`, and `either` groups.

To capture the major, minor, and patch versions of a [semver][semver] string:

```js
capture major {
  some of <digit>;
}

".";

capture minor {
  some of <digit>;
}

".";

capture patch {
  some of <digit>;
}
```

If you need to match a search without capturing it, you can use `match`. If you need to join multiple `match` statements together, you can use `either`. Here we'll use both to handle the lack of multi-ranges to match a 2-digit hexadecimal value:

```js
2 of match {
  either {
    0 to 9;
    a to f;
  }
}
```

### So Much More!

Melody supports lots of other features, so make sure to [check out the docs][Melody Docs]!

## Putting Melody Thru Its Paces

The basic examples are cool and all, but I wanted to convert some of my real world RegExes to Melody to see if the readability argument still holds up.

### A Simple Test

While working on my game ([debug][debug Game]) recently I wrote a RegEx to grab the name, vendor ID, and product ID from a gamepad. Here's what the original version I wrote looked like:

```regex
/^(.*?) $(?:standard gamepad )?vendor: (\w+) product: (\w+)$$/ui
```

The only issue I have with converting this to Melody is that Melody doesn't support flags, so my `u` (unicode) and `i` (case insensitivity) flags won't translate. For now I can handle that on the string before passing it to Melody's RegEx, but it's deffo a sizable shortfall to keep in mind.

Without further ado, here is my original RegEx converted to Melody syntax:

```js
<start>;

capture {
  lazy any of <char>;
}

<space>;
"(";

option of match {
  "standard gamepad ";
}

"vendor: ";

capture {
  some of <word>;
}

<space>;
"product: ";

capture {
  some of <word>;
}

")";

<end>;
```

It's a lot more verbose than the original RegEx, but that's what we want! The resulting Melody version is definitely more _human_ readable than the original RegEx, though if you already know how to read RegEx then it's debatable whether or not the Melody version is more readable.

~~The weirdest thing I've noticed is that Melody tends to add more non-capturing groups than necessary.~~ Yoav has already [addressed my issue][Unnecessary NCGs Issue] and published a fix for the unnecessary non-capturing groups! 🥰

### Let's Get More Complex

Last year I ran across an absurd Password Validation challenge. You can see my solution in action on [RegExr.com][Password Validation Challenge], but here's the actual RegEx I came up with:

```regex
/(?:.*(?:(?:[A-Z].*(?:[0-9].*[a-z]|[a-z].*[0-9]))|(?:[a-z].*(?:[A-Z].*[0-9]|[0-9].*[A-Z]))|(?:[0-9].*(?:[A-Z].*[a-z]|[a-z].*[A-Z]))).*)/
```

Every time I go back and try to read it... 🤢

The fact that this RegEx is so impossible to read is _exactly why_ I thought it would be a great test of readability for Melody. Let's take a look at what the Melody version looks like:

```js
match {
  any of <char>;

  either {
    match {
      A to Z;
      any of <char>;

      either {
        match {
          0 to 9;
          any of <char>;
          a to z;
        }

        match {
          a to z;
          any of <char>;
          0 to 9;
        }
      }
    }

    match {
      a to z;
      any of <char>;

      either {
        match {
          A to Z;
          any of <char>;
          0 to 9;
        }

        match {
          0 to 9;
          any of <char>;
          A to Z;
        }
      }
    }

    match {
      0 to 9;
      any of <char>;

      either {
        match {
          A to Z;
          any of <char>;
          a to z;
        }

        match {
          a to z;
          any of <char>;
          A to Z;
        }
      }
    }
  }

  any of <char>;
}
```

That's... a lot to chew on. However, it is _undeniably_ easier to read than the original RegEx! ❤️

## Final Thoughts

Melody seems like it'll be an _excellent_ addition to the JavaScript ecosystem! It's got a ways to go, but I'm personally excited to watch how it matures.

In case [Yoav][Yoav Lavi Github] is reading this, lemme tell you what I'd _looove_ to see: I can write my RegEx by creating a `.melody` file, then I can `import myRegex from './my-regex.melody'` and use `myRegex` directly in place of a regular RegEx! There's a Babel plugin that allows writing Melody within template strings, but it'd be amazing to be able to write it in completely separate files and have it imported via a custom Webpack loader or Rollup plugin. HMU if you wanna pair on that project. 🥳

## Updates from Yoav

Yoav informed me (via [Reddit][Yoav's Reddit Comment]) that they've fixed the issue generating [unnecessary non-capturing groups][Unnecessary NCGs Issue]! They also mentioned a couple things I thought were worth reiterating here:

* Negated character classes already have an undocumented initial implementation with updates coming soon
* Other than flags, Melody supports _every RegEx feature_ via the [`raw`][Melody Raw] method

[debug Game]: https://trezy.itch.io/debug
[Melody Docs]: https://yoav-lavi.github.io/melody/book
[Melody Quantifiers]: https://yoav-lavi.github.io/melody/book/syntax.html#quantifiers
[Melody Raw]: https://yoav-lavi.github.io/melody/book/syntax.html#raw
[Melody Repo]: https://github.com/yoav-lavi/melody
[Melody Symbols]: https://yoav-lavi.github.io/melody/book/syntax.html#symbols
[Password Validation Challenge]: https://regexr.com/4esbn
[semver]: https://semver.org
[Unnecessary NCGs Issue]: https://github.com/yoav-lavi/melody/issues/70
[Yoav Lavi Github]: https://github.com/yoav-lavi
[Yoav's Reddit Comment]: https://www.reddit.com/r/webdev/comments/tw0vcg/comment/i3jygi5

Melody: A New Way To RegEx Header

Melody: A New Way to RegEx

As some of you may already know, I've been preparing to go live again in February of this year! I've missed streaming **sooooooooo** much, and I've missed all of you as well! I'm incredibly excited to get back to streaming on a regular schedule so we can build some awesome projects together. ❤️

The thing is... I won't be doing it on Twitch.

## SAY WUT‽

I know, I know. Twitch is _the place_ to livestream these days. In fact, when I first started streaming all those years ago I was using YouTube! I ended up switching to Twitch because the experience from the streamer's perspective was just _so much better_.

A lot has changed over the years, though. YouTube Live has been making a bid to take on Twitch in terms of features and content, and you know they're serious because they've poured _tons_ of money into getting some of the biggest streamers on Twitch to move over.

Speaking of people moving from Twitch to YouTube, the list is impressive. Here's a few of them in no particular order:

* [Valkyrae](https://dotesports.com/streaming/news/valkyrae-on-move-to-youtube-i-can-truly-focus-on-making-content-that-im-proud-of)
* [TimTheTatman](https://gamerant.com/timthetatman-youtube-exclusivity-twitch-hate-raids/)
* [Ludwig](https://www.msn.com/en-us/news/technology/record-breaking-twitch-streamer-ludwig-ahgren-is-moving-to-youtube/ar-AARiuQK)
* [DrLupo](https://gamerant.com/dr-lupo-leaving-twitch-youtube-exclusivity-deal/)
* [CouRageJD](https://www.dailyesports.gg/couragejd-leaving-twitch-exclusive-youtube-streaming-deal/)
* [LazarBeam & Muselk](https://www.cnbc.com/2020/01/13/youtube-signs-valkyrae-and-other-gaming-stars-to-combat-amazon-twitch.html)

...and these are just the popular streamers that _had_ big contracts with Twitch and now have big contracts with YouTube. The list gets _much_ longer if you add in regular, every day streamers like myself that have already made the transition. There are rumors of even more popular streamers that are thinking about jumping ship, too.

I'm not doing this because of them, though...

## The Real Why

I would be lying if I said none of this has had an impact on my decision, but the core reasons are (I hope 🤞🏻) a bit less superficial. Let's talk about the three core reasons that I'm moving.

### Discoverability

Twitch has basically zero discoverability. What that means is that if you're not already a large streamer on Twitch, you're not likely to get there just by streaming because nobody can find you on the platform.

That's because when a viewer goes to Twitch, the front page lists everything based on viewership. If a channel or a category has the most viewers, it'll stay at the top of the list and gain more viewers. The opposite is true for channels with few viewers: they'll be staying at the bottom of the list, undiscoverable.

The only remedy for this is to build your audience on other platforms and funnel them to your Twitch channel. There's one platform that's most effective above all others. Care to guess which one?

It's YouTube.

Now, the discoverability for livestreams on YouTube is just as dismal (if not moreso) than on Twitch. However, if you create **static content** on YouTube — that is, normal videos rather than live content — it is imminently discoverable. Now when somebody subscribes based on your static content, they'll also be notified when you go live. You don't have to promote your Twitch channel in every video and hope viewers will jump on over to another site to subscribe there. The channels are locked together, and viewership on one begets viewership on the other.

It may seem like a small thing, but I'm making a bet that it'll have a large impact for a smaller streamer like myself.

### Community

If I just cared about building a brand and becoming a gazillionaire from my videos and streams, I'd probably stop with discoverability. That's not the whole story, though. The main reason I care about _discoverability_ is because it contributes to my _community_.

Twitch was good to me for almost 3 years as I grew my audience and my community. During my hiatus it's certainly dwindled, but I love the amazing folx over on my [Discord server](https://discord.gg/k3bth3f) (you should [come hang out with us](https://discord.gg/k3bth3f)!) and I want to see that group growing again. By growing my audience through better discovery, I'll also be growing my community on Discord!

If you want me to get in–depth with my plans for growing the community in a later article, let me know on [Twitter](https://twitter.com/TrezyCodes)!

### Let's Get Technical

The final reason is also the first thing that got me looking into jumping ship, and that's the technical capabilities of YouTube.

On Twitch, there's only one quality setting for most streamers. If a streamer is broadcasting in 4K, all of their viewers are going to need good enough connections to watch in 4K. It's great for people like myself with fast internet, but it's awful for viewers with slower connections! To be fair, Twitch does offer transcoding for some streamers, but you need to be partnered and have a very high viewership for it to be available. Ths is why most streams on Twitch are limited to 1080p and 3,000kbps or less.

On YouTube, _everybody gets transcoding_. When I go live on YouTube next month, I'll be streaming 4K content with a bitrate of 15,000kbps. For those with fast internet, this will be an excellent experience! For others, they can watch a lower resolution version of the stream without issue. ❤️

## Conclusion

Twitch was the right platform for me for several years, but it's time for me to move on. I'll be going [live on YouTube](https://youtube.com/c/TrezyCodes1) for the first time on February 17th at 6pm CT, and I hope I'll see you there. ❤️🥰❤️

A teal wood panel with the word, "goodbye," painted on it.

Goodbye

It's Time to Move On From Twitch...

Honestly, there are plenty of solutions to this. You could:
* Push more often;
* Backup your hard drive at least once every 12 nanoseconds;
* Put your laptop in a [hermetically sealed plastic bag][laptop ziploc].

While ~~all~~ most of those are valid solutions, I've got something slightly different. Instead of trying to protect your computer, why not stop relying on it all together? That's right, my digital nomads. This *one amazing trick* will allow you to eliminate your reliance on a single device, opening up the possibilities for you the next time your computer *literally catches on fire*.

<figure>
![My real computer catching on fire.][my computer on fire]
  <figcaption>My very real computer catching on very real fire.</figcaption>
</figure>

## Enter `code-server`
[`code-server`][code-server] is a magical piece of software from [Coder][Coder]. It allows us to run [VS Code][VS Code] on a cloud server, meaning that we no longer have to worry about maintaining our physical machine! Let's take a look at some of the massive benefits of using `code-server`.

### 1. It runs in the browser!
Because `code-server` runs in the browser, you can use it from *any device with a modern browser.*

**Chromebook?** No problem.

**iPad?** Doneskis.

**Raspberry Pi?** You know it.

**Palm Pilot?** Yea- uh, well… I did say *modern* browser. 😬

The added benefit here is that even if your device has limited resources — low RAM, tiny CPU, no *NIX environment — you'll still be able to work on your projects!

### 2. It has all of your favorite extensions!
Not only can you use VS Code in the browser, but you can also still use most of your favorite extensions! As a JavaScript developer, this is one of the most important parts for me.

NOTE: The `code-server` marketplace is more limited than the marketplace for VS Code because of Microsoft's Terms of Service, but if there's a missing extension, you can always request to have it added!

### 3. The built-in terminal works!
The `code-server` terminal works just like you'd expect! If you need to run your app, install new packages, or `cat` your SSH key, the built-in terminal has you covered. It works exactly like the terminal in a local installation of VS Code, and from it you can perform any task that your user is allowed to do!

## Conclusion
I've been using [`code-server`][code-server] for a little over a week now, and it's just a joy to use. My laptop finally has enough storage space to install that update I've been clicking away for months *and* my personal development pipeline is faster than ever! While those plastic laptop baggies might be a pretty solid back up plan, the best solution is to just get your code off of your laptop!

[my computer on fire]: https://images.contentful.com/6gqb05wxpzzi/4rfjeCKMTN1TM3xz3BfWO1/489c16455a96a7183a3f296221ee7777/my-computer-on-fire.gif "Enjoy this real clip of my real computer catching on real fire. 🔥"
[code-server]: https://github.com/cdr/code-server "code-server repository on Github"
[Coder]: https://coder.com "Coder website"
[laptop ziploc]:  https://www.ohgizmo.com/laptop-ziplocs-let-you-surf-the-web-in-the-shower/ "Laptop Ziplocs Let You Surf The Web In The Shower"
[VS Code]: https://code.visualstudio.com/ "VS Code website"

What would you do if your computer caught on fire?

I posted a gif of some new game dev work, and the amazing [@TimBeaudet][Tim Beaudet's Website] asked me a few questions about what I'm working on.

<figure>
![Screenshot of the MOAR game, specifically the quick stats UI which displays the character's name, current health and mana, and avatar.](https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F15263bd8-049b-495f-bd2c-f182101f329b%2Fcharacter-preview.gif?alt=media&token=f5667cd4-9d2f-40b6-bd7c-8b637a6fd93d)
  <figcaption>Screenshot of the MOAR game, specifically the quick stats UI which displays the character's name, current health and mana, and avatar.</figcaption>
</figure>

## Is it a big idea?
Holy crap yes and simultaneously not even a little bit. 🤣

*The story goes something like this...* Early last year, I woke up from a weird dream at 4am and had the code in my head to build an inventory management system in JavaScript. I snuck down to the office and wrote it all out. I was pretty happy with my creation, so I figured... why not build the rest of a game? And so began my first *real* foray into game dev.

## What was learned from Attempt #1?
My first idea was to build a simple game, then expand from there. I was heavily inspired by CrossCode and Moonlighter, so I intended to dig in with a game that combined some elements of both of those. I reached out to an artist friend of mine to see if he was interested. We started working together on some worldbuilding, some art, and developing the main story arc of the game. The idea was to build this region that was cut off from the rest of its continent. If the game turned out well, we could build the rest of the world on top of the engine and the world (heh) would be our oyster.

There were two roadblocks that prevented me from moving forward on that attempt. The first was that I wanted to go in a pixel art direction, and my artist buddy wasn't into it. He produced a couple gorgeous pieces of concept art for me, but when he tried converting it to art we could use (I had decided I wasn't married to pixel art, he could kind of do whatever) he lost motivation.

The second roadblock was game physics. I had built my own game engine, and I ran into a thousand issues when I tried to reconcile the renderer with the physics engine. That killed my motivation and I shelved the project for a few months.

## What was learned from Attempt #2?
Several months later, I dug into my second attempt because I was itching to get back to doing some game dev. I had decided I wanted to fiddle with an MMO and net code (because why would I **decrease** the scope? I mean c'mon...). I grabbed some free art from OpenGameArt.org (artist CalciumTrice, who I absolutely adore) and threw stuff together. The net code was surprisingly easy. I knocked all of that out, but then I ran into new physics engine issues (HOW ON EARTH DOES A RIGID BOX SQUEEZE THROUGH AN IMPERCEPTIBLY SMALL HOLE‽). After smashing my head against that issue for a couple of months, rewriting both the renderer and the physics code multiple times, my motivation was shot.

## Attempt #3?
Alright, here’s the setup:

> You’re on a farm. Somebody has asked you to go collect some logs and bring them back to the farm. Go do that.

The story isn’t exactly robust, and that’s okay. The plan is to finally get a tiny functional prototype done and get the gameplay to just *feel good*. From there I can turn the game into whatever I want. I’d like to revisit the larger stories I wrote for the previous two attempts and merge them into something that can drive development for this latest attempt, but *everything* is up-in-the-air atm.

## Takeaways:
* Don't allow people to engage in things if they seem hesitant. They don't want to do it!
* Physics are hard.
* Scoping down is *holy bananacows important.* Large scopes make it really difficult to focus on the basics.

[Tim Beaudet's Website]: https://timbeaudet.com/

Making a Video Game in Zero Easy Steps!

[Ana Tudor][Ana Tudor Twitter] asked this morning about using the Chrome DevTools for testing CSS performance:

<Tweet id={'1237009588664352771'} />

Chrome's performance tools have come a loooong way in terms of measuring performance on all sorts of scales, so I figured I'd take this opportunity to dig in and better educate myself on how to use them. What follows is the result of my endeavor to figure out what these graphs and charts mean. 😬

## TL;DR

Honestly, I'm not sure the Performance tab has that much to offer in terms of debugging CSS. It may be able to help define the *when*, but from my cursory dive I don't see it helping me identify the *why*. If others have more insight, I'd love to have somebody prove me wrong. 🥰

## Okay, what are we looking at?

This is a screenshot of the Chrome DevTools on the [about][about] page. This page has a decently meaty animation when it loads up, so I figured it'd be a good place to test this stuff out.

<figure>
![][devtools performance screenshot]
</figure>

## The Timeline
The first thing I did was try to understand what each section of the Performance tab is for. I started with the timeline at the top of the pane.

<figure>
![][devtools performance timeline screenshot]
</figure>

The timeline looks *super* interesting. At first glance, it seems like it's able to enlighten me with all sorts of valuable data. At second glance, I realize I find it *completely unintelligible. After clicking at random and hovering around a bit, I think I was able to glean some details on how to use it to track performance.

First off, you can grab the handles at either end of the timeline and drag them in to minimize the amount of data that's currently under analysis. This alters what you see in the rest of the tab, too.

Second, Chrome seems to have recorded what the site looks like as it renders. Hovering over any point on the timeline will show you a thumbnail of the site at that precise moment. This feature is what we in the industry often refer to as *hella cool*.

<figure>
![][devtools performance timeline gif]
</figure>

I've now minimized the data under analysis by using the thumbnails and pulling the handlebars to the beginning and end of the animation I'm wanting to analyze. 😎

### The... Other Timeline?

Okay, so below the complete timeline is another timeline with much more in-depth information. Again, this looks *super* useful, but I'm not entirely sure what to make of it. One thing I will say is *do not scroll while hovering this timeline*. It turns out that scrolling adjusts the selection in the full timeline up top. FML.

Okay, I'm going to try to reduce scope so I only have to understand a part of this, rather than the whole thing. First thing, I'm going to disregard the `Network`, `Timings`, `Chrome_ChildIOThread`, and `ThreadPoolForegroundWorker`. I'm sure they're all useful, but they don't seem immediately related to what I'm interested in.

Clicking the arrow to open the `Main` section is... holy cow it's noisy. When I hover over it I see a lot of things like `Schedule Style Recalculation` and `Recalculating Styles` (I really want it to say `Reticulating Splines` in here somewhere...), so I'm sure this something I'm going to dig into, but I'm going to put it off until last. The other pieces look *way* less noisy.

Opening the `Raster` section, I feel like I'm getting somewhere. I see two things underneath it — `Rasterizer Thread 1` and `Rasterizer Thread 2`. With all this talk of threads, I suspect this whole graph is about the browser's processor utilization. Most of these categories are probably related to the CPU, though there's a separate section specifically for the GPU that I'm excited to get to. Anywho, the `Raster` section. By definition, rasterization means:

> "to convert into pixels for screen output; convert into a raster image"
> *via [The Free Dictionary][rasterize definition]*

So this is very probably referring to the browser taking already generated images and preparing them, pixel-by-pixel, for rendering.

Next, I'm going to skip down to the `Compositor` section. There's only a single timeline underneath it. Compositing generally refers to taking two or more things and combining them to make a single thing. I'm guessing this is the browser taking the different pieces chunks of DOM, positioning them appropriately, then sending them as a single hunk to the `Rasterizer` to turn it into an image that can be rendered.

The `GPU` section is actually kind of disappointing. Similar to the `Compositor`, it's a bunch of blips on the timeline with no description. I was hoping it would give me some detail on what operations it was passing off the GPU, but nah. 😞

## The Overview
Finally, we have the donut chart at the bottom labeled "Summary".

<figure>
![][devtools performance summary screenshot]
</figure>

Looks like this is a breakdown of how long each of the performance heuristics that we're tracking took *in total*. Let's break down the legend here:

1. **Scripting** - It seems safe to assume that this is tracking the page's execution of JavaScript.
1. **Rendering** - I'm guessing this is a combination of both DOM rendering *and* CSS rendering.
1. **Painting** - I'd wager that this is related to CSS repaints, but honestly I'm not sure what the difference between rendering and painting is. We'll have to look this up next.
1. **System** - Probably OS-level things like garbage collection.
1. **Idle** - Time that the browser isn't doing anything or is waiting for something else to finish.

## Conclusion

So, I think all of the pieces of the timeline could be really valuable, but you still have to do a lot of work by hand. If you're working on some clunky CSS animations, the timelines could be super helpful to identify *when* your animation is getting wonky, though it doesn't seem to have any insight into *why* it would be happening. The overview seems really valuable for getting a quick look at the resources your app is using within a certain window, but I'm not sure that I'm going to be using it anytime soon.

One other resource that may be useful when you're digging into CS performance is the [CSS Triggers][csstriggers.com] website. It details which types of CSS rendering operations (`Layout`, `Paint`, `Composite`) will be triggered when changing each CSS property. You could use this — in conjunction with the `Performance` tab and looking at the styles on your elements — to try and narrow down what exactly is causing your animations to be clunky.

[about]: /about
[Ana Tudor Twitter]: https://twitter.com/anatudor "Ana Tudor on Twitter"
[csstriggers.com]: https://csstriggers.com/ "CSS Triggers"
[devtools performance screenshot]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-1.png?alt=media "Screenshot of the Chrome DevTools' Performance tab on https://trezy.com/about"
[devtools performance timeline screenshot]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-3.png?alt=media&token=3525e3ec-a631-4a0f-b263-69470a7d859f "Close up of the Chrome DevTools' Performance Timeline"
[devtools performance timeline gif]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-4.gif?alt=media
[devtools performance summary screenshot]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2F6187f874-96cf-4d2f-b18f-f5525fc157b0%2Fcss-debugging-2.png?alt=media "Close up of the Chrome DevTools' Performance Summary"
[rasterize definition]: https://www.thefreedictionary.com/rasterize "Rasterize definition in The Free Dictionary"

Performance Testing CSS with the Chrome DevTools

In this series, we're going to use [Firebase][firebase], [React][react], and [Next.js][nextjs] to build a photo-sharing web app. We'll start from nothing and build a complete user management system with logins, profiles, permissions, and file uploads!

When starting a new project, I don't always follow the same process, but I *always* start with [*Data Modeling*][data-modeling]. When building apps, all you're doing is creating new ways to display and manipulate your data. That means that no matter what, your data will always be the most crucial part of your app!

Let's dive in!

---

## What are we *really* building?

If our data is the most crucial part of our app, then *what is our data?* The first step of data modeling is to figure out what data needs to be modeled. To do that, let's think at a high level about what the app should be able to do.

* *Logging In* - Users need to be able to login to upload their photos
* *File Uploads* - It's not much of a photo-sharing app if nobody can upload photos to share
* *User Profiles* - I want to know more about the person that uploaded that cute cat picture
* *Moderation* - One of the dangers of a photo-sharing site is that people start uploading dangerous or illegal content, so I want to have a team of moderators that can manage that content

There are *plenty* of other features we could add to this site, but I want to start small, and this is a great start! Now that we know what we want to be possible, let's think about what we'll data we'll need to support those features.

* *Logins* - We'll use Firebase Auth to allow users to login
* *User Profiles* - We'll Firebase Firestore to store data about our users
* *Permissions & Roles* - We'll store roles in Firestore that a user can have, permitting them to do different things
* *File Uploads* - Firebase Storage is a great solution for file uploads, and keeping things in the Firebase family makes everything a lot simpler

## The shape of ~~water~~ data

Before we start writing any code or setting up the database, we need to know how we want our data to look. We have a high-level overview of what our data looks like, but now we need to get into details. We need to think about what bits of info are going to be relevant to our system and how we can represent them in the database. Since almost everything is going to based around the `User`, let's think about that first.

### The `User` model

Firebase Auth dramatically simplifies the process of building a login system. With Firebase Auth, you can allow users to log in with either their email and a password or with their social media accounts. However, we're *only* going to support social media login to reduce the scope of this project.

A `User` is going to comprise two chunks of data. First, there's the data that we get from Firebase Auth. When a user logs in via Firebase Auth, Firebase assigns them a unique user ID. There's some other useful data we can retrieve depending on what platform they sign in with, but for now, we'll just assume that the user has decided not to share any information with us from their social profile.

The second chunk of data we'll be retrieving is the user's `Profile`, which will be coming from Firestore. This will include some critical pieces of information, including:

- `username` - This will be what other users see when they look at the user's posts
- `email` - So we can stay in touch with the user
- `createdAt` - To keep track of when users were created
- `roleIDs` - An array of roles that the user has been granted so we can determine whether or not they have permission to perform specific actions

With all of this information, we can start modeling our data! Thus far, it looks something like this:
<figure>
  <DITAA>
{String.raw`
+-------------+    +-----------+
| {s}         |    | {s}       |
| Firebase    |    | Firebase  |
| Firestore   |    | Auth      |
+------+------+    +-----+-----+
       :                 :
       +                 |
       |                 |
       V                 V
+------+------+      +---+---+
| Profile     |      | User  |
+-------------+      +-------+
| id          |  /-->+ id    |
| username    |  |   +-------+
| email       |  |
| roleIDs     |  |
| userID      +--/
| createdAt   |
+-------------+
`}
  </DITAA>
  <figcaption>A diagram of our data model with the `User` coming from Firebase Auth and the `Profile` coming from Firestore</figcaption>
</figure>

#### A note on naming
Naming things is hard, and database field names are no exception. I try to follow the following rules when naming fields:

##### Boolean fields should start with `is`

A field to describe whether or not a user has been verified would be named `isVerified`. This is much more clear than a field named `verified`, which may be a `Boolean` field, or it may be a string that represents *how* the user was verified, like `by-email` or `by-street-address`.

##### Lists should be plural

A field with a list of sports a user is interested in should be named `sports` rather than `sport`.

##### Reference fields should end with `ID`

Reference fields (known as "foreign key" fields in SQL databases) always contain IDs that reference another item in the database. In our model about, our `Profile` has a `userID` field that will be populated by the `id` field of the `User` model. Naming the field `user` is confusing because it's not clear whether it will contain an ID or an object representing some other user data.

### The `Photo` model

Since we're talking about a photo-sharing site, our users should be able to upload some photos! Like `User`s, `Photo`s will also comprise two chunks of data. The first chunk will be from Firestore. This will be our record of all data about the `Photo`, including:

* `fileID` - When a file is uploaded, we'll generate an ID for it. We'll then use that ID as the filename for storing the file.
* `fileType` - `Photo`s have various file types — `gif`, `jpg`, `png`, etc. — and each of them can have slight variations on the way they're displayed or the way their metadata is stored. Storing that information will help us out later.
* `title` - When a user uploads a file, we'll allow them to add a title.
* `description` - When a user uploads a file, we'll let them add a description.
* `originalFilename` - To make `Photo`s easier for users to find, we'll store the filenames that they had when they were uploaded.
* `ownerID` - This will be the ID of the user that uploaded the file.

The next bit of information will come from Firebase Storage. This is where we'll store the actual file that the user has uploaded. With our new `Photo` data modeled out, our data model looks a bit more like this:

<figure>
  <DITAA>
{String.raw`
+------------+                          +-------------+    +-----------+
| {s}        |                          | {s}         |    | {s}       |
| Firebase   |                          | Firebase    |    | Firebase  |
| Storage    |                          | Firestore   |    | Auth      |
+----+-------+                          +------+------+    +-----+-----+
     :                                         :                 :
     |                      /------------------+                 |
     |                      |                  |                 |
     V                      V                  V                 V
+----+------+     +---------+---------+   +------+------+    +---+---+
| Photo     |     | Photo             |   | Profile     |    | User  |
+-----------+     +-------------------+   +-------------+    +-------+
| id    {d} |<--\ | id                |   | id          | /->+ id    |
| fileType  |<-\\-+ fileID            |   | username    | |  +-------+
+-----------+  \--+ fileType          |   | email       | |
                  | title             |   | roleIDs     | |
                  | description       |   | userID      +-+
                  | originalFilename  |   | createdAt   | |
                  | ownerID           +-\ +-------------+ |
                  +-------------------+ \-----------------/
`}
	</DITAA>
  <figcaption>A diagram of our data model with the `User` coming from Firebase Auth, the `Profile` and `Photo` models coming from Firestore, and the `Photo` file coming from Firebase Storage</figcaption>
</figure>

### The `Role` model

`Role`s are much simpler than most of our other models. There are only two pieces of information that a `Role` will care about:

* `title` - Each role should have a recognizable name, like `Administrator` or `Moderator`.
* `permissions` - These permissions will be fleshed out as we build our app, but each permission will be a string that represents some action. For example, `photo:delete` would indicate that any user with this role can delete a photo.

With `Role`s added, we've come to our final data model.

<figure>
  <DITAA>
{String.raw`
+------------+                            +-------------+                       +-----------+
| {s}        |                            | {s}         |                       | {s}       |
| Firebase   |                            | Firebase    |                       | Firebase  |
| Storage    |                            | Firestore   |                       | Auth      |
+----+-------+                            +------+------+                       +-----+-----+
     :                                           :                                    :
     |                      /--------------------+-------------------\                |
     |                      |                    |                   |                |
     V                      V                    V                   V                V
+----+------+     +---------+---------+   +------+------+    +-------+-------+    +---+---+
| Photo     |     | Photo             |   | Profile     |    | Role          |    | User  |
+-----------+     +-------------------+   +-------------+    +---------------+    +-------+
| id    {d} |<--\ | id                |   | id          | /->| id            | /->+ id    |
| fileType  |<-\\-+ fileID            |   | username    | |  | title         | |  +-------+
+-----------+  \--+ fileType          |   | email       | |  | permissions   | |
                  | title             |   | roleIDs     +-/  +---------------+ |
                  | description       |   | userID      +----------------------+
                  | originalFilename  |   | createdAt   |                      |
                  | ownerID           +-\ +-------------+                      |
                  +-------------------+ \--------------------------------------/
`}
  </DITAA>
  <figcaption>A diagram of our data model with the `User` coming from Firebase Auth, the `Profile` and `Photo` models coming from Firestore, and the `Photo` file coming from Firebase Storage</figcaption>
</figure>

## Data modeling

Modeling your data should be the first step in building any application. Knowing what data you need to collect, to display, and how it's all related can prevent you from having to make massive structural changes halfway through the development of your application.

In the next article, I'll walk through setting up the application with React and Next.js!

[data-modeling]: https://en.wikipedia.org/wiki/Data_modeling "Wikipedia: Data Modeling"
[firebase]: https://firebase.google.com/ "Firebase"
[nextjs]: https://nextjs.com/ "Next.js"
[react]: https://reactjs.org/ "React.js"

Part I: Data Modeling

Building Web Apps with Firebase

Web workers are magical. They allow for multi-threading in JavaScript, a language that has been single-threaded *since the beginning*. Their practical applications range from heavy number crunching to managing the retrieval and dissemination of asynchronous data, to loading images (as I'll discuss in this article).

I'm actually preparing for an upcoming talk about web workers, and according to a good friend of mine...

> Of course Trezy's talk is about web workers. If he wasn't already married to Meg, the man would marry a web worker.
> — @xlexious

I mean, I suppose I like them a bit. WHAT OF IT‽

## Why would we want to load images with web workers?

Moving image loading off of the UI thread and into a worker is a really great opportunity for image-heavy sites and one of my favorite web worker implementations. It prevents image downloads from blocking rendering and it can speed up your site significantly.

*Fun fact:* `<img>` tags actually block your application load. If you have 100 images on your page, the browser will download all 100 of them before it renders your page.

Let's talk a little bit about implementing web workers in a couple of different environments.

### The standard, vanilla implementation

To start a web worker in your average JavaScript app, you need to have it in its own file. Let's assume that we're working on my website, [https://trezy.com][trezy.com]. We'll name our worker file `image-loader.worker.js` and it'll be available at `https://trezy.com/workers/image-loader.worker.js`.

We'll start with a very simple web worker that will log out whatever data it receives:

```js
/*
 * image-loader.worker.js
 */

// The `message` event is fired in a web worker any time `worker.postMessage(<data>)` is called.
// `event.data` represents the data being passed into a worker via `worker.postMessage(<data>)`.
self.addEventListener('message', event => {
  console.log('Worker received:', event.data)
})
```

To start using it in our main JavaScript file, we'll do something like this:

```js
/*
 * main.js
 */

const ImageLoaderWorker = new Worker('/workers/image-loader.worker.js')

ImageLoaderWorker.postMessage('Hello world!')
```

If we load all of this up, we should see `Hello world!` in the console.
🎉 Woot! 🥳

## Let's Get Into It

### Step 1: Update your markup

With your worker implementation all figured out, we can now start implementing our image loader. I'll start with the HTML that we're going to plan on working from:

```html
<body>
  <img data-src="/images/image1.png">
  <img data-src="/images/image2.png">
  <img data-src="/images/image3.png">
  <img data-src="/images/image4.png">
  <img data-src="/images/image5.png">
</body>
```

> Uuuuuuuh, hang on. That's not what `<img>` tags look like!
> — You, just now.

Very astute observation, you! Normally you would use the `src` property of an `<img>` element to tell it where to download the image file from, but here we're using `data-src`. This is because when the browser encounters an `<img>` element with an `src` attribute, it will immediately start downloading the image. Since we want that job to be offloaded to our web worker, we're using `data-src` to prevent the browser from handling the download on the UI thread.

### Step 2: Pass the image URLs to our web worker

In our `main.js` file, we'll need to retrieve all of the relevant `<img>` elements so we can pass their URLs to our web worker:

```js
/*
 * main.js
 */

// Load up the web worker
const ImageLoaderWorker = new Worker('/workers/image-loader.worker.js')

// Get all of the `<img>` elements that have a `data-src` property
const imgElements = document.querySelectorAll('img[data-src]')

// Loop over the image elements and pass their URLs to the web worker
imgElements.forEach(imageElement => {
  const imageURL = imageElement.getAttribute('data-src')
  ImageLoaderWorker.postMessage(imageURL)
})
```

### Step 3: Download the images

Excellent! Now that our web worker has received a bunch of image URLs, let's figure out how to process them. This gets a bit complex in web workers for a couple of reasons:

1. **You don't have access to the DOM API.** A lot of non-web worker image downloader implementations create a new image element and set the `src` attribute on it, initiating the download, then replace the original `<img>` with the new one. This won't work for us because there's no way to create DOM elements inside of a web worker.

1. **Images don't have a native JavasScript format.** Images are made up of binary data, so we need to convert that data into something that we can use in JavaScript.

1. ~~**You can only communicate with the UI thread using strings.**~~ I've been corrected. This was the case in the days of yore, but no longer! 😁

So how can we get the image downloaded, converted from binary format to something JavaScript can use, and then passed back to the UI thread? This is where `fetch` and the `FileReader` API come in.

#### `fetch` is for more than just JSON

You're probably used to seeing `fetch` used to grab data from some API, then calling `response.json()` to get the JSON body of the response as an object. However, `.json()` isn't the only option here. There's also `.text()`, `.formData()`, `.arrayBuffer()`, and the one that matters to us for this exercise, `.blob()`.

A [`Blob`][blob] can be used to represent virtually anything, including data that doesn't have a native JavaScript format like images! They're perfect for what we're trying to do here. With that in mind, let's update our web worker to receive the image URLs and download them as `Blob`s:

```js
/*
 * image-loader.worker.js
 */

// I'm making the event handler `async` to make my life easier. If
// you're not compiling your code, you may want to use the Promise-based
// API of `fetch`
self.addEventListener('message', async event => {
  // Grab the imageURL from the event - we'll use this both to download
  // the image and to identify which image elements to update back in the
  // UI thread
  const imageURL = event.data

  // First, we'll fetch the image file
  const response = await fetch(imageURL)

  // Once the file has been fetched, we'll convert it to a `Blob`
  const fileBlob = await response.blob()
})
```

Alright, we're making progress! We've updated our images so they don't download automatically, we've grabbed their URLs and passed them to the worker, and we've downloaded the images to the browser!

### Step 4: Return the image data to the UI thread

Now that we've got the image as a blob, we need to send it back to the UI thread to be rendered. If we send the string back alone then the UI thread won't know where to render it. Instead, we'll send back an object that tells the UI thread what to render *and* where:

```js
/*
 * image-loader.worker.js
 */

self.addEventListener('message', async event => {
  const imageURL = event.data

  const response = await fetch(imageURL)
  const blob = await response.blob()

  // Send the image data to the UI thread!
  self.postMessage({
    imageURL: imageURL,
    blob: blob,
  })
})
```

Our worker file is done! The final step is to handle what we've received in the UI thread.

### Step 5: Render that image!

We're **so** close to being finished! The last thing we need to do is update our main.js file to receive and handle the image data that's returned from the web worker.

```js
/*
 * main.js
 */

const ImageLoaderWorker = new Worker('/workers/image-loader.worker.js')
const imgElements = document.querySelectorAll('img[data-src]')

// Once again, it's possible that messages could be returned before the
// listener is attached, so we need to attach the listener before we pass
// image URLs to the web worker
ImageLoaderWorker.addEventListener('message', event => {
  // Grab the message data from the event
  const imageData = event.data

  // Get the original element for this image
  const imageElement = document.querySelectorAll(`img[data-src='${imageData.imageURL}']`)

  // We can use the `Blob` as an image source! We just need to convert it
  // to an object URL first
  const objectURL = URL.createObjectURL(imageData.blob)
  imageElement.setAttribute('src', objectURL)

  // Let's remove the original `data-src` attribute to make sure we don't
  // accidentally pass this image to the worker again in the future
  imageElement.removeAttribute('data-src')
})

imgElements.forEach(imageElement => {
  const imageURL = imageElement.getAttribute('data-src')
  ImageLoaderWorker.postMessage(imageURL)
})
```

Check out the [Codepen demo][codepen-demo] with everything working together:

<Codepen id={'ZNdbeQ'} height={500} />

## BONUS: Implementing web workers with Webpack

If you're using Webpack to compile all of your code, there's another nifty option to load up your web workers: [`worker-loader`][worker-loader]. This loader allows you to import your web worker into a file and initialize it as if it were a regular class.

I think it feels a little more natural this way, too. Without changing the content of `image-loader.worker.js`, this is what an implementation would look like if you have `worker-loader` set up in your Webpack config:

```js
/*
 * main.js
 */

import ImageLoaderWorker from './workers/image-loader.worker.js'

const imageLoader = new ImageLoaderWorker

imageLoader.postMessage('Hello world!')
```

Just as in our vanilla implementation, we should see `Hello world!` logged out in the console.

## Conclusion

And we're done! Offloading image downloading to web workers is a great exercise in using several different browser APIs, but more importantly, it's an awesome way to speed up your website rendering.

Make sure to drop off your questions and suggestions in the comments below. Tell me your favorite web worker uses, and most importantly, let me know if I missed something awesome in my examples.

[blob]: https://developer.mozilla.org/en-US/docs/Web/API/Blob
[codepen-demo]: https://s.trezy.sh/image-worker-main
[trezy.com]: https://trezy.com
[worker-loader]: https://github.com/webpack-contrib/worker-loader

Loading Images With Web Workers

Loading Images with Web Workers

Have you ever spent far too long writing a clever little script in the browser’s devtools to get some information from a page? Maybe you’re trying to generate a list of recurring characters from the Marvel Cinematic Universe (MCU) with their names and secret identities from a Wikipedia page...

![That wasn’t too bad...][clipboard-script-1]

Or maybe you’re trying to get a JSON representation of all of the MCU movies sorted by total profit...

![Okay, that one took a little longer...][clipboard-script-2]

Or maybe you’re a **true masochist**, and you want to extract the Game of Thrones (GoT) character and actor names from the body of the GoT wiki page.

![SERIOUSLY, WHY WOULDN’T YOU PUT THIS DATA IN A TABLE‽][clipboard-script-3]

---

## Anyway.

The norm here is to log the data into the console as JSON, then manually select all of the text with your cursor. Not only is this a nightmarish task with large datasets, it also has the potential to have incomplete data. Long strings (especially data URIs) get collapsed with an ellipse (...) by the dev tools. If you want to copy even small data URIs, this approach will leave you — and I’m putting this delicately — *completely boned.*

## Okay, how do we do it better?

With the `copy()` function! It just so happens the the devtools for Chrome, Firefox, and Safari (couldn’t test with Edge) all provide the `copy()` function for jamming anything you need into the clipboard!

✨🧙🏻‍♂️ IT’S MAGIC! 🧙🏻‍♂️✨

If you want to jam an object full of data into your clipboard, it’s as simple as stringifying the data and using `copy()`:

```js
const bigDataSet = [ ... ]
const bigDataSetAsJSON = JSON.stringify(bigDataSet)

copy(bigDataSet)
```

Now if you paste anywhere, you’ll find that your clipboard is chock full of JSON beautifulness.

*Protip:* If you want your data to be styled (with spaces, line breaks, etc) the `JSON.stringify()` method has you covered. For example, if you want the output to use 2 spaces as indentation:

```js
JSON.stringify(bigDataSet, null, 2)
```

For more information on what all you can pass into `JSON.stringify()`, check out the [docs on MDN][json-stringify-docs].

---

## Wow, Trezy! You sure are smart and amazing!

Oh, I know. I appreciate you saying as much, though. If you want to fiddle with any of the code in the examples at the beginning of the article, you can find them [here][pastebin-1], [here][pastebin-2], and [here][pastebin-3].





[clipboard-script-1]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2Fe79faa9c-70cf-43db-a8ac-b8b99ece10bc%2Fclipboardscript1.png?alt=media&token=217b874a-2c3e-4f82-b298-e623f90619c1
[clipboard-script-2]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2Fe79faa9c-70cf-43db-a8ac-b8b99ece10bc%2Fclipboardscript2.png?alt=media&token=ae5a40d0-15d9-4adf-9f66-d464b4b49aae
[clipboard-script-3]: https://firebasestorage.googleapis.com/v0/b/trezy-core.appspot.com/o/articles%2Fe79faa9c-70cf-43db-a8ac-b8b99ece10bc%2Fclipboardscript3.png?alt=media&token=59d05274-df14-44d8-812c-09efad707b19
[json-stringify-docs]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify "JSON.stringify() on MDN"
[pastebin-1]: https://hastebin.com/okihububep.js
[pastebin-2]: https://hastebin.com/eyuqosuwik.js
[pastebin-3]: https://hastebin.com/jarivurozu.js

From The Dev Tools To The Clipboard

From the Devtools to the Clipboard

## …or Why the Hamburger Icon is Awesome.

I've read plenty of anti-hamburger icon posts that came out after Mike Stern's rant at WWDC '14. The issue I take with those articles — and Mike's rant, for that matter — is that they aren't addressing the icon. They're addressing the menu.

## Hamburger Icon vs. Hamburger Menu

The hamburger icon - three vertically stacked horizontal bars - is most often the iconography selected for a button that opens an action menu. The terms used to refer to that menu are vast in number and so I'll not attempt to list them all but I can at least give you the most common: drawer, sidebar, or - least commonly - a hamburger menu. The hamburger icon typically does what you would expect based on it's design. The hamburger menu, however, can be virtually anything from a list of pages on a website to a multi-tiered tree of navigation allowing you to traverse your overly complicated email labeling system.

The issue is that the icon is the one that's getting a bad rep as if it did something wrong when that could be no further from the truth. The icon does exactly what you would expect it to - open a visual representation of itself. Typically, however, the menu is the one causing all the ruckus. WTF, mang?

W.
T.
**F.**

## Menu vs. Nav

To explain why the menu is causing so much fuss I feel like I need to clear up a terrible ambiguity.

### Menus

Menus are, in their most basic form, intended to facilitate action. When you right-click on a selection and you see `cut`, `copy`, and `paste`? That's a menu. `Save` and `delete` buttons? Those should be in a menu. HTML5 even added a `<menu>` tag with some super sweet features built into it. Check out this pen for an example of my typical usage of the element.

### Navs

Navs are (I would hope obviously) intended for navigation. If I click a button or link in a `<nav>` element then I should be taken to an entirely new page. It should be like a wondrous adventure to a new, far off land where unicorns roam free and everybody is eating s'mores and pooping rainbows. The most actionable thing you should do when I click on a link is prompt me about unsaved changes.

## Why Does Any Of This Matter?

The main argument that Mike and the rest of the anti-hamburger movement makes is that it's bad UX when the menu pops out and covers up the rest of your perfect, delicately designed interface. That's totally legit. If I have to cover up whatever I'm doing to cut the paragraph I just selected? You better believe I'm gonna find a better text editor.

However, if this is the navigation I'll be using to take myself to Magic Unicornland™ then I already have intentions of leaving the page. Eff that stupid interface of yours, I just want to get where I'm going.

## The Point

I've been hemming and hawing but for why? It's because the hamburger icon? That guy is my bro. I always turn to him when I don't have enough unicorns in my life. Menus? They're my bros, too, they just aren't used correctly as often as they should be.





[canonical]: https://codepen.io/trezy/post/menu-vs-nav-or-why-the-hamburger-icon-is-awesome

HTML Elements: Menu vs. Nav

## Browser caching is one of the best ways to take care of your users while also speeding up your website... so why is it so hard?

**This article was originally published on 19 October, 2014 at [Medium][canonical].**

Browser caching is a magical thing. Every time you visit a website, the files that make up that site are downloaded to your computer by your browser, which then uses those files to render it for you. This takes time and valuable bandwidth, especially on slower connections. The next time you visit that same site, however, the files needed to render it are already downloaded to your computer. Your browser will use the files it already has to render the site, preventing you from having to waste your bandwidth and wait for the files to download.

Now, this is what happens in a wonderful, magical fairy tale land where all web developers do the right thing and make sure the browser caching is set up on their site. Unfortunately, this is rarely the case. In the spirit of making up statistics, I estimate that somewhere between 30–90% of websites don’t just leverage browser caching, they’re actively working against it.
😞

See, there are a couple of ways to implement browser caching. You can use what’s called a `cache-control` header, which tells the browser how long it can hold on to the file. If you look at my own website, you can see that the Google Analytics script I’m downloading from Google has this header set.

![The cache-control header has a max-age of 7200 seconds, or 2 hours.](https://thepracticaldev.s3.amazonaws.com/i/2zx6rh0vi0aepov91lej.png)

Two hours isn’t bad. If I revisit my site sometime within the next two hours, my browser will still use the version of that file that I just downloaded. The cool part is that since it’s being served by Google instead of by my server, that file will be cached for every website that uses it, including mine!

However, if Google updates that file within the next 2 hours, I won’t get those changes.
😞😞

This is also a great example of where a lot of websites use a technique called **cache busting.** Cache busting is where you fool the browser into thinking something like this Google Analytics script is a different file than it previously downloaded, guaranteeing the user **always** gets the latest version of the file. Developers achieve this by adding something like `?timestamp=2017-10-19T13:04:29.423Z` to the end of the filename. It’s just a parameter that uses the current date and time, so the browser always thinks that this file is different and, thus, always downloads a new version. Now, every time I go to that site I’ll have to download a new copy of that file.
😞😞😞

## So... is there a better way?

Remember when I said there are a **couple** of ways to implement browser caching? Let’s talk about that second one, which is called ETags. ETags are something that the server generates and sends along when a browser tries to retrieve a file for the first time. Here’s an example of a fresh request for one of the files served from my website.

![Notice there is no expires header. The cache-control header has a max-age of 0, which somewhat unintuitively means feel free to keep this file forever.](https://thepracticaldev.s3.amazonaws.com/i/nxvcfv7pmijen7yx9mvw.png)

This is my logo, which has an `etag` header set. This header contains a calculated hash of the file that I’m downloading. The server created that hash for me and sent it up with the file. Now let’s take a look at the second time I request that file.

![The ETags match!](https://thepracticaldev.s3.amazonaws.com/i/g3xrc58yax7wnw7c6cs2.png)

Since the browser received an `etag` header when it first downloaded this file, it made sure to send that ETag back to the server in the `if-none-match` header. The server will compare that ETag against what it calculates for its version of the file. If they *don’t* match, the server will send a new copy of the file to the browser.

However, if they *do* match it won’t send back a file at all. Instead it will send back a `304 Not Modified` response, telling the browser nothing has changed. The Trezy.com server has just saved me time and bandwidth. Just how much has it actually saved me, though?

On a fresh visit to [Trezy.com][trezy.com], the website downloads *781KB of files* and takes around *1.34 seconds to finish*. That’s just for my very tiny website. For other websites that you visit regularly, you can imagine that those numbers will be much larger.

On a second, cache-friendly visit to my website, though, it only downloads *46.1KB of files* and takes *1.05 seconds to finish*. That’s a *94% savings* in bandwidth, and *22% savings* in response times. Again, this is just on my very, very tiny website. Imagine what those savings could look like on a larger website like Facebook or Twitter!
🤔

---

## Let’s take a look at some implementation

We’ll look at the very simple implementation of ETags I used for my website, which runs on a [Koa.js][koa] server. Below is the core of what `koa-etag` does. It takes care of making sure that your server’s response have ETags calculated and attached to the responses.

```js
function etag(options) {
  return function etag(ctx, next) {
    return next()
      // `getResponseEntity` checks to see if the response has a body, and
      // stringifies it depending on what kind of body it has (JSON, HTML, 
      // image, etc)
      .then(() => getResponseEntity(ctx))
    
      // `setEtag` calculates the ETag from the response body if it exists,
      // then sets that ETag as a header
      .then(entity => setEtag(ctx, entity, options));
  };
}
```

This isn’t all we need to do, though. The response from the server will still contain the contents of the rest and it will respond with a `200 OK`, telling the browser that it’s basically getting a new file. Here’s the missing piece of the puzzle.

```js
function conditional() {
  return function conditional(ctx, next) {
    return next().then(() => {
      if (ctx.fresh) {
        ctx.status = 304;
        ctx.body = null;
      }
    });
  }
}
```

Alright, what’s going on here? `ctx.fresh` is a Koa.js-specific property, but it’s basically checking if the old and new ETags match. This middleware, `koa-conditonal-get`, uses this property to determine how to proceed. If they do match, the information the browser has is `fresh` and we don’t need to send anything new along, so we’ll set the status to that nifty little `304 Not Modified` and delete the response body, eliminating the need to send who knows how much gobbledy-gook across the wire. If the ETags don’t meet up to Will Smith’s standards, we’ll need to send along the new content.

---

## Make it real!

If you work on one of the 30–90% of websites that don’t implement browser caching, there’s no better time than now to fix it! This is a stupid simple implementation of ETags that may not cut the mustard for a lot of systems, but it’s a great start. It’s not just for websites, either! APIs can leverage ETags to make developer’s lives easier, too. If you have arguments about scalability, I’ll just go ahead and point out to you, Mr. or Mrs. Smarty Pants, that Github implements ETags in their API, so there.
😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁





[canonical]: https://medium.com/trezy-com/why-is-browser-caching-so-hard-7bd711603c91
[koa]: https://koajs.com
[trezy.com]: https://trezy.com

Why Is Browser Caching So Hard?

[Handlebars][handlebars] is **awesome**. I can separate my template logic from my application logic? Yes, please. When I try to use Handlebars in my local editor, though, it vomits all over those ugly `<script>` tags. Fortunately there’s an awesome, future-friendly, spec-compliant solution — the `<template>` tag.

`<template>` tags are super cool in a lot of ways. From the [HTML5 Rocks article][article-html5-rocks-template], here are the pillars of `<template>` tags:

1. Its content is effectively inert until activated. Essentially, your markup is hidden DOM and does not render.
1. Any content within a template won’t have side effects. Script doesn’t run, images don’t load, audio doesn’t play… until the template is used.
1. Content is considered not to be in the document. Using `document.getElementById()` or `querySelector()` in the main page won’t return child nodes of a template.
1. Templates can be placed anywhere inside of `<head>`, `<body>`, or `<frameset>` and can contain any type of content which is allowed in those elements. Note that “anywhere” means that `<template>` can safely be used in places that the HTML parser disallows…all but content model children. It can also be placed as a child of `<table>` or `<select>`:

```html
<table>
  <tr>
    <template id=”cells-to-repeat”>
       <td></td>
    </template>
  </tr>
</table>
```

## Why isn’t this being used elsewhere?

That’s a great question. I can only speculate but I’d reckon it has something to do with the recency / lack of support. `<template>` is supported in most browsers, though [Can I Use][caniuse-template] tells us that we’re lacking support in Internet Explorer (big surprise), Safari 7, and Blackberry. Luckily, we can add [this shim][shim-template] if we need to make it work everywhere. You can read more about the `<template>` tag and how to use it in [this tutorial on HTML5 Rocks][article-html5-rocks-template].

Here’s the coolest thing, though — current Handlebars users will actually have to write **less** code. Check it:

```html

<script type=”text/x-handlebars-template” id=”article-template”>
  <article>
    <h1>{{title}}</h1>
    {{content}}
  </article>
</script>
```

…just swap the `<script>` tags for `<template>` tags:

```html

<template id=”articleTemplate”>
  <article>
    <h1>{{title}}</h1>
    {{content}}
  </article>
</template>
```

And blammo, you’re using awesome new HTML5 tech. Your editor and I will love you for it. 😉

## The catch

As [joao][profile-joao] points out in the [Codepen comments](https://codepen.io/trezy/post/on-handlebars-and-template-tags#post-comments), not everything is hunky dory. Take a look at this code:

```html
<template id=”tableTemplate”>
  <table>
    {{#each}}
      <tr>
        <td>{{content}}</td>
      </tr>
    {{/each}}
  </table>
</template>
```

Looks legit, right? Unfortunately it breaks in the browser. The parser still requires the code inside the `<template>` tag to be valid HTML which means you can’t have any content in a table unless it’s also inside a cell (`<td>`). You can, however, create your table cells / rows in a template tag and use them in a table:

```html
<table></table>

<template id=”tableTemplate”>
  {{#each}}
    <tr>
      <td>{{content}}</td>
    </tr>
  {{/each}}
</template>
```

It’s not ideal and I would definitely prefer a better DOM API for it. Still, this stuff is super cool and I’ll be using it all over the place. If you take advantage of it, let me know! I’ll leave you with my implementation of `<template>` tags and Handlebars:

<Codepen id={'yxqCJ'} height={500} />

[article-html5-rocks-template]: http://www.html5rocks.com/en/tutorials/webcomponents/template/
[caniuse-template]: http://caniuse.com/#search=template
[canonical]: https://codepen.io/trezy/post/on-handlebars-and-template-tags
[handlebars]: http://handlebarsjs.com/
[profile-joao]: http://codepen.io/joao/
[shim-template]: http://jsfiddle.net/brianblakely/h3EmY/

On Handlebars and Template Tags

This morning I read [7 Reasons Why You Will Never Do Anything Amazing With Your Life](https://medium.com/raymmars-reads/7-reasons-why-you-will-never-do-anything-amazing-with-your-life-2a1841f1335d) by Raymmar Tirado. It’s a painfully accurate article about the way that today’s youth consume the world through the lens of Buzzfeed and UpWorthy, usually driven by their friends comments of, *"OMG, SO true!"*

I love the article. I love its message. I love the way that Tirado summarizes the issues with the products of our education system and emphasizes the benefits of living the way that he and I do: consuming quality, thought-provoking, intellectual content; parsing news to get to the truth of a matter; defining your own measure of success; bettering yourself everyday by taking to heart the best advice you find; pushing yourself towards your personal renaissance. I *love* it.

## So what’s the issue?

The extremely adversarial tone of the article trivializes the existence of college students, likely turning the target audience away from the message. Tirado even acknowledges that fact in his anger:

> Because you are probably not reading this article even though you know you should.

Had I not the stubbornness of a man trying to move a hippopotamus with his bare hands I likely would have stopped reading when Tirado started calling me names and trivializing the past that isn’t even mine. I do, however, possess the aforementioned gall so I soldiered through. The article continues to berate those who aren’t making an effort to improve themselves everyday as well as those who spend any amount of time consuming mindless, pointless information.

Again, I love the article. I love that Tirado has justified my life choices. I love that his article basically says, *"Trezy, you’re doing it right."* However, this is the kind of masturbation that people are indulging in everytime they read, *"10 Things You Didn’t Know About Disney Movies."* They’re getting an opportunity to justify that they’re intelligent in some way by saying, *"I totally knew about all of those except for #9."* Indulging that justification for a different audience — in this case, self-made people like Tirado and myself — is no different than what the producers of trash content are doing. Tirado even admits that he’s doing this deliberately:

> Because the people that are reading this already know these things.

## Alright asshole, what’s your point?

I’m not trying to belittle Tirado’s article in any way. I’ll say it [at least] one more time — I *love* the article. It contains a message that I wish every college graduate would hear. I wish it was a freaking commencement speech.

In its current tone, however, it will never reach that audience. It will be read over and over and over by people like Tirado and myself and praised because, *"OMG, SO true!"* The audience that it needs to reach will rarely finish it and, if they do, they’re unlikely to affect themselves by it.

## Oh. Well… shit.

Yeah, I know. This isn’t something that can’t be dealt with, though. While reading the article I noticed it lacking any call to action. Nowhere was it written, *"This is a way to become better informed,"* nor was it entitled, *"7 Ways To Do Something Amazing With Your Life."* Without a path to enlightenment the people that would benefit from it are left with nothing more than a bad taste in their mouths. They’ll likely go off to play some Xbox while they *"think about it."*

Without a call to action, nobody will benefit from a piece as inspirational as Tirado’s. Those that already follow the path will take pleasure in their indulgence and those that don’t will be left wondering how they can be better.

## So what’s your call to action?

Write with a call to action in mind, duh. Well... I guess there’s more to it than that.

It needs to be apparent and focused. I’d be wrong to claim that Tirado’s article doesn’t have a call to action at all because it does and is easily summarized — be better. It’s not focused, however. An uninformed reader would likely take away from the article that Tirado is just an angry, crotchety old grinch that regularly yells at the youngsters to, *"GET OFF MY LAWN."*

## Disseminating the points

Breaking down Tirado’s paths to enlightenment isn’t too hard, though:

### 1. Because You Have Not Failed Enough.

Walk into a high school classroom or college lecture hall. Ask a simple question: *"How do you think our president is doing and why?"* You’ll likely see exactly nobody jump up to answer. We are so afraid of failure that we usually don’t even try. If you don’t try then you’ll never fail and you’ll *never* succeed. You’re likely to fail a lot and that’s not a bad thing. Learn from your failures and the failures of others and eventually success won’t be so far away.

### 2. Because You Care What Others Think About You.

I usually try to do the right thing regardless of what others think. If I didn’t, I’d never do anything at all. I hold a great many unpopular opinions and I have lost friends to them before but I will continue to hold them because I believe in them. Caring about what others think is putting yourself on the fast track to being useless to the world because without strong opinions, you will **never do anything amazing**. Never compromise the things you care about, *especially* for somebody else.

### 3. Because You Think You Are Smarter Than You Are.

Don’t expect that you know anything just because you have a degree. There are billions of people in the world. Most of them know more than you. Learn from them, then learn some more. When you think you’re done, keep learning.

### 4. Because You Don’t Read.

Good places to find quality content depend on what kind of content you’re looking for but no matter the topic, they do exist. King amongst the general reading is *Medium*. *Google News* is another great way to keep up with the world. Everybody should have information sources that they read regularly. If you never read then you’ll rarely learn.

### 5. Because You Lack Curiosity.

Devouring what you read and hear as fact will always leave you wanting. Until you know a truth for yourself, nothing should be considered true. Always dive deeper, get a second opinion, find another source, and get to the truth of it. Not everything has to have a conspiracy theory but then again… not all conspiracy theories are wrong. Curiosity may have killed the cat but it sure as hell hasn’t killed Edward Snowden yet.

### 6. Because You Don’t Ask Enough Questions.

Let’s go back to the high school classroom. When the professor offers to answer questions you’re likely to hear… silence. Our culture is still raising us to become a part of the industrial complex where you don’t stand up, you don’t ask questions, and you *always* do as you’re told. The world of today requires so much more than that. If you’re not asking questions and you’re always doing what you’re told then you remain just another cog in the machine. Unless you start to ask questions you’ll never find yourself coming closer to the truth.

### 7. Because You Can’t Handle The Truth.

Many people find comfort in hiding behind a wall of ignorance and I get that. Those people, though, are the ones contributing to every problem we face as a society: ignorance about science prevents scientific advancement; ignorance about technology prevents technological advancement; ignorance about the world prevents the elimination of racism and anti-global views. You don’t have to be an expert on any of these things and, in fact, shouldn’t claim to be. Keep an open mind. The world becomes so much more interesting when you do.

## Write for the right audience

I hope it’s clear by now that I *love* Tirado’s article. I just don’t love that he wrote it for me. If you’re not trying to make a difference in this world then you’re doing it wrong. *That’s the point.* The list I made isn’t as clear of a path as I’d like it to be… but I think it’s a good start.

How to do Amazing Things

The CSS transition property allows for a lot of really cool effects in your design, but it's caused me to bang my head against the desk more than a couple of times. 

*Disclaimer:* At the time of this writing transitions still require browser prefixes to work for Firefox (`-moz-`), Opera (`-o-`), and Webkit (`-webkit-`). I have omitted them from the code examples here for readability, but they will be required if you intend to use these techniques.

## The long and the short of it

The transition can be broken into several different properties or used in its shorthand form. You can even mix and match depending on what you prefer. The different transition properties that exist are:

* [`transition`](https://developer.mozilla.org/en-US/docs/CSS/transition)
* [`transition-property`](https://developer.mozilla.org/en-US/docs/CSS/transition-property)
* [`transition-duration`](https://developer.mozilla.org/en-US/docs/CSS/transition-duration)
* [`transition-timing-function`](https://developer.mozilla.org/en-US/docs/CSS/transition-timing-function)
* [`transition-delay`](https://developer.mozilla.org/en-US/docs/CSS/transition-delay)

Each of the longhand properties also have their own shorthand form:

```css
div {
 background-color: #2f2;
 color: #090;
 transition-property: background-color, color;
 transition-duration: 1s, .5s;
 transition-timing-function: ease, steps(4,start);
 transition-delay: 0s, .5s;
}

div:hover {
 background-color: #fff;
 color: #000;
}
```

Keep in mind that you don't have to have multiple values for each property. If we were to change `transition-duration: 1s, .5s;` to `transition-duration: 1s;` then both transitions would use the same duration value. Personally, I prefer the shorthand property because it looks cleaner and it takes less code:

```css
transition: 
  <transition-property>
  <transition-duration>
  <transition-timing-function>
  <transition-delay>;
```

The `timing-function` and `delay` are both optional in the shorthand version. Here's an example:

```css
div {
 background-color: #2f2;
 color: #090;
 transition-property:
   background-color 1s,
   color .5s;
}

div:hover {
 background-color: #fff;
 color: #000;
}
```

Both of these blocks of code will create the same functionality so it's entirely a matter of preference. A final thing of note for `transition-property` is that if you don't change anything between states other than the properties you want animated, you can use `all` in place of a list of properties.

## Transitions swing both ways

It wasn't until I read [this article](http://www.impressivewebs.com/mimic-onmouseout-css3-transitions/) from Louis Lazarus that I realized I could use different transitions for different states. If a transition is applied to just one state of an object like in the code examples above it will activate on `:hover` (or whatever state you choose) and reverse when the state changes back. However, if each state has a different transition property, it will be applied to the incoming transition. For example:

```css
div:not(.menu):before {
 background-color: #ddd;
 border-radius: 10px;
 color: #333;
 content: 'Hover me to see the menu';
 padding: 10px;
}

div .menu {
 background: #88b;
 max-height: 0;
 -webkit-transition:
   max-height .5s ease .5s,
   max-width .5s ease 0s;
 max-width: 10px;
 overflow: hidden;
}

div .menu a {
 color: #fff;
 text-decoration: none;
}

div:hover .menu {
 max-height: 999px;
 -webkit-transition:
   max-height .5s ease 0s,
   max-width .5s ease .5s;
 max-width: 999px;
}
```

<Codepen id={'mvaLt'} height={500} />

In this example when you mouse over the `.menu`'s parent div its first transition will come from the `div:hover .menu` rule. First, it will grow vertically, then it will grow horizontally. When you mouse off the parent div (or the menu) the `.menu` will take it's transition from the `div .menu` rule, first shrinking horizontally, then growing vertically. It's a little bit confusing but super cool!

## It's all in the timing

The `timing-function`s will be familiar to flash developers and video editors that customize the easing on their transitions, timing, and other effects, but they're likely a foreign concept to most web designers. These functions are already well-described on [MDN](https://developer.mozilla.org/en-US/docs/CSS/timing-function) and in the [W3C spec](http://dev.w3.org/csswg/css-transitions/#transition-timing-function) so I'll just give a brief description of each them here.

### `ease`

This is the default setting for `timing-function` so unless you're using the longhand `transition-timing-function` with multiple properties, declaring it is unnecessary. It will ease both the in and out points of the animation with a slightly sharper curve on the in than the out. Basically it's faster in the middle than at the beginning or the end, and the beginning accelerates a little faster than the end.

### `ease-in`

This is similar to `ease` but it has a longer in point curve (slower acceleration) and an abrupt stop.

### `ease-out`

The opposite of `ease-in`, this has a longer out point curve (slower… slowing?). Basically it starts abruptly and slows down as it gets closer to the end.

### `ease-in-out`

I thought the existence of this one was odd since we already have the basic `ease` function. However, there is a slight difference. `ease-in-out` actually has an equal in and out curve, whereas `ease` has a slightly sharper in curve. The actual animation will have an equally slow beginning and end.

### `linear`

This function has a straight line from beginning to end. This means it will have an unchanging speed with an abrupt start and stop.

### `step-start` / `step-end`

What the purpose of these two functions is, I have no idea. I am sure that they have their uses somewhere. With `step-start`, it will make the switch for the transition at the beginning of the duration, then does nothing until the end of the duration. The `step-end` function does the opposite, waiting for the end of the duration, then applying the changes suddenly. These are not smooth transitions at all but rather changes with delays built in.

### `steps(number_of_steps, direction)`

Much more useful than the previous step functions, `steps()` allows you to spread your animation across several abrupt changes for the duration of your transition. Here's an example:

```css
a {
 transition: steps(4, start) 1s;
 width: 100px;
}

a:hover {
 width: 200px;
}
```

When hovering over this link it would immediately grow incrementally from 100px to 200px instead of moving through a smooth transition. These are literally immediate transitions, similar to if there were no transition at all. The `direction` (in this case `start`) is the same as the suffixes for `step-start` and `step-end`, determining whether the changes begin at the beginning or end of each step. The default value for `direction` is `end` but the parameter is not optional so `steps(2)` will not work.

### `cubic-bezier(x1, y1, x2, y2)`

This is the mother of all `timing-function`s, giving you ultimate control over the timing of your transitions. All of the other functions except for `steps()` can be defined using `cubic-bezier()`. However, it can be extremely complicated, so I'll leave you to your own devices here. I highly recommend checking out the [MDN](https://developer.mozilla.org/en-US/docs/CSS/timing-function#The_cubic-bezier%28%29_class_of_timing-functions) article about it for a really brilliant explanation.

## Conclusion

Talk about dissemination of information, these dogs are cooked! And by dogs I mean fingers. Not that I have huge fingers or anything, just… are you calling me fat? Anywho, leave a comment if you have any questions or if you figure out some super awesome combination of transitions.

On Dropdown Menu Transitions

`box-shadow` is arguably one of the coolest things to come out of CSS3. However, I’ve been creating shadows in Adobe Fireworks and Photoshop for years, so I feel like CSS3’s `box-shadow` implementation is just too constrained. In an effort to expand my boxy horizons, I set out on a quest to create some cooler shadows.

<Notice>*Disclaimer:* At the time of this writing filters and transforms still require browser prefixes to work, though filters will only work in Webkit browsers. I have omitted these prefixes from the code examples here for readability but they will be required if you intend to use these techniques.</Notice>

## Rocking out with box-shadow

My first attempt at making my shadows more dynamic still uses `box-shadow` but it extends its use to create a new effect. My main goal was to avoid using any extra elements, so all we need is a div and we’ll leverage pseudo elements to do the rest of the work.

<Codepen id={'Jrhpc'} />

What we’ve done is created two transparent pseudo elements behind our main element. These two pseudo elements then have `box-shadow` applied. This is done so that we can use 2D transforms to angle them, creating a 3D looking `box-shadow` for their parent element.

We also used the `top`, `bottom`, `left`, and `right` properties to keep the shadow from spilling out from the sides of the parent element.

## Box-shadow… without box-shadow?

I was pretty happy with the previous idea, but it didn’t look as awesome as I hoped. My next idea was to create the same effect using gradients.

<Codepen id={'aybiL'} />

This time we’re still using our pseudo elements but instead of giving them `box-shadows`, we’ll give them gradients. We also used a new CSS3 property called `filter`. Make sure to check out all the nifty things it can do [here][demo-box-shadows]. We just use the blur to soften the edges and make it look more like a shadow.

## Oooooh… that’s way prettier.

While I was working on this project I ran across a site with an even cooler style of drop-shadow that pointed inward rather than outward:

[Karma][karma]

All I really had to do was flip my last idea and we were good to go!

<Codepen id={'zEtgJ'} />

## Conclusion

If you use any of these drop shadows, post a link in the comments! Also, if you come up with any alternative ideas or issues that should be noted, let me know.

[canonical]: https://trezy.com
[demo-box-shadows]: https://html5-demos.appspot.com/static/css/filters/index.html
[karma]: http://demo.truethemes.net/Karma-Wordpress/

On Advanced Box Shadows

When I write my sans-serif font-family stack in my CSS file I normally use this:

```css
body {
 font-family: Ubuntu, Helvetica, Arial, sans-serif;
}
```

[Ubuntu][font-ubuntu] is one of my favorite fonts which I import from [Google Fonts][google-fonts] but you can replace it with whatever custom font you want. Since I prefer Helvetica over Arial, it's the next font on the list which I'm hoping they have preinstalled. If not the stack falls back to Arial, then the default `sans-serif` system font.

Now I've been writing my font stack this way for several years (sans the custom font) completely oblivious to the ridiculously obvious fact that half of the stack isn't necessary. The `sans-serif` piece of the stack asks for the system's preferred `sans-serif` font which, by default, is Arial on Windows and Helvetica on Mac. If I'm not concerned about the user having changed their default `sans-serif` font, I can cut 16 characters (not including spaces) out of my font stack:

```css
body {
 font-family: Ubuntu, sans-serif;
}
```

When I realized this a couple days ago, I subjected myself to an hour of staring at terrible websites as punishment for my ignorance. After recuperating from the debacle I decided to take a closer look at my new font stack. The only issue I have with it is that I don't trust my Windows users to not have changed their default system font to [Comic Sans][font-comic-sans] or [Papyrus][font-papyrus]. Fortunately, Windows will fallback to Arial if you declare Helvetica and it's not installed! When it's all said and done our font stack should like this:

```css
body {
 font-family: Ubuntu, Helvetica, sans-serif;
}
```

It's not a performance saver and it's not going to impress anybody - in fact you may look like an idiot if you admit to not having known this already - but it's a nice piece of info to have when writing your font stacks.





[canonical]: https://trezy.com
[google-fonts]: https://fonts.google.com
[font-comic-sans]: https://bancomicsans.com/main/
[font-papyrus]: https://trezy.com/blog/christmas-time-with-papyrus
[font-ubuntu]: https://fonts.google.com/specimen/Ubuntu

On Saving Characters

*Disclaimer:* Alright, don't get too excited. This stuff isn't backwards-compatible *at all*. However, there are fallback solutions and it's pretty darn cool that it's actually being spec'd.

Web designers were begging for variables and calculations in CSS well before LESS and Sass came along However, Sass and LESS output can sometimes bloat your CSS and, while it's pretty fun to play with, it's a pain to have to recompile your CSS after every change. Fortunately, the W3C has come in like the proverbial Mary Poppins and to give them a spit shine, making everything all fresh and new again.

## Variables

Mmmmmmmmm, variables. We've used them in almost every language but CSS… Until now. Admittedly, CSS variables are quite a long way off. They're still in a W3C Level 1 module so you won't be able to play with them for a while unless you want to get into the [Webkit nightly builds][webkit-nightly]. Still, it's fun to think about all of the amazing things we're going to be doing with them in a year…

Here's what variables might look like in CSS3. Keep in mind that since it's still Level 1, it's subject to change. To declare a variable, you'll create it inside an element. All of the examples are declaring them in the `:root{}` using the `var` prefix like this:

```css
:root {
 var-mainColor: #0c0;
}
```

You can then call the variables later on in the code by using the `var()` syntax:

```css
p {
 background-color: var(mainColor);
}
```

My main use for this in CSS has been dealing with branding colors. I can set all of the branding colors in the top of the stylesheet and use the variables throughout code, like this:

```css
:root {
 var-primaryColor: #0d56a6;
 var-secondaryColor: #4186d3;
 var-tertiaryColor: #689ad3;
}
header {
 background-color: var(primaryColor);
}
header > nav {
 background-color: var(secondaryColor);
}
article {
 background-color: var(tertiaryColor);
}
button {
 background-image:
   linear-gradient(
     bottom,
     var(primaryColor) 0,
     var(secondaryColor) 50%,
     var(tertiaryColor) 100%
   );
}
```

From this point on if I want to change the color scheme I can just change the colors in my `:root` element and they'll change across the entire website! I do hope, however, that before the spec is released we get the ability to create full property set variables that work like SASS mixins. The ability to do something like this would be stupendous:

```css
var gradient (color1, color2, color3) {
 background-image:
   linear-gradient(
     bottom,
     var(color1) 0,
     var(color2) 50%,
     var(color3) 100%
   );
}
article {
 gradient(#0d56a6, #4186d3, #689ad3);
 border: 1px solid #000;
}
```

[W3C Module][w3c-css-var]

## Calculations

Calculations are in a W3C Level 3 module, meaning they're pretty close to making it into the CSS3 full spec. If all goes well, we'll be able to consider them totally safe to use come next June. However, we can already play with them in the latest version of Chrome, Firefox, Opera, and Safari, as well as IE9/10.

So why are calculations so exciting? How about this horizontal centering:

```css
body {
 margin-left: calc(960px / -2);
 width: 960px;
}
```

[MDN Page][mdn-css-calc] | [W3C Module][mdn-css-calc]

## Units

There are some really snazzy new units coming with CSS3 but the ones I'm most excited about are `rem`, `vw`, `vh`, `vmin`, and `vmax`.

### rem

We're all aware of the `em` which we're encouraged to use for the sake of magnified page viewing. However, I've avoided them for quite sometime because they're a major pain in the ass to try to calculate. I don't like having to figure out what my em value is based on it's parent's calculated value which is based on it's parent's calculated value which is based on it's parent's calculated value which is… It just sucks. The `rem`, however, is here to save the day! The `rem` is similar to the `em` except that it's always relative to the `em` value of the root of the page. Take this code:

```css
:root {
 font-size: 20px;
}
.box1 {
 font-size: 2em;
}
.box1 > .box2 {
 font-size: 2em;
}
.box3 {
 font-size: 3rem;
}
.box3 > .box4 {
 font-size: 1rem;
}
```

In this case, `.box2` will have a font-size of 80px (2em of 20px = 40px, then 2em of 2em of 20px = 80px) but `.box4` will have a font-size of 20px (.box3 would be 3rem of 20px = 60px, `.box4` if 1rem of 20px = 20px). It's actually even more complicated than that, but this is the general way to figure everything up. `rem`s are much easier to use then `em`s, hands down.

### vw and vh

Even more awesome are the units that calculate based on the size of the viewport! `vw` and `vh` are percentages of the viewport width and height, respectively. Each `vw`/`vh` is 1% of the viewport size, so think about this:

```css
nav {
 width: 100vw;
}
nav a {
 min-width: 100px;
 width: 20vw;
}
```

With this you can create a navbar with 5 elements that is always the same size as the viewport! The `min-width` also makes sure that the links will never be too small so you can stack them or turn them into a vertical menu for super tiny screens.

### vmin and vmax

These guys are always relative to the larger or smaller size between the `vh` and `vw`. In other words, if the width of the viewport is smaller than the height (maybe its a smartphone in portrait mode) then the `vmin` will be relative to the width and the `vmax` will be relative to the height.

[W3C Module][w3c-css-vmin-vmax]





[less]: https://lesscss.org
[mdn-css-calc]: https://developer.mozilla.org/en-US/docs/CSS/calc
[sass]: https://sass-lang.org
[trezy.com]: https://trezy.com
[w3c-css-calc]: http://dev.w3.org/csswg/css3-values/#calc-notation
[w3c-css-var]: http://dev.w3.org/csswg/css-variables/
[w3c-css-vmin-vmax]: http://www.w3.org/TR/css3-values/
[webkit-nightly]: https://nightly.webkit.org

On Variables, Calculations, and New Units

Pure CSS tooltips have been a thing for a while now, but all of the solutions I've found have had severe limitations. After reading through Louis Lazaris's article — [Pure CSS Tool Tips Revisited][tooltips-article] over at [ImpressiveWebs][impressive-webs] — I decided to take a stab at making some powerful CSS tooltips of my own.

## The Problem

Louis's design broke some of the boundaries but still had some limitations. These were my goals:

### Multiline

Louis makes the argument that tooltips are only supposed to contain a small amount of information, eliminating the need for multiline tooltips. I agree with him to an extent, but I still think there are cases in which you would want a multiline tooltip. In my example, I am creating an error message rather than your average tooltip. I wanted my first line to be only the error type, then all of the following lines would contain the error message.

### IE8 Compatible

This was a big one since the company I'm doing this project for requires it. Fortunately we only have to support IE8, Firefox, and Webkit. Keep in mind, however, that this also means I don't know how this code will react in IE7 and below.

### No Extra HTML

Some other pure CSS tooltip solutions use extra elements, like placeholder spans or divs. I wanted to be able to pull in all of the information I needed without any extra elements. I bend the extra HTML rule a little bit since we do use an element's attributes to populate the tooltip but I think I can still live with myself.

## The Solution

If you check out the pen, you may notice the custom `data-` attributes on the link. The `data-tooltip` attribute is binary, meaning it's either set or it's not, just like `required`. I'll be using jQuery to create and populate the other two attributes in the final project but for now we'll just use some bunk data.

### Pseudo-classes and Uncommon Attributes

Most pseudo-classes describe some state of an element, i.e. `:hover` applies when the element is being hovered, `:focus` applies to form elements that are in focus, `:disabled` applies to elements that are disabled, etc. However, `:before` and `:after` are a little different. They are used to prepend and append, respectively, content to an element. For example you could use `.emailAddress:before` to append a label to the internal node of every element with a class of `emailAddress`.

You have probably seen most of this CSS before, though we're using a couple of pretty uncommon attributes. The `content` attribute only works with the `:before` and `:after` pseudo-classes. It determines what to prepend/append to the element. In this case we're using a pretty cool argument called `attr(x)`. It allows you to use the value from any attribute applied to the element as the content of the prepended/appended element. In our case we used the custom `data-` attributes we set earlier.

The `white-space` is another strange one. It's used to determine how white space (spaces and returns) should be handled inside of an element. We used `white-space:pre-wrap;` so that the spaces inside the `content` attribute would be preserved, specifically the `\A` which is a Unicode carriage return, pretty much the only way to ensure that the line breaks where we want.

### Positioning

This was the most important point to allowing multiline tooltips. Some previous solutions have used percentage positioning, some used pixel positioning, but they all used the `top` and `left` attributes. However these always break if you have more than one line so they are often used with `white-space:nowrap;`.

Instead of positioning negatively based on the top position of the element like Louis did, I set the top position of the tooltip to zero so it would line up with the top of the element, then gave the tooltip a `margin-top`. In my example, I'm placing the tooltip on a link so I set the bottom margin to 1em, ensuring the margin would always be the same height as my text. This may need to be adjusted depending on your line-height.

If you're not positioning the tooltip on a line of text then you can also set your margin to match the height of a static height element, or use some jQuery magic to adjust it.

<Codepen id={'Khnzy'} />

## Wrapping It Up

The rest of this code is pretty standard stuff. One other peculiar thing we're doing here is using the `:before` to create the arrow on the bottom of the tooltip. [Louis's article][tooltips-article] explains that part a bit and there are plenty of other tutorials on creating shapes using divs and borders so I won't cover that.

I've tested this in all of the necessary browsers (IE8+, Firefox, and Google Chrome) and haven't seen any issues yet. If you run into an issue or have a recommendation for making it even better, let me know in the comments! I'll do another tutorial in the future about how to make this guy extensible using jQuery. 😉

[impressive-webs]: https://impressivewebs.com
[tooltips-article]: http://www.impressivewebs.com/pure-css-tool-tips/
[trezy.com]: https://trezy.com

On CSS Tooltips

After reading through A List Apart's article [What I Learned About the Web in 2011][ala-article] I decided I needed to make a second effort at getting into mobile web design. This article chronicles the epic struggle between myself and the perils of designing for a screen that fits in my hand.

Part 1 will discover the philosophy behind responsive design and how to apply these new bits of brain lightning to our current processes. My odyssey will continue in part 2 as I get into the technical side of using techniques like media queries to create a responsive design. Hit the jump to read on.

## What is Responsive Design?

Responsive design is the ideology of designing a single website for multiple screen sizes. Don't be scared traditionalists, it's not that hard. Actually according to most experts in the design field responsive design is making them more talented designers. The ideology is being necessitated by the increasing number of devices that are accessing our websites. It's no longer enough to design for desktops and laptops. We now have to take into consideration all of the tablet and mobile users and provide them with the same experience that we give to our desktop users.

## In the Beginning…

I decided to start my descent into the deep, dark depths of change by reading into the exploits of others that succeeded in defeating this great beast. From these musings I learned a few things that I'd like to share:

### The Mobile Minotaur Comes First

It was stated by every book, blog and video I ran across on the topic of responsive design: design for mobile first. It makes sense if you think about it. The issue with tackling a design for a mobile screen is size. By traditional design methods you have created some sort of grid format, 960px powerhouse but when it comes time to create the mobile version you are trying to squeeze all of that content into a teeny little box. If you design for mobile first you have the advantage of expanding your content rather than smashing it with the proverbial hammer.

### "The Fold" is an Ancient Beast, but a Worthy Foe

If you're unfamiliar with "The Fold," check out Paddy Donnelly's explanation of it [here][the-fold-article]. What makes "The Fold" insignificant in responsive design is that our first designs are going to be built for mobile users. Our content is going to expand well beyond the confines of their screens so we are going to have to become comfortable with the mobile version of the vertical tango.

### Truncating is for Elephants

Mobile users may be lacking in screen real estate but that doesn't mean they should have fewer options than they do from their home computers. If anything they should have access to more features from their mobile devices. They have the ability to get all touchy-feely with your website. They are more interactive than a desktop user because of that physical connection. We need to cater to these users by making them feel like their feeling the website.

Now I think I'll take a coffee break. Blogging is hard. Watch out for Part 2!

[ala-article]: https://medium.com/r/?url=http%3A%2F%2Fwww.alistapart.com%2Farticles%2Fwhat-i-learned-about-the-web-in-2011%2F
[the-fold-article]: https://medium.com/r/?url=http%3A%2F%2Fiampaddy.com%2Flifebelow600%2F
[trezy.com]: https://trezy.com

<trezy-who/>

<trezy-who/>

Latest articles

ATProto Has a Profile Problem. Lexicon Generics Could Help.

Discord Isn't Requiring a Face Scan — Your Legislators Are

It's Christmas Time... With Papyrus