That word, "unprecedented" is a bit loaded. I mean it less as sensationalism and more that it's an important attribute of how the web is evolving today. Because it may mean that we and our teams need to act in ways that we never have before.

Hindsight now affords us a clear view that many factors have contributed to the acceleration of web tech over the last ~5 years:

I want to cut to the chase: I see the cracks starting to show in teams and projects that haven't kept up; through various open-source projects, to friends and friends of friends struggling to keep their stress levels down due to tech debt coming to collect. It's visibly accelerating; more and more deprecated, even abandoned dependencies, projects stuck on incredibly old and now brittle node versions, Dependabot shouting daily about new security vulnerabilities.

Back to things being unprecedented, a lot of web developers kept a mostly even pace set from the early 2000's to around 2015, which was fairly methodical, not necessarily stagnant, but pretty manageable to deal with the odd new feature that trickled down the pipe. And I think until now, the repercussions of keeping that pace haven't yet critically surfaced.

So here's my warning: The old skill sets need updating, right away. The gap is widening between those who are engaged with the change and those who fell into a comfort zone of what they know. Things will only get worse as the new productivity of the web leaves old concepts further in the dust.

Individually, if this idea resonates with you I think that's great, the power is absolutely in your own hands. But my bigger concern is with teams; whole companies even. How development teams are managed provides the biggest opportunity to catch up. Time needs to be invested and accounted for in keeping pace with the industry. It's no longer going to work to offer outdated solutions that miss the mark of being a part of today's modern web. Without strategic investment in updating role/skill matrices and individual learning plans, we could see many teams and companies succumb to overwhelming technical debt caused by the accelerated rising tide of digital entropy.

The good news is, I don't think it's too late. With the right adjustments and investments any person, team or organization can catch up. And not only that, but the opportunity here isn't just to catch up, it's about continuing to keep pace in this marathon of a time. Doing that and also building awareness around how the industry continues to move will provide incredible confidence to the software and products you build.

It's a common trend that as technology matures, it becomes more imperative that businesses understand clearly how to utilize it rather than rely on techno-mystique to get them by; ultimately time with tech leads to the savvy winning-out.

But the abrupt adjustment to the evergreen nature of the web today is disruptive to the idea of this pattern happening in longer-term cycles. Those who haven't yet, or don't soon, tighten that loop will start to fall out of sync entirely, and those that do it well will stand to gain quite a bit.

Whether it's front-end, back-end, devops or other interfacing skill-arenas that power the web ecosystem, the optimal concepts to deploy those domains have changed drastically in the last few years and will continue to move as fast or faster. If you're feeling left behind, now might be a great, and unprecedented, time to adjust and get moving.

The great news is that beyond hobby bloggers like me, there are some incredible voices out there making it really easy to get exposed to and learn some of the new cool concepts emerging in web tech. Here is just a glimpse of bloggers and articles that can get you on your way.

Better yet, skip the links and join the communities. Across discord, mastodon, bluesky, twitter (meh, sort of), and now threads, there are a ton of folks out there to connect with and learn from in real time.

To put the ending first, yes! I think if you're here reading this on your own time, because you're in web dev mastodon or (ugh) birdsite, or from a discord server, or you have me in your RSS reader, or did a nerdy google search: yes, we are the weirdos. But it's really a great kind of weird.

I only came to this realization a handful of years ago. I'll admit, for most of my early career I thought everyone obsessed over the latest and greatest HTML, CSS and JavaScript happenings, I thought it just came with the job. But it turns out, there's just a pretty good bubble for that sort of thing; perhaps mostly grown via blogging and web dev Twitter, all the folks engaged enough to hit publish early and often have created a euphoric echo chamber, that I'm very content to get comfy in.

Anyway, the point? Once I started realizing that it's more of a minority that spends some sub-section of their free time doing web dev stuff, the more I realized how much of an advantage we all have:

