Forem: Amaury

Your PHP website is a free API: how to unlock it with content negotiation

Amaury — Wed, 08 Apr 2026 11:50:09 +0000

The problem

You have a product catalog on your website. Your marketing team wants a mobile app. Your CTO says "we need an API." Six months later, you're maintaining two codebases that do the same thing: fetch products from the database and return them to a client.

There's a better way.

What is content negotiation?

Content negotiation is a mechanism built into the HTTP specification since 1996. It allows a server to return different representations of the same resource from the same URL, based on what the client declares it can handle.

The most common signal is the Accept header:

# A browser sends:
Accept: text/html

# A mobile app or API client sends:
Accept: application/json

Same URL. Same controller. Same business logic. Different output.

Other mechanisms exist and work on the same principle:

A .json extension appended to the URL: /products/42.json
A query parameter: /products/42?format=json
An X-Requested-With: XMLHttpRequest header, common with AJAX calls
A dedicated URL prefix: /api/products/42

A concrete scenario

Your e-commerce platform lists products, handles filters, sorting, and pagination. Your mobile app needs exactly the same data, structured as JSON, to render its own product screens.

Instead of building a parallel API, you teach your existing endpoints to respond differently based on who is asking. The browser gets an HTML page with navigation, images, and layout. The mobile app gets a clean JSON payload with the same product data.

Implementation in three frameworks

The three examples below implement the same product catalog endpoint. Symfony is a mature, enterprise-grade PHP framework built around reusable components. Laravel is the most widely adopted PHP framework, known for its expressive syntax and large ecosystem. Temma is a lightweight MVC framework designed to minimize boilerplate while remaining fully functional for production use.

Symfony

<?php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\Attribute\Route;

/**
 * Handles product-related pages and API endpoints.
 */
class ProductController extends AbstractController
{
    /**
     * Returns the product catalog as HTML or JSON depending on the Accept header.
     *
     * When the client sends Accept: application/json, a JSON response is returned.
     * Otherwise, an HTML page is rendered using a Twig template.
     *
     * @param  Request  $request  The incoming HTTP request.
     * @return JsonResponse|\Symfony\Component\HttpFoundation\Response
     */
    #[Route('/products', requirements: ['_format' => 'html|json'])]
    public function catalog(Request $request) {
        // Fetch product data (static here, would come from a repository in production)
        $products = [
            ['id' => 1, 'name' => 'Widget Pro', 'price' => 49.99],
            ['id' => 2, 'name' => 'Gadget Plus', 'price' => 29.99],
        ];

        // Check the preferred format from the Accept header
        if ($request->getPreferredFormat() === 'json') {
            // Return a JSON response for API clients
            return new JsonResponse(['products' => $products]);
        }

        // Render the HTML page for browser clients
        return $this->render('product/catalog.html.twig', [
            'products' => $products,
        ]);
    }
}

The route attribute declares the accepted formats. The data is prepared once. Symfony's getPreferredFormat() reads the Accept header and returns the matching format string. The action then branches: JSON response or Twig template.

Laravel
Laravel has no route-level format declaration for this use case. The detection happens in the controller via expectsJson(), which checks the Accept header.

routes/web.php

<?php

use App\Http\Controllers\ProductController;
use Illuminate\Support\Facades\Route;

// Single route serving both HTML and JSON depending on the Accept header
Route::get('/products', [ProductController::class, 'catalog']);

app/Http/Controllers/ProductController.php

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Routing\Controller;

/**
 * Handles product-related pages and API endpoints.
 */
class ProductController extends Controller
{
    /**
     * Returns the product catalog as HTML or JSON depending on the Accept header.
     *
     * When the client sends Accept: application/json, a JSON response is returned.
     * Otherwise, an HTML page is rendered using a Blade template.
     *
     * @param  Request  $request  The incoming HTTP request.
     * @return \Illuminate\Http\JsonResponse|\Illuminate\View\View
     */
    public function catalog(Request $request) {
        // Fetch product data (static here, would come from a model in production)
        $products = [
            ['id' => 1, 'name' => 'Widget Pro', 'price' => 49.99],
            ['id' => 2, 'name' => 'Gadget Plus', 'price' => 29.99],
        ];

        // expectsJson() returns true when the Accept header contains application/json
        if ($request->expectsJson()) {
            // Return a JSON response for API clients
            return response()->json(['products' => $products]);
        }

        // Render the HTML page for browser clients
        return view('product.catalog', ['products' => $products]);
    }
}

