Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Blog with Raw HTML

devpoga.org

Post reply on HN
Print view View original

101–110 of 137 posts

Re: I Blog with Raw HTML

#101

Post by eviks »

cookedcode wrote: post #96
eviks wrote: post #52

Earlier quoted context omitted.

Writing raw html and wiring it yourself is a hassle, how is not upgrading node a bigger one? Besides there are SSGs that are a single binary

I promise you, HTML is not a hassle... It's markup. You describe the page, and then... you're done. And if you don't use weird, niche tags, it'll work basically forever.

This is a patently false promise. Yes, it's markup, but a bad one un-ergonomic-suitable for direct human consumption. Even the author of the blog understands it and uses alternatives

> with md-block for markdown

> You describe the page, and then... you're done

Unless you want to re-describe something, of course. Maybe sort a column in a table...

Re: I Blog with Raw HTML

#103

Post by globular-toast »

cookedcode wrote: post #98
globular-toast wrote: post #87

I used to blog with raw html. In 1999 when I was 12. It sucked. There is a reason why we use things like markdown now. Still, you kids should definitely dig into the fundamentals at least one time and write raw html. Just don't stay there and pretend it's somehow better for you.

Lots of things suck when you're 12. Speak for yourself, though, HTML really isn't that difficult.

Didn't say it was difficult. Doing the dishes isn't difficult, but it still sucks.

Re: I Blog with Raw HTML

#107

Post by artps »

superkuh wrote: post #10

A tiny bit of webdev-side dynamicism can really help with managing visitor-side static websites built on .html files in directories. If you run your own webserver and write HTML then check out server side includes. Being able to include .html fragments in other .html files means no need to edit the same bit in dozens of .html files (ie, left_menu.html, footer.html, etc). And since SSI hasn't really changed in 20 year…

Absolutely agree. Just for fun, I recently implemented SSI using Cloudflare Workers [1] — but with a twist to feel like it's from 2025. It's a bit of a shitcode experiment, but I really wanted to recapture that early hacking spirit.

[1] https://github.com/artps/ssi

Re: I Blog with Raw HTML

#108

Post by wink »

eviks wrote: post #52
mromanuk wrote: post #33

Earlier quoted context omitted.

I used wintersmith.io. At some point it was abandoned and eventually the node version needed was old and other stuff associated with it. It became a hassle.

Writing raw html and wiring it yourself is a hassle, how is not upgrading node a bigger one? Besides there are SSGs that are a single binary

I faintly remember when the kernel config asked you if you wanted both `a.out` and `ELF` support.

No one says that single binaries compiled in the last 10 years might be usable without a VM in another 10 or 20 years.

And no, 20 years for the same blog to exist isn't even so rare.

Re: I Blog with Raw HTML

#109

Post by eviks »

wink wrote: post #108
eviks wrote: post #52

Earlier quoted context omitted.

Writing raw html and wiring it yourself is a hassle, how is not upgrading node a bigger one? Besides there are SSGs that are a single binary

I faintly remember when the kernel config asked you if you wanted both `a.out` and `ELF` support. No one says that single binaries compiled in the last 10 years might be usable without a VM in another 10 or 20 years. And no, 20 years for the same blog to exist isn't even so rare.

If you make such risks up, then no one says that html will be readable in the same way in 20 years (which is already kind of true as you have a lot of old blogs with awful layout on mobile)

But there is an even easier one - nothing will happen to your html built files of 20 years, they'll remain... static.

The worst is you'll go to updating your lovely html by hand, but you would've saved yourself wasting 20 years doing that instead of using a better system.

Re: I Blog with Raw HTML

#110

Post by superkuh »

cookedcode wrote: post #100
superkuh wrote: post #25

Earlier quoted context omitted.

re: static, there are two main points of view. Static from the visitor's perspective or static from the webmaster's perspective. This seems to be about static from the webmaster's perspective which is a "modern" view and one that seems to have overloaded the term since 2015 or so.

What? No... static web pages can have JavaScript, but everybody gets the same page over the wire. Dynamic web pages have some sort of program generating the resulting page for you, like PHP or Ruby; they can return different HTML for the same URL. That's dynamic. It has nothing to do with if you're the client or the server.

For any communication I think we need to take as a premise that static HTML and static web sites are not the same category of thing. Any particular page on the web can be totally static or totally dynamic or a mix. There are static HTML pages on static web sites. There are dynamic HTML pages on static web sites. There are static HTML pages on dynamic web sites. And there are dynamic HTML pages on dynamic web sites.

The meaning of static HTML is the least contentious. A static HTML page is just an .html (or .htm, or anything else if the mimetype is set right) hypertext markup langage document that is stored on a file system as a file and sent to the end user when they request the URL that maps to that file. The HTML encodes what the web site user will see and does not change.

When the static .html file includes "static" (not really since it is executed code) javascript (or other executing language embeds) that changes the page to something other than displayed by the html in the file on disk. So it becomes a dynamic HTML page (for ~5 years called "DHTML").

The only place where static HTML becomes unclear is in the case where some webserver linked program generates the static HTML on demand with no storage of the HTML as a file on the filesystem before being sent to the site user. In this case even though the user sees only static HTML there's crucially no file ever created on the webserver so it's dynamic HTML.

The meaning of static website is increasingly more unclear compounding on the fuzziness of what a static HTML page is. Generally there are the same two points of view as above but with a tweak.

There's the website users point of view where a static web site is static if the pages are just HTML and do not require executing any code to view. If you (or your browser) look at the source you can read the text and see the image URLs. It does not have to be generated by the browser's execution of some client side code.

Then there's the developer point of view where a static web site if the code required to generate the website is stored in a static file on the webserver. In this framing you can deploy a self contained .html file which includes the javascript code for a client side dynamic web application. This web application can completely change the text shown and even draw in outside information not in the file. But since it can be put on a CDN as a static asset it is a static web site.

You advocate the developer-view of what static website means. But this perception is a modern overloading of the phrase. For literal decades static meant what the user-view of static website. Neither is wrong but unless you state it explicitly there will be misinterpretation like above.

Post reply on HN