...is the usual use case for the "why not just use HTML?!" argument. Still, even at the enterprise level, considering SSR's popularity, the "pendulum" has been in favor of static HTML for a while.

That's just a verbose way of saying "a file hosting service."

> using Hugo to compile markup into HTML with a CI/CD pipeline created to push the content up to your S3 bucket

What's wrong with that though? You could describe any computer technology in arbitrarily high level of depth to mock how complicated it is. Text editors sound very complicated too if you describe their internal data structures, the window server the GUI runs on, the operating system's context switching system, etc.

using a bash script to munge a few files together then a cron job running to rsync them to an Apache server running on a VPS

is considered morally and technically superior to

using a JavaScript tool to build a site then having a GitHub Action push the files up to an S3 bucket with a cloudfront distribution in front of it.

There’s no obvious reason for this, other than a belief that if something can be done with 50 year old technology, it should be.

With bash, cron, rsync, and a vps, one is using stable, long-lived tools that usually come with Linux, are vetted and patched automatically, and are familiar in the sense that those same tools can be used for all sorts of tasks, not just frontend development. There is also the argument that the only remote piece controlled by the service provider is a vps which still gives you lots of control and flexibility with minimal lock-in.

I prefer somewhere in the middle of the two extremes, but I see more appeal to the "old" approach than you allude to.

Sure, there are maturity differences but it's nowhere near so vast a difference as some claim.

These are just preferences. It's not a culture war issue.

However there’s fundamental difference: in a model of distribution by a distro the developer only produces a software but they don’t release it themselves. They provide source code and that’s it. Maintainers of packages for each distro vet new releases, test, and sometimes patch them so they work best within context of a given distro. So there’s extra effort spent on making sure the software is stable. In a model where a developer publishes their new release to some package repository directly (npmjs.com is just one of them, same applies to pypi.org, rubygems.org, etc) that extra “QA” by others than the developer doesn’t happen.

While past performance is no predictor of future performance, on the face of it I'm likely to bet on the stability and longevity of the classic time tested technology outlasting that of the newer technology. Especially if the newer one relies on specific 3rd party services.

eg the trade offs of the new might be weighted differently than the old as they apply to building vs hosting. Your build breaking due to stack changes is a different PITA than a security vuln in the hosting. Although the build might break more often due to churn in the new fangled stuff, you might trade that off for the less hands-on hosting maintenance.

But for another trade-off, the old stuff is far less service dependent, so less work to migrate if you need to change service providers.

Engineering is trade-offs, and decisions are made based on assigned weightings of various factors. The weightings are subject to bias though and thus always personal.

Why would I want to introduce so many a dependencies when I can have zero? Yes in this case old tech is superior. Sure if (and that is a big if) your blog is super popular you might want to "cloudflare" but that's about it.

“ I've come up with a set of rules that describe our reactions to technologies:

1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.

2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.

3. Anything invented after you're thirty-five is against the natural order of things.”

Only when applied to Linux, this amounts to:

Anything that was copied from UNIX is normal and ordinary and just part of the way the world works.

Anything that is included in a standard Ubuntu distribution is exciting and revolutionary.

Anything else is a ‘dependency’.

> Anything that is included in a standard Ubuntu distribution is exciting and revolutionary.

> Anything else is a ‘dependency’.

The picture you're painting of pure back-in-my-day-sonny! bias, while not totally wrong, is also not quite accurate. These different technologies have different installed bases, different probabilities of security vulns, different probabilities of still being maintained in 10 years, etc.

These are the kinds of trade offs we make.

2) As for probability - I had zero security incidents on my personal website / blog in 15 years. And I did not spend my life patching things. Just few minutes every once in a while. Keep this FUD for uninformed.

If there is a security vulnerability in a static site generator, that is unlikely to present to the internet, as the generator is not running on a public-facing server.

Hugo is now 8 years old, Jekyll is now 13 years old. Both are actively maintained, and given the inability of most people to string together a shell script that is both portable and correct, are likely better solutions than said shell script.

Sure doc. You are free to follow and waste your time and money. I do not get a kick out of using half of the world resources for writing glorified "hello world". And let all those intermediaries control what you do in a process.

Adams Douglas was magnificent. Your attempt to use his words in this particular context however is anything but...