The product data is built once. If the client wants JSON, response()->json() serializes it. Otherwise, the data flows into a Blade template.

Temma
Temma takes a different approach. The action has no awareness of what format is being requested. It just puts data where the view can find it. A single attribute on the action handles format detection and output routing automatically.

<?php

use \Temma\Attributes\View;

class ProductController extends \Temma\Web\Controller {
    /**
     * The View attribute enables content negotiation:
     * HTML is rendered via a Smarty template, JSON is serialized automatically.
     */
    #[View(negotiation: 'html, json')]
    public function catalog() {
        $this['products'] = [
            ['id' => 1, 'name' => 'Widget Pro', 'price' => 49.99],
            ['id' => 2, 'name' => 'Gadget Plus', 'price' => 29.99],
        ];
    }
}

When the client sends Accept: text/html, Temma renders the Smarty template at templates/product/catalog.tpl. When the client sends Accept: application/json, Temma serializes the data as JSON. The action code is identical in both cases.

The attribute can be placed on the controller instead of the action, making it apply to all actions at once:

<?php

use \Temma\Attributes\View as View;

/**
 * Handles product-related pages and API endpoints.
 *
 * The View attribute enables content negotiation for all actions in this controller:
 * HTML is rendered via a Smarty template, JSON is serialized automatically.
 */
#[View(negotiation: 'html, json')]
class ProductController extends \Temma\Web\Controller {
    /** Returns the product catalog. */
    public function catalog() {
        $this['products'] = [...];
    }
    /** Returns a single product by ID.. */
    public function detail(int $id) {
        $this['product'] = [...];
    }
}

A note on terminology: in Temma, "view" is broader than a template. It is the component responsible for generating output in any format. The Smarty view renders HTML via templates. The JSON view serializes data. The same concept applies to CSV, RSS, iCal, and custom formats. Temma also supports more granular content negotiation with specific media types:

#[View(negotiation: [
    'json'             => '~Json',
    'text/csv'         => '~Csv',
    'application/pdf'  => '\App\View\PdfExport',
])]

When to use it, when not to
Content negotiation is a good fit when:

The HTML and JSON representations share the same underlying data
A mobile app or third-party client needs the same content your website already serves
You want to avoid maintaining a parallel API for simple read operations

It is not a good fit when:

HTML and JSON representations diverge significantly in structure or content
You need field selection, filtering by relation, or linked data (JSON:API, GraphQL)
You need strict API versioning or stability guarantees
Your API requires authentication schemes incompatible with your web session model

Content negotiation does not replace a dedicated API layer. It eliminates the need for one in cases where that layer would be redundant.

Who does this in production?
This is not a niche pattern. Discourse, the open-source forum platform, documents it explicitly: most endpoints serve the same content as HTML or JSON. /categories returns an HTML page in a browser, or a JSON payload when called with Accept: application/json or as /categories.json.

MediaWiki, which powers Wikipedia, uses the same approach in its REST API, serving JSON or HTML from the same endpoints depending on the Accept header.

The bigger picture
HTTP content negotiation is often overlooked because frameworks don't always surface it prominently. But it has been part of the web's foundation for decades, and the tooling to use it is already there.

For complex API needs, dedicated solutions like API Platform (built on Symfony) provide a complete content negotiation layer with versioning, subprotocol support, and strict media type handling. Content negotiation at the controller level and a full API framework are not in competition: they solve different problems at different scales.

Full docs on Temma's content negotiation: temma.net.

Calling OpenAI from a PHP framework the same way you query Redis or Memcache

Amaury — Thu, 19 Mar 2026 17:47:00 +0000

Temma is a PHP MVC framework designed to be easy to pick up and use. It sits between micro-frameworks (too bare) and full-stack ones (too heavy), and tries to get out of your way as much as possible.

One of its core concepts is the datasource: a unified way to declare and access any external connection, whether it's a database, a cache, a message queue, or an API. In Temma 2.16.0, OpenAI joins that list.

Most PHP tutorials on OpenAI integration involve installing a SDK, writing a service class, injecting it manually, and wiring everything together. It works, but it's a lot of plumbing for what is ultimately a remote call.

In Temma, OpenAI is a datasource. The same way you declare a Redis connection, you declare an OpenAI connection. One line in your config, and you're done.

Configuration

In etc/temma.php:

<?php

return [
    'application' => [
        'dataSources' => [
            'redis'  => 'redis://localhost',
            'openai' => 'openai://chat/gpt-4/sk-proj-xxxxxxxxxxxxx',
        ],
    ],
];

