Andrew Walpole's Blog

Previews Are Hard! Also, Web Mullets

andrew@andrewwalpole.com (Andrew Walpole) — Wed, 04 May 2022 00:00:00 GMT

Previews Are Hard! Also, Web Mullets

I love the Jamstack revolution that has been going on for the last few years. Statics sites, yes please! SSR, yes please! Headless CMS, let's freaking go! Netlify, Vercel, AWS Amplify, Cloudflare pages, tears, folks, tears. of. joy. But this soup of delicious tech, like all the others, has its souring points. The one I'm most particularly interested in calling out here is content previewing.

Living that agency life, most of the time we're just building websites for less technical folks to manage. Sure we're going to give them a great-looking, fast, functional website, but they also need to change that content, swap those images and relabel all the CTAs. Unfortunately, my findings are: Jamstack stacks have poor implementations of preview workflows, and in many cases, implement them as afterthoughts, if at all.

The Problem

The problem seems to be in the decoupled nature of the parts. It's nice that Jamstack makes it easy to pick and choose your CMS and your framework and your host almost fully independent of each other. The problem is that it likely takes at least two of those to work together non-trivially to achieve good previews. And, well, shoot. Now your stack is coupled, you're bought-in, on the hook, you've become... opinionated.

Opinions get things done, but they absolutely subdivide your target audience.

It's not the worst thing for you, lovely developer-reader-friend, but it seems like very few of these stack-players are actually willing to get opinionated themselves and work together to create that great previewing experience. Instead, they try to go after universalized solutions, which lead to so much hoop-jumping for us. I will call out Prismic though; I think they really gave it a go, but even their framework-specific preview SDKs have spun my head around a bit; they haven't quite cracked it.

The Solution We Desperately Need

Wordpress... sorta! The block editor, that thing freaking rules, except, well it runs on React and I like Vue. But that aside, clients love building pages with blocks and editing content in blocks. Even ACF blocks, which I use most, are a great experience: Content inputs on the right, instant previews on the left. But this all falls apart when you want to use Wordpress in a Jamstacky way. Your block content is just walled-off enough from the Wordpress API that I can't easily just query data into my component and instantly render it to you as a preview.

Chris Coyier tweeted it perfectly just a few weeks ago:

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Sure, I could do WordPress-as-content-API-only thing, but ughgk, I don't love it. It's twice the technical debt and doesn't really provide a best-of-both-worlds thing. <br><br>I just want a single product that is WordPress in the back and Astro in the front. <br><br>Ship it people.</p>— Chris Coyier (@chriscoyier) <a href="https://twitter.com/chriscoyier/status/1513593685925056514?ref_src=twsrc%5Etfw">April 11, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

Wordpress in the back and Astro in the front – seamless previews transitioning into beautiful static builds.

A metaphorical web mullet to stun the masses, if you will.

This is what we need.

P.S. 👀

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">okay :)</p>— fred (@FredKSchott) <a href="https://twitter.com/FredKSchott/status/1513593963457880066?ref_src=twsrc%5Etfw">April 11, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

Save us Fred!

First

andrew@andrewwalpole.com (Andrew Walpole) — Sat, 30 Apr 2022 00:00:00 GMT

First

Well, I did it; after two years and three scrapped site designs – and of course I'm not even that stoked on this one – the itch to blog has been growing, so here I've settled to make a go at it.

This site is built with eleventy, with a custom esbuild setup for the small bits of sass and javascript. It's hosted on Cloudflare Pages, which is a bit of a departure from my usual choice of vercel or netlify, but I've been really happy with Cloudflare workers, so I'm giving this a go as well!

What can you expect from this blog?

Well, probably just a decent bit of web-related punditry and maybe a bit of leadership stuff... Really whatever strikes my fancy I guess. My goal is to publish a healthy mix of useful tech-specific things along with my own views on the way the web development industry is moving, with some sprinkling in of random things I like. If that's your jam, welcome, feel free to like (over there ↘) and subscribe!

More specifically these topics have a high chance of showing up:

Web Development
Dev Stacks/Architecture
Serverless non-sense
Leading dev teams
Business strategy
Robust-first computation via living-systems
3D printing tips and processes

Living on the Edge Functions

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 03 May 2022 00:00:00 GMT

Living on the Edge Functions

Edge Functions are all a buzz at the moment. Netlify just got them, they're in beta over at Vercel, and Cloudflare has had them for a few years under the somewhat misleading name, Cloudflare Workers.

It's easy to confuse them with serverless functions, and in my mind, I think they are a type of serverless function. The main difference is in the name; edge functions run as close to the requestor as they can (on a distributed edge server), while serverless functions are deployed to a specific region where they run regardless of the initiator's origin.

Beyond that universal difference, the specific organizations offering edge functions may implement different runtimes and add a proprietary layer on top of their usage that is less consistent. Or said another way, edge functions and serverless functions could likely work exactly the same, but in an effort to provide a differentiated offering, edge functions end up being optimized for specific edge-efficient use-cases. Generally, that use-case is: Intercept a client request and DO STUFF before returning a response; where DO STUFF is a whole heaping world of possibilities.

Let's take a quick look at what Netlify, Vercel and Cloudflare offer, as well as some of the great use-cases you can explore with edge functions.

Netlify

Netlify's edge function solution comes in one surprising flavor – Deno runtime! As a sideline-cheerleader for Deno, I was pleasantly surprised to see that Netlify went this direction. While Deno could be a whole post on its own, don't be scared off; you can write JavaScript and TypeScript in Deno, plus get access to a very cool import system, which in comparison to npm, makes bringing in external resources a breeze.

No surprise, Netlify provides a pretty great DX for edge functions. You describe the routes that should run edge functions in your netlify.toml and declare the functions themselves in an edge-functions directory at the top level of your project. Netlify handles the rest within its continuous deployment pipeline.

Finally, it's worth noting that Netlify really leans into the pitch that even if you aren't directly using them, your favorite frameworks – Next.js, Nuxt.js, Eleventy, Astro, SvelteKit, Remix – can or are taking advantage of them for you by providing middleware that use edge functions to SSR content for clients blazingly fast.

Vercel

Unfortunately, at the moment there isn't too much to report here. Edge functions are in beta on Vercel and are only implemented for Next.js projects. However, as a fan and an avid user of Vercel serverless functions, I expect that as they do come up to speed with their competition, it will be a solid offering.

Cloudflare Workers

One nice thing (among many) about Cloudflare, is that even if you're hosting through another platform, as a DNS manager, you can use Cloudflare in conjunction with whatever your current setup is. So in most cases, unless you are deeply tied into another DNS management system, you can add this on to any site with minimal disruption. Once you have your domain using Coudflare you're ready to use their ~~edge functions~~, err, I mean Cloudflare workers.

Using Cloudflare workers is not bad, it's also not a one-click deploy, but I think that's just fine. You create workers on your account and you can either set up their Wrangler CLI tool to write and deploy workers, or you can use an online editor, which I have found to be a really great starting path, providing you a decent-enough editor along with side-by-side testing and debugging tools.

Edge Function Use-Cases

So what do you do with edge functions? Probably too many things to list, but we'll try anyway, which should help to also solidify the concept of them.

Remember, edge functions run after the client/user makes a request (that you have defined to intercept). The function has some sort of payload with the request information as well as what the response will be. Within the function is where the magic happens, you could do things like:

Check the request parameters, query a database, and apply the data into the response.
Check the country the request came from (both Netlify and Cloudflare provide GeoIP services) and return a redirection to a specific URL.
Increment a counter in a database (or better yet, Cloudflare KV which is a whole blog post in itself) to track page visits.
Add/modify a header value (great for Auth things).
Read/Write/Manage cookies.
Completely compile, render and return a page or component with injected data/content.
Inject some HTML or a JS script into the page.
Respond with some JSON like an API endpoint.
Enforce a block or allow-list.
Respond with an a/b test of content.
Respond with an image or other types of content.

You can see a bunch of these and more in action with Cloudflare workers here.

tl;dr

Edge functions are serverless functions, but since they're on the edge, you may want to use them for specific scenarios that make sense on the edge, like modifying the response of a request by some smallish amount before sending it back. They are playing a big role in allowing frameworks to do high-speed SSR and if you haven't tried them out yet, or haven't even stepped into the world of serverless, Netlify and Cloudflare have made getting started really easy.

Throw the dart

andrew@andrewwalpole.com (Andrew Walpole) — Thu, 05 May 2022 00:00:00 GMT

Throw the dart

You don’t get good at darts by holding on to a dart, analyzing it’s form, composition, weight, learning about its history, the dart production, packaging and distribution process, binge-watching hundreds and hundreds of dart-throwing videos on Youtube, showing the dart to friends and dart enthusiasts and philosophizing about how it works and how it will fly when it is thrown. Then, at the last possible second, when the game has started, when it counts, when it has to be good, when it can’t fail, you throw the dart.

All of that education and preparation you did may help a little, you might not miss the board. But I hope you agree with me and see that there is a much more efficient way to get better at darts; to compete when it counts.

Throw the dart. Early. Often. Again, and again and again.

What You've Done is What You'll Do

andrew@andrewwalpole.com (Andrew Walpole) — Mon, 09 May 2022 00:00:00 GMT

What You've Done is What You'll Do

I can't claim these words, but they've stuck with me from an old (2009 maybe?) Adobe MAX talk by Erik Natzke, and so I thought I might pass them forward here.

I love learning new things. Being a part of the web industry right now, it's essential to constantly be learning new things if you want to keep up with the latest and greatest. But there's a cost to focusing on that idea too much. Worrying about figuring out how to keep up can be a huge emotional drain, and with all the avenues there are to explore it's quite easy to burn-out on the burden of learning.

'What you've done is what you'll do' manifests for me in my daily life in two main ways:

Scoped Learning

First, it reminds me that when there is something new to learn, I can break it up into two major buckets: "Do I want to know how to do this?" or "Do I just want to know about this?"

The latter question carries a ton of utility while removing a lot of the burden that comes along with learning how to do something. If I can hear a business case from a client or even coming from my own ideas and think of a technology I may know about that fits the bill, that's all I need in that moment; the doing can come later if it needs to.

Most importantly, I find that explicitly setting this scope of learning for myself up-front provides a boost to my drive to dig-in, because the expectations are set; I know, generally, the size of the hill I'm about to climb and so I can prepare accordingly for the trek.

Power in Doing

Don't get me wrong, the last paragraph was all about NOT DOING if you don't have to, but I think closer to Erik's point in his talk, this idea is also all about leaning in extra on what you know how to do already.

When you have a hammer, everything looks like a nail, and that's ok!

You've put that extra learning time into what you do. You wield your craft. Be proud of it, and then find the places you can keep doing it. The whole generalist vs. specialist thing sort of rubs me the wrong way, because as a self-proclaimed web generalist, I find that I have a very specific set of skills: the things I actively do! And I think that's actually true of most folks.

If you ask me to build a site, I'll probably use Eleventy or Vue or just vanilla HTML/CSS/JS, I've done that. If you want to start an online store, I might push you over to Etsy, I've done that. If you need some generative art I might make it with P5.js or Processing, I've done that. Need an API? I'll build you one with serverless functions, I've done that. Want a custom 3D printed trophy, I'll design it in illustrator and fusion 360, slice it with Cura and print it on my Ender 3 Max printer, because I've done that.

Part of it is that, yes, I put in the time and got experience in doing these things, but the other important piece is that getting to that point also means I must have had a good experience, I must have liked it, at least somewhat, to the point that I can continue to come back to these skills as the core of what I do.

Sure, I'll learn to do more things in the future and I can continue to build out this list. But do I have to? I don't think so, as long as those skills remain relevant, I find it incredibly useful to remind myself that what I've done is what I'll do, and that's great.

Diverge, Converge, and Repeat

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 13 May 2022 00:00:00 GMT

Diverge, Converge, and Repeat

If I were to roll up the things I've learned into high-level concepts, I think one of them might be, mindset, defined as: the way you intentionally prepare for, and approach, a contextual period of time. What filters do you have at the ready? Are you prepared to be overtly emotional, or defensive or aggressive or curious or passive? Our reactional self, for sure, will have something to say as things happen, but I do believe there is utility in setting your own expectations going into any situation.

It's useful to take just a few minutes to think about a situation – it might be a meeting, or a place I'm going to – to think about what my mindset might need to be. What should I be prepared for, and how might I respond to those things?

There's a core practice in Design Thinking that is really all about mindset. If you're unfamiliar with Design Thinking in general, I can't recommend enough, Stephen Gates' 3-episode podcast series on his process of it. Even though I may not carry out the entire process on a regular basis, it is full of concepts that can be broken out into a lot of everyday tasks.

For this post, I want to focus in quickly on one of those concepts of having a divergent or convergent mindset.

Diverge,

When you first are looking to generate ideas or tap into creativity, you should put yourself in a divergent mindset. This means that the boundaries – your limits, constraints, tethers – are all not allowed to be a part of the session. You are able to place the problem in an open, safe space and examine it from all possible perspectives that you can think up. The goal is more to explore the landscape of the problem, and uncover many possible paths, even those that may dead-end, than it is to find the path.

Converge,

Separate from that divergent, blue-sky session, comes a time to be critical with all you've uncovered. Why won't these things work? What are the risks, efforts, technical debts to take on in this idea? convergent thinking is about focusing a broad blurry vision into a clearer picture. You see the wrinkles and cracks take shape, as well as the beauty and elegance of the ideas that end up being worthy of further effort.

and Repeat

Separating these two mindsets is invaluable. You may think you can do them together, but they are in direct opposition to each other, and will limit your ability to quickly explore new ideas and possibilities. If you're having this session with multiple people, it's also powerful to align on the expectations that everyone adopt this mindset, cutting through the mental red-tape that holds folks back from contributing.

Finally, repeat the process. Doing it once may work a bit, but you tend to see the the value in intentionally switching between these mindsets multiple times over many sessions. You will bring new insights to your diverging sessions that you uncovered when you last converged, and vice versa. As you hone in on a solution your sessions may get quicker and you may do less work in each mindset, but you will be left with a direction that you can confidently pursue.

What's Your Go-To Web Stack?

andrew@andrewwalpole.com (Andrew Walpole) — Mon, 16 May 2022 00:00:00 GMT

What's Your Go-To Web Stack?

One of the best parts of my job is figuring out what technologies a client's website should be built in. I love the challenge of it; there are so many different external variables to consider and every client has its own set of opportunities and constraints to align a solution to.

Out of doing that work, I've made it a habit to present the following question to folks, not as any sort of test – though it's one of my favorite interview questions – but much more so as wanting to fill a genuine curiosity I have.

What's your go-to web stack, right now?

Here's the set-up:

I need you to build me a website right away (of course)! Content on the site will have to be updated at least once a week, but for the most part, the structure won't change much or at all. I'd love to post a few short, simple blog posts every now and then and I have a contact form I'd like people to reach me through. It's all designed up, sorry, a templated theme won't do.

So what do you do? How do you build this site? What technologies will comprise your stack and workflow? Maybe most importantly, if you aren't quite sure, what else do you need to know?

My Go-To Web Stack

For the last year or so, Eleventy is most likely what I would reach for, though I'm equally familiar with either Vue + Vite or Nuxt. I'm at a place where I can get up and building very quickly with Eleventy, and I love that it's so easy to reach for plugins to add on features, but also introspect those plugins and know quickly that there isn't too much magic going on behind the scenes. I've also gotten accustomed to adding on Vite or esbuild as well to bundle JavaScript and SASS.

The toughest part would be satisfying the need to regularly update content and post blogs. While Eleventy is great for developers out of the box, not so much for the less tech-inclined. And even though previews are hard, I would likely reach for a headless CMS. I'm torn a bit here, I love Contentful, I used it for years and think it provides a great experience. But the pricing tiers are rough, they're not positioned for small professional sites that may exceed the free tier. My other option would be Prismic, which really does fit the bill. My only hesitancy there is that I've only played with it, and so I have trouble saying it's part of my go-to stack if I haven't gone-to it for real yet, but I do think I'm ready to reach for it.

As for hosting, probably Cloudflare pages, actually, as it has been a great experience with this site and I really love having so many site administration tools at my disposal. Though, it's just as much of a toss-up to also choose Netlify or Vercel. Netlify especially might win-out because of their easy forms options, but I wouldn't be afraid to custom-roll a simple contact form with a serverless function either.

tl;dr

I think it's fascinating to run through this exercise of figuring out what technologies you would actually pick to build a site right at this moment. It's a bit different from "what do you like?" or "what is ideal?" or "what's cool?" because it's much more about understanding where your current comfort zone in web development is, especially because what you've done is what you'll do. Over time, your answer will likely change, so it's also fun to see what sticks and for how long.

For me, at this moment, it's:

Eleventy
SASS and vanilla JS + petite-vue
esbuild
Prismic
Cloudflare Pages

The Fourth Language

andrew@andrewwalpole.com (Andrew Walpole) — Thu, 12 May 2022 00:00:00 GMT

The Fourth Language

The web, and more the browser as we know it today, has its three core technologies that allow us web developers to build web content: HTML, CSS and JavaScript. But what's next? What will the fourth language be? I know there's not much of a dialog to be had here on my blog, though I would love to hear your thoughts, perhaps via twitter. But here's what I think.

The fourth could be a language of state. There are countless flavors of state-keeping libraries rooted in JavaScript these days, and you might be prepared to argue that they can stay there. There are some really amazing implementations; Vue's reactivity library being incredibly impressive for how small and simple it is, and so many other examples that have made it easy to build robust and complex application workflows.

But there's an issue of interoperability.

As state libraries deeply ingrain themselves into JavaScript, they fracture the way we are meant to tie together HTML and CSS. Sometimes to the point that the implementor just kicks it all out the door: JavaScript all the things!

A reactive, state-keeping language is less about bringing new computer science to the web, and more about being a fourth member on the team; its own member, an ambassador of state, with its own opinions and integrations that could be equal across JavaScript, HTML and CSS. I think it would have an API that each other technology could lean into, to get, update, and react to state changes. When CSS changes the state, HTML reacts. When JavaScript changes the state, CSS and HTML react; all equally delegated to and updated from this new friend.

We already do these things, but the wires are left exposed and tangled, woven throughout these three existing layers, causing concession and work-around. A fourth language, a fourth layer, to abstract away the mess into a place that there is no mess at all – like a perfectly wired server rack – would remove a burden from both the existing tech we shoe-horn this functionality into and the developer who needs to manage and orchestrate it all (especially over time).

I think it could be JSON-ish, and even have some amount of compatibility there, but it would have some syntactic flair of its own for sure. An elegant exposure of models and relationships between data, not unlike what you see in XState. A way to focus solely on describing how your website or app collectively quantifies the inputs, outputs and triggered sequences of action and change that need to be known and possibly occur.

So that's what I think, and I have an appetite for it too. Sure, it's another thing but that's not a foreign concept for us web-folk. I'd much rather it be so extra super new that we can't ignore it; that we can't just throw it out and move on when we get bored. Instead, we can rally around it, and grow an entirely new community of folks that can help the rest of us through it, and we can clean up our code, and make room for a bunch of new crazy-yet-terrible innovation on the web.

Building a Like Button with Cloudflare Workers

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 06 May 2022 00:00:00 GMT

Building a Like Button with Cloudflare Workers

Previously, I touched lightly on Cloudflare Workers. In this post, we'll get deeper into the weeds and see how we can use them to build a small portable like button (exactly the one you see down in the bottom right of the page – sorry RSS folks).

What are Cloudflare Workers and Cloudflare KV?

