DEV Community: Dennis Morello

The New HTTP QUERY Method

Dennis Morello — Tue, 07 Jul 2026 18:50:16 +0000

If you've ever built a search endpoint, you've hit this wall. Your query has filters, sort orders, a nested set of facets, maybe a geo bounding box. It doesn't fit in a URL, and cramming it into query string params is ugly and fragile. So you reach for POST /search, send the whole thing as a JSON body, and quietly accept that you've just lied about what the request does. It's not creating anything. It's a read. But POST is the only tool that lets you attach a body without fighting the platform.

That gap finally got filled. In June 2026 the IETF published RFC 10008, which defines the HTTP QUERY method: a new verb built for exactly this case.

The two bad options

Every read that needs structured input has been stuck choosing between GET and POST, and both are wrong in their own way.

GET is the semantically correct choice. It's safe (the client isn't asking to change anything), it's idempotent (retrying it is fine), and it's cacheable. The problem is the body. RFC 9110 is explicit that content in a GET request has no defined semantics, and sending one may cause some implementations to reject the request. So your query has to live in the URI, where you run into unknown length limits across proxies and servers, encoding overhead, and the query landing in access logs and browser history.

POST solves the body problem and creates a new one. It carries any payload you want, but it's neither safe nor idempotent by definition. Intermediaries won't cache it, clients won't retry it automatically after a dropped connection, and anything inspecting traffic has to assume the request might have side effects. You get the body, you lose everything that made the request honest.

QUERY is the missing third option: a method that carries a body and keeps the semantics of a read.

What QUERY actually is

The spec, authored by Julian Reschke, James Snell, and Mike Bishop, describes it in one sentence:

A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing.

So a QUERY request looks like this:

QUERY /products HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json

{
  "filters": { "category": "keyboards", "inStock": true },
  "sort": [{ "field": "price", "order": "asc" }],
  "page": { "size": 20 }
}

The three properties that matter:

It's safe and idempotent. The client isn't requesting a state change, and the request can be retried or repeated without worrying about partial effects. This is what POST could never promise.

It's cacheable. A cache is allowed to store the response and use it to satisfy later QUERY requests. The catch is that the cache key has to include the request content, not just the URI, since the body is what distinguishes one query from another. Two QUERYs to the same URL with different bodies are different requests.

The response isn't a representation of the URI. Unlike GET, where the response is the resource at that URL, a QUERY response is the result of running your query over some data scoped to the target. GET /products returns the products resource; QUERY /products returns whatever your query selected from it.

The details that bite

A few rules are worth knowing before you wire this up.

Content-Type is mandatory. The server MUST reject the request if the Content-Type field is missing or inconsistent with the body. In practice you'll see a 400 for a missing media type, a 415 Unsupported Media Type for one the server doesn't handle, and a 422 Unprocessable Content when the body parses fine but doesn't make sense as a query.

There are two response headers that trip people up because they sound alike:

Content-Location points at a resource representing the results of this query. A client can GET that URL later to fetch the same results again.
Location points at a resource representing the query itself. A client can GET that URL to re-run the query without resending the body, which is handy for turning a heavy query into a shareable link.

Results points to the answer; Location points to the question.

The spec also nudges you away from HTTP range requests for pagination. Range semantics technically apply, but most query formats already have their own paging built in (think SQL's FETCH FIRST), and that's the mechanism you should reach for.

Can you use HTTP QUERY today?

On the client, yes, already. The Fetch API and libraries like axios accept arbitrary method strings, so nothing is stopping you from sending one right now:

const res = await fetch("/products", {
  method: "QUERY",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ filters: { category: "keyboards" } }),
});

The friction is everywhere else in the stack. QUERY isn't a CORS-safelisted method, so cross-origin QUERY requests trigger a preflight OPTIONS. Your server has to answer it with Access-Control-Allow-Methods: QUERY or the browser blocks the real request. And anything that whitelists methods will reject QUERY until you tell it not to: reverse proxies, WAFs, API gateways, limit_except blocks in nginx. The method passing through the wire is the easy part; the config that guards the wire is where you'll spend your time.

Framework and server support is still landing. New HTTP methods don't come around often. The last one most people reached for was PATCH back in 2010, so the ecosystem moves slowly. Expect native routing helpers and middleware to fill in over the next couple of years rather than overnight.

Should you rush to switch?

Probably not, and there's no need to. Your POST /search endpoints work and aren't going anywhere. QUERY is the more correct tool, not an urgent migration.

What it does give you is a real answer to a question we've been hacking around for years. When you're designing a new read endpoint that needs a structured body, you now have a method that says exactly what it means: this is a safe, repeatable, cacheable read, and here's the query in the body where it belongs. That's worth reaching for on the next thing you build, even if the old endpoints stay put.

SolidJS 2.0: A React Developer's First Look at Signals and Async

Dennis Morello — Wed, 01 Jul 2026 22:00:00 +0000

I've shipped React for the better part of a decade. Hooks, Suspense, Server Components, the whole tour. So when the SolidJS 2.0 beta showed up in my feed with the tagline "The <Suspense> is Over," I rolled my eyes a little and then clicked anyway.

I'm glad I did. Solid has been the framework React people admire from a distance for years, and 2.0 is the release that finally made me install it and poke at the reactivity model instead of just reading about it. This post is my honest first look: what's new, what a React developer will recognize, and where Solid quietly does something React can't.

What is SolidJS 2.0?

