Jo's Blog

Scoping CSS

2026-03-12T23:20:00Z

As web developers, we create websites. As designers, we want to make components. Since the platform was not originally designed for this, there can be papercuts.

Ideally, we would be able to create isolated components, and have the styles for them not leak out into any other parts of our application.

I'm going to go through as many ways I can think of at doing this, to demonstrate how much of a problem this is. I'll be making a "Card" component. A card really is just something visually distinct from the other parts of your website, as far as I can tell.

I'll go over:

Vanilla CSS
Component Libraries
Web Components

Vanilla CSS

Stuff you can do that isnt like, a component library like React or Svelte.

Don't scope at all

Make a plain css file!

css

body > :is(header, footer) {
    background-color: LightGrey;
}

.card {
    background-color: LightSlateGrey;
}

Issues:

We have everything in one CSS file, this can get a bit unwieldy...
- We might want to structure our CSS to prevent this
We might introduce a global rule (e.g. all h2s are green) that might not want to be in certain areas of the website
- This is why we might want to scope our rules

Requirement	Met?
Good Structure	Not really
Scoping	No

BEM

BEM is a naming convention for components that tries to solve the scoping issue.

In BEM, you name your classes like this: .Block__element--modifier. (There seems to be debate on whether to use __ or - to designate elements. GetBEM and Bem.info disagree on this, and there appears to be no authoritative sauce …)

html

<div class="Card">
    <h2 class="Card__header">This is the card's Header</h2>
</div>

scss

.Card {
    background: LightSlateGrey;

    &__header {
        color: Green;
    }
}

This is nice, and the syntax is quite easy to work with, so it feels like it would be a good solution. Sadly, you do need a CSS preprocessor, Sass, for the above functionality. In vanilla CSS, you'd have to spell out .Card__header and et cetera. Annoying on a large codebase, I would assume. (I suspect that standards/vendor people liked Sass's & syntax, but "string concatenation on arbitrary selectors" was not a very attractive thing to add to CSS, so they compromised on a still-pretty-good solution.)

The other issue is that this requires some level of discipline to keep up. It's a constant effort to make sure that you make everything a class, name it according to BEM, just to solve scoping issues.

Requirement	Met?
Good Structure	Quite well (I would put each "block" in a separate file)
Scoping	Good, if you can keep it up

Nesting

css

.card {
    h2 {
        color: Green;
    }

    background: LightSlateGrey;
}

Nesting is cool! It means you can scope your CSS to the parent container without chaining selectors like .card h2. You can also set a lower bound, which is something that BEM can do

Requirement	Met?
Good Structure	Maybe
Scoping	It's okay, specificity can get high if you nest a lot.

@Scope

css

@scope (.card) /* to (.lowerBound, .otherBound) */ {
    :scope { /* targets .card */
   	    background: LightSlateGrey;
    }

    h2 {
        color: Green;
    }
}

Very similar to nesting. Unlike nesting though, it handles specificity very differently. While you can think of nesting as "resolving" to a non-nested CSS, @scope can't be resolved in this way.

Scope does priority in rule matching very differently, based on proximity rules. MDN has a good explainer on this. I'd love to go more in depth on priority in a later blog post, as it seems like a quite advanced topic in CSS.

Requirement	Met?
Good Structure	It's better than nesting
Scoping	Very well

In Component Libraries

Focusing on React (but probably applicable elsewhere):

CSS Modules

css Card.module.css

.card {
    background: LightSlateGrey;

    h2 {
        color: Green;
    }
}

jsx Card.jsx (You're writing React now, sorry)

import styles from "./Card.module.css"
export default function Card {
    return (
        <div className={styles.card}>
            <h2>This is the card's Header</h2>
        </div>
    )
}

CSS Modules only scope classes. In fact, they rewrite your classes for you. (Note that you can sidestep this magic through :global(.selector) if needed.) This would be a "foot gun":

css Card.module.css

.card { /* ... */ }

h2 {
    color: Green;
}

So you're not really writing scoped CSS. You're writing normal CSS where the classes happen to be scoped. At least it means you can reuse class names, I guess!

Requirement	Met?
Good Structure	Decent, though you do need to make sure to make sure everything is focused on classes…
Scoping	Autogenerating unique class names works well for scoping

CSS-in-JS

I don't really have enough experience with these libraries to touch on them, but CSS-Tricks has a good analysis.

They all have some funky way of inputting CSS though, like a Lit-style tagged template or an object.

Tailwind

html

<div class="bg-[LightSlateGrey]">
    <h2 class="text-[Green]">This is the card's Header</h2>
</div>

We are no longer writing CSS.

I'm lumping in Tailwind with React because it really shines when you are using a real component library. Since you're already naming your components in the class and file name it does feel quite redundant to repeat naming things. ~~It also feels horribly lazy, like React…~~

Not writing CSS really does help with scoping though. Since you're declaring every element with classes that point to it directly, you aren't going to have any issues with it targeting other elements. This is a core design idea of Tailwind (and where I philosophically oppose it!)

Requirement	Met?
Good Structure	Worse than any CSS
Scoping	Very

Style property

It's a property, not an attribute.

jsx

<div style={{ background: "LightSlateGrey" }}>
    <h2 style={{ color: "Green" }}>This is the card's Header</h2>
</div>

weh.

Requirement	Met?
Good Structure	:(
Scoping	Very

Web components

Finally. I've talked about this before, but the Shadow DOM means Web Components are by definition scoped separately from the rest of the document. This means you can go wild and put anything in the style tags, and it will only be scoped to your component.

js card.js

customElements.define('my-card',
  class extends HTMLElement {
    constructor() {
      super();

      const template = document.getElementById('my-card-template');
      const templateContent = template.content;

      this.attachShadow({ mode: 'open' }).appendChild(
        templateContent.cloneNode(true)
      );
    }
  }
);

html

<template id="my-card-template">
    <style>
     :host { /* targets the element wrapping over shadow root */
       background: LightSlateGrey;
     }
     h2 {
         color: Green;
     }
   </style>

   <h2>This is the card's Header</h2>
   <slot>This is the card's content</slot>
  </template>

  <!-- later... -->

  <my-card>foo</my-card>

Requirement	Met?
Good Structure	Meh. Web components are verbose.
Scoping	Quite well? Unsure how `<slot>` plays into this, but that's kind of a donut scope like you can do with `@scope`…

Editor Configs and stuff

2026-03-10T00:00:00Z

I've been switching between editors a lot recently. I'm a macOS user (currently…) so that does dictate some of my editor choices.

It also depends on my mood, I guess. Sometimes I prefer to use Helix in the terminal, and sometimes I prefer to use Nova because it feels very clean to use. Occasionally, I will use Zed or VS Code for features.

Helix configuration

Helix is very "batteries included", in that it comes with a lot of what you would expect by default. This is nice because configuration is annoying. I used to be an avid NeoVim user, and the configuration can get quite… intense? You basically need a package manager for it.

Helix comes with LSP support (program that performs IDE functions for you, specialized for a certain language) and highlighting through Tree-Sitter. Unlike other LSP IDEs, it does not bundle them and expects you to install the IDEs through your package manager.

You can view LSP support through the hx --health argument (command?) which will spit out something like this:

$ hx --health rust
Configured language servers:
  ✓ rust-analyzer: /Users/jo/.cargo/bin/rust-analyzer
Configured debug adapter:
  ✘ 'lldb-dap' not found in $PATH
Configured formatter: None
Tree-sitter parser: ✓
Highlight queries: ✓
Textobject queries: ✓
Indent queries: ✓

My helix configuration is quite short:

toml ~/.config/helix/config.toml

theme = "rose_pine_dawn"

[editor]
auto-format = true

[editor.cursor-shape]
insert = "bar"
normal = "block"
select = "underline"

[keys.normal]
x = "select_line_below"
X = "select_line_above"

… This is a bit misleading, though. First off, there's languages.toml, which I use for configuring language specific stuffs:

toml …/languages.toml

[language-server.rust-analyzer.config]
check.command = "clippy"

To explain the rest of my config I'll have to go through the tools I'm using.

SuperHTML is an LSP (and some other stuff) for HTML. It's lints (warnings? errors?) are based on spec, instead of Prettier which seems to be "vibes". Specifically, it doesn't have "end slashes" like <br />. I hate end slashes.
DPrint is a multi-language code formatter, which seems to be maintained by a member of the Deno team.
VSCode has a few built in language servers, which have been put on brew and such.
Emmet is basically a very easy way to do very succinct macros for HTML and CSS. I guess people don't do this anymore because of ai... whatever..

toml …/languages.toml (continued)

[language-server.emmet-lsp]
command = "emmet-language-server"
args = ["--stdio"]

[[language]]
name = "html"
language-servers = [{ name = "superhtml", except-features = [ "format" ]}, "emmet-lsp"]
auto-format = true
formatter = { command = "dprint", args = ["fmt", "--stdin", "html"] }

[[language]]
name = "css"
language-servers = [ { name = "vscode-css-language-server", except-features = [ "format" ]} ]
auto-format = true
formatter = { command = "dprint", args = ["fmt", "--stdin", "css"] }

[[language]]
name = "javascript"
language-servers = [ { name = "typescript-language-server", except-features = [ "format" ] }]
auto-format = true
formatter = { command = "dprint", args = ["fmt", "--stdin", "javascript"] }

[[language]]
name = "typescript"
language-servers = [ { name = "typescript-language-server", except-features = [ "format" ] }]
auto-format = true
formatter = { command = "dprint", args = ["fmt", "--stdin", "typescript"] }

The context within which I use Helix

I usually run Helix inside Zellij, which is like a less confusing Tmux. I don't have too much to say about it, but it allows me to do JJ work, compilers, etc. side by side with the editor.

Dark/Light mode switching

I use macOS, which has a global light/dark theme toggle. I'm personally more of a light mode user nowadays (I have astigmatism, and I'm trying to be more diurnal nowadays) but I use dark mode sometimes so I would like my applications to switch themes.

Current theme of choice for me is Rosé Pine. I used to be a Catppuccin user, but their light theme is just bad. It's horrible to look at.

For Helix, this issue was marked as a wont-fix, so I decided to roll my own script for it. The idea being that if you alias hx to this function, every time you open it the theme will be synced for you.

fish config.fish

function lightDark -a light dark
    if defaults read -g AppleInterfaceStyle 2>/dev/null | grep -q Dark
        echo $dark
    else
        echo $light
    end
end

function hx
    set CONFIG_FILE "$HOME/.config/helix/config.toml"
    set THEME (lightDark rose_pine_dawn rose_pine)

    if test -f "$CONFIG_FILE"; and grep -q "^theme" "$CONFIG_FILE"
        sed -i '' "s/^theme = .*/theme = \"$THEME\"/" "$CONFIG_FILE"
    end
    command hx $argv
end

Now, you can basically do the same thing for Zellij…

fish config.fish (continued)

function zellij
    set CONFIG_FILE "$HOME/.config/zellij/config.kdl"
    set THEME (lightDark rose-pine-dawn rose-pine)

    if test -f "$CONFIG_FILE"; and grep -q "^theme" "$CONFIG_FILE"
        sed -i '' "s/^theme .*/theme \"$THEME\"/" "$CONFIG_FILE"
    end
    command zellij $argv
end

It's pretty similar to do the same in bash, zsh, etc. You just want to set an alias instead of a function, probably?

Nova

It's a macOS only application. It's big sells are:

Very nice UI
No AI
Works well enough

I'm still trying to configure it. For me, I'm not totally happy with the linting and formatting for web stuff yet, unlike Helix.

Extensions I like:

Rust 3 (??): the most up to date Rust plugin, maintained by a friend of mine :)
HTML and CSS Validators
Deno seems to look good, though I'm using TypeScript LSP currently.