That's it. OpenAI sits alongside your database, your Redis cache, your S3 bucket, your Slack connection… Same pattern, same config file.

Basic usage

In any controller, you can access data sources using an array notation, or using methods:

// Set value in Redis
$this->redis['key'] = 'value';

// Get value from Redis
$value = $this->redis['key'];

For OpenAI, it's the same:

$openai = $this->openai;

// Simple prompt
$response = $openai['What is the capital of France?'];

// Or using the read() method
$response = $openai->read('Translate to French: Hello world');

// With a fallback value in case of error
$response = $openai->read(
    'Translate to French: Hello world',
    'Bonjour le monde'
);

System prompt and options

You can pass a system prompt and control temperature directly in the call:

$response = $openai->read(
    'Summarize this article in 3 bullet points: ' . $articleBody,
    null,
    [
        'system'      => 'You are a concise technical writer.',
        'temperature' => 0.3,
    ]
);

Multi-turn conversations

Temma's OpenAI datasource handles conversation history natively:

$response = $openai->read('And the capital of Italy?', null, [
    'system'   => 'You are a geography assistant.',
    'messages' => [
        ['role' => 'user', 'content' => 'What is the capital of France?'],
        ['role' => 'assistant', 'content' => 'The capital of France is Paris.'],
    ],
]);
// $response contains "The capital of Italy is Rome."

A practical example: auto-tagging articles

Here is a realistic use case: a controller action that generates tags for an article automatically.

<?php

use \Temma\Attributes\View   as TμView;
use \Temma\Attributes\Method as TμMethod;

#[TμView('~Json')] // use JSON view on all actions
class Article extends \Temma\Web\Controller {
    // create a DAO on the 'article' table
    protected $_temmaAutoDao = true;

    // POST /article/tag/1
    #[TμMethod('POST')] // accept POST requests only
    public function tag(int $id) {
        // get the article
        $article = $this->_dao->get($id);
        if (!$article)
            return $this->_httpError(404);
        // fetch the tags from OpenAI
        $tags = $this->openai->read(
            'Generate 3 comma-separated tags for this article: ' . $article['body'],
            null,
            [
                'system'      => 'You are a tagging assistant. Reply with exactly 3 tags, comma-separated, lowercase, no punctuation.',
                'temperature' => 0.2,
            ]
        );
        // update the article
        $this->_dao->update($id, ['tags' => $tags]);
        // return a JSON stream `{"tags": "tag1,tag2,tag3"}`
        $this['tags'] = $tags;
    }
}

No service class. No manual injection. The OpenAI connection is available in the controller exactly like the database connection, because from Temma's perspective, they are the same kind of thing: a datasource.

Why this matters

The datasource abstraction is one of Temma's core ideas. Whether you're talking to MySQL, Redis, S3, Slack, or OpenAI, the connection is declared in one place and accessed the same way throughout your code. Adding AI capabilities to an existing project becomes a config change and a few lines of code, not an architectural decision.

Temma is open source (MIT), has been in production since 2007, and the OpenAI datasource landed in the just-released 2.16.0. Full docs at temma.net.

µJS vs Turbo: same idea, different philosophy

Amaury — Wed, 11 Mar 2026 11:39:56 +0000

Turbo (part of Hotwire) and µJS solve the same problem: make server-rendered websites feel faster without rewriting the frontend in JavaScript. Both intercept link clicks and form submissions, fetch pages via AJAX, and inject content into the DOM.

The differences are in scope, weight, and how much they ask of your server.

Size

Library	Size (min + gzip)
µJS	~5 KB
Turbo	~25 KB

Turbo is 5× heavier. For a library whose primary job is "fetch a page and swap some HTML", that's a significant gap.

Build step

Turbo requires a build step — it's distributed as an npm package designed to be bundled. µJS doesn't:

<!-- µJS: drop-in, no bundler needed -->
<script src="https://unpkg.com/@digicreon/mujs/dist/mu.min.js"></script>
<script>mu.init();</script>

This matters for projects that deliberately avoid a JavaScript build pipeline — static sites, PHP/Python/Ruby apps, or any project where adding npm + a bundler is a step backwards.

Server-side requirements

This is the most important difference in practice.

µJS requires nothing from your server. It sends a standard HTTP request and expects standard HTML in return. Your existing pages work as-is.