SolidJS is a UI library with React-like JSX and a completely different engine underneath. Instead of re-rendering components and diffing a virtual DOM, it uses fine-grained reactivity: your component runs once, and updates flow directly to the exact DOM nodes that depend on a piece of state.

The 2.0 line is currently in beta. The first public build, v2.0.0-beta.0, landed on March 3, 2026, and the team skipped the alpha phase entirely because the milestones planned for it stopped feeling worth their own release. You can try it today:

pnpm add solid-js@next

The headline of the whole release is async. Solid's reactive graph now understands promises natively, and a lot of the API changes fall out of that one decision.

Fine-grained reactivity, from a React brain

Here's the mental model shift, and it's the thing to internalize before anything else makes sense.

In React, state changes re-run your component function. React then builds a new virtual DOM tree and diffs it against the old one to figure out what actually changed. useMemo, useCallback, and dependency arrays exist to keep that re-render machine from doing too much work. The React Compiler automates a lot of that memoization now, but the underlying model is the same: the component re-runs and React diffs the result.

In Solid, the component body is setup code. It runs a single time. When you read a signal in your JSX, Solid records that specific dependency and wires it straight to the DOM. Change the signal later and only that text node or attribute updates. No component re-render, and no dependency array to keep honest.

function Counter() {
  const [count, setCount] = createSignal(0);

  // This whole function runs ONCE. Only the text node updates on click.
  return <button onClick={() => setCount(count() + 1)}>{count()}</button>;
}

The tell for a React dev: count is a function, not a value. You call count() to read it. That call is what subscribes the surrounding computation to changes. Once it clicks, the absence of a dependency array stops feeling like something is missing and starts feeling like a bug class that no longer exists.

First-class async is the real story

This is where 2.0 earns its version bump. In Solid 1.x, async data meant createResource and wrapping things in <Suspense>. In 2.0, a derived computation can just return a promise, and the graph handles suspending and resuming for you.

// Solid 1.x
const [data] = createResource(userId, fetchUser);

// Solid 2.0: the promise flows through the reactive graph
const data = createMemo(() => fetchUser(userId()));

Suspense gets replaced by <Loading>, and the semantics are the part I actually care about. <Loading> is scoped to initial readiness. It shows a fallback while the subtree can't render anything yet, and then it stays out of your way. When userId() changes and the data refetches, the UI doesn't tear itself down and flash a spinner. It holds the old content until the new content is ready.

To show that a refresh is in flight, you reach for isPending, which reports on pending reactive work without unmounting anything:

const users = createMemo(() => api.listUsers());
const refreshing = () => isPending(() => users());

<>
  <Show when={refreshing()}>
    <RefreshIndicator />
  </Show>
  <Loading fallback={<Spinner />}>
    <UserList users={users()} />
  </Loading>
</>;

React 19 gets you most of the way here: put the update in a transition with useTransition, and Suspense holds the old content on screen instead of flashing its fallback, with isPending reporting the refresh. The difference is that React makes you opt into that at each call site, while Solid bakes the distinction between "we have nothing to show yet" and "we're refreshing what's already on screen" into the primitives themselves.

Mutations have a home now

For a long time React had no blessed way to do writes, so you rolled your own or reached for a data library. React 19 changed that with Actions and the useOptimistic hook, so this is a spot where the two frameworks have converged. Solid 2.0's version is action for mutations, plus createOptimistic and createOptimisticStore for optimistic updates, with refresh to revalidate afterward.

const [messages, setMessages] = createOptimisticStore(() => chatServer.loadMessages(), []);

const sendMessage = action(function* (next) {
  setMessages((m) => {
    m.push(next); // optimistic: show it instantly
  });
  yield chatServer.sendMessage(next); // await the server
  refresh(messages); // reconcile with the source of truth
});

The generator function is doing real work here. Each yield is a point where the action awaits, and the reactive system tracks the optimistic state until the real value lands and reconciles. Solid has been circling this for a while: @solidjs/router already shipped createAsync and action for data loading and mutations. 2.0 takes that thinking and builds async and actions into the core reactive graph, so the patterns aren't router-specific anymore.

Deterministic batching, and a gotcha

One behavioral change will trip you up if you're not ready for it. Writes are batched on a microtask, and reads don't reflect a write until the batch flushes.

const [count, setCount] = createSignal(0);

setCount(1);
count(); // still 0: the update is queued on the microtask
flush(); // apply queued updates synchronously
count(); // now 1

flush() forces the queue to apply right away when you need to read the result immediately, like focusing an input after a state change. Coming from React's synchronous batching it takes a moment to adjust, but the model is predictable, and that matters once async is woven through everything.

The renames a React developer should know

Solid 2.0 is a major version, so it cleans house. Since this is beta, some of these identifiers could still shift before stable, but the direction is set, and the migration guide tracks where things stand today. The changes that matter most coming from React:

<Suspense> → <Loading>, with the initial-readiness semantics above. <SuspenseList> becomes <Reveal>.
createEffect is split into a compute phase (what to track) and an apply phase (what to run with the result). Instead of reading signals inside one callback, you pass the two separately:

  // Solid 1.x
  createEffect(() => apiCall(signalB()));

  // Solid 2.0
  createEffect(signalB, apiCall);
  createEffect(
    () => [signalA(), signalB()],
    ([a, b]) => a && apiCall(b),
  );

If you've ever shipped a bug because a value was in a useEffect body but missing from the dependency array, separating the two is a direct answer to that. Ryan Carniato has also said the idiomatic 2.0 code reaches for createEffect far less than 1.x did, since async and derived state now cover cases you used to handle with an effect.

