Two articles on SPA or SPA-like sites vs alternatives

I missed these two articles by Tom MacWright from last year.

Second-guessing the modern web, 10 May 2020
If not SPAs, What?, 28 October 2020

In both, he outlines few upsides and downsides about the single page app (SPA) approach to websites and has a few points that I have really struggled to articulate in the past.

From “Second-guessing”:

There is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are trying to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.

I’ve dabbled with React and Vue in small side projects and experiments. But the point above is the big reason I’ve never taken the time to sit down and learn either of them properly. For almost every client site I’ve ever done, it just didn’t make sense to make it an SPA.

And I’m not 100% sure, but I think this might contribute to longevity. Some of my clients are still working with the same sites I built for them nearly 10 years ago, a few with just minor security-related updates in the meantime and no other maintenance strictly required. That’s not to say that those sites couldn’t use a “lick of paint” to bring them in to the 2020s; the point is that they work. And for organizations working on really tight budgets, or budgets that fluctuate wildly due to public funding, stability is really important. They can’t afford a developer on retainer to keep things running smoothly.

But of course the SPA vibe is pretty attractive, particularly for cultural orgs. MacWright has some decent alternatives suggested in “If not SPAs” including Turbolinks, Barba.js, and Will also mention MoOx/pjax since I’ve used it before for page transitions with very good results, but probably won’t use it in the future as it hasn’t been updated in a while.

And again, there’s the rub. The more non-native scripts, plugins, etc I use in a project, the more likely that it’s going to be a major headache (and thus major time/money for the client) for me to change things down the line if or when that bit of tech is no longer supported or has changed significantly.

So it’s not even so much about being wary of React or Vue, it’s about not making assumptions, being cautious and cognizant of future needs or restrictions when proposing a tech stack. Any tech stack you choose will ultimately become a ball-and-chain, not just those based on JavaScript frameworks. It’s just that the ball can sometimes be heavier than it needed to be, and you can anticipate that with a little foresight.


Some long-winded thoughts on privacy policies and consent popups

This Q&A is compiled from conversations I have had with many, many clients and collaborators who have had a hard time navigating things like the GDPR, privacy policies, cookie notices, consent messaging, and other related topics.

Here are all the questions covered below:

Read more


Edit your hosts file on a Mac to spoof DNS changes

Sometimes I need to spoof DNS changes before they go live, like when double-checking the behavior of a site in a production environment before the site launches.

You can do this by editing your Hosts file. By editing your Hosts file, you’re basically telling your computer, “Hey, ignore what all of the DNS caches are telling you about where to find this site. This is where you should actually look for it.”

All great and useful, but I forget how to do this every time. For future reference:

Open up Terminal (the command line) and run

sudo nano /etc/hosts

You’ll likely be prompted to enter the password for the user you have set up on your computer since sudo tells the computer to execute a command as a superuser, and it needs to make sure you’re authorized to do that. Once the command runs, the file you specified (/etc/hosts) will be opened up in the GNU nano command line text editor. Nano can be a little confusing if it’s super new to you, refer to the docs or search around, guides abound online.

There will probably be a bit of content in this file already. Some of it might be comments, text preceded by a # symbol. Don’t change the existing contents unless you know what the effect will be and you’re really sure about it!

