Hacker News Reader

Comment by Solvency | Hacker News Reader

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?

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.

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.

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.

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.

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

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!

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!

What's wrong with rendering a navbar with a simple iframe? Or SSI? Or JS .innerHTML? Or PHP echo?

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

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)

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.

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.

Reply on news.ycombinator.com