Open-source project
jktrn/astro-erudite avatar
jktrn/astro-erudite

astro-erudite is an Astro blog template with no UI framework and no CSS framework

An opinionated, unstyled static blogging template built with Astro and native CSS.

866 stars83 forksAstroMIT

At a glance

What is it?
astro-erudite is an opinionated, unstyled static blogging template built with Astro and native CSS, using autonomous custom elements, the Rust based Sätteri Markdown processor, Expressive Code and Temml for math. It runs on Bun with Astro 7 and Node 22, it is at version 2.0.1, and migrating from v1 means reading the breaking changes first.
Who is it for?
Adopt astro-erudite if you want a personal blog or portfolio that ships with a reading experience already designed, and you are prepared to work inside its opinions: native CSS with custom elements, a Rust Markdown processor and Bun as the package manager. Do not adopt it if you need a component library, a utility-first CSS workflow, or a framework-agnostic setup, since the whole template is deliberately opinionated on those points.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 5 days ago.
What is it written in?
Mainly Astro, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 24, 2026, and from our analysis. They are not legal advice.

Editorial analysis

No UI framework, no CSS framework, minimal dependencies

astro-erudite is described as enscribe's opinionated, unstyled static blogging template, built with Astro and native CSS. The README makes the two absences explicit: it uses no UI framework and no CSS framework, and contains minimal dependencies.

That statement is the reason the template exists. Astro projects are often assembled around a component library and a utility CSS framework, and a blog built that way inherits the runtime weight of both. This one does not.

What replaces them is a design system written in native CSS, built on autonomous custom elements and the Utopia fluid type and space scales. Autonomous custom elements are the web components model, so the template's components are plain custom elements rather than a framework's components, and the Utopia scales give typography and spacing a fluid rule instead of fixed breakpoints.

The dependency list in package.json backs the claim. There are Astro packages, the Markdown integration, the RSS and sitemap integrations, two Expressive Code plugins, the Expressive Code bridge for Sätteri, and Temml for math. The tooling is Astro check, Biome and TypeScript.

The audience is someone publishing a personal blog, a portfolio or an academic site who wants the reading and writing experience already settled and cares about how much ships to the browser.

Bun for install and dev, Astro 7 for the build

The toolchain is Bun for the package manager and the dev server, with Astro 7 doing the building. The repository carries a bun.lock file, which tells you the lockfile format the template expects.

Getting started is four steps. You create a repository from the template with the Use this template button, clone it, install the dependencies and start the dev server:

bash
git clone https://github.com/[YOUR_USERNAME]/[YOUR_REPO_NAME].git
cd [YOUR_REPO_NAME]
bash
bun install
bash
bun dev

The dev server runs on port 4321, so http://localhost:4321 is the address to open. The other commands in the table are the usual trio:

bash
bun run build
bun run preview
bun run astro

The build produces a static site in dist/, the preview command serves that built output locally, and the astro command passes through to the Astro CLI.

One detail worth checking before you start: the package.json engines field requires Node 22.12.0 or newer. Astro itself is pinned at ^7.0.2, and the build script is astro check followed by astro build, so type checking runs as part of every production build rather than as a separate lint step.

Formatting is handled by Biome, with a format script that writes and a format:check script that only reports. There is a biome.json at the top of the repository.

Sätteri for Markdown, Expressive Code for code blocks

The Markdown pipeline is where the template makes an unusual choice. The README calls Sätteri the ridiculously fast Markdown processor and notes that it is written in Rust, and the dependency list confirms it with @astrojs/markdown-satteri and satteri-expressive-code.

Code blocks are handled by Expressive Code, with support for code{:lang} annotations and TextMate scope highlighting. The two Expressive Code plugins in the dependencies add collapsible sections and line numbers, so those are opt-in extras rather than defaults.

The combination is what makes the template feel different from a standard Astro blog. A Markdown processor that is not JavaScript means the parsing work happens outside the JavaScript runtime, and the Expressive Code bridge ties the Rust processor's output into the rendering pipeline instead of bolting highlighting on afterwards.

The practical consequence for you as an author is that your code fences are rendered by Expressive Code with its own options, not by whatever highlighter Astro's Markdown configuration would otherwise use. If you are migrating from another blog, that is one of the differences you will notice first.

Math, callouts and subposts for writing

Three features target the writing side of a blog.

The first is mathematics. LaTeX is rendered to browser-native and lightweight MathML through Temml, which means the output is MathML in the document rather than an image or a client-side typesetting step.

The second is callouts. The template supports GitHub-style callouts and alerts through ::: directives, so a note or a warning in a post is written the same way you would write it in a GitHub issue.

The third is subposts. These exist to organise a series, and the README describes how they are rendered: as one continuous scrollable document rather than as separate pages. That is a different reading experience from a series of linked posts, and it means a long argument can be split across files for editing and still read as one piece.

Together these point at a specific kind of blog. A personal site with long-form writing, mathematics where it helps, series that are meant to be read end to end, and notes that look the way notes look in a repository.

