DEV Community: Ben Taylor

How I got Ruby snippets to run browser side in less than a day

Ben Taylor — Fri, 28 Jan 2022 04:22:01 +0000

Over the last year I've been working on Runno, an open source library and tool for embedding code snippets that run client side in the browser.

I had some time yesterday to work on Runno and decided to see if I could add another language. I'd heard on twitter that Ruby was looking into adding official WASM support, so I had a look into what that was. Turns out the proposal to merge WASI based WebAssembly support was perfect for me!

WASI stands for WebAssembly System Interface and it's a standard way for WebAssembly (wasm) binaries to talk to a system. This allows developers to use a single binding interface to interact with multiple different binaries. It's been primarily adopted for server-side execution, but for my use case of runnable code snippets it also works well.

I went and had a look at the PR for WASI support, assuming this would be a many month long process. When I looked it had already been merged! To get Ruby running on Runno I'd need to figure out how to compile it to WASM. I went to look at the building instructions, then I thought - I wonder if someone has already put it up on WAPM (the WebAssembly Package Manager)?

And it turns out that kateinoigakukun who wrote that PR had also packaged Ruby for WAPM. Super handy!

With all of that sorted I could try out the package to see if it worked. Because there's a standard interface I don't need to put it into Runno to try it out, I can just use it in my terminal. I wrote an example ruby file:

puts "G'day legend, how are ya?"

Then I tried running it with the Ruby package on WAPM:

$ wapm install katei/ruby
$ wapm run --dir=. ruby example.rb 
G'day legend, how are ya?

That looks like it works! Heck yeah!

Runno installs its packages using WAPM, it's based off a fork of WebAssembly.sh and so adding support for a new language already on WAPM is quite simple. If you're interested here's the PR. The important change is:

if (name === "ruby") {
    return { run: `cat ${entryPath} | ruby --disable=gems` };
}

I'm using cat to pipe the code over STDIN due to a bug I was seeing when the file path was passed as args to Ruby. I've also disabled gems because of another error I was seeing. I'll look into these in the future, but for now it works.

The result is that you can now make quick embeddable Ruby snippets for your website! Try clicking the run button below.

How to embed runnable code samples using Runno

Ben Taylor — Sat, 20 Nov 2021 21:19:31 +0000

A year or so ago I was playing around with building an online Introduction to Python course, but I got distracted by this problem that seemed like it should be solved: how can I embed runnable snippets on the web?

There’s a bunch of closed-source solutions that rely on other services. I was hoping for a way to just install a package, and then run code. Especially small snippets like print, input and if statements.

So I started building Runno. It lets you embed snippets of code from a few different languages (Python, JavaScript, C, C++ and SQL currently) within your website and runs it all client side using Web Assembly. You can use it without any packages using an iframe, or install the npm package and use it as a set of Web Components.

If you're looking to embed a runnable snippet of code it's pretty straightforward with Runno. Let's say I'm writing a blog post explaining how if statements work in Python, and I have this snippet of code:

name = input("What's your name? ")
if "i" in name.lower():
  print("You've got an I in your name, how selfish.")
else:
  print("There's no I in your name.")

To use Runno all I have to do is visit the runno.dev website and paste in my code snippet:

Then copy the HTML for the iframe out of Runno, and into your blog. Here the iframe code is:

<iframe src="https://runno.run/?editor=1&runtime=python&code=bmFtZSA9IGlucHV0KCJXaGF0J3MgeW91ciBuYW1lPyAiKQppZiAiaSIgaW4gbmFtZS5sb3dlcigpOgogIHByaW50KCJZb3UndmUgZ290IGFuIEkgaW4geW91ciBuYW1lLCBob3cgc2VsZmlzaC4iKQplbHNlOgogIHByaW50KCJUaGVyZSdzIG5vIEkgaW4geW91ciBuYW1lLiIp" crossorigin allow="cross-origin-isolated" width="640" height="320" frameBorder="0"></iframe>

You'll notice that it has a fixed width and height. This is to make it easy to paste in, but you can change those values!

On Dev you can't put an iframe in, but you can use a Codepen. Here I've made a codepen that just has the iframe inside of it, then styled the iframe to fit the full space of the codepen.

And now you can run the example code snippet!

If you're interested in learning more ways to use Runno there's some documentation on the website: https://runno.dev/#examples

Or if you're interested in contributing - it's Open Source:

taybenlor / runno

Browser-based runtime for programming languages and WASI binaries.

Web Component ideas: Building a carousel

Ben Taylor — Tue, 31 Aug 2021 13:37:23 +0000

Carousels are a useful component for displaying a series of images (or really any media). People often use carousels off the shelf, but they're quite easy to build yourself! In this post I'll go through building a Web Component for a carousel.

You can see here that as you click the next and previous buttons it scrolls through a series of images.

Building elements that don't exist

Web Components are handy tools for abstracting out common patterns in HTML. There's lots of user interface patterns that are common on the web but don't have their own elements. Instead you have to build them up yourself from other elements.

If you find yourself repeating HTML, or the complexity gets too much, it can be handy to abstract out the complexity. By creating a Web Component you can create a neat abstraction that becomes reusable and easier to understand. Plus it makes your HTML much tidier!

What does the HTML look like?

This Web Component is rather simple, it doesn't have any attributes - you just put some elements inside it.

<ben-carousel>
  <img src="http://placekitten.com/360/200">
  <img src="http://placekitten.com/300/200">
  <img src="http://placekitten.com/420/200">
</ben-carousel>

The idea here is to stick to standard elements as much as possible and to keep it simple. The carousel is going to be in charge of displaying the content like a carousel. Then the content itself can be anything! In this case I've put in three images of cats at different sizes.

A big benefit of this approach, using Web Components, is that I can put any HTML content inside my carousel. It's just HTML! Plus I can use it in any website, no matter the library. Sticking to standards often makes things easier.

Creating the template

To begin with I wrote down the elements I'd need to create this carousel:

<template id="ben-carousel">
  <button>Prev</button>
  <slot></slot>
  <button>Next</button>
</template>

You can see here that I've got two buttons, one for going left and one for going right. Then I've put a slot element in, this is where the content inside will go. But this isn't quite enough for it to look like a carousel. Right now it looks like this:

So we'll need to add some styling. Once we've got it looking like a carousel we can move on to making it work like a carousel.

Here's how I styled it:

<template id="ben-carousel">
  <style>
    :host {
      display: block;
    }

    #container {
      display: flex;
    }

    #images {
      display: flex;
      flex-shrink: 1;
      overflow: scroll;
    }
  </style>
  <div id="container">
    <button id="prev">Prev</button>
    <div id="images">
      <slot></slot>
    </div>
    <button id="next">Next</button>
  </div>
</template>

First lets look at the extra elements I added. I've created a div to wrap all of the other elements, this will be useful for layout. Then I've added another div for the images, this will help to control how much of them is displayed.

You can also see here that I've given every element an id. When you're working with Web Components the HTML and CSS is all scoped to within the component. So you can use id as much as you please, it won't overlap with others on your page. This makes it much easier to write JavaScript and CSS.

Now lets look at the style here. The first part makes it so the element displays as a block element:

:host {
  display: block;
}

Next up I've styled the outer container to use display: flex:

#container {
  display: flex;
}

This makes it so that the three child elements (#prev, #images, and #next) all display next to eachother horizontally. Which is key to the whole layout!

Finally we're looking at the #images container. Here I use flex-shrink: 1 to make it so the #images container will shrink down when the width of its parent is constrained.

#images {
  flex-shrink: 1;
  display: flex;
  overflow: scroll;
}

I've also used display: flex here to make the children of the #images container (the images) all display next to eachother in a line. Finally overflow: scroll says that the #images container should create a scrollbar if its content has overflowed it.

The result looks like this:

That's just about everything! The only part we don't have is the buttons.

Wiring up the buttons

To wire up the buttons we'll need to write some JavaScript. First we'll set up some boilerplate for creating the carousel element:

class CarouselElement extends HTMLElement {
  constructor() {
    super();

    this.attachShadow({mode: 'open'});
    const template = document.getElementById('carousel');
    const clone = template.content.cloneNode(true);
    this.shadowRoot.appendChild(clone);
  }
}

customElements.define('ben-carousel', CarouselElement);

Now we want to wire up the events. Because we've already given each of our elements an id this is rather easy. First we get each of the elements we need from the shadowRoot:

// ... inside the constructor

const images = this.shadowRoot.getElementById('images');
const prev = this.shadowRoot.getElementById('prev');
const next = this.shadowRoot.getElementById('next');

Then we set up click handlers that scroll the images container:

// ... inside the constructor

prev.addEventListener('click', () => {
  images.scrollLeft -= 100;
})

nextButton.addEventListener('click', () => {
  images.scrollLeft += 100;
})

And bingo bango we've got a scrolling carousel!

Interested in Web Components?

I'm speaking about Practical Uses for Web Components at Web Directions: Code on September 17 & 24 2021. If you're interested you can use the voucher bensentme to get 20% off!

Web Component ideas: Making an if element

Ben Taylor — Mon, 30 Aug 2021 12:07:51 +0000

I'm a big fan of Web Components, they're super useful. But have you ever thought of using them as an if statement?

If the user selects the cat radio element, then the "Yep, cats are the best!" message will be displayed. If they select the dog radio element, then the other message will be displayed.

Web Components for authoring content

People tend to think about web development as a way of building apps. But that misses a big category of what people do on the web: making documents! Back in the day people used to write raw HTML straight to their web servers. But now we write in a CMS or a blogging system like this one. In those sorts of systems you tend to use a rich text editor, or markdown.

HTML is still really good for making documents though! If you want to make something really custom, HTML is a great tool. Using Web Components lets you do even more interesting things, things that go beyond just bold, italic and headings. You can create custom logic as well! That's the kind of stuff that hypertext should be used for.

If you're maintaining a website, blog, or CMS with authors who like to do interesting things you should try out Web Components. They're easy to write and they're custom just for your purpose!

What does the HTML look like?

In this example I wanted to create a kind of if-statement that changed which content was displayed based on which option was selected in some radio buttons. I started by writing out the HTML, so I could get a sense of how it should work:

<label>
  <input type="radio" name="animal" value="cat">
  Cat
</label>

<label>
  <input type="radio" name="animal" value="dog">
  Dog
</label>

<ben-if name="animal" value="cat">
  <p>
    Yep, cats are the best!
  </p>
  <img src="http://placekitten.com/200/100" alt="kitten">
</ben-if>

<ben-if name="animal" value="dog">
  <p>
    Dogs are pretty good, but have you tried cats?
  </p>
</ben-if>

You can see here I'm creating a custom element called ben-if which has two attributes name and value. The idea is that if the matching radio box is ticked, then the if statement will show. Otherwise it will be hidden.

Because they're just HTML, I can put other HTML elements inside them without any issues. If you were using a markdown parser that allowed HTML, you could also put markdown inside the HTML. This makes it super flexible, so I could make lots of different sorts of things with just this one trick.

There's a lot of other benefits here to using web components. You don't need to include any third party libraries, and you don't need to set up a rendering context. It will work across any framework, including React, Vue, Svelte etc. It's part of the way the browser works!

Creating the template

To write my web component, I needed a template. This template is really simple because it doesn't do much. This is the HTML for it:

<template id="ben-if">
  <style>
    :host {
      display: none;
    }
  </style>
  <slot></slot>
</template>

In the styling here the :host element refers to the web component I'm building. I've made it display: none so that it is hidden by default. The <slot></slot> element is where child content will be put inside this element.

Writing the javascript

The logic for this is a little bit more complicated. First I've set up some boilerplate. This renders the template I created into the web component, and keeps track of the name and value attributes. It also defines the custom element I've created as ben-if.

class IfElement extends HTMLElement {
  static get observedAttributes() {
    return ['name', 'value'];
  }

  constructor() {
    super();

    this.attachShadow({mode: 'open'});
    const template = document.getElementById('ben-if');
    const clone = template.content.cloneNode(true);
    this.shadowRoot.appendChild(clone);
  }

  attributeChangedCallback(name, oldValue, newValue) {
    this[name] = newValue;
  }
}

// Define this custom element
customElements.define('ben-if', IfElement);

Now that I've got the boilerplate out of the way, it's time to do the logic. I created a checkIf method on my IfElement to show or hide my element:

  checkIf() {
    const radio = document.querySelector(`[name="${this.name}"][value="${this.value}"]:checked`);
    if (radio) {
      this.style.display = "block";
    } else {
      this.style.display = "none";
    }
  }