I'm missing formatting for HTML/CSS and some linting. There are options, I just haven't had the time to try all of them yet.

Nova seems to have a bit of an "issue" about having a bunch of similar extensions. I think part of the reason is that because Nova is paid, there is not as much of a userbase as something like VS Code. The only real way to figure out which one you should use is guessing from the last-updated time, though the Rust extensions have helpfully sequentially numbered themselves.

Another thing is that it doesn't have Helix keybindings. I have come to accept the fact that I will not be able to conform everything to the muscle memory of one text editor. It has a Vim mode, but switching between Helix and Vim is actively harmful to muscle memory. When I'm using Nova, I'm okay with being a bit slower. For most developers, words per minute is not a useful metric for programming work.

Zed

I love-hate Zed. Compared to Nova it's ugly and has bad text rendering. However it does have more support for extensions and debugging and stuff, like VS Code.

jsonc ~/.config/zed/config.json

{
  "base_keymap": "JetBrains",
  "helix_mode": true,
  "which_key": { // Gives hints about Helix binds
    "enabled": true,
    "delay_ms": 100,
  },

  "tab_size": 4,
  "project_panel": {
    "sort_mode": "mixed",
  },

  "format_on_save": "on", // Yea, it's a string "on" or "off"??
  "autosave": "on_focus_change",

  "disable_ai": true, // thank you zed team

  // Inline errors (vsc code lens, default in jetbrains)
  "diagnostics": {
    "inline": {
      "enabled": true,
      "max_severity": null,
    },
  },

  // Theming
  "icon_theme": {
    "mode": "system",
	  // These are from an extension
    "light": "JetBrains New UI Icons (Light)",
    "dark": "JetBrains New UI Icons (Dark)",
  },
  "ui_font_size": 16,
  "ui_font_family": ".SystemUIFont", // SF Pro on macOS
  "buffer_font_size": 12.0,
  "buffer_font_family": "Maple Mono",
  "buffer_line_height": "comfortable",
  "theme": {
    "light": "Rosé Pine Dawn",
    "dark": "Rosé Pine Moon",
  },

  // Language stuff
  "lsp": {
    "rust-analyzer": {
      "initialization_options": {
        "check": {
          "command": "clippy"
        }
      }
    },
    // I've omitted some stuff because it's not too useful
  },
}

There's a bunch more stuff you can configure in Zed (keymap.json, tasks.json, project specific overrides, …) but it's not very useful to me to go that deep. Zed feels like the Vim of GUI editors, in a bad way. I would list my extensions, but you can probably figure out what I would install based on what I've listed above.

New 88×31 Badge

2026-03-03T00:00:00Z

Hi! Check out the new badge:

It's an SVG!

html

<img
  src="/badge.svg"
  alt="Badge for the website J0.lol"
  width="88"
  height="31">

If you want to link to it on your website, please don't hotlink it, copy it instead. (Thanks for linking to my website, if you do!) Not only does it mean that it will make your website take longer to load, but my image links may not stay at the same location forever. Just right click the image and press save!

I think serving an 88×31 badge as an SVG is kind of funny. It's not really that size, it can be zoomed in forever! It's basically at a ratio of 88:31.

Understanding WebGPU

2025-12-19T00:00:00Z

WebGPU is an API for interacting with the GPU, from the web browser. WebGPU does not exist as a program, but it is a standardized interface between the web browser and the GPU. Browsers have to implement WebGPU. In fact, web browsers can be largely thought of as bundles of implementations of web standards, for example HTML.

As software developers, we have a lot of ways to talk to the GPU. Most of the time, however, this is strictly dependant on what platform we are writing code for. Here is a simplified flowchart:

Chekov's (deprecated) tag.

Let's imagine for a second that you are a browser vendor. You want to target all of these platforms, so you have to make and implement an API that turns the browser's GPU commands into the OS's GPU commands. You may notice that all of them (mostly) have OpenGL support. So you make WebGL as a wrapper over OpenGL.

A short history lesson

A timeline of notable Graphics APIs.

WebGL is a simple idea: Take OpenGL ES, a subset of OpenGL, and surface the API in the browser. When a user makes a call, just use the OS's OpenGL. This is what the four big browser engines (Opera, Chrome, Firefox, Safari) did in 2011.

The big conflict here is that just a few years later, OpenGL was set to be replaced. The key change between these new APIs and OpenGL was the idea of "low driver overhead." The idea is that by making more of an effort to conform to how the GPU is structured, you can talk to the GPU using less work on the CPU. In practice, this means you have to set up a lot of things before you can start GPU work.

As part of this replacement, Apple deprecated OpenGL in 2018. This raises some questions over how WebGL works, right? The entire point of it was to be a wrapper over a now deprecated API. Thankfully Chrome thought of this, all the way in 2010! They created the ANGLE project to translate OpenGL ES to other graphics APIs. Nowadays, WebGL support looks like this:

All browsers seem to use ANGLE for this.

A Better Way

Opening up these new APIs to the browser directly was the obvious next step. However, we need to solve the mismatch between what the browser wants and what the operating system wants. Lets say, for example, we pick Vulkan as the graphics API for the browser. Great! But now we have to solve how to run Vulkan on macOS. Because the people who make the browsers (Google, Apple, Mozilla) are mostly the same people who made the operating systems (Google, Apple, Microsoft) they would have a hard time picking a favorite API out of the current available ones. To solve this, a new API had to be made. And that's what WebGPU is.

The sad part about this is that we basically need another ANGLE to turn WebGPU into native OS APIs. But because WebGPU was designed for this, it maps much closer to current APIs than WebGL does. That makes developing a new ANGLE easier, and the closer the "mapping" is to the native API, the less performance is lost. Here's what those mappings look like:

Dawn and WGPU are the "ANGLEs" of WebGPU.

What This Means For GPU Programming

Essentially, WebGPU is not bound to the web browser. It is the new "universal standard" for talking to the GPU. This has many possible applications. Let's say you're making a game engine, for example. You want to target every system possible, because you don't want to lock down game developers to using, say, Linux on Desktop only. If you were to use WebGPU instead of another graphics API, you would only have to write your rendering code once!

You could definitely simplify this.

This isn't really a hypothetical. Today, you can use WGPU to talk to the GPU natively on any system. That's why I'm so excited about WebGPU.

I Made a DSL for My Blog

2025-11-27T00:00:00Z

I think I have spent most of my time on this blog trying to figure out how to write posts better. I honestly think I have outdone myself this time.

What I have used as blog post formats.
Markdown → PHP → HTML → Makup.
Click each entry to go to their blog posts.

I've been constantly changing because I have been unsatisfied with everything I've tried. I switched to a HTML-style format so I could have more control over my formatting. I've been trying to balance control over formatting with lack of verbosity.

So here's the language:

html

<p>This is a sample paragraph.</p>
<$code-block lang="html">
    <span>This is a sample code block.</span>
</$code-block>

I've changed the load-bearing symbol from # to $, for maybe obvious reasons.

I titled it makup because I'm terrible at naming things. It's just markup without the "r". Or maybe makeup with the "e". I dunno.

What it Does

Makup (the compiler) parses makup language, then passes any named components (eg <$code-block>) to a lookup table. If the tag name is registered, it will pass the contents and attributes of the component to a function.

rust

fn hello(input: &str, attrs: HashMap<&str, &str>) -> String {
    format!("<span>Hello {input}</span>")
}