Yes, I think so. Blurring the line between work and passion can be precarious to manage. I think it's important to build up some semblance of a wall to make sure you're pursuing development as a passion in a way that is not work, and instead, still does pique your interest. Related, checking in on yourself to make sure you're free time endeavors are not additive to burn-out feelings is critical.

I'm not a fan of binary divisions, so I think this is all a weirdo spectrum of sorts. I've come across lots of co-workers that genuinely have deep passion for their work, but they just happen to love doing other fun things in their free time. And I've met a few that truly just see it as a job, keeping their skills just as sharp as they need to carry out their responsibilities.

But I really identify with the folks that engage and obsess over it all. Chris Coyier touched on it on the ShopTalk Show podcast recently, saying,

"I always thought that was a cheat code I had for life. It just so happens that something I find relatively entertaining is this kind of thing, not necessarily listening to our show, but I listen to lots of different shows and blogs and stuff, and I read it and do all my RSSing and YouTubing and all that stuff. There's some negative implications to this too, but as a hobby almost, like I actually kind of find it fun. I say it's a cheat code because it becomes useful then, like when something comes up I'm like 'oh yeah that's the HSTS lists built into chrome browsers...' and the only reason I know that is because I read something about it one time almost recreationally, not because of my career experience, but because my hobby helped me get there."

And he's absolutely right! I don't think there's a week that goes by where that extra bit of staying connected to the web development world as a hobby doesn't help me out with being productive at work.

So if you're a weirdo like me, I say keep being weird; it's okay to love what you do professionally to a point where it takes up your leisure time; it's not something you have to fight if you don't want to. And that's quite the final point I want to emphasize: I spent a decent bit of time not allowing myself to be comfortable with this idea, but once I embraced it and said, "hey, it's great," it only made things better.

In 2017, with an hour to kill before teaching a web development class at UCSD, I stumbled into a free talk being put on. Living Computation & Postdeterministic Digital Design by Dave Ackley. Little did I know it was to be an inflection point in my entire view of computer science and personal scientific interests.

This post is likely to get long, so I'll split up the sections into a table of contents for easy reference:

To set the stage for all of this, we have to look at the foundational components of computing we desperately rely on today. CPU and RAM; the Von Neumann Architecture has been the underlying fixture upon which we compute for nearly 80 years. It's the guarantee of hardware determinism that allows us to code in the way we do: the minutely micromanaged dictatorship of the Centralized Processor Unit tells us that with its complete worldview and direct access to the entire software state held in RAM, it will not ever deviate from perfection. So that from step one of our program to step one billion, we can rely on deterministic results and values to be what we expect them to be.

This is how Dave put it in his talk, and when put this way it sounds quite amazing, too amazing. Hardware determinism is fragile. Sure it has taken us incredibly far, I'm not saying to discount it at all. But the fact is, we've climbed so high on this fragile path that as we begin to see limitations ahead of us, we're becoming more and more aware of the treacherous place we're currently computing in.

One bit-flip and we might be cooked - might not be too - but might be indeed, and there's no way to predict which it will be. Crashes, blue screens, all of these symptoms showing through the cracks of hardware determinism. And we pave over them:

We avoid the underlying issue entirely because we accept it absolutely as the immovable, unchangeable part of the system.

What of a world beyond hardware determinism? A new system, built from the ground up, where hardware certainly tries to be correct, but doesn't guarantee it, and without that contract, software now has to be built to run and adapt in that world.

Well, that's Robust-First Computation, a computational system of hardware and software that embraces non-deterministic execution, and it's not just an abstract idea anymore.

In order to understand why it's Robust-First Computation, we need to break the problem down. CPU and RAM impose a C.E.O. paradigm into its computational policy: Correct and Efficient Only!