This will query the document to find a checked element with the matching name and value. If there is one, it will set the element to display: block. If there isn't one it will set the element to display: none.

Now we just need to wire that call up. I put it in two places:

As an event that gets called any time a change event happens on the page
After the attributes change.

// ...
  constructor() {
    // ...
    document.addEventListener('change', () => {
      this.checkIf();
    });
  }

  attributeChangedCallback(name, oldValue, newValue) {
    // ...
    this.checkIf();
  }

And that's everything! Now it should all work together. Here's a codepen:

Interested in Web Components?

I'm speaking about Practical Uses for Web Components at Web Directions: Code on September 17 & 24 2021. If you're interested you can use the voucher bensentme to get 20% off!

Web Assembly should be a default binary target

Ben Taylor — Fri, 20 Aug 2021 10:44:28 +0000

WebAssembly (WASM) is no longer a toy environment for cool demos. It's a thriving ecosystem that enables high-performance web applications with rich functionality. It's a portable code system that can run binaries in the cloud, or on your local machine. This may seem like an extreme position, but hear me out: if you develop a compiled library, language, or other tool you should consider making WASM a default binary target.

Here are my main reasons:

Front-end web apps can handle workloads we'd previously reserve for the backend. Like image processing, or file encoding. This reduces bandwidth and speeds up apps.
WASM doesn't only run in the browser, you can use it from in-language bindings or an interpreter. This makes it a portable format that doesn't require compilation or platform-specific versions.
WASM runs in a sandboxed environment controlled by the host. The host can be certain that a library will not have network or file access unless it's provided.
With portability we get freedom. Freedom to run software anywhere we want without the arduous process of figuring out how to compile and run it.

Let's dive into that a bit further.

What's changed with WASM

When the whole concept of WASM started it was a big ol' hack. A neat trick to compile C programs so that they would run fast in a Javascript runtime. Emscripten really pushed the limits of what we thought was possible here and we saw some pretty amazing demos: some people compiled interpreted languages like Python to WASM, the legends at Unreal got their engine running inside the browser, it was all very cool. Gary Bernhardt even did a talk about how WASM would eat the world. But WASM has changed a lot since then.

Gary talking about Unreal Engine running in WASM

The most important change to happen to WASM is the WebAssembly System Interface (WASI). WASI is a system interface for a conceptual OS. It allows system software developers to bind to POSIX-like system calls, and for hosts to implement that functionality in a way that makes sense for their runtime. The result is flexible, but not so far from Linux, macOS, and Windows that it can't be practically implemented.

What's really neat about WASI is that it's based on a capability-oriented sandboxing system. The host who runs the binary can scope file access, proxy network access, and disable system calls as they see fit. This sort of sandboxing can prevent whole categories of security issues because it creates an extra layer between your application and its dependencies, reducing the possible impact scope if a dependency does get compromised.

Running WASM outside the Browser

With improvements in WASM has come an increased interest in running WASM outside the browser. This is a really interesting space of innovation that is made even easier with new tools for WASI. The obvious candidates are running WASM inside v8 runtimes. For example, Cloudflare's Workers platform uses v8 (Chrome's JS) as a way for them to run typical Javascript serverless functions as well as WASM-compiled binaries from other languages.

From Cloudflare: How Workers Works

But why run v8 at all? Good question! A WASM runtime is much simpler to implement than a Javascript runtime. You could absolutely implement one yourself. But rather than doing that, there's off the shelf solutions. Wasmer has runtime bindings for the major languages: Python, Ruby, PHP, Go, Rust, C/C++, and Javascript. The Bytecode Alliance has their own runtime that works in .NET, Python, Go, Rust, C, and C++. Plus I'm sure they're both working on more.

If you've got a WASM runtime for your language, you can load in a WASM binary, write some simple bindings to call into that binary and presto! You're running system code independent of OS or CPU. Just sling that bad boy on to whatever computer you want and press execute.

Now you know you could run WASM from your Python code, but why on earth would you? Here's an experience you might be familiar with:

$ install cool-library
Downloading cool-library...
Downloading dependencies: cool-dependency, ruby, gcc
Compiling gcc...
Compiling ruby...

You wanted to install cool-library but to get it, you need its dependencies. And those dependencies have dependencies. Meanwhile you're screaming, your computer's fan is screaming, and your package manager is compiling gcc, so that it can compile Ruby, so that some transitive dependency works. In most cases it's not really that bad, but it's familiar right?

We've kind of solved this problem with Docker. Things are at least better than they were. But it's a lot of overhead. You're setting up this whole shared kernel isolation system just to run a single binary. Seems like a portable binary would be better.

Go away James Gosling, inventor of Java. This is totally different.

This is where WASM shines! cool-library releases a WASM binary instead, we download it, and we run it from our favourite language. No need to install all of its dependencies, no need to compile gcc, no need to containerise an operating system. Just a binary you can run anywhere. It'll work on your linux server, it'll work on Windows, it'll work on your shiny new M1 MacBook. Heck, it'll work on the little chip running in your lightbulb that forwards your darkest secrets to Amazon. It'll run in more places than Javascript does!

If you think the idea of managing binary versions sounds terrifying, don't even worry about it. There's WAPM the WASM Package Manager right there to solve that problem for you.

$ wapm install cool-library
[INFO] Installing _/cool-library@0.2.0
Package installed successfully to wapm_packages!

That was easier!

This doesn't just stop at running WASM from your favourite language. Why do you need a language at all? With WAPM you can run the binary directly, like it's native. That means if a CLI tool is available in WAPM, you can install it and run it on your machine. No dependencies, no compilation, just a binary you install and run.

And if you want to deploy that WASM binary to production, there's another suite of tools for doing that. WasmEdge is a runtime made for cloud computing. Or skip the runtime altogether and compile your WASM to a native binary with Lucet, giving you all the security and sandboxing benefits of WASM and all of the performance benefits of a native binary.

Running WASI inside the Browser

Okay, so we know we can run these system binaries on your machine, or on your servers and that all makes sense. But why would you run them in the browser? What are you going to do? Run ffmpeg on the client side?!

Yes, yes I bloody well am. I'm gonna run whatever I want! If I want to run ffmpeg in the browser I should be able to. If I want to run clang in the browser I should be able to. If I want to download some open source printer drivers and run them in the browser I should be able to!

