github.com
I found myself writing a lot of custom code to get my site going because I wanted to use Jinja templating inside Markdown.
Once I was done, I decided to strip out `staticjinja` in favour of my own site generator.
And so Jinjabread was born!
One suggestion I’d make is to do two passes—one to index all the inter-page links, another to actually render the templates. I do that (and full text search) with SQLite: https://github.com/rcarmo/sushy/blob/master/sushy/models.py
It seems most of these never became fit for use for some bigger website.
Though you may have to use a plugin for responsive images: https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-id...
I've been using it for a static docs and blog site and it seems to be one of the most mature and comprehensive static site generators available.
Mouth-watering.
May we have some garlic butter with that?
Upvoted ya for having good taste ;)
Pure HTML, CSS, and vanilla JS. And a few files organized in a few folders. And upload.
Why must even a static site in 2024 require Python, libraries, framework dependencies, build steps, etc?
And because even in 2024, good SEO requires that the content be directly in the HTML source, even without JavaScript.
Also there is no such "old fashioned way". The old fashioned way was to use frames, server side includes with Apache (before PHP became popular), or have WYSIWYG tools do it for you.
SSI nowadays requires a host with a specific server stack and configuration. Meanwhile, with purely static files it's easy to find high quality hosts or CDNs, even for free.
For simple sites, it's much easier to pre-generate the static content and then upload the output files (Web 1.0), rather than dynamically generate it for every HTTP request sent to the server (Web 2.0).
It’s always been a pain to do something like maintain consistent navigation across multiple statically rendered pages. Very easy to look back with rose tinted glasses but previous solutions were often worse for the user, e.g. shared navigation created entirely in JS. Hell, I remember sites that used a shared Flash file!
SSI: requires you to have a server to run the include on. Means you can't use something as cheap as an S3 bucket
JS innerHTML: bad for SEO
PHP echo: nothing wrong with it at all, but again, requires you to be running on a server, keep it up to date, etc etc
The compromise between functionality and convenience since then has been creating frameworks that do these types of post-build steps to give modern functionality (templating, search, accessability options, dynamic theming, reusable custom components, ...) without compromising that idea, while still allowing flexibility on the presentation. Some go too far in either direction and lose the intent, some barely need that flexibility at all and would better be served with pure html.
Why don't people make static sites with a simple "Markdown-or-Similar to HTML" converter, CSS, and vanilla JS...etc?
(This is what I do, btw -- http://zim-wiki.org + a template)
..because it makes the files larger? I see why it's useful during dev though. (Great name!)
The web of the 90s and early 2000s was just so accessible as a kid curious about how it all worked. You could cobble together a personal website on Geocities and learn by copy and pasting code you found on someone else's website that did something cool. It just promoted this really beautiful experimentation and cross pollination of ideas that is mostly lost now.
Instead of "why not?" the author could sell the "why" there.
Surely the prettiness of the source that you actually edit is even more important than the final result?
A pretty final result can help with all sorts of future scenarios, like piping curl into grep for quickly checking if something exists. Similarly, I despise CSS preprocessing since figuring out a solution in the browser then has to be backported, hopefully with a source map to assist.