Hacker News Reader

Comment by cantSpellSober | Hacker News Reader

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

Yep, I know images are big, fonts are evil and what gzip is.

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

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.

Nope! We weren't talking about "everything in life" but instead HTML in statically-generated websites.

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.

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.

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.

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

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.

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

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.

Reply on news.ycombinator.com