Portability is a matter of freedom. The whole promise of computing is universality. Being able to run libraries wherever I want is extremely powerful. Maybe you can't imagine why I might want to, but that's the point of open source tools. You put them out there and then other people do amazing and incredible things with them - things you never dreamed of.

Because ffmpeg runs in the browser there are now video editors that run in the browser. That may seem like a silly idea, but even just the basics of video editing are useful for many people, and by running on the client-side you save a lot of bandwidth. The traditional way to process videos would be to transcode them server-side, then provide controls for the user to make small edits like trimming the video. Because the user is so "far away" from the video file, making this interactive is very difficult. Plus you have to upload the whole raw file first.

By running on the client-side we can trim, and transcode before uploading. This means that the user gets an interactive trimming user interface that responds instantly. Then when they're done, instead of uploading a massive raw file, they can transcode locally and then upload just what the site needs. This isn't a fantasy, Discourse uses a similar workflow to optimise images before uploading them.

Wouldn't you like to save bandwidth like Discourse did?

But this isn't just for media. Have you ever used Jupyter Notebooks? It's a document format for data science where you can interweave text explanations with code that executes on data and shows intermediate results. It’s a great way to communicate research results, since the results of the research are sent along with how to get those results. If you want to check the working, it's right there!

Jupyter Notebooks require a connection to a server that can run the Python code. The server can run locally, but you have to fire it up yourself. Or you could pay for someone to run a server for you, upload the document there and then run it. But what if you just want to have a quick look?

This isn't how we're used to browsing documents. Nowadays you just open up a website and read the document right there. That's exactly what JupyterLite allows you to do. It's an entirely in-browser version of Jupyter based off the Pyodide project from Mozilla. Pyodide is Python compiled to WASM, and packaged up with a bunch of standard scientific python packages.

Reproducible science is even more accessible because Mozilla put the effort into getting Python running in WASM. Imagine what other good could be done by getting the rest of our programming languages onto WASM? Library documentation could have runnable examples. Bug reports could include a runnable reproduction. Technical articles could run the real thing, in your browser, with no need to install locally. I could tweet a program, and you could run it inside the tweet!

Ultimately it's about freedom

One of the most frustrating parts of programming is finding good matches of tools and environments. You find a great library for solving your problem, but it's for another language. You find a database you want to use, but there's no binary for your architecture. You're familiar with a programming language, but it doesn't run where you want it. You deploy your code and it fails because your dev environment doesn't match your production environment!

We emulate, we containerise, we port, we put in a lot of effort to solve these problems. But all these barriers could go away. We could run software wherever we wanted, however we wanted.

WebAssembly should be a default binary target.

Understanding render-as-you-fetch with React & Relay

Ben Taylor — Thu, 03 Jun 2021 06:51:55 +0000

I've been moving an existing codebase to a GraphQL API over the last few weeks using Relay as the front-end client. One thing I've been struggling with has been implementing the render-as-you-fetch (or fetch-as-you-render) pattern. A big part of the difficulty here is how our tools rely on the render path for coordinating work. I'm using this article as a way to write down what I've learned researching and figuring out this pattern in practice.

What is render-as-you-fetch?

I'm not sure about the origin of the idea, but there's a great explanation of it in the ReactConf 2019 demo of Relay. There's also some good explanations in the React Docs for Suspense.

The basic idea is that the render path of your components is a bad place to load data. The simplest reason is that it can be blocked by other components loading. If you only load data on the render path, you can be susceptible to waterfalls of loads. The worst case is one component blocks a number of other components from rendering, then when it unblocks them all of those components need to load their own data.

Imagine a profile page for a user:



function ProfilePage({ userId }) {
  const [isLoaded, profileData] = useProfileDataFetcher(userId)
  if (!isLoaded) {
    return <LoadingSpinner />
  }
  return (<>
    <ProfileHeader profile={profileData} />
    <PhotoCarousel photoIds={profileData.recentPhotoIds} />
    <PostList postIds={profileData.recentPostIds} />
  </>)
}

You could imagine that the PhotoCarousel component and the PostList component both need to go get their own data. So you have one fetch (the profile data) blocking two more fetches. Each of those components could also be fetching data, such as comments, avatars etc. This creates a cascade of loading symbols like:

When the first component finishes loading, it reveals its dependent child components - which of course now need to load!

These waterfalls show a real flaw in the pattern of loading data inside a component (on the render path). It creates an awkward UX and makes your page much slower to load (even if your individual components are quite performant).

An aside on Suspense for Data Loading

To fully grasp the render-as-you-fetch pattern you also need to understand how Suspense for Data Loading works. It's a really nifty pattern that works kind of like an Error Boundary. You set it up by creating a Suspense component with a fallback loading component:



<Suspense fallback={<LoadingSpinner />}>
  <ProfilePage />
</Suspense>

Then if a component starts rendering, but is not yet ready to render you throw a Promise that will resolve when it's ready. To use it in our example we could modify our useFetchProfileData hook to throw if the data isn't finished loading.



const profileFetcher = new ProfileDataFetcher()

function useProfileDataFetcher(userId) {
  profileFetcher.loadFromNetworkOrCache(userId)
  if (profileFetcher.isLoading(userId)) {
    throw profileFetcher.getPromise(userId)
  }
  return profileFetcher.getData(userId)
}

The Promise that we throw then gets waited on by the Suspense component until it's complete. In its place the LoadingSpinner is rendered. Once it's complete the component will continue rendering.

A neat result of this, is that we don't need to handle managing loading state within our component. Instead we can assume we always have the data we depend on. This simplifies our ProfilePage quite a bit:



function ProfilePage({ userId }) {
  const profileData = useProfileDataFetcher(userId)
  return (<>
    <ProfileHeader profile={profileData} />
    <PhotoCarousel photoIds={profileData.recentPhotoIds} />
    <PostList postIds={profileData.recentPostIds} />
  </>)
}

But it doesn't stop our waterfall cascade of loading spinners.

Back to our Waterfall

The simplest solution to this problem would be to fetch all of the nested data in the ProfilePage component at once. The ProfilePage would load the profile data, the photos, the posts, the usernames etc. But this breaks down in a number of situations:

Nested routes - you can't know what data you'll need at each level until you evaluate the routes
Concurrent mode - your data-loading could be inside a component that has paused rendering
Slow components - the performance of your data loading is dependent on how fast your components evaluate
Re-rendering - each time your component is rendered it needs to retry fetching the data, even if it's unnecessary (e.g. a theme change)

