Introduction

imba-pages turns a folder of Imba files into a website. Every file in src/pages is a page, rendered on the server, and the build writes plain HTML and CSS that any static host can serve.

# src/pages/about.imba  →  /about
export const meta = {title: 'About us'}

export default tag AboutPage
	<self>
		<h1[fs:3xl]> "About us"
		<p> "Every file in src/pages is a page."

What you get

• Pages are files. src/pages/about.imba is /about, src/pages/blog/[slug].imba is every blog post. Markdown files are pages too.
• Static by default. imba-pages build writes a dist/ folder of HTML and CSS. No server to run, so it's fast, cheap and hard to break.
• Islands. Pages ship no JavaScript, except the components you put in src/islands/, and only on the pages that use them.
• Content. Markdown pages, and collections of Markdown/JSON/YAML files with field checks, for services, case studies or docs (like these).
• SEO built in. Canonical links, social sharing tags, structured data, sitemap.xml and robots.txt, driven by each page's meta.
• Imba all the way. Templates, scoped css blocks, inline [css], components.

What it's for

Sites that are mostly content: a business's brochure site, a portfolio, a personal site, documentation. If you'd reach for Astro, Eleventy or Hugo but want to write Imba, this is for you.

It's not an app framework: there's no client-side router, no database layer, no user accounts. For those, Imba with a backend (Rails, Node) is the better fit.

Compared to Astro

imba-pages borrows Astro's best ideas: file routing, static output, islands, content collections. The differences:

This site

These docs are an imba-pages site: Markdown files in a collection, rendered by one .imba template with the sidebar you see. It lives in site/ in the repo.

Next: Installation.