Instead, on a new line at the base, just add a new line with the IP address you want to point to followed by the URL without the protocol (so, not

Once you’ve changed it, save the file and exit nano. When you load up the URL in a browser, you should be seeing whatever resources are available at the IP address you’ve specified. If you’re still seeing the “old” site, try loading it in a private browsing window.

Don’t forget to change it back when you’re done.


General maintenance tips for website owners

This was originally written as a bit of a guide for my clients and collaborators, an aggregation of similar tips I have given to many of them individually in the past in so many shorter emails and conversations. Since it is relevant to most website owners though regardless of their relationship with me, I decided to share it more broadly here.

Websites require maintenance, even those with the smallest of footprints.

This is what I would consider “bare minimum” website-related maintenance tasks including checking your payment methods and contact details, reviewing your login and security practices, performing updates and taking backups, and checking your privacy policy.

The vast majority of these tasks do not require a web developer or IT person, almost anyone can perform this maintenance so long as you have access to necessary logins, can follow instructions, and are willing to set aside the time.

I say “almost anyone” because some people are understandably uncomfortable with wading in to this stuff, they may get confused or a bit daunted by the user interfaces they have to use. In that case, just be sure that you are working with someone that can hold your hand through it or can simply do it for you. Also, not everyone has access to all of their service providers. If you’re in a different situation, for example if you retain a web developer, design studio, or IT person to continuously maintain your website, then these are worthy topics to discuss with them but ultimately they will probably need to complete these tasks for you.

Of course there are other maintenance tasks that are super worthwhile. For example it might be worth checking search performance or 404 pages with Google Search Console if search engine optimization (SEO) is important to you, or to check analytics if that’s relevant to your site. And it’s worth speaking to your web developer about front-end maintenance. CSS and JavaScript gets better all the time, as do browsers, so old front-end behavior can really date a site.

But that’s all just the cherry on top. If you complete the tasks below I’d say you’re pretty golden, probably a step ahead of 80% of the site owners I’ve come across.

If you do fall behind on maintenance (it happens to the best of us!) and something goes wrong, at the very bottom you’ll find some tips on what to do if your site goes down suddenly.

Read more


Maintenance is everything

I don’t expect most of the opinions that I hold now to have the same shape in 10, 20. years. I don’t think any of us is the same person every day, identity shifts with every tiny experience, so it’d be a silly thing to suggest or expect.

But one that I think might stick, the thing that might last if I ever wrote a manifesto: Maintenance is everything.

Bikes, physical health, mental health, roads, relationships, furniture, websites, clothing, parks, plants, sewers.

If it’s worth creating/buying/doing in the first place, it’s usually worth maintaining. And I love maintenance, fixing things, so that’s lucky! (Don’t like cleaning so much, which is another major part of physical maintenance, but I’m working on that.)

The problem is that new/shiny is a lot more lucrative than old/broken (more on this). How do we shift that mindset?


Dev environment issue related to MySQL and missing OpenSSL v1.0.0 symlink

I woke up early this morning to get some work done before a call and suddenly my local dev environment stopped working without warning and with seemingly no reason. The root issue was that MySQL wouldn’t work, /usr/local/opt/openssl/lib/libssl.1.0.0.dylib was not loading.

TL;DR: This may have been related to some automatic cleanup on Homebrew’s part. But regardless, a simple restart sorted it. If this happens again and restarting doesn’t sort it, try uninstalling and reinstalling MySQL.

The rest of the detail is below for posterity if I run in to this in the future.

Read more


Questions and questionable answers on the blockchain and cryptocurrencies

Quick note: This post is way too long… but it felt weird to split it up considering it all came from the same burst of research, and I didn’t want to cut some of the finer details because I’m using this for reference. So apologies! ¯\_(ツ)_/¯

Illustration of blocks in yellow, pink, and blue

Illustration of blocks in blue, orange, and yellow

I’ve been aware of cryptocurrencies and the blockchain for a long time but have never taken a moment to dig in. Recently there’s been a lot of buzz around the blockchain amongst people I know and like. Some of these people have historically been pretty skeptical about it, as have I, so this has made me curious about what might have changed.

This is an attempt to get to the bottom of a few concepts and questions that have been lingering in my mind. It starts with a very basic attempt to describe the blockchain and crypto and then moves on to topics I’m particularly concerned about, especially energy usage, risk / legality, and the impact on the digital divide. I’m calling these answers “questionable” because I’m definitely still learning, but I’ve done enough research and thinking around it all that I’m comfortable with what I’ve written here. If you read any of this and think I’ve gotten something wrong, let me know.

I’m most interested in why non-fungible tokens (NFTs) are getting so much hype right this moment but decided to focus on the blockchain and crypto first since it forms the foundation of NFTs. A dive in to NFTs is to come separately.

Illustration of blocks in blue, yellow, and pink

What is the blockchain?

The blockchain is a way of storing data cryptographically. You can think of the term quite literally: blocks of data are chained together to form an ever-growing and nearly immutable ledger. The blockchain as we know it was invented in 2008 and was implemented for the first time with the Bitcoin protocol in 2009, creating the cryptocurrency bitcoin.

The blockchain is decentralized, meaning it isn’t stored in any one place. It is instead distributed across every different computer, or node, that has interacted with it on a particular network. The blockchain is one of many decentralized technologies, but it is more of a concept than a unique protocol such as Dat or the InterPlanetary File System (IPFS) (neither use the blockchain, to be clear). There are many different blockchain protocols with different advantages.

On the blockchain, each block of data and the way it is connected to the previous block is permanent and verifiable without the need for any third-party involvement or intervention. Because of this, one of the most common applications for the blockchain that we’ve seen so far is cryptocurrency transactions and investment.

But it’s worth noting that the blockchain can be useful for much more than cryptocurrencies and decentralized finance (DeFi). I’m particularly interested in the Handshake Network, a decentralized domain name system (DNS) alternative. And the blockchain could also be used to track the supply chain to prove with 99.9% certainty that a particular product’s manufacturing didn’t involve things like child labor.

Read more


Fix for overflow at top / bottom of screen when using CSS Scroll Snap

I’m currently working on a site that uses CSS Scroll Snap to frame some of the content nicely as you scroll through. In Chrome though, I was getting weird overflow issues at the top and bottom of the screen. If I scrolled to the bottom and then kept attempting to scroll down, it would gradually add more and more length to the page. Same with scrolling back up.

Adding overscroll-behavior-y: none; to the body element sorted it out. Read more about overscroll-behavior on MDN.

I originally tried to add this property to the html element since that’s the element with scroll-snap-type: y mandatory;. This didn’t work though, it seems that overscroll-behavior has to be on body.


How to embed an channel using an `iframe` in HTML

A friend got in touch recently about using this WordPress theme, asking if it would be possible to integrate support for channels in the theme. I suggested that it’s probably out of scope for the theme but could be great as a plugin that integrates the API, definitely something I’d be interested in making. Started thinking about how it might work best, wanted to keep it relatively simple and such since ideally I’d want it to work with classic WP and Gutenberg.

Turns out, I was way overcomplicating it. I mentioned the plugin idea to Sam and he suggested just doing an iframe embed like they do on the lovely blog. Of course! 🤦🏻‍♀️

I’d still like to explore the plugin idea at some point since it would offer a few more opportunities (see things to consider about embeds below, particularly the fact that embed support is undocumented), but this seems like a nice way of doing it in the meantime.

Example below of Gemma’s Internet Explorers channel as an embed:

How it works

This is the embed code for that particular iframe:

<iframe style="border:none;" width="100%" height="590" src="" title="Gemma Copeland’s channel “Internet Explorers”"></iframe>

If you’re less familiar with HTML, here’s what’s going on.

The opening and closing HTML tags <iframe></iframe> stand for an Inline Frame element. This type of element nests a separate resource like a webpage on to the page you’re currently looking at. It contains the attributes style, width, height, src, and title to modify the way it behaves.

Since many browsers render an iframe with a border by default, we’re using the style attribute to get rid of the border on this iframe. You can also style HTML elements with classes and CSS, but we’re using this technique, known as inline styles, for simplicity’s sake.

The width and height attributes specify—you guessed it—the width and height of the iframe. If you were missing either of these attributes, the iframe would collapse. According to the standards, these values should both be set as integers which the browser interprets as pixels. That said, browsers seem to be able to interpret a 100% width correctly, meaning that it fills 100% of the width of its container. If you want to stick to standards, you could add a high width value and then add max-width:100%; to your inline styles.

The src or “source” attribute tells the browser what content you want to embed. Without it, you’d just have an empty iframe. The URL we’re using here is exactly the same as the URL for Gemma’s actual Internet Explorers channel (, with the addition of /embed on the end. If you try visiting this URL,, you’ll see that it is essentially a stripped-down version of the original Channel page that is more suitable for embedding.

The title attribute indicates the contents of the iframe. It can be important for accessibility since some screen readers will use it.

Things to consider before embedding content on your site

There are a few things worth keeping in mind if you decide to try this. These notes apply to any embedded content, regardless of where it’s coming from.

1. An iframe embeds the tracking and cookie behavior of its source, not just its contents

When you embed another webpage on your site with an iframe, it will behave the exact same way as if you had visited the source website. In other words, that website may collect data about your visitors, use cookies, embed additional third-party tracking, or monitor your visitors’ interaction with the embedded content.

You should be sure that you’re ok with this before including an embed on your site. Personally, this is one reason why I don’t use embeds very often.

I feel comfortable embedding an channel in this case because it’s for demonstration purposes, they adhere to the GDPR, and I’m satisfied by the way they handle data according to their privacy policy.

2. The accessibility of an iframe embed depends mostly on the source page

It’s recommended to add a title attribute to your embeds for better accessibility, but that’s pretty much where your accessibility control stops. If the source page hasn’t been built with accessibility in mind, it may be difficult to browse for people that use alternative ways to navigate the web.

Unfortunately, channel embed pages are missing accessibility features such as unique title elements, descriptive alt texts for the block images, and semantic elements such as <figure> or <figcaption>. This is kind of understandable though since these embed pages are an undocumented feature, something that they probably made more for their own use, and they’re no doubt focusing their main efforts on the public-facing product. Would love to see it tweaked though, particularly since they use these embeds on their own blog.

3. It’s nearly impossible to change the way an embed looks

There’s very little you can do to change the look of an embed. You can change the way the frame itself appears, like removing the default border as we’ve done in the example above, but you usually can’t change the contents of the embed.

Sometimes a platform will accept additional attributes or URL parameters that change an embed’s functionality. YouTube is an example, see their Player Parameters documentation. But this just changes the general functionality, it doesn’t allow you to actually change the placement of the play button or change the controls from red to blue. You can use some fiddly JavaScript to get things looking like you want, but it’s pretty hacky.

Instead, if you want to heavily customize the way that the embed contents look, you should probably integrate the content using the platform’s API if they offer it. This is what we did on Gemma’s site, using the API and Eleventy to add channels directly to her homepage. This content inherits her site’s styles, so it’s more in keeping with the look and feel of her site.

4. Embeds can break

Broken links are an ever-present problem on the web, people are always changing URLs and taking down content. A broken link is only noticeable if you click it, whereas a broken iframe can look pretty crap. If this would bother you, then you might want to be careful about how much embedded content you include on your site.

Besides this, the source website can restrict which domains are allowed to embed their content at any time. This is unlikely to happen with a platform like Vimeo or YouTube which offer embeds as a part of their advertised functionality. But with this channel embed for example, might decide that they only want to allow their embed pages to be embedded on their own site and change their Content-Security-Policy or X-Frame-Options HTTP response headers accordingly. And it’s their right to do so if they wish!

If you want to increase the likelihood that third-party content will be available on your site in the future, it’s best to use documented methods, ideally an API. If you integrate content via an API, you can craft a graceful error message in the event that the content doesn’t load. This can look a lot more forgiving than a broken embed.

5. Embeds probably won’t be crawled by search engine bots

This is… not a huge concern IMO. But I mention it since it may be a concern for others. Search engine bots don’t tend to crawl iframe contents, meaning that they won’t take that content in to account when determining what your page is all about. If this is super important to you, then use the platform’s API (if available) to integrate third-party content directly in to your site.

Edit at 2pm: Changed width description since 100% isn’t technically in line with standards, though it works.


Disabling “save to Pinterest”

Just had a collaborator ask if we could disable the “save to Pinterest” button even if a visitor has a Pinterest addon / extension in their browser. My immediate reaction was “Maybe? I’d think not but will see!”

Turns out something like this should be possible. Pinterest supports disabling saves from a site, see their documentation. You can either enable it site-wide or per image.

I’m surprised but really happy to see that they offer this, hope that they continue to do so.