I recently wrote my own very similar static site generator in Python to migrate away from Ghost CMS and Python today has everything you need:
- pathlib is brilliant for managing filesystem
- jinja2 still best templating engine out there
- mistune very good markdown -> html renderer and it's quite easy to extend
- lxml is quite fast when it comes to HTML modification for dynamic content injection (CTAs etc.)
- livereload is great for live development and you can get around Python's slowness with smart reloading rather than having to rebuild the entire site
- tailwindcss works brilliantly with static generators as dropping in some html in markdown makes content creation really flexible
Making your own generator has never been this easy!
My only gripe is having to tune livereload to avoid rebuilding everything with each modification as building all 400+ articles on Python currently takes around 4 seconds which when doing theme development is a bit annoying but a small price to pay for staying in the Python ecosystem. For content creation you can just rebuild the effected graph of objects which is just some miliseconds, even in Python.
If you consider how this all works the issue becomes rather obvious: Your content is compiled into Elixir module attributes as strings at build time. The more content you have, the larger these modules become and the more data gets compiled into your application. For a small blog with a small number of posts this would work fine. In our case the ever growing list of lessons, posts, and translations results in a lot of content.
This creates two main pain points: First, compilation times have become painfully slow as the compiler has to process all that content into module attributes on every build. Second, on more than one occasion our Fly.io release has failed due to size and memory usage during deployment, thankfully retries have worked and gotten us on our way.
The trade-off here is that NimblePublisher's strength, everything pre-compiled for fast serving, becomes its weakness when you're dealing with substantial content volumes.
When we pull the trigger on a migration away from NimblePublisher we'll be sure to publish an updated blog post.
joelcares · 15h ago
With incremental builds 11ty compilation is very fast.
- pathlib is brilliant for managing filesystem
- jinja2 still best templating engine out there
- mistune very good markdown -> html renderer and it's quite easy to extend
- lxml is quite fast when it comes to HTML modification for dynamic content injection (CTAs etc.)
- livereload is great for live development and you can get around Python's slowness with smart reloading rather than having to rebuild the entire site
- tailwindcss works brilliantly with static generators as dropping in some html in markdown makes content creation really flexible
Making your own generator has never been this easy!
My only gripe is having to tune livereload to avoid rebuilding everything with each modification as building all 400+ articles on Python currently takes around 4 seconds which when doing theme development is a bit annoying but a small price to pay for staying in the Python ecosystem. For content creation you can just rebuild the effected graph of objects which is just some miliseconds, even in Python.
If you consider how this all works the issue becomes rather obvious: Your content is compiled into Elixir module attributes as strings at build time. The more content you have, the larger these modules become and the more data gets compiled into your application. For a small blog with a small number of posts this would work fine. In our case the ever growing list of lessons, posts, and translations results in a lot of content.
This creates two main pain points: First, compilation times have become painfully slow as the compiler has to process all that content into module attributes on every build. Second, on more than one occasion our Fly.io release has failed due to size and memory usage during deployment, thankfully retries have worked and gotten us on our way.
The trade-off here is that NimblePublisher's strength, everything pre-compiled for fast serving, becomes its weakness when you're dealing with substantial content volumes.
When we pull the trigger on a migration away from NimblePublisher we'll be sure to publish an updated blog post.
Did you mean Static maybe?