The solution to all of these problems is render-as-you-fetch. Instead of putting the fetching code inside of your component, you put it outside the component, and make sure it happens before the render even occurs. Imagine something like:



function ProfileButton({ userId, name }) {
  const router = useRouter()
  const clickAction = function() {
    profileFetcher.load(userId)
    router.navigateToProfilePage(userId)
  }
  return (<button onClick={clickAction}>{ name }</button>)
}

When the button is clicked the clickAction first loads the profile data, and then triggers navigation. This way the loading happens not only before the ProfilePage starts loading, but it happens outside of the render path. So complicated render logic has no way of impacting when the data gets loaded.

In relay this is all achieved using two hooks:



// From a container
const [queryRef, loadQuery] = useQueryLoader(/*...*/)

// Inside your component
const data = usePreloadedQuery(queryRef, /*...*/)

The first provides us with a loadQuery function that can be called to start the query loading, and a queryRef that will refer to that state. The second takes the queryRef and returns the data - or suspends if it hasn't loaded yet. There's also a less safe loadQuery function provided by Relay that doesn't automatically dispose of data.

Our ProfileButton example above, when using Relay would become something like:



function ProfileButton({ userId, name }) {
  const router = useRouter()
  const [queryRef, loadQuery] = useQueryLoader(/*...*/)
  const clickAction = function() {
    loadQuery(/*...*/, {userId})
    router.navigateToProfilePage(queryRef)
  }
  return (<button onClick={clickAction}>{ name }</button>)
}

And our Profile component would look like:



function ProfilePage({ queryRef }) {
  const profileData = usePreloadedQuery(queryRef, /*...*/)
  return (<>
    <ProfileHeader profile={profileData} />
    <PhotoCarousel photos={profileData.recentPhotos} />
    <PostList posts={profileData.recentPosts} />
  </>)
}

Here the queryRef is passed on to the ProfilePage so that it has a handle for the data loading. Then the usePreloadedQuery call will suspend if the data is still loading.

Routing with render-as-you-fetch

The big difficulty with all of this is that it starts falling apart when you consider routing. If you trigger fetching just before a navigation (like in the above example) what happens if the user visits that route directly? It would fail to load, because the queryRef hasn't been created.

In the ReactConf 2019 Relay demo video that I linked earlier they solve this with a thing called an "Entrypoint". This is a concept that wraps up two tasks together:

Preloading data with preloadQuery
Retrieving the lazy component for the route

In this case the idea is that each routing entrypoint contains a helper for loading its data, and it uses webpack codesplitting for lazy-loading each route's component hierarchy.

Using react-router attempting this approach, the entrypoint would look something like:



const Profile = lazy(() => import('./Profile'))

export function ProfileEntrypoint() {
    const { profileId } = useParams();
    const [queryRef, loadQuery] = useQueryLoader(/*...*/, { profileId })
    loadQuery()
    return (<Profile queryRef={queryRef} />)
}

And our routes would look like:



<Router>
    <Header />
    <Switch>
        <Route path="/profile/:profileId">
            <ProfileEntrypoint />
        </Route>
    </Switch>
</Router>

But this isn't going to work!

Unfortunately we've violated one of the rules we created going in: we've put the data fetching on the render path. Because our entrypoint is a component, and we call loadQuery when the component renders, the loading happens in the render path.

Our fundamental problem here is that the routing paths are evaluated during render, and not when the history object triggers a change. From what I understand it doesn't seem like its possible to resolve this. That means react-router is out. So is any router that evaluates its routes through components!

Finding a suitable router

So now we need to find a suitable router that can support this pattern of requesting data outside of the render path. The relay community has built an extension to Found - but it hasn't been updated for render-as-you-fetch. The Found router itself is quite flexible and extensible and so you could potentially implement entrypoints on top, but I haven't seen an example of this. As for other routers, I haven't seen any that aren't taking the react-router approach.

It seems like this is a problem that the relay team have seen in advance. Their Issue Tracker example rolls its own routing system based off the same primitives used by react-router.

There's also a couple of routers that people have built after encountering this problem: React Suspense Router and Pre-Router. Both are not very mature, but are promising. Pre-router particularly is quite clearly inspired by the Issue Tracker example.

Since they are rather immature, I think right now the best idea is to use the Router in the Issue Tracker example and maintain it yourself. This isn't a great solution, but it seems to be the only way forward for now.

Using the routing system from that example, our routes from before would instead look something like:



const routes = [
  {
    component: JSResource('Root', () => import('./Root')),
    routes: [
      /* ... */
      {
        path: '/profile/:id',
        component: JSResource('Profile', () =>
          import('./Profile'),
        ),
        prepare: params => {
          return {
            queryRef: loadQuery(/* ... */, {id: params.id}),
          }
        },
      },
    ],
  },
]

Here we see the entrypoint pattern quite clearly. Each route is made up of a path to match, a component to fetch, and a prepare function that loads the appropriate query. The JSResource helper here will cache the returned component to make sure it doesn't get lazily requested multiple times. While the prepare function is used to trigger any preparation work for the route - in our case that's the loadQuery function that Relay provides.

What's particularly useful about this approach is how loading works with nested routes. Each of the nested routes will be matched all at once, and their prepare calls and components will be successively run. Once all the preparation work is done the rendering can start, and even if rendering blocks at a higher level the data has already started loading for the lower levels. Waterfall solved!

Wrapping up

So that resolves our problem! But it does mean a lot of extra work for me, replacing our existing routing system with one that supports this new paradigm.

I hope this has helped you understand the render-as-you-fetch pattern, and helped you see how it might be implemented in practice using relay. If you know of a better solution to the routing problem, I'd love to hear it in the comments. Understanding all of this has been a bit of a wild ride for me, and I'm still getting my head around each of the required components. What seems like a straightforward idea at first ends up being more than a little complex.

Edit: Max Wheeler recommended on twitter that I check out Atlassian's React Resource Router. It looks like a great solution for render-as-you-fetch for regular fetch requests, however its API isn't ideal for relay. It might work with some nice wrappers around its useResource method. Worth checking out!

Edit2: @gajus has recommended using YARR (github.com/contra/yarr) which seems to be a great solution to this problem.

Running Vagrant on an M1 Apple Silicon using Docker

Ben Taylor — Thu, 22 Apr 2021 01:42:02 +0000

