Astro 3.3 Picture Component

Part of the Responsive Images series

The last time I wrote about image optimization and responsive images in Astro, there were some compromises to be made in order to use astro:assets image optimization.

First, it did not resize images or create responsive source sets, it only optimized the format and file byte size with the same width and height. Second, it did and still does require importing images in a way that at the very least requires you to know the file extension of the original, and in a way that I thought made dynamically creating image source file names impossible. And finally, there was no control at all over how images referenced in markdown are optimized.

The good news is that as of Astro 3.3, there is an improved astro:assets Image component as well as a new astro:assets Picture component that solve a lot of my problems. The issue of leaving it up to Astro to do what it wants with markdown images still exists, but I have a compromise for that issue.1 In the meantime, Astro 3.3+ can now create multiple image formats, multiple image pixel sizes, and can create both img and picture tags with source sets for great image responsiveness.

A Problem Requiring Responsive Images and Dynamic Image Names

Let’s look at a real world use case to show you a typical scenario where you need to create your image source file names dynamically as well as create multiple sizes.

Friends with Brews is a podcast about conversations and different kinds of brewed drinks – beer, coffee, or tea. Because part of the show’s premise is trying new drinks and giving them a thumbs-up or thumbs-down, I also want to keep a list of these drinks and showcase them both on the individual episodes they’re consumed on as well as on an aggregate brews page.

Friends with Brews brew list page

Each of these little detail blocks links to a details page for the specific drink.

Drink details page

Because several of these images are typically displayed on any given page, or because the image on the individual drink detail pages are dimensionally larger, I want them optimized as much as possible. In addition, I want them to be as responsive as possible for different size screens and different pixel densities.

One thing to note is that all of the drink details for every drink are kept in a JSON file called brews.json. This JSON file includes the name of the image associated with the drink. The JSON entry for a specific brew looks like this:

