Pannonico is a static site generator I have been building around the way I actually want to work on static sites.
For many years I have been using Pannini static site builder from Zurb and their Foundation framework. I loved it for its simplicity and speed, and have been using it for more than 10 years until I finally decided to make a modern solution.
Pannonico is written in Go and works with HTML or Markdown, layouts, partials and structured data. Vite is a first class citizen in Pannonico and can remain part of the same build when a project needs frontend assets, without turning the whole site into a JavaScript application. This gives you a very fast build for static pages and total freedom to build or use any kind of frontend framework, or even just plain ol' JS! :)
The CLI can be installed directly or used through npm. Pannonico also has an MCP server for AI-assisted development, plus a VS Code extension and language server for project-aware editor support.
The Free edition is already public, and I have been spending some time measuring and improving the build pipeline to produce as smooth experience as possible.
Attached table shows a preview from the current 10,000-page benchmark, measured in pages per second. Build process adapts to your hardware, so it will scale with its capabilities.
| Workload | Pannonico | Hugo | Eleventy |
|---|---|---|---|
| With templates | 2,045 | 1,874 | 1,189 |
| Templates + data | 1,689 | 1,897 | 1,257 |
| Templates + data + Vite | 1,603 | — | — |
- NPM plugin: https://www.npmjs.com/package/pannonico
- VSCode plugin: https://marketplace.visualstudio.com/items?itemName=vx-rs.pannonico
- Documentation: https://github.com/vx-rs/pannonico/tree/master/docs
This is not an official launch since the project is still in beta, and a lot can change, but I want to showcase how far I've got.
Other interesting features this CLI tool possess:
- CSS inlining, good for encapsulated HTML pages or HTML emails
- Numerous markdown improvements, like footnotes, or special blocks like warnings, errors, or whatever you want them to be
- Image optimization, similar to one used on tinypng.com - compression without quality loss
- Vite integration, not just as a frontend tool, but in a way that you can actually reference assets defined in Vite itself
- Pluralization and translation options
- ...and more, all in documentation
...
To be honest, someone told me that I can't do it, and I said - hold my beer. :)
I am a web developer for 25+ years, with focus on frontend, developer tooling and UI design. This is my serious take at AI assisted development. My intention is to keep developing this as long as I am able to work, to create a stable and "boring" software you can depend on, like I was able to depend on Panini, once upon a time.
If anyone from Zurb is reading this - thank you!
Top comments (9)
This is a really compelling direction, especially because you’re not trying to turn static-site generation into another JavaScript framework.
The architectural choice to keep HTML/Markdown, layouts, partials, and structured data at the center while treating Vite as an optional first-class build component makes a lot of sense. It preserves the simplicity that made tools like Panini valuable while addressing the realities of modern frontend workflows.
The benchmark is particularly interesting. The 10,000-page results suggest Pannonico is already competitive with Hugo and ahead of Eleventy in several workloads, while the Vite integration demonstrates that the architecture can handle a more realistic asset pipeline without forcing an SPA model.
I also like the emphasis on predictable, “boring” software. For developer tooling, long-term stability, deterministic builds, excellent error messages, incremental builds, and reproducibility often matter more than having an enormous feature set.
The areas I’d be especially interested in watching as the project matures are incremental rebuild performance, caching strategy, determinism across environments, plugin/API stability, and how the MCP integration handles project context without making the development workflow unnecessarily complex.
25+ years of frontend experience combined with modern tooling and AI-assisted development is a strong foundation for this kind of project. It feels less like “another static generator” and more like an attempt to preserve the best parts of the old workflow while removing the friction accumulated over the years.
Definitely worth following as the beta evolves. If you're open to connecting with developers/teams interested in tooling and long-term collaboration, feel free to reach me on @TG_coolsoftDev. I’d be interested in staying connected and seeing where Pannonico goes.
Thanks Kane, lets be in touch. I don't use Twitter, if this is what you meant, but you can find me on BlueSky here bsky.app/profile/jovanovic.bsky.so... or on Github github.com/vsjov
I don't use it.
then how we can do real-time chat.
Send me your LinkedIn account, we can connect and chat through that platform. I am not using much else besides BlueSky and LinkedIn.
Really interesting project! I especially like the idea of keeping Vite as a first-class citizen without turning the whole site into a JS application.
I'm curious though: how does Pannonico handle the boundary between the static build pipeline and Vite? Do you let Vite own the asset pipeline while Pannonico handles the HTML generation, or do they share more of the build process?
Thanks! The boundary is deliberately manifest-based. Vite owns the frontend asset pipeline: the JS/TS/CSS module graph, plugins, code splitting, hashing, and imported assets. Pannonico owns content, templates, HTML generation, and the final site output.
For production, Pannonico can run the configured Vite build, read its manifest, expose the resolved asset URLs to Go templates, and publish the rendered pages and Vite artifacts as one output tree. Vite can also run externally; Pannonico can consume its existing output.
In development, Vite keeps ownership of its dev server and asset HMR, while Pannonico rebuilds content and HTML. So they share build coordination, but not transformation responsibilities. The handoff is the Vite manifest rather than HTML passing through Vite.
I would like to get to know you better. Would you please contact me? t_g_@coolsoftDev
Some comments may only be visible to logged-in visitors. Sign in to view all comments.