As soon as we dispose of that foundation, we need to understand what other concepts then become available and useful on this less reliable platform. Robustness is the ability to withstand or overcome adverse conditions or rigorous testing and in an environment that is no longer guaranteed to be correct, lends itself incredibly well as a concept to deal with incorrectness or unknown conditions. So as we introduce the ability to be incorrect, we can trade off efficiency for robustness (because they are at odds) in order to maintain correctness.

And so we're left with the Robust-First Computing Creed:

First be robust

Hello. Are you still with me? Thanks! Let's try to bridge into the more tangible aspects of these wild ideas I've laid out, and get into what this all might look like from a hardware and software perspective.

It's important to set a good perspective for all of this. Undoing CPU and RAM and starting over is hard and will be slow, and we're only barely beyond, or even arguably at, the starting line. But that's what is so interesting to me. After 80 years of core computer science discovery, nearly all based on deterministic execution, this feels like a small, obscured basement door, left dusty and unperturbed, that opens up into an entirely new parallel universe of undiscovered computer science. Absolutely wild!

So what does robust-first code look like? One way to answer this question objectively is to look around and see if we can find any robust-first systems that already exist, and in fact, they do! Humans, animals, microorganisms, plants; living systems are incredible examples of computational systems built to withstand and execute amidst wild amounts of varying environmental factors.

From Dave's own Robust-first computing wiki:

Viewed as a kind of computer, note how different a living organism is compared to a serial deterministic machine. Deterministic machines are 100% completely repeatable – from the same inputs will come the exact same outputs — while living organisms rarely do anything the exact same way twice. Deterministic machines will crash, seize-up, or otherwise misbehave when virtually anything goes wrong inside them; living organisms, by contrast, can suffer grievous injury and yet survive, handle the immediate situation, and get away long enough to heal up and live on.

And so in thinking about what our code might look like, it's put forth that living systems are ripe for the picking to discover some of the base principles that might help us get into this new world.

And many more observable concepts can be repurposed into the pursuit of building robust software.

"But Andrew, that's not writing code, that's thinking about writing code!"

Too true! To get down to the clickity-clacking of our keyboards there's a lot of work to figure out and do. But once again, thanks to Dave Ackley and others thinking about these ideas for many years now, there are some places to lean on to jump further into it.

The Movable Feast Machine (MFM) is a specific architectural implementation of a software operating system, meant as a basis for programming robust-first software. Certainly, it's one of many possible ways you could build a robust-first architecture, but having worked with it myself, I would implore you to take a deep look at all it has to offer before trying to come up with your own system.

When people first see the MFM running, it's common to hear, "oh, it's like Conway's Game of Life!" And the answer is, "Yes, a little bit, but 'No' a lot a bit."

The MFM is a spatially laid-out 2D Grid, where individual grid Sites, implemented on hardware Tiles can contain Atoms which are essentially small agent programs that execute code or behaviors upon the grid within their own localized space. The important part is that there is no central control here. Each Atom on the grid can only see Manhattan Distance 4 sites away from its current location. This is called the Event Window and it brings enormous power and constraint in building atoms to navigate and do things together on the grid.

The tiles, where sites are implemented are treated as an implementation detail in the architecture: they're required to create a physical grid of tiles, and do help with robustness in that tiles can be swapped in and out as things need maintenance, but otherwise, the sites and atoms have no understanding that they are there; there is only the vast grid.

This brings us to an aside that I had not yet figured out how to work in. The MFM grid is built to be indefinitely scalable. Don't get it confused with infinitely scalable, we're not talking theory here. By having no centralized hardware or software unit, the MFM is designed to surpass traditional computing power, not by being efficient and fast, but by being able to grow in size without limits.

The official MFM is currently available in two places:

First, you can get started with the Movable Feast Machine Simulator (MFMS). Dave has built this as a software program that runs on Linux and can be programmed in two programming languages he has concocted for robust-first programming: ULAM and SPLAT. The ULAM wiki is a great place to start if you want to take a look.

Boiled down, programming an atom is a matter of defining how it should behave using what it can see (the Event Window) and the limited available state it has, to manipulate its local environment. Randomly, an atom will be picked to run, and execute that behavior.