Cloudflare workers are edge functions (serverless functions that run on an edge server, so they're super duper fast). They're just a bit of Javascript that can do anything Javascripty you want and return a value, like some json or even an entire webpage. By default, when you create one, you get a url that you can curl/fetch/browse-to that will trigger the function to run. You can also disable that url and point specific routes of your website to trigger the function when they are navigated to.

Cloudflare KV is a separate-but-related offering from Cloudflare. The KV stands for Key/Value, and it's essentially a flat, persistent, key/value store that Cloudflare can make available to your Cloudflare workers. This is sort of a big deal. There are some great serverless function offerings out there, but none make it quite so easy to bolt on a small, fast, synchronized database as Cloudflare has (Firebase comes close, but if you know of any others, I would love to hear about them).

Prerequisites

There's a small bit to get set up before you can use workers and KV:

You need a cloudflare account (it's free!)
The sign up process wil set you up with a free *.workers.dev sub-domain, which is where all of your worker urls will live, if you are using an existing Cloudflare account, you can set that up in the workers section of the dashboard.
Once you have that set up, you're ready to create and use workers – up to 100,000 runs per day for the free tier!
You can also follow the getting started guide, which will walk you through setting up the Workers CLI so you can develop and publish workers from your local machine. In this tutorial, we're skipping that and doing everything (even writing the code!) on the Cloudflare dashboard.

Create the worker

Under the workers tab of your Cloudflare account dashboard is where you can create workers and manage KV. In there, click the, Create a Service button. If you don't see that button, you may still need to set up your workers.dev sub-domain; follow the steps.

Give your service a name, I'll call mine, likes. The name dictates the function endpoint, so in this case it will be https://likes.walpolea.workers.dev. Then choose a starter, I'll go with the bare HTTP Handler which will provide a small boilerplate function to get going with. Hit Create Service and your worker is ready for use!

Create the KV

On the dashboard menu, under Workers, choose, KV and click the Create Namespace button. Give the namespace a name, in this case, likes and click, Add. You now have a KV store set up, you can use the dashboard to see the values and even update them manually if you need to.

Hook KV up to the Worker

One more important step to get KV working with your worker. Go into your Workers Overview, click the likes worker. In the detailed worker dashboard, go to Settings and then the Variables tab. Theres a section at the bottom called KV Namespace Bindings. You need to provide a variable name, LIKES and connect it to your likes KV Namespace.

Write the worker code

We're going to write the worker directly on Cloudflare. On the worker details dashboard you were just on, click the, Quick Edit button. I could tediously walk you through building the code line-by-line, but I would rather just show it all to you. If you have some base knowledge of serverless functions it should be pretty straight-forward. So here it is:

//this is the very first thing to run, a fetch event happened
//it calls handleRequest which needs to figure out how to
//respond back to the client
addEventListener("fetch", event => {
  event.respondWith(handleRequest(event.request))
});

async function handleRequest(request) {
  
  //This function will handle both getting (Get) and setting (Post) our likes
  //Use request.method to check which it is.
  switch(request.method) {

    //This is required because our preflight checks
    //need cors enabled
    case "OPTIONS":
      return responseJSON({ok: "OK"});
    break;

    //This is where we look up and return the likes value
    //based on the key (title) passed in as a url param
    case "GET":

      const { search } = new URL(request.url);
      const params = new URLSearchParams(search);

      if( params.has('title') ) {
        const title = params.get('title');
        let likes = await getLikes(title); //see below
        likes = likes ? likes : 0; //if it's null, it's 0

        return responseJSON({title, likes});
      }

    break;

    //This is where we increment the number of likes
    //based on the key (title) which is passed in as json data
    case "POST":

      const { title } = await request.json();
      let likes = await incrementLikes(title); //see below

      return responseJSON({ title, likes });
      
    break;
  }

  //a catch-all response if something weird happens
  return responseJSON({error:"Something went wrong"});
}

//returns a json response object with data as the payload
function responseJSON( data ) {
  return new Response(JSON.stringify(data),{

    //this is the secret to enableing cors
    //feel free to set the origin to a value that you trust
    const corsHeaders = {
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Headers': '*',
      'Access-Control-Allow-Methods': 'GET,HEAD,POST,OPTIONS',
    };

    headers: {
      ...corsHeaders,
      'content-type': 'application/json;charset=UTF-8',
    },
  });
}

//This function retrieves the number of likes
//in the KV based on the key (title)
async function getLikes( title ) {
  //get the value from KV
  const likes = parseInt( await LIKES.get(title, { type: "text"}));
  return likes;
}

//This function increments the number of likes
//in the KV based on the key (title)
async function incrementLikes( title ) {
  let likes = await getLikes(title);
  
  if( likes ) { //does this have a value, or is it null?
    likes++;
  } else { //the first time it's liked set it to 1
    likes = 1;
  }

  //update the value in KV
  await LIKES.put( title, likes.toString() );

  return likes;
}

The worker is set up to handle two types of requests:

GET with a ?title=SOME-KEY parameter, which will return the number of likes stored in that key.
and POST with a json payload of { title: 'SOME-KEY' } which will increment the number of likes at that key.

You absolutely could split these out into two separate workers, but this seemed easier to show off. If you get stuck, I have to shoutout the Cloudflare docs, they are great and have a large variety of examples that show you exactly what code you need.

Hooking up the front-end

Once again, I'm opting to keep it short here and just show you. You can pretty easily start using your new likes API with a couple of fetch commands. Here's a pen showing the like button in action:

<p class="codepen" data-height="580" data-default-tab="result" data-slug-hash="QWQbgjV" data-user="walpolea" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/QWQbgjV"> Petite-vue Like Button powered by Cloudflare Workers and KV</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

The secret sauce is really in these two functions that hit the worker we built:

const endpoint = 'https://likes.walpolea.workers.dev/';

async function loadLikes( title ) {
  return (await ( await fetch(`${endpoint}?title=${title}`)).json()).likes;
}

async function postLike( title ) {
  if( !this.likeAdded ) {
    const response = await ( await fetch(endpoint, {
      method: 'POST',
      headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({title})
    })).json();

    this.likeAdded = true;
    return response.likes;
  }
}

Wrap-up

If you made it this far, whew, thanks for joining me on this journey. Feel free to actually like this post down in the bottom right (sorry RSS folks). I hope you can see how easy and powerful Cloudflare workers and KV are. You could use them in so many ways beyond this simple example.

Stop Leading Zeros with Leximited Notation

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 10 May 2022 00:00:00 GMT

Stop Leading Zeros with Leximited Notation

Have you ever started a content series of some kind – maybe videos, music tracks, book chapters, blog posts or podcast episodes – where you want the episode number to be a part of the title, and so you just start naming them:

1. Introduction
2. The thing after the introduction
3. We're well beyond the intro now
.
.
.
10. Quite a milestone
11. It goes to to eleven

Have you seen the problem yet? You can sort numbers easy-enough, sure:

[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21].sort()

OUTPUT: [1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20, 21, 3, 4, 5, 6, 7, 8, 9]

Whoops! Oh yeah, it's JavaScript, you can sort numbers ~~easy-enough~~, sure:

[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21].sort( (a,b) => a - b )

OUTPUT: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21]

As you saw in the first example, on the default Array.sort(), even numerical values in JavaScript undergo an alphabetical sort, and it's no different when those numbers are strings. It's even harder as part of a title to cook-up a function that is going to both parse out the number from many characters and attempt to sort it correctly. Beyond that, our content lives in databases and across platforms, and so the issue gets worse as you may not even be in control of the sort algorithm.

Did you know that the non-numerical ordering seen above has a name? It's lexicographical ordering, or lexical order. Remember that now!

<br>

Enter: Leading Zeros

I'll be brief here, because, spoiler alert, this is not the answer I'm recommending. You can trade that sorting issue for another. You can lead the numbers with zeros. From an alphabetical perspective, your sorting will now check out:

['001', '002', '003', ... '010', '011'].sort();

OUTPUT: ['001', '002', '003', ... '010', '011']

But do you see the issue you traded in for? Up front, you need to commit to a number of leading zeros, and as soon as you hit a number that extends beyond the bounds of your zeros, you're right back to the original sorting mess.

A new challenger approaches: Leximited Notation

Dave Ackley came up with a different style of numerical notation that solves both issues. A notation that when sorted alphabetically or numerically maintains the same order: Leximited Notation.

It's pretty easy to learn, kind of like pig-latin as a kid, it's a bit odd at first, but then you get the hang of it quickly as you go. Here's how it works:

You prepend the number's character length to the number itself.
That's it! Let's take a look at some examples:

4 has a character length of 1, so in Leximited notation it's: 14 The length is prepended to the number itself.

Another: 37 has a character length of 2, so in Leximited notation it's: 237

Let's try counting!

0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, ... 99, 100, 101 in Leximited format would be: 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 210, 211, 212, 213, ... 299, 3100, 3101

The numbers are also self-delimiting which means if you parse a string with leximited numbers, you can use the first value to know how many character spaces to parse out of the string to get the entire number. So, to complete the "Ahhhhhh, I get it!" moment, the name comes from:

Lexicographically Delimited Notation!

Ahhhhhh, I get it!

tl;dr

Leximited Notation solves an annoying issue where numbers as strings, especially in titles of things, lexicographically sort differently from numerical sorting. You can lead those numbers with zeros, but that's both ugly and flawed. Leximited notation on the other hand is easy: You just prepend the number's character length to the number itself.

You can read all the juicy details on Leximited Notation or if you want to use it in code, I put together a simple JavaScript encoder/decoder on github.

Work is a Place to Help People

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 20 May 2022 00:00:00 GMT

Work is a Place to Help People

The angle at which you approach all things is important. That's certainly one of my big recurring threads. It's a broad enough idea that it shows up all over the place, "look on the bright side," "the glass is half-full," "take a walk in their shoes;" all of these notions are concerned about the way we interpret, and then react to, the world in front of us.

I like to carry this idea with me as often as I can. One of those places I carry it to is my work. I can't really say when or where or from who the idea came from, but at some point in my career – I think around the time I started leading people – I made a fundamental shift in how I perceive work.

Work used to be a place to contribute meaningfully to a business, and in return be provided a snug-fitting piece of the life-puzzle. It certainly isn't not that, just as the glass may also actually be half-empty. But I shifted to an idea that has really made how I approach work a lot more fulfilling.

Work, to me now, is a place to help people. I'm not just talking about what your company does for society, though certainly, many businesses are in the business of helping people at all sorts of levels, and that's not to be overlooked. Really though, I'm mostly talking about your co-workers. You're plopped into the lives of these people; a bunch of would-be strangers, connected for five days a week, many hours a day:

Help them.

Because, why not? Be helpful. Adopt a helping attitude. You don't have to be all sunshine and roses all the time, certainly therapists aren't and they help people, sometimes in the biggest ways. You have a job to do, sure, do that, but fight for the right to have working-day capacity to help the people around you, it's important.

"What do you need from me?"

"What are your biggest work worries?"

"What's the hardest thing about working here?"

"Is there anything I can do to help you?"

This attitude, perception, mindset, these questions, are some of the most important to me as a leader and as a contributor at work. Sometimes work is stressful and busy and hard for me too, and maybe I'm less helpful then; hopefully someone offers me help, we all could use some sometimes.

Even the business strategy side of me likes this idea of helping people. It's pretty dang rock-solid. You will shape the working culture, your leaders will notice, people will like that you're helpful, folks will follow your lead, you will leave a more-than-usual impression on their lives, you will feel more fulfilled helping people than you will doing your day-to-day job. And I believe you can count on this idea, doesn't matter if you're a part-time fry cook, or the CTO of a big tech company, or anything in-between. People want to work in a place where people are helpful. So do that, that's the work.

Do it for Context

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 31 May 2022 00:00:00 GMT

Do it for Context

In 2019 I made a ten episode podcast series called Code Snippet. The idea of doing a podcast had been rattling around in my brain for many years prior, but I just didn't have the ingredients that pushed me to take action on it. A few lukewarm ideas, no one to co-host with, mediocre equipment. But those were just excuses, not real reasons why I couldn't make a podcast. Finally, the thing that got me to do it was this simple idea:

Do it for context.

Context informs the shape of the lens with which we perceive things; it is the key to understanding with confidence.

I had no further expectations other than to learn how to make a podcast, and in hindsight, this was an amazingly wonderful reason to get started.

How do I publish a podcast?
Do I need a script?
How do I come up with topics?
How should episodes be structured?
Do I even sound good?
How much editing is involved?
Will people listen?
What else am I missing?

All of these things had to be answered in a practical manner, so instead of leaving it to theoretical punditry to solve each question, the solutions had to be accessible, and easy enough to fit into a reasonable amount of effort. On top of that, I had chosen to ignore two issues that had previously held me back:

I dislike most podcasts with a single host
and mouth-blogging code is awkward and hard to follow along with.

Since it was just me, and the topic I had chosen had exactly these two characteristics, I plowed ahead in spite of my extreme hesitation. And I did it! I used anchor.fm to do the heavy lifting for publishing my podcast, Adobe Audition for editing, learned that I really need to work on my umms and uhhs, but otherwise, I gained an entirely new outlook on what making podcasts was all about.

In the end, I decided that my goal was accomplished and the content wasn't worth keeping going. But I got a more-than-expected amount of listens and gained a wealth of knowledge and understanding.

And so, the larger takeaway for me was really that some things are just worth doing for the experience of it; for the understanding of the little details that can easily go unseen until you're in the thick of it. So the next time you're unsure about getting started, or allowing excuses to stop you, go into it with a simple goal: To gain understanding; for context.

Accessibility is Hard and Important

andrew@andrewwalpole.com (Andrew Walpole) — Thu, 19 May 2022 00:00:00 GMT

Accessibility is Hard and Important

Were you aware that today, May 19th, is Global Accessibility Awareness Day? How do you feel about that?

For a lot of web developers, including myself, the feeling can often be somewhere along the spectrum of shame and despondency. Why? Because Accessibility is hard and important.

If you feel this way, you're not alone. We have to acknowledge these feelings, face them head on.

It's Important

We feel shame because it's important to us. We care, and that's a good starting point. I feel ashamed when I write inaccessible HTML because there might be someone out there who I'm frustrating, or letting down because they can't access the content the same way a non-disabled person might.

It's not comfortable, but I'm telling you here and now that it's important enough to not run away from. Embrace the discomfort, embrace the shame, take a step in a better direction. Even if it's two steps forward and one step back, it's important to keep at it.

It's hard

Writing accessible HTML is hard for a bunch of reasons, I won't dive deep, but I will say that I think the biggest reasons are:

As seasoned developers, we're too prideful to admit and/or unwilling to be told that the skills we've worked so hard to hone in this industry are no longer good enough.
Curricula for new-comers to the industry is not adapting quick enough to address the accessibility missteps in our web development culture.
There is not enough accountability enforced at the top levels of for-profit companies to allow accessibility a proper seat at the operational table.

Some of those are big things. Sure let's keep an eye on them, but accessibility is hard, let's now move on from that idea, it's something to overcome, not an excuse to hold you back. Figure out your next step. What HTML did you write this week? Go open it up and take a look, I'll wait...

Is it written semantically? Are you applying WAI-ARIA standards? Is the site navigable via the keyboard? It's a lot, I get it, those aren't even all of the questions to ask, but pick one, and get to work, it's hard and important.

I'll be right there with you, a self-proclaimed expert, a seasoned web developer, learning a bunch of new things, unlearning a bunch of bad habits. Let's do it, it's hard and important.

Take a step

Not sure where to go next? Check out these resources I picked out that distill down some of the focus areas. Pick one and just start reading.

Accessibility Developer Guide - especially check out the examples section!
Accessibility Cheatsheet
WAI-ARIA Cheatsheet
W3C Accessibility Checklist
W3C WAI-ARIA Authoring Practices

Do Hard Things Again

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 14 Jun 2022 00:00:00 GMT

Do Hard Things Again

One of my longer-lived side projects has been mfm.rocks. And while the explanation for what's going on there deserves its own post, let's save that for another day.

I was recently doing some development on what is now the 2.0 version of the platform there, and for a bit I had been putting off reimplementing a particular element called SwapWorm, that I severely struggled through putting together on version 1.0.

Scared isn't quite the the right feeling I had about it; perhaps dread is slightly more fitting. I vividly remember fighting nasty bugs with SwapWorm for weeks, unsure why it wasn't quite doing what I needed it to do. Ultimately, I did find the issue and conquer the bugs, and it felt really great to finally overcome the challenge.

Well, I dove in on it a few days ago, and what a different experience it was. SwapWorm 2.0 came together in an hour or two, and sure there were bugs to work through, but nothing like it had been before. I was left a bit stunned. The code flowed, it all seemed so much more simple, I had clarity for the task at hand, and so much more experience programming in this type of environment since the first go-around.

And so, that's this post's message. It's great to tackle a hard problem and overcome it. But also make a point to tackle the hard problems again, especially the ones that really stick in your mind. I think you'll find, as I did, that it will be an entirely new experience that can show you how much you've progressed and reward you with a new kind of satisfaction.

Escape Hatches

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 17 Jun 2022 00:00:00 GMT

Escape Hatches

In web development, we rely on a lot of 3rd party systems when it comes to the practical building of websites and apps. Your stack is a conglomeration of important decisions. As someone responsible for making those decisions, the choice often comes down to:

What do I get, and what do I give up?

Each framework, technology, or system gives you something – proprietary features, enhanced development experiences, hyper-specific workflows; essentially abstractions and shortcuts to getting the work you need to do done quicker and easier. You're buying-in to system productivity.

At the same time, all of those abstractions force you into a specific set of constraints. Some systems only integrate well with particular other systems. Others, may only solve for specific use-cases on top of a general process, cutting down on flexibility (or maybe it makes you feel better to call this complexity). Wordpress, as a classic example, has features that require specific technologies to sit around it, dictating the full stack – PHP, MySQL, Apache/nginx – but in return you get quick entry into building front-end pages, managing content, and a whole host of functions that tackle non-trivial common web-based situations.

Anyway, not to belabor the point:

Abstractions have trade-offs that require careful consideration.

What I really want to say is, maybe they don't always have to. Certainly, some levels of the stack would have a harder time than others at this, but providing escape hatches to eject out of the abstraction, down into the underlying technology, can do wonders for a product's value. As an architect, I have learned to put heavy weight on technologies that provide both the happy-path as well as the ability to deviate when critical opportunities or edge-cases arise.

A great example of this is Vite. I have to think that a part of its popularity is not just the happy-path it provides, but also the ability to exit down into both the raw rollup and esbuild configurations when you need to; a feature I've already used more than a handful of times in production systems.

Why don't more companies provide escape hatches?

I think it's two things:

There is a common mindset that the happy-path, your product experience, defines your product, and there just isn't enough internal perception to look beyond those walls. It's rarely questioned, and perhaps when it is, it's hard to argue away resources from focusing on bringing direct value to your offering.
Related, I think it's also common to think that if you expose the escape hatch, you also need to start paving the road out there too. It becomes hard to let go, it may even feel like if a whole portion of the experience you provide has no support, you're letting your users down in some way.

I think these reasons are both short-sighted, and are mostly a product of not considering a different audience: the folks that take on the debt of your product. I don't care if the escape hatch leads to treacherous territory, I agree to the terms and welcome the ability to not be hamstrung when executing on my very specific business needs.

So, if you have a hand in building your product, take a moment to consider the escape hatch; a way to leverage the features you're already building on top of, and a way to provide welcomed value to those who seek to push the limits of your happy-path.

Build Momentum for the Next Thing

andrew@andrewwalpole.com (Andrew Walpole) — Wed, 13 Jul 2022 00:00:00 GMT

Build Momentum for the Next Thing

It's very easy to get stuck in a mindset of worrying about whether what you are doing will be successful or a failure. It makes a lot of sense, because often how we get to perceive the progress of others is through their milestones (the things deemed successful or failures), and not their full nuanced progression.

My take though, is that success and failure are only by-products of a greater trait that is often overlooked; momentum!

It's always in the last place you look

It's a groaner for sure, but I've always thought it interesting how a silly quip can be so truth-rooted. I think the same goes for momentum:

Doing something always leads to the next thing

Meaning, just get started, do something, start the wheels turning. It's advice you hear again and again, it's advice I still often need to hear, but I will say that it's also a core principle that, when I am able to keep mindful of, has been an invaluable notion in all aspects of my life.

Big, hard goals and tasks take momentum, and so that's the punch-line here, focus on the momentum, focus on the getting-going. Step, then step again, and eventually, as winding of a path it may end up being you will get there. But in contrast, stagnation over time can stick you in the mud, and the advice there is, acknowledge the mud, understand that it will be a slog to getting-going, and try not to let it discourage you and stagnate you more.

We Need Context Management Systems

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 18 Nov 2022 00:00:00 GMT

We Need Context Management Systems

The problem with headless content management systems is that they don't cleanly account for the context of content to always be defined in a proper place.

Take a headless CMS with content representing a restaurant menu. In that instance, the content can be modeled in a way that is very easy to manage without assigning context to it. A very clean separation where content manager can happily keep up the data while the front end assumes the role of applying that content into its final context.

However, take a homepage, comprised of components (or blocks or modules). Here we have the content – the words and media on the page – as well as a specific context – the order and layout decisions that mold content into a consumable digital experience.

Just ordering the list of components on the screen is applying a hierarchical context to the page. And then each component itself is often riddled with specific context choices. A hero: maybe the sizing and position of the heading text relative to a background image laid underneath. A grid of product cards might also give you control over the amount of columns or choosing a special layout for the first item to take on.

Abandoning a hard-lined rule that the CMS contains content and website code applies context comes with many trade-offs and implications.

Mixing content and context can be good

The content manager now wields more control over the website: this can lead to better upkeep and longevity in the utility of the site.
It can make business sense: the previously mentioned longevity is attributed to a more cost-effective management of a site, as well as being able to streamline experiential changes to match the evolving goals of the business.
Deciding on context first, when your content is still taking shape, can help solidify your content choices given the context limitations.

But tight coupling leads to a lot of bad

Those benefits trade-off with things like a much heavier up-front cost to develop contextual flexibility into the site.

Also tying large amounts of context into a headless CMS erodes away a major benefit of headless in the first place: your contextual content now becomes specifically dependent on your component API, making it much harder to move away from that exact front-end implementation.

Without a clear line established, the decision for where every contextual variant in a component now becomes a discussion: How much configuration is appropriate for this component? Where will this get configured, and how? What's the experience of setting, evaluating and committing to contextual configurations?

The answering of these questions equates to significant time and effort for building a website. Furthermore, the decisions are often arbitrary without an underlying rule to strengthen them. This leaves a fragile barrier that invites continuous debate and last-minute changes as or after a system is built.

It's hard to separate content and context

All that said, it might seem simple: stop mixing context and content! But that's actually hard. Context and content inform each other. As frustrating as it may be on the development side to manage a control panel of contextual inputs, it's also maddening for a content creator to build what they need to without a visual guide of what the end experience will be.

But it can be done

I think there are two solutions to lay out here:

Consider context strategically.

The first is taking on strategic consideration of the technical implementation of handling context as part of defining the project's scope. Become conscious of where contextual application sits in the thing you're building.

If more than "no context" will live at the CMS layer, decide up-front a clear sense of how much or how little context needs to be configurable. Where you land on this scale from little to most will ripple through budget, timeline and architecture.

We need Context Management Systems

Second, I think there's a larger opportunity for technology to step in and formalize context further as a major step in making the web. This is the Context Management System. Create a separate space, that lives decoupled from content and code and streamlines the ability to marry content with an experiential context it is intended to be presented in. But why? That seems like a lot of added complexity!

Yes, it is more architecture and may not apply to smaller systems that can work out an agreed-upon shared custody of context. But I do firmly believe that the cleaner delineation of context is extremely valuable:

Content managers can focus on content management and dial way back on the required technical proprietary understanding of system configuration so often thrown onto them.
In tandem, the effort spent by the development team to customize the context configuration experience, which is driven by the specific technical expertise of an individual or team of content managers, can be greatly reduced.
A new role, context manager is born. And maybe this still ends up falling on the content manager, or a developer, or maybe more strategically assigned to a designer. Whether it increases headcount or not, being able to assign this role specifically unattached to also managing content or also maintaining codebase is massively valuable.
A context management system can focus on shaping content into an explicit experience, but also many explicit experiences using the same content, thus re-establishing the whole point of moving into a headless CMS.

What does a Context Management System look like?

Managing context already exists across many platforms. The Wordpress Block Editor is a great example, it marries content and context management in a pretty good way. Some headless CMS products also provide various strategies to hook into your front-end code creating sort of an alternative path to the content creation experience. These are fine, and definitely fall under the bucket of strategic context management, but they aren't quite what I'm proposing here.

A context management system is one that sits much more firmly between the CMS and the final end-point. It takes on all of the deep ties to the front-end experience, but provides an interface that does not require intimate knowledge of code.

It can still provide an environment to experiment with context before content is finalized, but also brings UX design back into the conversation long after a web design has been finalized and approved. Where the maintenance phase of a website often consists of either: just change the content, or develop a new feature, with little in-between. Configuration at the contextual layer allows you to keep the content but change the experience. With having implemented a design system of components, this now becomes a massively useful tool to experiment with and apply that design system in an agile manner.

More technically, a Context Management System might have these features:

A way to visualize multiple contexts at once at a high level.
A way to apply content into a context (of course).
A way to map content fields to possible contextual destinations within components.
A way to transform content to fit certain contexts.

Separating context and content is worth considering

Context is worth considering, separately from content and the front-end implementation. Especially in the case of working with design systems, your context options are defined up-front and fit this idea quite well. Just as content evolves, the design and experience with which it is conveyed should evolve too, sometimes separately from the message. I think we need tools that specifically focus on this capability that also allow for autonomy around developing new features and content. Context Management Systems, and Context Managers could be that next focused key that help large digital systems work effectively over a longer lifespan.

Consider Astro over WordPress for your Brand's Website

andrew@andrewwalpole.com (Andrew Walpole) — Sun, 29 Jan 2023 00:00:00 GMT

Consider Astro over WordPress for your Brand's Website

I've spent the last handful of years building lots of websites for company brands big and small. As the lead architect and stack decision-maker for those projects, I've come to one major conclusion: WordPress is great if you get it right, but if you get it right, it's quite expensive.

How is WordPress so expensive?

You might be thinking, "But WordPress is free!"

Sure, the software and often some of the most critical plugins and themes are free or even quite affordable. If your content is your main focus for your new site, go ahead and grab a nice theme and have fun. I'm specifically talking about you, dear future-someone's-client, about your future-new custom website that showcases your brand and products/services, setting your business apart from your competition.

WordPress ends up being expensive in three ways:

Development: Getting it right means building a robust, highly-composable set of componentry to fit your brand. This can be a large up-front investment into the development of your site that will help fight against Digital Entropy.
Maintenance: Someone needs to learn and know how to keep your site humming, both on the technical back-end and on the content-focused front-end.
Platform Dependence: WordPress is a great CMS, but some of the shortcuts that make things easy sacrifice separation of concerns. And so while content is manageable it is often tightly coupled to context, and thus as your site's content grows so does your dependence on WordPress and your specific theme. You will invest more in evolving it and keeping it going rather than having the option to clearly pivot as your business might demand.

Astro is a great WordPress alternative

There are lots of alternative technologies to build your website in these days. Some are entire platforms that offer as much as WordPress might, often with the same issues listed above. Some are more rigid, trading in customizability for simplicity. And some are a bit more barebones, where it takes a much more technical hand to pieces together functionalities to cover all the facets of building and managing a website.

I'm here to recommend Astro. Astro lets you build static or server-rendered websites. It's specifically built to handle major front-end frameworks developers like to build sites in and provides a developer experience that keeps dev focused on building the site itself and not just the inter-workings of it.

There are four main reasons I think Astro is worth a long look:

You can get a custom site built, and while it may not be cheaper, front-end development can be done very efficiently and most of that cost will go into bringing the site to life and not the underlying stack.
Coupling Astro with a headless CMS is really easy, but also not required. This could let you take things in phases, starting without a CMS and then quickly integrating one as content is needed to be managed quickly. This also solves the separation of concerns issue mentioned above. A headless CMS provides a clear opportunity to build your content in a way that is reusable even as your business needs require you to make drastic changes to your website.
Continuing off of the last point, Astro's ability to adapt to many popular web frameworks also puts you in a prime position to grow into a Design System of componentry. Even building new websites, or adjacent campaign sites with the same underlying Astro stack would be easy to do.
Fighting digital entropy is, in most cases, not worth it. Instead, embrace it. Websites are more effective as they closely align to your business. But business evolves, knocking that synchronicity out of step. To remain highly effective, redoing some or all of your website every few years is a normal thing these days, and Astro makes that easy.
Lastly, what sets Astro apart from all the other WordPress alternatives? For me, it's their server-rendering and hybrid-rendering offering. Astro is the best of static site generation: fast, performant sites and the best of server-rendered sites: dynamic, realtime content and functionality. They've cracked a long-avoided nut that opens up a huge amount of potential for building great sites.

WordPress is still a contender, but keep an open mind

If you have the budget and the need to manage a site very deeply and often with non-technical folks, I think WordPress is really hard to look away from. The block editor and the experience you can have in building and maintaining sites with the right componentry is great.

But if those things aren't all true, I encourage you to take a look at Astro. Even as young of a framework that it is, it has the capabilities you need to build a beautiful, functional and scalable site.

The New Astro Content Collections are Great

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 10 Feb 2023 12:00:00 GMT

The New Astro Content Collections are Great

It's official, I think I'm an Astro fanboy.

If you're here, you might notice the site has been spruced up a bit, and that's because I just spent the last few evenings moving my entire site over to the newly landed Astro 2.0. It was a joy to build. And while I quite loved my old Eleventy setup too, I'm glad I made the move.

But I'm not ready to gush about all things Astro yet, right now I just want to talk about a specific new feature: Content Collections.

Content collections are a clever and simple file-based CMS

The way Content Collections work in Astro is you have a directory called content/ in your project src/. In there, you create more directories, one for each content-type (or content collection) you want to manage. Within those content-type buckets you can put markdown or MDX files. The classic use-case is for a blog, like this one!

With metadata in the frontmatter and the content in the body, your markdown files act as individual content collection entries. The file-based nature of it is extremely robust, and I love that it's fully separated from the context in which the content will be placed.

In my case, this site currently has three Content Collections: blog/, work/, and site/. Each representing different content pieces that I may want to query for and place across my site.

Using Content Collections is easy

There are two main ways to get content from Content Collections in Astro:

You can query content by its file slug with getEntryBySlug()
Or query an entire collection using getCollection()

Querying by slug:

In my site/ content collection I only have an about.md file for now. But as I build out sections and pages with content, I can add new files to the collection to pull out and place into areas of my site. It's a great use-case to query the content by slug because I'll likely know exactly which single entry I'll want to put in a specific place.

In my components/ directory I have a helper component called SiteContent.astro to make it easy:

---
import { getEntryBySlug } from 'astro:content';

const { slug } = Astro.props;
const entry = await getEntryBySlug('site', slug);
const { Content } = await entry.render();
---

<Content />

This component imports getEntryBySlug() and calls it using a passed-in slug prop to query for a specific entry in my site content collection. Calling render() on the retrieved entry returns a Content component that can be used in the component body to render the markdown of the entry. If you needed to grab any of the frontmatter metadata for the entry, you can find all of that in the entry.data object.

Now in my index.astro I can just add a simple <SiteContent slug="about" /> to render my about.md content.

Querying multiple entries:

Getting multiple entries is not much harder. Creating the listing for my blog page looks a little like this:

---
import CollectionListItem from './CollectionListItem.astro';
import { getCollection } from 'astro:content';

const {collection = 'blog'} = Astro.props

const allPosts = await getCollection(collection);

const { limit = Infinity, filter = ['published'], interactive = false} = Astro.props;
const filteredLimitedOrderedPosts = allPosts.reverse().filter(post => post.data.tags?.some( tag => filter.includes(tag) ) ).slice(0, limit);
---

{ allPosts.map( post => <CollectionListItem post={post} /> }

Again, given a passed-in collection prop, we can call getCollection(collection) to retrieve all of the entries as an array. From there it's a matter of massaging the array with features like sorting, filtering and limiting before sending them off to be rendered via another <CollectionItem /> component.

And there's more!

I didn't touch on it here, but Content Collections have another great feature: a full schema definition and checking system that keeps your content conforming to the required metadata you need to keep your site humming along properly.

All-in-all, I'm really enjoying Astro as a site builder. It's fast and intuitive, and if the slickness of Content Collections is any sign, I can't wait for this framework to continue to grow and mature.

If you'd like to see more of how I rebuilt this site in Astro, you can have a peek at the source code over on GitHub: https://github.com/walpolea/andrewwalpole.com.

Sprinkling Interaction with Petite-Vue

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 17 May 2022 00:00:00 GMT

Sprinkling Interaction with Petite-Vue

How do you sprinkle on a little bit of interactivity to a website? For many of us, jQuery was the definitive answer; from simple to complex, jQuery fit the bill for a long time. With many of those core DOM APIs getting back-filled into vanilla JavaScript, we have long-since moved away from jQuery.

But even years later, I can't help but still see a gap left in its wake.

The Gap

Vanilla JS is better than ever, don't get me wrong, but the work to get things hooked-up tends to inflate pretty quickly as your features grow. What you thought would be a sprinkling turns into a dousing. It's too easy to step too far and find yourself nearly writing your own framework.

On the other side, many of us have gone full hog-wild into a framework. React, Svelte, or Vue are great places to have all the interactivity you want at your finger-tips. But with them, comes an almost entirely new workflow to creating a website than just standing up a few .html, .css, and .js files.

So that's the gap: Vanilla JS is not structured enough, and the big frameworks are too structured. Isn't there something in the middle?

Something in the middle: Petite-vue

I've been itching to write this post for a few reasons:

I love petite-vue, so I'll share the love, and
when it landed people were super excited by the novelty of it – a mini-Vue, how cute! – but I don't think it got the full appreciation it deserved.

Petite-vue fills the gap perfectly for me. It's easily added to a site or just a single page, can be written portably and reused, is quite small (6kb), and provides you with a declarative approach to interactivity that makes it quick and easy to super-charge your front-end without entirely taking it over.

And the bonus, for Vue-inclined folks, it is a sub-set of Vue syntax, so the learning curve is almost nonexistent.

Getting Started

There are a few ways you can get started with petite-vue. And certainly, the docs will get you up to speed with the technical basics faster than this post will, but I want to peek into some of the ways I find the library most useful.

Managing global page state

Petite-vue is great when you want your entire page to react and communicate with itself. Here's a few lines of JavaScript to get us going:

<script type="module">
  import { createApp } from 'https://unpkg.com/petite-vue?module'
  createApp({
    //SOME GLOBAL STATE PROPERTIES & FUNCTIONS
    isDarkMode:false
  }).mount();
</script>

This will mount petite-vue to the entire document, allowing you to immediately start using the declarative syntax of it within your html. If you just want to toggle some state and update some classes or css variables based on user interaction, this might be the route for you!

In your HTML you can now access, modify and read your state object to react to the page accordingly:

<label>
  <input type="checkbox" v-model="isDarkMode"> Dark Mode
</label>
<div :class="{darkmode: isDarkMode}">
  Hello World
</div>

isDarkMode gets assigned to the checked state of the checkbox via the v-model directive. And on the div, the class, darkmode is present only when isDarkMode is true.

<p class="codepen" data-height="450" data-default-tab="html,result" data-slug-hash="abqpjGy" data-user="walpolea" style="height: 450px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/abqpjGy"> Getting Started with Petite-vue</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

<hr>

Functional components

My next favorite use of petite-vue is to build little functional components. Let's build a simple content accordion. The big difference here is we are no longer attaching petite-vue to the entire page. Instead we're going to surgically inject it into the markup that we want to imbue with super powers.

I have to point out that this is very much a middle-ground between full-page interaction and traditional component frameworks. The goal isn't to fully encapsulate the component into a single function call (though petite-vue can do that). Instead, it serves as a way to inject functionality into your markup, allowing the markup and css to stay bespoke while the functionality is consistent.

<p class="codepen" data-height="450" data-default-tab="js,result" data-slug-hash="ExQWyMv" data-user="walpolea" style="height: 450px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/ExQWyMv"> Getting Started with Petite-vue 2</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

In the JavaScript, we create a function called, accordion. That function returns the scope object, which can contain properties and functions that the petite-vue component uses. All we need is an isOpen state and a function to calculate the height of the toggleable content when it's opened or closed.

In the html, the v-scope attribute is what sets the whole thing in motion. Petite-vue binds that object to this element, and all children now have access. You can see we're using isOpen a bunch to set attributes and make the whole accordion work. Even modifying CSS variables, though a bit ugly to look at:

:style="{ '--height': calculateHeight($el) }"

is super powerful here, allowing our CSS to play a hand in how this works. Because isOpen is referenced inside of calculateHeight() petite-vue knows to call it when that property changes 🤯!

The last point is that we can reuse this accordion scope across multiple elements, they act as completely independent instances of petite-vue.

<hr>

Micro-web-apps

I absolutely will cover more use-cases in the future, but I want to leave you with this one.

Not only does petite-vue fill the gap of website interaction for me, it's comfortable playing in web-app territory without completely taking over your build process. You can even scope your micro-web-app right into your site.

Here's a small deck of cards micro-web-app in petite-vue:

<p class="codepen" data-height="450" data-default-tab="result" data-slug-hash="QWgORQN" data-user="walpolea" style="height: 450px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/QWgORQN"> Petite-vue Deck of Cards</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

The app is comprised of two scopes, one for the outer shell of the app (DeckOfCards), setting up the deck and interface. The second is for each Card allowing me to easily componentize how it is built and rendered. It's incredibly powerful that you can compose multiple scopes together this way, allowing you to manage multiple parts of the app separately.

Certainly there would come a point at which it might make more sense to switch this into a larger framework, but the biggest point I want to illustrate is that through all of these demos, petite-vue allows you to stay as simple or go as complex as you need to, very much to akin to what we had with jQuery; it fills the gap. It's an amazing tool for sprinkling functionality into sites, or prototyping a larger app idea. I hope you'll give it a try!

Progressive Enhancement with Petite-vue

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 24 May 2022 00:00:00 GMT

Progressive Enhancement with Petite-vue

I recently wrote about how petite-vue is a great way to sprinkle in interactivity. There's a downside to putting all your eggs in the JavaScript basket though, especially when it involves rendering content. There's a whole fuzzy world of, just because you can, doesn't mean you should web dev things, and this is definitely one of them.

Similar to Single-Page Applications (SPAs), you'll have a rougher time with SEO, because the content isn't there when the page loads, it's being added at runtime. Also, if JavaScript is turned off, your users will get served up a whole lot of nothin'. You can debate that we're beyond a world that needs the web to work without JavaScript, but I like the idea of approaching JavaScript as a tool for progressive enhancement; the concept has too many benefits to out-right ignore.

The Problem

To illustrate the problem, here's a pen showing a searchable list of grocery items being rendered to the page using petite-vue. Why not just write HTML? Because we want to enhance this list by making it searchable, and petite-vue makes that elegantly easy.

We use the v-for directive to create <li>'s from a filteredList getter that filters the original list with the <input> value. As the search term in the input updates, the filteredList getter reruns, causing the v-for to rerender the list all in real-time.

<p class="codepen" data-height="450" data-default-tab="html,result" data-slug-hash="QWQqNKj" data-user="walpolea" style="height: 450px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/QWQqNKj"> Progressively Enhanced Petite-Vue</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

<aside> As an aside, it's a shame that we have to take full control of rendering the content away from HTML to make this work easily. This would be one of the possible scenarios that could be fixed by <a href="/blog/the-fourth-language">a fourth language</a> centered around keeping track of interactive page state. </aside> <br>

The Solution

Let's fix the problem with a progressive enhancement pattern in petite-vue.

Effectively, we're going to provide the list (without search functionality) as static markup, and then use petite-vue to rerender that content with its own markup. It's essentially a bait-and-switch of static content with interactive content. As long as your markup matches, the user won't notice any large content shifting, except for where there are added functional pieces, like the search box.

Hit Rerun down in the bottom right to see the progressive enhancement happen. For dramatic effect, there's a 2 second setTimeout delay to give you time to see the original static content, and then watch the content become enhanced. In reality, with a quick loading site, users likely won't even notice the transition happen.

<p class="codepen" data-height="450" data-default-tab="js,result" data-slug-hash="qBxPqmY" data-user="walpolea" style="height: 450px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/qBxPqmY"> Progressively Enhanced Petite-Vue</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script> <br>

The Progressive Enhancement Pattern

Let's pull apart the example and break down the pattern, because that's the bit that can be applied to a whole host of situations where you want to use petite-vue to progressively enhance your content.

Javascript

First let's get the JavaScript out of the way, because it's important that I don't leave you in the dark, but it really has little bearing on the pattern:

import { createApp } from 'https://unpkg.com/petite-vue?module';

const searchableList = ({list}) => {
  return {
    list,
    initialized:false,
    search:'',
    //when the scope mounts, set initialized to true
    async mounted() {
      await new Promise(resolve => setTimeout(resolve, 2000)); //artificial delay
      this.initialized = true;
    },
    //return a filtered version of the full list based on the search term
    get filteredList() {
      if( this.search ) {
        return this.list.filter( g => g.toLowerCase().includes(this.search.toLowerCase()) )
      }
      //otherwise, no search term, return the full list
      return this.list;
    }
  };
}

//this tells petite-vue to look for v-scope directives on the page,
//and we register the ability to use the searchableList scope we built
createApp({
  searchableList
}).mount()

<br>

HTML

The HTML is really where we can call out the progressive enhancement pattern. We separate the block into two main parts:

<div class="container" v-scope="searchableList({list:groceries})" @vue:mounted="mounted">
  <template v-if="initialized">
    <!--   This only shows when petite-vue runs and sets initialized to true  -->
    <h1>Enhanced with Petite-vue</h1>
    <input type="text" v-model="search" placeholder="search groceries">
    <ul>
      <li v-for="item in filteredList">{{item}}</li>
    </ul>
  </template>
  ...

The first block, within a <template> tag will be the petite-vue enhancement. we will add the v-if="initialized" directive so that this tag will not render unless initialize is evaluated by petite-vue as true. The beauty here is that HTML won't render a <template> tag into the page either, so if JavaScript hasn't run, we never see this content. Inside is all the stuff from the earlier demo, using v-for and such.

  ...
  <div v-else>
    <!--   This content would be statically or server generated and hide when petite-vue runs  -->
    <h1>Statically Rendered Content</h1>
    <ul>
      <li>Milk</li>
      <li>Eggs</li>
      <li>Bread</li>
      <li>Jam</li>
      <li>Cheese</li>
      <li>Butter</li>
      <li>Mustard</li>
    </ul>
    <script>
      //this could also be server-generated, which is why I put it up here in the html block
      const groceries = ['Milk', 'Eggs', 'Bread', 'Jam', 'Cheese', 'Butter', 'Mustard'];
    </script>
  </div>
</div>

The second part is your statically generated content contained in <div v-else>. Once again being tricky, without JavaScript running, the v-else gets ignored and the page will render this content as normal. Here you might actually be using something like php or nunjucks or liquid to dynamically generate this markup. Whatever it is, it's just HTML, either static or server-generated.

The last added trick is that we need to pass the list of things into petite-vue as JavaScript, so you'll also see a <script> tag where we can generate the array petite-vue needs to recreate the list itself. Again, something that can be generated with a templating language.

That's it! When JavaScript is disabled, the static content is displayed by default. But when petite-vue mounts, initialized becomes true and the static content hides and the enhanced petite-vue content shows.

tl;dr

It's a little more work, but in a lot of production cases, I find this pattern to be very approachable as a way to provide static content that is then progressively enhanced by JavaScript. I've shipped this pattern on a few sites already with great success (including this blog's tag filtering functionality). The pattern can be broken down as follows:

Put your enhanced petite-vue markup in a <template v-if="initialized">
Put your static content in a sibling <div v-else> tag
Also render out a <script> tag that defines the data petite-vue needs to render its own version of the content.
Set initialized to true when petite-vue mounts, this will hide the static content and show the enhanced content.

Blog Post Image Generator with HTML2Canvas

andrew@andrewwalpole.com (Andrew Walpole) — Sun, 29 May 2022 00:00:00 GMT

Blog Post Image Generator with HTML2Canvas

I'm a big fan of the HTML2Canvas library. It has some quirks and is less maintained (lots of issues and open PRs) than I would like to see – actually I worry quite a bit about it becoming too stale to use, just because it can be so useful!

Here's a look at one way I'm using it to generate preview images for my blog posts, it's so simple, my production version of it just lives in codepen.

Before I get to that, I just want to clarify that this is not automatic social share images. Though this could be a piece of getting there, the biggest issue is that a hands-off solution will require you to automate the "run in browser" portion of an automated process, which you can pull off with something like puppeteer, but that's not in scope of this post.

The Setup

The setup is mostly focused on getting some HTML and CSS up that I would like to render as an image.

<div class="featured-image" :class="{ square: isSquare }">
    <h1>{{title}}</h1>
    <p>{{summary}}</p>
    <div class="site-tag">
      <svg viewBox="0 0 1158 1201" fill="none" xmlns="http://www.w3.org/2000/svg">
        <!-- truncated for space -->
      </svg>
      <div class="tag-content">
        <p>Andrew Walpole &copy; {{year}}</p>
        <p>andrewwalpole.com</p>
      </div>
    </div>

You'll notice some {{petite-vue}} content placeholders here, but it's not required. You could hardcode the content in, or use vanilla JavaScript to update it. But for me, petite-vue is a quick way to hook the content up to text inputs that I can easily use to generate a new custom image.

Here are those form fields getting hooked up to the content:

<label>
  Post Title:
  <input type="text" v-model="title">
</label>
<label>
  Post Summary:
  <textarea v-model="summary" cols=50 rows=5></textarea>
</label>
<label>
  <input type="checkbox" v-model="isSquare"> Square
</label>
<button @click="saveDown">Save Image</button>

As mentioned, this provides a simple interface to allow the content to be customized quickly. The title and description can be entered, and I even have an option to toggle between wide and square layouts.

The Secret Sauce

The last but most special bit is to use html2canvas to generate an image from the html, and it's pretty easy:

import "https://cdnjs.cloudflare.com/ajax/libs/html2canvas/1.4.1/html2canvas.min.js";

saveDown() {
  const containerToRender = document.querySelector('.featured-image');
  html2canvas(
    containerToRender,
    { 
      allowTaint: true, 
      useCORS: true, 
      backgroundColor: "transparent",  
      width: containerToRender.offsetWidth, 
      height: containerToRender.offsetHeight,
    }
  ).then(canvas => {
    const previewArea = document.querySelector('.preview-area');
    previewArea.innerHTML = "";
    previewArea.appendChild(canvas);
  });
}

We querySelector for the container we want to imagify, then call html2canvas( <container>, <options> ). It returns a promise that when fulfilled will give you back a <canvas> element. We can then just append that canvas into our HTML and you can right click it to Save Image As....

A few things to note. We're using the container's width and height to render the image, this allows our size toggle to work, and will also render a different image if the browser window is constraining the size. You can fix these values if you want a consistent size. Also, I had some issues with the SVG positioning and the opacity settings on it, also the ::before on the title renders oddly the first time you save it, and then correctly the second time. These are those quirks I mentioned at the beginning.

The image that is generated is a PNG, which is not well optimized. I find myself needing to run it through squoosh before using it, and that's a little annoying, but in my search for a client-side optimizer that could eliminate this step I have come up short.

Finally here's the whole thing for you to see and play with:

<p class="codepen" data-height="800" data-default-tab="result" data-slug-hash="VwQbzdq" data-user="walpolea" style="height: 800px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/VwQbzdq"> Blog Post Featured Image Generator</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

Lead Great Engineering Manager One-on-ones

andrew@andrewwalpole.com (Andrew Walpole) — Mon, 13 Feb 2023 12:00:00 GMT

Lead Great Engineering Manager One-on-ones

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.

Make it Official

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.

Tactics for making it official

Being very up-front about it is what works for me. "Hey Joe, welcome to another one-on-one, in this meeting we get a bit more formal and talk through our roles and relationship with the business."
Follow a tight agenda. I'll talk more about the agenda items I use in a bit, but having detailed notes about each section of the meeting helps establish that this is a bit of a rehearsed dance.
Get a little meta about it. "This is your chance to talk to me, but you're also talking to my role and the company. Any critical feedback you have toward those things is really important and won't be taken personally." Acknowledging that we're here to talk about how we fit into our roles, and not just about ourselves individually, helps to open the conversation to critical feedback and insights.

Follow a Specific Agenda

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.

Set and Reset Expectations

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:

You are open and honest about how the work you're doing makes you feel, both in capacity and meaning.

You have a clear understanding of your work priorities, and if you don't, you actively come to me for clarity.

When projects are off-track or have the potential to be off-track, you let me know your concerns.

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?"

Check-In on Role

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:

Do you feel like you clearly understand your role in the business?
Are you being asked to do work that doesn't align with your role?
What do you think about the company's culture/vision/direction?
Are you feeling burnt out at all?
What's something you're doing a lot of today, that you weren't doing a year ago?
Do you see any opportunities to change your role?
What kind of impact do you feel you're making?
Are you doing meaningful or important work?

Reserve a Time for a Specific Topic or Question

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:

How do you think our QA process could be better?
What technologies are you interested in that you wish we could be using at work?
What's something I do that annoys you?

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.

Set and Track Goal Progress

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.

What's on Your Mind?

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.

Acknowledge Action Items

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

Be Vulnerable and Show Empathy

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!

Productive Developer Experiences

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 24 Feb 2023 12:00:00 GMT

Productive Developer Experiences

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:

A well-groomed happy path

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?

No walls or fences. Providing escape hatches and even calling out where someone might want to deviate from the path later is key.
If your tech is really flexible, divide it up by use-cases. It's more paths to maintain, but worth it in the end that you aren't actually curating a hedge maze.
Call out the scenery. Don't just tell us how to do something; why does it work this way? What are some gotchas or limitations worth knowing about?
Make all of the bells and whistles opt-in. Show me the base experience and the points at which common functionality can be plugged in, but don't overwhelm me with a "luxury experience" because it quickly leads to cognitive overload.

Docs are the map to your product landscape

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?

Features as baby steps

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.

Useful error messages

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.

Good names make for good mental models

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.

DX will grow

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.

To Be Flexible, Be Inflexible

andrew@andrewwalpole.com (Andrew Walpole) — Wed, 15 Feb 2023 12:00:00 GMT

To Be Flexible, Be Inflexible

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.

Digital Entropy

andrew@andrewwalpole.com (Andrew Walpole) — Mon, 10 Oct 2022 00:00:00 GMT

Digital Entropy

A recent Shop Talk Show conversation around the idea of, "entropy but as it applies to the web" really got my brain gears turning.

Entropy is defined as:

1. a thermodynamic quantity representing the unavailability of a
system's thermal energy for conversion into mechanical work, often
interpreted as the degree of disorder or randomness in the system.

2. lack of order or predictability; gradual decline into disorder.

Entropy as a physics thing already has a huge impact on computing with hardware. The non-software bits are truly affected by our real world and thus can easily succomb to time's embrace without extreme upkeep.

But what about software? The idea of digital entropy might not translate super cleanly, but I do see how time and our social constructs (some might call those software too) employ friction upon software systems which will wear them out of their utility and favor if not kept up.

Societal Friction

I see three big social constructs that grind away at software, and by extension, the websites we build:

Security requirements, functional needs, and user expectations.

Security requirements

When hackers find a new way to exploit our code, we need to patch it, we truly require security to keep our systems safe. There is rarely a week that goes by that there isn't some new wordpress plugin that needs to be upgraded to avoid zero-day exploits. And the steadiness of that notion has pushed many of us into a higher level of thinking: avoid the server, build static, it's just safer by default, and thus you reduce the digital entropy inflicted by security over time.

Functional needs

Functional needs are all about the business tied to the software as a tool; we must keep equitably transacting, please the share-holders, beat the competition, stay on top. Business requirements change, the strategy and target of conversion changes. This change is often fairly steady, gradual, in the control of the business, moving at a pace that matches its capability. The next version is defined, planned and rolled-out. It's the natural motion of the social construct of capitalism and it eats away at our code.

User expectations

Closely related is the ever changing landscape of user expectations. This happens less gradually, and appears more in what we like to call, Innovation. When someone builds a new way to do something, or a new something all-together that we had not yet exactly realized before and the experience has a disruptive effect on the consumer. It changes minds; your code recodes them. Goliaths are cut down in favor of the new and novel, maybe permanent, maybe not, but it's a tumultuous ocean that churns and grates on our code. The ratchet of user expectations clicks into place, squeezing our apps and sites a little tighter, expecting change or inciting death.

Beyond Digital Entropy

I don't want to extend the entropy metaphor any further, but I think there is more to the picture especially as we really hone in on the web. Beyond the natural, outside forces that surround the web are the layers of technologies contained within.

The idea of a development toolchain is not wrong. Our websites have become varying lengths of linked-together technologies, each dependent on the others' strength and capability to continue to produce an end-product. I might also throw out some some sort of mechanical automaton metaphor: all of the determined sprockets and springs, carefully placed, each doing its part. Some sites are constantly on the move, churning; serving. Others, more coin-operated; triggered builds, automated deploy.

Without maintentance, keeping the machine well-oiled, our links degrade, our gears wear, and the lifespan of our websites is determined by the both the world around and within them.

The Lifespan of a Website

I bent this blog post intentionally quite a bit, but I really wanted to get here: The lifespan of a website is an interesting idea. I think I've clearly laid out all the factors that set the timer in motion. And so the last point to make is that I genuinely believe that the lifespan of a website is exactly tied to two things: how hard it works - how much tech is linked together and how often it conveys - and how often its code is cared for and invested in.

I'll close with a great quote from Dave Ackley, because I think it zooms out on this whole conversation, to a question that I stumbled into, "Why even bother with this fabricated uphill churning of bits?"

There's one fundamental notion,<br> Because simplicity is finally best:<br> Code is data in motion,<br> Data is code at rest.

Because the web, software, digital computation is our new(ish) way of human progress. Data and code, and data and code. It might not feel like it down in the weeds, but these digital systems we dabble in are now deeply tied to how humanity functions and computes as a whole.

Use Vite for JavaScript Libraries

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 07 Jun 2022 00:00:00 GMT

Use Vite for JavaScript Libraries

More than once I've written some snazzy JavaScript code that I want to quickly turn into a sharable library, but the process of how to best and easily do that has bogged me down enough to drop the idea entirely.

In this post, I'll walk through how you can build a set of JavaScript into a library provided in both ESM and UMD format using vite.

There's not a lot of secret sauce here, in fact, most of what I'm about to show you is lifted right from the vite docs. But I find it helpful when 3rd-party people can verify a technique.

Setup

Starting from a fresh directory we need to:

Initialize the project
Install vite
Setup some files

npm init --yes
npm i vite --save-dev
mkdir lib && touch lib/main.js vite.config.js index.html

lib/main.js will be your main library entry point that vite will compile and index.html is actually optional, but what it's really great for is showing an example of how you use your library, which tends to be a small but nagging pain point in building a library that you want folks to use.

Configure

Let's now configure vite to build your library. To do that we need to edit two files: vite.config.js and package.json.

vite.config.js

const path = require('path')
const { defineConfig } = require('vite')

module.exports = defineConfig({
  build: {
    lib: {
      entry: path.resolve(__dirname, 'lib/main.js'),
      name: 'YOUR_LIBRARY_NAME',
      fileName: (format) => `YOUR_LIBRARY_NAME.${format}.js`
    }
  }
});

The magic here is that vite has a library mode, and that's exactly what we're using. By default it will build your entry point into ESM and UMD formats into a /dist folder.

package.json

{
  "name": "YOUR_LIBRARY_NAME",
  "version": "1.0.0",
  "description": "A GOOD DESCRIPTION",
  "files":["dist"],
  "main":"./dist/YOUR_LIBRARY_NAME.umd.js",
  "module":"./dist/YOUR_LIBRARY_NAME.es.js",
  "exports": {
    ".": {
      "import": "./dist/YOUR_LIBRARY_NAME.es.js",
      "require": "./dist/YOUR_LIBRARY_NAME.umd.js"
    }
  },
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },
  ...
}

We wrap-up config by telling your package.json where your compiled library will live. This is not technically required, but if someone installs your library as a dependency, npm/yarn will know where to pull code from.

Write the library

Your lib/main.js file is where you will export all of your code from. If your library is simple you could put all of the code right in there, or if it's more complex with multiple files, it just needs to import and reexport all the things you want to bundle into the library. It's also worth noting that if you import external dependencies into your library files they will also get bundled together in the final output.

As an example, I have recently created a wrapper library for petite-vue called PV. You can check out the library code as well as the index.html to see how I'm using that to test and build a demo of the library.

Build the library

npm run build or vite build will bundle up your library into /dist while npm run dev or vite will start a server to view your index.html which makes it easy to test things out as you build the library.

And that's all there is to it! If you need to further customize your library, vite is really just exposing a proxy for rollup, and you can add rollupOptions to your vite.config.js to customize your build settings, like multiple entry points.

Always Be Expecting

andrew@andrewwalpole.com (Andrew Walpole) — Sat, 25 Feb 2023 12:00:00 GMT

Always Be Expecting

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.

Before starting a new project: How will it go? What should I expect to be difficult?
When tackling a new task: How long do I expect this to take? What are others' expectations around how this should be done?
In meetings: What are we all expecting to get out of this discussion?

"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.

Three Design Smells Only Developers Can Sense

andrew@andrewwalpole.com (Andrew Walpole) — Wed, 01 Mar 2023 12:00:00 GMT

Three Design Smells Only Developers Can Sense

Using the font-size hack

Ever seen or done this?

html { font-size: 62.5%; }
body { font-size: 1.6rem; }

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?

Unoptimized media

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.

Responsive gotchas

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

Navigations not accounting for more or fewer items.
Grids of cards designed with the same lorem ipsum content across all of them.
Heights of mobile components perfectly fit into a single viewport size.
Ambiguous resizing guidance in extra large viewports.

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.

Follow your nose

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.

An Introduction To Robust-First Computation

andrew@andrewwalpole.com (Andrew Walpole) — Thu, 09 Mar 2023 12:00:00 GMT

An Introduction To Robust-First Computation

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:

A World Beyond Hardware Determinism
Understanding Robust-First
A Whole New World of Computer Science
Living Computation as Robust-First Code
The Movable Feast Machine
MFMS
The T2 Tile Project
MFM-JS
Get Involved

<br>

A World Beyond Hardware Determinism

</a>

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:

"Just one more bug to fix!"
"Try turning it off and on again, it's efficient enough!"

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

But here's the mind-blowing, blue-pill-offering moment:

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.

<br>

Understanding "Robust-First"

</a>

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<br> Then as correct as possible<br> Then as efficient as necessary

<br>

A Whole New World of Computer Science

</a>

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!

<br>

Living Computation as Robust-First Code

</a>

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.

<br>

The Movable Feast Machine

</a>

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:

<br>

MFMS

</a>

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.

<br>

The T2 Tile project

</a>

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.

<br>

MFM-JS

</a>

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!

<br>

Get Involved

</a>

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:

Join us in the T2 Tile Discord where further questions and discussions about all this stuff is encouraged!
Dave also runs a non-profit called the Living Computation Foundation where you can donate to the T2 Tile project.
Check out the T2 Tile Youtube Channel and the Dave Ackley Youtube channel which has some great MFM demos and teachings.
Here's an ALife 2020 workshop that walks you through setting up MFMS and some ULAM and SPLAT basics.
More Information and links about the MFM can be found at movablefeastmachine.com.
Dave has written one of my favorite "computer-science fiction" pieces called, The Path to Best Effort which is a scientific publication written in the year 2039 and chronicles the historical uprising of robust-first computational systems.
You can find Dave and I on mastodon as well.
Lu Wilson also has a lovely MFM-inspired engine called Sandpond which they talk about on their Youtube Channel.
Even Von Neumann himself thought we would be moving away from Serial Determinism very soon after his initial architecture was demonstrated.

Are We The Weirdos?

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 18 Apr 2023 12:00:00 GMT

Are We The Weirdos?

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:

There's less frustration encountered as the needs of your job often trail the knowledge of your passion.
And related, it becomes easy to lead the conversation at work when you can be confident of how things are evolving.
Having the additional exposed context to the wide breadth of the web ecosystem comes in handy constantly, allowing for better system design and thoughtful solutions.
Being engaged in the community, especially on Discords as I have found, gives you a great resource and platform beyond work walls to gut-check your thoughts and ideas.

Are there downsides?

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.

It's really a spectrum

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.

The Web Is Moving at an Unprecedented Pace

andrew@andrewwalpole.com (Andrew Walpole) — Wed, 12 Jul 2023 12:00:00 GMT

The Web Is Moving at an Unprecedented Pace

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.

Why are things moving so quickly now?

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

React, Vue and other frameworks matured as reliable application-level technologies which translated into more growth for the use of our core web technologies.
Communities grew and rallied across social avenues, providing constructive discourse, data, thought-leadership and volunteered action, which trickled directly into the various web spec teams having the person-power and motivation to triage ideas and grow our spec feature-sets.
Browsers too reacted to the pace picking up and through internal efforts sped up their own release cycles and aligned with each other via the interop project.
And while there are more specific items to add to this list, I think overall, the momentum built to a point where progress now begets progress, as making the web platform more capable and productive is hitting real bottom lines.

What does this fast pace mean?

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.

Business needs to get involved!

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.

There's opportunity

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.

Adjust and get moving

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.

Not sure how to take the first steps?

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.

CSS Grid Systems with CSS Grid

andrew@andrewwalpole.com (Andrew Walpole) — Wed, 30 Aug 2023 12:00:00 GMT

CSS Grid Systems with CSS Grid

It's funny. If you google around for a modern CSS Grid framework that uses CSS Grid, you won't find much. You will see very few new frameworks at all, but you will find many that have thrived over the last decade or more, a lot of which are bundled together with larger component libraries or web scaffolding systems.

Most of those frameworks use a traditional n-columns (usually defaulting to 12) grid layout system made popular by Bootstrap or Foundation. And for good reason: these patterns were web development staples for a long time. Even with the advent of Flexbox and it not being a 1-to-1 replacement of those, these grid systems required a hefty layer of CSS on top to make them go brrrrrr.

Enter CSS Grid

But then in 2017, all the major modern browsers (excluding IE) got support for CSS Grid. I remember it coming out of the gate with a pretty big bang, especially with Jen Simmons and Mozilla pouring time and resources into evangelizing Grid's capabilities and Firefox's novel and superior devtools support of it.

The early Grid days were good; buzz about it lingered, and it seemed like a lot of folks adopted it. But eventually, like all new shiny features, Grid became just another thing to reach for.

It's at this point that I will fast-forward to six years later of hindsight to look back on: A lot of folks missed CSS Grid! I've talked with dozens of devs over the last few years who don't reach for it at all or don't even know it is something to be reached for.

And I get it. Similarly, I missed Flexbox, having shirked a lot of front-end learning in place of doing Flash and Actionscript during that time. It wasn't until only a few years ago that I really started building up my muscle memory for Flexbox.

So now it makes sense why these older style grid frameworks are still thriving. People learned the API, they work well; the patterns are comfortable and well-established.

Exit CSS Grid

But here's my big insight: People missed CSS Grid a little extra because it's so good and capable on its own, you don't need to build a framework around it.

And so all that hot new software that we saw with wrapping Flexbox or float layouts over many years; all that hype and buzz the communities would be full of at regular intervals wasn't there for Grid. Only now that browsers are finally rallying to get us subgrid is there a little resurgence in buzz.

Grid Doesn't Need a Framework

So here's my buzz, and my testimony as a CSS Grid addict: Grid makes building for the web very unscary, or dare I say, easy. I reach for it daily. And I've even tried to build a framework around it. But you don't really need it. Its syntax is lightweight and immensely capable on its own, for both simple straight-forward web development up through highly componentized modular systems.

I encourage anyone who has not given it a decent go to put in the time to make it a tool in your tool belt.

Hidden customText Preheaders in Veeva/Salesforce Emails

andrew@andrewwalpole.com (Andrew Walpole) — Sun, 03 Sep 2023 12:00:00 GMT

Hidden customText Preheaders in Veeva / Salesforce Emails

Here's a very specific one in hopes of preventing someone from having the fraught Google expedition I had.

My job has me moderately learning and working in Veeva for email development. This is essentially a document-based CMS that lets you stitch parts and pieces of files and code together to build fairly complex customizable emails and other experiences. One feature is the customText directive which allows you to inline multiple string choices within any set of text. Something like:

{{customText[Here is a custom option|And this is a another custom option|And one more for good measure]}}

Useful!

Another email-specific concept relevant to this story is Preheaders. Many email clients take the first few sentences of text in an email and append it after the subject in their interfaces so the user has a little more context as to what the email is about. Given that, it's a little bit of a marketing hack to create this idea of Preheaders, or hidden text that comes first in the body copy of the email so that the email clients show specifically chosen text rather than the actual starting text of the email message. Sneaky!

A set of preheader code might look like this:

<span class="preheader" style="font-size:0px;line-height:0px;max-height:0px;max-width:0px;mso-hide:all !important;overflow:hidden;visibility:hidden;display:none;">Hey this is my preheader text</span>

Just a <span> with a bunch of inlined ways to make it visually disappear from various email clients.

The Problem

Ok, now that we're up to speed, what if we want to combine these two things: customText hidden preheaders? Well you can't do it, at least that's what the internet has to say about it. What's the issue? When you load an email from Veeva into Salesforce it sees the customText directive and proceeds to replace it with a <select> dropdown of your options. The only problem is that it renders within the email markup that the customText lives in, so:

<span class="preheader" style="font-size:0px;line-height:0px;max-height:0px;max-width:0px;mso-hide:all !important;overflow:hidden;visibility:hidden;display:none;">
  {{customText[This is the first optional hidden preheader|And this is a second optional hidden preheader]}}
</span>

In the Salesforce email editor becomes something like:

<span class="preheader" style="font-size:0px;line-height:0px;max-height:0px;max-width:0px;mso-hide:all !important;overflow:hidden;visibility:hidden;display:none;">
  
  <!--  Salesforce adds in this <select> for the choices:  -->
  <span class="AE_customText" tagtext="customText" required="false">
    <select id="0" class="hideCustomTextValues">
      <option id="0_0" value="This is the first optional hidden preheader">This is the first optional hidden preheader</option>
      <option id="0_1" value="This is the first optional hidden preheader" style="display: none" hidden="">This is the first optional hidden preheader</option>
      <option id="0_2" value="And this is a second optional hidden preheader">And this is a second optional hidden preheader</option>
      <option id="0_3" value="And this is a second optional hidden preheader" style="display: none" hidden="">And this is a second optional hidden preheader</option>
    </select>
  </span>
  
</span>

See the problem? The <select> is within your hidden preheader markup, so as you might expect, it doesn't render the dropdown in Salesforce!

The Solution

So how can we fix this? We need to show the dropdown in Salesforce but continue to hide it in our final rendered emails. Enter the fairly new CSS :has()!

We can select the .preheader class by looking to see if it contains Saleforce's .AE_customText class, and undo all the hiddenness of the preheaders, like so:

@supports selector(:has(*)) {
  .preheader:has(.AE_customText) {
    display:block !important;
    opacity:1 !important;
    visibility:visible !important;
    overflow:unset !important;
  }
}

Salesforce will now show the dropdown so you can make a choice, but when the email is rendered anywhere else the .AE_customText class won't exist and none will be the wiser!

Here's a codepen of the full solution:

<p class="codepen" data-height="300" data-default-tab="result" data-slug-hash="jOXMVJE" data-user="walpolea" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/jOXMVJE"> Email css for salesforce optional preheaders</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script is:inline async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

Remote Leadership Takes a Concerted Effort

andrew@andrewwalpole.com (Andrew Walpole) — Sat, 09 Sep 2023 12:00:00 GMT

Remote Leadership Takes a Concerted Effort

Not that good leadership in general doesn't take calculated skill, but if we're looking at the huge pandemic-driven swing from few to many leaders becoming remote workers, it's worth talking about how an absence of physical presence impacts how leaders need to execute on their role to be successful.

It's all about interfaces

The kinetic work of leadership is mostly about interfacing with people. The abrupt move from in-person to going remote seems akin to replacing your keyboard and mouse with your old Nokia phone keypad. It's not that you're left entirely dead in the water, I mean if you are old enough to have used one of those devices you'll know we got pretty adept at playing snake and composing full sentences with 10 buttons. But certainly, it's an initial major hit to productivity if you don't make the specific effort to adapt.

It's at this point that I can't help but recall the beginning of the pandemic. For myself, I had not worked remotely full-time before, but I think I was lucky for a few reasons: First, being an engineering manager, there were fewer obstacles to overcome being distanced between screens when the work me and my team were doing was already so natively available on those screens. Second, my tactical approach to leadership helped me very quickly understand that those same tactics had to be translated and adapted to remote work.

The big apparent insight in breaking down the situation was that remote work meant a steep decline in natural opportunities to interface directly with people.

</div>

Concerted is the Key

It's really the exact word I want to press upon in my point here: Concerted means to jointly plan or coordinate. And so effective remote leadership means a leader being deliberate in creating opportunities to meet with their folks, but also to arrange and do it in a way that works for all parties. Truly an effort of communicating to communicate more is needed: Let's talk about work, but first, let's talk about how we talk about work.

Taking this extra step fills a void that physical spaces innately provide, from the position of your desk to theirs, or the sizes and availabilities of meeting spaces; their physical fixedness guide us to fall into a communication pattern and cadence that just works. Having the deliberate conversation that figuratively breaks the fourth wall of your computer screen helps to break down the actual digital barriers between leader and led.

So if you are a leader, or even just being led remotely, and you feel like that loss of physical space has not been accounted for, I think these thoughts can provide a solid basis for how you can begin to fill the gap to establish stronger leadership ties. Embrace the meta of it and have real conversations about how to have better work conversations.

Glowing Blurred Backgrounds with CSS

andrew@andrewwalpole.com (Andrew Walpole) — Sun, 10 Sep 2023 12:00:00 GMT

Glowing Blurred Backgrounds with CSS

About a year ago I was asked to create a glowing ball of light animated background effect for a website. The end result was very cool looking for being so easy to pull off with just CSS. Here's a quick look at how it's done.

Using clip-path: polygon() and filter: blur() on a container you can create some pretty cool and performant glowing, animating background effects:

<p class="codepen" data-height="525" data-default-tab="css,result" data-slug-hash="JjwYaxM" data-user="walpolea" style="height: 525px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/JjwYaxM"> Pretty Blurred Backgrounds with clip-path and filter:blur</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p>

I think the code is pretty straightforward, so I won't go line-by-line, but here are the things to note:

Using clip-path:polygon() is a really great way to create interesting and scalable shapes since you can use percentage-based values. On top of that, they are pretty easy to create with online tools or vector graphics software.

I happen to prefer Adobe Illustrator, and while it's paid, I'm well-versed with it and I love that I can copy a path out of it directly into vscode as an SVG. And pro-tip, your SVG export settings in Illustrator will match how that copy/pasted code looks, so you can fine-tune it to format exactly as you like. Illustrator does prefer to export SVGs with absolute pixel values, so the other trick there is to use a 100px x 100px artboard to draw your path, and then use some JavaScript like this to convert the path from pixel to percentage values! Works like a charm!

Now back to the CSS effect! Since we're going to be blurring these paths, they don't have to be perfect at all. In fact, I get away with turning three rough blob shapes into a single path by connecting them with a sliver of path that ends up disappearing in the blurring process.

Here it is without the blurring applied:

<p class="codepen" data-height="525" data-default-tab="html,result" data-slug-hash="jOXBpZj" data-user="walpolea" style="height: 525px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/jOXBpZj"> Pretty Blurred Backgrounds with clip-path and filter:blur</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p>

The next tip is to animate the internal shapes, but apply the filter:blur() to the container. This will give you the performance you want on an effect like this. It also helps to blur with a vw unit since a fixed value might not be as blurred as you want on large screens or too blurred on small screens.

Lastly, you can use gradients and mix-blend-mode to get the exact effect you're looking for. The little CSS framework I've provided in the above code also gives you all you need to layer multiple paths on top of each other and tweak values like colors, opacity, size, position, and speed.

If You Blog, Consider Blogcasting

andrew@andrewwalpole.com (Andrew Walpole) — Sat, 11 Feb 2023 12:00:00 GMT

If You Blog, Consider Blogcasting

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.

How to get started Blogcasting

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.

Step 1: Record the episode

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.

Step 2: Host the episode

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.

Step 3: Implement the blogcast into your blog posts

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:

---
const {url} = Astro.props;
---

<div class="blogcast-player" >
  <media-controller audio>
    <audio
    slot="media"
    src={url}
    ></audio>
    <media-control-bar>
      <media-play-button></media-play-button>
      <media-time-range></media-time-range>
      <media-playback-rate-button></media-playback-rate-button>
      <media-time-display show-duration></media-time-display>
      <media-mute-button></media-mute-button>
      <media-volume-range></media-volume-range>
    </media-control-bar>
  </media-controller>
  <p>Listen along to this post as you read, or <a href="https://andrewwalpole.com/feed.xml">subscribe to the blog</a></p>
</div>

<script>
  import 'media-chrome';
</script>

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.

Step 4: Add the media to your RSS feed

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 <enclosure /> tag pointing to the file for each <item>.

It might look something like this:

<enclosure url="https://pub-40fccf9e493a4d029eb2b8955f358ac3.r2.dev/if-you-blog-consider-blogcasting.mp3" type="audio/mp3"/>

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

Will you give it a shot?

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!

Servers Got Hot So Front-End Got Cool

andrew@andrewwalpole.com (Andrew Walpole) — Thu, 21 Dec 2023 12:00:00 GMT

Servers Got Hot So Front-End Got Cool

As I reflect back on the year in web development, what stands out to me is that the steady comeback of servers (especially via serverless) in web architecture, which has been steadily mounting for the past many years, seems to have finally hit an eruption point. Specifically SSR and Hybrid SSR (that's SSR + SSG intermingled) are now top architectural contenders for delivering websites large and small, simple and complex, as the natural scalability of complexity these concepts can handle is elegant and efficient.

On top of that, buy-in solidified at the platform level, both in modern web hosting and frameworks. Where folks were once fine trading-off some hoop-jumping to cobble SSR into their sites, it's now a first-class switch in many circumstances to enable an exact balance of performance and capability across any site or app.

Furthermore, I'll dare to make a connection here that because server-side popularity has grown, it has somewhat pulled the back-of-the-front-end more towards back-end, leaving a clearer gap between front-of-the-front-end needs. Or said differently, I think appreciation is growing for mastery in HTML and CSS as complex JavaScripty logic leans heavier into back-end territory. It also helps that CSS is also having its moment as the CSSWG is hitting its stride in proposing and growing the language at a pace unseen in years past.

So servers got hot and front-end got cool, recovering from a bit of a bludgeoning from the javascript-all-the-things crowd as they also got put in their place a bit. But will it last? There are a lot of architectural fads that tend to rise and fall in our industry, and while I'm sure we'll continue to see newer concepts overtake old, as a renewed resurgence and the fact that it's over the hump of being a one-size-fits-all solution, I can easily imagine Hybrid SSR lasting us through the next decade of web development, acting as a capable base allowing us to focus on innovation in other areas.

Bloxels is the Best STEAM Software for Kids

andrew@andrewwalpole.com (Andrew Walpole) — Sat, 13 Jan 2024 12:00:00 GMT

Bloxels is the Best STEAM Software for Kids

In December of 2020, my then seven year-old was big into art and Angry Birds, which was his first foray into video games. He would play the game and when his screen time was over switch to his desk to draw all of the characters and the levels. As an engineering dad seeing his brain begin to piece together the complexities of playing a game like that, I naturally began itching to find a great gift that could introduce him to programming.

We had tried a few things previously; like those robots you can program to move with simple arrow buttons to denote going forward or turning. They were neat, but didn't really capture his attention. A bit of the same with scratch and scratch-like visual programming tools and games; He could understand the basics, but there wasn't enough payoff to them that held his attention.

Looking at what else might be out there to fill the "engineering for kids" void, it seemed as if I had to concede that there really wasn't a great product for such an early age.

Enter Bloxels

Deciding to pivot on engineering a tiny bit, I purchased Bloxels, an educational video game building app. I recall being quite unsure about it as there were a lot of mixed reviews on Amazon. It was an interesting product though. Not only were you purchasing a voucher to have an account and own the app, it also came with a physical pixel art board that lets kids design characters and levels by placing colored cubes into a grid; novel, but a neat way to turn pixel art into a tangible event.

So on Christmas morning, my little one opened it up and with a clearly excited-confused look of, "Wow, amazing... what is it?!?!" our journey into Bloxels began.

What Bloxels is and what it isn't

Before I go on, I just want to note that one of the great things about Bloxels is that what it is now is much more evolved from what it was three years ago. So from here on out I'll be referring to the latest capabilities rather than just the old.

Bloxels is not really a programming game. At least not in a clear one-to-one manner. You won't find an exposed programming language with if statements and loops and variables to learn. Instead, Bloxels focuses more on the mechanics of design, both in form and function. And so in that sense, Bloxels is absolutely an engineering game.

Teaching the form of design

Bloxels is a great first drawing app for kids. I could even imagine that, had I been a Bloxels user earlier, I would have plopped my three or four year old in front of the character designer to play around with building pixel art. You can build pixel-based sprites with an easy to use interface and even animate them. It's an incredible introduction to digital art that balances ease of use and complexity of capability with masterful UX design.

There are essentially four modes of design within Bloxels:

The character builder (for building characters with all their moving states)
The art builder (for building environmental level tiles and items)
A background builder (for creating backgrounds for your levels to sit on top of)
And the game builder itself (for designing and bringing all your assets together into a game)

The first three design modes mentioned above have a very similar drawing app interface; it's the place you can really exercise those artistic pixel-art skills. The game builder though, is quite another beast.

Teaching the function of design

Upon creating a new game, you're given a choice: Platformer or Top-Down; think original Mario Bros. vs original The Legend of Zelda. Once you make a choice the game builder sets you into your level, which is a large gridded-out canvas where you can place blocks. Different block types make up the core functionality of building games; from terrain, hazard, collectible, story block, enemy, action block, power-up and liquid, you have everything you need to design out the function of the game. The thing I love most about this is that the types of blocks are color-coded and can be placed down completely from a functional perspective first, and then later skinned with your various block-art designs. This presents a huge engineering skill packed into a very simple feature: planning out your functional design and mechanics separate from focusing on your artistic vision.

Each block type also has configuration settings, this is where we start to see some programming concepts in the game. Though limited to the features of Bloxels, there are enough if/then scenarios that can be built and toggled to do a decent job of building the mental foundations of connecting various decision trees to form a functional game.

You can set up:

Doors and keys
Various difficulties and types of enemies
Power-ups for your character to change their abilities mid-game
Warp points to move throughout levels and even across separate game maps
And much more; Bloxels continues to add features regularly to keep games engaging

Set up for success and encouraging failure

The last thing I'll focus on is how the game comes with a ton of asset packs and pre-made examples for kids to get started from. This creates a smooth on-ramp of usability and learning that is often lacking in software. At the same time, the test button is almost always on screen, encouraging learning to experiment and iterate with ideas with a near real-time feedback loop.

They doubled down on the engineering

I'm not going to belabor convincing you that this is a good app for kids; it really is.

Instead, let's take a look at what really clinches Bloxels for me personally as something I want to support. Remember when I mentioned the bad Amazon reviews? Well it turns out that Bloxels original owners didn't do a great job at marketing the product and began failing as a company. Therefore they went through a period where they were offloading product with pretty much zero support, causing folks with issues to run screaming to the review section to say what a scam it was.

I'm not sure I have the story pieced together 100% correct, but it seems like one of the lead engineers was able to rescue the brand and the app from the company, take it over and turn the ship around by pouring time into making it a better, more reliable product. Years later, Bloxles seems to be quite healthy, and their continuous investment into features over many years has made it the incredible app it is today.

Under the hood, play.bloxels.com is a pretty elegant looking SPA. All of the various features, capabilities and textures come in over API endpoints as structured JSON data, which is then rendered client-side. Given that once you're editing games nearly everything you see is user-generated or user-configured, it's quite a smart tactic to save and load sets of configurations back and forth, with efficiencies going into the size and structures of those datasets. Just open up devtools as you poke around and you'll be impressed with the interworkings of fetch calls and responses.

tl;dr

We've been a Bloxels household for over three years now and there are few apps or games that I can recall having such a long-term reverence for. I thought I was just getting something fun for my son to express his creativity and was surprised to find out it absolutely was that and a ton more. Bloxels strikes a balance of fun and education in a way that is quite rare. It promotes learning to iterate on design and take into consideration the player and advanced game mechanics and shows how bringing function and aesthetic design together is a powerful combination for creating engaging experiences. It is the best STEAM app I've come across for young children to learn how all the aspects of design and engineering play a powerful role in our world.

Once again, these thoughts are my own entirely, Bloxels has no understanding that I'm publishing this. They have just proven themselves deserving of kind and reverent words and a solid recommendation from this engineering dad.

I'll leave you with one of my son's first games to try out for yourself: Flopsy's Adventure

AI Now is like The Jetsons

andrew@andrewwalpole.com (Andrew Walpole) — Mon, 04 Mar 2024 12:00:00 GMT

AI Now is like The Jetsons

That is to say, if I were to place down a bet on all the grand futures we're currently imagining and reading about with the AI revolution now infantly upon us, probably a lot of what is predicted to come, in broad strokes, will eventually be so, but most of how and when it will materialize is not.

Dreams of flying cars, robot maids and video telecommuting, just a few of many ideas that are finally becoming sort of true. But 60 years later? Hope your internet connection is stable during all those zoom calls. Oh no, what did your roomba just smear across the floor? And have you seen our flying cars?!? I think it's still going to take a bit.

Not that it will be another 60 years for things to really get moving, we are moving a lot faster. But we've still got a lot of iterating, legislating, appealing, regressing, forging, considering, and all those other messy things that wind the path for individuals and teams and departments and companies and societies.

The point? I think it's two things that I think of often amidst the daily sensations:

Don't be ignorant of history, while the path may be new, we are the same wayfarers.
There will be a place for everyone and time for everyone to find their place.

Use @vue/reactivity for Reactive Data Stores

andrew@andrewwalpole.com (Andrew Walpole) — Sat, 27 Jan 2024 12:00:00 GMT

Use @vue/reactivity for Reactive Data Stores

Vue's reactivity system has been around since 2020, but I've often thought it has gone under the radar. That thought was more than confirmed for me when the idea of signals dropped last year and everyone seemed to go nuts at it's revelational reactive state capabilities. To me, at both first glance and deeper-dive, signals was barely different from @vue/reactivity.

But I can see why it has been overlooked. It has vue in the name, so it must be for Vue! That's not the case. Though built for and into the core offering of Vue 3, the @vue/reactivity package stands alone just fine and can be used completely absent of Vue the component framework.

Again for those of you in the back:

@vue/reactivity is a completely stand-alone and light-weight reactivity system.

Why reactive data stores?

There are a lot of patterns that vary in complexity to add the capability of shared state across an application or website. Without getting in the weeds there, the reactivity part of a reactive data store pattern is really about abstracting away the ability for state to become updated as it changes across the places it needs to be used. So instead of having the manually retrieve values as they update, you have automatic mechanisms to tap into performing actions as state updates.

3 Ways to create reactive stores

One thing I like about the @vue/reactivity package is that you have a few options as to how you want to structure your stores. You can level up the complexity of them which helps you build in safeguards needed to wrangle state across larger apps, or keep them dead simple for smaller needs. Let's take a look at three patterns, going from simple to more complex:

Really simple global store

This is about as simple as it gets. We use the library's reactive object to store all of our values, getters and actions. This is great for small but highly shared sets of data that need to stay in sync.

store.js

import { reactive, computed } from '@vue/reactivity';

// global reactive state
export const state = reactive({
  count: 0,
  increment() {
    state.count++;
  },
  countIsEven: computed( () => state.count % 2 === 0 ),
});

When we want to use the store, we simply import the store object and access all the properties. Here's an example of wiring-up our counter with vanilla HTML and javascript.

somewhere-else.html

<div class="count"></div>
<div class="is-even"></div>
<button class="inc">++</button>

<script type="module">
import { state } from './store.js';
import { effect } from "@vue/reactivity";

document.querySelector('.inc').addEventListener('click', () => state.increment() );

effect( () => {
  document.querySelector('.count').innerHTML = state.count;
  document.querySelector('.is-even').innerHTML = state.countIsEven;
});
</script>

This introduces the effect function, which is the way we tap into state changing automatically: any function passed into effect() will be run when the state changes.

View as Codepen Demo

The flexible store

This pattern ups the complexity a bit but provides a few safeguards and lets you distinguish between global shared state and also instance-specific local state values.

useCounter.js


import { ref, computed } from '@vue/reactivity';

// Global state, getters, actions:
const globalCount = ref(0);

const countIsEven = computed( () => globalCount.value % 2 === 0 );

function incrementGlobalCountOnly() {
  globalCount.value++;
}

//Scoping our store into a function allows us to capture
//local state which can be run across multiple instances of useCounter
export const useCounter = () => {

  // Local state, getters and actions
  const localCount = ref(0);

  const localCountIsEven = computed( () => localCount.value % 2 === 0 );

  function increment() {
    globalCount.value++;
    localCount.value++;
  }

  return {
    globalCount, 
    countIsEven,
    incrementGlobalCountOnly,
    localCount,
    increment,
    localCountIsEven
  };
};

Here we've established two places to declare state and actions. Outside of the useCounter function, these values will be shared among all users of the store, but declarations made within the function provide each caller of useCounter() its own localized copy of that value. This allows for a reusable pattern that lets you compose state and function into any sort of UI; excellent for components!

Here's a look at using this counter store with templating library, lit-html, where we put together a quick reusable Counter() template. This code is a direct pull from a snippet Evan You shared back in 2020

somewhere-else.html


<h2>Counter 1</h2>
<div class="counter-1"></div>

<h2>Counter 2</h2>
<div class="counter-2"></div>

<script type="module">

import { useCounter } from './useCounter.js';
import { effect } from "@vue/reactivity";
import { html, render } from "lit-html";

const Counter = () => {
  const {
    increment, 
    globalCount, 
    localCount, 
    countIsEven, 
    localCountIsEven 
  } = useCounter();
  
  return () => html`
    <div class="counter">
      <p>Global Count: ${globalCount.value} - isEven? ${countIsEven.value}</p>
      <p>Local Count: ${localCount.value} - isEven? ${localCountIsEven.value}</p>
      <button @click=${increment}>++</button>
    </div>
  `;
}

//This marries our component instance with the DOM
//and sets up re-rendering based on state using effect
function mount( comp, target ) {
  const template = comp();
  effect( () => render( template(), target) );
}

mount( Counter, document.querySelector('.counter-1') );
mount( Counter, document.querySelector('.counter-2') );

</script>

Perhaps not the most practical example here, but I hope it's clear that this pattern gives you more options as to how you can scope reactive state to both the global and local instance.

We also switch from piling everything into a reactive object and instead reach for ref which is similar but meant for creating reactive primitives. Separating our state and actions into individual variables allows them to be exported and then imported separately which gives you granular control over which consumers of the state can access and do what. It's also worth mentioning that with ref types, we must use <ref>.value to access the data, whereas, reactive types, the keys can be directly accessed.

View as Codepen Demo

Multi-store app state

With greater app complexity comes a greater responsibility to stay organized and limit where and when state can be mutated. This last pattern continues to add a few features that help you maintain sanity across a larger application structure with multiple sets of data.

Mainly I'll add two concepts that help separate mutation from state and also show that you don't need one store to rule them all; we can break things up by service or domain to allow components to specialize in their state scope.

First, let's create two separate stores similar to our previous patterns:

/store/UserStore.js

import { reactive, computed } from "@vue/reactivity";

// State
const user = reactive({
  isLoggedIn: false,
  username: null,
  profileUrl: computed( () => {
    return user.username ? `/profile/@${user.username}` : undefined;
  })
});

// Actions
const User = {
  async Login( credentials ) {
    user.username = await Auth( credentials );
    user.isLoggedIn = true;
  },
  Logout() {
    user.username = null;
    user.isLoggedIn = false;
  }
}

export { user, User };

// Private functions
function Auth( credentials ) {
  // TODO: Authentication
  return "UserName";
}

This simple User-scoped store begins by only keeping state within the reactive user variable. All mutation actions are then placed in a User object. I like the simple distinction of lower and uppercase to distinguish these, but feel free to name them something like userState and UserActions if you want to be more explicit.

In this case, since the UserStore is more of a singleton pattern with only global properties, we aren't using the previous pattern of wrapping our export in a function like useUser() but again this is easily done if you need that instanced local state as well.

Here's another store we might have in our app to track global UI state:

/store/UIStore.js


import { reactive } from "@vue/reactivity";

// Constants
const THEMES = ["light", "dark", "waverunner64"];

// State
const ui = reactive({
  showSettingsPanel: false,
  colorTheme: "light",
});


// Actions
const UI = {
  toggleSettingsPanel(v) {
    ui.showSettingsPanel =
      v === undefined ? !ui.showSettingsPanel : v === false ? false : true;
  },
  settingsPanelOff() {
    UI.toggleSettingsPanel(false);
  },
  settingsPanelOn() {
    UI.toggleSettingsPanel(true);
  },
  changeTheme( theme ) {
    if( isValidTheme(theme) ) {
      ui.colorTheme = theme;
    }
  }
};

export { ui, UI, THEMES };

// Private functions
function isValidTheme( theme ) {
  return THEMES.includes(theme);
}

We've introduced some constants that you may want to expose as helpers, but otherwise same deal here: separate state and logic into respective ui and UI objects.

Now for the final piece to the pattern. While you could expose each of these state objects directly to the components that need them, I like to hide them behind one more layer that composes all of your state objects together. This creates a unified way components access state, creates a layer to inject middleware and transforms, and may make refactoring easier down the road.

UseAppState.js


import { ref, readonly } from "@vue/reactivity";
import { user, User } from "./userState";
import { ui, UI } from "./uiState";

const initialized = ref(false);

function initializeAppState(config) {
  //We can do things like set up a database connection
  //Or load information from localStorage here
  console.log('initialize app state');
}

export const useAppState = (config) => {
  if (!initialized.value) {
    initializeAppState(config);
    initialized.value = true;
  }

  return {
    ui: readonly(ui),
    user: readonly(user),
    UI,
    User,
  };
};

The layer here is pretty light, but a few things to point out. We've moved back to the useAppState() function to allow you to do any sort of local initialization you may need. We also have a global initialization function that will run once the first time any component or service taps into our state model. This is great for initializing database connections or loading in preset. Lastly and most importantly, we've introduced the readonly() function supplied with @vue/reactivity which turns your reactive state object into a copy that cannot be directly mutated. This further safeguards our data from accidentally being changed outside of the specified action functions.

To see how this can be used check out this full Astro-based demo on stackblitz.

tl;dr

I showed you three patterns for creating simple to more complex reactive stores that can be shared across instances of just about any sort of client-side JavaScript, be it Vue components, Astro components, React, web components or just plain <script> tags.

One of the biggest points I want to leave you with is that these patterns aren't perfect and the pattern you choose could be a middle-ground between these, or even something much more battle-hardened than the final example. There isn't any exact way to build these; there's an ambiguity to deal with in how flexible the library and its individual constructs are. So most of all, take into consideration your application size and needs to create a shared state pattern that works best for you.

@vue/reactivity is an underrated library that is both lightweight and mature. So I can't recommend enough taking a look if you're looking to add reactivity or shared state and data store solutions to your next project.

What's Your Go-To Web Stack? (2024 Edition)

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 05 Mar 2024 12:00:00 GMT

What's Your Go-To Web Stack? (2024 Edition)

In 2022 I wrote the first, What's Your Go-To Web Stack? post. Now I'm back a few years later to reflect on any changes to my own answer and to challenge you once again to answer the question as well. Minimally it's an amusing exercise, but I think done over time it's an interesting introspection take a quick snapshot and compare it to those of the past.

What's your go-to web stack, right now?

Here's the set-up:

So what do you do? How do you build this site? What technologies will comprise your stack and workflow? Maybe most importantly, if you aren't quite sure, what else do you need to know?

My Go-To Web Stack

At this very moment, it's a really easy answer for me. Astro has won me over in the last few years. It's a joy to use, both in bringing me back personally to the simple focus of building websites (and not building projects that turn into websites), and also in seeing the successful role it can play in building custom production sites for clients competitively. It keeps you close to the front end, while providing the luxuries of any modern build-step framework.

The static-first nature provides excellent performance, but SSR being just a toggle away gives me the flexibility and confidence to build any sort of site or even app that might get thrown at me.

On top of Astro, its ability to nearly seamlessly integrate interactivity via Vue yields clean and performant interactive and functional sites. I've also become a steady user of vueuse and its large library of functionality-I-always-reinvent-but-dont-need-to-now-because-of-vueuse.

In the CSS realm, while nesting has now arrived, I just can't quite bring myself to quit some of the niceties, or maybe just having the possibility of niceties, of SCSS yet. Though I've fully forsaken SCSS variables in favor of custom properties. I'll also give a shoutout to Ryan Mulligan's Layout Breakouts concepts which has been doing good work for my work lately.

For the dynamic content component for this project, it's tough to argue from the built-in content collections feature of Astro; if I were building the site for myself it's an easy choice. But let's say we need some sort of simpler online UI to publish content from. I would probably reach for Contentful or Prismic. Both systems are robust and capable, and each offers a more than decent free tier. This used to not be the case for Contentful, but I'm now quite happy that they've remodeled their offering to something that a lot of folks can jump into for small projects. Coming in third actually might be AirTable which I've picked up over the last few years for some projects and it's quite good for small projects.

For the form, I think my serverless game has grown to the level that I would likely just roll it myself over attempting to pay, integrate and style a 3rd-party service. Let's just parse out that data and send it on over to our CMS or maybe even right to email.

As for hosting, I think my conviction for one host over another has waned a bit. I am still mostly positive about the offerings and capabilities of Cloudflare and Vercel and would likely choose one of those, but I'm less stoked about their in-flux reputations. For sure Netlify has just gone and fallen off my radar, are they even still around? Maybe a new old player is AWS Amplify, which just launched SSR support after being static-only for so many years; but it's a bit early to tell how that will play out. Lastly, while I haven't done much with them, I keep a longing gaze turned toward Deno Deploy. All the things Deno is doing are cool and good, and I want to support that.

tl;dr

Once again this exercise was a lot of fun to reflect on. Many of my answers changed. A few years ago I was slinging Eleventy and Nuxt sites like nobody's business, and while I am still fond of what they can do, the layered-on happy-defaults simplicity of Astro quickly won me over. In that time I've also switched jobs, but I think it's interesting how that transition only supported the continued trajectory I was on with the web and did not cause any major disruption to it.

For me, at this moment, my go-to web stack is:

Astro
Vue + vueuse
SCSS
Contentful / Custom Serverless Forms
Vercel

Invisible Contexts

andrew@andrewwalpole.com (Andrew Walpole) — Sat, 23 Mar 2024 12:00:00 GMT

Invisible Contexts

Josh Collinsworth recently put out an incredibly well-written article about his perceptions of the Front-end Web Development role being devalued within the industry. If you haven't given it a read, please do!

Josh sums up his article saying he just feels it mostly. Well I feel it too and I've been thinking a lot about why that is.

For me, there are two clear places I see front-end development, and especially front-of-the-front-end (HTML, CSS, DOM-facing JavaScript), being devalued.

The Rise of the Full-stack Developer

The last decade of web development has seen multiple balancings and rebalancings of the importance and need for both front and back-end developers. And so as the latest and greatest client and server technologies waged land wars, we sold away that frustration and uncertainty with the idea of a role that can just do it all and break the hard divide between the two.

The Full-stack Developer was borneth!

It looks great on paper, especially to the payroll department: One person to fill traditionally two roles. But in reality, we know it doesn't work that way. It may be a role for a technology generalist to thrive in, but one person's effort is finite, and consistent, quality development across the entire product development spectrum requires focus and expertise. Nevertheless, start-ups soaked up the efficiency, and in a tumultuous churn of web tech it was a decent defense.

Fast-forward a few years, the full-stack idea has remained, but those raging wars have mostly subsided. With React and Node's grip on the industry, and then a rise in serverless architecture, it seems like both sides have reached an agreement: JavaScript!

History lesson aside, how does this devalue front-end development? Whether it's mostly truth or just stereotype, the idea has been set: Full-stack devs got by with shirking front-of-the-front-end tech and they still built the apps. Ergo, The front end can't be that important. It's the real engineering that matters, right?

I might even venture to surmise that concepts like CSS-in-JS, Tailwind and others were born out of necessity from these types of roles looking to squeeze down the uncompromising breadth of technologies they've had to contend with. Once again, putting a message out there that we don't need the raw, deep capabilities of CSS.

In the same sense that I sure can build a website in plain HTML, they sure can build an App with just Javascript and a Database. This was how software was back in the '90s and early '00s. UX was icing on the cake, not yet a competitive business strategy. So sure, you can do that, but it doesn't prove the argument. UX and design are tablestakes now, and the industry isn't entertaining a step backward.

The Rise of UX Design

That last paragraph is a perfect segue into the other big reason I think front-end development is being devalued: UX Design has been and continues to be, in the spotlight.

What's not to love about it? A beautiful, thoughtful set of pretty pictures and content. I see what looks like a button and my built-up knowledge of foundational UX patterns as a digitally savvy user has me say,

"Aha! I can click that! Bravo, designer!"

"An accordion? Yes! I know what to do with that too. How lovely!"

"What's this boring bit with the words and photo? Oh, it does parallax? That sounds fancy, I can't envision it exactly, but sure, sounds amazing!"

Don't get me wrong, I think UX Design is incredibly important. I love that it now is as important as it is. I even switched career paths from Software Engineering to Web Development because I wrote a technical paper on the importance of considering the user experience of functional components when building OS-level software, amidst a dull curriculum of C++ and low-level Windows programming.

So don't take this as me being mad at UX Designers, I'm not. If anything, they've done such a good job in their roles, the hand-off to the next step, front-end development, implementation, feels like someone just shut down the party.

"It's going to take how long? And there will be bugs at first? And when you're done it will look the same as it looks in figma, just in a browser? The designer already designed it, isn't the hard work done?"

Some of it is, yes, but we now need to deal with (and we're finally at the title of the blog post):

Invisible Contexts

Let's take charge of the problem: Listen fellow front-enders, we have a marketing problem. To our left and our right, the roles around us are dazzling the project managers, clients and VPs with their voodoo and techno-babble. We have voodoo too, but no one sees it. Our role is filled with detail; minutia. We take beautiful broad-stroked ideas and birth them into ugly reality.

Doing that for the web means taking one or two, or if we're lucky, three different screen designs and translating them into a dynamic functional system that works on all screens, all browsers, all operating systems, all devices, all users, all functional states, all user journeys and stories, etc. These are the incredibly complex, compounded situations of reality that we must work through, these are the invisible contexts that make up the primary function of the job.

And yet they do remain mostly invisible. I don't see this work being valued in the same way it is for the UX designer; the credit was already given for the broad idea, this next step is nothing new.

"When do we get to launch? That will be exciting!"

I don't necessarily have an answer to propose to conclude this post. But I did want to end with a fun graphic and connect one more idea. Chris Coyier pointed out that Design Engineering is having a moment and maybe this is our Fresh Start™ opportunity.

I like to think that the role of Design Engineer brings these invisible contexts into clearer focus. It's a role that shifts left from Front-end Developer, encompassing some UX design responsibilities around synthesizing functionality amidst design, and centers on that transition from rough idea to exact reality: What actually is the experience you build? I like it. I think this is a shift that potentially unlocks new value, value that may solve our devaluing problem.

And we've seen it before. The Apple of yesterday was filled with roles that centered on that real experience, and we saw the rewards that came from that, they were next level; like nothing else. And now we see how it's so easily lost when that focus is lost, and they give in to the devaluing.

So I for one am excited to see this solidify further, perhaps it's still grass-roots at the moment, but the roles do exist sparsely here and there. The only question left is if we do fully shift left, what becomes of the traditional Front-end Developer? Perhaps it's the place Full-stack belonged all along.

The Concentrated Water Cooler

andrew@andrewwalpole.com (Andrew Walpole) — Thu, 04 Apr 2024 12:00:00 GMT

The Concentrated Water Cooler

I wrote previously about how remote leadership takes a concerted effort. For companies that have gone and stayed remote due to the pandemic, the work environment has been severely altered. What maybe wasn't so clear is that this means all of the behaviors that make up what work looks like also need reexamination. That includes how co-workers socialize and fill in the gaps of what the company does with the culture of who the company is comprised of.

Water cooler talk is the old slang that stuck around, denoting the place where co-workers might find themselves engaging in conversations beyond the boundaries of work-at-hand. These encounters are casual and provide an opportunity for personalities to come out and tighter relationships to form, one water refill at a time.

"Did you catch the game last night?"

I don't know who talks like that, but it seems to be the right type of thing to use as an example here.

In the age of remote work, there are a lot of culture-building moments like that lost behind the screen divide. So, in similar fashion to remote leadership, building strong remote-based company cultures takes a concerted effort.

Should you schedule a 10-minute zoom or slack huddle every morning? I don't think so. In most cases, trying to emulate the same concepts that work in-person can be an even bigger issue than not doing them at all.

And on top of that, we should also reconsider the affordances of remote work. Like what was previously commute and water cooler time, may now be time spent with the kids before school, or conversations with your partner or friends, delivering value back to you.

While value back to you does help the company, because you and your well-being matter. This doesn't alleviate the need to establish some sort of social culture between people at work; relationships matter, especially at work.

So I propose the concentrated water cooler: The idea that each of those small but now missed daily social interactions a company would accumulate each day across many employees should be viewed as accruing a debt of social need. And thus, as that debt accumulates to a non-trivial amount, it should be paid off in a larger lump sum: Get people together! Once or twice a year, fly them out, plan some events, make it simple, light and fun, invest in your social and cultural capital. Cancel work for two or three days and let people do what they do.

Now I'm going to be particular about this: If you have a big company, split it up. Two's company, three's a crowd, five to thirty is a party and any more than that is a panic attack waiting to happen. Get a few teams or a department together. The folks that already see each other day-in and day-out on zoom. That's it. The goal is relationship building, and the good news is usually it just takes a neat atmosphere, some food and drink, and people will do what they do. Skip the games and agenda, or at least keep it real loose.

The Showy / Hidey Navigation Bar

andrew@andrewwalpole.com (Andrew Walpole) — Mon, 08 Apr 2024 12:00:00 GMT

The Showy / Hidey Navigation Bar

That's definitely the technical term for it. It's that popular navbar pattern where the header disappears above the screen as you scroll down, affording you more content consumption space, but then, as if it were waiting just out of view for you, reappears upon the slightest scroll up.

I've built so many of these over the last few years, I decided to distill the pattern down. Essentially we need just a few ingredients to pull it off:

A container separate from the <header> to sticky down the page.
Some javascript to let us know when we've scrolled up or down.
And if you don't want things to get too janky, an understanding of a minimum height for our header to be.

For our html:

<header>
  <div class="navbar">
    <!-- All the nav stuff-->
  </div>
</header>

Focusing just on the pattern, I've left the innards of the navbar up to you, maybe a logo and a list of links would be good. We really just need the extra .navbar class to position: fixed; while the <header> stays position: static; to hold the space for the navbar. You can see that in our CSS:

header {
  --nav-height: 100px;
  min-height: var(--nav-height);
  
  .navbar {
    --top-position: 0px;
    position:fixed;
    width:100%;
    top: var(--top-position);
    
    transition: top 0.6s;
    
    &.hide:not(:focus-within) {
      --top-position: -100%;
    }
  }
}

As I mentioned, setting the --nav-height is important because without letting the component know how tall it might be, it can't hold any space at the top of the page for the navbar to sit into. So either your first content section will run under the navbar, or if you toggle it between static and fixed positioning when you scroll, it will jump the screen up as it's taken out of the flow. It's all much simpler if you just hold the right amount of pixel space.

<aside>

As an aside, you might think I'm overdoing it here and you should just use position: sticky;. And indeed, this will keep the header in the flow and then sticky it to the top as you scroll. But I've gone down this path a few times and I continue to hit major barriers with sticky and the togglable mobile menu you may eventually build into the nav. So until I can get past that barrier I will continue to recommend position:fixed; for this pattern.

</aside>

Next, we default the top to 0px and change it to -100% when it has the .hide class applied. Add in a transition and your navbar is ready to hide and show elegantly.

It's also worth mentioning the :not(:focus-within) bit, which allows the navbar to not be hidden when we give focus to the nav items. So as you tab through with a keyboard, the navbar will reappear.

Finally, we need some javascript to hook it all together. Though when scroll-driven animations are widely available, perhaps we won't need that at all.

const useShowyHidey = () => {
  let lastScrollTop = 0;
  const navbar = document.querySelector(".navbar");
  
  const toggleNavOnScroll = () => {
    const st = document.documentElement.scrollTop;
    if ( st > lastScrollTop && st > parseInt(getComputedStyle(navbar).getPropertyValue("--nav-height")) ) {
      navbar.classList.add("hide");
    } else if (st < lastScrollTop) {
      navbar.classList.remove("hide");
    }
    lastScrollTop = st <= 0 ? 0 : st;
  }
  
  if (navbar) {
    window.removeEventListener( "scroll", toggleNavOnScroll);
    window.addEventListener( "scroll", toggleNavOnScroll);
  }
}

useShowyHidey();

We listen to the scroll event and toggle the .hide class based on scroll direction.

And here's the whole thing in a codepen!

<p class="codepen" data-height="500" data-default-tab="result" data-slug-hash="eYoMOLp" data-user="walpolea" style="height: 500px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/eYoMOLp"> Showy / Hidey Navigation Bar</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

Fast and Simple APIs with Deno KV

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 12 Sep 2023 12:00:00 GMT

Fast and Simple APIs with Deno KV

In a previous post, I dove into how you can build a like button with Cloudflare Workers and KV. Well, there's finally a new rival service in town: Deno KV. Let's take a look!

In the process of building that same likes service in Deno KV, I have to say I'm quite impressed with how quick and easy it was to go from code to production. I'll outline the steps it took to get things going and then walk through the details.

Sign up for a free Deno Deploy account
Create a new project and choose the "Hello World" template with the Try with Playground button. Similar to Cloudflare's online editor, you get plopped right into an online coding environment.

From there you can code, test and deploy your API until you have it just right. And then optionally you can move that code over to GithHb when you're ready to graduate from the playground experience.

It's also worth noting that you can do all of this from your local machine via deployctl which is Deno Deploy's CLI tool. You just need to create a project and generate an API key in your account to deploy with a command like:

deployctl deploy --token=<YOUR API KEY> --project=<YOUR PROJECT NAME> main.ts

A neat benefit of doing it this way is that you can locally run your code with deno run --allow-net=:8000 --unstable main.ts and even Deno KV will work for full local end-to-end testing.

Writing the API Code

Whether you're working locally or on the Deno playground, setting up our likes API is pretty straightforward.

At the heart of it all, your Deno Deploy code is running a Deno script. So if you want to do web stuff, you'll want to set up a server. That server will have a handler function where you can encounter any request on your project and make it all do something.

And for good measure, check out the respondJSON() helper function I have included which will enable CORS on your endpoint and respond with JSON data. This is very important if you want some other website to be able to use your API:

import { serve } from "https://deno.land/std@0.140.0/http/server.ts";
const kv = await Deno.openKv(); //Initialize Deno KV

async function handler(_req: Request) {
  //Do servery stuff here
}

//start the server
serve(handler);

//A helper to return CORS enabled JSON data
function respondJSON( data, status = 200 ) {
  
  const corsHeaders = {
    'Access-Control-Allow-Origin': '*',
    'Access-Control-Allow-Headers': '*',
    'Access-Control-Allow-Methods': 'GET,HEAD,POST,OPTIONS',
  };

  return new Response(JSON.stringify(data, null, 2),{
    status,
    headers: {
      ...corsHeaders,
      'content-type': 'application/json;charset=UTF-8',
    },
  });
}

We're building a little API, so the servery stuff we want to do is parse out the request information and see if it matches up with a command like retrieving or posting likes:

async function handler(_req: Request) {

  //Browsers love to pre-hit endpoints with an "OPTIONS" method
  //this will ensure we're handling that with CORS
  if( _req.method === "OPTIONS" ) {
    return respondJSON({ok: "OK"});
  }
  
  //the _req object has lots of goodies to use
  //We parse the url sent in to access the parthname and params
  const { method } = _req;
  const url = new URL(_req.url);
  const id = url.searchParams.get('id');
  
  //Define some routes and functions to call when they're hit:
  const routes = {
    '/likes': {
      GET: async (id) => await getLikes(id),
      POST: async (id) => await postLike(id)
    },
    '/likes/reset': {
      GET: async (id) => await resetLikes(id),
    }
  };
  
  //Now, if we match a route and have an id
  //we can call the appropriate route function
  if( routes[url.pathname] && id ) {
    const responseData = await routes[url.pathname]?.[method](id);
    return respondJSON( responseData );
  }

  //oops, if something went wrong return an error
  return respondJSON({ success: false }, 404);
}

Ok, that's the API setup: it has some route logic and knows what functions to call. Let's now set up those functions and finally get to using Deno KV!

//Returns the number of likes an Id has
async function getLikes(id) {

  //Query the value based on the Id
  const res = await kv.get(['likes', id]);

  //If the Id doesn't exist in KV set it to 0
  if( res.value === null ) {
    await kv.set(['likes', id], 0);
  }

  return { success:true, id, likes: res.value ?? 0 };
}

//Adds a like to an Id
async function postLike(id) {

  //Query the current likes and then set it to current+1
  const { likes } = await getLikes(id);
  const res = await kv.set(['likes', id], likes+1 );
  
  //oops the operation failed
  if( !res.ok ) {
    return { success: false, likes }
  }

  return { success: true, id, likes: likes+1 };
}

//Resets the Id's likes to 0.
//TODO: Add a secret password parameter check here
async function resetLikes(id) {

  const res = await kv.set(['likes', id], 0 );
  
  if( !res.ok ) {
    return { success: false }
  }

  return { success: true, id, likes: 0 };
}

And that's it! You can see the production code on github, and see the API in action below:

<p class="codepen" data-height="500" data-default-tab="js,result" data-slug-hash="dywWNzv" data-user="walpolea" style="height: 500px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/dywWNzv"> Likes Counter with Deno KV</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

Overall, I'm really happy with Deno KV. It's simple to use, and paired with the Deno Deploy platform it's quick to get up and running with. If I have to critique something, I do think the documentation could use some zhuzhing, as I did get turned in circles for a few days before figuring things out properly.

I look forward to playing more with Deno KV and the Deploy service. Especially for you front-end folks, this is an incredibly powerful back-end solution to lean on when you need that little bit of persistent or shared state for the thing you're building.

Takeaways from a Weekend Project

andrew@andrewwalpole.com (Andrew Walpole) — Wed, 17 Apr 2024 12:00:00 GMT

Takeaways from a Weekend Project

This weekend I built a simple web app to configure and generate a layout breakouts CSS pattern: Layout Breakouts Builder. Over a few coding sessions, all together, it maybe took ~4 hours of work.

This post isn't so much about the Layout Breakouts pattern, though I do think it's quite useful! Instead, I'd like to quickly reflect on doing projects like this.

So here are my takeaways:

Starting is hard and easy

The idea of starting a project like this seems hard.

I've been wanting to build this thing for months but just couldn't overcome the idea that it would be too hard to get started.

The act of starting was actually quite easy:

Identify first step. Do first step.

In this case, I sat down and said, "ok, what's one thing this thing needs to do?" The answer was that it needed to output some formatted CSS code based on some variable values. So that's where I started. I built a function that took in some parameters and returned formatted text. I stuffed that text into a <pre> tag, and from there I was off to the races on the whole thing.

Having a go-to web stack is useful

As a web developer, having a quick go-to web stack to build projects like this is essential. So many times I've had project ideas of grandeur, only to get stalled immediately in the technical architecture because I didn't have the right tools on-hand to get started.

But not this time. My muscle memory for Astro + Vue hosted on github + vercel has become strong enough that these things faded away into the background, letting me focus on the core functionality.

If you don't have this at-hand, I recommend going into real prototype mode and using something like codepen.

Vueuse useClipboard is great!

One of the daunting flourishes for this app was to add a "copy code" button. I've done this before, actually quite a bit, but it always leaves me feeling drained because the easy way is touted as deprecated, and the harder way has support quirks, and when you try to land on a way forward you're 12 stack-overflow questions in just wishing for a copy( text ) function.

Well @vueuse/core useClipboard to the rescue! I've been using the library quite a bit, and it has a ton of useful Vue composables. But given the haunting scenario I just listed above looming over me, it was an extra chef's kiss moment for me.

The code looked something like this:

import { useClipboard } from '@vueuse/core';
const { copy } = useClipboard();

and then later on my copy button:

<button @click="copy( lb.generateCSS() )">Copy CSS</button>

<br>

Constructable Stylesheets are cool!

Credit given where credit is due: This project happened thanks to the crew over at the Shop Talk Show d-d-d-discord. Someone talked about building a similar code-generating tool, and someone else mentioned using Constructable Stylesheets to make it easy and performant. Well that was it for me, I had to try it.

Spoiler alert: it was easy and is performant! I was able to instantiate a new CSSStyleSheet and apply it to the page, and then use the replaceSync( codeAsText ) function to update the styles as the editor generated them. Worked like a charm!

The code looked something like this:

const sheet = new CSSStyleSheet();
document.adoptedStyleSheets = [sheet];

watch( lb, () => {
  sheet.replaceSync( lb.value.generateCSS() );
});

<br>

Do this (more) often

Lastly, a reminder to myself and suggestion to you all: Do this more often. Make stuff you're passionate about. The process and the result are rewarding in so many ways.

Thoughtful Communication

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 12 Apr 2024 12:00:00 GMT

Thoughtful Communication

I have built up some decent technical skills over the years, but out of all the daily things I do that make me feel effective in executing that technical work within the context of a larger team, communicating stands out as a skill that has the power to make or break the entire pace of a project.

Like most of these types of "soft skills" the secret to them is mostly to build awareness that you're doing them: I'm communicating now, let me consider my words; be thoughtful.

Especially in a world where a lot of working communication now happens via Slack, there's opportunity to put extra thought into your words.

For me, effective communication is about three things:

Setting the proper context for the person or people being communicated to.
Understanding what the main points I'm trying to convey are.
And removing ambiguity, or said another way, including proper clarity.

Context Setting

I think of setting the context as about starting the recipient of your message in a place that is known or familiar to them and then leading them into the new thing you're trying to convey. I'll usually start my messages

"Do you remember that weird bug we discussed last week on clientsite.com, I've done some investigating and here is what I found:"

"I have reviewed the mock-up that you sent me (inserts link to mock-up), I had a few follow-up questions about it:"

"Can we talk about project X? I want to make sure we are aligned on the timing and budget..."

Maybe messages that start out this way seem normal to you. That's probably a good sign. But I do regularly encounter folks launching right into the middle of a thought, and we have to spend time walking things back and uncovering the context to have the effective part of the conversation. I even catch myself doing it, but usually, upon re-reading the message before hitting send, I will realize my opportunities for setting context and make revisions.

Think of it this way: You're in the mode of the thing you are communicating, but they might not be. Say a few words to prepare their brain to take in some new information about a thing that at this moment may have fully fallen out of their focus.

Get to the points

Bullet points that is! I would say that if I ever Slack a message longer than one or two sentences, you can bet it likely has bullet points. It's also a reason why most of the context statements above end in a colon; because once the context is set it's time for bullets:

Bullets empower you to focus on the main point of the message.
You can order them in a way that they build off of each other as you go,
Allowing the recipients to digest the information in a way that is logical.
You can use them to effectively split out information.
Like explaining something that happened
And then listing out the resultant consequences of it happening.

Remove Ambiguity

Ambiguity can be tough to self-assess; you can't get it right every time. It's also a careful balance between being concise and being clear. Can what I just said or wrote be interpreted in multiple ways? If so, it can help to add words that clarify statements, or reframe statements entirely:

"We can start working on this project earlier than expected in order to meet the set deadline, but with the increase in project scope we should revisit the overall development budget. Or said another way, I have concerns that what we're now being asked to do will require more hours of effort."

"On line 36 of CarouselGridTabs.vue you are referencing a property that is not always set via the component props. Can you make sure to account for that situation and think through any other situations the component might have trouble dealing with?"

"Yes, let's revert only today's changes that were pushed to production. To be clear: production should be reverted to reflect it's state from yesterday, and we will keep our newer updates in staging until we are given the greenlight to re-release them"

Like this last example, I think there is a lot of clarity to be given when answering questions. Try not to stick to simple "yes, no, ok" answers and be clear on what the answer entails. Using qualifying words like "only" or "never" or specific dates, versions or other contextual identifiers go a long way in sending clear messages.

Final thoughts

Putting all these things together makes for a decent framework to start communicating effectively:

Ask for clarity if you are having trouble figuring out how to respond
On-ramp your recipient to your message with context
Rre-read all long messages and revise words constantly
Add qualifiers to disambiguate
Cut extraneous information and stick to your main points
Cite your sources
And use lots and lots of lists!

But mostly it takes practice: Be in the moment when communicating; be thoughtful.

Custom Top and Bottom CSS Container Masks

andrew@andrewwalpole.com (Andrew Walpole) — Wed, 29 May 2024 12:00:00 GMT

<style>

.mask-container, .mask-box { /* The image used as a mask for the top of the container / --top-mask-image: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 100"><path d="M0,100S32.06,0,326.72,0c255.72,0,358.35,119.2,673.28,77.47v22.53H0Z"/></svg>'); --top-mask-image-height: 100; / The width of the top mask image / --top-mask-image-width: 1000; / The height of the top mask image */

/* Calculate the height of the top mask */ --top-mask-height: calc( ( var(--top-mask-image-height) / var(--top-mask-image-width) * 100 ) * 1cqw - 2px );

/* Define all the same for the bottom / --bottom-mask-image: url('/static/blog/css-masks/swoop-bottom.svg'); --bottom-mask-image-height: 100; / The width of the bottom mask image / --bottom-mask-image-width: 1000; / The height of the bottom mask image */

/* Calculate the height of the bottom mask */ --bottom-mask-height: calc( ( var(--bottom-mask-image-height) / var(--bottom-mask-image-width) * 100 ) * 1cqw - 2px ); }

.mask-container { /* Define a container to use cqw instead of vw units */ container-type: inline-size;

/* Added bonus: apply padding to container above the .mask-box equal to the negative margin */ & div:has(+ .mask-box) { padding-block-end: var(--top-mask-height); }

/* Added bonus: apply padding to container below the .mask-box equal to the negative margin */ & .mask-box + div { align-items: start; padding-block-start: var(--bottom-mask-height); } }

.mask-box {

/* Apply negative margin to the top and bottom */ margin-block: calc( -1 * var(--top-mask-height) ) calc( -1 * var(--bottom-mask-height) );

/* Pad the container so content doesn't hit the masks */ padding-block: var(--top-mask-height) var(--bottom-mask-height);

/* Apply the masks! */ mask-image: var(--top-mask-image), linear-gradient(transparent var(--top-mask-height), black 0%, black calc( 100% - var(--top-mask-height)), transparent calc( 100% - var(--bottom-mask-height)) ), var(--bottom-mask-image); mask-repeat: no-repeat; mask-position: top, top, bottom; mask-size: 100%, 100%, 100%;

}

.purple-box { min-height:200px; background: linear-gradient(to bottom, rebeccapurple, purple); padding-inline:30px; padding-block-start:30px; color:white; align-content:end; }

.purple-box.align-start { align-content: start; }

.mask-box-demo { background: linear-gradient( 135deg, papayawhip, salmon ); min-height:400px; display:grid; place-items:center; }

.flags-top { --top-mask-image: url('/static/blog/css-masks/mask-flags.svg'); --top-mask-image-height: 100; --top-mask-image-width: 1000; }

.tent-bottom { --bottom-mask-image: url('/static/blog/css-masks/mask-tent-bottom.svg'); --bottom-mask-image-height: 100; --bottom-mask-image-width: 1000; }

.name-top { --top-mask-image: url('/static/blog/css-masks/mask-name-top.svg'); --top-mask-image-height: 100; --top-mask-image-width: 1000; }

.name-bottom { --bottom-mask-image: url('/static/blog/css-masks/mask-name-bottom.svg'); --bottom-mask-image-height: 100; --bottom-mask-image-width: 1000; } </style>

Custom Top and Bottom CSS Container Masks

Here's the use case: You have a design where the top and/or bottom section of a website has a custom shape defining its transition to the container before and/or after it. Essentially, it's a shape mask on the top or bottom of the container with the actual content in the section sandwiched in-between.

Well it turns out that a lot of the methods out there to achieve this effect are pretty old, quite involved, and come with a lot of limitations. Thinking, there must be a better way, I set out to figure it out.

I started by consulting the Shop Talk Discord's #help-desk to see if anyone had any thoughts. We mused a bit about clever border-radius settings and svg clip-path a bit, but I finally got the spark I needed when Hussein Al Hammad shared a very promising demo using multiple mask-image definitions!

It was really a TIL for me that mask-image supported multiple image definitions, similar to background, and that was exactly what I needed to formulate an idea for this CSS trick.

The Masking Methodology

The concept is involved, but not overly complex:

Apply a mask-image (svg or png) to mask the top of the box.
Use the ratio of the width and height of the mask image to calculate the mask height based on the viewport or container width.
Apply a second mask with a linear gradient that starts at the first mask's height and ends at the bottom mask's height.
Apply a third mask to the bottom of the container with the exact same methodology as the top.
Use the top and bottom heights to create padding and negative margin on the box.
As a bonus, if you use a container to store your css variables, you can use the calculated mask heights to apply a padding to the containers above and below the masked box.

One thing to note is that if you're dealing with full-width containers for this effect, you can use vw units in your calculations. But in the following example, I opted for the newer cqw units and defining container-type: inline-size; on the parent of the .mask-box which lets you use this concept on containers less than full viewport width! The great thing is that cqw units are equal to vw units when not within a container.

The .mask-box Code:

.mask-container, .mask-box {
  /* The image used as a mask for the top of the container */
  --top-mask-image: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 100"><path d="M0,100S32.06,0,326.72,0c255.72,0,358.35,119.2,673.28,77.47v22.53H0Z"/></svg>');
  --top-mask-image-height: 100; /* The width of the top mask image */
  --top-mask-image-width: 1000; /* The height of the top mask image */

  /* Calculate the height of the top mask */
  --top-mask-height: calc( ( var(--top-mask-image-height) / var(--top-mask-image-width) * 100 ) * 1cqw - 2px );

  /* Define all the same for the bottom */
  --bottom-mask-image: url('/static/blog/css-masks/swoop-bottom.svg');
  --bottom-mask-image-height: 100; /* The width of the bottom mask image */
  --bottom-mask-image-width: 1000; /* The height of the bottom mask image */

  /* Calculate the height of the bottom mask */
  --bottom-mask-height: calc( ( var(--bottom-mask-image-height) / var(--bottom-mask-image-width) * 100 ) * 1cqw - 2px );
}

.mask-container { 
  /* Define a container to use cqw instead of vw units */
  container-type: inline-size;

  /* Added bonus: apply padding to container above the .mask-box equal to the negative margin */
  & div:has(+ .mask-box) {
    padding-block-end: var(--top-mask-height);
  }

  /* Added bonus: apply padding to container below the .mask-box equal to the negative margin */
  & .mask-box + div {
    align-items: start;
    padding-block-start: var(--bottom-mask-height);
  }
}

.mask-box {
  /* Apply negative margin to the top and bottom */
  margin-block: calc( -1 * var(--top-mask-height) ) calc( -1 * var(--bottom-mask-height) );

  /* Pad the container so content doesn't hit the masks */
  padding-block: var(--top-mask-height) var(--bottom-mask-height);
  
  /* Apply the three masks! */
  mask-image: var(--top-mask-image),
              linear-gradient(transparent var(--top-mask-height), black 0%, black calc( 100% - var(--top-mask-height)), transparent calc( 100% - var(--bottom-mask-height)) ),
              var(--bottom-mask-image);
  mask-repeat: no-repeat;
  mask-position: top, top, bottom;
  mask-size: 100%, 100%, 100%; /* You may need to increase the width to 101% on the svg masks to compensate for strange sizing behavior in Firefox */
}

Rather than piece it together bit by bit, here is the whole thing! I tried to comment each relevant item. A few things to note though:

The sibling selectors that add padding to the containers above and below the .mask-box aren't required, but it does help if you don't want to guess or hardcode at where you need to have content stop before it underlaps the mask.
The masks themselves can be any image, but I find svg either inlined or referenced as a file to be quite good. For png images, any transparency in the file will not be part of the mask. The pngs will also tend to get fuzzy as they scale up.

With the CSS above, you can use your .mask-box like this:

<div class="mask-container">
  <div>
    <span>The Content Above the Effect</span>
  </div>

  <div class="mask-box">
    <h3>I am a .mask-box</h3>
  </div>

  <div>
    <span>The Content Below the Effect</span>
  </div>
</div>

<div class="mask-container"> <div class="purple-box"> <span>The Content Above the Effect</span> </div>

<div class="purple-box align-start"> <span>The Content Below the Effect</span> </div> </div>

View it on Codepen

Creating Masks

Once this pattern is in place, creating masks is very easy! You can really use any image, though I may recommend a pretty wide sizing ratio, as the mask scales proportionally and may get quite tall on wide screens. For my demos I found a 1000px by 100px sizing was nice!

You can easily create sets of classes to apply the new images and sizing:

.flags-top {
  --top-mask-image: url('/static/blog/css-masks/mask-flags.svg');
  --top-mask-image-height: 100;
  --top-mask-image-width: 1000;
}

.tent-bottom {
  --bottom-mask-image: url('/static/blog/css-masks/mask-tent-bottom.svg');
  --bottom-mask-image-height: 100;
  --bottom-mask-image-width: 1000;
}

<div class="mask-container"> <div class="purple-box"> <span>The Content Above the Effect</span> </div>

<div class="purple-box align-start"> <span>The Content Below the Effect</span> </div> </div>

.name-top {
  --top-mask-image: url('/static/blog/css-masks/mask-name-top.png');
  --top-mask-image-height: 100;
  --top-mask-image-width: 1000;
}

.name-bottom {
  --bottom-mask-image: url('/static/blog/css-masks/mask-name-bottom.png');
  --bottom-mask-image-height: 100;
  --bottom-mask-image-width: 1000;
}

<div class="mask-container"> <div class="purple-box"> <span>The Content Above the Effect</span> </div>

<div class="purple-box align-start"> <span>The Content Below the Effect</span> </div> </div>

And that's it! This is definitely a CSS trick, but not one that is too overly complicated, especially in comparison to other methods out there. I also like how robust it is. The masks scale responsively very well, and can be varied in size and complexity. You can even use transparent to black gradients on png masks to achieve some interesting fade effects. If you use this technique I would love to see what you do with it, I'm sure it can be pushed even further!

Surprise for a programmer on Birthday

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 03 May 2024 12:00:00 GMT

Surprise for a programmer on Birthday

Was the title of a stack-overflow post from 2010 that no longer exists. If you try to visit you'll see:

It was posted by my then-cool-girlfriend, now-incredible-wife as a genuine and innocent question about code. Little did she know the contentious pretension and division she was about to unleash upon the stack-overflow community.

The Story

Unbeknownst to me, a few months before my 25th birthday, she cleverly posted the question under a pseudonym:

Surprise for a programmer on Birthday

Help! My boyfriend's birthday is next month. Since he is a programmer, I'd love to make him a cake with the code for "happy birthday" (and perhaps something awesome) written in icing on top. Not being a programmer myself, I have no idea where to begin. Any suggestions would be greatly appreciated!

Within hours the post went viral. Lots of upvotes, answers and comments poured in. For the most part it was a fun time!

A programmer with a girlfriend? - Bob Kaufman

The cake is a lie! - OMG Ponies

One-twelth of the programmers on this site (approx 12,000 people) have a birthday next month. Now all of them who have girlfriends are going to expect an awesome cake with code. Two of those three programmers are going to be very disappointed. - Jeffrey L Whitledge

I think Jeffrey's count is wrong. I remember a programmer I used to work with, and she had a girlfriend. - Windows programmer

Very amusingly, many questioned the authenticity of the post and OP entirely:

I call B.S. on this whole question. This so-called "programmer's girlfriend", leading us on with this "penelope" handle, must know more than she's letting on, if she's posting on StackOverflow. - Jeff Meatball Yang

Why are you all assuming that "Penelope" is not a guy? - Vicky

There is statistical and conclusive proof she is NOT a programmer and is NOT a guy - she responded to every post (as far as I could find) - Mark Schultheiss

But as quickly as the party started, so too the sticklers arrived:

This question has been closed.

The question was voted for closure. You see, this wasn't the first cake question to cause a tizzy. A similar question had previously been asked proposed a wedding cake, causing strict community guidelines to be put in place about the content and intention of the questions posted on stack-overflow. Fun? Girlfriends and boyfriends? Cake? "No thanks!" said stack-overflow.

But in the democratic spirit that the platform provided, the crowd fought back!

Voting to reopen just cause this question is awesome. - Earlz

People closing this lovely question, you do realize that if you get the required votes, this question will be immediately re-opened by hordes of fans? - JSBangs

My only gripe for this question is it definitely should've been CW, but thats not enough for it to be closed. Surely we can have some fun on here every once in a while :) - Earlz

@haters - this question stays! - pokstad

The question was voted to be reopened!

And closed again!

Back up!

The war raged on for days. Users chimed in, some now incredulous that this one question had earned her account more reputation points and gold badges than many of them had accumulated in years of platform use.

LIGHTEN UP PEOPLE! This is starting to tick me off. If it bothers you that much that penelope has a few gold stickers more than you...you have some major issues. - Epaga

After the main hubbub subsided, I was let in early on the fun. It ended up being the best gift of all to see such an amusing event in internet history caused on my behalf by my better half.

Cake baked and party concluded, a final update was made, with pictures as proof:

UPDATE:

hey everyone! sorry it has taken me so long to post pics. the cake was a HUGE success and he enjoyed every bite. but most of all, he loved the "actionscript birthday message" that graced the top of it! i wanted to thank you all for your suggestions. i have printed them and will make many more "coded" cakes as the holidays go by. i really want to do the heart "equation" for valentines day! i took peter toroks idea and tailored it for andrew's birthday cake (i asked a programmer to help me make it fit on the cake!). needless to say, andrew and all of his programmer buddies got a kick out of it and gobbled up the dark chocolate, peanut butter cake that was underneath all that nerdy icing-y goodness! here is proof:

so thank you ALL again! i had a lot of fun making the cake and thanks to all of you, he'll never forget it, or this birthday! -tania

Conclusion

With the question's utility brought to an end, it was closed and locked for good. Sometime later it was removed altogether. I used the wayback machine and stack printer's archive to piece the story back together and create this more official retelling. Check those links if you want to read through all of the other comments and answers given.

About a year later, the story was referenced in a blog post about code-decorated cakes and a few years ago I attempted to archive an abbreviated version of this story as a twitter thread.

Finally, I'll go ahead and leave you with this codepen recreation of the cake itself, running the code on top of it:

<p class="codepen" data-height="800" data-default-tab="result" data-slug-hash="PogvaJp" data-user="walpolea" style="height: 800px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/walpolea/pen/PogvaJp"> Surprise for a programmer on Birthday</a> by Andrew (<a href="https://codepen.io/walpolea">@walpolea</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

<style>

blockquote, blockquote > * { font-size: 90% !important; }

.gallery { margin-inline:Auto; max-width:800px; display:grid; grid-template-columns: 1fr 1fr;

.wide { grid-column: 1/ -1; } }

</style>

Opinions for Writing Good CSS

andrew@andrewwalpole.com (Andrew Walpole) — Tue, 11 Jun 2024 12:00:00 GMT

Opinions for Writing Good CSS

CSS can be hard and frustrating for beginners. The nature of the language is so different from traditional programming languages. While it’s easy to learn the parts: selectors, properties, etc. It's much tougher to practically compose multiple ideas together to make something new or more complex happen.

There just aren’t a lot of straight paths in CSS. With multiple ways to accomplish the same concepts, it can be difficult to figure out a solution that is new to you, and also to know if it’s the right or best approach. If "it depends" is a telling mantra of the senior dev, CSS is indeed a language written to fill that space in an experienced developer's heart.

As hard as it might be to fill the knowledge gap of knowing when and where to reach for what, that's what makes it such a beautiful language. CSS is quite robust and capable, as individual declarations can be complexly composed together into a lovely symphony of style and layout.

One of my core pieces of advice is: to be flexible, be inflexible. And I think that's really what this post is about with regard to CSS. Due to the nature of how complex CSS can and should be when written, it's important, to perhaps, essential to have opinions about how you write it.

Opinions

As someone who has taught CSS to students and junior developers, take them or leave them, these are some of the opinions I've built up that I think help you in writing good CSS from day one.

Don't include CSS that isn't needed

Too obvious? Maybe not! It's often necessary to experiment with things – don't be afraid of that! – but clean up failed experiments right away. Once you let something unnecessary linger in the codebase no one in the future will be able to easily tell if it's necessary or not – not even you!

Use comments

Specifically, sometimes you need to write some CSS that either you aren't 100% confident about why you need it. This is the perfect place to express that skepticism in a comment, both for you and anyone else reviewing the code in the future. While there are other good reasons to use comments, including this confidence metadata for a solution opens up quick-win opportunities to revisit things later in an effort to refactor and improve the codebase. It also may signal spots where tough-to-track bugs may appear later.

Avoid using Ids for CSS selection

Embrace the cascade. In doing that, you'll find that one of the core concepts is being adept at managing specificity in your code. And in doing that, the Id selector is just too potent to get used to using. For more information about this I can't recommend enough this recent talk by Mayank.

Avoid using !important

Also related to managing specificity well, !important is a code smell. While there are some rare occasions where you absolutely need it (especially with inherited or older codebases), if you find yourself using it, there is a bigger issue somewhere. Stop and search out the issue first before deciding it is the solution.

Figure out a system for consistency

No system is a bad system, and half a system is still a system. Naming, structure, selecting, vars, nesting, scoping; there are so many places in CSS where systematic consistency will go far in making your code revisitable and maintainable. Have a system of any kind, document it, and use it. As far as what system you should use, that’s all up to you. Do what makes sense. From BEM to CUBE to making it up on the spot, there are a lot of options and most aren’t wrong considering the alternative.

Resets and defaults are useful

In a related vein to systematizing, a good reset can take some antiquated complexities out of starting with CSS. I recommend checking out Andy Bell's and Josh Comeau's modern reset ideas.

Defaults are similar to resets, but can be used in a few clever ways. Define default values globally. These can serve your system as smart fallbacks. But also define defaults on things you can't afford to miss. The classic example being to select and apply a border to all images that have no alt attribute defined:

img:not([alt]) {
  border: 5px solid red;
}

Clever selections of things you should be attending to aren't just a party trick, they work for you in complex builds, serving as a reminder to enforce your rules and system.

Understand the codebase

This might be more specific to working on a team, but it's important to spend extra time reading and internalizing the CSS you aren't writing in a project. Aligning your coding style and the tools you reach for to the system in place is essential to keep the codebase feeling cohesive as you pitch in to build it. Get to know your reset, utility classes, global CSS vars, typography, colors, and spacing systems before moving forward on contributing your own components and styles.

Lean heavily on CSS Variables

CSS variables aren't just about saving you keystrokes. Set up CSS variables as if you're gathering up your tools to implement your design. "I know I'll need these colors, backgrounds, pixel values, etc." Doing this will start to form a cohesive API of what makes the thing you're styling its specific style. In most cases you'll be set up to play with values easily and customize styling and layout across variations of your subject.

Assess responsive requirements of a design first

Before writing any CSS, especially layout CSS, have a good long sit-down with your design. It's essential to formulate an understanding of how the next thing you're going to build behaves responsively. Clear responsive understanding will lead to cleaner, more elegant and thoughtful CSS solutions. Conversely, attempting to apply layout changes to a subject after one specific sizing has been created can often lead to brittle, band-aided solutions.

Avoid margins on components and padding on containers

I'm not in the no margins ever club, but I do align with some of those points. Margin is special in that it often conveys spacing definitions between items. In a mode where you're styling a component, which often does not yet have an established context, you will want to wait to define a margin until the component is instanced into a final context.

Similarly, in styling something meant to contain or slot in some other unknown contextual item, be careful not to fix yourself to a specific set of padding so that it can be appropriately defined in each instance used.

There are exceptions to this depending on how flexible your system or design needs to be, but it helps to start from a cautious mindset and then explicitly opt-in to marrying spacing to any component.

Don't paste CSS

I can't emphasize this enough, especially for the junior devs. Do. Not. Paste. CSS. Co-pilot for CSS? No. Figma styles for CSS? No. Grab all those cool styles from someone else's component? No.

Can you be informed by all of those things? Yes! Absolutely! But resist the urge to copy and paste large blocks of CSS as writing out each property definition will both make you a better CSS developer and engage your brain in a way that allows you to always make explicit and understood choices about the CSS you are writing.

Wrapping up

I'm sure I could continue to build up this list until it matched my personal style of writing CSS. If you've disagreed with any of these, that's fine, they're just my opinions. But I do think I've picked a set that can be generally agreed upon and that I've seen provide a solid base for helping folks simplify their approach to CSS and end up with cleaner, better code. And I hope this post begs the question, What CSS opinions do you have?

Build Your Next App with Durable Redis

andrew@andrewwalpole.com (Andrew Walpole) — Fri, 01 Nov 2024 12:00:00 GMT

Build Your Next App with Durable Redis

Connecting your website or app to a database unlocks an immense amount of possibilities; being able to create something that adapts to usage over time is a critical enabling factor to compounding work that a computer can do for a person.

In the past I've written at length about a few of the KV store offerings out there, like Cloudflare KV and Deno KV. I like them because because they are some of the simplest data services that you can tap into to bring your projects up to that next level of being dynamically data-driven.

With simple keys and values though, there are limitations around how far you can push those stores into behaving like a fully modeled application database. You might think then, that as you need to graduate up to another level of database capability you may need to bite the bullet and jump into something with way more setup overhead like Postgres, MongoDB or some similar equivalent.

What's Redis?

I'll be honest, for as long as Redis has been around, I've mostly been oblivious to it. Academically I get it: It's a database that capitalizes on the speed of running in-memory to make getting and setting data fast. So as a proxy layer that sits between your big slow database and your user, it can be applied into your architecture as a means to squeeze out performance and scalability of your system.

Given that summation, it's hopefully apparent that Redis really doesn't sound like something to be reaching for for small projects and experiments.

What's Durable Redis

Here's where that conclusion flips on its head a bit.

Redis is built with the ability to be hosted as a durable solution. While usually it isn't when used in the proxying context described above, durability is really what Redis lacks to be a stand-alone database solution. Essentially this means that as Redis is interacted with in-memory, it also performs the work of syncing and saving data to disk, allowing an outage to not cause total loss of data. This may slow down performance a bit, but trades off excellently with the need to simplify your architecture and choose Redis as a primary data source.

Durable Redis is pretty cool. The database itself is NoSQL in concept, bringing the simplicity of a KV store, but also going beyond with having an understanding of many different value types which can be traversed, compiled, searched and queried quite powerfully.

How to get started with Durable Redis

I was introduced to Redis through Vercel KV. Digging in there though, you quickly realize that the service is mostly a light wrapper around Upstash, one of the only hosted durable Redis services I've been able to find. If you're looking to host it yourself, this really isn't the article for you, but I imagine it could be figured out pretty well with Docker.

Maybe worth mentioning also that Amazon has MemoryDB which touts itself as a Redis compatible, durable data solution; I haven't tried it out but it sounds possibly comparable.

Upstash has quite decent pay-as-you-go pricing, and a generous free tier, making it ideal for side-projects or small apps.

The basics

Upstash walks you through setting up your first database, and when finished provides you the tokens you need to access the database via their SDK which comes in the usual various flavors.

For me, I've been using it through Astro SSR, which allows me to easily build server-side application logic that can interact with the DB, or create API endpoints that can proxy access to the client-side.

Essentially, like any KV store, Redis allows you to set data at keys; up to 250 million of them per instance! So even simple sets and gets will go quite far for you. Let's take a look at simple CRUD functions before talking about some useful capabilities:

redis-crud.js


import { Redis } from '@upstash/redis'

const redis = new Redis({
  url: 'https://your-db-instance-name.upstash.io',
  token: '********',
})

/**
 * Create or Update a JSON object using `JSON.SET`.
 */
export async function createOrUpdateObject(key, data, path = '$') {
  return await redis.json.set(key, path, data); // '$' indicates the root path
}

/**
 * Retrieve a JSON object by key using `JSON.GET`.
 */
export async function getObject(key, path = '$') {
  return await redis.json.get(key, path); // '$' retrieves the entire object
}

/**
 * Delete an object using `DEL`.
 */
export async function deleteObject(key, path = '$') {
  return await redis.json.del(key, path);
}

It doesn't get much easier than that folks! Four critical operations handled in three simple functions.

If you noticed the path = '$' bit, essentially this has to do with Redis understanding JSON to a fair extent. We can use the JSON commands to modify objects and arrays and nested values within sub-parts of object models rather than continuously retrieving and re-storing large objects over each call.

A few Redis tips

To take Redis further, I found the pattern of adding types to my keys very useful. For example, say you have multiple types of data you want to store in a Redis database. Well, the top-level set of keys are flat, so you can use the keys themselves to delineate data.

Keys like, user:12345 or todo:98765 where the prefix defines the data type and the suffix defines the Id, allows for a great way to scope down your data sets. You can then use SCAN which accepts a glob-style pattern to query your keys by type:

export async function getAllObjectsOfType(type) {

  const pattern = `${type}:*`;
  let cursor = 0;
  let keys = [];
  
  //Use SCAN to retrieve all the keys
  do {
    const [nextCursor, scanKeys] = await redis.scan(cursor, { match: pattern });
    cursor = parseInt(nextCursor);
    keys = keys.concat(scanKeys);
  } while (cursor !== 0);
  
  if (keys.length === 0) return [];
  
  //Use JSON.MGET to retrieve all the objects at those keys:
  return await redis.json.mget(keys, '$');
}

We can write a simple function to check if a key exists:

export async function keyExists(key) {
  return await redis.exists(key);
}

We can also write functions to modify JSON primitives, like adding/removing items in arrays, flipping boolean values, and incrementing or decrementing numeric values. Here are a few examples of those:


export function redisKey(type, objectId) {
  return `${type}:${objectId}`;
}

/**
 * Toggle a boolean field in a JSON object using `JSON.TOGGLE`.
 */
export async function toggleBooleanField(type, objectId, path) {
  const key = redisKey(type, objectId);

  // Use `JSON.TOGGLE` to toggle the boolean field
  const newValue = await redis.json.toggle(key, path);

  // Return the new boolean value
  return newValue;
}


/**
 * Increment a numeric field in a JSON object using `JSON.NUMINCRBY`.
 */
export async function incrementObjectField(type, objectId, path, incrementBy) {
  const key = redisKey(type, objectId);
  return await redis.json.numincrby(key, path, incrementBy);
}

/**
 * Append a value to an array in a JSON object using `JSON.ARRAPPEND`.
 */
export async function appendToArray(type, objectId, path, value) {
  
  const key = redisKey(type, objectId);
  const exists = await redis.exists(key);
  
  if (!exists) {
    return await redis.json.set(key, path, [value]);
  } else {
    return await redis.json.arrappend(key, path, value);
  }
}

Conclusion

I've just got done with my first foray into Durable Redis while building an app for a client using Astro and Vercel KV. I was impressed with the sweet spot of capability and simplicity in getting up and running with it, and hopefully I've shown you that this is a great option for projects that are not overly complex but need a bit more than a simple KV or object store. I think this is a great option to help get your next fun idea off the ground and even scale up a bit as it grows into something bigger.

Audit Content Reads with Cloudflare KV

andrew@andrewwalpole.com (Andrew Walpole) — Mon, 27 Feb 2023 12:00:00 GMT

Audit Content Reads with Cloudflare KV

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 Islands and client:visible

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:

<template>
  <div style="visibility:hidden;"></div>
</template>

<script setup>

import { ref, onMounted } from "vue";

const endpoint = 'https://pagereader.walpolea.workers.dev/';
const {title} = defineProps(['title']);
const reads = ref(undefined);

const postRead = async (title) => {

  if(title) {
    const response = await ( await fetch(endpoint, {
      method: 'POST',
      headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({title})
    })).json();

    reads.value = response.reads;
  } 
}

onMounted( () => {
  postRead( title );
});

</script>

The component is comprised of a hidden empty <div> and takes a title prop, which onMounted(), is used to ping the pagereader service.

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

<PageReader title={Astro.url.pathname} client:visible />

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.