Franklin.jl, a static site generator built for technical writing

A generator aimed at pages with mathematics and code

Franklin is a static site generator in Julia, and the description in the repository is blunt about what kind of project it is, another static site generator, simple, customisable, fast, with maths through KaTeX, code evaluation and optional pre-rendering, in Julia. The README is more specific about the orientation, a static site generator oriented towards technical blogging with code and maths, towards flexibility and towards extensibility. That focus is what separates it from a general purpose site generator, and it explains the two extensions the base syntax adds to plain markdown. The first is the ability to define and use LaTeX-like commands, both inside and outside maths environments, and the second is the possibility of evaluating code blocks on the fly. The lifecycle badge on the project page says maturing, which is an honest word for a generator that is used in production by large sites but whose author is still asking for help on parts of it. The audience is a technical writer or a teacher who publishes derivations and programs.

Markdown, plus three things a technical page needs

The key feature list reads as a list of additions to markdown rather than a replacement for it. Standard markdown is the base, with the possibility of using LaTeX-style commands and generating functions written in Julia, so a symbol can be defined once and used in prose and in maths. The second addition is a simple way to introduce div blocks, which is what makes styled callouts such as Theorem boxes possible without writing raw HTML in every post. The third is that Franklin can execute and show the output of Julia code blocks, which means the code in a page is the code that ran. On the output side there is easy HTML templating to define or adapt a given layout, custom RSS generation, and a website optimisation step that compresses the generated HTML and CSS and can optionally pre-render KaTeX and highlighted code blocks to remove the javascript dependency. The pre-rendering option is the interesting one, since it trades a build time cost for a static page with no client side maths library, and it is also the feature the README now advises against.

The deployment warnings come before the feature list

The README has an Important notes section that is worth more attention than most projects give theirs, because both notes describe ways to lose an afternoon. The first is about CSS. If, after deployment, the site does not seem to apply CSS, you probably forgot a step, and the documentation points to a specific page on creating a repository on GitHub. The second is a direct recommendation to switch off pre-rendering and minification, which is done by passing two keyword arguments to the optimize call in your deploy script.

prerender=false, minify=false

The reason given is that the corresponding logic will be removed in a future version of Franklin, because it is tricky to maintain and caused too many issues. That is a stronger statement than a deprecation notice, and it means a site that depends on pre-rendering today is depending on a feature the project intends to delete. The third note is a relief rather than a warning. If you get messages about some JS library not being found on your computer, you can safely ignore them.

Two kinds of site: adapted templates and custom ones

The examples list is split into sites built from one of the available themes in FranklinTemplates.jl and sites that migrated an existing design, and the second group is the more telling. The Julia website, including the blog, is deployed using Franklin, and Circuitscape's site was migrated from Jekyll, PkgPage.jl is a front page generator built on Franklin, and JuliaCon's site is there too. In the adapted group are Franklin's own site, the MLJ tutorial site showing how Franklin interacts with Literate.jl, the SciML organisation site, the MIT Introduction to Computational Thinking course site, and the SymbolicUtils manual using the Tufte template. The maintenance note is worth repeating because it is a candid statement about the state of the project. The author is looking for people with web development skills who would be keen to help improve and enrich the base themes in FranklinTemplates.jl, and says explicitly that you do not need to be confident in Julia to help, and that a request to work on something in either Franklin or FranklinTemplates will be answered on Slack. Support is the #franklin channel on the Julia Slack.

The documentation is the project's front door

For a project whose selling point is extensibility, the documentation does the work of showing what is possible. The main website is franklinjl.org, there is a set of demos for users already familiar with Franklin, and the repository's own docs/ directory holds the documentation for the site, since Franklin's own website is written in Franklin, which is a nice self reference. A third party blog post by Ifihan Olusheye about building a blog with Franklin is linked as well, which is useful for seeing a whole site from the outside rather than one feature at a time. The repository listing matches the shape of a Julia package rather than a site, with src/, test/, docs/, demos/, a Project.toml for the dependencies, a .codecov.yml and a LICENSE.md. The CI and coverage badges sit in the header next to the lifecycle badge, so the build status of the code and the maturity statement of the project are visible at the same time, which is the combination you want when you are deciding whether to base a site on it.

A slow release line and a permissive licence

The release history is unusual for a project with this profile, and it is worth understanding before you pin a version. The tags are v0.10.95 from 2023-11-07, v0.10.96 from 2025-06-05 and v0.10.97 from 2025-10-14, so the version has not reached 1.0 and the gaps between releases have been months long rather than days. The repository is not archived and the last push was on 2026-10-16, so work continues on the branch even though the tags are infrequent, which means a version you pin is a snapshot rather than a moving target. The licence is MIT, recorded in LICENSE.md, which is permissive enough for a company to publish a site built with it without obligations beyond keeping the notice. The practical consequence of the whole picture is that a team choosing Franklin is choosing a project with a small but active maintainer, an improving but explicitly unfinished template collection, and a generator whose feature set is stable enough to rely on while the deployment advice tells you to turn two of its options off.

Editorial conclusion

Franklin fits a technical writer who publishes mathematics and code, especially a Julia user who wants the code in a page to run at build time and the maths to be authored once and rendered, and it fits a team that wants a site whose own source is the site. It does not fit a writer who wants a batteries included theme system with no work, since templates are a separate project that the author is still looking for help with, and it does not suit a deployment that depends on pre-rendering, since the project recommends switching that off and plans to remove the logic. Verify three things first: that your maths and code workflow fits the markdown extensions, in particular whether you want your code executed on every build, that the template you plan to start from is in FranklinTemplates.jl rather than something you will write yourself, and that the deploy settings you copy do not still enable pre-rendering and minification, which the project asks you to turn off.

Frequently asked questions

Official sources

1. JuliaDocs/Franklin.jl on GitHub
2. License: MIT
3. Project website
4. README
5. Releases