Mastodawn

Hardcore Narrativist Apr 15, 2020

@wizard I'm not sure what your point is: that users maintaining a blog should write the HTML by hand? In that case, what's the advantage?

@hardcorenarrativist This is the article that inspired that post, though I'd been thinking similar things for a while before I read it: https://stackingthebricks.com/how-blogs-broke-the-web/

How the Blog Broke the Web

I first got online in 1993, back when the Web had a capital letter — three, in fact — and long before irony stretched its legs and unbuttoned its flan

@hardcorenarrativist I don't know if it's necessarily better for everyone to be hand-coding HTML. (Though HTML was originally designed to be hand-coded!)

You could also erase the distinction between abstract content and viewable web pages by using WYSIWYG editors, for example.

@hardcorenarrativist but to answer your point more directly: it's not that bloggers should be hand-coding HTML, it's questioning whether a "blog" - a website featuring content primarily organized in reverse chronological order -- is even a good idea. Maybe it isn't, for a lot of sites.

Hardcore Narrativist Apr 15, 2020

@wizard Aha, I see! That makes more sense now.

I have mixed feelings about it: on the one hand, standardisation of these formats and such is both natural and valuable. On the other, I think maybe we've done it too much? And most people have forgotten (or don't even know!) that they can publish whatever they want, however they want, instead of just posting micro-updates on social media and such.

But maybe that's just nostalgia? Maybe creativity simply has other forms now? idk

@hardcorenarrativist I do like looking back at very old web sites which are designed as documents or document collections, rather than logs. They tend to stand the test of time well, and they can live on in the Internet Archive even if they disappear. The abstracted units of "content" which produced them, if they ever existed in databases or whatever, are long gone. What's left is particular HTML files.

Hardcore Narrativist Apr 15, 2020

@wizard BTW, if you haven't read Amusing Ourselves to Death, it sounds like a book you'd like. I put my summary here:
http://hcoder.org/2019/11/02/book-summary-amusing-ourselves-to-death/

Published... on... my blog *ducks*

Book summary: Amusing ourselves to death | HCoder

This is the first part of my summary for the book“Amusing ourselves to death”by Neil Postman. It’s abook about media (specifically TV, as the book is from 19...

@hardcorenarrativist :) will check it out!

@wizard the big difference is that static content is faster, doesn't rely on a backend that can (will) break, and is much, much harder to hack (if not impossible, it depends on how much dumb javascript you include... ideally none)

@wizard ...can't SQL Inject something that doesn't have SQL, and can't run shellcode on a broken interpreter or cgi if you don't have an interpreter or cgi.

Surface area reduction. :)

(that said, I have a wordpress blog and a static 1-page hugo website)

@renatoram Implementation details!

@wizard not to a sysadmin and/or infosec guy, no 😊

@renatoram they're implementation details that happen to matter to a sysadmin and/or infosec guy, is all. :)

@renatoram So I guess "unimportant" in my initial post is relative. Not unimportant to everyone.

@wizard if you abstract enough, "data goes in" -> "implementation details" -> "data comes out" describes pretty much everything ever built.

But that level of abstraction makes the argument irrelevant.

Yes, and?

@renatoram It doesn't describe *everything* ever built, no. If I put a README.txt file on a web server, there is no processing between the data going in and the data coming out. The data going in is a text file. The data coming out is a text file.

@renatoram You could say "well, that doesn't count as 'anything ever built' because it's nothing." And I'm like, yeah. That's it exactly. :)

@renatoram but seriously, sites created by SSG's absolutely do "rely on a backend that can (will) break"

It's just that it breaking would prevent you from regenerating/updating the site, and wouldn't affect the existing site

@wizard different ball game.

Development works in stages: code that breaks in dev is normal, code that breaks in testing is normal and must be fixed, code that breaks in QA is bad, go back to dev and write better tests.

Code that passed every step of the Development Lifecycle, and still break in production, is BAD.

An SSG can't break in production because the production artifact is pages, not an application anymore. If it breaks in development, who cares? That's just how dev works.

@wizard this is obviously from a sysadmin POV: for the dev who has to write code that works and doesn't break the SSG obviously it's important that it breaks, and why, and how to fix it.

But it can't impact production (aside for a possible delay in releases), so it's by definition a lower level damage.

@wizard corollary: if the output artifact IS an application (even just a client-side one because of all the Javascript it runs) then "static generator' is a bit of a misnomer. It's just a compiler with a fake nose and dark glasses 😄