Turbo has conventions. Turbo Drive (basic navigation) works like µJS. But Turbo Frames require your server to return specific <turbo-frame> elements. Turbo Streams — the equivalent of µJS's patch mode — requires your server to return <turbo-stream> custom elements wrapping content in <template> tags.

This means adopting Turbo Streams changes your server-side HTML output. With Rails and the Hotwire ecosystem, helpers handle this for you. With other backends, you're on your own.

Multi-fragment updates: patch mode vs Turbo Streams

Both libraries can update multiple parts of the page in a single response. The syntax tells the story.

µJS — patch mode:

The server returns plain HTML. Each fragment carries mu-patch-target and mu-patch-mode attributes:

<!-- Append new comment -->
<div class="comment" mu-patch-target="#comments" mu-patch-mode="append">
    <p>Great article!</p>
</div>

<!-- Update counter -->
<span mu-patch-target="#comment-count">14 comments</span>

<!-- Reset form -->
<form action="/comments" method="post" mu-patch-target="#comment-form">
    <textarea name="body"></textarea>
    <button>Submit</button>
</form>

Turbo Streams:

Each fragment must be wrapped in <turbo-stream> / <template>:

<turbo-stream action="append" target="comments">
    <template>
        <div class="comment">
            <p>Great article!</p>
        </div>
    </template>
</turbo-stream>

<turbo-stream action="update" target="comment-count">
    <template>14 comments</template>
</turbo-stream>

<turbo-stream action="replace" target="comment-form">
    <template>
        <form action="/comments" method="post">
            <textarea name="body"></textarea>
            <button>Submit</button>
        </form>
    </template>
</turbo-stream>

With µJS, the fragment is the content. With Turbo, each fragment requires a wrapper structure. The µJS approach has less boilerplate, and the HTML is directly readable as-is.

There's another practical advantage: with µJS, mu-patch-target attributes are ignored on initial page load. You can use the exact same HTML fragment in your normal page template and in your patch response.

HTTP methods

Turbo supports GET and POST only. µJS supports GET, POST, PUT, PATCH, and DELETE — directly on links, buttons, and forms via mu-method:

<!-- DELETE button -->
<button mu-url="/api/item/42" mu-method="delete"
        mu-mode="remove" mu-target="#item-42">
    Delete
</button>

<!-- PUT link -->
<a href="/api/publish/5" mu-method="put" mu-mode="none">Publish</a>

With Turbo, PUT/PATCH/DELETE require a workaround (hidden _method field or server-side routing conventions).

Triggers and polling

Turbo handles links and forms. That's it.

µJS adds mu-trigger, which lets any element initiate a fetch on any event:

<!-- Live search -->
<input mu-trigger="change" mu-debounce="300"
       mu-url="/search" mu-target="#results" mu-mode="update">

<!-- Poll every 5 seconds -->
<div mu-trigger="load" mu-repeat="5000"
     mu-url="/notifications" mu-target="#notifs" mu-mode="update">

<!-- Load on focus -->
<input mu-trigger="focus"
       mu-url="/suggestions" mu-target="#suggestions" mu-mode="update">

Real-time: SSE

Both libraries support Server-Sent Events. µJS has it built-in and reuses the same patch syntax:

<div mu-trigger="load" mu-url="/stream"
     mu-method="sse" mu-mode="patch"></div>

The server pushes standard HTML fragments with mu-patch-target attributes — the same format as a regular patch response. Nothing new to learn.

Turbo Streams can be delivered over SSE, but you're still working with the <turbo-stream> / <template> format, and the server must produce that structure.

When Turbo makes more sense

Turbo is the right choice if:

You're in the Rails / Hotwire ecosystem — the integration is deep, the helpers are mature, and the community is large
You need Turbo Native for iOS/Android apps
Your team is already familiar with Turbo conventions

Outside the Rails ecosystem, Turbo's conventions become overhead without the ecosystem benefits.

Summary

	µJS	Turbo
Size	~5 KB	~25 KB
Build step	None	Required
Server changes needed	No	For Frames and Streams
Multi-fragment updates	Patch mode (plain HTML)	Turbo Streams (`<turbo-stream>`)
HTTP methods	GET/POST/PUT/PATCH/DELETE	GET/POST
Triggers on any event	Yes	No
Debounce / Polling	Built-in	No
SSE	Built-in	Built-in
Rails ecosystem	No	Yes

µJS is a focused library: drop it in, call mu.init(), and your site gains AJAX navigation with no server changes. If you need more, the attributes are there. If you don't, you don't pay for them.

