[dmje]

To me the idea of a small web is a great one. But then for some reason everyone equates small with "static builder" and before you know it you're into a hellscape of complexity with static site builders, SPAs and other madness.

What happened to "I'll edit this .html file and FTP it up, with maybe a light sprinkling of CSS and js for any interactive elements"? Why did devs get obsessed with a deeply complex jamstack type thing to do even incredibly simple sites?

It's like a sort of "iceberg web" - small on the surface but hiding a mountain of complexity and dependencies under the surface.

[nicbou]

I like static builders. It's just markdown files and some templates. It makes editing much easier. If your website is about the content and not the presentation, it makes a lot of sense.

I made my own static site builder (typical HN!) and it's just a python package. At its simplest it depends on Python Markdown and Jinja.

The website itself is dead simple and gracefully degrades. It's just text on a page after all.

[vintagedave]

> I made my own static site builder (typical HN!) and it's just a python package

Same! I designed the look of my site, and then wrote Python to generate it, though instead of Jinja I even wrote my own templating library. The goal of reinventing the wheel was to learn Python through writing a non-trivial, useful app and libraries.

I haven't quite mustered up the courage to publish the source, yet, though: being a learning exercise I'm painfully aware some of the code is not as good as it should be. And I'm still learning what makes Python code Pythonic.

> What happened to "I'll edit this .html file and FTP it up..."

A SSG _is_ that, these days. My SSG generates my own site design. If I tweak the site's look and feel, I do that once and re-run the SSG. I wouldn't want to have to do that across multiple HTML files.

My process is:

* Write Markdown

* Run the SSG script

* FTP it up (overwriting previous contents; I have dated backups of every version, and the most recent run of the SSG is the canonical version.)

I entered the site in the competition, since it's no-Javascript, pure HTML & CSS, minimal, manuscript-style typographic focus, with articles on design, management, and the just plain miscellaneous. Very much going for the 'old-school personal site about whatever someone finds interesting' feeling, and hopefully some bits will be of interest to HN people too, maybe. https://daveon.design if you're interested!

[nicbou]

Mine replaces Craft CMS and its twig templating system, so Jinja made a lot of sense.

It also converts and resizes images, processes SCSS, and a few other things that suit my workflow.

Editing source-controlled files in a familiar text editor is blissful.

[2b3a51]

Readable (just) in Seamonkey although some of the text is overwriting other text. Fully readable in links on the command line. Well done.

[vintagedave]

Thankyou! I'll check SeaMonkey. I've tested only Firefox, Chrome and Safari (and desktop and mobile) so far. Really glad to hear it works in links! That's awesome.

There should be a reasonable amount of accessibility markup too (in how it's structured plus some specific accessibility items) for screen readers as well.

[2b3a51]

Try palemoon perhaps.

Seamonkey is an old school fork of Netscape before they pulled out Firefox. I suspect the CSS rendering is marginal CSS 2.

I use Seamonky on OpenBSD i386 arch as Firefox no longer supported. I am using deliberately low spec computers for personal surfing.

The links render shows the 'skip to main content' link which is always a good sign that accessibility has been addressed.

[nicbou]

If you have a few minutes to kill, I'd love to know how allaboutberlin.com feels on such a device. I sometimes choose convenience over coverage, but I still try to make the website accessible.

[rchaud]

> Why did devs get obsessed with a deeply complex jamstack type thing to do even incredibly simple sites?

Because devs don't think of websites like a place for personal expression; to them, personal websites are usually roughly structured wikis of stuff they've learned that would be mostly hard to read or follow for others.

So they geek out over the details of the blog infrastructure. If instead of a website, they were asked to draw something, they'd focus on the sturdiness of the paper.

[packetlost]

This seems like the correct answer. I can't think of how many times I've been like "I should publicize all my notes" and then I restart the cycle of looking into blogging or note-taking/wiki software (with publishing options like Notion). I'm not much into writing long-form content, but I journal and log pretty consistently. It's always the "distill this body of knowledge into an easily consumable article-style thing" that I lose interest, both because it's hard but also because I feel the return on investment is super low. I already get the benefits of my notes, and blogs are too 1-way to get meaningful feedback unless it goes "viral" on a link aggregator like HN or Lobsters. Maybe I just underestimate how much feedback is typically given or over estimate the difficulty in making it to the front page...

[ilyt]

> What happened to "I'll edit this .html file and FTP it up, with maybe a light sprinkling of CSS and js for any interactive elements"?

What happened are people being annoyed with hand-fucking html every time they want to write a blogpost started writing/using static site builders

[Solvency]

So instead of typing ("hand fucking") a few HTML characters around your blog post you trade it in for a big complex orgy of additional abstractions, tools, and processes.

[ilyt]

Yes. HTML is not great and when you have to fuck with CSS to it becomes distracting. Just put the effort once into making template I want then just write markdown.

[philistine]

I don’t understand how something like Jekyll could be considered big and complex. What examples do you have in mind?

[baobabKoodaa]

Well, I run my own blog on Gatsby, and about once per year I have to dedicate a weekend to figure out how to make it run locally again, because the entire JS ecosystem is an unstable hellscape of ever-changing complexity that morphs from one shape to another for absolutely no reason at all.

[philistine]

While I totally understand the node.js idea of building the backend with the same language as the frontend, I don’t understand why anyone should use JS for a static website. The point of a static website is to get away from server troubles, and it seems like building something static on top of JS is just the worst house of cards. I’m happy with my tech choices because I always think about the people behind my choices.

I moved from ConTeXt to XeTeX because the people making context didn’t care about documentation.

I moved to Jekyll because the people behind it were making Github. They built something rock solid.

I moved from Apache to Nginx because the people making it were trying to build something simple to configure. It showed and I could solve my redirect issues in minutes.

[ryukoposting]

Came here to say this. If I need to fiddle with NoScript just to read your web page, it isn't small.

[mouzogu]

we like to solve problems by creating 10 new ones

[Dalewyn]

>Why did devs get obsessed with a deeply complex jamstack type thing to do even incredibly simple sites?

When all you have are frameworks, everything looks like JavaScript.

[bccdee]

I don't think it's fair to equate static site generators with SPAs. At its core, a static site generator just renders markdown and slots it into html templates. That's nice and convenient and still perfectly simple.

[dylanzhangdev]

in my bolg, i use vscode write markdown files，next run a simple nodejs script: use pandoc convert md to html and rewrite index.html.I'm happy with this simple enough build system that it gets me started writing lightly.

https://www.seazhang.com/, Link are given as examples, because blog content is Chinese and personal, not worth mentioning.

[boredumb]

imo using your language of choice as an html templating engine that serves your "static" files is the best choice - you can essentially be left with editign css/js and html files but if you have some neat feature you want to add you can implement it and start taking advantage of the templates to interpolate your new stuff. Keeps your clients small and it's up to you to keep it simple or add what ever giant frameworks you want.