I don't have any moral opinion about it - in fact I run a site with the setup described which is half why I am satirizing it (It's cheap to run, but it's also overly complex, has a load of dependencies that ultimately a simple HTML file shouldn't have, and the final setup is quite limiting).

I do think we lose something intangible by building websites with mousetrap-esque technologies. The idea is usually that when you abstract something away, it becomes simpler to understand and quicker to develop in - but IMO it seems like we have abstracted away and it has become harder to understand and slower to develop in.

No, the biggest problem is that for so called 'engineers', software engineers who do web development are by far among the worst at actually evaluating solutions based on their engineering merit. Thus, we get overengineered solutions in companies and areas that simply do not need that level of complexity.

The two approaches I described have exactly the same number of moving parts; they require you to understand exactly the same number of technologies. There is no difference in ‘complexity’.

there is so much can go wrong that this unlikely to be as simple as running a bash script.

i usually use node cmd to write terminal programs but recently tried bash and i found it much better for simple stuff.

Filezilla? rsync? Please share your secret!

[0]: https://uncomputation.net/cascading-style-s-expressions/

If you're writing a blog, then you probably want a way for people to subscribe to it instead of making them visit your site manually. Unless you are confident that you not only CAN write a feed by hand, but will never forget to hand-update it after updating the post itself, you're going to want to at least have the RSS feed be auto-generated.

And once you've added the infrastructure to auto-generate the RSS index, there's very little point in not auto-generating the HTML index, too. If only because, that way, you won't forget to run it.

A well-designed SSG, like all of the ones I've used, will interlock[1] updating the feed and the HTML. You can't easily update one without updating the other, just like you have to go out of your way to open a microwave oven without also turning it off.

[1]: https://en.wikipedia.org/wiki/Interlock_(engineering)

That’s a pretty neat idea, if all CSS on a site originated from your s-exp’s then you’d make it trivial to find not just what, but why a particular style has been applied (because now you’re only looking in an acyclic-graph, it’s easier to search).

While I like Jekyll and I'll continue using it, I can definitely relate to the frustration when first using it. I get this feeling that I already know what I want Jekyll's HTML to look like, and now I need to work backwards and develop an understanding of Jekyll in order to figure out how to get Jekyll to produce the desired output.

By "HTML" I don't actually mean that I have a problem with embedding specific markup in the page, it's stuff like putting the files in the right place, getting the template to contain the right material, etc.

And to be clear, I'm going to continue using Jekyll since it seems more practical than e.g. Hugo given my constraints / available resources / etc, and I may even migrate some other sites I maintain to Jekyll, but Jekyll, like other static site generators, seems to throw a lot of mess in the way of simple desires, as the parent comment articulates.

It's a truly dead simple static site generator that uses pandoc to turn the markdown into HTML, and mustache as the templating language. It's about 400 lines of actual code total. It doesn't include an actual server, it just converts your markdown files into HTML. It's by no means finished but I use it for my personal website.

It is very easy to over complicate things but it is also easy to use it for lightning fast static page generation focusing only on letting it manage the head and global page structure.

I expect to try at least one other static site generator before that project is done. To be fair I am very interested in a Python-based generator because I have a whole lot of visualization code in Python that could be cut-n-pasted into one.

An example (that I maintain) of what the author describes: https://www.bidadance.org. Each of the pages is just plain HTML on disk.

Edit: you cheated by changing uri. The point still stands for your home page

The events list is created with JS, yes. But that's the only thing on the whole site (~25 pages) that works that way.

Here's another site I maintain this way where the events list is plain HTML: https://www.kingfisherband.com

EDIT: for a nice summary, look at google's html style guide. Section 3.1.7 is particularly neat [0].

[0] https://google.github.io/styleguide/htmlcssguide.html#Option...

https://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html

Perhaps they were thinking of XHTML, which did require all tags because it was based on XML.

In XHTML transitional, and HTML1-4, what you'd get is browsers with divergent understandings of your DOM tree structure such that content that worked fine in one would be a horribly mangled mess (often breaking layout in difficult to read ways) in another browser.

And then I found out there were some browsers that wouldn't handle it right unless content-type headers were set up right on the server, and of course that made it an extra pain, especially on commodity hosting where you might not have that remotely under your control.

The "strict warnings"/"rendering problems crash the page" setting was also... mixed. Certainly prompted you to pinpoint the issue and fix it but that level of nag often felt unnecessarily militant after what everyone was used to.

