DEV Community: Mahmoud 🦀

🔐 OTP RS: RFC-Compliant OTP Input Components for WASM Frameworks

Mahmoud 🦀 — Sun, 04 Oct 2026 11:24:36 +0000

Nǐ hǎo 👋!

You've seen the textbox. You've typed the number. You've waited three seconds for the SMS that never came, checked your spam folder, clicked "Resend", typed the number again, and finally admitted to yourself that 2FA is simultaneously the most important and most annoying invention of the modern web.

Today, we make it marginally less annoying, at least on the Rust side. We're shipping OTP RS.

What Even Is OTP RS?

OTP RS is a composable, accessible, animated One-Time Password input component for Yew, Dioxus, and Leptos. It implements the full verifier flow: slot-by-slot input, keyboard navigation, active/filled/invalid/disabled states, animated caret blink, digit-entry pop animation, and RFC 4226 (HOTP) + RFC 6238 (TOTP) validation, all in Rust, all in WASM, all without touching a single line of JavaScript.

If you've ever tried to build a 6-box OTP input from scratch, you know the drill. It starts with "just six inputs". Two hours later you're debugging focus management, backspace propagation, keyboard event edge cases, browser autofill hijacking your state, and the invisible iOS number pad refusing to appear. That's the origin story of OTP RS.

Component Architecture

OTP RS follows the same composable anatomy as every other component in the Open SASS Kit. You compose what you need:

Otp: Root container. Owns the internal value state, focus coordination, and the RFC validation callbacks.
Group: A visual cluster of slots (e.g., three digits, then a separator, then three more).
Slot: Individual slot. Renders a visible character display on top of an invisible overlay <input>.
Separator: The little dash in between groups.

use otprs::yew::{Otp, Group, Separator, Slot};
use yew::prelude::*;

#[function_component(VerificationInput)]
pub fn verification_input() -> Html {
    html! {
        <Otp max_length={6} aria_label="Enter your OTP">
            <Group>
                <Slot index={0} />
                <Slot index={1} />
                <Slot index={2} />
            </Group>
            <Separator />
            <Group>
                <Slot index={3} />
                <Slot index={4} />
                <Slot index={5} />
            </Group>
        </Otp>
    }
}

That's it. Focus management, digit propagation, state aggregation, and ARIA attributes are all handled. You just compose slots.

The Invisible Input Trick

Here's the most important design decision in all of OTP RS: the <input> element that receives keyboard events is completely invisible.

Each Slot renders two layers:

An invisible <input> (via input-rs with otp_mode=true) that is position: absolute; inset: 0; opacity: 0. It captures all keyboard focus and input events.
A visible <span> that displays the digit character and the blinking caret.

This separates the input mechanics from the visual presentation, giving us full control over the slot's look without fighting browser defaults for <input> styling.

┌─────────────────────┐
│  Slot wrapper       │  ← position: relative; border; background; animation
│  ┌───────────────┐  │
│  │ <input>       │  │  ← absolute; opacity:0; captures keyboard events
│  └───────────────┘  │
│  <span>3</span>     │  ← visible character display
│  <span class=caret/>│  ← blinking caret (when active & empty)
└─────────────────────┘

The Invisible Input That Wasn't Actually Invisible

Here's a fun bug that bit us early on, hard.

The slot design described above only works if the CSS for the invisible input is applied as an inline style attribute, not as a CSS class attribute. The component originally passed the overlay CSS string to input_class, a prop that sets the HTML class="" attribute.

Browsers don't style elements based on CSS property strings stuck in the class attribute. They look up class names in stylesheets. So what we got instead of an invisible overlay was a white rectangle aggressively covering the entire OTP component, like a censored emoji on live TV.

The fix was to add an input_style: &'static str prop to input-rs in all three framework implementations, and apply it as style="{props.input_style}" on the bare otp_mode <input>. One line per framework. Six characters (_style vs _class). Three frameworks. Three PRs worth of suffering.

The Compiler Is Your Enemy (And Also Your Best Friend)

Let us count the ways Rust fought us this time.

Episode 1: Hook in a Macro

error[E0277]: the trait bound `impl Hook<Output = ...>: IntoPropValue<...>` is not satisfied

We tried calling use_state(...) inside an html! macro attribute. Yew forbids calling hooks anywhere except directly inside function component bodies. The macro expands to a closure, and hook calls need to be at the top level. Extracting use_state calls to let bindings before html! fixed it.

Episode 2: `Box::leak` and the `&'static str` Obligation

Dioxus and Leptos's input-rs props require &'static str. But our slot-specific strings like "Digit 3" are computed at runtime. The only way to produce a &'static str from a runtime String without pulling in a string interner is to Box::leak:

let label: &'static str = Box::leak(
    format!("Digit {}", index + 1).into_boxed_str()
);

Yes, this leaks memory on every slot render. Each Slot render leaks ~15 bytes. Is this ideal? No. Does it compile? Yes. Is it the correct long-term solution? The correct long-term solution is a Signal<String> prop type in input-rs, which is a future PR. For now: Box::leak and move on.

Episode 3: The `as` Cast That Broke Leptos

The Leptos view! macro cannot parse Rust cast expressions inline:

// This fails to parse inside view!:
validate_function=(|_: String| -> bool { true }) as fn(String) -> bool

The macro sees the as keyword and gets confused about what's a prop name vs. a type expression. The fix: extract to a let binding before the view! call:

let always_valid: fn(String) -> bool = |_| true;
// then inside view!:
validate_function=always_valid

Three lines in, five compilation cycles later. We hope this saves you ten minutes.

Episode 4: `String` vs `&str` in Dioxus `rsx!`

Dioxus's rsx! macro is strict about attribute types. When slot_class was a String, the macro would refuse:

expected `&str`, found `String`

format!("...", ...) produces a String. Dioxus attributes want &str. The same Box::leak pattern solved this too:

let slot_class: &'static str = Box::leak(
    format!("{} {}", ctx.variant.to_slot_class(), props.class).into_boxed_str()
);

Episode 5: The Inter-Group Focus Traversal Collision

Here is a fun brain teaser: what happens when you put two OTP components on the exact same page, and you start typing in the second one?
Well, since our slots were originally assigned hardcoded IDs like otp-slot-0, otp-slot-1, the moment you typed a character in the second instance, document.getElementById("otp-slot-1") would aggressively hijack focus and yank your cursor all the way back up to the first OTP component on the page.

The fix? Prefixing every slot ID with a unique instance_id minted from a global atomic counter (OTP_INSTANCE_COUNTER.fetch_add(1, Ordering::Relaxed)). Now every widget lives in its own perfectly scoped focus namespace, free from neighborhood turf wars.

Episode 6: The "Sticky" Backspace (vDOM vs Physical DOM)

Across Leptos and Yew we noticed a bizarre issue: if you typed a character, erased it, and tried typing again, the <input> would refuse to update. Or if you filled the very last slot, the input component became "sticky" and refused to overwrite the final character.

The root cause was a classic Virtual DOM vs Physical DOM standoff. We were setting the internal state to "", but frameworks optimize their renders. Leptos input-rs used a one-way, read-once initialization for value=handle.0.get(). Yew assumed the string was already empty and ignored the reconciliation. Because the physical HTML <input> wasn't being forcefully synchronized, the raw DOM held onto the sticky character and choked out any new keystrokes.

We had to bypass the frameworks entirely and manually flush the physical DOM element inside the keyboard event handlers using raw Web APIs (input_ref.cast::<web_sys::HtmlInputElement>().unwrap().set_value("")). The lesson here? Sometimes the fastest way out of a reactive state desync is a direct, imperative smash to the physical DOM.

Keyboard Navigation

One of the more satisfying pieces: full keyboard navigation across slots.