Constantly churning, random execution across the grid then creates a system where these atoms can compose their behaviors to work together to build larger systems, bottom-up, to force robust-first thinking into your software architecture.

Second, you can follow along with Dave himself as he has undergone a public, youtube-chronicled, multi-year journey of going from simulator to full hardware implementation. The T2 Tile project documents the journey of building physical hardware tiles that run a true version of the MFM architecture. To date, the project has been quite a success in proving-out the system and uncovering problems in building this type of architecture.

The T2 Tile Project introduction video is also a great way to hear a lot of these high-level concepts that I've been talking about in a clearer, more concise way.

Or if you want to skip all the way forward to seeing what this indefinitely scalable tiled grid of computers looks like, there's a T2 Tile Demos channel as well.

If you're reading this because you follow me, you're likely a lot more web-oriented in focus. Being a fanatical follower of this movement for many years, I have concocted my own implementation of the Movable Feast Machine as a JavaScript library.

Leaving that talk in 2017, an unquenchable desire to see what robust-first programming was all about started to grow in me. Without the ability to run the MFMS, my only option was to reimplement the concepts for myself to a level that let me play with it all first-hand.

Out of that came MFM.rocks where you can see some of the Elements I've built over the years in action. And this twitter thread follows some of the highlights, learnings and experiments I undertook as well.

I'm happy to walk through the interworkings of the MFM-JS engine and Element programming API if anyone is interested. Just pop into the T2 Tile discord (linked below) and send a message!

If you made it this far, thank you again. It's a lot to digest and took me a while to connect many of the dots.

I've been wanting to put this all together for a while now, but to what end? Well, I guess part of me thinks there are folks like me who will be very intrigued by these ideas and want to explore them further as I have. If that might be you, I hope this offers enough getting-started material for you to begin the descent into the rabbit hole.

Here are some additional useful links to help your exploration:

Ever seen or done this?

It's the classic font-size hack, where instead of the default 1rem = 16px, the equation is forced to 1rem = 10px allowing for easier math and translation from px to rem font-sizes.

There is some debate and confusion over whether this is bad to do. Technically no: it doesn't negatively affect the user experience. Fonts can still scale with zoom.

As a deviation from web defaults though, it's arguably unnecessarily added system complexity that impacts DX over UX, which is not a super strong position to be taking.

But what's the underlying issue? Well, I think it's rooted in font sizes traditionally starting in pixels on the design side.

And so, I propose that it's a Design Smell, a metaphorical extension of Code Smell where code is a symptom of another development decision. In this case, that "other decision" is landing back a few steps in the design phase.

Teaching web designers how preferred web font size definitions work, especially as tools like Figma adopt them, would be a great way to tackle this issue at its root.

What other Design Smells might there be?

How media is handed over for development can be fraught with odor. Dev tools and lighthouse tests can easily point out that large non-web-optimized media is present. But beyond that, things like using a jpg or png over an svg just because there's a gradient background offers the chance to coach back into design-land that CSS is great at gradients and there's a better solution to improve both performance and quality of that design element.

Another category of design smells exist around responsive design. While there are many specific instances to call out:

All of these come down to not exploring the edge cases of responsive circumstances, especially those that throw in the wrench of real content.

I have to say, that if these make it unscathed into development, you'll be holding your nose all the way through. Ambiguous responsive design is especially important to tackle before development starts, which is why design and development collaboration is so important.

I think Design Smell can be a useful term, especially in bridging the developer-designer relationship. As the capabilities of the web, especially CSS, grow, it's imperative to maintain an open, two-way avenue for knowledge transfer. Just as front-end developers can learn to exercise design skills to fill in gaps and not get tripped up, web designers too will yield better UX design because of knowing how the web works.