The reference for the full feature list and the exact syntax is the user guide on the template's own site, and the README points there rather than duplicating it.

Scrollspy table of contents, anchors and per-post SEO

The reading side gets the same treatment.

The table of contents is fully responsive and highlights the current section with scrollspy behaviour, so a long post shows where you are in it. Heading anchors are clickable, which makes every section of a post linkable as a permalink.

SEO is handled with granular metadata and Open Graph tag control for each post, plus RSS feed and sitemap generation through the @astrojs/rss and @astrojs/sitemap integrations.

Content structure has its own pages. Author profiles get a dedicated authors page, and posts support multiple authors. Tags get a tags page for categorisation and discovery. These are the pages that make a blog feel like a site rather than a feed, and the reason a template that ships them saves a surprising amount of work.

The last entry in the feature list is worth singling out for anyone who has run a blog before: the list of community sites built on the template, with tags such as minimal, portfolio, blog, interactive, sci-fi, academic, bento and ascii. It is also a practical instruction. The README asks you to open a pull request if you want your site added, so the list doubles as the template's gallery.

What the alternative looks like, and why the opinions matter

The other common route to the same result is a bare Astro project assembled with a CSS framework and a component library, which is what the README is positioning against.

The difference in approach is not cosmetic. A utility-first setup gives you a large ecosystem of prebuilt patterns, ready-made components and a familiar utility vocabulary, and you keep the framework's release cycle as a dependency. This template gives you a small dependency list, a design system you read as plain CSS and custom elements, and a Markdown processor that runs outside JavaScript.

The trade is direct. You inherit the author's opinions, including the specific type and space scales, the callout syntax, the subpost model and the Rust Markdown pipeline. If you like them, the work is done. If your brand requires a component library, or your team cannot maintain a custom CSS design system, or you need to change how code blocks are rendered, you are fighting the template rather than using it.

That is also why the migration note matters. The README flags that the template has recently been updated to v2, points to a blog post explaining what changed and why, and links a breaking changes section for people migrating an existing v1 project. A template with strong opinions changes its opinions between major versions, and the v1 to v2 jump is exactly where the reading experience and the file layout moved.

Version 2.0.1, MIT licence, and the shape of the repository

The release history is short and recent. Version 1.6.3 was published on 2025-09-07, version 2.0.0 on 2026-06-06 and version 2.0.1 on 2026-06-12, and the last push to the default branch was on 2026-10-19. The repository is not archived.

The layout is a typical Astro project: astro.config.ts at the top, tsconfig.json, biome.json, a src directory, a public directory with the static assets including the open graph image and preview screenshots, and the bun.lock file. The package.json version is 2.0.1, matching the latest release.

The licence is MIT, which makes it the easy case for reuse. You can fork it, change it, publish a derived site, and use it commercially, and the only obligation is keeping the licence and copyright notice with it. For a template that people build personal portfolios on, that is the right choice, and the community list shows people do exactly that.

One practical habit follows from the structure rather than the licence. The template is meant to be used with the Use this template button so that you own your repository outright, and the git clone step in the getting started guide assumes that. Forking from the upstream repository instead means your site inherits the template's history and its upgrade path, which for a v2-era template with breaking changes is a decision you should make deliberately rather than by accident.

Editorial conclusion

Adopt astro-erudite if you want a personal blog or portfolio that ships with a reading experience already designed, and you are prepared to work inside its opinions: native CSS with custom elements, a Rust Markdown processor and Bun as the package manager. Do not adopt it if you need a component library, a utility-first CSS workflow, or a framework-agnostic setup, since the whole template is deliberately opinionated on those points. Before you start, read the v2 breaking changes if you are moving an existing v1 site, confirm your machine runs Node 22.12.0 or newer because package.json states it as an engine requirement, and try bun dev first so you can see the design before you commit to the template.

Frequently asked questions

How do I start a blog with astro-erudite?

Create a repository with the Use this template button, clone it, run bun install and then bun dev, and open http://localhost:4321. For a production build use bun run build, which writes a static site to dist/, and bun run preview serves that output locally.

Does astro-erudite use Tailwind or a UI component library?

No. The README states that the template uses no UI framework and no CSS framework, and its design system is built on native CSS with autonomous custom elements and Utopia fluid type and space scales. The dependency list contains no CSS or component framework.

What changed in astro-erudite v2?

The README points to a blog post titled Introducing astro-erudite v2 for what changed and why, and to a breaking changes section for people migrating an existing v1 project. Version 2.0.0 was published on 2026-06-06 and 2.0.1 on 2026-06-12.

What runtime does astro-erudite need?

The package.json engines field requires Node 22.12.0 or newer, and the project is developed with Bun for installs and the dev server, with a bun.lock file. The Astro version used is 7.0.2 and the production build runs astro check before astro build.

Official sources

  1. jktrn/astro-erudite on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/jktrn-astro-erudite.svg)](https://hysenlabs.com/projects/jktrn-astro-erudite)

Was this useful?