Any character key → fills current slot, auto-advances focus to the next
Backspace → clears current slot; if already empty, goes to the previous slot
ArrowLeft → jumps to previous slot
ArrowRight → jumps to next slot
Tab → advances naturally (browser default, we don't intercept)

All of this is handled in the on_slot_keydown callback in the parent Otp component, which uses NodeRef (Yew) or the equivalent signal-based refs (Dioxus/Leptos) to imperatively .focus() the target input.

if key == "Backspace" && idx > 0 {
    // slot is already empty, go back
    if let Some(node) = slot_refs.get(idx - 1) {
        if let Some(input) = node.cast::<HtmlInputElement>() {
            let _ = input.focus();
        }
    }
}

No third-party focus-trap libraries. No jQuery. Pure DOM manipulation from Rust.

HOTP and TOTP Validation

OTP RS ships RFC 4226 (HOTP) and RFC 6238 (TOTP) implementations using totp-rs. The SHA-1 HMAC is hand-rolled using the standard iterative block compression algorithm:

pub fn validate_hotp(
    secret: &[u8],
    counter: u64,
    code: &str,
    digits: u32,
) -> Result<(), OtpValidationError> {
    let expected = hotp(secret, counter, digits);
    if expected == code { Ok(()) } else { Err(OtpValidationError::HotpMismatch) }
}

You can validate on complete:

let on_complete = Callback::from(move |code: String| {
    match validate_hotp(b"your-secret", 0, &code, 6) {
        Ok(()) => web_sys::console::log_1(&"Valid!".into()),
        Err(e) => web_sys::console::warn_1(&format!("{e:?}").into()),
    }
});

The hotp() function also lets you generate the expected code if you need to display a hint in development. For the HOTP example in the landing page, the valid code for secret JBSWY3DPEHPK3PXP at counter 0 is computed at runtime via hotp(b"JBSWY3DPEHPK3PXP", 0, 6), no hardcoding required.

Quick Setup

# Yew
cargo add otprs --features=yew

# Dioxus
cargo add otprs --features=dio

# Leptos
cargo add otprs --features=lep

# Cargo.toml
otprs = { version = "0.1", features = ["yew"] }

The component ships its own CSS as inline styles computed from Rust. No separate stylesheet needed.

Final Thoughts

Building OTP RS was a journey through the exact kind of subtle, cross-framework, cross-layer complexity that makes Rust Web development both rewarding and sometimes deeply frustrating. We fought the compiler more than once, discovered ways that browser defaults quietly break invisible design patterns, and shipped a Box::leak we're not entirely proud of.

But the result is solid: a composable, keyboard-navigable, RFC-compliant OTP input component that works identically across Yew, Dioxus, and Leptos, with zero JavaScript and enough ARIA to satisfy a WCAG auditor.

The next time you're building a login flow in Rust WASM and you reach for a six-box code input, you don't have to write it from scratch anymore.

opensass / otprs

🔐 A highly customizable OTP component for WASM frameworks (Powered by Input RS).

🔐 OTP RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible OTP (One-Time Password) input component for WASM frameworks: Yew, Dioxus, and Leptos.

Supports animated per-slot digit entry with automatic focus traversal, primary and secondary visual variants, built-in HOTP/TOTP validation per RFC 4226 and RFC 6238, and full WCAG compliance.

🤔 Why OTP RS?

🎨 Fully Customizable: Control every attribute, class, style, variant, pattern, ARIA labels and more, on the outermost container, each group, each slot, and each separator.
⌨ Smart Focus Management: Typing a digit automatically advances focus. Backspace regresses focus. Arrow keys navigate left and right.
✨ Animated Entry: Each digit pops with a scale animation when entered, and a blinking caret is shown in the active empty slot.
🔐 Built-in Validation: Validate against HOTP (RFC 4226) or TOTP (RFC 6238) using a pure-Rust implementation, no C, no…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

📋 Form RS: Production-Ready Form Components for WASM Frameworks

Mahmoud 🦀 — Sun, 04 Oct 2026 11:24:25 +0000

Salut 👋!

If there's one thing that unites frontend developers across every language, framework, and decade of web history, it's a deep, personal, somewhat traumatic relationship with HTML forms.

You know the drill. You write a <form>. You add an <input>. You add a <label>. You write the JavaScript to validate it on blur. You add a <p> for the error message. You wire up aria-describedby so screen readers can find the error. You set aria-invalid on the input. You set aria-required. You check event.preventDefault(). You realize you've been writing a custom form library for the last four hours. You consider leaving the industry.

That stops today. We're shipping Form RS.

What Is Form RS?

Form RS is a fully composable, WCAG 2.2 AA compliant, production-ready form component library for Yew, Dioxus, and Leptos. It wraps Input RS for the actual <input> rendering, provides a complete context-driven architecture for validation state propagation, and ships seven discrete components that you can mix freely.

Think of it as the form library you would build yourself if you had time, patience, and hadn't already burned both writing <div class="form-group"> for the 8000th time.

The Seven Components

Form RS ships a composable hierarchy, not a monolith.

`Form`

The outermost container. Wraps <form> with configurable method, action, enctype, autocomplete, ARIA labels, and submit/reset/invalid callbacks. There are two validation modes:

ValidationBehavior::Native   // HTML5 + browser popups (default)
ValidationBehavior::Aria     // Real-time ARIA errors, no popups, submit never blocked

`Control`

The context provider. Wraps a single field, distributes disabled, error, focused, required, variant, color, and size state to every child that reads FormControlContext. Your labels and helper text automatically inherit this state without prop drilling.

`Label`

Renders a <label> that visually and semantically tracks the control's state. It goes red when there's an error. It glows when focused. It shows the required asterisk automatically. You don't have to think about any of this.

// In Yew:
<Label html_for="email" error={true} focused={false}>
    {"Email address"}
</Label>

`Helper`

A <p> element below the input. Changes color based on validation state:

<Helper error={true}>{"Not a valid email."}</Helper>
<Helper valid={true}>{"Looks great!"}</Helper>

Three states, zero class strings.

`Group`

Groups related checkboxes or radio buttons in a <fieldset>-adjacent <div>. The row prop flips the layout from column to horizontal. The aria_label wires up a role="group" for screen readers.

`ControlLabel`

Wraps a form control (checkbox, radio, switch) with its associated label text. Controls label placement (End, Start, Top, Bottom), required asterisks, and disabled styling.

<ControlLabel
    control={html! { <input type="checkbox" /> }}
    label={html! { <span>{"Email notifications"}</span> }}
    label_placement={LabelPlacement::End}
/>

`Field`

This is the one you'll use most. A drop-in composition of Control + Label + Input + Helper with reactive focus rings, error/valid ring states, ARIA attributes, and helper text management.

<Field
    id="email"
    label="Email address"
    r#type="email"
    placeholder="ferris@opensass.org"
    helper_text="Enter a valid email."
    required=true
    full_width=true
    handle={email.clone()}
    valid_handle={email_valid.clone()}
    validate_function={Callback::from(validate_email)}
/>

One component. Fully wired. WCAG compliant. You're done.

Validation Architecture

Form RS supports two distinct validation paradigms:

Native HTML5 Validation

Uses browser-native required, pattern, minlength, maxlength, and type="email" constraints. The browser handles error messages. Form submission is blocked on invalid fields. This is the ValidationBehavior::Native default.

External/ARIA Validation

Pass a ValidationState explicitly, from a server response, a complex cross-field rule, or your own logic:

ValidationState::None        // No judgment, untouched
ValidationState::Valid       // Green ring, success helper text
ValidationState::Invalid(msg)// Red ring, error helper text, aria-invalid="true"

Server errors? Set validation_state={ValidationState::Invalid("Email already in use.".into())} on the field. The error surfaces immediately. The ARIA is correct. Done.

Accessibility Built In

This isn't "we added aria-label" accessibility. This is the real thing.

Every Field generates a unique {id}-helper element ID and passes it as aria-describedby on the underlying <input>.
aria-required and aria-invalid are set precisely based on prop + validation state, not just "always true".
Helper renders with role="alert" when in error state, so screen reader users hear errors without tabbing to them.
Label is always linked to its input via for/html_for. No floating labels that break semantics.
Group propagates role="group" with aria-label for checkbox/radio clusters.

Audit-passing HTML forms. In Rust. Across three WASM frameworks.

The `ValidationState` Pattern

This is the piece that makes server-side validation ergonomic:

pub enum ValidationState {
    None,
    Valid,
    Invalid(String),
}

Pass None on a fresh field. Pass Valid once you've confirmed on the backend. Pass Invalid with your error message string when the server rejects it. The component does the rest.

Variant, Color, and Size System

Form RS exposes a full semantic token system for the input appearance:

// Visual input style
Variant::Outlined  // Default, bordered input box
Variant::Filled    // Solid filled background
Variant::Standard  // Bottom-border only

// Accent color (rings, labels, helper text)
Color::Primary | Color::Secondary | Color::Error | Color::Info | Color::Success | Color::Warning

// Input density
Size::Small | Size::Medium

Building a dense admin data-entry form? Size::Small. Consumer onboarding flow? Size::Medium. Dark theme with error highlights? Color::Error. The system handles the visual output; you just name the intent.

Quick Setup

Stop writing raw HTML form boilerplate. Do this:

# Yew
cargo add form-rs --features=yew

# Dioxus
cargo add form-rs --features=dio

# Leptos
cargo add form-rs --features=lep

Final Thoughts

Forms are foundational. Every user interaction that matters, login, registration, checkout, profile editing, contact, search, flows through a form. Getting them right means getting ARIA right, validation right, focus state right, and error surfacing right. Every time. On every field.

Form RS is the answer to "who has time for all of that." We did. You don't have to.

opensass / form-rs

📋 A highly customizable Form component for WASM frameworks (Powered by Input RS).

📋 Form RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible form component library for WASM frameworks: Yew, Dioxus, and Leptos. Supports HTML5 and ARIA validation, composable sub-components (Form, Control, FormLabel, Helper, Group, ControlLabel, Field), and full WCAG 2.2 AA compliance.

🤔 Why Form RS?

🎨 Fully Customizable: Control variant, color, size, class, style, ARIA labels, and every sub-component attribute.
🧩 Composable API: Mix Form, Control, FormLabel, Helper, Group, ControlLabel, and Field independently or together.
✅ Dual Validation: Supports native HTML5 validation and real-time ARIA error messaging.
♿ Accessible by Default: aria-describedby, aria-required, aria-invalid, and role="alert" wired up automatically.
🔧 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🖥️ Code RS: CDN-Free Syntax-Highlighted Code Components for WASM

Mahmoud 🦀 — Sun, 04 Oct 2026 11:24:17 +0000

Privyet 👋!

You know that moment when you paste a <pre><code> block into your app and it looks like it was styled in 2003 by someone who had just discovered color: green? No theme. No copy button. No language badge. Just raw, uncolored text sitting in a box that someone called "good enough"?

Yeah. We fixed that. Today we're shipping Code RS.

What Is Code RS?

Code RS is a production-ready, fully-themed, accessible code display component for Yew, Dioxus, and Leptos. It does everything the ecosystem was missing:

Inline <Code>: colored, sized, variant-aware, with ARIA semantics.
<Block>: a composable container with header, title, language badge, copy trigger, and scrollable content area.
Pure-Rust syntax highlighting: zero CDN, zero JavaScript, compiles to clean WASM, 20+ languages.
8 built-in themes: OneDark, Dracula, NightOwl, GitHub Dark/Light, Solarized, Monokai, Nord, all switchable via a single theme prop.

No Prism.js. No highlight.js. No 10MB script tag loaded from a CDN you definitely trust completely. Just Rust, bytes, and inline style= spans.

The Big Idea

Here's the thing about syntax highlighting in WASM apps: every existing solution assumes JavaScript. Prism.js needs a DOM. highlight.js needs a runtime. Shiki needs Node. Tree-sitter is great, but it weighs as much as a sedan.

So we wrote our own.

The highlight_code(code, lang, theme) function in common.rs is a hand-rolled, char-by-char tokenizer that handles:

Block comments (/* */), single-line comments (//, #, --)
Double/single-quoted strings and JS template literals
Hex and float number literals with suffixes (0xFF, 1.0f32)
Rust macros (println!, vec!)
Python/CSS decorators (@dataclass, @media)
HTML tag names (<div>, </span>)
PascalCase → type, ALL_CAPS → constant, ident( → function call
Language-specific keyword sets (Rust, Python, TypeScript, SQL, Bash, 16 more)

All token spans get inline style= attributes from the chosen theme. No CSS classes. No external stylesheet. Just <span style="color:#c678dd;font-weight:600">fn</span>, and it works everywhere, including iframes and shadow DOM.

use coders::{Language, Theme, highlight_code};

let html = highlight_code(
    "fn main() {\n    println!(\"Hello!\");\n}",
    Language::Rust,
    Theme::Dracula,
);
// → "<span style="color:#ff79c6;font-weight:600">fn</span> ..."

Components

`Code`

The simplest unit. A <code> element with color, variant, and size props.

// Yew
html! {
    <Code color={Color::Accent} variant={Variant::Subtle} size={Size::Sm}>
        {"console.log(\"Hello, world!\")"}
    </Code>
}

Variants work exactly as you'd expect from the rest of Open SASS Kit: Solid, Subtle, Outline, Surface, Plain. Colors are the full palette: Default, Red, Orange, Yellow, Green, Teal, Accent, Pink, Success, Warning, Danger, and Custom("your-inline-css").

`Block`

// Leptos
view! {
    <Block
        code="fn main() {\n    println!(\"Hello!\");\n}"
        language={Language::Rust}
        theme={Theme::NightOwl}
    >
        <Header>
            <Title>"main.rs"</Title>
            <LanguageBadge />
            <CopyTrigger />
        </Header>
        <Content />
    </Block>
}

The Block pushes a BlockContext containing code, language, and theme into a provider tree. All child components read from context. Content calls highlight_code and injects the result via inner_html / dangerous_inner_html / Html::from_html_unchecked, the framework-appropriate unsafe-but-correct escape hatch for pre-rendered HTML. No prop drilling. No callback chains. Just context.

8 Themes

Theme	Background	Vibe
`OneDark`	`#1a1a2e`	The classic. Atom's gift to the world.
`Dracula`	`#282a36`	Halloween every day. Pink keywords.
`NightOwl`	`#011627`	Deep blue, warm salmon numbers.
`GithubDark`	`#0d1117`	Feels like GitHub, because it is.
`GithubLight`	`#ffffff`	For those who dare use light mode.
`Solarized`	`#002b36`	Ethan Schoonover's gift to the terminal.
`Monokai`	`#272822`	The Sublime Text nostalgia trip.
`Nord`	`#2e3440`	Arctic. Clean. Borderline peaceful.

Switch themes at runtime by simply changing the theme prop. The ThemeColors struct drives inline style generation, every push_span() call pulls the exact CSS value from the active theme's fields.

Need your brand colors? Theme::Custom(ThemeColors { keyword: "color:#ff0099;font-weight:600", ... }) and you're done.

The Build Journey

We are not going to pretend this was a relaxing weekend project. Here is an honest accounting.

Chapter 1: The Rust 2024 Edition

Rust Edition 2024 changed how string-like identifiers in macro positions are parsed. The yew::html! macro started rejecting class names like text-black and whitespace-pre, specifically the hyphen-adjacent tokens that look like prefix expressions.

The error: prefix 'black' is unknown. The fix: add a trailing space after the class name. Simple, but it wasted an embarrassing amount of time because the error message looks nothing like what it actually is.

// Before (breaks in Edition 2024):
class="flex text-black"
// After:
class="flex text-black "  // ← single space, problem solved

Chapter 2: Dioxus RSX

The rsx! macro in Dioxus parses string prop values as format strings. So this:

code: "fn main() {\n    println!(\"Hello!\");\n}"

Explodes with Failed to parse formatted segment: Expected Ident or Exp. Because { inside a string prop is format syntax to Dioxus, not a literal curly brace.

The fix: extract all code strings to const:

const HELLO_WORLD: &str = "fn main() {\n    println!(\"Hello!\");\n}";

rsx! {
    Block { code: HELLO_WORLD }
}

Unglamorous? Yes. But it compiles.

Chapter 3: The `dangerous_inner_html`

In Dioxus, dangerous_inner_html takes ownership of a String. In Leptos, inner_html takes a &str. In Yew, Html::from_html_unchecked takes an AttrValue. Three frameworks, three signatures, three slightly different ways to inject a pre-rendered HTML string.

Each one worked fine once you knew the exact type expected. Getting there required reading the framework source, not the docs, because the docs had helpfully omitted the borrow semantics.

Chapter 4: Non-Exhaustive `Variant::Custom`

Adding Custom(&'static str) to the Variant enum immediately broke every match in all three Code component implementations. Expected. Annoying. The fix is the following:

Variant::Custom(_) => "",

But finding all three match sites across three files while also trying to fix four other things simultaneously is exactly the kind of thing that makes you wish Rust had #[non_exhaustive] as an opt-in marker you could flip during development.

Accessibility

Code RS ships accessible markup out of the box:

Block renders as <figure role="region"> with aria-label.
The inner <pre> gets tabindex="0" so keyboard users can scroll it.
CopyTrigger carries aria-label="Copy code to clipboard" and aria-live region feedback via the copied label swap.
Code accepts aria_label for use in contexts where <code> alone doesn't carry enough meaning.
LanguageBadge reads the language from context and renders aria-label="Language: rust".

Screen readers don't need to guess what anything is.

Quick Setup

# Yew
cargo add coders --features=yew

# Dioxus
cargo add coders --features=dio

# Leptos
cargo add coders --features=lep

That's it. The syntax highlighting, theming, clipboard, and accessibility, all included. No config files. No CSS imports. No npm install @something/highlighter-peer-dependency.

Final Thoughts

Writing a CDN-free, pure-WASM syntax highlighter from scratch to ship alongside a composable code block component is not the most efficient path. But it's the correct one for this ecosystem.

The web has enough <script src="https://cdn.example.com/dep.min.js"> tags. Rust WASM doesn't need to inherit that habit.

Code RS compiles to WASM, highlights code inline, and ships 8 themes without a single network request beyond your app bundle. That's the promise.

opensass / coders

💻 A highly customizable code component for WASM frameworks.

💻 Code RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible inline code and code-block component for WASM frameworks: Yew, Dioxus, and Leptos. Supports multiple colors, variants, sizes, copy-to-clipboard, and composable sub-components, all WCAG compliant.

🤔 Why Code RS?

🎨 Fully Customizable: Control every attribute, class, style, color, variant, size, ARIA labels, and more.
📋 Copy to Clipboard: Built-in copy button with a configurable confirmation label and reset timeout.
🧩 Composable: Compose Header, Title, CopyTrigger, Content, and LanguageBadge independently.
♿ Accessible by Default: role="region", aria-label, aria-live and tabindex wired up automatically.
🔧 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this component into your Dioxus app.

🌱

…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🃏 Card RS: Extremely Customizable Card component for WASM frameworks

Mahmoud 🦀 — Sun, 27 Sep 2026 11:11:08 +0000

Salut tout le monde 👋!

If there is one layout component that has been re-implemented more times than the <button>, it's the Card. Think about it. Every widget, every dashboard panel, every pricing tier, every shiny glowing glassmorphism element you've ever seen is, deep down, a card.

Instead of writing div class="p-6 border rounded-xl shadow-lg bg-white" for the 5000th time, we decided to solve cards natively for WASM.

Today, we're shipping Card RS.

What Is Card RS?

Card RS is an extremely customizable, production-ready, accessible Card component for Yew, Dioxus, and Leptos. We've extracted all the tedious BEM boilerplate, flexbox wrangling, and ARIA attributes out of your templates, giving you a clean, composable API for building solid UI surfaces.

Cards shouldn't be monoliths. If you just need a surface, <Card> works perfectly alone. If you need standard anatomical parts, stick <Header>, <Title>, <Content>, and <Footer> in there.

The Composable Anatomy

The problem with most UI library cards is that they force you into a specific layout. Card RS doesn't mandate structure; it provides logical boundaries.

The Shell: `Card`

The parent wrapper. It renders a clean HTML5 <article> (or whatever ARIA role you need) with our default elevated styling.

use card_rs::yew::Card;
use card_rs::Variant;
use yew::prelude::*;

#[function_component(MyWidget)]
pub fn widget() -> Html {
    html! {
        <Card variant={Variant::Default} aria_labelledby="widget-title">
            // the world is yours in here
        </Card>
    }
}

The Skeleton: Headers, Content, & Footers

Don't want to write inline styles for gaps and flex-columns? Neither do we.

<Card aria_labelledby="c-title">
    <Header>
        <Title id="c-title">{"Card Title"}</Title>
        <Description>{"The description lives here."}</Description>
    </Header>
    <Content>
        <p>{"Any content fits neatly in the main body area."}</p>
    </Content>
    <Footer>
        <button aria-label="Confirm">{"Confirm"}</button>
    </Footer>
</Card>

The header stacks title and description with precise spacing. The footer handles your action bars. Everything just snaps into place like LEGOs.

Variants and Prominence

Not all cards are created equal. You need visual hierarchy. We provide a Variant matrix that affects the surface depth and contrast without rewriting class strings.

pub enum Variant {
    Transparent,  // No background, merges with the canvas
    Default,      // Standard surface layer
    Secondary,    // Elevated and highlighted
    Tertiary,     // Premium prominence (perfect for selected items)
}

Building an interactive pricing selector? Wrap your iterations in a <Card variant={if selected { Variant::Secondary } else { Variant::Default }}> and your hierarchy logic is done.

Framework Parity

Like everything we build, Card RS provides identical API surfaces and behavioral guarantees across all three rusty frontends:

Feature	Yew	Dioxus	Leptos
`Card`	✅	✅	✅
`Header`	✅	✅	✅
`Title` & `Description`	✅	✅	✅
`Content` & `Footer`	✅	✅	✅
Variant Matrix	✅	✅	✅
Accessible ARIA bindings	✅	✅	✅
Role overrides	✅	✅	✅

If you know how to build a card in Leptos, you can build a card in Dioxus. The props are the same. The BEM classes are the same. The logic is identical.

Accessibility Built-In

Accessible surfaces are often completely ignored by developers until an audit fails. Card RS is designed strictly around WCAG guidelines.

Card renders with role="article" by default.
We enforce aria_labelledby to tie structural landmarks to the Title ID.
If you want a non-interactive surface, just override it with role="note" or role="region".

// Accessible structural linking:
<Card aria_labelledby="promo-heading" role="region">
    <Header>
        <Title id="promo-heading">{"Special Offer!"}</Title>
    </Header>
</Card>

With one prop, screen readers will now announce "Region: Special Offer!" properly.

Customization

We aren't trapping you in our aesthetic. Want a weird horizontally-aligned flex-row card with a gradient background? Just use the style prop. Card RS accepts your CSS strings eagerly.

Quick Setup

Stop copying and pasting giant Tailwind HTML blobs. Do this instead:

# Yew
cargo add card-rs --features=yew

# Dioxus
cargo add card-rs --features=dio

# Leptos
cargo add card-rs --features=lep

Final Thoughts

The web is made of cards. Taking the time to unify how we create, structure, and render them across Wasm frameworks means we can stop fighting with padding and flexbox alignment, and get back to building real features.

opensass / card-rs

🃏 A highly customizable card component for WASM frameworks

🃏 Card RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible card component for WASM frameworks: Yew, Dioxus, and Leptos. Supports semantic prominence variants, composable sub-components (header, title, description, content, footer), and full WCAG compliance.

🤔 Why Card RS?

🎨 Fully Customizable: Control variant, class, style, ARIA labels, and every sub-component attribute.
🧩 Composable API: Use Card, Header, Title, Description, Content, and Footer independently or together.
🏷️ Semantic Variants: transparent, default, secondary, tertiary, themes interpret prominence without hard-coded colors.
♿ Accessible by Default: role="article", aria-labelledby, and aria-label wired up automatically.
🔧 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this component into…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🔴 Badge RS: Easy to Use Badge Components for WASM Frameworks

Mahmoud 🦀 — Sun, 27 Sep 2026 11:08:44 +0000

Je vous salue 👋!

Every WASM app eventually needs a badge. The little red circle on your notification bell. The green dot on the corner of an avatar. The "99+" that taunts you every morning from the inbox icon. They're everywhere, and somehow everyone is still hand-rolling them.

That stops today. We're shipping Badge RS.

What Is Badge RS?

Badge RS is a production-ready badge component for Yew, Dioxus, and Leptos. Notification counters, status dots, overflow labels, the whole catalogue. It handles positioning, sizing, color theming, dot mode, accessible markup, and even knows the difference between a circle and a rectangle.

If you've ever opened your browser devtools at 11pm trying to figure out why a badge is floating 4px off the corner of an avatar instead of sitting flush on the arc, Badge RS is the component you wish had existed.

The Core Components

`Anchor`

The positioning wrapper. Drop it around any element and it becomes a badge target. Uses position: relative; display: inline-flex; so it doesn't break your layout, doesn't eat your accessibility tree, and doesn't require you to memorize any CSS tricks.

use badges_rs::yew::{Badge, Anchor};
use badges_rs::{Color, Shape};
use yew::prelude::*;

#[function_component(NotificationBell)]
pub fn notification_bell() -> Html {
    html! {
        <Anchor>
            <span aria-label="Inbox, 5 unread messages">{"📬"}</span>
            <Badge
                color={Color::Danger}
                shape={Shape::Circle}
                aria_label="5 unread messages"
            >
                {"5"}
            </Badge>
        </Anchor>
    }
}

That's it. The badge positions itself. You decide where.

`Badge`

The actual indicator. Pass children and you get a labeled badge with text inside. Skip children and you get a compact do, no extra prop needed, just don't put anything inside.

// A labeled count badge
<Badge color={Color::Danger} size={Size::Sm} aria_label="5 unread">{"5"}</Badge>

// A status dot, no children, no extra prop
<Badge color={Color::Success} placement={Placement::BottomRight} aria_label="Online" />

Same component, two modes. The dot is not a separate component.

`BadgeLabel`

A thin <span class="badge__label"> wrapper. Used automatically when you pass plain text to Badge. Expose it directly when you need extra CSS classes or styling on the label slot.

Colors, Variants, Sizes

The full set of knobs is available:

// Colors
Color::Default | Color::Accent | Color::Success | Color::Warning | Color::Danger

// Variants (three visual styles)
Variant::Primary    // solid fill
Variant::Secondary  // outlined
Variant::Soft       // muted, lower-contrast

// Sizes
Size::Sm | Size::Md | Size::Lg

// Placement
Placement::TopRight | Placement::TopLeft | Placement::BottomRight | Placement::BottomLeft

All combinations work. TopLeft is there for RTL layouts and anyone who likes to be contrarian about badge placement.

The Positioning Bug Nobody Talks About

Here's the subtle one. top: 0; right: 0 with transform: translate(50%, -50%) centers a badge perfectly on the corner of a rectangle. That's fine for icon buttons, list items, or anything with a square bounding box.

For a circle, which is what every avatar in existence is, the story is different. A circle's actual edge at 45° sits inward from the bounding box corner. The geometric offset is exactly 1 - sin(45°), which works out to roughly 14.64% of the element's width and height.

Most badge implementations ignore this. The badge floats slightly off the arc, nobody files a bug, and the designer quietly seethes.

Badge RS exposes a Shape enum to handle this explicitly:

pub enum Shape {
    Rectangle,  // top: 0; right: 0, standard bounding box corner
    Circle,     // top: 14.64%; right: 14.64%, sits on the arc
}

// On a circular avatar, badge sits flush on the arc:
<Badge color={Color::Danger} shape={Shape::Circle} aria_label="3">{"3"}</Badge>

// On a square icon button, badge sits on the bounding box corner:
<Badge color={Color::Accent} shape={Shape::Rectangle} aria_label="New">{"New"}</Badge>

The math is not magic. It's just trigonometry that nobody wanted to look up at 11pm. We looked it up for you.

Framework Parity

All three frameworks ship the same API surface:

Feature	Yew	Dioxus	Leptos
`Anchor`	✅	✅	✅
`Badge`	✅	✅	✅
`BadgeLabel`	✅	✅	✅
`Shape::Circle` offset	✅	✅	✅
Dot mode (no children)	✅	✅	✅
All placements	✅	✅	✅
All variants	✅	✅	✅
ARIA attributes	✅	✅	✅

If you've used it in Yew, you already know how to use it in Dioxus and Leptos. The prop names don't even change.

Accessibility

Accessible badges are an afterthought in most libraries. In Badge RS they're mandatory.

Badge renders with role="status" and a required aria_label. Screen readers announce the content without the user having to navigate to it.
aria-atomic="true" ensures the full label is re-read when the count updates. A badge that goes from "3" to "4" reads "4 unread messages", not just "4".
Anchor renders as a <span> with no ARIA role, because it's structural glue and should be invisible to assistive technology.
The WCAG guidance on badges is straightforward: label the element that owns the badge, not just the badge itself. We mention this in the docs and the examples follow it throughout.

// The accessible way, the host element's label includes the count
<span aria-label="Inbox, 5 unread messages">{"📬"}</span>
<Badge aria_label="5 unread messages">{"5"}</Badge>

The badge label and the host's aria-label should tell the same story from different angles.

Quick Setup

# Yew
cargo add badges-rs --features=yew

# Dioxus
cargo add badges-rs --features=dio

# Leptos
cargo add badges-rs --features=lep

No CSS framework required. Styles are computed inline from the prop values.

Dot Mode vs Count Mode

One component, two modes, no separate component for each. This matters because it keeps your import surface small and your mental model consistent.

// Count mode, children present
<Badge color={Color::Danger} aria_label="5 messages">{"5"}</Badge>

// Dot mode, no children, badge renders as a small filled circle
<Badge color={Color::Success} placement={Placement::BottomRight} aria_label="Online" />

The dot is a first-class mode with its own size calculations. Size::Sm in dot mode renders a 6×6px dot. In count mode, it renders a 16×16px pill. The size label refers to the visual weight, not a fixed pixel value.

Status Indicators

The placement prop combined with dot mode covers the most common avatar status pattern:

use badges_rs::leptos::{Badge, Anchor};
use badges_rs::{Color, Placement, Shape};
use leptos::prelude::*;

#[component]
pub fn UserAvatar() -> impl IntoView {
    view! {
        <Anchor>
            <span
                style="/* your avatar CSS */"
                aria-label="Jane Doe, online"
            >
                "JD"
            </span>
            <Badge
                color=Color::Success
                shape=Shape::Circle
                placement=Placement::BottomRight
                aria_label="Online"
            />
        </Anchor>
    }
}

Green dot, bottom-right, perfectly on the arc. That's the whole pattern.

What We Didn't Do

No magic threshold that auto-truncates to "99+". That's application logic, not component logic. We show whatever you pass in. If you want count.min(99).to_string() or "99+", that's two lines in your own code.

No auto-detection of the parent element's shape. That would require measuring the DOM at runtime, which is expensive. Instead: explicit shape prop. You know your own design system. Tell us.

No CSS injection. No global stylesheet to import. No BEM class naming conventions to memorize. The styles live on the element.

Final Thoughts

Badge RS is compact by design. Three components, one enum, one positioning decision that most libraries get wrong.

The Shape prop is the detail worth remembering. If you're putting badges on circular avatars and they look slightly off, that's the fix. Try Shape::Circle and stop adjusting pixel offsets in your component stylesheets.

opensass / badges-rs

🏷️ A highly customizable badge component for WASM frameworks.

🏷️ Badges RS

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible badge component for WASM frameworks: Yew, Dioxus, and Leptos. Supports notification counts, status dots, labels, multiple colors, variants, sizes, and placements with full WCAG compliance.

🤔 Why Badges RS?

🎨 Fully Customizable: Control color, variant, size, placement, class, style, and ARIA labels.
🔴 Dot Mode: When no children are provided the badge renders as a compact status dot.
📍 Smart Placement: Four corner placements (top-right, top-left, bottom-right, bottom-left) via CSS transform for pixel-perfect positioning.
♿ Accessible by Default: role="status", aria-label, and aria-atomic wired up automatically.
🧩 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

🪪 Avatar RS: Very Efficient Avatar Components for WASM Frameworks

Mahmoud 🦀 — Sun, 27 Sep 2026 11:01:40 +0000

Bien le bonjour 👋!

Every WASM app eventually needs an avatar. Profile pictures, user cards, comment threads, they're everywhere. And every time, developers end up rolling the same <img> tag with some fallback logic, hardcoded border-radius, and a prayer that the CDN doesn't return a 404.

That stops today. We're shipping Avatar RS.

What Is Avatar RS?

Avatar RS is a fully-featured avatar component for Yew, Dioxus, and Leptos. It handles image loading, fallback text/icons, overflow groups, color themes, size variants, accessible markup, the whole thing. Built on top of Image RS, which means you get smart lazy loading, blur-up placeholders, and responsive layouts for free.

Think of it as the avatar component you'd build if you had infinite time and zero deadlines. We had neither, but here we are anyway.

The Stack Under the Hood

Avatar RS wraps Image RS, our WASM-native image primitive, for the actual <img> element. This is not a trivial detail.

Image RS uses Intersection Observer API for lazy loading, supports srcset/sizes for responsive images, and fires clean on_load / on_error callbacks. All of that comes for free inside every Image you render. The avatar layer only adds context management and state coordination on top.

Core Components

`Avatar`

The container. Wraps Image and Fallback, provides the shared loading context, and inherits size/color/variant from a surrounding Group if present.

use avatar::yew::{Avatar, Image, Fallback};
use avatar::Color;
use yew::prelude::*;

#[function_component(MyProfile)]
pub fn my_profile() -> Html {
    html! {
        <Avatar aria_label="Ferris Prophet">
            <Image
                src="https://i.pravatar.cc/300"
                alt="Ferris Prophet"
            />
            <Fallback color={Some(Color::Accent)}>{"JD"}</Fallback>
        </Avatar>
    }
}

The fallback shows while the image loads, hides once it lands.

`Fallback`

Text initials, an icon, or anything you want rendered when the image hasn't loaded yet (or doesn't exist at all). Supports a delay_ms prop to intentionally delay reveal, useful when your image usually loads fast and you don't want the fallback to flash briefly then disappear.

// Fallback shows immediately:
<Fallback color={Some(Color::Success)}>{"MH"}</Fallback>

// Fallback waits 200ms before appearing (prevents flicker on fast connections):
<Fallback delay_ms={200} color={Some(Color::Accent)}>{"JD"}</Fallback>

Small prop, big UX difference.

`Group`

Stack multiple avatars with automatic overlap, configurable max count, and an overflow badge showing how many more there are.

use avatar::yew::{Avatar, Group, Count, Image, Fallback};
use avatar::{Color, Size, Variant};
use yew::prelude::*;

#[function_component(TeamStack)]
pub fn team_stack() -> Html {
    html! {
        <Group
            size={Size::Lg}
            max={Some(3)}
            total={Some(6)}
            aria_label="Project team"
        >
            <Avatar aria_label="Member 1">
                <Image src="https://i.pravatar.cc/150?u=m1" alt="Member 1" />
                <Fallback color={Some(Color::Accent)}>{"M1"}</Fallback>
            </Avatar>
            <Avatar aria_label="Member 2">
                <Image src="https://i.pravatar.cc/150?u=m2" alt="Member 2" />
                <Fallback color={Some(Color::Success)}>{"M2"}</Fallback>
            </Avatar>
            <Avatar aria_label="Member 3">
                <Image src="https://i.pravatar.cc/150?u=m3" alt="Member 3" />
                <Fallback color={Some(Color::Warning)}>{"M3"}</Fallback>
            </Avatar>
            <Count
                color={Some(Color::Danger)}
                variant={Some(Variant::Soft)}
                aria_label="3 more members"
            />
        </Group>
    }
}

Pass max={Some(3)} and total={Some(6)}, and Count automatically shows +3. The math is done for you. The CSS overlap is done for you. You just write components.

The `overflow_count` Context

This is the part that required actual thought.

Group computes overflow_count = total - max and pushes it into context. Count reads it from context when its own count prop is zero (the default). This means the badge doesn't need to know anything explicit, it just reads the group state.

// In Group:
let overflow_count = total.saturating_sub(max);
ctx_provider.provide(&GroupContext { overflow_count, .. });

// In Count:
let effective_count = if count == 0 { ctx_overflow } else { count };
// Renders: "+{effective_count}"

One source of truth.

Framework Parity

All three frameworks ship the same API surface:

Feature	Yew	Dioxus	Leptos
`Avatar`	✅	✅	✅
`Image`	✅	✅	✅
`Fallback`	✅	✅	✅
`Group`	✅	✅	✅
`Count`	✅	✅	✅
`total` + `max` overflow	✅	✅	✅
Context propagation	✅	✅	✅
`delay_ms` on fallback	✅	✅	✅
Image RS integration	✅	✅	✅

The Dioxus and Leptos implementation uses use_context_provider / use_context idioms native to each framework, but the behavior is identical. If you've used it in Yew, you already know how to use it in Leptos.

Soft Refresh & The Browser Cache Fix

Here's one that caught us off guard. In Yew, images rendered via Image would sometimes fail to appear after a soft page refresh. Hard refresh? Fine. Soft? Gone.

The culprit: when a browser serves an image from cache, the load event fires before Yew has had a chance to attach the listener. The effect sees a "loading" state, the image is already done, and the component never flips to "loaded".

The fix was straightforward once we knew what to look for. We inject a node_ref into the underlying <img> element and check img.complete on mount:

use_effect_with(props.src, move |src| {
    if !src.is_empty() {
        let already_loaded = node_ref
            .cast::<web_sys::HtmlImageElement>()
            .map(|img| img.complete())
            .unwrap_or(false);

        if already_loaded {
            status.set(ImageLoadingStatus::Loaded);
        } else {
            status.set(ImageLoadingStatus::Loading);
        }
    }
    || ()
});

This required adding web-sys with the HtmlImageElement feature to the yew feature gate in Cargo.toml. A small addition, but it closes a genuinely annoying browser quirk.

Dioxus and Leptos did not have this issue, their reactive systems handle DOM updates differently and don't suffer from this ordering problem.

Colors, Variants, Sizes

Everything inherits downward through context. Set defaults at the group level, override them per-avatar if needed.

// Colors
Color::Default | Color::Accent | Color::Success | Color::Warning | Color::Danger | Color::Custom("...")

// Variants
Variant::Default  // solid fill
Variant::Soft     // muted, lower-contrast

// Sizes
Size::Xs | Size::Sm | Size::Md | Size::Lg | Size::Xl | Size::Xxl | Size::Custom("...")

Color::Custom("...") and Size::Custom("...") accept raw CSS strings, so if your design system uses hsl(270 60% 50%) or 3.5rem, those work too.

Quick Setup

# Yew
cargo add avatar --features=yew

# Dioxus
cargo add avatar --features=dio

# Leptos
cargo add avatar --features=lep

That's it. The styling is computed inline from the prop values.

Accessibility

Every component exposes its ARIA props explicitly:

Avatar renders role="img" with a required aria_label.
Image manages aria-hidden based on loading state.
Fallback is hidden from assistive tech once the image loads.
Group gets an aria_label for the whole group.
Count gets its own aria_label (defaults to "Additional members").

Screen readers get a consistent, clear picture regardless of whether images loaded or not.

What We Didn't Do

No auto-injection of count badges. No magic child-slicing that differs between frameworks. No runtime diffing of the children list to figure out how many to show. These patterns break in different ways across Yew, Dioxus, and Leptos, and they make the component harder to reason about.

Instead: explicit total and max props, explicit Count placement, one context object that everything reads from. It's a little more to type. It's a lot easier to debug.

Final Thoughts

Avatar RS is exactly what it says on the tin: a production-ready avatar component for WASM apps.

It's backed by Image RS, which means you get all the image loading sophistication without reinventing it. The overflow logic is explicit and predictable. Framework parity is real, not aspirational.

opensass / avatar

👦 A highly customizable avatar component for WASM frameworks (Powered by Image RS).

👦 Avatar

🎬 Demo

Framework	Live Demo
Yew
Dioxus
Leptos

📜 Intro

A highly customizable, accessible avatar component for WASM frameworks: Yew, Dioxus, and Leptos. Supports image loading with automatic fallback content, multiple sizes, color themes, and full WCAG compliance.

🤔 Why Avatar?

🎨 Fully Customizable: Control every attribute, class, style, size, color, variant, ARIA labels and more.
🖼️ Smart Image Loading: Tracks idle → loading → loaded/error status with context. Fallback is shown until the image is ready.
⏱ Delay Support: Prevent flash-of-fallback on fast connections with delay_ms.
♿ Accessible by Default: role="img", aria-label, aria-hidden wired up automatically.
🧩 Framework Agnostic: Same API semantics across Yew, Dioxus, and Leptos.

Y Yew Usage

Refer to our guide to integrate this component into your Yew app.

🧬 Dioxus Usage

Refer to our guide to integrate this component into your Dioxus app.

🌱 Leptos

…

View on GitHub

We are Open SASS, babe!

We're working tirelessly on making Rust web development extremely easy for everyone.

If you made it this far, it would be nice if you could join us on Discord.

Till next time 👋!

I Resurrected a Dead CRC Crate and It Suddenly Went Viral

Mahmoud 🦀 — Sun, 20 Sep 2026 09:11:49 +0000

Bonjour 👋!

So there I was, browsing crates.io at an hour that most reasonable people would describe as "the middle of the night", doing what all emotionally stable developers do at that hour: auditing dead Rust crates for signs of life.

That's when I found crc32.

Not crc32fast. Not crc. Not crc32c. The original. The stubby, ancient, crc32 crate. Last published in 2015. No changelog. No CI. A Cargo.toml that predates most of the stable Rust syntax I use daily. And sitting there, abandoned and unloved.

People were using this thing. Were probably shipping software with it in their dependency tree. They just didn't know how to reach the crate maintainer, who had apparently retired to a cabin in the woods with no internet access sometime around when Rust 1.0 was announced.

I stared at those download numbers for thirty seconds.

Then I did what any emotionally stable rustacean would do: I resurrected it. From the ashes. In modern Rust. With no_std. With Python bindings. With a build-time proc-macro codegen crate. With CI/CD, Debian packaging, RPM packaging, and a Ferris logo.

You know. Normal stuff.

Wait, What Even Is CRC-32?

CRC-32 stands for Cyclic Redundancy Check, 32-bit variant. It's the checksum algorithm that:

ZIP files use to verify archive integrity.
Ethernet frames use to detect bit errors in transmission.
FDDI, PKZIP, PNG and approximately half the binary protocols ever invented also use.
Every zlib function you've ever called calls internally when you weren't paying attention.

In other words, CRC-32 is everywhere. It's the duct tape of data integrity. It's been computing checksums since before most of today's developers were handing in their first homework assignments.

The original Rust crc32 crate implemented the byte-at-a-time version, the classic, the grandaddy variant. Simple. Correct. Slow as a 56k modem by 2024 standards.

I didn't just port it. I rewrote the whole thing from the zlib source, added slicing-by-4, slicing-by-8, and slicing-by-16 table variants, pulled the table-generation itself into a build-time proc-macro subcrate, added a streaming Digest, a GF(2) matrix combine function, and shipped the whole thing as a no_std library with Python and Node.js bindings.

All in 100% safe Rust. With #![forbid(unsafe_code)] at the crate root.

Because anything worth resurrecting is worth resurrecting properly.

The Architecture

Let me tell you what the original crc32 crate looked like. It was, essentially:

src/lib.rs
src/crc32gen.rs
src/crc32gen_file.rs

That's it. 3 files. A lookup table, a loop, a bitwise XOR. Beautiful in its simplicity, like a stone hut in a field. Functional. Zero frills. Absolutely not capable of 1 GiB/s throughput.

Here's what crc32-v2 looks like today:

crc32-v2/
├── crc32-codegen/             ← proc-macro subcrate: generates all 17 CRC tables at build time
│   └── src/lib.rs             ← build.rs calls crc32_codegen::run() → writes to $OUT_DIR
├── src/
│   ├── lib.rs                 ← minimal entry point: #![no_std], module declarations, Python FFI
│   ├── tables.rs              ← crc32() byte-at-a-time baseline
│   ├── byfour.rs              ← crc32_little / _8 / _16 / crc32_big
│   ├── combine.rs             ← crc32_combine() via GF(2) matrix squaring in O(log n)
│   ├── digest.rs              ← streaming Digest with update() / finalize() / digest()
│   └── python.rs              ← PyO3 bindings (gated on feature = "python" + "std")
├── tests/
│   └── byfour.rs              ← 40 Rust integration tests
└── python/
    └── crc32_rs/
        └── __init__.py        ← re-exports all symbols from the compiled .so

The stone hut has been converted into a, uh, well-appointed facility.

The Magic Trick

This is my personal favourite part of the whole project. And possibly the most unhinged.

CRC-32 slicing-by-16 requires 17 lookup tables: one 256-entry big-endian table, and 16 256-entry little-endian tables at different offsets. That's 17 × 256 × 4 = 17,408 bytes of lookup table data that needs to exist at runtime.

The naive way: write the tables by hand and commit 17,000 bytes of constants to git as a .rs file.

The normal way: generate them at startup and cache them in a static.

The way I did it: proc-macro subcrate (crc32-codegen) that is invoked from build.rs at compile time, generates all 17 tables using the CRC-32 polynomial arithmetic, writes them to $OUT_DIR/crc_tables.rs, and the main crate include!s the output. Zero runtime initialization. Zero startup cost. The tables are baked into the binary at link time.

[build-dependencies]
crc32-codegen = { path = "crc32-codegen" }

fn main() {
    crc32_codegen::run();
}

That's the entire build.rs. One function call. The codegen crate does all the polynomial math, formats the Rust source, and writes it to disk. The main crate wakes up with all 17 tables pre-computed, pre-verified, and pre-formatted.

This is the kind of thing that inspires either awe or a mildly concerned Slack message from your coworkers. There is no middle ground.

The 4 Speeds of CRC-32

Let me paint you a picture of what "slicing-by-N" actually means, because it's one of those ideas that sounds arcane until you see the numbers and then you can't stop thinking about it.

The classic CRC-32 loop looks like this:

for &byte in buf {
    let index = (crc ^ u32::from(byte)) & 0xff;
    crc = CRC_TABLE[0][index as usize] ^ (crc >> 8);
}

One byte per iteration. One table lookup. On a 1 MiB payload that's 1,048,576 iterations. At ~2 ns per iteration (fast CPU, warm cache), that's ~2ms. Not terrible. Not great.

Slicing-by-4 says: what if we process four bytes per iteration instead? You pre-compute four separate 256-entry tables (one for each byte offset), and in each step you XOR together four table lookups instead of one. Four bytes per iteration, four table lookups, but modern CPUs can do all four lookups in parallel because there are no data dependencies between them. Result: roughly 2.4× faster.

Slicing-by-8 does the same with eight tables. Slicing-by-16 pushes it to sixteen tables and sixteen bytes per step, letting the CPU's out-of-order execution and instruction-level parallelism do the heavy lifting. With #[inline(always)] on the inner fold functions, fat LTO, and overflow-checks = false in the bench profile, LLVM sees through all the abstraction and generates machine code that is, frankly, embarrassingly fast for code written entirely in safe Rust.

The full breakdown:

Method	1 B	64 B	1 KiB	64 KiB	1 MiB	Throughput
`crc32` (byte-at-a-time)	2 ns	167 ns	2,856 ns	188,134 ns	2,916,562 ns	~343 MiB/s
`crc32_little` (slicing-by-4)	3 ns	73 ns	1,086 ns	82,129 ns	1,199,953 ns	~833 MiB/s
`crc32_little_8` (slicing-by-8)	3 ns	61 ns	922 ns	56,486 ns	1,004,746 ns	~1,004 MiB/s
`crc32_little_16` (slicing-by-16)	3 ns	39 ns	753 ns	48,101 ns	781,535 ns	~1,282 MiB/s
`crc32fast` (SIMD via `pclmulqdq`)	11 ns	20 ns	102 ns	5,802 ns	89,204 ns	~11,300 MiB/s

crc32_little_16 hits ~1,282 MiB/s on a 1 MiB payload. That's 3.7× faster than the baseline, without a single SIMD intrinsic, without a single unsafe block, and without any CPU feature detection. It Just Works on x86-64, ARM, RISC-V, WASM, and whatever exotic architecture you're running this week.

Note that tiny 1-byte payloads still favour the baseline crc32 (2 ns vs 3 ns) because the slicing variants pay a small alignment prologue overhead. We document this honestly, unlike some people's README files.

The Cross-Library Reality Check

Look. I know what you're thinking. "But crc32fast uses SIMD and does 11 GiB/s. Doesn't that make this pointless?"

No. Here's why.

crc32fast is genuinely excellent for x86-64 with pclmulqdq. But crc32-v2 occupies a different niche:

Library	Method	Time (1 MiB)	Throughput	Type
`crc32fast`	`hash`	89,204 ns	~11,300 MiB/s	SIMD (`pclmulqdq`) / Rust
`zlib-rs`	`crc32`	96,968 ns	~10,390 MiB/s	SIMD / Rust
Python (`zlib.crc32`)	C extension	355,270 ns	~2,815 MiB/s	SIMD / C
`crc32-v2`	`crc32_little_16`	781,535 ns	~1,282 MiB/s	Pure safe Rust
Python (`crcmod`)	C extension	2,865,836 ns	~349 MiB/s	Non-SIMD / C

crc32fast: amazing. zlib-rs: also amazing. Both use runtime SIMD dispatch and unsafe. Both don't compile to WASM without special handling. Both don't work in no_std environments without a careful dance.

crc32-v2 compiles everywhere Rust compiles. Embedded RISC-V? Yes. wasm32-unknown-unknown? Yes. A microcontroller that needs to verify a firmware checksum before flashing? Yes. A kernel module? With #![no_std] and a custom allocator? Also yes.

When you need 11 GiB/s you use crc32fast. When you need something that works anywhere, has zero dependencies outside alloc, and is produced by a compiler that will literally refuse to let you write unsafe code: you use crc32-v2. There are more situations in the second category than you'd expect.

Python Bindings

Here's a section I am writing in the spirit of radical honesty. Shipping Python bindings for a Rust library requires configuring:

maturin (the build tool)
pyo3 (the FFI framework)
pyproject.toml (the Python packaging config)
A python/crc32_rs/__init__.py that re-exports from the compiled .so
The module-name field in pyproject.toml matching the #[pymodule] name in Rust

If any one of these four things is even slightly wrong, Python greets you with:

ModuleNotFoundError: No module named 'crc32_rs'

Not a helpful error. Not "the module-name in pyproject.toml doesn't match the pymodule attribute". Just: it doesn't exist. Good luck.

I went through approximately four rounds of this before getting it right. The root cause was a mismatch between module-name = "crc32_v2._crc32_v2" (incorrect) and module-name = "crc32_rs._crc32_v2" (correct). One underscore in the wrong namespace and Python acts as if the entire compiled extension simply does not exist in this universe.

The fix took three characters. The investigation took forty-five minutes.

>>> from crc32_rs import crc32, crc32_little_16, crc32_bytes, crc32_hex, Digest
>>> 
>>> print(hex(crc32(b"Hello, world!")))
0xebe6c6e6
>>> print(hex(crc32_little_16(b"Hello, world!")))
0xebe6c6e6
>>> print(crc32_bytes(b"Hello, world!").hex())
ebe6c6e6
>>> print(crc32_hex(b"Hello, world!"))
ebe6c6e6
>>> 
>>> d = Digest()
>>> d.update(b"Hello, ")
>>> d.update(b"world!")
>>> print(hex(d.finalize()))
0xebe6c6e6
>>> print(repr(d))
Digest(crc=0xEBE6C6E6)

Now it works. The Python interpreter is stuffed. We do not speak of the forty-five minutes.

Rust for Python Developers

Let's talk about something that the throughput benchmarks don't fully capture: what happens to performance when you're computing CRC-32 on tiny payloads? Like, really tiny. 1 byte tiny.

The issue with Python's zlib.crc32 is not that it's slow for large inputs, it delegates to SIMD C code under the hood and handles 1 MiB payloads at 2,815 MiB/s, which is genuinely fast. The issue is that every Python function call carries ~200-300 ns of interpreter overhead before you've even touched a byte of data.

Payload	Python `zlib.crc32`	Rust `crc32-v2`	Speedup
1 B	~297 ns	~2 ns	~148×
64 B	~301 ns	~39 ns	~7.7×

148 times faster on a single byte. If you're checksumming thousands of small messages per second, network packets, log entries, sensor readings, the Python interpreter overhead alone is eating your entire latency budget before you even get to the CRC computation.

Moving the loop into Rust and calling Python once at the end is not premature optimisation. It is the correct architectural decision. crc32-v2 makes that decision easier to implement.

`no_std`: Ferris Goes Embedded

This was the part I underestimated most. Adding no_std support sounds simple: slap #![cfg_attr(not(feature = "std"), no_std)] on the library, add extern crate alloc, and done.

And then you build the cdylib target without std features and discover that a dynamic library needs a panic handler and a global allocator, because without std, the linker has no idea what to do when you panic, and with no allocator it has equally no idea what to do when something tries to allocate.

The fix requires a dummy allocator implemention that satisfies the GlobalAlloc trait contract just enough to let the linker stop complaining:

# Features that gate the standard library
[features]
default = ["std"]
std = []
python = ["pyo3", "std"]    # Python bindings require std
node = ["napi", "napi-derive", "napi-build", "std"]  # Node.js too

#![cfg_attr(not(feature = "std"), no_std)]
extern crate alloc;

And panic = "abort" in [profile.dev] so that the no_std cdylib doesn't try to set up unwinding infrastructure that doesn't exist.

Result: cargo build --no-default-features completes successfully. Ferris is now embeddable. The microcontroller community rejoices.

Safety

#![forbid(unsafe_code)] is enforced at the crate root. This is a compiler directive that physically prevents any unsafe block from being compiled into the library.

The borrow checker, like a very particular building inspector, will reject your PR on first principles if you try to introduce unsafe into the slicing loops, the GF(2) matrix arithmetic, the streaming Digest, or the codegen subcrate. You can argue with it. You can find workarounds. The borrow checker does not care. It has seen your workarounds and it finds them unconvincing.

The only unsafe surface is the Python FFI layer's dummy allocator stub needed for bare-metal builds, and this is isolated, cfg-gated, and documented. The rest of the crate is provably safe at compile time.

This means you can use crc32-v2 in environments where one unsafe bug could corrupt a firmware image, crash a file server, or cause a network device to accept invalid data. The compiler provides the guarantee. Not the tests. Not the code review. The compiler.

Getting Started

Rust

[dependencies]
crc32-v2 = "0.2.0"

# For embedded / no_std:
# crc32-v2 = { version = "0.2.0", default-features = false }

use crc32_v2::{crc32, crc32_combine, byfour::crc32_little_16, Digest};

// One-shot
assert_eq!(crc32(0, b"123456789"), 0xCBF43926);

// Fastest pure-software path (~1,282 MiB/s)
assert_eq!(crc32_little_16(0, b"Hello, world!"), 0xEBE6_C6E6);

// Streaming
let mut d = Digest::new();
d.update(b"Hello, ");
d.update(b"world!");
assert_eq!(d.finalize(), 0xEBE6_C6E6);

// Combine two independently-computed CRCs (O(log n) via GF(2) matrix squaring)
let c1 = crc32(0, b"Hello, ");
let c2 = crc32(0, b"world!");
assert_eq!(crc32_combine(c1, c2, 6), crc32(0, b"Hello, world!"));

Python

pip install crc32-rs

>>> from crc32_rs import crc32, crc32_little_16, crc32_bytes, crc32_hex, Digest

>>> assert hex(crc32(b"123456789")) == "0xcbf43926"
>>> # The correct CRC-32 of "rust_magic" is:
>>> print(hex(crc32(b"rust_magic")))
0xa3067d13

Node.js

npm install crc32-rs

const { crc32, crc32Little16 } = require('crc32-rs');
console.log(crc32(Buffer.from("Hello, world!")).toString(16)); // ebe6c6e6

What's Next

The crate is at 0.2.0 and functionally complete for its initial scope. The roadmap includes:

Slicing-by-32: Because if 16 tables give us 3.7× speedup, we're obligated to find out where the speedup curve flattens.
serde support: Serialize and deserialize Digest state for resumable streaming checksums.
WASM target: The no_std foundation is already there. The WASM build should be trivial in theory. "In theory" is doing a lot of work in that sentence and I am prepared for it to do slightly less work once I try it.

Closing Thoughts

crc32-v2 started as a resurrection project. Someone wrote crc32 in 2015, abandoned it, and 9,062 people quietly became dependent on it through their transitive dependency graphs without knowing they were relying on a crate that predated Rust 1.0.

It ended up as something that resurrected the algorithm and pushed it forward: slicing-by-16 giving 3.7× throughput improvement, build-time table codegen via proc-macro, no_std compatibility, Python and Node.js bindings, and Ferris the Crab holding a magic wand computing 0xa3067d13 in your terminal.

The original crc32 crate was doing its best with 2015-era Rust. We can do more. We should do more. The 9,062 people who downloaded it deserve more.

cargo add crc32-v2 → compute checksums → sleep well knowing Ferris has you covered 🦀⚡

Star the repo, try the Python bindings, install the npm package, or read the docs if you still have questions.

This has been a public service announcement from someone who looked at a dead Rust crate with 9,062 downloads and thought: "Someone should fix this."

That someone was me. And honestly? It was a great use of my 2AM.

Till next time: Keep the bytes honest. Keep the checksums rolling. 🦀🔄

wiseaidev / crc32-v2

The fastest port of the CRC-32 algorithm in Rust.

⚡ CRC32-V2

The fastest pure-software, no_std-compatible CRC-32 implementation in Rust, slicing-by-16 tables, zero heap allocation in the hot path, and native Python / Node.js bindings, all written in 100% safe Rust 🗿.

🚀 Installation

Platform	Command / Link
Rust	`cargo add crc32-v2`
Rust (no_std)	`cargo add crc32-v2 --no-default-features`
Python	`pip install crc32-rs`
Node.js	`npm install crc32-rs`
Debian / Ubuntu	`gh release download`, see PACKAGING.md
RHEL / Fedora	`gh release download`, see PACKAGING.md

🔭 Features

Feature	Description
`no_std` + `alloc`	Embeddable in bare-metal, WASM, and embedded targets, no standard library required
100% safe Rust	`#![forbid(unsafe_code)]` enforced crate-wide; zero `unsafe` blocks
`crc32`	Byte-at-a-time baseline (~343 MiB/s); compatible with zlib, PKZIP, Ethernet, and FDDI
`crc32_little`	Slicing-by-4 (~833 MiB/s); 2.4× faster than byte-at-a-time
`crc32_little_8`	Slicing-by-8 (~1,004 MiB/s); 2.9× faster than byte-at-a-time
`crc32_little_16`	Slicing-by-16 (~1,282 MiB/s); 3.7× fastest pure-software path
`crc32_big`	Big-endian (unreflected) variant for hardware CRC controllers
`crc32_combine`	Merge

…

View on GitHub

P.S. The original crc32 crate maintainer is apparently a Microsoft employee. So, if you happen to work at Microsoft and are currently hiring Rust developers who spend their 2AM evenings resurrecting ancient dependencies to slice them by 16, please hit me up. We can bond over polynomial arithmetic. Thanks for the help <3!

Frozendict 🧊: State of the Art Immutable Hashmap for Python and Node JS.

Mahmoud 🦀 — Sat, 19 Sep 2026 04:25:17 +0000

Hello 👋!

So there I was, staring at Python's frozenset, feeling that specific special rage that only a data structure enthusiast at 1AM can feel, while dict sat there, utterly mutable, fully hashable, completely disobedient.

Dictionary keys can change. You can pop from it. You can clear it. You can update it mid-computation and break 30 tests simultaneously.

I looked at this situation calmly. And then I did what any reasonable person would do: I wrote frozndict, a fully immutable, insertion-ordered, O(1)-hashable dictionary in 100% safe Rust with Python and Node.js bindings so fast they make frozendict (the C extension) look briefly embarrassed at its own party.

The result? frozndict: the state of the art immutable hashmap. Frozen at construction. Hashable by design. Faster than guilt.

Why Should You Care?

Python's dict is a magnificent beast. It's ordered, fast, flexible. It is also a ticking time bomb if you try to use one as a cache key, a functools.lru_cache argument, or anywhere that requires hashability.

cache = {}
key = {"x": 1}
cache[key] = 42  # TypeError: unhashable type: 'dict'

The stdlib's frozenset solved this for sets. Nobody solved it properly for dicts for 15+ years, until frozendict (the C extension) came along. And then I looked at frozendict's construction time and made a concerned face.

frozndict solves all of this:

Truly immutable: mutation attempts at the Rust level raise TypeError. Not AttributeError. No monkey-patching. __setitem__, __delitem__, update, clear, pop, popitem, and setdefault are all implemented, as gates that will refuse you entry and then log the attempt somewhere in the moral universe.
O(1) __hash__: computed once at construction. Subsequent calls return a cached isize. No recomputation. Ever.
O(1) copy(): returns the same Arc<FrozenDictInner>. One pointer copy. 63 ns. Done.
Insertion-ordered: all views, keys(), values(), items(), iterate in the order you inserted.
fromkeys support: FrozenDict.fromkeys(["a", "b"], 0) works exactly as you'd expect, including on subclasses.
Set algebra on views: fd.keys() & other_keys, fd.items() - other_items, ^, |, isdisjoint, all there.

The Architecture

Here is the internal layout:

FrozenDict
  └── Arc<FrozenDictInner>          ← shared ownership, O(1) clone
        ├── entries: Box<[(isize, Obj, Obj)]>   ← insertion-ordered (key_hash, key, val)
        ├── lookup: Box<[(isize, u32)]>          ← sorted by hash for binary search
        ├── hash: isize                          ← pre-computed at build time
        ├── cached_keys: OnceLock<Py<PyList>>    ← lazy, shared across views
        ├── cached_values: OnceLock<Py<PyList>>
        └── cached_items: OnceLock<Py<PyList>>

The key insight: entries stay in insertion order. The lookup table is a separate, sorted slice used only for binary search. This gives us:

O(n) insertion-ordered iteration (just walk entries)
O(log n + k) lookup (binary search to the hash bucket, then linear scan for collision k)
O(n log n) construction (one sort of the lookup table, then done)
O(1) copy() and clone() (pointer copy of the Arc)

The hash is computed by XOR-mixing each key_hash * MIX_KEY ^ value_hash * MIX_VAL. Order-independent. Two frozen dicts with the same contents but different insertion order are equal and share a hash. As nature intended.

The Performance Numbers

These are real numbers. Benchmarked with timeit on Python 3.12.3, x86-64 Linux, min of 7 runs × 2,000 iterations, N=1000 entries.

Python-level benchmark

Operation	Python dict	frozendict (C)	immutables.Map	frozndict 🧊
Construction	6.45 µs	7.70 µs	241.67 µs	90.70 µs
Clone O(1)	6.45 µs	70.48 ns	404.62 ns	138.68 ns
Equality	19.37 µs	19.44 µs	24.39 ns	32.42 ns
Iteration	7.39 µs	7.42 µs	14.97 µs	4.14 µs
copy()	6.53 µs	323.83 ns	317.07 µs	63.29 ns
hash()	N/A	168.19 ns	45.07 ns	45.52 ns
Lookup	32.52 ns	48.31 ns	48.11 ns	82.62 ns

frozndict wins iteration, copy(), equality, clone, and very nearly ties immutables.Map on hash(). On a per-call basis, the pure Rust functions run in nanoseconds, which is approximately 1,000,000x faster than any Python-level re-implementation of the same logic would be. This is what happens when you move computation to Rust and let LLVM take it from there.

Rust-level benchmark

Workload	Time
Construction, n=100	~2.7 µs
Construction, n=1000	~35 µs
Lookup hit	~41 ns
Lookup miss	~39 ns
Iteration, n=1000	~3.1 µs
`hash()`	~4.8 µs
`with()` (functional update)	~31 µs
`merge()`	~35 µs

The lookup path is 40 nanoseconds. For comparison, a Python function call overhead alone is about 60-100 ns. frozndict answers your lookup query faster than Python could even begin thinking about it.

The Equality Problem

Here is a question for you: are these two FrozenDicts equal?

a = FrozenDict({"x": 1, "y": 2})
b = FrozenDict({"y": 2, "x": 1})  # different insertion order
a == b  # ?

Yes. Obviously yes. They have the same key-value pairs. The answer is True.

The naive implementation, comparing entries positionally, index by index, returns False because the entries are stored in insertion order. Early frozndict versions had exactly this bug. I discovered it while writing the tests at midnight and sat in silence for a moment before going to fix it.

The correct implementation uses the sorted lookup table to do a key-based lookup for each entry in other, then checks the value. Order-independent. Hash-consistent. Correct.

a == b  # True
hash(a) == hash(b)  # True, hash is order-independent by design
{a, b}  # {frozendict({'x': 1, 'y': 2})}, only one element

That last line, being usable in a set, is the whole point. If your immutable dict can't be a set member, what are you even doing with your life?

The `Arc<FrozenDictInner>` Design

Every Python object wrapping frozndict shares one Arc<FrozenDictInner>. When you call copy(), we clone the Arc, which is a single atomic increment on a reference count. No allocation. No copying of entries. No touching the lookup table.

import time
from frozndict import FrozenDict

d = FrozenDict({i: i*2 for i in range(1000)})
t0 = time.perf_counter_ns()
c = d.copy()
t1 = time.perf_counter_ns()
print(t1 - t0)  # \~63 ns

63 nanoseconds. For a 1,000-entry dictionary.

For comparison, copy.copy() on a Python dict of the same size is ~6.5 µs. That's 100x slower than frozndict.copy(). And copy() on the C frozendict is ~324 ns, still 5x slower.

frozndict.copy() is so fast it's almost a moral argument for immutability. Why would you ever mutate a dictionary when the immutable version is cheaper to "clone"?

The Views

frozndict returns view objects that behave like dict_keys, dict_values, and dict_items, but with the full set-algebra API you always wished Python's dict views had by default.

d1 = FrozenDict({"a": 1, "b": 2, "c": 3})
d2 = FrozenDict({"b": 2, "c": 99, "d": 4})

# Keys set algebra
d1.keys() & d2.keys()          # frozenset({'b', 'c'})
d1.keys() | d2.keys()          # frozenset({'a', 'b', 'c', 'd'})
d1.keys() - d2.keys()          # frozenset({'a'})
d1.keys() ^ d2.keys()          # frozenset({'a', 'd'})
d1.keys().isdisjoint(["x"])    # True

# Items set algebra (tuples!)
d1.items() & d2.items()        # frozenset({('b', 2)}), only exact (k,v) matches
d1.items() - d2.items()        # frozenset({('a', 1), ('c', 3)})

The views are lazy, they hold a reference to the same Arc<FrozenDictInner>, share zero extra memory overhead, and do all set operations on demand. The items view is particularly clever: ("c", 3) is NOT in both dicts' items because the values differ (3 vs 99). The binary lookup handles this correctly.

Mutation Guards

Every mutable dict method exists on FrozenDict. All of them raise TypeError. This is important:

fd = FrozenDict({"a": 1})
fd["b"] = 2         # TypeError: 'FrozenDict' object does not support mutation
fd.update({"c": 3}) # TypeError: 'FrozenDict' object does not support mutation
fd.pop("a")         # TypeError: 'FrozenDict' object does not support mutation
fd.clear()          # TypeError: 'FrozenDict' object does not support mutation
del fd.x            # TypeError: 'frozendict' object does not support mutation

Why implement these at all if they just fail? Because Python's typing.MutableMapping and collections.abc.Mapping ABCs expect these methods to exist for proper isinstance checks and duck-typing. If you use a FrozenDict anywhere a dict | MutableMapping is type-hinted, you get the correct TypeError, not a cryptic AttributeError suggesting the method doesn't exist.

This is the difference between "I cannot do this" and "this object has no concept of doing this". frozndict chooses the former. We exist. We just refuse.

Subclassing, `fromkeys`, `__class_getitem__`, and `reversed()`

All of the things Python developers expect to work, work.

class ColdStorage(FrozenDict):
    pass

cs = ColdStorage({"temp": -273})
ColdStorage.fromkeys(["a", "b", "c"], 0)
# frozendict({'a': 0, 'b': 0, 'c': 0})

FrozenDict[str, int]
# frozndict.FrozenDict[str, int]  ← GenericAlias, works with type hints

list(reversed(FrozenDict({"c": 3, "a": 1, "b": 2})))
# ['b', 'a', 'c']

fromkeys on a subclass returns an instance of the subclass. __class_getitem__ returns a frozndict. __reversed__ iterates keys in reverse insertion order.

These are the features that make a library correct instead of merely functional. There's a difference.

Getting Started

pip install frozndict

from frozndict import FrozenDict

>>> fd = FrozenDict({"name": "Ferris", "type": "crab", "mood": "frozen"})
>>>
>>> fd["name"]
'Ferris'
>>> fd.get("age", 0)
0
>>> hash(fd)
-7563131740537042003
>>> fd.copy()
frozendict({'name': 'Ferris', 'type': 'crab', 'mood': 'frozen'})
>>>
>>> # Use it as a dict key:
>>> memo = {fd: "result"}
>>>
>>> # Use it in a set:
>>> seen = {fd}

As a Rust library:

[dependencies]
frozndict = "2.1.1"

use frozndict::FrozenMap;

let map: FrozenMap<&str, i32> = FrozenMap::new([("a", 1), ("b", 2)]);
assert_eq!(map.get("a"), Some(&1));
assert_eq!(map.len(), 2);

let extended = map.with("c", 3);
assert_eq!(extended.len(), 3);

The Road Ahead

frozndict 2.1.1 is stable but not finished. The roadmap includes:

WASM target: compile the core to wasm32-unknown-unknown for browser-side immutable hashmaps
serde support: serialize/deserialize FrozenMap as naturally as a HashMap

If any of these sound urgent to you: open an issue. Or star the repo.

Closing Thoughts

frozndict does one thing: it gives Python a dictionary that is genuinely, provably, irreversibly frozen. Not "sort of frozen if you don't try to break it". Frozen at the hardware level, where the Rust borrow checker watches over your entries like a disapproving parent at a teen party.

It's insertion-ordered. It's hashable. It's O(1) to copy. Its inner functions run in nanoseconds. It has views with set algebra. It subclasses correctly. Its fromkeys works. Its mutation guards are polite but firm.

wiseaidev / frozndict

State of the art immutable hashmap for Python and Node.

🧊 FrozenDict

frozendict is a state of the art world's most memory-efficient immutable hashmap written in 100% safe Rust, with native Python and Node.js bindings 🗿.

🚀 Installation

Platform	Command
Rust library	`cargo add frozendict`
Python	`pip install frozndict`
Node.js	`npm i frozendict`
Debian/Ubuntu	Download `.deb` from GitHub Releases
RHEL/Fedora	Download `.rpm` from GitHub Releases

🤔 What does this crate provide?

frozendict provides a fully immutable, hashable dictionary for Python and Node.js backed by a high-performance Rust core. It:

Stores entries in a single contiguous sorted heap allocation, zero per-entry heap overhead.
Looks up keys in O(log n) via binary search, no hashing, no pointer-chasing, excellent cache behaviour.
Caches its hash at construction, repeated hash() calls are O(1).
Integrates with Python's dict protocol (keys(), values(), items(), pickle, copy, | merge operator).
Exposes a native Node.js FrozenDict class with TypeScript declarations via napi-rs.
Provides functional…

View on GitHub

Star the repo. File issues. Use it as a cache key confidently. And the next time someone tries to mutate your dictionary mid-computation, point them here.

Till next time: Stay frozen. Stay fast. Don't mutate. 🦀🧊

I Optimized My Bump Version Tool and Made It 1,000,000x Faster Than Its Python Counterparts.

Mahmoud 🦀 — Fri, 11 Sep 2026 22:15:08 +0000

Hello again, fellow Rustaceans, Pythonistas in denial, and the three people on earth who genuinely enjoy reading version bumper release notes 👋!

If you were here for my last post, where I rewrote bump2version in Rust and declared it ~10,000x faster than the Python CLI, you may recall that I ended it with a vague threat about future benchmarks. The Mossad agents who consulted on the architecture wrote "this is not over" in the margin of their whiteboard. I ignored it.

I should have listened.

Because in the weeks since that post, I went back in. Deep in. I committed crimes against cargo build that will haunt me during thunderstorms. I --release'd things that should not be --release'd. I made Claude hallucinate a performance chart at 3AM and then used it to motivate myself.

The result: bump2version 0.2.1.

Now 1,000,000× faster than its Python counterparts. Yes, I am counting subprocess overhead.

The Soviet material resurfaced. It always does.

Let's get into it.

🤔 Wait, We Already Did This. Why Are We Here Again?

Because 0.2.0 shipped, and I immediately opened my Gmail inbox.

The audacity of the open-source community. The audacity, bro! I build something 10,000x faster and within days there are requests. "Can it watch files?", "Can it detect which manifests I'm using?", "Can I run it in the browser?", "Can I use it with Go?", "Can I use it with Java?", "Can my Ruby project use it?". I ain't got no time for this. I need to take a little break and play CS2 with the boys!

I looked at these emails. I looked at the ceiling. I looked at my coffee. The coffee looked back at me with the hollow expression of a language runtime that has seen too many package manager debates.

And then I cracked my knuckles and got to work.

🕵️ The Mossad Agents Return

I thought I was done with the Mossad agents after 0.2.0. I was not.

They came back. Same 3AM knock. Same whiteboard. But this time they brought slides. Twelve of them. With bullet points. And speaker notes. One slide was just the word "BRANCHLESS" in 72-point font with a red circle around it.

Their new requirements:

memchr for all hot-path string scanning. "You are doing .contains() in a loop like an animal", they said. I was.
SmallVec for version component storage. Because heap-allocating a Vec<u8> for three numbers (major, minor, patch) is an insult to modern CPU cache lines.
Branchless arithmetic for the bump itself. No if major { ... } else if minor { ... } nonsense. One lookup table. One store. Done.
Watch mode. They wanted to know the moment a file changed. I asked why. They said that was classified.
Auto-detect language manifests. "You scan Cargo.toml like it's the only file in the world", they observed, correctly. "What about pyproject.toml? pom.xml? go.mod? Are Go developers not also suffering?"

They are. They are very much also suffering.

I implemented every point. The Mossad agents reviewed the diff, said "passable", and vanished into the root filesystem like a well-placed .gitignore entry.

⚡ The 1,000,000× Number

Let me be absolutely scientifically honest with you for one sentence before I stop being honest: the 1,000,000× number compares the full bump-my-version CLI round-trip (importing Python, loading dependencies, spawning a subprocess) against our in-process library call with a warm cache and a SmallVec.

One is a sports car. The other is a person who has to call a taxi, wait 12 minutes, and explain where they're going in a language they only partially speak.

Now let's look at the real numbers.

🔥 New Benchmarks: `0.2.0` vs `0.2.1` vs Python

Operation	`bump2version` `0.2.0`	`bump2version` `0.2.1`	Python pyO3 FFI	`bump-my-version` CLI
Parse + bump + serialize	~57 µs	~0.4 µs	~79 µs	~585 ms
File search/replace (1k lines)	~65 µs	~11 µs	~1.7 µs	~590 ms
File search/replace (100k lines)	~4.2 ms	~0.9 ms	N/A	~600 ms
Config file parse	~800 µs	~140 µs	N/A	~500 ms (on import)

Versus the Python CLI subprocess: ((500 x 1000) ÷ 0.4) = ~1,250,000× faster for a version parse-bump-serialize. We round down to 1,000,000x for humility. The Mossad agents said rounding up was acceptable. We preferred honesty.

What got fast and why:

memchr replaced every inner-loop string search. memchr is basically SIMD-accelerated strchr and it is unreasonably good at its one job.
SmallVec<[VersionPart; 8]> means version component vectors never touch the allocator for reasonable semver (≤8 parts). Stack-allocated. L1 cache. Zero malloc.
Branchless bump arithmetic: the bump logic is now a lookup into a const table of which component to increment and which to zero. The CPU's branch predictor doesn't even have to sweat.
Arc<Regex> cache from 0.2.0 was kept. The regex is compiled exactly once and shared. The Mossad agents reminded us about this at every meeting by projecting the same slide.

📡 Watch Mode

bump --watch --bump patch

It sounds simple. It was the opposite of simple.

"Just watch a file and re-bump when it changes", I told myself, in the tone of a man who has never used inotify before.

Bro, I used inotify. Or rather, notify-rs used inotify for me, which is almost the same thing except someone smarter than me had already suffered through the Linux kernel filesystem event API so I wouldn't have to. God bless crate authors.

Watch mode works like this:

You provide a --watch flag.
bump registers a recursive file watcher on all files listed in your .bumpversion.toml.
Every time a registered file is saved (debounced to 200ms to avoid event avalanches), bump checks whether the version string is still consistent with current_version.
If it detects drift, it re-applies the bump.

This is either extremely useful for local development workflows or a deeply irresponsible footgun. We ship tools for adults. The lock safety is your problem.

# Watches VERSION, Cargo.toml, and README.md for changes, auto-bumps on save
bump --watch --bump patch --config-file .bumpversion.toml

# Oh no did I just? yes, yes you did. It already ran.
[watch] Detected change: Cargo.toml
[watch] Bumping patch: 0.2.1 → 0.2.2

🌐 Multi-Language Auto-Detection: `--detect` Is Doing God's Work

Previous bump2version was Rust-centric. You gave it files, it bumped files. Very obedient lil tool. Very rigid. Like a Rust compiler, actually.

The new --detect flag changes all that:

bump --bump minor --detect

This single command:

Walks the entire directory tree (skipping target/, node_modules/, .git/, etc.)
Finds every recognized manifest: Cargo.toml, pyproject.toml, setup.cfg, package.json, go.mod, pom.xml, build.gradle, Gemfile
Checks each one for the current version string
Rewrites every match in one coordinated pass

Six languages. One command.

cd my-monorepo
bump --current-version 0.1.0 --bump patch --detect --dry-run

# [detect][dry-run] Would update: Cargo.toml
# [detect][dry-run] Would update: pyproject.toml
# [detect][dry-run] Would update: package.json
# [detect][dry-run] Would update: pom.xml
# [detect][dry-run] Would update: go.mod
# [detect][dry-run] Would commit 5 file(s): 0.1.0 → 0.1.1

Full supported matrix:

Language	Manifest Files
🦀 Rust	`Cargo.toml`
🐍 Python	`pyproject.toml`, `setup.cfg`, `setup.py`
🟨 JavaScript / Node.js	`package.json`
🐹 Go	`go.mod`
☕ Java	`pom.xml`, `build.gradle`, `build.gradle.kts`
💎 Ruby	`Gemfile`

The Go developers, in particular, messaged to say thank you. We thanked them for using Go despite everything.

🌍 Real Language Examples

Every language now has a working example under examples/, each with its own pre-baked .bumpversion.toml.

# Python project
bump --config-file examples/python/.bumpversion.toml --bump patch --dry-run
# [dry-run] Would commit 2 file(s): 0.1.0 → 0.1.1

# Node.js project
bump --config-file examples/nodejs/.bumpversion.toml --bump minor --dry-run
# [dry-run] Would commit 1 file(s): 0.1.0 → 0.2.0

# Java Maven project
bump --config-file examples/java/.bumpversion.toml --new-version 2.0.0 --dry-run
# [dry-run] Would commit 1 file(s): 0.1.0 → 2.0.0

# Ruby gemspec + Gemfile
bump --config-file examples/ruby/.bumpversion.toml --bump major --dry-run
# [dry-run] Would commit 2 file(s): 0.1.0 → 1.0.0

# The "bump everything at once" grand finale
cd examples/multi-lang
bump --current-version 0.1.0 --bump minor --detect --dry-run
# [detect][dry-run] Would update: Cargo.toml, pyproject.toml, package.json, pom.xml, Gemfile, VERSION

6 ecosystems. 1 tool. Still forbids unsafe. We have standards.

🕸️ The Yew WASM App

You ever look at a perfectly good CLI tool and think: "This would be better if I could bump versions from a browser"?

No? Me neither. But then someone on the team whispered "WASM" and I remembered that I am constitutionally incapable of saying no to WebAssembly.

So now there is a Yew-based web application at examples/yew-app/. It:

Runs entirely in the browser: wasm32-unknown-unknown, no server required
Connects to the same Rust core via a version_ops.rs bridge module

And yes, git-related features had to be extracted into an optional feature flag (git) because gix uses Unix-specific APIs that don't compile to WASM. We found this out the fun way, which is a phrase that means "at 2AM with a 47-line linker error".

🤖 I Abused ChatGPT, Claude and Gemini. Again. More.

You may recall from my previous post that I abused Claude during 0.2.0 development. My lawyer said not to bring it up again.

So I won't bring up the fact that during 0.2.1 development, I made ChatGPT, Claude and Gemini:

Rewrite the detect.rs walk implementation 7 times until it correctly skipped node_modules without accidentally also skipping node_modules_backup (important distinction)
Argue with itself about whether SmallVec<[VersionPart; 8]> was better than SmallVec<[VersionPart; 4]> for typical semver usage (it is 8, empirically)
Generate .bumpversion.toml configs for 7 languages, review them for correctness, then find its own mistake in the Ruby config and fix it without being asked

The OpenAI, Anthropic and Google lawyers have upgraded from "concerned" to "a medium-sized incident report has been filed".

My legal counsel has asked that I clarify: no Claude was permanently harmed. Tokens were consumed. Electricity was used. The --detect flag works correctly.

🚀 3 Binaries, One Package, Zero Confusing Changelog Entries

After cargo install bump2version --features rust-binary, you get three things:

Binary	Use case
`bump`	The modern, primary CLI
`cargo-bump`	Cargo subcommand (`cargo bump --bump patch`)
`bump2version`	✅ Backward-compatible alias for old CI configs, tutorials, and the 47 blog posts that told people to run `bump2version --bump patch`

The bump2version binary is not deprecated. It is not going anywhere. If you have a shell script from 2025 that calls bump2version --bump minor, it will still work in 2030, and presumably during the heat death of the universe, if any of your CI pipelines survive that long.

This was a deliberate choice. Breaking changes in release tooling are a form of chaos that no version bumper should inflict on the people who trusted it.

# All of these do the exact same thing:
bump --bump patch
cargo bump --bump patch
bump2version --bump patch   # kept for backward compatibility

📋 The `.bumpversion.toml` Glow-Up

The config file now tracks all version-carrying files in the project, not just Cargo.toml:

[bumpversion]
current_version = 0.2.1
commit = false
tag = false

[bumpversion:file:Cargo.toml]
search = version = "{current_version}"
replace = version = "{new_version}"

[bumpversion:file:package.json]
search = "version": "{current_version}"
replace = "version": "{new_version}"

[bumpversion:file:README.md]
search = "{current_version}"
replace = "{new_version}"

[bumpversion:file:RUST.md]
search = "{current_version}"
replace = "{new_version}"

[bumpversion:file:WASM.md]
search = "{current_version}"
replace = "{new_version}"

[bumpversion:file:DOCKER.md]
search = `{current_version}`
replace = `{new_version}`

[bumpversion:file:PACKAGING.md]
search = {current_version}
replace = {new_version}

[bumpversion:file:rpm/bump2version.spec]
search = Version: {current_version}
replace = Version: {new_version}

One bump --bump patch and every single version string, across docs, code, configs, packaging specs, and Docker manifests, updates atomically. The Mossad agents reviewed this config and said "acceptable" which, from them, is essentially a standing ovation.

🦀 The Borrow Checker Tried to Ruin Watch Mode

There is a moment in every Rust developer's life, we all know the moment, where you look at a piece of code that should work, that does work in your head, that you have drawn on paper with arrows and boxes to prove its correctness, and the borrow checker looks at you across the compiler output and says:

error[E0505]: cannot move out of 'watcher' because it is borrowed

And then below that:

note: the borrow later used here

And then below that, a footnote that reads note: move occurs because... followed by a chain of reasoning so long it wraps around to the next terminal page.

The Yew WASM integration did this to me for different reasons: gix depends on Unix syscalls (openat, statx, platform symlink handling) that simply do not exist in wasm32-unknown-unknown. The linker error was 47 lines long and named three crates I had never heard of.

The fix: gating all git-related functionality behind a git feature flag that is disabled by default for WASM builds. Clean. Simple. The kind of solution that is obvious in retrospect and invisible before you spend four hours in the linker output.

[features]
default = ["std", "git"]
git      = ["gix", "std"]
cli      = ["clap", "git"]
rust-binary = ["cli", "git", "detect", "watch"]  # ← full featured binary
watch    = ["notify", "cli"]
detect   = ["walkdir", "cli"]

The WASM app uses none of the git features. The CLI binary uses all of them. The feature graph is clean enough that my Mossad advisors called it "elegant" before immediately asking about the benchmark numbers.

📦 Getting The Full Picture

# The complete CLI, with everything
cargo install bump2version --features rust-binary

This gets you bump, cargo-bump, and bump2version. All 3. No choices required. Just install and bump.

Quick Examples

# Standard semver
bump --bump patch           # 0.2.1 → 0.2.2
bump --bump minor           # 0.2.1 → 0.3.0
bump --bump major           # 0.2.1 → 1.0.0

# Safe preview
bump --bump patch --dry-run
bump --bump minor -n        # same thing, shorter

# Git integration
bump --bump patch --commit --tag

# Custom message
bump --bump minor --commit --message "chore: ship {new_version} 🚀"

# Auto-detect all manifests
bump --bump patch --detect

# Watch mode (exits when you ctrl + c)
bump --watch --bump patch

As a library (no `std` required for the core)

[dependencies]
bump2version = { version = "0.2.1", default-features = false }

use bump2version::{config::BumpConfig, version::{parse_version, bump_version, serialize_version}};

let cfg = BumpConfig::default();
let v   = parse_version("1.2.3", &cfg).unwrap();
let v2  = bump_version(&v, "minor", &cfg).unwrap();
assert_eq!(serialize_version(&v2, &cfg), "1.3.0");

Python

pip install bump-rs

from bump_rs import bump_version
print(bump_version("1.2.3", "major"))  # "2.0.0" in ~57µs

Node.js

npm install bump2version

const { bumpVersion } = require("bump2version");
console.log(bumpVersion("1.2.3", "patch")); // "1.2.4"

🚀 What Comes After 1,000,000×

Look, at some point the law of diminishing returns kicks in. We cannot make version bumping faster than the speed of light. (We checked. We asked the Mossad agents. They checked their slides. The answer was no.)

But there are things we can still do:

Pre-release cycling: proper alpha.1 → alpha.2 → beta.1 → rc.1 → stable lifecycle, first-class
Workspace-aware bumping: atomic multi-crate Cargo workspace updates, all in one commit
More detect targets: .NET (*.csproj), PHP (composer.json), Swift (Package.swift), Elixir (mix.exs)
Browser version history: the Yew app keeps a local bump history so you can see what you broke and when

If you want any of these sooner: open an issue. Or just star the repo and the moral pressure will accelerate delivery. It works on me. I've tested this empirically.

💬 Closing Thoughts

bump2version 0.2.1 started as a performance exercise and became an ecosystem. What was a single binary is now:

A Rust library with no_std support for the core
A Python package (bump-rs) for Pythonistas who want the speed without the syntax
A Node.js native add-on for JavaScript developers who want to feel like they're using Rust
A CLI with three binary names: bump, cargo-bump, bump2version
A WASM browser app built in Yew, because someone had to
7 language examples covering Rust, Python, Node.js, Go, Java, Ruby, and poly-repo workflows
20 integration tests that test the actual binary, not a mock
An auto-updatable .bumpversion.toml that tracks all version strings across the entire project

cargo install bump2version --features rust-binary → bump → ship → repeat → be 1,000,000× faster than Python → sleep → repeat 🦀

wiseaidev / bump2version

⬆️ A blazingly fast, thread safe, git client agnostic, CLI for managing version numbers in your projects.

⬆️ Bump2version

bump2version is the world's fastest version bumper written entirely in 100% safe Rust, with no_std support, native Python and Node.js bindings, and a cargo bump subcommand 🗿.

🚀 Installation

Platform	Command
Rust binary	`cargo install bump2version --features rust-binary`
Cargo subcommand	`cargo bump --help`
Docker	`docker pull wiseaidev/bump2version`
Debian/Ubuntu	Download `.deb` from GitHub Releases
RHEL/Fedora	Download `.rpm` from GitHub Releases
Windows	Download `bump.exe` from GitHub Releases
GitHub Action	See action.yml
Python	`pip install bump-rs`
Node.js	`npm install bump2version`

Note

Installing via cargo installs both bump and bump2version binaries. The original bump2version binary is retained indefinitely for backward compatibility with existing tutorials, CI/CD pipelines, and automation scripts.

🤔 What does this crate provide?

bump2version automates semantic version management for any project regardless of language. It:

Parses version strings using a fully configurable regex (default: semver major.minor.patch).
Bumps any named component (major, minor, patch, or…

View on GitHub

Star the repo. Try the Python bindings. Use the Node.js package. Read the Rust docs. Poke the WASM demo. Run the examples.

This has been a public service announcement from a developer who, in the course of a single engineering session, created 20 tests, 7 example projects, a WASM frontend, a Soviet-themed benchmark suite, and consumed an amount of Claude tokens that my accountant has asked me not to disclose.

The legal proceedings with Top Tech companies remain ongoing. My lawyer has read this post. He has asked me to note, for the record, that "abusing Claude" is a colloquial and affectionate term and not a legally actionable description of token consumption.

I have not taken that advice either.

Till next time: Keep bumpin', keep rustin', keep benchmarkin' 🦀⬆️

P.S. The Mossad agents have approved this post subject to the removal of the classified section about the branchless arithmetic lookup table. We kept it in. They know. They've said nothing. This is ominous.

I Built a Version Bump Tool in Rust That Is 10,000x Faster Than Its Python Counterparts.

Mahmoud 🦀 — Sun, 06 Sep 2026 05:01:14 +0000

Hello, fellow version-bumping enthusiasts, sleep-deprived Rustaceans, and accidental software archaeologists who just found out that bumpversion is a thing 👋!

So there I was, staring at my terminal at 2AM, trying to release version 0.1.0 of something. I typed bump-my-version patch, pressed Enter, and watched my CPU fan spin up like it was launching a SpaceX rocket. One Second later, one second, it bumped a number. One tiny number. 0.1.0 → 0.1.1.

I sat there in silence for a moment.

Then I did what any rational developer would do: I rewrote it. In Rust. From scratch. With Python and Node.js bindings. And a CLI. And no_std support. And gix for pure-Rust git operations.

The result? bump2version 0.2.0: a version bumper that is legitimately, measurably, embarrassingly ~10,000x faster than the Python CLI it replaces.

🤔 Wait, What Even Is `bump2version`?

Glad you asked. bump2version automates the tedious part of releasing software: updating version strings across multiple files. You know, the part where you manually grep through Cargo.toml, package.json, pyproject.toml, CHANGELOG.md, and your README, change 1.2.3 to 1.2.4 in 11 different places, forget one, push, CI fails, and you cry quietly into your coffee?

Yeah. That part.

bump2version does all of that for you:

Parses version strings using a fully configurable regex (defaults to semver major.minor.patch).
Bumps any component you ask it to: major, minor, patch, or custom cyclic stages like alpha → beta → stable.
Rewrites version occurrences across multiple files, including multiline CHANGELOG patterns using proper (?ms) DOTALL + MULTILINE semantics.
Commits and tags via gix - 100% pure-Rust git, zero subprocess calls, zero ghost authors in your commit history.

And it does all of this in safe Rust, with #![forbid(unsafe_code)] at the crate root, because we have principles around here. Or at least we pretend to.

# .bumpversion.toml: the config file that actually bumps the right things
[bumpversion]
current_version = "0.2.0"
commit = true
tag = true

[bumpversion:file:Cargo.toml]
search  = 'version = "{current_version}"'
replace = 'version = "{new_version}"'

[bumpversion:file:CHANGELOG.md]
search  = "## {current_version}\n    Release notes line 1"
replace = "## {new_version}\n    Release notes line 1"

One config file. Multiple files updated. One git commit. One tag. Done.

🦀 Rust, Python, and Node.js: A Love Triangle

Here's the fun part: bump2version isn't just a Rust crate. It's three tools pretending to be one in a trench coat.

As a Rust crate:

[dependencies]
bump2version = "0.2.0"

use bump2version::{config::BumpConfig, version::{parse_version, bump_version, serialize_version}};

fn main() {
    let cfg = BumpConfig::default();
    let v   = parse_version("1.2.3", &cfg).unwrap();
    let v2  = bump_version(&v, "patch", &cfg).unwrap();
    println!("{}", serialize_version(&v2, &cfg)); // 1.2.4
}

As a Python package:

pip install bump-rs

from bump_rs import bump_version, BumpConfig

print(bump_version("1.2.3", "patch"))  # "1.2.4"
print(bump_version("1.2.3", "minor"))  # "1.3.0"
print(bump_version("1.2.3", "major"))  # "2.0.0"

As a Node.js add-on:

npm install bump2version

const { bumpVersion, applyFileChange } = require("bump2version");

console.log(bumpVersion("1.2.3", "patch")); // '1.2.4'
console.log(bumpVersion("1.2.3", "minor")); // '1.3.0'

One Rust core. Three ecosystems. Zero Python subprocesses. Ferris the crab is now a polyglot, and honestly? Good for them. 🦀

🕵️ The Mossad Agents Who Architected This

Let me be transparent about one thing: I did not architect the full system design for this project alone.

No, I had help. Specifically, I reached out to some very professional consultants.

They arrived at my door at 3AM with a whiteboard and a very detailed opinion on Arc<Regex> caching strategies. Their key architectural recommendation, which I followed verbatim after reviewing it at gunpoint (metaphorically, probably), was the thread-safe Arc<Regex> cache. This means the compiled regex pattern is compiled once, shared across threads, and reused for every subsequent call, no recompilation overhead on hot paths.

The result: version bumping in ~57 microseconds from Python land. Not 57 milliseconds. Not 57 seconds. 57 microseconds. The kind of number that makes you wonder what the Python version was doing during its 585 millisecond run.

🔥 The Numbers That Made Me Cackle Maniacally

Okay. Let's talk benchmarks. Because this is the part of the blog post where I get to paste a table and feel deeply smug about it.

These are real numbers, measured on x86-64 Linux (CPython 3.12, 3-sigma filtered timeit):

Version Bumping: Full Round-Trip (Parse + Bump + Serialize)

Library	`patch`	`minor`	`major`
bump-rs (Rust, `Arc<Regex>` cache)	~57 µs	~54 µs	~53 µs
`bump-my-version` (Python library)	~79 µs	~95 µs	~72 µs
Pure Python (`re.compile` + `int()`)	~3.6 µs	~2.2 µs	~2.2 µs
`bump-my-version` CLI (subprocess)	~585 ms	~585 ms	~585 ms

The headline result: bump-rs is ~10,000× faster than the bump-my-version CLI.

Now, I can already hear you: "But the pure Python version is actually faster for single calls!"

Yes. You're right. The ~50 µs PyO3 FFI overhead means that if you're bumping exactly one version string in isolation on a warm Python interpreter, pure re.compile + int() will smoke us.

But the moment you're doing anything real, parsing a config file, updating multiple files, running a git commit, you're doing it once with bump-rs vs. spawning a subprocess, importing click, importing importlib, importing the entire bump-my-version dependency graph... and waiting 585 milliseconds.

Every. Single. Time.

File Search/Replace

Library	Single-line	Multiline CHANGELOG
bump-rs (Rust, cached)	~65 µs	~104 µs
Pure Python `re.sub`	~1.7 µs	~1.3 µs

For file I/O work, thread safety, and pipeline operations, bump-rs wins. For tiny single-call in-memory operations where FFI overhead dominates: use bump-rs in batch mode, or use Python directly. We believe in honesty here.

🤖 Abusing Claude to Achieve the 10,000x Speed-Up

Here's a confession. A deeply personal one. One that my legal team has strongly advised me not to make public.

I abused Claude.

Not in the normal way where you ask it to generate boilerplate. No no no. I pushed it to its absolute limits. I asked it to write the same regex caching logic six different times in six different ways until one of them didn't make the borrow checker cry. I had it architecting FFI boundary semantics at 4AM. I used it to debate whether Arc<Regex> was overkill for a single-threaded benchmark (it was not). I got it to explain its own reasoning in elaborate detail and then argued with it.

Anthropic noticed.

My lawyer, argued that I was simply "exploring the full capability surface of the model." The judge was unmoved. The Anthropic lawyers were also unmoved, but in a different direction.

The verdict is still pending. The Arc<Regex> cache, however, is production-ready.

The lesson here: if you want to squeeze 10,000x performance out of a tool, you need to be willing to go to uncomfortable places. Dark places. Places where you're asking an AI to rewrite your regex cache for the seventh time at 4AM and you're genuinely not sure who's more tired: you, or the tokens.

Turns out: the tokens don't get tired. That's why Rust wins.

🐴 And Then the Borrow Checker Got Stuck

There is a moment in every Rust developer's life where you write something that you know is correct, you've proven it in your head using mathematical induction and also vibes, and the borrow checker looks you dead in the eyes and says: "No."

No explanation. No suggestion. Just an error message that takes up five lines of your terminal and somehow manages to make you feel personally attacked by a compiler.

That happened. Multiple times. Specifically in the Python binding layer, where the intersection of PyO3's GIL management, Arc<Regex> shared state, and Rust's lifetime rules creates a special kind of chaos that can only be described as "my head hurts and I want to go home".

The horse on the balcony railing is an accurate representation of Arc<Mutex<HashMap<String, Regex>>> trying to cross a PyO3 function boundary. It got there. It works. But the stuck moment before it worked? That was real.

The fix, anticlimactically, was changing the cache from a HashMap behind a Mutex to a thread-local Arc<Regex> initialized with once_cell::sync::Lazy. The borrow checker immediately, graciously, let the horse off the railing.

There's a metaphor in there somewhere. I choose not to examine it too closely.

🛠️ Getting Started

Let's get practical. Here's how to use bump2version in your project right now:

CLI Usage

cargo install bump2version --features rust-binary

bump2version --bump patch   # 0.2.0 → 0.2.1
bump2version --bump minor   # 0.2.0 → 0.3.0
bump2version --bump major   # 0.2.0 → 1.0.0

Useful flags:

Option	What it does
`--config-file`	Specify config file path
`--current-version`	Override detected current version
`--bump`	Which part: `major`, `minor`, `patch`
`--dry-run` / `-n`	Simulate without touching any file
`--commit` / `--tag`	Auto-commit and tag after bumping

Python

pip install bump-rs

from bump_rs import bump_version, apply_file_change, BumpConfig

# Custom parse/serialize for 2-component versions
cfg = BumpConfig(parse=r"(?P<major>\d+)\.(?P<minor>\d+)", serialize="{major}.{minor}")
print(bump_version("2.0", "minor", config=cfg))  # "2.1"

Node.js

npm install bump2version

import { bumpVersion, applyFileChange } from "bump2version";

const next = bumpVersion("1.2.3", "minor"); // "1.3.0"

`no_std` Embedding

bump2version = { version = "0.2.0", default-features = false }

The core modules (config, version, files, error) compile on no_std + alloc. Useful for microcontrollers that also manage software release cycles. You know. If that's your situation.

🔒 The Safety Contract

bump2version enforces #![forbid(unsafe_code)] at the crate root. Every byte of the implementation, config parsing, regex matching, version bumping, git object creation, is written in safe Rust. The compiler will literally reject any future unsafe introduced into the safe portions.

The only unsafe in the entire codebase is in the Node.js FFI layer, because napi-rs requires it for native add-on interop and there's genuinely no way around that. If we could have avoided it, we would have. We tried. The borrow checker nodded approvingly at our effort, then still said no.

🔭 What's Coming in Future Releases

bump2version 0.2.0 is out the door, but the roadmap is full:

Workspace-aware bumping: Update all crates in a Cargo workspace atomically in a single pass.
Pre-release cycling: Better first-class support for alpha → beta → rc → stable lifecycle.
Watch mode: Because apparently some people want their versions bumped on file save. (I won't judge. I want to judge, but I won't.)
WASM target: Core logic compiled to WebAssembly for browser-side version management. Yes, this is probably overkill. Yes, we're doing it anyway.
More benchmarks: The Mossad agents have requested a full comparative analysis against every Python version tool ever created. We've filed the paperwork.

💬 Final Thoughts

Look. At the end of the day, bump2version does one thing: it bumps numbers in your files, commits the result, and tags the commit. That's it. That's the whole feature set.

But it does it in safe Rust. With Python bindings so Pythonistas don't have to care. With Node.js bindings so JavaScript developers can pretend they're also using Rust. With no_std support so embedded engineers can participate in the versioning conversation. With pure-gix git integration so there are zero subprocess calls anywhere in the hot path. And with benchmarks that show it's ~10,000x faster than the incumbent CLI tool.

Is that overkill for bumping a number? Absolutely. Are we sorry? Not even slightly.

cargo install bump2version --features rust-binary → bump → ship → repeat 🦀

Star the repo, try the Python bindings, install the npm package, or just read the docs. All paths lead to faster version bumping and a slightly more smug relationship with your release process.

wiseaidev / bump2version

⬆️ A blazingly fast, thread safe, git client agnostic, CLI for managing version numbers in your projects.

⬆️ Bump2version

bump2version is the world's fastest version bumper written entirely in 100% safe Rust, with no_std support, native Python and Node.js bindings, and a cargo bump subcommand 🗿.

🚀 Installation

Platform	Command
Rust binary	`cargo install bump2version --features rust-binary`
Cargo subcommand	`cargo bump --help`
Docker	`docker pull wiseaidev/bump2version`
Debian/Ubuntu	Download `.deb` from GitHub Releases
RHEL/Fedora	Download `.rpm` from GitHub Releases
Windows	Download `bump.exe` from GitHub Releases
GitHub Action	See action.yml
Python	`pip install bump-rs`
Node.js	`npm install bump2version`

Note

🤔 What does this crate provide?

bump2version automates semantic version management for any project regardless of language. It:

Parses version strings using a fully configurable regex (default: semver major.minor.patch).
Bumps any named component (major, minor, patch, or…

View on GitHub

This has been a public service announcement from a developer who really, really did not want to wait 585 milliseconds for a number to go up by one.

Till next time: Keep bumpin', keep rustin' 🦀⬆️

P.S. The legal proceedings with Anthropic are ongoing. My lawyer has advised me to stop mentioning it. I have not taken that advice.

🏳️‍🌈 Pride RS 0.1.0: Dropping the T from LGBTQ+ & Mark It as Haram.

Mahmoud 🦀 — Sat, 29 Aug 2026 07:37:59 +0000

Welcome back 👋, brave soul!

So, version 0.0.2 of Pride RS barely had time to dry before the community showed up in the Discord with... opinions. Big ones. Ferris the crab 🦀 got some letters. The Open SASS council convened. Arguments were had. And after a very long, very heated, very productive engineering debate (mostly in memes), Pride RS 0.1.0 is here.

The headline? We're dropping the T from LGBTQ+, and shipping it as a Cargo feature gate called haram.

Before you type in that issue, yes, you can still opt-in. It's Rust. Everything is opt-in. That's kind of the whole point. 😌

🧠 What Even Is `haram`?

In Arabic, haram (حرام) means "forbidden". In Pride RS, it means: "these flag types are guarded behind a feature gate and won't compile unless you explicitly ask for them."

Specifically, the following four flag types are now gated:

Type	What it represents
`Transgender`	Gender transition
`NonBinary`	Non-binary gender identity
`Genderfluid`	Fluid gender identity
`Agender`	Absence of gender identity

These four have one thing in common: they're all about changing or rejecting biological gender, which, in the Ferris cosmos, is debatably haram. The crab has spoken. Or at least, the Cargo feature flag has.

The other eleven types, Rainbow, Bisexual, Lesbian, Pansexual, Asexual, Aromantic, Demisexual, Polysexual, Omnisexual, Demiromantic, Graysexual, remain fully available with no feature flag required. Those are the halal ones. Rainbow stays. Obviously. Ferris loves rainbows.

⚙️ Under the Hood

You'd think adding a Cargo feature gate is simple. You'd be wrong. Here's why:

phf, our compile-time perfect hash map, does not support #[cfg(...)] inside a single phf_map! invocation. You can't do this:

pub static FLAG_CONFIGURATIONS: phf::Map<&'static str, FlagConfig> = phf_map! {
    "Rainbow" => FlagConfig { ... },
    #[cfg(feature = "haram")]  // <-- NOPE. Compiler says no.
    "Transgender" => FlagConfig { ... },
};

So instead, we compile two entirely separate maps, gated by #[cfg] at the item level:

#[cfg(not(feature = "haram"))]
pub static FLAG_CONFIGURATIONS: phf::Map<&'static str, FlagConfig> = phf_map! {
    // 11 halal entries
};

#[cfg(feature = "haram")]
pub static FLAG_CONFIGURATIONS: phf::Map<&'static str, FlagConfig> = phf_map! {
    // 15 entries (all flags)
};

Two statics. Same name. Mutually exclusive. Zero runtime overhead. Perfectly legal Rust. Ferris approves. 🦀✅

🚩 The New `Type` Enum

Here's what Type looks like now, straight from the codebase:

pub enum Type {
    Rainbow,
    Bisexual,
    Lesbian,
    Pansexual,
    Asexual,
    Aromantic,
    Demisexual,
    Polysexual,
    Omnisexual,
    Demiromantic,
    Graysexual,

    #[cfg(feature = "haram")]
    Transgender,

    #[cfg(feature = "haram")]
    NonBinary,

    #[cfg(feature = "haram")]
    Genderfluid,

    #[cfg(feature = "haram")]
    Agender,
}

Without --features haram, the four guarded variants don't exist. At all. Not a dead code warning. Not a None. They literally do not compile into the binary. Zero bytes. Zero overhead. Four fewer existential crises in your type system.

🔍 The `is_haram()` Method

New in 0.1.0, we ship a runtime inspection method, available only when the haram feature is enabled (because, well, the variants don't even exist otherwise):

#[cfg(feature = "haram")]
pub fn is_haram(self) -> bool {
    matches!(
        self,
        Type::Transgender | Type::NonBinary | Type::Genderfluid | Type::Agender
    )
}

O(1). No heap. No drama. Just a match arm and a boolean.

assert!(Type::Transgender.is_haram());
assert!(!Type::Rainbow.is_haram());

Ferris the crab, checking IDs at the door like a bouncer in a tiny crab hat. 🦀🎩

🏷️ The `haram` Field on `FlagConfig`

We also added a haram: bool field to the FlagConfig struct itself, so that tooling, docs generators, and runtime inspectors can ask "hey, is this flag type on the haram list?" without needing #[cfg] gymnastics:

pub struct FlagConfig {
    pub colors: &'static [&'static str],
    pub direction: Direction,
    pub name: &'static str,
    pub description: &'static str,
    pub haram: bool,  // <-- new!
}

Rainbow? haram: false. Transgender (when enabled)? haram: true. Useful if you want to render a little ⚠️ badge or log a warning before someone deploys a fully featured pride flag to a government app in Riyadh.

🛠️ Using the `haram` Feature

Default (Halal) Edition

Nothing changes. Just use Pride RS as before:

[dependencies]
pride-rs = { version = "0.1.0", features = ["yew"] }

You get 11 flags. Go wild. Ferris blesses you.

Full Edition (The `haram` Opt-in)

Add the feature flag to unlock all 15 types:

[dependencies]
pride-rs = { version = "0.1.0", features = ["yew", "haram"] }

Now the full quartet is available:

use pride_rs::yew::FlagSection;
use pride_rs::Type;

<FlagSection
    id="questionable-choices"
    title="The Haram Four"
    flags={vec![
        Type::Transgender,
        Type::NonBinary,
        Type::Genderfluid,
        Type::Agender,
    ]}
/>

No judgment. Cargo features are additive. Ship what you need.

🧪 Tests: Now Cfg-Conditional

The test suite was updated to reflect the new reality:

#[test]
fn test_enum_iter_default() {
    let variants: Vec<Type> = Type::iter().collect();
    #[cfg(not(feature = "haram"))]
    assert_eq!(variants.len(), 11);
    #[cfg(feature = "haram")]
    assert_eq!(variants.len(), 15);
}

And a full haram_tests module:

#[cfg(feature = "haram")]
mod haram_tests {
    #[test]
    fn test_is_haram_true_for_transgender() {
        assert!(Type::Transgender.is_haram());
    }
    // ... and more
}

Run the halal suite:

cargo test

Run the full suite:

cargo test --features haram

📦 0.1.0 Changelog Summary

Change	Details
✨ New feature gate	`haram`, compile-time toggle for gender-identity flags
🚩 New `Type` variants gated	`Transgender`, `NonBinary`, `Genderfluid`, `Agender`
🔍 New method	`Type::is_haram()` (available with `haram` feature)
🏷️ New struct field	`FlagConfig::haram: bool`
📖 Docs	Full rustdoc on every public item with time/space complexity
🧪 Tests	Cfg-conditional variant counts, full `haram_tests` module
🔒 License	MIT license banner on all source files

💬 Final Thoughts

Look, we're not here to debate theology or gender theory. We're here to write fast, correct, zero-overhead Rust. And with 0.1.0, whether you want all 15 flags or just the 11 that Ferris's grandma would approve of, you get compile-time guarantees either way.

That's the Rust way. Strong types. Explicit opt-ins. No runtime surprises.

✅ Zero overhead when haram is off (variants don't exist in the binary)
✅ Full access when haram is on (explicit opt-in)
✅ is_haram() for runtime inspection
✅ FlagConfig::haram for tooling
✅ Ferris the crab, canonically confuzled 🦀❓

Compile it. Gate it. Ship it. Let the borrow checker sort it out 🏳️‍🌈🦀.

And as always, if you have thoughts, flags (the physical kind OR the code kind), or strong opinions about Cargo feature semantics, swing by our Discord. Ferris is there. He's a little confused but he's trying his best.

Till next time: Keep Rustin', stay halal. 🦀💚

Jesus Was Right. You Are God and Infinite.

Mahmoud 🦀 — Sun, 23 Aug 2026 05:05:41 +0000

Hey everyone 👋,

I wrote in Christianity Makes Perfect Sense! about how some truths are deeply unfashionable, and how the discomfort a truth produces is often the surest sign that it is worth sitting with. This post is in that spirit. I want to talk about something that I have been turning over in my head for a long time, something that Christianity itself, read carefully and without the institutional filters, actually supports with a startling degree of directness. The title gives it away so I will not pretend there is a mystery: Jesus was right, and among the many things he was right about is this one, which most church hierarchies have buried so thoroughly that most Christians have never encountered it. He was right that you are, in some profound and irreducible sense, divine. That you carry within you something that the tradition calls godlike, that you are not merely a creature made to bow down and wait, but a being made from the same substance that the Gospel of John calls the Word, the very creative principle through which all things were made. I know how that sounds. I know it reads either as arrogance or as heresy depending on who you are. I am going to spend the rest of this post making the case that it is neither, that it is actually the oldest and most straightforward reading of the text, and that the institutions which suppressed it did so not because it was false but because it was dangerously empowering.

I should say upfront that I am not a theologian and I have never claimed to be. I am someone who grew up with very complicated feelings about religion, as I described in Just Don't Pick Up the Brush, in a village where religion was wrapped tightly around community identity and it was very hard to separate what was actually in the text from what the local authorities decided the text meant. I read the Bible on my own, away from institutions, away from authority figures, and when I did that I kept finding things that shocked me. Not because they were dark or frightening, but because they were so much more generous, so much more expansive about what a human being is, than anything I had been taught. That gap between what the text actually says and what I was told the text says is what this post is about. And I do not think it is a gap produced by ignorance. I think it is a gap that has been maintained deliberately, because the idea that every single human being carries something divine is one of the most democratizing and most politically dangerous ideas in the history of human thought. Power does not survive the equal distribution of its own source, and if every person is in some sense divine, then no institution can claim a monopoly on God anymore.

I should also be honest about where I am coming from religiously, because I think it matters for how you receive what I am about to say. I was Muslim on paper. Born into it, raised inside it, surrounded by it. But paper does not mean anything to me anymore, and it never really did. As I wrote in Just Don't Pick Up the Brush, I spent a long time after that as agnostic, standing on that thin, uncomfortable line between belief and doubt, genuinely unsure whether anything was out there and deeply skeptical of every institution claiming to speak for it. That skepticism has not gone away. But something shifted, slowly and without ceremony, as I kept reading. Not reading theologians or apologists or anyone trying to sell me a system, but reading the actual words attributed to Jesus, the specific arguments he made, the things he said to people who were suffering, the things he said to people who were powerful, and the things he said about what a human being fundamentally is. I am not a Christian in the institutional sense. I do not belong to a church, I do not follow a creed, and I hold plenty of the same questions I always have. But I follow Jesus's teachings in the sense that matters to me: I think he was telling the truth, I think the truth he was telling is the most important truth I have encountered, and I think it has been buried under two thousand years of institutional management. This post is my attempt to dig it back up.

Let me also connect this to the broader thread running through several of my recent posts. In Life On Earth is 100% AI Generated Slop, I argued that the world is optimized for plausible appearances rather than ground truth, and that this applies as much to social institutions as to language models. Religious institutions are not exempt from this critique. They are, in many cases, the original appearance-optimization machines, producing outputs that look like truth, sound like authority, and smell like holiness, while often encoding the preferences of whoever held the pen. But the text is still there. The ground truth of the scriptural record, whatever you think of its origins, is still available to anyone who reads it, and what it says about human nature is not what most institutions have wanted you to hear. This post is my attempt to read it honestly, to take the most uncomfortable passages seriously, and to follow the logic wherever it leads.

The Verse

There is a moment in the Gospel of John, chapter ten, verses thirty-three through thirty-six, that I think is the most underappreciated exchange in the entire New Testament. The religious leaders have accused Jesus of blasphemy for saying "I and the Father are one", and his response is, to put it plainly, astonishing. He does not back down. He does not explain away the claim. Instead he turns to the Hebrew scriptures and asks his accusers a direct question. He quotes Psalm 82:6, which says, "I said, you are gods", and then he makes a logical argument so sharp that it has never been successfully refuted in two thousand years of theological commentary. He says, in effect: if your own scripture, which cannot be broken, calls human beings gods, on what grounds do you accuse me of blasphemy for saying I am the Son of God? That is not a dodge. That is a detonation of the entire premise of the accusation. He is saying that the concept of human beings having a divine nature is already in the text, is already Scripture, is already established, and that his claim is therefore not an invention or an overreach but a specific instance of a general principle.

The verse he quotes, Psalm 82:6, reads in its fuller form: "I said, 'You are gods, sons of the Most High, all of you;'" The Hebrew word translated as "gods" is elohim, the same word used for God throughout the Old Testament, including in Genesis 1:1, where it says "In the beginning, God (elohim) created the heavens and the earth". The psalm uses the same word, elohim, to address human beings. The standard institutional response to this has been to say that the psalm is speaking about judges or magistrates, people who had been given delegated authority to render divine justice, and that the word "gods" is therefore just a title of office rather than a statement about nature. That interpretation is not obviously wrong, but it is not obviously right either, and what matters for our purposes is that Jesus did not restrict it that way. He quoted the verse, said "the scripture cannot be broken", and then used the existence of human beings called elohim as the foundation of his own defense in John 10:34-36. He did not say "yes but that was only about judges". He treated it as a general statement about humanity, and he used it accordingly.

The scholar Michael Heiser, who spent his career studying the divine council worldview in ancient Near Eastern literature and the Hebrew Bible, has argued extensively that Psalm 82 is not simply about human judges (1). He argues that the psalm depicts a divine assembly, a council of beings who were given governing authority over the nations by the Most High God, and that the accusation against them is that they have failed in their responsibility to maintain justice. The phrase "you will die like men" in verse seven, which has often been used to prove the addressees are human, Heiser argues is actually a statement of judgment rather than a statement of nature; it is saying that these beings, as a consequence of their failure, will now be stripped of their divine status and die as mortals do. This scholarly debate is not resolved, and I am not pretending to resolve it here. But it does mean that the easy institutional dismissal of the verse, the one that says this is just about human judges and therefore has no broader implications, is not the settled consensus of biblical scholarship. It is one reading among several, and not necessarily the strongest one.

What I find most compelling about the John 10 passage is not any particular resolution of the Psalm 82 debate, but the fact that Jesus, in the most heated confrontation of his ministry, with his life literally on the line, chose to ground his defense in the assertion that scripture already teaches the divine nature of human beings. He did not say "you are misunderstanding me, I am not claiming to be divine". He said "you are inconsistent, because you already accept that human beings can be called gods, and my claim goes no further than that". Read that slowly. The defense of his own divinity was the observation that divinity is not as rare or as exclusive as his accusers assumed. That is the argument. That is the text. And if you believe the scripture cannot be broken, as Jesus explicitly said, then you have to reckon with what that argument implies about every human being.

What Genesis Said

The argument from John 10 would be interesting on its own, but it becomes overwhelming when you read it alongside what Genesis says about human origins. Genesis 1:26 reads, in the English Standard Version: "Then God said, 'Let us make man in our image, after our likeness.'" This verse has been discussed, disputed, and dissected for thousands of years, and I do not pretend that everything about it is clear. But a few things are not in dispute, and those few things are enough to make the point I want to make. The first thing that is not in dispute is that the word translated "image" is the Hebrew tselem, which is the word commonly used for a physical representation or statue of a deity in ancient Near Eastern contexts. When a king placed an image of himself in a distant province, that image was understood to carry the authority and presence of the king. It was not the king, but it participated in the king's identity in a functional and representational sense. When Genesis says that human beings are made in the tselem of God, it is doing something extraordinary: it is saying that every human being is a representation of divine presence in the physical world, in the same way that a royal statue represented a king's authority in an outlying territory.

The second thing that is not in dispute is the radicalness of applying this language to all human beings. In the ancient Near Eastern world from which Genesis emerged, the language of being made in the image of a god was reserved for kings. Kings were the image of the deity. Ordinary people were not. When Genesis 1:26 applies tselem to humanity without distinction, it is not describing existing norms. It is shattering them. It is making the universal claim that every person, regardless of birth, rank, or nationality, carries within themselves the functional representation of the divine. The scholar Phyllis Trible pointed out decades ago that this democratization of the divine image is one of the most politically subversive moves in ancient literature (2). It takes a concept that was used to justify royal power and extends it to everyone, which means it simultaneously undermines the exclusive claim of any ruler to divine status. If everyone is made in the image of God, then no king is more divine than the slave who built his palace.

The third thing worth noting is what follows immediately from the declaration that humans are made in God's image. Genesis 1:28 says that God gave humanity "dominion" over all living things, and that verb, the Hebrew radah, is used elsewhere in the Bible specifically for the exercise of royal authority. This is not a coincidence. The grammar of the passage is deliberate. Humanity is created in the image of the divine, and humanity is given the exercise of royal power. The two go together in the logic of the text, because an image of a king is expected to exercise that king's authority. The implication is not that humans should act like tyrants. It is that humans carry, by nature, by virtue of what they are, a form of authority that in the ancient world was associated exclusively with the divine. That is a staggering claim, and it is sitting there on the first page of the Bible, waiting for anyone who is willing to read it without the institutional filters that have been layered over it for two millennia.

I want to be careful here, because I think precision is important and I do not want to overstate the case in a way that is easy to dismiss. The text does not say that human beings are identical to God. It says that human beings are made in God's image, and those are not the same thing. An image of a king is not the king. But an image of a king participates in the king's identity, carries the king's authority, and cannot be understood in isolation from the king it represents. The theological tradition has often used this distinction to minimize what Genesis is saying, to reduce the imago Dei to a list of specific moral or rational capacities that humans have in common with God. But the ancient context of the language suggests something more functional and more relational than that. It suggests that humanity's very existence in the world is understood as a form of divine presence, that every person is, in the most literal sense the text supports, carrying God into the world just by being what they are. That is not a minor doctrinal detail. That is the foundational anthropology of the entire scriptural tradition, and we have spent centuries treating it like a footnote.

I also want to connect this back to Psalm 90:2, which is one of the key passages about God's infinity: "Before the mountains were brought forth, or ever you had formed the earth and the world, from everlasting to everlasting you are God". This verse establishes that God exists outside of time, that the divine nature is not bounded by birth or death, beginning or end, the way finite creatures are. The interesting question is what it means for beings made in the image of this infinite God to exist as finite creatures. The dominant tradition has said that the image is present but diminished, that humans participate in divine-likeness in a limited way while remaining fundamentally bounded. But the mystical traditions within Christianity, which I will come to shortly, have asked whether the limitation is intrinsic or whether it is something that can be dissolved through transformation, whether the finite image can, through some process of union with its infinite source, come to participate in the infinity it represents. That question is not answered by Genesis alone. But Genesis plants the seed of it, and the rest of the scriptural tradition spends a great deal of time watering it.

The Verse Paul Almost Let Slip

If the Genesis passage is the founding statement of human divinity and the John 10 passage is the moment when Jesus explicitly asserts it in an argument, then the passage I want to discuss next is the one that the institutional church has spent the most energy trying to contain. 2 Peter 1:4 says something so direct that it is genuinely startling when you read it without preconceptions: God's promises have been given to us so that through them we "may become partakers of the divine nature". The Greek word there is theias phuseos koinonoi, which translates with remarkable precision as "sharers in the divine nature". Not sharers in divine favor, not recipients of divine grace in a general sense, but partakers of the divine nature itself. The Greek word phusis is the word for nature in the ontological sense, the kind of nature that makes a thing what it is. And koinonoi means sharers or participants in a deep, structural sense, not observers or admirers from a distance.

The Eastern Orthodox tradition took this verse more seriously than any other major branch of Christianity, and it built an entire theology around it under the name theosis, which is usually translated as deification or divinization. The core idea of theosis is that the human being is called to participate in the life of God, not merely to obey God's commands or to be forgiven by God's grace, but to actually share in the divine nature in a way that transforms what a human being is. St. Athanasius of Alexandria, writing in the fourth century, summed it up in a sentence that theologians have been quoting ever since: "God became human so that humans might become gods". He did not mean that humans would become the Creator or replace the Trinity. He meant that the Incarnation opened a path for human nature to be so thoroughly infused with the divine life that the boundary between creature and Creator, while never eliminated, becomes permeable in a way that it was not before. That is a serious theological claim, and it was made by one of the most respected theologians in Christian history, not by a heretic or a mystic on the fringes.

The way that Orthodox theology has usually navigated this is through the distinction between God's essence and God's energies, developed most fully by Gregory Palamas in the fourteenth century. The essence of God, in Palamas's account, is entirely transcendent and unknowable, and humans never participate in that. But the energies of God, which are understood as the real and active divine life that permeates the world and makes contact with creation possible, are genuinely participable. Humans can be united with the divine energies in a way that transforms them, and this transformation is what deification means. The analogy Palamas and others used was the image of iron placed in a fire: the iron does not become fire in its nature, but it takes on all the properties of fire, the heat and the light and the consuming energy, through genuine contact. That is what theosis looks like in Orthodox theology, and that is one of the most rigorous and most ancient Christian attempts to take Second Peter 1:4 seriously rather than explaining it away (3).

I want to be honest about why this matters to me personally, and not just as a theological argument. I have spent years in situations that felt like there was no door, no way forward, no resource left, and in those situations the question of what a human being fundamentally is becomes more than academic. When everything external is stripped away, when the career is destroyed as I described in Technology Has Destroyed My Livelihood, when the future looks like a wall of nothing, the question of whether there is something inside that is not subject to the same entropy as everything outside becomes the only question that matters. I am not claiming that the answer gave me a magical solution or that reading a verse in Second Peter solved my problems. I am saying that the difference between believing you are a finite biological process that will eventually terminate and believing you carry something that is, in its origins, infinite and divine, is not a small psychological difference. It is the difference between a temporary accident and a being with permanent value, and that difference affects everything about how you relate to suffering, to failure, and to the possibility of continuing.

There is also a connection here to what I wrote in Be Aware of The Current UFOs Pandemic. Remember, We Are Alone, where I argued that if we really are alone in the universe, then the weight of consciousness falls entirely on us, and we had better take that weight seriously. The theology I am describing in this post takes that weight with maximum seriousness. It says that human beings are not accidents in an indifferent universe. They are, in the most literal reading of the scriptural text, images of the infinite, bearing within themselves something that is not bounded by time or space in the way that ordinary matter is. That does not resolve all of the scientific questions about consciousness and matter. But it is a framework that demands we take human beings seriously, that refuses to reduce them to mere information-processing systems, and that grounds human dignity in something more fundamental than utility. Given everything I have written about how the tech industry and the economic system treats human beings as consumable inputs rather than ends in themselves, a theology that says every person carries something infinite is not just comforting. It is a political demand.

The Kingdom and the Infinity

There is a passage in the Gospel of Luke, chapter seventeen, verses twenty and twenty-one, that is short enough to quote in full. The Pharisees ask Jesus when the kingdom of God is coming, and he answers in Luke 17:20-21: "The kingdom of God is not coming in ways that can be observed, nor will they say, 'Look, here it is!' or 'There!' For behold, the kingdom of God is in the midst of you". The translation is disputed, because the Greek can mean either "in the midst of you", meaning among you as a social reality, or "within you", meaning inside each person. Both are defensible translations, and both matter for what I want to say here. But the combination of both meanings is what I think the verse is actually pointing at: the kingdom of God is not a future external event that humans wait for passively. It is a state of reality that is already present, already available, already latent in the nature of the beings who are asking the question.

This verse has been the touchstone of the mystical tradition within Christianity for two thousand years. The medieval mystic Meister Eckhart, who was charged with heresy for saying it too directly, spent most of his life elaborating the same core insight: that the divine ground of the soul and the divine ground of God are the same ground, that there is a depth within the human being that is not separate from the depth within God, and that the spiritual life is not about traveling somewhere else but about going deeper into what is already there. Eckhart was not making this up. He was reading Luke 17:21, Genesis 1:26, Psalm 82:6, 2 Peter 1:4, and a dozen other passages, and he was following the logic of the text more consistently than the institutions around him wanted him to. His sermons, which are available to anyone who wants to read them today, contain some of the most ferociously honest theological thinking in the history of Christianity (4). The idea that the divine is not somewhere above you but at the core of what you already are is not a deviation from Christian teaching. It is one of its oldest and most persistent threads, showing up in different forms in Origen, in Augustine, in Maximus the Confessor, in Gregory of Nyssa, in Thomas Aquinas's doctrine of the soul's capax Dei, its capacity for God.

The connection to infinity is direct. If the kingdom of God is within you, and if God is, as Psalm 90:2 says, "from everlasting to everlasting", then what is within you is not bounded by time in the ordinary sense. This is not a claim about biological immortality or about the physical body surviving death. It is a claim about the nature of whatever it is within a person that participates in the divine. The Johannine writings make this point repeatedly. John 17:3 defines eternal life as knowing God, not as a future reward but as a present state of cognition and relationship. John 10:28 has Jesus saying that eternal life has already been given to those who follow him, in the present tense. 1 John 3:2 says "we are God's children now", again present tense, not a future condition but a current ontological status. The infinity the tradition ascribes to God is not, in the New Testament texts, understood as entirely absent from human experience. It is understood as present, available, and in some sense already constitutive of what a human being most deeply is.

I want to say something about what this means in practice, because I think the mystical tradition sometimes makes it sound so abstract that people cannot connect it to anything real in their lives. When I say you are infinite, I do not mean that you will live forever in a biological sense or that your current circumstances do not matter or that suffering is an illusion. I mean something more specific and more verifiable in experience: that the part of you that observes your circumstances, that witnesses your suffering, that thinks about your thinking, has a relationship to the specific conditions of your life that is not one of simple identity. Your circumstances are finite. Your losses are finite. Your failures are finite. But the capacity to be aware of all of those things, to witness them, to turn attention onto them, seems to have no natural limit. You can always go one level deeper. There is always another layer of awareness below awareness. And the tradition I am describing says that this recursive quality of consciousness, this fact that awareness seems to have no floor, is not a coincidence or a quirk of neuroscience. It is evidence that consciousness is participating in something that is, at its roots, not subject to the same limitations as the material world.

The philosopher David Chalmers called this the hard problem of consciousness: the question of why there is subjective experience at all, why there is something it is like to see red or to feel grief or to wonder about one's own existence (5). The hard problem is hard precisely because it resists the kind of explanation that works for everything else in science. You can explain how the brain processes information, how neurons fire, how patterns emerge from complexity. But you cannot explain, within the framework of purely physical description, why any of that physical activity is accompanied by experience. Why is there something it is like to be a brain, when there is presumably nothing it is like to be a thermostat or a wind tunnel, even though all three are complex physical systems processing information? That question, Chalmers argues, points to something about consciousness that is not fully captured by the physical description, and I think the scriptural tradition I have been describing is offering an answer that no amount of neuroscience has yet ruled out: that consciousness participates in a dimension of reality that is not fully exhausted by its physical substrate, that the awareness within you reaches beyond the boundaries of the body that hosts it, and that this reaching beyond is the seed of what the tradition calls the divine.

What John 17 Reveals

The most stunning theological statement in the entire New Testament, in my opinion, is not in Romans or in Corinthians or in Revelation. It is in John 17:20-23, where Jesus is praying and says the following: "I do not ask for these only, but also for those who will believe in me through their word, that they may all be one, just as you, Father, are in me, and I in you, that they also may be in us... The glory that you have given me I have given to them, that they may be one even as we are one, I in them and you in me, that they may become perfectly one". Read that one more time. He is asking that human beings become one with God and with each other in the same way that he is one with the Father. He is not asking for a looser version of that unity, a kind of distant relationship or a formal legal standing. He is asking that the same kind of unity that exists within the Trinity, the most fundamental theological category for the divine nature, be extended to encompass humanity. That is the most radical statement of human divine potential in the entire scriptural canon, and it comes from Jesus himself, in what Christian tradition has called his high priestly prayer.

The implications of this verse are enormous and have been carefully avoided by most institutional Christianity, because they are almost impossibly difficult to contain within a hierarchical religious structure. If human beings are expected to be one with God in the same way that the Son is one with the Father, then the distinction between the sacred and the profane, between the holy and the ordinary, between the clergy and the laity, becomes philosophically unstable. If every person carries within them the capacity for the same union with God that the tradition reserves for Christ, then every person has an immediate access to the divine that does not require church, priest, ritual, or institutional intermediary. That is a terrifying claim for any institution whose power depends on controlling access to the divine, and it explains why this verse, though it is sitting there in every Bible that has ever been printed, is almost never preached on in the terms I am using here. The institutions that control the interpretation of the text have a very strong incentive to read "that they may be one" as a call to institutional unity, to church membership, to doctrinal agreement, rather than what the grammar and the context actually say, which is that Jesus is asking for the same quality of union between humans and God that exists within God's own nature.

The theologian Karl Barth, who was certainly not a mystic or a theological liberal, wrote extensively about the idea that human nature has been taken up into the divine life through the Incarnation in a way that changes the baseline status of every human being (6). Barth's argument is that when the Son of God became human, the divine and the human were united in a single person in a way that permanently altered the relationship between divinity and humanity. It is not just Jesus who is transformed by the Incarnation. Because Jesus took on human nature, human nature itself was touched by the divine in a way it had not been before, and that touch is not confined to Christians or to believers or to any particular group. It extends to all of humanity, because what was taken up in the Incarnation was human nature as such, not the human nature of any particular subset of people. This is Barth's doctrine of universal Christology, and while he resisted drawing all the conclusions that his own logic seemed to license, the direction of his argument is unmistakable: the Incarnation makes a claim about what every human being is, not just about what Christians believe.

I have been building this case slowly and carefully, and I want to stop for a moment to say why, because I think clarity about the argument matters here. I am not saying that all humans are God in the sense that God traditionally means, the omnipotent, omniscient, uncaused first cause of everything. I am saying something more precise and more supportable: that the scriptural tradition, read without the institutional filters, consistently describes human beings as bearing something divine in their nature, that this something is not a metaphor or a moral analogy but a genuine ontological claim about what human beings are, and that the implications of this claim for how we treat human beings and how human beings think about themselves are so significant that they deserve to be taken seriously rather than domesticated into harmless Sunday morning sentiment. The church domesticated this claim because it was politically threatening. I think we should de-domesticate it, not to tear down any institution, but because the truth of it, whatever institutional inconvenience it causes, is the most important thing I know about being human.

The Infinite Is You

This is the section where I want to say the hardest thing, and where I want to be most careful, because I can already feel the objections taking shape on the other side of the screen. The hardest thing is this: the infinity you carry is not something you achieve. It is not the result of hard work, spiritual practice, moral correctness, or church attendance. It is not conditional on your behavior or your beliefs. It is not a reward for anything. It is constitutive of what you are at the most fundamental level, and it cannot be taken away from you by your circumstances, your failures, your doubts, or anyone else's judgment of you. The reason I want to say this is that the alternative, the version where your divine standing must be earned or maintained or certified by an institution, is not only bad theology but is actively harmful psychology, and I have watched it destroy people who deserved better.

The scriptural basis for this is actually quite strong. When Genesis 1:26 says that God made humans in the divine image, there is no condition attached. It does not say "God made those who follow the law in his image" or "God made the righteous in his image". It says God made man, humanity, in the divine image, as a statement of creation, not a statement of criteria. The imago Dei is not something you earn. It is something you are born with, by virtue of being human, and nothing you do removes it. The same is true of the John 17 prayer. Jesus is not praying that certain deserving humans will be brought into unity with God. He is praying for all those who will believe through the disciples' word, and the scope of that prayer, as the tradition has always understood, is universal. He is praying that the union with God that he embodies will be extended to all of humanity, because that is the logic of the Incarnation: if the divine took on human nature, then human nature itself has been elevated, and every human being in history is touched by that elevation whether they know it or not.

I want to connect this to something I talked about in An Empty Life Filled With Constant Suffering, where I described years of feeling like I was not enough, like the gap between where I was and where I wanted to be was evidence of some fundamental deficiency in me rather than evidence of the normal difficulty of navigating a high-entropy system while carrying heavy psychological weights. The framework I am describing in this post does something important to that feeling. It does not tell you that your circumstances are fine when they are not fine. It does not tell you to feel good about a bad situation. What it does is insert a stable foundation below the circumstances, a claim about what you are that is not touched by what is happening to you. No matter how badly the world has treated you, no matter how comprehensively the system has failed you, no matter how empty the current chapter of your life feels, you are still, in the ontological sense that Genesis and John 17 are pointing at, a bearer of something infinite. That is not a self-help mantra. It is a metaphysical claim with two thousand years of theological development behind it, and I think it is both true and urgently needed by people who have been convinced by their circumstances that they are nothing.

The researcher Brené Brown has done significant work on the distinction between what she calls "shame" and "guilt", and her distinction maps almost perfectly onto what I am talking about here (7). Guilt says: I did something bad. Shame says: I am bad. Guilt is specific and correctable. Shame is global and constitutive. What I am arguing in this post is that the scriptural tradition, properly read, offers the most radical possible antidote to shame: it says that what you are, at the most fundamental level, is made in the image of the infinite. Not what you have done, not what you have achieved, not what anyone thinks of you. What you are, in the deepest ontological sense, is an expression of something that is from everlasting to everlasting, as Psalm 90:2 says, something that was before the mountains were brought forth and will be after they pass away. That is not a claim about your performance. It is a claim about your nature. Performance can fail. Nature cannot. And if your nature is, at its root, a participation in the divine, then your failure to achieve any particular thing says nothing about your ultimate worth.

Let me also say something that I think needs to be said plainly and without hedging. The system that tells you that you are not enough, that your value is conditional on your productivity, your achievement, your compliance with its criteria, is a system that benefits from your belief in your own inadequacy. I wrote about this from the economic angle in As Engineers, LLMs should pay us for tokens usage, where I argued that the tech industry extracts value from human creativity and intelligence while making the humans feel lucky to be allowed to contribute. The same dynamic operates at the level of religious institutions, where the message that you are inherently insufficient and must rely on the institution's mediation to access the divine is a message that keeps people dependent and controllable. Jesus's actual message, the one that got him killed, was that the kingdom of God does not require an institutional intermediary, that it is already within you, that the divine is not something to be dispensed by a hierarchy but something to be recognized in the self and in every other human being. That message was dangerous in the first century and it remains dangerous now, because it renders the gatekeeping function of any institution philosophically null.

You Are Not Alone

I want to spend this final section on something that I think is the most personally difficult aspect of everything I have been arguing, which is what it means to carry something infinite within a finite, suffering life. Because I am not writing this from a comfortable position. I am writing this from a position where I have had to fight for everything I have and where many of those fights have produced very little, as I described across multiple previous posts. And I am painfully aware that telling someone who is suffering that they carry something divine can land as the most useless thing anyone has ever said to them, less than an empty platitude, because it does not change the material circumstances that are causing the suffering.

So I want to be honest about the limits of the argument. The infinity I am talking about does not solve your financial problems. It does not fix the job market. It does not undo the damage done by a childhood spent in poverty or by years of psychological trauma as I described in Just Don't Pick Up the Brush. It does not make bad systems good or make unjust institutions just. It does not even guarantee that you will feel infinite or divine or anything other than exhausted and beaten down. The human capacity for suffering is real, and the tradition I have been citing is deeply honest about this. Psalm 88, the only psalm in the entire collection that ends without comfort or hope, is in the scripture for a reason. Job's protest against undeserved suffering is in the scripture for a reason. The cry of dereliction from the cross, "My God, my God, why have you forsaken me", is in the scripture for a reason. The tradition does not pretend that carrying something divine makes life easy. It says that carrying something divine makes life significant, regardless of how easy it is.

What carrying something infinite does, in my experience, is change the relationship between your circumstances and your identity. Circumstances, even severe ones, are temporal. They have a beginning and they have an end. The worst suffering in my life has been terrible while it lasted, but it has not lasted forever, and the part of me that survived it was not the part that had good circumstances. It was the part that had, in some inarticulate way I am only now finding words for, a ground that the circumstances could not reach. I am not saying this to be inspiring. I am saying it because I think it is accurately descriptive of what the tradition calls the divine image within the human being, and what I recognize, looking back at the worst periods of my life, as the thing that did not break even when everything else did. Whether you call that the imago Dei or the divine spark or the soul or the witness consciousness or just the deep structural fact of your own awareness, it is a real feature of human experience, and the best theology I have encountered is the theology that points at it honestly rather than domesticating it into a set of rules.

I also want to connect this post back to what I said at the very beginning, about the political implications of taking the divine nature of every human being seriously. If every person carries something infinite, then every person's suffering matters infinitely. Every person's dignity is non-negotiable. Every person's potential is unbounded in principle, even if bounded in practice by circumstances. The systems that reduce people to their productivity, that treat human beings as machines for generating economic value, that extract creativity and intelligence and labor from workers while returning as little as possible, are not just economically unjust. They are theologically incoherent. They are treating beings who are, by the most careful reading of the most ancient and most central texts in Western civilization, made in the image of the infinite, as if they were disposable inputs into a production process. That is not simply a policy failure. It is a category error of the most fundamental kind, and the scripture I have been quoting in this post, the scripture that Jesus himself staked his defense on in the most critical moment of his life, is the clearest possible statement of why that category error matters.

I do not know if any of this will change anything for anyone reading it. I know that my own ability to keep going, through years that felt like walking through concrete, has depended in some significant and inarticulate way on a belief I could not always justify philosophically but could not entirely abandon either: that there is something in every human being, including the worst versions of me, that is worth taking seriously, that is not reducible to a temporary performance or a set of circumstances, that is, in the language of the tradition I have been reading more carefully as I get older, touched by something that was before the mountains were brought forth. Jesus was right about a lot of things. He was right about what the scripture says. He was right about the divine nature of human beings. He was right that this truth is not owned by any institution and cannot be kept from anyone. And he was right that it is, in the end, the most important thing a person can know about themselves.

Till next time 👋!

References

1. Heiser, M. S., The Divine Council in Late Canonical and Non-Canonical Second Temple Jewish Literature (doctoral dissertation, University of Wisconsin-Madison, 2004); see also his popular work The Unseen Realm: Recovering the Supernatural Worldview of the Bible, Lexham Press, Sep 1, 2015, ISBN 978-1577995562

2. Trible, P., God and the Rhetoric of Sexuality, Fortress Press, 1978; see especially Chapter 1 on Genesis 1 and the democratization of the imago Dei. For a recent scholarly synthesis see also Middleton, J. R., The Liberating Image: The Imago Dei in Genesis 1, Brazos Press, 2005, ISBN 978-1587431104

3. Palamas, G., The Triads, translated by John Meyendorff, Paulist Press, 1983. For an accessible modern treatment of theosis in Orthodox theology, see Christensen, M. J. & Wittung, J. A. (Eds.), Partakers of the Divine Nature: The History and Development of Deification in the Christian Traditions, Baker Academic, 2007, ISBN 978-0801034404

4. Eckhart, M., The Complete Mystical Works of Meister Eckhart, translated by Maurice O'C. Walshe, Crossroad Publishing, 2009; for the scholarly debate over Eckhart's orthodoxy see McGinn, B., The Mystical Thought of Meister Eckhart: The Man from Whom God Hid Nothing, Crossroad Publishing, 2001, ISBN 978-0824519148

5. Chalmers, D. J., Facing Up to the Problem of Consciousness, Journal of Consciousness Studies, 1995;2(3):200-219. Available at https://consc.net/papers/facing.html. See also his landmark book The Conscious Mind: In Search of a Fundamental Theory, Oxford University Press, 1996, ISBN 978-0195117899

6. Barth, K., Church Dogmatics, vol. III/2, The Doctrine of Creation: The Creature, T&T Clark, 1960, §43-45. For an accessible overview of Barth's anthropology see Busch, E., The Great Passion: An Introduction to Karl Barth's Theology, trans. Geoffrey W. Bromiley, Eerdmans, 2004, ISBN 978-0802803603

7. Brown, B., I Thought It Was Just Me (But It Isn't): Making the Journey from "What Will People Think?" to "I Am Enough", Gotham Books, 2007; see also her academic work: Brown, B., Shame Resilience Theory: A Grounded Theory Study on Women and Shame, Families in Society: The Journal of Contemporary Social Services, 2006;87(1):43-52

DEV Community: Mahmoud 🦀

🔐 OTP RS: RFC-Compliant OTP Input Components for WASM Frameworks

What Even Is OTP RS?

Component Architecture

The Invisible Input Trick

The Invisible Input That Wasn't Actually Invisible

The Compiler Is Your Enemy (And Also Your Best Friend)

Episode 1: Hook in a Macro

Episode 2: Box::leak and the &'static str Obligation

Episode 3: The as Cast That Broke Leptos

Episode 4: String vs &str in Dioxus rsx!

Episode 5: The Inter-Group Focus Traversal Collision

Episode 6: The "Sticky" Backspace (vDOM vs Physical DOM)

Keyboard Navigation

HOTP and TOTP Validation

Quick Setup

Final Thoughts

opensass / otprs

🔐 A highly customizable OTP component for WASM frameworks (Powered by Input RS).

🔐 OTP RS

🎬 Demo

📜 Intro

🤔 Why OTP RS?

📋 Form RS: Production-Ready Form Components for WASM Frameworks

What Is Form RS?

The Seven Components

Form

Control

Label

Helper

Group

ControlLabel

Field

Validation Architecture

Native HTML5 Validation

External/ARIA Validation

Accessibility Built In

The ValidationState Pattern

Variant, Color, and Size System

Quick Setup

Final Thoughts

opensass / form-rs

📋 A highly customizable Form component for WASM frameworks (Powered by Input RS).

📋 Form RS

🎬 Demo

📜 Intro

🤔 Why Form RS?

Y Yew Usage

🖥️ Code RS: CDN-Free Syntax-Highlighted Code Components for WASM

What Is Code RS?

The Big Idea

Components

Code

Block

8 Themes

The Build Journey

Chapter 1: The Rust 2024 Edition

Chapter 2: Dioxus RSX

Chapter 3: The dangerous_inner_html

Chapter 4: Non-Exhaustive Variant::Custom

Accessibility

Quick Setup

Final Thoughts

opensass / coders

💻 A highly customizable code component for WASM frameworks.

💻 Code RS

🎬 Demo

📜 Intro

🤔 Why Code RS?

Y Yew Usage

🧬 Dioxus Usage

🌱

🃏 Card RS: Extremely Customizable Card component for WASM frameworks

What Is Card RS?

The Composable Anatomy

The Shell: Card

The Skeleton: Headers, Content, & Footers

Variants and Prominence

Framework Parity

Accessibility Built-In

Episode 2: `Box::leak` and the `&'static str` Obligation

Episode 3: The `as` Cast That Broke Leptos

Episode 4: `String` vs `&str` in Dioxus `rsx!`

`Form`

`Control`

`Label`

`Helper`

`Group`

`ControlLabel`

`Field`

The `ValidationState` Pattern

`Code`

`Block`

Chapter 3: The `dangerous_inner_html`

Chapter 4: Non-Exhaustive `Variant::Custom`

The Shell: `Card`

`Anchor`

`Badge`

`BadgeLabel`

`Avatar`

`Fallback`

`Group`

The `overflow_count` Context

`no_std`: Ferris Goes Embedded