onMount → onSettled, reflecting the async-aware lifecycle.
<Index> → <For keyed={false}>; in that non-keyed mode the row is passed as an accessor, matching the old <Index> stability model.
Store setters are draft-first by default. You mutate a draft instead of threading a path. This is 1.x's produce behavior promoted to the default, so you no longer wrap the callback, with a storePath helper as the opt-in escape hatch for the old path style:

  // 2.0 default: mutate the draft
  setStore((s) => {
    s.todos[id].done = true;
  });
  // Legacy path style, opt-in
  setStore(storePath("todos", id, "done", true));

classList is folded into class, which now takes strings, arrays, and objects.
use: directives are removed in favor of ref directive factories.
Context is simpler. The context is directly usable as the provider, so Context.Provider is gone. A context created without a default is typed as its value instead of T | undefined, and useContext throws ContextNotFoundError when there's no provider above it; a context created with a default still returns that default:

  const Theme = createContext(); // no default
  // 2.0: the context is its own provider
  <Theme value="dark">{/* ... */}</Theme>;

Signals are heading toward the standard

The word "signals" is everywhere now, and it's worth knowing why. There's a TC39 Signals proposal at Stage 1, with design input from the people behind Angular, Vue, Svelte, Preact, Qwik, MobX, and Solid. Ryan Carniato, Solid's creator, has been part of that conversation for years, and his writing on fine-grained reactivity helped push it onto the committee's radar.

Worth being precise here, because it's easy to overstate: Solid 2.0 does not ship the TC39 API as its core. The proposal is synchronous, and Solid 2.0's whole thing is async reactivity, which goes further than what's currently on the table. Solid influences and tracks the standard rather than implementing it. But the fact that the primitive Solid has bet on for years is now a serious standardization effort tells you the industry is drifting toward the model React chose not to adopt. Svelte 5 already rebuilt its reactivity around signals with its runes API, and it's unlikely to be the last framework to make the jump.

Should you drop React? No. But watch this closely.

I'm not migrating my day job to Solid this quarter, and I don't think you should either. It's a beta, the ecosystem is smaller than React's, and API names are still moving. That's the honest read.

But 2.0 is the most interesting frontend release I've looked at in a while, precisely because it isn't chasing React. It takes fine-grained reactivity seriously and follows the idea all the way through to async, and the result is a set of primitives that make the hard parts of React (stale closures, dependency arrays, Suspense re-triggering, figuring out where mutations should live) feel like problems you can just stop having.

If you write React and you've never actually run Solid, this is the release to spend a weekend on. Spin up a project with solid-js@next, build something small with createSignal and <Loading>, and pay attention to how much of your usual React vigilance you can put down.

The beta is live at github.com/solidjs/solid, and the announcement discussion is worth reading in full if any of this piqued your interest.

Rebuilding Defrag98: Getting the Details Right

Dennis Morello — Tue, 30 Jun 2026 17:00:00 +0000

There's a specific kind of satisfaction that comes from watching the Windows 98 defrag screen do its thing. Clusters shuffling around. That progress bar crawling. The sense that your computer was doing something important, even if you had no idea what.

That's the feeling I wanted to bottle when I built the first version of defrag98.com back in 2024. The project took off beyond anything I'd expected. It got picked up by Hacker News and The Verge, and people from all over the world spent time staring at a browser tab the way their younger selves once stared at a CRT monitor. Mission accomplished.

But the more I looked at it, the more I noticed the cracks.

It wasn't quite right

The most significant problem was the simulation logic. The original Windows 98 defragmenter didn't march through clusters sequentially. It read blocks, wrote them, and shuffled them around in a messier, more organic process that made watching it genuinely hypnotic. My first implementation was too orderly. It looked like a simulation. The real one looked like a machine thinking.

The legend was missing too. The real Windows 98 defragmenter had a dedicated button that opened a dialog explaining what each block color meant: optimized, reading, writing, bad cluster. Without it, the simulation was just a pretty light show. Now it has one.

On the visual side, the cluster grid also had a black background, when the real defragmenter used white. A small detail, but exactly the kind of thing that breaks the spell for anyone who actually remembers the original.

Then there was the progress bar. The real utility didn't draw a smooth, continuous fill. It revealed a row of chunky segmented blocks one at a time, with a "% Complete" caption underneath. Mine was too modern, too clean. Now it fills block by block the way it should, and the window is sized to give it room to breathe.

Even the controls were missing some manners. The original asked you to confirm before stopping a defrag, and it told you plainly when the job was Paused or Stopped. Small things, but they're the difference between a screensaver and a tool you can actually operate.

The rebuild: Next.js to Vite, and a faithful simulation

I moved the project from Next.js to Vite + React. This might sound like a lateral move, but it was the right call for what defrag98.com actually is: a single-page, entirely client-side app with no routing, no server-side data, and no need for SSR. Next.js is excellent at what it does, but fighting its SSR model to build something that runs entirely in the browser felt like wearing a suit to go swimming.

Vite gave back the dev experience that SSR had been quietly taxing. Faster builds, instant HMR, and a mental model that actually matches the app. While I was in there, the rest of the stack got a refresh too: Tailwind CSS v4 through its native Vite plugin (no more PostCSS pipeline), Base UI for the accessible dialogs, selects and checkboxes, Zustand for state, TypeScript 6, and the Rust-based oxc toolchain (oxlint and oxfmt) in place of ESLint and Prettier for near-instant linting and formatting.