Live playground — test each feature interactively
Full comparison: µJS vs Turbo vs htmx
GitHub
npm: npm install @digicreon/mujs

µCSS: I built a full-featured CSS framework on top of PicoCSS

Amaury — Wed, 11 Mar 2026 08:24:45 +0000

For over a decade, I used Bootstrap for all my projects. It's solid and well-documented, but over time I found myself increasingly frustrated, especially with themes. Most of them pull in dozens of JavaScript libraries and fonts you don't need, and cleaning that up takes forever.

So last year I started looking for something lighter.

Discovering PicoCSS

I reviewed a lot of alternatives: Pure, Chota, Milligram, Bulma, UIkit, Skeleton, Simple.css, MVP.css, and many others. Most were either abandoned, too bare-bones, or just not pleasant to look at.

I ended up choosing PicoCSS. It's beautiful, semantic, accessible, and weighs only 11KB. Most HTML elements look great with zero CSS classes. For simple projects, it's perfect.

But PicoCSS intentionally stays minimal. No grid system. No modal, no tabs, no toast, no breadcrumb, no badge. For anything beyond a basic page, you're on your own.

The gap

I maintain a PHP framework called Temma, and I was working on a UI component library for it. Adapting components to PicoCSS meant building most of them from scratch: the grid, modals, tabs, alerts, cards, navigation...

At some point it became obvious: I had built enough pieces to assemble a proper CSS framework. One that uses PicoCSS as a stable foundation, and adds everything it omits.

µCSS

That's what µCSS is: PicoCSS v2 + the missing parts.

17 UI components — Accordion, Alert, Badge, Breadcrumb, Button, Card, Forms, Hero, Modal, Nav, Pagination, Progress, Skeleton, Spinner, Table, Toast, Tabs
12-column responsive grid — 5 breakpoints, offsets, ordering, display utilities
20 color themes — one self-contained CSS file per theme
Utility classes — color (text, background, border), positioning (sticky, fixed)
Dark mode — automatic (prefers-color-scheme) or manual (data-theme)
~19KB gzipped — smaller than Bootstrap (~30KB)
Pure CSS — no JavaScript dependency
No build step — no Node.js, no SASS, nothing to compile

Usage is a single <link> tag:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@digicreon/mucss/dist/mu.css">

Or pick a specific theme:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@digicreon/mucss/dist/mu.violet.css">

Available themes: azure (default), red, pink, fuchsia, purple, violet, indigo, blue, cyan, jade, green, lime, yellow, amber, pumpkin, orange, sand, grey, zinc, slate.

The result

The site mucss.org uses µCSS itself (along with µJS, a lightweight alternative to HTMX that I also built).

GitHub: https://github.com/Digicreon/muCSS
Themes: https://mucss.org/themes

Happy to discuss design decisions or answer questions.

Make your server-rendered website feel like an SPA — with 5KB of JavaScript

Amaury — Tue, 10 Mar 2026 13:13:26 +0000

Make your server-rendered website feel like an SPA — with 5KB of JavaScript

You've built a server-rendered website. PHP, Python, Ruby, Go — doesn't matter. It works. It's fast. It's SEO-friendly.

But every link click triggers a full page reload. The browser flashes white. The scroll position resets. Users notice.

The usual answer is: "rewrite everything in React." That's overkill. There's a lighter path.

What µJS does

µJS intercepts link clicks and form submissions, fetches pages in the background with the fetch() API, and swaps the content — without a full page reload. Navigation feels instant. The URL updates. Back/forward buttons work.

That's the core. No framework. No build step. No server changes.

~5 KB gzipped
Zero dependencies
Works with any backend

Let's walk through a concrete example, step by step.

Step 1: A plain HTML website

Here's a minimal site with two pages and a navigation bar.

index.html:

<!DOCTYPE html>
<html>
<head>
    <title>My site</title>
    <link rel="stylesheet" href="/style.css">
</head>
<body>
    <nav>
        <a href="/">Home</a>
        <a href="/about">About</a>
        <a href="/contact">Contact</a>
    </nav>
    <main id="content">
        <h1>Home</h1>
        <p>Welcome.</p>
    </main>
</body>
</html>

Clicking "About" reloads the entire page. The nav bar re-renders, the stylesheet re-fetches, the layout flickers.

Step 2: Add µJS

Add one script tag at the end of <body>, and call mu.init():