I've recently started at a new job, and I'm fortunate enough to have a new M1 Macbook Air. I'd heard from the wider community that everything "just works" on the M1, even though it's not an Intel chip. "Even Docker" they said. "Wow" I thought, this will be seamless, incredible.

So I sit there on my first day ready to get started. NPM installs everything fine, my python packages all install and both the backend and frontend are running, too easy! Then I hit an issue. This application requires a service which is run using Vagrant on Virtualbox.

Virtualbox very much doesn't support Apple Silicon. It's unclear whether Virtualbox will ever support Apple Silicon. The preferred alternative is a product by VMWare which also doesn't (yet) support Apple Silicon. I'm in a bit of a pickle.

But! Never fear! I can see that Vagrant also supports Docker. So over the next three days I dive into documentation, I frantically search the web for "vagrant docker M1" and "vagrant docker config" and "vagrant docker network issue" and "vagrant docker systemctl". After shaving at least three seperate yaks, and configuring a monstrosity I got it all running! Here's some lessons I learned.

Disclaimer: I am very much not a linux / ops / devops person. My experience with linux is limited but there's not much help out there for this issue so I'm doing my best.

Docker and Vagrant are frenemies

Docker and Vagrant have very different philosophies about how you should run your development setup. Docker's ideal is a minimalist setup, with just enough to run the single process you need. If you want more processes, Docker wants you to create more containers. Vagrant prefers a maximalist style, install everything on the one virtual machine and get it all going together.

To get Docker going you'll need a Dockerfile this describes the setup needed to create the Docker container. For our Docker container to be friends with Vagrant we're going to configure it as if its a traditional linux machine. By default you'll need at least sshd (which lets you SSH into the machine). I also needed systemd (which runs services). This is very much not how you should do Docker normally.

Here's the Dockerfile I used:

# Docker image to use with Vagrant
# Aims to be as similar to normal Vagrant usage as possible
# Adds Puppet, SSH daemon, Systemd
# Adapted from https://github.com/BashtonLtd/docker-vagrant-images/blob/master/ubuntu1404/Dockerfile

FROM ubuntu:18.04
ENV container docker
RUN apt-get update -y && apt-get dist-upgrade -y

# Install system dependencies, you may not need all of these
RUN apt-get install -y --no-install-recommends ssh sudo libffi-dev systemd openssh-client

# Needed to run systemd
# VOLUME [ "/sys/fs/cgroup" ]
# Doesn't appear to be necessary? See comments

RUN apt-get -y install puppet

# Add vagrant user and key for SSH
RUN useradd --create-home -s /bin/bash vagrant
RUN echo -n 'vagrant:vagrant' | chpasswd
RUN echo 'vagrant ALL = NOPASSWD: ALL' > /etc/sudoers.d/vagrant
RUN chmod 440 /etc/sudoers.d/vagrant
RUN mkdir -p /home/vagrant/.ssh
RUN chmod 700 /home/vagrant/.ssh
RUN echo "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9WhQ==" > /home/vagrant/.ssh/authorized_keys
RUN chmod 600 /home/vagrant/.ssh/authorized_keys
RUN chown -R vagrant:vagrant /home/vagrant/.ssh
RUN sed -i -e 's/Defaults.*requiretty/#&/' /etc/sudoers
RUN sed -i -e 's/\(UsePAM \)yes/\1 no/' /etc/ssh/sshd_config

# Start SSH
RUN mkdir /var/run/sshd
EXPOSE 22
RUN /usr/sbin/sshd

# Start Systemd (systemctl)
CMD ["/lib/systemd/systemd"]

If you don't need systemd in your setup then you can remove that and change the RUN of sshd to:

CMD ["/usr/sbin/sshd", "-D"]

All of this sets up a Docker container which doesn't work like a regular Docker container. It runs more like a virtual machine. This means it will be difficult to manage using the normal Docker commands. Once you take it down it will also be difficult to get up again. Best to control it with Vagrant. I've had to delete the container and re-create it with Vagrant many times.

Vagrant is pretty easy to configure

To get Vagrant running using your Dockerfile you just need to add a little bit of configuration:

Vagrant.configure(2) do |config|

# ... your existing config

  # Custom configuration for docker
  config.vm.provider "docker" do |docker, override|
    # docker doesnt use boxes
    override.vm.box = nil

    # this is where your Dockerfile lives
    docker.build_dir = "."

    # Make sure it sets up ssh with the Dockerfile
    # Vagrant is pretty dependent on ssh
    override.ssh.insert_key = true
    docker.has_ssh = true

    # Configure Docker to allow access to more resources
    docker.privileged = true
  end

# ...

end

You may need to override some other settings here. The override variable allows you to change top-level settings, while the docker variable allows you to setup docker-specific stuff. Have a read of the vagrant docker provider and vagrant docker provisioning documentation.

Once you've set this up, you can run your Vagrant machine with:

$ vagrant up --provider=docker

And if you need to do extra things inside the machine, you can ssh in with:

$ vagrant ssh

You should have sudo access as well if you need it.

Vagrant doesn't like to run multiple boxes

When I first ran Vagrant, before I realised Virtualbox wouldn't work it started and then failed. Then when I tried to run vagrant with the Docker provider it gave me errors about not having multiple boxes. I also couldn't delete my box because virtualbox wasn't running.

You can just delete the files in .vagrant to resolve that. It seems like Vagrant doesn't have a good way of resolving this itself.

You can re-provision Vagrant

Sometimes I found my setup would break, in my case it wasn't too hard to just run the Vagrant provisioning script again.

$ vagrant up --provision

Once that was complete some of my issues got resolved. It's not a good idea to blindly do this, but in my case I'm just trying to get it running.

Docker's public network bridge feature is broken

It doesn't seem to work on Mac! So if your Vagrant config has something like:

config.vm.network "public_network"

Try to see if you can replace it with:

config.vm.network "private_network", type: "dhcp"

In my case this substitution was sufficient, but you may have other requirements.

Your linux binaries need to be arm64

I ran into some issues because our provisioning scripts assumed that the architecture of the system would be amd64 (Intel and AMD 64-bit processors). It was a pretty safe bet that the CPU was amd64 up until Apple introduced their M1 chip!

Running linux on the M1 chip uses the arm64 architecture instead. As a handy shortcut you can get the architecture of the current machine in linux with:

