HN Explorer

Show HN: A static site generator that prettifies the output HTML (github.com)

71 points by jdeanwallace ↗ HN
I recently stripped out Django from my personal site and converted it to a static site, using `staticjinja`.

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!

47 comments

[ 4.9 ms ] story [ 117 ms ] thread
cantSpellSober
> Prettify all generated HTML (because why not?)

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

brainzap
I also format my blog HTML, I cant say why, but I want it to be tidy and readable.
dlachausse
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.
alxeder
the next generation is using devtools, inspect element
dlachausse
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.

cantSpellSober
These add things that are missing (<html>, missing closing tags etc). Great for debugging but not the actual source.
jjgreen
You should definitely do that at https://www.lingscars.com/
filcuk
I can't tell if it's real or satire, but I like it (not in a visit ever again way)
jjgreen
Real, as well as being a work of art.
jkestner
Wow, the presentation belies the nicely written source (excepting obfuscated JS). It's a depixelated love letter to 90s sites.
Ylmaz
These pages should be served compressed anyways right? Then there will be no difference in size anymore.
dlachausse
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.
chrisweekly
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.
cantSpellSober
Yep, I know images are big, fonts are evil and what gzip is.

Instead of "why not?" the author could sell the "why" there.

dinkleberg
Not everything in life needs to be optimized.
pfarrell
And not every optimization is worth the effort.
cantSpellSober
In this case effort was required to remove the optimization.
cantSpellSober
Nope! We weren't talking about "everything in life" but instead HTML in statically-generated websites.
djbusby
Soon as I saw the title I thought their "why" was: so it looks good when I view source.
jkestner
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.
Retr0id
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?

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

Retr0id
Right, that's why I don't use minifiers. My pretty templates render to pretty HTML, with no additional prettification pass needed.
forgotmyinfo
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.
nsonha
who needs this feature? If there is a need for it this should be done in the browser anyway.
rigid
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.

Seb-C
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?
Solvency
Can anyone please explain what happened to the idea of making static sites the old fashioned way?

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?

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

[deleted]
(comment deleted)
Solvency
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.
[deleted]
(comment deleted)
Seb-C
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).

forgotpwd16
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.
afavour
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!

Solvency
What's wrong with rendering a navbar with a simple iframe? Or SSI? Or JS .innerHTML? Or PHP echo?
afavour
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

cpach
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.
thiht
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.
forgotmyinfo
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!
zen928
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.

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

fuzztester
>And so Jinjabread was born!

Mouth-watering.

May we have some garlic butter with that?

Upvoted ya for having good taste ;)