Pattern
Dashboards.
A dashboard often has a large amount of shared document/navigation structure plus a smaller set of genuinely dynamic regions. Nift can generate the stable shell while ordinary browser code owns live state.
Shared shell
<body>
@input('templates/partials/dashboard-nav.html')
<main class="dashboard">
@content
</main>
<script type="module" src="@pathto('public/assets/dashboard.js')"></script>
</body>
Page content can define mount points
<h1>System status</h1>
<section id="service-health"></section>
<section id="recent-events"></section>
Vanilla JS, React, Vue or Svelte can own the live UI
const response = await fetch('/api/status');
const data = await response.json();
document.querySelector('#service-health').textContent =
data.ok ? 'Operational' : 'Degraded';
If the interaction grows complex, replace that browser module with a bundled framework entry point without changing Nift's role in the surrounding page.
Realtime updates
const socket = new WebSocket('/ws');
socket.addEventListener('message', ({ data }) => {
const event = JSON.parse(data);
renderEvent(event);
});The Nift-generated shell does not care whether runtime data arrives through fetch, Server-Sent Events or WebSockets.
Framework-backed dashboard
If dashboard state becomes sophisticated, compile a React/Vue/Svelte application into public/assets/dashboard.js and keep the same Nift shell. The architectural boundary can evolve without rewriting the surrounding site.
Dashboard navigation as a partial
<aside class="dashboard-nav">
<a href="\@pathto('dashboard')">Overview</a>
<a href="\@pathto('dashboard/logs')">Logs</a>
<a href="\@pathto('dashboard/settings')">Settings</a>
</aside>Shared navigation stays generated and reusable even when the panels themselves are driven by runtime API data.
Backend freedom
The API can be Go, Express, Bun, FastAPI, C++, serverless functions or something else entirely. Nift does not participate in the runtime request after it has produced the frontend files.