The outputted string will replace the component. In theory, this language does not really need to work on top of HTML (it's similar to PHP in that way) but the syntax is trying to mimic it.

How I Made it

The language is specified using Pest, a PEG parser (and generator). Having only worked with LL/LALR parsers before, it was a little strange to work with, but the grammar is quite simple.

grammar.pest

document = { SOI ~ (statement | text)* ~ EOI }

statement = { tag_open ~ text ~ tag_close }
tag_open  = { "\<\$" ~ PUSH(tag_ident) ~ attr_list? ~ ">" }
tag_ident = { (ASCII_ALPHA_LOWER | "-" | "_")+ }
tag_close = { "</$" ~ POP ~ ">" }

attr_list = { " "+ ~ attr ~ (" " ~ attr)* ~ " "* }
attr      = { attr_key ~ "=" ~ "\"" ~ quoted_text ~ "\"" }
attr_key  = { (ASCII_ALPHA_LOWER | "-" | "_")+ }

quoted_text = { (!("<$" | "</$" | "\"") ~ ANY)+ }
text        = { (!("<$" | "</$") ~ ANY)+ }

The whole library is less than 100 lines of code (excluding generated code and tests.) You can view the "core" of it on Tangled, here. It's a bit ugly right now. I'm not sure if I could get it to be nicer, but I'm just glad it works robust enough to write blog posts in.

Using the library

Honestly, the main reason I wanted to work on this is... code block highlighting sucks. What's nice about this approach is that I can finally render them on the server instead of the client., with a robust parser (tree-sitter). To do this, I'm using the library autumnus. I was going to use the inkjet crate, but it got deprecated days after I found it. Welp.

rust

// SAFETY: function is not allowed to error. Annoyingly.
#[allow(clippy::expect_used, clippy::unwrap_used)]
fn code_block(contents: &str, attrs: HashMap<&str, &str>) -> String {
    let lang = attrs
        .get("lang")
        .or_else(|| attrs.get("language"))
        .unwrap_or(&"plain");

    let formatter = autumnus::HtmlInlineBuilder::new()
        .lang(Language::guess(lang, contents))
        .source(contents)
        .theme(Some(
            autumnus::themes::get("catppuccin_mocha").expect("Built in!"),
        ))
        .build()
        .expect("i hope this doesnt crash!");

    let mut output = Vec::new();
    formatter.format(&mut output).unwrap();
    let output = String::from_utf8(output).unwrap();

    maud::html! {
        .code-block {
            .code-language { (lang) }
            (PreEscaped(output))
        }
    }
    .into_string()
}

As you can see, there's still some papercuts with Makup, but it's perfectly usable for this. (Unwrapping here is not catastrophic, it's currently expected that the parsing will panic in certain cases.) I might try and add maud support directly so i don't have to call a conversion method, but trait trickery like that in Rust is maybe somewhat above my skill level.

The other use case I had for this was to render the speech-boxes that I use to add a bit of personality to my writing. In this case, I already had a function that generated them for non-post pages on my website. That means it was as simple as plugging that into my rewriter function:

rust

fn speech_box(contents: &str, attrs: HashMap<&str, &str>) -> String {
    let char = attrs.get("character").unwrap_or(&"deer");
    let emotion = attrs.get("emotion").unwrap_or(&"neutral");

    // ⤵︎ this function!
    speech(
        &match *char {
            "you" => SpeechCharacter::You,
            _ => SpeechCharacter::Deer,
        },
        &match *emotion {
            "worried" => SpeechEmotion::Worried,
            "shocked" => SpeechEmotion::Shocked,
            "happy" => SpeechEmotion::Happy,
            _ => SpeechEmotion::Neutral,
        },
        &html! { (PreEscaped(contents)) },
    )
    .into_string()
}

Footnotes

I've probably talked about this already on here, but the client side rendering was pretty horrible. When I was using Prism and Shiki, I used a special comments syntax for having unescaped markup in code blocks. When first loading the page, an empty code block would be shown, and then once the highlighter kicked in it would be swapped for a pretty code block. The one thing I currently miss from Shiki is the ability to have two themes and swap them with device color scheme. I believe this is possible with autumnus, but it would have to be a bit hacky. I'll open an issue now on the repo and see what happens.
I'm definitely not done working on it. I want to eventually port over the footnotes system, but that would require making my rewriter a bit more stateful (and adding void tags!) Specifically, I would need some shared state somewhere so footnotes can be ordered correctly and backreferences can be made. The current version of this is in a quick JS script I made.

should we be evangelizing the way we do

2025-11-25T00:00:00Z

Verb
evangelize (third-person singular simple present evangelizes, present participle evangelizing, simple past and past participle evangelized)

To tell people about (a particular branch of) Christianity, especially in order to convert them; to preach the gospel to.
To preach any ideology to those who have not yet been converted to it.
To be enthusiastic about something, and to attempt to share that enthusiasm with others; to promote.
— evanglize - Wiktionary

I was just thinking about Tech Evangelism. As a technologist, I am often to subject to the opinions of my peers I have some opinions of myself.

Here:

Editor: Either Helix or Zed right now. I switch between them based on context.
Programming Language: Rust.
OS: currently macOS, but my second pick would be NixOS. Probably.

I have formed these opinions from life experience. I have used a lot of editors, so I can somewhat confidently say that these editors fit me most. I have spent a lot of time with Rust and mostly enjoy working with it. I tolerate macOS the most out of the current options right now.

If you have been in programmer circles a lot, you will hear endless debate about programming language, or editor, or sometimes OS. I would like to question what purpose this serves in these spaces.

Why we might evangelize

People like sharing their opinions

I think this is a big one. People share opinions because its fun to share opinions, and engage in some sort of dialogue about the things you use. Uh. I'm not sure really why though.

Searching for connection?

We are a social species. If we share the same opinions about something, maybe it says something about a shared personality trait. For example, maybe if we both use Vim, we share some sort of hacker spirit.

Sharing joy?

Maybe we just remember the good times of using a tool, and want to spread that with others. I think the core of this is that using good tools makes us excited (or enthusiatic, like in the above definition) and we want to share how that made us feel with our peers.

What's wrong with evangelizing?

I think a lot of communities in tech are based on exclusion. Take, for example, the ideal of an Arch Linux user. If I were to describe the "popular culture" stereotype of an Arch Linux user, it would be that they are annoying and want to force their opinions onto you. This is a reductive way to talk about people who use a tool, but this was born from exclusion.

Mindful evangelism

This is why I try to practice being mindful when evangelizing to others.

Try and lead with why your tool is better, but not needlessly disparaging their tool.
Argue your point in good faith. This means listening to the concerns of the other person.
Offer some vulnerability in your argument. If you have used a tool a lot, you know it has downsides, so present them too.
Try and learn something from the other person too. You don't need to do the exact same things they do to connect with them. They likely know something about their tool that you don't, as well.

These should be pretty obvious, I think.

Squircles in CSS!

2025-10-22T00:00:00Z

Just wanted to shout out this cool new feature coming to CSS: you can now specify exactly how round you want your border-radii to be.

A normal radius would look like this:

The border corners are just arcs of circles. This is what the new property looks like:

css

corner-shape: notch;    /* or superellipse(-infinity) */
corner-shape: scoop;    /* or superellipse(-1) */
corner-shape: bevel;    /* or superellipse(0), a straight line */
corner-shape: round;    /* or superellipse(1), default. */
corner-shape: squircle; /* or superellipse(2) */
corner-shape: square;   /* or superellipse(infinity) */

/* You can also specify each corner separately. */
corner-shape: square squircle bevel scoop;  /* top-left, top-right, bottom-right, bottom-left */

Lined up, they look like this:

Your browser supports corner-shape.

Notch

Scoop

Bevel

Round

Squircle

Square

Your browser does not support corner-shape. A rendered image is provided.

You might want to use this effect for mimicking an iOS-style squircle, since previous ways of doing this had to use SVG masks (Here's the CodePen.) If you want to see more interesting ways of using this new feature, see CSS-Tricks article about it. (I think we might have a good replacement for the classic CSS Triangle!)

Making embed images with Typst

2025-10-21T22:00:00Z

Just making a quick post to show off new functionality. I saw a couple websites using Typst to generate OpenGraph embed images. I basically took the implementation from crates.io's crates_io_og_image library. (It's MIT licensed, I'm allowed to!)

One thing I noticed: invoking Typst is slow slow. I ended up having to add caching to keep rendered images around.

Another issue was that Discord embeds were, like, wrong? Well first, they looked like this:

I looked at MDN's embed meta tags, and saw that they used this:

html

<meta name="og:image:type" content="image/png">
<meta name="og:image:height" content="1080">
<meta name="og:image:width" content="1920">
<meta name="og:image:alt" content="The MDN Web Docs logo, featuring a blue accent color, displayed on a solid black background.">

I thought that maybe it couldn't determine the size, so used a small version? So I updated my site, and it still wasn't working. So I looked again, and noticed this rather unassuming tag:

html

<meta name="twitter:card" content="summary_large_image">

I guess so. I went to Discord's embed tester, and it explicitly says that they use Twitter embed stuff. I suppose this stuff isn't really specified. I feel like OpenGraph should add something like this eventually.

Anyway, I added all of this stuff and it worked. Yaaay.

Here's a sample embed:

There's a chance that I could accidentally mess this up if I put a big title or subtitle in. That would be pretty funny.

Web Components Are Easy, Mostly

2025-10-17T19:00:00Z

Web components are a tool you can use to give layout and functionality to custom elements, e.g. <hello-world>. There are, roughly, three types of web components. Most web component frameworks (Lit) are using Imperative Shadow DOM web components.

Let me break that down. Imperative means you create and modify elements through function calls instead of declaring a layout (e.g. in HTML). DOM is the tree model of the layout (HTML). A shadow DOM is a separate tree, which means it is somewhat encapsulated from the rest of the document (the Light DOM.)

The three types of Web component.
(CSR is client-side rendered, SSR is server-side rendered.)

Making Imperative Shadow DOM Components

You define a component in JavaScript by making a class and then adding your component to a registry. Let's try and recreate this element in a web component:

class SpeechBox extends HTMLElement {
	connectedCallback() {
		const shadow = this.attachShadow({ mode: "open" });

		const wrapper = document.createElement("div");
		wrapper.style.display = "flex";

		const speechImage = document.createElement("img");
		speechImage.src = "https://j0.lol/static/speech/deer/neutral.png";
		speechImage.setAttribute("height", "120px");

		const speechBoxBorder = document.createElement("div");
		speechBoxBorder.style.border = "5px solid rgb(176 152 232)";
		speechBoxBorder.style.background = "black";
		speechBoxBorder.style.color = "white";

		const slot = document.createElement("slot");
		speechBoxBorder.appendChild(slot);

		wrapper.appendChild(speechImage);
		wrapper.appendChild(speechBoxBorder);

		shadow.appendChild(wrapper);
	}
}

customElements.define("speech-box", SpeechBox);

html

<speech-box>
	<p>Hello there!</p>
</speech-box>

Codepen sample

When the component gets loaded, connectedCallback() is called. This lets you do a lot, but here we instantiate a Shadow DOM 'root' node, and imperatively add nodes to it. The <slot> element will let you poke a hole in your Shadow DOM to include Light DOM elements.

Yeah. I wanted to demonstrate taking 'imperative' to it's logical conclusion. This is what libraries like Lit help with. Here's what a very simple component looks like in Lit:

import {html, css, LitElement} from 'lit';

export class SpeechBox extends LitElement {
	static styles = css`
		div.border {
			border: 5px solid rgb(176 152 232);
			background: black; color: white;
		}`;

	render() {
		return html`<div class="border"><slot></slot></div>`;
	}
}
customElements.define('speech-box', SpeechBox);

Lit Playground

Being able to declaratively define your CSS and HTML is a lot nicer, and a lot of people who try to go down this route just re-invent Lit anyway.

Making Imperative Light DOM Components

This classification is more of a 'trick' more than anything. But it's a real thing you can do! You might prefer to work in the Light DOM if, for example, you are making components for your own website, and don't need encapsulation of styling. One thing to note is: because you lose the Shadow DOM, you lose the functionality of <slot> (and its sister <template>), which means you need to manually move around things you want slotted. Not much of a loss, though!

class SpeechBox extends HTMLElement {
	connectedCallback() {
		// get children before appending anything to element
		const previousChildren = this.children;

		const wrapper = document.createElement("div");
		wrapper.style.display = "flex";

		const speechImage = document.createElement("img");
		speechImage.src = "https://j0.lol/static/speech/deer/neutral.png";
		speechImage.setAttribute("height", "120px");

		let speechBoxBorder = document.createElement("div");
		speechBoxBorder.style.border = "5px solid rgb(176 152 232)";
		speechBoxBorder.style.background = "black";
		speechBoxBorder.style.color = "white";

		// slot children in here
		speechBoxBorder.replaceChildren(...previousChildren);

		wrapper.appendChild(speechImage);
		wrapper.appendChild(speechBoxBorder);

		this.appendChild(wrapper);
	}
}

customElements.define("speech-box", SpeechBox);

Codepen sample

Please note that you don't have to do this, and a simple custom element without any Javascript like this could still be called an "(Imperative) Light DOM" component.

Making Declarative Shadow DOM Components

So "Declarative Shadow DOM" is a method of using <template> (with a shadowrootmode attribute) to define a shadow DOM root in HTML only. You still need Javascript for initializing your custom element, and adding interactivity, but you can define styles and layout in HTML. You can make one like this:

html

<speech-box>
	<template shadowrootmode="open">
		<div style="display: flex;">
			<img src="https://j0.lol/static/speech/deer/neutral.png" height="120px">
			<div style="border: 5px solid rgb(176, 152, 232); background: black; color: white;">
				<slot></slot>
			</div>
		</div>
	</template>

	<p>Hello there!</p>
</speech-box>

Codepen sample

Compared to imperative examples, this is a lot simpler to understand. You make a template, punch a "slot" hole in it, and it just works. I like the idea of this a lot. You can just spit this out with PHP, or whatever you use as your server backend. The issue is, every time you want to use one of these components, you need to include the template again. This makes it quite a pain to use in practice, unless you want to do something like this:

php

<speech-box>
	<?php echo speechBoxTemplate(); ?>

	<p>Hello there!</p>
</speech-box>

(Did you know that you can use <?= and ?> here instead to omit the echo?)

You might think:

Why didn't they just let you name and reuse <template> blocks, so you don't have to repeat yourself constantly?

It turns out that the people who proposed this had thought of this. Their answer is that you can just copy <template> blocks with Javascript to repeat blocks of HTML. That's nice, but it does make this use case a bit more painful. Of course, something like this can easily be abstracted over with a framework.

There are a few ways that this could be improved in the future. One proposal, Declarative Custom Elements, would allow you to define an entire element in HTML so you could use it later without being encumbered with the template.

html

<definition name="my-element" constructor="MyElement">
		<template shadowmode="closed"> ~ </template>
		<script>
			class MyElement extends HTMLElement { ~ }
		</script>
</definition>

Conclusion

I hope this was an okay introduction to Web Components! If you are just starting out using them, I think it's important to know what you are doing with them. Mainly just so you can pick the best method of using them. If you think I didn't give a good overview (or just want more to read), please read through some of the provided articles below. Thanks!

Website Version 5

2025-10-16T19:50:00Z

I rewrote my website again!

TLDR

PHP → Rust
Static HTML templating → HTML inside Sqlite
Writing posts in-repo → Web post creator
GitHub → Tangled

Whyyyyy?

~~I'm unemployed.~~ I really hated the previous posting model of having to commit HTML to a git repo, commiting it, pushing it, git pulling on the other end, etc. With this new site, I can edit posts directly into a Sqlite DB.

The Stack

Umm. I'm using Rust now. To "simplify" this, I will present this simple diagram.

Version 4 (the previous website version) has a much simpler infrastructure. I wish Rust was this simple, but it comes with the territory.

I could have probably done this all in PHP. But it would have been a lot messier.

The "Templating Engine"

I like maud a lot. I've been eyeing it up for a future project. Let me explain the appeal.

Most Rust templating languages (minijinja) look like this:

html

{&percnt; for user in users &percnt;}
    <li>&lcub;&lcub; user.name &rcub;&rcub;</li>
{&percnt; endfor &percnt;}

You have to specify this in a separate file, and serialise any types you use. It's kind of annoying and necessitates something like serde to do wizard magic to your structs and enums. Maud looks like this:

rust

html! {
    h1 { "Hello, world!" }
    p.intro {
        "This is an example of the "
        a href="https://github.com/lambda-fairy/maud" { "Maud" }
        " template language."
    }
}

You really can just put this as the return type of a function. It's so much nicer. I don't have to fumble with a bunch of named .html.jinja files and all of your templating is "just there" with the code. It's honestly what I love about PHP so much. As a plus, you can just put any expression and splice it into your templates. Yes, you can nest this. It's ugly.

Ok, but why do you have a HTML rewriter?

Uhhmm. Well so I made a web editor for creating new posts.

It's a bit shabby.

I wanted to add a custom element. On web, this is pretty simple. On the server, however, I am just feeding HTML into maud. So, I wrote a rewrite rule in lol-html:

rust

let contents = rewrite_str(&post.contents,
    RewriteStrSettings {
        element_content_handlers: vec![element!("speech-box", |el| {
            let char = el.get_attribute("character").unwrap_or("deer".to_string());
            let emotion = el.get_attribute("emotion").unwrap_or("neutral".to_string());

            let SpeechDetails { class, alt, src } = render_speech(/* snip who cares */);

            el.set_tag_name("div")?;
            el.set_attribute("class", &format!("dialog speech {class}"))?;
            el.before(&format!(r#"<div class="dialog-box"> <img class="raw dialog profile" width="120" height="120" src="{src}" alt="{alt}"> "#), ContentType::Html);
            el.after("</div>", ContentType::Html);

            Ok(())
        })],
        ..RewriteStrSettings::new()
    }
).unwrap();

It's somewhat gross, but it means I don't have to run JS just to put funny images on the screen. I don't want to deal with layout shift and FOUC and all the other annoying client rendering issues.

Now I can just do this and not worry about it:

html

<speech-box character="deer" expression="happy">
    <p>awawawawawawawawawa</p>
</speech-box>

The Web Framework

I have so little to say about poem. Which is really awesome! If you have used axum before, it's basically just that but with everything you want bundled inside. No more tower_sessions!! It's nice. I like it.

Moving to Tangled, and other thoughts

Unsure what to think about 'git forges' in general. Ideally, there would be a perfect code forge that:

hosts all of you stuff for you, for free, forever
isn't hosted by a for-profit corporation

This doesn't really exist, but Tangled is a step towards this. It's built on ATProto (which is decentralized), therefore you can log in with your Bluesky account. You can host your own code storage (so if Tangled Corp Inc™ annoys you personally, you can move your data away from them) but I don't care about that too much. I like how the frontend feels much lighter than GitHub. I probably won't move all of my projects to this though (yet?)

Using `jj`

I decided to try Jujutsu for this project. I like it a lot! It's a version control system that "wraps over Git" and lets you control the underlying data in a different way. My favorite feature is that you can write what you do before you do it, instead of trying to name what you have done after the fact. It's mostly a psychological thing, but I feel like this helps me stay focused on what I set out to do.

I would suggest trying it if this seems interesting to you, or if Git confuses you a lot.

On loving your website

2025-06-27T15:00:00Z

I think — at least for me — that blogging is a form of journaling. I feel like if I was journaling physically[1] I would love to take care of a physical tome containing my thoughts. Decorate it, take care of it, et cetera. Following this logic, I take great joy in taking care of my website. Polishing the CSS, adding nice features, making a nice favicon[2], and other stuff (sorry I have been working on it a lot recently.) So, uh, I think I want to just gush about all the changes I have made recently to my site, and maybe circle back to some deeper point about self-love.

Lots of commits.

Favicons are weird

I have many questions about favicons.

Why are they called favicons?[3] Favorite icons? Shouldn't they be called like bookmark[4] icons or something? Did they make this up in like Netscape Navigator or Internet Explorer or something?[5]
Why are they so small? It's really hard to represent anything in a 16×16 square. At least we can now use 32×32, and people who know their way around a vector design program can use an SVG.
How have we not come up with a better way of linking an icon to your website than stuffing a bunch of <link> tags in your <head>[6]??

Um. Sorry about all the footnotes. When I started working on my current iteration of my site, which I arbitrarily named V4, I was getting into drawing at the same time. I wasn't sure what to fit in that thing, so I just put the drawing I had in there. It uh. It looked bad. Here's a recreation: . Ew, right? So a few months ago I made this new drawing, the dialog box deer that you have definitely seen on this site already. And I realised that I can adapt it into a favicon: . Much clearer, right? Just bicubic scaling the image down makes it quite readable, which I was honestly shocked at.

Changing fonts

My old heading font

My new heading font

I'm a programmer first, not a writer. So when I was making my website, it just made sense to add a touch of monospace to it. I imported my terminal font (Maple Mono) into my project and set it as a heading font, italicized with cursive symbols. Though I was getting kind of tired of it. I don't think monospace fonts look that good when at such a large size. So I found this new font on Google Fonts (where else?) called Hepta Slab and fell in love with it immediately. It's still very round, which captures the sort of look the rest of my fonts have (the sans-serif font is DM Sans) while feeling way more in place than a monospaced font.

I think people all have complex relationship with fonts. Though maybe that's just my autism speaking. People hate Comic Sans. People love to write Word documents with Arial. Web developers love Inter. Everyone sort of has their own font, in their handwriting[7]. You might feel comforted by a monospace font. Cursive might remind you of rigid school structures.

Physicality

The home page is floating on a background.

The page has a nice border and a shadow now.

As someone with autism, I have a divine fixation with tactile things. Shapes feel nice. During this redesign, I've been trying to add physicality wherever possible. This isn't just because of Apple's Liquid Glass design language, but I think flat design is boring generally. I think many people do??

I've been adding physicality wherever possible. The figures now have a shadow and border. Well, I haven't really been able to add it anywhere else, due to some rigid CSS limitations. I'll figure it out eventually. I hope this looks good!

Cute little icons

Old arrow icons.

New, nice clock icons.

Old comment section. Uses text for reply and like labels.

New comment section. Lots of icons, and a LOT of tweaking to get things feeling better.*

＊ Note that the comment lines are very thin, and you might have to zoom in to see them.

I found a new icon library: CSS.gg. They serve very simple SVG icons you can just throw in your source. These have been sprinkled around where necessary.

Code Blocks and Highlighting

rust

fn main() {
    println!("Here's a code block!");

    // Explode
    unsafe { unreachable_unchecked!() }
}

I'm currently using Prism.js for code highlighting. It's widely supported, has good theming, and a heck of a lot of language support. Um. The only issue is that it doesn't really make sense in $CURRENT_YEAR. Since the advent of tree-sitter, code highlighting is done via syntax trees instead of regex parsing. It's faster, and makes more sense. However: tree-sitter is written in a compiled language. This makes it a pain to run in the browser [8]... There's web bindings via wasm on npm, but it would need a bit of work to use to highlight. Plus, I'm sort of worried about the size of WASM blobs. Each language requires its own blob, so I could be pulling in several wasm blobs on every site. Prism.js is (at time of writing, on this site) $74.4 kB JS + 1.4 kB CSS$ big. As a test, I pulled in tree-sitter JS, WASM and the Javascript WASM blob. That alone (without any highlighting code or anything!) is $152 kB JS + 206 kB WASM + 359 kB WASM js grammar$ . Yipes!

So this is why I'm using Prism. There are other regex-based highlighters, but this one works fine. One thing I added recently is the little language tag, which makes it more obvious which language is in the code block. I added it for my blog post where I talk about Swift in comparison to Rust.

About footnotes

Umm. I like tangents. You might notice the large footnotes section on this article. This was pretty fun to implement! If you've used markdown, and not really thought about writing in HTML, you might assume that footnotes are a HTML primitive. Nah! My current implementation looks like this:

html

<p>
    This is a paragraph <a ref="umm_actually"></a>.
</p>

<footer>
    <h2 id="notes_heading">Footnotes</h2>
    <ol>
        <li id="note_umm_actually">
            Well, there's not really much text there. Its a sentence.
            Should it really even be put in a p tag?
            It's kind of semantically wrong.
        </li>
    </ol>
</footer>

A script comes along and fills out everything to be semantically correct HTML. It's based on this great article about making footnotes accessible, but I tweaked it a bit to remove markup boilerplate. Note that the <a> tag uses ref, not href. Not sure if this attribute is used in other places, but I thought it would be fine to use here. (It gets stripped by the script and replaced with a href.)

One fun issue I found is that the "return" ↩ symbol looks different depending on browser. Mobile browsers (at least mine) will make it an emoji, while desktop browsers will use a normal font. You can choose this behaviour by suffixing a unicode character:

Default	↩	⛄
Variation Selector 15 `︎`	↩︎	⛄︎
Variation Selector 16 `️`	↩️	⛄️

Weirdly, on Chrome macOS it always picks the snowman emoji.

Aside on writing in HTML

I think HTML might be the most expressive way to write. You can express almost anything (see the fonts section :p) and it doesn't have the same issues that other markup formats have with wordiness (if you think HTML is bad, see $L A T E X$ .) I see most bloggers using markdown and I wonder: why? It makes everything harder. If you want to have a "component", you basically have to extend markdown, then have a framework or preprocessor to convert into HTML. You can put HTML in markdown (sometimes), but the syntax is very odd. Either way, it's gross.

I think people are scared of HTML. It's not that hard to write, and you can use Emmet to write a lot of HTML from very understandable abbreviations if you have worked with CSS. footer>h2#notes_heading+ol>li*3 produces an entire footnotes section from earlier, and it lets you use tab to jump between text fields to fill.

You also lose a lot of semantic information with markdown. You could represent a figure>img+figcaption like this:

![alt text](/static/foo.png)
This is an image.

But what happens when you want to style a figure? If you want to center the caption, frame the image, add a ::before pseudo-element with a counter, etc. What will a screen reader do when it comes across your figure? Not what you want it to do!

So it's either restrictive, ugly, or heavy. Um, maybe that was convincing. I think using HTML thoughtfully like this makes you better at using HTML thoughtfully elsewhere. When writing in HTML, go to MDN and think: "Is there an element for this?" By doing this, you'll learn about new tags like <samp> for quoting output from a program, <abbr> for acronyms or abbreviations, all of MathML, <ruby> for displaying pronounciation( pro-noun-si-a-tion ) . It's fun :)

Trying to conclude this post

I've had a lot of fun writing this post, as well as working on my website. HTML+CSS is one of the most expressive technologies we have in software development. Working on your personal website is, I think, a form of self love. It's a construct built for the express purpose of self-expression. Express yourself!

Footnotes

I've tried journaling physically before. I just really struggle with it. I think my hands aren't up to the task? They are very weak. I've always struggled with it. I'm left handed and I don't think I was ever raised to write properly? Maybe it's some deeper problem though. Oh well.
Did you know that Safari is really really annoying about favicon caching? Details are here, but it really sucks. If you're trying to work on your favicon, see this great article about it, highlighted to me by one of my most favorite websites: CSS-Tricks.
Because they helped differentiate URLS in your... favorites. They are called favorites instead of bookmarks because Microsoft said so.
Aside: I really don't use bookmarks. Maybe this really dates me as a member of Generation Z, but it's almost always a lot easier to just let the powerful browser autofill b into bsky.app for me. And the bookmarks toolbar is such a waste of space! If I don't have the URL saved in the browser for whatever reason, searching into Kagi will almost always give me what I want.
They were introduced in IE5. Makes sense why they use the very Windows .ico format then.
Google actually tried. When they introduced Progressive Web Apps, they made a new Web Manifest that you can stuff (Android) icons into instead of the head. Here's what that looks like:
json
```
{
  "icons": [
    { "src": "/icon-192.png", "type": "image/png", "sizes": "192x192" },
    { "src": "/icon-mask.png", "type": "image/png", "sizes": "512x512", "purpose": "maskable" },
    { "src": "/icon-512.png", "type": "image/png", "sizes": "512x512" }
  ]
}
```
It would be nice if we could standardise on this for favicons or whatever. But everything has been set in stone, I guess.
Shantell Sans has a really lovely story. You can read it here.
You may be asking: Why don't you just render it serverside? A few reasons:
- My website is in PHP, not a compiled language like Rust.
- I did this before, and made an impossible-to-maintain PHP extension that sucks.
- Even if I did this, I'm moving the highlighting computation time onto the "load bearing" HTML step instead of loading after the rest of the page is loaded.
- Like, I'm not caching my pages (because PHP) so every page gets rendered on every request. If I was making a static site generator this would make a lot more sense. But I'm not really interested in re-architecting my entire website for this purpose (yet...)
So, I'm choosing to stick with client-side highlighting.

Is Swift becoming unergonomic Rust?

2025-06-25T15:00:00Z

So about a week ago, I was bored and watching WWDC 25 (pronounced "dub dub DC", apparently.) I was watching this video: Improve memory usage and performance with Swift, where they show off some new features in Swift to reduce memory overhead and increase safety (feel free to watch this alongside!) The first new standard library construct they show off is InlineArray<N, T>, which acts like... an array. In Rust terms, the normal Swift array is similar to a Arc<Vec<T>>, where it is a growable collection that can be shared across threads and is copied on write. To keep the analogy going, the new Swift InlineArray is like a Rust array: [T; N]. To make it clear, Array is heap-allocated and InlineArray is stack-allocated.

swift

func array() {
    var array = [4, 5, 6]
}

func inlineArray() {
    var array: InlineArray<3, Int> = [4, 5, 6]
}

And let's compare to Rust:

rust

fn vec() {
    // I could wrap this in an Arc, but
    // that's not really what real code would do.
    let mut vec = vec![4, 5, 6];
}

fn array() {
    let mut arr = [4, 5, 6];
}

You can probably see the argument I'm going to make here — This is less ergonomic. Rust is often said to have bad syntax, but here you can see that the better performing option is just easier than the heap-allocated version.

Safety

So another topic in the video is how to efficiently read from a reference counted collection. In order to avoid the reference counter, and read data directly, one would previously use an unsafe pointer to do a direct read.

swift

// Safe usage of a buffer pointer
func processUsingBuffer(_ array: [Int]) -> Int {
    array.withUnsafeBufferPointer { buffer in
        var result = 0
        for i in 0..&lt;buffer.count {
            result += calculate(using: buffer, at: i)
        }
        return result
    }
}

As highlighted in the talk, these buffers are unsafe partially because they could be used outside of the scope of the function (e.g. returned, or stored as part of a structure), and misued. In order to make this operation safe, they introduce a type called Span, which points to a contiguious block of memory. In order to make this safe, a new "Marker trait" (Rust speak) called Escapable is added to the language. This trait is auto-added to all types by default, and you can specify if your type cannot be used outside of its context with ~Escapable. Pretty neat language feature!

This is a very different approach to Rust. We deal with pointer unsafety by relegating them to Unsafe Rust, a language that lives alongside Safe Rust. But also — We sidestep this whole problem. Vecs are not reference-counted (you have to wrap them in a Rc or Arc for that,) so we don't have to sidestep the reference counter.

Conclusion

You can clearly see the difference in these language's designs from these two examples. Swift makes working with types as easy as possible, while letting you "drop down" for performance. Rust instead makes the most ergonomic pattern the most performant, while letting you "build up" convenience by moving to heap allocation with Vec<T>, adding copy-on-write with Cow<T>, or reference counting with Rc<T>.

I think it's clear who these language features are for — Swift library maintainers. Being able to write more performant code for your users will make everyone happy, and doing this without unsafety is nice. I don't think this is really for app developers, or anything like that. Making all of your array accesses use spans to dodge the reference counter is technically faster, but makes things much more annoying to maintain than the obvious solution. I think the talk makes this clear, as they show off a new Binary Parsing library at the end which uses these new language features.

As for the title of this article. I don't think Swift is becoming unergonomic Rust (Betteridge's law of headlines wins again.) It's just bringing in features similar to Rust to "drop down" to. Honestly, a "less complex" Rust has a good place in the world of programming languages. There is some work adjacent to this, see the Alloy language: a fork of Rust that gives you opt-in garbage collection for things like Linked Lists. I think it's easy to write things like this off — but all languages have their tradeoffs. What makes you a good developer is being able to take all of the values of prospective systems and being able to pick the right one! (Bryan Cantrill has a great talk on this: Platform as a Reflection of Values)

How I use the new Spotlight

2025-06-25T00:00:00Z

So. Raycast is a replacement for Apple's Spotlight, a quick search accessible anywhere in macOS with ⌘+Space. It is "extendable", in that it has an in-app extensions library which add entries which do various things. This is useful in various ways, but I mostly use it to quick-search various websites, like Kagi or MDN.

In macOS Tahoe, Apple lets you run "Shortcuts" from Spotlight. These can take a text input directly in Spotlight, and run basically whatever. One decent use for this is to run something like brew update to update your packages.

What are "Shortcuts"?

Imagine if Scratch was integrated into your OS. You can organise blocks to make a kind of annoying form of computing. It has strange limitations.

A simple shortcut. Useful, though!

One neat thing is that you can bind a shortcut to a.... shortcut? Like, they call this "Quick Keys", but it's like a shortcut alias. If I want to search Kagi, I can make a kg alias, then kg↩︎Foo to search "Foo" on Kagi.

That's basically it. Shortcuts are kind of fun to make, but can be a bit infuriating if you don't know how to use the esoteric blocks. On macOS, you can at least fall back to sh, or a scripting language like Python.

Here's all the shortcuts I've made so far. Can't really think of any more I could make.

The macOS Tahoe beta is so bad that it made me switch to Chromium.

2025-06-24T22:00:00Z

Every damn year I do this. I see new beta, I install beta, beta sucks, I cry. Why do I keep doing it?

Yeah... So basically everything here is worse. I don't really care to have "discourse" about the new design, but it sure seems to make even basic things like Finder run slow somehow.

It has some really rough edges too... What even is this? I think the glowing "tab bar" is the most offensive thing here.

One issue is Safari is really slow. Embarrassingly slow. I've long been an advocate for not using Chromium, since Google is the devil or whatever. But the new Safari update makes using WebKit damn near unusable. It can take like, upwards of 30 seconds to open a new tab sometimes. Maybe my 8GB M1 Macbook Pro is showing its (rather young) age, but I don't think it's just me.

So I decided to make a tentative deal with the devil. I'm currently using... Thorium. It's some chrome fork that a friend recommended to me. It claims to be 'The fastest browser on Earth.' Whatever. I just want a no-nonsense browser that won't freeze for damn seconds while I work. For that purpose, it has been very good.

Why not Firefox? Mainly because it's the only macOS browser that doesn't have by default WebGPU support somehow, and that's like what 80% of what I'm interested in right now.

The new Spotlight is pretty good, though. I've been having fun making shortcuts for it. It has the potential to replace Raycast fully (but Spotlight has been quite buggy with shortcuts as of now.)

I added Bluesky powered comments!

2025-03-26T20:00:00Z

I added comments to my site!

It works by linking to a bluesky post, and mirroring the comments to my website. It's pretty cool :)

Here's the basics of how to use it:

html

<!-- You should download and mirror the script if possible! -->
<!-- https://github.com/LoueeD/bsky/blob/main/comments.js -->
<script type="module" src="https://esm.sh/gh/loueed/bsky@v1.0.0/comments"></script>

<!-- You can plug your post URL into https://pdsls.dev to get the URI here. -->
<bsky-comments post="at://did:plc:by6abidhbnj6siox5if2wzq6/app.bsky.feed.post/3llckts3ryc2w"></bsky-comments>

Yeah, that's basically it. I didn't make it or anything. Just want to show it off.

The only issue is... how am I going to post this and get the ATproto uri before I publish it?

How to run games on macOS like it's SteamOS

2025-03-22T19:00:00Z

Whisky was recently pronounced dead ^[src]. This was inevitable. It wasn't really that good either. However, this leaves a void in the macOS gaming community of Wine GUIs that don't cost an arm and a leg.

However, a recent revival of Wineskin has come out, called Kegworks Winery. It's pretty decent. Here's a tutorial on how to use it.

Installation

Install Kegworks Winery. Here's the brew command they have on their GitHub. ^[src]

brew upgrade
brew install --cask --no-quarantine Kegworks-App/kegworks/kegworks

Open it up and install a version of CrossOver wine (WS**WineCX**)
Make a wrapper app (Be prepared for this to take a while, and freeze up.)
Open up your new wrapper
Notice that your new wrapper application has an AI generated icon. Ew. Change that to something better. (Here's a Steam icon.)

Steam

You want to run steam. Probably. Open winetricks and run the steam action.
Once that's done, go to 'Advanced' and change the Windows app to Steam.
You will want to use a DirectX translation layer:
- D3DMetal is the official, Apple supported, translation layer. This will have the least overhead and, usually, widest compatability. If you're unsure, use this one.
- DXVK is used widely on macOS and Linux for gpu call translation. This should be your fallback if D3DMetal fails you.
- DXMT is a newcomer and focuses only on DirectX11 to Metal translation. Some games will work great with this. ^[src]

Tweaking

You may also want to tweak some other graphics settings:

You may get better or worse performance by tweaking which type of synchronization you use. There are two options in Kegworks and Crossover. Personally, I have not seen any difference between the two.
- Eventfd-based synchronization, or ESYNC.
- Mach semaphore-based synchronization, or MSYNC ^[src]
High DPI mode. If you're on an Apple display, you probably have a high DPI. This is quite annoying to do.
1. Open regedit
2. Go to HKCU\Software\Wine\Mac Driver
3. Then set a new string value RetinaMode to Y ^[src]
4. Open winecfg
5. Change the dpi. Note that the default is 96dpi. For a 2× DPI monitor, go for 96 × 2 = 192dpi.
If you're often switching between high dpi and 96dpi monitors, I would recommend making a separate wrapper app so you don't have to undo and redo this hack constantly.

EDIT: I made a tool to automate this: winebottle-retina-toggler. I also made an issue on Kegworks Winery in hopes of a better solution.

Troubleshooting

Theoretically, Steam should "just work." Give it a test run before you close your wrapper app. If your wrapper stops working, open up your wrapper .app with "Show Package Contents" and open KegworksConfig.app to get access to the config menu again.

Annoyingly, Steam is quite buggy in wine. This is just because Steam sucks. It's a web browser running through three translation layers (D3DMetal, Wine, Rosetta 2.) It is still pretty usable, though, and the macOS build of Steam isn't much better!

Performance and Compatibility

It's alright. The main issue is memory constraints. If you have an 8gb Apple device, you will feel this when you try and load large games. If you want good benchmarks, I can recommend Andrew Tsai's channel. If you need other performance & compatability details, try the AppleGamingWiki.

Conclusion

Free yourself from the shackles of productivity

2025-03-21T12:00:00Z

One of the things that has been plaguing me recently is editor choice. I've been a programmer for a large portion of my life, and the editor is the window to code. Naturally, I have tried a lot of editors:

IntelliJ and friends
VSCode
NVIM
Helix
Emacs
Nova
Zed
Micro

It is easy to switch editor. Most editors use the same LSP backends (IntelliJ is an exception!) So why switch?

"Modal Editing is more productive"

My first big switch was to NVIM. I was instantly sold on the idea that I could use my keyboard to do actions quicker. And you can! After learning how to use vim keybinds, you can do a lot of actions very quickly. Is this good, though? One can quite easily see the link between 'actions per second' and productivity, but I would like to argue that this is not useful.

"Helix has easier keybinds"

What sold me on Helix, a TUI editor made in Rust, was two things:

It claims to have keybinds that make more "sense"
It claims to have faster actions per second than vim keybinds

Instead of having an "action to selection" model, it has a "selection to action" model, which supposedly makes it more intuitive. The issue here is that productivity and intuitiveness are kind of fake words in situations like this. Nobody has stats on this! The developers chose to make it like this because they thought it was better. And that's fine! The issue is, none of this is objective in any way. You are not a better programmer for using a modal editor. Even if modal editing was an objective good, developer productivity is not a concrete measurement, and probably is influenced by a wide amount of variables. Caffeine intake, or hours slept, is probably a better measure of productivity than editor.

It doesn't matter if there is a "best editor" or not

That's my thesis. All editors are, functionally, the same program. You can do whatever you want in any editor about as fast as any other editor. I will not defend IntelliJ over VSCode, or anything similar, because they are the same. Stop taking editing so seriously, and relax!

Can you tell I don't care about seriousness?

But...

But I like using $EDITOR!

That's good! I'm not on a crusade. I think discussion just orients around "productivity" and other such programming metrics too much in editor conversation. I think people tend to forget that we are human sometimes! If $EDITOR is what makes you feel good, go for it!

My site went down!

2025-03-20T22:00:00Z

My site went down! This is because the syntax highlighting library I made in an older blog post broke! Instead of just updating it (it was a pain because ext-php-rs is hard to use...) I just replaced it with Prism.JS.

This library is a lot simpler and better maintained. The only downside is that highlighting happens on the frontend, which probably means some sort of FOUC happens. The benefit is that I don't have to maintain a PHP library in Rust.

While doing this, I realised that I could make a lot of my site a lot easier to maintain if I just drop build steps.

Blogging in HTML

It's not that hard! The downsides of having to use XML-y tags everywhere is that you gain the benefits of concrete syntax. Another benefit is Semantic HTML, which let's me do things like abbr's.

It's pretty fun to read all the semantic tags and try them out. And it's fun to read the MDN! Click here for a combination of both of these. =)

Styling

I changed the font on my website from Cascadia Code to Maple Mono. I think it complements the body font a lot better! And I use the font in my editor now instead of Cascadia.

While changing styling, I found a horrible bug where a <pre><code> block's contents would influence the size of the document's page, even when scrolling. To fix this, my partner figured out that because I was using a display: grid; element as a document wrapper, the grid was calculating it's min-width with the minimum size of all elements in the body.

The fix, of course, is trivial:

css

.wrapper {
    display: grid;
    grid-template-rows: auto 1fr auto;
}

main {
    /*
        Needed, otherwise .wrapper grid will use `min-width: min-content`.
        Problematic if an element expands past 100vw,
        where it will cause main to grow massively.

        https://developer.mozilla.org/en-US/docs/Web/CSS/min-width#values
    */
    min-width: 0;
}

Dialog box

That's about it, other than some other stylesheet cleanup (I removed a bunch of calcs and moved some px values to rem!) Keep things simple!

RSS is done!

2024-10-10T20:00:00Z

Just a short post!

I added RSS (technically an Atom feed) to my website! You can now subscribe to my blog posts with the link on my blog index or click here to add me to your RSS reader.

Implementation

I used this very colorful library from "Starbeam Rainbow Labs": atom.gen.php. It's quite easy to use, and less buggy than others that I found.

I had to pull in Carbon (great library) to deal with dates better too (I was storing them in a quite silly way before.)

Pretty simple, don't you think?

php

<?php

use Michelf\MarkdownExtra;
require_once "remote/atom.gen.php"; # https://starbeamrainbowlabs.com/code/phpatomgenerator/
global $posts;
$host = "https://j0.lol"; // So this doesn't break when im working on localhost

$feed = new atomfeed();
$feed->title = "j0's blog";
$feed->id_uri = $host . "/blog";
$feed->feed_uri = $host . "/feed";
$feed->logo_uri = $host . "/static/j0site-pfp.png";
$feed->addauthor("Jo Null", "me@j0.lol", "https://j0.lol/", "author");

foreach ($posts as $slug => $post) {
    $parser = new MarkdownExtra();
    $content = $parser->transform(
        file_get_contents("./posts/" . $slug . ".md")
    );

    $feed->addentry(
        $host . "/blog/" . $slug,
        $post["title"],
        $post["date"]->getTimestamp(),
        "Jo Null",
        $content
    );
}

header("content-type: application/atom+xml");
echo $feed->render();

When to use Rust

2024-09-29T12:00:00Z

Part of using a tool is to decide when to use it instead of using another tool. I think we should look at programming languages the same. No language will ever be "one size fits all", as they all have small differences that will make them better for different use cases.

Some examples of when to use Rust:

When you're doing low-level development

If you're working low level, and you want your code to be correct, use Rust. This one's pretty obvious. I like doing a lot of low-level game development (working on obsolete hardware, writing shaders, etc.) and Rust is great for this as it has lots of great tools and frameworks for this!

When you're writing performant code

This is basically the same as the previous point, but Rust's "zero cost abstractions" mean that you can work at a higher level and write performant code. Sometimes.

When you need something to be airtight

One great example of this is Element X, a Matrix client. Matrix rolls their own encryption, and while I don't claim to know much about implementing encryption, avoiding memory unsafety is a pretty good idea.

Matrix rolls matrix-rust-sdk with their Android and iOS clients by making bindings. This ensures that all of their clients work the same way when decrypting messages or whatever people on Matrix do. It also means that their encryption logic is faster (probably).

Note that they don't write the entire app in Rust! It's not worth it!

When you're learning Rust (or just having fun)

All of this doesn't matter when you're still learning. When you are learning, it's best to strive for the thing you want to do whether it's worth it. Tackling things that aren't easy will teach you way more lessons than if you write 50 CLI calculators.

When you really want to use that library

Sometimes it's worth it, just for that one library that someone made well. What I would recommend doing in this case is to make bindings to a language that's more appropriate for your use case. This is a good learning exercise too!

When not to use Rust:

A CRUD web app

This one is very painful to me because I did this. It's really, really not worth the hassle. Use Laravel. It's perfectly engineered for producing shiny CRUD apps.

If you really care about how performant your site is going to be, maybe consider using Rust.

Your personal website

I made this mistake! It was fun to make at first, and I enjoyed applying my knowledge, but it became such a burden to maintain.

Axum puts way more overhead on your program than something simple like PHP's AltoRouter. You have to be a real HTTP server and deal with all that comes with being a real HTTP server. Another thing is that Axum requires you to get all of your state via specifying them in handlers, and then you have to worry about lifetimes and stuff. Maybe I'm nitpicking, but it's too much for a small project.

You will end up importing a lot of crates. Rust doesn't come with a lot to help you write a blog! I ended up with about 20 dependencies for my old blog site.

Your iteration time will slow because of inflated build times. This one sucks if you're writing a blog! You have to recompile it every time (unless you're smart about it!) This gets worse the more you add to your site, punishing you for pouring more care into your website.

A GUI app

Overplayed, but Rust GUI sucks.

If you're making a small program, you can get away with egui + eframe for a UI. It's pretty well-made for this use case. If you're going to make a larger program, make bindings from a backend to a frontend in a more appropriate language (Swift, Kotlin, C/++/#) or just don't use Rust. Consider why Rust would help you with your program, and if that outweighs the technical debt of gluing a Rust blob to your program.

If you're insane enough (or well funded enough), you can get away with making your own GUI. Good luck!

A conclusion

These are just some recommendations, from doing most of this stuff myself. Rust is a fun language, I enjoy it a lot, but I can get really burnt out when I end up using it wrong.

You can do anything you like, and I recommend it, but please be kind to yourself. If you find yourself knee-deep in a Rust program and thinking "I am really not enjoying myself", maybe try using something else. Keep doing things and having fun!

Color Schemes

2024-09-25T12:00:00Z

Let's talk about color schemes on my website!

The CSS

If you haven't noticed, I'm using Tailwind colors. Yes, that Tailwind. Why? I like having a clear palette of colors, which is the one thing that forsaken ECMAScript library does right.

If you look at my CSS (I don't minimize it!) you will see at the start:

css

:root {
    --dull-lavender-50: 247 244 254;
    --dull-lavender-100: 239 235 252;
    --dull-lavender-200: 227 218 250;
    --dull-lavender-300: 206 189 245;
    --dull-lavender-400: 180 151 238;
    --dull-lavender-500: 155 109 229;
    --dull-lavender-600: 140 77 218;
    --dull-lavender-700: 124 59 198;
    --dull-lavender-800: 104 49 166;
    --dull-lavender-900: 87 42 136;
    --dull-lavender-950: 54 25 92;

    --steel-gray-50: 243 243 250;
    --steel-gray-100: 233 234 246;
    --steel-gray-200: 214 214 239;
    --steel-gray-300: 189 189 228;
    --steel-gray-400: 167 162 215;
    --steel-gray-500: 148 138 202;
    --steel-gray-600: 131 114 185;
    --steel-gray-700: 113 96 162;
    --steel-gray-800: 93 80 131;
    --steel-gray-900: 77 69 106;
    --steel-gray-925: 55 49 76;
    --steel-gray-950: 34 30 46;
    --steel-gray-975: 17 15 23;
}

These aren't the color schemes that come with Tailwind, just the system that Tailwind uses for it's color schemes. And I'm not really sure where the actual code came from (probably some SaaS site that went pay-to-win) but I think it's a pretty decent way to pick colors for your website.

How to use this

In your real CSS, you don't want to be using these wordy variables. You should abstract over them. Here's a great way to do that:

css

:root {
    /* You need this here! View the MDN page for `light-dark()` if you're curious. */

    color-scheme: light dark;

    --bg: light-dark(
        rgb(var(--dull-lavender-200)), /* Light */
        rgb(var(--steel-gray-950))     /* Dark  */
    );


    --text: light-dark(
        rgb(var(--steel-gray-900)),
        rgb(var(--dull-lavender-200))
    );
}

This lets you pick your light and dark colors together! Much better than a media query. Here's some good design tips if you're doing that: CSS Tricks

Make sure...

Make sure you use the rgb() representation, not the hex (or use hsl). And leave out the rgb()! This lets you add transparency like this:

css

.whatever {
    color: rgb(var(--steel-gray-50) / 50%);
}

It's a little weird to look at, but it's better than having to make --steel-gray-50-transparent.

The tool to do this for you

There's hundreds of tools out there to make configs for you (here's my favorite). It doesn't really matter which one you pick, as long as it outputs hex codes. Here's some glue to convert between Tailwind configs to CSS (just in case you don't have some weird Emacs keybind to do this for you):

Color name:

Your Tailwind Config:

Please make sure you format it like the example above. You can leave whitespace or quotes or whatever.

This button will work on the placeholder, if you wanna play around.

Attributions
Hex to HSL Source:
https://www.jameslmilner.com/posts/converting-rgb-hex-hsl-colors
Hex to RGB Source:
https://codepen.io/othmanDes/pen/VWRLrP

Site remake

2024-09-25T10:00:00Z

I remade my website! I went from using Rust to PHP!

Why? Don't you love Rust?

I love Rust! I don't love using the wrong tool for the job though! I think that PHP is the perfect language for a Personal Home Page.

It's interpreted, so I don't have to recompile the thing every time I want to change something
PHP is quick and easy, and comes with great templating built in.
- In Rust, I had to import minijinja to do this

Rust web development is dependency hell!

Dependencies in Rust suck. They add to your compile time, mess up your Cargo.toml, and if they have macros they're even worse for compile time!

Look at all the dependencies I used to make this site!

toml

[dependencies]
ansi-to-html = "0.2.1"
axum = "0.7.4"
chrono = "0.4.35"
comrak = "0.21.0"
erased-serde = "0.4.4"
include_dir = "0.7.3"
itertools = "0.12.1"
kdl = "4.6.0"
knuffel = "3.2.0"
miette = { version = "7.2.0", features = ["fancy"] }
minijinja = { version = "1.0.16", features = ["loader"] }
rand = "0.8.5"
select = "0.6.0"
serde = { version = "1.0.197", features = ["derive"] }
syntect = "5.2.0"
thiserror = "1.0.58"
tokio = { version = "1", features = ["full"] }
tower-http = { version = "0.5.2", features = ["fs"] }
tracing-subscriber = "0.3.18"

How many dependencies do I have in PHP?

json

{
    "require": {
        "altorouter/altorouter": "^2.0",
        "michelf/php-markdown": "^2.0"
    }
}

Two! I could probably get it even lower if I were to use my web server's routing, but ehhhhhhhhhh

Altorouter is a pretty nice to use router, and PHP Markdown renders my blog's posts.

Okay, but how do you do syntax highlighting?

PHP-Markdown doesn't come with it! We need to shoehorn it in ourselves.

After looking around, I found Shiki-PHP, which offers code highlighting by making bindings to Shiki: https://github.com/spatie/shiki-php

However, Shiki is slow. Very slow. It uses Node JS. As we both know, running JavaScript on the server is the worst thing you can do for your poor program.

I used Syntect before to do highlighting in Rust. It's very good! Just one issue: It's in Rust!

Let's use Rust in PHP!

Using ext-php-rs, all I need to do is to make a stub program to hook Syntect in, then install it as a PHP Module.

I need two functions:

One, to turn code into HTML
Another, to generate CSS for the highlighting

php

#[php_function]
pub fn syntect_highlight(code: &str, language_ext: &str) -> String {
    let syntax_set = SyntaxSet::load_defaults_newlines();
    let syntax = syntax_set.find_syntax_by_extension(language_ext).unwrap();
    let mut html_generator = ClassedHTMLGenerator::new_with_class_style(syntax, &syntax_set, ClassStyle::Spaced);
    for line in LinesWithEndings::from(code) {
        html_generator.parse_html_for_line_which_includes_newline(line).unwrap();
    }
    let output_html= html_generator.finalize();
    output_html
}

#[php_function]
pub fn syntect_css(theme_path: &str) -> String {
    let theme = ThemeSet::get_theme(PathBuf::from(theme_path)).unwrap();
    css_for_theme_with_class_style(&theme, ClassStyle::Spaced).unwrap()
}

Now, we can just build this with cargo build, and uh. Get a .dylib.

Our glue library ext-php-rs offers a solution to install this all for us, but it doesn't work on my machine! And it seems abandoned! Instead, let's just install it ourselves.

Note

I got this working on my Ubuntu Server! Not my MacOS laptop though. I had to build it from git instead of the latest version though.

cargo install cargo-php --git https://github.com/davidcole1340/ext-php-rs

If you have PHP installed globally you will have to install it on the super-user (use sudo). Overall this seems spotty, and I'm looking for an alternative to this.

From cargo-php

rust

fn get_ext_dir() -> AResult<PathBuf> {
    let cmd = Command::new("php")
        .arg("-r")
        .arg("echo ini_get('extension_dir');")
        .output()
        .context("Failed to call PHP")?;

Okay, so...

$ php -r "echo ini_get('extension_dir');"

/opt/homebrew/lib/php/pecl/20230831

$ # Please ignore how i blatantly misspelled syntect here. Shame on me.
$ cp ./target/release/libsyntext_ext_php.dylib /opt/homebrew/lib/php/pecl/20230831

Okay, now we need to enable it in php.ini.

.../php/8.3/php.ini

extension=...
extension=libsyntext_ext_php.dylib

Now we can use it in PHP. Awesome! The code blocks on this site are being rendered like this :)

Note that this technically adds a third dependency, if you were keeping track. Better than 19!!

Also: if you want to use it, here's the repo: https://github.com/j0lol/ext-php-syntect

ZeroBridge 0.1.0 Release

2024-04-03T10:00:00Z

I wrote a Discord bridge for Minecraft 1.4.7! I might go in depth about this in another blog post, but for now, here's a link: ZeroBridge

Okay here's a bit of talk

It runs in NilLoader, and is mainly targeted for the pack Rewind Upsilon. It was really fun to make! NilLoader is very barebones, and most of the code is directly injected into Minecraft via MiniTransformer. For some reason, I find working with ASM (Java Bytecode Manipulator) to be quite nice.

I originally started work on this project maybe a year ago? I digged it out recently from my backups because I wanted to play Upsilon but the people I want to play with really want a Discord bridge. I basically rewrote the entire thing to play nice when inside Rewind Upsilon. I also added a config (with Jankson), webhooks (with Visage rendering), a bunch of other stuff that makes it feel like a real thing.

Anyway, enjoy!

Jo's Blog

Scoping CSS

Vanilla CSS

Don't scope at all

BEM

Nesting

@Scope

In Component Libraries

CSS Modules

CSS-in-JS

Tailwind

Style property

Web components

Editor Configs and stuff

Helix configuration

The context within which I use Helix

Dark/Light mode switching

Nova

Zed

New 88×31 Badge

Understanding WebGPU

A short history lesson

A Better Way

What This Means For GPU Programming

I Made a DSL for My Blog

What it Does

How I Made it

Using the library

Footnotes

should we be evangelizing the way we do

Why we might evangelize

People like sharing their opinions

Searching for connection?

Sharing joy?

What's wrong with evangelizing?

Mindful evangelism

Squircles in CSS!

Further Reading

Making embed images with Typst

Web Components Are Easy, Mostly

Making Imperative Shadow DOM Components

Making Imperative Light DOM Components

Making Declarative Shadow DOM Components

Conclusion

Further Reading

Website Version 5

Whyyyyy?

The Stack

The "Templating Engine"

Ok, but why do you have a HTML rewriter?

The Web Framework

Moving to Tangled, and other thoughts

Using jj

On loving your website

Favicons are weird

Changing fonts

Physicality

Cute little icons

Code Blocks and Highlighting

About footnotes

Aside on writing in HTML

Trying to conclude this post

Is Swift becoming unergonomic Rust?

Safety

Conclusion

How I use the new Spotlight

The macOS Tahoe beta is so bad that it made me switch to Chromium.

I added Bluesky powered comments!

How to run games on macOS like it's SteamOS

Installation

Steam

Tweaking

Troubleshooting

Performance and Compatibility

Conclusion

Free yourself from the shackles of productivity

"Modal Editing is more productive"

"Helix has easier keybinds"

It doesn't matter if there is a "best editor" or not

But...

Using `jj`