$ dpkg --print-architecture

I used this in shell scripts by setting a variable:

readonly ARCH=`dpkg --print-architecture`

And then substituting that in when binaries were downloaded and installed, usually that was relatively simple, e.g.:

wget http://somedomain.com/some_binary_linux_amd64.zip

Became

wget "http://somedomain.com/some_binary_linux_${ARCH}.zip"

I learned a lot - but I still don't know much

I learned a lot about Docker (and how not to do things) Vagrant (and how to hack it) and some various linux tricks trying to get this all working. However I'm very much not a linux, Docker or Vagrant person, I'm just trying to make things work. So if I've written anything here horribly wrong, or extremely misguided, please throw down a comment.

If this helped you I'd love to hear it! I got stuck googling around for how to do this, and I imagine there are other people out there in the same boat.

Safer Authentication with TypeScript

Ben Taylor — Tue, 17 Nov 2020 10:30:45 +0000

I’ve been going through the Auth0 tutorial on Cloudflare Workers and integrating it with my own codebase. One of the first things I noticed was how loose the use of types was in the example code. This isn’t necessarily bad, it’s a tutorial, it’s not written in TypeScript, and the audience is just wanting to get something to work. But to me authentication is mission critical, which means I want to be confident about my types.

Let’s look at one of the first functions they have you implement:

This piece of code is pretty neat. One thing I like about it is that it returns a tuple. The first thing in the tuple is whether it was authorized or not, and the second thing is either the authorization information or the redirect information. What this means is that we can guard against the first item in the tuple and then use the second item.

But, unfortunately, TypeScript gets something different when it infers types for this function:

(boolean | {authorization:any})[] | (boolean | {redirectUrl:any})[]

Typescript thinks that this is an Array of either (boolean or an authorization object) OR it’s an Array of either (boolean or a redirect object). That’s messy! It means we can’t be confident that the implementation is correct. It would be valid to write it with the boolean flipped around, or with the object on either side. It also means we can’t use the types of this function to be confident that we’re only using the return type in the right way. For example to use the authorization object we will have to use a type assertion on it:

We have to do this because the type of data is:

boolean | { authorization: any } | { redirectUrl: any }

If someone made a mistake with the if statement here the type assertion would prevent any type errors from being raised.

We can improve the situation by encoding information about the sorts of return values the authorize function can have within the return type.

The full text of this post is available on my Substack, where I go into how we can use the right types to make this safer.

Safer Authentication with Typescript

Thanks for reading!

BlurHash as a service with Cloudflare Workers

Ben Taylor — Fri, 13 Nov 2020 23:11:42 +0000

Last week I came across BlurHash on twitter. It’s an interesting tool for dealing with image loading issues. Basically it allows you to show a blurred version of an image while the real image is loading over the network. So you can show a kind of preview while it’s loading.

This is a pretty useful technique in terms of UX and perceived performance. It obviously looks a lot nicer, since you’ve got pops of colour and a bit of variety, but the more important part is that users can actively see that the website is loading.

When a user sees just a blank screen or a blank area they can’t get a sense that the page is loading. Maybe it’s broken, or stuck. If you introduce intermediate loading steps it feels to the user like there is an active loading process going on. This is the same concept behind skeleton screens, where a skeleton of the user interface is displayed while the page is loading.

The way BlurHash helps you out is through tooling, not through some specific component implementation. BlurHash gives you two main functions: an encode function and a decode function. The encode function turns the image into a short string of characters (similar to a hash), while the decode function turns a string into a blurred image. Here’s the diagram from their website:

What’s really cool about this is that you can generate the BlurHash string server side when you’re processing images, and then save it along with your model. Then on the client side you can render the blurred image while you’re waiting for the full image to load. Since the blurred image is just a string, you don’t need any sort of binary storage or transfer - just throw it in your JSON or your HTML and get on with it.

The situation this doesn’t work for is when you don’t have full control over server-side processing of your images. You might be consuming images from somebody else’s API, or you outsource your image uploads. I’ve been messing around with Cloudflare Workers a lot recently and it struck me that it would be pretty cool to have a worker do this processing for you.

The full text of this post is available on my Substack, where I go deep into how I implemented BlurHash as a service using Cloudflare Workers.

BlurHash as a Service using Cloudflare Workers

Thanks for reading!

Neater Icons with Web Components

Ben Taylor — Sun, 09 Aug 2020 11:50:51 +0000

Over the years we've seen steady changes in best practices for rendering icons. Icon fonts remain easy to use, SVGs render well on high definition screens and well, for some reason Facebook seems to still use a png sprite sheet?

(I'm sure they have a good reason, they're smart people)

However the actual use of these different techniques still feels... imperfect. If you're using icon fonts you'll be writing some HTML like this:

<button>
  <span class="icon-plus"></span> Add
</button>

Or you might inject the icon from your CSS with something like this:

<button class="add">Add</button>

.add::before {
  font-family: 'iconfont';
  content: '\addicon';
}

If you're using SVG you could just drop that SVG straight into the DOM (not a bad idea).

<button>
  <svg viewBox="0 0 16 16">
    <path d="big series of numbers"></path>
    <path d="maybe another path"></path>
  </svg>
  Add
</button>

But more likely you're using an SVG sprite sheet and so your code looks a bit tidier, like this:

<button class="btn">
  <svg viewBox="0 0 16 16">
    <use xlink:href="#icon-add"></use>
  </svg>
  Add
</button>

And then if you're using a PNG sprite sheet... uhh lets not go into it.

My main point is that you end up mixing the implementation of your icon rendering system, with the markup and CSS you're writing to implement your webpage. This isn't necessarily bad, but abstraction can create neat boundaries. If this was JavaScript we would have long ago written a helper function like icon('name') that returns us an icon with that name.

On the web we have a great new friend for abstraction: Web Components.

With Web Components we could write this code example as:

<button>
  <my-icon name="plus"></my-icon>
  Add
</button>

This lets us hide the implementation details of our icon rendering system and allows for a short and semantic syntax in its place. If someone unfamiliar with your codebase had a read of that, they'd think "Hey this thing renders an icon".

This is a great way to use Web Components - to hide the implementation details of something you do all the time. You don't have to build a huge design system to reap these rewards. Just write a bit of JavaScript.