Back when I built my current site in Eleventy, I talked about how to use petite-vue and Cloudflare KV to create a like button for your webpage. Look! There it is over on the bottom right of this page (sorry RSS folks), maybe you should click it to make sure it works!

To this day, that post is quite popular and holds up well if you want to follow along with the KV and edge function setup.

Recently, I used the same concept to track page reads on my site. What's a page read? Well, for me it's just that you've scrolled to the end of the page. This will let me audit, very generally, how many folks are engaging with my posts and getting to the end.

The new part of this setup was no longer creating something waiting for user interaction. Instead, I needed something to trigger when it came into view at the end of the page. While rolling your own IntersectionObserver isn't too painful, there was an even better solution at hand.

Astro's islands architecture treats your UI components as build-time rendered by default. When you want to make a client-side component interactive with JavaScript, you need to explicitly add a directive to it to tell Astro to hydrate it. One of the directives is client:visible which handles all the IntersectionObserver setup automatically.

So all I needed to do was build a Vue component that onMounted() pings my edge function read counter, and that's it! Here's a look at that Vue component:

The component is comprised of a hidden empty

And here is how it's used with the client:visible directive:

In my Cloudflare dashboard I can view the KV store to see my current counts.

There's nothing too ground-breaking here, but analytics platforms these days are often heavy and intrusive. On the flip side, server-based analytics have a terrible time distinguishing between bot and meat traffic. So I quite like this as a simple middle-ground solution that, thanks to Astro, was very easy to put in place.

Expectations are a massively core principle to my own being. I attribute a lot of my success in becoming a leader to the introspection and sharing of expectations. In recounting my one-on-one formula I talked a lot about setting and resetting them with your direct reports; doing so builds trust and provides clarity.

But well beyond being a tool to strengthen working relationships, constant self-reflection on expectations and alignment across business partners and project collaborators can increase productivity and the success of work.

"What should I expect?"

That's it. Form a habit of asking this question.

"What do you expect?"

Just as important as it is to exercise your explicit internal conversations around expectations, external discussions around what others think are essential to aligning on what needs to be done next. It allows us to measure the differences between multiple perspectives, and most importantly unify ideas and desired outcomes before pressured conflict forces it out.

Clarifying your own and others' expectations is a solid tactic to address upcoming unknowns and tackle work productively and confidently. And while you might not always fully reveal the fog of war ahead, it will give you tangible readiness to face things as they come, as surprising or unsurprising as they might be.

Early in my career, I remember watching the software and web industry shift from being functionally-focused to user-focused. It was a main driving reason why I decided to switch from a software engineering degree to one that incorporated web development and UX design. Today, functionality is often the baseline, and competitive advantage is pursued through the user experience lens.

There has been another shift in the last few years, though not as overtaking; more complementary. Developer Experience, or DX, is growing as yet another focus point for software to consider as a primary driver of adoption and platform longevity.

Here are my top features that I think drive productive developer experiences:

The experience to get up and running with anything is a make-or-break moment for new users. Too difficult and we'll "nope!" right out of there. Lesser-considered though, too magical or left unexplained, and the smarter users might also begin to build a case for being skeptical. Your happy path should be well-groomed, like an upkept hiking trail. It should have bridges in the rough spots and not wind to and fro too much.

What makes a good happy path?

Your docs need to be great. They need to be updated thoroughly as your product changes and should be split at minimum into three categories: use-cases, features and reference. Your use-cases show me how someone might use your entire product to accomplish a common use-case. Your features need to deep-dive into each special ability your tech has, and all the ways it can be configured and used. And your reference needs to give me an even closer, raw look at the exposed consumer API. What are the expected inputs and outputs of any given thing I'm working with?

I mentioned making optional features as opt-in as possible. Going hand-in-hand with that, features should feel like small steps. Being overwhelmed by the effort of enabling or configuring a feature is one of the biggest reasons developer tech can be abandoned. Small, easy steps lessen that load. I shouldn't have to do 15 steps to accomplish something, and even worse, if I get intimidated or change my mind on step 7, things shouldn't be in a broken state.

