Very nice. Like my own stuff, you have an index file and dependent media per folder, which is the only real way to scale out beyond a few dozen pages (my site has… a few more - https://taoofmac.com/static/graph)

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

There's a gazillion nice python SSGs but when it comes to advanced stuff like responsive imagrs, i18n or js optimization, you always have to add it yourself.

It seems most of these never became fit for use for some bigger website.

Facebook's SSG Docusaurus does those things: https://docusaurus.io/

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.

That does not sound like a good idea to prettify code where whitespaces are significant and can make or break your layout. How do you deal with it?

>And so Jinjabread was born!

Mouth-watering.

May we have some garlic butter with that?

Upvoted ya for having good taste ;)

Because doing it this way sucks. I used to do it this way a decade ago when I was learning and it was hell to maintain and keep consistent. It's the reason why I learned PHP in the first place (stuff like `include('header.php')` blew my mind!), because I was aware of the problems and went looking for a solution.

Because we didn't want a markup language for hypertext to be the same construct we write blog posts / documentation / etc. in, we wanted consumable human-readable DSLs with no explicitly linked connotations to a browser engine (WYSIWYG renderers, markdown)

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.

Because even in 2024 there is still the unavoidable need not to repeat huge chunks of code such as the page layout, menus, headers and metadata in every single page of the website.

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.

I'm referring to the old fashioned way. Is iframe not cool enough? SSI not leetcode appropriate? All of these methods worked fine on 2001.

Iframes have a pretty bad UX and are ugly and difficult/impossible to properly integrate in any decent design. Also it does not work well with touchscreen and responsive designs.

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).

Fads and lack of education? HTML is better than ever, and authoring it isn't that bad. I do it for my own personal site, and I haven't keeled over yet. It's still allowed!

Very few people ever did that, especially at any kind of scale. There were different answers, certainly: server side includes via cgi-bin, using PHP to bolt together string templates etc.

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!

What's wrong with rendering a navbar with a simple iframe? Or SSI? Or JS .innerHTML? Or PHP echo?

iframe: not good for accessibility, doesn't resize to fit content

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

I'll slightly modify your argument; because Pure HTML does suck:

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 writing text in plain text files and maybe having markdown for formatting is more preferable than shoving it in HTML files. Also reducing redundancy is nice, e.g. having header in its own file rather copied in every page.

It’s a matter of preference. IMHO, Markdown is a simpler and more pleasant format for writing/editing. The conversation to HTML is automated, so I don’t really need to think about it.

> Prettify all generated HTML (because why not?)

..because it makes the files larger? I see why it's useful during dev though. (Great name!)

You see this concern about file size of websites all the time, but the extra white space is not what makes websites large, it’s all the images, fonts, and JavaScript libraries that get bundled with them. For most sites the HTML is negligible and compresses well if you enable GZip.

True. Also, for a typical web page, over 90% of user-perceived latency occurs AFTER the HTML has been fetched, unzipped, and parsed. That doesn't mean minification and compression are worthless, but it may help put things in perspective.

Soon as I saw the title I thought their "why" was: so it looks good when I view source.

"why" in the repo, not the HN title

I'd say, it's to optimize for source readability. That's something many of us relied on to learn HTML, and we need to keep that path open.

Not everything in life needs to be optimized.

And not every optimization is worth the effort.

In this case effort was required to remove the optimization.

I'm a bit confused by this too. My static site generator also generates mostly-pretty HTML, but not because there's a prettification pass, it's just because the templates themselves are pretty (because I wrote them that way).

Surely the prettiness of the source that you actually edit is even more important than the final result?

> 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.

Right, that's why I don't use minifiers. My pretty templates render to pretty HTML, with no additional prettification pass needed.

I also format my blog HTML, I cant say why, but I want it to be tidy and readable.

I think readability of HTML is something that people of a certain age just expect. I remember in the early days of the web just doing a “View Source” for interesting websites and learning a lot of really neat tricks to apply to my own websites.

You should definitely do that at https://www.lingscars.com/

Wow, the presentation belies the nicely written source (excepting obfuscated JS). It's a depixelated love letter to 90s sites.

I can't tell if it's real or satire, but I like it (not in a visit ever again way)

Real, as well as being a work of art.

the next generation is using devtools, inspect element

Browser dev tools are incredible, but they just hit different than view source.

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.

These add things that are missing (<html>, missing closing tags etc). Great for debugging but not the actual source.

These pages should be served compressed anyways right? Then there will be no difference in size anymore.

Gzip exists, and text compresses pretty well. Unless it's 20 MB of JavaScript just to render some text, that you're best just removing.