<body>
    <!-- your content -->
    <script src="https://unpkg.com/@digicreon/mujs/dist/mu.min.js"></script>
    <script>mu.init();</script>
</body>

That's it. Every internal link (URLs starting with /) is now intercepted. Clicking "About" fetches /about via AJAX and swaps the entire <body> — no full reload, no flash, no scroll reset.

The browser history is updated. Back and forward buttons work. Your backend doesn't change.

Step 3: Update only the content area

Swapping the entire <body> works, but if your nav bar is complex (active states, dropdowns…), you may want to update only the <main> block.

Use mu-target and mu-source:

<a href="/about" mu-target="#content" mu-source="#content">About</a>

µJS fetches /about, extracts #content from the response, and replaces the current #content. The nav bar is untouched.

You can also set this globally in mu.init() to avoid repeating it on every link:

mu.init({
    target: "#content",
    source: "#content"
});

Step 4: Handle forms

µJS intercepts form submissions automatically. A GET form behaves like a link:

<form action="/search" method="get"
      mu-target="#content" mu-source="#content">
    <input type="text" name="q" placeholder="Search…">
    <button type="submit">Search</button>
</form>

A POST form works too — data is sent as FormData, and the response replaces the target:

<form action="/comment" method="post">
    <textarea name="body"></textarea>
    <button type="submit">Post comment</button>
</form>

HTML5 validation (required, pattern…) is checked before the request is sent. No extra code needed.

Step 5: Live search

Want search results to update as the user types? Use mu-trigger and mu-debounce:

<input type="text" name="q"
       mu-trigger="change"
       mu-debounce="300"
       mu-url="/search"
       mu-target="#results"
       mu-source="#results"
       mu-mode="update">

mu-trigger="change" fires on every keystroke
mu-debounce="300" waits 300ms after the user stops typing before sending the request
mu-mode="update" replaces the inner content of #results (not the element itself)

Your /search endpoint returns plain HTML. No JSON, no JavaScript on the server side.

Step 6: Update multiple fragments at once (patch mode)

Sometimes one action needs to update several parts of the page: add a comment, increment a counter, clear the form. That would normally require multiple requests or a JSON API.

With patch mode, the server returns a single HTML response with multiple fragments, each annotated with a target:

Link or form:

<form action="/comment" method="post" mu-mode="patch">
    <textarea name="body"></textarea>
    <button>Send</button>
</form>

Server response:

<!-- Append the new comment to the list -->
<div class="comment" mu-patch-target="#comments" mu-patch-mode="append">
    <p>The new comment</p>
</div>

<!-- Update the comment counter -->
<span mu-patch-target="#count">42 comments</span>

<!-- Reset the form -->
<form action="/comment" method="post" mu-patch-target="#comment-form">
    <textarea name="body"></textarea>
    <button>Send</button>
</form>

Three DOM updates, one HTTP request, no JavaScript on the client side.

Step 7: Real-time updates with SSE

Need live updates without polling? µJS supports Server-Sent Events:

<div mu-trigger="load"
     mu-url="/notifications/stream"
     mu-method="sse"
     mu-mode="patch">
</div>

The server pushes HTML fragments over the SSE connection. µJS renders them using patch mode. No WebSocket setup, no client-side message parsing.

Bonus: prefetch on hover

Prefetch is enabled by default. When the user hovers over a link for 50ms, µJS starts fetching the page in the background. By the time they click, the content is ready. This typically saves 100–300ms of perceived loading time — for free.

Disable it per-link if needed:

<a href="/heavy-page" mu-prefetch="false">Heavy page</a>

What you get without changing your backend

Feature	How
AJAX navigation	`mu.init()`
Fragment update	`mu-target` + `mu-source`
Live search	`mu-trigger` + `mu-debounce`
Multi-fragment update	`mu-mode="patch"`
Real-time push	`mu-method="sse"`
Prefetch on hover	Enabled by default
Progress bar	Enabled by default
View Transitions	Enabled by default
DOM morphing	Auto-detected (idiomorph)
Back/forward buttons	Built-in

Try it

Live playground — test each feature interactively, with the page HTML, server response, and live result side by side
Documentation
GitHub

npm install @digicreon/mujs

Or via CDN:

<script src="https://unpkg.com/@digicreon/mujs/dist/mu.min.js"></script>

µJS is MIT licensed, ~5KB gzipped, zero dependencies. Carson Gross (creator of htmx) listed it on the htmx alternatives page.

If you have questions about design decisions or how it compares to HTMX/Turbo, happy to discuss in the comments.