Beyond the core

Nift as the glue, not the universe.

Nift does not need its own replacement for every tool in web development. Let Nift handle tracked outputs, templates, partials, paths and incremental builds; let TypeScript, React, Vue, Svelte, Vite, Tailwind, Go, Node, Python and the rest of the ecosystem keep doing what they already do well.

Plain HTML + CSS + JavaScript

The simplest integration is no integration at all: keep ordinary assets in the public tree and reference them from Nift templates.

<link rel="stylesheet" href="@pathto('public/assets/css/style.css')">
<script src="@pathto('public/assets/app.js')"></script>

Using @pathto for those concrete local paths gives generated pages the correct relative URL and lets Nift fail the build when the referenced file does not exist.

npm or Bun + TypeScript

Package management and TypeScript compilation can remain completely conventional. Compile TypeScript into Nift's public assets, then reference the result.

{
  "scripts": {
    "build:js": "tsc",
    "build:site": "nift build",
    "build": "npm run build:js && npm run build:site"
  }
}

<script type="module" src="@pathto('public/assets/js/app.js')"></script>

With Bun the same idea can use bun run or bun build. Nift does not care which package manager produced the asset.

Vite as the frontend asset pipeline

Vite can own JavaScript/TypeScript bundling and development-oriented frontend tooling while Nift owns page composition.

project/
  content/
  templates/
  frontend/
    src/
    package.json
    vite.config.js
  public/
    assets/
  .nift/

npm --prefix frontend run build
nift build

Configure Vite's output where it makes sense for your project—commonly somewhere under public/assets/—and Nift templates can reference those built files normally.

Tailwind CSS

Tailwind can scan the HTML/templates you actually author and emit CSS into the output tree. Nift only needs to link to the generated stylesheet.

npx @tailwindcss/cli -i ./assets/input.css -o ./public/assets/css/site.css
nift build

<link rel="stylesheet" href="@pathto('public/assets/css/site.css')">

React, Vue or Svelte where you want richer UI

Nift does not require the whole page to become a client framework application. A bundler can produce a React/Vue/Svelte entry point for a particular interactive region while Nift continues generating the surrounding document.

<main>
  @content
</main>

<div id="account-dashboard"></div>
<script type="module" src="@pathto('public/assets/dashboard.js')"></script>

The component framework owns the interactive region. Nift owns the document structure around it. If your application genuinely wants React/Vue/Svelte to own nearly everything, Nift can instead be used for the portions where its templating/build model remains useful.

Go backend

my-app/
  content/
  templates/
  public/
    assets/
  backend/
    main.go
    api/
  .nift/

Nift can generate the frontend files that your Go service serves, while browser JavaScript talks to the backend API in the usual way.

const response = await fetch('/api/status');
const status = await response.json();

No Nift-specific Go integration is required.

Node + Express

An Express application can serve Nift's public directory and provide APIs beside it.

import express from 'express';

const app = express();

app.use(express.static('output'));

app.get('/api/health', (req, res) => {
  res.json({ ok: true });
});

app.listen(3000);

Python backends

The same boundary works with Flask, FastAPI, Django or another Python stack: generate frontend assets/pages with Nift, serve them from the Python application or a web server/CDN, and expose APIs normally.

Nift: templates + pages + static frontend output
Python: application runtime + APIs + database + authentication
Browser: ordinary HTTP between them

Minifiers, image tools and bundlers

Tools such as esbuild, Rollup, SWC, terser, lightningcss, PostCSS, Sass, image optimisers and custom scripts can run before or after Nift depending on what they transform.

# One possible production pipeline
npm run build:frontend
nift build-all
npm run minify:html

There is no requirement for a “Nift plugin” merely to use a tool. If it can read and write files, it can usually compose with Nift.

When @dep actually belongs

Do not add @dep just because another tool produced a CSS or JavaScript file that you reference with @pathto. Use @dep for the narrower case where an external file influences a generated output but Nift otherwise has no relationship from which to know that.

@dep('data/generated-navigation.json')

A repository can contain several worlds

product/
  site/                 # Nift content/templates
  frontend/             # TypeScript + Vite + React
  server/               # Go / Node / Python
  scripts/              # build/minification/image tooling
  public/               # assembled web output
  package.json
  Makefile

Your top-level build script, Makefile, package scripts or CI workflow can orchestrate those pieces. Nift does not need to absorb them into its own language to work with them.