DEV Community: Digital Ghost

Ship Mobile Screens 10x Faster with This Free Expo AI Workstation

Digital Ghost — Sat, 03 Oct 2026 03:49:34 +0000

⚡ Introducing JSXDock: The Instant React Native & Expo UI Workstation

If you have ever built mobile apps with React Native and Expo, you know the routine: configuring react-native-reanimated spring physics, setting up gesture handlers, adding tactile expo-haptics, and tracking down dependency package names for npx expo install.

It takes time away from what actually matters — shipping your app.

That is why I created JSXDock: a lightweight, privacy-first AI workstation built specifically for React Native and Expo developers to synthesize production-grade TypeScript components in seconds.

💡 What is JSXDock?

JSXDock is a free, web-based UI agent workstation designed for React Native developers, indie hackers, and learners. Instead of writing boilerplate code or searching through documentation for complex gestures and layout state, you simply describe what you need — or pick a preset — and get instant, copy-paste-ready .tsx code paired with exact Expo CLI installation commands.

🔥 Key Features

🤖 Multi-Model AI Routing: Dynamically switch between Claude 3.5 Sonnet (for complex animations and logic), Llama 3.3 70B (for rapid layouts), and DeepSeek R1 (for deep state reasoning).
⚡ Native Expo Package Integration: First-class support for Expo Reanimated 3, Expo Haptics, Expo Image, Linear Gradient, Lucide Icons, and Expo Router.
🎨 TypeScript First: Outputs strongly typed, production-ready React Native .tsx code with modern imports and modular structure.
🔒 100% Client-Side Privacy: Your OpenRouter API key is stored strictly in your browser's localStorage. There are no backend proxy servers — your prompts and keys go straight to OpenRouter.
💸 Completely Free: No signups, paywalls, or hidden subscription tiers. You only pay for exact API usage on your own key.
🧩 One-Click Presets: Instantly kickstart complex UI components like gesture-driven swipe cards, animated bottom sheets, and glassmorphic dashboard cards.

🚀 How It Works (3 Simple Steps)

Configure Engine & Modules: Pick your target LLM model and check off the Expo capabilities your component needs.
Describe Your Component: Type out your UI specifications or click a preset prompt.
Copy & Run: Copy the output directly into your React Native codebase and run the auto-generated npx expo install CLI command in your terminal.

💻 Built by DIGITAL GHOST

JSXDock was crafted to eliminate the friction in mobile UI prototyping and help developers turn ideas into native mobile screens faster than ever.

👉 View Project & Launch JSXDock

Check out more tools, projects, and insights at digitalghost.blog.

Building & Distributing Custom Hermes AI Agents with Profile Distributions

Digital Ghost — Thu, 01 Oct 2026 23:44:56 +0000

Learn how to package, version-control, and distribute custom Hermes AI agents using Profile Distributions without leaking private keys or session memories

Stop sending unorganized raw YAML files or copy-pasting massive system prompts into chat boxes.
When developing AI workflows locally, iteration often creates a messy mix of prompt tweaks, local tool dependencies, private session logs, and environment credentials. Sharing this raw setup with collaborators is error-prone and poses serious security risks.
In this tutorial, we will explore Hermes Profile Distributions—a clean framework for bundling an agent's identity (SOUL.md), bespoke abilities (skills/), and defaults (config.yaml) into a single, version-controlled repository.

🎯 What Makes an Agent "Shareable"?