"id": "YodfV6yTeB75PJpmQDPgU",
"name": "Oktoberfest Märzen",
"brewery": "Hacker-Pschorr",
"image": "HackerPschorrOktoberfestMarzen-8E6221D0-7EB7-46B3-8AFA-5CA4A1E6AC1B",
"description": "As it was forbidden to brew in summer, a stronger beer -- the Märzen -- was brewed earlier in March. It would finally be served at the Oktoberfest, under the \"Heaven of Bavaria.\" We have returned once again to the age-old recipe and recreated that gloriously smooth, honey-coloured piece of history from times gone by. Perfect with: Bavarian sausage salad and all the titbits a true Bavarian would also enjoy: roast chicken, sausages or suckling pig cooked in Wiesn beer.",
"type": "beer",
"sortOrder": "0",
"episodes": ["54"],
"url": "",
"rating": [
"host": "Peter",
"vote": "thumbs-up",
"description": "It is malty, it is toasty, and it is crisp. Very happy, this is good."

Note the image entry: the image name doesn’t have a file extension for technical reasons, namely that when you’re importing images in an Astro file, you can’t create a dynamic file name including the file extension. Vite has to know the file extension ahead of time, even if you do cobble together the rest of the file name at compile time.

Because of this, I just made all my images PNG, regardless of what they would later be optimized to by the various image optimization components I’ve used over the life of the Friends with Brews website, and therefore I also didn’t include the file extension because I would be hard-coding it into the image name string to keep Vite happy.

It sounds more confusing than it is. Here’s my code pre-Astro 3.0, back when Astro had an image optimization tool called @astrojs/image which had both Image and Picture components. Note the src property of the Picture component and the above paragraph will make more sense.

import { Icon } from "astro-icon";
import { Picture } from "@astrojs/image/components";
const { brew, episode } = Astro.props;
<div class="brew">
<div class="brew-image">
<a href={`/bottle/${}/`}>
widths={[400, 800, 1200]}
formats={["avif", "webp", "png"]}
alt={`${brew.brewery} ${}`}

Astro 3.0 - 3.2.x Solution

After migrating to Astro 3 and before Astro 3.3 gave the ability to generate multiple widths for each desired image format, I was generating those myself. For my brew images, I was creating 400 pixel wide and 1000 pixel wide images for each drink in addition to the original size. This was all automated with Retrobatch, but it was still a little more work and management on my part.

Retrobatch automated image generation

In my case, I would generate the 400 and 1000 pixel wide images in webp, and also keep the full-sized png on hand to link to for people who like staring at large images with equally impressive download times.

Here’s what my BrewsDetails.astro file looked like with this solution:

import { Icon } from "astro-icon";
import { capitalize, brewIcon } from "./utilities/stringformatter.mjs";
const { brew, episode } = Astro.props;
const brewImage = brew.image.replace(/(-)(\w{8}-\w{4}-\w{4}-\w{4}-\w{12})$/, "-400$1$2") + ".webp";
<div class="brew">
<div class="brew-image">
<a href={`/bottle/${}/`}>
<img src={`/images/brews/${brewImage}`} alt={} />
<!-- Etc, etc, etc -->

The first thing eagle-eyed readers will notice is that I’m not using any kind of image component at all here – just a plain old html img tag. This is because I was already generating the optimized images and because I was using a wider image size than needed to help with the high pixel-density display cases.

This string is just making sure we’re grabbing the 400 pixel wide version of the image for this view:

const brewImage = brew.image.replace(/(-)(\w{8}-\w{4}-\w{4}-\w{4}-\w{12})$/, "-400$1$2") + ".webp";

This is all fine and dandy, but it’s less optimal than the pre-Astro 3.0 days, because the html I was using does nothing for lazy loading, does nothing for only grabbing the largest image needed for the device screen size and pixel density, and is basically a massive compromise.

I was not a giant fan of having to do this, in other words.

Fortunately, the smart people at Astro kept refining Astro 3.x’s image optimization solution.

Astro 3.3+ Solution

Now that Astro 3.3+ has the ability to use the Image or Picture components to generate multiple widths per image format, this solves the problem of different screen sizes and pixel densities. Now I can let it generate the extra images for me.

Here’s what the Picture component looks like for these small drink images:

import { Icon } from "astro-icon";
import { Picture } from "astro:assets";
import { capitalize, brewIcon } from "./utilities/stringformatter.mjs";
const { brew, episode } = Astro.props;
<div class="brew">
<div class="brew-image">
<a href={`/bottle/${}/`}>
<Picture src={import(`../assets/images/brews/${brew.image}.png`)}
formats={['avif', 'webp', 'jpg']}
widths={[400, 800]}
alt={`${brew.brewery} ${}`} />
<!-- Etc, etc, etc -->

Here’s the file diff between my Astro 3.0-3.2 version versus my new Astro 3.3+ version:

BrewsDetails.astro file diff

By the way, remind me to talk about Kaleidoscope sometime. Its ability to diff things in multiple views, act as the command line difftool, and show diffs between different git commit versions is really spectacular.

Importing images using dynamic file names

Notice the difference between the way the Picture src property is composed here compared to the pre-Astro 3 version in the first half of this article? This is because the images located in the src directory need to be imported for the astro:assets Image and Picture components. Typically import statements do not like dynamically constructed strings – they error out and complain that you need to give them a static string.

Fortunately I ran across an Astro Discord thread explaining how to do the import using a dynamic string (still requiring the file extension to be statically defined, of course), and let’s just melodramatically say that it changed my life.

Another equivalent way to do it would be to use import.meta.glob to grab all the image assets and then grab the image using the key of the matching image file name, like this:

const images = import.meta.glob("../../assets/images/brews/*.png");
<Picture src={images[`../../assets/images/brews/${bottle.image}.png`]()} formats={['avif', 'webp']} alt="A description." />`

If, like me, you were desperately hoping for a better way to optimize your images after migrating to Astro 3, your prayers are pretty much answered. There’s still the issue of image links in your markdown files, though. I’ll cover that topic in a future post.


Astro 3.3: Picture component | Astro Blog
Images Component 🚀 Astro Documentation
Picture Component 🚀 Astro Documentation
My Responsive Images series


  1. The issue of how markdown images are optimized is not completely immaterial because markdown image links are used for every single image inside blog posts or podcast show notes, for example.

Podcast Transcripts With Audio Hijack

Part of the My Podcasting Workflows series

There I was sitting in bed after a long work day, reading SixColors, as one should, when I stumbled across this article: Audio Hijack adds automatic transcription.

This is kind of exciting. I have mixed feelings about it, actually. On the one hand, not having to laboriously create transcripts after the fact with the admittedly lovely MacWhisper does sound good. On the other hand, I’ll still have to edit the transcript to more closely mirror the edited podcast, since this will transcribe the live recorded version of the conversation instead of the edited version.

Anyway, who cares – obviously I’m going to try this out for the next recording of Friends with Brews and see how it goes. Here’s my setup, which I believe should let me get an attributed transcription:

Audio Hijack Transcript Block

I’ve used MacWhisper’s Transcribe Podcast feature on the last two episodes of Friends with Brews I’ve transcribed to get speaker attribution. You can see it in action on the transcription for Episode 52 – If I Were a Beer. If I can replicate that while recording the podcast instead of as a separate task later, you can bet that Audio Hijack Transcribe block will be value added.

Podcast Recording Practices

Part of the My Podcasting Workflows series

I talked previously about the recording software I use for podcasting on the Mac. It’s all great stuff, and if you haven’t read that article, you should. Even if you think you’re not a podcaster, maybe someday you will be, and each of those applications has use far beyond creating podcasts.

At some point in the near-ish future, I want to talk about specific app setups and use methodologies for podcasting, but before I do that I want to talk about some general best practices for recording. Some of these will help make the life of whoever edits your podcast a lot easier, assuming they care about sound quality and conversation flow.

I know a lot of people say no one cares about audio quality or crosstalk or words repeated three times in a row, but people do care. It’s a lot different being in a conversation and not really hearing all the starts and stops and repeated words and uhms and ahhs, but they start to matter for people listening to podcasts.

Since your goal is to make your podcast as enjoyable as possible and you don’t know what annoys any given listener, why not make a good faith effort to make it as listenable as possible? In terms of recording, it takes very little extra effort to have a good quality sound and smooth conversation versus one that makes it obvious you couldn’t be bothered.1

My motto about effort is “I can care less than you do”, meaning that if you, the media or product producer, don’t even care enough to try, why should anyone else care about your product either? This is not the same as saying you have to sound like This American Life or have custom jingles and the best artwork in existence. It does mean you need to clearly be trying so that your listeners know you really do care about their experience. Other people won’t care about your thing unless you care about your thing.

Get Rid of Noise

If you have a noisy podcast, some segment of your audience, probably a much larger segment than you think, will notice and will care. There have been several podcasts I’ve tried in the past that I just couldn’t listen to because it was too obvious that the hosts just recorded without testing or listening back to their own material and threw it out there for the world to suffer to.

When I say noisy, I’m using the term as a catch-all for background noise, hiss in the recording, water heaters, air conditioning, vocal reverb or extreme compression (think Skype or Zoom recordings), and even things like clipping, which is when your signal is too loud for the mic to handle and the waveform clips at the top, resulting in a very painful noise in the recording. It’s amazing how many people don’t even bother to see if they’re clipping or not, and it can be hard to fix in post.

Some simple steps for getting rid of noise in your podcast include the following.

Consider Your Mic

Use a decent mic, preferably one that doesn’t pick up every sound between the mic diaphragm and Mars. For this reason, condenser mics like the oddly popular Blue Yeti will not work for many people.

Echoing Is for the Alps

Reduce echo in your recording environment. Foam panels and temporary throw rugs and curtains can do wonders to absorb sound rather than let it bounce around.

Don’t Blow Hot (Or Cold) Air

Record as far away from air blowers as you can. Sometimes you’ll have no choice but to record with AC or heating on – let your editor know (maybe that’s you) so they can test some recordings of yours and see if they can remove the noise cleanly. Chances are they can, but they may need a little trial and error.

Mute Yourself

Have a mute switch, be it hardware or software based. I have an Elgato Wave XLR, which has a capacitive touch mute switch, and I love it. Peter uses an app called Shush since he’s using a USB mic.

Use your mute switch when you cough, snort, drink (unless your podcast IS at least partially about the drink), eat, or otherwise make noises that your editor should care about. Also mute whenever not talking to avoid the temptation to talk over someone else, which also makes editing take longer (again, your editor should care about crosstalk).

It’s All in the Technique

Learn good mic technique. This is harder than it sounds. It’s very easy to talk very loud sometimes and very quietly at other times. Some mics require eating the mic and others will overdrive in a second if you’re an inch too close and be at a nice level otherwise. Stay at a consistent distance and position relative to the mic, and don’t forget you ARE recording and not just having a nice zoom call.

What you’re striving for are consistent levels and quality of voice, and both can change drastically based on your own speech habits (talking loudly at the start of a sentence and trailing off into a whisper) or distance from mic. Practice and listen to your practice recordings.

Think Global, Act Local

Have everyone record their own mic locally. You will put each of these recordings into your editor and line them up. This will give you the ability to eliminate crosstalk (which you can’t do with everyone other than you on one track), get better, non-compressed sound quality (which you can’t do with a Skype or Zoom recording), compensate for noise and volume differences between other hosts (which is much harder to do with everyone else on one track), and can and should result in the best sounding voices for everyone.

Making everyone sound as good as possible is the editor’s goal. If you’re a host and also the editor, you get zero points for caring about the sound of your own voice and no one else’s.

There are lots of other considerations for clean sound, but this is a start, and I’ve already yammered on for almost 950 words now. So just one more thing:

Practice and Tweak

This does not mean I want you to be a tweaker, but I do want you to record and listen to the recordings. Have your co-hosts do the same, and give everyone’s test recordings to the editor to play with. Change your environment and/or recording settings as necessary. This takes practice, googling, and research if you’re not an audio engineer, but fortunately there is enough good quality affordable hardware and software that can create a nice sound that you don’t need to become an audio engineer either.

Next time I’ll talk about some specific software settings I use to try to get a decent recording. I know this post is very high-level and theoretical, but it’s really more of a nudge to think about these things and realize they need to be taken into consideration. Your listeners will thank you, but so will your inner producer. It’s your name on the product, so why not make it as pleasant to listen to as possible?


  1. This probably sounds preachy, and I don’t claim to have the most amazing podcast production quality in the world. But I do TRY. The listeners can give me feedback if they think I’m failing at it, but if anyone says I don’t take it seriously, they are wildly incorrect.

Astro 3 and Responsive Images

Part of the Responsive Images series

Astro 3 is here and you’re looking at a site published with it. I spent a few days last week converting this site and Friends with Brews from Astro 2.x to Astro 3, and there are some things I had to learn and decide to make it happen, and most of it has to do with responsive images.

You may recall my long saga of responsive image generation methods for this site and for Friends with Brews. Most of this journey has revolved around the fact that there are two kinds of optimized images on my sites:

  • Site related (logos, images for permanent site pages, etc),
  • Content related (images in blog posts or podcast episode show notes).

Site related images are easy. I can use whatever the image optimization scheme de jour that Astro uses because these are known, unchanging files and because I refer to them inside Astro components.

In the case of Astro 3, the astro:assets Image component is the official way to create optimized images inside Astro components.

This component is a lot less flexible and capable than the previous @astrojs/image component. There’s no Picture component, it doesn’t resize images from the original size, and as a result it’s easy to wind up with larger image sizes than you need and not have smaller physical sizes for responsive views like phone browsers. But it handles Astro SSR mode and prevents CLS (cumulative layout shift), which is really annoying to see.

I have relatively few site images on either this site or Friends with Brews – mostly site logos and pictures of the offenders (me on this site and Peter and me on Friends with Brews).

Using Image in an Astro component involves importing the images to be used and setting those imported images as the Image component src.

import { Icon } from "astro-icon";
import { Image } from "astro:assets";
import Base from "../layouts/Base.astro";
import site from "../data/site.json"
import av from "../assets/images/ScottLatest.jpg";
let title = "About Me - " + site.title;
let description = "About Scott Willsey";
<Base title={title} description={description}>
<h1>About Me</h1>
alt="Scott Willsey"
(etc, etc, etc)

It’s important to note again that width={600} doesn’t result in Image creating a 600 px wide version of the image. It will create a webp image of 85% quality as specified but in the original image dimensions and aspect ratio. The 600 pixel width is used in the HTML that it outputs to tell the browser what to do with it:

<article data-astro-cid-kh7btl4r>
<h1 data-astro-cid-kh7btl4r>About Me</h1>
<img src="/_astro/ScottLatest.69c944ff_Ctgce.webp" class="about-av" alt="Scott Willsey" data-astro-cid-kh7btl4r width="600" height="600" loading="lazy" decoding="async">
<p data-astro-cid-kh7btl4r>Hello, friend.</p>
(etc, etc)

Content related images are images IN the content of the site itself, whether that be blog posts (this site) or podcast episode show notes (Friends with Brews). In my case, my content is in Markdown, so my image links are just standard Markdown image links. They are also hyperlinked to the original full-sized image.

The one really interesting setting is "Keep History For", which has options for 7 days, 30 days, 3 months, 6 months, 1 year, or unlimited. Unlimited comes with a warning that your hard drive will slowly be eaten alive and you should be ok with that.
[![Clipboard History retention length setting](../../assets/images/posts/ClipboardHistoryLengthSetting-E511BEDE-4432-49AB-A442-05069F910E41.png)](/images/posts/ClipboardHistoryLengthSetting-E511BEDE-4432-49AB-A442-05069F910E41.png)
The Clipboard History view itself is relatively simple. You can have pinned history items, and below those are your history items in reverse chronological order. The beauty of a clipboard history function is that you can copy several things in a row from a source and then worry about pasting them all later without losing any of them.

Get rid of all that hyperlink stuff and the Markdown for the image itself looks like this:

![Clipboard History retention length setting](../../assets/images/posts/ClipboardHistoryLengthSetting-E511BEDE-4432-49AB-A442-05069F910E41.png)


Yes, I put UUIDs in my image names so that I never have to worry about name collisions, however unlikely. I have this automated on my Mac with folder actions. I talked about folder actions in my post about Automatic Image Processing With AppleScript and Retrobatch, but basically the idea is you can set a script to run whenever a specific thing happens to a folder. I can dump a bunch of images into a specific folder and they get output into another folder with the original file name plus a UUID appended.

Anyway, the good news is that the astro:assets Image component handles images in Markdown for you by creating optimized versions in more efficient file types. Here you can see one specific png that it created a webp version for, and the difference in file size.

Terminal window
scott@Songoku:scottwillsey3.0 main 2d cd dist/_astro
scott@Songoku:_astro main 2d ll FolderActionsSetupMenu*
-rw-r--r--@ 1 scott staff 527607 Sep 15 18:37 FolderActionsSetupMenu-86B4A871-966E-4A27-A2C5-3FC85E131D6C.4464166b.png
-rw-r--r--@ 1 scott staff 60900 Sep 15 18:37 FolderActionsSetupMenu-86B4A871-966E-4A27-A2C5-3FC85E131D6C.4464166b_Q8a7k.webp
scott@Songoku:_astro main 2d

One thing that isn’t different is the image dimensions:

Image component optimized vs. original image dimensions

This means I have to pay more attention to original image sizes that I’d prefer to. I’m hoping in the future this new Images component will gain some of the functionality back that it had before, but my guess is the real monkey in the wrench in doing some of those things is the SSR support.

Right now I have a Folder Action that resizes my images to a maximum width of 1770 pixels. I can use those for the blog post inline images and link to the original sized ones. That gives me a compromise between image size and responsiveness, taking into account the high-resolution nature of most modern screens. Images need to be 2x and in many cases 3x the size they’ll be shown at in order to look sharp.

At some point I’ll probably revisit this but no matter what I do, astro:assets Image currently will not generate image srcset HTML for me, so even if I generate multiple sizes for the same file format, only one of them is ever going to get used.

Markdown vs MDX

You may recall that when I originally converted the site from Eleventy to Astro, I used MDX for my content files instead of Markdown. MDX allows the use of components and would let me directly use the astro:assets Image component in my content for content images the same way I do in my Astro components for site images.

Astro 3 will let you use the astro:assets Image component directly in MDX. This gives you more control over the HTML that’s generated for your image, but it also comes with extra complexity in terms of the writing process.

I decided a long time ago that I don’t want to go down that path any longer because when I’m writing, I don’t want to mix implementation details with content. I don’t write my blog posts in a code editor, and when I’m writing, I don’t want to have to remember how I have everything set up, and I don’t want to have to import components and images into a content file. I just want to use Markdown links.

Image Component vs Astro Remark Eleventy Image

The last Astro 2.x version of this site used Astro Remark Eleventy Image to generate responsive images for images inside markdown content. It worked well, it’s very flexible, and it had several upsides. The downsides are no support for SSR, if you need that, and it results in a slower build process because it doesn’t cache previously rendered images. Because of this latter fact, I decided to move entirely to the astro:assets Image component.

I was also worried about Astro’s Image component trying to process images in my Markdown files and fighting Astro Remark Eleventy Image, but I haven’t tested to see if this will happen. I may make a branch and link to my public images folder for images in Markdown and see if that avoids a collision between the components. If so, I may wind up using Astro Remark Eleventy Image again to get more responsive images with better file size/quality compromises.


Even when I’m done, I’m never done. That’s the real takeaway here. As with anything, careful consideration of how you use images and what the compromises are between different solutions is required with Astro 3 (and every version of every web framework, honestly). I’m sure there will be much more on the topic of image optimization from me in the future, given my history with it so far.

Raycast Clipboard History


Part of the Raycast series

One of Raycast’s core features is Clipboard History. Clipboard History is exactly what it sounds like – a basic clipboard manager that lets you access your clipboard history.

Clipboard History has several settings. As always, to get to Raycast settings, launch Raycast with your keyboard shortcut (⌥+Space in my case), then hit ⌘+, (the standard macOS application preferences keyboard shortcut) to open Raycast Settings.

Clipboard History settings

There’s probably not too much you’ll want to change. You’ll probably want Clipboard History to paste to the active app instead of back to the clipboard, and you’ll probably want fast text recognition for text in photos. The one really interesting setting is “Keep History For”, which has options for 7 days, 30 days, 3 months, 6 months, 1 year, or unlimited. Unlimited comes with a warning that your hard drive will slowly be eaten alive and you should be ok with that.

Clipboard History retention length setting

The Clipboard History view itself is relatively simple. You can have pinned history items, and below those are your history items in reverse chronological order. The beauty of a clipboard history function is that you can copy several things in a row from a source and then worry about pasting them all later without losing any of them. As you can see, clipboard history includes files and images. Any clipboard items show what app they were copied from, what the content type is, and then details such as word count or image dimensions.

Clipboard History image

Clipboard History Retrobatch file

Whatever app is active when you trigger Raycast and Clipboard History will be the app you can paste your selected item into by hitting Return. If you have your cursor in a Safari URL bar at the time, it’ll paste it there, assuming it’s text. If you’re typing in Drafts, like I am right now, it’ll paste the item into Drafts. In each case, the paste will only happen if the selected item is a content type that’s contextually possible – you can’t paste images into Safari URL bars or even into Drafts (it’s a markdown text editor), but you CAN paste an image or other file into a Finder window or an image into a text editor that takes images.

Clipboard History isn’t something you can get people hyped up about at parties, but it is super useful and it’s nice having an easy to use and straightforward implementation of a clipboard manager right in Raycast. You wouldn’t get Raycast just for Clipboard History because there are tons of other Mac clipboard managers, but if you do use it already, the simplicity and well thought out design make Clipboard History indispensable.

As always with everything in Raycast, you can assign a Hotkey (keyboard shortcut) or alias (open Raycast and type the alias) to Clipboard History. I have an alias of ch assigned so I can just pop open Raycast, type ch and hit enter and be in Clipboard History.

You can read more about Raycast Clipboard History in the Raycast manual section on Raycast Core.

A Series of Series

As I started yet another topic series in my last post about Raycast, I realized there was not a good way on this site to see topically related posts. I decided to remedy this by creating a Series view.

Now there’s a Series menu item that links to a list of Series available on the site. Each of those series names in turn links to an individual series page which is identical to the list except it only shows the one selected series instead of all of them.

Series menu item

Both the Series index page and the Series dynamic route page (to create all the individual series pages) rely on a component called SeriesList.astro to show each series and its associated posts.

On the Series index page, it repeats the component view for each existing series:

Series index

On the individual series page, it just calls the component once because it’s only showing the one series:

Raycast series page

Besides the update to the menu, which is located in layouts/Base.astro, there are 3 new files that make Series happen: pages/series/index.astro, pages/series/[name].astro, and components/SeriesList.astro.

Here are what the Series index.astro, [name].astro, and SeriesList.astro files look like.

import { getCollection } from "astro:content";
import { Icon } from "astro-icon";
import config from "config";
import Base from "../../layouts/Base.astro";
import SeriesList from "../../components/SeriesList.astro";
const allPosts = await getCollection("posts");
const allSeries = allPosts
.map((post) =>
.filter((series) => series !== undefined)
.filter((series, index, self) => self.indexOf(series) === index)
let title = "Series - " + config.get("title");
let description = "Series of related posts on " + config.get("title") + ".";
<Base title={title} description={description}>
<article data-pagefind-ignore>
<span id="series-list">
<h1><Icon name="mdi:plus-box-multiple" /><a href="/series">Series</a></h1>
<div class="series">
{ => (
<SeriesList series={series} posts={allPosts} />
div.series {
margin: 3em 1em;
span#series-list [astro-icon="mdi:plus-box-multiple"] {
width: 1.5em;
margin: 0 0.3em -0.5em 0;
import { getCollection } from "astro:content";
import { Icon } from "astro-icon";
import config from "config";
import path from "path";
import { slugify } from "../../components/utilities/StringFormat.js";
import { deslugify } from "../../components/utilities/StringFormat.js";
import Base from "../../layouts/Base.astro";
import SeriesList from "../../components/SeriesList.astro";
export async function getStaticPaths({}) {
const allPosts = await getCollection("posts");
const sortedPosts = allPosts.sort(
(a, b) => new Date( - new Date(,);
const allNames = new Set(); => { && allNames.add(slugify(;
return Array.from(allNames).map((name) => {
return {
params: { name },
props: { posts: sortedPosts,},
const { posts } = Astro.props;
const { name } = Astro.params;
let title = deslugify(name);
let description = "Posts in " + title + " series.";
<Base title={title} description={description}>
<article data-pagefind-ignore>
<span id="series-list">
<Icon name="mdi:plus-box-multiple" /><a href={new URL(path.join("/series", name), config.get("url"))}>{title} Series</a>
<div class="series">
<SeriesList series={title} posts={posts} />
<p class="series-link">
<a href="/series"><Icon name="mdi:plus-circle-multiple" /> Browse all series</a>
div.series {
margin: 3em 1em;
span#series-list [astro-icon="mdi:plus-box-multiple"] {
width: 1.5em;
margin: 0 0.3em -0.5em 0;
p.series-link {
margin: 1.5em;
[astro-icon="mdi:plus-circle-multiple"] {
width: 1em;
margin-bottom: -0.15em;
import { Icon } from "astro-icon";
import path from "path";
import config from "config";
import { postdate } from "./utilities/DateFormat.js";
import { slugify } from "./utilities/StringFormat.js";
import { titleCase } from "./utilities/StringFormat.js";
const { series, posts } = Astro.props;
const filteredPosts = posts.filter((post) => !== undefined && (slugify( === slugify(series)));
<section aria-label="Series list">
<h2><a href={`/series/${slugify(series)}/`}>{series}</a></h2>
filteredPosts.sort((a, b) => -
.map((post) => (
<a href={new URL(path.join(config.get("posts.path"), post.slug), config.get("url"),)}>
<div class="cal">
<Icon pack="bi" name="calendar2-week-fill" />
<time datetime={}>
href={new URL(path.join(config.get("posts.path"), post.slug), config.get("url"),)}>
<div class="description">{}</div>
header {
background-color: var(--surface-menu);
border-radius: 0.5rem;
padding: 0.5rem 2rem;
margin: 1rem 0;
h4 {
margin: 0.3em 0;
}, a {
font-weight: bold;
font-size: 0.75em;
color: var(--accent1);
div.description {
font-size: 0.75em;
margin: 0.3em 0 2em;
div.description:last-child {
margin-bottom: 0.5em;
[astro-icon="bi:calendar2-week-fill"] {
width: 0.75em;



Part of the Raycast series

If you’ve listened to recent Friends with Brews episodes, you probably know that I’ve gotten into Raycast in a big way. Raycast falls in the category of “App Launcher”, but I really dislike that title as it sells short what most of the good app launcher category apps do. For me, Raycast is a system utility that verges into automation territory.

Raycast window

I intended to write one blog post about all the features I use in Raycast. About the time I’d gotten to the 1600 word mark on my draft, I had a conversation with my friend Peter about some Raycast articles he’d read. Specifically, Peter didn’t like the fact that they all mentioned some commands you could use and showed some screen shots, but never went into depth about how they worked or why you’d want to use those features to begin with. At that point I saw my single gigantic post fracture into a million tiny pieces, and I knew it was going to be a series on Raycast. It’s the only way to provide meaningful information on how to use it rather than just flinging a bunch of bullet points at the page.

Raycast has a lot of features and requires some digging into to find what works and how it works. The versatility in terms of how to find and use commands is important to grasp because the right setup can make the difference between adding new workflows to your Mac use that make you efficient and happy, and forgetting those features are there at all and wondering why people think Raycast is even useful. It’s no different than any other multipurpose tool in that regard.

What IS Raycast?

What does Raycast say Raycast is?

One way to find out what an app is is to ask the developer of the app what it is. Raycast (the company) has this to say about Raycast (the product):

Raycast is a blazingly fast, totally extendable launcher. It lets you complete tasks, calculate, share common links, and much more.

That’s great, and it’s true, but it’s also not enough information to help someone who truly doesn’t know anything about the horrendously named app launcher category understand why they’d want to use it. I understand they need a concise statement of purpose, and truthfully I doubt I could do any better myself. That’s why this first blog post in my series on Raycast is just bit longer than that.

What does ChatGPT say Raycast is?

I decided to ask ChatGPT, via Raycast, what ChatGPT thinks Raycast is. ChatGPT’s reply?

Raycast is an AI-powered software productivity tool that provides a unified interface for accessing and executing various tasks, applications, and information within a computer’s operating system. It allows users to quickly search for files, launch applications, perform calculations, access web services, and more, using a text-based command bar. Raycast aims to streamline workflows and improve productivity by simplifying task execution and information retrieval within the computer environment.

Ok. Again, all technically true, and it’s definitely “within the computer environment”, which is good to know if you’re worried about Raycast trying to take over your house or steal your car.

What does Scott say Raycast is?

Raycast is a Mac power-user utility for making your workflows faster, more powerful, and more centralized and maintainable.

That’s basically my way of saying if you really want to know what Raycast is, you’ll have to read this series. 🙂 But let’s cover some basics and key features of Raycast that will help as I slowly roll out blog posts emphasizing a specific command or extension in detail over the course of this probably infinite Raycast series.

Some Basics

Raycast is categorized as an app launcher. To that end, it’s basically a search bar that appears on screen when triggered by some key combination. Personally, I use Opt-Space, although I could map it to Cmd-Space and completely replace Spotlight’s keyboard shortcut.

Search and Selection

Once the search bar appears, you start typing things, varying depending on your goal. If you want to launch an app like the horrible category name suggests, you start typing the name of the app and Raycast comes up with options for you to choose from.

Raycast application search

To make selection fast and easy, Raycast lets you use Cmd+number keyboard combinations to make a choice. Hold Cmd for a second and you’ll see what number key to hit to select a particular option. They’re numbered from top to bottom as could be expected, so the Cmd+number choice for a given app is just its order in the list.

Raycast Cmd selection numbers

This same Cmd+number selection technique works for anything you search for in Raycast, so anytime a list is on screen, you can use this to quickly make your choice from the list of applicable items.

Hotkeys and Aliases

Anything you can do in Raycast you can assign to a HotKey or an Alias. A HotKey is a keyboard shortcut.

HotKeys let you perform a command without having to open Raycast first. This works especially well for its window management commands, but is useful for a lot of things.

Aliases require you to open Raycast, but then you just quickly type the alias and you have that command selected and ready to execute without having to search for it and choose it from the list.

Here’s an example of a bunch of the Window Management commands with HotKeys assigned, followed by one of some Safari commands with Aliases.

Raycast HotKeys

Raycast Aliases

These are some of the very basics of Raycast that will come in handy as I show some examples of my Raycast workflows in future articles.

To Be Continued

I already have some posts on other topics that could be linked as different series on my site but I currently have no way of grouping them and surfacing them to the user as a series. Adding that functionality to the site will be step 1 in the Raycast series, even before firing up Drafts and typing additional words about the app itself. It should be easy enough, and I can even write about how I did it. Bonus!

Once that’s done, Raycast deep-dives will be forthcoming.