The bigger change was moving cluster rendering to a <canvas> element. Instead of creating and updating hundreds of DOM nodes, I'm now drawing directly to a 2D canvas context. The number of clusters rendered adapts to whichever disk size you select, so a larger virtual drive produces a denser, more satisfying grid. The difference is easy to feel: the animation is smoother, the browser is happier, and it scales without complaint. I also size the canvas before the first paint, which killed the layout shift that used to jump around on mobile.

On the simulation side, I rewrote the defrag algorithm to properly model read and write operations on individual clusters, with non-sequential processing that mirrors how the original utility actually behaved. If you remember the way blocks would jump around seemingly at random before gradually settling into order, that's what it does now.

The sound got some attention too. The hard disk loop and the completion chime were re-encoded to a fraction of their old size (the HDD loop went from over a megabyte to around 350KB), shipped as Opus/WebM with an AAC fallback, and the Win98 fonts are preloaded now so nothing flashes on first paint. There are also toggles in Settings to mute the hard disk sound or the mouse clicks, and your choice is remembered the next time you visit.

When a defrag finishes, you now get the authentic Windows 98 "Disk Defragmenter" message box telling you it's done, chime and all, instead of the run just quietly ending.

A couple of things changed off-screen that I care about as much as the visible ones. I dropped Google Analytics and Tag Manager in favor of Cloudflare's cookieless Web Analytics, so there's no tracking cookie and no consent banner getting between you and the nostalgia. The site is hosted on Cloudflare Workers as static assets, and it ships an llms.txt so the AI crawlers that come poking around get a clean description of what this thing is.

defrag98.com also ships a web app manifest, so on supported browsers you can install it to your device and launch it like a native app. And it now runs fully offline: a service worker built with vite-plugin-pwa and Workbox precaches the app shell and every runtime asset, the fonts, cursors, audio, and icons, so once you've opened it once you can defragment a virtual drive on a plane with no signal. New builds activate quietly on the next launch, with no update prompt to nag you. Feels right for something built to feel like software from another era.

There's also a hidden Easter egg somewhere in the app. I'll leave it at that. If you grew up on Windows 98, you'll know it when you see it.

A quieter ask

The original version had a donation banner styled as an authentic Windows ME system notification: yellow background, full viewport width, sliding down from the top of the screen five seconds into your session. It was accurate to the era. It was also an interruption, landing right in the middle of the nostalgic moment it was supposed to be protecting.

The data confirmed it. Despite solid traffic, very few visitors converted to donors.

The new approach takes a cue from pre-release Windows software, the small line of unobtrusive text in the corner of the screen that says something like "This is a pre-release version". I added a quiet line in the bottom-right of the desktop area, linking to my Buy Me a Coffee page. It's there if you want it. It doesn't demand your attention. The only other time donating comes up is in that completion message box, once the defrag has actually finished and you've had your moment: a gentle Yes or No, never an interruption. The minimum donation has also dropped from $5 to $3, because the goal was never to extract money. It's to help cover the domain and hosting costs that keep defrag98.com running for anyone who gets something out of it.

Why this still matters to me

I've received $148 in total donations since launching. That's not a business. But it's proof that people feel something when they use it, enough to voluntarily send a few dollars to a stranger on the internet for a free toy.

That's the part that keeps me iterating on this instead of moving on. It's not a portfolio piece. It's a tiny time machine, and apparently enough people want to visit 1998 for a few minutes that keeping the lights on feels worth caring about.

If you haven't tried it yet, go defragment something. If you used to stare at this screen as a kid, I hope it hits the way I intended. And if you find the Easter egg, well, you'll know what to do.

Configuring My Site for AI Discoverability

Dennis Morello — Tue, 21 Apr 2026 08:02:58 +0000

A growing share of web traffic doesn't come from people anymore. It comes from models reading on their behalf. ChatGPT, Claude, Perplexity, Copilot. They fetch a handful of pages, summarize, and ship the answer back. If your site isn't readable by those agents, you don't exist to them.

People are calling this GEO, short for Generative Engine Optimization. It overlaps with SEO but the priorities are different. Agents don't care about your layout. They care about your prose, your metadata, and how many tokens it costs them to read you.

This post covers how I configured this site for GEO. The first half is framework-agnostic. The second half is specific to my setup on Cloudflare, and includes a deliberate choice that fails a popular GEO audit. I'll explain why.

Part 1: general GEO techniques

Serve raw Markdown alongside HTML

The single biggest GEO win is giving agents a version of each page without the navigation, styling, and scripts. HTML is designed for browsers. Markdown is designed for readers, human or otherwise. Agents spend their context window on your prose, not your DOM.

Every blog post on this site has a mirror URL with a .md suffix:

/blog/my-post is the full HTML page for humans
/blog/my-post.md is the raw Markdown, served as text/markdown

In Astro, this is a two-line route at src/pages/blog/[slug].md.ts:

export const GET = async ({ params }) => {
  const post = await getPostById(params.slug);
  return new Response(formatPostMarkdown(post), {
    headers: { "Content-Type": "text/markdown; charset=utf-8" },
  });
};

Both variants are pre-generated at build time. Same content, roughly half the tokens for an agent to consume.

Advertise the Markdown version in `<head>`

Agents landing on the HTML need to know the Markdown exists. A single <link> in the head does it:

<link rel="alternate" type="text/markdown" href="/blog/my-post.md" />

Browsers ignore this tag. Agents that parse the head follow it.

Publish an `llms.txt` index