Speaking of writing JavaScript - it's probably time I showed you how to implement this element. I'm going to show it here without any frameworks or magic, but feel free to npm install your way to a solution that works for you. I'll be showing you the SVG version - but you could use a similar strategy with icon fonts.

Implementing our Icon

First off you'll need a template element. This will represent the stuff that lives "inside" the my-icon element.

<template id="my-icon">
  <svg>
    <use id="use" xlink:href=""></use>
  </svg>
</template>

That wasn't so scary. Here we're defining a template element which can be used inside our custom element. I've used an id for the use element so we can set its xlink:href later. Since the id is inside a template it won't conflict with the rest of the document.

Then in JavaScript we create a custom element.

// URL to your SVG
const baseURL = '/sheet.svg';

class MyIconElement extends HTMLElement {
  // This tells the browser we want to be told
  // if the `name` attribute changes.
  static get observedAttributes() {
    return ['name'];
  }

  constructor() {
    super();

    // Here we create the DOM elements from the template
    // and put them in the ~~spooky~~ shadow DOM.
    this.attachShadow({mode: 'open'});
    const template = document.getElementById('my-icon');
    const clone = template.content.cloneNode(true);
    this.shadowRoot.appendChild(clone);

    // Lets also grab a reference to that use element
    this.useEl = this.shadowRoot.getElementById('use');
  }

  // This is called whenever an attribute in the
  // observed attributes changes. It means you can
  // change `name` and it will update.
  attributeChangedCallback(name, oldValue, newValue) {
    this.useEl.setAttribute('xlink:href', `${baseURL}#icon-${newValue}`);
  }
}


// Finally lets define this custom element
customElements.define('my-icon', MyIconElement);

And we're done!

We can now write:

<button>
  <my-icon name="plus"></my-icon>
  Add
</button>

To have it render like this:

Understanding that JavaScript

There's a lot going on in this JavaScript so let's talk about it a bit. If you haven't seen the ~spooky~ shadow DOM before it can seem a bit scary. A better name for it would be a "private" DOM. It's a small little private space for you to set styles, create elements, and do weird things without impacting the "public" DOM. Or, if you like, a dark shadow realm where you can banish horrors of CSS and HTML - and nobody will know.

A big benefit of using the shadow DOM is that we can pollute our namespace with id all we like, it won't impact anyone else. If you look at the page in the inspector, the template SVG will all be hidden. You can still view it - but it's not there by default.

Then if we expand the shadow root.

Another trick here is in the attributeChangedCallback function. Here is the real "work" of this element. It turns the icon name that a human would use, into a xlink:href friendly value that we then set on the use element.

If we changed the name attribute to be "cross" as an argument then the HTML would end up looking like this:

<svg>
  <use id="use" xlink:href="sheet.svg/#icon-cross"></use>
</svg>

Basically the same as before!

You can see a demo of this, with two different icons in this example. I've also made it a codepen here but the SVG won't load due to cross-site protections.

If instead you wanted to use icon fonts, then you could change the attributedChangedCallback to set the properties you need for your icon font.

Making it useful (extensions)

So at this point you're basically done, you have icons on the page - what more could you want? Well, probably a lot more. You'll want to set up some default CSS, you may want to add some accessibility defaults. Maybe there's some helpers specific to your application you could add.

There's plenty of guides out there about how best to do SVG icons, so I'll leave the details to them. However here's some quick tricks to make things work well. We'll revisit our template from earlier:

<template id="my-icon">
  <!-- Web components can have a scoped style tag, this only impacts elements inside the shadow DOM. -->
  <style>
  /* :host indicates the "host" element of the
   * shadow DOM. So our custom my-icon element.
   */
  :host {
    display: inline;
  }

  /* Because this is scoped, we can use very
   * simple selectors.
   */
  svg {
    width: 1em;
    height: 1em;
    fill: currentColor;
  }
  </style>

  <svg>
    <use id="use" xlink:href=""></use>
  </svg>
</template>

Here I've added a style element into the template. In this context style elements are not considered a code smell - in fact they're necessary. This style element is entirely scoped to the Shadow DOM and lets us be "lazy" in our CSS. This scoped approach is one of the greatest abstraction tricks Web Components can give us, when you're writing CSS here you don't have to think "how will this impact my other elements and classes" you only need to keep the one scope in your head.

The downside and upside of using the Shadow DOM is that regular CSS can't "penetrate" it. You start off with everything at browser defaults - so if you want any styles you'll have to set them here. Some things will inherit through the boundary, mostly text styles, but you can't use any classes you've set up outside the Shadow DOM.

In my style here I've set the :host to be display: inline - this is mostly to indicate "this is an inline element". Next I've added some simple styles to the svg element. These styles ensure it resizes as the font-size increases, and changes its fill to whatever color is set.

Now if you use these icons as part of your website, in buttons, links etc - they fit in. They resize and change colour based on their context. This is extremely smooth, and gives you many of the benefits of icon fonts but with SVG, a much easier to work with format.

Final Note

I'm new to publishing on dev.to if you like this and you'd like to see more things by me just shoot through a comment or message!

DEV Community: Ben Taylor

How I got Ruby snippets to run browser side in less than a day

How to embed runnable code samples using Runno

taybenlor / runno

Browser-based runtime for programming languages and WASI binaries.

Web Component ideas: Building a carousel

Building elements that don't exist

What does the HTML look like?

Creating the template

Wiring up the buttons

Interested in Web Components?

Web Component ideas: Making an if element

Web Components for authoring content

What does the HTML look like?

Creating the template

Writing the javascript

Interested in Web Components?

Web Assembly should be a default binary target

What's changed with WASM

Running WASM outside the Browser

Running WASI inside the Browser

Ultimately it's about freedom

Understanding render-as-you-fetch with React & Relay

What is render-as-you-fetch?

An aside on Suspense for Data Loading

Back to our Waterfall

Routing with render-as-you-fetch

Finding a suitable router

Wrapping up

Running Vagrant on an M1 Apple Silicon using Docker

Docker and Vagrant are frenemies

Vagrant is pretty easy to configure

Vagrant doesn't like to run multiple boxes

You can re-provision Vagrant

Docker's public network bridge feature is broken

Your linux binaries need to be arm64

I learned a lot - but I still don't know much

Safer Authentication with TypeScript

BlurHash as a service with Cloudflare Workers

Neater Icons with Web Components

Implementing our Icon

Understanding that JavaScript

Making it useful (extensions)

Final Note

Further Reading