<p>Qed.

<img src=“some_image.jpg”>

And

<p>Qed.</p>

<img src=“some_image.jpg”>

Are going to give me different results.

The `p` element in particular has pretty scary rules, but it basically boils down to "if it doesn't make sense for this to be inside a paragraph (usually because it's a block element of some kind), it ends the paragraph."

[1] https://html.spec.whatwg.org/multipage/syntax.html#optional-...

Furthermore, you need to know about this rule even if you do write `</p>`. If you write this:

    <p>
        <div>hello</div>
    </p>

    <p>
        </p><div>hello</div>
    </p>

They will indeed auto close the (first) paragraph, and also auto open a new <p> element because of the extra closing </p> tag.

Try it out by typing this in your address bar and open the inspector:

    data:text/html;charset=utf-8,<!DOCTYPE html><p><div>hello</div></p>

    <head></head><body><p></p><div>hello</div><p></p></body>

edit: sorry niconii, I edited my comment under your feet.

For example, try running the following document through the W3C's HTML validator[1]:

  <!DOCTYPE html>
  <html lang=en>
  <title>Test Document</title>

  <p>
    <div></div>
  </p>

[1] https://validator.w3.org/nu/#textarea

[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...

Of course, that screams "MISTAKE" that a validator should warn you about. Like a linter that would spot missing extra parentheses for an assignment in a if condition in C-like language. It is allowed to not put the parentheses, but it is recommended to put them.

And of course, that makes "Valid HTML" (almost?) redundant (There are probably "vocabulary" errors that are possible, like a missing src attribute for an img or a missing title tag in head - don't take my words on this though).

div in p is not invalid, it's outright impossible to obtain from HTML parsing.

You can obtain this by doing this in JavaScript:

    document.body.appendChild(document.createElement("p"));
    document.body.firstChild.appendChild(document.createElement("div")))

    data:application/xhtml+xml;charset=utf-8,<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml"><head><title>Hello</title></head><body><p><div></div></p></body></html>

    document.body.innerHTML

    <p xmlns="http://www.w3.org/1999/xhtml"><div/></p>

While the HTML parser does handle errors, to conform to the spec, document authors must not make these errors.

Here is an excerpt from the spec[1]:

> As described in the conformance requirements section below, this specification describes conformance criteria for a variety of conformance classes. In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.

Furthermore, a user agent is not required to correct errors, and can simply halt at the first error[2]:

> The error handling for parse errors is well-defined (that's the processing rules described throughout this specification), but user agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification.

[1] https://html.spec.whatwg.org/multipage/introduction.html#how...

[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...

Citing from [1]:

Earlier [SGML] HTML DTDs included the following definition for flow capturing this in a rather straightforward way:

    <!ENTITY % flow "%block; | %inline;">

Nesting of phrasing into flow elements is about the most basic property of the HTML grammar. In SGML, the flow/phrasing hierarchy is expressed by declaring the content model of flow elements as allowing %phrasing;, where %phrasing;, like in earlier HTML DTDs, is substituted into a string such as a|abbr|... containing all phrasing elements as a name group.

For example, the element declaration for the p element is as follows:

    <!ELEMENT p - O 
      (#PCDATA|%phrasing;)*
      -(%flow_only;)>

- the content of p elements can be any sequence of text content (#PCDATA) and phrasing elements, and

- flow content isn't just forbidden in direct child content of p (via admitting %phrasing; elements only), but also isn't admitted anywhere in descendant content of p, as expressed by the -(%flow_only;) SGML exclusion exception, and

- the end-element, but not the start-element tag of p can be omitted, as declared in ps tag omission indicator - O

where the flow_only parameter entity contains block-level elements as described above, ie. flow elements that aren't also phrasing elements.

[1]: http://sgmljs.net/docs/html5.html

There was a time when people thought we might be able to change web development practice and browsers to something more consistent, but (a) what they chose was XHTML and (b) the benefit of switching was not there.

However, I also want to add to the other point here; namely, "why do this in the first place?"

Google mentions "file size optimization" in the style guide linked above, and it led to criticism on HN and elsewhere along the lines of "sure, maybe shaving off a few bytes adds up for Google, but you're not Google." However, this really isn't why I do it, and I think maybe it's poisoned the discussion a bit.

For me, it's mostly about reducing visual noise. It's not necessarily less typing if you're using an editor that auto-inserts closing tags, but I think it's harder to read with the end tags, particularly when it comes to tables. For instance, consider this table (which, if you're curious, is about Super Nintendo audio samples):

  <table>
    <tr><th>sample rate</th> <th>data rate</th>    <th>max length</th></tr>
    <tr><td>32000 Hz</td>    <td>18000 byte/s</td> <td> ~3.641 s</td></tr>
    <tr><td>16000 Hz</td>    <td> 9000 byte/s</td> <td> ~7.282 s</td></tr>
    <tr><td> 8000 Hz</td>    <td> 4500 byte/s</td> <td>~14.564 s</td></tr>
  </table>

  <table>
    <tr><th>sample rate <th>data rate    <th>max length
    <tr><td>32000 Hz    <td>18000 byte/s <td> ~3.641 s
    <tr><td>16000 Hz    <td> 9000 byte/s <td> ~7.282 s
    <tr><td> 8000 Hz    <td> 4500 byte/s <td>~14.564 s
  </table>

On top of that, let's be honest, <html><head></head><body></body></html> is just useless boilerplate. We all know what goes in the head and what goes in the body, and I think we can all figure out where the HTML starts and ends. The browser knows all of this too, which is why all of those tags are completely optional. Not only does getting rid of that make the code less noisy, it solves the age-old problem of "should I indent the head and body or not?" (Though, in practice, I still keep <html lang=en> so that I can specify the language for people who use screen readers. </html> is just silly, though.)

Today, data tables are mostly dynamically generated, probably via accessing an API endpoint of some sort. The dev would at most write a function that would output the data inside a <table> element. But the table data itself would only be visible in the browser, it wouldn't be hardcoded into the HTML markup.

It's similar to how often you see tables in Markdown.

https://www.markdownguide.org/extended-syntax/

HTML tables are similarly cumbersome, with or without closing tags. If you have a table of static information to fill in, copy/pasting from Excel into a HTML table generator and pasting the output is signficantly faster.

I'd also much rather write an HTML table by hand than a markdown one.

The verbose format has no advantage whatsoever, unless you are doing weird xml stuff.

Apache has supported Server Side Includes forever. All you need to do is drop an 'include' in your HTML file and Apache will inject the contents in the right place.

    <!--#include virtual="/header.html" --> 

https://httpd.apache.org/docs/current/howto/ssi.html

Edit:

IIS: https://docs.microsoft.com/en-us/iis/configuration/system.we...

Lighttpd: https://redmine.lighttpd.net/projects/1/wiki/docs_modssi

Nginx: https://nginx.org/en/docs/http/ngx_http_ssi_module.html

Tomcat: https://tomcat.apache.org/tomcat-7.0-doc/ssi-howto.html

Jigsaw: https://www.w3.org/Jigsaw/Doc/User/SSI.html

If I received your code I would start by rolling my eyes, then by wasting some time learning Yet Another Technology (TM) that I will likely forget before the next time it comes handy.

In my experience, if you care about maintenance, one should stick to the worn path unless they have a good reason not to.

> It's cool that Apache also supports conditionals.

<...shudders...>

I wouldn't suggest using it for anything complex but it's ideal for inserting common headers and footers into static HTML.

Plus, it's using fewer technologies than anything you suggest. Less to maintain, less to go wrong. Sounds like a winner.

(didn't downvote you - I actually appreciate your sharing of your point of view)

Everything in the XML "ecosystem" (XSL, XPath, XDT, SOAP) is so unfriendly that I'm no longer surprised everyone is reinventing these concepts in (unfortunately) JSON these days.

Resorted to using the DTD schema as it can support complex things (and that’s what they use for the probably never to be released updated version) through some python hackery to generate a hundred or more classes that takes forever to compile and, strangely enough, actually does what its supposed to do which is represent SVG as a bunch of classes with reading/writing to xml.

I was going through a phase and tried that with rss but it was more hassle than it was worth.

—edit—

Should add the DTD makes things like enums for tags or whatever simple so you can have typed values and property formed xml documents — can’t remember if I ever managed to get that working with the XSD.

An iframe with some CSS might however work to some degree.

Or you could use a frameset

    {{include "/includes/header.html"}}

[0]: https://caddyserver.com/docs/modules/http.handlers.templates

[1]: https://github.com/caddyserver/website/blob/master/src/docs/... <-- Try doing that with SSI

That aside, Caddy is awesome, thanks for a great piece of software!

    $(document).ready(function() {
        $('nav').load('/nav.html');
    });

Note, the people in the article were burned by wiki software that went unmaintained during its rewrite from Python 2.7 to Python 3 (afaict). Now they are editing HTML files on a production server. I'm sure getting let down like they did gave them a specific distaste for certain trade-offs that work for the rest of us, but you can also imagine the babies being thrown out with the bathwater like scaling out an article database without revision history.

That said, it tends to be a good thing when you realize a vastly simple solution works for you.

> I'm normally someone who's attracted to ideas like writing in a markup language instead of raw HTML and having some kind of templated, dynamic system (whether it's a wiki, a CMS, or a themed static site generator), as you can tell from Wandering Thoughts and DWiki itself.

Note that HTML is a markup language (an SGML application) and so is XHTML (an XML application).

If you meant by "a markup language" a user-friendly or domain-specific markup language, then there is good news: if you use XML as your markup (ideally by defining your own wiki's DTD, as simple or as sophisticated as you like) then you can associate an XLST transform "program" with it, and then a click on "view HTML" in the browser will display the underlying XML [sic], not as you would expect the generated XHTML, as the XHTML is generated from the XML on the fly only (not stored persistently anywhere, thus avoiding file clutter).

For example, you may like a structure like:

  <docs>
    ...
    <doc>
      <title>...</title>
      <text>...</text>
      <keywords>...</keywords>
    </doc>
    ...
  </docs>

Advocate for simple and easy to read UI if you want but come on now.

When you're just relying on browser defaults and there no basic styles to make the text readable. The pages are a challenge to understand. You can have plain html but using CSS to create some visual hierarchy would go a long way. Feels like there's two text sizes and two colors.

With pure HTML and possibly some cleanly included JS he could get any visual appearance he wants, such as the common hero video or the effects you see where scrolling manifests differently as you scroll through different parts of the document.

In this case though, the author isn't submitting it, so it's not like they're the culprit. But even if they were it's also not really an indictment of any sort either; happens to everyone who writes online; it's the siren song of "engagement" with your work. (Lots of people here want to believe this site is somehow fundamentally different from Reddit or any other forum where "internet points" dictate the flow of content. It isn't; the tics and triggers are just different. Topics like this are a good example.)

> With pure HTML and possibly some cleanly included JS he could get any visual appearance he wants

With default browser font sizing and spacing? Yeah, sure, you can get any bad look you want from pure HTML and some JS. CSS is practically mandatory for webpage readability these days, but it's all a moot point since the OP doesn't seem to be arguing against CSS in any form anyway (and even literally admits he uses it.) Honestly the linked support site is mostly OK in this regard; though I'd blow up the font size a point/point-and-a-half more, add a tiny bit more line spacing, and make the margins bigger.

You mean dark grey text on light grey background?

Or a mobile stylesheet that displays one paragraph and half a photo on a 5k monitor and makes you scroll for the rest?

  body { font-family: helvetica; line-height: 1.5; }

"our current support site [https://support.cs.toronto.edu/] is that most basic thing, a bunch of static .html files sitting in a filesystem (and a static file of CSS, and some Javascript to drop in a header on all pages)."

this circumvents Netlify's bandwidth metering and all the users retrieving the IPFS assets keeps the IPFS assets loading quickly

note, I append ?filename=filename.extension to the url to keep track of which hash is what

ironically Pinata is also a gateway that will show any hash for free

then I just deploy the whole project/frontend/backend to github and that auto deploys to netlify and the domain name routes to that instance

He keeps mixing his data into his presentation of that data.

Keep your data however you like, plain text files in a simple directory structure, database, whatever. The important thing is, as much as possible, organize the data in a presentation neutral way.

Choose whatever programs you want to present that data, in whatever context. When you eventually tire of some of those solutions, if you've done things right, you will simply discard them and pick new ones to present your data in new ways.

As long as he continues to mix his data with it's presentation at the outset, he doesn't have data, he has a website, or a wiki, or whatever, and he'll keep having to solve the same problem.

For instance, if you decide you want to give a templating language like Mustache a try - have fun programmatically extracting your content from those HTML pages and translating it into Mustache. Doable? Sure. Easy? Certainly not - and it's going to be very painful and manual if you didn't keep the same format for all of those HTML pages.

That can be a problem the other way around as well. I wanted to convert a Mediawiki-based site to static HTML pages, but ultimately gave up and instead updated to a recent version of Mediawiki, because I couldn't find a solution which would've kept all existing URLs working.

The designed virtue of Markdown is its ease of authoring; why would you want to convert to it? It's surely easier to convert directly from HTML to whatever other format you want than from Markdown to that format.

https://ontology2.com/the-book/html5-the-official-document-l...

but practically it never happens. So we get stuck with languages like markdown, restructured text and various sorts of wiki markup. Just about everybody who gets serious about extracting data from Wikipedia learns the hard way that parsing wikimedia markup is possible to get 90% right with a lot of suffering but if you have a DOM-intelligent HTML parser often you can get 99.95% right with 2 minutes of work parsing the HTML.

(The reason why is that people look at HTML and fix the markup until the HTML looks right, they don't look to see that the markup is conformant to any spec.)

For a long time I've wanted to like Dreamweaver and it didn't seem so bad in 2003 but today I type a few characters into the live view and then I can go on vacation and the characters might have appeared a week later. You'd think every HTML editor that is embedded in HTML was developed by a sadist except that it seems there is a basic conceptual problem that makes WYSIWYG HTML editing completely impractical.

I guess the answer depends on many factors; personal preferences and also the project’s context play a big role; personally I’m surprised how often I choose <em>HTML</em>.

I'm assuming this excludes laptops, so we're talking tablets/smartphones? If so, out of curiosity, how often are you writing code on a smart phone/tablet? I've never written a line of any code on anything other than a laptop (when travelling) or desktop.

Ssh on a phone is better than no ssh, but good lord is it frustrating.

I would never willingly edit HTML (or anything else for machine consumption) on a phone, that's what real keyboards are for.

One selling point is that it only uses regular HTML syntax, so no need for dedicated syntax highlighting. Development seems to have stopped though since 2015.

I also love Vue and the simplicity of remote html resources/dependencies for simple sites. I created a single html file VueJS template that has a bunch of resources out of the box for things that I commonly want if I want to create a quick simple site.

Check it out -> https://vue-template.spaghet.me

The beauty of the site is its basically a quine. You can get started by just running: curl https://vue-template.spaghet.me -o index.html

---

I have created a few NFT / Web3 pages using that template. For the most part, a lot of Web3 UIs are just client side sites that connect to on-chain data, so another super lean use-case for simple HTML pages.

It's really easy for this kind of endeavor to get out of hand. The hardest part of plain HTML is sticking with it and writing just enough automation to keep you sane.

It's also far too easy to get sloppy when working on something that does some basic preprocessing. My personal preference is to keep the pages as HTML, and write a processor that does minor modifications to the HTML DOM, using a proper HTML5 library.

If done carefully, you can keep the experience close to the experience of editing pure HTML. For example, rather than some custom "shortcodes", you can use custom HTML elements. Custom HTML elements are a more verbose, but come with major advantages over terser shortcodes (use existing tooling, you don't need a parser). You can do simple stuff like automatically add alt="" or srcset="" to your <img> based on image metadata, or automatically generate breadcrumbs using site structure.

The general idea is to keep it as close to plain HTML as possible. If possible, make it so the page is plain HTML.

It is so so trivial to vet local HTML changes and use a repository where you just directly push to master that I'd suggest it to anyone building a plain HTML site just for the fact that you're getting free backups as a side effect.

Git, when used without branches and merges, is really dead simple.

I wanted something simple e.g. based on pandoc. I have also tried writing posts in pure HTML. HTML has lots of advantages, but when you have to read your own stuff, it's not very pretty. Markdown brings more clarity to your documents and also allows you to embed HTML.

I have used Sergey [1] to create some basic HTML templates, but it is not as pleasant to use as Markdown. Also, generating RSS and creating archives are problematic. This should be automated.

I decided to use Blot [2]. I am not familiar with the author, but I think it is a good tiny product worth recommending. It will turn any document into a page. You can create an HTML page and it will be embedded into your template. The author appears to be nice [3]. The code is open source.

[1]: https://sergey.cool/ [2]: https://blot.im/ [3]: https://blot.im/about/notes/politics

For instance the "template" of your web site might be an HTML document that has something like

   <div id="content"/>

It's not that hard but I think it's never caught on for a few reasons.

One of them is that DOM parsing and unparsing is an order of magnitude or two slower than text-based templating sytems. I guess you could parse the template once and cache it but it's still going to be slow.

Another is that you run into "hygenic macro" problems if you want to merge random DOM trees into each other: for instance you could have multiple elements with the same id, the same classes used for different meanings in some other places. You need some answer to this if you want to make something scalable (e.g. the whole point of this exercise is that you should be able to transclude HTML + CSS from anywhere and have it "just work")

Finally it would be really nice to have a reliable WYSIWYG HTML editor, particularly one that would help you use CSS classes in a disciplined way to customize the system to add whatever markup features you want for your site.

It doesn't exist and I wonder why. Every HTML editor I've seen is just garbage. Latency for typing characters is several round trips to the moon. Navigation, selection, where characters appear when I type all seem to be random, like my computer is possessed by the devil.

(It's a general problem w/ most WYSIWYG editors that look like MS Word, including MS Word. I'm sure there is something conceptually wrong with the model which is why all those editors are buggy, but it seems everybody else thinks it is OK for selection, navigation and where you type characters to be random.)

I don't know how fast text-based template systems are, but I can do a clean build of my entire website in under half a second. That seems pretty fast to me. I've been adding content to it for over 20 years now... it's not a massive site since it's just me, but it's not exactly small either.

Every page is authored as HTML, with some extra headers at the top. It's parsed as HTML5. The processor will apply templates in a fairly simple way... merge everything in <head>, merge everything in <body>. There's a special tag for templates that means "put the <body> here, instead of merging".

Any given piece of HTML will be parsed / unparsed only twice, because the templates work on DOM manipulation. The second parse / unparse is there because I use an HTML minifier, and the HTML minifier has a bytes in/bytes out interface.

> Another is that you run into "hygenic macro" problems if you want to merge random DOM trees into each other:...

This is a beast of a problem. If I need an ID in a template that may get used in multiple places, then there's some piece of code somewhere generating the ID.

My experience is that it really becomes a problem when you have large, large sites with tons of people working on them, and it's not a problem at all for one person.

> Finally it would be really nice to have a reliable WYSIWYG HTML editor, particularly one that would help you use CSS classes in a disciplined way to customize the system to add whatever markup features you want for your site.

It's called "Dreamweaver". Truly one of the most powerful web authoring tools ever made.

Selection, where the cursor ends up when I click on something and where the cursor goes when I hit the arrow keys are all erratic enough to make me wonder if my computer is possessed by the devil.

I've submitted so many tickets to Adobe about strange problems with Dreamweaver that it's a wonder I haven't been hellbanned from their issue tracker.

I will not go back to plain HTML, though. That is the other extreme, which is even harder to maintain, because changing the general structure, navigation or layout would require a lot of manual work. Maybe I'll write a site generator on my own ...

Honestly, it was a lot more fun when it was my hobby and just me messing around in my spare time. I know WordPress is not particularly popular on HN, and I understand the reasons. That said, I use it for my personal blog because it reliably gets out of my way.

Couple this with good CSS and HTML could actually be composable. Composability was known to be a good thing in GUIs in the 1970s and the web still struggles with achieving it without heaps of JavaScript.

Of course I’m sure there is some weird reason this was never done, so instead you need mountains of shit to work around it.

It's old tech but it's really at the sweet spot for power versus complexity. I still use it and recommend others do as well. It makes a static site much easier to maintain.

I still remember the days of "plain HTML pages", most people didn't even get to close tags properly and shipped malformed HTML to browsers.

I wish I knew a way around this because my knowledge of web design is incredibly small and I intend to keep it that way.

Just copy the CSS from http://bettermotherfuckingwebsite.com/

Anything else is probably overkill.

If you don't want to learn web design, you don't have to learn web design. Keep creating and serving sensible html pages and you will be alright.

https://github.com/runvnc/tersenet (note that Gemini is a real system, mine is just an idea)

https://moonmusiq.com/

(behold http://nerget.com and weep when you see the "new" features it refers to :D )

How about PHP + CSS?