llms.txt is a convention for a Markdown file at the root of your site listing your content with short descriptions and links. Think of it as a sitemap an LLM can actually read.

I ship two variants:

/llms.txt is the index. Title, description, one line per post with a link to its .md version.
/llms-full.txt is the full corpus. Every post body concatenated into a single response.

Why both? An agent researching a specific topic can fetch llms.txt, pick the relevant links, and pull them. An agent doing deep research on the site as a whole fetches llms-full.txt once and has everything it needs in one request. Either way there's no crawling.

Declare your AI stance in `robots.txt`

robots.txt now carries a Content-Signal directive for AI use. Mine reads:

User-agent: *
Content-Signal: search=yes, ai-train=no, ai-input=yes
Allow: /
Sitemap: https://morello.dev/sitemap-index.xml

Three independent knobs:

search=yes lets search engines index
ai-train=no says my content is not for training data
ai-input=yes says my content can be retrieved and used as input for AI answers

This is the stance I'm comfortable with. I want to show up when someone asks Claude about something I've written; I just don't want my posts absorbed into the next base model.

Whether any given operator actually honors this is another question. The signal's there regardless, and I'd rather be on record than silent about it.

Add structured data that actually describes the content

Most blogs ship JSON-LD schema by reflex. Few of them include the fields that help a generative engine decide whether your article is worth fetching.

On each post I emit a BlogPosting graph with:

wordCount and timeRequired (ISO 8601 duration), so an agent can estimate how much context it'll spend before fetching
articleBody, the full text machine-readable, with no HTML parsing required
author linked to a Person node with knowsAbout so the entity is grounded in real topics
BreadcrumbList for site hierarchy

All of it goes into a single @graph per page rather than scattered <script> tags, which makes it cheaper for an engine to walk from post to author to site without cross-referencing.

A sitemap that actually tracks freshness

If you regenerate your sitemap once and never look at it again, you're wasting a signal. Every URL in mine carries a lastmod timestamp pulled from the post's updatedDate frontmatter, falling back to pubDate. When I edit an old post, its lastmod moves forward and crawlers reprioritize it.

Validate with real tools

Two tools I found useful while iterating on all of the above:

isitagentready.com audits across five categories: discoverability, content accessibility, bot access control, protocol discovery, and commerce. The bot access control checks (Content-Signal, Web Bot Auth, AI bot rules) are the part that actually influences how agents treat your content.
acceptmarkdown.com has a narrower focus. It checks whether your site responds to Accept: text/markdown with a Markdown body, includes Vary: Accept, returns 406 for unsupported types, and parses q-values correctly.

I'll come back to the second one at the end of the post, because my site deliberately fails it.

Part 2: the Cloudflare-specific setup

General GEO gets you most of the way there. The rest is delivery. How fast you respond, whether the edge caches correctly, and how you advertise your agent-facing resources without waiting for someone to parse your HTML.

Static assets, zero Worker invocations

My wrangler.jsonc points a ./dist directory at Cloudflare's assets deployment, with no main entry:

{
  "name": "morellodev",
  "compatibility_date": "2026-04-18",
  "assets": {
    "directory": "./dist",
    "html_handling": "drop-trailing-slash",
    "not_found_handling": "404-page",
  },
}

Every request goes straight from the edge asset cache. HTML, Markdown, llms.txt, sitemap, RSS. Same path for all of them, and no Worker ever runs. On the Workers Free tier this matters. A crawler sweep that would otherwise eat into 100k daily invocations now costs me nothing. Agents, for better or worse, don't fingerprint politely.

Advertise discovery endpoints in a `Link` header

Cloudflare's _headers file lets you ship response headers without any server code. I use it to tell every response, not just HTML ones, where the agent-facing files live:

/*
  Link: </sitemap-index.xml>; rel="sitemap",
        </rss.xml>; rel="alternate"; type="application/rss+xml"; title="RSS",
        </llms.txt>; rel="describedby"; type="text/plain",
        </llms-full.txt>; rel="describedby"; type="text/plain"

A crawler doing a HEAD against any URL on the site sees all four links before it parses a single byte of HTML. One round-trip, no body, full discovery.

Long-lived cache for hashed assets

Astro emits fingerprinted filenames under /_astro/, so those can sit in cache for a year:

/_astro/*
  Cache-Control: public, max-age=31536000, immutable

Faster first paint for humans, cheaper crawls for agents. Same lever.

Why I skipped `Accept: text/markdown` content negotiation

acceptmarkdown.com will tell you this site doesn't do content negotiation. No Vary: Accept, no 406, no Markdown from the canonical URL. That's not an oversight. I tried it, shipped it briefly, and rolled it back.

The reason is Cloudflare's free plan. Custom cache keys are Enterprise-only, and their docs are explicit that Vary: Accept is ignored for caching decisions. The edge collapses every variant of /blog/my-post into one cache entry, so the first requester's format poisons the cache for everyone else until TTL expires.

The workaround is a Worker that bypasses the edge cache. But now every /blog/* request burns a Worker invocation, humans included, and the Workers Free plan gives you 100k per day and 10ms of CPU each. That's a real budget to share across humans and bots, for no functional gain over a static .md URL.

So I deleted the Worker. The only thing I lost is curl -H "Accept: text/markdown" …/blog/my-post returning Markdown. Between llms.txt, <link rel="alternate">, and the /blog/[slug].md convention, no mainstream agent I've seen actually needs Accept: negotiation. It's the more elegant protocol; alternate URLs are the more robust one on a free-tier CDN. On a paid plan I'd probably do both.

Where this leaves things

Every page exists in two forms, both served from the edge. Agent-facing resources are advertised in response headers on every request, before any HTML gets parsed. Structured data tells engines what the article is and how much context it takes to read. robots.txt says what I'll allow and what I won't.

GEO is still very new. The standards are half-drafted, the tools disagree with each other, and half the signals I described above didn't exist two years ago. I fully expect to be rewriting parts of this post within six months, probably with a different opinion about Accept-based negotiation, once I've either moved off the free plan or found a workaround that doesn't involve a Worker. But for now: serve agents a version they can cheaply consume, be explicit about what you'll allow, and accept that the defaults aren't on your side.

If you're reading this via a summary from some assistant, hi. Thanks for the traffic.

Git Worktrees Are Underrated

Dennis Morello — Mon, 16 Mar 2026 22:07:48 +0000

If you've ever stashed half-finished work to review a PR, or lost a train of thought switching branches, you should know about git worktrees. They've been in git since 2015, but most developers I talk to have never heard of them.

The problem with branches

The standard git workflow is linear. You're on a branch, you need to context-switch, so you stash your changes (or worse, make a throwaway commit), switch branches, do your thing, switch back, and pop the stash. If you're lucky, nothing conflicts.

This gets worse when you're juggling multiple things at once. Reviewing a colleague's PR while your feature branch is mid-refactor. Running tests on one branch while coding on another. Hotfixing production while your main work sits frozen.

A git repository has one working directory. One branch checked out at a time. Everything else has to wait.

Worktrees

Git worktrees let you check out multiple branches simultaneously, each in its own directory. They share the same .git history and objects, so you're not cloning the entire repo, but each one has its own working directory and index.

git worktree add ../feat-login feat/login

Now feat/login is checked out in ../feat-login. You can open it in a separate editor window, run tests there, or just let it sit while you work on something else.

When you're done:

git worktree remove ../feat-login

Why nobody uses them

If worktrees are so useful, why aren't they more popular? I think it comes down to two things.

First, the directory problem. Every time you create a worktree, you have to pick a path. There's no convention for where they go. After a week you end up with directories scattered across your filesystem: ../feat-login, ~/tmp/hotfix-auth, ../../pr-review. Good luck remembering where anything is.

Second, there are no ergonomics. You can't easily list your worktrees with status info, cd into one quickly, or run something like npm install in the new directory after checkout. The raw git commands work, but they don't make worktrees feel like a real workflow.

These aren't fundamental problems with worktrees. They're tooling gaps. That's why I built arbor.

A better workflow with arbor

Arbor is a CLI that manages git worktrees. It keeps them organized in a central directory (~/.arbor/worktrees/) and handles the stuff that plain git doesn't.

# Clone a repo (sets up a bare repo + default branch worktree)
arbor clone user/my-app

# Create a worktree for a new feature
arbor add feat/login

# Shell integration auto-cds you into the worktree
# You're now in ~/.arbor/worktrees/my-app/feat-login

# Need to review a PR? Open another worktree
arbor add fix/auth-bug

# See all your worktrees with dirty/clean status
arbor status

Every worktree for my-app lives under ~/.arbor/worktrees/my-app/. Branch slashes become dashes in directory names, so the filesystem stays tidy. When you're done with a branch:

arbor rm -d feat/login

That removes the worktree and the local branch in one step.

What makes it stick

I've been using worktrees for a while, but I kept falling off because of the friction. A few things in arbor made the difference for me.

Shell integration. arbor init sets up a wrapper so that arbor add and arbor switch automatically cd you into the worktree directory. Without it you create the worktree and then have to cd into it yourself every single time, which gets old fast.

Post-create hooks. You can add an .arbor.toml to your repo:

[hooks]
post_create = "npm install"

Every new worktree gets its dependencies installed automatically. You can chain commands too:

[hooks]
post_create = ["npm install", "cp .env.example .env"]

And arbor status --all shows the state of every worktree across all your repos, which is nice for a quick scan before you call it a day.

Where I use them most

PR reviews. arbor add the branch, review it in a separate editor window, remove it when done. My own work is untouched.

Long test suites. Tests running on one branch, coding on another. No waiting around.

Hotfixes. arbor add hotfix/critical, fix it, push it, remove it. Back to what I was doing.

Comparing behavior. Two worktrees open side by side, one on main and one on my feature branch. Way easier than switching back and forth.

Big migrations. Upgrading a framework to a new major version in a worktree while the rest of the team keeps shipping from main. No half-broken build blocking anyone.

Try it

Arbor is open source, written in Rust. Install with Homebrew:

brew install morellodev/tap/arbor

Or grab a binary from the releases page.

Run arbor init after installing to set up shell integration. Takes about 30 seconds.

If you've never tried worktrees, give them a shot. And if you have but gave up because of the directory mess, this might be worth another look.

morellodev / arbor

A friendly CLI for managing git worktrees

🌳 arbor

A CLI for managing git worktrees. It keeps all your worktrees under ~/.arbor/worktrees so you can switch between branches without stashing or losing context.

Why arbor?

Git worktrees are great: multiple branches checked out at once, no stashing, no half-finished commits. The problem is that git worktree add makes you pick a directory every time, and you end up with worktrees scattered everywhere.

Arbor puts them all in one place. arbor add feat/login creates the worktree, and with shell integration it cds you into it too. arbor rm feat/login cleans it up.

Who is this for?

If you review PRs while working on your own feature, juggle hotfixes alongside long-running branches, or run tests in one worktree while coding in another — arbor keeps everything organized.

Install

Homebrew (macOS and Linux)

brew install morellodev/tap/arbor

Pre-built binaries (macOS, Linux, Windows)

Download the latest binary for your platform from…

View on GitHub

Recreating History: Building a Windows 98 Disk Defrag Simulator with Modern Web Tech

Dennis Morello — Sun, 14 Jul 2024 09:41:54 +0000

Hey fellow devs! I'm Dennis Morello, a Senior Frontend Engineer with a passion for both cutting-edge web technologies and retro computing. I'm excited to share my latest project that combines these interests: a faithful recreation of the Windows 98 Disk Defragmenter, built entirely for the web.

Check it out: defrag98.com

Update 19 Jul 2024: We're on Product Hunt! 🚀

Great news, everyone! The Windows 98 Disk Defragmenter Simulator is now live on Product Hunt. This is an exciting milestone for the project, and I'm thrilled to share it with a wider audience of tech enthusiasts and nostalgia lovers.

Update 14 Jul 2024: Featured on The Verge and Hacker News!

The project has been featured on Hacker News and The Verge! Thank you to everyone who has tried it out and shared their love for this blast from the past.

The Tech Stack

For this project, I leveraged some of the most powerful tools in modern web development:

React: For building the UI components
Next.js: To optimize performance and SEO
Zustand: To manage the state of the app
TailwindCSS: To style the app, along with 98.css for bringing in the Windows 98 aesthetic
Radix UI Primitives: For accessible interactive components like sliders and modals
Vercel: The hosting platform for the app

Challenges and Solutions

1. Recreating the Defragmentation Algorithm

One of the biggest challenges was implementing a defragmentation algorithm that felt authentic. I created a custom algorithm that:

Randomly selects clusters to process
Simulates file movements across the disk
Adjusts processing speed based on the selected virtual drive

2. Pixel-Perfect UI Recreation

Achieving the exact look and feel of Windows 98 required meticulous attention to detail. I used a combination of 98.css and TailwindCSS to:

Match colors precisely
Recreate the characteristic 'chunky' borders
Implement the classic Windows 98 typography

3. Simulating Hard Drive Sounds

To add an extra layer of nostalgia, I implemented realistic hard drive sounds. This involved:

Recording and editing authentic HDD sounds
Leveraging the Web Audio API for precise playback control
Synchronizing sound effects with the visual defragmentation process
Adapting the HDD sounds to the chosen drive speed

What I Learned

This project was a fantastic opportunity to:

Deep dive into the intricacies of writing a custom defrag algorithm, and find a balance between performance and simulation accuracy
Explore the challenges of accurately simulating legacy software
Push the boundaries of what's possible in browser-based applications

What's Next?

This is a project I started just for fun, but I'm excited to see where it goes. I'm looking forward to continuing to improve the app, and adding more features as feedbacks from users come in.

I'd love to hear your thoughts, suggestions, or questions about this project. Have you worked on similar retro tech simulations? What challenges did you face?

5 Things You Might Not Know About JavaScript

Dennis Morello — Thu, 08 Jun 2023 06:50:30 +0000

JavaScript is a programming language that has been around for over 20 years. It's used in many different ways, but what are some things you might not know about it? In this blog post, we'll explore 5 things you might not know about JavaScript.

Original post at https://morello.dev/articles/five-things-you-might-not-know-about-javascript

Introduction

JavaScript has undoubtedly become one of the most essential programming languages in the world of web development. As the backbone of interactive web pages, it enables developers to create dynamic and engaging user experiences. You might already be familiar with the basics of JavaScript, but there are numerous lesser-known aspects and hidden gems within the language that can enhance your coding skills and expand your understanding.

In this blog post, we'll delve into 5 intriguing things about JavaScript that you might not be aware of. Whether you're ready to impress your colleagues with newfound JavaScript knowledge or simply eager to enhance your own programming prowess, this blog post is for you. Let's dive in and uncover the hidden gems that await us in the vast world of JavaScript!

1 - "JavaScript" is trademarked by Oracle

The name "JavaScript" is a trademark of Oracle Corporation in the United States. The trademark was originally owned by Netscape Communications Corporation, which created the language in 1995. In 1996, Netscape transferred the trademark to Sun Microsystems, which was acquired by Oracle in 2010.

A trademark is a legal protection that grants exclusive rights to use a particular word, phrase, symbol, or design to identify and distinguish a product or service.

As a trademark holder, Oracle has the authority to control the usage of the term "JavaScript" within the United States. This means that other entities must seek permission from Oracle or adhere to specific guidelines if they wish to use the term in a way that may be covered by the trademark. Unauthorized use of a trademarked term can lead to legal repercussions.

It is important to note that while the term "JavaScript" is trademarked by Oracle in the United States, the programming language itself is an open standard governed by the ECMAScript specification. This means that the language can still be used and implemented by developers and organizations globally, regardless of the trademark ownership.

In 2022, Node.js and Deno creator Ryan Dahl wrote an open letter titled Dear Oracle, Please Release the JavaScript Trademark, where he urges Oracle to release JavaScript trademark.

2 - JavaScript and ECMAScript are not the same thing

JavaScript is often referred to as ECMAScript, but the two terms are not interchangeable. JavaScript is a programming language, while ECMAScript is a standardized specification that defines the syntax, semantics, and features of the JavaScript language. It provides a standardized framework for implementing JavaScript across different platforms and browsers.

ECMAScript is maintained by Ecma International, an industry association, and undergoes regular updates to introduce new features and enhancements.

It is important to note that different versions of JavaScript correspond to different editions of the ECMAScript specification. For example, ECMAScript 5 (ES5) introduced significant improvements and features to the JavaScript language, while ECMAScript 6 (ES6) brought about even more significant changes, such as arrow functions, classes, and modules.

In summary, JavaScript is the widely used programming language that follows the ECMAScript specification. ECMAScript provides the standardization and guidelines for implementing JavaScript across platforms, ensuring compatibility and allowing developers to write code that can be executed consistently.

3 - JavaScript is a dynamically typed language

As in every programming language, in JavaScript variables and values have types associated with them. Although JavaScript is often referred to as a dynamically typed language, meaning that variables can hold values of any type, it does have a type system that determines how values can be used and manipulated.

JavaScript employs a loose type system, where type coercion can occur implicitly, allowing for flexibility in operations between different types. For example, the + operator can be used to add numbers or concatenate strings, but also to cast a value to a number.

There is also an operator called typeof that can be used to determine the type of a value at a given point in time. It returns a string representing the type of the operand.

4 - JavaScript has seven primitive types

As of ECMAScript 2020 release, JavaScript has seven primitive types, which are the building blocks of all JavaScript values:

Boolean: Represents a logical value of either true or false.
Null: Represents the intentional absence of any object value. It is a primitive type, but its sole value is null.
Undefined: Represents a variable that has been declared but has not been assigned a value. If a variable is declared but not assigned a value, it is automatically assigned the value of undefined.
Number: Represents numeric values, including integers and floating-point numbers. JavaScript uses the double-precision 64-bit binary format (IEEE 754) to represent numbers.
BigInt: Introduced in ECMAScript 2020, BigInt is a primitive type that provides a way to represent arbitrarily large integers. It allows developers to perform operations on numbers beyond the limits of the Number type.
String: Represents a sequence of characters enclosed in single quotes (''), double quotes ("") or backticks (``). Strings are used to store and manipulate textual data.
Symbol: Introduced in ECMAScript 2015, Symbol is a primitive type that represents a unique identifier. Symbols are often used as keys in objects to avoid name collisions.

These primitive types in JavaScript are immutable, meaning their values cannot be changed once created. They are distinct from objects, which are composite data types that can store multiple values and have methods and properties associated with them.

Another property of primitive types in JavaScript is that they are passed by value. This means that when a primitive value is assigned to a variable or passed as an argument to a function, a copy of the value is created and stored in the variable or parameter, and any changes made to the variable or parameter will not affect the original value.

5 - JavaScript is a "compiled" language

In the context of JavaScript, the term compiled can be misleading. Unlike languages such as C++ or Rust, where the source code is directly transformed into machine code before execution, JavaScript goes through a different process. When a JavaScript program is executed, it is first passed through a just-in-time (JIT) compiler built into the JavaScript engine.

During the execution, the JavaScript engine performs several optimizations, including parsing the source code, optimizing the code based on various heuristics, and generating machine code or bytecode for efficient execution. This dynamic compilation process, performed by the JavaScript engine at runtime, helps improve the performance of JavaScript programs.

It is worth noting that the compilation process in JavaScript is different from the traditional pre-compilation step found in languages like C or C++. In JavaScript, there is no separate compilation step that generates an executable file beforehand. Instead, the compilation happens as part of the runtime execution.

Overall, while JavaScript can be considered a compiled language in the sense that it undergoes compilation during runtime, it is more accurate to describe it as an interpreted language with a just-in-time compilation process.

If you want to go deeper, Kyle Simpson explores this topic in detail in his book You Don't Know JS Yet.

Conclusion

JavaScript never ceases to surprise and fascinate developers with its hidden depths and lesser-known features. In this blog post, we explored five intriguing aspects of JavaScript that you might not have been aware of, expanding your understanding of this versatile language.

As you continue your journey with JavaScript, remember that there is always more to explore and learn. Embrace the ever-evolving nature of this dynamic language, and continue to discover new facets that will enhance your development skills.

React Awesome Reveal v3 Beta

Dennis Morello — Sun, 02 Aug 2020 21:43:21 +0000

React Awesome Reveal v3 using Emotion to provide animations is now on beta 🎉 Check it out by adding react-awesome-reveal@beta to your React project.

react-awesome-reveal v2.4.0 released!

Dennis Morello — Sat, 18 Jan 2020 11:12:32 +0000

A new version of react-awesome-reveal has just been released, featuring a reverse option that... reverses the animation direction 👻 It is useful for making elements visible and invisible in a controlled way (form error indicators, badges, notifications and so on)!

Add data-test-id attributes to React apps

Dennis Morello — Fri, 03 Jan 2020 22:10:11 +0000

Meet react-test-attributes, my new library for React apps to add custom data-* attributes to DOM elements. Use it for your E2E tests!

https://www.npmjs.com/package/react-test-attributes

React Awesome Reveal v2 Released

Dennis Morello — Sat, 30 Nov 2019 21:57:18 +0000

React Awesome Reveal has just received a major update featuring zero external dependencies and a cleaner API 🎉 Check it out at github.com/dennismorello/react-awesome-reveal

Demo site

React Awesome Reveal

Dennis Morello — Tue, 26 Nov 2019 18:26:32 +0000

Hi all, I am writing react-awesome-reveal, a React library to animate elements when they appear in the browser viewport. It uses the Intersection Observer API and CSS Animations to be buttery smooth 🚀

Let me know what you think!