- cross-posted to:
- technology@midwest.social
- cross-posted to:
- technology@midwest.social
You must log in or register to comment.
for $0 a day, you can utilize Codeberg pages for static hosting or VMs from Oracle Cloud Free Tier (4 cores and 24 GB RAM that you can use on up to four VMs).
for the domain part, you can get 'em from afraid.org or eu.org.
VMs from Oracle Cloud Free Tier
These vm’s are apparently only for people that actually spend their money on net-services etc - IE people registered in the Capitalist surveillance networks as ‘good customers’/available to follow. At least I and a bunch of other ‘hidden’ non-spenders are routinely rejected (ignored/failed reg etc). ‘Free’ tier my ass…
Sorry, not your fault oc, just tired of all the Corp f*ckers…
The process looks like this:
- Author your web content on your hard drive.
- Preview it in your web browser.
- When you’re happy with what you have, upload it to your web host. Repeat as often as you’d like.
That was a lot of words to say “just use static HTML and assets”… There’s one huge glaring unfixable issue with static HTML though. There’s no templating at all. That might seem obvious or a good thing, but are you really going to copy paste the same
<head>,<header><nav>and<footer>across 300 blog posts? Then what happens if you ever change layout? Are you going to modify 300 html files by hand? Hell naw.I often lament that there is no HTML
<import>feature yet to solve this problem. IFrame is ok, but also kind of shit and it’s not the intended purpose at all. It’s pretty much the only missing feature keeping me from recommending static HTML.The answer is just use PHP as a build step. It’s a tiny bit more complicated, but not by much. It’s still extremely flexible, you can write it to do whatever you want since it’s your own build step, and you won’t be fighting it. But you also get the benefits of not dealing with the ramifications of copy pasting.
It’s not an only html solution, but I’m fond of using nginx server side v includes, which with a little setup let’s you do things
<--# set var="browser-title" value="Colophon" --> <--# set var="page-title" value="oink" --> <--# include file="/stubs/header.shtml" -->You can do simple things like set variables and import reusable html templates. And since nginx is commonly used as the webserver or proxy you kind of get this functionality “for free.”
PS generating html by hand isn’t that bad though. You can either script it yourself or just have your own manual template html file that you base everything on, and/or use something like emmet/emmet-vim
That nginx thing looks pretty cool! Very neat (if using nginx).
In the second half you’re talking about dynamic imports right? Like
fetching the html with JS and then loading that? I try and avoid doing that for various reasonsIn the second half you’re talking about dynamic imports right? Like fetching the html with JS and then loading that? I try and avoid doing that for various reasons
I think I get you? No JS involved, no dynamic requests from the client side. Opening the page in a browser, you’d just see the one page request which arrives fully formed looking like static html.
If you mean my scripting and emmet comment, I just meant to script the creation of the static html then serving it. But not like programmatically, more like
for file in ./blogs/$(date -I).*/*; do cat $file >> ./blogs/$(date -I).serve-me.html; doneor something (probably more rigorous than that, but that kind of mix of convention is semi automated hackery). I find non-commercial web pages don’t really need to change very much, so I’ll often just copy a header and footer into a file and fill in the middle manually. But I actually enjoy writing HTML. :9I also try to avoid JS unless there’s something I really want to do with it. And then I like to offer a <noscript> alternative.
Or you could just use a https://github.com/myles/awesome-static-generators
I prefer the flexibility of PHP personally, but there’s pros and cons to everything. For example, I don’t really see how setting up 11ty is any easier than a 10 line
build.php. Might as well keep it simplePHP is additional vulnerability, while static html is bullet proof, as long as http server is safe and up to date.
How is PHP a vulnerability if it never leaves your machine and you only use it to build the HTML?
Oh, if you’re only using it to generate static html it’s of course safe. I would prefer minimal markdown for blogs, though.
I guess I just really like HTML. Any excuse to write actual HTML makes me happy
Don’t some web frameworks support ahead of time compilation? If I remember correctly, at least Svelte?
If you don’t need HTML explicitly, wouldn’t static site generators also work? They should also support inline HTML, if Markdown or whichever markup language a given generator uses isn’t quite enough.
That’s what I said. Use PHP as a static site generator. You write .php files which are almost exactly semantically the same as .html files, then you have a 10 lines of code build.php script which outputs it all to raw html and assets, but with the power of being able to import your navbar and such more easily. It’s like master pages in ASP.NET if you’ve ever used that, but that may be dating myself lol. You generally don’t need a framework at all. I can give an example of what I use for my own website if needed, but I’m too tired to get my laptop until tomorrow
I understand what you meant. I mostly mentioned frameworks because you complained about a lack of HTML imports. I haven’t used ASP.NET in particular, but I’ve used PHP & non-js server-side libraries with template support.
Still, the focus of your original comment was blogs, for which I think that PHP/HTML is overkill. At least for the average blogger.
Markdown is a lot more approachable for the average person than HTML. Still, basic knowledge of it can’t hurt, and like I wrote earlier, static site generators typically allow you to add raw HTML if necessary.
I know that there are lots of approaches to static sites with reusable components. I’ve used PHP for it too, as well as template languages and even shell scripts.
Oh yeah I guess… but in my experience non-tech people can’t even manage a .txt file asset directory, so Markdown is far too complicated for them.
The original article was advocating for manually typing out your .html .js and .css files. Like just complete raw dog it 90’s style, which is even harder for most people, so I kind of just assumed tech knowledge.
Anything short of a clicky-draggy online interface or asking Claude to do it is generally outside the reach of most non-tech people. I don’t think any average bloggers are going to become front-end developers just to start their blog; I basically just completely ignored that part of the article because it’s kind of insane. So my comments have been targeted towards people with at least mild programming knowledge.
If you’re hand typing out .html anyway, it’s like a 5 minute additional process to set up PHP and copy a build script online. That way you’re still sticking to the “fundamentals” as closely as possible, in this context raw assets, but now you have the power of imports and other cool stuff if you need it. I do agree with that part of the article. People are too willing to jump in to any which framework because they’re popular, when in most cases the amount of frameworks you need is zero. Just write some articles and you’ll know what you need after 10.
My problem with stuff like 11ty is that, in theory, it’s good. It abstracts away the HTML. But to actually use it, you have to understand HTML anyway; and at that point, why the middleman? Just write HTML. The second you need an <article> tag or a <section> or an <aside> or a <nav> or a <ul> of <a>nchor tags but some of them are external so they need the noref shit… you get my drift. You end up writing HTML inside your markdown, but now you are finagling two different languages. I don’t really see how # is much simpler than <h1> anyway.