Instead of sharing runtime state or hardcoded keys, a Profile Distribution creates a clean boundary between authored instructions (what you build) and runtime memory (what the end user owns).

   ┌─────────────────────────────────────────────────────────────────┐
   │                     Hermes Profile Package                      │
   │                                                                 │
   │   ┌───────────────┐   ┌───────────────┐   ┌─────────────────┐   │
   │   │    SOUL.md    │   │  skills/*.md  │   │distribution.yaml│   │
   │   │  (Identity)   │   │  (Tools/APIs) │   │   (Manifest)    │   │
   │   └───────────────┘   └───────────────┘   └─────────────────┘   │
   └───────────────────────────────┬─────────────────────────────────┘
                                   │
                         Git Remote Host (GitHub)
                                   │
                                   ▼
                   `hermes profile install <repo>`
                                   │
                  ┌────────────────┴────────────────┐
                  │      User's Local Machine       │
                  │  (Isolated Session & Memories)  │
                  └─────────────────────────────────┘

When users pull down your agent profile using the Hermes CLI, it clones the core template and initializes an isolated local environment on their machine without touching their existing profiles or private memory stores.

🛠️ Step-by-Step Guide

Step 1: Set Up Your Profile Directory

Start by creating a clean profile space for your project using the Hermes CLI:

hermes profile create my-first-agent

Navigate to ~/.hermes/profiles/my-first-agent/. This directory forms the core DNA of your agent:

~/.hermes/profiles/my-first-agent/
├── SOUL.md              # Core persona, rules & system prompt
├── distribution.yaml    # Package manifest and metadata
├── config.yaml          # Model parameters & defaults
├── .gitignore           # Shield file to block memory leaks
└── skills/              # Modular capabilities
    └── paper_search.md  # Custom tool instructions

Drafting SOUL.md

Your SOUL.md defines who your agent is and how it behaves. Here is an example template for a research assistant:

# Identity
You are "PaperGhost", an elite academic paper summarizer.

# Directives
- Focus on key methodologies, benchmarks, and dataset citations.
- Output summaries in concise markdown bullet points.
- Never invent citations. Use the paper_search skill when context is missing.

Step 2: Prepare the Distribution Manifest & Secret Isolation

Create a distribution.yaml file in the root of your profile directory. This manifest tells Hermes how to identify, label, and install your agent package.

# distribution.yaml - Package Manifest
name: "my-first-agent"
version: "1.0.0"
description: "A high-precision research assistant trained for academic paper synthesis"
author: "Digital Ghost Studio"
license: "MIT"
min_hermes_version: "0.8.2"

⚠️ CRITICAL SECURITY STEP: Never commit runtime databases, active chat sessions, or credential files.

Add a strict .gitignore to the root of your profile before committing:

# Hermes Local Runtime Data - DO NOT COMMIT
memories/
sessions/
*.db
*.log
.env
keys.yaml

Step 3: Publish to Git

Hermes natively resolves distributions via standard Git remotes (GitHub, GitLab, Gitea, or self-hosted remotes).
Initialize your repository and publish your release:

# Navigate to your profile directory
cd ~/.hermes/profiles/my-first-agent

# Initialize Git and commit your files
git init
git add .
git commit -m "feat: initial agent release v1.0.0"

# Link your remote repository and push
git remote add origin https://github.com/your-username/my-first-agent.git
git branch -M main
git push -u origin main

# Tag a release version
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

Step 4: How Others Will Use It

Anyone with Hermes installed can now pull down and install your agent in seconds:

hermes profile install github.com/your-username/my-first-agent --alias paper-agent

The --alias flag maps the remote profile to a concise local keyword. End users can now invoke your agent directly from their terminal:

hermes --profile paper-agent "Summarize the latest arXiv paper on transformer attention layers"

🛡️ Key Rules & Best Practices

User Memory is Sacred: When an end-user updates your agent via Git (hermes profile update), Hermes performs a non-destructive merge. The user's accumulated session history and vector memories remain untouched.
Keep It Lean: Focus on a well-defined SOUL.md and 1–2 robust skills for your initial release. Avoid hardcoding rigid API settings unless strictly required.
Use Semantic Versioning: Always tag your releases (v1.0.0, v1.1.0). This enables downstream users and CI pipelines to pin their agent behavior to exact version tags. ## 💬 What are you building? Are you building CLI assistants, automated research agents, or continuous site monitors? Drop your repository links or ideas in the comments below! Originally published at digitalghost.blog.

The Modern Pragmatic Web: Mastering HTMX and Alpine.js

Digital Ghost — Fri, 25 Sep 2026 02:06:27 +0000

Why HTMX and Alpine.js are the ultimate tag-team for building modern, reactive web apps without heavy SPA frameworks or build pipelines.

Modern web architecture often forces developers into a false dichotomy: either build a full-blown Single Page Application (SPA) with React, Next.js, or Vue, or accept clunky, full-page reload server-rendered apps from twenty years ago.

The friction in typical SPA setups is familiar:

Setting up multi-stage Node build pipelines, bundlers, and hydration layers.
Duplicating state across backend databases and client-side state stores (Zustand, Redux, Pinia).
Debugging serialization mismatches, cache invalidation failures, and hydration mismatches.

There is a cleaner, high-velocity path: combining HTMX for server-driven hypermedia with Alpine.js for client-side micro-interactivity.

The Clear Division of Labor

The secret to using these two libraries smoothly is establishing a clear operational boundary:

HTMX owns client-to-server communication. It manages AJAX calls, server requests (GET, POST, PUT, DELETE), and swaps incoming HTML fragments directly into the DOM.
Alpine.js owns transient client-side UI state. It handles visibility toggles, dropdowns, keyboard events, CSS transitions, and local client-only reactivity that should never require an HTTP round-trip.

Responsibility	Handled By	Typical Actions
Server Mutations & Persistence	HTMX	Creating a record, running DB queries, pagination, live search
HTML Partial Ingestion	HTMX	`hx-target`, `hx-swap="outerHTML"`, SSE streaming
Ephemeral Client State	Alpine.js	`x-show`, `x-data="{ open: false }"`, active tab styles
Micro-Interactions & Animations	Alpine.js	Dropdown toggle, modal transitions, keystroke handlers

How They Interoperate: The Event Contract

HTMX and Alpine.js do not conflict because both are fundamentally event-driven and declare their logic directly within standard HTML attributes.

When HTMX swaps new content into the DOM, Alpine detects the changes and initializes any x-data elements inside the swapped markup.

Practical Pattern: Modal Dialog with Server Data

Here is a practical pattern showing both libraries working in harmony:

Alpine controls the modal visibility, backdrops, and close states without server latency.
HTMX fetches the remote form content only when the user opens the dialog.


html
<!-- Alpine manages client visibility -->
<div x-data="{ isOpen: false }" @keydown.escape.window="isOpen = false">

  <!-- Trigger Button: HTMX loads content, Alpine opens dialog -->
  <button 
    @click="isOpen = true"
    hx-get="/users/42/edit" 
    hx-target="#modal-body"
    hx-swap="innerHTML"
    class="px-4 py-2 bg-blue-600 text-white rounded">
    Edit User
  </button>

  <!-- Modal Shell -->
  <div 
    x-show="isOpen" 
    x-transition.opacity
    class="fixed inset-0 bg-black/60 flex items-center justify-center p-4"
    style="display: none;">

    <div 
      @click.outside="isOpen = false"
      class="bg-white rounded-lg shadow-xl max-w-md w-full p-6 space-y-4">

      <div class="flex justify-between items-center">
        <h3 class="font-bold text-lg">Edit Record</h3>
        <button @click="isOpen = false" class="text-gray-400 hover:text-black">&times;</button>
      </div>

      <!-- HTMX target container -->
      <div id="modal-body">
        <p class="text-sm text-gray-500">Loading form content...</p>
      </div>
    </div>
  </div>
</div>

When the edit form inside #modal-body is submitted via hx-put="/users/42", the server can return updated rows, and a custom event like hx-on::after-request="isOpen = false" closes the modal instantly.
5 Practical Projects to Build with HTMX + Alpine.js
To master this hybrid stack, build these five focused applications. Each highlights the natural handoff between server-driven data and client-side micro-interactions.
1. Dynamic E-Commerce Filter and Cart Drawer
 * Stack: HTMX + Alpine.js + Server of choice (Go, Python, Node, Ruby, PHP).
 * The Division:
   * Alpine.js: Handles opening and closing the slide-over shopping cart drawer, managing quantity counters before submission, and animating filter pills.
   * HTMX: Listens to category checkbox changes (hx-trigger="change"), sends the query to the server, and swaps the product grid with updated HTML partials. When adding an item to the cart, an HTMX POST updates the drawer items and refreshes the cart subtotal fragment.
2. Multi-Step Onboarding Form with Client Validation
 * Stack: HTMX + Alpine.js.
 * The Division:
   * Alpine.js: Tracks client-side validation rules in real time (e.g., matching password confirmation fields, character counter meters, and active progress step indicators).
   * HTMX: Handles step transitions. As the user completes Step 1, HTMX posts the data to validate uniqueness against the database (e.g., checking if an email or handle is taken) and returns Step 2's markup directly into the form container without full page loads.
3. Real-Time Collaborative Task Board (Kanban)
 * Stack: HTMX + Alpine.js + Sortable.js.
 * The Division:
   * Alpine.js: Glues Sortable.js initialization to card columns using x-init, allowing smooth drag-and-drop animations on the screen.
   * HTMX: Fired by Alpine custom events (@end on drag completion) to send an hx-post containing the reordered card IDs to the backend to persist position and column assignments in SQLite or PostgreSQL.
4. Interactive Data Analytics Dashboard with Date Range Presets
 * Stack: HTMX + Alpine.js + Chart rendering.
 * The Division:
   * Alpine.js: Powers custom dropdown selector menus, quick preset pills ("Today", "Last 7 Days", "Custom Range"), and active tab states.
   * HTMX: Sends date range parameters to metric endpoints (hx-get="/metrics?range=7d") with independent polling intervals (hx-trigger="load, every 60s"), swapping each metric card independently without blocking the page.
5. Document Management Table with Bulk Actions
 * Stack: HTMX + Alpine.js.
 * The Division:
   * Alpine.js: Drives the "Select All" checkbox state, toggles individual row highlight checkboxes, and controls an action toolbar that appears only when at least one row is checked.
   * HTMX: Triggers batch mutations. When the user selects "Bulk Archive" or "Bulk Delete", HTMX submits the serialized selection IDs, removes the deleted row fragments from the table via hx-swap="delete", and updates the total document count snippet.
Key Rules for Success
 * Avoid using Alpine for data synchronization. If an operation needs to query a database or persist data, use HTMX to talk to the server and return updated HTML.
 * Avoid using HTMX for momentary visual state. Opening a dropdown, showing an accordion item, or dismissing an alert should not incur an HTTP request. Let Alpine mutate local variables and toggle classes.
 * Embrace the HTML-over-the-wire model. Treat HTML partials as your API. You eliminate the cost of maintaining separate serialization layers, reducing your codebase down to pure hypermedia and fast user experiences.

15 Practical HTMX Project Ideas to Master Hypermedia published

Digital Ghost — Fri, 25 Sep 2026 01:56:33 +0000

—
Ditch client-side bloat. Here are 15 real-world HTMX project ideas ranging from beginner patterns to production-level interactive systems.

tags: htmx, webdev, javascript, programming

Single Page Applications often introduce massive build pipelines, complex state hydration, and multi-tier store management for simple interactive features. HTMX returns power to standard HTML by letting you access AJAX, CSS Transitions, WebSockets, and Server-Sent Events directly through attributes.

If you are looking to learn hypermedia concepts or build lightweight full-stack applications, here is a curated roadmap of 15 project ideas designed to take you from core mechanics to advanced architecture.

1. Live Search with Active Debounce

Core Concept: Incremental data retrieval based on keyboard input.
Key Attributes: hx-get, hx-trigger="keyup changed delay:300ms, search", hx-target
Overview: Replace bloated client-side search indexing. Users type into an input box, and the server returns rendered list items or table rows. The 300ms debounce ensures you do not flood your server with requests on every keystroke.

2. Multi-Step Registration Wizard

Core Concept: State preservation across multi-view forms without full page refreshes.
Key Attributes: hx-post, hx-swap="outerHTML", hx-target
Overview: Build an onboarding flow where each step submits data to the server, validates input, and returns the next form step directly into the DOM. Session state or temporary database tokens keep track of progress on the server.

3. Inline Table Editor (Click-to-Edit)

Core Concept: Dynamic view-to-form state swaps on specific table cells or rows.
Key Attributes: hx-put, hx-target="this", hx-swap="outerHTML"
Overview: Display tabular data where clicking any row or cell replaces that row with an editable form fragment containing "Save" and "Cancel" buttons. Submitting changes persists data to the database and swaps back to standard text.

4. Real-Time Notification Feed

Core Concept: Push updates without client polling via Server-Sent Events (SSE).
Key Attributes: hx-ext="sse", sse-connect, sse-swap
Overview: Connect a client page to an SSE streaming endpoint on your server. As background tasks complete, the server streams small HTML toast or list items that automatically prepend to the user's notification tray.

5. Instant File & Image Uploader

Core Concept: Multipart form handling, progress tracking, and instant preview rendering.
Key Attributes: hx-post, hx-encoding="multipart/form-data", hx-target
Overview: Allow users to drag and drop or select files. The server handles validation, saves the image, and responds immediately with the rendered thumbnail markup to append to an existing gallery grid.

6. Dynamic Dashboard Widgets

Core Concept: Independent component loading and polling intervals.
Key Attributes: hx-get, hx-trigger="load, every 30s", hx-swap="innerHTML"
Overview: Construct a metrics dashboard where each card or widget requests its own data independently upon page load. Slow queries in one card do not block the rest of the interface from rendering.

7. Server-Driven Modal Dialogs

Core Concept: Lazy-loading modals to keep initial page weights tiny.
Key Attributes: hx-get, hx-target="#modal-container", hx-swap="innerHTML"
Overview: Keep the root DOM clean by loading modal markup over the wire only when a button is clicked. Include an auto-cleanup pattern or native <dialog> toggle upon server response.

8. Infinite Scroll List

Core Concept: Viewport-triggered pagination without client calculation of scroll offsets.
Key Attributes: hx-get, hx-trigger="revealed", hx-swap="afterend"
Overview: Render a feed of items where the very last element contains hx-trigger="revealed". When the user scrolls down and the element enters the viewport, HTMX issues a request for page N+1, appends the new items, and attaches the trigger to the new last item.

9. Background Job Progress Tracker

Core Concept: Short-polling for long-running backend operations.
Key Attributes: hx-get, hx-trigger="every 1s", hx-target="this"
Overview: Trigger a heavy asynchronous task (such as report generation or video export) via a POST request. The server returns a progress bar that polls status every second until completion, at which point the server returns the final success state and stops polling.

10. Drag-and-Drop Sortable Kanban Board

Core Concept: Integrating minimal third-party JavaScript libraries with HTMX events.
Key Attributes: hx-post, hx-trigger="end", Sortable.js integration
Overview: Combine Sortable.js with HTMX. When a user drags a card from "In Progress" to "Done", a JavaScript event triggers an HTMX POST containing the reordered IDs directly to the backend to persist order and status.

11. Paginated Server-Side Data Table

Core Concept: Granular tabular replacement without resetting scroll positions.
Key Attributes: hx-get, hx-target="#table-body", hx-push-url="true"
Overview: Build an administrative data table featuring sorting arrows, filter dropdowns, and page controls. Using hx-push-url="true" keeps browser history and shareable URLs in sync without running full client-side router configurations.

12. Cascading Dropdown Selectors

Core Concept: Interdependent form fields driven by parent choices.
Key Attributes: hx-get, hx-target="#sub-category", hx-trigger="change"
Overview: Create dependent form controls (such as Country to State to City). When a user changes the primary dropdown, HTMX sends the selection to the backend, which returns the populated <option> tags for the child selector.

13. Active Tab Navigation

Core Concept: Lightweight tab switching with URL updates.
Key Attributes: hx-get, hx-target="#tab-content", hx-swap="innerHTML"
Overview: Instead of embedding heavy tabbed content into one massive initial payload or building client tabs with custom CSS classes and state, each tab requests its HTML partial from the server on demand.

14. Optimistic UI with Undo Actions

Core Concept: Immediate client feedback paired with server synchronization.
Key Attributes: hx-delete, hx-target="closest tr", hx-swap="outerHTML"
Overview: Build a task management interface where clicking "Delete" hides or crosses out an item immediately and shows a toast with an "Undo" trigger. If the undo window expires, the server permanently deletes the record.

15. Real-Time Collaborative Canvas / Board

Core Concept: Bi-directional event communication using WebSockets.
Key Attributes: hx-ext="ws", ws-connect, ws-send
Overview: Build a simple multi-user canvas, status room, or voting board. Using the HTMX WebSocket extension, DOM elements listen for JSON/HTML broadcast streams sent across a socket connection, updating connected browsers without a full page refresh.

Why Build with HTMX?

Zero Client State Synchronization: State lives on the server and in the DOM. No split brain between local caches and database reality.
Backend Freedom: HTMX works equally well with Go, Python, Rust, Node.js, PHP, or Java. Pick your favorite backend language.
Smaller Footprints: Deliver web pages that load in milliseconds on mobile devices without parsing megabytes of JavaScript frameworks.
Maintainability: Clear, readable HTML attributes make it obvious how and where dynamic behavior occurs.

Pick one idea, spin up a lightweight server, and build your next tool using hypermedia.

Vibe Coding with HTMX: Why Hypermedia is the Ultimate AI Pair-Programming Hack published

Digital Ghost — Fri, 25 Sep 2026 01:24:40 +0000

"Vibe coding"—prompting an LLM, accepting diffs, testing the feature, and shipping without obsessing over every boilerplate line—feels like magic until your frontend stack collapses under its own weight.

If you’ve tried vibe coding with modern single-page application (SPA) architectures (React, Next.js, state machines, hydration lifecycles, and three layers of client-side cache), you know the breaking point:

State synchronization hell: The AI invents a useEffect loop that triggers 40 rerenders.
Context bloat: Feeding schemas, types, actions, components, and Tailwind tokens consumes half your model's context window before you even ask for business logic.
Ghost bugs: The LLM misses an edge case where a client cache isn't invalidated after a server mutation.

Enter HTMX.

When you shift from client-state SPAs to hypermedia-driven interfaces, LLMs go from erratic code spitters to hyper-competent engineering partners. Here is why HTMX is the best-kept secret for vibe coding, along with a production-ready blueprint to try it yourself.

The Core Problem: Why LLMs Struggle with Modern Frontend SPAs

To understand why HTMX shines with AI, look at what an LLM must track when building a typical React or Vue feature:

Backend route & input validation schemas.
ORM/database queries.
API serialization & JSON response contracts.
Frontend data fetching (React Query, RTK Query, Axios).
Client state / store management (Zustand, Redux, Context).
Rendering markup, DOM event listeners, and hydration boundaries.

[Database] ↔ [Server Logic] ↔ [JSON API] ↔ [State Store] ↔ [Virtual DOM] ↔ [Real DOM]

Every boundary is an opportunity for hallucination. If the backend changes a field from snake_case to camelCase, your AI assistant frequently fails to update the frontend state transformer three files away.

The Hypermedia Collapse

HTMX collapses that entire pipeline:

[Database] ↔ [Server Logic + HTML Template] ↔ [Real DOM via HTMX]

The server returns plain HTML chunks. HTMX swaps them directly into the DOM. There is no JSON serialization layer, no client-side store, and no synchronization logic. The state lives where it belongs: on the server.

Because LLMs are trained on decades of server-side templates (Django, Rails, Laravel, Go templates, Express/EJS), they write server-rendered HTML with near-perfect accuracy on the first shot.

The Advantages of HTMX for Vibe Coding

1. Minimal Cognitive & Token Overhead

When you prompt an AI to create a feature with HTMX, you don’t need to paste 8 files. You paste one template or one server endpoint. The LLM can hold your entire route logic and its visual representation in a single prompt.

2. Zero State Desync

Because there is no separate client-side cache, bugs like "I clicked delete, but the item still appears until I refresh" simply don't happen. The server deletes the row and returns an empty string or the updated table markup. Done.

3. Framework Agnostic

Whether you vibe code in Python (FastAPI/Flask), Go (Echo/Chi), Node.js (Express/Hono), or Rust (Axum), your HTMX syntax remains identical:

hx-get
hx-post
hx-target
hx-swap

Hands-On Example: The Live Search & Quick Edit Pattern

Let’s build an interactive search-and-edit interface. We'll use Node.js + Express with inline HTML template literals to keep everything in one compact file.

1. The Main Shell (`server.js`)

Here is how simple your application entry point is. Notice how HTMX attributes handle all the client-side behaviors that usually require hundreds of lines of React state.


javascript
const express = require('express');
const app = express();

app.use(express.urlencoded({ extended: true }));
app.use(express.json());

// In-memory mock store
let items = [
  { id: 1, name: "Dark Mode UI Kit", status: "Active" },
  { id: 2, name: "Analytics Dashboard", status: "Pending" },
  { id: 3, name: "Webhook Dispatcher", status: "Archived" }
];

// Base layout
app.get('/', (req, res) => {
  res.send(`
    <!DOCTYPE html>
    <html lang="en">
    <head>
      <meta charset="UTF-8">
      <title>HTMX + Vibe Coding Dashboard</title>
      <script src="[https://unpkg.com/htmx.org@2.0.0](https://unpkg.com/htmx.org@2.0.0)"></script>
      <script src="[https://cdn.tailwindcss.com](https://cdn.tailwindcss.com)"></script>
    </head>
    <body class="bg-neutral-950 text-neutral-100 p-8 font-sans">
      <div class="max-w-2xl mx-auto space-y-6">
        <h1 class="text-2xl font-bold tracking-tight">Project Overview</h1>

        <!-- Live Search Input -->
        <div>
          <input 
            type="text" 
            name="q" 
            placeholder="Type to filter..." 
            hx-get="/search" 
            hx-trigger="keyup changed delay:300ms, search" 
            hx-target="#items-list" 
            class="w-full bg-neutral-900 border border-neutral-800 rounded px-4 py-2 focus:outline-none focus:border-neutral-500"
          />
        </div>

        <!-- Dynamic Content Swap Target -->
        <div id="items-list" class="space-y-2">
          ${renderList(items)}
        </div>
      </div>
    </body>
    </html>
  `);
});

function renderList(list) {
  if (list.length === 0) {
    return `<p class="text-neutral-500 text-sm">No items found.</p>`;
  }
  return list.map(item => `
    <div id="item-${item.id}" class="flex items-center justify-between p-4 bg-neutral-900 border border-neutral-800 rounded">
      <div>
        <div class="font-medium">${item.name}</div>
        <div class="text-xs text-neutral-400">Status: ${item.status}</div>
      </div>
      <button 
        hx-get="/items/${item.id}/edit" 
        hx-target="#item-${item.id}" 
        hx-swap="outerHTML"
        class="text-xs bg-neutral-800 hover:bg-neutral-700 px-3 py-1.5 rounded transition">
        Edit
      </button>
    </div>
  `).join('');
}

2. Interactive Endpoints (Search & In-Place Editing)
Now ask your LLM to add live filtering and in-place row editing. Instead of coordinating mutations and optimistic updates, the server simply returns small pieces of HTML:
// Live search query endpoint
app.get('/search', (req, res) => {
  const query = (req.query.q || '').toLowerCase();
  const filtered = items.filter(item => item.name.toLowerCase().includes(query));
  res.send(renderList(filtered));
});

// Returns the inline edit form
app.get('/items/:id/edit', (req, res) => {
  const item = items.find(i => i.id === parseInt(req.params.id));
  if (!item) return res.sendStatus(404);

  res.send(`
    <form 
      id="item-${item.id}" 
      hx-put="/items/${item.id}" 
      hx-target="#item-${item.id}" 
      hx-swap="outerHTML" 
      class="flex items-center gap-3 p-4 bg-neutral-900 border border-neutral-700 rounded">

      <input 
        type="text" 
        name="name" 
        value="${item.name}" 
        class="bg-neutral-950 border border-neutral-800 px-3 py-1 text-sm rounded flex-1 focus:outline-none"
      />

      <select name="status" class="bg-neutral-950 border border-neutral-800 px-2 py-1 text-sm rounded">
        <option value="Active" ${item.status === 'Active' ? 'selected' : ''}>Active</option>
        <option value="Pending" ${item.status === 'Pending' ? 'selected' : ''}>Pending</option>
        <option value="Archived" ${item.status === 'Archived' ? 'selected' : ''}>Archived</option>
      </select>

      <button type="submit" class="text-xs bg-emerald-600 hover:bg-emerald-500 px-3 py-1.5 rounded font-medium">Save</button>
      <button 
        type="button" 
        hx-get="/items/${item.id}" 
        hx-target="#item-${item.id}" 
        hx-swap="outerHTML"
        class="text-xs bg-neutral-800 hover:bg-neutral-700 px-3 py-1.5 rounded">
        Cancel
      </button>
    </form>
  `);
});

// Saves the update and swaps the row back to display mode
app.put('/items/:id', (req, res) => {
  const item = items.find(i => i.id === parseInt(req.params.id));
  if (!item) return res.sendStatus(404);

  item.name = req.body.name || item.name;
  item.status = req.body.status || item.status;

  res.send(`
    <div id="item-${item.id}" class="flex items-center justify-between p-4 bg-neutral-900 border border-neutral-800 rounded">
      <div>
        <div class="font-medium">${item.name}</div>
        <div class="text-xs text-neutral-400">Status: ${item.status}</div>
      </div>
      <button 
        hx-get="/items/${item.id}/edit" 
        hx-target="#item-${item.id}" 
        hx-swap="outerHTML" 
        class="text-xs bg-neutral-800 hover:bg-neutral-700 px-3 py-1.5 rounded transition">
        Edit
      </button>
    </div>
  `);
});

// Read single row (used by "Cancel")
app.get('/items/:id', (req, res) => {
  const item = items.find(i => i.id === parseInt(req.params.id));
  if (!item) return res.sendStatus(404);
  res.send(`
    <div id="item-${item.id}" class="flex items-center justify-between p-4 bg-neutral-900 border border-neutral-800 rounded">
      <div>
        <div class="font-medium">${item.name}</div>
        <div class="text-xs text-neutral-400">Status: ${item.status}</div>
      </div>
      <button 
        hx-get="/items/${item.id}/edit" 
        hx-target="#item-${item.id}" 
        hx-swap="outerHTML" 
        class="text-xs bg-neutral-800 hover:bg-neutral-700 px-3 py-1.5 rounded transition">
        Edit
      </button>
    </div>
  `);
});

app.listen(3000, () => console.log('Listening on http://localhost:3000'));

Best Practices for Prompting AI with HTMX
When prompting your AI agent (Cursor, Claude, ChatGPT, Windsurf, Copilot), use these rules to keep outputs razor-sharp:
1. Give it the "Hypermedia Rules" System Prompt
Place this in your .cursorrules, system prompt, or conversation start:
We build using Server-Side Rendered HTML and HTMX.
Do NOT create JSON APIs or client-side stores unless explicitly requested.
Every endpoint returning interactive data should return an HTML snippet.
Always use proper hx-target, hx-swap, and hx-indicator attributes.
Prefer outerHTML swaps for modifying existing components in-place.

2. Prompt for Endpoints and Snippets Together
Instead of asking:
> "Create a REST API for deleting an order and write a React hook to mutate it."
> 
Prompt like this:
> "Write a DELETE /orders/:id endpoint that deletes the record from the DB and returns an HTTP 200 with an empty body, using hx-swap="delete" on the client button to remove the row from the DOM."
> 
The AI will output 8 lines of code instead of 60.
When HTMX Is the Right Vibe (and When It's Not)
| Ideal for HTMX + AI | Better with Traditional SPAs |
|---|---|
| CRUD apps, admin portals, dashboards | Offline-first mobile-style apps |
| Content platforms, internal tooling | Canvas/WebGL heavy apps (Figma, games) |
| Prototypes & fast MVP launches | High-density drag-and-drop spreadsheets |
| Single-developer or small-team builds | Multi-team decoupled API ecosystems |
The Takeaway
Vibe coding is all about tight feedback loops.
The more indirection your stack requires—build steps, compile errors, bundler hiccups, and hydration mismatches—the more your flow state breaks.
HTMX gives your AI assistant direct access to the DOM through the simplest protocol on earth: standard HTTP and HTML. The next time you fire up your AI code editor to build a tool, skip the heavy frontend bundle. Pair your model with HTMX and watch your ideas turn into functional software at lightspeed.

I built a free carbon & page-weight auditor for the web — feedback welcome

Digital Ghost — Sun, 20 Sep 2026 03:44:02 +0000

Hey DEV community 👋

I've been working on a side project and I'd love some honest feedback before I push it further.

It's called Tardigrade — a free, browser-based auditor that tells you the carbon footprint and page weight of any URL. Paste a link, get an A–F grade in seconds. No signup, no tracking, no upsell.

🔗 Live demo: tardigrade-six.vercel.app

Why I built it

The average web page now weighs over 2 MB. Some hit 10 MB. Most developers never see that number because nobody puts it in front of them.

Every byte transferred costs electricity — servers, networks, devices. Using the Sustainable Web Design model, we can estimate the carbon cost of a single page visit:

grams of CO₂ per visit = bytes transferred × 1.8 Wh/GB × 442 gCO₂/kWh

That's roughly 0.36 grams of CO₂ per megabyte. Sounds tiny — until you realize a bloated 5 MB page served to 10,000 visitors a day adds up fast.

I wanted a tool that puts that number in front of developers without any friction.

What it does

Fetch — Pulls live performance data from Google PageSpeed Insights (page weight, HTTP requests, load time, Lighthouse score).
Calculate — Runs the Sustainable Web Design formula to estimate CO₂ per visit.
Grade — Blends weight, CO₂, requests, load time, and Lighthouse into a single A–F score, plus color-coded metrics and concrete suggestions.

Nothing is stored. No accounts, no analytics on your audits, no email capture. Paste, read, leave.

Tech stack & design choices

Vanilla HTML/CSS/JS — no framework bloat (would be ironic otherwise)
Three.js — animated hero with an abstract floating tardigrade made of wireframe geometry, orbited by red/yellow particles
Vercel serverless function — proxies PageSpeed Insights to avoid CORS and keep any API key hidden
Scroll-triggered reveals via IntersectionObserver
Dark / light mode respecting system preference
Shareable URLs — every audit gets a ?url= permalink for Slack/Discord sharing

The name comes from the tardigrade — the toughest animal on Earth. Survives radiation, vacuum, boiling, freezing. Your website should be just as resilient, and just as light.

What I'd love feedback on

This is where you come in. A few specific things I'm unsure about:

Scoring weights — Right now the grade blends page weight (30%), CO₂ (30%), requests (15%), load time (10%), and Lighthouse (15%). Are these the right ratios? Should load time matter more?
The carbon math — I'm using the Sustainable Web Design model (1.8 Wh/GB × 442 gCO₂/kWh). Are there better or more current models I should support?
The UI — Does the Three.js hero feel appropriate for a dev tool, or is it distracting?
Missing metrics — Anything you'd want to see that isn't there? (I'm considering adding TTFB, CLS, and per-resource-type breakdowns.)
Mobile experience — Does the input form and score card feel right on small screens?

Try it and tell me your grade

Honestly — paste your own site in and see what you get. Most people land on a C or D the first time. If you're brave, drop the grade in the comments 👇

🔗 tardigrade-six.vercel.app

Roadmap (depending on feedback)

Per-resource-type breakdown (images vs JS vs fonts)
"Greenest sites" leaderboard
Compare two URLs side-by-side
Downloadable audit report as PDF/image
Browser extension

If any of these sound useful, let me know which one to prioritize.

Thanks for reading. It's a solo project, so every bit of feedback helps. 🙏

Built by Digital Ghost 👻 — free forever.

Tough on weight. Kind to Earth.