If you've focused on the prior two points you're probably in a good place. But the cherry on top is having great error messages. Letting me know at build or runtime what might be wrong will keep me in the development flow as much as possible. Don't make me hunt for bugs that are rooted in your own proprietary conventions.

Finally, zooming out a bit, I think it's important to track the mental model that your DX paints in developers' minds. One key factor in how that model takes shape is in naming features and conventions in your product. Names will elicit specific contextual connections, and so your product gains to get a leg-up on explaining features by leveraging common developer contexts. Bad names on the other hand do quite the opposite; potentially introducing confusion via mismatched contexts.

These are just a few stand-out features I find in a good developer experience. But specific focus on DX is fairly new, which will cause the baseline bar to be raised more and more as new techniques emerge. If you're building a product or service that developers use, it is critical that you adopt and invest in the DX focus.

Quick aside: I actually wrote this blog post, at least one by a similar title, 10 years ago. Going back and reading it, it didn't quite hit the mark of what this idea has meant to me since, so I thought I would give it another go.

To lay a quick contextual foundation here, I'm really going to be talking about process. Systems get lumped in here too. But broken down, systems are made up of smaller processes. And I mean all processes; from computer code to project management processes to baking a cake.

Building flexibility into any process can be incredibly valuable and important when needing to control the capabilities of the outcomes of that process. And in most cases that flexibility is tactically implemented as variable input.

But flexibility comes at the cost of added complexity. Maybe in software there is a much higher tolerance for allowing systems to be very flexible; especially when the complexity is handled entirely by the computer. However, when that complexity involves people, it quickly acts against the ease and efficiency of executing the process.

So here's the pay-off point: to pursue adding flexibility to any given process, you should also explicitly define what is inflexible; nail down the parts that don't add as much value by making them variable. Shrink the change and limit the complexity. Doing so will lead to much more balanced, manageable processes, where more focused thoughtfulness can go into the few variable inputs required. This will ultimately generate higher-quality, specialized outcomes without putting undue stress on your operations.

There are lots of different ways to be a great leader. So I want to be clear up-front that this is really what I have found works for me. If you're a budding manager that hasn't quite honed their own style, or just looking to try new things, maybe give some of the following a shot.

Also, there's nothing really specific to engineering in this; I think it's a format that any leader can implement.

The first thing I establish with my one-on-one meetings is that, as much as our team may grow close and comfortable working together – essential for highly productive, happy teams – our one-on-one format is the one place to be formal. That might sound cold or strange at first, but here's my reasoning:

The business exists. Its goal is to establish roles, that when fulfilled, make money. But in most cases, the specific folks fit into those roles are not critical to the primary goals of the company. Welcome to capitalism.

So being formal is my way of bringing that idea to the forefront of the conversation. I'm in a role of leading, which means I'm accountable for the production expected by the business of those roles under me. Let's take time to talk about how we're both caught up in that contract.

As I mentioned, I follow a very strict agenda. In a lot of cases most of it is scripted out. Again, I feel like this could be seen negatively, but having that script frees up your brain to think about the specific conversations those topics lead to and not about the overhead of running the meeting. The script is meant to prompt you both to find specific relevant topics to discuss.

First up, we talk about role expectations. I try to be a really hands-off, non-micromanaging manager. But in order to make that work, building up trust and communication with my team is essential. I can help to lay the framework for doing that through clear expectations.

In the meeting I'll run through my pre-defined expectations, I might say something like:

Here are my expectations as your leader:

Going over each item can feel like it's overkill over time, but I make a point to stick to it as each instance provides the opportunity to discuss any specific instances where these expectations were or weren't met.

We then flip the conversation. "What are your expectations of me?" Once established, they get worked into the script and I recite what I have interpreted them to be. Here I can ask for critical feedback: "Am I living up to these expectations for you? Do you have any you want to edit or add?"

There's a little overlap here from the previous section, as my expectations often align to roles. But this section is meant to focus more on how equitable the employer/employee relationship is at any given time. Even though I'm the manager, I try to remove myself mentally from being on one side or the other. Instead, being a liaison or mediator for that relationship.

Here are some conversation-starter questions for this section:

At this point, I like to cut away from the script a bit and try to come up with a specific question to hone in on. It might be something like:

Nothing too broad, just something to quickly solicit feedback on. On my side, individually asking the same question to multiple direct reports helps to track and call out any trends.

Back on track with the main agenda, we now want to take a look at any individual goals or learning plan items in place for that person. Reiterate what their goals are and ask about progress. If progress is stifled, talk about why. See if goals need to be adjusted and define smaller milestones and tasks for them to accomplish.

By this point, while there probably has been some good conversation, it's time to give the reins of the meeting over to them. "Is there anything that we didn't already cover that you want to talk through?"

Providing your folks a chance to completely lead the conversation without a specific topic is really important. I also find it helpful to reiterate that I'm always open and welcoming of critical feedback.

Lastly, recount any action items that came up in the meeting. Align on what they are and when they should be done by.

With that, the one-on-one is done. But a few final notes to make. If this is a new team, don't expect a super rich conversation; you're still establishing a connection with your team, so it's okay if it feels a bit robotic. To combat that, find opportunities to show your own vulnerability and empathy. I have found you really get what you give.

Double-down on the idea of getting meta with the conversation, encourage stepping into 3rd-person view of their role, your role and the business, it really helps keep things objective and not personal.

Finally, find the right cadence. For me, every one to two months seems good, but make sure you are still less-formally checking-in in-between; this isn't the only meeting you should be having with your folks regularly, just the most formal of them.

If you have tips on running great one-on-ones with your team, or have things you like that your leader does, I would love to hear them!

I had the not-so-new idea of attaching an audio companion to my blog. As someone who sort of wants to dip into podcasting (beyond the one I already tried), but doesn't quite have the time or drive to get something going right now, it seemed like a cool compromise.

I'm calling it blogcasting, because it seems right, and certainly it's not a term I invented, but as long as I don't google it, I can claim to have.

I went down a few avenues to get the blogcast up and running. First I thought I would use a podcasting platform to host it, and then, bonus, it would be a podcast too. Ultimately though, most podcast hosts are not free and it's a bigger process to add in all the metadata for a podcast episode just to get something published.

Thanks to friends in the ShopTalk Show d-d-d-discord though, I was able to figure out a simpler implementation.

First, I settled on a very quick recording process using audio hijack to capture the audio, and Adobe Audition to do a very quick listen-through and editing of pace and mistakes. So far each episode takes about 1.5x its length to edit, and that seems pretty good.

You need a place to host your .mp3 files. In some cases your blog might have a server that can do this. In my case, a static blog hosted on Cloudflare, I chose to create a Cloudflare R2 storage bucket to host my files.

Since I'm now using Astro, I was able to very quickly create a BlogcastPlayer.astro component that uses muxinc/media-chrome under the hood. It's a really fantastic web component library for doing quick custom video and audio players.

The BlogcastPlayer.astro component looks something like this:

Listen along to this post as you read, or subscribe to the blog

Given a url prop, the player renders itself. Not shown are some of the extra styles I applied to fix it to the bottom of the page, but hopefully you get the gist of it.

This is honestly the most surprising and cool part about this. I had no clue that all you need to do to add media to accompany a blog post feed is to add an tag pointing to the file for each .

It might look something like this:

Most RSS readers are happy to pick this up and display a playable interface.

What do you think? Is this an appealing idea? Have you tried it out on this post? I'd love to hear your feedback, whether it's just dropping a like in the lower right (sorry RSS folks), or replying to my tweet or toot sharing this post. I myself am looking forward to Blogcasts sweeping the nation!